IRC channel logs
2023-06-05.log
back to list of logs
<spk121>I went from 'hey does guile-plotutils still build' to 'hey can I get CI/CD to work' to 'hey can I get CI/CD to make a Guile package for MinGW Pacman' to 'hey can I get Guile to build on MinGW at all' <spk121>This is why I never finish anything <mwette>spk121: I'm the same. Like three projects in parqllel all the time. <mwette>This weekend I started on yet another module for dealing w/ C data structure via bytevectors. <spk121>mwette: this one will be the best one yet <wingo>rlb: in 3.2 could we do only utf8 ? <wingo>rlb: also, regarding bits: depends on the type. for stringbufs i think the high bits are free, but there is probably some code in (language tree-il compile-cps) that assumes that its understanding of the kind of strings is exhaustive <civodul>rlb: (system base types) wants to know, too (mostly for debugging purposes) <dthompson>fantasary, wireworld, and super bloom all used guile. <dthompson>fantasary is a MUD-like online virtual world built with goblins. easy to build with guix and there's a guix pack provided. <rlb>wingo, civodul: thanks - think I found some of those expectations the hard way :) And I don't know about 3.2, but I'm back working on it in earnest, and it's going fairly well. The big question will be whether or not what I've done and how I've done it is plausible to a broader audience, or can be made so. <rlb>civodul: oh, and depending on what you were asking - in the current arrangement, all strings will be utf-8, though ascii-only strings have their own subtype (replacing latin-1). Also, the UTF-8 stringbuf variant (i.e. not ascii-only) are immutable and include a coarse grain character byte-offset index whose granularity/size scales with the length of the string (granularity meaning it indexes every N chars). <sneek>I've been serving for one month and 15 days <sneek>This system has been up 9 weeks, 2 days, 2 hours, 12 minutes <dsmith>rlb, Looking forward to your utf-8 changes. Are "foreign" strings going to be or can be separate? (Like OsString in Rust?) <wingo>lol, guile has (ice-9 lineio) that exports make-line-buffering-input-port; entirely unused; also (ice-9 buffered-input) exports make-line-buffered-input-port, a completely different thing <civodul>ACTION didn't know about this module <civodul>also, (ice-9 string-fun) has seen quite a few uses in Guix <civodul>only one of its bindings is documented <janneke>(ice-9 poe) could use an update too... <janneke>i believe instead guix rolls their own... <civodul>to me these files are leftovers from the 90s, so i'm always surprised to see them used :-) <civodul>string-fun predates srfi-14 for instance <rlb>dsmith: I haven't been doing anything there yet, and was considering that separate unless we think they have to go together. I think you may still be able to use the unpleasant trick of sneaking the data via latin-1, but now it'll be more expensive, i.e. no longer pass-through. And yeah, in the long run, I'd really like to see first-class support for binary "strings" in all the relevant functions. Not sure what I think that should <rlb>look like yet, though. <rlb>(A number of options...) <rlb>Suppose you could even just support bytevectors everywhere it matters, as long as we have reasonable apis for requesting//creating/manipulating/passing them. <rlb>e.g. python's hack is a hack -- you get bytes back based on the type of the argument in some cases, but that still only works if the relevant function has a plausible argument to abuse. e.g. what about say (fdopendir FD)? <rlb>(you get bytes back if the input path, for example is bytes, a "localized" (fsvo localized) string otherwise) <dthompson>I stumble across one every now and then when I go spelunking for something in guile's source <rlb>One thing I vaguely wondered about -- assuming we do migrate to utf-8, might there be any appetite for something like --with-pcre? I'd wondered because I thought it might be nice to have (when available) one standardized regex syntax/etc. as compared to whatever the platform's regex(7) does. <rlb>(Also wondered since I've already done the majority of the work, so it'd be pretty easy, I think.) <rlb>(wrt guile pcre support -- created it for other purposes already) <mwette>Is guile regex in all-scheme a desireable / doable goal? compile-time FSMs? I made a perl-like match-regexp syntax module a while ago that might be useful for that. <dsmith>One issue with teh current Guile regex is they are C strings. (so NUL delimited) <mirai>RhodiumToad: wdym? what should I be expecting then? <dsmith>Does guile have an srfi for that? <rlb>dsmith: is that an issue wrt null, i.e. as long as the rx syntax supports \0. I suspect pcre handles unicode null, but don't recall. <rlb>...also, whatever we do, I still might be inclined to want to have one option that works the way the majority expects (with rx strings of the "typical kind"), and for that option to also be one of the faster implementations. <rlb>Ideally we'd have solid support for both, i.e. more familiar rx strings, and a sexp-based approach. <rlb>But I was inclined to think that pcre does a lot of hard work for us, if it were suitable. <rlb>(But that's just a suspicion -- I become more familiar with it on the C side after an investigation to try to find something that seemed pretty solid to provide cross-platform, standardized syntax for lokke.) <mwette> Not sure how "modern" rx's work but [a-z] seems very ASCII centric, no? <rlb>I think pcre is fully unicode. <dsmith>rlb, Well, you can't use guile rx to search for \0 or have \0 in your data. Mostly not an issue I guess, but still a surprising limitatin <rlb>Though I think some of it may depend on the pcre compilation options. <rlb>You can if it's a unicode null, at least if the rx lib handles that. <rlb>And guile strings aren't necessarily null delimited, i.e. they're specified by length internally. <rlb>iirc the docs even say that nulls are allowed, but I suspect "woe unto you" if you try to use them in any given system call :) <dsmith>Ahh, yes, there is srfi-115. Not in guile though <rlb>Though they are *also* currently null terminated, with some fixmes relating to remaining (presumably important) internal functions that care. <rlb>somethingsomething_symbol, etc. iirc. <rlb>Hmm, that might be an important test to add if we don't have it -- i.e. can you round-trip arbitrary binary via latin-1. I'd assume so unless (would have to think about it) we do any automatic unicode normalization on the wide path -- if so I might need to "fix" that. <rlb>Otherwise the utf-8 conversion would strand us in the same place python 3 ended up for a while :/ <dsmith>Did python ever get fixed? I hear there are filenames that you just can't open (because not utf8). Segfaults or something. <RhodiumToad>mirai: unless I seriously misunderstand, with-syntax first evaluates the values, and then expects them to be syntax objects