Lo all… is there a way to render text in pict/draw, and get the locations of the individual glyphs? I’d like to animate some expression transformations, and I need to micro-manage moving phrases around.

@tim986 Possibly get-text-extent? https://docs.racket-lang.org/draw/dc___.html#%28meth._%28%28%28lib._racket%2Fdraw..rkt%29._dc~3c~25~3e%29._get-text-extent%29%29

I had that in mind, but dismissed it out of hand because I thought it would just give me the extent of the full text (and not help me identify glyphs at locations)…

Thanks for pointing me back at it… offset looks useful to me, wanting something like: (send a-dc get-text-extent (substring s (add1 offset) #f #f offset)) (out-by-one error guaranteed)

Is the IRC still live? Does rudybot live here?

Is there an equivalent to Python’s defaultdict(factory) type in Racket? That is a mutable hashtable that calls the given factory when accessing keys not previously used. I can say hash_hash = defaultdict(dict) hash_hash["first"]["second"] = value

That avoids having the check if "first" not in hash_hash: hash_hash["first"] = {}

(hash-set! (hash-ref! hh 'first make-hash) 'second value)

I sometimes stick this in a function, but I think it’s clear and clean enough as it is.

Functionally: (hash-update h 'first (lambda (h-first) (hash-set h-first 'second value) hash) Or currying the update function? (hash-update h 'first (curry hash-set 'second value) hash)

Wow, why didn’t I think of that..

Honestly, the hash-set!/hash-ref! is what I would do… although there is a mutating hash-update! which I’m sure is better.

I have a class inherited from a canvas%. I tried to change the cursor with (send this% set-cursor ’hand). What’s the right way to do this?

2 things wrong? this% is not the correct object and ’hand should be (make-object cursor% ’hand) ?

@steveh2009 this% is the object’s class, this is the object

and yes, you need a cursor% object: the docs for set-cursor say cursor : (or/c (is-a?/c cursor%) #f) so it needs an instance of cursor%, or #f to inherit the cursor from the parent window

This is a good question IMO: https://stackoverflow.com/questions/56764556/is-there-a-way-to-specify-where-raco-should-install-a-package

I have kinda the same problem. In my computer, I have rosette-devel installed, which provides #lang rosette. I want to install ocelot, which has rosette as a dependency. So the language name collides, and the transitive installation of rosette fails. So:

• If I want ocelot with fresh rosette while maintaining rosette-devel, how can I do that?
• If I want ocelot with my rosette-devel, how can I do that?

I know there’s package scope dir, though I don’t know how to use it and whether if it’s the right solution.

> this is nice as it allows multiple versions of a single package to coexist nicely Is that nice? I mean, it’s nicer than incompatible versions of a package conflicting. But it’s not as nice as successive versions maintaining backward compatibility.

I feel like rosette and rosette-devel as separate packages is the root problem here. If it’s “devel”, it shouldn’t be on the package manager. (I realize I’m being kind of dogmatic, but, I’m weary of tilting at the same old windmills.)

@samdphillips Cool! Thanks for your help with the wrapper function :slightly_smiling_face:

@greg or at least, instead of maintaining backwards compatibility, breaking changes should be gradual and the package owner should send pull requests to migrate other packages’ code

In my experience, it’s completely unmaintainable to never break backwards compatibility. That just makes me end up with a bunch of dead code and confusing names for things.

A package can provide an additional, new module with a new design/interface.

If that’s too challenging, because the design delta is too big and hairy, then I think it’s OK to say “Welp the old package X is ‘frozen’ and won’t get even security fixes much less new features. And, we have a new package called Y”.

Especially for open source where someone isn’t even paid by an employer to do the work, there’s no obligation to keep maintaining something. Of course that’s fine. And of course sometimes backward compatibility breaks, by accident. And gets fixed again. That’s life. I’m just saying, please don’t break things on purpose. ¯_(ツ)_/¯

Why would you even

A new module means new names, which is a big cost

New module name, same definition names.

Definitely don’t break things on purpose, yeah

Yes, I think new module names are a big cost

Oh. OK. I didn’t appreciate the cost, but I admit it’s probably bigger than I realized.

I think my position is: if you don’t want me to break you, you need to give me some way to avoid breaking you. That can mean putting your code in a package on the catalog so I can know it exists and depends on me, or sending me a link to your open source project, or just sending me an email telling me you’re using my code in your private project. I’m just one person with a full time job, so my maintenance budget is very limited.

I really need to document that policy