IRC channel logs


back to list of logs

<davexunit>is there anyway to hint to the compiler that a variable used as a loop counter is in the u64 range?
<xvilka>btw, anyone knows if there is a Guile kernel for Jupyter (former ipython)? I found one Scheme kernel, but it's a not real Scheme - it's implemented in Python...
***sajith is now known as Guest50132
***micro` is now known as Guest59573
<meena>dsmith: o/~ hai
<meena>i keep confusing the channels i'm in
<civodul>wingo: looking at i wonder if we missed an opportunity to decouple file name encoding from locale encoding
<civodul>we could have introduced a special fluid and env. var for file name encoding
<civodul>such that we wouldn't need to change the current locale if all we want is to change the way file names are interpreted
<civodul>well, maybe in 3.0
<civodul>or maybe never since UTF-8 has taken over the world! :-)
<wingo>i think we can still add such a fluid i would think...
<wingo>like we can add a fluid that defaults to #f, and if its #f then guile uses the locale
<wingo>double dynamic lookup ;)
<wingo>friggin file names
<civodul>that could work
<civodul>but we also need to add scm_from_file_name and similar
<civodul>which would call scm_from_stringn with the fluid's value or locale_charset()
<wingo>same with the related things in this set (command-line args and env vars)
<dsmith>bytestrings! It's all bytestrings.
<dsmith>Sure wish there was a nicer name for that.
<dsmith>Like bs or something
<civodul>wingo: yeah, it's this bad
<wingo>there was much gnashing of teeth on the mailing list a month or so ago about this
<wingo>i think scm_from_file_name etc would work fine fwiw
<wingo>just a bit gnarly :)
<dsmith>Hmm. How about "byst" ? Short, mnemonically memorable, an probably unique.
<dsmith>And the same characters as "char" (and "byte"!)
<civodul>wingo: well if also need scm_from_environment_variable and scm_from_command_line, then it becomes unpleasant
<wingo>ACTION mainly concerned about impact to scheme users rather than impact on C API and internals
<wingo>like, how is our ability to write correct programs affected
<civodul>without some sort of a raw "bytestring", it's hard
<civodul>OTOH, we do want to encourage string decoding whenever possible
<wingo>did you see the two unicode weirdness suggestions
<civodul>maybe but i must have forgotten :-)
<wingo>one to do what emacs does, which is some kind of utf-8 zaniness
<wingo>for file names which don't decode, emacs "encodes" them as a sort of invalid utf-8
<wingo>that encodes the "bad" bytes in such a way that they would be written out exactly
<wingo>like it's a kind of utf-8 that embeds bytes
<civodul>i see
<wingo>and whose byte values manage to correspond to codepoints i think? not sure.
<civodul>what about: (or (false-if-exception (utf8->string file)) (raw-latin1->string file))
<wingo>the other is to do what python does, which is to map invalid bytes to a private unicode codepoint range
<wingo>civodul: if you do that, then how do you know how to turn that string back into bytes?
<civodul>right, good point
<civodul>so maybe instead of introducing a fluid and API, we should follow Python or Emacs, after all
<wingo>or we could do what racket does, which is to have a disjoint type for file names :)
<wingo>afaiu anyway
<civodul>and a disjoint type for env vars!
<civodul>and for command-line args!
<wingo>i think the python sol'n would be easiest, incidentally. i don't know if it covers all use cases tho
<wingo>basically we would implement it as a new substitution strategy
<wingo>i think anyway :)
<civodul>there'd still be the problem that one would need to have locale data installed just to be able to convert strings
<wingo>civodul: what do you mean by that?
<civodul>wingo: if we do the Python thing without introducing a new fluid, then users would still need to do (setlocale LC_CTYPE "something") to make sure file names are decoded according to the encoding of "something"
<wingo>do they?
<civodul>currently yes
<wingo>default is ascii; bytes 128-255 would get encoded as reserved unicode codepoints
<civodul>default is locale encoding, no?
<wingo>depends i guess but yeah
<wingo>GUILE_INSTALL_LOCALE and all that
<wingo>anyway with python's strategy for whatever locale/default encoding the user has, it just handles undecodable bytes as special unicode codepoints
<wingo>and reverses that transformation when going back to byte streams (assuming current locale/default encoding is same when going to byte string as when coming from byte string)
<handsome_pirate>Hey, y'all, when doing a build with guile, what is the search path?
<handsome_pirate>I keep failing with:
<handsome_pirate>ice-9/boot-9.scm:757:25: In procedure dispatch-exception:
<handsome_pirate>ice-9/boot-9.scm:757:25: no code for module (rx irregex)
<handsome_pirate>or, specifically:
<handsome_pirate>rpm -ql irregex
<handsome_pirate>(The source of the irregex rpm is me, so it may be that I'm screwing up there)
<spk121>guile -c "(write %load-path)" will tell you what Guile thinks its load path is
<spk121>Oh, I see it. (rx irregex) should be in /usr/share/guile/site/2.2/rx/irregex.scm
<spk121>you forgot an rx subdirectory
<spk121>handsome_pirate: ^^
<handsome_pirate>spk121: oh
<handsome_pirate>spk121: thanks
<handsome_pirate>spk121: so
<handsome_pirate>rpm -ql irregex
<handsome_pirate>same error
<spk121>handsome_pirate: is this Alex Shinn's Irregex?
<handsome_pirate>spk121: yes
<spk121>handsome_pirate: there seems to be some comment at the top of irregex/irregex-guile.scm about the weird way he wants files to be installed. But, otherwise, I don't know what the problem is.
<handsome_pirate>spk121: I missed that, heh
<handsome_pirate>spk121: yeah, that seems to have got it, thanks!