IRC channel logs


back to list of logs

<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)'
<ijp>I dunno, maybe?
<spk121>ArneBab_: I think the current story is that for 2.0, we don't call setlocale by default unless interactive.
<ArneBab_>is that/will that be different in 2.2?
<spk121>ArneBab: yes, if I recall correctly
<zv>Wouldn't that be dangerous in the general case?
<ArneBab_>why shoul dit?
<ArneBab_>why should it?
<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))))"
<spk121>It doesn't work for me.
<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
<mark_weaver>zv: what danger did you have in mind?
<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
<spk121>mark_weaver: oh, right. Thanks.
<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))
<djcb>how can I achieve that?
<amz3>djcb: use re-export
<mthl>you can see for an example
<djcb>amz3: thanks!
<mthl>which doesn't require manual #:re-export
<djcb>can I express "re-export everything that ..
<djcb>that's a useful example
<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
<djcb>(for me at least)
<amz3>djcb: +1
<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 :)
<kristofer> #fsf
<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)
<galex-713>Is that real?
<galex-713>OMG 32bit x86 WORK AGAIN \\oooo/
<galex-713>wingo: is that your fault? :p :D
<wingo>re the guile thing, i get to take credit both for the breakage and the fix ;)
<mark_weaver>wingo: ooooh, that's great news!!
<mark_weaver>huge thanks for debugging it
<galex-713>thank you very much \\o/
<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>ok ^^ (where is it?)
<wingo>i think it is in guix
<wingo>seems pretty minimal :)
<mark_weaver>iirc, there's a GSoC project to improve bournish
<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
<random-nick>taylan: doesn't eshell rely on buffers and stuff?
<ijp>bournish is probably a better tutorial example than the brainfuck one
<galex-713>ijp: does bournish has lisp or sh syntax?
<taylan>galex-713: it has bournish syntax ;)
<galex-713>Is there an example somewhere?
<taylan>galex-713: it looks like normal sh. just very limited in capabilities.
<galex-713>Like a guile busybox :)
<taylan>you can see in what commands it implements, where "%commands" is defined
<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>I see
<galex-713>taylan: a better explanation: because it can :p
<galex-713>And I heard coreutils code is wtf
<galex-713>taylan: btw, does guix provide other kernels than linux?
<galex-713>Like Hurd, kFreeBSD, or even better, kOpenBSD?
<galex-713>or kNetBSD maybe
<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.
<galex-713>Everything related to hurd is a wip x)
<galex-713>(even in debian)
<taylan>oh, we should move to #guix for these things btw
<random-nick>galex-713: yeah hurd support is a GSoC project
<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.
<taylan>I wrote down this a while back to clear my mind on it, though it could be outdated:
<madsy_>taylan: Ah, thanks
<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_: see
<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>but there's probably still more work to be done
<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