IRC channel logs

<nalaginrut>morning guilers~

<davexunit>hey

<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?

<kurohin>yes

<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 "../mylib.so" "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 mylib.so 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/ld.so.conf*, 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 2.0.9.92-d3606

<mark_weaver>mine is the same

<nalaginrut>hmm

<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

<civodul>heh

<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

<mark_weaver>yay!

<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?

<synacktic>Yes

<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>Alright

<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: http://paste.lisp.org/display/140315

<davexunit>and a screenshot of the result: http://imgur.com/SzuDXlx

<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.

<davexunit>thanks.

<mark_weaver>where's the code for signal handling?

<mark_weaver>well, I guess I can find it myself :)

<davexunit>mark_weaver: https://gitorious.org/guile-2d/guile-2d/source/a3d00293cbd731a86751b1f46d994bebab4bd655:2d/signals.scm

<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.

<mark_weaver>thanks!

<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 libguile.2.0.so 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>2.0.9"

<mark_weaver>okay

<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 libguile.so

<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

IRC channel logs

2013-11-30.log