IRC channel logs

2021-03-05.log

back to list of logs

<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>have*
<apteryx>seems no
<apteryx>daviid: I've sent the guile-lib patches to guile-devel; if they don't show up feel free to ping me
<apteryx>otherwise there's an exact copy here: https://notabug.org/apteryx/guile-lib
<daviid>apteryx: ok tx- i'll look asap
***janneke_ is now known as janneke
<leoprikler>wingo, civodul: w.r.t. Guile 3.0.6, would it be possible to include my patch to https://bugs.gnu.org/45131?
<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
<leoprikler>thanks
<civodul>hey Guilers!
<wingo>moin :)
<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)' :-\
<lloda>other than that
<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)
<lloda>right right
<spk121>wingo: my updated list of nits from fuzzing the new vs old reader https://paste.debian.net/1187964
<chrislck>wingo: wouldn't you want to issue-deprecation-warning these quirks?
<wingo>chrislck: eventually yeah, not in 3.0.6 tho
<wingo>spk121: thanks!!!
<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>Happy Friday, Guilers!!
<civodul>hey dsmith-work, happy Friday!
*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>
<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>should be enough
<soda__hobart>yup, it worked, haha, sorry for the dumb question
<soda__hobart>or easily checkable question, i guess
<lloda>nw
<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
<soda__hobart>oh? i need to read that part of the documentation then
<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?
<soda__hobart>like this: https://paste.debian.net/1188010/
<soda__hobart>i guess i wouldn't be able to close the socket?
*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
<RhodiumToad>civodul: why is that surprising?
<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
<civodul>and a pony, too
*sneek wants a pony
<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>Does the same happen if you do --to=bytecode?
<leoprikler>If not, it might be a differently flavoured #45131.
<rekado>no, with “--to=bytecode” it compiles the file correctly.
<rekado>I don’t know what a joiner is
<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)
<wingo>moo
<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
<dsmith-work>wingo: Ah good. Sometimes those go unnoticed..
<wingo>yeah tx for repeat
<wingo>wtf is #b#b0 ????
<manumanumanu>Ahoy!
<manumanumanu>ArneBab: It would be nice to have some smaller data to work on with wispstate. Something that takes max 10 seconds.
<manumanumanu>can I just truncate the csv?
<manumanumanu>or will that give me invalid data?
<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)
<manumanumanu>anyway, good night!