IRC channel logs
2025-09-16.log
back to list of logs
<old>rlb: I've heard of something like this for debian yeah <rlb>old: whoever mentioned it actually named the tool -- I should have made some notes... <rlb>old: thanks -- made a note this time, and if no one already knows it's not suitable, think it'd be good to look in to it (might when I get time). <old>I'll have to check what it is actually doing. but what is your use case with Guile? <old>to check ABI stability between releases? <rlb>Verify between releases, *and* either "by request", or, if it's cheap enough, and feasible, perhaps always for say prs, or even just make check, or make check-abi, or... <rlb>e.g. be nice to easily know immediately that say the lilypond changes (depending on which ones we're talking about --- there were two proposals? not sure) don't affect the abi. <old>there might be something light weight enough in that <rlb>(as far as the tool(s) can tell) <old>I guess we could roll our own in Guile lmao <old>we already have ELF parser and Dwarf <old>We could start with exported symbols <old>then we could with DWARF check symbol signatures <old>that would not be that hard <dsmith>"The empty list counts as false for historical reasons only, and programs should not rely on this because future versions on Scheme will probably do away with this nonsense." <old>what are `anon #x221fb0c8' procedures? <civodul>ArneBab: hi! i’ve added you as committer on Codeberg <civodul>i didn’t take care of the migration so i don’t know exactly what the situation is, whether previous committers lost commit rights, etc. <ekaitz>civodul: what's the status of the lightening move to codeberg? <ekaitz>i think the only blocker was the CI <ttz>Is guile's format the same as SRFI-48's format? If yes it would be good to export it from a module (srfi :48). It is otherwise very ennoying to implement portable formating. <ttz>No actually these are not the same... <dsmith>ttz, It's pretty much the same as CL format <old>ACTION wondering if the JIT could be cached on disk and reload on next launch of appliccation <old>ACTION or if AOT is the way to go instead <humm>if you can cache it, you’ll want to do that when packaging <humm>if you do that, that’s just AOT but more annoying <duncan>CL format is considerably more useful than SRFI 48 IME. <old>humm: it depends on the workload for the JIT so I don't think you actually want to cache it <civodul>old: i think we have more down-to-earth performance issues worth solving <civodul>for example the overhead on libc bindings <old>you have an example in mind? <old>I'll be happy to contribute to make Guile more performant <sneek>euouae, ArneBab says: where I am reviewer, I appreciate it if contributors focus on trivial changes. That makes it much more likely that they cut their contributions into smaller steps that I can realistically review and merge within half an hour in an evening. <euouae>ArneBab: Well for trivial changes I would not coordinate <euouae>sometimes you need to revamp a section <civodul>old: when calling a C function that takes a char*, we allocate a new string, via scm_to_locale_string <euouae>civodul: I don't know if you're seen any of my messages - but I wanted to help with the autotools section of the guile manual <euouae>I watched one of your talks about a year ago where you said guile needs more maintainership so I do want to get involved and I feel like there's some parts (not code related) that I want to touch upon <old>civodul: Ah I see. For example getenv(3). So this involves polling the locale state, allocating a buffer, copying the string possibly with some conversion and then freeing the buffer. <old>that's quite a round-trip just to pass a string <ttz>dsmith: it may be pretty much the same as CL, but not having a standard foramtting module makes it really painful to write an R6RS library that outputs things. <ttz>Best I found was to manually multiply by 1. to force the point notation and use a combination of number->string and string-append. <ttz>which is really clunky <ttz>true, but that's still clunky <ttz>and it does not allow controlling how many digits are printed <euouae>ttz: what in particular are you trying to do with floats? <dsmith>AwesomeA1am54321, What is your error? <AwesomeA1am54321> The 'app' clause of `match` should work, but I'm not sure why it doesn't. Perhaps I'm misunderstanding the syntax <euouae>I'm a bit familiar with IEE-745 etc, maybe I can help <AwesomeA1am54321>dsmith: Throw to key `match-error' with args `("match" "no matching pattern" 63) <ttz`>Really not much, I was just trying to output a number in a portable fashion (for Chez and Guile at least). <sneek>Welcome back ttz`, you have 1 message! <euouae>AwesomeA1am54321: you're not using value anywhere <euouae>ttz`: in a portable fashion means what? <euouae>Oh, you're trying to write a float in R6RS <ttz`>basically I want something like SRFI-48 <ttz`>I don't have any impl of it <euouae>AwesomeA1am54321: why would #b00111111 match against the (app val-const val) sexp? <euouae>AwesomeA1am54321: match matches against cons/vector/etc/goops structure <ttz`>I also would like SRFI-244 which is just define-values which Guile exports but not as an SRFI <euouae>ttz`: it's under Implementation in that link <AwesomeAdam54321>euouae: Oh, I didn't know that. I thought `(app val-const val)` would bind `val` to `(val-const byte)` <euouae>AwesomeAdam54321: no, not at all <euouae>you'd use (let ((app (val-const byte))) ...) for that <dsmith>Have to keep in mind that Guile predates R5RS (and R4RS?) and maybe even the SRFI's. Lots of "non-standard" stuff because at the time, there was no standard... <identity>(app val-const val) is no diffferent from (app val-reg val) nor (app val-reg val), all of these patterns would match '(a b c) or any other three-element list <ttz`>I can understand that, but now that standard exists it would be nice if things were at least reexported in a standard way. <dsmith>Just a general "why is Guile different?" <euouae>ttz`: if you reexport them you might break things <euouae>well it changes the meaning of old symbols <dsmith>Yeah. Someone made a heroic effort to bend Guiles modules into the shape of R6RS libraries, for example. <AwesomeAdam54321>euouae: Is there a way to do that in the pattern match clause itself? Or would I just use a let? <euouae>AwesomeAdam54321: that's not what match is for <ttz`>Does it? If I add new module implementing SRFI-48 that exports Guile's define-value, I don't see how I risk breaking things. <euouae>AwesomeAdam54321: why do you want to use match? <dsmith>Lots of stuff is still the same to maintain backwards compatibility. <euouae>ttz`: why would you do that though? <euouae>I'm not sure what point you're making <euouae>At any rate, if we focus on the original goal, wasn't it to print a float r6-rsportably? <identity>guile's ‘format’ has a nasty thing about being slightly more limited until any module whatsoever imports (ice-9 format), after which every module has the full ‘format’ <ttz`>I want to run libraries like (library (my lib) (export ...) (import (srfi :244))) <AwesomeAdam54321>euouae: I was wondering whether there was a shorter syntax for returning the first processed value that matched. Maybe I could just use or <euouae>ttz`: you can definitely do that. (define-module (my module) #:use-module (mod1) #:use-module (mod2) #:export (...)) <ttz`>I am using define-values too <ttz`>yes, the point is that Guile does not re-export define-values as (srfi :244) so my snippet code will break <euouae>ttz`: Is this because srfi 244 is not implemented in Guile? <euouae>Right, so that is the problem then, right? <ttz`>even though Guile already has what it takes to implement it <euouae>Okay but that is different from what you said earlier, which I took to mean something else. <euouae>Guile does not have maximal SRFI coverage <ttz`>sure, my question was also: since Guile already has define-values, why isn't it re-exported as (srfi :244) by the language? <euouae>Because SRFI-244 was received in 2022-11-29 at which point Guile devs/contributors did not notice it to include it <ttz`>So would a patch be accepted? <euouae>ttz`: Maybe, I can't answer that because I am not a maintainer. I don't see why not. <ttz`>How to open a PR? The "New pull request" button is blurred for me <euouae>ttz`: you need to clone the repository in your account; connect that remote to your local git repo; push a new branch with changes (say patch-1) and the button will be unblurred <rlb>You raise the pr from a branch in your "fork". <euouae>what's the issue with gcc 15? the C standard upgrade to C17? <euouae>I went by memory, lots of breakage with that <rlb>(For now, for debian, I just added -std=c17, but wingo has a fix in wip-whippet, and there's a fix for main proposed in the bug tracker.) <euouae>but -std=c17 is the correct thing to do <euouae>Unless by fix you mean that you want to support both c17 and c23 for some reason <euouae>The issue is that multiple-standard preserving source code is essentially a polyglot, and IMHO polyglots are _bad_ <rlb>hmm, hurd almost worked this time <ArneBab>rlb: the contributor from lilypond wants to/will file the PR himself. Feels better for him and is less work for me ⇒ win/win ☺ <rlb>I'm not all that familiar with the srfi process -- am I right to assume the standard implementations have already had a good bit of review? <ArneBab>In the SRFIs I contributed to, there were 1-2 reviewers, but in my case I think there was only one. The text is what’s reviewed best there. <rlb>For now I was just asking in general, so I know how to approach them when proposed, but could end up applying to yours. <ArneBab>I’ve seen the API reviewed closely (must match the definition), but don’t think that there’s review for efficiency on a given implementation. <ArneBab>The reviews that were done are usually public: you can check on the mlailing list whether there was review. <rlb>OK, thanks --- that helps, i.e. wide spectrum between "can't expect anything" to "can expect it's had careful review" of the implmentations. I just wanted to know what the norm/convention/requirments were. <ArneBab>I’ve reviewed 2 or 3 there, but do that depending on the topic (whether it interests me directly) <ArneBab>But I think at least Arthur is reading everything. <ArneBab>And if there’s no reaction to reviews for too long, the usual reaction is to close the SRFI after a while. <ArneBab>(a while: more than a month, I think) <euouae>I'm trying to write a macro here for match records <euouae>I want (match x (($ <my-class> a b c) (list a b c))) with a macro (match x ((my-macro a b c) (list a b c))) <euouae>I can't figure out a way to get this right, does anyone have a clue for me? <euouae>hm, I can at least get it to work if I include match in the macro def. <dthompson>or rather, according to the match syntax rules, you're defining a clause that binds the first element of x to my-macro <euouae>dthompson: yeah I was basically trying to extend the syntax of match, I realized it's impossible as it is <dpk>euouae: see SRFI 262 ;-) <euouae>dpk: It occurred to me that extensible macros are possible (turing completeness...) but they're a level "above" normal macros since now you extend the DSL rather than the language lol <euouae>That SRFI will definitely be an interesting read, thank you <dpk>ACTION wonders if the right way to pronounce euouae’s nick aloud is ‘saeculorum amen’