<daviid>rlb: are you useing bullseye as well? <jgart>Hi, Is ash the same as the 2k-ary method? <nalaginrut>I think ash is the same with << or >> in C, not sure about what is 2k-ary <rlb>daviid: I'm somewhere between bullseye and sid, generally, but right now I'm still on libltdl-dev -14. <rlb>Are we thinking that guile and/or lokke builds may break as soon as I upgrade? If so, maybe I should test in a vm first, and/or file a bug or badger the maintainer... <daviid>rlb: ok so you have libtool -14 stil - i thought i should try to unpack libtool -14 somewhere, then manually copy this .la file and see if at least i can work til a better solution ... not ideal of course, but maybe worth a try <daviid>because it seems it is libtool -15 the problem, not libltdl-dev, iiuc ***Server sets mode: +nt
<spk121>wingo: I would like to add a C func to guile to help out guile-gi. A func to call that says if a thread has been initialized for Guile. Could just patch scm_current_thread to not SEGV if called on an un-guile thread <wingo>spk121: sure. how would it work for scm_leave_guile ? <wingo>i would have it be scm_c_current_thread and have it return either struct scm_thread* or NULL <wingo>i assume you would want to use it from C, right? i guess it makes no sense to use it from the ffi <wingo>because at that point you are already in guile <spk121>well, the actual need it to know if a C callback should scm_with_guile or scm_init_guile to install the top-level continuation, because if someone uses guile to call the glib functions that spawn non-guile C callbacks in other threads, hijinks ensue <wingo>isn't scm_with_guile sufficient in both cases? <spk121>Not exactly, since I'd like errors to be caught at a higher level if there is guile -> callback -> guile, but at a lower level for newly_spawned_c_thread ->guile <spk121>and it is not easy to tell which case has occured because of bastard api like g_task_run_in_thread <wingo>spk121: how about a thread-local parameter in scheme? you would set it in your "main" threads <wingo>and in aux threads it would be #f <wingo>so you can know in Scheme whether to install a catch-all for threads spawned by C, or whether to propagate the exception on if there is pending Guile handlers on the stack <spk121>wingo: so if I use scm_with_guile in a callback, I can check that variable to see if I can re-throw errors caught at scm_with_guile's local continuation barrier? <wingo>the idea would be more that you install your own catch-all trampolien that invokes the callback in question, which would run inside the continuation barrier. if (in-gobject-thread) then the trampoline just invokes the callback and lets any existing exception handler handle exceptions. otherwise you invoke the thread in call-with-error-handling <wingo>or whatever other error-handling strategy you want <pkill9>does there exist a desktop launcher similar to kupfer (which allows you to select actions) written in guile and supporting extensions written in guile? ***hugh_marera17 is now known as hugh_marera
<solrize_>hi is the guile compilation command really supposed to be guild? i don't get many search hits. i'm trying to use it on debian and i don't know what package to install. thanks <solrize_>leoprikler, thanks yeah, but i didn't see how to install guild <rlb>solrize_: yeah, that's it <rlb>$ dlocate /usr/bin/guild <rlb>guile-3.0-dev: /usr/bin/guild-3.0 <rlb>guile-2.2-dev: /usr/bin/guild-2.2 <rlb>daviid: note that libltdl-dev is a binary package produced by the libtool source package, and at least here, the .la file is in the former (in -14), iirc. <rlb>not sure if that helps (assuming I *am* recalling correctly) <daviid>rlb: i did clone lokke, setup, autoreconf, confugure fails with ./configure: line 13402: syntax error near unexpected token `3.0'\n ./configure: line 13402: `GUILE_PKG(3.0 2.2)' <solrize_>how does guile do bignum arithmetic? i notice it's lots slower than python or sbcl <daviid>rlb: which admittedly isn't the cause of the error, your configure.ac entry GUILE_PKG([3.0 2.2]) is correct, afaict, it be an error 'above' maybe? <daviid>rlb: so, i copied the latest guile,m4 in lokke/m4, and configure pass <daviid>rlb: so, lokke make fails as well, expected of course but wanted to confirm <daviid>rlb: yes to your above comment wrt libltdl-dev, after i wrote i checked that the 'missing' .la file is in libltdl-dev <rlb>daviid: ok, if I get a chance I might investigate this weekend. <rlb>Do we already have any idea if guile (and/or building guile C extensions) currently depends on having that file available, either because it's a hard requirement, or perhaps because of the way guile's m4 macros are currently arranged? <rlb>wingo: i.e. does the building of guile C extensions currently depend on the availability of libltdl.la? (if you, or anyone else, knows)? <wingo>rlb: i don't think so but i could be wrong <wingo>how could it depend on libltdl.la ? <wingo>you can build guile extensions against installed guile with all .la files removed <wingo>so i would think, no problem <ArneBab>solrize_: where do you see GUile slower than Python? Do you compare against numpy? <narispo>efraim: hey, so I will try patching cargo to disable mtime checking for .rlib, maybe that's the issue, since incremental compilation (what .rlib is in part for AIUI) relies on mtime <narispo>And since we reset mtime in the store.. <daviid>rlb: fwiw, libg-golf is not a guile C extension, it is a 'simple' C (tiny) lib, a few functions only, mainly implementing as a function, those macros in GLib/GObject that I couldn't 'do without', and that g-golf bind using the ffi ... <daviid>rlb: so, starting with libtool 2.4.6-15, the autotool chain can't build/make any C shared lib, in its first incantation ... and although any subsequent incantation seems to work, then make install fails (for that C shared lib we are trying t build I mean) <solrize_>ArneBab, this takes around 0.5 sec in guile 2.0: <solrize_>equivalent in python 3.7 is about 0.25 sec and in sbcl is around 0.15 sec iirc <efraim>narispo: sounds like a good idea <solrize_>i didn't try numpy which i thought was mostly for arrays <narispo>efraim: there was quite fruitful discussion with them I could have ***rekado_ is now known as rekado
<rekado>uhm, 0.5s is fine. I get a segfault with Guile 3.0.5. <rekado>when it segfaults it takes less than 0.5s ;) <narispo>efraim: someone just suggested we could get rid of cargo and use rustc directly, reimplementing parts of cargo within GNU Guix to fit our needs, we could even dynamically link stuff this way. What is missing is build script handling when doing that, so maybe we can rewrite build scripts in Scheme or reimplement that part as well. <narispo>efraim: do you know where the other guy we had spoken conversation with is? <rekado>narispo: (this is #guile, #guix is next door) *rekado submitted a bug report <rekado>I get the same segfault in 3.0.2 <ArneBab>wingo: is there a way to get inner defines not only in (let () ), but also inside (begin …), when and in cond-clauses? (basically everything that starts a multi-element body)? <solrize_>is there a guile builtin for reduce or foldl or sth like that?