IRC channel logs

2021-11-07.log

back to list of logs

*chrislck read dune in 1990s lol
<stis>yah I should have known about this book when I was younger!
<stis>it's a masterpiece in so many ways, It's this book or Tolkien that a rank highest
<dsmith>Yes!
<drakonis>ooooo
<drakonis>there's a wip branch for mingw
<drakonis>so windows soon i guess?
<mike121>drakonis: guile master might compile for mingw if you do an unthreaded, 32-bit version
***mike121 is now known as spk121
<drakonis>well, its not for my own consumption
<rlb>wingo: wondering if we should start defining cond-expands for Z releases too. I was just trying to use it to handle the fact that we added bitvector functions in 3.0.3.
<rlb>This is for a file that should work all the way back to 2.2, and since 2.2 rejects nested defines, I can't just use defined? (I think)?
<rlb>Anyway, just wondered, since we don't really do "traditional" semantic versioning, i.e. substantial things can be added in Z releases.
<rlb>Also does anyone know if we guarantee that the {major,minor,micro}-version strings will always be just an integer? i.e. not (minor-version) => "3rc2" or something?
<mwette>rlb: maybe not relevant but module #:version requires three non-negative numbers
<rlb>Ahh, ok.
<rlb>I also just noticed that 3.0 doesn't allow (unless (defined? ...) (define ...)), i.e. "definition in expression context" error, so you can't use that inside a guile-3 cond-expand to decide whether or not you need to patch things up.
<rlb>Perhaps not how I should have approached that anyway...
<mwette>rlb: and i've noticed in python documentation they now add "new since N.M" for each function; I wonder if it could be possible to automate generating a list like that
<rlb>That'd be nice -- clojure does that.
<rlb>(they use metadata attached to the "defn"s (defines)).
<rlb>e.g. https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/map-indexed and via the corresponding source link: https://github.com/clojure/clojure/blob/7529bc90a35eba940581311d7dfed21fec22b4f5/src/clj/clojure/core.clj#L7294
<rlb>So aside from just handling things during ./configure, is there a typical way we can check for a given Z version in a scm file and make definitions accordingly? (Guessing I can do it via some more explicitly macro expansions if nothing else.)
<rlb>(or rather the equivalent of "at least X.Y.Z" that will "always work"?)
<rlb>i.e. won't be broken by (expected) future versions -- part of my hesitation is experience with build systems that sometimes produce say git describe based versions for dirty trees, etc. So just wasn't sure what we (and our build system) promises.
<drakonis>guile got positively namedropped in a hn discussion about racket
<drakonis> https://news.ycombinator.com/item?id=29134703
<rlb>(I hadn't tested lokke against 2.2 recently, and I'd forgotten just how much faster "make -j5 check" is with 3.0.)
<rlb>Not a great name, and not pretty, but perhaps it'll do for now: https://paste.debian.net/hidden/d19af9bb/
<rlb>(presuming I can count on integers...)
*dsmith starts a lame joke involving counting and integers, but decides againt it..
<lilyp>Typically integers won't float away when you count on them, but they might overflow.
*rlb groans :)
<lilyp>Sorry, I really doubled down on that one
<rlb>hah
<lilyp>Long long ago, there was an unsigned short letter. Now it is charred.
*dsmith applauds
<rlb>OK, that's a pretty "good" project name :) https://github.com/athos/kitchen-async