***vicenteH` is now known as vicenteH
<Apteryx>I don't understand; all of a sudden Geiser is giving me all kind of silly errors such as: <unnamed port>:393:29: <unnamed port>:393:29: In procedure module-lookup: Unbound variable: define-module <Apteryx>And I can compile my module using guild or guile without any warning... humph. <Apteryx>I think I've found the culprit. I'm defining a module with (define-module (a b) .... but the a folder is not in my %load-path, so it errors very early it seems, at least when using C-c C-a. <Apteryx>Then nothing works, not even %load-path <Apteryx>it is! I extended GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH with a new Guile dev sandbox (~/src/guile-hacks/) in my ~/.bash_profile and relogon; now Geiser is happy. <Apteryx>My current scripts are in the ~/src/guile-hacks/fiasco namespace so it works. <Apteryx>Is there any way to set a variable in the Guile REPL without printing it? like a = (my-func) to mute the output? It's very long and causes Emacs to choke. <happy_gnu[m]>I think I was reading about something like that in the manual <happy_gnu[m]>If you happen to love peace and quiet and prefer to keep your REPL’s echo area free from autodoc’s noise, geiser-repl-autodoc-p is the customization variable for you: set it to nil <happy_gnu[m]>and autodoc will be disabled by default in new REPLs. You can always bring the fairies back, on a per-REPL basis, using C-c C-d C-a <happy_gnu[m]>The customization group geiser-guile is also worth a glance, for a couple of options to fine-tune how Geiser interacts with Guile’s debugger (and more). <Apteryx>Which should I use, vhashs or hashtables? <Apteryx>Seems they both offer the same performance benefit, but that vhashs also allow easy manipulation via list-based procs, whilst hash tables do not? <dustyweb>Apteryx: hashtables are faster, but are imperative / operate on mutation <dustyweb>Apteryx: vhashes do not mutate and are fairly performant, but every time you add something that already exists it still keeps the old one <dustyweb>so you don't really "replace" the old value... it's still hanging around memory-wise, if that turns out to be important to the code you're working on <Apteryx>happy_gnu[m]: thanks for the geiser guile group tip; I've found a few defaults to adjust for my taste there. <dustyweb>vhashes are kind of like constant-access alists <Apteryx>I see. If the mapping I need is static, I guess both would work the same then? <happy_gnu[m]>Apteryx: Oh I am glad, I think is the first time I help you :) <happy_gnu[m]>I got distracted reading dustyweb blog and I saw about a Guile tutorial with robots <happy_gnu[m]>that has a REPL and you have to type commands to advance <dustyweb>Apteryx: yeah if you don't need to update the mapping using either should be fine <dustyweb>because you aren't appending beyond the initial set <dustyweb>so it's both not really mutating and not going to have duplicates <happy_gnu[m]>the little guiler .. the robot guiler .. some name like that <Apteryx>What whas the trick to split the string given to format on multiple lines? The compiler doesn't like (string-append ...) <daviid>Apteryx: \\n, ~% or 'real' cariage return in the format string itself will do... <Apteryx>daviid: right, that would split the printed string. I'm looking to split the string in the source code file, for readability. <Apteryx>Sorry if I expressed the question poorly. <daviid>I don't understand what you are trying to do, example? <Apteryx>Maybe this is for internalization reasons... I read somewhere it's better if the strings to translate are static instead of dynamic. <Apteryx>OK. Seems to run in the face of good coding style conventions though. <daviid>the coding style conventions are for the code itself, not for strings that require 'not to be split' (for example because passed to a gnome widget that wraps them automatically ...) <daviid>if you prefere to keep your procedure 'clean with that respect, you can define a var with the format string outside the procedure and call it using ~? <Apteryx>Right, that'd be a way. Thanks! I'll try to come up with more succint messages as well ;)