IRC channel logs

2020-08-17.log

back to list of logs

***catonano_ is now known as catonano
<tohoyn>sneek: botsnack
<sneek>:)
<tohoyn>daviid: what is the situation with G-Golf?
***evhan` is now known as evhan
***terpri__ is now known as terpri
<dsmith-work>Monday Greetings, Guilers
<mwette>Have a great week!
<lloda>|o
<lloda>could use an example of how to use display-backtrace
<lloda>or even how to get at the data there
<lloda>I find the doc obscure :-/
<dsmith-work>str1ngs: So the problem I had bringing the bot over was (IIRC) was for-each being undefined (!!). Initially, I rewrote the calling code with named let instead. I found that srfi-1 for-each was still available, so I went back to that.
<d4ryus>lloda: does (catch #t (lambda () <code>) (lambda error <error handling>) (lambda _ (display-backtrace (make-stack #t) (current-output-port)))) as an example help? The first lambda of catch gets called, on error the 3rd lambda (with the display-backtrace call) gets called before the stack is unwound, then the stack is unwound and the 2nd lambda gets called.
<lloda>that helps I think
<lloda>but how can I look at that stack on the repl?
<lloda>the printer is of no use
<d4ryus>Hmm, not sure. You could save the stack and then look at the frames etc. if that helps?
<d4ryus>I wrote a very basic display-backtrace procudure as a display-backtrace replacement due do display-backtrace not working well with fibers: https://paste.gnome.org/pqrskdxgm maybe you can find some info there on how to inspect the stack
<lloda>thanks d4ryus i can use that
<lloda>even tho i'll have to edit & rerun
<lloda>which i find puzzling since ,bt can obviously access that stack
<d4ryus>I guess you could hook the repl into it, maybe wrapping your code with call-with-error-handling does the trick? (see: module/system/repl/error-handling.scm line 43)
<lloda>ooh that seems to be precisely what I need
<d4ryus>Looks like that is what the guile repl does. It starts a new repl with a debug record (looks like it contains the stack and other info) inside the procedure thats passed as 4th argument (the error handling procedure that gets called before the stack is unwound) to catch.
<roelj>Does someone have an example of an Autotools-based project that uses a libtool library that is loaded in Guile with "load-extension"?
<roelj>I don't know how I should configure the distribution of the library so that Guile can find it..
<lloda>it seems that frame-arguments doesn't always return a list. Sometimes it returns _ and I don't know what that means...
<dsmith-work>roelj: An external library? Or is the package the library?
<roelj>dsmith-work: Uhh.. I have Guile code and C code under one Autotools project.
<roelj>So, an internal library I suppose :)
<lloda>apparently '_ means the arguments have been GC'd ?
<dsmith-work>Ok. This might help: https://gitlab.com/dalepsmith/guile-sqlite I'm not expert on autotools, but that seems to work.
<dsmith-work>roelj: ^^
<roelj>dsmith-work: Of course, I should've gone to the awesome guile-sqlite code!
<roelj>dsmith-work: Thanks for the pointer, again :)
<dsmith-work>That's sqlite2. There are better/more extensive guile sqlite3 interfaces out there.
<roelj>dsmith-work: Well, I only needed line 17 from "configure.ac"
<dsmith-work>roelj: And 11-17 of Makefile.am
<dsmith-work>(11-16)
<dsmith-work>roelj: Specifically, I've named the .so sqlite.so, NOT libsqlite.so .
<roelj>Hm, I get a "*** No rule to make target 'all'. Stop." when make enters the directory containing the extension code. Any ideas?
<roelj>Perhaps I forgot LT_INIT
<lloda>i'm surprised (. x) matches an improper list
<lloda>i suppose it makes sense
<erkin>I believe it's nonstandard syntax.
<RhodiumToad>I think it's how (. x) gets read that causes it
<RhodiumToad>experimentation suggests that (. x) is read as just x
<erkin>I guess that wasn't intended.
<dsmith-work>roelj: You have no "all" target. Either add an all target or have whatever is calling that make use an existign taret.
<RhodiumToad>so e.g. (match '(a . b) ((. x) x)) is the same as (match '(a . b) (x x)) and in either case is (a . b)
<dsmith-work>roelj: (without looking at your files..)
<lloda>so it's (match x ((? list? x) x)) the way to go?
<lloda>is it
<RhodiumToad>you want to return x as-is only if it is a proper list?
<lloda>i want to match a proper list yes
<d4ryus>lloda: I think _ means "optimized out"
<RhodiumToad>lloda: or maybe (match x ((e ...) e))
<lloda>thx d4ryus i figured
<lloda>i needed to parse the result of frame-arguments because otherwise the 2nd etc arguments would get removed by the truncated printing
<lloda>should have thought of that RhodiumToad thx
<justin_smith>d4ryus: is the "optimized out" state related to TCO by any chance? eg. if the tail call was followed, I'd expect the gc to reclaim the locals of the function that was jumped from
<justin_smith>otherwise TCO wouldn't work - you'd leave a trail of all the locals back through the call chain
<justin_smith>I think
<justin_smith>well, it would work but also be a resource leak
<justin_smith>which is a less than ideal version of "works"
<d4ryus>justin_smith: Yeah, makes sense. Besides TCO you often see arguments of local procedure calls replaced with _. I guess those get optimized (inlined?).
<justin_smith>intuitively that sounds right, some day I'll read the compiler code maybe and really know
<roelj>dsmith-work: I forgot to include the Makefile.am in configure.ac. D'oh! :)
<dsmith-work>heh
<roelj>But I'm exploring a different route now; How do I access a handle from "scm_c_make_gsubr" from Scheme?
<dsmith-work>roelj: Sorry, I don't understand your question.
<roelj>Ah, my bad.. Here's another attempt at explaining my situation: I have a function (written in C) that I'd like to expose in a Scheme module (instead of the toplevel). So I can scm_c_make_gsubr that function, which returns a handle to the Scheme equivalent of that function. Now, how can I "add" this function to the public interface of an existing Scheme module?
<roelj>I found "scm_c_export" and "scm_c_call_with_current_module".
<RhodiumToad>as far as I can see, scm_c_define_gsubr adds the definition to the current module
<RhodiumToad>so just make sure the current module is the correct one
<dsmith-work>Typically, you use SCM_DEFINE a the the function definition, and then run the snarfer, and #include the resulting foo.x file in the body of your init function.
<RhodiumToad>otherwise, the return value of scm_c_make_gsubr is exactly the thing that you would pass to scm_define
<dsmith-work>And then in the .scm file that dynamically loads the .so, you (re-)export what you want to expose.
<roelj>Uhh.. I now do: SCM m = scm_c_resolve_module(...); scm_c_call_with_current_module (m, f, NULL); And in f I call scm_c_define_gsubr.
<RhodiumToad>that seems like it might be overkill, but should work?
<roelj>But if I #:use-module (that module), it cannot find the functions I added using scm_c_define_gsubr.
<roelj>How could I simplify it?
<RhodiumToad>did you export them?
<roelj>As in, scm_c_export("the-name-of-the-function", "another-function")..?
<RhodiumToad>yes
<roelj>No.. :)
<RhodiumToad>well then
<roelj>haha
<roelj>Right. So, you mentioned it might be overkill. What's overkill? The call to scm_c_call_with_current_module?
<RhodiumToad>yes
<RhodiumToad>scm_c_module_define might be more applicable
<roelj>Ah, I see
<roelj>When using scm_c_module_define, how do I scm_c_export them?
<RhodiumToad>er, good question.
<roelj>I added scm_c_export ("the" "functions", NULL); But I still get a "Unbound variable: the".
<RhodiumToad>where did you add it?
<roelj>In the function that is passed as second parameter in scm_c_call_with_current_module.
<roelj>Directly after scm_c_define_gsubr.
<RhodiumToad>that should work...
<roelj>Perhaps I should paste the code somewhere. What's a good paste service?
<RhodiumToad>dpaste.org
<leoprikler>debpaste, gnome paste, dpaste, pick one
<roelj> https://dpaste.org/8nCw
<RhodiumToad>typo
<RhodiumToad>pdf_report vs pdf-report
<roelj>Bah, indeed!
<roelj>That was it indeed
<roelj>thanks!
<roelj>Alright, one more thing.. So I have an executable that calls scm_with_guile. Which in turn loads that (www db reports) module. If I were to define a function "init_guile" that does "scm_c_define_gsubr", can I then load the executable with "load-extension"? Or is it impossible to compile an executable that is also a library?
<leoprikler>ever heard of ASLR?
<roelj>Nope
<leoprikler>(short answer: Yes, you can make executables, that are also shared libraries)
<roelj>I can't quite link address space layout randomization and executable+library yet.
<leoprikler>Perhaps I'm remembering it wrong, but in order to implement ASLR and be able to move the code of the program itself, you have to basically make it a shared library (i.e. compile with -fPIC etc.)
<leoprikler>the magic behind ASLR then becomes loading a shared library and executing main ;)
<roelj>leoprikler: Yeah, I found: http://marklodato.github.io/2009/10/03/executable-shared-libraries.html
<roelj>Building now..
<roelj>Guile says "file not found", even when passing the absolute path to it. Does it expect a ".so" extension?
<leoprikler>it is not an absolute path without that, so I'd say yes
<roelj>But.. my executable does not have a .so extension! :P
<leoprikler>in that case, you might want to check whether something is wrong with your shared library
<leoprikler>"file not found" can also mean that a dependency was not found and is generally very confusing
<leoprikler>when in doubt, strace
<dsmith-work>strace reveals all..
<roelj>Ah, good call
<roelj>Well, it does seem to open the executable first, then continues to search for <executable>.la and <executable>.so
<roelj>So I guess -fPIC and -fPIE is not enough to make it a recognizable shared library for Guile.
<RhodiumToad>if you build something as an executable, it won't export any symbols by default
<roelj>Perhaps splitting the shared-library bits and the executable is better / easier anyway
<roelj>Ah, I see.. I have multiple source files, most in a subdirectory. And I set <program_name>_LDFLAGS to "-fPIC -fPIE -pie". But it seems that only <program_name>.c is compiled with these options, and not the rest.
<roelj>What's the automake magic that is needed to make the LDFLAGS "global" for this program?
<dsmith-work>So LDFLAGS are only for linking....
<roelj>Right, so I added it to <executable-name>_CFLAGS. That seems to do it.
<roelj>As in, it compiles. But it doesn't seem to make a difference
***apteryx_ is now known as apteryx
***janneke_ is now known as janneke`
***janneke_ is now known as janneke
<erkin>The guard in this syntax-case macro refuses to match any use of the macro: https://clbin.com/2eIY7
<erkin>It naturally works without the guard.
<erkin>Anyone got any ideas?
<erkin>Is it because it can't determine whether the `+' refers to a procedure at compile-time?
<erkin>Okay, putting the guard aside, there's a syntax-case macro that works correctly with Racket but breaks in Guile.
<erkin> https://clbin.com/z0ygw
<erkin>The expanded form evaluates fine on both, so I think the Guile macro expander might be expanding it differently.
<erkin>Oh wait, Guile futures don't take thunks.
<erkin>At least I learnt how to use `macroexpand' today.
<leoprikler>I think your guard is malformed
<leoprikler>#'f yields #<syntax +>
<leoprikler>you actually want something that makes use of syntax->datum