Re: [racket-users] Racket 7.3 Plot Performance Regression

[evdubs]

Thanks for trying it out.

I just tried using the bash installer from 
https://download.racket-lang.org/ and I experience the same issue of 
lagginess in 7.3. I also tried using a snapshot release from 
https://plt.eecs.northwestern.edu/snapshots/ and I experienced the same 
issue. 

I am not sure what I should try next other than maybe profiling, but I have 
not had much luck making effective use of the profiler in the past for 
interactive applications.

Evan

On Thursday, May 30, 2019 at 4:23:13 AM UTC-10, Sam Tobin-Hochstadt wrote:
>
> I just tried this on my build (from HEAD) and I also do not see any 
> slowdown. Trying with a regular installer would be helpful. 
>
> Sam 
>
> On Fri, May 17, 2019 at 5:09 PM evdubs > 
> wrote: 
> > 
> > Hi All, 
> > 
> > I have noticed sluggish performance with my plot overlays in Racket 7.3 
> that I had not noticed in versions 7.2 and prior. Here's the code I am 
> using to test (taken from here): 
> > 
> > (require plot) 
> > 
> > (define ((make-current-value-renderer fn) snip event x y) 
> >   (define overlays 
> > (and x y (eq? (send event get-event-type) 'motion) 
> >  (list (vrule x #:style 'long-dash) 
> >(point-label (vector x (fn x)) #:anchor 'auto 
> >   (send snip set-overlay-renderers overlays)) 
> > 
> > (define snip (plot-snip (function sin) #:x-min 0 #:x-max (* 2 pi) 
> #:y-min -1.5 #:y-max 1.5)) 
> > (send snip set-mouse-event-callback (make-current-value-renderer sin)) 
> > snip 
> > 
> > With 7.3, it feels like the frame rate hovers around 5-10 fps and the 
> mouse pointer input is buffered so you can move around the plot and it will 
> slowly try to catch up to where your pointer was. 7.2 and prior all felt 
> snappy and seemed to be at least 20-30 fps. 
> > 
> > Here are my installation details: 
> > 
> > Ubuntu 19.04 
> > Intel Core i5-7400 
> > 16GB RAM with only ~10GB in use (no swapping) and <1GB in use by 
> DrRacket 
> > Racket 7.3 installed from the PPA 
> > 
> > I asked Alex H. if he had noticed this regression and he said he had 
> not. He uses Windows. I have not tried to see if the PPA version is any 
> different from the official installer to see if there's a difference. Maybe 
> that's the next step? 
> > 
> > Evan 
> > 
> > -- 
> > 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/b68b9731-3163-4d0b-9edc-32c3774b6243%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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/a79a3b45-ea09-4b62-af58-3a367d1d799d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Kevin Forchione]

> On Jun 3, 2019, at 9:42 AM, Matthias Felleisen  wrote:
> 
> 
> 
>> On Jun 3, 2019, at 12:33 PM, Kevin Forchione  wrote:
>> 
>> Oh! I see! That solves the expansio issue! Wonderful. You’ve opened up a 
>> whole new set of possibilities for me. Thanks, Matthias.
> 
> 
> I am glad I sent my solution a second time :)

Me, too. For some reason the bundling of my emails appeared only to present 
your suggestion of using syntax-parameters and perusing of docs and not the 
code! It made your follow-up comments cryptic though I didn’t realize I was 
missing something until the “OR” in your prior email. Going back through the 
bundle the earlier code was there. The “Or” solution, however, brought home to 
me that you can nest the syntax-parameterize calls. :) 

Kevin

-- 
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/34F49B72-5C89-4994-9288-43DB336E2DBE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 9

['Paulo Matos' via Racket Users]

Issue 9 is here.

https://racket-news.com/2019/06/racket-news-issue-9.html

Grab a coffee and enjoy.
-- 
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/5b22e4e7-6dde-1bee-18fa-cdf35760d706%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: scopes across files

[Eric Griffis]

Apologies to mobile users. The superscripts added by +scopes aren't boxes
in the Web client.

To clarify my question: how do I handle the situation where variables bound
by one macro and used by another are out of scope when file boundaries are
involved?

The +scopes into shows that the scope sets go from intersecting to disjoint
or sharing only a macro scope.

On Mon, Jun 3, 2019, 11:52 AM Eric Griffis  wrote:

> Several times now, I've run into one or another form of the following
> problem:
>
> Say I want to build primitives to
>
>1. declare an "interface" as a list of names, and
>2. implement and use those names at run time in a limited scope
>
> Concretely, I want to run the following code:
>
> (interface Speaker say speak)
> (implement Speaker displayln (say 'hello) speak)
>
> If I put these lines at the end of a file that implements the two forms,
> it should (displayln 'hello) when I run it.
>
> Here is the interface macro:
>
> (define-syntax (interface stx)
>   (syntax-case stx ()
> [(_ id member-id ...) #'(define-syntax id #'(member-id ...))]))
>
> The implement macro is trickier. A naive implementation looks like this:
>
> (define-syntax (implement stx)
>   (syntax-case stx ()
> [(_ class-id def ... expr)
>  (with-syntax ([(id ...) (syntax-e (syntax-local-value #'class-id))])
>#'(letrec ([id def] ...) expr))]))
>
> It fails with the following message:
>
> ; /tmp/j.rkt:44:30: say: unbound identifier;   in: say;   context...:;
> #(570423 use-site) [common scopes];   other binding...:;local;
> #(570422 macro) [common scopes];   common scopes...:;#(570223 module) 
> #(570226 module j) #(570426 local) #(570427 intdef);#(570428 local)
>
> Incorporating the debug-scopes package's +scopes macro shows this:
>
> (letrec⁰˙˙¹
>  ((say⁰˙˙¹ displayln⁰˙˙³) (speak⁰˙˙¹ (say⁰˙˙³ (quote⁰˙˙³ hello⁰˙˙³
>  speak⁰˙˙³)ˢˡⁱ⁼²⁺ᵘˢᵉ⁼³0 module   5705121 module j 5705152 macro5707193 
> use-site 570720
>
> For reasons I don't yet fully comprehend, it just works out if I use
> syntax-local-introduce on the id's, so +scopes gives me this:
>
> (letrec⁰˙˙¹
>  ((say⁰˙˙³ displayln⁰˙˙³) (speak⁰˙˙³ (say⁰˙˙³ (quote⁰˙˙³ hello⁰˙˙³
>  speak⁰˙˙³)ˢˡⁱ⁼²⁺ᵘˢᵉ⁼³0 module   5712471 module j 5712502 macro5714553 
> use-site 571456
>
> But if the interface and implement invocations are not in the same file
> as their implementations, it breaks with a similar error:
>
> ; /tmp/h.rkt:5:30: say: unbound identifier;   in: say;   context...:;
> #(572682 module) [common scopes];   other binding...:;local;#(572388 
> module) #(572391 module j) #(572596 module);#(572599 module j) [common 
> scopes];   common scopes...:;#(572685 module h) #(572700 local) #(572701 
> intdef) #(572702 local)
>
> In this situation, +scopes gives:
>
> (letrec⁰˙˙³
>  ((say⁴˙˙⁵ displayln⁴˙˙⁶) (speak⁴˙˙⁵ (say⁴˙˙⁶ (quote⁴˙˙⁶ hello⁴˙˙⁶
>  speak⁴˙˙⁶)ˢˡⁱ⁼⁶⁺ᵘˢᵉ⁼0 module   5768541 module j 5768572 module   5770563 
> module j 5770594 module   5771505 module h 5771536 macro577173
>
> If I move the interface invocation back into the original file and keep
> the implement invocation in a separate file, I get the same error but
> +scopes gives something slightly different:
>
> (letrec⁰˙˙³
>  ((say⁰˙˙⁴ displayln⁴˙˙⁶) (speak⁰˙˙⁴ (say⁴˙˙⁶ (quote⁴˙˙⁶ hello⁴˙˙⁶
>  speak⁴˙˙⁶)ˢˡⁱ⁼⁴⁺ᵘˢᵉ⁼0 module   5723881 module j 5723912 module   5725963 
> module j 5725994 macro5726975 module   5726826 module h 572685
>
> What's going on here? How do I fix this?
>
> Eric
>

-- 
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/CAORuSUzCs5SiisiLjG3uQMiBdK%2BOHOjq8sgEsNdw54LUMAeEEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] scopes across files

[Eric Griffis]

Several times now, I've run into one or another form of the following
problem:

Say I want to build primitives to

   1. declare an "interface" as a list of names, and
   2. implement and use those names at run time in a limited scope

Concretely, I want to run the following code:

(interface Speaker say speak)
(implement Speaker displayln (say 'hello) speak)

If I put these lines at the end of a file that implements the two forms, it
should (displayln 'hello) when I run it.

Here is the interface macro:

(define-syntax (interface stx)
  (syntax-case stx ()
[(_ id member-id ...) #'(define-syntax id #'(member-id ...))]))

The implement macro is trickier. A naive implementation looks like this:

(define-syntax (implement stx)
  (syntax-case stx ()
[(_ class-id def ... expr)
 (with-syntax ([(id ...) (syntax-e (syntax-local-value #'class-id))])
   #'(letrec ([id def] ...) expr))]))

It fails with the following message:

; /tmp/j.rkt:44:30: say: unbound identifier;   in: say;   context...:;
   #(570423 use-site) [common scopes];   other binding...:;local;
  #(570422 macro) [common scopes];   common scopes...:;#(570223
module) #(570226 module j) #(570426 local) #(570427 intdef);
#(570428 local)

Incorporating the debug-scopes package's +scopes macro shows this:

(letrec⁰˙˙¹
 ((say⁰˙˙¹ displayln⁰˙˙³) (speak⁰˙˙¹ (say⁰˙˙³ (quote⁰˙˙³ hello⁰˙˙³
 speak⁰˙˙³)ˢˡⁱ⁼²⁺ᵘˢᵉ⁼³0 module   5705121 module j 5705152 macro
5707193 use-site 570720

For reasons I don't yet fully comprehend, it just works out if I use
syntax-local-introduce on the id's, so +scopes gives me this:

(letrec⁰˙˙¹
 ((say⁰˙˙³ displayln⁰˙˙³) (speak⁰˙˙³ (say⁰˙˙³ (quote⁰˙˙³ hello⁰˙˙³
 speak⁰˙˙³)ˢˡⁱ⁼²⁺ᵘˢᵉ⁼³0 module   5712471 module j 5712502 macro
5714553 use-site 571456

But if the interface and implement invocations are not in the same file as
their implementations, it breaks with a similar error:

; /tmp/h.rkt:5:30: say: unbound identifier;   in: say;   context...:;
  #(572682 module) [common scopes];   other binding...:;local;
#(572388 module) #(572391 module j) #(572596 module);#(572599
module j) [common scopes];   common scopes...:;#(572685 module h)
#(572700 local) #(572701 intdef) #(572702 local)

In this situation, +scopes gives:

(letrec⁰˙˙³
 ((say⁴˙˙⁵ displayln⁴˙˙⁶) (speak⁴˙˙⁵ (say⁴˙˙⁶ (quote⁴˙˙⁶ hello⁴˙˙⁶
 speak⁴˙˙⁶)ˢˡⁱ⁼⁶⁺ᵘˢᵉ⁼0 module   5768541 module j 5768572 module
5770563 module j 5770594 module   5771505 module h 5771536 macro
577173

If I move the interface invocation back into the original file and keep the
implement invocation in a separate file, I get the same error but +scopes
gives something slightly different:

(letrec⁰˙˙³
 ((say⁰˙˙⁴ displayln⁴˙˙⁶) (speak⁰˙˙⁴ (say⁴˙˙⁶ (quote⁴˙˙⁶ hello⁴˙˙⁶
 speak⁴˙˙⁶)ˢˡⁱ⁼⁴⁺ᵘˢᵉ⁼0 module   5723881 module j 5723912 module
5725963 module j 5725994 macro5726975 module   5726826 module h
572685

What's going on here? How do I fix this?

Eric

-- 
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/CAORuSUz_v5jYSFQetnuLb6haNx8Hwo0CqR0Bm-jCJO0DT7Bz6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Mutating hash-map while iterating

[Ben Greenman]

You want the paragraph just above the caveat about concurrent modification:

> A hash table can be used as a two-valued sequence (see Sequences). The keys
> and values of the hash table serve as elements of the sequence (i.e., each
> element is a key and its associated value). If a mapping is added to or
> removed from the hash table during iteration, then an iteration step may fail
> with exn:fail:contract, or the iteration may skip or duplicate keys and
> values. See also in-hash, in-hash-keys, in-hash-values, and in-hash-pairs.

https://docs.racket-lang.org/reference/hashtables.html

-- 
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/CAFUu9R7js1zaUxF5Ck%3Dc%2BBmcY3s_x7q5v%2BPy_tVwfTN6y4vRuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] New Package: Dynamic FFI - Write C Code Inline

[Neil Van Dyke]

This looks neat.

I'm glad you noted upfront in the documentation about things it can't 
handle automatically (e.g., allocations/lifetimes that need special 
management).


In your discussion relating this to other work/approaches, you might 
want to contrast with SWIG (e.g., you work from the original headers, 
when SWIG not available).  And, as a practical measure, maybe consider 
using some of the information from SWIG when available.


If you or someone later someone wants to do work with C code in 
pure-Racket (without the Clang dependency), I recall some earlier work 
on C parsing, and you might find some packages for that (also check 
PLaneT), maybe including by Dave Herman.  A C parser is a lot harder 
than one might initially think (it's not just the fairly straightforward 
standard grammar with type-based ambiguities, but also getting all the 
preprocessing correct while (for some tools needs) retaining 
pre-preprocessing information, such as the names of macro uses and fine 
source position information), but you can do neat things once you build 
it.  One of my past employers used such a fancy C parser for "reverse 
engineering" C code into a full CASE system (which included other neat 
toys, like a high-level structured systems analysis, 
network-based in-circuit emulator, embedded system code instrumentation 
for path coverage, static complexity analysis, test case generation).


BTW, that's a clever use of `at-exp` for embedded C code in your 
example.  For cases in which that doesn't work as cleanly, people can 
also use Racket `#<<`...`#>>` "here strings" (or you can make a simple 
special embedded reader, which could also be a cue to an editor/IDE to 
treat as C code).


--
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/ab1f4127-7a49-a59d-10ce-4d2f0202a91a%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Matthias Felleisen]

> On Jun 3, 2019, at 12:33 PM, Kevin Forchione  wrote:
> 
> Oh! I see! That solves the expansio issue! Wonderful. You’ve opened up a 
> whole new set of possibilities for me. Thanks, Matthias.


I am glad I sent my solution a second time :) 

-- 
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/4727251D-33B3-4C88-A99E-F13F4E417AD6%40felleisen.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: New Package: Dynamic FFI - Write C Code Inline

[Jay McCarthy]

We're already on it...

https://github.com/jeapostrophe/adqc

See an example here:

https://github.com/jeapostrophe/adqc/blob/master/t/fib.rkt

It'll be more than just C though, because we'll be generating
verification conditions and we'll allow you to enforce time and space
bounds.

Jay

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

On Mon, Jun 3, 2019 at 11:53 AM zeRusski  wrote:
>
> Oh wow! IIUC it is super awesome. Would a natural next step be #lang terra?
> Hey Jay McCarthy would you like to mentor that effort ;-)
>
>
> On Saturday, 1 June 2019 20:06:29 UTC+1, David Benoit wrote:
>>
>> Hi All,
>>
>> I've recently released a new library for dynamically generating FFI bindings 
>> to C by parsing header files.
>> It also allows users to create FFI libraries by writing C functions directly 
>> inline in Racket programs.
>>
>> The library works as a native extension to Racket by linking with Clang's 
>> parser libraries and converting AST declarations into FFI objects.
>> As a result, the package depends on Clang and LLVM headers and libraries.  
>> See the documentation for info on installing dependencies.
>>
>> I've only built the package on GNU/Linux so far.  If anyone is interested in 
>> building the library on other OSes, it should be a fairly trivial port.
>>
>> I'd like to give a special thanks to Jay McCarthy, who came up with the idea 
>> for this project and was my adviser during its implementation.
>> I hope its something the Racket community might find useful!
>>
>> More usage examples are available in the docs and the test directory in the 
>> source code.
>>
>> Thanks!
>> David B
>>
>> I'll sign off with a quick preview:
>>
>> #lang at-exp racket/base
>>
>> (require dynamic-ffi/unsafe)
>>
>> @define-inline-ffi[struct-test]{
>>   #include 
>>   #include 
>>   #include 
>>
>>   typedef struct {
>> char *name;
>> uint64_t value;
>>   } number;
>>
>>   char* names[] = {"zero", "one", "two", "three", "four", "five", "six"
>>  "seven", "eight", "nine", "ten", "eleven", "twelve"};
>>
>>   number add(number a, number b) {
>> number c;
>> c.value = a.value + b.value;
>> if (c.value >12)  {
>>   fprintf(stderr, "error: this example can only count to twelve...\n");
>>   exit(1);
>> }
>> c.name = names[c.value];
>> return c;
>>  }
>> }
>>
>> ;; _list-structs are created by default.  I hope to optimize this in the 
>> future.
>>
>> (define n2 (list "two" 2))
>>
>> (define n7 (list "seven" 7))
>>
>> (printf "add(n2, n2): ~a\n" (struct-test 'add n2 n2))  ;; output: add(n2, 
>> n2): (four 4)
>> (printf "add(n7, n7): ~a\n" (struct-test 'add n7 n7))  ;; output: error: 
>> this example can only count to twelve...
>>
>>
>>
>>
>>
> --
> 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/628bf864-d261-481b-962c-2e54be297228%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAJYbDa%3DVWBy6vc3C8Ag6JWtYsbEwGL_pyozzM5-DAuzexDo1tw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Kevin Forchione]

> On Jun 3, 2019, at 9:09 AM, Matthias Felleisen  wrote:
> 
> 
> Or, 
> 
> #lang racket
> 
> (require (for-syntax ) racket/stxparam)
> 
> (define-syntax-parameter return (syntax-rules ()))
> (define-syntax-parameter false (syntax-rules ()))
> 
> (define-syntax fn
> (syntax-rules ()
>   [(_ (arg ...) body ...)
>(λ (arg ...)
>  (let/cc fn-exit
>(syntax-parameterize ([return (syntax-rules () [(_ x) (fn-exit x)])])
>  (syntax-parameterize ([false (syntax-rules () [(_) (return #f)])])
>body ...]))
> 
> ((fn (x y) (when (< x y) (return x)) y) 2 30) ; => 2
> ((fn (x y) (when (< x y) (false)) y) 2 30)   ;=> #f
> 

Oh! I see! That solves the expansio issue! Wonderful. You’ve opened up a whole 
new set of possibilities for me. Thanks, Matthias.

-- 
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/F77FB88D-5D84-4F67-87F5-8F53717DFF61%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Matthias Felleisen]

Or, 

#lang racket

(require (for-syntax ) racket/stxparam)

(define-syntax-parameter return (syntax-rules ()))
(define-syntax-parameter false (syntax-rules ()))

(define-syntax fn
 (syntax-rules ()
   [(_ (arg ...) body ...)
(λ (arg ...)
  (let/cc fn-exit
(syntax-parameterize ([return (syntax-rules () [(_ x) (fn-exit x)])])
  (syntax-parameterize ([false (syntax-rules () [(_) (return #f)])])
body ...]))

((fn (x y) (when (< x y) (return x)) y) 2 30) ; => 2
((fn (x y) (when (< x y) (false)) y) 2 30)   ;=> #f



-- 
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/B99E2A20-68EE-46C3-B8F4-2066F3C063CD%40felleisen.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Second Call for Submissions: ICFP Student Research Competition

['Sam Tobin-Hochstadt' via users-redirect]

 ICFP 2019 Student Research Competition
Call for Submissions

ICFP invites students to participate in the Student Research
Competition in order to present their research and get feedback from
prominent members of the programming language research
community. Please submit your extended abstracts through the
submission website.

### Important dates

Submissions due:14 Jun 2019 (Friday) 
https://icfp19src.hotcrp.com
Notification:   28 Jun 2019 (Friday)
Conference: 18 August (Sunday) - 23 August (Friday)


Each submission (referred to as "abstract" below) should include the
student author’s name and e-mail address; institutional affiliation;
research advisor’s name; ACM student member number; category
(undergraduate or graduate); research title; and an extended abstract
addressing the following:

* Problem and Motivation: Clearly state the problem being addressed and
  explain the reasons for seeking a solution to this problem.

* Background and Related Work: Describe the specialized (but
  pertinent) background necessary to appreciate the work in the
  context of ICFP areas of interest. Include references to the
  literature where appropriate, and briefly explain where your work
  departs from that done by others.

* Approach and Uniqueness: Describe your approach in addressing the
  problem and clearly state how your approach is novel.

* Results and Contributions: Clearly show how the results of your work
  contribute to programming language design and implementation in
  particular and to computer science in general; explain the
  significance of those results.

* Submissions must be original research that is not already published
  at ICFP or another conference or journal. One of the goals of the
  SRC is to give students feedback on ongoing, unpublished
  work. Furthermore, the abstract must be authored solely by the
  student. If the work is collaborative with others and*or part of a
  larger group project, the abstract should make clear what the
  student’s role was and should focus on that portion of the work.

* Formatting: Submissions must be in PDF format, printable in black
  and white on US Letter sized paper, and interpretable by common PDF
  tools. All submissions must adhere to the "ACM Small" template that
  is available (in both LaTeX and Word formats) from
  https://www.acm.org/publications/authors/submissions. For authors
  using LaTeX, a lighter-weight package, including only the essential
  files, is available from
  http://sigplan.org/Resources/Author/#acmart-format. The submission
  must not exceed 3 pages in PDF format. Reference lists do not count
  towards the 3-page limit.

Further information is available at the ICFP SRC website:
https://icfp19.sigplan.org/track/icfp-2019-Student-Research-Competition

ICFP Student Research Competition Chair:
  William J. Bowman (University of British Columbia)

-- 
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/5cf544f460cba_78b42ab427c125b89235b%40homer.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Matthias Felleisen]

#lang racket

(require (for-syntax ) racket/stxparam)

(define-syntax-parameter return (syntax-rules ()))

(define-syntax fn
  (syntax-rules ()
[(_ (arg ...) body ...)
 (λ (arg ...)
   (let/cc fn-exit
 (syntax-parameterize ([return (syntax-rules () [(_ x) (fn-exit x)])])
   body ...)))]))

(define-syntax false
  (syntax-rules ()
[(_) (return #f)]))


((fn (x y) (when (< x y) (return x)) y) 2 30) ; => 2
((fn (x y) (when (< x y) (false)) y) 2 30)   ;=> #f

-- 
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/18038548-A78C-487B-A2A8-7F1C864903BF%40felleisen.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Kevin Forchione]

> On Jun 3, 2019, at 8:51 AM, Matthias Felleisen  wrote:
> 
> 
> My code run your examples. Whay is missinng? 
> 
Here’s what I’ve been trying to run.

#lang racket

(require (for-syntax racket/syntax)
 racket/stxparam)

(define-syntax-parameter false
  (lambda (stx)
  (raise-syntax-error (syntax-e stx) "can only be used inside lambda.")))

(define-syntax (fn stx)
  (syntax-case stx ()
[(_ (arg ...) body0 body ...)
 (with-syntax ([return (format-id #'body0 "~a" #'return)])
   #'(λ (arg ...) (let/cc return
(syntax-parameterize ([false #'return]) body0 body 
...]))

((fn (x y) (when (< x y) (return x)) y) 2 30) ; => 2
((fn (x y) (when (< x y) (false)) y) 2 30)


Kevin

-- 
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/CC4AB8E6-76E4-43C3-9D2D-497F7467B858%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] 7 GUIs

['John Clements' via users-redirect]

Would it make sense to post the early ones to the 7GUIs site? They might be the 
easiest ones for others to understand.

John

> On Jun 1, 2019, at 4:47 PM, Matthias Felleisen  wrote:
> 
> 
> Someone recently mentioned the “7 GUIs” task. I spent a couple of days to 
> write up minimal solutions: 
> 
>  https://github.com/mfelleisen/7GUI/blob/master/task-7.rkt 
> 
> In my spare time, I will develop this repo in more depth (types, units, etc) 
> because it looks like a reasonably educational task. 
> 
> 
> 
> -- 
> 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/9A5BBCC3-C65A-4BFD-8C37-F7F35BCF39E7%40felleisen.org.
> For more options, visit https://groups.google.com/d/optout.



-- 
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/8d3d750e-6df3-41dd-84fd-1e43a2f261c1%40mtasv.net.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: New Package: Dynamic FFI - Write C Code Inline

[zeRusski]

Oh wow! IIUC it is super awesome. Would a natural next step be #lang terra 
?
Hey Jay McCarthy would you like to mentor that effort ;-)


On Saturday, 1 June 2019 20:06:29 UTC+1, David Benoit wrote:
>
> Hi All,
>
> I've recently released a new library 
>  for dynamically 
> generating FFI bindings to C by parsing header files.
> It also allows users to create FFI libraries by writing C functions 
> directly inline in Racket programs.  
>
> The library works as a native extension to Racket by linking with Clang's 
> parser libraries and converting AST declarations into FFI objects.
> As a result, the package depends on Clang and LLVM headers and libraries.  
> See the documentation 
>  for info on 
> installing dependencies.
>
> I've only built the package on GNU/Linux so far.  If anyone is interested 
> in building the library on other OSes, it should be a fairly trivial port.
>
> I'd like to give a special thanks to Jay McCarthy, who came up with the 
> idea for this project and was my adviser during its implementation.
> I hope its something the Racket community might find useful!
>
> More usage examples are available in the docs and the test directory 
>  in the source 
> code.
>
> Thanks!
> David B
>
> I'll sign off with a quick preview:
>
> #lang at-exp racket/base
>
> (require dynamic-ffi/unsafe)
>
> @define-inline-ffi[struct-test]{
>   #include 
>   #include 
>   #include 
>
>   typedef struct {
> char *name;
> uint64_t value;
>   } number;
>
>   char* names[] = {"zero", "one", "two", "three", "four", "five", "six"
>  "seven", "eight", "nine", "ten", "eleven", "twelve"};
>
>   number add(number a, number b) {
> number c;
> c.value = a.value + b.value;
> if (c.value >12)  {
>   fprintf(stderr, "error: this example can only count to twelve...\n");
>   exit(1);
> }
> c.name = names[c.value];
> return c;
>  }
> }
>
> ;; _list-structs are created by default.  I hope to optimize this in the 
> future.
>
> (define n2 (list "two" 2))
>
> (define n7 (list "seven" 7))
>
> (printf "add(n2, n2): ~a\n" (struct-test 'add n2 n2))  ;; output: add(n2, 
> n2): (four 4)
> (printf "add(n7, n7): ~a\n" (struct-test 'add n7 n7))  ;; output: error: this 
> example can only count to twelve...
>
>
>
>
>
>

-- 
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/628bf864-d261-481b-962c-2e54be297228%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Matthias Felleisen]

My code run your examples. Whay is missinng? 



> On Jun 3, 2019, at 11:36 AM, Kevin Forchione  wrote:
> 
> 
> 
>> On Jun 3, 2019, at 4:54 AM, Alex Knauth  wrote:
>> 
>> 
>> 
>>> On Jun 3, 2019, at 1:02 AM, Kevin Forchione  wrote:
 On Jun 2, 2019, at 7:13 PM, Matthias Felleisen  
 wrote:
> On Jun 2, 2019, at 9:41 PM, Kevin Forchione  wrote:
> 
> Hi guys,
> I’ve been working with macros and let/cc and have a situation where I 
> have the 2nd macro bound to the let/cc return of the first. No idea how 
> I’d do that, but here’s an example of what I’m attempting to do:
> 
> #lang racket
> 
> (require (for-syntax racket/syntax))
> 
> (define-syntax (fn stx)
>  (syntax-case stx ()
>[(_ (arg ...) body0 body ...)
> (with-syntax ([return (format-id #'body0 "~a" #'return)])
>   #'(λ (arg ...) (let/cc return body0 body ...)))]))
> 
> (define-syntax (false stx)
>  (syntax-case stx ()
>[(_) #'(return #f)]))
> 
> ((fn (x y) (when (< x y) (return x)) y) 2 30) ; => 2
> ((fn (x y) (when (< x y) (false)) y) 2 30)   ;=> #f
> 
> My thought is that the 2nd macro doesn’t know about the 1st macro except 
> perhaps through the six of compile time… so that if I had define-syntax 
> working with a lambda I’d have all the pieces available in the (fn …) but 
> not sure what tools I might use to accomplish that.
> 
> Any ideas are appreciated!
 
 This situation calls for syntax-parameters in my mind: see docs, too — 
 Matthias
>>> 
>>> Hmmm. A cursory glance at some of the examples suggests I’ll have to do 
>>> some exploring on this. One issue that it looks like I’ll have to work out 
>>> is that “false” in my example needs to translate to “(return #f)” and I’m 
>>> not sure at this stage where a syntax-parameterize statement would be 
>>> positioned in the fn macro
>> 
>> It should go around the same set of expressions that the `return` identifier 
>> would have been unhygienically bound in. For this example, that means around 
>> `body0 body ...`, or in context:
>> 
>> (λ (arg ...) (let/cc k (syntax-parameterize ([return ( #'k )]) body0 
>> body ...)))
>> 
>>> (or how it would know to use it unless it could interrogate the body list 
>>> looking for that value. That might be what I’d need to do here…
>> 
>> I'm not sure what you mean by interrogate the body, but if you're referring 
>> to the syntax-parameterize needing access to the continuation bound by 
>> let/cc, then your right. That's why in the example above, the 
>> syntax-parameterize needs to be inside of the let/cc where `k` is bound, and 
>> the new parameter value needs to refer to `k`. Is that what you meant?
> 
> That’s what I was thinking, but the transformation would have to be something 
> more like:
> 
> (let/cc return
> (syntax-parameterize ([false #'(return #f)]) body0 
> body ...]))
> 
> And that doesn’t work. I imagine that would expand into ((return #f)). 
> 
> Kevin

-- 
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/4F2802CF-7FF0-4C44-8843-97D6FC448239%40felleisen.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Mutating hash-map while iterating

[zeRusski]

Is it ok to mutate a hash while iterating over it say in one of ~for~ forms?
Specifically I want to filter (that is drop) some keys, but I'm also 
interested in
mutation in general. I guess the answer lies in whether forms like 
~in-dict~ etc
create lazy streams that hold on to the table?

Relevant docs that I managed to dig out: 
- hash-map 

 
seems to suggest that at least dropping keys is fine, but that only
  talks about hash-map procedure specifically not other forms;
- caveats concerning concurrent modifications 

 
maybe kinda relevant (I've asked 

  similar question about concurrency 

 
some time ago).

Here're some examples to be concrete:

#+begin_src racket
  ;; IMO ok according to docs?
  (hash-map h (λ (k v) (when (pred v) (hash-remove! h k

  ;; probably ok assuming it translates to hash-map?
  (dict-map h (λ (k v) (when (pred v) (dict-remove! h k

  ;; is that ok?
  (for (((k v) (in-dict h))
#:when (pred v))
(dict-remove! h k))

  ;; defensive solution
  (let ((fails (for/list (((k v) (in-dict h))
  #:when (pred v))
 k)))
(for-each (curry dict-remove! h) fails))
#+end_src

That question wouldn't arise were I to deal with immutable data, but I'm 
not.

-- 
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/b57fc367-64b3-434b-93bb-ddb0684d26fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Kevin Forchione]

> On Jun 3, 2019, at 4:54 AM, Alex Knauth  wrote:
> 
> 
> 
>> On Jun 3, 2019, at 1:02 AM, Kevin Forchione > > wrote:
>>> On Jun 2, 2019, at 7:13 PM, Matthias Felleisen >> > wrote:
 On Jun 2, 2019, at 9:41 PM, Kevin Forchione >>> > wrote:
 
 Hi guys,
 I’ve been working with macros and let/cc and have a situation where I have 
 the 2nd macro bound to the let/cc return of the first. No idea how I’d do 
 that, but here’s an example of what I’m attempting to do:
 
 #lang racket
 
 (require (for-syntax racket/syntax))
 
 (define-syntax (fn stx)
  (syntax-case stx ()
[(_ (arg ...) body0 body ...)
 (with-syntax ([return (format-id #'body0 "~a" #'return)])
   #'(λ (arg ...) (let/cc return body0 body ...)))]))
 
 (define-syntax (false stx)
  (syntax-case stx ()
[(_) #'(return #f)]))
 
 ((fn (x y) (when (< x y) (return x)) y) 2 30) ; => 2
 ((fn (x y) (when (< x y) (false)) y) 2 30)   ;=> #f
 
 My thought is that the 2nd macro doesn’t know about the 1st macro except 
 perhaps through the six of compile time… so that if I had define-syntax 
 working with a lambda I’d have all the pieces available in the (fn …) but 
 not sure what tools I might use to accomplish that.
 
 Any ideas are appreciated!
>>> 
>>> This situation calls for syntax-parameters in my mind: see docs, too — 
>>> Matthias
>> 
>> Hmmm. A cursory glance at some of the examples suggests I’ll have to do some 
>> exploring on this. One issue that it looks like I’ll have to work out is 
>> that “false” in my example needs to translate to “(return #f)” and I’m not 
>> sure at this stage where a syntax-parameterize statement would be positioned 
>> in the fn macro
> 
> It should go around the same set of expressions that the `return` identifier 
> would have been unhygienically bound in. For this example, that means around 
> `body0 body ...`, or in context:
> 
> (λ (arg ...) (let/cc k (syntax-parameterize ([return ( #'k )]) body0 
> body ...)))
> 
>> (or how it would know to use it unless it could interrogate the body list 
>> looking for that value. That might be what I’d need to do here…
> 
> I'm not sure what you mean by interrogate the body, but if you're referring 
> to the syntax-parameterize needing access to the continuation bound by 
> let/cc, then your right. That's why in the example above, the 
> syntax-parameterize needs to be inside of the let/cc where `k` is bound, and 
> the new parameter value needs to refer to `k`. Is that what you meant?

That’s what I was thinking, but the transformation would have to be something 
more like:

(let/cc return
(syntax-parameterize ([false #'(return #f)]) body0 body 
...]))

And that doesn’t work. I imagine that would expand into ((return #f)). 

Kevin

-- 
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/135285AD-843C-4258-8034-EF9F59E27EB0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] New Package: Dynamic FFI - Write C Code Inline

[Konrad Hinsen]

On 01/06/2019 21:06, David Benoit wrote:
I've recently released a new library 
 for dynamically 
generating FFI bindings to C by parsing header files.
It also allows users to create FFI libraries by writing C functions 
directly inline in Racket programs.


Thanks, this looks very promising! Even more so with the option of 
generating static FFIs that I saw in the documentation. That's important 
in practice to prevent LLVM and clang becoming dependencies for lots of 
Racket code.


Now if you could also provide a tool for dynamically generating free 
time for playing with this, I'd be even happier ;-)



Konrad.

--
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/0bf94bb8-6211-13f0-a86e-4adf027f31ee%40fastmail.net.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] macros and let/cc

[Alex Knauth]

> On Jun 3, 2019, at 1:02 AM, Kevin Forchione  wrote:
>> On Jun 2, 2019, at 7:13 PM, Matthias Felleisen > > wrote:
>>> On Jun 2, 2019, at 9:41 PM, Kevin Forchione >> > wrote:
>>> 
>>> Hi guys,
>>> I’ve been working with macros and let/cc and have a situation where I have 
>>> the 2nd macro bound to the let/cc return of the first. No idea how I’d do 
>>> that, but here’s an example of what I’m attempting to do:
>>> 
>>> #lang racket
>>> 
>>> (require (for-syntax racket/syntax))
>>> 
>>> (define-syntax (fn stx)
>>>  (syntax-case stx ()
>>>[(_ (arg ...) body0 body ...)
>>> (with-syntax ([return (format-id #'body0 "~a" #'return)])
>>>   #'(λ (arg ...) (let/cc return body0 body ...)))]))
>>> 
>>> (define-syntax (false stx)
>>>  (syntax-case stx ()
>>>[(_) #'(return #f)]))
>>> 
>>> ((fn (x y) (when (< x y) (return x)) y) 2 30) ; => 2
>>> ((fn (x y) (when (< x y) (false)) y) 2 30)   ;=> #f
>>> 
>>> My thought is that the 2nd macro doesn’t know about the 1st macro except 
>>> perhaps through the six of compile time… so that if I had define-syntax 
>>> working with a lambda I’d have all the pieces available in the (fn …) but 
>>> not sure what tools I might use to accomplish that.
>>> 
>>> Any ideas are appreciated!
>> 
>> This situation calls for syntax-parameters in my mind: see docs, too — 
>> Matthias
> 
> Hmmm. A cursory glance at some of the examples suggests I’ll have to do some 
> exploring on this. One issue that it looks like I’ll have to work out is that 
> “false” in my example needs to translate to “(return #f)” and I’m not sure at 
> this stage where a syntax-parameterize statement would be positioned in the 
> fn macro

It should go around the same set of expressions that the `return` identifier 
would have been unhygienically bound in. For this example, that means around 
`body0 body ...`, or in context:

(λ (arg ...) (let/cc k (syntax-parameterize ([return ( #'k )]) body0 
body ...)))

> (or how it would know to use it unless it could interrogate the body list 
> looking for that value. That might be what I’d need to do here…

I'm not sure what you mean by interrogate the body, but if you're referring to 
the syntax-parameterize needing access to the continuation bound by let/cc, 
then your right. That's why in the example above, the syntax-parameterize needs 
to be inside of the let/cc where `k` is bound, and the new parameter value 
needs to refer to `k`. Is that what you meant?

Alex Knauth

> Kevin

-- 
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/ECF4DCD1-C651-42BC-8138-5314640F2862%40knauth.org.
For more options, visit https://groups.google.com/d/optout.