IRC channel logs

2023-08-14.log

back to list of logs

<rlb>OK, so for anyone interested in my UTF-8 work: https://codeberg.org/rlb/guile-utf8-tmp/src/branch/utf8/README-utf8-conversion That branch should also build and pass all the tests, and it's up to date with current main. As mentioned in the README, it's also not quite finished, but is, I think ready for first impressions.
<rlb>wingo civodul mwette ^
<rlb>I put it there for now, but I'm happy to move it elsewhere if there are any notable preferences.
<rlb>wingo: and I may well have been a bit too liberal with unrelated code changes. I'm generally happy to back off :) (e.g. I did use a good bit of defer declaration until closer to use, and a lot more const).
<rlb>For the moment, I'd really just like to know if this seems good enough to continue to pursue, and isn't headed too far off into the weeds...
<rlb>ACTION has possibly done too much utf-8 lately, wanders off for a bit :)
<rlb>Oh, and it'd be obvious from the diff, but for anyone wanting to start testing it against external code, the strings.h *internal* API has changed a lot, but the intention is that code that sticks to the public API shouldn't require changes.
<rlb>You'll also need to rebuild from scratch with this branch (say via make clean). It changes the stringbuf byte-code layout, so you can't just switch back and forth between main and this branch and expect to have nice things.
<rlb>wingo civodul: And I should also mention that barring substantial objections, I was planning to continue rebasing that branch for a bit, i.e. I still have a bunch of FIXMEs in a file here that I need to review and incorporate -- I imagined this mostly as a preview branch, so I can hopefully find out if what I'm doing is remotely in the right direction.
<mwette>rlb: thanks. I read through the readme. Now I see 121 commits. I like the (ascii|utf-8) and read-only approach. I'm curious how the C i/o worksout.
<rlb>...depending on what you mean, I'd assume it should (is?) up to the port to handle buffering between write-char and the eventual bulk byte writes (when buffered).
<rlb>i.e. assume we already have something like java/python's Buffered(Reader|Writer), etc., but haven't looked at ports more wholistically yet -- only changed what I had to change on the C side.
<rebiw>anyone familiar with doc-snarf?. I'm not sure as to how to generate an html website or info manual out of the guile source files.
<rebiw>and "guile-tools doc-snarf" seems to completely ignore the docstrings.
<ArneBab>This is my current plan for a tutorial I want to create — most texts for the points are already written in handwriting. Do you see something that’s missing? https://rollenspiel.social/system/media_attachments/files/110/884/116/063/879/834/original/04c5b371f9463743.png
<graywolf>Hey :) I want to apply a list of procedures to an object, currently I have (define (x y . z) (fold (lambda (a b) (a b)) y z)). Is there a more elegant way? (fold apply y z) does not work (and now I understand why), is there anything else?
<Arsen>(for-each apply y z) perhaps?
<graywolf>I do care abount the return value though... Basically (x 1 a b c) should be the same as (c (b (a 1))). My code does work, but the (lambda (a b) (a b)) seems ugly, so I am curious it there is more elegant way. If these is none, so be it.
<Arsen>oh, you'd like to compose the list of functions together?
<Arsen>try simply ((apply compose LST) value)
<Arsen>((apply compose (list 1+ 1+)) 2)
<chrislck>((apply compose (reverse z)) y)
<chrislck>the fold is probably the fastest
<ArneBab>civodul: I finally got the SRFI-119 patch finished. I’d be happy if you could check the changes! To simplify the review I created both a new squashed patch and added a second email with commits for the changes.
<ArneBab>civodul: thank you again for the review you did already!
<civodul>ArneBab: hi! this is on guile-devel, right?
<ArneBab>civodul: yes
<civodul>awesome; i'll try to provide feedback by the end of the week
<ArneBab>Thank you!