IRC channel logs

<rlb>TIL -- #f as a template-id for datum->syntax :)

<RavenJoad>I am toying with GOOPS right now and am struggling to get something simple done. I have two classes <super> and <child>. <super> has a name slot that defaults to "Default". I want instantiation of <child> to set <super>.name to "Child".

<RavenJoad>I have toyed with defining initialize and make for <child> and neither worked. After both possible definitions, I have (get-name (make <child>)) evaluate to "Default".

<RavenJoad>Now, (get-name (make <child> #:name "Child")) evaluates to "Child", which is what I expect. I want to avoid needing to provide the #:name field when initializing the <child>.

<lloda>was looking at bug 69921, do the source parameters to eval-string do anything atm? for example if i do (eval-string "(+ 'a 1)" #:file "custom.scm" #:line 4 #:column 3)

<lloda>the backtrace says 'In unknown file: 1 (+ a 1)'

<RavenJoad>I have two classes <super> and <child>. <super> has a name slot that defaults to "Default". I want instantiation of <child> to set <super>.name to "Child". I want (get-name (make <child>)) to return "Child", without me having to manually do (get-name (make <child> #:name "Child")). If I do not manually provide the name, then I get <super>.name's default initialization value.

<RavenJoad>I have tried implementing custom make and initialize methods, but neither seems to be working. Does anyone have suggestions or pointers to code that show how to do this?

<dthompson>RavenJoad: you'd have to define the same slot in the child class with the new default

<dthompson>or get a little more meta and have the default as a class slot or something

<RavenJoad>So there is no rough equivalent to "protected" inheritance of slots, like C++ or Java has?

<dthompson>the child inherits the slots of the super

<chrislck>sneek: botsnack

<sneek>:)

<chrislck>weird coming this channel and seeing this ^ comment out of context

<dthompson>lol

<RavenJoad>dthompson: That is what I assumed (otherwise what good is inheritance). But setting a field in the parent class requires re-declaring it in the child? Just so I can set the slot at an object's construction time?

<dthompson>talking about GOOPS

<chrislck>:)

<dthompson>I'm confused now. is this an instance slot or a class slot?

<RavenJoad>I want this to be an instance slot. I will define multiple subclasses of <super>; <child1>, <child2>, and so on. Each one should override the default value of the name instance slot in <super>.

<dthompson>so yeah the way to do that is to override the slot

<dthompson>specify a slot of the same name in the child with the new configuration

<RavenJoad>Ok. Just to be clear, there is no way to set this name slot in the <childX> classes by providing a custom implementation for initialize?

<dthompson>RavenJoad: you can do anything in initialize, so no that's not correct

<RavenJoad>Ok. It is just easier and more GOOPS-y to just override the name slot?

<dthompson>that's one possible way, if it works for you.

<RavenJoad>So I can explore, is there a GOOPS codebase somewhere that uses GOOPS' MOP to override methods like make and initialize?

<dthompson>I don't have any great examples to point to

<dthompson>I usually look at CLOS projects and see if GOOPS can do the same

<dthompson>sometimes it can, sometimes it can't

<RavenJoad>That's a good point. I'll ask on some Common Lisp places and see if they can point me somewhere. I have been consulting the manual, but its section on instance creation using MOP is not very clear.

<dthompson>here's a random thing of mine that does some MOP stuff https://git.dthompson.us/catbird/tree/catbird/cached-slots.scm

<dthompson>no real substitute for reading the goops source to figure out where to extend things

<dthompson>the manual helps with the high level stuff

<RavenJoad>Thanks for the link! I'll look over the initialize method specifically and see if I can decipher how initialize is supposed to work. Yeah, I was really hoping I did not have to read GOOPS' source, but oh well.

<dthompson>RavenJoad: oh yeah I also wrote this blog post about the issues I have run into with GOOPS https://dthompson.us/posts/issues-with-object-oriented-programming-in-guile.html

<dthompson>working to improve GOOPS is something I'd like to do but something I never get around to

<RavenJoad>I actually came across that GOOPS post of your's last night while trying to search for a solution to this issue. Fortunately, I am not trying to do something (seemingly) as complicated as what you were doing.

<ArneBab>dthompson: I now linked your tutorial on https://www.draketo.de/software/guile-fast — it’s really cool to finally have a practical guide I can look into to see what I can improve!

<dthompson>ArneBab: cool :)

<old>Hey I was wondering the other day, I think that guile now support utf-8 by default right? i.e., strings are all utf-8

<old>and so string-ref now become a O(n) operation instead of O(1)

<old>but it would be possible to cache the character indexes in a bitmap

<old>string-ref could then be O(1) again with some little memory overhead

<dthompson>after learning much about strings while working on hoot, I think string-ref/string-set! are outdated interfaces that should be avoided in new code. better to use string ports and stuff.

<dthompson>random access strings are a thing of the past

<old>like using an iterator?

<old>that make sens for this kind of access pattern, but there are still valid random access like sub-string

<dthompson>also iteration

<mwette>looking forward to the roll-in of rlb's utf8-string update

<old>dthompson: can you point me to a procedure that do that kind of iteration?

<old>I do not often use string other than string=? and prefix

<dthompson>old: call-with-input-string + textual input procedures

<old>ah okay so working with port

<old>Wondering if there could be any performance issue here for heavy string manipulation, even though it is an excellent abstraction

<dthompson>in hoot we defined substring in terms of string-copy and that is implemented with wasm stringref iterators https://gitlab.com/spritely/guile-hoot/-/blob/main/module/hoot/strings.scm?ref_type=heads#L110

<rlb>dthompson: if we do decide to adopt the utf-8 stuff I messed with, we still get O(1) ish (with a larger constant) for references via scaled-resolution sparse indexes for utf-8 strings, and direct indexing for ascii-only, but fine-grain mutation is roughly O(n) (with iirc (been a while since I had it all in my head) an option to keep it O(1) for ascii with extra implementation complexity if we like).

<rlb>I *think* I mostly started leaning away from in-place modification, even for ascii strings, but I've overhauled/reworked the proposal/code so many times, I'd have to go remember where the current version landed on that front :)

<rlb>At the moment, I'm just waiting to see if it looks like we do want to pursue it, and then I'll be happy to swap it all back in. i.e. the current branch is ready for consideration, and I assume will need adjustments once reviewers can tell me what we'd prefer on a few fronts.

<dthompson>rlb: hey very cool! sounds like good stuff to me

<freakingpenguin>me: hmm I think I'm understanding the fundamentals! rlb: scaled-resolution sparse indexes

<freakingpenguin>The rabbit holes never end

<dthompson>I know what a sparse index is but that's about it :)

<dthompson>sounds good and computery

<mwette>rlb's string update reduced the overall execution time of a large example ffi-helper run by 20%; the run uses a lot of reverse-list->string as well as a lot of read-char and unread-char

<rlb>wrt sparse -- we just append an "index" to each utf-8 string that indicates the byte offset of every Nth char, where N is compile-time configurable (the stride, maybe 32 right now?), and the index element type is chosen based on the string length, i.e. u8/u16/u32, depending on what's needed for the largest offset.

<rlb>So to find a given char, you look at the index, jump to the nearest offset, and then iterate forward no more than "stride" characters.

<old>rlb: wouln't a bitmap more compact and fast?

IRC channel logs

2024-03-21.log