IRC channel logs

2017-10-15.log

back to list of logs

***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>define-module is a built-in, no?
<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
<happy_gnu[m]>Apteryx: is it working now?
<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]>Apteryx: ohh cool :) I didn't know about Guile path
<happy_gnu[m]>I think I was reading about something like that in the manual
<happy_gnu[m]>Let me see if I can find it
<happy_gnu[m]>Apteryx is this what you mean?
<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).
<amz3``>nalaginrut: what's up?
<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 :)
<Apteryx>:)
<happy_gnu[m]>I am trying to install chickadee
<happy_gnu[m]>I got distracted reading dustyweb blog and I saw about a Guile tutorial with robots
<happy_gnu[m]>then I thought.. hey I could try a game with a robot
<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>daviid: http://paste.lisp.org/display/358761
<Apteryx>Maybe this is for internalization reasons... I read somewhere it's better if the strings to translate are static instead of dynamic.
<daviid>just don't split the string
<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 ;)