<sbidin>Is there an in-built way to get a file's absolute path? <sbidin>Something like (abs-path "a/file") => "/home/sbidin/a/file" <sbidin>If run within the home directory. <please_help>mark_weaver: I expect guile to tell me there was/would have been a segfault but not to, itself, segfault. <please_help>I'm getting *** Error in `guile': double free or corruption (!prev): 0x00000000029ff210 ***, what's that about? <please_help>as for magic bullets, can't guile just run the C code in a subprocess kinda way? <sbidin>mark_weaver: It gets a bit messy with paths containing '..' though. I'll try to find a lib that does this "the right way". <mark_weaver>please_help: guile has support for launching subprocesses, if that's what you want to do. <please_help>mark_weaver: rather code using the FFI should be launched as a subprocess I think, though I don't know the impact on performance. This way, if the child dies (segfault), guile doesn't need to. <mark_weaver>that's not something that would be reasonable to do automatically. once you launch a subprocess, it's a different address space, different file descriptors, etc, etc. <mark_weaver>we provide the tools to do that if you want, but the FFI is about running C code within the same process. <please_help>Fork the process. wait on child. If the child process returns normally, copy the resulting memoryspace over. If not, signal run failure and continue on. Plus, isn't it possible to start with shared address spaces anyway? The segfault is a consequence of a bad memoryop but not necessarily of the memorystate. <sbidin>can I get the location of a script from within it? <sbidin>because it might not be run directly <sbidin>something like Python's __file__ <sbidin>a possible bug: the manpage mentions "--no-autocompile", but the runtime message says "pass the --no-auto-compile argument to disable". <sbidin>regardless of which one I use, autocompilation is still enabled. <sbidin>p.s. the --no-autocompile is a typo <sbidin>is there a way to combine using /usr/bin/env guile with the fancy shebang parameters functionality? <sbidin>combined with guix and its ever-changing paths, this is tricky <mark_weaver>well, GuixSD doesn't have /usr/bin/env anyway, and for good reason <mark_weaver>it completely defeats the guarantees that guix provides for a script to depend on the current PATH <mark_weaver>the best solution is to actually package your script within guix itself <mark_weaver>but if that's too much hassle, you could put /run/current-system/profile/bin/guile in the shebang <sbidin>I could do that, but it would be overkill for such a tiny script. It really is insignificant. An additional issue is that it's a script that's supposed to be runnable by people on other distributions... :)) <mark_weaver>I suppose we should provide a more convenient tool to import a script into guix, transforming its shebang <mark_weaver>okay, another option that we sometimes do in guile land, although I don't much like it, is to make it a shell script on top and guile on the bottom <sbidin>ahh, yes, that will actually work <mark_weaver>in guile, anything between #! and !# is a block comment, specifically made to allow the top part of a script be a shell script. <sbidin>oh, you meant embed the script itself into the top comment <mark_weaver>for emacs users, the "-*- scheme -*-" bit on the second line is important. that will cause emacs to go into scheme mode when editing the file, otherwise it will guess that it is a shell script. <sbidin>great! it works. thanks for the help. :) ***michel_mno_afk is now known as michel_mno
<paroneayea>sneek: later tell davexunit One crazy way maybe to have different objects communicate things between ticks and still keep things functional is a pseudo-functional pseudo-actor model where npcs / player objects and etc first process the current game state, then generate possible messages to be read by other actors during this tick based on that state... maybe? <paroneayea>sneek: later tell davexunit I guess that deviates more from the FRP direction than you want to go, though. ***michel_mno is now known as michel_mno_afk
<taylanub>what's the best way to test guile after making changes to the source? like ./pre-inst-env in guix... <taylanub>ah, found mention of ./meta/guile in README <amz3>taylanub: you are puttin your srfi inside guile? <taylanub>I keep falling for the same mistake: I write (let ((foo ...)) ...) in a macro template where 'foo' is a pattern variable, thinking it will get shadowed by the let-binding. <taylanub>in my own code I use a naming convention like <foo> for pattern variables for that reason, but I guess I shouldn't do that in a patch for Guile. (I can't imagine it getting confused with record type names, or causing any other issues.) <taylanub>(let ((obj object)) ...) ;judging by Munroe's "WTFs per minute" metric, this code loses some points :) <taylanub>(let ((object <object>)) ...) ;now the intent is clear <taylanub>(and the actual identifier namespace less cluttered, not forcing the use of worse names) <please_help>do we have an equivalent to racket's array-indexes-set! ?