IRC channel logs

2013-06-30.log

back to list of logs

***sneek_ is now known as sneek
<rlb>dsmith: yeah -- don't know how soon it might move, but once I have guile-2.0 working against it (with the glibc fix), then I'll probably badger the libgc maintainer again.
<dsmith>Meanwhile, wingo has really be cranking on the rtl vm in master.
<rlb>rtl?
<dsmith>rlb, A register based vm instead of a stack based one.
<dsmith>rlb, register transfer language iirc
<dsmith>rlb, The next step to a full native machine compiler
<rlb>ahh, ok, right
<wackOnline>hello,I have a question about @,e.g: (@@ (web uri) uri-uri-decode) and (@ (web uri) uri-uri-decode) distinction between
<ijp>if the function is exported, there is no difference
<add^_>Indeed
<ijp>@@ looks into the module for private top level variables
<ijp>@ only looks for public top level variables
<ijp>take care when using @@ since an update to the code may break it
<wackOnline>Oh, I get it, thank you
<taylanub>How does one get better error information from Guile ? Executing a unix script, copy-pasting code into the REPL, or using C-M-x with Geiser all give quite obscure error messages from what I see.
<ijp>example?
<taylanub> http://sprunge.us/DZci Copy-pasting code to the REPL example.
<taylanub> http://sprunge.us/KQEW C-M-x with Geiser example.
<taylanub> http://sprunge.us/UWPL Unix script example.
<taylanub>I guess I can tell that at some point it tries to evaluate an expression (#f 0 0). Hrm, the script output seems to point at line 79, I'm just now noticing that.
<taylanub>(Wouldn't one expect a finished script to be the least useful for debugging ?)
<ijp>what's your problem? the "unknown file" bit?
<ijp>The error message is quite clear
<taylanub>Then I have to learn how to read it. :\\
<ijp>wrong type to apply ==> not a function, or an applicable struct
<ijp>at least, assuming we have applicable structs. I think we do
<taylanub>In the Geiser and REPL cases, the line numbers are wrong (corresponding to lines of the REPL perhaps?), and I get no information as to what bit of my actual code caused the error, although I think I can imagine how hard it is to provide that information when there's so many compilation passes ...
<ijp>anyway, you are dropped into a debugger. Learn to use it :P
<taylanub>It's also amazing how a single line of code can expand to 100, quite literally. :P
***linas__ is now known as linas
<add^_>ijp: I just watched a GoogleTechTalk about Haskell, it was amusing. ;-)
<tupi>hello guilers. anyone knows what could be the cause of the guile compilation error? i'm asking because i just successfully compiled on another debian machine and here on mine, it faiuled: so it could well be a missing -dev or -dbg package...
<tupi> CCLD libguile-2.0.la
<tupi>gcc: error: .libs/dynl.o: No such file or directory
<tupi>gcc: error: .libs/regex-posix.o: No such file or directory
<tupi>make[3]: *** [libguile-2.0.la] Error 1
<tupi>
<dsmith>tupi, Did you copy everything over from one machine to the other? Specifically the configure output?
<dsmith>If you ran ./configure on the new machine, it should have failed to find things that are not there
<taylanub>add^_: Hrm, link ?
<dsmith>taylanub, I just searched for google tech talk haskell
<taylanub> https://www.youtube.com/watch?v=b9FagOVqxmI ?
<add^_>Yup
<taylanub>Thanks.
<tupi>dsmith: i precisly fail to find out what is the missing thing. do you have an idea, basd on the output i copied above ? i tried but so far did not identify the problem
<tupi>also, both machines are 'old' and did compile 2.0.7 without any problem
<tupi>on the one that compiles the latest table [git], automake is 1:1.13.2-1 and on the one that fails, it is 1:1.13.3-1 could that be a problem ?
<tupi>s/table/stable :)
<dsmith>Not sure
<dsmith>I don't understand why it's trying to link those .o files when it never created them. I would have thought the make would have failed when it tried to build them in the first place.
<dsmith>dyn.c is ltdl
<dsmith>and the other depends on the regex code in the system library
<tupi>ok, the diff in respect this package is that on the not working machijne i have 1 more package
<dsmith>tupi, Isn't there an error message earlier when trying to compile those two .o's?
<tupi>libltdl7:i386 [because of skype dependencies, i had to had architecture 386...]
<tupi>but on both i have also libltdl-dev:amd64 2.4.2-1.2
<tupi>let me check
<tupi>don't know, if i try make again, it is not trying to compile anything but these again
<add^_>taylanub: It's pretty cool, although I'm sticking with Scheme. But it's fun to look at something new once in a while. :-D
<taylanub>There's Typed Racket and all ...
<tupi>i mea n the outpu is the one a copied above, it is not trying to compile the missing .o
<taylanub>I'm always interested in having the best of all worlds. :P
<dsmith>tupi, I would think it would try and compile dynl.o from dynl.c and stop when it doesnt
<dsmith>Hmm.
<tupi>in the config.log i have [quite a lot of result no actually] an output wher it includes regex.h and at the end says configure:28517: result: no
<dsmith>What if the compiled output was named something else.
<taylanub>By the way I'll be "releasing" bytestructures 1.1, where you can now bundle a descriptor to a bytevector so you needn't provide the descriptor at each ref/set call. Together with pointer->bytevector, that should allow some delicious FFI abstractions.
<taylanub>("Releasing" in scare-quotes because it will consist of a tagged git commit.)
<dsmith>tupi, I've not used a multiarch system yet
<tupi>dsmith: i am not knowledgeable either, i just had to install because of skype, [how sad ms purchased skype by the way] and otherwise would not have done that.
<dsmith>tupi, Is there anything libguile/.libs/dynl*
<tupi>dsmith: no, i have a bunch of libguile* _and_ net_db.o posix.o socket.o but no dynl.o
<add^_>taylanub: Yeah :-) I thought it was a good idea to look at Haskell because I'm reading about the λ-calculus
<tupi>dsmith: on the machine that compiled successfuly they are all there
<add^_>But yeah, the best from both worlds
<tupi>dynl.o net_db.o posix.o regex-posix.o socket.o
<dsmith>dynl can be explained by a missing -dev package, but the regex stuff is part of the C library.
<dsmith>I don't understand why that is not building.
<dsmith>Also, I don't understand why the build doe not stop when it fails to compile dynl.o
<dsmith>unless you are usning make -k
<tupi>the machine that fails is more up-to-date with debian packaes the the one that succeeds
<dsmith>tupi, Sorry, I don't think I can help.
<tupi>i do make
<tupi>not make -k
<dsmith>Very odd
<tupi>dsmith: it's ok, i will send an email with the config.log and the error message
<dsmith>WHen you run make again does it TRY to compile dynl.c ?
<tupi>nope
<dsmith>OR just ignore it?
<dsmith>Hmm.
<dsmith>git or tarball?
<tupi>git
<tupi> http://paste.lisp.org/display/137858
<tupi>i'll try a dist clean and compile again
<dsmith>more complete is git clean -dxf
<dsmith>then you must run autogen.sh and ./configure again.
<dsmith>WHich is where the problem might lie
<dsmith>lay?
<tupi>yes
<tupi>./autogen.sh --prefix=/opt sends warnings i don't think i had one the working box
<tupi>m/snarf:5: warning: AM_V_SNARF_$(V: non-POSIX recursive variable expansion
<tupi>
<tupi>it repetedly says 'blabla ... non-POSIX recursive variable expansion'
<tupi>but suggest to run configure at the end
<tupi>let's see
<tupi>configure done. it does not seem to fail
<dsmith>Look at your makegfile. Does it have unexpanded AM macros in it?
<dsmith>IT sounds like your makefile has rules to link those .o files, but no rules to build them. Very odd.
<tupi>in the makefile i have
<tupi>EXTRA_DOT_DOC_FILES = dynl.doc posix.doc net_db.doc socket.doc regex-posix.doc
<tupi>EXTRA_DOT_X_FILES = dynl.x posix.x net_db.x socket.x regex-posix.x
<tupi>
<tupi>GCC_CFLAGS = -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wpointer-arith -Wswitch-enum -fno-strict-aliasing
<tupi>LIBLOBJS = dynl.lo posix.lo net_db.lo socket.lo regex-posix.lo
<tupi>LIBOBJS = ${LIBOBJDIR}dynl$U.o ${LIBOBJDIR}posix$U.o ${LIBOBJDIR}net_db$U.o ${LIBOBJDIR}socket$U.o ${LIBOBJDIR}regex-posix$U.o
<dsmith>As does mine
<civodul>tupi: what Automake version do you use?
<dsmith>Ahhh!
<tupi>civodul, 1:1.13.3-1
<dsmith>I bet this has something to do with the recent windows build changes
<tupi>[on the machine that fails
<tupi>and 1:1.13.2-1 on the one that compiled
<civodul>ok
<civodul>should be fine
<civodul>and Autoconf 2.69?
<tupi>civodul: on the box that fails i have multiple arch, could that be a problem ?
<civodul>Debian?
<dsmith>All my files in libguile/.libs/ are libguile_2.2_la*.o except for dynl, net-db, posix, socket, and regex-posix
<tupi>yes on both, and yes, debian testing/unstable/experimental
<civodul>normally that shouldn't be a problem, unless the Debian versions are specifically patched
<civodul>ok
<civodul>are you building --disable-shared or something?
<dsmith>civodul, I am.
<tupi>no i am not
<civodul>(there's http://bugs.gnu.org/14193 related & on my to-do list, but it's mostly cosmetic)
<tupi>./autogen.sh --prefix=/opt; ./configure --prefix=/opt; make
<civodul>ok
<civodul>autogen.sh ignores its arguments
<civodul>which Libtool version?
<tupi>libltdl-dev:amd64 2.4.2-1.2
<tupi>libltdl7:amd64 2.4.2-1.2
<civodul>ok
<civodul>and does it work if you take a tarball from http://hydra.nixos.org/build/5416231 ?
<tupi>i will try now
<civodul>without running autogen/autoreconf, that is
<tupi>let me tell you that on the box that fails, there is one more libtool package
<tupi>libltdl7:i386
<civodul>oh
<civodul>but what matters more is the "libtool" package, not "libltdl"
<tupi>libtool 2.4.2-1.2
<civodul>ok, good
<civodul>let's see if the tarball works
<civodul>if it does, it may be an autofoo issue
<tupi>ok, i am trying now
<tupi>by the way did you see my message about par-map ?
<civodul>not yet i guess
<tupi>par-map uses 1 core [instead of 12] in guile 2.0.9
<civodul>argh
<tupi>yep!
<tupi>i did notice because one of my process triggers 7200 threads [of digital image processing] and should last _+ 50 min. but after a couple of minutes, it starts to use 1 core only and lasted 5h
<tupi>i think it passed the libguile already, it's in module psyntax ...
<civodul>ok
<civodul>i think i won't investigate tonight, but will do sometime this week
<tupi>i can send an email with the config.log of the git [failing] built if you want
<tupi>the par-map problem is not urgent either, but it would be nice to get it sorted out of courtse. did you reproduce the problem at least ?
<civodul>no, i'm doing other things right now :-)
<tupi>ok
<civodul>and i'll need a concrete test case
<civodul>because i fixed the simple cases in the past, AFAIK
<tupi>the code you pasteed to me
<tupi>here it is
<tupi>it wil only take a sec to try
<tupi>guile -c '(begin (use-modules (ice-9 threads)) (par-map 1+ (iota 400)) (display (length (@@ (ice-9 futures) %workers))) (display "\\n"))'
<tupi>oh
<tupi>iota 400000 of course ...
<dsmith>civodul, Do you know where scm_to_wchar is defined? I can't find it.
<dsmith>Ahh
<dsmith>conv-integer.i.c
<civodul>tupi: hmm, seems there's a problem
<tupi>civodul: i just installed the latest from the tarball. i confirm that the simple par-map test case you offered shows the problem here too, so you should be able to reproduce on your machine i guess.
<civodul>but i don't see how it defers from the previous bug report
<tupi>oh msg xrossed :)
<tupi>it does not. the thing is that what you did did worked on guile 2.0.7 but somehow not anymore in guile 2.0.9
<tupi>don't know
<tupi>i did see a lot of git changes on futures, threads ... so i guess it could be that the 'bug' was reintroduced, don't know
<civodul>tupi: could you try to bisect it?
<civodul>maybe just compare with 2.0.7
<tupi>you mean the source code ?
<civodul>no, the behavior
<tupi>well on 2.0.7 [i don't have any available now, just installed 2.0.9 :) but could reinstall] it would use all cores up to the end of your example (iota 400000). in 2.0.9, it does not even try :) or just a millisecond maybe, then falls to 1 core only
<civodul>pfff
<tupi>dsmith: the config.log is 2M, any cmd to split/compress so i can send it to devel?
<dsmith>gzip?
<tupi>gzip is still 250K
<tupi>i was hoping a magic linux cmd to split/compress
<tupi>:)
<taylanub>xz :P
<tupi>bzip or even better ?
<tupi>taylanub: great, that did it
<tupi>tx
<taylanub>Was there some kind of limit you were trying to fit it in ?
<tupi>yes, 50K otherwise the email is rejected [gnu ...]
<taylanub>Whoa, xz got it to 1/5 the size of what gzip did ? Quite the difference.