IRC channel logs

<fossy>siraben: regarding binary.lisp, mes-m2 is scheme, not common lisp, so there are some largish changes that will have to be made

<fossy>and how do we replace lispy with mes-m2?

<siraben>fossy: yeah don't worry that it looks like common lisp, it was just easier to adapt the parser to accept something looking more like CL

<siraben>We don't need lispy and below anymore. What I'll do is rewrite binary.lisp to make it self-hosting, then rewrite it to make it Guile compatible, then another rewrite for mes-m2

<siraben>Actually... I'll rewrite lispy to make it self hosting (binary is the one that adds infix operators, which we don't want for lisp)

<OriansJ>siraben: sounds good. I'll work on getting vm.c running properly from the M2-Planet build

<siraben>Self-hosting and Guile compatible*

<siraben>Oops I must have confused myself. Self-hosting isn't needed, it just needs to be able to run under Guile. It will take a proto-Haskell program and output ION assembly

<rain1>hi!

<Hagfish> http://boginjr.com/it/sw/dev/vinyl-boot/

<xentrac>hmm, I don't think we have Guile bootstrapping yet, because of syntax-case

<xentrac>I mean, we have it bootstrapping in the opposite sense: you need a Scheme to compile Guile

<xentrac>which is the opposite of what we're after :)

<rain1>things are a bit circular sometimes

<xentrac>how are you doing, rain1?

<xentrac>glad to see you!

<rain1>im doing a lot better

<rain1>how are you?

<xentrac>not dead yet!

<rain1>:)

<Hagfish> https://forgefed.peers.community/modeling.html#ticket

<Hagfish>i'm glad that people are thinking about how to have a decentralised issue tracker

<xentrac>can't you just put the issue data in git?

<Hagfish>i think they want a web front-end, and an auth system

<xentrac>those are reasonable desires

<xentrac>though how do you reconcile "an auth system" with "decentralized"?

<Hagfish>federation

<Hagfish>that does mean trusting other servers not to lie about what a user on that server is doing

<xentrac>so not really decentralized, just distributed

<Hagfish>yeah, only as decentralised as email

<siraben>xentrac: Yeah I'll make sure it runs in Guile, then make sure it runs on mes-m2

<xentrac>email servers don't trust other servers not to lie about what a user on that server is doing

<siraben>Just want good debugging all the way

<xentrac>the users have to trust their own server and the server of whoever they're talking to, that's all

<Hagfish>xentrac: don't they? if you receive an email from alice@gmail.com, do you know that Alice sent it, and not an admin on GMail?

<xentrac>probably "rely on" is a better term

<OriansJ>Hagfish: only if encrypted and signed by the Alice I know

<xentrac>well, if I as a user on canonical.org choose to rely on Gmail's server, I can then know that Alice sent it. but my mail server doesn't know and doesn't care

<xentrac>I'm also relying on my own mail server to tell me that it really came from gmail's server

<Hagfish>yeah, if you're running your own server, that's one less entity to have to trust

<Hagfish>we're all about removing entities needing trust here :)

<xentrac>yeah, that's one reason the term "rely on" is a better term

<xentrac>it explains more clearly what we're trying to achieve

<xentrac>"trust" sounds like something we want to have more of

<xentrac>but for example I just got a mail from 110.2.94.103.iconpln.net.id purporting to be from ThomasThomasu@iconpln.net.id

<xentrac>he says, "Ich wette, du bist ein toller Kerl. Warum triffst du dich nicht mit einem M<E4>dchen wie mir?"

<Hagfish>lol

<xentrac>probably 110.2.94.103.iconpln.net.id is not a server I want to rely on in general

<Hagfish>but if you wanted to hear more from Thomas, you'd have to rely on that server to provide those messages

<xentrac>right

<Hagfish>(and rely on it to _not_ send messages which pretend to be from him)

<xentrac>(except I suspect she may have included a link to her web page with photos of her)

<xentrac>certainly I wouldn't rely on it to tell me about mail from thaths@gmail.com though

<xentrac>for example

<Hagfish>right, true

<xentrac>so in that sense my mail server isn't relying on 110.2.94.103.iconpln.net.id, or only to a very limited extent

<Hagfish>it's relying on it to at least the extent that you want to communicate with ThomasThomasu@iconpln.net.id

<OriansJ>love the vinyl link by the way Hagfish

<Hagfish>(modulo the fact that a single email address might have several machines sending/receiving mail for it)

<xentrac>right

<Hagfish>OriansJ: yeah, i thought it might find a favourable audience here :)

<xentrac>sure, probably 110.2.94.103.iconpln.net.id is not actually an MX, though I haven't looked

<OriansJ>Hagfish: makes me wish I could order that vinyl to play with my IBM 5150

IRC channel logs

2020-11-22.log