IRC channel logs


back to list of logs

***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
<lloda>I hope this will fix it
<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
<wingo>as 2.1.3
<janneke>wingo: i support you with that
<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 ?
<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>i think the 6 failures at are genuine failures
<civodul>and the 6 successes at are genuine successes, of course ;-)
<civodul>except in the cross-compilation case, there's just one Guile being built
<wingo>how would you explain the backtrace in then?
<wingo>i don't see how it would print source locations.
<wingo>maybe the -L "/tmp/nix-build-guile-0pre.drv-0/build/../guile-" 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?
<wingo>civodul: yes
<civodul>i remember this was discussed recently
<wingo>and i have asked others and they also say yes
<civodul>did you bribe them?
<wingo>and that error in the backtrace is consistent with the recent bug fix
<wingo>hehe ;-)
<wingo>so yeah, that guile-tarball-0pre download from the log... is that a thing?
<wingo>at the very top of
<civodul>according to this is built from commit 7142005a055432f0d261c294c8cef012651a1899, which is the latest one
<wingo>i wonder if the tarball includes prebuilt/ or something
<wingo>i.e. is it the result of "make dist" or no?
<wingo>so weird
<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
<civodul>that should be fine no?
<civodul>no stale .go files
<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
<wingo>so i guess i should download and see what's in it
<wingo>which is the disted tarball
<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_>I read here that there are Guile bindings to the GNU Scientific Library:
<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
<wingo>i see, the nixos tarball is built here:
<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
<wingo>not sure though!
<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;
<wingo>so maybe the cross-compiled files from x86-64 to ia32 that are made in prebuilt/ don't work
<wingo>i reproduce the bug! yay
<wingo>using .go files cross-built from x86-64 to i686
<civodul>wingo: ooh, good catch!
<dsmith__>wingo, Did you see my email about 32bit?
***dsmith__ is now known as dsmith
<wingo>dsmith: i did not, let me catch
<wingo>er, look
<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 bound that to "mask"
<wingo>and then checked (= bits (logand mask bits))
<wingo>where's the bug? :)
<wingo>~~quiz time~~
<civodul>tick tock...
<daviid>too scary
<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> <- wait a couple minutes before it uploads
<wingo>sorry, did not get a chance to look at that
<daviid>wingo: ok
<wingo>i know it's frustrating but i have really not had time, sorry
<wingo>after the release :)
<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>in a couple hours :P
<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>wingo: g-wrap fails
<daviid>it compiled fine against 2.1.2 but maybe I have to activate an 'allow depricated' flag or smething?
<daviid>guile-cairo [master] compiles fine, but make check fails
<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>wingo: guile-gnome make fails with an error I've never seen before:
<daviid>but 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>wingo: guile-lib make pass, make check fails
<daviid>3 tests out of 25 failed
<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>hey wingo
<paroneayea>ACTION reads the ethreads memcached code 
<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`>héllo :)
<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
<random-nick>amz3`: see resolve-module
<amz3`>ah thanks looking at it right now
<amz3`>OK! I solved an issue with my program
<amz3`>So it goes like this
<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)'
<amz3`>and it works...
<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...
<amz3`>nalaginrut: o/
<ArneBab>amz3: I’m glad it helped! (however it’s not my trick, I just learned it from someone else in here)
<amz3`>My program is not hanging!
<amz3`>yeah! this way ->
<amz3`>yeah!! this way ^
<amz3`>yeah!! everywhere
<random-nick>amz3`: <^V>
<dsmith>sneek, later tell civodul Are there any continuous integration servers for guile? For guix?
<sneek>Got it.
<ijp>dsmith: hydra?
<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: oh I didn't know about htat library
<paroneayea>ijp: I wonder if it's good enough for extracting link relations... probably?
<ijp>ACTION shrugs
<paroneayea>ijp: thanks, I didn't know about that library!
<paroneayea>or rather
<paroneayea>that sub-library
<random-nick>what is special about html5 syntax?
<random-nick>more elements that don't have to end?
<ijp>what's special is that they've specified how it is supposed to be parsed
<mark_weaver>there's htmlprag
<ijp>rather than trying to reverse engineer that information from browsers
<paroneayea>that solves that one
<paroneayea>no https in guile proper is still an irritation though for considering writing this in guile though :\\
<paroneayea>hm, I wonder if means better possibilities for reviving