IRC channel logs

2020-01-25.log

back to list of logs

<str1ngs>where do we find such creative people to make logos and art? The young gnu and with the robot on the guile website is pretty cute.
<rlb>sneek: later tell civodul I suspect my misunderstanding is that I was thinking in terms of clj dynamic vars, where a sub-thread (often) sees the exact same "fluid" as the parent, but in guile, the current *value* of the fluid conveys, not the actual fluid?
<sneek>Got it.
<zap`>str1ngs: I really like guile web page too. I think sigrazil made very cool designs
<nly>hi
<str1ngs>hello nly
<rlb>(hmm, actually I think I was wrong about an aspect of how clj dynamics work too as compared to fluids...)
<civodul>rlb: futures are executed by threads from a pool (it's "work stealing") that does not restore the dynamic extent where the 'future' or 'touch' calls appear
<civodul>so you need to explicitly capture/restore bits you care about
<d4ryus>hmm, could it be that there is no way to connect to an abstract unix socket from scheme? unix(7) states that sun_path[0] has to be a null byte and it seems (from what i read in socket.c (scm_connect)) that this would not work as it converts the scheme path (string) to an empty string due to the leading \0...
<manumanumanu>jcowan: building on mac os x isn't fun. I just gave up and rewrote the formula for guile2.2 which works. This seems to be a general problem with building on mac os x though, as I have had to do it with quite some packages.
<spk121>.
<jcowan>Thinking further on sirgazil's proposed logos, I now favor row 3 on a white background, and row 1 on a black background.
<rlb>civodul: thanks I think I realized that -- what I hadn't thought hard about yet was the relationship between a fluid in the parent thread and child. I'd just vaguely assumed they might share the same fluid but that's not right, and not even what I'd want (in the case I care about).
<rlb>And yeah, I fixed the issue with dynamic-state related bits.
<rlb>Thanks
<Jeanne-Kamikaze>Hello. I am trying to install the chickadee library, but it seems to fail to find the gl package. I downloaded and sudo make install'ed guile-opengl, which appears to place libraries in guile's system path, but chickadee is still unable to find them. Can someone please help? Thanks.
<Jeanne-Kamikaze>The output of: $ ls /usr/local/lib/guile/2.2/ccache
<Jeanne-Kamikaze>gl gl.go glu glu.go glut glut.go glx glx.go
***dsmith` is now known as dsmith
<dsmith>Jeanne-Kamikaze: The usual trick is to run the command under "strace -efile". That will show where it's looking, and NOT looking!
<Jeanne-Kamikaze>It doesn't even appear to be looking for any path that contains "gl"
<Jeanne-Kamikaze>Found the path. Seems like guile on Ubuntu uses /usr/lib/x86_64-linux-gnu/guile/2.2 instead.
<drakonis>so, guile and guix should sign up for the google season of docs to further improve the docs
<drakonis> https://www.gnu.org/software/guile/docs/docs.html oh and this should be updated to point to guile 3
<str1ngs>Jeanne-Kamikaze if you export GUILE_LOAD_COMPILED_PATH=/usr/local/lib/guile/2.2/ccache . does that help
***dddddd_ is now known as dddddd