IRC channel logs
2014-12-24.log
back to list of logs
<ArneBab>Do you think I should add more people to acknowledgements? <ijp>just the usual people: jesus, buddha, marlon brando, etc. <cky>.oO(But why in $DEITY's green earth would people use HTML3.2?!) <cky>Like, even HTML4 is as old as R5RS itself. <cky>(Actually, it's older than R5RS, having been ratified in December 1997.) <ArneBab>cky: because the SRFI process mandates HTML 3.2 <ArneBab>also everything can display HTML 3.2 correctly. It does not have style sheets. <ArneBab>strangely that was my feeling when I wrote it - it reminded me of the time when I used HTML as a document markup language for my own writing. Roughly 14 years ago. <ArneBab>(or rather: when I converted it from the org-mode export to HTML 3.2 - mostly stripping away all kinds of extra features) <drdanmaku>back when html documents were, y'know, documents <drdanmaku>and the browser wasn't trying to be an application runtime <ArneBab>but well - times are changing. And some of the semantic HTML 5 markup elements actually seem quite nice. <jralls>What does 'bad header on object file: "GOOF----LE-4-2.0"' mean? <ijp>it probably means you are using a .go file from one guile version that doesn't work on another <ijp>are you building guile from master? <jralls>ijp: No. It's actually a GnuCash user who's tried to build the latest release on Ubuntu. <jralls>His config.log shows Guile-2.0.11, with no Guile 1.8 installed. <ijp>1.8 didn't do compilation anyway, so that wouldn't be a problem <ijp>2.2 is pretty different though, so that's what sprung to mind <jralls>GC's configure doesn't test for Guile2.2. Maybe he has that too. <ijp>I don't see why they would be running master, but it doesn't hurt to ask <jralls>Heh. It's Ubuntu. Bleeding edge are them. <ijp>hmm, but no, then I'd expect the cookie to say 2.2 <ijp>ah no, that would be if the gnucash file was compiled on 2.2, not if they were running 22 <ijp>jralls: they'd need to install it themselves, since there hasn't been a 2.2 release <jralls>Well, I wouldn't put it past Ubuntu to package from git, but it does seem unlikely. What other possible causes of that error? FWIW I tested on Debian Jessie and had no problem. <ijp>well, the only way you can get that error is if you try to use .go files whose cookie doesn't match the guile you are using <ijp>e.g. different endianness <jralls>Hmm, different endianness seems unlikely these days unless one is using old Apple hardware. And he built GC, and therefore compiled the scheme files, on the machine with the problem. <jralls>Is it only a cookie check or might the compiled header have gotten damaged some other way? <ijp>verify_cookie in objcodes.c <ijp>oh wait no, silly me. make_objcode_from_file <ijp>FUNC_NAME being the "official" one, for error purposes <jralls>Hmm, maybe I misinterpreted the report. He says he installed from the package, so the build log he linked is the packager's machine, not his. <ijp>there shouldn't be much degrees of freedom, but if there was a conflict between the two, that would be causing it <jralls>ISTM the easiest thing for him to do is to delete the go files and let whatever Guile he's got rebuild them when he starts up. <ijp>I can't see how to display it from guile, but the cookie format is GOOF----$ENDIANNESS-$WORD_SIZE-$VERSION <jralls>Does Guile care about word size? If built on a 64-bit machine would it fail on a 32-bit one (assuming one could find one somewhere besides a museum and my house...)? <jralls>Strings foo.go | head shows the signature easily enough. <jralls>ijp: What about the reverse? The signature is LE-4-2.0, so he built it with 32-bit Guile. Will 64-bit Guile choke on that? <ijp>I don't know enough about why guile couldn't handle it, but the cookie check would fail, and error <ijp>the only thing it's liberal about is using a lower minor version <jralls>OK, then that's likely the problem. The build log says "amd64", so the packager screwed up and built it with a Guile compiled for 32 bits. <mark_weaver>is it just me, or are most of GNU's sites down? e.g. the web site and savannah <cky>jralls: ARM is big-endian too. <cky>Oh wait, ARM apparently supports both. <ArneBab>nalaginrut: it’s not so bad - the essential features are there <ArneBab>I now sent the SRFI to the srfi editors. Let’s see whether it actually becomes a christmaas SRFI ☺