IRC channel logs
2025-11-18.log
back to list of logs
<bootchk>mwette: thank you for your interest. Is type "boxed null-terminated array of pointers to GObject" the C type "GObject***" (emphasis on triple ptr/ref)? <graywolf>Is there a way to fold over a bytevector? <shawnw>Using srfi-171 transducers is one way. <mwette>bootchk: I think its **GObject, or better yet, *GObject[]. <mwette>can you build for debuging and run under gdb? <mwette>Maybe GObject *content[], where content is what's in the box. <bootchk>mwette: yes, can gdb. It is a little strange, arranging to debug a Gimp plugin, which is the Guile interpreter in this case. If that is what you mean. <bootchk>mwette: Now I am trying to understand how G-Golf gets involved on a callback from Gimp. How does it come to know the types of the arguments? Since the handler in Scheme did not declare in Scheme its types. Does G-Golf wrap the Scheme code? I am not looking for answers, just trying to understand the machinery better. <bootchk>mwette: I already know that a hack to G-Golf to do an extra dereference fixes the problem (my prototype Gimp plugin in Scheme behaves as expected.) The question is, where in the machinery (Gimp or G-Golf) is there a disconnect? Does Gimp pass too many levels of ref, or should G-Golf do another deref? <bootchk>By analogy, the G-Golf hello-world example, how does G-Golf know the types for the the Gtk.activate callback? I suppose that is different, that is a signal. But still, C code is calling into Scheme somehow, and G-Golf is marshalling the call into Scheme. <mwette>bootchk: sorry. I don't know G-Golf. I have only used gtk2 directly, by making FFI calls to c-code. I hope daviid can shed some light on your questions. <daviid>bootchk: the annotation says it expect an array of pointers to GObject instances, you pass an array of pointers to pointers to GObject instances: this is a Gimp bug, and fwiw, why on earth would you add a totally unusefull extra deref ... <daviid>bootchk: the activate signal is from GtkApplication, the annotation tells us (all lang bindings) what is expected <bootchk>daviid: I don't want to add an extra deref, just trying to fix it. I just keep throwing up that as an example of what is wrong. I was just hacking in the worst sense, and the extra deref "fixes" it in the worst possible way. The fact that the deref fixes it is only a clue to what is wrong, somewhere. <daviid>bootchk: there is nothing to patch in g-golf 'here' <daviid>ok, but why can't you fix it? I mean it's been a few days you know what the problem is ... can't you get some help from gimp dev collegues? <bootchk>daviid: yes, that's a good idea to get help. Its been a few days, since I am slow, its complicated, and I have other commitments. <bootchk>daviid: I will make a MR in the Gimp repo, and appeal to the lead developer Jehan, for help. <daviid>bootchk: i'd try to just talk about the problem first, then ask how to fix, then make a patch and raise a MR .. fwiw <bootchk>daviid: for my education, how does G-Golf know the signature of a callback from C into Scheme, in this case the C typedef GimpRunImageFunc? How do I (describe ...) it, in Guile CLI. <daviid>bootchk: you'd need to read and learn gobject-introspection, but as a user, all you need to know is that g-golf (and any other lang bindinbg), through annotation, gets a spec of what you, as a user, can read in the callback documentation <mwette>ArneBab: congrat's. It's good to see people writing. I don't use wisp, but I'll take a look anyhow. <mwette>I'm a little lost on when `.' is not necessary. Is that application of a procedure? <identity>mwette: you can think of . as (lambda (x) x), so "\n . 42 \n" is the same as ((lambda (x) x) 42) which reduces to 42. "\n 42 \n" is the same as (42), which is not valid. <identity>basically, the dot prevents the expression from being interpreted as function application <ArneBab>Also (. 5) is 5 in Guile and some other Schemes -- try it out … (but that’s not the reason for the `.', just the reason why . is used. The actual reason is that Wisp generalizes (. 5) ⇒ 5 to (. 5 6 7 8) ⇒ 5 6 7 8). <ArneBab>mwette: wisp inverts the calling logic: every line is a function call (similar to the shell), except if it starts with a . -- then it continues the line before it which was indented less deeply. <ArneBab>mwette: one argument I found for that (retroactively) is that about 2/3rd of the code lines in the Guile modules start with a parenthesis. So calling procedures is actually the more common case which means it would be efficient to make that the default. <ArneBab>There are also drawbacks: while Wisp has been reported to be easier to read to many, it is actually a more complex syntax. And dot-prefixed lines are a common source of error ("wrong type to apply: ..."). <mwette>I see the value. I guess a lot of people looking at lisp for the first time are turned off by the thickness of paren's in the language. <ieure>I know that's conventional wisdom, I'm not sure how actually accurate it is. <ArneBab>ieure: I don’t know either. In general, empirical programming language notation research is severely lacking: https://www.draketo.de/software/language-empiric -- But I’ve been wanting to do an actual empirical study to find out for over a decade now and getting Wisp done as the thinnest possible mapping from indentation to Lisp (that doesn’t have big failure modes) was an important step on the way. Also I got sidetracked by work and <ArneBab> real life quite a bit (but kept walking, if slowly). <ieure>ArneBab, Good summary of resources, thank you. <ArneBab>ieure: if you find other good sources, please tell me so I can link them. <rlb>dsmith: should main build on freebsd now? I was just testing and it woulnd't, but I might be doing something wrong. <rlb>dsmith: I started via "M4=gm4 ./autogen.sh"