IRC channel logs
2025-06-27.log
back to list of logs
<lechner>humm / yeah, thanks for pointing that out. i couldn't think it through <Arsen>guix did already so i suppose one might as well <dsmith>ts the benefit or motivation to move to codeberg? <wingo>dsmith: easier review of patches and issues <adamhume10>as well as encouraging more guix users to review and contribute, i think <adamhume10>If more people helped review patches, it would be easier for core maintainers to merge them <z572`>I like the cross-references on codeberg <z572`>On the mailing list, it's totally unclear <civodul>z572`: same for me, it seems anecdotal but it makes a big difference <wingo>also it will be easier to manage contributors / permissions, to not have to muck with savannah <Arsen>we're considering it for gentoo, and I'm considering using it full time <wingo>i love it when a plan comes together <wingo>civodul: do you want to draft someone to do the migration? :) <z572`>i think should create guile organization first? <z572`>i think is import guile repo <z572`>And I think we may need to keep using two repositories for a while to see if using codeberg can attract more people to contribute and review <wingo>need to upload some tags from gnu.org's repo there, for the moment there are just the branches for main and wip-whippet <Arsen>wingo: you can do a git clone --mirror and a git push --mirror from the cloned repo <Arsen>or actually, they have an importer IIRC <Arsen>you can just point it to the savane clone URL <wingo>disabled issues for the time being <wingo>Arsen: ah that is probably a good idea <z572`>We may also need to mention codeberg's repository somewhere in the repo and explain the situation <wingo>well, for the moment things can be experimental <wingo>i agree of course in the medium term <wingo>but the migration can take some time <civodul>wingo: “draft” is maybe not the right term, but sure :-) <civodul>so which one is the current repo? :-) <wingo>well. let me finish this mirror clone and push, so that codeberg's repo is the same <wingo>ACTION waiting on slow savannah git <wingo>while i wait, i am writing the big honkin' scm_trace_object function <civodul>wingo: i’ve been meaning to announce a migration plan for Fibers for a while too! <Arsen>guile/guile looks more complete now :) <dthompson>civodul: like moving fibers to codeberg or merging fibers into guile? :) <wingo>civodul: there is a "guile" team now and you are admin, feel free to make guile/fibers <wingo>and also to do whatever else you like! <noe>and thanks for migrating! <noe>very fast, well played! <noe>i’m still stuck at building stage0 ;( <old>move to codeberg yes please <janneke>not as high-brow as ubuntu's bug #1 but maybe that's for the best <janneke>"[guile] scheme is still not the default/preferred language for the web" or something ;) <rlb>wingo: is the mirroring ongoing, or should we just push to both? <dthompson>janneke: heh missed opportunity I suppose :) <janneke>having json builtin is also nice, i guess ;) <rlb>wingo civodul: do we have a current C minimum for 3.2 (formally our roughly)? <civodul>rlb: it may be older than C99 on ‘main’ <civodul>worth upgrading, but probably not on ‘main’ <rlb>OK, thanks (for that generic, looks like we might need c11). <rlb>oh, maybe it's more complicated than that... <omentic>heyo! is there a nice way to simulate racket's call-in-continuation w/o thunkifying everything? <omentic>the guile continuation primitives seem very nice, by the way <omentic>i thought guile didn't implement srfi 226? or at least it's not on the support table. is there a library somewhere? <identity>omentic: i think it does not, but you might want to skim the document itself and the sample implementation <cow_2001>dthompson: i've asked on #lispgames. how do i draw stuff for prototyping, specifically on guile? i have either chickadee or guile-opengl, but guile-opengl does not have a guide, just a reference manual. chickadee then? <cow_2001>there's guile-cairo, too, but that's not live <cow_2001>spritely hoot needs a lot of time to recompile each change <dthompson>cow_2001: chickadee would be the easiest for stuff like drawing sprites <omentic>identity: unfortunately the sample implementation implements it in terms of a continuation-resume-k... which is undefined <omentic>(or rather, call-in-continuation -> continuation-resume-k -> continuation-info-resume-k) <dthompson>we'll be working on the repl-driven development story for hoot in the future, so you can do more stuff without recompiling <dthompson>chickadee has early support for vector graphics but it's not particularly mature <adamhume>omentic: I think we can't do `call-in-continuation` without thunkify. you can simulate it, but can't use it directly. This is the curse of control operators: Each group of control operators can simulate each other, but it can only be simulated by abandoning the use of the original one. <adamhume>I guess this was the motivation for MNW to propose SRFI-226, to specify the semantics of continuations, exceptions, dynamic environments, and threads in a grand unified way. <omentic>adamhume: yeah, that's my impression :c <omentic>i do wonder if i could successfully make the argument for including call-in-continuation as a builtin primitive... <omentic>but i suppose that requires finishing the project it'd be useful for first (at the very least) <omentic>(i'm writing a little effect handlers library. call-in-continuation is required for "bidirectional effects". but the rest of the library can be built w/o it) <adamhume>ACTION googling for "bidirectional effects" <adamhume>I can imagine some kind of controlled `call-in-continuation`: We can combine the `call-with-prompt` and thunkify hack. As the prompt tag is inforgable, only the client code holds proper prompt tag can abort to the thunkify hack part. <omentic>adamhume: yeah the effekt language has a good overview of bidirectional effects <omentic>(didn't see anything after that b/c my internet cut out, sorry) <adamhume>I can imagine some kind of controlled `call-in-continuation`: We can combine the and thunkify hack. As the prompt tag is unforgeable, only the client code holds proper prompt tag can abort to the thunkify hack part. <cow_2001>sha256 a4013d8f3204028dd29a98dd578cdf5c7995b8e9592a513cee7be42f157637e1 of that file <cow_2001>dthompson: maybe you can also flow the text again because the lines are getting short <z572``>dthompson: can we see chickadee on the codeberg? <wingo>rlb: let's call it guile 4.0, it has been long enough, and if it includes a new gc it is worth the major bump <wingo>rlb: as far as c standards, i think c11 should be the minimum. otherwise it's too hard to do parallelism <rlb>OK -- and wrt 4.0, I'd been assuming that for your branch, though I might eventually end up needing a fix for 3.x as well, but of course it doesn't have to be yours. <rlb>And I think we should also have at least a 3.0.11 release to fix 32-bit. <dthompson>alas z572`` is gone but I don't think I'll move my personal projects to codeberg. I like having them on my git server. <dthompson>the big missing piece is issues/pull requests, though. <dthompson>codeberg uses forgejo which is a fork of gitea <dthompson>neither forgejo nor gitea is suitable for self-hosting <wingo>i would like to branch main into stable-3.0 and then merge wip-whippet into main via a series of pull requests <wingo>no, stable-3.0; the branch for the 3.0 series, and main becomes the next series <rlb>sorry, I got ahead of myself version-wise :) <rlb>I'll have to assume it may only be my priority (#include "broken-record.h"), but *if* there's a chance we might want to allow syscall bytevectors, i.e. for program-arguments, getenv, delete-file..., I'd *really* like to either do that in a way that's backward compatible (of course), or get whatever breaking changes we'll need into 4.0. (And again, I'm *happy* to try to do the work if we can figure out what we want.) <rlb>ACTION would like to be able to consider guile for cases where he's had to reject it <rlb>writing any system-ish tool, i.e. that has to manipulate arbitrary fs paths (like cp, tar, rsync, ls, find, etc.) <rlb>guile can't handle unencodable system data, i.e. if the locale is utf-8, then an argument that's not encodable as utf-8 will be corrupted in program-arguments <rlb>or it produces an error? (I forget which by default) <veqq>Oh, that's really painful. <rlb>Eventually we may do something fancy with encodings (there's a related r7rs discussion), but it might still be nice to support bytevectors for situations where you know that's what you want. <veqq>What's the relationship between guile and r7rs these days? I'm sort of at the point of believing scheme is just a family and interoperatability isn't possible (and is tedious to attempt). I mean, adding r7rs support as a flag is easy, but <rlb>wingo was just discussing some other places where the docs might well be "refreshed" <veqq>I mean, as the community and sort of maintainers, how much do you even care about the standardization process? <veqq>rlb: oh, i see. just passively support, but now going its own way. got it. <wingo>guile's r7rs implementation should be fine. it is not a main focus however. most people that write scheme programs tend to target one implementation. targetting a standard is possible but not the easiest thing to do <wingo>regarding c11, c11 also has _Alignas, which is nice