that does not help
maybe @robby has some thoughts here. We’ve discovered that the problem with the quickscript-test/drracket.rkt test is that it ends up inserting the text into the interactions window instead of the definitions window, but it really seems like that shouldn’t happen.
I think you’ll need to explicitly change the focus to where you want it to be.
Right, the problem is that the tests do that, and adding even more doesn’t seem to fix it
The code I see at the link doesn’t do that.
The first failing test is this one: https://github.com/Metaxal/quickscript-test/blob/master/drracket.rkt#L103 and at line 96 there’s a call that I think sets the focus
and adding the focus call that @laurent.orseau suggested above at line 150, right before the other test failures, doesn’t fix those either
Can you point me to the run-script function?
oh, I found it
you’re ssaying that, with the code you sent me to (line 103), that you see typing in the interactions window first thing?
(during the string-insert script?)
In the cases where the test fails (it’s non-deterministic) the text “This is the editor” appears in the interactions window
IS that what the script does?
Do you know where the source code for the script is?
oh, duh. I found it now too. Sorry.
I don’t see anything obvious that’s wrong with that code. I’m not sure how ed gets calculated to pass to that function, tho.
Yeah I don’t know anything about how quickscript works, so I can’t speak to that
The use of the test suite library looks reasonable to me.
It’s calculated by the get-the-text-editor method in quickscript/tool which is: (define/private (get-the-text-editor)
; for a frame:text% :
;(define text (send frame get-editor))
; for DrRacket:
(define defed (get-definitions-text))
(if (send defed has-focus?)
defed
(get-interactions-text)))
Which seems to me like it should be doing the right thing here but I am very out of my depth
The call to the thunk on line 96 in drracket.rkt (the test suite) might happen concurrently with the call to run-script on 97 but if run-script is just taking us directly to the run-script private method in tool.rkt, then that’d explain why it doesn’t work.
Moving the content of that thunk (send (get-canvas) focus) outside of queue-callback causes the tests to pass consistently
That’s a sign that my analysis is right, I believe, but that’d be a bad change because you shouldn’t modify gui control state on a thread other than the eventspace main thread.
oh, I think I understand what’s going on.
The call to menu-select to run the script might be going before the call to on-focus.
the code needs to make sure that the on-focus call finishes before calling test:menu-select, I believe.
should the whole thing just be running inside queue-callback?
no
test:menu-select needs to run on a thread that’s not the eventspace main thrad
it is running on a thread that’s supposed to be “the user” who is clicking.
the idea is that you have two threads: one is the user who is doing stuff to the gui and those things are test:menu-select and friends
but then we sneak in some queue-callbacks because we want to tweak state more directly
and those need to be cooperating wth the test:menu-select (and friends) code, but just putting it in a queue’d callback is not enough to cooperate properly
but then it should be the “user” who sets the focus, right? but the thing it’s using to set the focus is something that has to be on the eventspace thread?
the user decides what to do, then does it.
that decision is happening on the non-eventspace main thread
then a callback should happen to actually take effect
imagine a button click. you move the mouse, that’s your thread
you click
then the OS comes in and puts something on the eventspace main thread in response to youclick.
your click
It might work to use test:run-one instead queue-callback to set the focus.
the issue is that the way that the test:* functions are movign stuff over to the eventspace main thread and the way queue-callback does are competing to see who goes first
queue-callback is a lower layer and the way it’s being used isn’t respecting the test: function’s invariants (in this case).
just changing queue-callback/res on that line to test:run-one does not fix it
what if you add some printfs to confirm that things are ahppening out of order?
(maybe using log-error is easiest)
if i add (sleep 5) right after the queue-callback it works
yeah, actually, now that I think about it, queue-callback/res should block until the thunk finishes
maybe the call to focus merely enqueues something that will change the foucs instead of changing the focus.
yep, that looks like it. From the docs:
that wouldn’t explain why doing it on the main thread causes it to work, would it?
“If the focus is in the window’s top-level window or if the window’s top-level window is visible and floating (i.e., created with the ’floatstyle), then the focus is immediately moved to this window. Otherwise, the focus is not immediately moved, but when the window’s top-level window gets the keyboard focus, the focus is delegated to this window.”
I think the simplest fix is to add a wait-until that checks that the definitions canvas has the focus
re “that wouldn’t …” doesn’t sound conclusive either way to me, actually.
ok that fixes it
I’ll open a PR
thanks everyone !
Thanks, Sam!
Note that we should probably audit other calls to focus too!
I’ll leave that to others :slightly_smiling_face:
PR opened
Catching up from my phone. Woah, thanks for finding the fix both of you! I’ll merge the PR soon.
How can I add some horizontal whitespace between two strings in Scribble? I’m looking for roughly the equivalent of   in HTML or ~ in LaTeX.
Ok, then I even remembered correctly. :wink: However, it doesn’t work for me. I’ll experiment a bit and try to find out why it doesn’t work or what I need to change for it to work.
It always renders as a tilde. :confused: (This is with #lang scribble/manual if it matters.)
I can use @hspace[1] as a workaround though.
What’s your code?
For example a~b on it’s own paragraph (empty line before and after).
Well, you need @~
It’s an identifier exported from the library.
Actually, probably @\|~\|
So that ~b is not parsed as one token
> So that ~b is not parsed as one token Right, that’s the problem I ran into now.
I can use a@~ b, but that renders as a  b in the HTML (i.e. a regular space before the b).
a@\|~\|b works though.
Would pipelining support in db make sense?
According to https://www.postgresql.org/docs/current/libpq-pipeline-mode.html\|https://www.postgresql.org/docs/current/libpq-pipeline-mode.html, “While the pipeline API was introduced in PostgreSQL 14, it is a client-side feature which doesn’t require special server support and works on any server that supports the v3 extended query protocol.”
I think a more significant improvement than any of this would be server-side support for http 2 and 3
header compression, no head-of-line blocking, stream multiplexing, etc.
In the real world, I definitely agree! I think the big design question for http 3 is do we roll our own implementation—the catch being the deep way that crypto is integrated into the protocol—or use something like Quiche? https://github.com/cloudflare/quiche Or, wait for QUIC support in OpenSSL? https://github.com/quictls/openssl/discussions/54
There’s already part of an implementation by @ryanc
re pipelining: I think that implementing pipelining in a way that would be legal for the benchmark above would be a bad fit for the db library. (The benchmark imposes restrictions about the placement of Sync messages.) Specifically, I dislike the idea of either exposing Sync to the user or sending more messages after a Sync without seeing the results so far. Low-level pipelining support would also conflict a bit with the db library’s automatic query preparation. At a higher-level, though, it would be possible to build a batch query operation that eliminates some round-trip latencies. I haven’t done it yet because it only benefits PostgreSQL.