Hi All,

I have just found two messages on the Cairo mailing list. In order to simplify maintenance they plan to drop some of the backends. And switch from Autotools to Meson (Python based build tool).

Since Racket relies on Cairo I thought it were a good idea to draw attention to the change. However, I don’t think the dropped backends affect us(?). Although I am unsure whether Racket uses the Cairo GL backend for anything.

Note that the Emmanuele writes this about the Quartz backend: [1]: Provisionally; the performance of the Quartz backend on modern macOS has degraded to such a point that it's literally faster to draw on image surfaces. ~That is, I think, he would prefer to drop support for the Quartz backend in the long run.~ ~(If a CoreGraphics backend existed it would make sense to drop Quartz - but there are no CG backend).~ I still think, he means the Quartz backend is slow (slower than a direct GL backend), but Quartz is part of CoreGraphics not an alternative.

For 1.17.8, the plan is: - clean up the repository - remove old documentation files - move documentation to Markdown - consolidate boilerplate/build gunk - Meson parity with Autotools on Linux, Windows, and macOS - drop the Autotools build - drop the known broken/unmaintained/abandoned upstream backends: - drm - qt - beos - OS/2 - cogl - directfb - OpenVG - put the GL backend "on notice" - if somebody shows up and is willing to review and fix the issues, we can keep it; otherwise, it goes The initial proposal of changing release management: https://lists.cairographics.org/archives/cairo/2021-April/029218.html The plans for 1.17.8. https://lists.cairographics.org/archives/cairo/2021-May/029251.html

I also read this discussion on the Cairo list a few days ago. While I know nothing about Cairo’s internal architecture my two areas of concern were:

• The main problem with the GL back-end (apart from being unmaintained) is that the Cairo architecture is not suited to GPU based rendering. This makes the GL backend difficult to write and less performant than it could be. • If I understand correctly Emmanuele (the person who wrote the initial email) volunteered to take over the build management because the GTK libraries still rely on Cairo and they are several years away from removing the Cairo dependency (they are however actively working on that). He just wants the Cairo build to work well with the GTK build system. I would be very happy if someone would tell me that I am 100% wrong on both of the above points.

I got the same impression as you.

While reading some older mails on the mailing list, I notice that there is work on a Cogl backend, which is a low-level api with a GL backend (if I understand correctly). https://developer.gnome.org/cogl/1.22/

morning all, for the emacs user, is there a way to show and navigate to the errors in code (with racket-mode)?

racket-xp-next-error C-c # N Go to the next error. racket-xp-previous-error C-c # P Go to the previous error.

The easiest is usually to click the filename (the first line of the error).

yes, it doesn’t work, the first line of the error is always: “build-path: absolute path cannot be added to a base path”

(it’s on windows btw)

so i know i’m playin with fire lol

and then the C-c # N and P don’t do anything

Do you have a screenshot?

sure

whatever the error it always shows that

So, this is a runtime error, right?

yes it looks like

yes it is

when I C-c the program

I am confused - is this an error in racket-mode? (not in your code?)

it’s in the repl while C-c C-c my code

to run it

Is the call to build-path in your code?

no

Then I think it is a bug in racket-mode.

makes sense

I’m gonna see if I can find some info about that thanks

Maybe @greg knows more?

I have to develop on windows since it’s the target OS and want to make sure it’s gonna work for it

You can find out by running that file in DrRacket - if you get the same error, then the problem is yours :slightly_smiling_face:

yes it works fine in DrRacket

emacs on windows is already shady, and + racket-mode… lol

As someone not that well-versed in Windows, is your Emacs a normal Windows application, or is it running in WSL or similar?

normal windows app

could be a long path issue, gonna move the directory directly under c, let’s see

Around line 207 in error.rkt:

ah yes

gonna play with that, see if I can fix

thanks a bunch, i’ll update

https://github.com/greghendershott/racket-mode/blob/master/racket/error.rkt#L209

moving to a shorter path doesn’t fix it

I think the first path ought to have been “manage_dialog.rkt” only. A filename can be added to the base path just fine.

yes in there:

; absolute path: "\Users\Patrice\dev\racket\seassist2\manage_dialog.rkt" ; base path: #<path:c:\Users\Patrice\dev\racket\seassist2&gt;

there’s something fishy in the way those paths are shown

Maybe it due to the note in blue?

I think, the (not (complete-path ...)) is used to determine whether the path is relative. And if it were relative, then the build-path would have worked.

yes, makes sense

i’m in that code, let’s see if I can fix

It might be that complete-path? should be replaced with absolute-path? there. Or it might be it should test that both aren’t true — unless the path is neither absolute nor complete, just use it as-is.

The “other end” might be relevant, too. Why is the original thing "\\Users\\Patrice\\dev\\racket\\seassist2\\manage_dialog.rkt" without a drive letter. If it had a drive letter — if it were both absolute and complete — then IIUC it would work fine, too.

I have to run soon and can’t look at this in detail now, but if you’re able to figure out some things, that would be great, thanks, and I’ll catch up later.

thank you greg, i’m out right now but i’ll work on it later and will update

yes, I confirm, just returning ‘s’ like so:

(define (complete-paths s) (displayln (string-append "s=" s)) #\| (regexp-replace* #px"([^:]+):(\\d+[:.]\\d+)" s (λ (_ orig-path line+col) (~a (or (and (not (complete-path? orig-path)) (existing (build-path (current-directory) orig-path))) orig-path) ":" line+col))) \|# s)

fixes the issue

so gonna dig more on how to fix the rest of the function, pretty green with racket so no guarantee :slightly_smiling_face:

https://github.com/greghendershott/racket-mode/issues/537

I’m gonna work on it later today, it’s a good exercise actually, and will update here and on github, awesome work with racket-mode btw, didn’t realize you were the author

did a quick test, just changing complete-path? to absolute-path? fixes it

not sure about regression (for other OSes) but this issue is gone

I have a C library that allocates a data array. At the Racket side, I’d like to make it a u32vector. The docs has a u32vector->cpointer, but does not have the opposite.

The implementation of u32vector simply wraps the pointer with a length in a struct named u32vector. But make-u32vector is not exported (as far as I can tell).

Is there a way to trick the system, so I can make a cpointer->u32vector ?

https://github.com/racket/racket/blob/master/racket/collects/ffi/vector.rkt

Or (hopefully) I am missing something simple?

Worst case, I suppose, I could make an empty u32vector and then use ptr-set! to chance the two fields. Feels a bit too hacky.

In the meantime, I will use make-cvector* .

Anyone know of a good alternative to Levenshtein where a greater emphasis is put on characters at the start and matching characters? For example, let’s say I have the following two strings: “go” and “dlang”. Now I compare “golang”. Levenshtein will match closer to “dlang” than to “go”.

Can you “cheat” and give “ggoo” “ddlangg” and “ggolangg” to the Levenhstein algorithm?

lol. that’s interesting

this is input from a user, so doing things like that likely aren’t reasonable

how come minimal racket is not linked for the 8.0 releases?

https://download.racket-lang.org/all-versions.html

@jestarray the download page was reorganized for 8.0

Jaro-Winkler gives weight to a matching prefix. I imagine you could modify it to do the same for a matching suffix.

Probably we should change that page to link to the “all variants” page for 8.0 and up.

thanks for the info

Oh, I didn’t read that very closely and thought you meant “start and end.” By “matching characters” do you mean exact matches in the same positions?

Yeah, but that’s overall less important than matching the start

I actually have implementations of a few string similarity metrics. Standard J-W will still consider “golang” and “dlang” more similar than “go” and “golang,” but you could adjust the weight of the prefix match.