IRC channel logs

<cow_2001>"a maze of record apis"

<haugh>Just use (srfi srfi-9 gnu), in my opinion

<haugh>Two caveats: I use a LOT of high order functionality, so that's probably coloring my preference. The Guix folks also did not find this approach sufficient, and so added (guix records) which, among other things, adds fieldname-based record queries.

<cow_2001>i didn't know there are more names after the "srfi-n"s in (srfi srfi-n ………)

<cow_2001>:|

<haugh>It's just a reflection of the directory structure. Poke around in your guile installation directory. .../srfi/srfi-9.scm is a file, .../srfi/srfi-9 is a directory, and .../srfi/srfi-9/gnu.scm is a file

<haugh>SRFIs 4 and 171 also have GNU extensions

<cow_2001>scheme really is a bunch of different languages with a very similar syntax ~;~

<cow_2001>it looks like everyone are doing their own thing

<cow_2001>to say nothing about lisp at large………

<haugh>I want to work with a language that respects me as an individual. In this ecosystem, we have access to ridiculously powerful constructs which enterprise software giants can't afford to let loose within their gigantic dev teams. The tradeoff is that other people's code will be very different from ours.

<cow_2001>how do you write cross compiler code this way? is it feasible?

<haugh>2lowlevel4me tbh

<cow_2001>maybe the phrase isn't "cross compiler". what is the term i am looking for? when you can run the same code in chez and guile and mit scheme

<cow_2001>so the tradeoff is that you have the language that you love but also an idiosyncratic language?

<rlb>cow_2001: generally stick to the standards (rnrs, srfi, etc.), perhaps try cond-expand, and then of course for any given thing, there might or might not be a portable option.

<cow_2001>and idiosyncratism is not good for a lingua franca

<cow_2001>like… java…?

<cow_2001>i never really wrote anything in java

<cow_2001>maybe an hello world once

<cow_2001>rlb: now that i think of it, same bit of c code may be ifdefed for different architectures for optimisation or whatever reasons

<rlb>ACTION recommends the clojure dialect of java in most cases :)

<cow_2001>which is very much like cond-expand

<rlb>C is a similar world on that front, hence autotools.

<rlb>(but *much* messier)

<rlb>(...though standard jvm/clj isn't (easily) appropriate (still) if you need fast startup time, i.e. cli tools)

<cow_2001>guile somehow manages to be very fast

<cow_2001>very fast startup time

<cow_2001>after sicp, k&r

<cow_2001>maybe i should do them concurrently?

<cow_2001>rlb: seriously now. should i follow more than one book at a time? switch when i get bored?

<rlb>No idea? :) Imagine it entirely depends on your preferences/requirements/goals.

<cow_2001>(greet kolev)

<cow_2001>(yes, i stole your joke)

<haugh>Some people overrate portability. It's a tool for approaching a particular set of problems, not a divine mandate. Scheme portability in particular is very difficult.

<cow_2001>portability is the word ~;~

<haugh>I've written a lot of shell and I'm really, really tired of people talking about portability.

<rlb>:)

<rlb>ACTION sympathizes

<haugh>"Hello, I've solved your difficult inter-organizational policy synchronization problem entirely in bytestreams."

<haugh>"BUT WILL IT RUN ON MY AMIGA??!?!"

<haugh>ugh

<cow_2001>what about zx spectrum?

<cow_2001>i don't have the experience needed to judge either way

<cow_2001>reading info guile match

<haugh>Just be selfish. Consider your own domain all-important. At the end of the day, it will be you and an error you don't understand. All of this preparation should be in service of helping you in that situation.

<cow_2001>hmm

<cow_2001>i should have read info guile match 40 years ago

<dsmith>!uptime

<sneek>I've been serving for 2 days

<sneek>This system has been up 3 weeks, 1 day, 6 hours, 10 minutes

<old>I just realize that ice-9 threads is resolved in boot-9

<old>How should a module replace these bindings, e.g. make-mutex ?

<old>With #:replace, I still get: WARNING: (guile-user): `make-mutex' imported from both (ice-9 threads) and (parallel mutex)

<RhodiumToad>... don't import it from both places?

<old>..

<old>Module A want to use (parallel mutex), too bad boot-9 already import ice-9 threads

<RhodiumToad>rename it or exclude it when importing (ice-9 threads)

<old>I'm not importing ice-9 threads, boot-9 is. I have zero control over this

<old>and it does not act like a core bindings

<old>I guess renaming is the easiest solution.

<old>But I've been working in the hope to have a transparent solution

<RhodiumToad>do your stuff in your own module rather than in guile-user?

<old>eh not sure why this is just an issue in the RPEL

<old>REPL

<old>but it seems that when running test, my function are indeed called instead

<old>not sure to fully understand the boot-9 stuffs

<lloda>if (write "α" ...) shows up in file as "??" instead of "α", what to check?

<cow_2001>lloda: i don't know what's your problem, but there's port-encoding. look up `info guile port-encoding` and its surrounding documentation.

<cow_2001>it may or may not be what you're looking for

<lloda>hmm thx

<lloda>idk why should it ever be anything but UTF-8

<ArneBab>lloda: for hysterical raisins — I spent weekends over weekends getting a tool working in Python3, because they had decided to break backwards compatibility on that. I know of at least one professional dev team that will never touch python again due to such breakage.

<lloda>hmm as long as you follow a deprecation proc you should be allowed to fix things

<lloda>i hope guile never gets so big that that becomes a problem tbh

<lloda>so following cow_2001 clue i found that if I run my script straight of the shell, port-encoding is utf-8 just fine

<lloda>but if i run it in a bash while loop, then the encoding is ANSI_X3.4-1968 (!!!)

<lloda>never seen such a thing

<ArneBab>With the experiences I now had from Python, I would say the best time to break backwards compatibility in a tool that is an integral part in other tools is never. Do you know how close we got to losing Lilypond as Guile-using tool due to the breakages in Guile 2.0?

<lloda>probably not all those breakages were necessary, but people don't follow dev and wait till 2.0 is in all the repos to tell you, instead of testing 1.9 where some things could have been fixed

<ArneBab>As a more tempered approach: count the time required for a compatibility layer that keeps tools working. If that time is less than the time all others need added together to get their tools working again, then that compatibility layer should be a requirement to get the change in.

<ArneBab>The python devs massively underestimated the amount of breakage they caused — and how long it lasted. There are still tools that only work on Python 2.

<ArneBab>The core reason I see: while you develop a tool, you spend a lot of time and enthusiasm on making it great. Then when it works, you spend that enthusiasm and time on something else, so you don’t actually have a lot of time to follow changes in the tooling your tool needs.

<ArneBab>This is especially true for Free Software where some useful tools are not maintained at all, because they don’t need maintenance: they just work.

<ArneBab>That’s how we can keep building more and better tools: the things we build keep working, so we can stand on the shoulders of giants. If they stop working, then we can’t.

<ArneBab>lloda: yes, people don’t follow the most recent version, because they actually just want to improve the tool they build, not spend their time chasing after a moving target.

<ArneBab>The hard question is: how to be the best tool in 2033 without losing the existing devs?

<ArneBab>One reason why I’m very skeptical of doing some breakage "just this once" is that after Python broke stuff with 3.0, they kept breaking things. The worst breakage was when they added the async and await *keywords*, so all code that used async as function argument just broke. callApi(async=True) ← crack. That hit me, too.

<lloda>good will on both sides?

<lloda>anyway i fixed my script by adding (fluid-set! %default-port-encoding "UTF-8") at the top. Surprised that i needed to tho :-\

<msavoritias>you dont do breakage just once though

<msavoritias>what you do is you make a plan and say okay 1. this is encouraged. 2. this is discouraged. 3. this is deprecated. 4. we remove it

<msavoritias>which this path can take between a decade to two decades

<msavoritias>for tools like guile

<msavoritias>probably closer to two

<msavoritias>i hope that guile doesnt feel like not changing or removing stuff is good. we tried that with C++ and it has gotten worse over time

<lloda>it's bizarre. after setting %default-port-encoding as above my program doesn't see ? in strings anymore, but when it prints them to the terminal they still print with ?

<lloda>maybe i need to set the port encoding in more places? :-\

<ArneBab>msavoritias: C++ is one of the few tools that survived, so keeping stuff working does not seem like a losing strategy.

<msavoritias>and it still deprecates stuff

<msavoritias>and there is a huge push to make the language simpler

<msavoritias>what made rust and google fork it

<Arsen>rust is not a fork and neither is carbon

<msavoritias>CL and scheme have the same thing

<lloda>the day is coming for C++ to do a fortran 90

<msavoritias>no. but its C++ with out the baggage

<Arsen>carbon was not made for simplification either

<lloda>it'll still be called C++, but it'll be a different language

<Arsen>it was made to break the long-standing abi which has come to hinder some pieces of the library

<Arsen>and rust.. well, rust is to C++ what scheme is to elisp

<daviid>fwiw, i'd recommend kawa rather clojure, start-up time is blindingly fast, and, it is scheme ... so much better, and the kawa integration with java classes is not far from an order of mag superiror to clojure, and it is free s/w, the clojure license isn't ...

<rekado>the EPL 1.0 is a free software license

<daviid>i santd corrected then, but i was (always) told clojure had a none free license, by some much more knowledgeable then myself on this domain ...

<daviid>though - The EPL 1.0 is not compatible with the GPL, and a work created by combining a work licensed under the GPL with a work licensed under the EPL cannot be lawfully distributed ... - and - The EPL, in addition, does not contain a patent retaliation clause ... fwiw

<RhodiumToad>lots of free licenses are not compatible with the GPL for whatever reason

<daviid>right, and afaic those are to be avoided ...

<daviid>on the technical side, one (very important) thing to mention as well, about kawa, is it does _not_ need any '(none)eco system', just a jre and kawa, then: kawa -C foo.scm [ that's it, beautiful, simple, efficient ... ]

<daviid>anyway, back to hack - just wanted to mention kawa, and suggest kawa instead of clojure ... imo

<ArneBab>I started a small game based on the code of dryads-wake for the game jam for blind gamers: https://hg.sr.ht/~arnebab/dryads-sun/browse/dryads-sun.w?rev=tip#L41 — I thought you might be interested. I have a week left and hope that I’ll be able to finish at least part of the story.

<ArneBab> https://dryads-wake.1w6.org/sun → ~~~ Dryads Sun ~~~ Rebuild in uncertain choices & dialogue.

<bsima>does anyone use guile-sdl2 with guile 3.0? I got a compile error and core dump which is kinda odd

<bsima>^^ ping dthompson maybe?

<dthompson>bsima: yeah I use guile-sdl2 with guile 3 and have been for years. what happened?

<dsmith>sneek, botsnack

<sneek>:)

IRC channel logs

2023-04-24.log