Re: [racket-users] Method gen:custom-write of a struct not working within lists

[Sam Tobin-Hochstadt]

On Thu, Mar 4, 2021 at 3:24 PM Dimaugh Silvestris
 wrote:
>
> On Thu, 4 Mar 2021 at 19:29, Sam Tobin-Hochstadt  wrote:
>>
>> It doesn't print that way because that wouldn't turn back into the original 
>> value when evaluated, since it's quoted.
>
>
> Is there any other way?
> If not, I might consider the possibility of having a struct type for each of 
> those ugens, but as I was saying in my first mail - is that sensible? That 
> would mean declaring ~600 struct types.

I'm not totally sure what you want. The goal of `print` is to print
things in roughly a way that evaluating the printed result would
produce the original value. Thus:

Evaluating '(1 2 3) produces a 3-element list.
Evaluating (sinosc: 1 2) sounds like it produces a structure that you want.

But evaluating '(sinosc: 1 2) produces a 3-element list, not a
structure. Thus, you don't want that as the printed result. That means
that if you want to construct a pair of 0 and that structure, you need
to use `cons` and not `quote`.

If you want something else then you might need to construct the
function provided for `gen:custom-write` directly, instead of using
`make-constructor-style-printer`, but I still don't understand what
you want the result to be.

Sam

-- 
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%2BZfBAj7sTP83Ke965r8jXFKiPKNz5jfqv38NiergNHs5w%40mail.gmail.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[philngu...@gmail.com]

Oh I see. So one problem is here that `match-define` expands to `match` 
with an implicit error case, which at the low level, isn't distinguished 
from a user-written second case, and the tag check can't just be eliminated.

On Thursday, March 4, 2021 at 9:40:22 AM UTC-8 Sam Tobin-Hochstadt wrote:

> I think there are two reasons that code gets slower.
>
> 1. The `match-define` includes pair and struct checks, which are
> omitted for plain accessor uses because of the unsafe declaration.
> 2. That use of `match` expands to `define-values` which ends up as a
> `call-with-values` and a `case-lambda` at the chez layer and is not
> removed.
>
> `match` could recognize that it's being compiled with unsafe mode and
> omit these checks, although it's not that straightforward. Also
> schemify (or Chez) could do more to eliminate the use of multiple
> values, although that's hard without eliminating the failure cases.
>
> Sam
>
> On Thu, Mar 4, 2021 at 3:23 AM philngu...@gmail.com
>  wrote:
> >
> > Thanks for the tip about PLT_CS_COMPILE_LIMIT! I submitted a revision to 
> the syntax object variant that incorporated sleepnova's and yjqww6's 
> improvements.
> >
> > Also, I never knew about `(#%declare #:unsafe)` until I saw yjqww6's 
> pull request. It makes a noticeable difference. One unsatisfying thing is 
> that in one place, if I replace the 4 separate define clauses with just 
> `(match-define (cons (op o val) rst) parsed)`, the benchmarks are more than 
> twice slower.
> >
> > On Wednesday, March 3, 2021 at 11:12:30 AM UTC-8 Sam Tobin-Hochstadt 
> wrote:
> >>
> >> First, there's no longer a difference because yjqww6 just had a PR
> >> merged that improves the Racket performance.
> >>
> >> The performance difference that was there was mostly because the Chez
> >> code was run with `--optimize-level 3` which turns off safety. If that
> >> was changed to `--optimize-level 2` the timing became much slower.
> >>
> >> Sam
> >>
> >> On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com
> >>  wrote:
> >> >
> >> > There’s this benchmark on BF interpreter where the Racket and Chez 
> Scheme implementations are very similar, but Chez Scheme is much faster 
> than Racket 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 
> 136s).
> >> >
> >> > There’s the “Racket (Syntax Object)” variant that directly parses 
> BF’s syntax into Racket syntax object, which is faster (3.7s for bench, 82s 
> for mandel), but still significantly behind Chez Scheme’s naive interpreter.
> >> >
> >> > Profiling doesn’t give very illuminating results, saying most of the 
> cost is from interpreting BF’s loop instruction.
> >> >
> >> > Given that Racket is on Chez, could this benchmark reveal some low 
> hanging fruit for improving Racket’s performance?
> >> >
> >> > --
> >> > 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...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/83b2819d-8295-4769-944d-fa0c155976dan%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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/a5e77286-68b8-481a-8dea-0f547c5ce968n%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/f771a13a-9fc4-4b71-9e47-3a83eb5290e7n%40googlegroups.com.

Re: [racket-users] Method gen:custom-write of a struct not working within lists

[Dimaugh Silvestris]

On Thu, 4 Mar 2021 at 19:29, Sam Tobin-Hochstadt 
wrote:

> It doesn't print that way because that wouldn't turn back into the
> original value when evaluated, since it's quoted.
>

Is there any other way?
If not, I might consider the possibility of having a struct type for each
of those ugens, but as I was saying in my first mail - is that sensible?
That would mean declaring ~600 struct types.

On Thu, 4 Mar 2021 at 20:52, Yury Bulka 
wrote:

> Wow, so great to hear the a SuperCollider client in Racket is on the
> horizon:)
>

Well, slowly and from the hands of an amateur programmer. But if this
mailing list and the SuperCollider mailing list are patient enough with me,
we might have one in a few months :)
So far, SynthDef compilation is mostly finished. I haven't gotten into OSC
messaging yet, which is the other big half.

-- 
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/CAN4YmRFsoUOjCbjm9ey5b%3DT2AHa7LngwtJjyAtnw-airnuGMUw%40mail.gmail.com.

Re: [racket-users] Racket Meetup! 6 March

[Dominik Pantůček]

Hello Racketeers,

just a friendly reminder here on the ML - this Saturday brings the next
monthly Racket meetup(s) in Gather Town!


>From the latest Racket News[1]:

6 March 2021 TWO sessions

11 am Pacific Time
4:30 pm UK time

See you there!

Dominik

[1] https://racket-news.com/2021/03/racket-news-issue-47.html

On 06. 02. 21 21:05, Stephen De Gabrielle wrote:
> 
> Thank you to Eli Barzilay for joining us on today's meetup to discuss
> the paper 'A Foreign Function Interface'. 
> 
> And a big thank you to Sam Philips for organising this event and
> making sure it happens. (all I did was the racket news announcement so
> thank you Sam)
>  
> I had to leave a little early but I wanted to communicate the date and
> time for the next meetup:
> 
> Racket users video meetup
> 6 March 2021 at 8pm CET, via Gather Town.
> https://gather.town/app/wH1EDG3McffLjrs0/racket-users
> 
> Paper for discussion (optional pre-reading) is:  To be decided! 
> 
> (Note - we do take suggestions if you have something that interests or
> excites you - and other media would also be considered; blog post,
> video, package, app - as long as it is Racket related)
> 
> Kind regards
> 
> Stephen De Gabrielle
> 
> -- 
> 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/CAGHj7-JQnJF18DjsN7392TSOa6JxTPFEy1OEwQQFm980zrUM3Q%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/32a5fc42-81bd--ced7-438c97ff5ac0%40trustica.cz.

Re: [racket-users] Method gen:custom-write of a struct not working within lists

[Yury Bulka]

Wow, so great to hear the a SuperCollider client in Racket is on the horizon:)

--
Yury Bulka
https://mamot.fr/@setthemfree
#NotOnFacebook



Dimaugh Silvestris  writes:

> I have a struct defined as:
> (struct ugen sc.unit (name rate inputs) 
>   #:methods gen:custom-write
>   [(define write-proc
>  (make-constructor-style-printer
>   [λ (x) (let [(rate (ugen-rate x))
>(name (symbol-append (ugen-name x) ':))]
>(cond [(eq? rate 'ar) name]
>  [else (symbol-append
> name rate)]))]
>   [λ (x) (ugen-inputs x)]))] #:transparent)
>
> So that (ugen 'sinosc 'ar (1 2)) prints as (sinosc: 1 2), which 
> incidentally it's the same as the function call that creates that value, 
> that is: (sinosc: 3 4) creates the struct instance (ugen 'sinosc 'ar (3 
> 4)). *
>
> The problem is, within a list it prints like '(#), which is 
> quite ugly.
>
> * I don't know if this is a smart choice. I'm building a SuperCollider 
> client, and in SuperCollider there's hundreds of ugens (unit generators, 
> such as oscillators, filters, etc).
> Because there's hundreds of them, I thought it might be heavy on memory or 
> cpu to declare a specific struct for each one of them; so I choose instead 
> to declare only constructors that build different instances of the ugen 
> struct.

-- 
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/87tupqelxo.fsf%40privacyrequired.com.

Re: [racket-users] Method gen:custom-write of a struct not working within lists

[Sam Tobin-Hochstadt]

I think you want to add `#:property prop:custom-print-quotable 'never`
to that struct declaration, and then it will behave as you wanted.

Sam

On Thu, Mar 4, 2021 at 11:44 AM Dimaugh Silvestris
 wrote:
>
> I have a struct defined as:
> (struct ugen sc.unit (name rate inputs)
>   #:methods gen:custom-write
>   [(define write-proc
>  (make-constructor-style-printer
>   [λ (x) (let [(rate (ugen-rate x))
>(name (symbol-append (ugen-name x) ':))]
>(cond [(eq? rate 'ar) name]
>  [else (symbol-append
> name rate)]))]
>   [λ (x) (ugen-inputs x)]))] #:transparent)
>
> So that (ugen 'sinosc 'ar (1 2)) prints as (sinosc: 1 2), which incidentally 
> it's the same as the function call that creates that value, that is: (sinosc: 
> 3 4) creates the struct instance (ugen 'sinosc 'ar (3 4)). *
>
> The problem is, within a list it prints like '(#), which is 
> quite ugly.
>
> * I don't know if this is a smart choice. I'm building a SuperCollider 
> client, and in SuperCollider there's hundreds of ugens (unit generators, such 
> as oscillators, filters, etc).
> Because there's hundreds of them, I thought it might be heavy on memory or 
> cpu to declare a specific struct for each one of them; so I choose instead to 
> declare only constructors that build different instances of the ugen struct.
>
> --
> 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/56b85a49-2b64-465a-a58d-3b758aa823c5n%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%2Bb_SSFcT35ohW1TeiDPpcHXiX8CN%3DNNseaRCz_nbSWcLw%40mail.gmail.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[Sam Tobin-Hochstadt]

I think there are two reasons that code gets slower.

1. The `match-define` includes pair and struct checks, which are
omitted for plain accessor uses because of the unsafe declaration.
2. That use of `match` expands to `define-values` which ends up as a
`call-with-values` and a `case-lambda` at the chez layer and is not
removed.

`match` could recognize that it's being compiled with unsafe mode and
omit these checks, although it's not that straightforward. Also
schemify (or Chez) could do more to eliminate the use of multiple
values, although that's hard without eliminating the failure cases.

Sam

On Thu, Mar 4, 2021 at 3:23 AM philngu...@gmail.com
 wrote:
>
> Thanks for the tip about PLT_CS_COMPILE_LIMIT! I submitted a revision to the 
> syntax object variant that incorporated sleepnova's and yjqww6's improvements.
>
> Also, I never knew about `(#%declare #:unsafe)` until I saw yjqww6's pull 
> request. It makes a noticeable difference. One unsatisfying thing is that in 
> one place, if I replace the 4 separate define clauses with just 
> `(match-define (cons (op o val) rst) parsed)`, the benchmarks are more than 
> twice slower.
>
> On Wednesday, March 3, 2021 at 11:12:30 AM UTC-8 Sam Tobin-Hochstadt wrote:
>>
>> First, there's no longer a difference because yjqww6 just had a PR
>> merged that improves the Racket performance.
>>
>> The performance difference that was there was mostly because the Chez
>> code was run with `--optimize-level 3` which turns off safety. If that
>> was changed to `--optimize-level 2` the timing became much slower.
>>
>> Sam
>>
>> On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com
>>  wrote:
>> >
>> > There’s this benchmark on BF interpreter where the Racket and Chez Scheme 
>> > implementations are very similar, but Chez Scheme is much faster than 
>> > Racket 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 136s).
>> >
>> > There’s the “Racket (Syntax Object)” variant that directly parses BF’s 
>> > syntax into Racket syntax object, which is faster (3.7s for bench, 82s for 
>> > mandel), but still significantly behind Chez Scheme’s naive interpreter.
>> >
>> > Profiling doesn’t give very illuminating results, saying most of the cost 
>> > is from interpreting BF’s loop instruction.
>> >
>> > Given that Racket is on Chez, could this benchmark reveal some low hanging 
>> > fruit for improving Racket’s performance?
>> >
>> > --
>> > 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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/racket-users/83b2819d-8295-4769-944d-fa0c155976dan%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/a5e77286-68b8-481a-8dea-0f547c5ce968n%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%2BbSp%3Dg-POJ7v9HUksw5WivY6_RbsPSnGv8B6PwfSYZs1A%40mail.gmail.com.

[racket-users] Method gen:custom-write of a struct not working within lists

[Dimaugh Silvestris]

I have a struct defined as:
(struct ugen sc.unit (name rate inputs) 
  #:methods gen:custom-write
  [(define write-proc
 (make-constructor-style-printer
  [λ (x) (let [(rate (ugen-rate x))
   (name (symbol-append (ugen-name x) ':))]
   (cond [(eq? rate 'ar) name]
 [else (symbol-append
name rate)]))]
  [λ (x) (ugen-inputs x)]))] #:transparent)

So that (ugen 'sinosc 'ar (1 2)) prints as (sinosc: 1 2), which 
incidentally it's the same as the function call that creates that value, 
that is: (sinosc: 3 4) creates the struct instance (ugen 'sinosc 'ar (3 
4)). *

The problem is, within a list it prints like '(#), which is 
quite ugly.

* I don't know if this is a smart choice. I'm building a SuperCollider 
client, and in SuperCollider there's hundreds of ugens (unit generators, 
such as oscillators, filters, etc).
Because there's hundreds of them, I thought it might be heavy on memory or 
cpu to declare a specific struct for each one of them; so I choose instead 
to declare only constructors that build different instances of the ugen 
struct.

-- 
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/56b85a49-2b64-465a-a58d-3b758aa823c5n%40googlegroups.com.

[racket-users] Racket News - Issue 47

[Paulo Matos]

Racket News is once again here... yes, it's one of *those* weeks!

https://racket-news.com/2021/03/racket-news-issue-47.html

Enjoy!

-- 
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/8d4589cc-d3d2-4b3b-b1b6-2fee2920d4b6n%40googlegroups.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[philngu...@gmail.com]

Thanks for the tip about PLT_CS_COMPILE_LIMIT! I submitted a revision to 
the syntax object variant that incorporated sleepnova's and yjqww6's 
improvements.

Also, I never knew about `(#%declare #:unsafe)` until I saw yjqww6's pull 
request. It makes a noticeable difference. One unsatisfying thing is that 
in one place, if I replace the 4 separate define clauses 

 
with just `(match-define (cons (op o val) rst) parsed)`, the benchmarks are 
more than twice slower.

On Wednesday, March 3, 2021 at 11:12:30 AM UTC-8 Sam Tobin-Hochstadt wrote:

> First, there's no longer a difference because yjqww6 just had a PR
> merged that improves the Racket performance.
>
> The performance difference that was there was mostly because the Chez
> code was run with `--optimize-level 3` which turns off safety. If that
> was changed to `--optimize-level 2` the timing became much slower.
>
> Sam
>
> On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com
>  wrote:
> >
> > There’s this benchmark on BF interpreter where the Racket and Chez 
> Scheme implementations are very similar, but Chez Scheme is much faster 
> than Racket 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 
> 136s).
> >
> > There’s the “Racket (Syntax Object)” variant that directly parses BF’s 
> syntax into Racket syntax object, which is faster (3.7s for bench, 82s for 
> mandel), but still significantly behind Chez Scheme’s naive interpreter.
> >
> > Profiling doesn’t give very illuminating results, saying most of the 
> cost is from interpreting BF’s loop instruction.
> >
> > Given that Racket is on Chez, could this benchmark reveal some low 
> hanging fruit for improving Racket’s performance?
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/83b2819d-8295-4769-944d-fa0c155976dan%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/a5e77286-68b8-481a-8dea-0f547c5ce968n%40googlegroups.com.