IRC channel logs


back to list of logs

<rekado>I’m trying to make a Guix package for chickadee, but it fails to build chickadee/render/shapes.go
<rekado>In procedure dispatch-exception
<rekado>In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): #:ffi
<lfish>Hello, quick question: when I start guile in emacs with geiser I'm greeted with a `guile: warning: failed to install locale', things seem to be fine though, should I worry about it?
<zxq9>lfish: iirc, it should default to the "C" locale, which equates (generally) to us_en
<lfish>so, it's only about the language?
<zxq9>Mostly language, but also bytewise sort order (not all alphabets sort the same way), default currency marker, etc.
<zxq9>Check Stephanie's answer here:
<zxq9>Your env might be missing a locale variable or something, or it is asking for one the system doesn't have installed.
<zxq9>Assuming your on a unix type system, you could experiment with exporting environment variables before running emacs.
<zxq9>(You can do that on Windows, too, I just don't remember which command does what in Windows. Does anyone even use Windows anymore?)
<lfish>zxq9 okay, thanks a lot
<zxq9>lfish: Anyway, nothing to be concerned about.
<wingo>sneek: later tell civodul i used to!
<wingo>i should take another look there
<nilg>How to get documentation for ice-9 in general (what it is, etc)? Thanks.
<nilg>How to know all modules under the ice-9 namespace?
<nilg>Specifically in which version of guile has ice-9 atomic been introduced?
<wingo>nilg: see NEWS
<nilg>Thanks wingo, so if I'm reading that correctly ice-9 atomic has been introduced in 2.2.0
<wingo>correct :)
<rekado>davexunit: git clone returns 403
<rekado>git clone git:// does work, though.
<rekado>davexunit: is Sly still under development?
<civodul>rekado: i think davexunit moved on to
<civodul>i like the functional reactive gimmicks in Sly, though
<rekado>can’t build chickadee :(
<civodul>building is overrated, you should do live programming
<rekado>okay, I could build it after adding an extra build phase to guile-sdl2
<wingo>:) rather
<rekado>now I have problems with creating a window
<rekado>I try the example on the website, but get “Couldn't find matching GLX visual”.
<rekado>after exporting SDL_VIDEO_X11_VISUALID= I get “Could not create GL context” instead.
<rekado>do I need to preload some libraries?
<civodul>rekado: i think that's because it dlopens
<civodul>see libepoxy, guile-opengl, etc. in Guix
<rekado>chickadee does not do this directly; it uses guile-opengl, which is already patched.
<rekado>it also uses guile-sdl2 which takes the absolute path of the SDL libraries at configure time.
<rekado>when I patch the “open-window” procedure to use OpenGL 2.1 instead of 3.3 it works fine until the shader should be compiled.
<rekado>my graphics chip should support OpenGL 3.3, though.
<rekado>it would be nice if Chickadee would support slightly older versions. (For shaders it requires v3.30, but my chip on a Librem 13 only supports 3.20.)
<rekado>bah, guess I’ll have to use Love instead.
<civodul>rekado: hopefully davexunit will read this later and come up with a solution :-)
<civodul>BTW, do you have a repo for the picture language?
<civodul>i modified it a bit and it'd be nice to have that somewhere
<rekado>civodul: it’s here:;a=summary
<civodul>thanks rekado!
<civodul>wingo: how would you suggest dealing with accesses to the "submodules" hash table?
<civodul>we could do like the call-with-module-autoload-lock trick maybe, unless we don't mind adding a mutex in the module record
<chrislck>this invalid code- error says "Wrong number of arguments to #f" - shouldn't it be "wrong number of arguments to loop"? caught me a couple times wondering what was my mistake
<chrislck>(let loop ((n 0))
<chrislck> (display n)
<chrislck> (loop n n))
<rain1>yes loop just takes 1 arg
<rain1>strange that it calls it #f
<chrislck>I've been afflicted by addiction to named let :-(
<wingo>civodul: i don't know :) what about wrapping `resolve-module' in call-with-module-autoload-lock ?
<wingo>that is a heavy hammer tho
<rain1>I love named let
<rain1>extremely rare that i want a full powered loop construct
<civodul>wingo: heavy hammer, indeed, but i suppose that would work
<civodul>we can't modify the module record type in 2.2, can we?
<wingo>not really. anyway adding per-module mutexes runs the risk of deadlock
<civodul>oh right
<janneke>mes has named let!
<janneke>Mes also wants real Guile-style modules
<wingo>i have been programming c for many years and i don't know when to use #include "foo" or #include <foo>
<rain1>I use "" for files in my project and <> for system headers
<wingo>weird when you're making a library tho, do you use <> in your public headers and "" locally?
<wingo>is there a difference between what you do in your headers and what you do in your c files?
<rain1>i don't think ive ever made a library
<wingo>(i know that in guile, both work fine.)
<civodul>wingo: i think <foo> is relative to the search path, whereas "foo" is possibly relative to the source file location
<civodul>in practice they're interchangeable though, AFAIK
<wingo>i think "foo" also searches the search path
<wingo>just, after the current directory.
<wingo>that's the only difference afaiu
<civodul>yes, that must be the only difference
<wingo>i will change libguile to include "smob.h" instead of "libguile/smob.h" or <libguile/smob.h> then. of course libguile.h continues to include "libguile/smob.h"
<wingo>i think rain1 is right in practice that "" means "mine" and <> means "not mine"
<wingo>civodul: does that sound about right to you?
<hugo>Yeah, both "" and <> searches both your headers, and system headers
<hugo>Just that "" gives priority to your headers
<hugo>And <> to system headers
<wingo>afaiu the only priority that you get with "" is that it adds the directory of the file doing the #include onto the search path, at the front
<wingo>i think this is not the case with <>
<civodul>wingo: i find <libguile/smob.h> to be "nicer" and clearer, but "smob.h" would work as well
<wingo>yes i am not quite sure what to do :) i think first i will convert all .c files inside libguile to include the libguile headers like "smob.h". later if we decide to change we can do it automatically
<wingo>right now there is some inconsistency, so i will first make things consistent
<wingo>i.e. config.h first, then system includes, then libguile includes (alphabetically ordered), then foo.h for foo.c
<didi>Can Guile's Web module handle HTTPS?
<sneek>Welcome back didi, you have 1 message.
<sneek>didi, taylan says: I can be better accessed through email, via taylanbayirli at google mail
<rain1>didi I do not know the answer to this but one thing you may be able to do is put nginx configured with HTTPs in front of your guile web app
<didi>Long time, no see, Taylanub.
<didi>rain1: Thanks, but I didn't explain myself properly. I mean using it as a client.
<rain1>oh ok, I am not sure
<didi>Hence, (http-get ""), for example.
<wingo>didi`: i believe it "just works" if your guile can import (gnutls)
<wingo>over the last week i have deleted code in guile for atari, vms, and cray
<wingo>i have kept code for obsolete sun and ia64
<cmaloney>Now I'll never have Guile on my mon-existent ATari ST
<cmaloney>What about Amiga? :)
<weinholt>vms is being ported to amd64, it might make some kind of a comeback
<cmaloney>It's overdue
<didi`>wingo: I'm on Debian Stable, with libgnutls30 installed, but (http-get "") is failing here.
<rekado>didi`: this is fixed in newer versions of Guile. What version do you have?
<rekado>I think this was fixed in 2.2.3.
<didi`>rekado: Stable's. Let me see...
<didi`>GNU Guile 2.0.13
<didi`>rekado: I see. Thank you.
***didi` is now known as didi
<civodul>wingo: atari, vms, and cray, woohoo :-)
<civodul>everytime i saw those ifdefs i wondered when they had been useful
<civodul>esp. the thing with weird pointers on cray