IRC channel logs

2019-10-09.log

back to list of logs

<Guest16914>spk121: hello! g-golf now has a GClosure low and high level implementation, clean and simple (very easy to read and short in terms of number of lines of code), but :), it raises an exception, even with among the most basic possible test call
<Guest16914>I was wondering if I could grab a little of your precious time to help me identify the cause: the code is very short, reads almost like english, and the exception happens, always, within ffi call to g_closure_invoke, although i can demonstrate that it properly calls my marshaller, which does its job and returns ...
<Guest16914>spk121: if you agree, please pull the latest from the g-golf devel branch (hoping you still have that somewhere on your comuter :)), then you may do this (willp apste in a seg)
<Guest16914>spk121: here https://paste.debian.net/1105479/
<Guest16914>the source code is here http://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/hl-api/closure.scm?h=devel
<Guest16914>the invoke method prepares the g-closure-invoke arguments, then calls g-closure-invoke, line 131 - the marshaller is 'dead simple', deined line 183, an as mentioned, does work fine
<Guest16914>so to be able to reprodube just the g-closure-invoke call and track the problem, i defined a temp var that grabs the arguments it eeds, the var is exported and its name is %g-closure-invoke-args, so after a first call to (invoke $2 1) as in the above paste, you ca see the args and t call 'manually' g-closure-invoke like this
<Guest16914> https://paste.debian.net/1105481/
<Guest16914>to complete, the g_closure_invoke binding is also 'dead easy', here http://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/gobject/closures.scm?h=devel, line 70 and the ffi binding is line 119
<nisstyre>I'm embedding Guile with a C program. I want to spawn a new thread, and I want to share some data between that thread and the main thread. It looks like there is no way to do this if I'm using "scm_boot_guile", is that right?
<nisstyre>every attempt I make results in a core dump
<nisstyre>the docs seem to imply that hash tables can be shared across threads but I don't see how
<nisstyre>I would of course not make concurrent writes to the data
<wingo>moin
<spk121>Guest16914: I'm kind of drowning in projects right now, but, I'll try
<daviid>spk121: tx! i'm actually daviid, i had some internet conection problems, and just after i posted, lost my connection ...
<daviid>spk121: of course it is when/if you have a bit of free time, but i would greatly apreciate your help ...
***ftknox_ is now known as ftknox
<lispmacs>hi, is there an admin here for guile-user mailing list? I tried to join about 7 hours ago but never got a confirmation email.
<dsmith-work>Hey Hi Howdy, Guilers
<gebrek>howdydo
***janneke_ is now known as janneke`
***janneke` is now known as janneke
***__shymega__ is now known as shymega
*chrislck has just discovered (ice-9 match), oh myyy
<str1ngs>daviid: in g-closure-marshal where is the continuation (value) defined?
<str1ngs>err (values) to be more precise
***w2gz is now known as w1gz
***roptat_ is now known as roptat
<daviid>str1ngs: the marshaller, which must follow a predefined C function 'template' must return no value -> hence its last form being (values), _but_ I see %g-closure-marshal was defined (wrongly) to return int (line 206), and changing that to void solves the bug
<daviid>str1ngs: well spoted! tx
<str1ngs>daviid: I suspected that might be the issue. but was not 100% sure
<lispmacs>Hi, I had some questions about the Actor model and I was wondering if there was somebody in the room with some knowledge about that
<daviid>i'll push a fix later, in a few hours or so
<str1ngs>daviid: sound good
<daviid>spk121: tx to str1ngs, i found the cause of the problem, so you may forget about my request for help :), tx
***ng0_ is now known as ng0
<dsmith-work>lispmacs: Just ask your questions. Sooner or later, someone might answer.
<dsmith-work>lispmacs: Might also want to try #scheme
<stis>tja guilers!