<daviid>i thought to use a weak key hash table to hold ffi pointers to (gobject mem allocated) 'boxed type', the value to be the ptr GType, together with a guardian on those pointers, so in the after-gc-hook i could weak-hash-ref the ptr, and use the g-type to call (g-boxed-free g-type ptr) ... but by the 'time' the guardian returns a ptr, the hash table has already been cleared of all to be returned ptr by the guardian ... so their (ptr) <daviid>respective g-type is 'lost' ... i wonder what a good solution would be to this problem, any hints? <daviid>ok, ignore the above, i found a solution - that might be 'tuned', a bit mem expensive - but ok 'for now' <dadinn>I am getting an error "Exception thrown while printing backtrace: In procedure public-lookup: Module named (system repl debug) does not exist" <dadinn>after that there is a only this: "ice-9/regex.scm:118:20: In procedure vector-ref: Wrong type argument in position 1 (expecting vector): #f" <dadinn>there is no stack-trace so I don't know where this is coming from :/ <dadinn>I am running this guile script with #!/guile -s <dadinn>is there a way to make sure the errors are printed in full? <dadinn>to be honest it's a guile script running KVM instance, running another guile script inside th VM. But still, I would expect to see some error message! <lloda>hmm that looks like a bug dadinn <dadinn>lloda: I was running it with guile-2.2 (both on the host and in the guest). Let me try to run it with guile-3.0 inside the guest... <lloda>(system repl debug) is part of Guile so it should never fail to be found <dadinn>lloda: I wasn't able to upgrade to 3.0. I will try again later. Do you have some suggestions what to do to diagnose if this is indeed a bug? <lloda>the source location in your error is in match:start, so i'd check where you're calling that, or one of the other functions that call match:start, like match:substring <lloda>re: the possible bug, not sure <lloda>poke in display-backtrace and see if/why (system repl debug) isn't available from there ***ec is now known as tjl
***tjl is now known as tlj
***tlj is now known as tjl
<ruffni>hello there! i had to build guile-hall on my own, `make check` worked fine but `hall --version` now throws this Syntax error at me: https://dpaste.org/U9jN . any ideas what i did wrong? <avp>I'm thinking about a standalone compilation mode that will allow to produce a FSM that does not need Guile-SMC to run. But that might be quite hard to achieve. <avp>Also one of the possibilites is that we can produce a FSM from other open formats such as Grapviz Dot notation... or convert PlantUML FSM to Dot FSM description and vice versa. <avp>From the practical point of view, there's a library of procedures in Guile-SMC ("char context") that usually needed for parsing textual input so each project that uses Guile-SMC can spare some parenthesis for the future. <avp>I found that I repeating myself each time that I write a parser, so that's why Guile-SMC is started -- I thought I can automate out the FSM generation. <avp>I wasn't the first to try this -- for example, Java has its own state machine compiler (http://smc.sourceforge.net/). But I think we can do better than that. <fnstudio>hi, i have two closures that i'd be planning to use as objects; i'm looking for a way to exchange information between them <fnstudio>i was thinking of creating a simple list and passing that to both closures for them to modify it, but that doesn't work (of course?) <fnstudio>should i create a third closure (of a different kind), instantiate it, and pass that to the former OO closures? <fnstudio>does this sound as the right approach? any other option? *fnstudio goes and searches what a box is <fnstudio>yeah, just found it, thanks RhodiumToad, it seems what i was looking for! excellent, thanks <RhodiumToad>make-variable, variable-ref, variable-set! might have lower overhead <RhodiumToad>looks like srfi-111 boxes are implemented as a record type with one field, whereas variables are a builtin native type <fnstudio>RhodiumToad: interesting, i'll look into that first then