What’s the right pattern for using nack-guard-evt?

I’m thinking it’s supposed to be something along these lines:

(nack-guard-evt (lambda (nack) (define r (get-resource)) (thread (lambda () (sync nack) (release-resource r))) r)) If the event is chosen for synchronization, will the thread (and its refs) that synchronizes on nack eventually be garbage collected?

Hello. I have a question about sql lib. … > There are two forms of IN expression, one for table expressions and one for lists of scalar expressions: > (in x #:from (https://docs.racket-lang.org/sql/index.html?q=%D1%8B%D0%B9%D0%B4#%28form._%28%28lib._sql%2Fmain..rkt%29._select%29%29\|select y #:from ys))  ; x IN (SELECT y FROM ys) > (in x #:values 1 2 3)               ; x IN (1, 2, 3) Q: How to pass a list of values there? Like something: (in x #:values (list 1 2 3))

I tried almost everything, but failed. :disappointed:

@dmitryhertz I don’t think you can use that syntax with arbitrary lists, but this should work and have the same effect (assuming postgres):

(define xs '(1 2 3)) (select 1 #:where (= x (any ,xs)))

(in Postgres, x IN (1, 2, 3) is <https://www.postgresql.org/docs/current/functions-subquery.html#FUNCTIONS-SUBQUERY-ANY-SOME|syntactic sugar> for x = ANY(ARRAY[1, 2, 3]) )

@popa.bogdanp, thank you a lot! I’ll memorize that IN is a just syntactic sugar. I use SQLite, it does not have ANY keyword unfortunately.

This might work in that case:

(define xs '("1" "2" "3")) (select 1 #:where (in 1 #:values (TableExpr:INJECT ,(string-join xs ", "))))

So you’d have to generate the SQL you want and insert it as a raw string in that position.

This isn’t too janky when you consider that (IIRC) sqlite doesn’t allow placeholders in the right-hand side of an IN expression.

If you do go this route, then you’ll want to be careful validating user input.

The actual code I’m using this pattern in: https://github.com/Bogdanp/koyo/blob/85c833ab6e2bd66d117da8ad493238e04ee7bc44/koyo-lib/koyo/job/worker.rkt#L135-L190

@popa.bogdanp thank you a lot! :+1: It works! But I wanted to avoid INJECT, but anyway.

(sql-ast->string (statement-qq (select prefix #:from loc #:where (in pref #:values (ScalarExpr:INJECT ,(string-join (list "7" "74" "749" "7495") ", "))))))

Yes, a thread blocked on an otherwise unreachable NACK will be GCed. The use in the actual code looks ok as far as I can tell, assuming that it’s ok to reorder items in the queue.

Thanks!

Different results in Racket BC and Racket CS:

The expected results were: 11.0 22.0 33.0 44.0.

The function flomat-ref is defined here: https://github.com/soegaard/sci/blob/master/flomat/flomat.rkt#L916 It relies on ptr-elm which finds the address of an element in the matrix:

A matrix is allocated with:

'atomic-interior is more constrained on Racket CS before v7.7.0.<something>. In older versions like 7.6, (cast (malloc …. 'atomic-interior) ….) will basically never work. But that pattern is ok in the most recent variants of Racket CS. Of course, there are many other things that can go wrong here, including Racket CS bugs, but can you check a snapshot?

Yes. I’ll try the latest.

I don’t immediately see why you need 'atomic-interior, and the “interior” aspect is still constrained in Racket CS. What part. of the implementation needs 'atomic-interior?

A matrix consists of the number of rows m, the number of columns n, a leading dimension ld and a pointer to an array of doubles.

If a submatrix is created, it can point into the the same array of doubles.

But is that pointer constructed with ptr-add and retained that way, or is it installed as a pointer into some foreign data structure?

It’s created with ptr-add.

In that case, I don’t think you need 'atomic-interior, and it’s also not the problem. But I vaguely remember a problem with ptr-add that has been fixed in CS, so maybe a snapshot will work for you. You example works for me in CS, at least.

In fact, it looks like you helped track down that problem: https://github.com/racket/racket/commit/b0e65199fd45853561553074904b40714caa487b

Ah! I had completely forgotten. Laurent was using CS and my default is still BC.

I can’t launch the DrRacket from snapshot 7.7.07 though.

It’s signed but not notarized. Does the drag-DrRacket-of-out-its-folder-and-back trick help?

Nope. It creates shortcuts instead of moving it, when I attempt to move it.

(I tried the xattr -d com.apple.quarantine /Applications/Racket\ v7.7.0.7 trick first if that matters)

I think it’s command-drag to actually move it. But I would expect xattr to work.

(Does xattr need -r if you use it on a folder?)

Yes. -r was missing.

The drag thing almost worked. But then I got:

Adding -r worked.

And it now gives the proper result.

Thanks for the help - embarrassing I forgot that bug.

Thanks. Here’s my full implementation which supports expansion to define-values and define-syntaxes

https://docs.racket-lang.org/list-plus/index.html

This is maybe kinda sorta interesting. I need to write some big-endian integers to a port, and I’m aware of integer->integer-bytes, but I noticed that there aren’t any functions that allow you to bypass the intermediary byte string, unless you write the bytes one-at-a-time directly to the port — in which case you need to shift and mask, too. I put together a simple benchmark with four methods: • write the bytes one-at-a-time, shifting and masking with functions from racket/fixnum • ditto, except using the corresponding functions from racket/unsafe/ops • using integer->integer-bytes without supplying a byte string (so that a fresh one is allocated) • ditto, but reusing the same byte string Results (N=50000000): BC writing bigendian 32-bit integers directly to an output port cpu time: 5336 real time: 5340 gc time: 17 writing bigendian 32-bit integers directly to an output port (unsafe) cpu time: 5320 real time: 5323 gc time: 22 writing bigendian 32-bit integers to an output port via a fresh byte-string cpu time: 5844 real time: 5868 gc time: 96 writing bigendian 32-bit integers to an output port via a reused byte-string cpu time: 4007 real time: 4021 gc time: 16 CS writing bigendian 32-bit integers directly to an output port cpu time: 3419 real time: 3588 gc time: 521 writing bigendian 32-bit integers directly to an output port (unsafe) cpu time: 3486 real time: 3602 gc time: 524 writing bigendian 32-bit integers to an output port via a fresh byte-string cpu time: 3560 real time: 3574 gc time: 286 writing bigendian 32-bit integers to an output port via a reused byte-string cpu time: 3083 real time: 3087 gc time: 291 So, first off, CS is much faster in every case. But it also spends a lot more time in the garbage collector. More surprisingly, in CS, the version that allocates a fresh byte string on each iteration spends much less time in the GC than either of the versions that write directly to the port.

Hi, everyone. I’m looking for a way to tell if a module exists. Is there something better than (module-declared? mod #t) ?

I use module-declared? too. Why don’t you wanna use it?