IRC channel logs

<ArneBab>lilyp: did you see any argument that said that systemd is cleaner than OpenRC (not more powerful or faster or anything, but cleaner)? I might have missed it, because that was outside my bubble, so I’d be glad to see it.

<mwette>I'm having issues w/ letrec-syntax. Any help? min example: https://paste.debian.net/1253720/

<antipode>You're nesting macros in macros

<antipode>More concretely:

<antipode>'f' and 'g' are two (syntax transforming) procedures

<antipode>the (syntax-rules () ((_ z) (+ (g z) 100))) is the procedure behind the macro 'h'

<antipode>This macro tries to use 'g'.

<antipode>However, the 'let-syntax' only introduces a 'f' and 'g' macro when the (syntax-rules () ((_ z) ...)) is being compiled.

<antipode>When the (syntax-rules () ((_ z) ...)) procedure is actually run when using 'h', these 'f' and 'g' don't exist anymore

<antipode>(IIUC)

<antipode>How about defining 'f' and 'g' outside 'h', with define-syntax?

<antipode>Alternatively, you can try (define-syntax h (syntax-rules () ((_ z) (letrec-syntax ((f ...) (g ...)) ...)), moving the 'f' and 'g' inside (untested)

<dsmith-work>Tuesday Greetings, Guilers

<mwette>antipode: thanks -- I think I tried the other embedding suggestion before and it didn't work -- more study to do

<mwette>antipode: but just tried and it works

***maximed is now known as antipode

<lilyp>ArneBab: The systemd side argues that it's cleaner because it doesn't need to spawn "like 10 processes to do some i18n"

<dsmith-work>Yeah, but instead of using a language tat

<dsmith-work>Yeah, but instead of using a language that's been around for 30 years or so, it uses a DSL of key:value pairs with about 500 keys documented in about 20 man pages, and at the end, there isn't a key:value for what you want to do.

*dsmith-work shakes fist at systemd

*dsmith-work checks his lawn. again.

<dsmith-work>man -k systemd | wc -l

<dsmith-work>205

<dsmith-work>Seems I was of a bit with the number of man pages...

<dsmith-work>man systemd | grep '(5)' | wc -l

<dsmith-work>28

<dsmith-work>Ok, not so bad after all.

<dsmith-work>But still..

<haugh>Hello! I'm reading some Artanis internals and wondering about the utility of this module-ref. What does this do that isn't accomplished with #:use-module and #:select ?

<haugh> https://gitlab.com/hardenedlinux/artanis/-/blob/43e5926ca83ee683eee7bd6f10a24111460fb187/artanis/utils.scm#L130-131

<unmatched-paren>haugh: that's an @@

<unmatched-paren>which allows you to access private defs in a module

<unmatched-paren>#:use-module ((web http) #:select (parse-date)) would fail because presumably parse-date isn't exported

<haugh>Got it, thanks.

<kitzman>Hmm. If I would decide to design smth similar to Inferno OS, I would try to do it in Guile.

<kitzman>Since most (if not all) VM instructions would be arch independent (i think?), guile could interpret code in such a way that it could suspend the state and migrate the process to another computer, right?

<unmatched-paren>kitzman: I don't believe guile's bytecode is arch-independent

<unmatched-paren>because there's a ``-t TARGET'' flag for ``guild compile''

<dsmith-work>The bytecode has 4 "archs". {{big,little}-endian,{32,64}-bit}

<haugh>I love seeing Bash notation in the wild

<unmatched-paren>dsmith-work: oh, huh, so passing ``-t aarch64-linux-gnu'' is wrong?

<dsmith-work>unmatched-paren: Not wrong.

<unmatched-paren>will it automatically work out the endianness and size_t size from the arch?

<dsmith-work>Yes, I belive so.

<unmatched-paren>okay, cool

*unmatched-paren is happy they don't have to change their guile configure script :P

IRC channel logs

2022-09-13.log