<ArneBab_>this fails — can we make it work by default? guile -c "(display ((λ()'ArneBab)))" <ArneBab_> ?: 0 [call-with-input-string "(display ((\\u03bb()'ArneBab)))" ...] <ArneBab_>ERROR: In procedure call-with-input-string: <ArneBab_>ERROR: Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)' <spk121>ArneBab_: I think the current story is that for 2.0, we don't call setlocale by default unless interactive. <spk121>ArneBab: yes, if I recall correctly <zv>Wouldn't that be dangerous in the general case? <ijp>spk121: yeah, but I could maybe see somone arguing -c is somehow more special than -s <spk121>But I would have thought that this would work: guile -c "(begin (setlocale LC_ALL \\"en_US.utf8\\") (display ((λ()'ArneBab))))" <ijp>oh right, I can see why that would't work <mark_weaver>spk121: the string passed to -c is of course converted before it is run <zv>I thought changing the locale also effects glibc string processing functions at-time-of-use <mark_weaver>I need to go afk now, but I'll be back later and will read the log <zv>if you were dealing with anything UTF-8 encoded that didn't fit into ASCII it could be reinterpreted differently between different calls of a function ***dsmith_ is now known as dsmith-work
<galex|713>I think guile should implement TeX or something alike, because with less than a dozen lines I can write XML into my .tex file and get it converted to syntax-colored pretty-printed SXML <mejja>That is trivial galex: Port guile to MMIX and you are ready to go! <djcb>suppose I have a module X, which contains (use-modules (X a) (X b)) <djcb>now, I like to have a and b available publicly after (use-modules (X)) <mthl>which doesn't require manual #:re-export <djcb>can I express "re-export everything that .. <mthl>This is not simple but it works :) <djcb>would be worth adding something like that to guile-proper, or? <amz3>why add to guile when you can copy/paste ? :o) <amz3>I don't understand how it does what it does <amz3>I mean I don't understand the guix snippet <mthl>amz3: there are subtle evaluation time distinction making it hard to reason about. <wingo>re-export-modules would be a nice thing to have in guile, i think :) <djcb>i *think* i understand the snippet, but figuring out the correct incantation is non-trivial <amz3>incantation is the correct word <wingo>oh gods i finally figured out the "miscompilation" <wingo>and it wasn't a miscompilation, it was a vm bug :/ <wingo>with the switch to having VM stack elements be all 64 bits <wingo>but the "mov" instruction, which is used to shuffle around values, only moves word-size values <wingo>which on 32 bits means you can end up with garbage in the upper 32 bits <wingo>there is a simple fix for the moment, thankfully :) <wingo>though a proper fix will involve having the register allocator know more about slot representations <wingo>mark_weaver: dsmith-work: kick off a fresh 32-bit compile, it should work now :) <galex-713>on #emacs: <taylan> GuixSD has a "bournish" shell implementation implemented as a language on the Guile compiler tower :D (useful for launching a rescue shell in the initramdisk and such without bundling in a whole bash or so) <wingo>re the guile thing, i get to take credit both for the breakage and the fix ;) <galex-713>wingo: breakage is a common thing while developing software and is unintented, while fix can be waited for and always is intended ;p <galex-713>wingo: is it true a bournish shell was implemented on guile compiler tower? <wingo>galex-713: as i understand it, yes, but i had nothing to do with it fwiw :) <galex-713>I really *have* to understand all the guile lowlevel stuff :o <galex-713>I mean, a file in enough to implement a language… that great… <taylan>I remember reading "bournish is to guile what eshell is to elisp" and now I wonder whether guix could make use of eshell via guile's elisp compiler... <taylan>but IIRC eshell uses buffers for some things, and guile itself doesn't implement the buffer type I think <ijp>obviously not without an emacs <ijp>bournish is probably a better tutorial example than the brainfuck one <taylan>galex-713: it has bournish syntax ;) <taylan>galex-713: it looks like normal sh. just very limited in capabilities. <madsy_>Do I understand this correctly: Guile assumes that sizeof(void*) == sizeof(long), so that values that fit in a long is stored directly as the pointer. And if the number doesn't fit in a long, the SCM gets converted to a bignum using GNU GMP. <taylan>I guess it can also run executables, but apparently cp and rm are implemented as built-ins, probably because the initramdisk of guixsd lacks coreutils... <galex-713>taylan: a better explanation: because it can :p <galex-713>taylan: btw, does guix provide other kernels than linux? <galex-713>Like Hurd, kFreeBSD, or even better, kOpenBSD? <taylan>support for Hurd is a work in progress AFAIK. <taylan>someone was working on it as part of GSoC; I dunno what the latest state is. <taylan>oh, we should move to #guix for these things btw <taylan>madsy_: I don't know about assuming sizeof ptr == long, but last state I know is that bit patterns ending in 1 0 are interpreted as a 30 or 62-bit integer, with those two bits shifted out. <madsy_>taylan: Investigating something in numbers.c in guile 2.0.9 and 2.0.11 which stops me from making 64-bit windows builds <madsy_>Probably more changes are needed, but that's at least one <taylan>madsy_: I was guessing one probably needs to compile guile with mingw, which I would expect to solve the long vs. long long thing... <taylan>since indeed on 64-bit Windows, long is only 32 bits. ***Bobbejaantje is now known as Mayor_Adam_West
<mark_weaver>madsy_: in there, you'll find a patch from me to work toward eliminating the assumption that sizeof(long)==sizeof(void*) <mark_weaver>madsy_: make sure to use the second patch I posted there, instead of the first one <mark_weaver>but I don't have an LLP64 system on which to test, so all I can do is fix problems as they are brought to my attention