<kernasi>the next question might be strange but I'd like to have some sort of guile in my initramfs <kernasi>but I can't have gnu glibc and all the stuff in it because it will grow too big :) <kernasi>so is there some sort of "mini" guile available? <kernasi>I will check it out, but do you know how big it is? <mark_weaver>but it's not really a mini guile. it's just a large initramfs <mark_weaver>it uses GNU libc, but it's statically linked, if I remember correctly. <kernasi>it will freak out when used with musl e.g. <mark_weaver>well, guile can use other C libraries, but there's an issue with musl, that's true. <mark_weaver>e.g. Guile works on the *BSD systems, Solaris, OS X, etc. <kernasi>I just got reminded back to the times I sat in front of CDE <mark_weaver>I've forgotten what's the issue with musl, but that's the only C library I know of off-hand that doesn't work with Guile. <mark_weaver>(I'm sure there are others, but I haven't seen reports of such) <mark_weaver>actually, iirc, the problem is that BDW-GC doesn't work with MUSL. <mark_weaver>it's not Guile itself, but the garbage collector that guile uses that's incompatible. <mark_weaver>(the earlier link was the announcement of the first hack to run guile in an initrd, but that was almost 3 years ago, and GuixSD has progressed significantly since then) <madsy>Heh.. bdwgc is still magic to me :) <madsy>Line 15, " if (lseek (fd, 0, SEEK_START) < 0)" should be SEEK_SET right? <madsy>And "end" in line 20, "data = malloc (end);" right after is not declared anywhere. My best guess is that it should point to the file end, but was forgotten about <madsy>Currently in 2.1.0 that #ifdef on HAVE_SYS_MMAN_H breaks on MinGW and I guess on all systems that don't have <sys/mman.h> <madsy>mark_weaver: Should end be renamed to len, or should end be the size of the file, as in size_t end = lseek(fd, 0, SEEK_END); ? <madsy>As in, an extra call to lseek prior to the if <madsy>Sure thing. I'll note down all the quirks in loader.c and ask on the mailing list <ivan-kanis>so as I was saying over at #scheme is that I am trying to get the reference of an object <taylan>ivan-kanis: did module-ref & resolve-module do the trick? <ivan-kanis>I am not sure what to pass to resolve-module for the top level... <taylan>ivan-kanis: the question would be which top level. every top-level binding belongs to a certain module. <taylan>the "core" module is (guile). the user/REPL module is (guile-user). <taylan>dunno what module is current when running a top-level program/script. maybe also guile-user. <taylan>(like with #!/usr/bin/guile I mean...) <ivan-kanis>Thanks, that should get me going. It's C so it'll take a while. I am not sure I am going about it the right way. <taylan>ivan-kanis: oh right, in C you'll want to use scm_public_ref/scm_private_ref I guess <taylan>(these seem to take module names as strings instead of module objects. dunno why.) <ivan-kanis>But I find out the procedure is define in '(guile-user) in the xbindkeys configuration file <ivan-kanis>scm_call_0 (scm_c_public_ref ("guile-user", key->function)); <ivan-kanis>In procedure public-lookup: No variable bound to foo in module (guile-user) <ivan-kanis>I need to find the equivalent of module-ref in C <taylan>ivan-kanis: variables are bound to symbols <ivan-kanis>Yes, I found out reading the 'module' section some more <taylan>are you sure the correct module name is "guile-user" and not "(guile-user)"? <taylan>(I would test and see for myself if C had a REPL :P) <ivan-kanis>According to somewhere in the doc it should be guile-user. <taylan>indeed the error message you pasted indicates that it correctly translated that to (guile-user) <taylan>ah yes, I see it in the docs now. (foo bar) becomes "foo bar" in the C API that takes strings for module names <ivan-kanis>It did not like "(guile-user)" :) Module named (#{\\x28;guile-user\\x29;}#) does not exist <taylan>ivan-kanis: are you sure foo is bound in guile-user then? <taylan>and are you sure it's a top-level binding and not within an internal scope somewhere? <ivan-kanis>maybe it becomes when I connect to the REPL via the network... <taylan>ivan-kanis: can you pastebin xbindkeys.scm? and how is it loaded into the runtime? <taylan>a typical way would be that xbindkeys.scm defines a module (file starts with 'define-module'), and then loaded via 'use-module' somewhere. then it would mean that foo is part of that module. that's perhaps the "cleanest" case, and makes it very obvious what module you need to use... <taylan>but maybe xbindkeys uses a different architecture of sorts <ivan-kanis>xbindkeys is old, it was written before modules existed I think <taylan>ok, no module definition. then the question is how is it loaded into the runtime. does something use the 'load' macro to load it? <ivan-kanis>scm_primitive_load(scm_from_locale_string(rc_guile_file)) <ivan-kanis>guile is started with scm_boot_guile in xbindkeys.c <taylan>ivan-kanis: maybe you can have the current module printed somehow, like with (xbindkey-function '(control blah) (lambda () (display (current-module) some-log-port))) <taylan>(or whatever the easiest way to get output from those functions is...) <rjmacready>ivan-kanis: are you trying to load a scheme file into a C program? <taylan>rjmacready: xbindkeys is a guile-using C program <rjmacready>i had to declare functions inside of a module to be able to accept them from C <taylan>pretty tiny: git clone git://git.savannah.nongnu.org/xbindkeys.git <ivan-kanis>taylan: well darn it displays #<directory (guile-user) <taylan>dunno if Savannah tends to offer a web interface <ivan-kanis>taylan: ah switching from scm_c_public_ref to scm_c_private_ref makes it work <taylan>ivan-kanis: oh, right, since it isn't defined with 'define-public' or exported with 'export'... <taylan>it's pretty old and seems to have a bunch of cruft but that's what you get with mature and pragmatic software... <taylan>the 2.0 and 2.2 stuff especially is great I think <taylan>lots of cleanup... and if GuileEmacs happens, that'll be pretty big. <sneek>Welcome back amz3, you have 1 message. <taylan>rjmacready: ah, good to know, thanks ***jmd` is now known as jmd
<amz3>what's next in artanis roadmap, if I may ask ... <nalaginrut>amz3: for 0.1.2, enhance sessions, add more types to migration, <amz3>I should polish an put my webapp online some day <amz3>the idea of it not being polish scares me, as I know I will be too lazy to fix it later <nalaginrut>I'm working on a patch for FFI, then I'll write CFFI with nyacc, we do need more bindings of other libs <amz3>I saw the message, nice thing you work on this <amz3>I started working in libgit2 bindings, but this is tedious... lot of repetition <nalaginrut>amz3: nyacc is a good thing which opened many possibility for us ;-P) <amz3>I mean, it's not a difficult task, but highly repititive <amz3>sadly it's not a parser combinator ;-) <nalaginrut>amz3: well, if you done libgit2, we may write a new project to replace tekuti but compatible with it, of course, take advantage of Artanis <nalaginrut>I do want to update my blog to Artanis, but I'd like to use git <amz3>myself, I'd like to have an easy to use git frontend ala gitlab... someday... <amz3>at least it will help some write one <amz3>what I really would like is to have a gnunet backend for my microblog app <amz3>this would be legendary ;) <nalaginrut>amz3: we'll have such thing, it's just about time <nalaginrut>we just need to write some projects as prerequiste <nalaginrut>it's better now, years ago, we have no chance to dream it... <amz3>yes, we need guile-gnunet <nalaginrut>but it requires new server core in Artanis to support it <amz3>https is part of my struggle, I never done https :/ <amz3>if it is default in artanis is will be helpful ***dje_ is now known as xdje