IRC channel logs
2025-05-15.log
back to list of logs
<daviid>trannus_aran: did you solve your instance intialization problem? in case it helps, here is an example - https://git.dthompson.us/starling/tree/starling/node-2d.scm#n163 for the <camera-2d> class definition, then below, lines 175-181 for a specialized initialize method for <camera-2d> instances, which sets one of its slots dependeing on the value of another ... <lechner>rlb / thanks for explaining! great catch <trannus_aran>daviid: what I don't get though, is how that override of the default initialization doesn't mess up object instantiation more broadly (aka, why initialize-instance overrides in CLOS use the :after keyword) <trannus_aran>like is that what the `(next-method)` call is doing there? <daviid>trannus_aran: you need to call next-method yes, but you could decide (have to by design) spit the initargs first, or not ... but as the default initialize method calls alocate, you need to call next-method, whether as the first call or after some 'pre compuation' is up to your project needs <lechner>Hi, is there a character on a regular keyboard, please, that can do double duty as a lambda if one squints really hard? <wingo>lechner: the traditional answer is \, as in haskell et al <wingo>hello, i am trying to inventory users of the smob mark interface. i know of gnutls, and also i know of a use in guile-gnome <wingo>anyone have other references? (civodul?) <wingo>ideally i would like to be able to ripgrep over all sources in guix :) <wingo>gnutls apparently doesn't use smob markers any more <wingo>ah no, it's just that guile bindings moved to another repo. they still use a marker <civodul>wingo: hi! that one smob marker in gnutls is probably unnecessary, i’m surprised it’s still there <wingo>it certainly seems insufficient -- i.e. if the gnutls_session_t can outlive the SCM session, then having the SCM session mark the session_data from the gnutls_session_t is insufficient to keep the session data alive <wingo>dunno, perhaps there is some other invariant making the SCM session outlive the gnutls_session_t in all cases <civodul>understood, that’s not the goal here, i think it’s just a leftover <wingo>however i don't see where the session data pair is otherwise referenced from the heap graph <wingo>so i think the mark function is probably necessary <wingo>if possible it's best to just store this sort of data directly as another word on the session smob <wingo>anyway anyway -- thinking about whippet and smobs and such. we managed to mostly eliminate smob mark functions in the ~ecosystem~, but never deprecated the mark facility per se <wingo>ah if that is the case, cool :) hard for me to tell with the generated code ;) <civodul>ah no actually it’s probably needed because of the gnutls_session_get_ptr thing <wingo>anyway what i was saying is that on wip-whippet i am going to remove smob mark functions. <wingo>as long as the, like, 4 users of smob mark functions are able to talk with us to figure out some alternative, we will be ok. <wingo>civodul: ok just for the record: for gnutls sessions, there are three objects in play, the SCM smob, the foreign gnutls_session_t, and the SCM session data. AFAIU the deal with the session data is that sometimes you get a callback with a gnutls_session_t and you need to get a SCM from that, and so we stash a reference to the SCM session data in the foreign session object. <wingo>currently the SCM smob marks the session data in its mark function. the smob outlives everything else because session smobs have a finalizer, and the finalizer keeps the smob alive, and the finalizer kills the foreign session. so, ok there. <wingo>to remove the mark function, i think the right thing is to set the smob itself as the session data, make the smob a double smob, and put the is-fd? and record-port objects in the two extra words of the smob <wingo>that will work with all guiles since 1.8 <mdj>wingo: Lilypond uses scm_set_smob_mark in lily/include/smobs.tcc. As you know, Lilypond is important. <mdj>I'm a bit worried about removing the mark facility. I know that I've used it a lot in Guile's role as an embedded language. Note that we risk pissing people off that use Guile for stuff that are not necessarily published. <mdj>Why do you want to remove it? <mdj>(BTW: In Lilypond, they use a member function "mark_smob" throughout the code.) <lechner>Hi, would the caret (^) be acceptable as a non-traditional stand-in for a Lambda in ASCII, please? <wingo>mdj: basically, the mark interface is slow, almost impossible to use correctly, and doesn't allow for evacuation. slow because it has no thread-local mark worker context. impossible because (a) mark functions can run on objects on internal bdw freelists (b) mark functions can run on partially-constructed objects (c) mark functions can run in the middle of non-atomic modifications to object state <wingo>and for evacuation, you want them to mark locations, not objects <wingo>what's more, with bdw they are almost never necessary; you can usually arrange things so that bdw will be able to see all object references <wingo>the "impossibly to use correctly" isn't just paternalism, i.e. "i know how to use them but users do not"; rather, i am as much of an expert on them as there exists and i still make subtle bugs when i write bdw mark functions that usually i catch much later <old>if this is a major bump to guile 4 with whippet, why not breaking the API then <old>just remove the interface if its problematic and nobody use it and it's a major bump <old>hell, jsut the major bump should be enough to make that decision <old>maybe it's time for a more thorough clean up in Guile if version 4 is happening <identity>lechner: arguably backslash ('\') looks closer to a lambda <wingo>generally speaking we try to avoid breaking api without a deprecation cycle <old>I understand that. but a major version bump usually mean API breakage anyway no? <old>anyway, it's just my 2 cent. Having to keep compatibility with Guile 1.8 when we are heading to 4 seems far fetch <mdj>Can we provide something more safe and fast, for example something declarative, that doesn't require a complete reorganization of data structures for users? <lechner>identity / thanks! I'm trying to tie a bunch of things together for a shell integration helper I'll share here soon. The backslash \ is a quoting character in Bash and other shells. Of the three alternatives caret ^, equal sign = and at sign @, the folks in #bash said the caret is least likely to interfere with shell functionality <rlb>wingo: were you planning to do anything about that latin1/utf9 cmp issue? If not, I might later -- i.e. if you think utf8 might only go into a 4.x, then we might want a fix for 3.x. <rlb>Though I haven't even thought yet about whether it might cause unacceptable "trouble" to fix it, i.e. could fixing it break existing .go use somehow, or... <lechner>Hi, what are favorite abbreviations for the term S-expression, please? Do you like sexp or sexpr? Or maybe something different? <ieure>Or s-exp if saying "sex" makes you uncomfortable. <wingo>rlb: i fixed that particular bug on my branch, but haven't poked it on 3.x <trannus_aran>anyone else here going to the european lisp symposium on the 19th-20th? :) <wingo>i would love to but i have other obligations <dpk>i am, and trannus_aran and i have already arranged to hang out :-) <niklauzg>Hiya folks, does Guile have existing or planned type annotations or contracts? I ask because as a learner I believe it'd be helpful to me. <niklauzg>(Helpful in using Guile to compose with increasing sophistication) <identity>niklauzg: i do not think so, but at the very least, you can add something like (assert (expected-type? input)) at the top of your procedures