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

[Hendrik Boom]

On Mon, Jun 01, 2020 at 10:28:55PM -0500, Shu-Hung You wrote:
> FWIW, because `.` is just cons, the program
> (define (F [X : T1] . [Y : T2]) 'e)
> is being read as:
> (define (F [X : T1] Y : T2) 'e)
> I guess that's the reason for having an extra '*' in the syntax.

Indeed.  It works for untyped Racket, but in typed Racket that notation 
would become quite ambiguous.

-- hendrik

> 
> On Mon, Jun 1, 2020 at 10:16 PM Sam Tobin-Hochstadt
>  wrote:
> >
> > The syntax looks like this:
> >
> > (define (f [x : Number] . [y : String *]) : Number (+ x (length y)))
> >
> > See the documentation for `define` in Typed Racket here:
> > https://docs.racket-lang.org/ts-reference/special-forms.html?q=define#%28form._%28%28lib._typed-racket%2Fbase-env%2Fprims..rkt%29._define%29%29
> > in particular the `rst` production.
> >
> > Sam
> >
> > On Mon, Jun 1, 2020 at 3:09 PM Hendrik Boom  wrote:
> > >
> > > On Mon, Jun 01, 2020 at 10:58:09AM -0400, Sam Tobin-Hochstadt wrote:
> > > > Do you perhaps have some other binding shadowing the binding of `:`
> > > > from Typed Racket? That produces the error message you get when I try
> > > > it.
> > >
> > > Not intentionally.  I'll have to look carefully for possible candidates.
> > > Or ask DrRacket to jump to a binding occurrence.
> > >
> > > Did that:  It wouldn't find a bining instance while that colon was
> > > there, but complained about the syntax error I was sompaining about.
> > > But when I removed the type specification from the let-clause and
> > > introuced a colon elsewhere in the function as an extra parameter in
> > > another expression, it would find the binding.  It turned out that the
> > > binding occurrence was the colon in the tail-parameter [args : T-Size].
> > >
> > > So I have to ask, what *is* the proper way to indicate that the
> > > function can be called with many more parameters, which are to be
> > > made available as a list?
> > >
> > > Thank you for the hint.
> > >
> > > -- hendrik
> > >
> > > >
> > > > Sam
> > > >
> > > > On Sat, May 30, 2020 at 1:32 PM Hendrik Boom  
> > > > wrote:
> > > > >
> > > > > 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] syntax woe with typed Racket 'let'

[Shu-Hung You]

FWIW, because `.` is just cons, the program
(define (F [X : T1] . [Y : T2]) 'e)
is being read as:
(define (F [X : T1] Y : T2) 'e)
I guess that's the reason for having an extra '*' in the syntax.

On Mon, Jun 1, 2020 at 10:16 PM Sam Tobin-Hochstadt
 wrote:
>
> The syntax looks like this:
>
> (define (f [x : Number] . [y : String *]) : Number (+ x (length y)))
>
> See the documentation for `define` in Typed Racket here:
> https://docs.racket-lang.org/ts-reference/special-forms.html?q=define#%28form._%28%28lib._typed-racket%2Fbase-env%2Fprims..rkt%29._define%29%29
> in particular the `rst` production.
>
> Sam
>
> On Mon, Jun 1, 2020 at 3:09 PM Hendrik Boom  wrote:
> >
> > On Mon, Jun 01, 2020 at 10:58:09AM -0400, Sam Tobin-Hochstadt wrote:
> > > Do you perhaps have some other binding shadowing the binding of `:`
> > > from Typed Racket? That produces the error message you get when I try
> > > it.
> >
> > Not intentionally.  I'll have to look carefully for possible candidates.
> > Or ask DrRacket to jump to a binding occurrence.
> >
> > Did that:  It wouldn't find a bining instance while that colon was
> > there, but complained about the syntax error I was sompaining about.
> > But when I removed the type specification from the let-clause and
> > introuced a colon elsewhere in the function as an extra parameter in
> > another expression, it would find the binding.  It turned out that the
> > binding occurrence was the colon in the tail-parameter [args : T-Size].
> >
> > So I have to ask, what *is* the proper way to indicate that the
> > function can be called with many more parameters, which are to be
> > made available as a list?
> >
> > Thank you for the hint.
> >
> > -- hendrik
> >
> > >
> > > Sam
> > >
> > > On Sat, May 30, 2020 at 1:32 PM Hendrik Boom  
> > > wrote:
> > > >
> > > > 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.
> > >
> > > --
> > > 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/CAK%3DHD%2BYkANXdevMc%3DiSTFaWnpzU-6ofNWF2qJtWyR-f6ES2gLg%40mail.gmail.com.
> >

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[George Neuner]

On 6/1/2020 4:21 PM, Bogdan Popa wrote:

George Neuner writes:

> But Python's DB pool is threaded, and Python's threads are core
> limited by the GIL in all the major implementations (excepting
> Jython).

Python's Postgres pooling does not[1] use POSIX threads under the hood
to manage the connections if that's what you mean, nor is the
concurrency of the Python applications based on system threads.  All of
the Python examples use either asyncio + fork(2) or green threads +
fork(2).  This includes the django example[3].


I said nothing whatsoever about POSIX.  And FYI, POSIX does not imply 
any particular implementation - POSIX specifies only the API, and a 
compliant implementation may provide kernel threads, user space threads, 
or a combination of both.


What I did say is that Python's threads are core limited - and *that* is 
true.   As a technical matter, Python *may* in fact start threads on 
different cores, but the continual need to take the GIL quickly forces 
every running thread in the process onto the same core.




> There are a few things Python can do faster than Racket, but the VAST
> difference in performance shown in the techempower tests isn't
> explained by them.

Here's a benchmark that doesn't touch the DB at all, showing an even
bigger difference in throughput between the two:

https://www.techempower.com/benchmarks/#section=data-r19=ph=json


That one actually is expected:  Racket's JSON (de)serializer is 
relatively slow.



What wasn't expected was Sam's results from the "plain text" test which 
also showed Racket much slower than Python.  That does hint at a lot of 
overhead in the Racket framework.




I wrote the latest implementation of the Racket code for that benchmark
and I considered doing things like bypassing the "standard"
`dispatch/servlet' implementation to avoid the overhead of all the
continuation machinery in the web server, but that felt like cheating.


To my knowledge, continuations will not be a factor unless either 1) the 
application is written in the #web-server language (which converts 
everything to CPS), or 2) the code invokes one of the send/suspend/*  
functions.


FWIW: I try to avoid using client facing continuations in my own web 
applications - for my money there are too many uncertainties connected 
with them.


Also the stuffer does a fair amount of work to deal with long 
continuation URLs.




Another area where the web server does more work than it should is in
generating responses: the web server uses chunked transfer encoding for
all responses; whereas all the Python web servers simply write the
response directly to the socket when the length of the content is known
ahead of time.


My understanding is that the port passed to  response/output  is the 
actual socket ... so you can front-end it and write directly.  But that 
might be "cheating" under your definition.



George

--
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/2fd131be-ca0e-eaa1-6595-d31a410d43d4%40comcast.net.

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[Brian Adkins]

I may look into this in more detail later, but I ran a simple benchmark 
comparison on my modest AWS EC2 server (ApacheBench can behave poorly on 
MacOS).

1) I ran ApacheBench w/ 6 processes to fetch a simple "hello world" static 
html file using only nginx. I got roughly 650 requests per second.

2) I then ran ApacheBench w/ 6 processes against one of my Racket web apps 
using a monitoring endpoint that does a simple db query to determine the 
health of the server, so this went from nginx (acting as a load balancer 
and https handler) to the Racket processes via proxy_pass (only 2 running 
in parallel) which exercises my custom dispatching and a simple postgres 
query. No continuations and completely stateless. I got roughly 350 
requests per second.

At first glance, that doesn't appear to be that much overhead when 
comparing the two. In fact, I would've expected the very small static html 
request to be significantly more than double the req/sec of the Racket app 
db request.

I developed Rails apps for over a decade, and I know my Racket web apps are 
significantly faster in similar "database backed web apps" context.

I believe there is something wrong with those benchmarks at the moment.

Brian

On Monday, June 1, 2020 at 3:40:52 PM UTC-4, Sam Tobin-Hochstadt wrote:
>
> I'm skeptical both of the DB explanation and the multi-core 
> explanation. As you say, the difference between something like Django 
> and Racket is much too large to be explained by that. For example, on 
> the "plaintext" benchmark, Racket serves about 700 req/sec (I get 
> similar results on my machine). Many of the benchmarks in languages 
> like Python and Ruby do more than 1000x better, which means that even 
> if we had perfect speedup on 32 cores, we'd be nowhere close. 
> Additionally, the "plaintext" benchmark doesn't touch the DB at all. I 
> tried commenting out all of the DB code entirely, and it did not 
> change the results. 
>
> My guess is that the web server is just doing a lot of per-response 
> work that would need to be optimized. 
>
> Sam 
>
> On Mon, Jun 1, 2020 at 2:12 PM George Neuner  > wrote: 
> > 
> > 
> > On 6/1/2020 1:40 PM, Bogdan Popa wrote: 
> > > I replied earlier today off of my Phone, but, for whatever reason 
> > > (caught in the moderation queue?), it's not showing up in this thread. 
> > > 
> > > Here's what it said: 
> > > 
> > > The reason for poor performance relative to the other 
> > > langs/frameworks is that there is currently no easy way to take 
> > > advantage of multiple cores using the web framework so that's 
> being 
> > > benchmarked is single-core performance. 
> > > 
> > > This is mainly a problem for benchmarks such as this, but not 
> really 
> > > an issue in the real world where you'd just run multiple processes 
> > > with a load balancer in front. 
> > 
> > Single core [by itself] doesn't explain the enormous performance 
> > difference between Racket and Django. 
> > 
> > I haven't looked at the Django submission - Python's (in)comprehensions 
> > give me a headache.  But Python's DB pool is threaded, and Python's 
> > threads are core limited by the GIL in all the major implementations 
> > (excepting Jython). 
> > 
> > There are a few things Python can do faster than Racket, but the VAST 
> > difference in performance shown in the techempower tests isn't explained 
> > by them.  My suspicion is that the Racket application is making too many 
> > database connections and not relying enough on its open connection 
> > pool.  Hundreds of trivial requests can be served in the time it takes 
> > to spin up a new backend process. 
> > 
> > YMMV, 
> > George 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/9236dcff-81df-1db8-c2ef-06b20e4690ec%40comcast.net.
>  
>
>

-- 
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/ce26a93b-e1f2-425a-abc9-be991ff0e4e4%40googlegroups.com.

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[Bogdan Popa]

George Neuner writes:

> But Python's DB pool is threaded, and Python's threads are core
> limited by the GIL in all the major implementations (excepting
> Jython).

Python's Postgres pooling does not[1] use POSIX threads under the hood
to manage the connections if that's what you mean, nor is the
concurrency of the Python applications based on system threads.  All of
the Python examples use either asyncio + fork(2) or green threads +
fork(2).  This includes the django example[3].

> There are a few things Python can do faster than Racket, but the VAST
> difference in performance shown in the techempower tests isn't
> explained by them.

Here's a benchmark that doesn't touch the DB at all, showing an even
bigger difference in throughput between the two:

https://www.techempower.com/benchmarks/#section=data-r19=ph=json

Here's the same benchmark running on my local machine where I
intentionally limited the Django app to a single CPU and I made it use
the `gevent' library for its workers so it is more comparable to the
Racket implementation:

https://www.techempower.com/benchmarks/#section=test=14ecbf16-cdb3-4501-8b7d-a2b8a549f73c=ph=json=2

And here's what happens when I let it use as much parallelism as it can:

https://www.techempower.com/benchmarks/#section=test=d3ad4d79-c7a7-4ca0-b297-ffda549947c8=ph=json=2

I do agree that improving the parallelism part wouldn't be enough to
catch up (clearly, there's a 2x difference even on a single core), but
it is a large factor here.

I wrote the latest implementation of the Racket code for that benchmark
and I considered doing things like bypassing the "standard"
`dispatch/servlet' implementation to avoid the overhead of all the
continuation machinery in the web server, but that felt like cheating.

Another area where the web server does more work than it should is in
generating responses: the web server uses chunked transfer encoding for
all responses; whereas all the Python web servers simply write the
response directly to the socket when the length of the content is known
ahead of time.

Another thing of note about the django implementation is that it uses
ujson, written in C with the express intent of being as fast as
possible, to generate the JSON data.


[1]: They call the default implementation a `ThreadedConnectionPool'[2],
but that's just because it uses the mutexes that the `threading' module
provides.

[2]: 
https://github.com/psycopg/psycopg2/blob/779a1370ceeac130de07edc0510f2c55846be1bd/lib/pool.py#L155

[3]: 
https://github.com/TechEmpower/FrameworkBenchmarks/blob/c49524762379a2cdf82627b0032c654f3a9eafb6/frameworks/Python/django/gunicorn_conf.py#L8-L21

-- 
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/m2mu5mr0zy.fsf%40192.168.0.142.

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[George Neuner]

On 6/1/2020 3:40 PM, Sam Tobin-Hochstadt wrote:

I'm skeptical both of the DB explanation and the multi-core
explanation. As you say, the difference between something like Django
and Racket is much too large to be explained by that. For example, on
the "plaintext" benchmark, Racket serves about 700 req/sec (I get
similar results on my machine). Many of the benchmarks in languages
like Python and Ruby do more than 1000x better, which means that even
if we had perfect speedup on 32 cores, we'd be nowhere close.
Additionally, the "plaintext" benchmark doesn't touch the DB at all. I
tried commenting out all of the DB code entirely, and it did not
change the results.

My guess is that the web server is just doing a lot of per-response
work that would need to be optimized.

Sam


Possibly ... I admit that I did not look at the plain text results: I 
was drawn to the fact that the DB results impose a lot of non-Racket 
overhead.


George

--
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/cfc6c027-180d-d822-6d36-9f1cfb1849fc%40comcast.net.

Re: [racket-users] Some stuff about "case".

[Jon Zeppieri]

On Mon, Jun 1, 2020 at 3:52 PM Jens Axel Søgaard  wrote:
>
> Den man. 1. jun. 2020 kl. 20.53 skrev Christopher Lemmer Webber 
> :
>
>
> I think `case` were more important before `match` arrived.
> If you want to see how `case` can be implemented without hash-tables, look at
> William D Clinger's paper:
>
> http://scheme2006.cs.uchicago.edu/07-clinger.pdf
>
> /Jens Axel

The Racket implementation of case is based on Clinger's paper. And
Clinger's approach does, in fact, use hash tables, except that in the
Larceny implementation, the hash table fetch is open-coded by case
(IIRC), which is not the case in Racket (unless it gets inlined by the
compiler in the CS version, I suppose, though I don't know if that's
actually possible).

- Jon

-- 
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/CAKfDxxx1rBXHD%2B9sLH4x6kBJoE2SbKHKp%3D_PGWCZVmqjAO7Qiw%40mail.gmail.com.

Re: [racket-users] Some stuff about "case".

[Jens Axel Søgaard]

Den man. 1. jun. 2020 kl. 20.53 skrev Christopher Lemmer Webber <
cweb...@dustycloud.org>:

> As I started typing this email and looking into the definition of case,
> I realized my assumptions are wrong.
>
> What I needed: something like case which dispatches on symbols, except
> not auto-quoting the arguments... I needed to evaluate them from the
> lexical environment.  So:
>
>   (let ([x 'foo])
> (caseish 'foo
>   [(x) 'got-foo]
>   [('x) 'got-quote-x]))  ; => 'got-foo
>

Sounds like `evcase`:

https://docs.racket-lang.org/mzlib/mzlib_etc.html#%28form._%28%28lib._mzlib%2Fetc..rkt%29._evcase%29%29



> I figured: case is fast, and I'm pretty sure semi-magical... my
> intuitive sense was that it did some smart things on a compiler level
> that would probably be anything I'd hand-code (which would either use an
> alist or an immutable hashtable).


I think `case` were more important before `match` arrived.
If you want to see how `case` can be implemented without hash-tables, look
at
William D Clinger's paper:

http://scheme2006.cs.uchicago.edu/07-clinger.pdf

/Jens Axel

-- 
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/CABefVgypomV3a%3DfcgyBtrvpyAS1FeH4YR3k3zEKR9One3Niu5Q%40mail.gmail.com.

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

[Sam Tobin-Hochstadt]

The syntax looks like this:

(define (f [x : Number] . [y : String *]) : Number (+ x (length y)))

See the documentation for `define` in Typed Racket here:
https://docs.racket-lang.org/ts-reference/special-forms.html?q=define#%28form._%28%28lib._typed-racket%2Fbase-env%2Fprims..rkt%29._define%29%29
in particular the `rst` production.

Sam

On Mon, Jun 1, 2020 at 3:09 PM Hendrik Boom  wrote:
>
> On Mon, Jun 01, 2020 at 10:58:09AM -0400, Sam Tobin-Hochstadt wrote:
> > Do you perhaps have some other binding shadowing the binding of `:`
> > from Typed Racket? That produces the error message you get when I try
> > it.
>
> Not intentionally.  I'll have to look carefully for possible candidates.
> Or ask DrRacket to jump to a binding occurrence.
>
> Did that:  It wouldn't find a bining instance while that colon was
> there, but complained about the syntax error I was sompaining about.
> But when I removed the type specification from the let-clause and
> introuced a colon elsewhere in the function as an extra parameter in
> another expression, it would find the binding.  It turned out that the
> binding occurrence was the colon in the tail-parameter [args : T-Size].
>
> So I have to ask, what *is* the proper way to indicate that the
> function can be called with many more parameters, which are to be
> made available as a list?
>
> Thank you for the hint.
>
> -- hendrik
>
> >
> > Sam
> >
> > On Sat, May 30, 2020 at 1:32 PM Hendrik Boom  wrote:
> > >
> > > 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.
> >
> > --
> > 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/CAK%3DHD%2BYkANXdevMc%3DiSTFaWnpzU-6ofNWF2qJtWyR-f6ES2gLg%40mail.gmail.com.
>
> --
> 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/20200601190913.hxaqlgfm7y6prm5p%40topoi.pooq.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To 

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[Sam Tobin-Hochstadt]

I'm skeptical both of the DB explanation and the multi-core
explanation. As you say, the difference between something like Django
and Racket is much too large to be explained by that. For example, on
the "plaintext" benchmark, Racket serves about 700 req/sec (I get
similar results on my machine). Many of the benchmarks in languages
like Python and Ruby do more than 1000x better, which means that even
if we had perfect speedup on 32 cores, we'd be nowhere close.
Additionally, the "plaintext" benchmark doesn't touch the DB at all. I
tried commenting out all of the DB code entirely, and it did not
change the results.

My guess is that the web server is just doing a lot of per-response
work that would need to be optimized.

Sam

On Mon, Jun 1, 2020 at 2:12 PM George Neuner  wrote:
>
>
> On 6/1/2020 1:40 PM, Bogdan Popa wrote:
> > I replied earlier today off of my Phone, but, for whatever reason
> > (caught in the moderation queue?), it's not showing up in this thread.
> >
> > Here's what it said:
> >
> > The reason for poor performance relative to the other
> > langs/frameworks is that there is currently no easy way to take
> > advantage of multiple cores using the web framework so that's being
> > benchmarked is single-core performance.
> >
> > This is mainly a problem for benchmarks such as this, but not really
> > an issue in the real world where you'd just run multiple processes
> > with a load balancer in front.
>
> Single core [by itself] doesn't explain the enormous performance
> difference between Racket and Django.
>
> I haven't looked at the Django submission - Python's (in)comprehensions
> give me a headache.  But Python's DB pool is threaded, and Python's
> threads are core limited by the GIL in all the major implementations
> (excepting Jython).
>
> There are a few things Python can do faster than Racket, but the VAST
> difference in performance shown in the techempower tests isn't explained
> by them.  My suspicion is that the Racket application is making too many
> database connections and not relying enough on its open connection
> pool.  Hundreds of trivial requests can be served in the time it takes
> to spin up a new backend process.
>
> YMMV,
> George
>
> --
> 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/9236dcff-81df-1db8-c2ef-06b20e4690ec%40comcast.net.

-- 
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/CAK%3DHD%2BauHeC6veH-867PuiihSbYmZB2hKyx5ZnBH%2B-1sXUKwxA%40mail.gmail.com.

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

[Hendrik Boom]

On Mon, Jun 01, 2020 at 10:58:09AM -0400, Sam Tobin-Hochstadt wrote:
> Do you perhaps have some other binding shadowing the binding of `:`
> from Typed Racket? That produces the error message you get when I try
> it.

Not intentionally.  I'll have to look carefully for possible candidates.
Or ask DrRacket to jump to a binding occurrence.

Did that:  It wouldn't find a bining instance while that colon was 
there, but complained about the syntax error I was sompaining about.
But when I removed the type specification from the let-clause and 
introuced a colon elsewhere in the function as an extra parameter in 
another expression, it would find the binding.  It turned out that the 
binding occurrence was the colon in the tail-parameter [args : T-Size].

So I have to ask, what *is* the proper way to indicate that the 
function can be called with many more parameters, which are to be 
made available as a list?

Thank you for the hint.

-- hendrik

> 
> Sam
> 
> On Sat, May 30, 2020 at 1:32 PM Hendrik Boom  wrote:
> >
> > 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.
> 
> -- 
> 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/CAK%3DHD%2BYkANXdevMc%3DiSTFaWnpzU-6ofNWF2qJtWyR-f6ES2gLg%40mail.gmail.com.

-- 
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/20200601190913.hxaqlgfm7y6prm5p%40topoi.pooq.com.

[racket-users] Re: Some stuff about "case".

[Christopher Lemmer Webber]

Except maybe for one thing: I wonder if the version of case defined here
is written in such a way that is smart in that it never has to make said
hash table / alist more than once, at compile time.  I'm guessing so?

Christopher Lemmer Webber writes:

> As I started typing this email and looking into the definition of case,
> I realized my assumptions are wrong.
>
> What I needed: something like case which dispatches on symbols, except
> not auto-quoting the arguments... I needed to evaluate them from the
> lexical environment.  So:
>
>   (let ([x 'foo])
> (caseish 'foo
>   [(x) 'got-foo]
>   [('x) 'got-quote-x]))  ; => 'got-foo
>
> I figured: case is fast, and I'm pretty sure semi-magical... my
> intuitive sense was that it did some smart things on a compiler level
> that would probably be anything I'd hand-code (which would either use an
> alist or an immutable hashtable).  So I started writing up an email
> asking if such a thing worked... then I remembered, this is a ~lisp,
> jumping straight to definition is part of the scene... so I did that.
>
> I... was wrong!  From the case macro:
>
> ;; Symbol and "other" dispatch is either sequential or
> ;; hash-table-based, depending on how many constants we
> ;; have. Assume that `alist' does not map anything to `#f'.
> (define (dispatch-hashable tmp-stx alist make-hashX else-exp)
>   (if (< (length alist) *hash-threshold*)
>   #`(case/sequential #,tmp-stx 
>  #,@(map (λ (x)
>#`[(#,(car x)) #,(cdr x)])
>  alist)
>  [else #,else-exp])
>   (let ([tbl (make-hashX alist)])
> (if (literal-expression? else-exp)
> #`(hash-ref #,tbl #,tmp-stx (lambda () #,else-exp))
> #`(or (hash-ref #,tbl #,tmp-stx (lambda () #f))
>   #,else-exp)
>
> Am I reading that right?  Here I was assuming writing something like
> case was for cool kids and I'd never pull such a thing off right.
>
> But... now it looks like, oh, it's actually just using an alist or an
> immutable hashtable... same as I would.
>
> So I almost trashed this email, but thought I'd send it anyway because
> a) either maybe it's interesting to someone or b) actually maybe I'm
> misreading and case really is smarter / more performant and I'm just
> missing it...!
>
>  - Chris

-- 
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/87h7vuvchp.fsf%40dustycloud.org.

[racket-users] Some stuff about "case".

[Christopher Lemmer Webber]

As I started typing this email and looking into the definition of case,
I realized my assumptions are wrong.

What I needed: something like case which dispatches on symbols, except
not auto-quoting the arguments... I needed to evaluate them from the
lexical environment.  So:

  (let ([x 'foo])
(caseish 'foo
  [(x) 'got-foo]
  [('x) 'got-quote-x]))  ; => 'got-foo

I figured: case is fast, and I'm pretty sure semi-magical... my
intuitive sense was that it did some smart things on a compiler level
that would probably be anything I'd hand-code (which would either use an
alist or an immutable hashtable).  So I started writing up an email
asking if such a thing worked... then I remembered, this is a ~lisp,
jumping straight to definition is part of the scene... so I did that.
   
I... was wrong!  From the case macro:

;; Symbol and "other" dispatch is either sequential or
;; hash-table-based, depending on how many constants we
;; have. Assume that `alist' does not map anything to `#f'.
(define (dispatch-hashable tmp-stx alist make-hashX else-exp)
  (if (< (length alist) *hash-threshold*)
  #`(case/sequential #,tmp-stx 
 #,@(map (λ (x)
   #`[(#,(car x)) #,(cdr x)])
 alist)
 [else #,else-exp])
  (let ([tbl (make-hashX alist)])
(if (literal-expression? else-exp)
#`(hash-ref #,tbl #,tmp-stx (lambda () #,else-exp))
#`(or (hash-ref #,tbl #,tmp-stx (lambda () #f))
  #,else-exp)

Am I reading that right?  Here I was assuming writing something like
case was for cool kids and I'd never pull such a thing off right.

But... now it looks like, oh, it's actually just using an alist or an
immutable hashtable... same as I would.

So I almost trashed this email, but thought I'd send it anyway because
a) either maybe it's interesting to someone or b) actually maybe I'm
misreading and case really is smarter / more performant and I'm just
missing it...!

 - Chris

-- 
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/87imgavcqj.fsf%40dustycloud.org.

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[George Neuner]

On 6/1/2020 1:40 PM, Bogdan Popa wrote:

I replied earlier today off of my Phone, but, for whatever reason
(caught in the moderation queue?), it's not showing up in this thread.

Here's what it said:

The reason for poor performance relative to the other
langs/frameworks is that there is currently no easy way to take
advantage of multiple cores using the web framework so that's being
benchmarked is single-core performance.

This is mainly a problem for benchmarks such as this, but not really
an issue in the real world where you'd just run multiple processes
with a load balancer in front.


Single core [by itself] doesn't explain the enormous performance 
difference between Racket and Django.


I haven't looked at the Django submission - Python's (in)comprehensions 
give me a headache.  But Python's DB pool is threaded, and Python's 
threads are core limited by the GIL in all the major implementations 
(excepting Jython).


There are a few things Python can do faster than Racket, but the VAST 
difference in performance shown in the techempower tests isn't explained 
by them.  My suspicion is that the Racket application is making too many 
database connections and not relying enough on its open connection 
pool.  Hundreds of trivial requests can be served in the time it takes 
to spin up a new backend process.


YMMV,
George

--
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/9236dcff-81df-1db8-c2ef-06b20e4690ec%40comcast.net.

[racket-users] Racket News - Issue 32 is here!

[Paulo Matos]

Racket News - Issue 32 is here!

No time to wait, go grab a coffee and enjoy!
https://racket-news.com/2020/06/racket-news-issue-32.html

-- 
Paulo Matos

-- 
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/53899429-8ae3-42e1-9596-17ae07916b8b%40googlegroups.com.

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[Bogdan Popa]

I replied earlier today off of my Phone, but, for whatever reason
(caught in the moderation queue?), it's not showing up in this thread.

Here's what it said:

   The reason for poor performance relative to the other
   langs/frameworks is that there is currently no easy way to take
   advantage of multiple cores using the web framework so that's being
   benchmarked is single-core performance.

   This is mainly a problem for benchmarks such as this, but not really
   an issue in the real world where you'd just run multiple processes
   with a load balancer in front.


hashim muqtadir writes:

> A new version of these benchmarks was just published ("Round 19"):
> https://www.techempower.com/benchmarks/#section=data-r19
>
> Racket scores rather poorly (0 errors is nice, though). Anybody has any
> guesses as to why this is? Racket performs well enough as far as I'm
> concerned, and while I don't use the web server much, sounds unlikely that
> it should be so far below django, for example. Maybe they run it in a
> handicapped configuration or something.

-- 
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/m2tuzusn0u.fsf%40192.168.0.142.

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[George Neuner]

On 6/1/2020 11:12 AM, Sam Tobin-Hochstadt wrote:

I think the biggest thing is that no one has looked at optimizing
these benchmarks in Racket. If you tried out running one of these
benchmarks and ran the profiler it would probably show something
interesting.

Sam
The code[1] itself isn't bad.  There are a couple of minor things I 
personally would tweak, but in my opinion the main problem is with the 
database access.


Postgresql uses process parallelism - it forks a new backend process to 
handle each connection.  Assuming (???) there are enough concurrent 
requests to open the maximum number of DB pool connections, then 1024 is 
WAY too many.  PG experts recommend no more than 5..10 backend processes 
per core, but according to the environment details[2], the test machines 
have only 14 HT cores (28 threads).


Mind you I'm only guessing, but it looks to me like this application 
could be losing an enormous amount of time in the starting of new 
backend database processes.  And since it is running inside a Docker 
container, there also is some per connection overhead there.


The requests made by the tests[3] are so trivial (needing little 
additional Racket processing) that I would consider reducing the number 
of PG pool connections to just a few per core and see how that goes.  My 
expectation is that the time saved by spinning up many fewer PG 
processes will vastly outweigh any loss in absolute request 
concurrency.  [Particularly if they also are running PG itself inside 
Docker.]


YMMV,
George

[1] 
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Racket/racket/servlet.rkt
[2] 
https://www.techempower.com/benchmarks/#section=environment=ph=fortune
[3] 
https://github.com/TechEmpower/FrameworkBenchmarks/wiki/Project-Information-Framework-Tests-Overview


--
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/eafb41e8-734c-7666-e684-edade3731e79%40comcast.net.

Re: [racket-users] Re: [racket] Web Framework Benchmarks

[Sam Tobin-Hochstadt]

I think the biggest thing is that no one has looked at optimizing
these benchmarks in Racket. If you tried out running one of these
benchmarks and ran the profiler it would probably show something
interesting.

Sam

On Mon, Jun 1, 2020 at 6:43 AM hashim muqtadir
 wrote:
>
> A new version of these benchmarks was just published ("Round 19"): 
> https://www.techempower.com/benchmarks/#section=data-r19
>
> Racket scores rather poorly (0 errors is nice, though). Anybody has any 
> guesses as to why this is? Racket performs well enough as far as I'm 
> concerned, and while I don't use the web server much, sounds unlikely that it 
> should be so far below django, for example. Maybe they run it in a 
> handicapped configuration or something.
>
> --
> 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/2a1062a4-e4f1-484c-a8a2-f63c161959e8%40googlegroups.com.

-- 
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/CAK%3DHD%2BYJh96XAabvFRrW2HTFW9ECjKdnFOKomK0mdKeoA_4GNQ%40mail.gmail.com.

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

[Sam Tobin-Hochstadt]

Do you perhaps have some other binding shadowing the binding of `:`
from Typed Racket? That produces the error message you get when I try
it.

Sam

On Sat, May 30, 2020 at 1:32 PM Hendrik Boom  wrote:
>
> 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.

-- 
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/CAK%3DHD%2BYkANXdevMc%3DiSTFaWnpzU-6ofNWF2qJtWyR-f6ES2gLg%40mail.gmail.com.

Re: [racket-users] "is not in my domain"

[Ben Greenman]

On 5/29/20, Beatriz Moreira  wrote:
>
>
> Hi, im a beginner with racket and im using it to implement a language in
> order to test its operational semantic rules.
>
> This is the function where i keep having the error:
>
> (define-metafunction FS
>
> call : env-ß classes address f ((x v)...) -> e
>
> [(call (env-ß_1 ... ((address_1 C_1 n_1 vars_1 ...) ... (address C n vars
> ...) (address_2 C_2 n_2 vars_2 ...) ...) env-ß_2 ...)
>
> ((contract C_1 {x_11 ...} F_1) ... (contract C {x_1 ...} f (x ...) {return
> e}) (contract C_2 {x_22 ...} F_2) ...) address f ((x v)...))
>
> e])
>
>
> And this is the error message :
>
> ../../../../../../../Applications/Racket
> v7.6/share/pkgs/redex-lib/redex/private/reduction-semantics.rkt:1588:55:
> call: (call (((2 C 4 (x 3) (r 9)) (9 A 24 (a 9) (b 5 ((contract C (x r)
>
> (a (d y) (return (y + d (contract A (a b) (c (a b) (return (3) 2 a
> (d 7) (y 3)) is not in my domain
>
> I have tried changing the parenthesis but i can't seem to get it right.
> Here's the code
>  .Thank
>
> you guys for your help! :)

The "not in my domain error" happens when a metafunction gets either
the wrong number of arguments or the wrong shape for a certain arg.

Once you have the right number of arguments, `redex-match?` can help
check shapes.

```
(require rackunit)
(check-true (redex-match? FS env-ß (term (((2 C 4 (x 3) (r 9)) (9 A 24
(a 9) (b 5)))
```

-- 
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/CAFUu9R4yO5dRXxbPB5JcfotbNCQONPS2SskTq3YAhtX7erXQ0A%40mail.gmail.com.

[racket-users] Re: [racket] Web Framework Benchmarks

[hashim muqtadir]

A new version of these benchmarks was just published ("Round 19"): 
https://www.techempower.com/benchmarks/#section=data-r19

Racket scores rather poorly (0 errors is nice, though). Anybody has any 
guesses as to why this is? Racket performs well enough as far as I'm 
concerned, and while I don't use the web server much, sounds unlikely that 
it should be so far below django, for example. Maybe they run it in a 
handicapped configuration or something.

-- 
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/2a1062a4-e4f1-484c-a8a2-f63c161959e8%40googlegroups.com.

Re: [racket-users] Re: GUI executable creating an annoying command line window

[Philip Benade]

Hi Andre

This was 100% caused by using an outdated version of DrRacket. In my case 
the terminal window was just empty, no messages. It seems that If any of 
your code produces an output in the REPL window of DrRacket that will cause 
the terminal window to show.

Regards
Philip

On Monday, 1 June 2020 02:00:57 UTC+2, Andre Garzia wrote:
>
> I noticed a similar behavior if I left any dangling "display" or "write" 
> in the code, a terminal window would open with those messages in it. Is 
> this what might be happening to you?
>
> On Tue, 26 May 2020 at 12:09, Philip Benade  > wrote:
>
>> Hi Alex
>>
>> I managed to get it working. Updating Dr.Racket to 7.7 did the trick. I 
>> should have thought of it sooner, but I became so wrapped up in looking for 
>> the problem in my code I didn't think of it.
>>
>> Thank you for your help.
>>
>> Regards
>> Philip
>>
>> On Tuesday, 26 May 2020 11:50:58 UTC+2, Alex Harsanyi wrote:
>>>
>>>
>>> I cannot reproduce this.  If I create the executable from the command 
>>> line using "raco exe --gui work-timer.rkt", or from DrRacket specifying 
>>> GRacket as the "base", the console window does not show up.  
>>>
>>> If I create the executable using "raco exe work-timer.rkt" or by 
>>> specifying "Racket" as the base in DrRacket, the console window shows up, 
>>> but this is expected.
>>>
>>> I am using Racket 7.7 (BC, not the Chez version).
>>>
>>> Alex.
>>>
>>> On Tuesday, May 26, 2020 at 5:00:01 PM UTC+8, Philip Benade wrote:

 Hi All

 I have been trying to create a simple GUI with the racket/gui library. 
 For the most part it works but alongside my GUI it also creates a command 
 line window. You can see a screenshot of this in the attached picture. I 
 found this discussion when I searched for a solution: 
 https://groups.google.com/forum/#!topic/racket-users/QmvqWtm1x28 In 
 that case it was happening because there were things that did not return 
 void. In my case however it is not printing anything, there isn't even any 
 white space.

 I am using the "Create Executable" option from the "Racket" heading in 
 Dr.Racket's menu. I set the Type to be "Distribution (to install on other 
 machines)" and the Base to "GRacket" and keep the "Embed DLLs in the 
 executable" check box checked. Is there some setting or something I can 
 change to make this window to go away?

 I have attached my program's .rtk file in case anyone needs it to see 
 what I'm doing wrong.

 Regards
 Philip

>>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/40774e6e-7b89-4cd2-a21a-f1a936783c94%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> http://www.andregarzia.com
>
>

-- 
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/0be98c95-66dd-4946-b069-a2ba59eb428e%40googlegroups.com.