IRC channel logs
2024-11-27.log
back to list of logs
<dthompson>cow_2001: go for it. I don't think I'd want to include it in haunt itself, though. but it's easy to add custom readers. <cow_2001>dthompson: i just looked it up. there is already one <daviid>i (just now) fixed a bug in g-golf, in short, i was calling string-length, but needed to call string-utf8-length, fine - but this fix might not always work, as i am not an expert wrt string encoding and conversion, i wonder if some experet here could give me some hints, let me explain what i have, what gi libs expect, and ask how to better check/fix all this <daviid>gi libs (always) expect utf8 strings - as it happens, i use en_US.UTF-8, so everything always worked fine 'for me', except for the above that i now fixed - but i think i ned more attention, as g-golf calls string->pointer and pointer->string, but does not check if the user encoding is utf8 based, now i wonder: (1) if g-golf should check and warn users at start-up if they do not use a utf8 encoding; (2) assuming yest to the former, what <daviid>is the best way to check, any one has a code snipset i could snarf, thanks <rlb>what is the source of the arguments to string->pointer and pointer->string? <rlb>For string->pointer, if you need utf8 for the target (glibs?), then (as you may already be doing), you should always specify that as the second argument, i.e don't rely on the current locale. <rlb>...for pointer->string, the encoding you should specify depends on where the string came from, and what the actual encoding is. <daviid>rlb: ok, if i do this, and the user as a diff encoding, will this still work? <rlb>i.e. if it comes from the "system", then maybe the default is fine (fsvo fine), but otherwise, "you have to know"./ <rlb>It always depends on "where the bytes came from", i.e. you have to know what the encoding was. <daviid>in g-golf, pointer->string always comes from a gi lib, so it is always utf8 <rlb>OK, so there you just always say "utf8". <rlb>i.e. you *do not* want the default encoding. <daviid>ok, thanks - now, will this work if a user has a diff encoding? or should i check and warn a g-golf start-up <rlb>will which bit work? <rlb>If you're always/only talking to glibs, and they've mandated utf-8, then you should just need to always give the second utf8 argument to both functions. <rlb>you don't care about the user encoding in that case. <rlb>(if I understand the situation correctly) <daviid>say a user has an utf16 encoding, and use g-golf, and i fix all string->pointer pointer->string to pass "utf8", will guile properly 'convert'? <rlb>But if you're getting raw bytes (a bytevector) "from the user" or "from the system", then you have to care. <daviid>rlb: so, iiuc, at g-golf start-up (init), i should check the user encoding and raises an error if they are not using a utf8 encoding (?), is my question <rlb>guile always (currently) uses either latin-1 or utf-32 internally -- so by the time you have a guile string, any conversions have already happened. <rlb>You only need to care about cases where you're being handed bytes that *you* need to conver to a guile string, and it sounds like for your cases, you're set, because you always know what the encoding of those bytes is (utf8). <rlb>No, the user can have whatever encoding they like. <rlb>And guile already/always handles converting that to latin-1 or utf-32 internally, but you don't care about that either. <daviid>ok, many thanks - i'll fix all string->pointer and pointer->string calls then <rlb>i.e. guile assumes that the locale is correct and converts from whatever the user's encoding is to a guile string (happens to use latin-1/utf-32 internally now) <rlb>(this is actually not quite sufficient, but that's a problem for another day, and doesn't affect your situation) <daviid>*fix g-golf to call string->pointer and pointer->string also pasing the "utf8" encoding and that will fix 'everything' wrt to g-golf and gi ... many thanks for your advices <rlb>I think that's right -- you only care about guile strings wrt the glibs, and they only speak utf8. However a given guile string that you're handed was created in the first place (say via conversion from the user) isn't your problem. <rlb>s/a given/some other/ <lechner>Hi, what's the relationship between 'read' and 'eval-string' please? Is (read A) the same as (eval-string (quote A)) ? <lechner>actually, i meant (with-input-from-string A (lambda _ (read)) or so <lechner>and on the other side that would be (eval-string (string-append "(quote " A ")")) <rlb>lechner: roughly speaking, read parses the input and produces data (a data structure); eval-string does that repeatedly until "end of string", executing (evaluating) each data structure (form) as scheme code, and then it returns the result of evaluating the last form. <lechner>Hi, is there a more concise way to parse an S-exp from a string than (call-with-input-string str (lambda (port) (read port))) <janneke>does guile (scheme) have a shorthands for (inexact->exact (floor ...)) etc? <lilyp>janneke: you can compose your own :) <dthompson>it's so trivial it wouldn't make much sense for guile to add it. better to focus on the primitives. <dthompson>already you'd want at least 3 variants: floor, ceiling, and truncate <mwette>dthompson: you mean in C, or Scheme as well? Would be nice to have frexp also. Currently I have to use log to get ahold of the exponent. That can't be very efficient. <dthompson>mwette: thought we were talking about scheme <mwette>I meant libguile/ versus modules/ <shawnw>SRFI-141 ported to Guile would give you a bunch of variations of those.