[racket-users] syntax woe with typed Racket 'let'

2020-05-30 Thread Hendrik Boom
I'm sorry to keep pestering this list, but I'm out of my depth with the 
detailed syntax (and semantics) of typed Racket.  But I'm doggedly 
ploughing on.

I'm having trouble with the 'let' line in the 'pointer-to' function listed 
later:

(let ([vt : Ffi-type (cast ((inst hash-ref Ffi-type Ffi-type) type-to-vector 
type #f) Ffi-type)])

Yes, there's an unbalanced parenthesis because this sin't the end of the 
let-expression.

The error message is

 let: expected type-annotated identifier
  parsing context: 
   while parsing annotated-binding
   while parsing optionally type-annotated binding in: (vt : Ffi-type (cast 
((inst hash-ref Ffi-type Ffi-type) type-to-vector type #f) Ffi-type))

I can't see the error.  'vt : Ffi-type' looks like a type-annotated 
identifier to me.  And it seems to have the right number of parentheses 
in front of it, followed by an expression whose vlue is to be bound to 
'vt'.

Here's the function it's part of:


(define (pointer-to [type : T-Type] . [args : T-Size]) : T-Type ; TODO: rename 
args to size-args
  (if (and (equal? args '(1)) (not (eq? type '_void)))
(mode-dependent-type
  `(_ptr i ,type) `(_ptr o ,type))
(case type
  ((_void) '_pointer/intptr)
  ((_byte _uint8) (mode-dependent-type 
'_string*/utf-8 
(if (null? args)
  '_bytes
  `(_bytes o ,@ args
  (else
(let ([vt : Ffi-type (cast ((inst hash-ref Ffi-type Ffi-type) 
type-to-vector type #f) Ffi-type)])
  (if vt
(mode-dependent-type
  `(,vt i)
  (if (null? args) 
vt
`(,vt o ,@ args))) 
(mode-dependent-type
  `(_vector i ,type)
  (if (null? args) 
'_pointer
`(_vector o ,type ,@ args)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20200530173230.bsrp5skkc35ot34h%40topoi.pooq.com.


Re: [racket-users] Possible bug in vector-cas!

2020-05-30 Thread Gustavo Massaccesi
Does your computer have exactly 8 cores (or subcores or whatever is the
official name of that hardware feaure)?

What happens if you use 7 futures instead of 8?

What happens if you use 9 (or 100) futures instead of 8?

Gustavo

PS: I don't know the low level details of the implementation of the
futures, but my guess is that in your example there is a main thread(?) and
8 futures, so you are running 9 things in 8 cores, and there is a race
condition and if you are unlucky it can cause a the program to block.





On Sat, May 30, 2020 at 1:12 PM Dominik Pantůček <
dominik.pantu...@trustica.cz> wrote:

> Hello Racketeers,
>
> it didn't take long before I hit another strange behavior when
> extensively using futures. The setup is relatively simple: I am
> processing a large fxvector/flvector and I am processing it on a
> line-by-line basis (the vectors themselves are width*height in nature).
> To avoid races I setup a (make-vector height #f) to serve as a vector of
> locks. Locking is simple:
>
> (let lloop ()
>   (when (not (vector-cas! locks y #f #t))
> (lloop)))
>
> .. do something ...
>
> (vector-set! locks y #f)
>
> Of course, the code in question is in 8 futures on my CPU and they are
> scheduled in parallel pretty consistently.
>
> Most of the time it works fine, but sometimes it just hangs with
> multiple CPU cores being utilized at 100% (I assume they are in the
> busy-wait "lloop").
>
> The problem is I cannot isolate a minimal working example from that. The
> code in question is about 3000 LoC and the issue expresses itself only
> in about 1 in 30 times just after the program has started. The GUI
> thread is running and there are lots of flonum operations and lots of
> thrown away flonum results (meaning GC gets triggered quite often).
>
> Also I cannot trigger the same issue with unsafe-vector*-cas! - I'll
> look into the differences in the source.
>
> I see this with latest Racket 3m.
>
> Any suggestions how to approach finding the source of the problem are -
> as always - very welcome.
>
>
> Cheers,
> Dominik
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/0e6de88c-1d39-38fa-ea69-2043c4f4071b%40trustica.cz
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAPaha9Mw3Txxe6h%2BrCBsLExoRTEg%2Bs1kPk07WOq_r43ncFE6%3Dg%40mail.gmail.com.


[racket-users] Possible bug in vector-cas!

2020-05-30 Thread Dominik Pantůček
Hello Racketeers,

it didn't take long before I hit another strange behavior when
extensively using futures. The setup is relatively simple: I am
processing a large fxvector/flvector and I am processing it on a
line-by-line basis (the vectors themselves are width*height in nature).
To avoid races I setup a (make-vector height #f) to serve as a vector of
locks. Locking is simple:

(let lloop ()
  (when (not (vector-cas! locks y #f #t))
(lloop)))

.. do something ...

(vector-set! locks y #f)

Of course, the code in question is in 8 futures on my CPU and they are
scheduled in parallel pretty consistently.

Most of the time it works fine, but sometimes it just hangs with
multiple CPU cores being utilized at 100% (I assume they are in the
busy-wait "lloop").

The problem is I cannot isolate a minimal working example from that. The
code in question is about 3000 LoC and the issue expresses itself only
in about 1 in 30 times just after the program has started. The GUI
thread is running and there are lots of flonum operations and lots of
thrown away flonum results (meaning GC gets triggered quite often).

Also I cannot trigger the same issue with unsafe-vector*-cas! - I'll
look into the differences in the source.

I see this with latest Racket 3m.

Any suggestions how to approach finding the source of the problem are -
as always - very welcome.


Cheers,
Dominik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0e6de88c-1d39-38fa-ea69-2043c4f4071b%40trustica.cz.