IRC channel logs


back to list of logs

<dadinn>hey guys, regarding my previous problem with getopt-long, I think I have a workaround
<dadinn>i.e. the issue was that options-spec is not extensible, additional, unsupported propetries cause the `getopt-long` function to throw errors
<dadinn>the code is here:
<dadinn>hack, but it works nicely, now i can add additional props to my spec, like `discription`, and `default`... needed for generating usage help
<mwette>(use-modules ((ice-9 getopt-long) #:select ((getopt-long . old-getopt-long)))) is an option over the (@ ...) syntax. See the manual section on modules.
<dadinn>mwette: fair enough, otoh maybe it is preferrable to have such an ugly sign of that something non-standard is going on there
<fibration>Maybe someone is interested in this: guile-snarf doesn't seem to work with the latest dash-0.5.10_3 package from voidlinux. Not sure if this is a dash or guile-snarf bug. everything's fine after changing the shell in the shebang directive from sh to bash
***fibratio` is now known as fibration`
***fibration` is now known as fibration
<dadinn>so finally, using my previously shared extension for specs in (ice-9 getopts-long), here is a kind of usage help generator I wanted:
<dadinn>my options-specs have extra 'description 'value-desc 'default properties, and they are used in the usage help generator ;)
<dadinn>for reference this was code for the getopts-long option-specs extension:
<dadinn>Not sure, does anyone think this could be useful in the ice-9 codebase? At least fixing that anoying anti-feature of not allowing additional "non-standard" properties in the option-spec would be nice to see back...
***chrislck1 is now known as chrislck
<nalaginrut>afternoon guilers~
<nalaginrut>wingo: could you take a look at this issue?
<nalaginrut>wingo: It seems guile-2.2 changed something to break the guile plugin in GDB
<nalaginrut>wingo: and I'm trying to write a debug tool with it, just like gef:
<nalaginrut>wingo: If any necessary, I could send a mail to
<nalaginrut>anyway, gdb guile plugin works fine with guile-2.0, I'm using it right now. It's better if we can fix it for 2.2
***Raimondii is now known as Raimondi
***w2gz is now known as w1gz
<dadinn>hi all
<dadinn>experimenting with modules currently. created a module, and tried to reference it from another script, and it fails "no code for module" I placed it under a directory as described. It seems that the current dir is not part of the load-path?
<dadinn>how do i tell guile to add the current dir to the load-path?
<amz3`>dadinn: guile -L `pwd`
<amz3`>dadinn: guile -L $(pwd)
<dadinn>amz3`: what is the reason it doesn't do it automatically? when i am running a script. shouldn't it be first on the list to check for other modules next to the script itself?
<dadinn>essentlially i have a script which uses module (my mod), and have this module next to the script, in a folder my, named mod.scm
<amz3`>I am not sure why 'current working directory' is not part of the guile path, I assume it's a security reason
<dsmith-work>amz3`: Yes
<dsmith-work>For the same reasons you don't want "." on your $PATH
<dsmith-work>Monday Greetings, Guilers
<dadinn>dsmith-work: is there a way i can configure the load-path? like $PATH
<dadinn>dsmith-work: I think if i remember correctly I can specify for scripts to load another file relative to them. I think that wouldn't apply to module boundaries?
<dsmith-work>dadinn: Are you aware of how module names work with the load path?
<dsmith-work>So for a module named (foo bar baz), the dir "foo" must be on the load path, and the module file is foo/bar/baz.scm
<dsmith-work>The "bar" dir is not on the load path.
<dsmith-work>Hmm. Maybe I've said that wrong.
<dsmith-work>Been a while since i've been a guile'ing.
<dadinn>dsmith-work: i was expecting it to be so
<dadinn>so (my mod) should be like my/mod.scm relative from a dir-root on the load path
<dadinn>so if my load-path is ("/usr/lib/guile" "/var/lib/guile") then (my mod) should be either /usr/lib/guile/my/mod.scm or /var/lib/guile/my/mod.scm
<dsmith-work>dadinn: Yes
<vivien_>Hello guile! I'm trying to have org-babel evaluate a call to load-extension. It does not work when I org-babel-execute it (the module is not initialized) but it does work when I copy/paste the content of the src block into the geiser buffer. As I understand it, org-mode does some extra lambdaing around the code to handle variable substitution and results extraction, and thus (load-extension) is called in a lambda. Did I miss something? How do
<vivien_> I have load-extension actually load the so when inside a lambda?
<vivien_>Or is there a better way to use guile with org-babel ?
<vivien_>OK I did a quick hack with an elisp source block that goes to the geiser buffer and types "(load-extension ...)"