***karswell` is now known as karswell
***micro`_ is now known as micro`
***micro` is now known as Guest28872
<lloda>wingo: janneke: thanks for the .go fix, I was getting used to clear cache on any errors that I could not explain <wingo>lloda: fingers crossed! tx to janneke for actually taking on the problem <wingo>so i think we should release with master as-is, with no changes to load paths <civodul>wingo: i haven't looked in detail, but that sounds good! <janneke>i like the idea of adding GUILE_COMPILED_PATH + 2.x; but think it could use some more thought/viewpoints <janneke>(appending '/2.x' to new env var, that is) <civodul>yeah, what wingo committed does not add this new env var, which i think is the most reasonable choice :-) <wingo>civodul: would it be possible to update the guile-0pre on hydra.nixos.org ? <wingo>many guile-master builds are failing because their guile-0pre is broken afaiu <civodul>wingo: i think there's no such thing as "guile-0pre", no? <wingo>i guess i don't understand hydra completely. however that backtrace indicates a failure to build the first .go file (bootstrap/ice-9/eval.go), but the backtrace shows that there are already .go files <wingo>so that build is using some GUILE_FOR_BUILD <wingo>otherwise the backtrace would show lots of frames from the interpreter instead of proper source locations in other parts of guile <civodul>except in the cross-compilation case, there's just one Guile being built <wingo>i don't see how it would print source locations. <wingo>maybe the -L "/tmp/nix-build-guile-0pre.drv-0/build/../guile-2.1.2.200-71420/module" line is related... <lloda>wingo: things work for me so I'm fine with 2.1.3 at this point <wingo>lloda: i understand you have some array patches too, let's work on those for 2.1.4 <civodul>wingo: i don't know, but does it work for you on i686 for instance? <civodul>i remember this was discussed recently <wingo>and i have asked others and they also say yes <wingo>and that error in the backtrace is consistent with the recent bug fix <wingo>so yeah, that guile-tarball-0pre download from the log... is that a thing? <wingo>i wonder if the tarball includes prebuilt/ or something <wingo>i.e. is it the result of "make dist" or no? <civodul>ah right, it uses the result of 'make dist' as input <civodul>but that 'make dist' is made from the same commit, IIUC <wingo>so what job produces the "make dist"? could it be including stale prebuilt/ files? <wingo>prebuilt/ files won't be removed in a make clean, and not in a distclean either afaiu <wingo>so if the source packages re-use the same build and git checkout, perhaps that's a source of bootstrappy errors <civodul>the thing takes commit X, then does "autoreconf && make dist", and then passes that to the 'build' jobs <wingo>does it do a fresh checkout or a "git pull" ? <civodul>sort of "git fetch + git reset --hard origin/master" <wingo>yeah so that can keep stale .go files around <wingo>because "make dist" will include .go files from prebuilt/ <civodul>no, because then the checkout is "interned" into the store <civodul>it always builds in a fresh directory <civodul>i don't understand where that "0pre" comes from <wingo>so the tarball is a normal tarball from "make dist" <wingo>however it does of course include all the .go files from prebuilt/ <wingo>i wonder if the prebuilt/ files are written to the builddir or the srcdir... <wingo>it could be the srcdir because that's how they are loaded up <wingo>they appear as part of the source tarball <rekado_>but it looks like GEE is no longer hosted on gna. <rekado_>Do you happen to know if the Guile bindings have survived and are available elsewhere? <wingo>civodul: do you know where the recipe is that creates the tarballs? those prebuilt .go files are coming from somewhere and i want to know how :) <lloda>wingo: thanks. The patches could use a review, actually I have a bug in one of the functions that I haven't been able to fix :-( I don't want to waste your time though <galex-713>Why do SXML use @ instead of keywords like #:attribute name? <wingo>galex-713: many reasons, but foremost an accidental reason: ssax/sxml was defined in r5rs scheme which has no keywords <wingo>with @ it's easier to deal with all attributes at once, also <wingo>and it works better with foldts / pre-post-order and other transformation tooks <ym>Is Guile-Emacs so laggy only on first start? <wingo>i have not tried guile-emacs yet! but yeah i think that many pre-compilation sorts of things are not yet enabled for it <wingo>so i think it compiles stuff at startup <ym>Yep, seems like it compiles definitions of functions I triggering, because second time the same functions work flawlessly. <wingo>civodul: perhaps you are right! the git export has no .go files, and the tarball takes 2 hours to build, indicating that it has to do a full build of the prebuilt/ stuff; the log is at the tarball build; http://hydra.nixos.org/build/36899073 <wingo>so maybe the cross-compiled files from x86-64 to ia32 that are made in prebuilt/ don't work <wingo>using .go files cross-built from x86-64 to i686 <dsmith__>wingo, Did you see my email about 32bit? ***dsmith__ is now known as dsmith
<wingo>dsmith: i did not, let me catch <dsmith>wingo, Fully builds but get several errors in make check. Seem to be EOF related. <dsmith>wingo, and from a git clean -dxf checkout, so no old files. <wingo>wow, this was a really nice bug in the assembler (!) <civodul>woow, already identified, that was fast! <wingo>it was an artisanal ethically sourced bug <wingo>let's say you are compiling and you have an immediate on the host. how to tell if it's an immediate on the target? <wingo>(define bits (object-address x)) ;; get the bis <wingo>(not (zero? (logand bits 6))) ;; if this is true then it's an immediate on the host <wingo>now to see if it's an immediate on the target, we did something like (case (asm-word-size asm) ((4) #xffffffff) ((8) #xffffffffffffffff) (else (error "blah"))) <wingo>and then checked (= bits (logand mask bits)) <civodul>wingo: object-address can still return a 64-bit integer when cross-building for a 32-bit platform, no? <civodul>so the 32-bit masks would leave the MSBs <wingo>(logand mask bits) for a 32-bit target takes the 32 least-significant bits <wingo>right :) on a 32-bit target, mask is (1- (ash 1 32)) so (logand mask bits) takes the 32 least-significant bits <wingo>however! that effectively reinterprets bit 31 as a sign bit <wingo>whereas on a 64-bit host, bit 31 is not a sign bit <wingo>that's the source of the "negative number out of range" foo for cross-compiled .go files from 64 to 32 bits <wingo>guile was residualizing this in the wrong way: <wingo>(define DT_GUILE_VM_VERSION #x37146003) <wingo>so that it was loading it up and treating the high bit as a sign bit :/ <daviid>wingo: is what you're talking about is related to and solves this bug: gnome/gw/support/glob.scm:117:15: gnome/gw/support/glob.scm:117:15: Value out of range 0 to 18446744073709551615: -1 <daviid>raised while trying to compile guile-gnome against 2.1.2 <wingo>daviid: hmm, i think this particular bug only shows up during cross-compilation <wingo>there was another bug in 2.1.2 that was related to that and fixed directly after the 2.1.2 release AFAIR <daviid>ok, will compile guile-gnome against master then. i always used master but at some point in time, can't remember exactly, I could not compile master here anymore, so grabed the tarball ... will let you know <wingo>well i should have a tarball out soonish if you want to test a prerelease <daviid>wingo: ok sounds good let me know <daviid>i've just pulled and started compilation right now, but if you get a tarball before it ends... it takes a couple of hours here iirc <daviid>wingo: did you got a chance to look at bug#20093 ? [so sorry to insist but i'd be so happy if ...] <wingo>sorry, did not get a chance to look at that <wingo>i know it's frustrating but i have really not had time, sorry <daviid>it's ok, for me any time, i'll grab master, but till it's solved, I cn't test any of my 'real' work, so let me know [i'll ping you from time to time :)] <wingo>i just pushed the assembler fix, hopefully that causes hydra to cascade green :) <wingo>locally the cross-built .go files for 32-bit appear to work <daviid>ACTION is compiling the prerelease <daviid>wingo: make and make check pass here, now compiling g-wrap and friends <daviid>it compiled fine against 2.1.2 but maybe I have to activate an 'allow depricated' flag or smething? <daviid>wingo: g-wrap make pass if configured using ./configure --prefix=/opt2 CFLAGS=-Wno-error=deprecated-declarations <daviid>and g-wrap make check pass as well <daviid>but 2.1.2.201-8b875 fixed the /glib/gnome/gw/support/glob.scm problem reported earlier today <wingo>those gnome-vfs errors are somewhat expected unfortunately, because the C interface to scheme ports changed <wingo>the gnome-vfs code will either have to be updated or gnome-vfs disabled <daviid>ok. I personnally don't use it but if it's not too much work and/or complicated I can fix it, if you want to give some guide lines, even better <daviid>maybe some other 'guile-gnomers' use it, don't know <daviid>wingo: it would be nice to fix make check and release guile-cairo 1.10 by the way, after this release of course <wingo>as far as guidelines, the manual describes the C interface and how it works; see "Input and Output" <wingo>yes you are totally right re: guile-cairo, i need to do that! <wingo>the make check failure you have is because of automake and parallel tests <wingo>guile-cairo needs the older test driver. <dsmith>wingo, There is no way to create a shim with the old api, because the data structures have changed? <wingo>dsmith: maybe it would be possible. some of the prototypes changed "in place". but in general i think that the model of how buffering should work changed enough that someone should have to think about it, and so for that reason i am ok with the breakage <daviid>wrt guile-cairo I can just locally add AM_INIT_AUTOMAKE(1.12 -Wno-portability -Wno-syntax serial-tests) and it should pass then ? <daviid>until we fix guile-lib, I can't run make check upon guile-cairo [which with the serial test goes further then before], neither guile-gnome nor guile-clutter: I don't know much about guile-lib source code actually, any one here is source code familiar with guile-lib ? <daviid>actually I was wrong, the guile-lib failures are not on the test suite so I installed and now guile-cairo make check pass <paroneayea>wingo: well, the memcached client code was certainly easy to read <paroneayea>wingo: I'm not sure how the "spawn" stuff works yet. However, I would have expected that this would be named "spawn!" <paroneayea>wingo: also why is the econtext predicate "nio?" instead of "econtext?" ***amz31 is now known as amz3`
<amz3`>how can I retrieve the same type of object as `current-module' for another module <ijp>resolve-module lets you do it by name <amz3`>ah thanks looking at it right now <amz3`>OK! I solved an issue with my program <amz3`>I was using (eval foo (current-module)) <amz3`>but I running my program using sh trick like explained by ArneBab <amz3`>and (current-module) was resolving to `guile-user' <amz3`>so now, I use `(resolve-module '(uav))' instead of `(current-module)' <ijp>I'm sure you've thought long and hard about if eval was really necessary <amz3`>yeah, I was thinking about this eval, and I true that it would be more fun to find something else <amz3`>yeah, I was thinking about this eval, and *It's* true that it would be more fun to find something else <amz3`>ijp: the program is a database, I need a way to query that data. That's the use of eval <amz3`>Next step is discover why page downloading is hanging... <ArneBab>amz3: I’m glad it helped! (however it’s not my trick, I just learned it from someone else in here) <dsmith>sneek, later tell civodul Are there any continuous integration servers for guile? For guix? <paroneayea>I guess we don't really have a nice way to parse html right now in guile-land. I wonder what my fastest path towards something like that working would be <ijp>what about the guile-lib html parser? <ijp>granted, even if that still works, it won't do the html5 parsing algorithm <paroneayea>ijp: I wonder if it's good enough for extracting link relations... probably? <ijp>what's special is that they've specified how it is supposed to be parsed <ijp>rather than trying to reverse engineer that information from browsers <paroneayea>no https in guile proper is still an irritation though for considering writing this in guile though :\\