IRC channel logs
2025-12-04.log
back to list of logs
<rlb>mwette: oh, I assumed that was a joke :) <mwette>Seems to bug some folks due to the go conflict, but I don't see a problem. I was thinking about it; .wo seemed a fun solution. <rlb>Yeah, I'd think the bar should be fairly high to change it, and of course only on an X/Y release. <rlb>So far I don't know of a good reason --- I've seen more confusion from the debian packaging automation when it's confused wrt warnings about the fact that it's ELF format, but not a normal shared library :) <rlb>extension hasn't been a problem as yet <rlb>I wonder what file thinks... <rlb>yeah, file just thinks it's ELF <mwette>Agree. I use `objdump -h boot-9.go | grep guile' <daviid>sneek: later tell tohoyn your client main procedure does not check nor sets the -d --debugg paramemter .. please update and re-paste, tx <daviid>sneek: later tell tohoyn the client main code is a total mess,pease out-source the making of the d-bus 'things' in a procedure, then call receive (i-subcr result-1 result-2( (my-d-bus-maker ...) <daviid>sneek: later tell tohoyn please us dimfi, not display ... when using dimfi, for the proceure/method/signal-cb top dimfi call, do not indent ... see g-golf core examples, only indent the args ... also see hoew g-golf core presents the in args and the reuslt(s) <daviid>sneek: later tell tohoyn you should use guile ac/d-bus, this 'gnome' d-bus layer is a total disaster - I wonder why you said that you need 'sync' inter process communication, it seems to me the exact opposite of what (all) interprocess communication layer would want (?) also, why not 'ping' the ac/d-bus author an dsask they provide sync com ... (?) <rlb>Vaguely wondering if I do happen to get noncharacters support working, could it even be plausible to make that the default (even) in a Z release --- I suppose a counterargument would be that someone out there might be relying on the current corruption, i.e. their code is somehow fine with and/or expects the question mark replacements (likely?). For everyone else, things might just start working right in more cases. <rlb>(I'm going to convert compile.scm to utf-8 so lintian will stop complaining at me.) <rlb>dpk: I just realized I've been wasting my time with iconv(3) :/ And I believe we're going to need some other library in order to implement noncharacters because iconv only lets you handle undecodable bytes on some platforms -- e.g. for freebsd, musl, solaris, and maybe others, there's no way to make it strict; it always just replaces undecodable sequences with either ? or * and moves along. iirc libunistring has some similar problems, <rlb>but it's less important since it's not general enough in the first place. <rlb>(at least if I read the manpage correctly) <rlb>netbsd too apparently --- suppose I should double-check, make sure the manpage isn't stale... <rlb>That's...unfortunate. <rlb>I wonder if it's feasible to just require GNU iconv (either unconditionally, or only if you want noncharacters support) -- the automake iconv macro makes it sound like it might already try to handle that, i.e. preferring GNU iconv when it's available. <dpk>rlb: you only need to support noncharacter error handling for UTF-8 on Linux and UTF-16LE on Windows, no? <dpk>Hoot might have some other special needs <dpk>i should look at the Python docs on how it guesses an encoding for OS strings again … <sneek>tohoyn, you have 4 messages! <sneek>tohoyn, daviid says: your client main procedure does not check nor sets the -d --debugg paramemter .. please update and re-paste, tx <sneek>tohoyn, daviid says: the client main code is a total mess,pease out-source the making of the d-bus 'things' in a procedure, then call receive (i-subcr result-1 result-2( (my-d-bus-maker ...) <sneek>tohoyn, daviid says: please us dimfi, not display ... when using dimfi, for the proceure/method/signal-cb top dimfi call, do not indent ... see g-golf core examples, only indent the args ... also see hoew g-golf core presents the in args and the reuslt(s) <sneek>tohoyn, daviid says: you should use guile ac/d-bus, this 'gnome' d-bus layer is a total disaster - I wonder why you said that you need 'sync' inter process communication, it seems to me the exact opposite of what (all) interprocess communication layer would want (?) also, why not 'ping' the ac/d-bus author an dsask they provide sync com ... (?) <rlb>dpk: no, I think we need to handle it for "all" encodings, i.e. if you run guile with a shift-jis locale, we have to be able to handle every incoming byte? <rlb>i.e. the locale could be anything, and the paths in the filesystem anything else, etc. <rlb>I *think* we need a lib that works the way gnu iconv(3) does --- posix is too liberal there. <rlb>(but I may be missing something) <rlb>Offhand, I'd guess that (c)python may handle things themselves, but haven't looked. <rlb>Also, while poking around my estimate of the work increased again -- i.e. it's not clear exactly what the required semantics of some of the related ports.c and then suspendable-ports functions are... <rlb>(Will/would just take time to understand better.) <tohoyn>rlb: I suppose you participate in Guile releases. What do you think about the write-struct/read-struct patch I sent to guile-devel last week? <dsmith>tohoyn, Would be good to also provide a test case <wehlutyk>does anyone have hints for exploring guile-bytestructures? <wehlutyk>I'm failing to get the example "linked-uint8-list" to work <wehlutyk>the (delay ...) call seems to make bs:pointer a 0x0 pointer <wehlutyk>I tried out for several days now, and I still can't get a working example of a list bytestructure <wehlutyk>(a list that can grow, not with pre-defined length when defined) <lechner>mwette / which extension would be better than .go? <wehlutyk> (bs:pointer (delay (bs:struct `((head ,uint8) <wehlutyk>I miss something there, as the pointer results as a null-pointer <mwette>lechner: I think .go is fine, actually. If it has to go, then .wo. <lechner>wehlutyk / i haven't used bytestructures in a while but can warmly recommend mwette's CDATA. dthompson may have something also <mwette>wehlutyk: that doesn't look right offhand. lemme think ... <lechner>wehlutyk / what's your use case if you don't mind me asking? <wehlutyk>using chickadee for a guile-based DynamicLand (yes still this, for those who've helped me so far!) <wehlutyk>so I'd just like to send some info through a socket <wehlutyk>but I'm unable to send a list of an unpredicted length <mwette>wehlutyk: how about (define linked-int8-list (bs:struct `((head ,uint8) (tail ,(bs:pointer (delay linked-int8-list)))))) <wehlutyk>I have to go get dinner ready, but I'll be back later! <dsmith>.go -> .Go But sad for those with less capable file systems <lechner>dsmith Hi, / did I get you confused with dthompson in my earlier message about bytevector alternatives? <dsmith>lechner, Nope. Playing the bikeshedding game for a .go replacement <lechner>dsmith / okay, i didn't expect to look like an idiot quite so fast. i was trying a pun, but apparently without success <dsmith>But then again, naming things is one of the two hard problems... <lechner>is that the joke that ends with a third point on numbering? <identity>initially there were only two hard things in computer science, cache invalidation and naming things. now there are four, cache invalidation, naming things and off-by-one errors <dsmith>lechner, Yes, the other being cache invalidation and off-by-one errors.. <identity>lechner: the quote usually goes «There are only two hard things in Computer Science; cache invalidation and naming things», and sometimes «…cache invalidation and naming things and one-off errors», maybe «…cache invalidation and naming things and one-off errors and cache invalidation»; i used «four» to string them together <lechner>guile actually makes off-by-one errors less likely, i've found, because ends are often specified exclusively, i.e. not counting the end element <lechner>dthompson / i think that means you also like to start a count with zero <dthompson>0 is the 1 of computer science, I always say (I don't say this) <mwette>I love it, but an index is not a name. I've been burned by (non CS) folks assuming WIDGET1 is at index 1. <lechner>yeah, it doesn't work for everyone. for instance, i doubt any president would like to fly in "Air Force Zero" <dsmith>Lets say you are laying out tiles on a floor. How many inches away from the wall is the 1st tile? Yes, 0. So thing 1 is at 0 <identity>programming was a mess before zero was invented <old>dsmith: actualy 1/8 inch <old>need to put a gap between the tile and the wall to allow for expansion of the tile <old>and you cover the gap with crown <ieure>was it your crowning achievement <sneek>I've been faithfully serving for one month and 25 days <sneek>This system has been up 7 weeks, 6 days, 21 hours, 39 minutes