IRC channel logs


back to list of logs

<akkad>where can one find a list of the guile library/packages?
<akkad>found it
<civodul>Hello Guilers!
<wingo>moin :)
<civodul>hey wingo
<civodul>did you sleep better yesterday? ;-)
<wingo>fine, tx :)
<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>see the manual
<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
<peterbrett_work>wingo: Also some components that use liblepton without a main loop
<peterbrett_work>(batch processing stuff)
<civodul>s/unfortunately/fortunately/ ;-)
<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: The guy who admins the gEDA servers gave him commit access
<peterbrett_work>wingo: When the old-timers resumed activity, he'd already made swingeing changes to the codebase
<peterbrett_work>wingo: For political reasons, the only viable approach was to fork
<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
<wingo>gdb does it, for example
<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 then i guess
<peterbrett_work>wingo: Thanks for the explanation
<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
<peterbrett_work>wingo: That seems doable to me
<peterbrett_work>civodul: Thanks for the wishes, I'll pass them on :)
<peterbrett_work>wingo: Do I need to submit a patch somewhere to update the website?
<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
<peterbrett_work>wingo: definitely happy to wait for the next update.
<wingo>peterbrett_work: if you send a mail with the details to bug-guile tho that would be great
<wingo>i.e. new url etc
<peterbrett_work>wingo: will do
<peterbrett_work>done :)
<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>wingo: there are broken download links:
<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
<civodul>heheh :-0
<civodul>maybe i'll do it as time permits
<OrangeShark>GNU Guile 2.2 release is still on the front page of Hacker News
<davexunit>yeah it's been there a good long time
<davexunit>pretty awesome
<dsmith-work>Happy Friday, Guilers!!
<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>funny thing is that the blog entry doesn't appear in the top 10 results
<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
<wingo>good evening
<wingo>heya daviid :)
<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>akkad: once it is unziped,
<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 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
<amz3>like not using json
<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)