IRC channel logs

<encryptedwhisper>yes, I also am using rev irc

<dpk>ACTION posts the following bug report here in the hope that someone will properly report it for her, since she has no patience for dealing with debbugs:

<dpk>since Guile switched its subprocess stuff from using fork+exec to using posix_spawn, it’s broken on Darwin. (installed via Nix)

<dpk>specifically, all processes immediately appear to exit with status code 127

<civodul>dpk: hi! what version of Guile are you using?

<civodul>(oh, and hi #spritely!!)

<dpk>(define pid (spawn "/bin/echo" '("echo" "hello world"))) (define exit-status (cdr (waitpid pid)) (status:exit-val exit-status) ;;=> 127, always, and ‘hello world’ is not echoed

<civodul>i believe this was fixed a while back: https://issues.guix.gnu.org/61095

<civodul>unfortunately, no new release since

<dpk>civodul: 3.0.9, with the JIT enabled

<dpk>happens with any process, with or without search-path? enabled

<dpk>oh okay

<civodul>if you could try current ‘main’, that’d be great

<dpk>it would be very nice to get this fixed because it affects basically every way to safely spawn a subprocess in Guile in a multi-threaded context

<civodul>or the Brew “tap” (i think that’s what it’s called) for Guile is likely to have the patch already

<dpk>and as a result, the R7RS Large specification HTML render is stuck on Guile 3.0.7 which the nix file has to build from source

<dpk>yeah i don’t use brew

<civodul>ah yes, sorry

<dpk>well, i have a VM of a version of Mac OS with brew installed, in case there’s something i really need that depends on it (mainly the script i use to get new versions of Emacs)

<dthompson>civodul: yeah I think a guile-next package was added to guile-homebrew recently to mirror guix and allow for packaging guile-hoot

<dpk> https://issues.guix.gnu.org/61095 page is not loading for me

<dthompson>dpk: what do you use instead of brew?

<dpk>Nix

<dthompson>ah right

<dthompson>well a guile-next package could easily be added there :)

<dpk>curl -v hangs after successfully connecting and sending the request

<civodul> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61095

<civodul>dpk: and here’s a shorter patch you can apply in Nixpkgs: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/guile-hurd-posix-spawn.patch

<dpk>(honestly, one of the lesser reasons Guile should get shot of its connection to GNU is to use an issue tracker that isn’t quite as antediluvian as debbugs)

<civodul>the choice of Debbugs was made many years ago, primarily because it was convenient for those hacking on Guile

<dpk>i can’t build Guile HEAD from Git on my Darwin box, sorry

<civodul>(i still like the comfort of debbugs.el, though i understand not everybody does)

<dpk>i’ve tried before

<dpk>another reason to get shot of GNU: no institutional pressure to use autoconf

<civodul>there’s no such pressure in reality :-)

<dpk>for my hacking on Guile’s psyntax i had to spin up a Linux VM to make it work

<civodul>dpk: the patch i sent above can be applied on top of 3.0.9, if you want

<dpk>(and the spawn bug doesn’t happen on Linux)

<civodul>it’s minimal, that’s why i said it could go to Nixpkgs

<dthompson>autoconf isn't exactly good... but I know of nothing better

<dpk>dthompson: you don’t need it!

<dthompson>there are a number of tasks that would become very difficult without it

<dpk>the damn thing spends half its time checking for system calls that were there in like Unix Version 4!

<dthompson>that stuff is silly

<dpk>‘checking for setuid ... yes’ no fucking shit, my box supports setuid(2)!

<dpk>that’s crap

<dpk>Git manages to run cross-platform perfectly well without autoconf

<dthompson>for a guile project, you wouldn't have any of that

<dthompson>you might check for some guile modules to ensure the necessary dependencies are there

<dpk>of course, some Stockholm syndrome sufferers came along and added a configure script anyway, but you don’t need to run it at all

<dpk>you can just run ‘make’ straight away

<dthompson>but then autoconf helps with things like generating scripts based on build-time inputs

<dpk>if only there were a build system with dependency tracking that could generate such scripts

<dthompson>there's a lot of things we'd have to do manually that autoconf/automake take care of. I wish it could be modernized and use literally any other language for the config.

<dpk>would Guile accept a patch to remove autoconf?

<dpk>i’m not sure i know the codebase well enough to do it, but i’m convinced it both can and should be done

<dpk>civodul: since you’re a Nixpkgs maintainer for the Guile package and the patch fixes a platform-specific bug, could you add it to the nixpkgs build for Guile?

<civodul>dpk: i used to be a Nixpkgs maintainer (10 years ago) :-)

<dpk>you’re still listed as a maintainer https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/guile/3.0.nix#L166

<civodul>ok, but it’s a lie ;-)

<civodul>i should have cleaned this up but that was a busy period full of unknowns, as you can imagine

<dpk>civodul: i don’t see how that patch will work without regenerating the configure script, since it touches configure.ac. which is the exact problem i have when building Guile from source in the first place

<civodul>dpk: the patch above touches only ‘libguile/posix.c’

<civodul>to be clear, this one: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/guile-hurd-posix-spawn.patch

<civodul>(there’s “hurd” in the name but i believe that’s the same problem on macOS)

<dpk>okay, trying applying that patch

<dpk>(without the other two in the thread)

<dpk>‘checking for uname... yes’ ‘checking for waitpid... yes’ very valuable use of my time and of valuable energy here

<dpk>the global climate definitely appreciates the extra CO2 resulting from the electricity generated to do these checks

<civodul>i understand your griefs (i really do!) but i think we can avoid animosity here

<dthompson>yeah, agreed.

<dpk>okay, yes, that patch fixes the issue

<dpk>made a PR for it https://github.com/NixOS/nixpkgs/pull/272047

<cwebber>hi civodul !

<cwebber>and also argh posix spawn

<isaneran>what did you call me

<cwebber>isaneran: lol

<cwebber>I'm a bit annoyed by "spawn" making it suddenly into guile's namespace recently

<cwebber>I had written an email suggesting that spawn should have to be imported via eg (ice-9 sspawn)

<cwebber>er, (ice-9 spawn)

<isaneran>oh is it included in the default environment?

<cwebber>it got included in the default environment *recently*

<isaneran>oh damn it is

<cwebber>and to my annoyance, after Goblins already existed and also used spawn as a core operator

<jfred>D:

<isaneran>if you do (define posix-spawn spawn) (unsetenv spawn) will it do the right thing?

<dpk>it always confuses me that Guile modules don’t start from an empty namespace by default like RnRS libraries do

<dpk>(we get people showing up in #scheme occasionally trying to do R6RS or R7RS stuff in Guile and getting weird errors about name conflicts)

<cwebber>jfred: did I remember correctly that you said you're using irccloud?

<jfred>Yup

<cwebber>how do you like it?

<isaneran`>sorry got yeeted and deleted by café wifi

<dpk>IRCCloud is what i use as well. it’s fine if you’re fine with a browser IRC client

<jfred>It's honestly been pretty nice, I just don't like that it's proprietary and centralized

<isaneran`>with ice

<jfred>but if you can look past those, functionally it's very slick

<isaneran>I think there was a free software very similar looking web irc client

<isaneran>the lounge

<jfred>On the `spawn` thing, something like `goblins:spawn` with `#:prefix goblins:` wouldn't be the worst thing in the world, but having to do `goblins:<-` would get old fast. I wish Guile had an equivalent of Python's import syntax so you could do something like `from goblins import <-`

<isaneran> https://thelounge.chat/

<isaneran>idk it feels a bit unfair of guile to introduce that kind of breaking change maybe

<dthompson>isaneran: oh tsyesika showed me the lounge recently

<jfred>isaneran: I used to use The Lounge and that was also pretty nice, though it didn't have native apps for mobile platforms. It's got a web app manifest which gets you most of the way there though. (I was using iOS at the time though and mobile Safari didn't support web push then; I think it might now)

<dthompson>it's not particularly self-hostable by spritely's criteria, though.

<jfred>I admittedly have gotten tired of having to manage my own infra in some cases, since that's what I do in my day job too haha

<jfred>Sandstorm is the one thing I run that doesn't feel like a chore to keep going

<isaneran>darude?

<jfred> https://sandstorm.io/ - also very capability-based :)

<isaneran>oo

<isaneran>will take a look

<isaneran>brb

<dthompson>yeah you've gotta be careful what you self host, at work or at home.

<jfred>I've gotten nearly all my friends on Matrix over the years, and I do enjoy using it, but Synapse is a pain to host heh

<jfred>I put up with it for a ~permanent home for my chats with friends though. I've cycled through way too many chat platforms prior to that

<jackhill>ACTION is in the XMPP camp. Biboumi is a nice gateway to IRC from XMPP which then gives you mobile clients too.

<cwebber>xmpp is beautiful, except that they handle encryption not the write way

<jackhill>(I don't use it though, since I had pre-existing IRC setup).

<cwebber>I'm going to nerdsnipe jfred for a second

<cwebber>jfred: what if instead of omemo we did this

<cwebber><jfred-private-key>@jfredserver.org

<cwebber>and your username IS your private key

<cwebber>and then used the contact list as a petname system

<cwebber>no OMEMO "authenticating" a key step, which like PGP is kind of a failed model

<cwebber>UX wise

<jfred>but... the *private* key as the identifier? :P

<cwebber>yes!

<jackhill>I'm not jfred, but yes, petnames to help with key distribution/authentication sounds awesome

<cwebber>oops

<cwebber>shit

<cwebber>er

<cwebber>shoot

<cwebber>public key

<jfred>;)

<cwebber>I only got 4 hours of sleep last night

<cwebber>okay if you retcon my words

<cwebber><jfred-public-key>@jfredserver.org

<cwebber>and then xmpp already supports self-proclaimed names on top of that, and then the user can set a petname with the contact list

<cwebber>bam, a much more secure XMPP

<jfred>I do like that - still relies on the DNS, but not sure you'll get around that with XMPP

<cwebber>I mean you could host over tor onion services ;)

<cwebber>but yes

<jfred>This would work with static asymmetric keypairs, but I wonder if there's a single keypair per user in e.g. the signal protocol? I don't actually know enough about how that works

<cwebber>heya Bagel3000 !

<cwebber>welcome to #spritely

<Bagel3000>ACTION slides in just because Christine said this place was for the cool kids. :D

<Bagel3000>Hey!

<jackhill>current OMEMO has a different key per device (and not cross-signing that I'm aware of)

<cwebber>Bagel3000: :)

<cwebber>it could be that you have a different subkey per device, all signed with the same primary key, but I'm a little bit skeptical of this utility tbh

<jackhill>I would be inclined to come up with an key-identifier that could express write-to-these-three-of-jfred's-keys and use petnames to keep track. Bonus of making it easier to exclude some clients from super-secret messages for which I have not seen a UI to do in current clients

<jfred>I could be wrong but I think the signal protocol does this so it can ratchet through ephemeral message keys on each device

<pukkamustard>ACTION also feels hit by cwebber's xmpp nerdsnipe

<cwebber>pukkamustard: ;)

<jfred>cwebber: I'm not sure but I wonder if a user having multiple JIDs would work fine too - so <jfreds-public-key-for-cwebber>@jfredserver.org maybe? That might interact poorly with non-anonymous MUCs though :)

<cwebber>jfred: if you have an initial key, the clients should be able to negotiate a particular pairwise key I'd think

<jfred>Sure - unique identifiers per contact have similarly nice antispam properties as unique capabilities per contact though

<civodul>cwebber: re ‘spawn’, i plaid guilty!

<civodul>to my defense, (ice-9 spawn) was proposed in earlier versions of the patch

<civodul>but we ended up with the global namespace for some reason

<cwebber>civodul: *points finger and screams Invasion of the Body Snatchers style*

<dthompson>lol

<civodul>:-)

<civodul>it’s unfortunate, that’s for sure!

<cwebber>civodul: do you think it's too late to move it?

<cwebber>also nice to see you in #spritely :)

<civodul>cwebber: yeah, i wouldn’t want to break the contract we have with users in general

<civodul>dunno

<civodul>also because i know we’re using it in Guix and related code

<cwebber>what we've done is "override" the binding when you import goblins

<civodul>to me, more importantly, it shows that we need to rethink our processes for things like adding new bindings

<cwebber>it's not ideal though

<civodul>yeah #:replace

<cwebber>civodul: one path could be to move to (ice-9 spawn), then have the one in the default environment issue a deprecation warning

<cwebber>but admittedly

<cwebber>maybe this is too late

<cwebber>and too much to worry about at this point

<cwebber>but I agree re: adding new bindings

<dthompson>reducing what's in the default environment would be good

<cwebber>yes

<dthompson>too much stuff in there now

<dpk>civodul: it *looks* like that patch breaks a bunch of Nix packages. i’m building on x86_64-linux now to confirm

<civodul>dthompson: yeah, we’ve been discussing it since it first got into Guile, but nobody dared so far :-)

<cwebber>also, it's on our agenda to eventually work out the secure, ocap-safe subset of scheme and how to run it, including how to handle that with a module system

<cwebber>on the original spritely plan, that's called "Oaken"

<dpk> https://github.com/NixOS/nixpkgs/pull/272047#issuecomment-1838858277

<dthompson>civodul: yeah and this isn't the first time you've told me that ;)

<cwebber>I know we have ice-9 sandbox but there's more to do to make it work

<civodul>right

<cwebber> https://spritelyproject.org/#oaken

<cwebber>I know it was a little bit overwhelming but I am proud of how the "monster manual plan" from the original spritely website has held up

<cwebber>still useful to point to today

<civodul>oh yes

<cwebber>goblins of course is at the top, but questie, aurie, brux, fantasary have all been worked on with those names, and we at least refer to them as the project names internally. when we talk about the activitypub bridge, we still say "mandy". and even though pukkamustard's ERIS has provided the porta part of porta&bella, it's still useful to refer to those in terms of the abstract requirement

<cwebber>questie and aurie are no longer separate things though, both have been folded into goblins

<cwebber>questie is the time traveling distributed debugger dthompson wrote, and tsyesika is taking my old external prototype of aurie and making it a core part of goblins as we speak more or less

<jfred>ACTION will be super interested to see what aurie ends up looking like in guile-goblins :)

<cwebber>It's pretty cool jfred!

<jfred>persistence is one big thing my horton implementation is missing haha

<cwebber>Much much easier to use, integrated into corr

<cwebber>Core

<encryptedwhisper>nerrrrds :3

<chitochi>so many funny things to play with coming, thank you for that \o/

<chitochi>jfred: may i ask what is horton?

<cwebber> http://www.erights.org/elib/capability/horton/

<cwebber>and jfred can mention their specific stuff

<jfred>gotta run to a meeting but my implementation is here: https://gitlab.com/jfrederickson/guile-horton

<cwebber>described in MarkM's keynote at apconf 2019 https://conf.tube/w/g87k3yKzYwpGhtohvQdC3k

<cwebber>(ignore my legacy visual/naming appearance :P)

<chitochi>thank you for the links, let's read that!

<dthompson>I thought we were talking about tim hortons ;)

<chitochi>i need to adapt to irc not having these emojis reactions on message, not easy xD

<chitochi>cwebber: never heard legacy used that way before, i will keep this :p

<chitochi>a quick read on all this and it's really interesting! the conference is in my todolist \o/

<cwebber>Unfortunately not all traces of my legacy code can be eliminated. Glad the W3C folks were willing to fix my name on AP

<chitochi>good to know they are ok on this!

<dpk>bah, nixpkgs-review is slow on a tiny VPS. (i can just tell this is either going to run out of memory (again) or disk space)

<cwebber>Alas I knew this would be true transitioning in my mid-30s while having a productive career behind me. Too bad I didn't put all the pieces together a decade earlier. So it goes. Still proud of my old work tho

<dpk>cwebber: i have academic papers under my deadname. fortunately nobody will ever cite them ever again, but still 😖

<cwebber>dpk: Aw. 🫂 Yeah it's rough

<dpk>i keep meaning to make a publications page on my website asking people to at least just use the first initials only for those papers if they do cite them

<chitochi>the current internet model is not helping, i really think the model of spritely can help

<dpk>there will always be permanent records which cannot be changed once published; this is not a bad thing in itself

<dpk>on the contrary

<chitochi>yes i agree, but it's not easy to navigate :'(

<dpk>i have another paper (to appear a book which has been stuck in proposal hell for 18 months now :<) making a strong case for ensuring permanence in the digital era (in the specific context of scholarly lexicography, but it applies elsewhere)

<chitochi>that's really interesting :o

<dpk>ACTION sends the book editor an email gently enquiring about status

<dpk>(actually decentralization is a key part of the point i make there)

<chitochi>(if you are willing to elaborate a little on that point i am curious :o)

<dpk>you can read the pre-print if you like :-)

<chitochi>that would be perfect 👀

<cwebber> https://gitlab.com/spritely/guile-goblins/-/merge_requests/180

<cwebber>anyway, back to it

<dpk>the guile-goblins Nix build is broken on Darwin, btw

<dpk>(just discovered that today)

<dpk>let me see if i still have the logs

<cwebber>dpk: I don't use Nix but would love to hear that guile-goblins is working properly on it!