IRC channel logs
2017-03-17.log
back to list of logs
<akkad>where can one find a list of the guile library/packages? <wingo>guix pack -f docker looks nice! <wingo>haven't tried it out yet tho <civodul>i've see your message about guildhall & guix <civodul>looks like there's something we could do, indeed <wingo>yeah. if we use a higher-level dsl that means that we could probably omit the sha256 too -- the sha256 of the source would correspond to the git revision in which it appears <wingo>if we really embrace git anyway <wingo>dunno, lots of possibilities <wingo>i found guildhall really complicated to work on. guix has a lot of code but i think it's fundamentally simpler <ArneBab_>same for me — it took me lots of time to even do simple things in guildhall <ArneBab_>lots of reading into "how does this datastructure work exactly, and where does this information come from?" <marusich>Hey, just wanted to say I saw the release email for 2.2, and it looks really good! Very excited to learn more and play more with Guile. Thank you for all of your hard work. <peterbrett_work>In Lepton-EDA (yeah there was a fork/rename) we use smobs a lot but our C library is a bit thread-unsafe <peterbrett_work>If I just chuck a Big Smob Mutex in there will everything work w.r.t. the Guile 2.2 finalizer thread? <wingo>peterbrett_work: if you have a "main loop" i would advise in that case to disable automatic finalization and just run finalizers every so often <wingo>what happened in Lepton-EDA? :) <peterbrett_work>wingo: Unfortunately we now have some bits that do large and non-trivial amounts of work in Guile-land without returning to C <wingo>peterbrett_work: if there are other parts of lepton that are called in a timely way you can invoke finalizers explicitly there too <wingo>e.g. when you create a new smob, you can invoke finalizers <peterbrett_work>wingo: Hmm, interesting idea! Just to check, is the Big Library Mutex hammer likely to _not_ work? <peterbrett_work>wingo: To cut a long story short: there was a period of gEDA core dev inactivity during 2015 <wingo>peterbrett_work: well consider for one thing that maybe your users have a guile without threads. in that case finalization happens via asyncs -- and could it be that the lock is already held when the async is invoked? <peterbrett_work>wingo: During that time, someone came along and said, "I'm going to rewrite everything using C++ & Python!" <peterbrett_work>wingo: When the old-timers resumed activity, he'd already made swingeing changes to the codebase <wingo>dunno, if you need some sort of global invariant to hold, and a global lock can enforce it, then great. of course you limit concurrency and might stall finalization depending on how long that takes <wingo>for me if you need threadsafety guarantees in a library with a lot of c finalizers, disabling automatic finalization is totally legit <peterbrett_work>wingo: So now we have Lepton EDA which is basically a continuation of the "original" gEDA, and gEDA which is basically Roland's Refactor. It's confusing. <wingo>peterbrett_work: tx for the update :) good luck with lepton! :) <wingo>we should change the mention on gnu.org/s/guile then i guess <civodul>sad story but yeah, happy continued hacking, peterbrett_work! <peterbrett_work>wingo: As far as I can tell, then, the Big Library Lock will work iff it's not held over any call into libguile <wingo>if that works for you, sure. sprinking scm_invoke_finalizers() around your code can work as well and probably doesn't impose lock ordering constraints or bottlenecks either, but as you like :) <peterbrett_work>wingo: Just exploring the options. I like a code sprinkling as much as the next developer. ;-) <wingo>peterbrett_work: we can do it at the next release, patch welcome though if you are willing. the process is a bit arcane though so if you are ok for waiting for next update, we'll do it then <wingo>peterbrett_work: if you send a mail with the details to bug-guile tho that would be great <peterbrett_work>Quick question: would you accept a patch to use SipHash for internal hashing? Or is that likely to be too slow? <peterbrett_work>Also… 2.2 release notes have a "See XXX in the manual, for more" when talking about "scm_new_smob". :D <wingo>regarding siphash, good question, we have some hashes in abi now, but if we updated quickly it would probably be ok. dunno. <wingo>the other hashing question is about the seed; current best practice is to randomize the hash seed on every invocation, by default anyway <wingo>it's a longer topic, in short :) our current hashes are good in terms of avalanche etc but vulnerable to that collision attack <wingo>so that would be the only reason to change afaiu, and that solution takes more planning <peterbrett_work>Yes and grabbing a good random seed on startup for e.g. the interned string table could be tricky to do in a nice cross-platform way <peterbrett_work>It would be nice to follow Python/Perl/etc. in addressing that potential attack vector for web-facing services implemented in Scheme <wingo>we already have the ability to get a random seed from the platform fwiw <wingo>usually it's just reading some bytes from /dev/urandom <civodul>if you're doing to update the Lepton-EDA URL, could you look into it? <wingo>i don't think i'll get to it today <wingo>i had my cvs dose for the week :P <OrangeShark>GNU Guile 2.2 release is still on the front page of Hacker News <amz3>look like my wiktionary API scraping went smoothly <amz3>I have a 1G compressed wiktionary dump of most articles from wiktionary in english <amz3>now I will need to structure the html from each pages into something that can be understood by a machine ie. me. <amz3>guile 2.2 is already in duckducgo search results <amz3>both hn and mailling list <amz3>I think weechat IRC client has a guile extension using 2.0.14 <akkad>anyone free to port a simple 5 liner to guile? can pay <daviid>wingo: i really like that idea you posted: guix is the guildhall that we always wanted! <wingo>tx! i hope it works out somehow <wingo>it's one of those areas where people have energy sometimes but there's often some limit that prevents things from expanding <wingo>maybe guix will be our vector to success :) <daviid>I hope one of us picks up the idea and makes it real, but I can not, I'm too busy already :) <akkad>ok so any ideas on calling out to gunzip a json file in guile? <daviid>akkad: (system "gunzip ...") and grab the returned status code ... <akkad>need to read from stream. any make-pipe? or with-open-file? <daviid>(*json->scm* #:optional port) : Reads a JSON document from the given <daviid> port, or from the current input port if none is given <amz3>akkad: I have something for you <amz3>wait, you need to stream the result of json? <amz3>I had this problem too, but I could not solve it in guile <amz3>AFAIK there is no json stream reader in guile <amz3>I worked around it, using scm instead of json <amz3>that said IIRC there is C library that can read a stream of json that can be bound to guile <daviid> "guile-json supports the parsing and writing of JSON from Guile." <daviid> "It aims to be fully compliant with the json.org specification, and" <daviid> "is released under the LGPLv3.") <amz3>yes, this doesn't it can stream read a bigger than RAM json <amz3>yes, this doesn't mean it can stream read a bigger than RAM json <amz3>akkad: what is your initial problem? maybe there is another solution <daviid>but akkad mentionned he/she wnats to open and read from file, here above in this channel ... so guile and guile-json would fit I think <amz3>a json can be bigger than ram <amz3>the wiktionary.scm takes 17Giga decompressed that's big compression factor (vs 1G)