IRC channel logs

2019-11-22.log

back to list of logs

<jcowan>see Chibi
<wingo>moin
<weinholt>greetings
<zig>o/
<andrzejku>hello
<andrzejku>:)
<wingo>i wonder if we can release guile 3 before 2020
<wingo>i think maybe i get a 2.9.5 out today if i am lucky and then 2-3 more releases before FOSDEM
<wingo>civodul: wdyt about this for release schedule: guile 2.9.5 today maybe, and ~biweekly releases until FOSDEM, at which point we have a guile 3.0
<wingo>hello also :)
<civodul>hi wingo!
<civodul>well, why not! :-)
<civodul>though we'd need to test users somehow
<wingo>indeed
<civodul>to make sure we don't let compatibility issues through
<civodul>i could give it a try with guix
<wingo>that would be neat
<wingo>if guix uses nothing deprecated, it should work
<wingo>nothing deprecated in guile 2.2 i mean
<civodul>yes, that should be fine
<civodul>well i meant using Guix to build stuff with 3.0 :-)
<wingo>ah yes :)
<civodul>anyway, exciting times!
<wingo>:)
<civodul>wingo: BTW, you may want to submit a talk to the minimialist track!
<civodul>i think the deadline is in a couple of days
<jcowan>yes, you have to make sure the new users are fully compatible with the old users
<zig>rekado: http://issues.guix.info/ is buggy is returns 504 gateway timeout.
<zig>rekado: btw, what is the hardware setup?
<civodul>zig: should be back to life now
<civodul>rekado: i've restarted it on your behalf
<civodul>we should write a service for it :-)
*zig comparing issues.guix.info time to reponse vs. babelia. The first query against i.g.i is much more slower than the second, which is to be expected, but still very slow response time. babelia cli takes 400ms, whereas issues.guix.info takes 4000ms
<zig>on issues.guix.org the second query is much faster with 100ms
<zig>including network roundtrip.
<rekado>zig: that’s because there’s caching
<rekado>issues.guix.gnu.org is slow because debbugs is slow
<rekado>the first time you connect it queries debbugs and waits for a response
<rekado>I wanted to cut out the connection to debbugs, but I can’t free time to work on this
<rekado>it’s *almost* ready, but someone would have to implement the missing 2%.
<wingo>i sympathize
*wingo distchecks
<davexunit>civodul: the new declarative modules broke some stuff in my own projects so that's a potential source of issues for guix.
<davexunit>luckily, I was able to reimplement some things that made the affected modules compatible with 2.2 and 2.9
<wingo>davexunit: what kinds of things broke?
<wingo>i am interested in hearing about the bugs :) could be that it should be off by default, dunno
<davexunit>I had a top-level mutable variable and all the modules that referenced it did not "see" updates to that variable because they just held onto its initial value.
<davexunit>like if I had a top-level (define foo #f) and later did (set! foo #t) it wouldn't matter because all of the modules that reference foo just took its initial value and got rid of the variable deferencing bit altogether
<davexunit>in my particular case, I was storing some information about opengl state this way. I switched to using a kind of box instead.
<wingo>davexunit: but the set! foo should have made that variable not declarative
<wingo>it could be that there is a bug somewhere
<wingo>or did you do set! foo from a different module?
*wingo distchecks a third time; fingers crossed :)
<bandali>hey davexunit, any plan to cut a 0.2.5 haunt release anytime soon? :)
<wingo>ok guile 2.9.5 release done :)
<zig>\o/
<davexunit>wingo: IIRC the set! came from a different module.
<davexunit>my problems were completely alleviated when I switched to a boxing approach, which was the better design anyway.
<davexunit>rather than sprinking globals around to track gl state, I made a dedicated data type to track all of the relevant state.
<davexunit>the fix was a lot easier than figuring out why things had broken in the first place. my programs were not crashing, but my opengl windows were just black because all the state was messed up.
<davexunit>set!s were working, so I was scratching my head wondering how the program state could be so messed up if my program was setting the proper state at the proper time.
<davexunit>anyway, guile 2.9.5 woooooooo!
<davexunit>bandali: is there a change you are looking for in haunt?
<dsmith-work>Happy Friday, Guilers!!
<nly>hi
<zig>o/
<zig>civodul: I think there is no mention of *thread safe* in the manual about weak hash-tables?
<zig>ref: https://www.gnu.org/software/guile/manual/html_node/Weak-hash-tables.html#Weak-hash-tables
*davexunit wishes that bytevector->pointer didn't allocate a new pointer object every time
<davexunit>bytevectors should just cache a pointer or something
<civodul>zig: ah, but they are thread-safe, really :-)
<civodul>davexunit: long ago i started looking at "immediate pointers", but i think there was a stumbling block
<davexunit>civodul: I have to cache pointers in lots of places to avoid generating lots of extra garbage
<davexunit>lots of let-over-lambda when wrapping ffi funcs
<davexunit>so that the bytevector and pointer only get allocated a single time
<davexunit>which only works under the assumption that you won't use these procedures in a multi threaded program (:
<civodul>yeah, that's not great
<civodul>i had: +#define scm_tc3_aligned_pointer 3
<civodul>but that collides with immediate numbers, iirc
<davexunit>I wonder if a less general approach to help the bytevector pointer case would be ok?
<davexunit>I don't know about everyone else, but that is 99% of what I make pointers out of
<davexunit>the occasional string, but almost always bytevectors
<civodul>i guess a hack would be to allocate a pointer object together with the bytevector
<civodul>so that bytevector->pointer just needs to return that
<davexunit>yeah that or defer the allocation until a pointer is needed and then cache it
<civodul>yes
<davexunit>I am feeding lots of data via bytevectors to opengl and openal at 60hz so I cache as many pointers as possible in various data structures
<davexunit>as far as opengl goes, I have things like 4x4 matrices that cache the pointer to their underlying bytevector. same for 2d/3d vectors, colors, etc.
<civodul>woow, quite some overheat
<civodul>*overhead
<civodul>well overheat as well, maybe?
<davexunit>it just sucks to have to do this for *every* data type that uses bytevectors
*civodul nods
<davexunit>I've been meaning to refactor some of my code to take care of this redundancy
<davexunit>but if it could be solved at the core it would be great :)
<davexunit>but once I have this I'll start complaining about struct unboxing ;)
<davexunit>though now that I've taken a pretty deep dive into structs I think I will just make structs with a single field. that field will be a bytevector that has all the real data packed into it.
<davexunit>structs are... weird... but I was able to do something neat with them that I think is cool and hopefully not cursed.
<civodul>i guess you could have your own bytevector type that wraps a pointer + bytevector
<civodul>as an interim solution
<davexunit>yeah.
<davexunit>I worry that eventually this will be a multi-project problem for me.
<civodul>yes, sure, that's why i said "interim" :-)
<davexunit>yes of course :)
<bandali>davexunit, sort of, i'd like jakob's commit
<bandali>and overall, i think there are a couple of other nice commits sitting on master
<bandali>and there hasn't been a release for nearly a year
<bandali>is there anything blocking a new release?
<civodul>bandali: 2.9.4 wasn't long ago
<civodul>and wingo proposed to release 2.9.5 today or so
<bandali>civodul, agreed :) i was talking about davexunit's haunt though :p
<bandali>haunt's newest release is 0.2.4, from 2018-11-29
<bandali> https://dthompson.us/projects/haunt.html
<wingo>civodul: done alerady :)
<wingo>could be we could optimize out the heap allocation in bytevector->pointer, in some cases
*wingo zzz
<civodul>wingo: i have a tentative patch for bytevector->pointer
<civodul>seems like it's easy, as long as one doesn't set a finalizer
<civodul>ooh, congrats on the release, wingo!
*civodul looks at backlog
<civodul>davexunit: what kind of breakage did you have with declarative modules?
<civodul>bandali: ah! a Haunt release would be very welcome, indeed!
<bandali>:)
*civodul gently prods davexunit
<dsmith-work>Hmm. Current .pdf Guile manual is only 954 pages long.
<dsmith-work>TOC ends on page 20.
<jcowan>Only.