<apteryx>Jeremy[m]: a comparison from apple.com seems hardly fair. From what I've read, they're both pretty good compilers, but GCC usually win by some margin. More important than performance however is being part of GNU and forming a consistent system. The documentation of GCC is much better (and available in the info format), from what I can see.
<nckx>Jeremy[m]: <Are there any plans to build Guix with clang?> No.
<nckx>And the decision won't be based on biased pro-clang advertisement from Apple ☺
<Jeremy[m]>well, it seems a general consensus that clang has a clearer codebase
<Jeremy[m]>certainly, I (someone who doesn't know C or C++) can understand the clang code better than the gcc code
<singpolyma>Is there a good (or alternatively a bad) way to get a guix package matching a certain version range (from guile mostly, guix repl script or similar). I know I can easily get one that equals an exact version but sometimes I want a range (for import style scripts etc)
<nckx>Jeremy[m]: ”I think Guix would benefit from using clang instead of gcc wherever possible...” Why?
<Jeremy[m]>nckx: because it's considered to be a better codebase
<Jeremy[m]>clean OOP, not many macros, very clear separation between concerns (compilation split between multiple "passes" that are independent of each other)
<nckx>Then why does GCC generate better code? 😛 This all sounds very subjective.
<Jeremy[m]>it also performs faster in most benchmarks, and has a broader variety of optimizations (e.g. native LTO)
<Jeremy[m]>also most modern programming languages use LLVM rather than libgcc so there would be more consistency if LLVM were used (no need to maintain two separate compiler systems)
<nckx>None of this sounds remotely convincing, sorry.
<mekeor[m]>assuming i want to launch syncthing as a shepherd-user-service, do i really have to define a syncthing-service with "(define syncthing ...)" although it has been defined in (gnu services syncthing) already?
<nckx>You seem to really like clang though, which is cool. Guix has Clang! It would be awesome if you'd help improve (even just updating it can be an undertaking — despite its modularity claims, it's a very monolithic beast to maintain in practice). Creating a drop-in clang-build-system would be even awesomer! None of that means Guix has to ‘switch to’ Clang, or that Clang is better (it's really not).
<dstolfa_>it's just bad in a different way from gcc/binutils/...
<dstolfa_>it started with a noble goal... maybe didn't quite end there :)
<lilyp>clang is a convenient tool to use when dealing with nonfree ISAs because there's no pesky GPL telling you to distribute the source code of your compiler
<dstolfa_>well, it's also a convenient interface to build something like clang-format on and a number of static analyzers. it's not all anti-GPL motivated. some bits are for sure, but it's still free software so i'm okay with that
<dstolfa_>ultimately llvm's existence improved gcc and binutils quite a bit.
<lilyp>any way, I ought to go to bed now, not discuss toolchains
*dstolfa_ remembers the nasty time of gcc "compiler errors" which may as well have been just a call to backtrace() in compiler internals or redirected to /dev/null, as that's about how useful they were
<podiki[m]>I'd bug report that, it should and has worked
<podiki[m]>I know there are others that use yubikeys and u2f around somewhere, maybe not awake right now
<orangias>It's a difficult situation to explain, but I'll try to bug report it anyway. Thank you for your help and guidance. I would have figured it out thanks to you if I hadn't been in some extraordinary crap.
<podiki[m]>it is annoying when you can't see what is really going wrong
<the_tubular>What is guix's default display manager and can I remove it ?
<apteryx>if you're using a desktop template, that'd be gdm, and yes you can remove it
<zamfofex>Jeremy[m]: I find LLVM to be specially neat. I think part of what makes it seem so neat to me is how it does indeed separate compilation from code generation into two very clearly distinct steps.
<zamfofex>The benefit being that other programming languages can target it and benefit from features such as optimizations and its various backends without having to fork the project or some such. I think that’s really neat!
<zamfofex>Another neat thing being that LLVM is designed with cross‐compilation in mind. GCC can cross‐compile, though it seems to have been an afterthought. From my experiences, it’s definitely not as straight‐forward as with Clang.
<zamfofex>Though I don’t think the points you brought up sound particularly convincing, and the reason is that they are either vague or subjective.
<zamfofex>You claim that Guix would benefit from using Clang instead of GCC, but when you are asked why, you claim that “Clang has a better codebase”.
<zamfofex>Which is an understandable reason. But when you are asked “why does Clang has a better codebase?”, you list some seemingly hand‐wavy objective points.
<zamfofex>Personally, I don’t really like C++ and object orientation, so some of the points you mentioned makes me feel the converse.
<zamfofex>I don’t think the points in the Apple analysis you linked are false, and I agree with most of them. Though I think it’s generally easy to make either side seem bad by virtue of wording or cherry picking.
<zamfofex>It might not necessarily be *intentionally* biased, by the way. In that analysis case, it seems a lot of the points they brough up seem to be regarding using the compiler alongside an external tool such as a code editor or IDE.
<zamfofex>Clang works better in that regard, because (as it mentions in that very page), it was designed with the use‐case in mind. GCC wasn’t, and that usage is not a goal for how it is used.
<zamfofex>That can be seen as “bad” if you want a compiler that can integrate well with editors, but otherwise it’s not particularly useful. Specifically, a lot of the points in the Apple page are not relevant to the original point you were making about Guix at all.
<zamfofex>Jeremy[m]: Though I’d honestly still encourage you to experiment! Guix is fairly easy to customize in general. You could modify the C compiler used to Clang, and you should be able to try out those changes in packages by yourself!
<zamfofex>That might be an interesting thing to try out! If you do believe there is legitimate benefit for it, you could also release your modifications and explain your rationale for it in a way that people can easily try out and use.
<zamfofex>But I just don’t think Clang is obviously better from a technicial perspective as you seem to be claiming. I don’t think it’s worse either, it just takes a different approach. It definitely has benefits, but that doesn’t mean it’s always the better choice.
<zamfofex>(Sorry for posting so much text! I just felt like I had a lot to say. I hope everything seems sensible enough.)
<lilyp>Also, the whole "coding tips by compiling" thing looks a little weird if you consider having to compile the codebase as you type
<lilyp>When Emacs can just as well point you towards errors found in M-x compile using GCC Clang or any other compilerr
<maximed_>sneek: later tell pkill9: While SELinux configurations usually label binaries specially, SELinux can do without labelling binaries, if the programs manually switch context (I don't remember the necessary commands though). (IIUC, I haven't ever actually tried this)
<roptat>I'll delay my usual translation merge to sometime after the week-end, to give you all a chance to complete the translation in your favorite language(s) :)
<itd>Hi. Question: for packages p where -i> input and -pi> propagated-input in dependency graph "(p3 -i> (p2 -i> (p1 -pi> p0)))": p0 will not be available when building p3, correct? (Because p2 does not propagate input p1?)
<oriansj>itd: only direct dependencies are used in the builds
<oriansj>So if a->b->c->d is your build chain b will only have a and output c; c will only have b and output d
<Zelphir>So I got the following code: https://paste.debian.net/1214099/ and I am wondering what I am doing wrong. I have also put the strack trace displayed by Geiser using ,bt and a trace displayed by Geiser using ,trace in the paste. Often I have these kind of traces, where 90% is Guile internal stuff, that I do not understand. Then I can see somewhere after `(min-length)` I get an error. I am not calling min-length myself, so it must be some internal stuff
<Zelphir>or SRFI-43 stuff. I have tried "print debugging", but the error seems to happen inside the form of `vector-map`. Anything before I can print, but as soon as vector-map is called the error comes and I don't know what I did wrong.
<Zelphir>Somewhere internally some call of `cdr` seems to get an empty list and I don't know what is causing it.
<roptat>I've never used srfi-43 before, so it's hard to say... maybe #guile will have more knowledgeable people?
<lilyp>Zelphir: It appears you're not looping correctly, can that be?
<Zelphir>Am I not? Let me check again, I am probably blind to the mistake already.
<Zelphir>`next-update` takes only 1 argument, the next index in the "updates" (vector of update elements). I am giving it 1 argument in `(next-update (+ index 1))`. Or is there another place?
<excalamus>sneek, later ask iskarian Hey, it's been like a month, but I finally finished my write up. After reworking my website, the site generator, hacking together some CSS to represent diffs, and then remembering what the heck we did, the build experience preserved at http://excalamus.com. I've got some follow up questions for next time you and I are able to talk. I appreciate your help and wanted to give an update from the ether...
<sneek>Welcome back excalamus, you have 3 messages!
<maximed>excalmus: ‘Are "fields" [..] actually GOOPS slots?’ --> AFAIL they aren't: the <package> record uses (guix record), which doesn't use GOOPS, but I suppose it would be possible to implement (guix records) on top of GOOPS
<maximed>excalamus: ‘Are "fields" [..] actually GOOPS slots?’ --> AFAIL they aren't: the <package> record uses (guix record), which doesn't use GOOPS, but I suppose it would be possible to implement (guix records) on top of GOOPS
<maximed>excalamus: pypi-uri is in (guix build-system python)
<maximed>Find it with ‘git grep -F define\*\ \(pypi-uri guix’
<maximed>or do "git grep -F pypi-uri | grep define"
<maximed>I recommend using "git grep -F pypi-uri | grep define" to find where something is defined (and what module you need to import)
<maximed>excalamus: The signifance of the license: prefix is that there is an 'expat' license and an 'expat' package, so license: is sometimes needed for disambiguation
<awb99>Is anyone using guix on cloud machines? I guess one easy way is creating docker images from guix. But for dedicated servers, I guess currently only the digital ocean api is interesting. Any other options that do not need a lot of manual tweaking?
<awb99>Will after running such a "hostile takeover" the guix system be the only thing remaining? Or will there be traces of the old debian still there?
<nckx>awb99: Plenty. Guix will only overwrite files (in /etc, etc.) managed by its own services; all others will be left behind. At best they'll be harmless but it's theoretically possible they could influence the final system in unforseen ways, so I delete them based on timestamp.
<maximed>Is there some option to ignore TLS certificates?
<maximed>Because "guix pull" doesn't depend on TLS for security, except to prevent eavesdropping
<vivien>Does debian (without running anything from guix) works?
<maximed>poet: dunno if this work, but maybe try running "guix environment --ad-hoc nss-certs -- guix pull"
<maximed>If SSL_CERT_FILE is unset, this presumably means the certificates from the system are used (IIUC)
<maximed>so if this is on Debian, running "apt-get update && apt-get upgrade" could update the certificates, which might resolve the problem
<poet>vivien: Yes, Debian is working fine. I ran 'apt update' with no problems, but havent used 'apt dist-upgrade' yet because the download is so large. I was gonna wait until this evening. But no problems with anything else I've tried.