Re: [racket-users] Match value of symbol vs. binding to it

[Brian Adkins]

On Tuesday, August 18, 2015 at 1:24:38 AM UTC-4, Alex Knauth wrote:
 On Aug 18, 2015, at 1:18 AM, Brian Adkins lojicdot...@gmail.com wrote:
 
  On Tuesday, August 18, 2015 at 1:13:16 AM UTC-4, Alex Knauth wrote:
  Is == what you're looking for?
  Or do you want a version of == that uses string=? ?
  
  I'm not sure what you're suggesting. I basically want a way to inject the 
  value of x into the pattern vs. using a literal such as abc since I need 
  to do this programmatically. The #:when clause and/or the ? function are 
  reasonable work arounds - I'm just hoping there's a more concise way to get 
  the value of x into the pattern.
 
 I mean like this:
 #lang racket
 (define x abc)
 (match '(1 abc)
   [(list 1 (== x)) #t]
   [_ #f])

Ah! Yes, that works. I did scroll down quite a bit in the match documentation, 
but apparently stopped before secion 9.3 I think that's exactly what I was 
looking for - thanks!

-- 
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] Match value of symbol vs. binding to it

[Brian Adkins]

Consider the following:

(define x abc)
(match '(1 abc)
  [ (list 1 y) #:when (string=? y x) #t ]
  [ _ #f ])

Is there a way to accomplish the same thing more concisely by interpolating the 
value of x into the pattern? For example (non-working syntax):

(define x abc)
(match '(1 abc)
  [ (list 1 ~x) #t ]
  [ _ #f ])

This also works, but seems overly verbose:

(define x abc)
(match '(1 abc)
  [ (list 1 (? (λ (v) (string=? v x #t ]
  [ _ #f ])

I tried a few quasipatterns, but got nowhere.

Thanks,
Brian

-- 
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] Match value of symbol vs. binding to it

[Brian Adkins]

On Tuesday, August 18, 2015 at 1:13:16 AM UTC-4, Alex Knauth wrote:
 Is == what you're looking for?
 Or do you want a version of == that uses string=? ?

I'm not sure what you're suggesting. I basically want a way to inject the value 
of x into the pattern vs. using a literal such as abc since I need to do this 
programmatically. The #:when clause and/or the ? function are reasonable work 
arounds - I'm just hoping there's a more concise way to get the value of x into 
the pattern.

 On Aug 18, 2015, at 12:55 AM, Brian Adkins lojicdot...@gmail.com wrote:
 
  Consider the following:
  
  (define x abc)
  (match '(1 abc)
   [ (list 1 y) #:when (string=? y x) #t ]
   [ _ #f ])
  
  Is there a way to accomplish the same thing more concisely by interpolating 
  the value of x into the pattern? For example (non-working syntax):
  
  (define x abc)
  (match '(1 abc)
   [ (list 1 ~x) #t ]
   [ _ #f ])
  
  This also works, but seems overly verbose:
  
  (define x abc)
  (match '(1 abc)
   [ (list 1 (? (λ (v) (string=? v x #t ]
   [ _ #f ])
  
  I tried a few quasipatterns, but got nowhere.
  
  Thanks,
  Brian
  
  -- 
  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.

[racket-users] Re: Building on Raspberry Pi - parallel build possible?

[Brian Adkins]

On Saturday, August 15, 2015 at 9:37:21 AM UTC-4, Brian Adkins wrote:
 I received a Raspberry Pi 2 Model B yesterday, so naturally I wanted to get 
 Racket on it as soon as possible :)
 
 I read somewhere that Unix Source + Built Packages was better than Unix 
 Source, but since I've received performance improvements from building Ruby 
 from sources vs. installing a package, I wanted a clean build of Racket, so 
 I chose Unix Source.
 
 After an hour or so, I gave up waiting on the build to complete and figured 
 I'd let it run overnight so it would be done in the morning. Well, it's been 
 building for over 10.5 hours now, and it's on the 
 ...math-doc/math/scribblings/math.scrbl step. No idea what percent complete 
 that is. It's been building math.scrbl for over 30 minutes!
 
 The Raspberry Pi has a 4 core CPU, so it pains me to see it pegged at only 
 25% this whole time. Is it possible to build Racket from Unix Source in 
 parallel to get all 4 cores fired up?

Hmm... I should've read more closely. The packages are in platform independent 
bytecode, so I doubt I'm receiving any benefit from manually building them :(  
Still, I am curious about the possibilities of a parallel build.

-- 
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] Building on Raspberry Pi - parallel build possible?

[Brian Adkins]

On Saturday, August 15, 2015 at 9:54:21 AM UTC-4, Matthew Flatt wrote:
 At Sat, 15 Aug 2015 06:37:21 -0700 (PDT), Brian Adkins wrote:
  The Raspberry Pi has a 4 core CPU, so it pains me to see it pegged at
  only 25% this whole time. Is it possible to build Racket from Unix
  Source in parallel to get all 4 cores fired up?
 
 You can use
 
  make install PLT_SETUP_OPTIONS=-j 4
 
 to build bytecode and documentation with 4 processes.
 
 
 (Parallelism is probably no help when building from the the Unix Source
 + Built Packages distribution, though.)

Good to know - thanks! I decided to nuke the build process, download the source 
w/ prebuilt packages and start over. I take it the reason the -j 4 won't help 
is that it's only for compiling Racket code into bytecode and doesn't affect 
the C compilation.

-- 
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] Building on Raspberry Pi - parallel build possible?

[Brian Adkins]

I received a Raspberry Pi 2 Model B yesterday, so naturally I wanted to get 
Racket on it as soon as possible :)

I read somewhere that Unix Source + Built Packages was better than Unix 
Source, but since I've received performance improvements from building Ruby 
from sources vs. installing a package, I wanted a clean build of Racket, so I 
chose Unix Source.

After an hour or so, I gave up waiting on the build to complete and figured I'd 
let it run overnight so it would be done in the morning. Well, it's been 
building for over 10.5 hours now, and it's on the 
...math-doc/math/scribblings/math.scrbl step. No idea what percent complete 
that is. It's been building math.scrbl for over 30 minutes!

The Raspberry Pi has a 4 core CPU, so it pains me to see it pegged at only 25% 
this whole time. Is it possible to build Racket from Unix Source in parallel to 
get all 4 cores fired up?

-- 
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] Memory tuning of standalone executable?

[Brian Adkins]

I just installed 6.2.1 on a Linux VPS via the Unix Source + Built Packages, 
and the install went smoothly. I created a standalone executable of a simple 
IRC bot I'm putting together via:

raco exe ircbot.rkt

When I run it the vsz=209440 and rss=63396. ~ 64 MB seems a little high to me. 

Are there any arguments I can supply to either raco when creating the exe, or 
to the exe when running it, that might reduce the runtime memory consumption?

In other words, is Racket possibly pre-allocating large chunks of RAM that I 
can limit?

I'll post the source to the ircbot later, but it's really minimal at this point 
- opens a TCP connection to the freenode server and an output file channel for 
some logging, not much going on. I just ran a test with a file that has only 
(sleep 60), and it used about 50 MB RAM.

Thanks,
Brian

-- 
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] Re: Memory tuning of standalone executable?

[Brian Adkins]

On Wednesday, August 12, 2015 at 1:02:00 PM UTC-4, Juan Francisco Cantero 
Hurtado wrote:
 On 08/12/2015 05:24 AM, Brian Adkins wrote:
  I just installed 6.2.1 on a Linux VPS via the Unix Source + Built 
  Packages, and the install went smoothly. I created a standalone executable 
  of a simple IRC bot I'm putting together via:
 
  raco exe ircbot.rkt
 
  When I run it the vsz=209440 and rss=63396. ~ 64 MB seems a little high to 
  me.
 
  Are there any arguments I can supply to either raco when creating the exe, 
  or to the exe when running it, that might reduce the runtime memory 
  consumption?
 
  In other words, is Racket possibly pre-allocating large chunks of RAM that 
  I can limit?
 
  I'll post the source to the ircbot later, but it's really minimal at this 
  point - opens a TCP connection to the freenode server and an output file 
  channel for some logging, not much going on. I just ran a test with a file 
  that has only (sleep 60), and it used about 50 MB RAM.
 
 Change #lang racket to #lang racket/base and import manually each 
 lib used by your code. Also, run raco make yourscript.rkt, it reduces 
 slightly the memory used by racket.
 
 With both changes, I see a reduction of RSS from 47.5 MB to 14.5 MB in 
 your (sleep) example.

Thanks! I ended up with the following for the ircbot:

(require racket/tcp)
(require racket/string)
(require racket/match)
(require racket/format)

DrRacket was super helpful in identifying which packages I needed to require.

Using raco exe ircbot.rkt dropped the numbers down to:

vsz=165428 rss=49588

Using raco make ircbot.rkt followed by racket ircbot.rkt dropped the numbers 
to:

vsz=150256 rss=35484 - still a little portly, but much better :)

-- 
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] Re: Revert to defaults - is *global* !

[Brian Adkins]

On Tuesday, November 3, 2015 at 5:55:58 PM UTC-5, Brian Adkins wrote:
> On Tuesday, November 3, 2015 at 5:46:23 PM UTC-5, Brian Adkins wrote:
> > This is my own fault, but maybe Dr Racket could be made a little clearer. I 
> > had hit -+ a few times to increase the font size, and I wanted to go 
> > back to the default. -0 did not work as expected, then I checked the 
> > menus and didn't find anything. Then I pulled up preferences which opens to 
> > the Fonts "tab".
> > 
> > I noticed it had a "Revert to Defaults" button. As you likely know, that 
> > reverts *all* defaults !!  Not what I expected/wanted. Had I clicked 
> > through to a few other tabs, I would've seen that the "Revert to Defaults" 
> > button was on each tab and would've surmised its global nature.
> > 
> > Maybe "Revert All to Defaults" as the button title, or a warning that it 
> > will revert every single value in preferences?
> > 
> > I take full responsibility, but ouch.
> > 
> > Brian
> 
> I have time machine running on Mac OSX, so I should be able to restore a file 
> to the previous version. Where does Dr Racket store preferences on OSX ? I'm 
> running 6.2.1.
> 
> Thanks,
> Brian

asumu on IRC got me fixed up with find-system-path:

(find-system-path 'pref-file)

I really love how there is always a great answer to the question, "How do I do 
 in Racket?"

-- 
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] Re: Revert to defaults - is *global* !

[Brian Adkins]

On Tuesday, November 3, 2015 at 5:46:23 PM UTC-5, Brian Adkins wrote:
> This is my own fault, but maybe Dr Racket could be made a little clearer. I 
> had hit -+ a few times to increase the font size, and I wanted to go 
> back to the default. -0 did not work as expected, then I checked the 
> menus and didn't find anything. Then I pulled up preferences which opens to 
> the Fonts "tab".
> 
> I noticed it had a "Revert to Defaults" button. As you likely know, that 
> reverts *all* defaults !!  Not what I expected/wanted. Had I clicked through 
> to a few other tabs, I would've seen that the "Revert to Defaults" button was 
> on each tab and would've surmised its global nature.
> 
> Maybe "Revert All to Defaults" as the button title, or a warning that it will 
> revert every single value in preferences?
> 
> I take full responsibility, but ouch.
> 
> Brian

I have time machine running on Mac OSX, so I should be able to restore a file 
to the previous version. Where does Dr Racket store preferences on OSX ? I'm 
running 6.2.1.

Thanks,
Brian

-- 
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] Revert to defaults - is *global* !

[Brian Adkins]

This is my own fault, but maybe Dr Racket could be made a little clearer. I had 
hit -+ a few times to increase the font size, and I wanted to go back to 
the default. -0 did not work as expected, then I checked the menus and 
didn't find anything. Then I pulled up preferences which opens to the Fonts 
"tab".

I noticed it had a "Revert to Defaults" button. As you likely know, that 
reverts *all* defaults !!  Not what I expected/wanted. Had I clicked through to 
a few other tabs, I would've seen that the "Revert to Defaults" button was on 
each tab and would've surmised its global nature.

Maybe "Revert All to Defaults" as the button title, or a warning that it will 
revert every single value in preferences?

I take full responsibility, but ouch.

Brian

-- 
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] (atanh -2) -> +nan.0

[Brian Adkins]

Someone tweeted about The Evolution of Lisp:

http://www.csee.umbc.edu/courses/331/resources/papers/Evolution-of-Lisp.pdf

As I was reading through it, I came across (p. 52) Steele's "acceptance test". 
I was curious how Racket might handle it, so I tried the factorial example, 
which passed, and then the (atanh -2) example which failed with +nan.0

If I instead call: (atanh (number->float-complex -2))  I do get a complex 
result.

I realize Steele's test was for Common Lisp, not Scheme/Racket, but I can see 
how it might be nice to have atanh automatically return a complex number vs. 
+nan.0

I wonder if Common Lisp handles this by simply manually coding *every* relevant 
function to deal with it, or if it's solved more fundamentally in the numerical 
libraries.

Brian

-- 
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] Futures vs. Places for parallelizing a simple game engine

[Brian Adkins]

I'm writing a Reversi/Othello game engine in Racket as a learning exercise. 
Since my macbook pro has 4 cores and 8 hardware threads, I'd like to see what 
sort of speedup I can get by parallelizing it.

I read through chapter 20 of the Racket Guide, and I *think* places may be more 
suitable than futures for this task due to the fact that each compute unit will 
be allocating memory for the next set of moves, etc. 

Does that sound right? I suppose one place per core makes sense. I'm not sure 
if hyperthreading warrants one place per thread.

In this case, I actually don't mind implementing both a futures and a places 
engine to compare since I'm just trying to get better at Racket, but I'm 
curious about the specific limitations of futures.

On a related note, are there any plans for other parallelizing mechanisms in 
the future such as Erlang style processes?

Thanks,
Brian

-- 
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: Futures vs. Places for parallelizing a simple game engine

[Brian Adkins]

On Thursday, September 3, 2015 at 12:27:01 PM UTC-4, Jens Axel Søgaard wrote:
> [...]
> 
> For this task places will be the perfect choice.
> 
> [...] 

Great - thanks for the advice. I'll create a non-parallel version first as a 
baseline, and then a version with places. Once I have some code to share, I'll 
post back here with a github repo.

-- 
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] Re: Futures vs. Places for parallelizing a simple game engine

[Brian Adkins]

On Monday, August 31, 2015 at 1:27:42 PM UTC-4, Brian Adkins wrote:
> I'm writing a Reversi/Othello game engine in Racket as a learning exercise. 
> Since my macbook pro has 4 cores and 8 hardware threads, I'd like to see what 
> sort of speedup I can get by parallelizing it.
> 
> I read through chapter 20 of the Racket Guide, and I *think* places may be 
> more suitable than futures for this task due to the fact that each compute 
> unit will be allocating memory for the next set of moves, etc. 
> 
> Does that sound right?

No opinions on this? For you experienced Racketeers, which approach would you 
choose for maximum speed?

-- 
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-dev] Re: Happy Module Day!

[Brian Adkins]

On Friday, December 11, 2015 at 9:06:16 AM UTC-5, Matthew Flatt wrote:
> Jay's explanation sounds right to me.
> 
> Naturally, we've wanted to move more code out of C for a long time. I
> think the pieces are finally moving into place so that it will really
> start to happen over the next year or so (but it's always difficult to
> predict).
> 
> FWIW, I'm puzzled by the behavior of `find . -name \*.rkt | xargs wc`,
> but using
> 
>  (for/fold ([n 0]) ([f (in-directory)]
> #:when (regexp-match? #rx"[.]rkt$" f))
>(+ n (length (file->lines f
> 
> on the v6.3 source distribution, I get
> 
>  .c:   308,651  (where roughly 10% is a GC that we don't use anymore)
>  .h:54,424
>  .rkt: 823,030

I think maybe an xargs limit is being reached or something - when I scroll up, 
I see another total line is displayed for .rkt, so it's:

779,431
43,544

For a total of 822,975 Racket lines. Sorry for the confusion.

-- 
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: Happy Module Day!

[Brian Adkins]

On Friday, December 11, 2015 at 8:17:39 AM UTC-5, Robby Findler wrote:
> Well, the current "racket" repo is only a small part of what we
> distribute. You might try that same thing on the standard
> distribution.
> 
> Robby

Interesting. When I download the "Unix Source" from racket-lang.org, I get:

.c = 308,651
.h = 54,424
.rkt = 43,544
.scm = 9,340

So 363,075 (87%) C and 52,884 (13%) Racket.

-- 
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] Re: [racket-dev] Re: Happy Module Day!

[Brian Adkins]

On Friday, December 11, 2015 at 8:08:58 AM UTC-5, Jay McCarthy wrote:
> On Fri, Dec 11, 2015 at 7:55 AM, Brian Adkins wrote:
> > Excuse my ignorance of Racket internals & implementation, but I'm curious 
> > about why the module system is implemented in C vs. Racket. Can someone who 
> > is familiar with it provide some insight?
> 
> I'll do my best...

Thanks Jay. 

-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 5:37:12 PM UTC-5, johnbclements wrote:
> > ...  
> > Any thoughts from folks that are FFI'ing from/to Racket and/or using a 
> > second language in the same system as Racket ?
> 
> My “thoughts" are more along the lines of cheerleading. I worked on Hygiene 
> for Rust, and I really want to see Rust succeed. I’ve built a tiny 
> proof-of-concept rust ffi interface that I describe at
> 
> http://www.brinckerhoff.org/blog/2013/03/29/embedding-rust-in-racket/
> 
> … but I can’t really comment on the difficulty of building larger interfaces. 
> I will say this, though: Rust will make you spend time at the front end, 
> satisfying the borrow-checker. The payoff comes later, when you don’t have to 
> debug all of those core dumps.
> 
> John

After going through the entire Rust book online and continuing my benchmark in 
Rust, I have to say, unfortunately, that it's been quite painful compared to 
just about every other language I've learned (which includes Haskell, OCaml, 
Python, Ruby, JavaScript, C/C++, etc.).

I kind of feel like Rust takes some of the work that languages like Racket, 
OCaml, etc. are doing for me and delegates it to my brain instead :(

Although there very well may be a payoff at some point, my hunch is that it may 
come in an app much larger than what I'd want to use it for i.e. I may just not 
be in the target market for Rust presently.

My time would probably have been better spent parallelizing my Racket benchmark 
and possibly dropping into C for the soundex function where I'm confident I can 
minimize memory allocation and other inefficiencies.

Given my time investment thus far, I may struggle on just to get an idea of the 
Rust vs. Racket speed comparison on this specific benchmark, but I'll probably 
time box it to this week before working on the "places" version in Racket.

I certainly appreciate Racket even more after this experience!

-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Friday, November 20, 2015 at 5:40:32 AM UTC-5, Hendrik Boom wrote:
> On Thu, Nov 19, 2015 at 02:01:02PM -0800, Brian Adkins wrote:
> > The more I dig into Racket, the more I like it. It seems like a perfect fit 
> > for both my personality and the type of applications I am, and will be, 
> > writing. For the vast majority of what I need to do, it's a great fit.
> > 
> > I do occasionally encounter a need for raw speed, so I'm looking for a 
> > complement to Racket for those few times when it's not fast enough. I 
> > chatted briefly about this on IRC the other day, but I thought I'd tap into 
> > the collective wisdom on the mailing list.
> > 
> > I'm open to suggestions, but I've tentatively narrowed the list down to 
> > Rust and C. I programmed in C/C++ for about a decade, then Java for a 
> > decade, and most recently in Ruby for a decade, so it's been a while since 
> > I was an expert C hacker, and my recent Ruby experience has lessened my 
> > polyglotness :)
> 
> Consider Gambit and OCaml.
> 
> OCaml is statically typed, and its compiler uses the static typing in 
> its code generation.  Although the stock OCaml interprets byte code, on 
> the x86 and AMD64 traditions the compiler will compile all the way to 
> efficient machine code.
> 
> Gambit is another Scheme dialect (and thus similar somewhat to 
> Gambti).  It normally compiles down to C, and permits you to specify 
> what C code is to be generated for specific user-declared functions.  
> THis might be the language team-up you want.
> 
> -- hendrik

I've actually spent a fair amount of time with OCaml, and I like the language a 
lot (better than Haskell), but for *me* it's kind of in an awkward spot - on 
the one hand, it's not quite as fast as Rust/C (although for a functional 
language, it's really fast), and multi-core requires async (got tired of 
waiting for the multi-core promise of 4.03), and on the other hand, I find 
Racket much more enjoyable, productive and a better fit for the way I think.

I would consider Gambit for a special purpose app that *needed* to compile down 
to C (maybe an embedded platform, robotics, etc. where Racket isn't available), 
but for my general application development, I'm sticking with Racket. I even 
have Racket running on my Raspberry Pi, and I think Linux is becoming more 
available for robotics, so I may be able to skip the whole "C" thing there as 
well.

-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 5:37:12 PM UTC-5, johnbclements wrote:
> > Any thoughts from folks that are FFI'ing from/to Racket and/or using a 
> > second language in the same system as Racket ?
> 
> My “thoughts" are more along the lines of cheerleading. I worked on Hygiene 
> for Rust, and I really want to see Rust succeed. I’ve built a tiny 
> proof-of-concept rust ffi interface that I describe at
> 
> http://www.brinckerhoff.org/blog/2013/03/29/embedding-rust-in-racket/
> 
> … but I can’t really comment on the difficulty of building larger interfaces. 
> I will say this, though: Rust will make you spend time at the front end, 
> satisfying the borrow-checker. The payoff comes later, when you don’t have to 
> debug all of those core dumps.
> 
> John

Thanks John - I came across your blog post soon after I started looking into 
Rust and bookmarked it for future reference. I have experienced needing to 
placate the compiler a bit which is reminiscent of my time with Haskell/OCaml - 
a little more front end loaded than Ruby/Racket.

-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 7:45:45 PM UTC-5, Neil Van Dyke wrote:
> Brian Adkins wrote on 11/19/2015 07:08 PM:
> > The example that provided the initial motivation is extremely simple - 
> > process 45M+ text records with some minor transformations (including 
> > computing a couple soundex values on first/last names). Racket came in at 
> > 2.4x faster than Ruby, but still CPU bound, and it really should be I/O 
> > bound, so I figure I'll process N records in parallel. But I'm really 
> > thinking more generally - I know I'll occasionally encounter these types of 
> > issues.
> 
> BTW, I don't know how much energy you've already put into 
> hand-optimizing the Racket code for that example, but just a general 
> comment for the list...  There are often big gains to be had through 
> hand-optimizing.  For this particular example, if one is seeing lots of 
> GC cost (which could be contributing to CPU-bound), and can't suppress 
> GC for the duration of the run, one might start by focusing on reducing 
> allocations (e.g., by reusing byte strings for read buffer, and maybe 
> even using same buffer for writing after you look at the pipeline).  
> Then, once I/O method is decided, profile and look at the operations and 
> the pipeline (e.g., maybe you find it's a win to have Soundex routines 
> working from zero-copy byte string I/O buffer directly, assuming 
> single-byte chars and handling any non-ASCII/Latin-1 as they go).  In 
> this example, a fast implementation might be somewhat closer to how 
> you'd do it in C than a first-shot Racket implementation is, only it's 
> still easier than C overall, and it works more smoothly with other 
> Racket code than intermixing C and Racket does.
> 
> Neil V.

I did *some* hand optimizing. Here's the code for the soundex and some string 
helper functions I created:

https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0

I fired up the profiler (in error trace mode) and worked on the critical paths. 
string-replace string-trim showed up. I hand rolled non-upcase-alpha and 
remove-zeros because they were faster than string-replace with regexes.

I'm sure more could be done, but I'd be a bit surprised if I can go from 2.4x 
to even 3x the speed of Ruby given the optimizing I've already done.

Brian

-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 6:25:19 PM UTC-5, Matthias Felleisen wrote:
> Brian, 
> 
> -- when you say "raw speed", do you need "Fortran" level speed for numerical 
> algorithms or just "somewhat faster than Racket, almost close to C"? If it's 
> the latter, Rust may work out for you. 

I would say more the latter - less than 2x of C speed.

> -- when you say you need many cores for your computations. That sounds like 
> very-raw speed, not just raw speed. This may call for C after all. 

The example that provided the initial motivation is extremely simple - process 
45M+ text records with some minor transformations (including computing a couple 
soundex values on first/last names). Racket came in at 2.4x faster than Ruby, 
but still CPU bound, and it really should be I/O bound, so I figure I'll 
process N records in parallel. But I'm really thinking more generally - I know 
I'll occasionally encounter these types of issues.

> -- then again, if it is just about trying to exploit the parallelism of your 
> computer when possible, why not use places (or futures) in Racket? Yes, 
> Rust's type system makes this a bit safer. It basically rules out race 
> conditions via its type system. But this one depends on your take of how much 
> you fear race conditions and how familiar you are with a mostly-functional 
> approach of our CML library, which in my experience reduces this danger, too.

Yes, re-implementing the Racket version with places is on my list, and I'll 
compare with the Rust or C multi-threaded version. I was getting ~ 10 MB/s I/O 
on my SSD in Racket, but I should be able to get ~ 70 MB/s, so even using 4 
cores may not be quite enough.

> -- if you opt for Rust, consider the callback problem. My (passive) 
> experience with lots of code that has to set up call backs from C to Rust, is 
> that this area is a bit problematic. I scanned John's blog post and didn't 
> see how he addressed that, though I didn't read his git repo. Perhaps there 
> are some examples there. And yes, in the end it's doable; it just seems to 
> require a lot of fiddling. 

In this specific case, I would probably just create a standalone program in the 
lower level language since it won't need much domain/business logic, so no FFI 
would be involved. In other cases, I'll definitely want to use FFI though, so 
if turns out that C is much better for FFI w/ Racket, that would influence me.

> -- finally, beware of the need to drop from Rust to unsafe Rust -- where the 
> type system just gives up the key innovations that Rust introduces. This is 
> especially noticable for callbacks, but even other code (see John's) tends to 
> include one or the other unsafe block. 
> 
> -- Matthias

Thanks - good things to consider.

-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

The more I dig into Racket, the more I like it. It seems like a perfect fit for 
both my personality and the type of applications I am, and will be, writing. 
For the vast majority of what I need to do, it's a great fit.

I do occasionally encounter a need for raw speed, so I'm looking for a 
complement to Racket for those few times when it's not fast enough. I chatted 
briefly about this on IRC the other day, but I thought I'd tap into the 
collective wisdom on the mailing list.

I'm open to suggestions, but I've tentatively narrowed the list down to Rust 
and C. I programmed in C/C++ for about a decade, then Java for a decade, and 
most recently in Ruby for a decade, so it's been a while since I was an expert 
C hacker, and my recent Ruby experience has lessened my polyglotness :)

If I were to do a *lot* of lower level coding, I think the niceties of Rust 
would win out over C, but I'm planning on doing most of my application coding 
in Racket, and only needing a lower level language for a few speedups, some 
ad-hoc file crunching programs, etc.. I like the memory safety Rust provides 
without giving up too much performance; the standard library seems fairly rich; 
the language features are fairly nice, etc.

Although I think there is a goal to reduce the amount of C code in Racket, I 
expect there will continue to be a fair amount for the foreseeable future, so 
getting my C chops back would allow me to possibly contribute in that area 
eventually (although I'd prefer to contribute Racket code). And there are some 
Schemes that compile down to C which would allow me to use them in some 
challenged environments (e.g. for Robotics, etc.), so renewing my C proficiency 
would be handy.

I think the FFI interaction between Racket & C may be smoother than between 
Rust & C, but that is conjecture.

Multi-core complicates things a bit. The specific program that motivated me to 
consider Rust or C is an easily parallellizeable program to parse & dump a file 
into a different format, and even though I wrote plenty of multi-threaded C 
code in the past, I'm almost positive this would be much more pleasant, and 
less error prone, in Rust. And given current CPU advances, I think multi-core 
is important for getting the most out of code these days.

Ultimately they're not mutually exclusive, but in the near term they are, I 
only have so much time.

Any thoughts from folks that are FFI'ing from/to Racket and/or using a second 
language in the same system as Racket ?

Thanks,
Brian


-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 9:56:01 PM UTC-5, gustavo wrote:
> > I did *some* hand optimizing. Here's the code for the soundex and some 
> > string helper functions I created:
> >
> > https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0
> >
> 
> I'm optimistic and I think that there is still some room for
> micro-optimizations (for example, replace the set!'s, but I didn't try
> yet).

I think the set!'s are what make it faster. Folks proposed various for 
statements which were much more elegant, but they were slower. I usually favor 
elegance over speed, and for the vast majority of my code, 
elegance/readability/etc. are more important, but this code takes hours to run, 
so speeding it up is helpful.

> But more important is:Do you want to preserve the general structure of the 
> code?
> 
> It has many small functions that are nice to write and debug, but each
> one creates an intermediate string. In this algorithm, most of the
> processing is character-by-character. So I think that most of the
> calculations can be merged in a megafunction that avoids most of the
> allocations.

Possibly, but profiling showed that various string functions were on the 
critical path.

> 
> Gustavo

-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 11:08:07 PM UTC-5, Brian Adkins wrote:
> On Thursday, November 19, 2015 at 9:56:01 PM UTC-5, gustavo wrote:
> > > I did *some* hand optimizing. Here's the code for the soundex and some 
> > > string helper functions I created:
> > >
> > > https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0
> > >
> > 
> > I'm optimistic and I think that there is still some room for
> > micro-optimizations (for example, replace the set!'s, but I didn't try
> > yet).
> 
> I think the set!'s are what make it faster. Folks proposed various for 
> statements which were much more elegant, but they were slower. I usually 
> favor elegance over speed, and for the vast majority of my code, 
> elegance/readability/etc. are more important, but this code takes hours to 
> run, so speeding it up is helpful.
> 
> > But more important is:Do you want to preserve the general structure of the 
> > code?
> > 
> > It has many small functions that are nice to write and debug, but each
> > one creates an intermediate string. In this algorithm, most of the
> > processing is character-by-character. So I think that most of the
> > calculations can be merged in a megafunction that avoids most of the
> > allocations.
> 
> Possibly, but profiling showed that various string functions were on the 
> critical path.
> 
> > 
> > Gustavo

FWIW here's some profile output:

https://gist.github.com/lojic/f1ea6371155db861e2cd

and the output from time on one run showing gc time

cpu time: 2908 real time: 2915 gc time: 84

-- 
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] Rust vs. C as a complement to Racket?

[Brian Adkins]

On Thursday, November 19, 2015 at 11:18:16 PM UTC-5, Brian Adkins wrote:
> On Thursday, November 19, 2015 at 11:08:07 PM UTC-5, Brian Adkins wrote:
> > On Thursday, November 19, 2015 at 9:56:01 PM UTC-5, gustavo wrote:
> > > > I did *some* hand optimizing. Here's the code for the soundex and some 
> > > > string helper functions I created:
> > > >
> > > > https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0
> > > >
> > > 
> > > I'm optimistic and I think that there is still some room for
> > > micro-optimizations (for example, replace the set!'s, but I didn't try
> > > yet).
> > 
> > I think the set!'s are what make it faster. Folks proposed various for 
> > statements which were much more elegant, but they were slower. I usually 
> > favor elegance over speed, and for the vast majority of my code, 
> > elegance/readability/etc. are more important, but this code takes hours to 
> > run, so speeding it up is helpful.
> > 
> > > But more important is:Do you want to preserve the general structure of 
> > > the code?
> > > 
> > > It has many small functions that are nice to write and debug, but each
> > > one creates an intermediate string. In this algorithm, most of the
> > > processing is character-by-character. So I think that most of the
> > > calculations can be merged in a megafunction that avoids most of the
> > > allocations.
> > 
> > Possibly, but profiling showed that various string functions were on the 
> > critical path.
> > 
> > > 
> > > Gustavo
> 
> FWIW here's some profile output:
> 
> https://gist.github.com/lojic/f1ea6371155db861e2cd
> 
> and the output from time on one run showing gc time
> 
> cpu time: 2908 real time: 2915 gc time: 84

And for completeness, I added the parser.rkt file to the gist, so all 3 files 
are there now:

https://gist.github.com/lojic/1deba97f2e2eb2fe3fc0

I think I'll code up a multi-threaded Rust or C version and see how the numbers 
compare, and then the Racket version with places.

-- 
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] Anyone attending RacketCon but *not* Strange Loop ?

[Brian Adkins]

On Jun 8, 2016, at 2:20 PM, John Clements <cleme...@brinckerhoff.org> wrote:
> 
> 
>> On Jun 7, 2016, at 1:07 PM, Brian Adkins <lojicdot...@gmail.com> wrote:
>> 
>> Just out of curiosity, is anyone attending RacketCon, but not attending 
>> Strange Loop?
>> 
>> I'm probably in the minority, but there don't seem to be enough compelling 
>> sessions this year for me (although I'd love to hear Matthew's and Andy's 
>> talk), so I'm considering flying in for RacketCon only. Seems a bit odd, but 
>> saving $625 pays for most of the plane ticket, so that's a nice bonus :)
> 
> On the contrary, it appears that most of PLT may in fact be in this category, 
> though perhaps not by choice….
> 
> John

Indeed. It appears they sold out in seven minutes. I say we go rogue next year, 
and in a city nice enough to entice my wife to join me for a getaway :)

-- 
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] Anyone attending RacketCon but *not* Strange Loop ?

[Brian Adkins]

Just out of curiosity, is anyone attending RacketCon, but not attending Strange 
Loop?

I'm probably in the minority, but there don't seem to be enough compelling 
sessions this year for me (although I'd love to hear Matthew's and Andy's 
talk), so I'm considering flying in for RacketCon only. Seems a bit odd, but 
saving $625 pays for most of the plane ticket, so that's a nice bonus :)

Brian Adkins

-- 
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] RacketCon hotel discount?

[Brian Adkins]

I noticed that the 2015 RacketCon had a "RAC" group code for the hotel. I 
already booked my hotel, but it's a changeable/cancelable reservation, so is 
there going to be a group discount for the hotel for this year's conference 
also? If so, what is it, and when is it active?

Brian

-- 
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] Re: Anyone attending RacketCon but *not* Strange Loop ?

[Brian Adkins]

On Tuesday, June 7, 2016 at 4:07:36 PM UTC-4, Brian Adkins wrote:
> Just out of curiosity, is anyone attending RacketCon, but not attending 
> Strange Loop?
> 
> I'm probably in the minority, but there don't seem to be enough compelling 
> sessions this year for me (although I'd love to hear Matthew's and Andy's 
> talk), so I'm considering flying in for RacketCon only. Seems a bit odd, but 
> saving $625 pays for most of the plane ticket, so that's a nice bonus :)
> 
> Brian Adkins

BTW - the Union Station hotel seems to be filling up, so it might be good to 
book a room before tomorrow when Strange Loop registration opens.

-- 
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 performance tips

[Brian Adkins]

On Monday, January 18, 2016 at 10:23:56 AM UTC-5, gustavo wrote:
> I have a few minor stile comments:
> 
> *** I'd replace
>(define backslash 92)
> with
>(define backslash (char->integer #\\))
> to improve legibility.
> And do the same replacement for other magic numbers. After
> optimization, both versions are identical.
> 
> [The only site where this would cause a difference is in code like
> (for ([i (in-range 92)]) ...)
> but you are not using something like this.]
> 
> 
> *** In  few spots, you use `null` as "do nothing in this case", for
> example in line 38. I think it's more idiomatic to use `(void)`.
> 
> *** In line 328, I it possible to do this? Replace
> 
>   ;;[[[
>   ;; 5. Remove all occurrences of AEIOU, except first letter
>   (define len2 (bytes-length str4))
>   (define str5(bytes-append
>(subbytes str4 0 1)
>(bytes-delete-pred
> (if (> len2 1) (subbytes str4 1 len2) #"")
>  (λ (b) ...
>   ;; 6. If first symbol is a digit replace it with letter saved on step 1.
>   (when (byte-numeric? (bytes-ref str5 0))
> (bytes-set! str5 0 first_letter))
>   ;;;]]]
> 
> with this
> 
>   ;;[[[
>   ;; 5. Remove all occurrences of AEIOU, except first letter
>   (define len2 (bytes-length str4))
>   (define str5(bytes-append
>#"?"
>(bytes-delete-pred
> (if (> len2 1) (subbytes str4 1 len2) #"")
>  (λ (b) ...
>   ;; 6. Replace firt symbol with letter saved on step 1.
>   (bytes-set! str5 0 first_letter)
>   ;;;]]]
> 
> or this:
> 
>   ;;[[[
>   ;; 5. Remove all occurrences
>   (define len2 (bytes-length str4))
>   (when (>= len2 1)
> (bytes-set! str4 0 (char->integer #\?))
>   (define str5
>(bytes-delete-pred
>  str4
>  (λ (b) ...
>   ;; 6. Replace firt symbol with letter saved on step 1.
>  (when (>= len2 1)
>(bytes-set! str5 0 first_letter))
>   ;;;]]]
> 
> I hope I'm not missing a corner case. I estimate that with the 200K
> fields this will reduce the time from 2.5s to 2.4s.
> 
> 
> *** I tried a few more changes that avoid allocating intermediate
> bytes, but they are more complex and with 200K rows I estimate that
> the difference in run time would be only 0.02s. If I find something
> bigger, I'll write again.
> 
> Gustavo
> 
> PS: How many "JOHN"s do you have? Have you considered caching the
> soundex of the names. But I'm not sure if this would be faster.
> 
> On Sun, Jan 17, 2016 at 10:13 PM, Brian Adkins wrote:
> > On Sunday, January 17, 2016 at 2:54:39 PM UTC-5, Brian Adkins wrote:
> >> On Sunday, January 17, 2016 at 2:50:19 PM UTC-5, Brian Adkins wrote:
> >> >
> >> > With built-in string-trim, the lowest of three runs was 10293. Using 
> >> > your string-trim the lowest of three runs was 7618, so it reduced the 
> >> > runtime by 26%.
> >>
> >> Although, I probably should've mentioned that I'm not particularly 
> >> interested in unsafe optimizations. I already have a very fast C program 
> >> if I'm willing to risk unsafe behavior, so for Racket, I'd like to retain 
> >> safety.
> >>
> >> Having said that, I'm pretty sure a combination of using Byte Strings and 
> >> manually optimizing string-trim & string-replace (or skipping them in some 
> >> cases) will get under the Ruby time.
> >
> > Yay - success!  :)
> >
> > I changed all strings to byte strings while leaving the style of the code 
> > very similar. It made a significant difference. Of course, I also gained 
> > the benefit if handwritten bytes-split, bytes-replace, bytes-delete, 
> > bytes-trim, etc. which were narrowly defined just for this app.
> >
> > Timings on a 200K line file are now:
> >
> > Ruby = 7.53s
> > Racket = 2.52s  (was 10.3s)
> >
> > The string version of the Racket program was over 4x slower. I'm quite 
> > satisfied with being 3x faster than Ruby with a similar coding style given 
> > this is really in Ruby's sweet spot i.e. text munging.
> >
> > New code is here:
> >
> > https://gist.github.com/lojic/892049e617637903f982
> >
> > I think my next step will be to create a version that uses places. 
> > make-shared-bytes may be useful for that.  I'll report back with timings. I 
> > have a 4 core macbook pro w/ 8 hyperthreads - no idea whether the 
> > hyperthreads are actually useful, but if I can get a 3x speed

Re: [racket-users] Racket performance tips

[Brian Adkins]

On Sunday, January 17, 2016 at 10:09:36 AM UTC-5, Jon Zeppieri wrote:
> Oops: that final else was wrong. If all we encounter in the string is 
> whitespace, the result is the empty string, not the input string, so:
> 
> 
> ;; ===
> 
> (require racket/unsafe/ops)
> 
> 
> (define (string-trim s)
>   (define len (string-length s))
>   
>   (let loop ([i 0])
>     (cond [(unsafe-fx< i len)
>            (cond [(char-whitespace? (unsafe-string-ref s i))
>                   (loop (unsafe-fx+ i 1))]
>                  [else
>                   (let inner ([j (unsafe-fx- len 1)])
>                     (cond [(char-whitespace? (unsafe-string-ref s j))
>                            (inner (unsafe-fx- j 1))]
>                           [else
>                            (substring s i (unsafe-fx+ j 1))]))])]
>             [else
>              ""])))
> ;; ===
> 
> 
> 
> 
> 
> 
> 
> On Sun, Jan 17, 2016 at 1:24 AM, Jon Zeppieri <zepp...@gmail.com> wrote:
> 
> 
> 
> 
> 
> On Sat, Jan 16, 2016 at 11:29 PM, Brian Adkins <lojic...@gmail.com> wrote:
> 
> 
> I'm happy to run experiments and report timings though.
> 
> 
> 
> 
> 
> 
> 
> Since the profile suggests that string-trim is the biggest culprit (followed 
> by fprintf), try using this specialized version of string-trim locally:
> 
> 
> ;; ===
> 
> (require racket/unsafe/ops)
> 
> 
> (define (string-trim s)
>   (define len (string-length s))
>   
>   (let loop ([i 0])
>     (cond [(unsafe-fx< i len)
>            (cond [(char-whitespace? (unsafe-string-ref s i))
>                   (loop (unsafe-fx+ i 1))]
>                  [else
>                   (let inner ([j (unsafe-fx- len 1)])
>                     (cond [(char-whitespace? (unsafe-string-ref s j))
>                            (inner (unsafe-fx- j 1))]
>                           [else
>                            (substring s i (unsafe-fx+ j 1))]))])]
>             [else
>              s])))
> ;; ===
> 
> 
> Instead of fprintf-ing the tabbed values, you might try (displayln 
> (string-join fields "\t")). Of course, that requires building a list of 
> strings, which has its own cost.


With built-in string-trim, the lowest of three runs was 10293. Using your 
string-trim the lowest of three runs was 7618, so it reduced the runtime by 26%.

-- 
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 performance tips

[Brian Adkins]

On Sunday, January 17, 2016 at 2:50:19 PM UTC-5, Brian Adkins wrote:
> 
> With built-in string-trim, the lowest of three runs was 10293. Using your 
> string-trim the lowest of three runs was 7618, so it reduced the runtime by 
> 26%.

Although, I probably should've mentioned that I'm not particularly interested 
in unsafe optimizations. I already have a very fast C program if I'm willing to 
risk unsafe behavior, so for Racket, I'd like to retain safety. 

Having said that, I'm pretty sure a combination of using Byte Strings and 
manually optimizing string-trim & string-replace (or skipping them in some 
cases) will get under the Ruby time.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket performance tips

[Brian Adkins]

On Sunday, January 17, 2016 at 2:54:39 PM UTC-5, Brian Adkins wrote:
> On Sunday, January 17, 2016 at 2:50:19 PM UTC-5, Brian Adkins wrote:
> > 
> > With built-in string-trim, the lowest of three runs was 10293. Using your 
> > string-trim the lowest of three runs was 7618, so it reduced the runtime by 
> > 26%.
> 
> Although, I probably should've mentioned that I'm not particularly interested 
> in unsafe optimizations. I already have a very fast C program if I'm willing 
> to risk unsafe behavior, so for Racket, I'd like to retain safety. 
> 
> Having said that, I'm pretty sure a combination of using Byte Strings and 
> manually optimizing string-trim & string-replace (or skipping them in some 
> cases) will get under the Ruby time.

Yay - success!  :)

I changed all strings to byte strings while leaving the style of the code very 
similar. It made a significant difference. Of course, I also gained the benefit 
if handwritten bytes-split, bytes-replace, bytes-delete, bytes-trim, etc. which 
were narrowly defined just for this app.

Timings on a 200K line file are now:

Ruby = 7.53s
Racket = 2.52s  (was 10.3s)

The string version of the Racket program was over 4x slower. I'm quite 
satisfied with being 3x faster than Ruby with a similar coding style given this 
is really in Ruby's sweet spot i.e. text munging.

New code is here:

https://gist.github.com/lojic/892049e617637903f982

I think my next step will be to create a version that uses places. 
make-shared-bytes may be useful for that.  I'll report back with timings. I 
have a 4 core macbook pro w/ 8 hyperthreads - no idea whether the hyperthreads 
are actually useful, but if I can get a 3x speedup with 4 cores, I'd be pretty 
pleased.

I suppose the following is a reasonable architecture:

1 place for reading the input file and placing a record in a input queue
N places (one per core) to read from the input queue, process and place in an 
output queue
1 place for reading the output queue and writing to either of two output files

-- 
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] Profiling help

[Brian Adkins]

I'm not sure if something changed with 6.3, but I have the output of:

racket -l errortrace -t parser.rkt

in the following gist:

https://gist.githubusercontent.com/lojic/9cd8a3a88ef2e110b9de/raw/79e9892326101333d11987c8e3a3b9df93adc63a/profile%2520output

I'm having trouble understanding the output. For example, I see that [48] ... 
(49.6%)  is probably an area I need to look at, but I can't tell what part of 
my code I should look at from that output. Likewise for the 19.4% reported for 
"for".

Any ideas?

Thanks,
Brian

-- 
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 performance tips

[Brian Adkins]

On Saturday, January 16, 2016 at 11:22:14 PM UTC-5, Alexis King wrote:
> Those programs appear to depend on input files. Is there any way you could 
> provide those inputs or otherwise make the programs self-contained? I might 
> be interested in taking a look at them, but it’s hard to get a feel for 
> what’s going on without being able to run the programs.
> 
> > On Jan 16, 2016, at 19:32, Brian Adkins wrote:
> > 
> > A while ago, I started a thread about whether Rust or C would be a better 
> > complement to Racket. After much more Rust research/coding, I got very 
> > tired of fighting the compiler, so I decided to blow the dust off my C 
> > skills (I haven't done any serious coding in C since 1996), and code up the 
> > app in C.
> > 
> > In about 2.5 hours, I had coded as much of the app in C as had taken many 
> > more hours in Rust and it was about 2.5x faster and *much* easier to 
> > understand. I knew exactly what I wanted to do for maximum performance, but 
> > I found myself constantly fighting Rust. I've concluded that, for me, C is 
> > a better complement.
> > 
> > Anyway, the purpose for this post is to ask for some assistance in getting 
> > the best performance out of my Racket code. After choosing a different 
> > soundex algorithm, I was a little disappointed in the following runtime 
> > numbers for identical functionality:
> > 
> > Racket = 10.3s
> > Ruby = 7.61s
> > C = 0.472s
> > 
> > Those are numbers for parsing 200K records in a fixed width format to 
> > create a postgres bulk input file. The real data contains 45+M records, so 
> > speed is a consideration (e.g. 1.8 min. for C vs. 38.6 min. for Racket)
> > 
> > It's the fact that Racket is currently slower than Ruby which is bugging 
> > me. Despite my rusty (no pun intended) C skills, I was able to hack a 
> > version that does zero heap allocation and is pretty speedy, so I wouldn't 
> > expect Racket to get close to it. On the other hand, I *would* definitely 
> > hope the Racket version can beat the Ruby version.
> > 
> > Here are the programs:
> > 
> > C: https://gist.github.com/lojic/4369d9d57eb775296c92
> > 
> > Ruby: https://gist.github.com/lojic/2b91fde8e6bbb7bab1cd
> > 
> > Racket: https://gist.github.com/lojic/f306104846d516761952
> > 
> > They have identical output (I measured through the first 4M input records), 
> > and they are very similar (same functions, etc.) in style.
> > 
> > Latest profile output from Racket (using open-output-nowhere as suggested 
> > by Vincent):
> > 
> > https://gist.githubusercontent.com/lojic/db6e02d0d9d88e1d5ced/raw/1002b6e6ee14f2c59b067abe6eac0488a3f2dc7a/profile.txt
> > 
> > Earlier today, I had a hacked up Racket version with manual loops, etc., 
> > but then I thought that I really shouldn't have to resort to that to beat 
> > Ruby, so I returned the Racket code to a form that was most similar to 
> > Ruby. For example:
> > 
> > Ruby:
> > 
> >  def self.parse_string line, beg, len
> >line[beg,len].gsub("\\", '').strip
> >  end
> > 
> > Racket:
> > 
> > (define (parse-string line beg end)
> >  (string-trim (string-replace (substring line beg end) "\\" "")))
> > 
> > But I think the Ruby runtime is a little more optimized currently. In 
> > particular, I suspect string-replace vs. gsub, string-trim vs. strip, etc.
> > 
> > The real fun will come when I use a places version of the Racket code, but 
> > I want to get decent linear speed before parallelizing.
> > 
> > Ruby has no JIT, and both Ruby and Racket of C runtimes, so there doesn't 
> > seem to be any fundamental reason why similar code shouldn't perform better 
> > in Racket.
> > 
> > By the way, I compared Racket 6.2.1 with 6.3 and the latter is 10.4% faster 
> > for this app, so that was encouraging.
> > 
> > Any help is greatly appreciated!
> > 
> > Brian
> > 

Unfortunately, the data is criminal records, so there would be a lot of fields 
to anonymize before I could make it public.

I'm happy to run experiments and report timings though.

-- 
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 performance tips

[Brian Adkins]

On Saturday, January 16, 2016 at 11:26:14 PM UTC-5, Neil Van Dyke wrote:
> Your code is very string-ops-heavy, and I would start looking at that.  
> One thing you could do is look for opportunities to construct fewer 
> intermediate strings, including across multiple procedure calls.  You 
> could also look for operations that are expensive, and use 
> less-expensive ones.  If your strings have no multibyte characters, it'd 
> be easier to make it a lot faster with reused bytes I/O buffers and a 
> tons less copying, but you could also try that with multibyte characters 
> (it's harder and slower, though).
> 
> If you get fancy with the optimization, you might end up with a DSL or 
> mini-language for the formats and/or transformation, to simplify the 
> source code while making its behavior more sophisticated.  But maybe you 
> want to focus on a proof-of-concept for the optimizations first, before 
> you go to the work of implementing the DSL.
> 
> BTW, the below comment, from an aborted response to your previous email, 
> doesn't seem to apply to your code, but I'll just note it for the record:
> 
> >
> > Without tracing through the actual code being profiled (not 
> > volunteering!), it's hard to say what the fix is.
> >
> > One little tip, from glancing at "collects/racket/string.rkt"... If 
> > your code happens to be calling `string-trim` with a large number of 
> > different `sep` arguments (different by `eq?`), it looks like it will 
> > be especially slow.  Or if you're calling `string-trim` a huge number 
> > of times with a nonzero number of non-`#f` `sep` arguments, and you're 
> > GCing.  (The implementation assembles regular expressions for non-`#f` 
> > `sep` arguments, and caches them in a weak hash with `eq?` test.)
> 
> BTW, I wouldn't be surprised if `string-trim` could be made faster for 
> the normal case of `sep` being `#f`, though the code doesn't look bad 
> right now.  (The majority of code that people write is not very 
> efficient, and `string-trim` looks better than the norm.) However, it 
> was written in a generalized way, and I don't know if anyone sat down 
> and hand-optimized for the `#f` case specifically. Or, it might have 
> been written a long time ago, and the VM/compiler or strings have 
> changed quite a bit since then, and so the code could benefit from 
> re-hand-optimizing.  (I've done a bunch of that kind of optimizing as a 
> consultant, and it can easily take a few hours for a single procedure, 
> so tends to only happen as-needed.)
> 
> Neil V.

For this app, the data is actually straight ASCII upper case mainframe data :)

Can you elaborate re: "reused bytes I/O buffers "  ?  One of the things I did 
in the C code was to reuse character arrays a lot and never malloc, but I'm 
less familiar with doing similar things in Racket.

I'm not opposed to hand optimizing (the C program was basically one gigantic 
optimization), but to be fair, it seems the same optimizations would need to be 
done to the Ruby code for comparison.

In other words, I have two related, but different goals:

1) I'd like to get to the point of being able to write expressive, "high level" 
code in Racket, in a similar manner as I've been accustomed to with Ruby, but 
with better performance than Ruby. Given Ruby typically trails the pack with 
respect to speed, that doesn't seem unreasonable.

2) I'd also like to get a better idea of practical optimizations that I can use 
with Racket when I need more speed, even if it lessens other aspects of the 
code such as readability, etc. I suppose the string-squeeze function in the 
Racket code is an example of that.

-- 
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] Profiling help

[Brian Adkins]

On Saturday, January 16, 2016 at 9:40:51 PM UTC-5, Vincent St-Amour wrote:
> Brian,
> 
> The Racket profiler is an edge profiler. So in addition to telling you
> which code time is spent in, it's also telling you which callers caused
> which proportion of that time.
> 
> In the case of [48], it's telling you that file output is a significant
> bottleneck, and that it's caused by the code at [2], [38], [39], etc.
> (as well as by recursive calls to `call-with-output-file`).
> 
> As for the `for` ([49]), the loops at [40] and [37] are the main
> culprits.
> 
> Based on that, you could try redirecting output to `open-output-nowhere`
> if you want to profile your computation (as opposed to output), or you
> could try batching your output (fewer, larger `printf`s instead of many
> small ones) to reduce the cost of output.
> 
> Vincent

Thanks. I used open-output-nowhere and got the following profile info:

https://gist.githubusercontent.com/lojic/db6e02d0d9d88e1d5ced/raw/1002b6e6ee14f2c59b067abe6eac0488a3f2dc7a/profile.txt

I was surprised that using open-output-nowhere is actually slower though !!  
Runtime was 13,761ms vs. 10,258ms with real I/O.

I'm going to follow up another thread I started a while back with more 
performance info.

It's definitely a CPU bound app (only able to write about 4 MB/s). Even the C 
version (see other thread shortly) is CPU bound, and it's pushing 90+ MB/s to 
disk. I have an SSD.

-- 
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 performance tips

[Brian Adkins]

On Saturday, January 16, 2016 at 11:54:05 PM UTC-5, Brian Adkins wrote:
> On Saturday, January 16, 2016 at 11:26:14 PM UTC-5, Neil Van Dyke wrote:
> > Your code is very string-ops-heavy, and I would start looking at that.  
> > One thing you could do is look for opportunities to construct fewer 
> > intermediate strings, including across multiple procedure calls.  You 
> > could also look for operations that are expensive, and use 
> > less-expensive ones.  If your strings have no multibyte characters, it'd 
> > be easier to make it a lot faster with reused bytes I/O buffers and a 
> > tons less copying, but you could also try that with multibyte characters 
> > (it's harder and slower, though).
> > 
> > If you get fancy with the optimization, you might end up with a DSL or 
> > mini-language for the formats and/or transformation, to simplify the 
> > source code while making its behavior more sophisticated.  But maybe you 
> > want to focus on a proof-of-concept for the optimizations first, before 
> > you go to the work of implementing the DSL.
> > 
> > BTW, the below comment, from an aborted response to your previous email, 
> > doesn't seem to apply to your code, but I'll just note it for the record:
> > 
> > >
> > > Without tracing through the actual code being profiled (not 
> > > volunteering!), it's hard to say what the fix is.
> > >
> > > One little tip, from glancing at "collects/racket/string.rkt"... If 
> > > your code happens to be calling `string-trim` with a large number of 
> > > different `sep` arguments (different by `eq?`), it looks like it will 
> > > be especially slow.  Or if you're calling `string-trim` a huge number 
> > > of times with a nonzero number of non-`#f` `sep` arguments, and you're 
> > > GCing.  (The implementation assembles regular expressions for non-`#f` 
> > > `sep` arguments, and caches them in a weak hash with `eq?` test.)
> > 
> > BTW, I wouldn't be surprised if `string-trim` could be made faster for 
> > the normal case of `sep` being `#f`, though the code doesn't look bad 
> > right now.  (The majority of code that people write is not very 
> > efficient, and `string-trim` looks better than the norm.) However, it 
> > was written in a generalized way, and I don't know if anyone sat down 
> > and hand-optimized for the `#f` case specifically. Or, it might have 
> > been written a long time ago, and the VM/compiler or strings have 
> > changed quite a bit since then, and so the code could benefit from 
> > re-hand-optimizing.  (I've done a bunch of that kind of optimizing as a 
> > consultant, and it can easily take a few hours for a single procedure, 
> > so tends to only happen as-needed.)
> > 
> > Neil V.
> 
> For this app, the data is actually straight ASCII upper case mainframe data :)
> 
> Can you elaborate re: "reused bytes I/O buffers "  ?  One of the things I did 
> in the C code was to reuse character arrays a lot and never malloc, but I'm 
> less familiar with doing similar things in Racket.
> 
> I'm not opposed to hand optimizing (the C program was basically one gigantic 
> optimization), but to be fair, it seems the same optimizations would need to 
> be done to the Ruby code for comparison.
> 
> In other words, I have two related, but different goals:
> 
> 1) I'd like to get to the point of being able to write expressive, "high 
> level" code in Racket, in a similar manner as I've been accustomed to with 
> Ruby, but with better performance than Ruby. Given Ruby typically trails the 
> pack with respect to speed, that doesn't seem unreasonable.
> 
> 2) I'd also like to get a better idea of practical optimizations that I can 
> use with Racket when I need more speed, even if it lessens other aspects of 
> the code such as readability, etc. I suppose the string-squeeze function in 
> the Racket code is an example of that.

So, maybe replace in-lines with in-bytes-lines on line 31 of 
https://gist.github.com/lojic/f306104846d516761952 and flow Byte Strings 
through the app instead of Strings given the source being ASCII chars ?

-- 
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 performance tips

[Brian Adkins]

On Monday, January 18, 2016 at 11:23:37 AM UTC-5, Brian Adkins wrote:
> [...]
> Thanks. Yes, I have a lot of cleanup to do - I basically hacked this together 
> as fast as I could to experiment.
> 
> I had wondered about caching the soundex values in the past, so I just coded 
> up a version and concluded it's not helpful, but I think part of that is 
> Racket has some efficiency issues with growing hashes.
> 
> For the smaller, 200K line, file, there was some improvement, but as I 
> increased the percentage improvement dropped significantly and approached 
> zero.
> 
> I think the remaining "low hanging fruit" is:
> 
> 1) Reuse byte string buffers and basically manipulate indexes
> 2) Parallelize with places

A couple more notes of interest:

1) I painstakingly created a version that mostly manipulates indexes into byte 
strings so the flow was as follows:
a) a byte string is allocated by "(for ([line-no (in-naturals 1)]"
b) a fixed length byte string is allocated once for an output buffer and reused
c) individual fields were moved from the byte string in (a) directly into the 
buffer in (b) while trimming and deleting embedded backslashes in one operation
d) the buffer was written to the file via write-bytes

All that effort and obfuscation of the code resulted in about 9.5% increase in 
speed. I'm actually glad the speedup wasn't more significant, so I won't be 
tempted to write in that style because it was messy :)

2) Given the heavy use of parse-bytes, I converted the following:

(define (parse-bytes line beg end)
  (bytes-trim (bytes-delete (subbytes line beg end) backslash)))

to this "optimized" hand rolled version that does everything in one pass:

(define (parse-bytes line beg end)
  (define (helper beg end)
(let ([result (make-bytes (- end beg))])
  (let loop ([src beg]
 [dst 0])
(cond [(< src end) (let ([b (bytes-ref line src)])
 (if (= b backslash)
 ;; Skip backslash
 (loop (+ src 1) dst)
 ;; Copy byte to result
 (begin
   (bytes-set! result dst b)
   (loop (+ src 1) (+ dst 1)]
  [else (if (> dst 0)
(subbytes result 0 dst)
#"\\N")]
  (let left ([i beg])
;; Compute i to be the index of the leftmost valid byte
(if (< i end)
(let ([left-byte (bytes-ref line i)])
  (if (or (<= left-byte space)
  (> left-byte max-ascii)
  (= left-byte backslash))
  (left (+ i 1))
  (let right ([j (- end 1)])
;; Compute j to be the index of the rightmost valid byte
(if (>= j i)
(let ([right-byte (bytes-ref line j)])
  (if (or (<= right-byte space)
  (> right-byte max-ascii)
  (= right-byte backslash))
  (right (- j 1))
  (helper i (+ j 1
#"\\N"
#"\\N")))

and the speedup was even less impressive - about 3.5%. I thought that by 
minimizing copying of subbytes multiple times I would gain more, but, again, 
I'm pleased that writing Racket in a more readable/understandable manner 
results in reasonably efficient code.

I'm just about done cleaning up the code, then I'll create a version using 
places and report back with the code and timings and let this thread quiesce :)

-- 
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] Re: High level design for an app using places?

[Brian Adkins]

On Tuesday, January 19, 2016 at 1:13:44 AM UTC-5, Brian Adkins wrote:
> I've finalized the sequential version of my program to convert a large 
> fixed-length field file into two distinct output files (one per table) 
> suitable for bulk import into postgres.
> 
> https://gist.github.com/lojic/413f972bcaf1a6b156e2
> 
> On a single core, the runtime is 5.35x longer than the C program and sustains 
> ~ 15 MB/s file output. So, I'd now like to create a parallel version using 
> places, and I would like some general, high-level design advice from anyone 
> who has been in the trenches with applications using places.
> 
> What organizational structure would you recommend for a program that reads 
> byte string lines from one file, transforms them, and writes them to two 
> output files?
> 
> One option is the following:
> 
> InputFile -> InputPlace -> InputQueue -> N ProcessPlaces -> OutputQueue -> 
> OutputPlace -> [ OutputFile1, OutputFile2 ]
> 
> Another option would be to have N shared byte strings (one per process place) 
> and rotate through them with incoming lines. I'm not sure if they can be 
> synchronized on directly, or not.
> 
> Another option would be to have the input place write lines to the channel of 
> specific process places in a round robin manner.
> 
> I'll also need some mechanism to determine when to write the special last 
> line of each of the two output files.
> 
> I don't mind experimenting with a few approaches, but if I can glean some 
> community wisdom from folks who have been through the trial & error already, 
> that would be great!
> 
> Thanks,
> Brian

Main loop is lines 22 through 59 of parser.rkt in the gist:

https://gist.github.com/lojic/413f972bcaf1a6b156e2

-- 
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] assoc api

[Brian Adkins]

Is there an advantage to having assoc return the associated list vs. the tail 
of the associated list? Wouldn't it be better for it to behave more like 
hash-ref ? Do folks typically just define their own function such as the 
following ?

(define daynums (map list
 '(sunday monday tuesday wednesday thursday friday saturday)
 (range 7)))

(define (aref list key)
  (cadr (assoc key list)))

(aref daynums 'wednesday)  -> 3

Ruby's Array#assoc also returns the entire list, so I suppose this is just a 
historical artifact, but off the top of my head, I can't recall ever wanting 
the entire list since I already have the key I'm searching for.

Brian

-- 
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] Standardizing the threading macro and organizing packages

[Brian Adkins]

On Sunday, January 31, 2016 at 1:05:17 PM UTC-5, Alexis King wrote:
> > On Jan 29, 2016, at 21:55, Brian Adkins wrote:
> > 
> > Was any consensus reached on this? I've been working through some exercises 
> > in Racket that a friend is implementing in Elixir, and I just came across a 
> > "method chaining" situation. I ended up simply writing a wrapper function, 
> > but using a version of ~> would've been nice.
> 
> Yes, actually, there was. The “threading” package was the result, and
> you can find the documentation here[1]. I believe rackjure’s threading
> implementation now also uses this package, so at least some level of
> standardization has been reached.

Awesome! I just tried it out, and it works great:

(define (score word)
  (apply + (~> word
   string-trim
   string-downcase
   string->list
   (map (curry hash-ref points) _

(define (word-count str)
  (~> str
  string-downcase
  (string-split #px"[^a-z]+")
  (foldl (λ (word hsh) (hash-update hsh word add1 0))
 (make-immutable-hash)
 _)))

> If you want Clojure-style threading macros, the threading package is
> probably your best bet. Of course, that might not actually be what you
> want: consider also looking at the different ~> from the point-free
> package, which is actually a higher-order function. When paired with a
> shorthand function package (which didn’t ever get standardized), it can
> be a little more powerful (and just as concise) than a dumb macro.

I'll check this out later.

-- 
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] Re: LaTeX inspired key bindings

[Brian Adkins]

On Thursday, January 28, 2016 at 5:30:57 PM UTC-5, Brian Adkins wrote:
> I'm sure this is a really bad idea, but I couldn't resist after finding 
> section 3.3.8 in the Dr. Racket documentation - what fun :)
> 
> (define (∃ member list)
>   (cond [ (∅? list) ∅ ]
> [ (≡ member (α list)) list ]
> [ else (∃ member (ω list)) ]))
> 
> (∃ 8 '(3 9 8 5))
> 
> Using "alpha" for "car" kind of makes sense, but using "omega" for "cdr" 
> really doesn't - I expect it should return the last element of the list, but 
> I couldn't think of any greek symbol that might mean "tail".
> 
> I have been using Command-\ to insert λ instead of lambda. It's too pretty to 
> resist.
> 
> Brian

I suppose a better idea than actually inserting λ might be to configure Emacs 
(like I already have) to display λ instead of lambda. I haven't quite settled 
on whether to stay in Emacs or in Dr. Racket - I tend to go back and forth 
depending on my needs at the moment.

-- 
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] LaTeX inspired key bindings

[Brian Adkins]

I'm sure this is a really bad idea, but I couldn't resist after finding section 
3.3.8 in the Dr. Racket documentation - what fun :)

(define (∃ member list)
  (cond [ (∅? list) ∅ ]
[ (≡ member (α list)) list ]
[ else (∃ member (ω list)) ]))

(∃ 8 '(3 9 8 5))

Using "alpha" for "car" kind of makes sense, but using "omega" for "cdr" really 
doesn't - I expect it should return the last element of the list, but I 
couldn't think of any greek symbol that might mean "tail".

I have been using Command-\ to insert λ instead of lambda. It's too pretty to 
resist.

Brian

-- 
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] Standardizing the threading macro and organizing packages

[Brian Adkins]

On Wednesday, October 7, 2015 at 11:18:41 PM UTC-4, Sam Tobin-Hochstadt wrote:
> A few thoughts:
> 
> 1. This is a great idea -- one of the reasons that I think Racket has
> avoided lots of little dialects despite syntactic flexibility is
> standardizing the community on one thing. I'm glad you're continuing
> this.
> 
> 2. When we've standardized on this sort of thing in the core, the
> primary way we arranged it is writing things on mailing lists, so I
> hope that works just as well here.
> 
> 3. I agree with Jay's point about `data` and such, but I don't think
> this fits in any existing category. I'm skeptical of a grab-back
> `util` collection, though, so I think just putting this in it's own
> collection makes the most sense. If we eventually have more things
> like this, then we should come up with a category.
> 
> Sam

Was any consensus reached on this? I've been working through some exercises in 
Racket that a friend is implementing in Elixir, and I just came across a 
"method chaining" situation. I ended up simply writing a wrapper function, but 
using a version of ~> would've been nice.

The commit is here:

https://github.com/lojic/exercism-racket/commit/5d2d24c240d7157204c473ea98d2e4990bb9e4ca

Lines 29-34 on the left compared to using a wrapper function in lines 35-39 on 
the right.


> On Wed, Oct 7, 2015 at 11:09 PM, Alexis King  wrote:
> > While in St. Louis, I had a brief conversation with Jay, Alex, and Jack 
> > about how we all happen to have our own implementation of Clojure’s 
> > threading macro. That macro is called -> in Clojure, but I believe Greg’s 
> > rackjure library set the Racket standard of calling it ~>, since the arrow 
> > is already used by contracts and types (and the FFI, too, for that matter). 
> > I have no idea how many implementations of this macro exist in the wild, 
> > but 5 is already far too many.
> >
> > Duplication is an uncomfortably common problem in Lispy circles, but 
> > fragmentation is never a good thing, so I’m interested in trying to create 
> > a standard implementation. It is my understanding that Racket has mostly 
> > avoided this problem by traditionally absorbing common libraries into the 
> > core, but I also understand there’s been a push to reverse this trend by 
> > spinning these things off into packages. I plan to extract my 
> > implementation of ~> and all its associated friends (I have a lot of them) 
> > into their own package, but I’d also like to ask some questions first.
> >
> > First of all, do any people object to this idea in principle? Is this too 
> > trivial of a thing to try and standardize? Assuming that’s not the case, 
> > I’ve been wondering what collection to put these in. Currently, Racket 
> > packages tend to use their own collections, which is even recommended by 
> > the documentation. However, Jay recently brought to my attention that 
> > perhaps this isn’t the best way to organize things: it might be better to 
> > extend existing collections with new modules. For example, he suggested I 
> > move my collections library to data/collection, which would imply that the 
> > lens library should be moved to data/lens. I actually like this idea quite 
> > a bit, especially for packages that are more mature.
> >
> > This prompts the question asking where a set of utility macros actually 
> > belong. They don’t belong in data/, certainly, and they don’t belong in 
> > syntax/, since that collection deals with handling syntax objects 
> > themselves. Would it be good to create a util/ collection and place this in 
> > util/threading? Or would these be better in their own, separate collection?
> >
> > The danger of departing from the one-to-one correlation with package names, 
> > of course, is the possibility of dramatically increasing the potential for 
> > conflicts. Personally, I think that grouping collections logically might be 
> > a good thing, but maybe it isn’t worth the risk? I’m interested in hearing 
> > people’s thoughts.
> >
> > Thanks,
> > Alexis
> >
> > --
> > 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.

Re: [racket-users] Which html-parsing package?

[Brian Adkins]

On Friday, February 19, 2016 at 11:46:17 AM UTC-5, Neil Van Dyke wrote:
> BTW, I now intend to move my packages to the new package system shortly, 
> and I'll then stop supporting the PLaneT ones.
> 
> (There's some urgency to moving now, so I'm going to punt on workarounds 
> for the version-related differences in the new package system, and cut 
> some corners on automation like I had for PLaneT, for now.  I might have 
> to leave in the `mcfly-runtime` package dependency for now, if I don't 
> have time to move to my forthcoming `threedoc` format and tool.)
> 
> Neil V.

Thanks!

-- 
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] Programming language popularity (there's no accounting for taste!)

[Brian Adkins]

I began compiling very crude statistics on programming language popularity back 
in 2009, and just kept doing it periodically. Initially I did it manually, but 
I finally got smart and wrote the following Racket program to scrape the 
results automatically:

https://gist.github.com/lojic/83fff86aeea6af1c31ac

The numbers should clearly be taken lightly, but there is *some* information to 
be had. Here is the latest post:

http://blog.lojic.com/2016/02/24/programming-language-popularity-part-ten/

I am fortunate in being able to choose whatever tool I feel is best, so 
popularity isn't that important to me. Having a critical mass of libraries is, 
but that's another matter.

After a decade of C/C++, followed by a decade of Java, I came across Ruby, and 
it has been my primary development language for the last decade. Ruby was such 
an improvement over Java that it finally dawned on me to make a purposeful 
search to see if I might get an improvement over Ruby that it was over Java.

Thus began a nine year search through Common Lisp, Haskell, Clojure, Standard 
ML, OCaml, Julia, Pony (barely), etc., and Racket has emerged as the clear 
winner for me personally. I'm already as productive in Racket as I am in Ruby 
for a number of things, but I do have a fair amount of work to do before I'm as 
productive in web development as I am with Rails. I'm hoping that 2016 will be 
the year of preparation to allow a complete switch.

Brian

-- 
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] Programming language popularity (there's no accounting for taste!)

[Brian Adkins]

On Wednesday, February 24, 2016 at 12:24:59 PM UTC-5, Vincent St-Amour wrote:
> If we add up the "Racket" and "Scheme" numbers (the latter being, I
> suspect, mostly Racket), the total is pretty close to Ruby. I find that
> amusing. :)
> 
> Actually, I'm curious what the numbers look like if you count "PLT
> Scheme" towards Racket.
> 
> Vincent

In previous blog posts, I included aggregate lines for things like "lisp 
family", "ml family", etc. but skipped it this time out of laziness.

I just ran the Racket program with "PLT Scheme" and got the following:

$ racket pl_popularity.rkt
Path=/search?q=%22written%20in%20PLT%20Scheme%22 Num=4370
Path=/search?q=%22programmed%20in%20PLT%20Scheme%22 Num=2
Path=/search?q=%22developed%20in%20PLT%20Scheme%22 Num=518
Path=/search?q=%22implemented%20in%20PLT%20Scheme%22 Num=2120
(PLT Scheme 7010)

For comparison, here's the Racket data:

Path=/search?q=%22written%20in%20racket%22 Num=6210
Path=/search?q=%22programmed%20in%20racket%22 Num=1520
Path=/search?q=%22developed%20in%20racket%22 Num=5090
Path=/search?q=%22implemented%20in%20racket%22 Num=3330
(racket 16150)

By the way, if anyone runs the program - it's purposefully slow to avoid 
getting banned by Google, so the random wait per query is rather long. I 
thought it was broken because it took so long to get the first results, and I'm 
the author, so I thought I'd pass on that info :)

Brian

-- 
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] Process for providing new functions for the standard library

[Brian Adkins]

What is the process for providing additions to Racket's standard library? Do 
people just submit pull requests, or is there a particular vetting process, to 
determine whether a function is generally useful enough to warrant inclusion in 
the standard library, that should happen first to avoid cluttering the pull 
request queue?

As I get deeper into Racket, I expect I'll occasionally find a function I'm 
used to having in the standard library of another language missing. I can 
easily create my own packages for this sort of thing, but some of them may be 
useful enough to add to Rackets standard library.

In the case of functions from another language's standard library, there is at 
least some filtering that has already happened, but I suppose the barrier to 
inclusion into the standard library varies quite a bit among languages.

Thanks,
Brian

-- 
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] Research Triangle, NC - Lisp & Scheme meetup

[Brian Adkins]

If any of you happen to be in the Triangle area of NC, I created a Lisp & 
Scheme meetup today:

http://www.meetup.com/Triangle-Lisp-Scheme/

I founded TriFunc in 2009 here, but the broad scope & niche interest has always 
been a problem (especially after the Clojure (headquartered in the Triangle) 
folks created their own group :), and now that I'm focused solely on Racket, I 
thought I'd morph it into a group with better focus. After running TriFunc for 
7 years, I'm not expecting a Lisp/Scheme group outside of a large city to be 
very big, but even a handful of lispers getting together can be fun in the 
right venue.

Brian

-- 
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] Re: Programming language popularity (there's no accounting for taste!)

[Brian Adkins]

On Thursday, February 25, 2016 at 8:36:22 AM UTC-5, Robert Herman wrote:
> Cool, Brian!
> 
> I am not able to scroll past the page view. The scroll is bottomed out, but 
> clearly there is more text on your page. I am using Firefox to view.
> 
> Just curious about your experience with pony lang? I always come back to 
> Racket!
> 
> Rob

Strange - works ok in Chrome & Safari on my mac.

Regarding the language you mentioned above, unfortunately, I won't be able to 
discuss it until August 24 due to this silly Racket-focusing bet :)

https://gist.github.com/lojic/99ef37c8bcde418111d4

I found myself too often distracted with shiny, new languages even after 
realizing Racket was perfect for my needs, so I hacked my competitive nature (I 
*hate* to lose bets no matter how small!) to allow me focus solely on Racket :)

-- 
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] Re: Programming language popularity (there's no accounting for taste!)

[Brian Adkins]

On Thursday, February 25, 2016 at 9:02:07 AM UTC-5, Robert Herman wrote:
> On Thursday, February 25, 2016 at 8:49:41 PM UTC+7, Brian Adkins wrote:
> > On Thursday, February 25, 2016 at 8:36:22 AM UTC-5, Robert Herman wrote:
> > > Cool, Brian!
> > > 
> > > I am not able to scroll past the page view. The scroll is bottomed out, 
> > > but clearly there is more text on your page. I am using Firefox to view.
> > > 
> > > Just curious about your experience with pony lang? I always come back to 
> > > Racket!
> > > 
> > > Rob
> > 
> > Strange - works ok in Chrome & Safari on my mac.
> > 
> > Regarding the language you mentioned above, unfortunately, I won't be able 
> > to discuss it until August 24 due to this silly Racket-focusing bet :)
> > 
> > https://gist.github.com/lojic/99ef37c8bcde418111d4
> > 
> > I found myself too often distracted with shiny, new languages even after 
> > realizing Racket was perfect for my needs, so I hacked my competitive 
> > nature (I *hate* to lose bets no matter how small!) to allow me focus 
> > solely on Racket :)
> 
> I hear you. Like I said, I keep coming back to Racket after those 'shiny 
> distractions'.
> I used the inspector in Firefox, and found scrolling=no in the main frame 
> component for some reason. I changed it, and now I can see the rest of your 
> page.
> 
> Do you do web pages with Racket coming from your Ruby background?
> 
> Rob

I've yet to develop web pages with Racket, but I'll be looking into the Racket 
web server soon, and will likely begin development of a new web framework later 
this year. I've been developing for the web for 23 years using a handful of 
languages and frameworks, so I think I now have a pretty good idea of how I 
want things to work, but the proof of the pudding is in the eating, so we shall 
see!

-- 
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] Programming language popularity (there's no accounting for taste!)

[Brian Adkins]

On Wednesday, February 24, 2016 at 2:40:23 PM UTC-5, Robby Findler wrote:
> Scheme is great. Racket isn't Scheme, although it draws a ton of
> inspiration from the language and it's design. Viva Scheme! Viva
> Racket!
> 
> Robby

I agree, but I have mixed emotions. The lisp community is better than most at 
dividing and conquering itself. From an academic perspective, I can see how 
there may be advantages to a proliferation of implementations experimenting 
with varieties of solutions, but from an industry perspective, there appears to 
be a lot of waste and reinvention of wheels.

I do love the Scheme heritage in Racket, and I hope that the essence of Scheme 
remains, but I would selfishly prefer that more developers would rally behind 
Racket and focus on expanding the package ecosystem :)

I'm still a relative newbie, but it appears to me that Racket is the strongest 
of the Scheme-ey lisps, so that's where I'm investing my time.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Places performance & channel capacity

[Brian Adkins]

My initial experiment with places is a bit disappointing:

Sequential version: cpu time: 2084 real time: 2091 gc time: 91

Places version: cpu time: 16895 real time: 3988 gc time: 4244

Using 8x the CPU time seems quite high.

And more importantly, the places version only wrote 128,541 lines to the output 
file vs. the correct number of 198,480 (65%). I suspect the program is ending 
while some of the worker places are still active, but I think that implies that 
if I correctly waited for all activity to finish, the numbers would be even 
worse. Putting a sleep after the main input reading loop gets me all but 5 of 
the records.

My simplistic design was to have the main place read lines from an input file, 
write the lines to the place channels of N workers for processing (in a round 
robin manner using modulo # workers). The workers write the parsed lines to a 
single output place for writing to the output file.

Is it possible to limit the number of messages on a place channel? I suspect 
the input place is moving faster than the workers, so the workers' place 
channels may be getting huge.

Someone mentioned buffered asynchronous channels on IRC since you can set a 
limit, but it appears you can't send them across a place channel, so I'm unsure 
how to make use of them with places.

Sequential & parallel code is here:

https://gist.github.com/lojic/283aa3eec777e4810efc

Relevant lines are lines 44 to 105 of the parallel version.

Are there any projects, papers, etc. of best practices with respect to places 
that I can look at?

Thanks,
Brian

-- 
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] Re: Places performance & channel capacity

[Brian Adkins]

On Wednesday, January 20, 2016 at 11:28:59 PM UTC-5, Brian Adkins wrote:
> My initial experiment with places is a bit disappointing:
> 
> Sequential version: cpu time: 2084 real time: 2091 gc time: 91
> 
> Places version: cpu time: 16895 real time: 3988 gc time: 4244
> 
> Using 8x the CPU time seems quite high.
> 
> And more importantly, the places version only wrote 128,541 lines to the 
> output file vs. the correct number of 198,480 (65%). I suspect the program is 
> ending while some of the worker places are still active, but I think that 
> implies that if I correctly waited for all activity to finish, the numbers 
> would be even worse. Putting a sleep after the main input reading loop gets 
> me all but 5 of the records.
> 
> My simplistic design was to have the main place read lines from an input 
> file, write the lines to the place channels of N workers for processing (in a 
> round robin manner using modulo # workers). The workers write the parsed 
> lines to a single output place for writing to the output file.
> 
> Is it possible to limit the number of messages on a place channel? I suspect 
> the input place is moving faster than the workers, so the workers' place 
> channels may be getting huge.
> 
> Someone mentioned buffered asynchronous channels on IRC since you can set a 
> limit, but it appears you can't send them across a place channel, so I'm 
> unsure how to make use of them with places.
> 
> Sequential & parallel code is here:
> 
> https://gist.github.com/lojic/283aa3eec777e4810efc
> 
> Relevant lines are lines 44 to 105 of the parallel version.
> 
> Are there any projects, papers, etc. of best practices with respect to places 
> that I can look at?
> 
> Thanks,
> Brian

FYI - after some trial and error, I was able to specify a sleep time of ~ 500ms 
after the input file has been read to allow sufficient time for the workers to 
write to the output place and the output place to populate the file (minus ~ 5 
records). The output from time for various number of workers is:

2 workers => cpu time: 9396 real time: 3279 gc time: 2233

3 workers => cpu time: 11835 real time: 3543 gc time: 2137

4 workers => cpu time: 17078 real time: 4461 gc time: 4234

5 workers => cpu time: 21610 real time: 4988 gc time: 5366

I have 4 cores and 8 hyperthreads, but adding workers just means more CPU time 
and more elapsed time :(

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Places performance & channel capacity

[Brian Adkins]

On Thursday, January 21, 2016 at 7:48:44 AM UTC-5, Robby Findler wrote:
> It may be the overhead of communicating the data is dominating the
> time spent working.
> 
> Would it work to the main place open the file, count the number of
> lines, and then just tell the worker places which chunks of the file
> are theirs? Or maybe just do the counting at the byte level and then
> have some way to clean up the partial lines that each place would get?
> 
> Robby

I think one of the problems might be the fact that every mutable byte string 
needs to be converted to an immutable bytes string before it can be sent across 
a place channel, right?

I have no idea how costly that is, but that could be a huge part of the 
overhead. Unfortunately, it seems that the result of most byte string 
operations is a mutable byte string (with no way to tell the system to place it 
in the shared area), so it might be unavoidable.

-- 
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: Places performance & channel capacity

[Brian Adkins]

On Thursday, January 21, 2016 at 7:48:44 AM UTC-5, Robby Findler wrote:
> It may be the overhead of communicating the data is dominating the
> time spent working.
> 
> Would it work to the main place open the file, count the number of
> lines, and then just tell the worker places which chunks of the file
> are theirs? Or maybe just do the counting at the byte level and then
> have some way to clean up the partial lines that each place would get?
> 
> Robby

The sequential version takes 10 microseconds per line (including input, 
processing, output), so the processing part is clearly less than that. Maybe 
that amount of work is too fine grained? Can anyone with a lot of places 
experience comment on the suitability of a 10 microsecond unit of work for 
places?

The overhead should be limited to copying a byte string to the worker place, 
and then copying a different byte string to the output place. The CPU time and 
GC time for the places version is much higher than I expected.

I think my approach is pretty natural - hand off input records to workers for 
processing. I think your suggestion might complicate the program quite a bit.

Although in this *particular* case, the input file is fixed length, I'm not 
sure I'd feel comfortable depending on all 45M records being exactly the same 
size. As an experiment, I may verify that they are, and then compute a file 
offset for each worker.

*But*, that's not really what I had in mind for language supported parallelism 
- that's not very different than me just firing up N Racket processes via the 
operating system and using command-line cat to combine their individual output 
files.

The good news is that in preparation for creating the places version I switched 
from:

(fprintf e-out "~a\t~a\t..." field1 field2 ...)

to

(write-bytes (bytes-append field1 #"\t" field 2 #"\t" ...) e-out)

so that the parse-case function could return (bytes-append ...) instead of 
doing the actual output. This shaved off about 20% from the runtime! So the 
sequential version is now only 4.23x the C program where Ruby is 15.7x the C 
program. 

The sequential version would be fine in production, but after many years of 
seeing only one of my cores pegged at 100% by Ruby, I was really looking 
forward to seeing all four cores pegged :) Actually, the parallel version 
*does* in fact peg all the cores, but that's not exciting when it actually 
takes longer in total!

I was naively hoping for about a 3x speedup for the 4 core places version. I 
still wonder if causing the worker place channels to get huge is a problem - 
that might explain the very high GC time.

If anyone knows how to use buffered asynchronous channels with places, or 
simply how to block when attempting to put more than N messages in a place 
channel, I *think* that would help, but maybe not enough.

Brian

-- 
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 performance & channel capacity

[Brian Adkins]

On Thursday, January 21, 2016 at 10:58:51 AM UTC-5, Sam Tobin-Hochstadt wrote:
> Hi Brian,
> 
> A few suggestions:
> 
> 1. You really want to use synchronization to determine when to end,
> not sleeping. Have each place write a message back to its parent when
> it is done, and have the parent wait for that message before
> finishing.

That seems difficult in this case since each worker is in a loop where it reads 
a line from it's place channel, does some work and then writes the result to 
another place channel, so it's processing a stream.

I suppose the main place could write a terminating message to each worker after 
the input file has been read, and then wait for the worker place to also send 
back a terminating message.

> 2. Async channels are implemented with threads, and threads can't be
> sent between places. This is currently pretty fundamental to the way
> places work -- they are essentially copies of the Racket runtime which
> don't share anything, so things like threads (or procedures or mutable
> data) can't be sent between them.

I have a better idea of how places work now, but it seems like it would be 
handy to have a way to limit the size of a place channel, right?  If my input 
place is running much faster than the worker places, each of the worker place 
channels may be getting *huge* which seems bad.

> If what you need is buffering in places, you should probably write a
> buffer yourself using a thread and a mutable vector, which will
> consume all the messages sent to the worker place.

The blocking needs to be done in front of the worker place channel though, not 
after it, right? In other words, I'm trying to prevent the place channels from 
growing w/o bound. My goal is to maximize use of the cores and minimize elapsed 
time - my understanding of Racket threads is they only run one at a time, so 
I'm not sure how a thread would help in this case.

-- 
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 performance & channel capacity

[Brian Adkins]

On Thursday, January 21, 2016 at 12:50:26 PM UTC-5, antoine wrote:
> Bonjour,
> 
> Maybe for avoiding transforming mutable data to immutable data you could use
> make-shared-bytes and transfer the data by this mean? Don't know the 
> underlying
> implementation of make-shared-bytes it didn't seem to use POSIX shared memory
> objects.
> 
> Use one make-shared-bytes per place and synchronise between master place and a
> child with the normal chanel communication.

But you would still need to copy the mutable byte string (returned by various 
byte string functions) to the shared byte string you create with 
make-shared-bytes, right? So, a byte string would still be copied.

As someone suggested earlier, I could use read-bytes! and read directly into a 
byte string created by make-shared-bytes. Then I *think* the cost to "send" it 
to the worker place is minimal (maybe just sending a pointer). That would 
require some buffer bookkeeping to split lines, etc., but the workers would 
still need to copy their resulting byte strings to the output place.

Maybe I'm being overprotective, but my hunch is that I need the output place to 
serialize access to the output file vs. having the worker places write directly 
to it, but if Racket serializes access to the output port, maybe I can skip 
that.

-- 
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 performance & channel capacity

[Brian Adkins]

On Thursday, January 21, 2016 at 2:26:50 PM UTC-5, antoine wrote:
> To make it clear here is what i have in mind:
> 
> #lang racket
> 
> ;; dummy function, just remplace by A
> (define (do-stuff shared-data data-length)
>   (values
>(make-bytes data-length 65)
>data-length))
> 
> (define p
>   (place ch
>  (define shared-data (place-channel-get ch))
>  (let loop ()
>(define data-length (place-channel-get ch))
>(define-values (new-data new-data-length) (do-stuff shared-data 
> data-length))
>(bytes-copy!   shared-data 0 new-data 0 new-data-length)
>(place-channel-put ch new-data-length)
>(loop
> 
> (module+ main
>   (define shared-data (make-shared-bytes 10 66))
>   (place-channel-put p shared-data)
>   (place-channel-put p 5)
>   (place-channel-get p) ;; 5
>   (printf "~a\n" shared-data)  ;; AB
>   (place-channel-put p 7)
>   (place-channel-get p) ;; 7
>   (printf "~a\n" shared-data)) ;; AAABBB
> 
> > But you would still need to copy the mutable byte string (returned by 
> > various byte string functions) to the shared byte string you create with 
> > make-shared-bytes, right? So, a byte string would still be copied.
> 
> Yes
> 
> > As someone suggested earlier, I could use read-bytes! and read directly 
> > into a byte string created by make-shared-bytes. Then I *think* the cost to 
> > "send" it to the worker place is minimal (maybe just sending a pointer). 
> > That would require some buffer bookkeeping to split lines, etc., but the 
> > workers would still need to copy their resulting byte strings to the output 
> > place.
> 
> Yes
> 
> > Maybe I'm being overprotective, but my hunch is that I need the output 
> > place to serialize access to the output file vs. having the worker places 
> > write directly to it, but if Racket serializes access to the output port, 
> > maybe I can skip that.
> 
> According to the doc it seem you can't pass output-file-port.

I think I get what you're saying, but the trouble is to do this requires 
changing just about everything in the code i.e. manipulating indices into a 
shared buffer vs. having functions returning byte strings. It's much closer to 
what I did in the C program - definitely faster, but more manual bookkeeping 
for the programmer.

So, instead of programming in a more functional way - pass in a byte string, do 
some work and return another byte string. You would pass in a mutable byte 
string with a begin and end indices, do some work and return the updated 
indices, etc.

You can pass file ports across place channels - I send the output port to the 
output place, and it works fine. What I don't know is whether Racket would 
serialize N places that are writing to one port.

-- 
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] Re: Places performance & channel capacity

[Brian Adkins]

On Thursday, January 21, 2016 at 2:53:48 PM UTC-5, Brian Adkins wrote:
> 
> Ok, so the huge place channel for each worker isn't the main issue. I changed 
> the code so the output process sends a message to the main process every N 
> messages, and the main process waits on a message from the output process 
> every N messages. This has the effect of setting a limit on the place 
> channels.
> 
> Through some trial and error, I discovered that waiting every 8,000 messages 
> provides the best performance. So, the size of the place channels for each 
> worker is < 8000 / num-workers (currently 4 workers), and the size of the 
> place channel for the output process is < 8,000 messages. 
> 
> I don't know the exact count since I don't know the ratio of consumer to 
> producer.
> 
> My input lines are all exactly 300 bytes, so the output channel has < 2.3 MB 
> and each worker has < 600 KB
> 
> Current elapsed time for sequential is 2.467s and places is 3.732 s  > 50% 
> slower.
> 
> Limiting the place channel size reduced GC time also:
> 
> cpu time: 13249 real time: 3012 gc time: 280
> 
> Ratio of CPU time to real time is 4.4 which is good, but minimizing the 
> elapsed time is the goal.
> 
> So, in summary, copy byte strings to other places is too expensive in my 
> scenario.

I did some more experimenting by adding a sleep to the processing function to 
see how expensive the processing function had to be for the sequential and 
places versions to be equal.

Adding a 2.1 microsecond sleep gives the following:

Sequential:
cpu time: 3574 real time: 3887 gc time: 77 (operating system elapsed = 4.321s)

Places:
cpu time: 13791 real time: 2958 gc time: 231 (operating system elapsed = 3.659s)

less sleep, e.g. 2.0 microseconds, puts the sequential version ahead.

I then increased the sleep as follows:

17.5 microseconds => places ~ 1/2 as long as sequential
32.0 microseconds => places ~ 1/3 as long as sequential
50.0 microseconds => places ~ 1/4 as long as sequential
100 microseconds => places ~ 1/3.8 as long as sequential (only 4 workers)

The work itself is ~ 10 microseconds, so it would appear that a (32+10)=42 
microsecond unit of work is required to get a 3x speed up on 4 cores when 
needing to copy ~ 300 bytes twice into place channels.

In hindsight, I guess that's not too surprising since the majority of work is 
copying bytes from one place to another anyway (soundex isn't that slow), so if 
the parallel version has to copy the line twice when the work is ~ copying the 
line once, it's going to be expensive getting the data into and out of places.

If the work was parsing HTML or JSON, then the places version would probably be 
worth it on a 4 core machine.

Brian

-- 
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: Places performance & channel capacity

[Brian Adkins]

On Thursday, January 21, 2016 at 6:54:54 PM UTC-5, Neil Van Dyke wrote:
> If I understand correctly, you're ultimately looking for a general way 
> that you can write this kind of record processing code simply in the 
> future.  And that, right now, you're investing some one-time 
> experimental effort, to assess feasibility and to find an 
> approach/guidelines that you can apply more simply in the future.

I think I'm past the stage of assessing the feasibility of Racket for my work 
in general - I simply enjoy expressing code in Racket more than other 
languages. This particular project was really exploring the boundaries of 
Racket with respect to performance (and parallelization). In other words, which 
tasks are appropriate for Racket and which ones may be more suitable for 
something like C.

I primarily develop web applications, but most projects involve some sort of 
data import either from files, web services, etc. However, for most of these, 
performance isn't a huge factor, so a simple, straightforward, sequential 
solution in Racket would be fine.

This case study involves one atypical program that imports 45 million criminal 
records four times a year, so even for that, it's only mildly annoying that it 
takes a while, and the postgres index creation takes longer than creating the 
bulk import file. So, it's more of an excuse to use a real world program to 
explore than a bona fide need for absolute performance.

> Regarding feasibility, unless I misunderstand this pilot application, I 
> think that it could be done in Racket in a way that scales almost 
> perfectly with each additional core added, limited only by the ultimate 
> filesystem I/O.  That might involve Places, perhaps with larger work 
> units or more efficient communication and coordination; 

Yes, I think "more efficient communication and coordination" is the key, and I 
expect that's going to be a learning experience for me. I would probably get 
better parallel results by coding up an Othello or Chess game and parallelizing 
the game tree search.

> [...]
> Going back to "simply", rather than 
> simply-after-upfront-hard-work-done-by-application-programmer, maybe 
> there's opportunity for 
> simply-after-further-hard-work-done-by-core-Racket-programmers... For 
> example, perhaps some of the core Racket string routines could be 
> optimized further (I imagine they're already got a working-over, when 
> Unicode was added), so that even simple programs run faster. And maybe 
> there are Places facilities that could be optimized further, or some new 
> facility added.  And maybe there's a research project for better 
> parallelizing support.

I may be interested in further researching "places" performance later in a more 
organized and helpful manner vs. my current seat-of-the-pants, 
throw-up-some-mud-and-see-what-sticks approach :)

> BTW, there might still be a few relatively simple efficiency tweaks in 
> your current approach (e.g., while skimming, I think I saw a snippet of 
> code doing something like `(write-bytes (bytes-append ...))`, perhaps to 
> try to keep a chunk of bytes contiguous, for interleaving with other 
> threads' writes).

I used bytes-append to join fields with tabs plus a trailing newline to format 
the output record. I suppose I could use bytes-join instead and manually append 
the newline.

> > If the work was parsing HTML or JSON, then the places version would 
> > probably be worth it on a 4 core machine.
> 
> For HTML and JSON parsing, unlike your records application, I think the 
> parser itself has to be one thread, but you could probably put some 
> expensive application-specific behavior that happens during the parse in 
> other threads.  Neither my HTML nor JSON parsers was designed to be used 
> that way, but my streaming JSON parser might be amenable to it. The HTML 
> parser is intended to build a potentially-big AST in one shot, so no 
> other threads while it's working, though it should be reasonably fast 
> about it (it was written on a 166MHz Pentium laptop with 48MB RAM, 
> usually on battery power).

I simply meant that the unit of work for parsing HTML or JSON (i.e. one web 
page or one JSON document) is probably large enough to warrant the overhead of 
copying the bytes to a place vs. my program which is copying individual lines.

A streaming parser would like wind up with the same problem as my program - one 
line of HTML or JSON is too fine grained to be worth copying to a place for 
parsing.

Brian

-- 
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] (help ...) form in command-line REPL vs. Dr. Racket

[Brian Adkins]

On Tuesday, January 26, 2016 at 6:03:41 PM UTC-5, Robby Findler wrote:
> In DrRacket you can type f1 when your insertion point is on the word "help".
> 
> Robby

Awesome - thanks. I'm not sure if you meant 'insertion point is on the word 
"filter" ', or not, but for fun, I hit F1 with the insertion point on "help" 
and got meta-help which showed me 18.3 Interactive Help.

I then evaluated (require racket/help) in the repl, then tried evaluating (help 
filter)

A web page was opened, but not the help for filter (it was 4.9 Pairs and 
Lists), and the repl had the following:

> (require racket/help)
> (help filter)
Loading help index...
Sending to web browser...
  file: /Applications/Racket v6.3/doc/reference/pairs.html
  anchor: (def._((lib._racket/private/list..rkt)._filter))
osascript: OpenScripting.framework - scripting addition 
"/Library/ScriptingAdditions/Adobe Unit Types.osax" cannot be used with the 
current OS because it has no OSAXHandlers entry in its Info.plist.
> 

Hitting F1 when the insertion point is on filter works great though :)

I also tried (help "filter")   and that does open up a more relevant page - the 
search results for searching help with filter; where the command-line repl 
opens up the page with the help for filter - the command-line (help) form 
appears to expect a procedure symbol and shows the specific help for it.


> On Tue, Jan 26, 2016 at 4:28 PM, Brian Adkins wrote:
> > I was doing some reading on Scheme, and I came across the following page:
> >
> > http://bastibe.de/2012-09-20-story-about-schemes.html
> >
> > The author mentions:
> >
> > "That said, I found plt-racket to be a joy to work with. (help filter) will 
> > open your browser with the appropriate help page for filter. Amazing. "
> >
> > I thought that was pretty cool, so I tried it in Dr. Racket and got: "help: 
> > undefined"
> >
> > When I try it in the command-line REPL for racket, it worked great. I was 
> > just curious why it works in the command-line REPL, but not Dr. Racket - do 
> > I need to configure something for Dr. Racket?
> >
> > It's not a big deal because I usually just keep a browser tab opened to the 
> > help and use the integrated search feature, but it could be handy on 
> > occasion.
> >
> > Thanks,
> > Brian

-- 
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] (help ...) form in command-line REPL vs. Dr. Racket

[Brian Adkins]

On Tuesday, January 26, 2016 at 6:15:41 PM UTC-5, Brian Adkins wrote:
> On Tuesday, January 26, 2016 at 6:03:41 PM UTC-5, Robby Findler wrote:
> > In DrRacket you can type f1 when your insertion point is on the word "help".
> > 
> > Robby
> 
> Awesome - thanks. I'm not sure if you meant 'insertion point is on the word 
> "filter" ', or not, but for fun, I hit F1 with the insertion point on "help" 
> and got meta-help which showed me 18.3 Interactive Help.
> 
> I then evaluated (require racket/help) in the repl, then tried evaluating 
> (help filter)
> 
> A web page was opened, but not the help for filter (it was 4.9 Pairs and 
> Lists), and the repl had the following:


My bad, Dr. Racket *was* pulling up the right page (after requiring 
racket/help) - 4.9 is where filter is described. So both the command-line repl 
and Dr Racket repl give the same behavior after require in the latter.

I'm not sure what the OSAX error is, but it's just noise.


> 
> > (require racket/help)
> > (help filter)
> Loading help index...
> Sending to web browser...
>   file: /Applications/Racket v6.3/doc/reference/pairs.html
>   anchor: (def._((lib._racket/private/list..rkt)._filter))
> osascript: OpenScripting.framework - scripting addition 
> "/Library/ScriptingAdditions/Adobe Unit Types.osax" cannot be used with the 
> current OS because it has no OSAXHandlers entry in its Info.plist.
> > 
> 
> Hitting F1 when the insertion point is on filter works great though :)
> 
> I also tried (help "filter")   and that does open up a more relevant page - 
> the search results for searching help with filter; where the command-line 
> repl opens up the page with the help for filter - the command-line (help) 
> form appears to expect a procedure symbol and shows the specific help for it.
> 
> 
> > On Tue, Jan 26, 2016 at 4:28 PM, Brian Adkins wrote:
> > > I was doing some reading on Scheme, and I came across the following page:
> > >
> > > http://bastibe.de/2012-09-20-story-about-schemes.html
> > >
> > > The author mentions:
> > >
> > > "That said, I found plt-racket to be a joy to work with. (help filter) 
> > > will open your browser with the appropriate help page for filter. 
> > > Amazing. "
> > >
> > > I thought that was pretty cool, so I tried it in Dr. Racket and got: 
> > > "help: undefined"
> > >
> > > When I try it in the command-line REPL for racket, it worked great. I was 
> > > just curious why it works in the command-line REPL, but not Dr. Racket - 
> > > do I need to configure something for Dr. Racket?
> > >
> > > It's not a big deal because I usually just keep a browser tab opened to 
> > > the help and use the integrated search feature, but it could be handy on 
> > > occasion.
> > >
> > > Thanks,
> > > Brian

-- 
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] (help ...) form in command-line REPL vs. Dr. Racket

[Brian Adkins]

On Tuesday, January 26, 2016 at 6:21:13 PM UTC-5, Brian Adkins wrote:
> On Tuesday, January 26, 2016 at 6:15:41 PM UTC-5, Brian Adkins wrote:
> > On Tuesday, January 26, 2016 at 6:03:41 PM UTC-5, Robby Findler wrote:
> > > In DrRacket you can type f1 when your insertion point is on the word 
> > > "help".
> > > 
> > > Robby
> > 
> > Awesome - thanks. I'm not sure if you meant 'insertion point is on the word 
> > "filter" ', or not, but for fun, I hit F1 with the insertion point on 
> > "help" and got meta-help which showed me 18.3 Interactive Help.
> > 
> > I then evaluated (require racket/help) in the repl, then tried evaluating 
> > (help filter)
> > 
> > A web page was opened, but not the help for filter (it was 4.9 Pairs and 
> > Lists), and the repl had the following:
> 
> 
> My bad, Dr. Racket *was* pulling up the right page (after requiring 
> racket/help) - 4.9 is where filter is described. So both the command-line 
> repl and Dr Racket repl give the same behavior after require in the latter.
> 
> I'm not sure what the OSAX error is, but it's just noise.

The OSAX error was a red herring - I removed the Adobe Unit Types.osax file and 
no longer get the error, but the anchor tag on the URL isn't working from 
either repl.

It looks like it's *trying* to send the anchor:

> (require racket/help)
> (help filter)
Loading help index...
Sending to web browser...
  file: /Applications/Racket v6.3/doc/reference/pairs.html
  anchor: (def._((lib._racket/private/list..rkt)._filter))

but the URL ends up as:

file:///Applications/Racket%20v6.3/doc/reference/pairs.html

instead of:

file:///Applications/Racket%20v6.3/doc/reference/pairs.html#%28def._%28%28lib._racket%2Fprivate%2Flist..rkt%29._filter%29%29

-- 
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] (help ...) form in command-line REPL vs. Dr. Racket

[Brian Adkins]

On Tuesday, January 26, 2016 at 6:30:59 PM UTC-5, Brian Adkins wrote:
> On Tuesday, January 26, 2016 at 6:21:13 PM UTC-5, Brian Adkins wrote:
> > On Tuesday, January 26, 2016 at 6:15:41 PM UTC-5, Brian Adkins wrote:
> > > On Tuesday, January 26, 2016 at 6:03:41 PM UTC-5, Robby Findler wrote:
> > > > In DrRacket you can type f1 when your insertion point is on the word 
> > > > "help".
> > > > 
> > > > Robby
> > > 
> > > Awesome - thanks. I'm not sure if you meant 'insertion point is on the 
> > > word "filter" ', or not, but for fun, I hit F1 with the insertion point 
> > > on "help" and got meta-help which showed me 18.3 Interactive Help.
> > > 
> > > I then evaluated (require racket/help) in the repl, then tried evaluating 
> > > (help filter)
> > > 
> > > A web page was opened, but not the help for filter (it was 4.9 Pairs and 
> > > Lists), and the repl had the following:
> > 
> > 
> > My bad, Dr. Racket *was* pulling up the right page (after requiring 
> > racket/help) - 4.9 is where filter is described. So both the command-line 
> > repl and Dr Racket repl give the same behavior after require in the latter.
> > 
> > I'm not sure what the OSAX error is, but it's just noise.
> 
> The OSAX error was a red herring - I removed the Adobe Unit Types.osax file 
> and no longer get the error, but the anchor tag on the URL isn't working from 
> either repl.
> 
> It looks like it's *trying* to send the anchor:
> 
> > (require racket/help)
> > (help filter)
> Loading help index...
> Sending to web browser...
>   file: /Applications/Racket v6.3/doc/reference/pairs.html
>   anchor: (def._((lib._racket/private/list..rkt)._filter))
> 
> but the URL ends up as:
> 
> file:///Applications/Racket%20v6.3/doc/reference/pairs.html
> 
> instead of:
> 
> file:///Applications/Racket%20v6.3/doc/reference/pairs.html#%28def._%28%28lib._racket%2Fprivate%2Flist..rkt%29._filter%29%29

Manually copying what the repl reports as the anchor to the end of the URL 
(separated by #) works fine, so it knows the file, it knows the anchor, but by 
the time it gets to the browser, only the file is used.

Racket 6.3
OSX 10.10.5

Just out of curiosity, does this work for anyone else? In other words, in the 
Dr. Racket repl:

(require racket/help)
(help filter)

does that scroll down to the filter description in section 4.9, or is your URL 
missing the anchor?

-- 
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] (help ...) form in command-line REPL vs. Dr. Racket

[Brian Adkins]

On Tuesday, January 26, 2016 at 6:39:23 PM UTC-5, olopierpa wrote:
> On Wed, Jan 27, 2016 at 12:35 AM, Brian Adkins wrote:
> 
> > Just out of curiosity, does this work for anyone else? In other words, in 
> > the Dr. Racket repl:
> >
> > (require racket/help)
> > (help filter)
> >
> > does that scroll down to the filter description in section 4.9, or is your 
> > URL missing the anchor?
> 
> it works for me (Racket 6.3 / windows)

Thanks. I just changed my default browser to Safari, and it works fine, but 
when the default browser was Chrome, it failed.

-- 
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] (help ...) form in command-line REPL vs. Dr. Racket

[Brian Adkins]

On Tuesday, January 26, 2016 at 6:42:43 PM UTC-5, Brian Adkins wrote:
> On Tuesday, January 26, 2016 at 6:39:23 PM UTC-5, olopierpa wrote:
> > On Wed, Jan 27, 2016 at 12:35 AM, Brian Adkins wrote:
> > 
> > > Just out of curiosity, does this work for anyone else? In other words, in 
> > > the Dr. Racket repl:
> > >
> > > (require racket/help)
> > > (help filter)
> > >
> > > does that scroll down to the filter description in section 4.9, or is 
> > > your URL missing the anchor?
> > 
> > it works for me (Racket 6.3 / windows)
> 
> Thanks. I just changed my default browser to Safari, and it works fine, but 
> when the default browser was Chrome, it failed.

Ok, this is odd, it works with both Chrome and Safari *if* they're not already 
open when (help filter) is evaluated. If they are already open, the URL is 
missing the anchor.

I *always* have Chrome open.

-- 
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] (help ...) form in command-line REPL vs. Dr. Racket

[Brian Adkins]

On Tuesday, January 26, 2016 at 6:52:14 PM UTC-5, olopierpa wrote:
> On Wed, Jan 27, 2016 at 12:46 AM, Brian Adkins wrote:
> 
> > Ok, this is odd, it works with both Chrome and Safari *if* they're not 
> > already open when (help filter) is evaluated. If they are already open, the 
> > URL is missing the anchor.
> 
> In my case, the default browser is Chrome, and it was already open.
> 
> > I *always* have Chrome open.
> 
> Same here.

It's likely an OSX problem. The following works from a terminal window whether 
Chrome is already open or not:

osascript -e 'tell application "Chrome" to open location 
"file:///Applications/Racket%20v6.3/doc/reference/pairs.html?q=filter#%28def._%28%28lib._racket%2Fprivate%2Flist..rkt%29._filter%29%29"'

-- 
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] (help ...) form in command-line REPL vs. Dr. Racket

[Brian Adkins]

On Tuesday, January 26, 2016 at 6:55:26 PM UTC-5, Brian Adkins wrote:
> On Tuesday, January 26, 2016 at 6:52:14 PM UTC-5, olopierpa wrote:
> > On Wed, Jan 27, 2016 at 12:46 AM, Brian Adkins wrote:
> > 
> > > Ok, this is odd, it works with both Chrome and Safari *if* they're not 
> > > already open when (help filter) is evaluated. If they are already open, 
> > > the URL is missing the anchor.
> > 
> > In my case, the default browser is Chrome, and it was already open.
> > 
> > > I *always* have Chrome open.
> > 
> > Same here.
> 
> It's likely an OSX problem. The following works from a terminal window 
> whether Chrome is already open or not:
> 
> osascript -e 'tell application "Chrome" to open location 
> "file:///Applications/Racket%20v6.3/doc/reference/pairs.html?q=filter#%28def._%28%28lib._racket%2Fprivate%2Flist..rkt%29._filter%29%29"'

Oops, the above does *not* work if Chrome isn't open already - presumable 
because there is no application to "tell".

That seems like a pain - I guess Racket would need to 1) determine the default 
browser, 2) determine whether it's already running, then 3) if it is, use the 
above method; otherwise, use whatever it does now which seems to work fine if 
the browser *isn't* already open.


-- 
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] Re: Places performance & channel capacity

[Brian Adkins]

On Wednesday, January 20, 2016 at 11:47:57 PM UTC-5, Brian Adkins wrote:
> On Wednesday, January 20, 2016 at 11:28:59 PM UTC-5, Brian Adkins wrote:
> > My initial experiment with places is a bit disappointing:
> > 
> > Sequential version: cpu time: 2084 real time: 2091 gc time: 91
> > 
> > Places version: cpu time: 16895 real time: 3988 gc time: 4244
> > 
> > Using 8x the CPU time seems quite high.
> > 
> > And more importantly, the places version only wrote 128,541 lines to the 
> > output file vs. the correct number of 198,480 (65%). I suspect the program 
> > is ending while some of the worker places are still active, but I think 
> > that implies that if I correctly waited for all activity to finish, the 
> > numbers would be even worse. Putting a sleep after the main input reading 
> > loop gets me all but 5 of the records.
> > 
> > My simplistic design was to have the main place read lines from an input 
> > file, write the lines to the place channels of N workers for processing (in 
> > a round robin manner using modulo # workers). The workers write the parsed 
> > lines to a single output place for writing to the output file.
> > 
> > Is it possible to limit the number of messages on a place channel? I 
> > suspect the input place is moving faster than the workers, so the workers' 
> > place channels may be getting huge.
> > 
> > Someone mentioned buffered asynchronous channels on IRC since you can set a 
> > limit, but it appears you can't send them across a place channel, so I'm 
> > unsure how to make use of them with places.
> > 
> > Sequential & parallel code is here:
> > 
> > https://gist.github.com/lojic/283aa3eec777e4810efc
> > 
> > Relevant lines are lines 44 to 105 of the parallel version.
> > 
> > Are there any projects, papers, etc. of best practices with respect to 
> > places that I can look at?
> > 
> > Thanks,
> > Brian
> 
> FYI - after some trial and error, I was able to specify a sleep time of ~ 
> 500ms after the input file has been read to allow sufficient time for the 
> workers to write to the output place and the output place to populate the 
> file (minus ~ 5 records). The output from time for various number of workers 
> is:
> 
> 2 workers => cpu time: 9396 real time: 3279 gc time: 2233
> 
> 3 workers => cpu time: 11835 real time: 3543 gc time: 2137
> 
> 4 workers => cpu time: 17078 real time: 4461 gc time: 4234
> 
> 5 workers => cpu time: 21610 real time: 4988 gc time: 5366
> 
> I have 4 cores and 8 hyperthreads, but adding workers just means more CPU 
> time and more elapsed time :(

I changed the code to have the main place write #f to each of the worker 
places' channels after it sent the last line, and then wait to get #f back from 
each worker. This is only part of the solution, but it was helpful because it 
showed that the output place still had over 52,000 lines in its place channel 
waiting to be output to disk.

I have to think that's bad for performance.

I'm sure I can implement my own workaround for this, but am I wrong in thinking 
that being able to set a limit/capacity for a place's channel is a good idea? 
It seems the most natural solution to have the producer place block if the 
channel is full.

-- 
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] Re: Places performance & channel capacity

[Brian Adkins]

On Thursday, January 21, 2016 at 2:12:51 PM UTC-5, Brian Adkins wrote:
> On Wednesday, January 20, 2016 at 11:47:57 PM UTC-5, Brian Adkins wrote:
> > On Wednesday, January 20, 2016 at 11:28:59 PM UTC-5, Brian Adkins wrote:
> > > My initial experiment with places is a bit disappointing:
> > > 
> > > Sequential version: cpu time: 2084 real time: 2091 gc time: 91
> > > 
> > > Places version: cpu time: 16895 real time: 3988 gc time: 4244
> > > 
> > > Using 8x the CPU time seems quite high.
> > > 
> > > And more importantly, the places version only wrote 128,541 lines to the 
> > > output file vs. the correct number of 198,480 (65%). I suspect the 
> > > program is ending while some of the worker places are still active, but I 
> > > think that implies that if I correctly waited for all activity to finish, 
> > > the numbers would be even worse. Putting a sleep after the main input 
> > > reading loop gets me all but 5 of the records.
> > > 
> > > My simplistic design was to have the main place read lines from an input 
> > > file, write the lines to the place channels of N workers for processing 
> > > (in a round robin manner using modulo # workers). The workers write the 
> > > parsed lines to a single output place for writing to the output file.
> > > 
> > > Is it possible to limit the number of messages on a place channel? I 
> > > suspect the input place is moving faster than the workers, so the 
> > > workers' place channels may be getting huge.
> > > 
> > > Someone mentioned buffered asynchronous channels on IRC since you can set 
> > > a limit, but it appears you can't send them across a place channel, so 
> > > I'm unsure how to make use of them with places.
> > > 
> > > Sequential & parallel code is here:
> > > 
> > > https://gist.github.com/lojic/283aa3eec777e4810efc
> > > 
> > > Relevant lines are lines 44 to 105 of the parallel version.
> > > 
> > > Are there any projects, papers, etc. of best practices with respect to 
> > > places that I can look at?
> > > 
> > > Thanks,
> > > Brian
> > 
> > FYI - after some trial and error, I was able to specify a sleep time of ~ 
> > 500ms after the input file has been read to allow sufficient time for the 
> > workers to write to the output place and the output place to populate the 
> > file (minus ~ 5 records). The output from time for various number of 
> > workers is:
> > 
> > 2 workers => cpu time: 9396 real time: 3279 gc time: 2233
> > 
> > 3 workers => cpu time: 11835 real time: 3543 gc time: 2137
> > 
> > 4 workers => cpu time: 17078 real time: 4461 gc time: 4234
> > 
> > 5 workers => cpu time: 21610 real time: 4988 gc time: 5366
> > 
> > I have 4 cores and 8 hyperthreads, but adding workers just means more CPU 
> > time and more elapsed time :(
> 
> I changed the code to have the main place write #f to each of the worker 
> places' channels after it sent the last line, and then wait to get #f back 
> from each worker. This is only part of the solution, but it was helpful 
> because it showed that the output place still had over 52,000 lines in its 
> place channel waiting to be output to disk.
> 
> I have to think that's bad for performance.
> 
> I'm sure I can implement my own workaround for this, but am I wrong in 
> thinking that being able to set a limit/capacity for a place's channel is a 
> good idea? It seems the most natural solution to have the producer place 
> block if the channel is full.

Ok, so the huge place channel for each worker isn't the main issue. I changed 
the code so the output process sends a message to the main process every N 
messages, and the main process waits on a message from the output process every 
N messages. This has the effect of setting a limit on the place channels.

Through some trial and error, I discovered that waiting every 8,000 messages 
provides the best performance. So, the size of the place channels for each 
worker is < 8000 / num-workers (currently 4 workers), and the size of the place 
channel for the output process is < 8,000 messages. 

I don't know the exact count since I don't know the ratio of consumer to 
producer.

My input lines are all exactly 300 bytes, so the output channel has < 2.3 MB 
and each worker has < 600 KB

Current elapsed time for sequential is 2.467s and places is 3.732 s  > 50% 
slower.

Limiting the place channel size reduced GC time also:

cpu time: 13249 real time: 3012 gc time: 280

Ratio of CPU time to real time is 4.4 which is good, but minimizing the elapsed 
time is the goal.

So, in summary, copy byte strings to other places is too expensive in my 
scenario.

-- 
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] raco pkg install -> connection refused

[Brian Adkins]

I'm trying to install the html-parsing package, and I'm getting a connection 
refused error. Is this just a transient issue?

$ raco pkg install html-parsing
Resolving "html-parsing" via 
https://download.racket-lang.org/releases/6.4/catalog/
tcp-connect: connection failed
  address: mirror.racket-lang.org
  port number: 80
  step: 6
  system error: Connection refused; errno=61
  context...:
   /Applications/Racket v6.4/collects/net/http-client.rkt:235:0
   /Applications/Racket 
v6.4/collects/racket/contract/private/arrow-val-first.rkt:335:3
   /Applications/Racket v6.4/collects/net/url.rkt:144:0: 
http://getpost-impure-port
   /Applications/Racket v6.4/collects/net/url.rkt:251:2: redirection-loop
   /Applications/Racket 
v6.4/collects/racket/contract/private/arrow-val-first.rkt:335:3
   /Applications/Racket v6.4/collects/pkg/private/network.rkt:59:3
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:218:0: 
read-from-server
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:138:9: for-loop
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:135:2: 
lookup-normally
   /Applications/Racket 
v6.4/collects/pkg/private/../../racket/private/more-scheme.rkt:261:28
   /Applications/Racket v6.4/collects/pkg/private/prefetch.rkt:128:2
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:132:0: 
package-catalog-lookup9
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:200:0: 
package-catalog-lookup-source19
   /Applications/Racket v6.4/collects/pkg/private/clone-path.rkt:370:0: 
desc->repo8
   /Applications/Racket v6.4/collects/pkg/private/clone-path.rkt:64:2: 
add-repo-desc35
   /Applications/Racket v6.4/collects/pkg/private/clone-path.rkt:45:0: 
adjust-to-normalize-repos

When I try to open http://mirror.racket-lang.org/releases/6.4/catalog/ 
directly, I get connection refused.

Thanks,
Brian

-- 
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] Which html-parsing package?

[Brian Adkins]

I'm looking for an html parser that can handle real world web pages that are 
typically invalid (similar to Ruby's Nokogiri). I came across recommendations 
for the html-parsing package, so I went to: 

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

I couldn't find it via the parsing or parser tags, but using my browser's find, 
found html-parsing. The description states: "A fork of the Planet 1 
html-parsing library". On the documentation page, I see a history with the last 
entry being 0.3 2011-08-27 and the following require:

(require sxml/html)

Clicking on the following link at the top of the doc page:

http://www.neilvandyke.org/racket-html-parsing/

takes me to Neil's page with a more recent history: PLaneT 3:0 — 2015-04-24 and 
the following require:

(require (planet neil/html-parsing:3:0))

Which package do I want?

Brian

-- 
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] Which html-parsing package?

[Brian Adkins]

On Wednesday, February 17, 2016 at 10:20:21 AM UTC-5, Neil Van Dyke wrote:
> Brian Adkins wrote on 02/17/2016 10:04 AM:
> > http://www.neilvandyke.org/racket-html-parsing/
> >
> > takes me to Neil's page with a more recent history: PLaneT 3:0 — 2015-04-24 
> > and the following require:
> >
> > (require (planet neil/html-parsing:3:0))
> >
> > Which package do I want?
> 
> You might prefer that one, from PLaneT, since that's the one I support.
> 
> (I think what happened with the other one is that someone was 
> experimenting with the new package system catalog early on, and used my 
> `html-parsing` package as an exercise.  Eventually I'll move my packages 
> to the new system, but there are complications I need to find time to 
> deal with.)
> 
> Neil V.

1) May I suggest we remove the out of date html-parsing package from the main 
package catalog? Had I not had the hiccup with the catalog server, I likely 
would've installed the out of date package and not realize what I'd done.

I expect most newbies assume that https://pkgs.racket-lang.org/ is where you go 
for packages, so if they find html-parsing there they probably think they've 
found the correct one.

2) I'm not familiar with planet. What is the equivalent of "raco pkg install 
html-parsing" in the planet world? Also, what is the equivalent of (require 
(prefix-in h: html-parsing)) for the planet required (i.e. prefixing).

Thanks!
Brian

-- 
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] Which html-parsing package?

[Brian Adkins]

On Wednesday, February 17, 2016 at 10:35:44 AM UTC-5, Brian Adkins wrote:
> On Wednesday, February 17, 2016 at 10:20:21 AM UTC-5, Neil Van Dyke wrote:
> > Brian Adkins wrote on 02/17/2016 10:04 AM:
> > > http://www.neilvandyke.org/racket-html-parsing/
> > >
> > > takes me to Neil's page with a more recent history: PLaneT 3:0 — 
> > > 2015-04-24 and the following require:
> > >
> > > (require (planet neil/html-parsing:3:0))
> > >
> > > Which package do I want?
> > 
> > You might prefer that one, from PLaneT, since that's the one I support.
> > 
> > (I think what happened with the other one is that someone was 
> > experimenting with the new package system catalog early on, and used my 
> > `html-parsing` package as an exercise.  Eventually I'll move my packages 
> > to the new system, but there are complications I need to find time to 
> > deal with.)
> > 
> > Neil V.
> 
> 1) May I suggest we remove the out of date html-parsing package from the main 
> package catalog? Had I not had the hiccup with the catalog server, I likely 
> would've installed the out of date package and not realize what I'd done.
> 
> I expect most newbies assume that https://pkgs.racket-lang.org/ is where you 
> go for packages, so if they find html-parsing there they probably think 
> they've found the correct one.
> 
> 2) I'm not familiar with planet. What is the equivalent of "raco pkg install 
> html-parsing" in the planet world? Also, what is the equivalent of (require 
> (prefix-in h: html-parsing)) for the planet required (i.e. prefixing).
> 
> Thanks!
> Brian

Also, is there a website where I can browse planet packages and get more info? 
I tried:

https://planet.racket-lang.org/

but got a 503 Service Unavailable message. Since Ben mentioned in another 
thread that the package catalog was back online, I figured the above 503 is 
unrelated to the earlier problem.

-- 
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] raco pkg install -> connection refused

[Brian Adkins]

On Wednesday, February 17, 2016 at 10:28:48 AM UTC-5, Ben Greenman wrote:
> You should be able to install html-parsing now.

I'm no longer getting connection refused, but now I'm getting a 403.

$ raco pkg install html-parsing
Resolving "html-parsing" via 
https://download.racket-lang.org/releases/6.4/catalog/
package-catalog-lookup: error from server
  URL: 
https://download.racket-lang.org/releases/6.4/catalog/pkg/html-parsing?version=6.4
  status code: 403
  context...:
   /Applications/Racket v6.4/collects/pkg/private/network.rkt:59:3
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:218:0: 
read-from-server
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:138:9: for-loop
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:135:2: 
lookup-normally
   /Applications/Racket 
v6.4/collects/pkg/private/../../racket/private/more-scheme.rkt:261:28
   /Applications/Racket v6.4/collects/pkg/private/prefetch.rkt:128:2
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:132:0: 
package-catalog-lookup9
   /Applications/Racket v6.4/collects/pkg/private/catalog.rkt:200:0: 
package-catalog-lookup-source19
   /Applications/Racket v6.4/collects/pkg/private/clone-path.rkt:370:0: 
desc->repo8
   /Applications/Racket v6.4/collects/pkg/private/clone-path.rkt:64:2: 
add-repo-desc35
   /Applications/Racket v6.4/collects/pkg/private/clone-path.rkt:45:0: 
adjust-to-normalize-repos
   /Applications/Racket v6.4/collects/pkg/private/install.rkt:889:3
   /Applications/Racket 
v6.4/collects/racket/contract/private/arrow-val-first.rkt:335:3
   /Applications/Racket v6.4/collects/racket/file.rkt:378:8
   /Applications/Racket v6.4/collects/racket/file.rkt:367:0: 
call-with-file-lock42
   /Applications/Racket v6.4/collects/pkg/main.rkt:201:16
   ...

-- 
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] raco pkg install -> connection refused

[Brian Adkins]

On Wednesday, February 17, 2016 at 1:53:56 PM UTC-5, Matthew Flatt wrote:
> At Wed, 17 Feb 2016 10:45:26 -0800 (PST), Brian Adkins wrote:
> > On Wednesday, February 17, 2016 at 10:28:48 AM UTC-5, Ben Greenman wrote:
> > > You should be able to install html-parsing now.
> > 
> > I'm no longer getting connection refused, but now I'm getting a 403.
> 
> This should be fixed now.

Works great - thanks to all who helped restore the server(s).

-- 
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] Setup/teardown for unit testing

[Brian Adkins]

If you're going to add something, please don't do #1 :) That's how it's done in 
Ruby, but it's an OO, stateful platform, so it fits.

The only other way I've seen recently is the Elixir version ( 
http://elixir-lang.org/docs/stable/ex_unit/ExUnit.Case.html 
<http://elixir-lang.org/docs/stable/ex_unit/ExUnit.Case.html>) , and I like it 
- the setup function simply returns a value that is passed to the test case. 
Your example confused me because I think you used balance instead of account as 
the param e.g.:

(test-suite #:before-each (open-bank)
(test-case/param (lambda (account) (check-= (balance account 0)))
 ...))

I would also want to retain the string description.

I agree that divergence can be a problem, but I'm a little less concerned with 
that in something like Rackunit, so I'm on the fence on this now given the 
simplicity of the solution for my personal need.

The Elixir solution probably uses pattern matching on the test function, so 
there's a version that accepts a string description and a block/lambda, and 
another version that accepts a string, a hash and a block/lambda. This saves 
you from having to introduce a #:param keyword.

Maybe something like:

(test-suite #:before-each (open-bank)
  (test-case/context "Description" account
(check-= (balance account 0

> On Mar 9, 2016, at 11:06 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote:
> 
> I think having a built-in way to do something like this would be a
> good thing, rather than having everyone write their own abstraction
> for this. One way we've avoided divergence in the Racket community
> despite Racket's flexibility is by building in the right abstractions
> in core libraries. But I share Jay's worry about the code in your
> gist.
> 
> Here are a few possible ways I think we could add per-test-case setup code:
> 
> 1. Purely state-based. Add a `#:before-each` keyword, which defines an
> expression to run before each test case. Then you'd write:
> 
> (let ([account #f])
>  (test-suite #:before-each (set! account (open-bank))
> (test-case (check-= (balance account 0))
>  ...)))
> 
> 2. Parameter-passing, with an explicit lambda (could maybe make this a
> keyword version of test-case as well):
> 
> (test-suite #:before-each (open-bank)
> (test-case/param (lambda (balance) (check-= (balance account 0)))
>  ...))
> 
> 3. Parameter-passing, with a binding position in the macro (perhaps
> using a keyword like #:param):
> 
> (test-suite #:before-each (open-bank)
> (test-case #:param balance (check-= (balance account 0))
>  ...))
> 
> Certainly 1 is the simplest to implement, but stateful test frameworks
> seem quite unfortunate. 2 is also simple, but has a proliferation of
> API surface.
> 
> Any other thoughts on which of these is preferable? I'm happy to
> implement whichever solution seems best.
> 
> Sam
> 
> 
> On Wed, Mar 9, 2016 at 10:53 AM, Jay McCarthy <jay.mccar...@gmail.com> wrote:
>> I looked at the gist you posted. I don't think it is plausible for us to add
>> something like that to the test code, because you're imagining splicing the
>> test body after the before exprs (because in your example, the before binds
>> an identifier.)
>> 
>> I really think you just want a slightly different test-case macro that does
>> exactly what you want.
>> 
>> (define-syntax-rule (brian-test-case label account . exprs)
>> (test-case label (define account (open-bank)) . exprs))
>> 
>> I really can't see the appeal of trying to push something into Rackunit that
>> can expand to what your example would do. It just seems so much more
>> complicated to implement and explain what it means than just putting in a
>> one line macro like this.
>> 
>> I feel that there is an analogy between `do`, `for`, and `let loop`. It is
>> definitely wise to not have to program every `for` loop explicitly with `let
>> loop`s, but trying to keep expanding the `for` macro to do more and more
>> towards the Lisp `do` macro is a bad move, IMHO, because it is so much more
>> complicated and non-orthogonal. It's better to make a test system that
>> integrates well with the rest of the language and to just use the language's
>> features for extensibility.
>> 
>> Jay
>> 
>> 
>> On Tue, Mar 8, 2016 at 1:35 PM, Brian Adkins <lojicdot...@gmail.com> wrote:
>>> 
>>> Not exactly. I'm looking for a way to run a function before *each*, of
>>> possibly many, test-cases. The test-suite #:before only runs once before
>>> running all the test-cases.
>>> 
>>> Although my gist: https://gist.github.com/lojic/db7016fb95b1c05e4ade only
>>> has a few test

[racket-users] Re: Sequential vs. Parallel 13-Queens program

[Brian Adkins]

On Friday, March 11, 2016 at 7:42:22 PM UTC-5, Brian Adkins wrote:
> I coded up a sequential and parallel version of N-Queens, then did a ton of 
> benchmark runs of 13-Queens to compare the time. For each configuration 
> (sequential or parallel w/ M workers), I ran the programs 6 times, threw out 
> the high two & low two and averaged the middle two numbers.
> 
> The spreadsheet with timings is here:
> 
> https://docs.google.com/spreadsheets/d/1LFwdZbBveaARY_AquGXY9jgaSJlOA03NQCV9TeYQ-l8/edit?usp=sharing
> 
> The code is here:
> 
> https://gist.github.com/lojic/aef0aec491d3dc9cb40b
> 
> I didn't spend any time refining/optimizing, so it's fairly crude, but 
> informative nonetheless.
> 
> The executive summary of timings for the parallel version:
> 
> # Places  Time
> 1 34.9
> 2 19.7
> 3 13.8
> 4 12.3
> 5 11.9
> 6 12.9
> 7 12.1
> 8 12.2
> 
> The sequential version took 31.3 seconds.
> 
> The basic idea for the parallel version is to place the first 13 starting 
> positions in a queue that the place workers will pull from and produce a set 
> of solutions with that starting position. Both the parallel and sequential 
> versions collect all 73,712 solutions in a list and compute the length of it. 
> I hardcoded the number of solutions as a quick & dirty way of determining 
> completion in the parallel version just to allow me to get the timings easily.
> 
> It was great to finally write some Racket code that got all my cores heated 
> up :)
> 
> Brian

Interesting. My first parallel version had the workers write each solutions 
(list of N queen positions) to the parent as they were computed. I just changed 
the program to collect all the solutions for a given prefix (closer to the way 
the sequential version works) and send that list to the parent.

The result is a modest 4% speeedup. I had assumed that creating the extra 
intermediate lists would be slower.

I thought I read something about the implementation of Places that allows data 
to be moved efficiently from one Place to another via virtual memory pages - 
maybe something like that is going on. Regardless, I'm happy that the more 
natural algorithm (to me anyway) is also more efficient. I guess the overhead 
of many place-channel-put/get calls is more expensive than the allocation & 
garbage collection of the intermediate lists.

The second parallel version referred to above is here: 
https://gist.github.com/lojic/957828ce7c67c0376a23

-- 
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] Sequential vs. Parallel 13-Queens program

[Brian Adkins]

I coded up a sequential and parallel version of N-Queens, then did a ton of 
benchmark runs of 13-Queens to compare the time. For each configuration 
(sequential or parallel w/ M workers), I ran the programs 6 times, threw out 
the high two & low two and averaged the middle two numbers.

The spreadsheet with timings is here:

https://docs.google.com/spreadsheets/d/1LFwdZbBveaARY_AquGXY9jgaSJlOA03NQCV9TeYQ-l8/edit?usp=sharing

The code is here:

https://gist.github.com/lojic/aef0aec491d3dc9cb40b

I didn't spend any time refining/optimizing, so it's fairly crude, but 
informative nonetheless.

The executive summary of timings for the parallel version:

# PlacesTime
1   34.9
2   19.7
3   13.8
4   12.3
5   11.9
6   12.9
7   12.1
8   12.2

The sequential version took 31.3 seconds.

The basic idea for the parallel version is to place the first 13 starting 
positions in a queue that the place workers will pull from and produce a set of 
solutions with that starting position. Both the parallel and sequential 
versions collect all 73,712 solutions in a list and compute the length of it. I 
hardcoded the number of solutions as a quick & dirty way of determining 
completion in the parallel version just to allow me to get the timings easily.

It was great to finally write some Racket code that got all my cores heated up 
:)

Brian

-- 
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] Sequential vs. Parallel 13-Queens program

[Brian Adkins]

My program does represent a solution by a list of length N (one queen per 
file), so each element of the list is a file and stores the rank. The reason I 
also store the second coordinate (the file) is for ease of knowing the file 
when backtracking. If I used vectors instead, I could get by with just storing 
one number, the rank, since the index of the vector would be the file.

Using vectors won't change big-O but might reduce the constant factor.

My main goal was really just to compare sequential vs. parallel though, I'm 
sure there are other heuristics that could be applied to make the algorithm 
less naive.

> On Mar 12, 2016, at 7:05 PM, Jos Koot <jos.k...@gmail.com> wrote:
> 
> I addition to my previous post:
> 
> If I understand well you are using posn-s.
> A solution of the N-queens can be represented by a list or vector of lenhgth
> N that for each row (or column) records the position of a queen in the
> column (or row). This reduces the computation of time O(f(N^2)) to O(f(N)),
> because only rows (or cullums) are considered, not all N^2 squares of the
> board.
> Jos 
> 
> -----Original Message-
> From: Brian Adkins [mailto:lojicdot...@gmail.com] 
> Sent: sábado, 12 de marzo de 2016 23:33
> To: Jos Koot
> Cc: Racket Users
> Subject: Re: [racket-users] Sequential vs. Parallel 13-Queens program
> 
> The code is a little difficult for me to read. It doesn't seem to collect
> *all* solutions for a given N. If that's the case, would you be able to
> modify it to do so to allow a more direct comparison?
> 
>> On Mar 12, 2016, at 1:19 PM, Jos Koot <jos.k...@gmail.com> wrote:
>> 
>> See https://en.wikipedia.org/wiki/Eight_queens_puzzle
>> For a non recursive non-back-tracking algorithm.
>> It is a loop that (when using a vector) can easily be unrolled in
> parallelly
>> executed loops.
>> I implemented it as follows running on 2 processors:
>> 
>> #lang racket
>> #|
>> The following text is copied from article n queens of wikipedia:
>> 
>> This heuristic solves N queens for any N ≥ 4. It forms the list of
> numbers
>> for vertical positions (rows) of queens with horizontal position (column)
>> simply increasing. N is 8 for eight queens puzzle.
>> 
>> 1. If the remainder from dividing N by 6 is not 2 or 3 then the list is
>> simply all even numbers followed by all odd numbers ≤ N
>> 2. Otherwise, write separate lists of even and odd numbers (i.e. 2,4,6,8 -
>> 1,3,5,7)
>> 3. If the remainder is 2, swap 1 and 3 in odd list and move 5 to the end
> (i.
>> e. 3,1,7,5)
>> 4. If the remainder is 3, move 2 to the end of even list and 1,3 to the
> end
>> of odd list (i.e. 4,6,8,2 - 5,7,9,1,3)
>> 5. Append odd list to the even list and place queens in the rows given by
>> these numbers, from left to right (i.e. a2, b4, c6, d8, e3, f1, g7, h5)
>> 
>> In the following procedure I use a vector with as many elements as the
> chess
>> board has rows. Every element is assigned exactly once. Rows and columns
> are
>> counted from 0 (in the wikipedia article they are counted from 1)
>> 
>> Futures allow two or more loops to run simulanuously on two or more
>> processors. If you don't have futures, replace (define f (future odd)) by
>> (odd) and remove the touch.
>> |#
>> 
>> (require racket/future)
>> 
>> (define (queens n)
>> (define v (make-vector n))
>> (define n-odd (quotient n 2))
>> (define r (remainder n 6))
>> (define (odd)
>> (case r
>>  ((3)
>>   (for ((k (in-range 0 (sub1 n-odd (vector-set! v k (+ 3 (* 2 k
>>   (vector-set! v (sub1 n-odd) 1))
>>  (else
>>   (for ((k (in-range 0 n-odd))) (vector-set! v k (add1 (* 2 k)))
>> (define (even)
>> (case r
>>  ((2)
>>   (vector-set! v n-odd 2)
>>   (vector-set! v (add1 n-odd) 0)
>>   (for ((k (in-range (+ 2 n-odd) n)))
>>(vector-set! v k (+ 6 (* 2 (- k n-odd 2)
>>   (vector-set! v (sub1 n) 4))
>>  ((3)
>>   (for ((k (in-range n-odd (- n 2
>>(vector-set! v k (+ 4 (* 2 (- k n-odd)
>>   (vector-set! v (- n 2) 0)
>>   (vector-set! v (- n 1) 2))
>>  (else
>>   (for ((k (in-range n-odd n)))
>>(vector-set! v k (* 2 (- k n-odd)))
>> (define f (future odd))
>> (even)
>> (touch f)
>> v)
>> 
>> (define (check v)
>> (let ((n (vector-length v)))
>> (for/and ((x1 (in-range 0 n)))
>>  (let ((y1 (vector-ref v x1)))
>>   (for/and ((x2 (in-range (add1 x1) n)))
>>(let ((y2 (vector-ref v x2)))
>> (not
>>  (or
>>   (= y1 y2)
>>   (= (abs (- x1 x2)) (abs (- 

[racket-users] Implicit "self" place channel

[Brian Adkins]

I'm toying around with porting a small Elixir program to Racket. The following 
gist has both programs:

https://gist.github.com/lojic/66c00514dab54b84c56e

One thing that's quite awkward in my Racket version is the need for the extra 
place channels (ch1, ch2). 

So, for example, the size function needs 3 channels:
1) pid - the place channel of the stack place to send the command to
2) ch1 - a channel the stack will send the response to
3) ch2 - a channel for size to read the response from

I think if I used Racket threads, my code would be more similar to the Elixir 
example, because it appears that threads have their own implicit mailbox.

Do places have an implicit mailbox that I've overlooked? Or is the 3 channel 
requirement above unavoidable?

Thanks,
Brian

-- 
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] Re: Implicit "self" place channel

[Brian Adkins]

On Tuesday, March 8, 2016 at 5:10:45 PM UTC-5, Brian Adkins wrote:
> I'm toying around with porting a small Elixir program to Racket. The 
> following gist has both programs:
> 
> https://gist.github.com/lojic/66c00514dab54b84c56e
> 
> One thing that's quite awkward in my Racket version is the need for the extra 
> place channels (ch1, ch2). 
> 
> So, for example, the size function needs 3 channels:
> 1) pid - the place channel of the stack place to send the command to
> 2) ch1 - a channel the stack will send the response to
> 3) ch2 - a channel for size to read the response from
> 
> I think if I used Racket threads, my code would be more similar to the Elixir 
> example, because it appears that threads have their own implicit mailbox.
> 
> Do places have an implicit mailbox that I've overlooked? Or is the 3 channel 
> requirement above unavoidable?
> 
> Thanks,
> Brian

I coded up a version using threads instead of places, and it's very close to 
the Elixir code. I've added the racket-threads.rkt file to the gist:

https://gist.github.com/lojic/66c00514dab54b84c56e

I think I just need to adjust my thinking re: concurrency & parallelism. 
Threads would allow the massive concurrency of Elixir/Erlang processes but 
limited to one core. Places allow using all cores, but using a very different 
programming model - rather than spawning a million places, I understand it's 
better to spawn one per process (or possibly hyperthread), so one would likely 
make more use of queues of work units vs. sending the work units directly to 
the places.

-- 
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] Re: Sequential vs. Parallel 13-Queens program

[Brian Adkins]

On Friday, March 11, 2016 at 9:01:38 PM UTC-5, Brian Adkins wrote:
> On Friday, March 11, 2016 at 7:42:22 PM UTC-5, Brian Adkins wrote:
> > I coded up a sequential and parallel version of N-Queens, then did a ton of 
> > benchmark runs of 13-Queens to compare the time. For each configuration 
> > (sequential or parallel w/ M workers), I ran the programs 6 times, threw 
> > out the high two & low two and averaged the middle two numbers.
> > 
> > The spreadsheet with timings is here:
> > 
> > https://docs.google.com/spreadsheets/d/1LFwdZbBveaARY_AquGXY9jgaSJlOA03NQCV9TeYQ-l8/edit?usp=sharing
> > 
> > The code is here:
> > 
> > https://gist.github.com/lojic/aef0aec491d3dc9cb40b
> > 
> > I didn't spend any time refining/optimizing, so it's fairly crude, but 
> > informative nonetheless.
> > 
> > The executive summary of timings for the parallel version:
> > 
> > # PlacesTime
> > 1   34.9
> > 2   19.7
> > 3   13.8
> > 4   12.3
> > 5   11.9
> > 6   12.9
> > 7   12.1
> > 8   12.2
> > 
> > The sequential version took 31.3 seconds.
> > 
> > The basic idea for the parallel version is to place the first 13 starting 
> > positions in a queue that the place workers will pull from and produce a 
> > set of solutions with that starting position. Both the parallel and 
> > sequential versions collect all 73,712 solutions in a list and compute the 
> > length of it. I hardcoded the number of solutions as a quick & dirty way of 
> > determining completion in the parallel version just to allow me to get the 
> > timings easily.
> > 
> > It was great to finally write some Racket code that got all my cores heated 
> > up :)
> > 
> > Brian
> 
> Interesting. My first parallel version had the workers write each solutions 
> (list of N queen positions) to the parent as they were computed. I just 
> changed the program to collect all the solutions for a given prefix (closer 
> to the way the sequential version works) and send that list to the parent.
> 
> The result is a modest 4% speeedup. I had assumed that creating the extra 
> intermediate lists would be slower.
> 
> I thought I read something about the implementation of Places that allows 
> data to be moved efficiently from one Place to another via virtual memory 
> pages - maybe something like that is going on. Regardless, I'm happy that the 
> more natural algorithm (to me anyway) is also more efficient. I guess the 
> overhead of many place-channel-put/get calls is more expensive than the 
> allocation & garbage collection of the intermediate lists.
> 
> The second parallel version referred to above is here: 
> https://gist.github.com/lojic/957828ce7c67c0376a23

I cleaned up the code a bit (removed hardcoded completion checks, etc.) and 
moved the code to a git repo:

https://github.com/lojic/LearningRacket/tree/master/miscellaneous

I was hoping to get more than a 3x speedup, but my final results show a 2.8x 
speedup on 4 cores. I suppose the amount of work per solution isn't large 
enough for a better speedup.

In the N=13 case that takes 11 seconds, there are 6,700 solutions per second 
being sent across a place-channel with each solution being a list of 13 structs 
of 2 elements.

Still, 2.8x is appreciated :)

-- 
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] Sequential vs. Parallel 13-Queens program

[Brian Adkins]

The code is a little difficult for me to read. It doesn't seem to collect *all* 
solutions for a given N. If that's the case, would you be able to modify it to 
do so to allow a more direct comparison?

> On Mar 12, 2016, at 1:19 PM, Jos Koot <jos.k...@gmail.com> wrote:
> 
> See https://en.wikipedia.org/wiki/Eight_queens_puzzle
> For a non recursive non-back-tracking algorithm.
> It is a loop that (when using a vector) can easily be unrolled in parallelly
> executed loops.
> I implemented it as follows running on 2 processors:
> 
> #lang racket
> #|
> The following text is copied from article n queens of wikipedia:
> 
> This heuristic solves N queens for any N ≥ 4. It forms the list of numbers
> for vertical positions (rows) of queens with horizontal position (column)
> simply increasing. N is 8 for eight queens puzzle.
> 
> 1. If the remainder from dividing N by 6 is not 2 or 3 then the list is
> simply all even numbers followed by all odd numbers ≤ N
> 2. Otherwise, write separate lists of even and odd numbers (i.e. 2,4,6,8 -
> 1,3,5,7)
> 3. If the remainder is 2, swap 1 and 3 in odd list and move 5 to the end (i.
> e. 3,1,7,5)
> 4. If the remainder is 3, move 2 to the end of even list and 1,3 to the end
> of odd list (i.e. 4,6,8,2 - 5,7,9,1,3)
> 5. Append odd list to the even list and place queens in the rows given by
> these numbers, from left to right (i.e. a2, b4, c6, d8, e3, f1, g7, h5)
> 
> In the following procedure I use a vector with as many elements as the chess
> board has rows. Every element is assigned exactly once. Rows and columns are
> counted from 0 (in the wikipedia article they are counted from 1)
> 
> Futures allow two or more loops to run simulanuously on two or more
> processors. If you don't have futures, replace (define f (future odd)) by
> (odd) and remove the touch.
> |#
> 
> (require racket/future)
> 
> (define (queens n)
> (define v (make-vector n))
> (define n-odd (quotient n 2))
> (define r (remainder n 6))
> (define (odd)
>  (case r
>   ((3)
>(for ((k (in-range 0 (sub1 n-odd (vector-set! v k (+ 3 (* 2 k
>(vector-set! v (sub1 n-odd) 1))
>   (else
>(for ((k (in-range 0 n-odd))) (vector-set! v k (add1 (* 2 k)))
> (define (even)
>  (case r
>   ((2)
>(vector-set! v n-odd 2)
>(vector-set! v (add1 n-odd) 0)
>(for ((k (in-range (+ 2 n-odd) n)))
> (vector-set! v k (+ 6 (* 2 (- k n-odd 2)
>(vector-set! v (sub1 n) 4))
>   ((3)
>(for ((k (in-range n-odd (- n 2
> (vector-set! v k (+ 4 (* 2 (- k n-odd)
>(vector-set! v (- n 2) 0)
>(vector-set! v (- n 1) 2))
>   (else
>(for ((k (in-range n-odd n)))
> (vector-set! v k (* 2 (- k n-odd)))
> (define f (future odd))
> (even)
> (touch f)
> v)
> 
> (define (check v)
> (let ((n (vector-length v)))
>  (for/and ((x1 (in-range 0 n)))
>   (let ((y1 (vector-ref v x1)))
>(for/and ((x2 (in-range (add1 x1) n)))
> (let ((y2 (vector-ref v x2)))
>  (not
>   (or
>(= y1 y2)
>(= (abs (- x1 x2)) (abs (- y1 y2)))
> 
> (for/and ((n (in-range 4 100))) (check (queens n)))
> 
> (for ((k (in-range 2 9)))
> (printf "(expt 10 ~s) : " k)
> (let ((n (expt 10 k)))
>  (time (queens n
> 
> Runs fast:
> 
> (expt 10 2) : cpu time: 0 real time: 0 gc time: 0
> (expt 10 3) : cpu time: 0 real time: 0 gc time: 0
> (expt 10 4) : cpu time: 0 real time: 0 gc time: 0
> (expt 10 5) : cpu time: 0 real time: 0 gc time: 0
> (expt 10 6) : cpu time: 63 real time: 47 gc time: 32
> (expt 10 7) : cpu time: 203 real time: 140 gc time: 15
> (expt 10 8) : cpu time: 3183 real time: 2543 gc time: 1123
> 
> Times measured with DrRacket
> 
> Jos
> 
> 
> -Original Message-
> From: racket-users@googlegroups.com [mailto:racket-users@googlegroups.com]
> On Behalf Of Brian Adkins
> Sent: sábado, 12 de marzo de 2016 1:42
> To: Racket Users
> Subject: [racket-users] Sequential vs. Parallel 13-Queens program
> 
> I coded up a sequential and parallel version of N-Queens, then did a ton of
> benchmark runs of 13-Queens to compare the time. For each configuration
> (sequential or parallel w/ M workers), I ran the programs 6 times, threw out
> the high two & low two and averaged the middle two numbers.
> 
> The spreadsheet with timings is here:
> 
> https://docs.google.com/spreadsheets/d/1LFwdZbBveaARY_AquGXY9jgaSJlOA03NQCV9
> TeYQ-l8/edit?usp=sharing
> 
> The code is here:
> 
> https://gist.github.com/lojic/aef0aec491d3dc9cb40b
> 
> I didn't spend any time refining/optimizing, so it's fairly crude, but
> informative nonetheless.
> 
> The executive summary of timings for

Re: [racket-users] Setup/teardown for unit testing

[Brian Adkins]

I think you're right. Coming from a Ruby perspective, the lack of a setup 
facility seemed like a glaring omission at first glance, but I do strongly 
favor orthogonality and dislike bloat - thanks for the macro example.

> On Mar 9, 2016, at 10:53 AM, Jay McCarthy <jay.mccar...@gmail.com> wrote:
> 
> I looked at the gist you posted. I don't think it is plausible for us to add 
> something like that to the test code, because you're imagining splicing the 
> test body after the before exprs (because in your example, the before binds 
> an identifier.)
> 
> I really think you just want a slightly different test-case macro that does 
> exactly what you want.
> 
> (define-syntax-rule (brian-test-case label account . exprs)
>  (test-case label (define account (open-bank)) . exprs))
> 
> I really can't see the appeal of trying to push something into Rackunit that 
> can expand to what your example would do. It just seems so much more 
> complicated to implement and explain what it means than just putting in a one 
> line macro like this.
> 
> I feel that there is an analogy between `do`, `for`, and `let loop`. It is 
> definitely wise to not have to program every `for` loop explicitly with `let 
> loop`s, but trying to keep expanding the `for` macro to do more and more 
> towards the Lisp `do` macro is a bad move, IMHO, because it is so much more 
> complicated and non-orthogonal. It's better to make a test system that 
> integrates well with the rest of the language and to just use the language's 
> features for extensibility.
> 
> Jay
> 
> 
> On Tue, Mar 8, 2016 at 1:35 PM, Brian Adkins wrote:
> Not exactly. I'm looking for a way to run a function before *each*, of 
> possibly many, test-cases. The test-suite #:before only runs once before 
> running all the test-cases.
> 
> Although my gist: https://gist.github.com/lojic/db7016fb95b1c05e4ade 
> <https://gist.github.com/lojic/db7016fb95b1c05e4ade> only has a few 
> test-cases, if there were many, the redundancy of specifying the context each 
> time would be annoying.
> 
> What I'd really like is something similar to Elixir though, so I think I'll 
> code up that macro/function. It would be more functional to have each 
> test-case accept a context parameter, so you'd define a setup function that 
> returns a value that each test-case accepts as input.
> 
> It might look something like:
> 
> (test-suite
>   "my test suite"
>   #:setup (lambda () (open-bank))
> 
>   (test-case "initial balance is 0" account
> (check-eq? (balance account) 0))
> 
>   ...
> 
> So, the lambda specified in #:setup returns an object, account, that is 
> passed to each test-case.
> 
> I'll need to think of a reasonable syntax for it, but the idea is that each 
> test-case in a suite will have context created for it functionally.
> 
> 
> On Tuesday, March 8, 2016 at 1:17:53 PM UTC-5, Matthias Felleisen wrote:
> > Are you looking for something like this:
> >
> > #lang racket
> >
> > (require rackunit rackunit/text-ui)
> >
> > (define my-database #f)
> >
> > (define my-first-test-suite
> >   (test-suite
> >"An example suite"
> >#:before (lambda () (set! my-database '(a b c)) (displayln `(Before 
> > ,my-database)))
> >#:after  (lambda () (set! my-database #f)   (displayln `(Before 
> > ,my-database)))
> >(test-case
> > "An example test"
> > (check-eq? 1 1))
> >(test-suite "A nested test suite"
> >(test-case "Another test"
> >   (check-equal? 1 2)
> >
> >
> > Welcome to DrRacket, version 6.4.0.13--2016-03-04(-/f) [3m].
> > Language: racket.
> > > (run-tests my-first-test-suite)
> > (Before (a b c))
> > 
> > An example suite > A nested test suite > Another test
> > Another test
> > FAILURE
> > name:   check-equal?
> > location:   unsaved-editor:17:26
> > actual: 1
> > expected:   2
> > . Check failure
> > 
> > (Before #f)
> > 1 success(es) 1 failure(s) 0 error(s) 2 test(s) run
> > 1
> >
> >
> >
> > On Mar 8, 2016, at 1:14 PM, Brian Adkins wrote:
> >
> > > Jay:
> > >
> > > Here's a gist: https://gist.github.com/lojic/db7016fb95b1c05e4ade 
> > > <https://gist.github.com/lojic/db7016fb95b1c05e4ade>
> > >
> > > without.rkt is how I coded it up and with.rkt is how I'd like to be able 
> > > to code it.
> > >
> > > I agree that it's trivial to add, b

[racket-users] Re: Eliminating boiler plate for parallel tasks

[Brian Adkins]

On Saturday, March 19, 2016 at 11:45:46 AM UTC-4, Brian Adkins wrote:
> I've put together a very simple (31 lines) example of parallel task execution 
> here:
> 
> https://gist.github.com/lojic/6cee4fcd4220e2788ece
> 
> The example contains a lot of boilerplate (only a few lines are specific to 
> the problem), so before I go about eliminating the boilerplate myself, I 
> thought I'd ask if this has already been done in a general and reusable way - 
> has it?
> 
> I'm fairly new to parallel programming in Racket, but thus far I seem to 
> encounter the same pattern repeatedly:
> 
> 1) Create a pair of place channels to allow sending units of work to parallel 
> workers and retrieving results
> 
> 2) Create one place per core which repeatedly grabs a unit of work from the 
> queue, calls a function with the unit of work, and places the result on the 
> queue
> 
> 3) Write all the units of work to the queue
> 
> 4) Retrieve all the results from the queue
> 
> It think this can all be boiled down to specifying:
> 1) The name of the function to do the work (line 4)
> 2) The list of units of work (line 23)
> 
> The rest of the example is generic.
> 
> Thanks,
> Brian

This example is probably clearer:

https://gist.github.com/lojic/d92bd1f537410f6dc4e9

It's shorter, and by using place/context, I eliminated a lot of cruft. All of 
main is now generic.

-- 
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] Eliminating boiler plate for parallel tasks

[Brian Adkins]

I've put together a very simple (31 lines) example of parallel task execution 
here:

https://gist.github.com/lojic/6cee4fcd4220e2788ece

The example contains a lot of boilerplate (only a few lines are specific to the 
problem), so before I go about eliminating the boilerplate myself, I thought 
I'd ask if this has already been done in a general and reusable way - has it?

I'm fairly new to parallel programming in Racket, but thus far I seem to 
encounter the same pattern repeatedly:

1) Create a pair of place channels to allow sending units of work to parallel 
workers and retrieving results

2) Create one place per core which repeatedly grabs a unit of work from the 
queue, calls a function with the unit of work, and places the result on the 
queue

3) Write all the units of work to the queue

4) Retrieve all the results from the queue

It think this can all be boiled down to specifying:
1) The name of the function to do the work (line 4)
2) The list of units of work (line 23)

The rest of the example is generic.

Thanks,
Brian

-- 
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] Can a macro have an affect above/outside its scope?

[Brian Adkins]

On Monday, March 21, 2016 at 11:19:18 AM UTC-4, Neil Van Dyke wrote:
> I propose that it's time for `#lang racket/base` to have a `define/provide`.
> 
> (Out of all the possible combinations of definition forms and other 
> things we might often want to do with the defined identifier(s) at the 
> same time, the pair of `define` and `provide` together is overwhelmingly 
> the most common in my code.  It might even be the normal case for me 
> that `define` is usually paired with a `provide`.  Years ago, I moved to 
> putting `provide` right before the `define`, which was a win in a few 
> ways, but I always feel dumb typing "(provide foo)\n(define (foo ".  I 
> haven't wanted to make a special package dependency or new `#lang` for 
> `define/provide`; I think `define/provide` belongs in `racket/base` now.)
> 
> Neil V.

As I mentioned in my original post, I wasn't suggesting we emulate the Elixir 
behavior - I was really just curious about macro limitations :) 

`define/provide` seems a bit long to me. I also like the distinction between 
defining  a function with define and indicating export behavior with provide.

-- 
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] Can a macro have an affect above/outside its scope?

[Brian Adkins]

I've been porting my friend's Elixir code to Racket with great success. When I 
asked what the equivalent of (provide my-func) was in Elixir, they mentioned 
that you can define a private function with defp instead of def. For example:

defmodule MyModule do
  def foo(a) do
...
  end

  defp bar(b) do
...
  end
end

vs.

#lang racket
(provide foo)

(define (foo a) ... )
(define (bar a) ... )


I prefer the Racket way, but it made me curious about the possibility of a 
definep macro that would work similarly as a thought experiment. 

Is it possible to do the following?

#lang racket

(define (foo a) ... )
(definep (bar a) ... )

I'm not asking for someone to help with definep - I'm just curious about the 
possibility of a macro adding/modifying something outside of its scope. In 
other words, could a definep macro create or modify the proper (provide) 
construct to export foo and not bar ?

Thanks,
Brian

-- 
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] Re: new #lang sicp

[Brian Adkins]

On Friday, March 18, 2016 at 8:03:29 AM UTC-4, Neil Van Dyke wrote:
> Could anyone currently working through or teaching SICP please try out 
> the new `#lang sicp` support, in Jens Axel Sogaard's `sicp` package in 
> the new package system?
> 
> http://docs.racket-lang.org/sicp-manual/
> 
> If you find any problems with this, please let me and Jens Axel know.
> 
> I'd prefer to shake out any glaring problems now, before people start 
> working through SICP in the summer or September.  (I expect a few 
> problems, and I don't want them to be first encountered by new students 
> trying to do their homework, so am "crowdsourcing QA" in advance.)
> 
> I've updated my old PLaneT package 
> ("http://www.neilvandyke.org/racket/sicp/;) to point people to Jens 
> Axel's new one.
> 
> Neil V.

This is great - thanks to all who had a part in updating the package. I've had 
"work through SICP" on my list for a while, so I'll use the package when I 
start that in a couple months or so, and post any issues.

-- 
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] Can a macro have an affect above/outside its scope?

[Brian Adkins]

Sure, or just switch the semantics so p means public. I'm no concerned with the 
difficulty of public vs. private so much as adding or updating the provide from 
from a define.

On Monday, March 21, 2016 at 10:56:49 AM UTC-4, Sean Kanaley wrote:
> What if you define define as define/provide and define definep as define?
> 
> 
> That doesn't answer the question about black magic though.
> 
> 
> On Mon, Mar 21, 2016 at 10:51 AM, Brian Adkins <lojic...@gmail.com> wrote:
> I've been porting my friend's Elixir code to Racket with great success. When 
> I asked what the equivalent of (provide my-func) was in Elixir, they 
> mentioned that you can define a private function with defp instead of def. 
> For example:
> 
> 
> 
> defmodule MyModule do
> 
>   def foo(a) do
> 
>     ...
> 
>   end
> 
> 
> 
>   defp bar(b) do
> 
>     ...
> 
>   end
> 
> end
> 
> 
> 
> vs.
> 
> 
> 
> #lang racket
> 
> (provide foo)
> 
> 
> 
> (define (foo a) ... )
> 
> (define (bar a) ... )
> 
> 
> 
> 
> 
> I prefer the Racket way, but it made me curious about the possibility of a 
> definep macro that would work similarly as a thought experiment.
> 
> 
> 
> Is it possible to do the following?
> 
> 
> 
> #lang racket
> 
> 
> 
> (define (foo a) ... )
> 
> (definep (bar a) ... )
> 
> 
> 
> I'm not asking for someone to help with definep - I'm just curious about the 
> possibility of a macro adding/modifying something outside of its scope. In 
> other words, could a definep macro create or modify the proper (provide) 
> construct to export foo and not bar ?
> 
> 
> 
> Thanks,
> 
> Brian
> 
> 
> 
> --
> 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users...@googlegroups.com.
> 
> 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.

[racket-users] Setup/teardown for unit testing

[Brian Adkins]

Does RackUnit provide a facility similar to the setup & teardown functions of 
other unit testing frameworks? In other words, I'd like to execute some code 
before each test w/o coding each test to call a setup function or having to 
create my own macro given how common this is.

As far as I can tell, neither the #:before of test-suite nor the before macro 
accomplish this. In fact, I haven't been able to discern the purpose of the 
before macro because the following seem equivalent to me:

(before
  before-expr
  expr1
  expr2)

before-expr
expr1
expr2

At least with the after macro, there is a guarantee that the after-expr will be 
evaluated in the face of exceptions.

Also, as I mentioned in IRC, I just discovered that the setup function in 
Elixir (the love child of Erlang and Ruby :) returns an expression that each 
test accepts as input. This is more functional than the traditional approach of 
the setup function mutating a variable that the test cases access and allows 
the tests to run concurrently in the same file. Might be worth adding to a 
wishlist for future versions of RackUnit.

Thanks,
Brian

-- 
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] Setup/teardown for unit testing

[Brian Adkins]

Jay:

Here's a gist: https://gist.github.com/lojic/db7016fb95b1c05e4ade

without.rkt is how I coded it up and with.rkt is how I'd like to be able to 
code it.

I agree that it's trivial to add, but for something as common as "setup" and 
"teardown" for unit testing, there may be an advantage to having it in 
RackUnit. When it comes down to it, test-case, check-equal, etc. aren't hard to 
add either, but why should we all implement those.

Brian

On Tuesday, March 8, 2016 at 12:49:21 PM UTC-5, Jay McCarthy wrote:
> Hi Brian,
> 
> 
> Can you explain what you want to write? Just imagine that the feature was 
> already there... what do you want?
> 
> 
> I think of Rackunit as a way of writing checks, so if I wanted to do what 
> you're talking about, then I'd define the macro/function that you don't want 
> to. In other words, with Rackunit, you are just writing a program and it 
> provides a way to keep track of and print out individual tests, so all the 
> features of Racket are there for writing that program. There's no reason to 
> add functions, dynamic-wind, and begin blocks to Rackunit, because they're 
> already in Racket. For instance, my tests look like
> 
> 
> (define f )
> (module+ test
>  (check-equal? (f ) )
>  (check-equal? (f ) )
>  (check-equal? (f ) ))
> 
> 
> 
> and sometimes
> 
> 
> (define (f )
> (module+ test
>  (define (test-f-like-woah )
>     (check-equal? (f ) ) )
>  (test-f-like-woah )
>  (test-f-like-woah ))
> 
> 
> 
> If I had already done the second kind, then I'd put setup in there.
> 
> 
> Given that Rackunit doesn't already have an "outer" paren, each check really 
> is atomic, so any setup would be environmental, like wrapping in a 
> dynamic-wind/parameterize or just another function call before the 
> check-equal?.
> 
> 
> Now, if you REALLY want this, and I don't feel that you should, you could 
> look at current-check-around and do something like:
> 
> 
> (let ([old (current-check-around)])
>  (parameterize ([current-check-around (lambda (c) (before!) (old c) 
> (after!))])
>   (check-equal? ....)
>   (check-equal? )
> 
>   (check-equal? )))
> 
> 
> 
> This would run (before!) 3 times and (after!) 3 times.
> 
> 
> Jay
> 
> 
> 
> 
> On Tue, Mar 8, 2016 at 12:23 PM, Brian Adkins <lojic...@gmail.com> wrote:
> Does RackUnit provide a facility similar to the setup & teardown functions of 
> other unit testing frameworks? In other words, I'd like to execute some code 
> before each test w/o coding each test to call a setup function or having to 
> create my own macro given how common this is.
> 
> 
> 
> As far as I can tell, neither the #:before of test-suite nor the before macro 
> accomplish this. In fact, I haven't been able to discern the purpose of the 
> before macro because the following seem equivalent to me:
> 
> 
> 
> (before
> 
>   before-expr
> 
>   expr1
> 
>   expr2)
> 
> 
> 
> before-expr
> 
> expr1
> 
> expr2
> 
> 
> 
> At least with the after macro, there is a guarantee that the after-expr will 
> be evaluated in the face of exceptions.
> 
> 
> 
> Also, as I mentioned in IRC, I just discovered that the setup function in 
> Elixir (the love child of Erlang and Ruby :) returns an expression that each 
> test accepts as input. This is more functional than the traditional approach 
> of the setup function mutating a variable that the test cases access and 
> allows the tests to run concurrently in the same file. Might be worth adding 
> to a wishlist for future versions of RackUnit.
> 
> 
> 
> Thanks,
> 
> Brian
> 
> 
> 
> --
> 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users...@googlegroups.com.
> 
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> 
> 
> -- 
> 
> Jay McCarthy
> Associate Professor
> PLT @ CS @ UMass Lowell
> http://jeapostrophe.github.io
> 
>            "Wherefore, be not weary in well-doing,
>       for ye are laying the foundation of a great work.
> And out of small things proceedeth that which is great."
>                           - D 64:33

-- 
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] Setup/teardown for unit testing

[Brian Adkins]

Not exactly. I'm looking for a way to run a function before *each*, of possibly 
many, test-cases. The test-suite #:before only runs once before running all the 
test-cases.

Although my gist: https://gist.github.com/lojic/db7016fb95b1c05e4ade only has a 
few test-cases, if there were many, the redundancy of specifying the context 
each time would be annoying.

What I'd really like is something similar to Elixir though, so I think I'll 
code up that macro/function. It would be more functional to have each test-case 
accept a context parameter, so you'd define a setup function that returns a 
value that each test-case accepts as input.

It might look something like:

(test-suite
  "my test suite"
  #:setup (lambda () (open-bank))

  (test-case "initial balance is 0" account
(check-eq? (balance account) 0))

  ...

So, the lambda specified in #:setup returns an object, account, that is passed 
to each test-case.

I'll need to think of a reasonable syntax for it, but the idea is that each 
test-case in a suite will have context created for it functionally.


On Tuesday, March 8, 2016 at 1:17:53 PM UTC-5, Matthias Felleisen wrote:
> Are you looking for something like this: 
> 
> #lang racket
> 
> (require rackunit rackunit/text-ui)
> 
> (define my-database #f)
> 
> (define my-first-test-suite
>   (test-suite
>"An example suite"
>#:before (lambda () (set! my-database '(a b c)) (displayln `(Before 
> ,my-database)))
>#:after  (lambda () (set! my-database #f)   (displayln `(Before 
> ,my-database)))
>(test-case
> "An example test"
> (check-eq? 1 1))
>(test-suite "A nested test suite"
>(test-case "Another test"
>   (check-equal? 1 2)
> 
> 
> Welcome to DrRacket, version 6.4.0.13--2016-03-04(-/f) [3m].
> Language: racket.
> > (run-tests my-first-test-suite)
> (Before (a b c))
> 
> An example suite > A nested test suite > Another test
> Another test
> FAILURE
> name:   check-equal?
> location:   unsaved-editor:17:26
> actual: 1
> expected:   2
> . Check failure
> 
> (Before #f)
> 1 success(es) 1 failure(s) 0 error(s) 2 test(s) run
> 1
> 
> 
> 
> On Mar 8, 2016, at 1:14 PM, Brian Adkins wrote:
> 
> > Jay:
> > 
> > Here's a gist: https://gist.github.com/lojic/db7016fb95b1c05e4ade
> > 
> > without.rkt is how I coded it up and with.rkt is how I'd like to be able to 
> > code it.
> > 
> > I agree that it's trivial to add, but for something as common as "setup" 
> > and "teardown" for unit testing, there may be an advantage to having it in 
> > RackUnit. When it comes down to it, test-case, check-equal, etc. aren't 
> > hard to add either, but why should we all implement those.
> > 
> > Brian
> > 
> > On Tuesday, March 8, 2016 at 12:49:21 PM UTC-5, Jay McCarthy wrote:
> >> Hi Brian,
> >> 
> >> 
> >> Can you explain what you want to write? Just imagine that the feature was 
> >> already there... what do you want?
> >> 
> >> 
> >> I think of Rackunit as a way of writing checks, so if I wanted to do what 
> >> you're talking about, then I'd define the macro/function that you don't 
> >> want to. In other words, with Rackunit, you are just writing a program and 
> >> it provides a way to keep track of and print out individual tests, so all 
> >> the features of Racket are there for writing that program. There's no 
> >> reason to add functions, dynamic-wind, and begin blocks to Rackunit, 
> >> because they're already in Racket. For instance, my tests look like
> >> 
> >> 
> >> (define f )
> >> (module+ test
> >>  (check-equal? (f ) )
> >>  (check-equal? (f ) )
> >>  (check-equal? (f ) ))
> >> 
> >> 
> >> 
> >> and sometimes
> >> 
> >> 
> >> (define (f )
> >> (module+ test
> >>  (define (test-f-like-woah )
> >> (check-equal? (f ) ) )
> >>  (test-f-like-woah )
> >>  (test-f-like-woah ))
> >> 
> >> 
> >> 
> >> If I had already done the second kind, then I'd put setup in there.
> >> 
> >> 
> >> Given that Rackunit doesn't already have an "outer" paren, each check 
> >> really is atomic, so any setup would be environmental, like wrapping in a 
> >> dynamic-wind/parameterize or just another function call before the 
> >> check-equal?.
> &g

Re: [racket-users] Appropriate open source license for a Racket based framework

[Brian Adkins]

On Wednesday, March 2, 2016 at 12:17:55 AM UTC-5, Neil Van Dyke wrote:
> Brian Adkins wrote on 03/01/2016 11:31 PM:
> > Are there any particular license issues that I should be aware of in this 
> > regard?
> 
> I don't know.  Looks like core Racket is now LGPLv3, which is pretty 
> flexible about commercial uses.  I've been using LGPLv3 for almost all 
> of my Racket packages since around 2009, and LGPLv2-something before 
> that.  (One exception is that a financial data scraping package of mine 
> is GPL, and I also was working on a Racket firmware that was GPL.)  The 
> legal notice in the documentation of each of my packages says people can 
> contact me about alternative licenses.  In the last 13 years, I recall 
> only once someone asking about the license for one of my Racket/Scheme 
> packages, and it turned out the person was fine with LGPLv3.
> 
> Neil V.

Thanks. I've decided to go with the MIT License initially, this is *very* early 
in the process, so if a license change was deemed to be worthwhile later, it 
would be fine.

-- 
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] Racketcon talk proposal deadline

[Brian Adkins]

Sounds good - I'll try and get a talk ready for our May 19 local meetup which 
will give me time to incorporate feedback before the end of May, then I'll have 
an additional three+ months of coding prior to Racketcon.

> On Mar 2, 2016, at 1:29 PM, Vincent St-Amour <stamo...@eecs.northwestern.edu> 
> wrote:
> 
> Hi Brian,
> 
> You're way in advance. :) I'm planning to send out the call for
> proposals later this month.
> 
> We don't usually have a hard deadline, but if you could send me your
> proposal by the end of May, that would be great! Does that work for you?
> 
> Vincent
> 
> 
> 
> 
> On Wed, 02 Mar 2016 11:50:56 -0600,
> Brian Adkins wrote:
>> 
>> This is very premature, but out of curiosity, when is the deadline for 
>> submitting talk proposals for Racketcon? I'd like to use the date as a 
>> motivational tool to help me make enough progress on the web framework to be 
>> talk-worthy!
>> 
>> Thanks,
>> Brian
>> 
>> -- 
>> 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.