IRC channel logs

2020-03-17.log

back to list of logs

***Server sets mode: +nt
***jao is now known as Guest17393
***jao- is now known as jao
***Server sets mode: +nt
<rlb>sneek: later tell civodul looks like we'll still need --enable-jit=no on some platforms (I cherry-picked your fix in -7 and re-enabled the jit everywhere, including armel): https://buildd.debian.org/status/package.php?p=guile-3.0
<sneek>Will do.
<rlb>Unless there's some other fix in 3.0.1 that might matter -- that's obviously still 3.0.0.
<manumanumanu>RhodiumToad: I got a hold of Oleg, btw. He will take a look at my patch when he has time. There is too much going on right now with the covid going around
<civodul>Hello Guilers!
<civodul>rlb: not sure i understand https://buildd.debian.org/status/package.php?p=guile-3.0
<civodul>(sneek delivered your message on #guix)
<civodul>there are test failures on some platforms, right?
<civodul>but it's 3.0.0 + patch, not 3.0.1 + patch, right?
<dsmith-work>Tuesday Greetings, Guilers
***rekado_ is now known as rekado
<chrislck>o/
***abcd is now known as abcd_
***abcd_ is now known as abcdd
<abcd>Hello, I have some questions on how to embed guile in a C application
<rlb>civodul: yes, I was trying to finish stabilizing 3.0.0 if it was easy, so it could be propagating to testing before working on and introducing 3.0.1 because I looked, and I *thought* there weren't any other patches in 3.0.1 that were likely to affect the segfaults. But perhaps I was mistaken. (And now amd64 failed in the tests on "FAIL: asyncs.test: preemption via sigprof".)
<dsmith-work>abcd: Best if you ask them then.. ;^}
<rlb>Is that's known to fail sometimes, or more likely a real problem?
<abcd>dsmith-work: Thanks!
<abcd>My use case would be using a guile script in a C program to 1. parse the command line arguments 2. read a JSON configuration file 3. generate a configuration object to be passed back to the calling C program
<abcd>I have read the tutorial, but it just explains how to run an interactive shell and I cannot find a reference on how to execute a C string as a guile script
<rlb>abcd: if I understand you, you can't drive it that direction (at least not until/unless guile has a C dialect) -- i.e. you'll still need to compile the C program, and link it against libguile.
<rlb>(Or compile the C program to a shared library and load it from guile.)
<abcd>yes the idea to use the guile script is to simplify on my side the configuration reading
<abcd>because right now I am doing the JSON parsing and command line arguments parsing directly in C and it's horrible
<abcd>I was hoping to use a scripting language just for the configuration of the C program
<abcd>the rest of the programm will stay in C, so for sure I am compiling it
<abcd>the configuration script could be a separate file loaded at runtime, but I would like to embed it in the C source as a string and execute it
<abcd>so the program would be self-sufficient and would not need an external file
<abcd>I found the tool xxd that can read a file and create a header-like file that can be included in a C program
<rlb>That's the part I don't follow -- you can't embed the C source and execute it, but you can link your C application (binary) against libguile.
<rlb>I mean for some versions of "can't".
<rlb>And which tutorial did you mean?
<abcd>let me find it again
<abcd> https://www.gnu.org/software/guile/docs/guile-tut/tutorial.html
<abcd>this one, that teaches how to write a logo application
<abcd>let me explain it again
<abcd>I have this program (called waps) that right now is a C99 only program
<rlb>abcd: so what I would typically favor is just driving my whole application from guile itself, and then put all my C code into a libfoo.so that guile can load and call. At first you could have nearly all your application in there, and your top-level guile script might just call (my-c-main ...), but then later you could move more bits to the scheme side if you liked. i.e. your application would just be a "#!/usr/bin/env guile -s"
<rlb>script...
<rlb>But you can also make it more "C oriented".
<abcd>at the startup it parses the command line and it reads a JSON file to configure itself
<abcd>waps is a rather intesive number crunching application so I wanted to avoid using a scripting language for the rest
<abcd>I wanted to use guile just for the initial configuration
<rlb>Ahh, looking at that tutorial, maybe you were specifically wondering about the scm_shell().
<rlb>i.e. you don't have to to call that.
<rlb>You can call scm_with_guile, and then do whatever you like.
<abcd>indeed in the reference manual they suggest that function
<rlb>So instead of scm_shell, you could call my_config_loader(), that returns your C config struct after using guile to build it.
<rlb>(using guile functions I mean)
<abcd>but I cannot find a function that can evaluate a C string
<rlb>And then pass that C struct to your normal C code.
<rlb>you can't evaluate a C string.
<abcd>yes that is exactly what I wanted to do
<rlb>You'd compile your C program as normal, and presumably it'll have a do_a_thing(config) function.
<abcd>so the libguile would only evaluate either an external file or an interactive session?
<rlb>Then you'd link your C code via gcc or whatever against libguile with a main that looks vaguely like this:
<rlb>int
<rlb>main(int argc, char **argv)
<rlb>{
<RhodiumToad>and of course you can evaluate a C string
<rlb> scm_with_guile (&register_functions, NULL);
<rlb> config_t config;
<rlb> load_config_via_guile (&config);
<rlb> return do_a_thing(&config);
<rlb>}
<rlb>
<rlb>In guile as-is?
<RhodiumToad>convert the C string to a scheme string and pass it to scm_eval_string?
<rlb>(I mean I know there are C interpreters, and we *could* have a C dialect, but we don't have one in guile ATM?).
<RhodiumToad>"C string" doesn't mean "string of C code" but rather "string as used in the C language"
<rlb>Umm, oh, yeah, so apparently ENOCOFFEE.
<jcowan>The (chibi show c) library allows you to generate C from s-expressions, and it's quite portable.
<rlb>Of course that's what abcd meant...
<abcd>rlb: yes it was what I had in my mind
<abcd>RhodiumToad: that is the function I was missing!
<rlb>abcd: apologies, I was clearly assuming you were saying something entirely unlikely.
<RhodiumToad>oh there's even a scm_c_eval_string
<RhodiumToad>so no need to even convert to a scheme string first
<abcd>Sorry but the reference manual is rather complicated and I got lost
<rlb>abcd: https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/Conversion-to_002ffrom-C.html
<rlb>?
<RhodiumToad>see under "Fly Evaluation" under "Read/Load/Eval/Compile"
<RhodiumToad>-- C Function: SCM scm_c_eval_string (const char *string)
<rlb>If you just want to convert C strings to guile and vice versa -- and what RhodiumToad says for actual evaluating scheme code in a C string.
<abcd>great! Thanks for the help on this
<abcd>and now it comes my second question
<rlb>(In my defense -- I heard "evaluate a C string" as "evaluate a *C* string" -- been working on compilation related stuff too much lately I guess...)
<abcd>rlb: no problem!
<abcd>so what would you suggest to use in guile as a configuration object?
<abcd>I was looking into records
<abcd>and the reference manual suggests to use SRFI-9 Records, but they apparently do not have a C API
<rlb>abcd: you can also call scheme procedures directly via the scm_call_... functions after looking up the function via the symbol, creating the args via the right scm_from... functions, etc.
<abcd>would you have some suggestions on how to generate some object in guile to be translated to a C struct?
<dsmith-work>abcd: These structs are known to C at compile time, right?
<abcd>yes
<rlb>abcd: if the thing's eventually destined for a C struct, I might either just have the guile side fill in the C struct (by providing functions to the guile side), or just (if it's simple enough) use alists or hash tables or combinations on the guile side, and then make the relevant calls into guile at the end to fill in the C struct from C before passing it to the C code.
<abcd>well, the configuration would actually be an array of structs
<rlb>for the former, see "foreign objects" in the info pages.
<rlb>for the latter, see all the functions like scm_assoc_*, etc.
<abcd>I was looking into the foreign objects section in the manual
<abcd>I do not understand what these slots are meant to be
<abcd>would they be some piece of memory that is handled by guile?
<RhodiumToad>each slot contains a pointer, integer, or scheme value
<RhodiumToad>think of the foreign object as having an array of slots
<abcd>so I could use a slot with a pointer to the struct
<RhodiumToad>yes
<abcd>instead of having a series of slots one per struct element
<abcd>how would you handle an array of structs?
<abcd>in a single slot or one struct per slot?
<RhodiumToad>depends what you want to do with them, I guess
<RhodiumToad>the number of slots for a given object type is fixed afaik
<abcd>oh ok, that has to be dynamically generated reading the JSON
<abcd>so it is not known at compile time
<RhodiumToad>might be easier then to read stuff into a scheme list, and then process that from C
<abcd>a list of records? or hash tables?
<RhodiumToad>whatever makes sense for the app
<rlb>abcd: you could just "cons" up the list of items and then reverse it at the end, but if you're going to be parsing json, I'd imagine that a key determinant of the rest of the process will be the json module's API, i.e. what does it return, or is it callback based or... I haven't don't json work from guile much lately, so don't know what the likely options are.
<abcd>good point
<rlb>...since guile has a js dialect, I'm a little surprised we don't have a built-in json parser, but don't see it in the info pages.
<abcd>I found this module: https://github.com/aconchillo/guile-json
<abcd>the annoying thing is that it is another dependency for my software, that is not packaged in the major linux distributions
<brendyyn>this has mysteriously popped up on hn https://news.ycombinator.com/item?id=22591194
<RhodiumToad>hm. the point about the circular dep is a good one, how best to break that?
<RhodiumToad>bleh, did my last comment get through?
<rekado>sneek: later tell brendyyn See also https://github.com/bl0b/nabs
<sneek>Got it.
<abcd>RhodiumToad: is GNU make really necessary for compiling guile? Using the old bsd make could break the dependency cyle
<chrislck>abcd: see srfi-180 still incomplete.
***jonsger1 is now known as jonsger
<abcd>chrislck: Thanks!
<RhodiumToad>the freebsd guile port specifies gmake, so it probably does need it, though I haven't looked at why
<abcd>maybe it's just because nobody bothered to try :)
<jcowan>One possibility is to use an option to build gmake without Guile and use that to build Guile.
<RhodiumToad>that's awkward from a packaging point of view
<RhodiumToad>yes, you can end up installing gmake-minimal and gmake-full or whatever
<RhodiumToad>or gmake and gmake-guile
<RhodiumToad>of course, most people will have built gmake without guile
<dsmith-work>Debian make seems to be missing guile support.
<jcowan>Another option is to build Guile with (OMG!) a shell script
<dsmith-work>More exciting: Have guile's Makefile depend on a guile-enabled make.
<jcowan>Compiling Chicken depends on having a Chicken compiler.
<RhodiumToad>that's true of many languages
<rekado>see http://bootstrappable.org/
<RhodiumToad>worst case, some languages (looking at you rust) require a very recent version of their own compiler
<jcowan>However, because the generated C is system-independent, you can rely on the project to provide you with the C in the tarball.
<heisenberg-25>Hi, Is there a gRPC implementation for scheme(guile)?
<jcowan>so to build the head, you either get a recent binary of Chicken for your system, or you grab the latest tarball with the C code, build it, and hope it is recent enough to build the head.
<rekado>generated C is not really “source” code
<civodul>s/really// :-)
<jcowan>In the sense of the GPL, no.
<dsmith-work>That really fast (and pretty good) Scheme compiler that I can't remember about r6rs timeframe also needed a copy of itself to bootstrap.
<dsmith-work>Sheesh. I can't remember it.
<weinholt>Ikarus?
<dsmith-work>Yes!
<dsmith-work>Happy Happy Joy Joy
<dsmith-work>And Vicare was the following continued development.
<abcd>Going back to the JSON parsing problem, what if I use the ecmascript compiler to parse the JSON? Isn't JSON a subset of javascript?
<jcowan>The reason for forking SBCL from CMUCL was precisely that CMUCL can only be bootstrapped from itself, whereas SBCL can be bootstrapped with itself, CMUCL, OpenMCL, and even CLISP (which needs no bootstrap)
<rlb>debian has both "make" and "make-guile" packages iirc.
<rlb>(binary packages anyway)
*rlb is considering a deb make nmu to update the guile version...
<jcowan>abcd: That is a *very* unsafe thing to do. Use a proper JSON parser.
<dsmith-work>rlb: Ahh, didn't realize that. (make-guile package)
<oni-on-ion>how come they didnt accept the changes into CMUCL and continue
<jcowan>You'd have to talk to the CMUCL maintainers.
<jcowan>As of now they have been separated for 20+ years, but there is still cross-fertilization going on
<wingo>civodul: you still working on weird threading bugs?
<civodul>wingo: on and off, yes
<civodul>did you see the patch i posted a couple of days ago?
<civodul> https://issues.guix.gnu.org/issue/28211#23
<weinholt>rotty, what's the latest on the pipe bug?
<wingo>civodul: weirdly, i wrote a reply but i can't find it atm
<wingo>maybe lost as a draft on my work machine that is in quarantine :P
<civodul>oh :-)
<wingo>found it and sent the reply :)
<civodul>yay!
<wingo>civodul: fwiw i think your patch is close but not quite the right thing, eagerly resetting the SP will prevent some live values from being marked
<civodul>wingo: ah!
<civodul>could you show me what you have in mind?
<civodul>i read your message and wasn't sure
<wingo>so i think the right strategy is to reset FP (collapsing the top N frames into one big frame), then the shuffle down, then setting SP (shrinking the top stack frame)
<civodul>oooh
<wingo>no need to mess with volatile pointers afaiu
<wingo>i.e. basically just move up the vp->fp = new_fp line before the value shuffle
<wingo>does that make any sense? :)
<civodul>wingo: yes, it does!
<civodul>i think the other bug i was chasing must have been because of my broken patch
<wingo>i don't doubt it, unmarked values can be gnarly
<wingo>ok zzz
<wingo>night!
<civodul>night!
<brendyyn>so when is guile gonna become a Rust extension language and jump on the hype train?
<civodul>isn't it hype already? :-)
<rlb>civodul: so all the release archs built fine with that one patch of yours *and* some disabling of the jit, *except* for a "FAIL: asyncs.test: preemption via sigprof" failure on amd64. I suppose I'll try integrating 3.0.1 and just defer the 3.0 testing migration a bit longer, but any idea offhand if bits in 3.0.1 might be expected to affect that asyncs test?
<brendyyn>civodul: I was wondering if it could be used with c++ and found a 2015 thread about it. i dont understand anything about that exception stuff, but python works with c++, why couldnt guile
<brendyyn>lots of graphics and game stuff, qt etc is c++
<civodul>rlb: i don't think anything in 3.0.1 affects this tset
<civodul>i've never seen this test failure though, so i don't know
<rlb>ok, thanks.
<rlb>Knowing that helps too (i.e. not known to be unpredictable).
<civodul>yeah
<civodul>either way, i'd recommend moving to 3.0.1
<rlb>oh, sure -- was just trying to isolate variables a bit if I could, but didn't work out :)
<rlb>(i.e. thought I might be able to stabilize 3.0.0 first, and then add 3.0.1)
<civodul>heh, i see :-)
<lfam>What's the push URL for guix-artwork?
<lfam>Sorry, wrong channel
<rlb>What's a reasonably efficient way to build a string char by char right now? i.e. if you're parsing and appending chars as you read them. Do I likely need to manage my own buffer?
<rlb>(or maybe string ports would already handle that (well enough for now) for me...?)
<oni-on-ion>whoa, nice! https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html
<spk121>rlb: I would (define str (make-string LENGTH)) (string-set! x i #\c)
<rlb>spk121: ahh, right, so manage my own buffer. I suspect that's where I'll end up eventually...
<spk121>rlb: but don't prematurely optimize. Try writing to a string port to see if it is good enough.
<rlb>spk121: agreed - that's what I'm doing for now.