IRC channel logs
2023-01-02.log
back to list of logs
<rekado>testng has three test failures, but they seem to disappear when building with just one core. <attila_lendvai>elevenkb, a better-than-sexp way to write code that should be serialized and sent to the builder, and processed otherwise (e.g. maybe when the package hash is calculated?) <vivien>My answer would be: Using the same programming language and the same code at any level in the program to system scale <rekado>nope, I was wrong; it still fails. <vivien>The biggest selling point of lisp is meta-programming, i.e. programs that write programs. With gexp you can make program write programs across machines and environments <elevenkb>yah makes sense. so, basically the old way of writing packages without gexps should be considered obsolete right? <cbaines>apteryx, regarding qa.guix.gnu.org, it doesn't look like there's something majorly wrong, although it does seem rather slow at the moment. Unfortunately I don't have time to investigate further right now. <vivien>For a more down-to-earth answer, if you used another programming language such as Python for instance, you would need to generate code in another programming language to pass it to the build daemon. That would be something like send_code_to_build_daemon('def do_build():\n do_thing_with_file({})'.format(send_file_to_build_daemon('file.txt')) and that would be awful because the top-level language does not understand the low-level <vivien>language (what’s in the single quotes). With guix it would be: #~(define (do-build) (do-thing-with-file #$file)). The frontier between inside the build daemon and outside of the build daemon is made explicit by the #~ and #$, but it’s the same language actually. <vivien>I’m not sure I’m doing a good job describing gexps <elevenkb>hmm for background, I've read SICP and such so I'm following along well vivien. <apteryx>cbaines: ok, thanks for checking; perhaps I just need to be patient <bjc>anyone here who can tell me what i'm doing wrong with the ungexp in the ‘format’ line here: http://ix.io/4kdb <KarlJoad>What is the proper way to conditionally include services in an operating-system record? (when pred (service foo-service-type)) does not work when pred is #f. <bjc>splice in nil or a list of one item <vivien>The "services" field of the operating-system declaration expects a list of services. You can use the append function, to append several lists. One of these lists may be (if pred (list service…) '()) <vivien>You can also have `(,(service …) ,(service …) ,@(if pred `(,(service …)) '())) too, and it’s easier to read I think. <mirai>(remove unspecified? (list a b (when foo c) d ...)) <vivien>That one is slightly less easy to read I would say <trevdev>I'm attempting to take on the task of building/packaging node-lts version 18 as the official repos are horribly out of date. Because I'm not a C dev and am only vaguely familiar with how `make` is supposed to work, this is going about as well as you might expect it to. I'm trying to build it on my machine successfully once before I attempt to create a "build env" in my own guix channel. The dependencies are supposed to be installed. <trevdev>I'm getting "cc: No such file or directory". I have the gcc-toolchain in my current profile. Any tips? <KarlJoad>mirai: vivien: I guess I have to use if instead of when I guess. Thanks! <vivien>In any case, both branches of the if must be lists. Either empty or not. <KarlJoad>Yeah. That was the problem I was running into with the when. <trevdev>Haven't changed anything and it's building. Hookay then <mirai>KarlJoad: 'when' and 'unless' return #<unspecified> when the condition doesn't happen <trevdev>Oof, it hit a call to cc -o and indeed failed again. What the heck. <mirai>naturally, those can't be spliced into the list <KarlJoad>mirai: Yep. I figured that out in the REPL. That is why I asked if there was a better way to do it than an if. But an if works. <mirai>usually people use the ,@if idiom <mirai>the (remove) one I don't think I've seen it used before but it does the same, it results in less line noise if you're unhappy the `,@() plastered all over <KarlJoad>The ,@ feels about the only way to do it. <vivien>Sometimes `,@() have surprising behaviors when mixed with their gexp counterparts <mirai>KarlJoad: you could do some eldritch incantations with cons* <KarlJoad>No gexps here, so no worries about that. <mirai>heck, if for some $reason you want to do it, you could even use M4 <KarlJoad>M4 feels like overkill for this... Just setting up a pair of servers to use for Cuirass. One is the controller and both have a remote-builder on them. <trevdev>`make CC="gcc" -j4` seems to be working. Thanks IRC rubber ducky <KarlJoad>trevdev: I believe there are other packages that use a phase to replace CC with gcc. I don't know for sure though. <trevdev>KarlJoad: I think I have seen that before. The last time I tried to do this failed spectacularily. Hopefully I <trevdev>...have learned enough since then to see it through <nckx>(Better-behaved packages don't need a phase at all.) <nckx>Setting "CC=gcc" breaks cross-compilation (--target=…). <trevdev>nckx: I had a look at the makefile and it looks like a flag or two have been set properly since that version <trevdev>The cross compilation thing is not so great for contributing my work I suppose <trevdev>I guess that's what `(cc-for-target)` is for <nckx>It's important to support cross-compilation when possible, but that's for after you get your package to build natively. Also, I don't even know if node cross-compiles at all. Some packages just don't. <trevdev>I will endeavour to make it as compatible as I can. <trevdev>I don't know how many web-developy people we have but v14 LTS is getting a bit old now <trevdev>My stumpwm CPU module says we're at 96 degrees whooowee! <vivien>Most NIH build systems don’t care about cross-compilation unfortunately. <KarlJoad>lechner: Did you have to do anything to your opensmtp server to get messages flowing to Gmail? No extra software (DKIM and friends)?