IRC channel logs
2026-07-03.log
back to list of logs
<JohnCowan>Right. What it shows is how difficult writinh a necessary and sufficient spec actually is. <ArneBab>JohnCowan: are you already getting feedback on your nonchar spec from people here? I think rlb may have informed opinions. <euouae>exciting to see more SRFIs merged <euouae>why did you replicate the copyright otice? <old>ArneBab: I can see to review that later today if I have time <old>euouae: indeed I don't get why the license is in the doc <old>ArneBab: I've made so requests for stylish change. I'll make a more in depth review later <JohnCowan>The license in the doc is *for* the doc: not all SRFIs have code <jan0t>the way intended to use guile is through guix? <jan0t>what if I dont have guix and want to use it in my devuan <rlb>"apt install guile-3.0" I suspect <rlb>and guile-3.0-dev, perhaps, depending on what you want to do. <euouae>jan0t: I use it on debian personally <jan0t>and how do i install the libs to use it? <jan0t>does it have a package manager to the libs? <jan0t>euouae: then we will be the same, I am on devuan <rlb>Ahh, right --- my impression is guix is common for that regardless. Though debian does I think have some deps. <euouae>no I download the packages separately and install via ./configure && make <rlb>(I'm still not very experienced with guix.) <euouae>I think I even manage my own guile installation I don't bother with the guile-3.0 package <jan0t>but how do you keep track of the compilation artifacts? <jan0t>to not let your system full of waste <euouae>how do I update libs and such? or what do you mean? <euouae>if I don't want to share the libs with other projects I put them under some prefix/ directory and then if I want to get rid of it I delete it; works a-la python virtual environments <euouae>this is all not simple stuff. if you are not familiar with guile + how this stuff works, then just go with guix as a package manager, it's bullet-proof and guile's tailored to work with it <euouae>guix can work side-to-side with devuan's apt, it won't interfere <euouae>also guile is not the language with projects with deep dependency trees. it's not as popular nor as thorough as other languages. <jan0t>I want to develop and contribute to projects that use it <euouae>why not use racket-lang, for example? <jan0t>euouae racket is used in real life? <jan0t>because guile is used in gnu for real life projects <euouae>I use guile, I don't use racket, but racket is well-known to be nice for newcomers <euouae>some things that are frustrating to newcomers are these: 1) setup build system 2) generate docs 3) run tests 4) use other dependencies 5) debugging <euouae>(1), (2), (3) are solved by my link above but (2) not to everyone's satisfaction: it's not like e.g. python where you can write documentation in the docstring and it gets formatted. you can use documenta for it <https://guile-documenta.griz.in/> but I wasn't intrigued <euouae>my notes veer off to the VM stuff of guile as I was trying to learn it <euouae>with guile you'll have to understand the macroexpander and the compilation tower to get basic debugging done. rough. <euouae>in scheme *a lot* of the dependencies come in the form of SRFIs which are either bundled by Guile or you ship their source code (obtained from the official page srfi.schemers.org) together with your project <euouae>got to go talk toy ou another time <rlb>I still do a good bit of debugging via "ponder, printf, ponder, ..." (or in guile's case, format). <rlb>...or write, though there's also pk, which I hadn't noticed until recently. <old>fortnunately the BLUE build sytem ought to solve 1, 2, 3, 4 pretty soon. without autotools