@lexi.lambda’s 2018 strangeloop presentation on Hackett was the most persuasive argument I’ve seen as to why you’d want powerful macros as a Haskell programmer:
@wanpeebaw The cpu loads for regex-redux looks odd.
In the other benchmarks the cpu loads for BC and CS are similar.
A vim plugin formerly written for clojure is rewritten for racket now
He was using traditional Chinese, simplified Chinese is more popular now
@torsten.grust has joined the channel
Hi everyone.
We’ve just started a new semester here at U Tübingen. Almost 700 new Racketeers incoming.
Some of our students see a bytes->string/locale: string is not a well-formed UTF-8 encoding error with Racket 7.8 on Windows 10 when they try to open/save .rkt files.
Is this a problem with a known workaround?
Might 7.9 fix that?
I recall an earlier report: https://groups.google.com/g/racket-users/c/ewvudAxrAtI/m/8B0CPBgaBwAJ Unfortunately, I don’t recall a resolution; I don’t think we figured out how to replicate or fix the problem, yet.
Uh, thanks, Matt. That could turn out to be a major problem this semester… let’s see.
One thing that puzzles us is that it does not appear to be a new problem, since old versions have the same problem (according to the previous report). So, both the problem and the reason people are hitting it now remain unclear. In any case, if anyone can figure out how to replicate the problem, that will help a lot.
Same problem with Racket 7.9, by the way.
Here’s something to try: change “collects/racket/private/path.rkt” adding a line between 27 and 28: s #; I’m curious whether that changes the error message. My guess is that it could change the error message, but it’s unlikely to allow a file to be opened.
I am unclear from previous reports on whether it’s a problem with the file dialog, or a general file-opening problem. I wonder, for example, when dragging a “.rkt” file onto DrRacket opens it successfully versus selecting a “.rkt” file from a file dialog.
I’ll have the student try that. Thanks!
By the way, this also affects saving new files.
Thanks for that. Along the same lines as above, I wonder whether saving works if an existing file is opened (possibly by drag-and-drop), modified, and saved — that is, avoiding the file-save dialog.
No luck with drag and drop. Same error message.
btw I just tried and it is very, very nice, exactly the sort of tools I was hoping to find in the racket/list world
That suggests that places scale a little less well on Racket CS, which is not that surprising to me.
might be that futures would work better on Racket CS for that benchmark since using regexps might be future-safe
It seems like on Linux, the Racket GUI library uses Control-Y for paste instead of Control-V as it does on Windows. Is this a common keybinding for GUI applications on Linux? Also, can this be changed at Racket GUI level (instead of updating every text field?)
Someone reported this issue for my application, but I am not familiar enough with Linux to tell if this is an issue or not: https://github.com/alex-hhh/ActivityLog2/issues/53
Ctl-y is emacs-style, and yes I would very much prefer Ctl-v instead, which is what most modern GUI tools use anyway.
I guess my question is about the GUI convention on Linux. Modern GUI tools do use Ctrl-V on windows, but on Mac OS they don’
don’t. They use Command-V
Yes, that’s what i’m saying. Ctl-v is very common for ‘paste’ in GUI tools on Linux (Ubuntu at least).
(even the default, basic calculator uses Ctl-v)
I’d be happy to have Ctl-v be the default for paste on linux, as changing the keymap is cumbersome
I could not find where Control-Y is bound to “paste” for the text field… Maybe the GTK library binds that value on Linux?
@robby may know more about this?
I think this is the relevant source: https://github.com/racket/gui/blob/master/gui-lib/mred/private/editor.rkt#L622
I’m as surprised as anyone that it’s still C-y, which I guess means that it has been a very long time since I last used Linux/Unix as my main environment.
(You can get a sense of the age of that code by the fact that the preceding line has both macos and macosx.)
and the fact that control-y works on a mac is something my fingers actually probably occasionally do without me noticing!
Would it be a bad idea to change these to more ‘modern’ values?
No objection from me.
Note that the menu-based key bindings are elsewhere (and take precedence over these ones when there is a conflict)
I know. But text-field%s use these values by default
I’ll push the change, and we’ll see how it goes with snapshots.
@alexharsanyi :point_up:
The C-a start-of-line and C-e end-of-line bindings will have to go away, since that conflicts with Ctl-a for Select All. There’s always Home and End.
People will notice that one I guess but perhaps in a good way.
Are the word movement keys also worth looking at? And shift-movement to select?
None of those are in the keymap used by the default current-text-keymap-initializer.
Shift to select with plain arrows is built into text%, of course.
Thanks for making this change. I tried to use current-text-keymap-initializer to override these for the application itself, but it is easier to have them by default in the GUI library (especially since everyone seems to agree that they are better defaults even for Linux)
Hi @torsten.grust, I am using Racket on Windows and never encountered this problem with opening rkt files.
Could this be a problem with the actual files themselves? If you can share one of the files that has this problem, I can try it out.
Also, do these students edit the .rkt files with other editors?
I believe it also adds c:x, etc.
But I see that it makes the opposite decision that Matthew did for c:a!
Probably also showing its age….
I was just starting to look at overriding the keybindings for the application only, when I noticed that Matthew changed the defaults in the GUI library, so I stopped investigating it.
In general I think it is a good idea for the GUI libraries to use the platform defaults, I was just not sure what those platform defaults are on Linux…
I believe that keymap function I linked to will do the platform defaults.
Matthew’s improvement is certainly better, tho, but that function is there in older versions.
But it is not clear how to call this function. Basicaly the application contains a lot of text-field% instances, and I don’t want to have to update each of them individually, so I was looking for something which would setup the defaults before the GUI widgets are created…
I will definitely notice if emacs-style keybindings go away, but if it’s possible to restore the old behavior by adding custom keybindings I suppose I have no grounds to complain. FWIW, GTK has key themes, and the gnome-tweaks tool allows setting the key theme to support emacs-style keybindings.
@alexharsanyi yeah, you’d have to set up an abstraction.
It is definitely awkward.