IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<TaylanUB>Morning ...
<TaylanUB>.oO( 3 AM )
<kurohin>how could i find the current directory guile is executing in?
<mark_weaver>what do you mean by "executing in"? are you looking for the current working directory of the process?
<mark_weaver>if so, check out (getcwd)
<kurohin>when I try to do (load-extention ... ...) I get a 'file not found' error
<mark_weaver>an extension that you made?
<mark_weaver>where did you put it?
<kurohin>in a directory above what (getcwd) returns
<kurohin>I am using gieser in emacs and it helps me outcomplete the path to the extension but for some reason it does not work
<kurohin>(load-extension "../" "init_func") does not
<kurohin>it worked at first but after a recompile of the library it does not , i am wondering if it might be some other dependencies that i have added to that it is having trouble finding
<mark_weaver>well, there are two problems. first, you should remove the .so suffix
<mark_weaver>the other thing is that it doesn't search relative to the current working directory
<mark_weaver>it might work to specify an absolute pathname (but with the .so removed)
<mark_weaver>otherwise, you should just put "mylib" and then arrange to have it somewhere on the search path.
<kurohin>is that the same search path that is used for finding scm files? load-path?
<mark_weaver>no, it's the shared library search path
<mark_weaver>it includes things like LD_LIBRARY_PATH, LTDL_LIBRARY_PATH, the system places specified in /etc/*, etc
<kurohin>is there a way to control or set the library search path from inside guile REPL
<mark_weaver>well, one option is to simply pass absolute paths to 'load-extension'.
<mark_weaver>another option is to use 'setenv' to set one of those environment variables, though keep in mind that will propagate to subprocesses (maybe not a problem)
<mark_weaver>libltdl (part of libtool), which is what handles this, also has an API for adding to the search path just for this process
<mark_weaver>s/this/the current/
<kurohin>thanks for the info, using setenv is not a problem while I am developing, when entering "production" I will have to do it the right way.
<mark_weaver>okay, happy hacking!
<nalaginrut>I think relative path is a problem, many guys encountered include me
<nalaginrut>fortunately, I used 'load'
<mark_weaver>if you could help me reproduce the problem with 'include' on my side, I could debug it.
<mark_weaver>but it seems to work for me.
<nalaginrut>I tried 'guile -q' to avoid loading other REPL plugins, but it's always reproduced for me
<nalaginrut>mark_weaver: maybe your Guile is cutting-edge?
<nalaginrut>mine is
<mark_weaver>mine is the same
<nalaginrut>is there other things I can drop the extension plugins?
<nalaginrut>IMO -q is enough
<mark_weaver>it would help if you gave us a self-contained example, with two files, one including the other, and then tell us what exact command(s) you typed from the REPL.
<nalaginrut>actually, I just typed (include "aa.scm")
<nalaginrut>but (load "aa.scm") is ok
<mark_weaver>yes, from the REPL you can't use a relative pathname.
<nalaginrut>and absolutely path is ok
<mark_weaver>but you can 'include' a relative pathname from a file
<nalaginrut>alright, I got the point
<nalaginrut>was this issue added into manual/docs?
<mark_weaver>well, the manual entry for 'include' says: "If FILE-NAME is a relative path, it is searched for relative to the path that contains the file that the `include' for appears in."
<mark_weaver>I think that's reasonably clear, no?
<nalaginrut>but it doesn't mention REPL
<mark_weaver>ah, there's a typo though. that "for" should be "form".
<nalaginrut>anyway, it's trivial
<nalaginrut>it'd be better if it mentioned REPL can't support the relative path for include
<nalaginrut>I thought it's bug in the begining
<madsy>wingo: Morning :)
<wingo>moin :)
<wingo>i wonder how well luajit does with closures
<civodul>Hello Guilers!
<madsy>hey civodul
<wingo>good day :)
*wingo almost finished fixing up vm.texi
<civodul>wingo: wo000t!
<civodul>that must have been tiring
<wingo>it was ok
<wingo>the tiring part will be the compiler
<wingo>in vm.texi it's mostly just the instructions, and those were mostly documented in c
<wingo>so i wrote a little script to munge them; now touching up by hand
<wingo>checked against the output of (instruction-list)
<wingo>yay scheme
<wingo>evening, bipt
<wingo>ok the "instruction set" section is updated now
<wingo>it's kinda rough but at least it's there
<synacktic>Is it possible to disable optimizations for debugging purposes?
<synacktic>I think my tracepoints aren't working because of tail-call elimination. (Does that happen?)
<mark_weaver>tail calls are not an optimization. they are a fundamental part of the semantics of procedure calls in scheme.
<mark_weaver>but indeed, tail-calls can make debugging more difficult.
<mark_weaver>regarding tracepoints: do you suspect that a tail call to a procedure with a tracepoint on it aren't getting traced?
<mark_weaver>can you come up with a minimal self-contained example to demonstrate the problem?
<mark_weaver>(something that I could reproduce on my end)
<synacktic>Hmm... so when I try it with a very minimal example there doesn't seem to be a problem
<mark_weaver>yeah, seems to work for me too
<mark_weaver>well, maybe start with the case that fails, and incrementally strip it down from there, trying to preserve the buggy behavior.
<synacktic>Turns out it had nothing to do with TCE. The function just wasn't being called :P
<mark_weaver>ah :)
<mark_weaver>thanks for letting us know, anyway :)
<davexunit>Working on functional reactive programming for guile-2d. Made a little proof on concept demo:
<davexunit>and a screenshot of the result:
<mark_weaver>oooh, looks nice!
<civodul>davexunit: excellent!
<mark_weaver>davexunit: I think (signal-lift (lambda (p) (vx p)) mouse-position) could be written (signal-lift vx mouse-position), no?
<davexunit>mark_weaver: yes it could. it was more complicated before.
<davexunit>then I removed everything but that and didn't take it the extra step.
<mark_weaver>where's the code for signal handling?
<mark_weaver>well, I guess I can find it myself :)
<davexunit>it's rather simple, perhaps too simple, but it has been working for all of my use-cases thus far.
<mark_weaver>on gitorious now, excellent! :)
<davexunit>yeah I finally got around to switching.
<davexunit>the only bothersome thing is that gitorious isn't rendering my org-mode readme for some reason.
<mark_weaver>which branch should I be looking at?
<mark_weaver>for the latest FRP stuff, that is.
<davexunit>mark_weaver: does that link not bring you to the right place?
<davexunit>wip-main-loop-rewrite is the branch name
<mark_weaver>it does, but I wanted to avoid using the web browser.
<davexunit>oh okay.
<davexunit>I have a bunch of local branches hanging around with half baked ideas in them.
<kurohin>mark_weaver: remember the problem I had last night with not being able to load my extension, it would give a "File not found" err, turns out it has nothing to do with search paths. the problem is when I try to use scm_new_smob symbol it can not be found. for some reason it is not exported by I have and is not exported by the guile application either. Is there any other library that I should link my extension to?
<kurohin>forgot -D to nm, it is exported as a dynamic symbol.
<kurohin>but why does my extension load if I comment out all usage of scm_new_smob
<mark_weaver>if there's a link error, it might be reported as file not found. terrible, I know.
<kurohin>I am using other function such as scm_gc_malloc, scm_c_define_gsubr and those does not give this error.
<mark_weaver>scm_new_smob is a recently added, inline function.
<mark_weaver>(added in 2.0.7)
<mark_weaver>do you have multiple versions of guile installed on your system?
<kurohin>no, I am using the one that came with ubuntu 13.10
<kurohin>the other functions works without linking with libguile, are proberbly found in the guile application but scm_new_smob does not work with our without linking with
<kurohin>is there any other function I could use instead of scm_new_smob
<mark_weaver>it would be good to find out what's going on here, instead of papering over the problem, if possible.
<kurohin>okey, love to help. what do you want me to do?, small example that triggers the problem?
<mark_weaver>that would be very helpful