<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>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>my options-specs have extra 'description 'value-desc 'default properties, and they are used in the usage help generator ;) <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>wingo: It seems guile-2.2 changed something to break the guile plugin in GDB <nalaginrut>wingo: If any necessary, I could send a mail to bug-guile@gnu.org <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>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? <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>For the same reasons you don't want "." on your $PATH <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 <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 <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 ...)"