***jonsger1 is now known as jonsger
<daviid>str1ngs: whenever you have a minute, please update and pick-up the latest commit for the g-golf guix package definition, thanks! <apteryx>hmm... what does call-with-blocked-asyncs do exactly? "block the execution of system asyncs by one level for the current thread while it is running." What are "system asyncs" ? <str1ngs>daviid: just to clarify you want me mail a patch to bump the guix hash to g-golf tip? <daviid>str1ngs: I would do that yes, many things have been fixed ... 'we' probably will need to do that a couple of times from now till the first alpha release, but now is a good time I think <daviid>str1ngs: I was/am assuming it's easy and not (very/to much) time consuming ... wdyt? <daviid>str1ngs: I also thought you could 'point to the latest commit' without to have to go through a patch review 'cycle' - since the package is in already, iiuc - and that you had commit rights for g-golf in guix ... and so that these 'updates' on guix would really just take a few minutes ... to many assumptions maybe :):) ***apteryx is now known as Guest90849
***apteryx_ is now known as apteryx
***apteryx is now known as Guest4964
***apteryx_ is now known as apteryx
***apteryx is now known as Guest55299
***apteryx_ is now known as apteryx
<str1ngs>daviid: I use a local g-golf.scm declaration myself which tracks g-golf develop tip. I plan to periodically send patches upstream to guix when needed. Maybe I can treat g-golf master branch as semi stable? Submitting patches to guix are not a problem. It's mainly the contributors there are pretty busy. <str1ngs>daviid: I'll submit a patch though that updates to g-golf's current tip. Then just ping me when you git milestones you'd like guix to be updated to. This until g-golf hits point release status. WDYT? ***wxie1 is now known as wxie
<daviid>str1ngs: if g-golf is in guix, which it seems it is, then I think it should be updated yes, and now is a good time - I merged everything to master indeed ... <leoprikler>hugo: not really, but you can roll your own if you use a let-bound parameter/variable pair <leoprikler>You do have to be careful with that however, since you need a set! and set-default! somewhat equivalently to Emacs Lisp then <leoprikler>Come to think of it, you might want to look into the Guile implementation of Emacs Lisp for hints ***sputny1 is now known as sputny
<hugo>leoprikler: How do you mean let-bound parameter/variable pair? ***sneek_ is now known as sneek
<leoprikler>you can get slightly different results if you use thread-local-fluids <tinga>Hi. Is there a package for Guile, or do I need to install packages like guile-json manually? (Can't see any mentioned in the guile docs.) <leoprikler>btw. there's a typo, the first "other" should be "old" <tinga>leoprikler, I'm on my way to installing guix <tinga>(Choosing from source as I always prefer.) <tinga>Well, if people are using guix as package manager for guile, then I'll just install the few dependencies Guix has manually I guess. <civodul>but recent Debian has many of Guix' dependencies available <tinga>civodul, debian's guile-json etc are all for guile 2.2 <leoprikler>you can bootstrap an older version of guix, then upgrade to a newer one <tinga>Hmm OK, I'll go with guile 2.2 from debian then install newer guile from within guix I guess. <civodul>yeah, "guix pull" will give you that <tinga>civodul, ok, maybe it's worth mentioning that in the README, too :) (i.e. "guile 3 is preferred but you can install via guile 2.2.x then run guix pull") <civodul>yeah, but like i wrote, the recommendation is to use the binary tarball <str1ngs>civodul: hello, I recently built guix locally with ubuntu-20.04 with only dependencies from Ubuntu repositories. So the debian packages have trickled down to ubuntu as well. I forget who contributed those packages but it's been useful. <tinga>civodul, I'm still one of those people who cares about avoiding binary installs if possible (unless it's reproducible builds) <civodul>str1ngs: we owe most of them to vagrantc, great work! <str1ngs>tinga: what version of debian are you using? double check guile 3.0 does not exist already. it's possible if you are say using buster it exists. <dsmith-work>wingo: v3.0.2-122-ge2066d2e6 shaved a few minutes off build times. Now 32 min for me <civodul>tinga: Guix is kinda about reproducible builds :-) <str1ngs>civodul: ah thanks for refreshing my memory. I meant to thank him for the work on that. <tinga>str1ngs, it does, but there are no -json nor -sqlite3 etc debian packages for guile 3 in testing <tinga>civodul, yep, that's one reason why I'm interested in it, so I also want to install guix itself in a reproducible manner, hence avoiding binary install. <str1ngs>tinga: ah gotcha. I personal use guile2.2 for non guix reason. <civodul>wingo: so you hardcoded an mbrot pass in the compiler or what? ;-) <civodul>the new match/case optimization is at -O2, right? <str1ngs>tinga: the thing with building guix locally is you still end up pulling base binary substitutes unless you boostrap the world. which is not worth it unless you have a specific reason too. so using the binary install is actually quite beneficial in the long run. <wingo>civodul: haha no, that good performance was already there fwiw <wingo>civodul: yes that optimization is in -O2 and above <tinga>str1ngs, sad to hear, how is using the binary install "beneficial"? *dsmith-work needs a bigger monitor <wingo>i think its effects don't really show up on the benchmark because you really want a user-written "match" facility written as a macro in the source language for it to be really useful <hugo>leoprikler_: Is my understanding that your make-parameter-variable uses the let scope to create thread-shared variables, and fluids for those with limited extent? <wingo>and those microbenchmarks don't exercise generated code so much <wingo>or not that kind of macro-generated code anyway <hugo>I also don't understand how records would solve anything here? Or do you mean that I should put a record in my fluid, and set the fields of the record, since only a pointer is actually stored in the fluid? <str1ngs>tinga: I am of the same school of thought as your self. I prefer to build most things from source as well. though I tend to now look at guix as a special case. Since it is highly repeatable and trustable. <civodul>wingo: so big match expressions found in the compiler are the kind of code that should benefit, right? <tinga>str1ngs, also, as I said, if reproducible then that's fine with me (allows to be verified by community effort unlike non-producible builds), so if "base binary substitutes" are built reproducibly then that's not so bad. <wingo>civodul: yes i think so. it's the code i had in mind when writing the optimization anyway <wingo>match expressions with many similar clauses <str1ngs>tinga: right that's the case here. the beneficial part is technically it's only useful to build and install from source when you plan to bootstrap everything. If you don't then you end up pull the substitutes you got with the binary install anyways. <str1ngs>tinga: another useful case is if you install the daemon with the binary install. But don't want to use guix environment guix all the time, specifically this needed on foreign distro's. <wingo>just uploaded a better version <wingo>yes, because it seals private bindings <wingo>meaning that anything not exported becomes a private letrec-bound definition, subject to contification / etc <wingo>so in general such programs are smaller <leoprikler_>hugo: no, you could use a record, that contains both a fluid/thread-local-fluid/parameter and a raw value and some accessors with the same effect as my let-based solution but perhaps a nicer naming scheme <hugo>leoprikler_: Let or record doesn't really matter. So my question is if the core concept here is that "regular" variables are shared between all threads? <leoprikler_>regular variables/let bindings are always shared, hence the evil-ness of set! <leoprikler_>in a similar manner, you can get quite evil results with destructive list operations, e.g. filter! <civodul>i think it's largely a function of the file's size <wingo>what's a function of the file's size? <wingo>not sure that it's simply file size <hugo>leoprikler_: Thank you. I will probably go with something along those lines. Possibly wrapping up the "regular" variable in an atomic box <civodul>wingo: not only that, but i think it's an important factor <civodul>trivial code in a very large file takes a long time to compile <civodul>the -O3/-O2 difference for assembler is interesting <civodul>much more visible than with the other files <wingo>anyway i think that with the baseline compiler these issues are solved, wdyt? <civodul>well "solved" is a strong word if we aim for GCC (or tinycc!) compilation speeds ;-) <civodul>but yeah, it should definitely make a big difference already <wingo>yeah but more progress can be made. <wingo>at this point it's easier to profile as well <civodul>and all that said: it's a great improvement <wingo>i.e. get a breakdown between read / expand / optimize / emit <civodul>also for Guix i'd like to provide expansion <civodul>try to see if there's something we can improve in all these macros <civodul>but it's hard to profile because that runs on eval <wingo>probably eval can be improved too <wingo>civodul: fyi my compile-times graph was wrong <wingo>i was measuring the wrong thing for -O1 <civodul>wingo: thanks for the update & good night! <civodul>ah yes -O1 is much lower than before <civodul>i guess peval removes a bit of work or something 
