***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. <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 <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 <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 <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. <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>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 <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 <dsmith>taylanub, I just searched for google tech talk haskell <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 ? <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>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>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 <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 <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 <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>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>i'll try a dist clean and compile again <dsmith>then you must run autogen.sh and ./configure again. <dsmith>WHich is where the problem might lie <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>it repetedly says 'blabla ... non-POSIX recursive variable expansion' <tupi>but suggest to run configure at the end <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>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>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 <civodul>tupi: what Automake version do you use? <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 <tupi>civodul: on the box that fails i have multiple arch, could that be a problem ? <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>are you building --disable-shared or something? <tupi>./autogen.sh --prefix=/opt; ./configure --prefix=/opt; make <tupi>libltdl-dev:amd64 2.4.2-1.2 <tupi>libltdl7:amd64 2.4.2-1.2 <civodul>without running autogen/autoreconf, that is <tupi>let me tell you that on the box that fails, there is one more libtool package <civodul>but what matters more is the "libtool" package, not "libltdl" <civodul>if it does, it may be an autofoo issue <tupi>by the way did you see my message about par-map ? <tupi>par-map uses 1 core [instead of 12] in guile 2.0.9 <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>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 :-) <civodul>because i fixed the simple cases in the past, AFAIK <tupi>the code you pasteed to me <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>iota 400000 of course ... <dsmith>civodul, Do you know where scm_to_wchar is defined? I can't find it. <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>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>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 <tupi>you mean the source code ? <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 <tupi>dsmith: the config.log is 2M, any cmd to split/compress so i can send it to devel? <tupi>i was hoping a magic linux cmd to split/compress <tupi>taylanub: great, that did it <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.