IRC channel logs


back to list of 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:
<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>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>Seems I was of a bit with the number of man pages...
<dsmith-work>man systemd | grep '(5)' | wc -l
<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 ?
<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