<rlb>wingo: perhaps for now, might be better to just change my code to collect a list of string fragments and then join them at the end (reverse!ing if necessary). Guessing that might be reasonably competitive... <rlb>i.e. no reason I actually need a string port... <rlb>(basically I think a chunkier version of what you described if that was just operating on chars) <apteryx>does guile has a debbugs tracker for patches? <apteryx>daviid: I've sent the guile-lib patches to guile-devel; if they don't show up feel free to ping me ***janneke_ is now known as janneke
<wingo>leoprikler: sure. will scrape patches from guile-devel between 1 dec and now <wingo>will let you know when i am done so you can check <lloda>would it break anything to accept '#0datum' or '#0 datum' for #0(datum) in the reader? <lloda>well I guess it would break '#0(datum)' :-\ <wingo>lloda: there are a number of weird productions that guile accepts that would be nice to "fix" -- but ideally 3.0.6 goes out the door with the same quirks as 3.0.5 <wingo>just so we can make sure not to make too many changes at once, and can fix up accidental incompatibilities (which would be bugs) <chrislck>wingo: wouldn't you want to issue-deprecation-warning these quirks? <wingo>chrislck: eventually yeah, not in 3.0.6 tho <lloda>those (quote #<eof>) are funny <chrislck>I'd have thought someone who codes using quirks is pointing a gun at their feet <pkill9>is there a snippet or something for guile-commonmark that creates tables from markdown? <leoprikler>chrislck: although they certainly do, you don't want to pull the trigger for them without warning them first <chrislck>leoprikler: i'm not saying remove support, just point the trigger via issue-deprecation-warning <chrislck>It help a lot to us e.g. modules changes, removal of _ use. *dsmith-work does the Friday dance <soda__hobart>does anyone have any suggestions for debugging a "symbol not found" error when using dynamic-link? <soda__hobart>the shared library object loads, but then i cannot access any of the functions with dynamic-call or dynamic-func <soda__hobart>i did LD_DEBUG=symbols and i saw this: "symbol=libguile_msg_muncher_LTX_init_muncher_guile; lookup in file=./libguile_msg_muncher.so [0]" <soda__hobart>i haven't been able to figure out what LTX is, or if it is relevant <soda__hobart>wait, i think the names are still getting mangled by C++. maybe i need to use extern <lloda>you def need to use extern "C" for any exports that will be accessed by Guile <lloda>else you have no control of what the export name is <soda__hobart>yeah, all the names are _Z19scm_from_P12... etc. sounds like payton manning hiking the football <soda__hobart>if i'm only trying to use one function, can i get by with only putting extern "C" around that one definition? <lloda>if you have a module init function in your library then you can define the exports there and they don't need to be extern "C" <lloda>that's how i did things before there was an ffi <lloda>i suppose the ffi way is easier now, plus it makes the function available to anyone and not just Guile <soda__hobart>i will try to write something up about this and other stuff i've learned about mixing guile and cpp and put it on the web or something <soda__hobart>ok, here is another question: is it bad to store a datagram socket in a closure? *civodul surprised to see srfi-1 'member' in gcprof <RhodiumToad>the socket would be closed when the closure is gc'd, I assume <RhodiumToad>which might of course be arbitrarily far in the future <civodul>RhodiumToad: because 'member' isn't supposed to allocate (at most one closure) <civodul>i often find myself running statprof, then gcprof, then statprof #:count-calls? #t <civodul>IWBN if there was a tool to aggregate all that info <civodul>+ Geiser support to navigate profiles <rekado>I have this “language” specification that compiles JSON to Scheme. In the past I could do “guild compile my.json --from=my-language --to=scheme”, but now it prints a backtrace. <rekado>the backtrace suggests that find-language-joint returns #false <rekado>there are two problems here: 1) the language definition is a compiler to scheme, so this should work and 2) #false is just propagated until it causes an unrelated error (In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): #f) <leoprikler>If not, it might be a differently flavoured #45131. <rekado>no, with “--to=bytecode” it compiles the file correctly. <leoprikler>a joiner is a sequence of compilers between from and to. <leoprikler>if there's a direct compilation from from to to, you don't need a joiner (that'd be at least one step removed) <leoprikler>so applying my fix to #45131 *should* resolve that issue (please test it, so that we have something else than Tree-IL to base that information on) <dsmith-work>Heya wingo. "it can record remembers the file name" Might want to adjust that in api-debug.texi <wingo>tx for the tip, saw your pm :) will fix <manumanumanu>ArneBab: It would be nice to have some smaller data to work on with wispstate. Something that takes max 10 seconds. <manumanumanu>ArneBab: If I take the algorithms you are using at face value, there is still quite a lot that can be done. <manumanumanu>and moving to vectorlists would make vector-append amortized O(1) instead of o(n), which - since it is called a billion times. <manumanumanu>and, if you migrated the whole thing to vector-lists you would get rid of those pesky vector->list <manumanumanu>and, if anything you could probably use transducers to fuse most of those (append (map (remove ...)), and I do believe that the delete-duplicates in that is more efficient than the one built into guile (which does a full rest-transverse of the list)