***catonano_ is now known as catonano
<rekado>Aurora_v_kosmose: there’s scandir in (ice-9 ftw) ***dftxbs3e_ is now known as dftxbs3e
<chrislck>anyone can read C and decode guile's read.c -- "end of file in string constant" in scm_lreadr - what does it mean *RhodiumToad goes to look <RhodiumToad>seems obvious enough to me - it's reading a "..." quoted string, but hit end-of-file before seeing the closing " *janneke wondered about the boldness of the statement "anyone can read C" ... <chrislck>janneke: I meant "is there anyone who can read C" <chrislck>janneke: I meant "is there anyone who can read C better than I" <janneke>chrislck: yes, luckily RhodiumToad got that :-) <janneke>i can't seem to remember that i'm not allowed to do (catch (and foo?) ... ) *janneke there should be some extra ... in there <miskatonic>does guile support gobject inspection repositories? <janneke>miskatonic: there are two projects working on that, afaik, guile-gi and guile-golf <dsmith>Home come Scheme doesn't have an all-dancing all-singing loop macro? Because CL is not properly tail recursive. <miskatonic>who needs the loop macro, anyways. There are enough other ways in CL to perform iterations <miskatonic>as there are in emacs lisp, which has by default neither loop nor tail recursion but still gets its job done <janneke>dsmith: that makes some sense; my occasional encounter with the imperativeness and c-like loop'iness of lisp drives me mad ***ftknox_ is now known as ftknox
<RhodiumToad>is there a way to tell the bot "later tell A or B ..." <lloda>sneek: later tell RhodiumToad yes <lloda>sneek: later tell lloda or RhodiumToad no <sneek>Welcome back lloda, you have 1 message! <sneek>lloda, lloda says: or RhodiumToad no <sneek>Welcome back RhodiumToad, you have 1 message! <sneek>RhodiumToad, lloda says: yes <RhodiumToad>guile-cairo bug: use of a size_t* where an unsigned long* is expected <RhodiumToad>just making "len" an unsigned long would suffice. passing an unsigned long containing the size of a memory object to a parameter of type size_t is always safe regardless of relative sizes of types (to the best of my knowledge) <RhodiumToad>but passing size_t* where unsigned long* is expected is an error unless size_t is typedef'd as exactly an unsigned long <RhodiumToad>I made the mistake of not testing on i386 arch when updating the freebsd port, so I have a mailbox full of build failures <lloda>is this fix enough for you to build? I can push a release <RhodiumToad>I'd prefer a release since then I can just update the port to the new version rather than having to add a patch <lloda>sure, np. Just asking if you had more things to fix <lloda>if you can test that'd be top <RhodiumToad>take me a couple hours maybe because I have a big build going on to test something else <lloda>np, just let me know whenever <lampilelo>so i have a queue_pop() function that locks and unlocks an scm mutex, the function is then called in a loop that empties the whole queue; i wanted to ask a question if it's worth it to make the mutex recursive and lock it before the loop, but after reading the code it looks like it does almost exactly the same thing both ways <lampilelo>i think i'll make a queue_pop_unsafe() function that won't lock and instead put the only lock-unlock in the process_queue() around the loop <lampilelo>nah, i'll make a comment about possible optimization if its needed <RhodiumToad>lloda: confirm build success on freebsd i386 and freebsd armv7 <RhodiumToad>sneek, later tell lloda confirm build success on freebsd i386 and armv7 as well as amd64 <lloda>got it RhodiumToad, will push the release asap <sneek>Welcome back lloda, you have 1 message! <sneek>lloda, RhodiumToad says: confirm build success on freebsd i386 and armv7 as well as amd64 <sneek>zzappie was in (here?) 28 days ago, saying: dsmith-work: Hey thanks ive found it too and was stuck exploring this person's profile for about an hour he or she did lots of cool stuff. <daviid>dsmith-work: is that so? i thought nicks were unique and if do not exists or misspelled, that the bot your tell us 'unknown ...'