IRC channel logs

2020-05-04.log

back to list of logs

***catonano_ is now known as catonano
<bsima>how do i get a list of the currently bound symbols at a repl?
<mitigate>daviid - the answers to my questions are --with-guile-site=yes for configuring guile-lib and GUILE_AUTO_COMPILE=0 for the user to use the system compiled files
<sneek>Welcome back mitigate, you have 1 message!
<sneek>mitigate, daviid says: I don't know what gentoo ebuild does, but if you use the autotool chain, _and_ specify --with-guile-site=yes as a configure option, then yes, it will use guile's (global) site dir for the source modules and guile's siteccache dir for the compiled modules, and in that case, you, a a user, dont ned to do anything tbe able to use guile'lib's modules and they all should be (pre)compiled
<mitigate>haha
<dsmith>rlb: There are 4 flavors, all combos of {32,64}{be,le}.
<dsmith>rlb: (but you prob already knew that)
<str1ngs>hello daviid, thanks for looking at this. I think in the case of vte-terminal-spawn-async the flags were more of an issue. though the annotation issue would still make this hard to work on. https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#g-spawn-async uses GSpawnChildSetupFunc and other functions on that page might use it as well. The documentation for GSpawnChildSetupFunc can be found here GSpawnChildSetupFunc
<str1ngs>daviid https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#GSpawnChildSetupFunc
<mitigate>I'm still having trouble with paths. I'm on M-x guiler in emacs and I've set up %load-path and %load-compiled-path - (use-modules (emacsy emacsy)) doesn't show an error (load it from the system). but (emacsy-initialize #t) throws an error In procedure module-lookup: Unbound variable: emacsy-initialize
<mitigate>coming from CL all the add-hook! set! hurts my eyes!!
<mitigate>i was hoping to get full strings in the stacktrace from the repl. On the command line the strings are truncated
<mitigate>i'm possibly missing something basic and should head for a modules tutorial
<RhodiumToad>I sort of like the !s, it makes it more obvious when you're mutating stuff
<str1ngs>mitigate: hello, what distro are you useing?
<mitigate>str1ng - gentoo - more of "roll your own"
<mitigate>ah now i see i have to use the wip branch of emacsy.
<str1ngs>mitigate: ahh wip branch fixed your problem.
<mitigate>not yet
<mitigate>but it'll fix another problem with an undefined variable
<str1ngs>I normally install emacsy with --prefix=$HOME/local. then set export GUILE_LOAD_PATH="$HOME/local/share/guile/site/2.2"
<str1ngs>and export GUILE_LOAD_COMPILED_PATH="$HOME/local/lib/guile/2.2/site-ccache"
<str1ngs>mitigate ^
<daviid>sneek: later tell mitigate you should not set GUILE_AUTO_COMPILE=0
<sneek>Will do.
<daviid>str1ngs: getting the spwanflags in g-golf is easy, I'll add those to g-golf right now, but here is how you do that - (gi-import-by-name "GLib" "SpawnFlags" #:with-methods? #f #:force? #t)
<daviid>str1ngs: the annotation 'bug' is only a problem if one once to pass NULL, (#f or %null-pointer), but we can still use that/those functions to make callback work in g-golf then ... but I need to understand what to do :) because according to the #instrospection folks, unlike I thought, I can't prepare and pass a GClosure
<str1ngs>daviid: would it be easier for me to just use (gi-import-by-name "GLib" "SpawnFlags" #:with-methods? #f #:force? #t) myself?
<daviid>str1ngs: no, i'll do that, just mentionning
<daviid>str1ngs: here is what they told me "in the case of the async APIs, there isn't (a closure API). you have to pass a function pointer to a C function, which uses ffi to get the C arguments off the stack, and translate them into values that you can pass to your user's scheme function"
<daviid>str1ngs: from that answer, it seems to me that what you pass i your C version, is one of the g_spawn_ function, is this correct?
<str1ngs>for my use case I really only need to pass #f or NULL here
<str1ngs>not to say that would'nt change but my use case is pretty trivial. I mainly just need this function to call.
<daviid>str1ngs: for all callback? exactly like in my 'template'?
<str1ngs>this is the C code http://git.savannah.nongnu.org/cgit/nomad.git/tree/typelib/util.c?h=feature-g-golf#n67
<str1ngs>I should probably use FLAGS for the 0 argument here
<daviid>it's ok
<daviid>str1ngs: if you were to pass a callback, would you pass a pointer to a predeined Glib function then?
<str1ngs>I think the scheme way would to have a lamba here. but my guess is that would be really hard to impliment?
<daviid>str1ngs: I was asking in the C code you pasted
<str1ngs>what I would normally do here in C. is create a function with the a GSpawnChildSetupFunc signature. and then pass that function name. but I'll have to test that out to confirm this is theoretical
<daviid>str1ngs: ok, it is so weird that they do not provide a closre api, because now I have (as all other bindig of course, not just g-golf) to 'invent' a mechanism to do that, exactly that, ut not using what we have ...
<str1ngs>well I would not do it for my VTE sake it's not worth the work IMHO. what are other bindings doing do you know?
<daviid>str1ngs: but there are other callback arguments 'out there'
<str1ngs>though there is one spot it might be useful let me find it.
<daviid>this was just a way to think and test ...
<str1ngs>this is a more practical use case I think. https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-run-javascript
<str1ngs>GAsyncReadyCallback is probably used more often in API
<str1ngs>btw the CL GI bindings suffer from this problem too.
<daviid>str1ngs: by th way I can very easily patch g-golf so it parse the vte-terminal-spawn-async child-setup-data-destroy #f, and I was asked to report a bug to the vte team, I won't becaue they don't use an email workflow, they use a web bug report workflow ... would you like to do that?
<str1ngs>daviid
<str1ngs>daviid: I can report the annotation bug to the VTE team now I'm aware.
<daviid>str1ngs: either the vte-terminal-spawn-async or this webkit_web_view_run_javascript is a good example - the problem is to come up with a solution for all ... or to manually bind a C signature function 'on demand' ...
<daviid>str1ngs: thy said 'it seems like an annotation bug', the person is a gnome developer, but not a member of the vte team ...
<str1ngs>I'll check the annotation if that's the case and it gets fixed I'm assuming #f would then work there?
<daviid>str1ngs: yes, note that (a) the typelib does not report it as 'allow-none', (b) the doc also does not mention 'allow-none' althogh the doc comment says '... or NULL'
<daviid>in the mean time, I'll patch g-golf right noe to accept it as an exception
<daviid>and import the spawnflags
<str1ngs>okay thank you.
<str1ngs>daviid: here is revised C version using GSpawnChildSetupFunc. http://paste.debian.net/1144861
<str1ngs>it's slightly more complete. maybe I should test VteTerminalSpawnAsyncCallback too
<str1ngs>BTW printf ("Starting Terminal\n"); prints to the widgets terminal which is intresting.
<daviid>str1ngs: ok, yes it's interesting to 'doubl test' it works
<str1ngs>I think GAsyncReadyCallback is more useful to g-golf as a whole. though I use VTE I can get around these corner cases with C if I have too. using a typelib and g-golf .
<daviid>str1ngs: then a webkit_web_view_run_javascript example, later, would be nice as well ...
<daviid>str1ngs: to come up with a general solution, g-golf needs to analyse its callback (the GI info) argument, then generate a C function with that signature, I'm not sure how to do that
<str1ngs> I hear ya, this is not easy to sovve. did #introspection talk about how other GI bindings solve this ?
<str1ngs>solve*
<daviid>str1ngs: the person had to leave, sothe conversation ended with the suggestion I pasted above "in the case of the async APIs, there isn't (a closure API). you have to pass a function pointer to a C function, which uses ffi to get the C arguments off the stack, and translate them into values that you can pass to your user's scheme function"
<daviid>I wonder what guile-gi does
<str1ngs>or pygobject
<str1ngs>I'm just putting a GAsyncReadyCallback example together in scheme.
<daviid>yes or pygobject - good for the GAsyncReadyCallback example ... we'll use it
<str1ngs>here the scheme JS example. http://paste.debian.net/1144866
<str1ngs>this is the simple version does not use a callback. but this should get you started I think?
<str1ngs>this throws the 'match-error can't find pattern callback
<str1ngs>I just pull I'm 18 commits behind :(
<daviid>str1ngs: ok, I jut pushed a patch and now the vte-terminal.scm script I did paste erlier todat works fine
<daviid>str1ngs: please pull, make and test ... :)
<daviid>str1ngs: I don't think the CL bindings were/are complete - the guile-gi author is absent these days, I hope he's fine ...
<str1ngs>daviid: great thanks will check it out first thing in the morning.
<daviid>ok
<daviid>this webkit-web-view-run-javascript is complete?
<daviid>*this paste
***apteryx_ is now known as apteryx
<daviid>str1ngs: this works - https://paste.debian.net/1144870/ - it will be a good example to further work this callback problem, so now we have two examples to play with ...
<gypsydave5>Quick question about mutable lists - (set-cdr! (cons 1 2) 3) works as expected, but (set-cdr! '(1 . 2) 3) complains that the argument isn't a mutable pair. What gives?
<RhodiumToad>pairs that are quoted in the expression aren't mutable
<RhodiumToad>since they're basically compiled constants
<gypsydave5>Perfect explanation RhodiumToad -- thanks!
<RhodiumToad>(as I understand it, anyway)
<dsmith-work>Hey Hi Howdy, Guilers
<guix-vits>sneek: botsnack
<sneek>:)
<z0d>was uniform-vector-read! removed from Guile? what can I use instead?
<str1ngs>sneek: later tell mitigate we merged emacys wip branch into master. thanks for letting us know about that.
<sneek>Okay.
<dsmith-work>z0d: Always check NEWS for language changes:
<dsmith-work>*** `uniform-vector-read!' and `uniform-vector-write' have been
<dsmith-work> removed. Use `get-bytevector-n!' and `put-bytevector' from (rnrs io
<dsmith-work> ports) instead.
<z0d>dsmith-work: thanks
<str1ngs>hello daviid, just a request for comments here. it looks like to me that <gtk-application-window> now takes a <gtk-application> for the #:application #:init-keyword before it took the !g-inst pointer. does this sound right to you?
<str1ngs>I made API change in Nomad and seems to be working.
<daviid>str1ngs: it should definitely accept an instance of the type of it proerty, I guess it was a bug that has been fixed - I patched the instance contruction for interfaces ...
<str1ngs>gotcha, it's working nicely thanks. do you have a link to your vte example. I forget to add it to my notes.
<str1ngs>daviid found the link in logs.
<daviid>so after those patches, you may do (make <gtk-tree-view> #:model store) - instead of gtk-tre-view-new/set its model ... and retrieve the model as an instance, (!model a-tree-view) -> an instance of the class tht was used to create to tree-view ...
<daviid>ok, those links die after some hours, days ... as you know
<str1ngs>okay good to know, I'm not using modal right now. I got the gnome link thinks
<str1ngs>thanks*
<str1ngs>I will probably use modal at some point. so thanks for the details
<str1ngs>also regards to VTE some time ago it was suggested to use spawn async but that is still not listed as stable API which is wired. so wondering if we should worry about VTE at all?
<str1ngs>weird*
<rlb>dsmith: thanks, actually didn't remember offhand.
<str1ngs>daviid: calling vte-terminal-spawn-async works well now thank. without using callbacks of course.
<daviid>str1ngs: I used the vte example because you use it, and now it's one of the example we have to further implement callbacks ... I also told the #introspection person that helped me with this that I did ask you to report the bug ...
<str1ngs>daviid: I will check the annotation and report that now.
<str1ngs>did you need any further examples for webkit-web-view-run-javascript. the example I used was minimal I planed to extended it for callback later. which does not need to show a GUI to test. thought not a practical example.
<daviid>str1ngs: did you see the run-javascript latest paste I posted yesterday?
<str1ngs>I'll check that, I'll find it on http://logs.guix.gnu.org/guile/
<str1ngs>webkit-web-view-run-javascript does work now, have not testing callbacks which is probably WIP?
<daviid>oh, we passed each other - no 'real' callback will work, since there is no protocol provided by GI
<daviid>I have no idea what I should do about this
<str1ngs>no problem, this is better then before.
<justin_smith>is it possible to attach a custom write implementation to a lambda?
<str1ngs>daviid: personally I don't need it because I can use the web extension via web messaging which is asynchronous . but that does not help regular users.
<daviid>str1ngs: do you know pygobject? i'd like to know what they do, if they do provide a callback solution that is 'general'
<str1ngs>daviid: I can look at pygobject for this senerio. My python is weak, but I should be able to grasp the C parts
<str1ngs>let me try to report this annotation issue. then I'll get a pygobject example going and try to figure out how it handles async call backs.
<daviid>str1ngs: I'll ask on #introspection, I did ask actually, but wantd to know if you dod know 'enough' about pugobject ... to help, no worries
<str1ngs>daviid https://gitlab.gnome.org/GNOME/gjs/ might be better reference since it's a GNOME project.
<str1ngs>in terms of asking how something is implimented.
<daviid>they point me to gjs regurlarly ... but they didn't (yey) in this case
<str1ngs> https://gitlab.gnome.org/GNOME/gjs/-/blob/master/gi/function.cpp#L204
<str1ngs>gjs_callback_closure seem to do the FFI argument lookup
<daviid>str1ngs: your C knowledge might b a better help
<daviid>take this vte callback example, your lambda that displays something i the terminal - how do we 'turn that a C function' that w can pass it ...
<str1ngs>GSpawnChildSetupFunc is probably not the hard. but maybe you mean VteTerminalSpawnAsyncCallback?
<daviid>str1ngs: anyone, the mechanism ... not a specific 'case
<str1ngs>gotcha, I thought GAsyncReadyCallback from webkit_web_view_run_javascript would be more practical to work on. since we know the API is more stable atleast.
<daviid>you have a lambda, any args, a C 'engine' will call it, how do you prepare the C function from scheme ... is the question
<daviid>str1ngs: forget about g-golf/gi,
<daviid>that is not the roblem
<str1ngs>makes sense, I will think on this.
<daviid>right, they pointed me to this code - https://gitlab.gnome.org/GNOME/gjs/-/blob/master/gi/function.cpp#L197-507
<str1ngs>aye that's the code that I thought handled this.
<daviid>I don't spot the part that 'writes' the C function
<str1ngs>maybe we can distill the gjs parts out
<daviid>its a guile ffi problem, not a g-golf/gi problem
<daviid>how to write a C function given a tempete (i cn give the tmplate)
<daviid>*template
<daviid>dynalically of course, otherwise we can write C function manually 'on-demand' ... :):)
<daviid>and here is a good example - a lambda that takes one argument, it is a pointer which can be NULL - how do we dynamically write a C function that can be called by a C 'engine'
<str1ngs>here GjsCallbackTrampoline seems to be built up to provide the function
<daviid>str1ngs: are you on #introspection?
<daviid>they are answering there ...
<str1ngs>one sec I'll connect to my znc
<daviid>i don't thnk it's logged
<str1ngs>I have a back log, reading now
<str1ngs>daviid: from the sounds of it there is enough in gjs_callback_closure to figure this out. but it will take more groking. particularly need to look at GjsCallbackTrampoline
<str1ngs>daviid: this is a very top down pseudo way to do this I think. g-golf would have a C function like gjs_callback_closure. this is called when the callback is needed. this gets all of the arguments converts them to scheme types. then calls the void *data which is the lambda with the scheme arguments. this is might be overly simplified but I think is basically how this would be done in g-golf. WDYT
<wingo>moo
<sneek>Welcome back wingo, you have 1 message!
<sneek>wingo, dsmith says: How does guile-cairo get at guile-snarf-docs and guile_filter_doc_snarfage which are not normaly installed?
<wingo>dsmith: iirc that was meant to be run only by the package maintainer. but it has been a long time, perhaps daviid knows more there
<wingo>civodul: hey did you see i pushed the new compiler :) not hooked up to anything yet tho
<wingo>is much like the old tree-il -> glil compiler; better handling of lexicals (no penalty for naming a value), worse handling of contification (something better left to cps)
<wingo>only tested in the most cursory of ways tho :P
<daviid>wingo: maybe you meant lloda`, because wrt guile-cairo, I've always been a mere user :) and none of my projects use guile-snarf-docs, so I wouldn't know
*wingo stands corrected
<wingo>my memory is a sieve these days :P
<daviid>wingo: it's ok, mine to :):)
<daviid>it's terrible
<wingo>yeah. accept the things you can't change, etc..
<justin_smith>repeating a question from 2.5 hrs ago that might have been missed in scrollback - is it possible to attach a custom write implementation to a lambda?
<wingo>justin_smith: don't think so, it's kinda baked in
<justin_smith>OK, in that case I'll use a helper (lambda closed over hash table from proc to printer) thanks
<dsmith-work>wingo: Still, lots of extensions use the snarfing machinery. Would be nice if the doc-snarfing part of that was also available.
<wingo>justin_smith: yeah makes sense
<justin_smith>call it something like write+ and replace the calls to write that matter
<wingo>dsmith-work: you're not wrong :) i hesitate to maintain & document such a thing in guile itself tho
<civodul>wingo: i didn't!
<civodul>woow
<civodul>lemme see
<civodul>wingo: neat!
<civodul>the bit about adding high-level intrinsics is interesting
<wingo>yeah, could apply to CPS at lower optimizations levels also; dunno
<wingo>not sure what the tradeoff is
<wingo>anyway for guix packages i am pretty sure that skipping CPS is the right thing
<wingo>the baseline code is quite good on simple cases imo
<civodul>so eventually -O0/-O1 would automatically pick the baseline compiler, right?
<wingo>civodul: yeah
<civodul>cool
<civodul>it's funny that it's a completely different path
<civodul>so the other -Oxyz flags would make no sense
<civodul>perhaps -Ocompilation-speed could select it or something
<civodul>so the missing bit is source location info mostly, right?
<dsmith-work>wingo: SO. How do you enable this new compiler?
<wingo>dsmith-work: not wired up currently :) you have to manually (load-thunk-from-memory (compile-bytecode (macroexpand exp) mod mod)))
<wingo>civodul: source location info is easy actually, just need to wire it up
<wingo>incidentally i am not jealous about this thing, i plan no big changes other than bug fixes, so plz feel free to hack on it
*wingo zzz
<civodul>wingo: noted, thanks!