<boxofrox>Hi, is it possible to reset/clear the top-level environment in guile? <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 ***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 <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? <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 <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 <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