IRC channel logs


back to list of logs

<boxofrox>Hi, is it possible to reset/clear the top-level environment in guile?
<boxofrox>i'm trying do what's describe in this stackoverflow Q&A for mit/lisp.
<ijp>you can sort of partially do it
<ijp>I mean, you can go through the output of ,b and use module-remove!
<ijp>but that won't do all the other sorts of things, like reset bindings for builtins
<ijp>this works because the repl is (usually) in (guile-user) and normal guile bindings are in (guile)
<ijp>give us a sec and I'll post a gist of how to make this a repl command
<boxofrox>gotta run to the store, so i'll be afk a bit
<boxofrox>thank you
***micro^_ is now known as micro^
<please_help>is there a list of documented scm_to_*/scm_from_* functions for quick reference?
<civodul>please_help: the manual has all of them
<civodul>try "info guile"
<please_help>If I have a chunk of memory that represents the partial content of a mmap'd file, is the best way to communicate that via a foreign pointer managed on the guile side?
<civodul>probably yes
<please_help>is there any alive wrapping of the gsl for guile?
<please_help>What's the best way to debug a segfault resulting from calling a function loaded from a custom c module?
<please_help>I have a function in a module that simply wraps/unwraps the scm/c types as appropriate and calls the real function to be made accessible to guile; if I call the wrapper after (load-extension ...) it segfaults, a call via (pointer->procedure ...) does not return the correct result; and yet it works when linked to a test C program.
<please_help>it looks like it might be working now all of a sudden, but again a direct call merely results in a segfault.
<please_help>suddenly it works even with a direct call and I have 0 idea what changed
<please_help>nevermind, guile already had a definition with the same function name as the one I was trying to load and I forgot to run my init()
<please_help>So, it works if I don't use the name defined via scm_c_define_gsubr
<please_help>although I hacked around the function pointers because fnptr to void* is not a valid type of cast, yet libguile requires a void* for the fnptr.
<please_help>is there a solution and/or is the hack *(void**)&fn incorrect?
<zacts>which scheme standards does guile support?
<ijp>4/5 as well as anyone else does (that's not saying much), enough of 6 that I don't bitch and moan
<please_help>it's going to support 7 fully, right?
<ijp>define "fully support"
<please_help>as per the specifications provided in the r7rs {small,large}
<please_help>then again we don't really know what large will be like yet
<ijp>well, it's meaningless to "fully support" large
<ijp>because doing 0 work is fully supporting large
<please_help>I don't follow
<ijp>please_help: it's all optional
<please_help>fully supporting r7rs small afaik means fully supporting r7rs, but that is not the same as fully supporting r7rs-large
<ijp>r7rs-small is problematic for the same reason r5rs is problematic
<ijp>i.e. it's not fully specified
<please_help>I see