IRC channel logs
2025-05-16.log
back to list of logs
<lechner>Hi, the reader format of SRFI-9 records an acceptable data interchange format? <rlb>wingo: any thoughts offhand about whether fixing the utf8 bug might affect backward compatibility (unacceptably) in 3.x. <ArneBab>wingo: how to recognize in a codebase whether smob mark functions are used? <ArneBab>old: breaking lilypond with guile 4 would be really bad communitywise. <fantazo>ArneBab: more the breakage, more the fun :-] <ArneBab>wingo: please keep in mind that lilypond is the one Guile application that is actually the best tool in its professional domain. If we break that again and either a fix is much slower (lilypond operations are performance critical, because they compile huge, complex songbooks, and slowdowns costs serious development time) this may cause them to pull away from Guile, and that could mark Guile as an unreliable base for good (or rather for bad <ArneBab>… or if a fix takes so much effort that their volunteers can’t get it done fast enough … <ArneBab>Also we still have not merged the Windows patches provided by Lilypond. <wingo>rlb: i think it is just a bug and should be fixed <janneke>sneek: later tell spk121: hmm did you remove "kill" for mingw, how would i kill my daemon that wrote a pid file, can't we get kill back ;-)? <chrislck>just a reminder that gnucash also uses guile a lot for reports .... there's nothing better ;-) and it's stuck on guile-2 on windows <wingo>i finally got guile to run with a non-bdw gc!!!!!!!!!!!!! <binarydigitz01>hey guys, i'm new to guile (and lisp in general). I wanted to ask if there are conventions in naming? specifically I'm currently writing a module that defines private procedures to foreign functions using foreign-library-function, and then create a exported procedure that wraps the foreign function. I wanted to ask how do i name the private function? right now i just lead it with an _ <binarydigitz01>another thing i've been stuck on is naming global variables, in common lisp you wrap the name in *, but i think in guile you start the name with %? are there any resources about naming conventions, or perhaps i've missed a page in the manual... <identity>binarydigitz01: in CL you *ear-muf* (global) dynamic variables, in Scheme those are called parameters, the % is (IIRC) used for global lexical variables <sham1>binarydigitz01: by default, procedures and other similar symbols don't get exported, so it doesn't really need a specific naming <sham1>There's no reason to define _wlr-backend-autocreate using define-public. A define is fine <binarydigitz01>sham1: I just realised my mistake, that's embarassing but thanks! I understand that define works, but i was trying to come up with a naming convention that makes my code more readable. <sham1>I'd say that for example in this case, you could do something like "wlr-backend-autocreate-ffi" <binarydigitz01>sham1: yeah that is 10x better thanks! Also I just realised, instead of making a wrapper procedure, are macros better suited for this? <sham1>Macros would be the wrong thing to use here <binarydigitz01>hmmm why would that be? I was thinking that macros would transform the call to what the ffi procedure would expect based on the parameters <identity>binarydigitz01: if you can do something with procedures, it should likely be done with procedures <identity>also, wlr-backend-autocreate-c (for the C language) may be a clearer name for the ffi procedure <ArneBab>binarydi`: there’s the best-practice "use the weakest method that gets the job done". You can always switch to stronger methods (i.e. macros) if you find that you really need them. <old>ArneBab: I'm sure lilypond can update it's code at some point? <old>I'm sorry to say, but lilypond is not the only user of Guile and the language should not be dictated by a single application usage. as much as lilypond is good in its domain <old>To be clear, I'm not saying that your concern is invalid <old>and if I was in the position of maintaining Lilypond, I would probably have the same arguments <old>anyway, I'm sure the maintainers will take the best decision overall for everyone <rlb>wingo: ok, thanks -- the kind of vague thing I was imagining was if we say wrote the hash values to the .go files and changing the algorithm would cause new mismatches that mattered "or something". <lechner>Hi, is there a more colloquial name for field validators? A search for fender brings up guitars. <old>lechner: sanitize? type-check? <identity>lechner: most frequently i see them referred to as 'sanitizers', like old says <lechner>old / identity / thank you for those suggestions. I like type checker. A sanitizer could also refer to a transformer that, in lieu of a boolean, returns an acceptable cleaned-up value <old>well it depends on what your check is doing <lechner>or maybe the slightly more formal type-predicate ? <old>if you are just checking type, well yes type-checker <old>In blue, we use #:type predicate for slots of class instances <old>the predicate can be anything but it usually just check the type of values <old>but maybe you want more? Maybe you want to check that the number is not negative? That become I guess category checking <lechner>it's really up to the user in my case. type checking is like social media. it's easy to do too much <lechner>since i have you here and we share an interest in build systems, is blue kind of a marriage between make and goops? <old>lechner: blue does not use make <old>it has its own DAG sorter and process scheduling powered by fibers <old>I think we will have a alpha release this summer <old>blue can build itself this way <old>and yes it does use GOOPS extensively <old>I've modify the meta protocol to do cool stuffs with it. True OOP <lechner>old / Hi, do you think we are kind of friendly toward each other and enjoy talking together sometimes? <old>lechner: yes of course! <lechner>old / okay, likewise. i saw a video about OOP some time ago but it's long and somewhat critical. are you interested in taking a look? <old>You can send the link. However, I'm very much busy with work and the kid, so it may takes sometime before I can watch it fully :-) <lechner>old / of course, i'm happy to talk about it with you, but i wasn't looking for that as much as I wanted to share it with you <lechner>how old is the kid? my younger, a girl, is 19 months <ieure>lechner, Fun age! My oldest is 18 and graduating high school. <lechner>wow! yeah, great age. my older is 11 <ieure>lechner, Old enough to know better, not old enough to do better. <lechner>rebellious as can be, but he luckily he joined the Navy. they are doing a good job <lechner>old / the video led me to Guile, via Haskell, and I was somewhat surprised to find object oriented paradigms in Guile <ieure>Any practical language has to be multi-paradigm, and Lisps have had OOP for decades. <old>lechner: my boy (first) is 13 months! <old>Still in a weird phase where feeding can be difficult and not much sleep <ieure>I don't believe OOP is categorically bad. CLOS is honestly an amazing OOP system. <ArneBab>old: lilypond is the application we must not break, because it is the only one that’s actually professional grade and outside the early adopter state in the tech adoption cycle. Keeping lilypond happy is where Guile proves whether it is reliable enough for professional tools. If we decide against that, then we as community aren’t a robust foundation for professional tooling. Yes, they can update their code, but we must make it painless <ArneBab>for them so they don’t balk out. That already almost failed once. <ArneBab>old: I’m not in the position of a lilypond maintainer, but I am a user of lilypond (and it is actually critical for quite a bit of stuff I care a lot about). But that’s not my reason for seeing it as critical. My reason is that I want Guile to actually become the GNU language. <ArneBab>old: and I don’t actually want to phrase this as request. I should phrase this more as a strategic question: if we want to be the GNU language for extensions, then we must prioritize Lilypond. If that’s not what we want to be, then I have to re-evaluate my technological choices, because I need the tools I build upon to not require high maintenance. I’ve been burned badly by Python (lost many, many weekends to python2→3 and python3 <ArneBab>adding keywords, because I built too much of my tooling on Python) and don’t want to experience that again. <lechner>old / congratulations & please don't worry so much! most of the time everything is fine. babies are a storm in the water glass. and they will hit their heads <lechner>ieure / did your eldest apply to college, or did you find something better to do with your money? <ieure> lechner, They're going to do a year of community college to figure out what they actually want to pursue. <lechner>Great, in Calfornia that would be free! <ArneBab>old: that said, I really want to see whippet work out, because the performance improvements it promises can unlock a lot of additional use-cases. So I’ll try to help smooth over work needed with lilypond as much as I can. <ArneBab>(and I’m already excited to ask e craven (space in there to not disturb) for another r7rs-benchmarks run once whippet is in) <lechner>ieure / so we are neighbors of sorts! beautiful state, I hear <ieure>lechner, Whereabouts are you? I live in east Portland. All the Pacific Northwest is gorgeous, I grew up here. <ArneBab>Damn, actually I opened the chat right now not to talk about lilypond, but to say how much I miss Guile at work right now. <ArneBab>I see so much repetition I could reduce in tests if only they were not Python but Scheme, and they would be much easier to review … <ieure>ArneBab, My day job is programming Go, and there are so so so many things an actual good programming language would make trivial. <ieure>My code is littered with // Nested for loops are approximating a reduce over a map <ieure>Generics means we *could* have map/reduce/filter, optional/union types, but those "aren't the go way," Go shops only want knuckle-dragger code. awful <ArneBab>ieure: I feel that … currently for me it’s self.foo_bar_baz = fun("prefix:foo-bar-baz", bla=(murps, burps)) — with lots of iterations of foo_bar_baz and murps and burps the same in most places. Just a local macro that calls define would make this so much nicer. <ArneBab>And this will be hell to refactor if for some function (murps, burps) changes … <ieure>Go is just.... very bad, even for a non-Lisp, and the type system is incoherent. <ArneBab>We really need to get Guile to being widespread enough that people rant about its weaknesses — because they use it in huge applications and feel them ☺ <ArneBab>But right now, I just wish I could use it … <ieure>Well, start by making the error reporting print the file and line containing the error. <ieure>This is a thing that I struggle with *constantly* when hacking Guile. <identity>ieure: well, they set out to make a language that programmers working at google could aprecciate: a bad one. <ieure>It's always (ice-9 boot-9) something something. Extremely frustrating. <ieure>identity, Yeah, I just expected better from someone like Ken Thompson. Guess they can't all be winners. <ArneBab>identity: I think they wanted simple, fast multithreading and being harder to create meta-programming complexity than python. <identity>ArneBab: well, the best way to avoid complexity introduced by X is to not introduce X... <ieure>Anyway, it pays the bills. Last two places (both Clojure shops) laid me off. And I didn't program very much Clojure at either. <ArneBab>ieure: it feels like this shouldn’t actually be too hard: (display (module-filename (program-module open-input-pipe)) <ArneBab>ieure: paying the bills is kind of a superpower in itself ☺ <ieure>ArneBab, I'm sure that works great for straightforward code, but situations where you have, say, macroexpanded code that evaluates a lambda, it's very difficult to tell where the actual problem is. <ieure>ArneBab, 100% of my experience here is hacking on Guix and getting errors that contain 0% useful information about what went wrong. <ArneBab>yes … can’t get it perfec, but it would be great to have fewer of those uninformative errors. <lechner>ieure / What do folks use Golang for these days? I thought it was originally billed as a systems language intended to replace C (and libc) but then it got all fancy. Are you writing tooling or real applications? <lechner>As for Guile error reporting, that's got to be the number one hurdle for adoption. The REPL is great but the erroror messages are terrible. Somewhere there is a Scheme that gets it right, I heard. Maybe Chicken? <ieure>ArneBab, Yeah, I mean. I don't really know what the issue is. Just that, having written nontrivial amounts of Clojure, Common Lisp, and Emacs Lisp, Guile's error reporting is *by far* the worst of any of those. It's not even close. <ieure>lechner, Go's general-purpose and used for a lot of stuff. I don't think it makes a very good systems language. Both my Go jobs have been large web application backend systems -- APIs and business logic orchestration. <ieure>But stuff like Forgejo is written in Go. So's Syncthing. <dsmith>there are plenty of worse things than go. <ieure>Sure. But also many better things. <ieure>I don't think I would for most stuff, but it depends on the application. <ieure>I will say: I loathe Go's make-the-dev-manually-unwind-the-stack-everywhere error handling, but it is better than C errno (though this is an extremely low bar). GC is also very good. <ieure>But there's a lot of extremely wacky design decisions that seem to be poorly thought out, which require more complexity to deal with than the complexity of the thing they wanted to avoid doing. <ieure>Like using capitalization to designate exported symbols instead of... literally any other approach. <ieure>Which means that now you can't have a Go struct that roundtrips through JSON in a way any other system can cope with. <ieure>So they added "field metadata", which is literally just a string you stick next to the field definition in the struct, which has its own syntax that gets parsed. <lechner>your evaluation seems so incongruent with the way Golang was originally sold, i.e. with Ken Thompson <ieure>It's very poorly thought out, and every hold-my-beer design decision interacts badly with some other part of the system, making it less than the sum of its parts. <ieure>The stdlib is also very minimalistic and parts barely work at all, or provide so few affordances that they may as well now. <ieure>Like, it has a CSV reader -- but the only thing it can give you is slice-of-slice-of-strings, it cannot convert, or unmarshal into a struct, or tell you if a line is a header. <lechner>well, i'm sorry you are so frustrated. it must be hard to be talented programmer caught up in an imperfect languge, but like dsmith said it seems it could be worse <ieure>So you have to write a ton of junk to actually use it. <ieure>Or the XML library, which doesn't correctly handle namespaces, and cannot be made to do so without a from-scratch rewrite by someone who actually knows how XML works. <lechner>ieure / i don't mean to open a can of worms for you, but libguile integrates by design nicely with lots of other languages. Can you call it from Golang? <ieure>Sure, yeah, I just feel like I'm taking crazy pills when people are fanatic about Go (many, many people are) and it's this... thing. <ieure>lechner, Go has FFI, but it's extremely slow. Also, that stuff would 100% not fly in a corporate production environment. <lechner>my speed experience with Guile has been good but I get the corporate angle <ieure>It's fragile code nobody else would be able to maintain. <lechner>other language seem to have even more migrations <ieure>I don't know if Guix is exceptionally huge or Guile is slow, but compiling Guix takes a shocking amount of time. <dsmith>I *do* like go's cross-compilation. Effortless <lechner>i am not sure Guix evaluates derivations in parallel <ieure>lechner, I'm talking about `make' in the Guix source repo; just compiling Guix itself. <ieure>It takes ~20 minutes of my laptop with the fans spinning up. <lechner>it's the monorepo. when i make changes to my channel the pull is done in twenty seconds <ieure>lechner, I still think we might be talking about different things here. <ieure>lechner, The pre-push commit hook in the Guix repo builds everything, to make sure it builds, so I do this all the time. <lechner>ieure / that's your personal hook right? I would work off of a fork and only push something after I have used it for a while <ieure>lechner, No, the guix repo has hooks all committers have to use, that's one of them. <ArneBab>ieure: keeping compile times low was AFAIK also a goal of the design of go. Look at the compile times of C++ template code … <ieure>ArneBab, Yeah, it depends on the project, but it is a pretty fast compiler. I've heard that many of the things I dislike (like capitalization for export) are to make the compiler faster. <ieure>Unit tests still take forever, though. <wingo>well there are heuristics to tweak, but --with-gc=heap-conservative-parallel-mmc has at least ran a few things for me <ArneBab>ieure: keeping unit tests fast is the responsibility of the devs … <ArneBab>⇒ need to complain to your co-workers ☺ (or better: organize to get them faster …) <ieure>ArneBab, It's a Sisyphean task, because the number of unit tests to run is ever-increasing. <ieure>No matter how much time you spend making the ones you have fast, they will continue to get slower, because the number increases. <ArneBab>ieure: we have a (soft) rule at work: compilation and unit tests may not take longer than 15 minutes. Too long unit tests must be optimized or become integration tests. The integration tests are at <30 minutes. But we have people who regularly optimize that. <lechner>also, with the weekend around the corner I'd like to extend my sincere thanks to the Guile developers for that gem of a language/compiler/linker/garbage collector or whatever you've been working on <ieure>lechner, There are plenty of optimization techniques you can apply. Probably the best bang for the buck at this shop is making everything independent and running the tests in parallel. <old>ArneBab: Guix is also an application is used professionally. And we should not restraint the possible performance improvement that Guix could get because of Lilypond. I don't see why lilypond could not just rewrite some code. It's not like a breakage between python2 and python3 <ArneBab>old: Guix is still in early adopter stage. And the point with lilypond is that this is also huge and we cannot estimate how much time it costs the devs — who are also volunteers — and should both ask them and minimize the effort. <ieure>lechner, But you're optimizing an O(n) problem where n guaranteed to increase. Have seen this over and over, at every job that cared enough to have unit tests. It's a sawtooth wave function: tests get slow, you dump a couple weeks into making them fast, more tests makes them slow again, rinse, repeat. <ArneBab>ieure: yes, I think you can’t avoid that. It’s how you *stay* good. <ArneBab>old: do you know whether it’s an hour of work or months of work for lilypond to adapt? <ArneBab>Same for me. And that’s something we should really change … <old>But if wingo managed to keep the API unbreak and we have whippet, I'm all for it <ArneBab>wingo: how certain is it that the mark function has to go? And how similar is the replacement performancewise? <old>But if because of that, whippet is not the default but a "turn on" knob at runtime, then I'm not that favor <old>lechner: I did actually listen to this OOP video once. I think I've also started scheme close to that date <ArneBab>old: if activating bdw-gc stays a knob at runtime, then the first option could be to toggle that from lilypond. <rlb>The switch to utf8 is also going to have its effects -- i.e. some code may need to be rewritten to still perform well enough, but that's also something we might be able to help with, one way or another, in some cases. <old>rlb: can't be worst than Python2 <ArneBab>string operations are critical for lilypond … <old>gosh I still have nightmware of that epoch <ArneBab>Python2→Python3 broke two of my projects for good … <rlb>old: this is a perf issue not a "just completely broken for a while" issue. <old>Python literally break on minor version bump. It's crappy runtime <old>rlb: because of variable length encoding? <rlb>Main thing is that (fine grain) string mutation should generally be avoided in favor of other approaches. <ArneBab>a perf-issue is a breaking issue for lilypond. That was one of the problems with Guile 2.0: lilypond became unusably slow for real users. <rlb>We'll have reasonably fast O(1)-ish (for some version of 1) lookups, but mutations are just going to be expensive. <old>well we should avoid mutation at all when possible so I guess it's good time to refactor codes that do mutation <rlb>But I get the impression that many languages and scheme's have favored similar tradeoffs now. <ArneBab>(can we just benchmark lilypond with the old and the new?) <rlb>It's *possible* that we might maintain an internal hybrid that allows ascii-only strings to have real O(1) mutability, but I'm hoping we don't end up there, given the complexity, etc. <ArneBab>maybe first benchmark lilypond (and maybe GNU Cash: I think that also does lots of string stuff) before taking that decision? <rlb>ArneBab: I'll have to double-check more carefully once/if anyone starts reviewing the utf8 work in earnest, but I think most of the public api is the same -- but it's been a year or more since I mostly finished it up and I'd have to refresh. <rlb>So far the people who have tested it have I think found things the same or faster. <rlb>And I ran the scheme benchmarks, they were promising as well. <rlb>But if your code depends on fine-grain string-set!, that's probably going to be trouble. <ArneBab>rlb: did you get in contact with GNU Cash devs? They may have a vested interest in testing. <old>I'm pretty sure we can achive good performance with mutable utf-8 strings. If emacs can .. <rlb>I haven't, but I also vaguely suspect we're a good way away from any prospect of deciding about it. <ArneBab>I’d start with GNU Cash before talking to lilypond folks, because some over at lilypond may still feel hurt from the bumpy 1.8 to 2.2 transition. <rlb>old: I suspect emacs may be doing something quite different much of the time, data-structure wise, i.e. wrt editable buffers, string properties, etc. <rlb>I had the impression that for our core scheme strings, we probably don't want more flexible multi-part editing-optimized string structures, <ArneBab>rlb: I guess that you’re right with that. <rlb>ACTION vaguely recalls someone may have pointed him to srfi along those lines... <rlb>(for an editing api) <rlb>(...hmm, or maybe I'm making that up.)