[racket-users] Compiling into Linklets

['Paulo Matos' via Racket Users]

Hi,

I am slowly getting the hang of linklets and I am playing with them in
my spare free time.

As far as I understand the current way to obtain linklets is to use
bootstrap-run.rkt in racket/src/expander.

I wrote a simple interactive program split into two modules:
factorial-input.rkt:
#lang racket/base

(require "factorial.rkt")

(let loop ()
  (printf "Enter a number: ")
  (define n (read))
  (cond
[(exact-positive-integer? n)
 (printf "~a! = ~a~n" n (factorial n))]
[else
 (printf "Invalid value~n")
 (loop)]))


factorial.rkt:
#lang racket/base

(provide factorial)

(define (factorial n)
  (if (= n 1)
  1
  (* n (factorial (- n 1)

Now I would like to compile the whole thing into linklets, so I try from
today's master branch HEAD:
racket/src/expander $ racket bootstrap-run.rkt --linklets -s -o
factorial-input.ll.rkt -t
/home/pmatos/Projects/redjacket/examples/factorial-input.rkt

First thing that tripped me up was that the output went to the terminal
instead of the file factorial-input.ll.rkt.

However, the biggest concern I had was that even though one of the lines
in the terminal says:
compile: /home/pmatos/Projects/redjacket/examples/factorial.rkt

followed by:
#hasheq((#f
 .
 #hasheq((0
  .
  (linklet
   ((.get-syntax-literal!)
(.set-transformer!)
((read 1/read))
(factorial)
(print-values))
   ()
   (void)
   (call-with-values
(lambda ()
  ((letrec-values (((loop_1)
(lambda ()
  (begin
'loop
(let-values ((()
  (begin
(printf
 "Enter a
number: ")
(values
  (let-values (((n_2) (1/read)))
(if (exact-positive-integer?
 n_2)
  (let-values ()
(printf
 "~a! = ~a~n"
 n_2
 (factorial n_2)))
  (let-values ()
(begin
  (printf
   "Invalid value~n")
  (loop_1))
 loop_1)))
print-values)
   (void)))
 (data
  .
  (linklet
   ((deserialize-module-path-indexes
 syntax-module-path-index-shift
 syntax-shift-phase-level
 module-use
 deserialize))
   (.mpi-vector)
   (define-values (.inspector) (current-code-inspector))
   (define-values
(.mpi-vector)
(deserialize-module-path-indexes
 '#(#('#%read)
#&factorial-input
#("factorial.rkt" 1)
#(racket/base)
#("private/base.rkt" 3)
#("pre-base.rkt" 4)
#("modbeg.rkt" 5))
 '#(0 2 6 1 3)
 (decl
  .
  (linklet
   ((deserialize-module-path-indexes
 syntax-module-path-index-shift
 syntax-shift-phase-level
 module-use
 deserialize)
(.mpi-vector))
   (self-mpi requires provides phase-to-link-modules)
   (define-values
(self-mpi)
(unsafe-vector*-ref .mpi-vector 3))
   (define-values
(requires)
(let-values (((data)
  '#(#()
 #()
 #()
 #(#:cons #:list 3 0 #:mpi 4 #:mpi 1
()
  (deserialize
   .mpi-vector
   #f
   #f
   '0
   (unsafe-vector*-ref data 0)
 

[racket-users] Racket News - Issue 11

['Paulo Matos' via Racket Users]

The big 11 is here! :)

https://racket-news.com/2019/07/racket-news-issue-11.html

Enjoy, preferably with a strong espresso!
-- 
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/1b61022f-c146-a0cb-d445-891d8d9f4bae%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 10

['Paulo Matos' via Racket Users]

It's here!!!

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

Have a good weekend,
-- 
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/f6a730ed-72f1-ba93-ffe3-21bd4af9dfe8%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Typed Racket segmentation fault

['Paulo Matos' via Racket Users]

On 05/06/2019 16:47, Philip McGrath wrote:
> What version of Racket are you using? I get a segfault in 7.2, but 7.3
> works for me.

I see the segfault in 7.1 but not in 7.2 or 7.3. Then I run it under
valgrind and I see it in all the versions. :)
It's there, but sometimes hiding.

Will take a look.

> -Philip
> 
> 
> On Wed, Jun 5, 2019 at 10:42 AM James Geddes  > wrote:
> 
> Dear All,
> 
> The following Typed Racket program is intended to produce an image
> of the Mandelbrot set (but it doesn't bother actually displaying the
> image).
> 
> Running the program using command-line Racket causes a crash.
> Specifically, Racket terminates with the error message:
> 
>         Segmentation fault: 11
> 
> However,
> 
> 1. The program runs successfully in DrRacket;
> 
> 2. Reducing the size of the image to, say, 200 x 200 (by changing
> the last arguments in the calls to `make-ticks`) also results in
> successful termination, without a segmentation fault.
> 
> Any advice appreciated!
> 
> (PS: I'm not actually that interested in making pictures. I'm trying
> to do some speed benchmarks to show my colleagues, particularly
> those who argue that Python is faster, and this example happened to
> be on hand.)
> 
> 
> James
> 
> 
> 
> 
> #lang typed/racket
> 
> ;; Generate an image of the Mandelbrot set
> (https://en.wikipedia.org/wiki/Mandelbrot_set)
> 
> (define *iteration-limit* : Integer 50)
> 
> (: mandel (-> Float-Complex Integer))
> ;; Given c, iterate z <- z^2 + c starting from z = 0 until either
> |z| > 2 or the number of iterations
> ;; exceeds *iteration-limit*. Returns the number of iterations required.
> (define (mandel c)
>   (let mandel-iter ([z 0.0+0.0i]
>                     [i 0])
>     (if (or (>= i *iteration-limit*) (> (magnitude z) 2.0))
>         i
>         (mandel-iter (+ c (sqr z)) (+ i 1)
> 
> (: brot ((Listof Float) (Listof Float) -> (Listof Integer)))
> ;; Apply mandel to a rectangular grid of complex numbers
> (define (brot xs ys)
>   (for*/list : [Listof Integer]
>       ([y (in-list ys)]
>        [x (in-list xs)])
>     (mandel (make-rectangular x y
> 
> (: make-ticks (-> Float Float Integer (Listof Float)))
> (define (make-ticks min max resolution)
>   (range min max (/ (- max min) resolution)))
> 
> (define *xs* (make-ticks -1.5 0.5 300))
> (define *ys* (make-ticks -1.0 1.0 300))
> 
> ;; Compute a Mandelbrot image (but then discard it)
> (void (brot *xs* *ys*))
> 
> 
> 
> 
> -- 
> 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/194F0EE9-0B9E-412B-A2C0-BCE51CD0AA75%40gmail.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/CAH3z3gY4Cte5p0ZuY6yCmjAc1jjebZQ6GTaQQZJXQxdoqaop2Q%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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/cea3ba1c-64fe-2d39-a8ed-98570751fb3e%40linki.tools.
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.

Re: [racket-users] Some concern about ChezScheme...

['Paulo Matos' via Racket Users]

On 28/05/2019 04:56, 'John Clements' via Racket Users wrote:
> I’m responding to my own message, because (thanks to Andy Keep) I’ve now 
> discovered a big chunk of the answer.
> 
> Specifically, it looks Jeremy Siek’s compilers class includes a textbook 
> written by him and Ryan Newton whose preface appears to answer all of my 
> questions; specifically, that they did merge Ghuloum’s approach with 
> nanopasses.
> 
> https://iu.instructure.com/courses/1735985
> 
> https://github.com/IUCompilerCourse/Essentials-of-Compilation
> 

These are very good references on compilation I was not aware of. Thanks
for posting.

-- 
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/dbd99ee3-b525-447a-2aea-d9f69a695f82%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: chez-runner plugin

['Paulo Matos' via Racket Users]

On 22/05/2019 18:00, francesco bennardo wrote:
> 
> 
> Il giorno mercoledì 22 maggio 2019 15:34:31 UTC+2, francesco bennardo ha
> scritto:
> 
> Someone knows home to use the "chez-runner" plugin? I've installed
> it but do not works.
> 
> 
> I use Racket yes, but I use chez scheme too.  Anyway they are different.
> I want to use both. If I do not put #lang racket in the definition, when
> I press the button "Run Chez" I get nothing, no prompt and I cannot
> continue.
>

You cannot use #lang racket if you want to run your script in Chez,
because Chez doesn't know what that means. I assume that this
chez-runner was an experiment and it lacks communication with the
interactions window.

My apologies but can't help you further, at this point, you have to open
an issue at:
https://github.com/Syntacticlosure/chez-runner/issues

-- 
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/8ab208cc-2c25-b242-c0e5-2a5fc35f86b0%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: chez-runner plugin

['Paulo Matos' via Racket Users]

I am talking without running it or even having used that plugin but it
looks like it's passing the definitions you have in your window but Chez
doesn't know `#l` in line one. I imagine you have something like `#lang
racket`?

Why not just use Racket then? Also, are you sure you want to run Chez
like that or are you really after Racket-on-Chez which is something
completely different?

On 22/05/2019 17:46, francesco bennardo wrote:
> Hello Paulo, thank you for your help. I have the button "Run Chez". I've
> already installed it. When I press the button I get this error:
> Exception in read: invalid sharp-sign prefix #l at line 1, char 1 of
> C:\Users\Francis\AppData\Local\Temp\chezscheme_temp_file15585396541558539654360.
> I start with the #lang racket only in the definition.
> 
> Il giorno mercoledì 22 maggio 2019 15:34:31 UTC+2, francesco bennardo ha
> scritto:
> 
> Someone knows home to use the "chez-runner" plugin? I've installed
> it but do not works.
> 
> -- 
> 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/f45532de-3edf-46ee-8295-744d76ee51f6%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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/b7218387-d0c3-46fb-7baa-45e3d3476a19%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] chez-runner plugin

['Paulo Matos' via Racket Users]

Hi,

It seems you are referring to this DrRacket plugin:
https://github.com/Syntacticlosure/chez-runner

Optimally Syntacticlosure should be able to help a lot more than I can
and if what I say doesn't make sense, I suggest you open an issue with
your question at :
https://github.com/Syntacticlosure/chez-runner/issues

However, I quickly glanced at the code and it seems it's a plugin for
DrRacket that simply calls `scheme --script` with what you have in the
definitions once you click the button `Run Chez`.
I suggest you start DrRacket, look for the button. If it's not there,
report an issue using the link above.

Paulo

On 22/05/2019 15:34, francesco bennardo wrote:
> Someone knows home to use the "chez-runner" plugin? I've installed it
> but do not works.
> 
> -- 
> 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/704b5a48-9e5f-4850-b92f-98dbef014472%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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/22979faf-7823-d97a-5a33-56d4cfb6a2df%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 8

['Paulo Matos' via Racket Users]

Issue 8 is here.

http://racket-news.com/2019/05/racket-news-issue-8.html

Ristretto time, 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/b7c1bb30-ad6f-6bc0-6ccd-e89e859a3697%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket News - Issue 7

['Paulo Matos' via Racket Users]

Hi Stephen,

Great to hear you're enjoying RN and enjoyed my choice of Automata via
Macros for this issue.

It's always exciting to hear that people are enjoying these issues.

All the best,
Paulo Matos

On 02/05/2019 22:13, Stephen Foster wrote:
> Yes!  Years ago, "Automata via Macros" was the paper that helped me see
> that macros are cool. :)  Thanks for including that.
> 
> I've been enjoying these Racket News issues!
> 
> On Wednesday, May 1, 2019 at 7:21:56 AM UTC-7, Paulo Matos wrote:
> 
> Issue 7 is here.
> 
> http://racket-news.com/2019/05/racket-news-issue-7.html
> 
> 
> Americano time, 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 7

['Paulo Matos' via Racket Users]

Issue 7 is here.

http://racket-news.com/2019/05/racket-news-issue-7.html

Americano time, 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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] SIGSEGV when running Racket

['Paulo Matos' via Racket Users]

On 22/04/2019 00:23, polarish...@gmail.com wrote:
> Hello everyone,
> 
> I observed some exceptions like `SIGSEGV MAPERR si_code 1 fault on addr
> 0x7f6f4e30fff0` when running a Racket program. Any ideas why this happens?

Hi Shaobo,

Unless you're using an unsafe op / ffi, it's a bug. Report it please.

Can you fill in a report here: https://github.com/racket/racket/issues/new

Attach example to allow us to reproduce and debug the issue. Add
information about OS, machine architecture. We will ask for more
information if necessary.

Thanks,

Paulo

> 
> Thanks,
> Shaobo
> 
> -- 
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket News - Issue 6

['Paulo Matos' via Racket Users]

On 18/04/2019 10:25, Alexander Shopov wrote:
> And a bit more popularity - there will be links from
> Linux Weekly News: Announcements -> Newsletters -> Developement to the
> news letter:
> 

Hi Alex,

Many thanks for this. It looks great.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 6

['Paulo Matos' via Racket Users]

Issue 6 is here.

http://racket-news.com/2019/04/racket-news-issue-6.html

It's cappuccino time, enjoy your weekend!
-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Generate really large random numbers in Racket

['Paulo Matos' via Racket Users]

On 01/04/2019 23:37, Robby Findler wrote:
> Generate multiples of those and combine them (shifting old ones over
> and adding new ones as the lowest digits)?
> 
> I'm not sure of a good way to generate nats uniformly at random where
> you don't specify an upper bound, but Neil Toronto suggested something
> crazy we used this paper:
> http://users.cs.northwestern.edu/~robby/pubs/papers/jfp2017-nfmf.pdf
> 

Awesome! I just skimmed the paper and the enumeration part brought
memories of a technique we developed for unbounded model checking almost
a decade ago.

Your figure 3 is not too far from our figures 4 and 5 on page 9 of:
https://www.researchgate.net/publication/225399880_A_Lazy_Unbounded_Model_Checker_for_Event-B

Also, I should point out that all this Lazy Unbounded Model Checking
research was developed in the good old PLT Scheme. :)

Should check if the thing still runs in todays Racket...

Now I should really grab a coffee and read your paper properly!

Paulo Matos

> Robby
> 
> On Mon, Apr 1, 2019 at 4:31 PM  wrote:
>>
>> Hello everyone,
>>
>> It appears that the largest number returned by the random function in Racket 
>> is 4294967087-1 for a good reason. Are there any libraries or simple 
>> approaches to generate a number larger than that?
>>
>> Thanks,
>> Shaobo
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Generate really large random numbers in Racket

['Paulo Matos' via Racket Users]

Check the math library by Neil Toronto:
https://docs.racket-lang.org/math/base.html?q=random#%28part._.Random_.Number_.Generation%29

(random-natural k) → Natural

  k : Integer

Returns a random natural number less than k, which must be positive. Use
(random-natural k) instead of (random k) when k could be larger than
4294967087.


On 01/04/2019 23:31, polarish...@gmail.com wrote:
> Hello everyone,
> 
> It appears that the largest number returned by the random function in
> Racket is 4294967087-1 for a good reason. Are there any libraries or
> simple approaches to generate a number larger than that?
> 
> Thanks,
> Shaobo
> 
> -- 
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 5

['Paulo Matos' via Racket Users]

Issue 5 is here.

https://racket-news.com/2019/04/racket-news-issue-5.html

Come on - make a strong espresso today. You know you deserve it!
-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket News - Issue 4

['Paulo Matos' via Racket Users]

On 18/03/2019 14:55, Jérôme Martin wrote:
> Thank you so much for this!
> 

Opened this for you:
https://github.com/racket-news/racket-news.github.io-src/issues/12

Feel free to add to it if something else comes to mind.

> If I can suggest a project for next month's spotlight:
> 
> - Christopher Lemmer Webber, co-editor of the ActivityPub specs, is
> working on a distributed social network library based on Racket:
> https://gitlab.com/spritely
>   It's still in early development, but I think it's an important project
> to give visibility to ;)
> 
> Maybe we could also have a spotlight section for #lang languages too?
> 
> - The brag parser generator is obviously a good project.
> - The video lang by Leif is also pretty awesome.
> - The slideshow lang might be a great pick too.
> - Obviously scribble.
> 
> On Friday, March 15, 2019 at 12:03:47 PM UTC+1, Paulo Matos wrote:
> 
> I have just published Issue 4 at
> 
> http://racket-news.com/2019/03/racket-news-issue-4.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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket News - Issue 4

['Paulo Matos' via Racket Users]

On 18/03/2019 16:51, Matt Jadud wrote:
> I'd be willing to pitch in some text around the thinking about the 'tbl'
> library for introductory data work, so that people might push back on
> it. Or, it would at least give a coherent surface for some conversation
> around collaboration.
> 
> If not next issue, at some point. Or, not. I'm flexible. It would force
> me to get some things in writing, though, which is useful.
> 

Hey Matt, that would be great. If you want to send in a pitch for the
Project Spotlight or any other section, feel free. It would be great to
have more contributions! :)

> Cheers,
> Matt
> 
> On Mon, Mar 18, 2019 at 9:55 AM Jérôme Martin
> mailto:jerome.martin@gmail.com>> wrote:
> 
> Thank you so much for this!
> 
> If I can suggest a project for next month's spotlight:
> 
> - Christopher Lemmer Webber, co-editor of the ActivityPub specs, is
> working on a distributed social network library based on Racket:
> https://gitlab.com/spritely
>   It's still in early development, but I think it's an important
> project to give visibility to ;)
> 
> Maybe we could also have a spotlight section for #lang languages too?
> 
> - The brag parser generator is obviously a good project.
> - The video lang by Leif is also pretty awesome.
> - The slideshow lang might be a great pick too.
> - Obviously scribble.
> 
> On Friday, March 15, 2019 at 12:03:47 PM UTC+1, Paulo Matos wrote:
> 
> I have just published Issue 4 at
> 
> http://racket-news.com/2019/03/racket-news-issue-4.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
> .
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket News - Issue 4

['Paulo Matos' via Racket Users]

Hi Jerome,

Thanks for all the suggestions.

On 18/03/2019 14:55, Jérôme Martin wrote:
> Thank you so much for this!
> 
> If I can suggest a project for next month's spotlight:
> 
> - Christopher Lemmer Webber, co-editor of the ActivityPub specs, is
> working on a distributed social network library based on Racket:
> https://gitlab.com/spritely
>   It's still in early development, but I think it's an important project
> to give visibility to ;)
> 

Sure! That's great. I will add it to the submissions for issue 5 or 6.

> Maybe we could also have a spotlight section for #lang languages too?
> 
> - The brag parser generator is obviously a good project.
> - The video lang by Leif is also pretty awesome.
> - The slideshow lang might be a great pick too.
> - Obviously scribble.
> 

We could do that but I have been using project spotlight in the broader
sense of standalone project and/or lang. For example, I featured the
rosette #lang a couple of issues ago.

I can obviously have one more section but the reason I would prefer not
to is because at about ~26 issues per year, I would like to have good
content for a long time coming, if you know what I mean. :)

Therefore I would prefer to schedule those great langs in the project
spotlight for issues up ahead. What do you think?

Paulo Matos

> On Friday, March 15, 2019 at 12:03:47 PM UTC+1, Paulo Matos wrote:
> 
> I have just published Issue 4 at
> 
> http://racket-news.com/2019/03/racket-news-issue-4.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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 4

['Paulo Matos' via Racket Users]

I have just published Issue 4 at

http://racket-news.com/2019/03/racket-news-issue-4.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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Season of docs participation

['Paulo Matos' via Racket Users]

I have been recently reading a lot of the guide and reference manuals
and they are great but not perfect (yet!).

Today I found about Google Season of Docs. What do people think about
Racket getting involved as a mentoring organization?
https://developers.google.com/season-of-docs/docs/get-started/

Kind regards,
-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] How to fix typos in documentation?

['Paulo Matos' via Racket Users]

On 07/03/2019 13:40, Marc Kaufmann wrote:
> Thanks Paulo, this is way better than the workflow I used the only other
> time I made a PR. The only thing I had to do was choose a branch to
> commit to: I chose 'master', mostly because I have no clue what else I
> would have chosen. What is the default to contribute to?
> 
> It was in scribblings by the way.
> 

OK, I found you.
https://github.com/MarcKaufmann/racket/tree/patch-1

As you can see, github created the patch-1 branch correctly and your fix
is there. You should see now a button in green saying 'Create New Pull
Request'.

Then it should show something like:

racket/racket master <- MarcKaufmann/racket patch-1

on top. Press create pull request and it will create a pull request in
racket/racket for master, based on your patch-1 branch changes.

I would then expect to see a PR from you here:
https://github.com/racket/racket/pulls

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] How to fix typos in documentation?

['Paulo Matos' via Racket Users]

On 07/03/2019 13:40, Marc Kaufmann wrote:
> Thanks Paulo, this is way better than the workflow I used the only other
> time I made a PR. The only thing I had to do was choose a branch to
> commit to: I chose 'master', mostly because I have no clue what else I
> would have chosen. What is the default to contribute to?
> 

In general you should not need to choose a branch to commit to because
github will automatically name it patch-N. Then you create a PR to merge
to master.

If really have to choose a branch to commit your change to in your fork,
select a new branch. I name them - so it could be
mkaufmann-scribblings-typo-fix. Then when you select the branch to merge
to, yes, it's master.

> It was in scribblings by the way.
> 

You mean scribblings in the racket repo?
I am asking because I can't see a PR there from you.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] How to fix typos in documentation?

['Paulo Matos' via Racket Users]

On 07/03/2019 11:55, Marc Kaufmann wrote:
> Hi,
> 
> I just came across a typo in the documentation and was about to move on
> simply because I couldn't be bothered to figure out how/where to change
> it. I couldn't find the docs in the github repo (I searched for doc, and
> looked under racket-lang-org without success).
> 
> Also, is there a guide on best practice for pull requests or
> contributions, including a "Fork this, do that, push like that, etc"? I
> have no idea, usually just fork the whole thing, but don't know how to
> keep it up-to-date. Pointers to Racket-agnostic resources very welcome.
> Thanks,
> Marc
> 
> PS: I am purposefully not saying where the typo is so that I will have
> to go and fix it, rather than have someone else fix it.
> 

Where the documentation is, depends on where the typo is. Is it in the
Guide, Reference, somewhere else?

Go to https://github.com/racket/racket
then search for the typo in the github search box and select 'in this
repository'.

Found it, great? No? Maybe the docs are somewhere else. Does it belong
to one of the libraries in pkgs.racket-lang.org? To scribble?

Once you found it, the easiest thing for a typo is to find the file in
github, then edit straight in github. It will automatically fork the
project. Then you can edit the file, fixing the typo and commit. Open PR
straight after that. Someone will come and merge the PR. :) If you need
step-by-step help feel free to pvt me in Slack.

Enjoy the ultimate pleasure of committing to the racket repo, go get
that chocolate bar you deserve!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 3

['Paulo Matos' via Racket Users]

I have just published Issue 3 at

http://racket-news.com/2019/03/racket-news-issue-3.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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] "table" data structure in Racket

['Paulo Matos' via Racket Users]

On 22/02/2019 04:05, travis.hinkel...@gmail.com wrote:
> After posing the question yesterday, I spent a little time poking around
> in the Github repository for Apache Arrow and came to the same
> conclusion, i.e., large project presumably facilitated by corporate backing.
> 

True, they are large projects... maybe even facilitated by corporate
backing but someone got them started and they probably got started
without corporate backing. I would say that you should do it if you are
motivated to do it for fun or if you need it. Start small, maybe create
just a very small subset of bindings that solve a specific problem.
Document it, publicize it, allow people to contribute. Maybe one day,
corporate backing will come.


Good luck!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 2

['Paulo Matos' via Racket Users]

I have just published Issue 2 at

http://racket-news.com/2019/02/racket-news-issue-2.html


I would have loved to send a text version to the mailing list but with
code and images to render I haven't found a way to do this properly yet.
I have tried scribble --text and pandoc but both had shortcomings.

For now, please refer to the web address. If you have suggestions please
let me know.

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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Fully expanded programs grammar: print-values

['Paulo Matos' via Racket Users]

On 06/02/2019 21:09, Shu-Hung You wrote:
> 
> 
> On Wed, Feb 6, 2019 at 9:42 AM 'Paulo Matos' via Racket Users
> mailto:racket-users@googlegroups.com>>
> wrote:
>>
>>
>>
>> On 06/02/2019 16:00, Shu-Hung You wrote:
>> > print-values is a normal identifier introduced by the racket/base's
>> > macro module-begin. It is a (private) function defined in
>> > racket/private/modbeg.
>> >
>> That's sort of surprising. I actually expected fully expanded programs
>> to be evaluable by the user. This obviously can't happen if it expands
>> to private functions.
>>
> 
> Actually, the fully expanded programs _can_ be evaluated by the users.
> It is possible to first expand an input program then pass the result to
> eval. The identifier has the right binding information, referencing to
> the private function in racket/private/modbeg, and that module will be
> instantiated because racket/base depends on it.
> 

Thanks for the clarification and reference. Actually after reading what
you said, it makes total sense and what I tried to do was completely
ridiculous. :)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Some concern about ChezScheme...

['Paulo Matos' via Racket Users]

Thanks for the references. That really useful. 

Interestingly according to Matt these ideas were already floating around at his 
uni as early as 98?

On 6 February 2019 18:50:21 CET, Matthias Felleisen  
wrote:
>
>
>> On Feb 6, 2019, at 12:30 PM, 'Paulo Matos' via Racket Users
> wrote:
>> 
>> I was quite surprised to read these nanopass ideas have been around
>for
>> so long.
>
>
>1. The educational idea came first: 
>
>A Nanopass framework for compiler education. • Volume 15, Issue 5 •
>September 2005 , pp. 653-667
>
>https://www.cambridge.org/core/journals/journal-of-functional-programming/article/educational-pearl-a-nanopass-framework-for-compiler-education/1E378B9B451270AF6A155FA0C21C04A3
>
>2. The experience report of applying the idea to a commercial compiler
>came about 10 years later: 
>
>A Nanopass framework for commercial compiler development. ICFP ’13 , pp
>343-350
>
>https://dl.acm.org/citation.cfm?id=2500618
><https://dl.acm.org/citation.cfm?id=2500618>
>
>— Matthias

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Some concern about ChezScheme...

['Paulo Matos' via Racket Users]

On 06/02/2019 13:42, Matt Jadud wrote:
> On Tue, Feb 5, 2019 at 8:01 AM 'Paulo Matos' via Racket Users
> mailto:racket-users@googlegroups.com>>
> wrote:
> 
> 
> Matthew mentions the move to Chez will help maintainability and I am
> sure he's right because he has been working with Racket for a long time
> but my experience comes from looking at backend files. When you look at
> them you end up being forced to look elsewhere, specifically the
> cpnanopass.ss file [3]. Well, this file is the stuff of nightmares...
> It's over 16000 (sixteen thousand!!!) lines of dense scheme code, whose
> comments are not necessarily Chez-Beginner friendly (maybe Alexis wants
> to rewrite it? [4]).
> 
> 
> Interestingly, having been in the classroom* around '98-2000  when some
> of these nanopass ideas were being developed (or, really, when I think
> they were really hitting stride in the classroom---I'm sure they were
> being developed well before), I find [3] to be exceedingly readable.
> Well, not "exceedingly": I think it would benefit from some breaking
> apart into separate modules. However, it uses the nanopass framework for
> specifying a series of well-defined languages, each of which can be
> checked/tested between pipeline stages. 
> 

I was quite surprised to read these nanopass ideas have been around for
so long. I might have heard of them about half a decade ago at the most.
I actually thought they were pretty recent... always learning...

OK, after reading your comment and skimming through the code it might be
that my problem is not being totally aware of the details of nanopass
compilation and therefore looking to the code and instead of being able
to abstract away portions of the code for different functions, just
seeing a huge blob of incomprehensible scheme with absolutely no comments.

> Some of the more gnarly code is in the register allocation... which is
> unsurprising. I do like that I can flip to the end, see the driver for
> all the passes, and each pass is a separate, match-like specification of
> a transformation from one language (datatype) to another. Ignoring the
> fact that there's support code in the file, 16KLOC suggests around 500
> lines per pass (at roughly 30 passes, it looks like); 500 lines seems to
> me to be a manageable unit of code for a single pass of a compiler that
> should, if written true-to-form, does just one thing per pass. (This is,
> I suspect, a classic "YMMV" kind of comment.)
> 

I guess a long comment describing some of this in the beginning of the
file would certainly be useful. In any case, as someone who dealt with a
lot of code and most of it development tools related I have never seen
anything like this. It would certainly be a lot clearer if each of the
passes had their own file. For example, in GCC all passes have their own
file and they are amazingly well commented. So if you open a file like
the register renaming pass
(https://github.com/gcc-mirror/gcc/blob/master/gcc/regrename.c) although
it is close to 2000 lines of C, it's pretty readable (assuming you know
how GCC IR works, of course). Also, you know this code is doing a
specific job, instead of doing 'all jobs', as in the case of the
cpnanopass file. But given Matthew's other message, I don't want this to
come across as me whining about the state of Chez but instead a call for
action to improve the situation. :)

> I can't say that I'm about to step in and join the compiler team (save
> us all from the thought!). I do think that it's nice to see the idea a
> nanopass compiler 1) in production and 2) having the maturity to become
> part of the production back-end of Racket. If [1] is where some/much of
> Racket's backend currently lives, I am ecstatic that the backend will be
> more Scheme (Chez? Racket?) than C/C++.
> 
> Cheers,
> Matt
> 
> [1] 
> https://github.com/racket/racket/blob/master/racket/src/racket/src/compile.c
> 

Scheme code is usually denser than C, therefore I am certainly less
scared by 2200 lines of C than I am by 16000 lines of scheme.

> * As an aside, one of the few times I remember Kent Dybvig making a
> "joke" in class was when he introduced the pass "remove complex
> operands." It was called "remove-complex-opera*." At Indiana, where
> Opera is a Thing, I think it was particularly funny as an inside joke of
> sorts. He devolved for a moment into what I can only describe as
> giggles---but, it was subtle just the same. It brings me a certain
> amount of joy to see "np-remove-complex-opera*" in [3].
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> To un

Re: [racket-users] Some concern about ChezScheme...

['Paulo Matos' via Racket Users]

On 05/02/2019 22:44, Neil Van Dyke wrote:
> BTW, sometime around when the move to Chez settles, it would be good if
> many people were somewhat familiar with current Racket internals. 

That would be absolutely great. I think if there is a small team of
contributors alongside Matthew improving Chez in order to get Racket
running on more archs and faster, it would definitely help further the
Racket cause.

This comment will get me started on writing down somewhere what I know
(and don't know) about the Racket / Chez internals and do some further
research.

> P.S., Yay, RISC-V! :)
> 

Happy to get some help on the port. :)

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Some concern about ChezScheme...

['Paulo Matos' via Racket Users]

On 05/02/2019 19:05, Matthew Flatt wrote:
> Hi Paulo,
> 
> Not to discourage other answers to your call for opinions, but here's
> mine.
> 
> Granting your point about the structure of the code in Chez Scheme,
> everything is relative. I still think Chez Scheme is a better starting
> point than the existing Racket implementation as code to reorganize,
> document, and improve. Adding a comment or two in the source is likely
> a part of that process. :) We're not at a point where it makes sense to
> recommend big changes to the organization of the Chez Scheme source,
> but that could happen.

Hearing you say this is a great relieve. It certainly shows that you
have thought that part of growing and improving Racket is improving Chez
itself. Therefore part of contributing to Racket might be contributing
to Chez itself.

> 
> I think you're mistaken about Andy and Kent's position on Chez Scheme.
> They will certainly not distance themselves from the project any more
> than I could conceivably distance myself from Racket. But they have
> priorities besides improving something that is probably just about
> perfect for their purposes.
> 

Sure, I completely understand your point. I am not bashing on Andy and
Kent. My position is that as a user Racket has a lot more community
support than Chez. Also, part (if not all) of your daily work seems to
be on Racket. Chez seems to be part of Andy's and Kent's past in the
sense that it doesn't feel like they are actively engaged with it any
longer. Again, this is no bashing of their positions, simply my feeling
as a user of both Racket and Chez. People have different paths and they
are in their own right to pursue other interests.

> We're under no illusion that moving to Chez Scheme will change much
> about who contributes to the core Racket implementation. Based on past
> experience (e.g, moving `racket/gui` from C++ to Racket), the
> contributor rolls will grow, but not radically. I'm delighted that you
> have been willing try a RISC-V port, and even the attempt is a kind of
> success and will help things improve things through feedback like this.
> 

I find the direction that Racket is taking extremely exciting and the
your viewpoint to where you see this going a breath of fresh air.

> Personally, while my contributions to Chez Scheme so far have been
> modest, I have already factored into my costs the worst-case scenario
> of fully maintaining Chez Scheme as used by Racket. Even if that
> happens, it still looks like a good deal in the long run.
> 

Thanks. I guess it all makes sense.

> Matthew
> 
> At Tue, 5 Feb 2019 14:01:07 +0100, "'Paulo Matos' via Racket Users" wrote:
>> Hi all,
>>
>> Now that I got your attention... :)
>> Although the title is not purely click-bait, it is motivated by personal
>> requirements.
>>
>> Most of us are happy with the move to Chez (actually haven't heard
>> anyone opposing it), but I would like to point to something I have felt
>> over the past year and to understand if this is just my feeling or not
>> from others (maybe Matthew) who have had any experience working with Chez.
>>
>> I have been, for over a year on and off, trying to port Chez to RISC-V.
>> My problem here is really understanding the Chez arquitecture, rather
>> than the RISC-V one with which I have been working for a few years now
>> as a consultant.
>>
>> The whole point of the work was not to get Chez on RISC-V per se but to
>> get Racket on RISC-V. My initial email to the Chez ML was replied to by
>> Andy Keep. He replied in great detail on how to create a Chez backend -
>> I have cleaned up his reply and have been slowly adding to it [1].
>>
>> That was a great start but from there things started to fall apart.
>> Further emails to my questions were generally not replied to (of the 4
>> messages sent, 1 was replied to) [2].
>>
>> Then there is some backend rot... I noticed for example, that there was
>> no Makefile for a threaded version of arm32 although the backend file is
>> there meaning it should be supported. It seems that it's just that
>> nobody every tried to build it. Then software floating point is an
>> option in a backend config file but if you enable it, bootstrapping
>> doesn't work because the compiler really expects you to have some
>> floating point registers.
>>
>> Matthew mentions the move to Chez will help maintainability and I am
>> sure he's right because he has been working with Racket for a long time
>> but my experience comes from looking at backend files. When you look at
>> them you end up being forced to look elsewhere, s

Re: [racket-users] Fully expanded programs grammar: print-values

['Paulo Matos' via Racket Users]

On 06/02/2019 16:00, Shu-Hung You wrote:
> print-values is a normal identifier introduced by the racket/base's
> macro module-begin. It is a (private) function defined in
> racket/private/modbeg.
> 
That's sort of surprising. I actually expected fully expanded programs
to be evaluable by the user. This obviously can't happen if it expands
to private functions.

Is there a specific reason for this or just happened and nobody every cared?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Fully expanded programs grammar: print-values

['Paulo Matos' via Racket Users]

Hi,

The docs[1] give a grammar for fully expanded programs.
I found it amazingly concise so I decided to give it a try and expanded
the following:

```
#lang racket

42
```

This expands to (nicely formatted):

#

That looks good to me. However, in the documented grammar there's no
reference to print-values. I assume print-values is an `id` in the
grammar, but I cannot find a reference to `print-values` in the docs
either. Is this an omission?

[1]
https://docs.racket-lang.org/reference/syntax-model.html?#(part._fully-expanded)
-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Some concern about ChezScheme...

['Paulo Matos' via Racket Users]

Hi all,

Now that I got your attention... :)
Although the title is not purely click-bait, it is motivated by personal
requirements.

Most of us are happy with the move to Chez (actually haven't heard
anyone opposing it), but I would like to point to something I have felt
over the past year and to understand if this is just my feeling or not
from others (maybe Matthew) who have had any experience working with Chez.

I have been, for over a year on and off, trying to port Chez to RISC-V.
My problem here is really understanding the Chez arquitecture, rather
than the RISC-V one with which I have been working for a few years now
as a consultant.

The whole point of the work was not to get Chez on RISC-V per se but to
get Racket on RISC-V. My initial email to the Chez ML was replied to by
Andy Keep. He replied in great detail on how to create a Chez backend -
I have cleaned up his reply and have been slowly adding to it [1].

That was a great start but from there things started to fall apart.
Further emails to my questions were generally not replied to (of the 4
messages sent, 1 was replied to) [2].

Then there is some backend rot... I noticed for example, that there was
no Makefile for a threaded version of arm32 although the backend file is
there meaning it should be supported. It seems that it's just that
nobody every tried to build it. Then software floating point is an
option in a backend config file but if you enable it, bootstrapping
doesn't work because the compiler really expects you to have some
floating point registers.

Matthew mentions the move to Chez will help maintainability and I am
sure he's right because he has been working with Racket for a long time
but my experience comes from looking at backend files. When you look at
them you end up being forced to look elsewhere, specifically the
cpnanopass.ss file [3]. Well, this file is the stuff of nightmares...
It's over 16000 (sixteen thousand!!!) lines of dense scheme code, whose
comments are not necessarily Chez-Beginner friendly (maybe Alexis wants
to rewrite it? [4]).

So I am a bit concerned about this. I somehow get the feeling that
what's going to happen is that Chez is going to slowly degenerate to a
Racket sub-project, and nobody is going to really use Chez directly.
Therefore this means Matthew et al. will end up maintaining it along
with Racket itself. As far as I understand it, both A. Keep and R.
Dybvig are both at Cisco and Chez is a side-project from which they are
slowly distancing themselves. Chez becoming a sub-project of Racket
might seem far-fetched until you noticed Matthew is already the number 4
contributor of Chez since it was open-sourced [5].

The only question I have is really, what do other people feel about
this. Am I making any sense? Have I missed some hidden Chez community
that's working day and night into improving it? Or is Chez current sole
purpose of existence to support Racket?

[1] https://github.com/LinkiTools/ChezScheme-RISCV/blob/wip-riscv/PORTING.md
[2]
https://groups.google.com/forum/#!searchin/chez-scheme/Paulo$20Matos%7Csort:date
[3] https://github.com/cisco/ChezScheme/blob/master/s/cpnanopass.ss
[4] https://twitter.com/lexi_lambda/status/1092539293791330305
[5] https://github.com/cisco/ChezScheme/graphs/contributors

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket News - Issue 1

['Paulo Matos' via Racket Users]

On 01/02/2019 14:28, Greg Trzeciak wrote:
> Nicely done!
> 
> Is my understanding correct and this will also be a newsletter (as in
> subscribe and receive by email)?
>

It's not pretty... yet, but I have added the newsletter subscription option.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket News - Issue 1

['Paulo Matos' via Racket Users]

On 01/02/2019 15:23, Sam Tobin-Hochstadt wrote:
> This looks very cool. 

Thanks.

> Long long ago, I wrote something similar for
> other free software projects, and my one piece of advice is not to
> commit to writing really frequently. Every month, or even every few
> months, is great.
> 

Wise words! :) Yes, initially I planned every second week but it might
end up being on the first of each month. We shall see... I certainly
think there are enough things going on to do it on a monthly basis.

A lot of the stuff can be automated and if I have people contributing
and I can automate that integration as well so that I act as a
hole-filler and editor, even better.

Thanks.

> Sam
> 
> On Fri, Feb 1, 2019 at 6:40 AM 'Paulo Matos' via Racket Users
>  wrote:
>>
>> A quick preamble: I have been thinking about creating something along
>> these lines for awhile but only just got my hands dirty. Here's the
>> first issue. Web page is a work in progress at racket-news.com.
>>
>> I was thinking about publishing the text version (from raco scribble
>> --text) in here for each issue (I just noticed that the text export
>> doesn't export links so feel free to refer to the online version). If
>> you feel this shouldn't be posted to the mailing list, please let me know.
>>
>> Also, this effort is only worth it IF the community thinks there's
>> something to gain from this. Please feel free to comment, suggest or
>> tell me it's a waste of time. I am not going to widely publicize this
>> until I nail the webpage and people think it's worth it.
>>
>> So, here we go...
>>
>> Web version: http://racket-news.com/2019/02/racket-news-issue-1.html
>>
>> Title: Racket News - Issue 1 Date: 2019-02-01T08:00:00
>>
>> Welcome to the first issue of Racket News. I am hoping this will be of
>> interest to everyone in the Racket community so if there’s something you
>> really dislike, or something you want to see added to the newsletter
>> please send me an email or submit a PR.
>>
>> Also, I think at the moment a bi-weekly or monthly newsletter is
>> something reasonable. By this I mean that I should have time to put it
>> together at this regular interval with enough interesting content. If
>> things happen differently when I will change how often it comes out.
>>
>> In this issue we have the Racket 7.2 release, update on RacketCS, and a
>> few extra goodies that came out recently.
>>
>> What’s New?
>>
>> Racket 7.2 released
>>
>> Racket 7.2 has been released! Vincent St-Amour has announced the release
>> on January 30, 2019. The listed improvements include collapsible
>> contracts, QuickScript integration, and various improvements to racklog,
>> among others.
>>
>> RacketCS
>>
>> This week we saw an update on Racket-On-Chez by Matthew Flatt. For those
>> who missed the boat, the whole point of this transition is
>> maintainability. Hopefully with a more maintainable system, things will
>> get easier for those currently contributing to Racket but also newcomers
>> to Racket might more easily contribute PRs to improve the system in
>> general.
>>
>> The summary on the report is that Racket on Chez is considered mostly
>> done with all functionility in place and most tests passing. There are a
>> few things where RacketCS won’t behave the same as current Racket:
>>
>> * no single-precision or extended-precision flonums;
>>
>> * some differences in the FFI;
>>
>> * no support for C API;
>>
>> There are a few other incompatible points but for more detail please
>> refer to the original post. RacketCS will never be fully compatible with
>> Racket, therefore he whole point is to get people to move their stuff to
>> RacketCS and get rid of the current Racket variant.
>>
>> However, there are some performance issues that might block a few
>> applications from transitioning right away. Alex Harsanyi, developer of
>> ActivityLog2 mentioned in the mailing list that in his case RacketCS is
>> significantly slower than Racket 7.1. Matthew promised in a reply no
>> switch will happen until performance is good enough. Alex elaborated his
>> point further by providing function timings of ActivityLog2 in this
>> gist.
>>
>> Wiki
>>
>> Stephen de Gabrielle has been seriously active on the wiki side of
>> things. It has some really interesting content and you should check it
>> out.
>>
>> Racket Github Topic
>>
>> Stephen de Gabrielle has beautified the GitHub topic for Racket through

Re: [racket-users] Re: Racket News - Issue 1

['Paulo Matos' via Racket Users]

On 01/02/2019 15:00, Greg Trzeciak wrote:
> I personally think PR maybe too much (unless someone creates entire news
> - also good as an option). Especially if you only wanted to post a link
> to a new blog post.
> 
> But issues may work - you could simply have a button with following url:
> https://github.com/racket-news/racket-news.github.io-src/issues/new?title=[submission]&body=foo
> 

Great idea. I will try to add something like that. Thanks.

> That would be the simplest solution requiring least effort.
> 
> 
> 
> On Friday, February 1, 2019 at 2:36:48 PM UTC+1, Paulo Matos wrote:
> 
> 
> 
> On 01/02/2019 14:28, Greg Trzeciak wrote:
> > Nicely done!
> >
> > Is my understanding correct and this will also be a newsletter (as in
> > subscribe and receive by email)?
> >
> 
> Yes, still something I have to sort out. Lets say this is a pilot
> /episode/ to understand the community's reception.
> 
> On that, is mailchimp the way to go these days or there's something
> else
> out there I should be looking at?
> 
> > An idea - include a form like "Submit a news" where readers can
> quickly
> > share their finding, e.g. blog posts, new package (their own or
> someone
> > else's they like) - this could send an email, create a gist or a
> github
> > issue.
> >
> 
> That's interesting. Initially I thought people could do that by
> submitting a PR or if they don't want to create a PR, they could submit
> an issue. Do you think forwarding people to the submit issue form would
> put people away from contributing?
> 
> -- 
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket News - Issue 1

['Paulo Matos' via Racket Users]

On 01/02/2019 14:28, Greg Trzeciak wrote:
> Nicely done!
> 
> Is my understanding correct and this will also be a newsletter (as in
> subscribe and receive by email)?
> 

Yes, still something I have to sort out. Lets say this is a pilot
/episode/ to understand the community's reception.

On that, is mailchimp the way to go these days or there's something else
out there I should be looking at?

> An idea - include a form like "Submit a news" where readers can quickly
> share their finding, e.g. blog posts, new package (their own or someone
> else's they like) - this could send an email, create a gist or a github
> issue.
> 

That's interesting. Initially I thought people could do that by
submitting a PR or if they don't want to create a PR, they could submit
an issue. Do you think forwarding people to the submit issue form would
put people away from contributing?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Racket News - Issue 1

['Paulo Matos' via Racket Users]

A quick preamble: I have been thinking about creating something along
these lines for awhile but only just got my hands dirty. Here's the
first issue. Web page is a work in progress at racket-news.com.

I was thinking about publishing the text version (from raco scribble
--text) in here for each issue (I just noticed that the text export
doesn't export links so feel free to refer to the online version). If
you feel this shouldn't be posted to the mailing list, please let me know.

Also, this effort is only worth it IF the community thinks there's
something to gain from this. Please feel free to comment, suggest or
tell me it's a waste of time. I am not going to widely publicize this
until I nail the webpage and people think it's worth it.

So, here we go...

Web version: http://racket-news.com/2019/02/racket-news-issue-1.html

Title: Racket News - Issue 1 Date: 2019-02-01T08:00:00

Welcome to the first issue of Racket News. I am hoping this will be of
interest to everyone in the Racket community so if there’s something you
really dislike, or something you want to see added to the newsletter
please send me an email or submit a PR.

Also, I think at the moment a bi-weekly or monthly newsletter is
something reasonable. By this I mean that I should have time to put it
together at this regular interval with enough interesting content. If
things happen differently when I will change how often it comes out.

In this issue we have the Racket 7.2 release, update on RacketCS, and a
few extra goodies that came out recently.

What’s New?

Racket 7.2 released

Racket 7.2 has been released! Vincent St-Amour has announced the release
on January 30, 2019. The listed improvements include collapsible
contracts, QuickScript integration, and various improvements to racklog,
among others.

RacketCS

This week we saw an update on Racket-On-Chez by Matthew Flatt. For those
who missed the boat, the whole point of this transition is
maintainability. Hopefully with a more maintainable system, things will
get easier for those currently contributing to Racket but also newcomers
to Racket might more easily contribute PRs to improve the system in
general.

The summary on the report is that Racket on Chez is considered mostly
done with all functionility in place and most tests passing. There are a
few things where RacketCS won’t behave the same as current Racket:

* no single-precision or extended-precision flonums;

* some differences in the FFI;

* no support for C API;

There are a few other incompatible points but for more detail please
refer to the original post. RacketCS will never be fully compatible with
Racket, therefore he whole point is to get people to move their stuff to
RacketCS and get rid of the current Racket variant.

However, there are some performance issues that might block a few
applications from transitioning right away. Alex Harsanyi, developer of
ActivityLog2 mentioned in the mailing list that in his case RacketCS is
significantly slower than Racket 7.1. Matthew promised in a reply no
switch will happen until performance is good enough. Alex elaborated his
point further by providing function timings of ActivityLog2 in this
gist.

Wiki

Stephen de Gabrielle has been seriously active on the wiki side of
things. It has some really interesting content and you should check it
out.

Racket Github Topic

Stephen de Gabrielle has beautified the GitHub topic for Racket through
a PR.

Upcoming Meetups

* FOSDEM2019 - On Feb. 2,3 in Brussels, Belgium FOSDEM will take place.
  There is a minimalistic languages interest group where Racket will be
  mentioned a few times

* BOB2019 - Right before Racketfest, also in Berlin, Germany. Directly
  related to Racket, you a talk by our own Shriram Krishnamurthi and a
  tutorial by Jesse Alama on WebDev

* RacketFest - Jesse Alama is organizing the first European Racket
  Meeting. It will take place in Berlin, Germany on March 23, 2019. Make
  sure you get your ticket before they sell out... again!

Racket around the web

Here are a few blog posts about Racket...

* Racket-on-Chez Status: January 2019

* Can we abstract control flow?

Project of the Week

We all know how there are so many hidden gems in the Racket world. I
hope, in this section, to make these gems shine, one at a time.

So for this week I chose to mention: Rash by William Hatch.

>From its webpage:

Rash is a shell language, library, and REPL for Racket.
 
Use as a repl that is as convenient for pipelining programs as Bash is,
but has all the power of Racket. Use as a scripting language with #lang
rash. Embed in normal Racket files with (require rash), and mix freely
with any other Racket language or library.
 
Rash is in active development, but it is largely stable (and the parts
that aren't are marked as such). I use it as my default interactive
shell on my laptop. It currently lacks the interactive polish of Zsh or
Fish, but it is so much better as a language. Every script I've ported
from a bourne-related shell 

Re: [racket-users] Re: updated Racket-on-Chez status

['Paulo Matos' via Racket Users]

On 30/01/2019 02:32, Alex Harsanyi wrote:
> I know the report explains the various cases where Racket CS is slower than
> Racket 7.1, but I would like to mention that these cases are very
> significant,
> at least in my case -- I mention this because the report recommends making
> Racket CS the default, which I am very concerned about:
> 
>> To maximize the maintenance benefits of Racket CS, it’s better to make it
>> the default Racket variant sooner rather than later
> 
> To understand the performance impact, below are the numbers for my
> application.  I mentioned this before [1] and I added some new timings
> to the
> Google Sheets Document [2].
> 
> * the total Travis build time (build + tests) is ~13 minutes using
> Racket 7.1
>   and it is 20 minutes, a 7 minute increase.
> 
> * the build time itself grows from 3.75 minutes in Racket 7.1 to 8.5 minutes
>   in Racket CS, a 5 minute increase.  My Edit-Compile-Run cycle is already
>   slow with Racket 7.1.
> 
> * even ignoring compile and load time, code sections which run after Racket
>   initialization and library loading indicate that the running time is
>   increased by 33% -- given that current execution time is several
> seconds to
>   several minutes in Racket 7.1, a 33% increase is very visible to the end
>   user.
> 
> As it stands now, the cases where RacketCS is slow have a significant impact
> on my application.  Do others see the same performance degradation in their
> applications?
> 

I am about to run some thorough tests and benchmarks on my app. Will
report back on this. Thanks for raising these issues.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Beginning of the end for googlegroups?

['Paulo Matos' via Racket Users]

Apologies for message unrelated to racket, but it might affect us.

Just read this:
https://groups.google.com/a/isocpp.org/forum/m/#!msg/sg14/FZEWCOSyFlk/MFUXyq1YDAAJ

Not sure of the size of the mailing list but I wonder if this is the beginning 
of the end and we should have instead a plan B.

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] hackernews

['Paulo Matos' via Racket Users]

On 31/12/2018 19:09, Stephen De Gabrielle wrote:
> 
> On a related tack, I've started writing a '7 reasons why your next
> project should be in built on Racket' let me know if you would be
> interested in providing feedback.  (My inspiration was a similar post
> for Python)
> 

How's this going? Let me know if I can provide any feedback.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Escaping strings for the shell

['Paulo Matos' via Racket Users]

I am surprised nobody mentioned Rash. I have been using it for all my
shell scripting needs and it's awesome.

https://pkgs.racket-lang.org/package/rash

On 29/12/2018 05:09, David Storrs wrote:
> I am using 'system' to offload some work onto wget and other
> applications in a few one-off scripts.  Is there an easy way to escape
> a string so it's suitable for usage in the shell?  Things like
> backwhacking all the quotes and relevant spaces and such.
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: FYI Racket & DrRacket tagged projects on GitHub

['Paulo Matos' via Racket Users]

On 11/01/2019 17:23, Greg Trzeciak wrote:
> What would be really neat if https://pkgs.racket-lang.org/ would include
> date-added to all the packages. This way one could create automatic list
> of newly added packages and let's say distribute it in the newsletter

Which newsletter are you referring to here?

I had been thinking of getting a Racket Newsletter out of the ground but
haven't come around to it yet. Have you discussed previously something
in this direction? If so, I would like to help.

If not, maybe we can open a discussion around this theme. Do people find
it interesting/useful? One of the things that made me think about this
was that regularly I find little library gems in the Racket world that I
wouldn't find otherwise so maybe a newsletter that highlights one of
these one every two weeks or so would be great. Another thing it would
be useful for is to highlight recent Racket developments, new libraries,
libraries requiring a maintainer, etc.

> 
> 
> On Friday, January 11, 2019 at 3:18:40 PM UTC+1, spdegabrielle wrote:
> 
> FYI 
> 
> Racket & DrRacket tagged projects on GitHub can be found at 
> 
> https://github.com/topics/racket  
> 
> https://github.com/topics/drracket  
> 
> A great way to discover Racket activity that you wouldn’t otherwise see.
> 
> Kind regards
> 
> Stephen
> 
> -- 
> 
> 
> -- 
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] go cheney yourself

['Paulo Matos' via Racket Users]

And here I was hoping for the piece to somehow have a Rackety end...

On 08/01/2019 22:09, Tim Hanson wrote:
> great piece by Michelle Goldberg, imho:
> 
> https://www.nytimes.com/2019/01/07/opinion/rashida-tlaib-profanity.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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Experiences with Racket on RISC-V?

['Paulo Matos' via Racket Users]

On 08/01/2019 18:01, Alexander Shopov wrote:
> Won't emulators like QEMU do good enough job for the initial ironing out
> of problems like the mentioned RISC-V backend for Chez and libffi for
> Racket?

Yes, they will. For sure. I own a Hifive Unleashed but use it mostly for
nightly testing. For the porting work I use qemu.

Give it a try... For a Fedora28 on a riscv64 system, install latest qemu
and then:

wget https://fedorapeople.org/groups/risc-v/disk-images/stage4-disk.img.xz
wget https://fedorapeople.org/groups/risc-v/disk-images/bbl
wget https://fedorapeople.org/groups/risc-v/disk-images/vmlinux
xz -d stage4-disk.img.xz

qemu-system-riscv64 \
-nographic \
-machine virt \
-smp 4 \
-m 2G \
-kernel bbl \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-append "console=ttyS0 ro root=/dev/vda" \
-device virtio-blk-device,drive=hd0 \
-drive file=stage4-disk.img,format=raw,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,hostfwd=tcp::1-:22

Enjoy!

> 
> На вт, 8.01.2019 г. в 16:01 ч. Hendrik Boom  > написа:
> 
> On Mon, Jan 07, 2019 at 06:38:07PM -0300, Andrei Formiga wrote:
> > Sorry to slightly hijack the thread here, but what would be a good
> RISC-V
> > dev board to experiment with Racket on it?
> 
> Not available at all yet, but there's the Libre-RISC-V development,
> being discussed on a mailing list:
> 
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
> 
> The aim seems to be to make a fully free (as in freedom, not beer) chip
> design for a real-life RISC-V processor, and get it manufactured.
> 
> Ideally, not proprietary anything.
> 
> We will see.
> 
> -- hendrik
> 
> -- 
> 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
> .
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Experiences with Racket on RISC-V?

['Paulo Matos' via Racket Users]

On 08/01/2019 13:34, Bruce O'Neel wrote:
> 
> Hi,
> 
> The HiFive1 is a 32 bit integer only machine, sadly.  I guess I must
> admit being a bit old to re-do software floating point.  I still have
> nightmares of ARM and then later 68000 systems.
> 
> Your right about the HiFive Unleashed would be a good system, but,
> expensive.
> 

For sure. I talked to them in the last RISC-V Workshop and they told me
the followup will be considerable cheaper but also produced in larger
numbers.

I have seen also a considerable surge in customers wishing to work with
RISC-V, therefore RISC-V ports pay a lot of my bills at the moment.
Unfortunately none to port Racket to RISC-V, yet. :) This means that I
would hope that many more devices will come in the short term into
market based on RISC-V.

> 
> 
> 
> /07 January 2019 23:06 Neil Van Dyke  wrote:/
> 
> These are pretty new, and the prices are higher than other ISAs with
> economies-of-scale and mostly long-amortized development costs (and
> there's perhaps no loss-leaders or dumping for market share or lock-in,
> like we sometimes see in industry).
> 
> The HiFive1 is more like a $60 Arduino or maybe RasPi:
> https://www.sifive.com/boards/hifive1
> 
> The HiFive Unleashed, when combined with their Expansion Board,
> could be
> used to make a workstation, but is pretty new, and costs thousands of
> dollars:
> https://www.sifive.com/boards/hifive-unleashed
> 
> I've seen "RISC-V" USB dongle-like boards, but the ones I've seen are
> just little FPGA experimenter boards burnt with RISC-V logic.
> 
> That's what I found, last time I looked.  Paulo or others might know
> other boards.
> 
> There's also always emulators, and RISC-V logic you program yourself on
> bigger general-purpose FPGA boards.  (Programming FPGA yourself means
> you're one small enhancement away from being able to call yourself a
> CPU
> designer.  :)  If you do FPGA, it would help to try to use an open
> toolchain, but I think the options for that are still relatively early
> and improving.  (Last I looked, the open toolchains would let you use
> only a few small FPGAs, but I saw something the other day that suggests
> the environment is improving, so look for the latest info/news,
> whenever
> you start.)
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.
> 
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Giving scribble a shot

['Paulo Matos' via Racket Users]

Hi,

I am working on some scribble and I am having trouble understanding
what's going on with a few cases. Here's a simple test:

test.scrbl:
---
#lang scribble/book

@require[scribble/example
 scribble/manual
 scribble-abbrevs
 scriblib/footnote]

@title{Scribble to odt}
@author[(author+email "Tester" "t...@tester.foo")]

@table-of-contents{}

@section{Test section}

Verbatim:
@verbatim{|
$ racket
Welcome to Racket v7.1.
>
|}


Next comes a code block:
@#reader scribble/comment-reader
@examples[#:label #false
1 ;; an integer
1/2   ;; a rational number
]


What about a racket value reference @racket{#false}?


Do margin notes work?@margin-note{In the margin?}


Hey, we need a footnote@note{As a foot note...} test.
---

There are a few issues when compiling to pdf using pdflatex:
1. @#reader scribble/comment-reader doesn't help comments to be rendered
in this case. Is it because it only works with a racketblock? How can I
get comments in examples to be displayed
2. The line after the verbatim environment is indented. How can I stop
this from happening? Same thing with the line after the examples.
3. I find it rather awkward #false is shown in green surrounded by
double quotes. Why does this happen? Can I remove them?

Thanks,
-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Experiences with Racket on RISC-V?

['Paulo Matos' via Racket Users]

On 07/01/2019 22:38, Andrei Formiga wrote:
> Sorry to slightly hijack the thread here, but what would be a good
> RISC-V dev board to experiment with Racket on it? 

I have the HiFive Unleashed which I recommend:
https://www.sifive.com/boards/hifive-unleashed

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Experiences with Racket on RISC-V?

['Paulo Matos' via Racket Users]

On 05/01/2019 00:55, David Thrane Christiansen wrote:
> Hi Paulo et al,
> 
> Thanks for the info! It sounds like Racket or Racket-on-Chez is a bit
> of a risky bet for a RISC-V project with a quick turnaround, but I'll
> keep my eyes peeled for the future.
> 
> Thanks again!

Hi,

I don't really understand the risky bet comment. What's a risky bet? To
use Racket on RISC-V for production? Well, yes, it doesn't run yet.
RacketCS doesn't compile because the RISC-V backend for Chez is not
finished, Racket doesn't compile because libffi, at least, hasn't been
ported to RISC-V.

However, it's not a risky bet to support the porting of Racket for
RISC-V because both are really mature projects which are here to stay
and lots can be done on RISC-V since the base ISA's and some extension
specs have been frozen.

Kind regards,

Paulo Matos

> David
> 
> Den tor. 3. jan. 2019 kl. 04.29 skrev Paulo Matos :
>>
>> Hi,
>>
>> Thanks for CCing me on this. I have been involved in the RISC-V
>> community for awhile and I am interested in getting Racket on RISC-V. I
>> have started porting Chez to RISC-V as a side project as currently I
>> have no clients paying me to do so. Therefore, as you would expect, it's
>> going slow. The good news is that the little porting I did is online[1]
>> and I am accepting PRs. :)
>>
>> If I can help with anything else please let me know. Things are slow on
>> my side until the 7th as I am on holiday but I will read all the racket
>> related messages by then and reply if I see I have anything to add.
>>
>> Paulo Matos
>>
>> [1]  https://github.com/LinkiTools/ChezScheme-RISCV/
>>
>> On 03/01/2019 02:59, Neil Van Dyke wrote:
>>> (CC-ing Paulo Matos.)
>>>
>>> I expect RISC-V to be a top architecture platform for systems
>>> researchers doing open science, including some language/compilers
>>> researchers.  And for CS students in systems classes.
>>>
>>> RISC-V is also looking to be important for a more open hardware platform
>>> for some industry, and for nations and user bases who care about that.
>>>
>>> This is a good, accessible overview of RISC-V, by Krste Asanovic:
>>> https://www.youtube.com/watch?v=QTYiH1Y5UV0
>>>
>>> I'd love to see Racket started towards RISC-V, by being tested working
>>> well on the current RISC-V boards (and on a good open source emulator).
>>>
>>>
>>> BTW, a second-priority, open-ish target architecture that might be also
>>> be on the horizon for Racket is Power9.  Were Racket to also go there, I
>>> think it would make sense for IBM / Red Hat to fund that, somehow.  (If
>>> someone wanted to do this unfunded, you could use an emulator, and ask
>>> raptorcs.com to kindly let you have remote access to a Talos II.  But
>>> IBM doesn't need charity. :)  Power9 would not be done to the exclusion
>>> of RISC-V, but be complementary.
>>>
>>> (I also still use amd64/x86, arm, and (openwrt) mips, of course.  No
>>> slights to those.)
>>>
>>>
>>> David Thrane Christiansen wrote on 1/2/19 7:38 PM:
 Hi all,

 I'm just wondering if anyone here has experience running Racket on
 Debian on RISC-V, either positive or negative. There is a Debian
 package, at least, but language implementations are often one of the
 more challenging things to make reliable on a new architecture.

 In case it matters, the GUI part is not relevant for what I'm
 interested in.

 Thanks!

 David

>>
>> --
>> Paulo Matos
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Experiences with Racket on RISC-V?

['Paulo Matos' via Racket Users]

Hi,

Thanks for CCing me on this. I have been involved in the RISC-V
community for awhile and I am interested in getting Racket on RISC-V. I
have started porting Chez to RISC-V as a side project as currently I
have no clients paying me to do so. Therefore, as you would expect, it's
going slow. The good news is that the little porting I did is online[1]
and I am accepting PRs. :)

If I can help with anything else please let me know. Things are slow on
my side until the 7th as I am on holiday but I will read all the racket
related messages by then and reply if I see I have anything to add.

Paulo Matos

[1]  https://github.com/LinkiTools/ChezScheme-RISCV/

On 03/01/2019 02:59, Neil Van Dyke wrote:
> (CC-ing Paulo Matos.)
> 
> I expect RISC-V to be a top architecture platform for systems
> researchers doing open science, including some language/compilers
> researchers.  And for CS students in systems classes.
> 
> RISC-V is also looking to be important for a more open hardware platform
> for some industry, and for nations and user bases who care about that.
> 
> This is a good, accessible overview of RISC-V, by Krste Asanovic:
> https://www.youtube.com/watch?v=QTYiH1Y5UV0
> 
> I'd love to see Racket started towards RISC-V, by being tested working
> well on the current RISC-V boards (and on a good open source emulator).
> 
> 
> BTW, a second-priority, open-ish target architecture that might be also
> be on the horizon for Racket is Power9.  Were Racket to also go there, I
> think it would make sense for IBM / Red Hat to fund that, somehow.  (If
> someone wanted to do this unfunded, you could use an emulator, and ask
> raptorcs.com to kindly let you have remote access to a Talos II.  But
> IBM doesn't need charity. :)  Power9 would not be done to the exclusion
> of RISC-V, but be complementary.
> 
> (I also still use amd64/x86, arm, and (openwrt) mips, of course.  No
> slights to those.)
> 
> 
> David Thrane Christiansen wrote on 1/2/19 7:38 PM:
>> Hi all,
>>
>> I'm just wondering if anyone here has experience running Racket on
>> Debian on RISC-V, either positive or negative. There is a Debian
>> package, at least, but language implementations are often one of the
>> more challenging things to make reliable on a new architecture.
>>
>> In case it matters, the GUI part is not relevant for what I'm
>> interested in.
>>
>> Thanks!
>>
>> David
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: The performance of ‘set’ vs. lists+‘remove-duplicates’

['Paulo Matos' via Racket Users]

 (list-ref (match impl
['set sets]
['list setls]
['hash seths])
  (car index/size))
(list-ref (match impl
['set sets]
['list setls]
['hash seths])
  (random (length index/size]
   ; function receives a set and a value
   [(add member? remove) (fn (list-ref (match impl
 ['set sets]
 ['list setls]
 ['hash seths])
   (car index/size))
 (list-ref vs-single (random (length
vs-single]))


   ; don't extract time, instead time (run ...)
   #:extract-time 'delta-time
   #:num-trials 10))

(parameterize ([plot-x-ticks no-ticks])
  (plot-pict
   #:title "small sets benchmark"
   #:width 3840
   #:height 2160
   #:x-label #f
   #:y-label "normalized time"
   (render-benchmark-alts
; default options
(list (cons 0 8) 'list)
results
; format options so we can omit the index in the size list
#:format-opts (lambda (opts)
(let ([index/size (car opts)]
  [impl (cadr opts)])
  (format "size: ~a, ~a" (cdr index/size) impl))

You might have to play with width/height of plot for your monitor and
then play with the sizes since visualizing all the sizes at once is a
pain. Also, run it twice, first with copy and to-list operations and
then the remainder - otherwise you won't be able to make out much in the
plot.

I am keen to get feedback on generating a nicer, most understandable
plot - I always wished I was able to generate the beautiful
visualizations we tend to see in the Web2.0 era but never had the
artistic eye or the inclination to learn how to do it.

More importantly though, I am keen to hear on the issues with regards to
the results. So, is set really that much worse because of the generic
contracts? Also, is there a way to speed up the copying of hash tables?

Paulo Matos

On 06/12/2018 17:08, 'Paulo Matos' via Racket Users wrote:
> 
> 
> On 06/12/2018 16:39, Vincent St-Amour wrote:
>> On Thu, 06 Dec 2018 07:05:03 -0600,
>> 'Paulo Matos' via Racket Users wrote:
>>>
>>>
>>>
>>> On 05/12/2018 11:55, Tony Garnock-Jones wrote:
>>>> I suspect it will be slow because sets are generics, and generics are
>>>> slow. 
>>>
>>> I am curious now. How slow? Why? Do you have any data backing this up?
>>> Generics are very useful, I would be very disappointed if they are
>>> indeed very slow.
>>
>> For what it's worth, I seem to recall that generics, while they do
>> introduce indirection, and not particularly costly on their own.
>>
> 
> ah... that's more reassuring. Thanks.
> 
>> Contracts for generics, though, which the set library is using, are
>> really costly.
>>
> 
> Good! That's understandable.
> 
> I am preparing a battery of benchmarks on this motivated by this thread
> which I hope to share soon.
> 
>> Vincent
>>
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: The performance of ‘set’ vs. lists+‘remove-duplicates’

['Paulo Matos' via Racket Users]

On 06/12/2018 16:39, Vincent St-Amour wrote:
> On Thu, 06 Dec 2018 07:05:03 -0600,
> 'Paulo Matos' via Racket Users wrote:
>>
>>
>>
>> On 05/12/2018 11:55, Tony Garnock-Jones wrote:
>>> I suspect it will be slow because sets are generics, and generics are
>>> slow. 
>>
>> I am curious now. How slow? Why? Do you have any data backing this up?
>> Generics are very useful, I would be very disappointed if they are
>> indeed very slow.
> 
> For what it's worth, I seem to recall that generics, while they do
> introduce indirection, and not particularly costly on their own.
> 

ah... that's more reassuring. Thanks.

> Contracts for generics, though, which the set library is using, are
> really costly.
> 

Good! That's understandable.

I am preparing a battery of benchmarks on this motivated by this thread
which I hope to share soon.

> Vincent
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: The performance of ‘set’ vs. lists+‘remove-duplicates’

['Paulo Matos' via Racket Users]

On 05/12/2018 11:55, Tony Garnock-Jones wrote:
> I suspect it will be slow because sets are generics, and generics are
> slow. 

I am curious now. How slow? Why? Do you have any data backing this up?
Generics are very useful, I would be very disappointed if they are
indeed very slow.

> For my application, it has worked well to replace set/seteq with
> hash/hasheq mapping to #t; this only works when you have total control
> over set representation as an implementation detail, of course! But for
> me it sped up my set-heavy program quite a lot.
> 
> On Tuesday, December 4, 2018 at 8:50:33 PM UTC, Leandro Facchinetti wrote:
> 
> I rewrote a codebase that was using ‘set’s to use lists that I
> ‘remove-duplicates’ whenever I ‘cons’. The result is orders of
> magnitude faster. Do you have any idea why?
> 
> -- 
> Leandro Facchinetti >
> https://www.leafac.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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places and many cores? (File descriptor limit?)

['Paulo Matos' via Racket Users]

On 05/11/2018 15:57, Matt Jadud wrote:
> Hi all,
> 
> First, thank you for the conversation around this. 
> 
> On Sun, Nov 4, 2018 at 5:30 PM George Neuner  > wrote:
> 
> 
> One .zo per distributed place is just one descriptor per process. 
> Again insignificant because you have 4K per process.
> 
> It's apparent that the code is leaking descriptors somewhere. 
> Forcing GC may mitigate the problem, but it would be better if you
> found the leak.
> 
> 
> I've lied. I am *not* using distributed places. I'm using
> *dynamic-place*, which clearly is why I'm running into limits.
> 
> Unless anyone has alternative ideas, I'm going to restructure my code to
> use distributed places on the single machine, which will, I think, give
> me multicore parallelism and eliminate the file descriptor limit I'm
> running up against. 
> 

I have developed loci which has the same interface as places but uses
processes instead of OS threads.

https://github.com/LinkiTools/racket-loci

The documentation is non-existent but if you know places, there should
be little else to do besides replacing place for locus and places for
loci. Let me know if I can help any further.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places and many cores? (File descriptor limit?)

['Paulo Matos' via Racket Users]

On 04/11/2018 22:56, Matt Jadud wrote:
> On Sun, Nov 4, 2018 at 4:30 PM 'Paulo Matos' via Racket Users
> mailto:racket-users@googlegroups.com>>
> wrote:
> 
> Curious about what your places are doing.
> How come you started so many places without seeing this:
> https://groups.google.com/d/msg/racket-users/oE72JfIKDO4/zbFI6knhAQAJ
> 
> Could you share what each of the places do?
> 
> 
> Each process is:
> 
> 0. Requesting an identifier (integer) from the queen process over a
> (distributed) place channel,


OK, you don't see what I did because you're using distributed places.
Makes sense!

Thanks,
-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places and many cores? (File descriptor limit?)

['Paulo Matos' via Racket Users]

Hi,

Curious about what your places are doing.
How come you started so many places without seeing this:
https://groups.google.com/d/msg/racket-users/oE72JfIKDO4/zbFI6knhAQAJ

Could you share what each of the places do?

Paulo Matos

On 04/11/2018 18:18, Matt Jadud wrote:
> Hi all,
> 
> I have some code that is unhappy.  I suspect I'm running into an
> OS-level resource limit.
> 
> I'm working with an Intel Phi machine running CentOS that reports 256
> cores. It is built using the Intel Xeon Phi 7210, which suggests that it
> has four, 64-core processors. I compiled Racket from source, but I don't
> think that makes a difference here.
> 
> I've parallelized some code using places, and seem to be OK when (<
> num-places 96). I've used channels (synchronous and asynchronous in
> places, as well as two, semaphore-protected queues) internally for the
> queen bee process. I have around N:M places-to-threads in the queen, and
> my code is not *intentionally* non-deterministic.
> 
> The worker bees process messages in-and-out on their place-channels.
> Each worker holds 2 connections to two databases. (I'm wondering if
> compiled .zos of libraries are counting towards the number of open files
> each place holds on to...)
> 
> When I run with 64 places, things are OK. When I run with 96 places,
> things seem OK (code runs to completion). When I run with 128 places,
> things are not OK. 
> 
> My current best guess is that I'm running into a max number of allowed
> open file descriptors. I don't have root on the system, so I can't
> easily change this, but I thought I'd throw this to the list, and see if
> anyone has any further thoughts as to what I might look for. Given that
> it takes a while to spin up all 128 of the places, I suspect things look
> like they're running fine... until enough of the places spin up, I run
> out of descriptors (I suspect), and then all kinds of badness begins.
> 
> [mjadud@phi data]$ ulimit -Ha
> 
> core file size          (blocks, -c) unlimited
> 
> data seg size           (kbytes, -d) unlimited
> 
> scheduling priority             (-e) 0
> 
> file size               (blocks, -f) unlimited
> 
> pending signals                 (-i) 385394
> 
> max locked memory       (kbytes, -l) 64
> 
> max memory size         (kbytes, -m) unlimited
> 
> open files                      (-n) 4096
> 
> pipe size            (512 bytes, -p) 8
> 
> POSIX message queues     (bytes, -q) 819200
> 
> real-time priority              (-r) 0
> 
> stack size              (kbytes, -s) unlimited
> 
> cpu time               (seconds, -t) unlimited
> 
> max user processes              (-u) 385394
> 
> virtual memory          (kbytes, -v) unlimited
> 
> file locks                      (-x) unlimited
> 
> [mjadud@phi data]$ ulimit -Sn
> 
> 1024
> 
> 
> When running with 96 places:
> ...
> 
> [mjadud@phi data]$ ls -l /proc/$(pidof racket)/fd | wc -l
> 
> 873
> 
> # This is a steady state.
> 
> 
> Keeping an eye on things when running with 128 places:
> ...
> 
> [mjadud@phi data]$ ls -l /proc/$(pidof racket)/fd | wc -l
> 
> 983
> 
> [mjadud@phi data]$ ls -l /proc/$(pidof racket)/fd | wc -l
> 
> 999
> 
> 
> #  cat /proc/os-release
> 
> NAME="CentOS Linux"
> 
> VERSION="7 (Core)"
> 
> ID="centos"
> 
> ID_LIKE="rhel fedora"
> 
> VERSION_ID="7"
> 
> PRETTY_NAME="CentOS Linux 7 (Core)"
> 
> ANSI_COLOR="0;31"
> 
> CPE_NAME="cpe:/o:centos:centos:7"
> 
> HOME_URL="https://www.centos.org/";
> 
> BUG_REPORT_URL="https://bugs.centos.org/";
> 
> 
> CENTOS_MANTISBT_PROJECT="CentOS-7"
> 
> CENTOS_MANTISBT_PROJECT_VERSION="7"
> 
> REDHAT_SUPPORT_PRODUCT="centos"
> 
> REDHAT_SUPPORT_PRODUCT_VERSION="7"
> 
> 
> -- When Things Die --
> 
> open-input-file: cannot open input file
> 
>   path:
> /usr/netapp/faculty/mjadud/racket-src/racket/share/pkgs/cldr-bcp47/cldr/bcp47/data/timezone.xml
> 
>   system error: Too many open files; errno=24
> 
>   context...:
> 
>   
> /usr/netapp/faculty/mjadud/racket-src/racket/collects/racket/private/kw-file.rkt:102:2:
> call-with-input-file*61
> 
>   
> "/usr/netapp/faculty/mjadud/racket-src/racket/share/pkgs/cldr-bcp47/cldr/bcp47/timezone.rkt":
> [running body]
> 
>    temp37_0
> 
>    for-loop
> 
>    run-module-instance!125
> 
>    for-loop
> 
>    [repeats 1 more time]
> 
>    run-module-instance!125
> 
>    for-loop
> 
>    [repeats 1 more time]
> 
>    run-module-instance!125
> 
>    for-loop
> 
>    [repeats 1 more time]
> 
>    run-module-instance!125
> 
>    for-loop
> 
>    [repeats 1 more time]
> 
>    ...
> 
> instantiate: unknown module
> 
>   module name: # 'typed-racket/private/type-contract.rkt[8709188] predicates)>
> 
>   context...:
> 
>    namespace-module-instantiate!96
> 
>    for-loop
> 
>    [repeats 1 more time]
> 
>    run-module-instance!125
> 
>    for-loop
> 
>    [repeats 1 more time]
> 
>    run-module-instance!125
> 
>    for-loop
> 
>    [repeats 1 more time]
> 
>    run-module-instance!125
> 
>    for-loop
> 
>    [repeats 1 more time]
> 
>    run-module-instance!1

Re: [racket-users] gzip/gunzip through pipe is blocking

['Paulo Matos' via Racket Users]

On 30/10/2018 19:10, Matthew Flatt wrote:
> At Tue, 30 Oct 2018 17:54:46 +0100, "'Paulo Matos' via Racket Users" wrote:
>>
>>
>> On 30/10/2018 16:39, Matthew Flatt wrote:
>>> You need to close the output port after `gunzip-through-ports` finishes.
>>>
>>
>> OK, that was a mistake of writing this smallish example. The problem
>> persists, if I write (close-output-port out) after (gunzip-through-ports
>> out):
>> ➜  zipping-through-ports wc -l foo1
>> 12987 foo1
>> ➜  zipping-through-ports wc -l foo2
>> 12987 foo2
>> ➜  zipping-through-ports wc -l foo3
>> 12987 foo3
>> ➜  zipping-through-ports wc -l foo.txt
>> 12988 foo.txt
>>
>> I was expecting foo.txt to be the same as
>> $ cat foo1 foo2 foo3 > foo.txt
> 
> Oh, I see. The gzip format lets `gunzip-through-ports` stop when it
> gets to the end of a compressed stream, so if you want to decompress
> multiple concatenated streams until an EOF:
> 
>   (let loop ()
> (unless (eof-object? (peek-byte cin))
>   (gunzip-through-ports cin out)
>   (loop)))
> 

Yes! That makes sense. :)

This works:

```
#lang racket

(require file/gzip
 file/gunzip)

(define paths '("foo1" "foo2" "foo3"))

;; compress
(printf "compressing~n")
(call-with-atomic-output-file "foo.gz"
  (lambda (op p)
(for ([f (in-list paths)])
  (call-with-input-file f
(lambda (i) (gzip-through-ports i op #false (current-seconds)))
#:mode 'binary

;; decompress
(printf "decompressing~n")
(define-values (in out) (make-pipe))
(void
 (thread
  (thunk
   (call-with-input-file "foo.gz"
 (lambda (cin)
   (let loop ()
 (unless (eof-object? (peek-byte cin))
   (gunzip-through-ports cin out)
   (loop)))
   (close-output-port out))
 #:mode 'binary
(call-with-atomic-output-file "foo.txt"
  (lambda (op p)
(let loop ([l (read-line in)])
  (unless (eof-object? l)
(display l op)
(newline op)
(loop (read-line in))
```

> 
>> Still, I should point out that the reason I didn't close it originally
>> was because the documentation mentions that it's not necessary to close
>> make-pipe ports:
>> "Unlike some other kinds of ports, pipe ports do not need to be
>> explicitly closed to be reclaimed by garbage collection."
> 
> It isn't necessary to close the pipe for the pipe to be GCed when it's
> no longer referenced. But if you want to get an EOF from the input end
> of the pipe, then the write end needs to be closed.
> 

Thanks for the clarification.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] gzip/gunzip through pipe is blocking

['Paulo Matos' via Racket Users]

On 30/10/2018 17:07, George Neuner wrote:
> 
> On 10/30/2018 11:32 AM, 'Paulo Matos' via Racket Users wrote:
>> I have quite a few large files that I want to gzip to a single file
>> (without an intermediate concatenation) and then later gunzip.
> 
> I don't think you can do that - at least not without other software. 
> gzip/gunzip are meant to work only with a single file. gzip is a
> compression format, not an archive format - the compressed stream is
> assumed to contain a single object, it has no index or other metadata to
> handle multiple objects.  Typically you would tar the files and then zip
> the tar.
> 

I think you misunderstood. I don't really want the three files inside
the gzip. I want to gzip a single text file with the contents of foo1,
foo2 and foo3.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] gzip/gunzip through pipe is blocking

['Paulo Matos' via Racket Users]

Thanks for the comments on the random file generation. Regarding the
write a line at a time, that's just an artifact of adapting this from my
larger program which has to process each line before it's written back
to disk.

On 30/10/2018 17:04, Neil Van Dyke wrote:
> Two small comments in addition to what Matthew said...
> 
> 'Paulo Matos' via Racket Users wrote on 10/30/18 11:32 AM:
>> $ base64 /dev/urandom | head -c 100 > foo3
> 
> Even though these are just test files, you might normally want to make
> them by instead `dd if=/dev/urandom` piped to `base64 -`, along with
> `dd` options like `ibs`, `obs`, and `count`.  That gets you exactly the
> size of Base64-encoded content you want, with well-formed Base64
> encoding, without consuming unnecessary bytes from "/dev/urandom", and
> with possibly more efficient I/O blocking factors.
> 
> Also, in the exact illustrative example code you gave, I wonder whether
> you'd get better performance and simplicity by having
> `gunzip-through-ports` write direct to the "foo.txt" output-port, with
> no line-by-line processing, and whether you need the separate thread. 
> (Of course, your actual application code might need to do line-by-line
> processing, and/or have a separate thread, so I'm mainly mentioning this
> for the list, and for future copy&paste code reusers.)
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] gzip/gunzip through pipe is blocking

['Paulo Matos' via Racket Users]

On 30/10/2018 16:39, Matthew Flatt wrote:
> You need to close the output port after `gunzip-through-ports` finishes.
> 

OK, that was a mistake of writing this smallish example. The problem
persists, if I write (close-output-port out) after (gunzip-through-ports
out):
➜  zipping-through-ports wc -l foo1
12987 foo1
➜  zipping-through-ports wc -l foo2
12987 foo2
➜  zipping-through-ports wc -l foo3
12987 foo3
➜  zipping-through-ports wc -l foo.txt
12988 foo.txt

I was expecting foo.txt to be the same as
$ cat foo1 foo2 foo3 > foo.txt

Still, I should point out that the reason I didn't close it originally
was because the documentation mentions that it's not necessary to close
make-pipe ports:
"Unlike some other kinds of ports, pipe ports do not need to be
explicitly closed to be reclaimed by garbage collection."

The full program is now (also added a call to newline that I initially
forgot):
```
#lang racket

(require file/gzip
 file/gunzip)

(define paths '("foo1" "foo2" "foo3"))

;; compress
(printf "compressing~n")
(call-with-atomic-output-file "foo.gz"
  (lambda (op p)
(for ([f (in-list paths)])
  (call-with-input-file f
(lambda (i) (gzip-through-ports i op #false (current-seconds)))
#:mode 'binary

;; decompress
(printf "decompressing~n")
(define-values (in out) (make-pipe))
(void
 (thread
  (thunk
   (call-with-input-file "foo.gz"
 (lambda (cin)
   (gunzip-through-ports cin out)
   (close-output-port out))
 #:mode 'binary
(call-with-atomic-output-file "foo.txt"
  (lambda (op p)
(let loop ([l (read-line in)])
  (unless (eof-object? l)
    (write l op)
(newline op)
(loop (read-line in))
```
> At Tue, 30 Oct 2018 16:32:04 +0100, "'Paulo Matos' via Racket Users" wrote:
>> Hi,
>>
>> I have quite a few large files that I want to gzip to a single file
>> (without an intermediate concatenation) and then later gunzip.
>> Interestingly the gunzipping is blocking on a read-line. I wonder if
>> this is because I cannot use gzip-through-ports the way I am doing it or
>> if there's a bug somewhere.
>>
>> Generate 3 files with:
>> $ base64 /dev/urandom | head -c 100 > foo3
>> $ base64 /dev/urandom | head -c 100 > foo2
>> $ base64 /dev/urandom | head -c 100 > foo1
>>
>> Now run the code:
>> ```
>> #lang racket
>>
>> (require file/gzip
>>  file/gunzip)
>>
>> (define paths '("foo1" "foo2" "foo3"))
>>
>> ;; compress
>> (printf "compressing~n")
>> (call-with-atomic-output-file "foo.gz"
>>   (lambda (op p)
>> (for ([f (in-list paths)])
>>   (call-with-input-file f
>> (lambda (i) (gzip-through-ports i op #false (current-seconds)))
>> #:mode 'binary
>>
>> ;; decompress
>> (printf "decompressing~n")
>> (define-values (in out) (make-pipe))
>> (void
>>  (thread
>>   (thunk
>>(call-with-input-file "foo.gz"
>>  (lambda (cin)
>>(gunzip-through-ports cin out))
>>  #:mode 'binary
>> (call-with-atomic-output-file "foo.txt"
>>   (lambda (op p)
>> (let loop ([l (read-line in)])
>>   (unless (eof-object? l)
>> (write l op)
>> (loop (read-line in))
>>
>> ```
>>
>> This is going to block in a read-line, and I have a suspicion that it
>> blocks at the end of a compressed file. Is there a reason for it
>> blocking? Note that if you `zcat foo.gz | less` you can see the whole
>> file, so I am suspicious that something might be wrong with
>> gunzip-through-ports.
>>
>> Any suggestions to improve this?
>>
>> Thanks,
>>
>> -- 
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] gzip/gunzip through pipe is blocking

['Paulo Matos' via Racket Users]

Hi,

I have quite a few large files that I want to gzip to a single file
(without an intermediate concatenation) and then later gunzip.
Interestingly the gunzipping is blocking on a read-line. I wonder if
this is because I cannot use gzip-through-ports the way I am doing it or
if there's a bug somewhere.

Generate 3 files with:
$ base64 /dev/urandom | head -c 100 > foo3
$ base64 /dev/urandom | head -c 100 > foo2
$ base64 /dev/urandom | head -c 100 > foo1

Now run the code:
```
#lang racket

(require file/gzip
 file/gunzip)

(define paths '("foo1" "foo2" "foo3"))

;; compress
(printf "compressing~n")
(call-with-atomic-output-file "foo.gz"
  (lambda (op p)
(for ([f (in-list paths)])
  (call-with-input-file f
(lambda (i) (gzip-through-ports i op #false (current-seconds)))
#:mode 'binary

;; decompress
(printf "decompressing~n")
(define-values (in out) (make-pipe))
(void
 (thread
  (thunk
   (call-with-input-file "foo.gz"
 (lambda (cin)
   (gunzip-through-ports cin out))
 #:mode 'binary
(call-with-atomic-output-file "foo.txt"
  (lambda (op p)
(let loop ([l (read-line in)])
  (unless (eof-object? l)
(write l op)
(loop (read-line in))

```

This is going to block in a read-line, and I have a suspicion that it
blocks at the end of a compressed file. Is there a reason for it
blocking? Note that if you `zcat foo.gz | less` you can see the whole
file, so I am suspicious that something might be wrong with
gunzip-through-ports.

Any suggestions to improve this?

Thanks,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

On 05/10/2018 19:23, Matthew Flatt wrote:
> 
> We should certainly update the documentation with information about the
> limits of parallelism via places.
> 

Added PR:
https://github.com/racket/racket/pull/2304


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

On 08/10/2018 22:12, Philip McGrath wrote:
> This is much closer to the metal than where I usually spend my time,
> but, if it terns out that multiple OS processes is better than OS
> threads in this case, Distributed Places might provide an easier path to
> move to multiple processes than using `subprocess` directly:
> http://docs.racket-lang.org/distributed-places/index.html
> 

Sam mentioned trying that yesterday and I developed the loci library
before I did try them. Looking at the API, I can only say that at the
moment my library is certainly easier to use in the localhost. Once I
get to try to implement remote loci I will look into distributed places
and try to improve on that.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

Hi all,

Apologies for the delay in sending this email but I have been trying to
implement and test an alternative and wanted to be sure it works before
sending this off.

So, as Matthew suggested this problem has to do with memory allocation.
The --no-alloc option in Matthew's suggested snippet does not show the
delay I usually see in the thread CPU usage although thread creation is
still quite slow past around 20 places.

I started developing loci [1] to solve this problem instance yesterday
and I got it to a point where I can prove that subprocesses solve the
problem I am seeing. No point attaching a screenshot of htop with all
bars full to 100%... that's what happens. Also, process creation is
almost instantaneous and there's no delay compared to threads.

In the evening after I had almost everything sorted, Sam suggested on
Slack that I try distributed-places and use them locally. I haven't
tried this and I cannot say if it works better or worse but it seems
certainly harder to use than loci as my library uses the same API as places.

Part of the development was pretty quick because I noticed Matthew had
been playing with this before:
https://github.com/racket/racket/blob/master/pkgs/racket-benchmarks/tests/racket/benchmarks/places/place-processes.rkt
(might be worth noting that the code doesn't work with current racket)

I will adding contracts, tests and documentation throughout the week and
then replace places in my system with loci so I can dog-food the
library. Next step is to add remote loci at which point I will want to
compare with distributed-places and possibly improve on it.

If anyone has comments, suggestions or complaints on the library please
let me know but keep in mind it's barely a day old.

Paulo Matos


1: https://github.com/LinkiTools/racket-loci
   https://pkgd.racket-lang.org/pkgn/search?q=loci

On 05/10/2018 19:23, Matthew Flatt wrote:
> At Fri, 5 Oct 2018 17:55:47 +0200, Paulo Matos wrote:
>> Matthew, Sam, do you understand why this is happening?
> 
> I still think it's probably allocation, and probably specifically
> content on the process's page table. Do you see different behavior with
> a non-allocating variant (via `--no-alloc` below)?
> 
> We should certainly update the documentation with information about the
> limits of parallelism via places.
> 
> 
> 
> #lang racket
> 
> (define (go n alloc?)
>   (place/context p
>  (let ([v (vector (if alloc? 0.0 0))]
>[inc (if alloc? 1.0 1)])
>(let loop ([i 30])
>  (unless (zero? i)
>(vector-set! v 0 (+ (vector-ref v 0) inc))
>(loop (sub1 i)
>  (printf "Place ~a done~n" n)
>  n))
> 
> (module+ main
>   (define alloc? #t)
>   (define cores
> (command-line
>  #:once-each
>  [("--no-alloc") "Non-allocating variant" (set! alloc? #f)]
>  #:args (cores)
>  (string->number cores)))
> 
>   (time
>(map place-wait
> (for/list ([i (in-range cores)])
>   (printf "Starting core ~a~n" i)
>   (go i alloc?)
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

I just confirmed that this is due to memory allocation locking in the
kernel. If your places do no allocation then all is fine.

Paulo Matos

On 08/10/2018 21:39, James Platt wrote:
> I wonder if this has anything to do with mitigation for Spectre, Meltdown or 
> the other speculative execution vulnerabilities that have been identified 
> recently.  I understand that some or all of the patches affect the 
> performance of multi-CPU processing in general.
> 
> James  
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

I was trying to create a much more elaborate example when Matthew sent
his tiny one which is enough to show the problem.

I started a 64core machine on aws to show the issue.

I see a massive degradation as the number of places increases.

I use this slightly modified code:
#lang racket

(define (go n)
  (place/context p
 (let ([v (vector 0.0)])
   (let loop ([i 30])
 (unless (zero? i)
   (vector-set! v 0 (+ (vector-ref v 0) 1.0))
   (loop (sub1 i)
 (printf "Place ~a done~n" n)
 n))

(module+ main
  (define cores
(command-line
 #:args (cores)
 (string->number cores)))

  (time
   (map place-wait
(for/list ([i (in-range cores)])
  (printf "Starting core ~a~n" i)
  (go i)

Here's the results in the video (might take a few minutes until it is live):
https://youtu.be/cDe_KF6nmJM

The guide says about places:
"The place form creates a place, which is effectively a new Racket
instance that can run in parallel to other places, including the initial
place."

I think this is misleading at the moment. If this behaviour can be
'fixed' then great, if not I will have to redesign my system to use
'subprocess' to start another racket process and a footnote should be
added to places in documentation to alert the users about this behaviour.

Matthew, Sam, do you understand why this is happening?

On 05/10/2018 16:51, Sam Tobin-Hochstadt wrote:
> I tried this same program on my desktop, which also has 4 (i7-4770)
> cores with hyperthreading. Here's what I see:
> 
> [samth@huor:~/work/grant_parallel_compilers/nsf_submissions (master)
> plt] time r ~/Downloads/p.rkt 1
> N: 1, cpu: 5808/5808.0, real: 5804
> [samth@huor:~/work/grant_parallel_compilers/nsf_submissions (master)
> plt] time r ~/Downloads/p.rkt 2
> N: 2, cpu: 12057/6028.5, real: 6063
> [samth@huor:~/work/grant_parallel_compilers/nsf_submissions (master)
> plt] time r ~/Downloads/p.rkt 3
> N: 3, cpu: 23377/7792., real: 7914
> [samth@huor:~/work/grant_parallel_compilers/nsf_submissions (master)
> plt] time r ~/Downloads/p.rkt 4
> N: 4, cpu: 41155/10288.75, real: 10357
> [samth@huor:~/work/grant_parallel_compilers/nsf_submissions (master)
> plt] time r ~/Downloads/p.rkt 6
> N: 6, cpu: 89932/14988., real: 15687
> [samth@huor:~/work/grant_parallel_compilers/nsf_submissions (master)
> plt] time r ~/Downloads/p.rkt 8
> N: 8, cpu: 165152/20644.0, real: 21104
> 
> Real time goes up about 80% from 1-4 places, and then doubles again
> from 4 to 8. System time for 8 places is also about 10x what it is for
> 2 places, but only gets up to 2 seconds.
> On Fri, Oct 5, 2018 at 10:32 AM Matthew Flatt  wrote:
>>
>> At Fri, 5 Oct 2018 15:36:04 +0200, Paulo Matos wrote:
>>> Again, I am really surprised that you mention that places are not
>>> separate processes. Documentation does say they are separate racket
>>> virtual machines, how is this accomplished if not by using separate
>>> processes?
>>
>> Each place is an OS thread within the Racket process. The virtual
>> machine is essentially instantiated once in each thread, where things
>> that look like global variables at the C level are actually
>> thread-local variables to make them place-specific. Still, there is
>> some sharing among the threads.
>>
>>> My workers are really doing Z3 style work - number crushing and lots of
>>> searching. No IO (writing to disk) or communication so I would expect
>>> them to really max out all CPUs.
>>
>> My best guess is that it's memory-allocation bottlenecks, probably at
>> the point of using mmap() and mprotect(). Maybe things don't scale well
>> beyond the 4-core machines that I use.
>>
>> On my machines, the enclosed program can max out CPU use with system
>> time being a small fraction. It scales ok from 1 to 4 places (i.e.,
>> real time increased only some). The machine's core are hyperthreaded,
>> and the example maxes out CPU utilization at 8 --- but it takes twice
>> as long in real time, so the hardware threads don't help much in this
>> case. Running two processes with 4 places takes about the same real
>> time as running one process with 8 places, as does 2 processes with 2
>> places.
>>
>> Do you see similar effects, or does this little example stop scaling
>> before the number of processes matches the number of cores?
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

On 05/10/2018 14:15, Matthew Flatt wrote:
> It's difficult to be sure from your description, but it sounds like the
> problem may just be the usual one of scaling parallelism when
> communication is involved.
> 

Matthew, thanks for the reply.

The interesting thing here is that there is no communication between
places _most of the time_. It works as a ring topology where every
worker only communicates with the master and the master with all workers.

This communication is relatively rare, as in a message sent every few
minutes.

> Red is probably synchronization. It might be synchronization due to the
> communication you have between places, it might be synchronization on
> Racket's internal data structures, or it might be that the OS has to
> synchronize actions from multiple places within the same process (e.g.,
> multiple places are allocating and calling OS functions like mmap and
> mprotect, which the OS has to synchronize within a process). We've
> tried to minimize sharing among places, and it's important that they
> can GC independently, but there are still various forms of sharing to
> manage internally. In contrast, running separate processes for Z3
> should scale well, especially if the Z3 task is compute-intensive with
> minimal I/0 --- a best-case scenario for the OS.
> 

So, here you have pointed out to something that's surprising to me:
"OS has to synchronize actions from multiple places within the same
process (e.g., multiple places are allocating and calling OS functions
like mmap and mprotect, which the OS has to synchronize within a process)."

I thought each place was its own process similar to issuing a call of
racket itself on the body of the place. Now it seems somehow places are
all in the same process... in which case they'll probably even share
mutexes, although these low level details are a bit foggy in my mind.

> A parallel `raco setup` runs into similar issues. In recent development
> builds, you might experiment with passing `--processes` to `raco setup`
> to have it use separate processes instead of places within a single OS
> process, but I think you'll still find that it tops out well below your
> machine's compute capacity. Partly, dependencies constrain parallelism.
> Partly, the processes have to communicate more and there's a lot of
> I/O.

Again, I am really surprised that you mention that places are not
separate processes. Documentation does say they are separate racket
virtual machines, how is this accomplished if not by using separate
processes?

My workers are really doing Z3 style work - number crushing and lots of
searching. No IO (writing to disk) or communication so I would expect
them to really max out all CPUs.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

All,

A quick update on this problem which is in my critical path.
I just noticed, in an attempt to reproduce it, that during the package
setup part of the racket compilation procedure the same happens.

I am running `make CPUS=24 in-place`on a 36 cpu machine and I see that
not only sometimes the racket process status goes from 'R' to 'D' (which
also happens in my case), the CPUs are never really working at 100% with
a lot of the work being done at kernel level.

Has anyone ever noticed this?

On 01/10/2018 11:13, 'Paulo Matos' via Racket Users wrote:
> 
> Hi,
> 
> I am not sure this is an issue with places or what it could be but my
> devops-fu is poor and I am not even sure how to debug something like
> this so maybe someone with more knowledge than me on this might chime in
> to hint on a possible debug method.
> 
> I was running some benchmarks and noticed something odd for the first
> time (although it doesn't mean it was ok before, just that this is the
> first time I am actually analysing this issue).
> 
> My program (the master) will create N places (the workers) and each
> place will start by issuing a rosette call which will trigger a call to
> the z3 smt solver. So, N instances of Z3 will run and after it is done
> it will run pure racket code that implements a graph search algorithm.
> This N worker places are actually in a sync call waiting for messages
> from the master and the work is being done by a thread on the worker
> place. The master is either waiting for the timeout to arrive or for a
> solution to be sent from a worker.
> 
> The interesting thing is that when the Z3 instances are running I get
> all my 16 CPUs (on a dedicated machine) working at 100%. When the racket
> code is running the search, they are all holding off at around 60%-80%
> with a huge portion of it in the kernel (red bars in htop).
> 
> Since the Z3 calls come before the threads inside the places are started
> and we get to the sync call, is it possible something bad is happening
> in the sync call that uses the kernel so much? Take a look at htop
> during Z3 and during the search - screenshots attached.
> 
> Are there any suggestions on what the problem might be or how I could
> start to understand why the kernel is so active?
> 
> Kind regards,
> 
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket-on-Chez snapshots

['Paulo Matos' via Racket Users]

On 02/10/2018 16:25, Alexis King wrote:
>> On Oct 1, 2018, at 13:07, Brett Gilio  wrote:
>>
>> Hey, could you provide a resource with more information on Chez possibly
>> replacing the Racket VM? I haven't been keeping up to date on this.
> 
> From an interaction between Greg Trzeciak and Matthew Flatt on the slack 
> channel:
> 
>> Greg: is there a chance for a post (blog or mailing list) summarizing the 
>> "state of racket" talk for those of us who didn't attend racketcon?
>>
>> Matthew: Yes (or planned, at least), in two parts. The first part will be a 
>> blog post that mostly reflects the Racket-on-Chez results that I reported at 
>> the Scheme workshop. That talk was recorded, so I expect it will be 
>> available as video at some point. The second will be a how-to post on 
>> modifying Racket-on-Chez.
> 
> So even if you weren’t at RacketCon, there are plans to provide a more 
> current update at some point (hopefully soon).
> 

+1
Awesome! I assume there'll be RacketCon videos as well?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Playing the Game with PLT Redex · Second Edition

['Paulo Matos' via Racket Users]

Leandro, obrigado por esta excelente contribuição.

Thank you for this excellent contribution. It's really good. I am
reading it a bit at a time and I really enjoy it, not only how you write
it but the subject as well.

Racket needs more of this.

Paulo Matos

On 30/09/2018 18:34, 'Leandro Facchinetti' via Racket Users wrote:
> Hi Racketeers,
> 
> I while ago I wrote a short article in which I used PLT Redex to play a
> game of Peg Solitaire. I now present you the extended version of that
> article:
> 
> https://www.leafac.com/prose/playing-the-game-with-plt-redex/
> 
> The short and to-the-point version still exists in the form of an
> introduction: 
> https://www.leafac.com/prose/playing-the-game-with-plt-redex/introduction
> 
> But now I also dive into a few PLT Redex forms in more detail. I
> consider this to be a better bridge between knowing little about
> programming-language theory and being able to follow more advanced
> material, for example, the excellent SEwPR.
> 
> I welcome feedback.
> 
> Thank you for your time.
> 
> -- 
> Leandro Facchinetti mailto:m...@leafac.com>>
> https://www.leafac.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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

I attach yet another example where this behaviour is much more
noticiable. This is on a 64 core dedicated machine in amazon aws.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Places code not using all the CPU

['Paulo Matos' via Racket Users]

Hi,

I am not sure this is an issue with places or what it could be but my
devops-fu is poor and I am not even sure how to debug something like
this so maybe someone with more knowledge than me on this might chime in
to hint on a possible debug method.

I was running some benchmarks and noticed something odd for the first
time (although it doesn't mean it was ok before, just that this is the
first time I am actually analysing this issue).

My program (the master) will create N places (the workers) and each
place will start by issuing a rosette call which will trigger a call to
the z3 smt solver. So, N instances of Z3 will run and after it is done
it will run pure racket code that implements a graph search algorithm.
This N worker places are actually in a sync call waiting for messages
from the master and the work is being done by a thread on the worker
place. The master is either waiting for the timeout to arrive or for a
solution to be sent from a worker.

The interesting thing is that when the Z3 instances are running I get
all my 16 CPUs (on a dedicated machine) working at 100%. When the racket
code is running the search, they are all holding off at around 60%-80%
with a huge portion of it in the kernel (red bars in htop).

Since the Z3 calls come before the threads inside the places are started
and we get to the sync call, is it possible something bad is happening
in the sync call that uses the kernel so much? Take a look at htop
during Z3 and during the search - screenshots attached.

Are there any suggestions on what the problem might be or how I could
start to understand why the kernel is so active?

Kind regards,


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] 2018 SIGPLAN Software Award

['Paulo Matos' via Racket Users]

Impressive and well-deserved achievement.

The work done by the PLT Group and others has been undervalued for too
long. I certainly believe that for too long the only marketing coming
out of Racket/PLT Scheme was "it's great for education", which although
it might be true, it understates its real value.

Racket is a great language in its own right. Not just for education and
not just for prototyping. Racket is great for product development as
well - from start to finish - no ifs or buts. Saying otherwise is
understating its value and undervaluing your work.

I congratulate everyone in Racket boat, I have a feeling the future is
bright. Buckle your seatbelts, the ride is just starting! :)

Paulo Matos

On 27/09/2018 00:53, Matthew Flatt wrote:
> Dear Racketeers, 
> 
> Racket has just received the
> 
>2018 ACM SIGPLAN Software Systems Award
> 
> We are honored by this award, but it belongs to more than the core
> group of people named in the citation. Many people have invested time
> and energy into this language.
> 
> The language is what it is now because of you.
> 
> Looking back at the modest beginnings in January 1995, we want to
> acknowledge some contributors specially: 
> 
>   John Clements, for constructing the incredible stepper back in the
>  late 90s and thus helping distinguish DrScheme from all other
>  pedagogic IDEs, for maintaining the beast for 20 years, and
>  taking on many other library projects;
> 
>   Cormac Flanagan, for using PLT Scheme to create MrSpidey, which
>  placed our little language into the web of SIGPLAN research and
>  awareness way way back;
> 
>   Matthew Butterick for "Beautiful Racket", code, languages, volunteer
>  teaching, and faithful evangelizing;
> 
>   Vincent St-Amour, Ryan Culpepper, Paul Steckler, and Mark Krentel
>  for managing the Racket world of software for many years;
> 
>   and Vincent also for his tender love and care for RacketCon.
> 
> Many, many others have contributed to Racket over the past two decades
> through implementation, teaching, and research. We have collected many
> names at the end of this post, but our memories are probably flawed
> and, in recent years, the contributor community has grown
> tremendously. This doesn't mean we aren't thinking of you and thanking
> you today --- and not just today, but every time we launch our
> wonderful DrRacket and run beautiful Racket programs.
> 
> THANK YOU ALL. We are looking forward to many more years of
> Racketeering!
> 
> - Matthew with Eli, Matthias, Robby, Shriram, Jay, and Sam 
> 
> Contributors: Claire Alvis, Leif Andersen, Yavuz Arkun, Ian Barland,
> Gann Bierner, Stephen Bloch, Filipe Cabecinhas, Corky Cartwright,
> Stephen Chang, Richard Cleis, Richard Cobbe, Greg Cooper, Christos
> Dimoulas, Eric Dobson, Carl Eastlund, Moy Easwaran, Will Farr, Dan
> Feltey, Michael Filonenko, Burke Fetscher, Kathi Fisler, Spencer
> Florence, Daniel Friedman, Tony Garnock-Jones, Sebastian Good, Paul
> Graunke, Kathy Gray, Ben Greenman, Dan Grossman, Arjun Guha, Dave
> Gurnell, Tobias Hammer, William Hatch, Bruce Hauman, Greg Hendershott,
> Dave Herman, Jim Hollan, Blake Johnson, Andrew Kent, Gregor Kiczales,
> Alexis King, Casey Klein, Alex Knauth, Geoffrey S. Knauth, Mario
> Latendresse, Xiangqi Li, Guillaume Marceau, Gustavo Massaccesi, Jacob
> Matthews, Mike T. McHenry, Philippe Meunier, Albert Meyer, Scott
> Owens, David T. Pierson, Jon Rafkind, Prabhakar Ragde, Norman Ramsey,
> Jamie Raymond, Grant Rettke, Guido Rößling, Emmanuel Schanzer, Paul
> Schlie, Dorai Sitaram, Francisco Solsona, Sarah Spall, Mike Sperber,
> Stevie Strickland, James Swaine, Jens Axel Søgaard, Neil Van Dyke,
> David Van Horn, Anton van Straaten, Asumu Takikawa, Kevin Tew, Neil
> Toronto, Milo Turner, Dale Vaillancourt, Dimitris Vyzovitis, Mitch
> Wand, Stephanie Weirich, Noel Welsh, Adam Wick, Danny Yoo, Shu-Hung
> You, and ChongKai Zhu.
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Compilation/Embedding leaves syntax traces

['Paulo Matos' via Racket Users]

On 26/09/2018 19:39, Philip McGrath wrote:
> On Wed, Sep 26, 2018 at 1:36 AM Paulo Matos  wrote:
> 
> I am keen on hearing about alternatives. The reason to do like this is
> to minimize friction with clients. Clients in the area of development
> tools expect something that they can execute and generally are not too
> keen on scripty calls like `python foo.py`, so if I said: Please run the
> program with `racket s10.rkt` ... it would very quickly lower my
> possibility of a sale. Racket distribution creates essentially the
> package that they expect, something they can run out of the box without
> thinking much about dependencies in something that looks like an
> executable - even if it's just more or less a racket shell. Your product
> appearance is important and therefore I want to give something they are
> already used to.
> 
> 
> I definitely understand wanting users to be able to run the application
> in a way that feels as normal as possible to them: I think about this
> even with internal tools that I develop for collaborators with a limited
> technical background.
> 
> I think the approach I brought up would be compatible with making
> distributions. What I had in mind (but see below) was something like:
> ;; x86_64-no-contracts.rkt
> #lang racket/base
> (require "../run-program.rkt")
> (run-program #:arch 'x86_64 #:contracts? #f)
> 
> ;; i386-with-contracts.rkt
> #lang racket/base
> (require "../run-program.rkt")
> (run-program #:arch 'i386 #:contracts? #f)
>  Then `raco exe`/`create-embedding-executable`/whatever can work on
> either version.
> 
> > Most seriously, depending on exactly how you use these compile-time
> > environment variables, it seems like you could negate some of the
> > benefits of the "separate compilation guarantee," particularly if you
> > are assuming that all of your modules are compiled at the same time.
> >
> 
> Why would that be a problem?
> 
> 
> This is a longer discussion and I am by no means an expert, but I can
> point you to the "separate compilation guarantee" docs
> (http://docs.racket-lang.org/reference/eval-model.html#(part._separate-compilation))
> and Matthew Flatt's paper "Composable and Compilable Macros: You Want it
> /When?/" (https://www.cs.utah.edu/plt/publications/macromod.pdf).
> 

I took the time to think through this and skim through the paper. I
understand what you mean by separate compilation guarantee. I am not
convinced what I am doing breaks the separate compilation guarantee.
>From what I understood this is broken if there are any side-effects of
the compilation process, i.e. printing, writing to files, etc. Which
there are none with the approach I take. However, I might be missing
some subtle detail. I haven't yet internalised all of the information
with regards to phase levels.

> I don't think what you are doing circumvents the separate compilation
> guarantee per se, 

+1 ah, should have read this before writing the above. :)

> because you don't produce "external effects" (e.g.
> I/O) during compilation and then rely on those side-effects during
> run-time. But, while I have not thought especially deeply about this,
> using environment variables this way seems to be sort of the mirror
> image: the state of the universe external to the Racket runtime system
> has effects on the compilation of your modules, and it seems like that
> might introduce similar problems.
> 

This might be one of those subtleties I don't quite understand and they
might happen. As I said in the OP, I am actually still having problems I
can't reproduce in a small example, that only occur when the code is
embedded in the executable.

> In particular, "the practical consequence of [the separate compilation]
> guarantee is that because effects are never visible, no module can
> detect whether a module it requires is already compiled. Thus, it can
> never change the compilation of one module to have already compiled a
> different module." This has all kinds of nice benefits that are detailed
> in the paper.
> 

This might be related to what I am seeing... which looks like this:
instantiate-linklet: mismatch;
 reference to a variable that is uninitialized;
 possibly, bytecode file needs re-compile because dependencies changed
  name: g8759.1
  exporting instance: '#%embedded:g28621:stochastic-statistics
  importing instance: '#%embedded:g26566:stochastic


On the other hand, it's strange that this only happens when the code is
embedded in the executable... so I am not sure if it's actually this or
just a bug in my phase 1 code in the embedding process.

> In your case you seem to assume that all of the modules are compiled at
> the same time (i.e. with the same set of environment variables). 

Correct.

> You do
> seem to put in the effort to actually uphold that assumption, and maybe
> there are compelling reasons to do so in your case, but I would suggest
> thinking carefully about that decision.
>

Re: [racket-users] Compilation/Embedding leaves syntax traces

['Paulo Matos' via Racket Users]

On 25/09/2018 23:38, Ryan Culpepper wrote:
> On 9/25/18 1:11 PM, Alexis King wrote:
>> [] Personally, I would appreciate a way to ask
>> Racket to strip all phase ≥1 code and phase ≥1 dependencies from a
>> specified program so that I can distribute the phase 0 code and
>> dependencies exclusively. However, to my knowledge, Racket does not
>> currently include any such feature.
> 
> `raco demod -g` seems to do that, but the `-g` option is marked with a
> warning.
> 
> Ryan
> 

Once you have this new demod'ed zo file, how do you run it? On the
example of my original post, I get the demod'ed file, and try to run it
with racket. It doesn't crash but it also prints nothing.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Compilation/Embedding leaves syntax traces

['Paulo Matos' via Racket Users]

On 25/09/2018 23:44, Philip McGrath wrote:
> On Tue, Sep 25, 2018 at 3:46 PM 'Paulo Matos' via Racket Users
> mailto:racket-users@googlegroups.com>>
> wrote:
> 
> OK, so I understand now that what I want is an unimplemented feature,
> but in most compilers these days and certainly those based in LLVM and
> GCC there's a feature called whole-program optimization or link time
> optimization. Basically the compiler will get the whole program in
> memory after compiling each module/file and run the optimizations on the
> whole thing again therefore being able to optimize things it wasn't able
> to optimize before when it only had a module/file view.
> 
> 
> I know that `raco demodularize` can flatten a whole program
> (https://docs.racket-lang.org/raco/demod.html). I think I remember
> reading a paper that looked at using this as the basis for whole-program
> optimization, but I don't remember the results of the paper, much less
> anything about doing this in practice.
>  

You are right, and as Ryan mentioned in another post -g will re-compile
after the de-modularization - in effect doing whole-program
optimization. I am amazed and scared at the same time. :)

If you recall the paper please let me know.

> 
> >> My software has several compile time options that use environment
> >> variables to be read (since I can't think of another way to do
> it) so I
> >> define a compile time variable as:
> >>
> >> (define-for-syntax enable-contracts?
> >> (and (getenv "S10_ENABLE_CONTRACTS") #true))
> >>
> >> And then I create a macro to move this compile-time variable to
> runtime:
> >> (define-syntax (compiled-with-contracts? stx)
> >> (datum->syntax stx enable-contracts?))
> >>
> >> I have a few of these so when I create a distribution, I first
> create an
> >> executable with (I use create-embedding-executable but for
> simplicity,
> >> lets say I am using raco):
> >> S10_ENABLE_CONTRACTS=1 raco exe ...
> 
> 
> More broadly, the thing that first struck me is that most Racket
> programs don't seem to use this sort of build process. I do think they
> should be /able/ to, and there may be good reasons to do that in your
> case, but I've been trying to think about what it is about this that
> strikes me as un-Racket-ey and what alternatives might be.
> 

I am keen on hearing about alternatives. The reason to do like this is
to minimize friction with clients. Clients in the area of development
tools expect something that they can execute and generally are not too
keen on scripty calls like `python foo.py`, so if I said: Please run the
program with `racket s10.rkt` ... it would very quickly lower my
possibility of a sale. Racket distribution creates essentially the
package that they expect, something they can run out of the box without
thinking much about dependencies in something that looks like an
executable - even if it's just more or less a racket shell. Your product
appearance is important and therefore I want to give something they are
already used to.

> I think one part of it is that compiling differently based on
> environment variables seems to go against the principle that "Racket
> internalizes extra-linguistic mechanisms"
> (http://felleisen.org/matthias/manifesto/sec_intern.html). For a
> practical example, environment variables are vexing on Mac OS for GUI
> programs.

Not sure about Mac OS because I never used one but I hadn't had the need
before this project to do something like this and when I started I was
pointed to how contracts are doing this:
(define-for-syntax enable-contracts? (and (getenv "PLT_TR_CONTRACTS") #t))

in
https://github.com/racket/typed-racket/blob/1825355c4879b6263b0c8fe88b30e11d79fc0d31/typed-racket-lib/typed-racket/utils/utils.rkt#L43


So, I created a racket app to pack my application, so you can actually
do something like:
racket create-s10-distribution.rkt --with-contracts --with-statistics
./release-folder

This will put an S10 release in release folder that can be moved to
another system.

Side note: This is also useful for benchmarking as I can easily
dockerize it, and get it running on a big AWS machine without worrying
about installing racket, etc.

> 
> Another issue is that this approach means that only one compiled
> configuration exists at a time. In some cases maybe that's right: I've
> had files in which I manually switch the definition of a macro to, say,
> add some `printf`s that I only want when I'm actively working on that
> specific file. But more often, if it makes sense for multiple versions

Re: [racket-users] Compilation/Embedding leaves syntax traces

['Paulo Matos' via Racket Users]

On 25/09/2018 23:38, Ryan Culpepper wrote:
> On 9/25/18 1:11 PM, Alexis King wrote:
>> [] Personally, I would appreciate a way to ask
>> Racket to strip all phase ≥1 code and phase ≥1 dependencies from a
>> specified program so that I can distribute the phase 0 code and
>> dependencies exclusively. However, to my knowledge, Racket does not
>> currently include any such feature.
> 
> `raco demod -g` seems to do that, but the `-g` option is marked with a
> warning.

Wow, ok, I am officially amazed - but at the same time slightly scared
of trying it on a very large application. :)


What do you mean 'marked with a warning'?
raco demod --help just says:
-r, --recompile : Recompile final module to re-run optimizations

There's no warning there.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Compilation/Embedding leaves syntax traces

['Paulo Matos' via Racket Users]

On 25/09/2018 20:11, Alexis King wrote:
> (Sorry, Paulo, for the duplicate message; I forgot to Reply All the
> first time.)
> 
> This is sort of subtle. When we consider a macro-enabled language, we
> often imagine that `expand` takes a program with some phase ≥1 code,
> expands all the macros in the program by running the phase ≥1 code, and
> produces a fully-expanded program with only phase 0 code left. There is
> some truth to this, but it doesn’t paint the whole picture.
> 
> [snip] [snip]

Alexis, thanks for the thorough reply. I understood everything, at least
up until this point.


> The above explains why Racket retains some phase ≥1 code. However, it
> may be unsatisfying: while it’s true that the phase ≥1 code might be
> necessary for compilation of other modules, once you have compiled your
> whole program, it shouldn’t be necessary to keep that information
> around, right? 

Right! That's exactly what I was thinking...

> No other modules will ever need to be compiled against
> the macro-providing module. However, this is not necessarily true!
> Racket provides a set of reflective operations for compiling modules at
> runtime, and it makes no assumptions that all modules will be loaded
> from compiled code. In this sense, Racket includes an “open-world
> assumption” when compiling modules, and it retains any phase ≥1 code
> necessary for compiling new modules at any time.
> 

OK, so I understand now that what I want is an unimplemented feature,
but in most compilers these days and certainly those based in LLVM and
GCC there's a feature called whole-program optimization or link time
optimization. Basically the compiler will get the whole program in
memory after compiling each module/file and run the optimizations on the
whole thing again therefore being able to optimize things it wasn't able
to optimize before when it only had a module/file view.

Now, in Racket when I compile an executable, although it's true there
might be dynamic-requires, if you look at the example I posted there's
not even one. Surely it's possible to remove all the phase>=1 code,
correct? Is it just the case that this kind of global optimization is
not yet implemented?

Even with dynamic-requires, if the dynamic-require depends on a compile
time variable that contains the path, after compilation the
dynamic-require won't change and will always require the same file,
therefore we can do the same kind of phase >= 1 code cleanup.

Am I missing any subtlety here or are these feasible but we are just
missing these optimizations?

> This sort of thing is necessary to implement tools like DrRacket, which
> frequently compile new modules at runtime, but admittedly, most programs
> don’t do any such thing. Personally, I would appreciate a way to ask
> Racket to strip all phase ≥1 code and phase ≥1 dependencies from a
> specified program so that I can distribute the phase 0 code and
> dependencies exclusively. However, to my knowledge, Racket does not
> currently include any such feature.
> 

Again, here I assume that in some cases, like the ones I mentioned above
you wouldn't even have to ask. It could be done automatically.

> For more information on declaring, instantiating, and visiting modules,
> and how that relates to compilation, see this very helpful section in
> The Racket Guide:
> 
>http://docs.racket-lang.org/guide/macro-module.html
> 

Thank you for the reference.

Paulo Matos
> 
>> On Sep 25, 2018, at 07:32, 'Paulo Matos' via Racket Users 
>>  wrote:
>>
>>
>> Hi,
>>
>> I reached a point at which I don't think I am exactly understanding how
>> the racket compilation pipeline works.
>>
>> My software has several compile time options that use environment
>> variables to be read (since I can't think of another way to do it) so I
>> define a compile time variable as:
>>
>> (define-for-syntax enable-contracts?
>> (and (getenv "S10_ENABLE_CONTRACTS") #true))
>>
>> And then I create a macro to move this compile-time variable to runtime:
>> (define-syntax (compiled-with-contracts? stx)
>> (datum->syntax stx enable-contracts?))
>>
>> I have a few of these so when I create a distribution, I first create an
>> executable with (I use create-embedding-executable but for simplicity,
>> lets say I am using raco):
>> S10_ENABLE_CONTRACTS=1 raco exe ...
>>
>> I have a bunch of other options that don't matter for the moment.
>>
>> One of the things I noticed is that in some cases when I run my
>> executable, compile time code living inside begin-for-syntax to check if
>> a variable has been defined during compilation or not is triggered. At a
>>

[racket-users] Compilation/Embedding leaves syntax traces

['Paulo Matos' via Racket Users]

Hi,

I reached a point at which I don't think I am exactly understanding how
the racket compilation pipeline works.

My software has several compile time options that use environment
variables to be read (since I can't think of another way to do it) so I
define a compile time variable as:

(define-for-syntax enable-contracts?
  (and (getenv "S10_ENABLE_CONTRACTS") #true))

And then I create a macro to move this compile-time variable to runtime:
(define-syntax (compiled-with-contracts? stx)
  (datum->syntax stx enable-contracts?))

I have a few of these so when I create a distribution, I first create an
executable with (I use create-embedding-executable but for simplicity,
lets say I am using raco):
S10_ENABLE_CONTRACTS=1 raco exe ...

I have a bunch of other options that don't matter for the moment.

One of the things I noticed is that in some cases when I run my
executable, compile time code living inside begin-for-syntax to check if
a variable has been defined during compilation or not is triggered. At a
point, which I didn't expect any more syntax expansion to occur.

I can't really reproduce the issue with a small example yet but I
noticed something:

main.rkt:

#lang racket

(require (file "arch-choice.rkt"))

(module+ main
  (printf "arch: ~a~n" (get-path)))

arch-choice.rkt:

#lang racket

(provide get-path)

(begin-for-syntax

  (define arch-path (getenv "ARCH"))

  (unless arch-path
(raise-user-error 'driver "Please define ARCH with a suitable path")))

(define-syntax (get-path stx)
  (datum->syntax stx arch-path))

Then just to make sure nothing is compiled I remove my zos:
$ find . -type f -name '*.zo' -exec \{\} \;

Then compile it:
$ ARCH=foo raco exe main.rkt

In this case if you run ./main you'll get 'arch: foo' back which is fine
so I can't reproduce what I see in my software which is with some
combinations of compile time options, I see:
'driver: Please define ARCH environment variable'

which should even be part of the executable because it's a compile time
string (or so I thought).

So I did on the above example:
$ strings main | grep ARCH
PLANET-ARCHIVE-FILTER
ARCH"
''Please define ARCH with a suitable path


OK, so, this agrees with what I see in my program: compile-time error
strings still exist in the code. Why is that? I thought that only fully
expanded code (compiled-code) would make it to the executable file.

Another thing that might help me understand what's going on, is there a
way to extract the bytecode from the executable and decompile it?

Thanks,


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket language for enterprise software

['Paulo Matos' via Racket Users]

On 25/09/2018 12:42, Daniel Brunner wrote:
>> with java based frameworks like Spring Boot for developing
>> Microservices? Do you see organizations adopting Racket or Racket based
>> languages slowly?
> 
> We are providing services on Amazon Web Services for handling the data
> of sensors (less than 2,000) in the oil and gas market. Several
> components (maybe one could call them microservices) are written in Racket.
> 
> Kind regards,
> Daniel
> 

Which company is this, may I ask?
Feel free to join racket-money [1].


[1]: http://www.neilvandyke.org/racket-money/

Regards,
-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Assumptions of raco distribute on target system

['Paulo Matos' via Racket Users]

On 18/09/2018 14:23, Matthew Flatt wrote:
> 
> The right solution is probably to use the "natipkg" build of Racket for
> Linux, which minimizes the libraries that are required from the OS. For
> example, the natipkg variant uses its own build of libcrypto. You can
> find natipkg builds from a snapshot page or the "More Variants and
> Checksums" download page for the current release:
> 
>   http://download.racket-lang.org/releases/7.0/
>
Thanks. I will take this route. Just out of curiosity, why are  natipkg
binaries built and distributed? Is there any use case you are
specifically targetting?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Assumptions of raco distribute on target system

['Paulo Matos' via Racket Users]

I have been playing with a CI pipeline of my software that does:
test -> build -> containerize

The idea is that build creates an OS independent distribution using raco
distribute and then containerize creates a docker image of the
distribution using a well-known linux distro. In my case, I chose to use
debian:stable-slim. Containerization doesn't really work. For example,
libcrypto is not added to the distribution so the application fails to
start inside the container.

Take this project:
Dockerfile:

FROM debian:stable-slim

# Clone and setup
COPY ./lc /lc/

ENTRYPOINT ["/lc/bin/lc.exe"]

main.rkt:
#lang racket

(require openssl/libcrypto)

(if libcrypto
(printf "Woohoo~n")
(printf "Doh~n"))

$ raco exe -o lc.exe main.rkt
$ ./lc.exe
Woohoo
$ raco distribute lc lc.exe
$ lc tree
.
├── bin
│   └── lc.exe
└── lib
└── plt
└── racket3m-7.0
$ docker build -t lc-demo .
Sending build context to Docker daemon  19.76MB
Step 1/3 : FROM debian:stable-slim
 ---> 414b5dbe710f
Step 2/3 : COPY ./lc /lc/
 ---> a43cb109cc9a
Step 3/3 : ENTRYPOINT ["/lc/bin/lc.exe"]
 ---> Running in bd7ab103ba33
Removing intermediate container bd7ab103ba33
 ---> fa0fdc5081f8
Successfully built fa0fdc5081f8
Successfully tagged lc-demo:latest
$ docker run lc-demo
Doh

Initially I thought someone forgot to mark the path of the libcrypto
library with a define-runtime-path, except I was wrong.
https://github.com/racket/racket/blob/5bb837661c12a9752c6a99f952c0e1b267645b33/racket/collects/openssl/libcrypto.rkt#L55

That looks ok to me, so why didn't raco distribute copy the library into
the distribution?

Kind regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] specialized languages

['Paulo Matos' via Racket Users]

If I understand correctly you want to create languages in Racket?

In which case you want to read:
https://beautifulracket.com/

Paulo Matos

On 17/09/2018 02:22, Hendrik Boom wrote:
> I'm looking for an introduction to the tools for making Racket into a 
> specualized language.
> 
> I know how to write compilers already.  I've done a few for significant 
> languages.
> 
> I'm looking for how to use the specialised tools available in Racket.
> 
> -- hendrik
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Historical mailing list archives [fast.cs.utah.edu]

['Paulo Matos' via Racket Users]

Hi,

Just a quick question with regards to old mailing list archives: up to
2002, did we only have one mailing list?

These are the archives I could find:
https://www.cs.utah.edu/plt/mailarch/

Was there anything else back then?
Also the link above says:
 After June 2002:
http://list.cs.brown.edu/pipermail/plt-scheme/

But that link is broken. I assume it should point to:
http://lists.racket-lang.org/users/archive/

Was it in June 2002 that it was split into dev and users?

Thanks,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Distributing application with run-time configuration

['Paulo Matos' via Racket Users]

OK, I sat down and re-read:
https://docs.racket-lang.org/guide/phases.html

Then I noticed I made a stupid mistake in my first attempt. I didn't
need to provide the binding at different levels, I needed only to
require it at different levels. So doing
(require s10/arch-choice
 (for-syntax s10/arch-choice))

did the trick.

Thanks for your time helping me with this issue.

Kind regards,

Paulo Matos

On 13/09/2018 14:28, 'Paulo Matos' via Racket Users wrote:
> 
> 
> On 12/09/2018 16:37, Matthew Flatt wrote:
>> As you
>> say, you could have a macro expand to the result of `(getenv "ARCH")`
>> to pin it down at compile time, but you'll need to import that macro
>> into two phases, since the right-hand side of
>> `define-runtime-module-path-index` is implicitly used at two phases. 
> 
> Thanks for your thorough explanation of the issues. That clarified it
> completely.
> 
> I have got it to working and realised that actually a compile time
> configuration is more future-proof in case I end up developing a private
> backend for a customer which I should ship to another customer by
> mistake, therefore embedding a single backend per release is better.
> 
> I setup a file which does this to choose the backend at compile-time:
> #lang racket/base
> ;;
> ---
> 
> (require (for-syntax racket/base))
> 
> (provide get-configured-backend-path)
> 
> ;;
> ---
> ;; This module is used to move the compile time variable s10arch, read
> from the environment
> ;; to a build-time variable using a macro.
> 
> (begin-for-syntax
>   ;; An environment variable must be defined selecting the arch to use.
>   (define s10arch (getenv "S10ARCH"))
> 
>   (unless s10arch
> (raise-user-error 'driver "Please define S10ARCH environment
> variable")))
> 
> (define-syntax (get-configured-backend-path stx)
>   (syntax-case stx ()
> [(_) (datum->syntax stx s10arch)]))
> 
> 
> Then from another module I am doing:
> (require s10/arch-choice)
> 
> (define-runtime-module-path-index backend-path
>   (build-path (get-configured-backend-path) "name.rkt"))
> 
> However the problem here is that get-configured-backend-path does not
> exist in level0 - only in level1.
> 
> I tried to provide it then like so:
> (provide get-configured-backend-path
>  (for-syntax get-configured-backend-path))
> 
> and then require it for syntax as well in the driver module, however
> this generates the strange:
> s10/arch-choice.rkt:7:21: provide: provided identifier is not defined or
> required
> 
> How can get get-configured-backend-path to exist at both level which
> seems to be what define-runtime-module-path-index requires?
> 
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Distributing application with run-time configuration

['Paulo Matos' via Racket Users]

On 12/09/2018 16:37, Matthew Flatt wrote:
> As you
> say, you could have a macro expand to the result of `(getenv "ARCH")`
> to pin it down at compile time, but you'll need to import that macro
> into two phases, since the right-hand side of
> `define-runtime-module-path-index` is implicitly used at two phases. 

Thanks for your thorough explanation of the issues. That clarified it
completely.

I have got it to working and realised that actually a compile time
configuration is more future-proof in case I end up developing a private
backend for a customer which I should ship to another customer by
mistake, therefore embedding a single backend per release is better.

I setup a file which does this to choose the backend at compile-time:
#lang racket/base
;;
---

(require (for-syntax racket/base))

(provide get-configured-backend-path)

;;
---
;; This module is used to move the compile time variable s10arch, read
from the environment
;; to a build-time variable using a macro.

(begin-for-syntax
  ;; An environment variable must be defined selecting the arch to use.
  (define s10arch (getenv "S10ARCH"))

  (unless s10arch
(raise-user-error 'driver "Please define S10ARCH environment
variable")))

(define-syntax (get-configured-backend-path stx)
  (syntax-case stx ()
[(_) (datum->syntax stx s10arch)]))


Then from another module I am doing:
(require s10/arch-choice)

(define-runtime-module-path-index backend-path
  (build-path (get-configured-backend-path) "name.rkt"))

However the problem here is that get-configured-backend-path does not
exist in level0 - only in level1.

I tried to provide it then like so:
(provide get-configured-backend-path
 (for-syntax get-configured-backend-path))

and then require it for syntax as well in the driver module, however
this generates the strange:
s10/arch-choice.rkt:7:21: provide: provided identifier is not defined or
required

How can get get-configured-backend-path to exist at both level which
seems to be what define-runtime-module-path-index requires?


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Distributing application with run-time configuration

['Paulo Matos' via Racket Users]

Hi,

I am trying to create racket distribution for my application, except I
am tripping on my first few steps - that of generating the binary.

First, the architecture of the application. There is a driver program
that is configured with a backend at run-time (although one can argue
this should be a compile time configuration - happy to change that).

The configuration that matches the driver to the backend is an
environment relative path - which is then used to dynamic-require the
backend.

The tree looks like:

`|- info.rkt
 |- driver.rkt
 |- build.rkt
 |
 `-archs
   |- intel
   |  `- name.rkt
   `- arm
  `- name.rkt

info.rkt:
#lang info

(define collection 'multi)
;


driver.rkt:

#lang racket

(unless (getenv "ARCH")
  (raise-user-error 'driver "Please define ARCH with suitable path"))

(define arch-path (getenv "ARCH"))
(define arch-name-path
  (build-path arch-path "name.rkt"))

(module+ main

  (define arch-proc
(dynamic-require arch-name-path
 'get-arch))
  (printf "loading arch ~a~n" (arch-proc)))
;

archs/intel/name.rkt

#lang racket

(provide get-arch)

(define (get-arch)
  (if (fixnum? (expt 2 32))
  'x86_64
  'i386))
;

archs/arm/name.rkt


#lang racket

(provide get-arch)

;; Support for 32bits arm only
(define (get-arch)
  'arm32)


So far so good.
$ raco pkg install --link --auto
$ ARCH=archs/intel racket driver.rkt
loading arch x86_64
$ ARCH=archs/arm racket driver.rkt
loading arch arm32

Not, I try to create an executable using raco exe:
$ mkdir bin
$ raco exe ++lib archs/intel/name.rkt ++lib archs/arm/name.rkt -o
bin/r-prog driver.rkt
$ ARCH=archs/intel bin/r-prog
loading arch x86_64
$ cd bin
$ ARCH=archs/intel ./r-prog
open-input-file: cannot open module file
  module path: /home/pmatos/tmp/racket-distro/bin/archs/intel/name.rkt

This doesn't work but it's understandable. However, if only I could
replicate this behaviour in a build script using
create-embedding-executable:

build.rkt:

#lang racket

(require compiler/embed)

(create-embedding-executable
 "prog"
 #:verbose? #t
 #:modules (list (list #f '(file "driver.rkt"))
 (list #f '(file "archs/intel/name.rkt"))
 (list #f '(file "archs/arm/name.rkt")))
 #:configure-via-first-module? #t
 #:literal-expression
 (parameterize ([current-namespace (make-base-namespace)])
   (compile
`(begin
   (namespace-require ''driver
 #:cmdline (list "-U" "--"))

(make-directory* "bin")
(delete-directory/files "bin/prog" #:must-exist? #f)
(copy-directory/files "prog" "bin/prog")
(delete-directory/files "prog")


$ ARCH=archs/intel bin/prog

This finishes successfully and returns nothing which makes me think that
nothing is being executed. This is slightly different from the error I
initially had but I am quite lost with the inner workings of
create-embedding-executable and am using examples online to guide me
which are few and don't really deal exactly with the kind of program I
am trying to compile.

At this point I have a few questions:
1. It is still not clear what the first element in each sublist in
#:modules exactly represents. I understand that it is related to a
module prefix but I don't understand how any value besides #f is useful.
The example in the docs has #f so I used that. Can someone clarify the
usefulness of having a prefix or #t?
2. All examples I have seen create a new namespace in literal-expression
and then use namespace-require. Why can't I just do (require ...) in the
literal-expression?
3. I will have some problems once I got the basics to work with paths. I
assume the solution is define-runtime-path.

I tried
(define-runtime-path arch-path (getenv "ARCH"))

but this will, I think, evaluate the value at both compile time and
runtime which means I will potentially get two different values for
arch-path depending if I am compiling or executing. This also means I am
moving the backend configuration to compile time which is ok but how can
I get the variable at compile time, and then cache that for use at runtime?

I tried
(define-for-syntax foo (getenv "FOO"))
(define-runtime-path p (build-path foo "name.rkt"))

but this will tell me foo is not available at runtime, so I sort of need
to move the compile-time value to runtime. Maybe I am over-complicating
this though so I am happy to hear some comments on this.

Kind regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Let's organize a Scheme European Event at FOSDEM 2019

['Paulo Matos' via Racket Users]

Hi Amirouche,

A scheme european event would be a great idea. Jesse is trying to get
something together for 2019 - although Racket specific afaik.

Still, I have to give my 2 cents on FOSDEM. I think it's pretty bad.
I have been super-frustrated for two consecutive years and gave up on
it. The problem with it is that year after year it has more people. It's
over-crowded.

You spend at least an hour queueing for lunch or for a coffee for
example. The worst is the that the rooms get full super quickly and you
end up with a sign on the door saying: "Room is full, join us through
the live stream." - Hey, if I wanted to live stream, I would have stayed
home.

The problem is that there are so many people some will just sit in a
room, on their laptops, waiting to hear something interesting. This
happened to me over and over again this year. I swore I wouldn't go to
FOSDEM anymore.

I super-support an idea of an european gathering of schemers but if it's
at FOSDEM, I will probably stay home and live stream.

Good luck,

Paulo Matos

On 24/08/2018 18:59, amz3 wrote:
> Hello /Racketeers,/
> 
> Let's organize a Scheme event at FOSDEM 2019 in Bruxelles.
> 
> I started a page on the wiki @ http://community.schemewiki.org/?FOSDEM2019
> 
> You can edit the wiki page. The goal of that page is to gather enough
> talk ideas to be able to submit a proposal for a developer room at
> FOSDEM. See the CFP
> https://fosdem.org/2019/news/2018-08-10-call-for-participation/
> 
> 
> Best regards,
> 
> 
> Amirouche aka. amz3
> 
> -- 
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Confused by the behavior of hash->list

['Paulo Matos' via Racket Users]

On 17/08/18 18:18, Jussi Salmela wrote:
> Hi all!
> 
> (I'm on 7.0)
> Just to jump right to the point here are the hash example lines from the User 
> Guide and a few added lines with comments that should make it clear what I am 
> confused about:
> 
> (define ht (make-hash))
> (hash-set! ht "apple" '(red round))
> (hash-set! ht "banana" '(yellow long))
> (writeln ht)
> (writeln (list? (hash-ref ht "apple")))
> ;; This is how I assumed hash->list to behave:
> (writeln (for/list ([key (hash-keys ht)])
>(list key (hash-ref ht key
> ;; This is how it behaves:
> (writeln (hash->list ht))
> 
> 
> This is the output I get:
> 
> #hash(("banana" . (yellow long)) ("apple" . (red round)))
> #t
> (("apple" (red round)) ("banana" (yellow long)))
> (("banana" yellow long) ("apple" red round))
> 
> So I'm confused why the list is "flattened" by hash->list. I can manage the 
> situation using for/list, I'm just wondering.
> 

Hi,

The list is not flattened, it's just not showing as much detail as you
would probably like.

>From the docs of hash->list the result type is (listof (cons/c any/c any/c))

This is an association list, so the result is:
(("banana" . (yellow long)) ("apple" . (red round)))

except that racket shows them as lists, and it looks like:
(("banana" yellow long) ("apple" red round))

This is the counterpart of hash constructors which get an assoc list as
argument.

> Thanks,
> Jussi
> 

Kind regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Interaction between define/private and keyword arguments

['Paulo Matos' via Racket Users]

I understand, I would have preferred something more explicit, like using define 
for fields as it is but then instead of using define again for methods, with 
possibly public or private annotations to have something like 
define-method/public and define-method/private.

It feels to me that allowing this 
(define (f x) 2)
To be a field and then with
(public f)

Transforming it into a method makes it slightly more confusing. 

On 16 August 2018 20:56:24 CEST, Robby Findler  
wrote:
>That probably would have been better but we opted to reuse the
>definition
>of the define macro. Too clever by half (maybe).
>
>Robby
>
>On Thu, Aug 16, 2018 at 1:40 PM 'Paulo Matos' via Racket Users <
>racket-users@googlegroups.com> wrote:
>
>>
>>
>> On 16/08/18 19:42, Robby Findler wrote:
>> > Yes, this looks like a bug. I see something went wrong between
>> > versions 6.6 and 6.7.
>> >
>>
>> Thanks, opened #2232.
>>
>>
>> > As for `define` vs `define/private`, they are not the same. In the
>> > `define` case, storage is allocated in the object (since it is a
>> > field, bound to a procedure) and in the `define/private` case, it
>> > isn't (since it is a method).
>> >
>>
>> That, of course, makes total sense after you said it. I however,
>thought
>> that something like:
>> (define f 2)
>> would define a private field and
>> (define (f x) 2)
>> would define a private method, but what I didn't realise is that at
>the
>> implementation level, there must be a way to identify a field which
>is a
>> lambda and a method because one is part of the object and the other
>part
>> of the class.
>>
>> Thanks!
>>
>> > Robby
>> >
>> > On Thu, Aug 16, 2018 at 12:37 PM 'Paulo Matos' via Racket Users
>> >  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I spent a whole day trying to find and then reduce an issue I was
>having
>> >> with my software. A procedure, suddenly, was just not being
>called. It
>> >> was as if the call was just gone - pufft. Nothing I did helped.
>> >>
>> >> I was confused - but after a day I managed to reproduce this with
>a
>> >> ridiculously simple case and it looks like it might be a bug.
>> >>
>> >> Run:
>> >>
>> >> #lang racket
>> >>
>> >> (define myc%
>> >>   (class object%
>> >> (super-new)
>> >>
>> >> (define/public (foo x #:arg (k 0))
>> >>   (printf "foo~n")
>> >>   (foo* x #:arg k))
>> >>
>> >> (define/private (foo* y #:arg k)
>> >>   (printf "foo*~n")
>> >>   (bar y (add1 y) (* y 2)))
>> >>
>> >> (define/private (bar x y z)
>> >>   (printf "~a ~a ~a~n" x y z
>> >>
>> >> (define c (new myc%))
>> >> (send c foo 2)
>> >>
>> >>
>> >> That works just fine, right? It prints '2 3 4'
>> >>
>> >> Now try changing the foo* definition to using define/private as
>in:
>> >> (define/private (foo* y #:arg k) ...)
>> >>
>> >> Nothing... The call enters foo* though but bar is never called!
>> >> If instead you do just:
>> >> (define (foo* ...) ...)
>> >>
>> >> it works again! For me this is the most horrible realization
>because I
>> >> always assumed
>> >> (define (foo ...) ...) was the same as (define/private (foo ...)
>...)
>> >>
>> >> First, is this not the case?
>> >> Second, is this a bug? Why does this happen? Shall an issue be
>opened?
>> >>
>> >> Kind regards,
>> >>
>> >> --
>> >> 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.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>>
>> --
>> 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.
>> 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.
>For more options, visit https://groups.google.com/d/optout.

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Interaction between define/private and keyword arguments

['Paulo Matos' via Racket Users]

On 16/08/18 19:42, Robby Findler wrote:
> Yes, this looks like a bug. I see something went wrong between
> versions 6.6 and 6.7.
> 

Thanks, opened #2232.


> As for `define` vs `define/private`, they are not the same. In the
> `define` case, storage is allocated in the object (since it is a
> field, bound to a procedure) and in the `define/private` case, it
> isn't (since it is a method).
>

That, of course, makes total sense after you said it. I however, thought
that something like:
(define f 2)
would define a private field and
(define (f x) 2)
would define a private method, but what I didn't realise is that at the
implementation level, there must be a way to identify a field which is a
lambda and a method because one is part of the object and the other part
of the class.

Thanks!

> Robby
> 
> On Thu, Aug 16, 2018 at 12:37 PM 'Paulo Matos' via Racket Users
>  wrote:
>>
>> Hi,
>>
>> I spent a whole day trying to find and then reduce an issue I was having
>> with my software. A procedure, suddenly, was just not being called. It
>> was as if the call was just gone - pufft. Nothing I did helped.
>>
>> I was confused - but after a day I managed to reproduce this with a
>> ridiculously simple case and it looks like it might be a bug.
>>
>> Run:
>>
>> #lang racket
>>
>> (define myc%
>>   (class object%
>> (super-new)
>>
>> (define/public (foo x #:arg (k 0))
>>   (printf "foo~n")
>>   (foo* x #:arg k))
>>
>> (define/private (foo* y #:arg k)
>>   (printf "foo*~n")
>>   (bar y (add1 y) (* y 2)))
>>
>> (define/private (bar x y z)
>>   (printf "~a ~a ~a~n" x y z
>>
>> (define c (new myc%))
>> (send c foo 2)
>>
>>
>> That works just fine, right? It prints '2 3 4'
>>
>> Now try changing the foo* definition to using define/private as in:
>> (define/private (foo* y #:arg k) ...)
>>
>> Nothing... The call enters foo* though but bar is never called!
>> If instead you do just:
>> (define (foo* ...) ...)
>>
>> it works again! For me this is the most horrible realization because I
>> always assumed
>> (define (foo ...) ...) was the same as (define/private (foo ...) ...)
>>
>> First, is this not the case?
>> Second, is this a bug? Why does this happen? Shall an issue be opened?
>>
>> Kind regards,
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Interaction between define/private and keyword arguments

['Paulo Matos' via Racket Users]

Hi,

I spent a whole day trying to find and then reduce an issue I was having
with my software. A procedure, suddenly, was just not being called. It
was as if the call was just gone - pufft. Nothing I did helped.

I was confused - but after a day I managed to reproduce this with a
ridiculously simple case and it looks like it might be a bug.

Run:

#lang racket

(define myc%
  (class object%
(super-new)

(define/public (foo x #:arg (k 0))
  (printf "foo~n")
  (foo* x #:arg k))

(define/private (foo* y #:arg k)
  (printf "foo*~n")
  (bar y (add1 y) (* y 2)))

(define/private (bar x y z)
  (printf "~a ~a ~a~n" x y z

(define c (new myc%))
(send c foo 2)


That works just fine, right? It prints '2 3 4'

Now try changing the foo* definition to using define/private as in:
(define/private (foo* y #:arg k) ...)

Nothing... The call enters foo* though but bar is never called!
If instead you do just:
(define (foo* ...) ...)

it works again! For me this is the most horrible realization because I
always assumed
(define (foo ...) ...) was the same as (define/private (foo ...) ...)

First, is this not the case?
Second, is this a bug? Why does this happen? Shall an issue be opened?

Kind regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Question about style

['Paulo Matos' via Racket Users]

On 11/08/18 16:11, Bob Heffernan wrote:
> Dear all,
> 
> I am new to Racket and only slightly less new to scheme & scheme-like
> languages.
> 
> I have noticed myself often doing something like the following:
> 
> (define (foo x)
>   (let* ([y (f x)]
>  [z (g y)]
>  [p (h z)])
> (bar p)))

I really, really don't like nesting and a few years ago adopted the
style of internal defines. It makes for much more readable code:

(define (foo x)
  (define y (f x))
  (define z (g y))
  (define p (h z))

  (bar p))

I avoid nesting, long lines and short names. So I would try to name the
variables appropriatelly. If intermediate variables don't have a
'meaning' such that they can be given proper names, maybe they don't
deserve to be a variable and instead I will compose.

Just my 2 cents.

Paulo Matos

> 
> Which could, of course, be written as
> 
> (define (foo x)
>   (bar (h (g (f x)
> 
> Here's an example from something I was just working on:
> 
> (define (get-data input)
>   (let* ([url-string (construct-url input)]
>  [url (string->url url-string)]
>  [port (get-pure-port url)])
> (read-json port)))
> 
> which, again, could be written as:
> (define (get-data input)
>   (read-json (get-pure-port (string->url (construct-url input)
> 
> My question is: is the way I'm writing things considered to be bad
> style?  It feels like a hangover from more imperative-style programming
> & the inclination to do one thing "per line".  On the other hand, it
> often helps readability.
> 
> It might be, of course, that both versions amount to the same thing
> after the interpreter has been at them.
> 
> Thanks and regards,
> Bob Heffernan
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] C level bit manipulation - Racket Manifesto

['Paulo Matos' via Racket Users]

On 11/08/18 19:41, Sam Tobin-Hochstadt wrote:
> There are basically two differences between the `unsafe-lsb` function
> in Racket and the C one:
>  - the Racket calling convention vs the C calling convention
>  - the instruction used to perform the LSB calculation
> 
> For a variety of reasons Racket's function calling convention is more
> heavyweight than C's, but if that code is inlined into some larger
> function that will go away (as it would in C). The simpler instruction
> used by the C compiler is because the C compiler recognizes that
> pattern of bitwise and, whereas the Racket JIT does the obvious `and`.
> That could of course be fixed in the JIT, although it's not clear how
> much of a win it is.
> 

Is this something that will change with Racket-on-Chez? i.e. Racket will
then use the Chez optimizer to generate machine code?

> More broadly, whether Racket supports "C-level" programming depends on
> what you mean. If it means "can I use the same APIs and access the
> same bits I would in C", then you certainly can, although often you
> need to use the FFI to do so. That's what the Racket Manifesto means.

Understood, that's what I wanted to know.

> If it means "can I generate the same assembly instructions or get the
> same maximum performance from pure Racket code as from C code", then
> it isn't true, and you'll need to use some other tools, such as
> generating code yourself (see https://github.com/rjnw/sham for an
> example).
> 

Wow,didn't know about sham. Thanks for the reference.

> Sam
> 
> On Sat, Aug 11, 2018 at 4:15 AM, 'Paulo Matos' via Racket Users
>  wrote:
>> Hi,
>>
>> In http://felleisen.org/matthias/manifesto/, you can read:
>> "In support, Racket offers protection mechanisms to implement a full
>> language spectrum, from C-level bit manipulation to soundly typed
>> extensions."
>>
>> What are we talking about here when we mention C-level bit manipulation? Is
>> this referring to the ffi or some other Racket feature that allows me to
>> generate unsafe bit manipulation instructions?
>>
>> In C, for a bitwise_and of an integer x and 0xff, I get:
>> https://godbolt.org/g/gy3ZN9
>> bitwise_and:
>>   movzx eax, dil
>>   ret
>>
>> In Racket, I tried:
>> #lang racket
>>
>> (require disassemble
>>  racket/unsafe/ops)
>>
>> (define (lsb x)
>>   (bitwise-and x #xff))
>>
>> (disassemble lsb)
>>
>>0: 488b4808   (mov rcx (mem64+ rax #x8))
>>4: 48898bf8ff (mov (mem64+ rbx #x-8) rcx)
>>b: 488b4810   (mov rcx (mem64+ rax #x10))
>>f: 48898bf0ff (mov (mem64+ rbx #x-10) rcx)
>>   16: 4881c3f0ff (add rbx #xfff0)
>>   1d: 488b13 (mov rdx (mem64+ rbx))
>>   20: 488b5230   (mov rdx (mem64+ rdx #x30))
>>   24: 488b4208   (mov rax (mem64+ rdx #x8))
>>   28: 488983f8ff (mov (mem64+ rbx #x-8) rax)
>>   2f: 48b8a80e484c   (mov rax #x4c480ea8)
>>   39: 488b00 (mov rax (mem64+ rax))
>>   3c: 488983f0ff (mov (mem64+ rbx #x-10) rax)
>>   43: 4881c3f0ff (add rbx #xfff0)
>>   4a: 488b4308   (mov rax (mem64+ rbx #x8))
>>   4e: f6c001 (test al #x1)
>>   51: 0f850f00   (jnz (+ rip #xf))
>>   57: 66833831   (cmp (mem16+ rax) #x31)
>>   5b: 0f850500   (jnz (+ rip #x5))
>>   61: e81e771fb4 (call (+ rip #x-4be088e2))
>>   66: e8bb751fb4 (call (+ rip #x-4be08a45))
>>   6b: 488b4320   (mov rax (mem64+ rbx #x20))
>>   6f: 4883c310   (add rbx #x10)
>>   73: f6c001 (test al #x1)
>>   76: 0f851400   (jnz (+ rip #x14))
>>   7c: ba60fba070 (mov edx #x70a0fb60)
>>   81: b9ff01 (mov ecx #x1ff)
>>   86: e86e001fb4 (call (+ rip #x-4be0ff92))
>>   8b: e90700 (jmp (+ rip #x7))
>>   90: 4881e0ff01 (and rax #x1ff)
>>   97: 4c8b75c8   (mov r14 (mem64+ rbp #x-38))
>>   9b: 4883c428   (add rsp #x28

[racket-users] C level bit manipulation - Racket Manifesto

['Paulo Matos' via Racket Users]

Hi,

In http://felleisen.org/matthias/manifesto/, you can read:
"In support, Racket offers protection mechanisms to implement a full 
language spectrum, from C-level bit manipulation to soundly typed 
extensions."


What are we talking about here when we mention C-level bit manipulation? 
Is this referring to the ffi or some other Racket feature that allows me 
to generate unsafe bit manipulation instructions?


In C, for a bitwise_and of an integer x and 0xff, I get: 
https://godbolt.org/g/gy3ZN9

bitwise_and:
  movzx eax, dil
  ret

In Racket, I tried:
#lang racket

(require disassemble
 racket/unsafe/ops)

(define (lsb x)
  (bitwise-and x #xff))

(disassemble lsb)

   0: 488b4808   (mov rcx (mem64+ rax #x8))
   4: 48898bf8ff (mov (mem64+ rbx #x-8) rcx)
   b: 488b4810   (mov rcx (mem64+ rax #x10))
   f: 48898bf0ff (mov (mem64+ rbx #x-10) rcx)
  16: 4881c3f0ff (add rbx #xfff0)
  1d: 488b13 (mov rdx (mem64+ rbx))
  20: 488b5230   (mov rdx (mem64+ rdx #x30))
  24: 488b4208   (mov rax (mem64+ rdx #x8))
  28: 488983f8ff (mov (mem64+ rbx #x-8) rax)
  2f: 48b8a80e484c   (mov rax #x4c480ea8)
  39: 488b00 (mov rax (mem64+ rax))
  3c: 488983f0ff (mov (mem64+ rbx #x-10) rax)
  43: 4881c3f0ff (add rbx #xfff0)
  4a: 488b4308   (mov rax (mem64+ rbx #x8))
  4e: f6c001 (test al #x1)
  51: 0f850f00   (jnz (+ rip #xf))
  57: 66833831   (cmp (mem16+ rax) #x31)
  5b: 0f850500   (jnz (+ rip #x5))
  61: e81e771fb4 (call (+ rip #x-4be088e2))
  66: e8bb751fb4 (call (+ rip #x-4be08a45))
  6b: 488b4320   (mov rax (mem64+ rbx #x20))
  6f: 4883c310   (add rbx #x10)
  73: f6c001 (test al #x1)
  76: 0f851400   (jnz (+ rip #x14))
  7c: ba60fba070 (mov edx #x70a0fb60)
  81: b9ff01 (mov ecx #x1ff)
  86: e86e001fb4 (call (+ rip #x-4be0ff92))
  8b: e90700 (jmp (+ rip #x7))
  90: 4881e0ff01 (and rax #x1ff)
  97: 4c8b75c8   (mov r14 (mem64+ rbp #x-38))
  9b: 4883c428   (add rsp #x28)
  9f: 5f (pop rdi)
  a0: 5e (pop rsi)
  a1: 5b (pop rbx)
  a2: 5d (pop rbp)
  a3: c3 (ret)

(define (unsafe-lsb x)
  (unsafe-fxand x #xff))

(disassemble unsafe-lsb)

   0: 488983f8ff (mov (mem64+ rbx #x-8) rax)
   7: 4881c3f8ff (add rbx #xfff8)
   e: 488b4308   (mov rax (mem64+ rbx #x8))
  12: 4881e0ff01 (and rax #x1ff)
  19: 4c8b75c8   (mov r14 (mem64+ rbp #x-38))
  1d: 4883c428   (add rsp #x28)
  21: 5f (pop rdi)
  22: 5e (pop rsi)
  23: 5b (pop rbx)
  24: 5d (pop rbp)
  25: c3 (ret)

This returns two assembly listings and as expected the unsafe-lsb is 
shorter than the one for lsb but not even close to the one you'd get in 
C. Is there something else in Racket that I might be missing that it 
gives me access to the low level C bit manip constructs besides ffi?


Kind regards,

--
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] S10 - a new commercial product in Racket

['Paulo Matos' via Racket Users]

Hi all,

I was discussing this in racket-money and someone suggested I should
quickly reference it here.

S10 (https://linki.tools/s10) is a superoptimization framework in Racket.

If you are familiar with Mangpo's work on Greenthumb you know what I am
talking about. This work follows a similar pattern but builds a
commercial product on top of the Racket ecosystem.

A bit of background:

At Linki Tools (https://linki.tools) we have been interested in
development tools consultancy and for a few years now we have been
developing compiler optimizations and backends for GCC and LLVM, as well
as testing and verification frameworks for compiler technology.

Throughout my time in this market I have seen a few places where the
existence of a superoptimizer would have been welcomed however, there
was nothing available that could be easily retargetable to other
architectures (usually clients have their own internal cpu archs that
are not publicly available). I found Greenthumb back in 2016 and
contacted Mangpo back then, however after some careful study of the code
and some upstream patches I started heavily changing the code, to the
point where incremental upstream patches became unfeasible.

I ended up rewriting most of Greenthumb and adding many other features
expected by clients of a commercial product like straightforward
profiling and debugging, better error messages, distributed execution, a
plugin framework for internals extension, etc. Because of this S10
stopped working with the backends developed for Greenthumb and I decided
to target instead as a proof of concept RISC-V architectures rv32i,
rv64i, rv128i. This led me to present this work last week in Barcelona
in the RISC-V Workshop.

A lot of things remain to be done but I didn't want to let the
opportunity pass to thank everyone who is part of the Racket community
and made this possible. Thank you for the amazing Racket ecosystem.

Kind regards,
-- 
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.
For more options, visit https://groups.google.com/d/optout.