IRC channel logs

2022-04-04.log

back to list of logs

<stis>evening guilers!
<rlb>wingo: so not sure what's going on, but I noticed that (web request) response-code claims to be a procedure, but when I try to use it from the clj side, it crashes as if it's a syntax-transformer (which lokke can't trivially handle from the clj-side right now). But at the repl, class-of also claims it's a procedure?
<rlb>(it's actually a record accessor, so I wondered if those might be special somehow)
<rlb>Ahh, now I can see it's a macro...
*rlb looks for a procedural way to access record fields...
***alMalsamo is now known as littlebobeep
<dsmith-work>{appropriate time} Greetings, Guilers
<alextee[m]>a discussion came up elsewhere and I'm wondering, what are the differences between Guile and other extension languages/frameworks? would be nice to have a comparison somewhere
<drakonis>alextee[m]: hmm, it depends, honestly?
<mwette>one significant difference is that GUile has a compiler tower to it is conceivable to have Guile host many languages extending applications
<mwette>s/to it/so it/
<mwette>see https://paste.debian.net/1236789/
<alextee[m]>mwette: I see thanks! still haven't figured out how to use ECMAscript scripts with my libguile integration but I want to try it soon
<dsmith-work>Guile has some depenencies that might complicate the extended app, such as libgmp and libgc. (or that might be the very reason to use Guile)
<alextee[m]>oh wow first time i'm hearing about libgmp this looks pretty useful.. i was looking for something to operate on rational numbers instead of floats
<lilyp>alextee[m]: If everything else fails, just bind your js-eval function to a variable and call it with a scm_from_utf8_string(char*)
<alextee[m]>lilyp: so same as I'm currently doing: scm_c_primitive_load (script_path); SCM func = scm_variable_ref (scm_c_lookup ("zrythm-script")); scm_call_0 (func);
<alextee[m]>can you give me an example of a js script that would work with this?
<lilyp>I don't have one, but I'd do this differently.
<lilyp>Like, what's the point in calling a named func rather than just compiling the code and then executing the automatically generated loader thunk?
<alextee[m]>it's just to have a somewhat standard entry point and way to write acceptable scripts, seemed easier to implement at the time
<lilyp>I think something along the following lines would work
<lilyp>first, compile_mod = scm_resolve_interface("system base compile")
<lilyp>compile_proc = scm_module_ref(compile_mod "compile")
<lilyp>code = get_string_all(script_path)
<lilyp>bc = scm_call_n(compile_proc, code, kwd_from, FROM, kwd_to, s_bytecode, SCM_UNDEFINED)
<lilyp>scm_call_0(bc) // actually eval it
<lilyp>thereafter you can bind func and call it as before
<lilyp>alextee[m]: 👆️
*lilyp → zzz
<alextee[m]>lilyp: thanks! ill give this a spin
<lilyp>ahh, wait, you might need to load_thunk_from_memory first on the returned bytecode
<lilyp>perhaps compile to value could also work, but I haven't tested that one yet
<lilyp>in any case, you probably want to call the thunk in a clean module, so...
<alextee[m]>this is probably what the compile procedure is doing (compile '(+ 1 2) #:from 'scheme #:to 'tree-il)
*alextee[m] looks for how to specify #:from from C
<alextee[m]>scm_from_utf8_keyword()
<alextee[m]>well this is what I have so far https://paste.debian.net/1236805/
<alextee[m]>fails when calling the compile procedure "wrong type to apply" I think on the code variable.. not sure what type that needs to be
<alextee[m]>this is the error https://paste.debian.net/1236806/