[racket-dev] Is this expected behavior?

2012-09-17 Thread Jordan Schatz

On a freshly pulled and compiled racket:

jordan@serenity ~ racket
Welcome to Racket v5.3.0.24.
 (enter! slideshow/pict)
define-values: assignment disallowed;
 cannot re-define a constant
  constant: invoke-unit/core
  in module: /usr/local/lib/racket/collects/racket/unit.rkt
   /usr/local/lib/racket/collects/racket/unit.rkt: [running body]
   /usr/local/lib/racket/collects/mzlib/unit.rkt: [traversing imports]
   /usr/local/lib/racket/collects/texpict/mrpict.rkt: [traversing imports]
   /usr/local/lib/racket/collects/slideshow/pict.rkt: [traversing imports]
   /usr/local/lib/racket/collects/racket/enter.rkt:51:0: enter-require
   /usr/local/lib/racket/collects/racket/enter.rkt:33:0: do-enter!

I think it has to do with the new module system?

- Jordan
  Racket Developers list:

Re: [racket-dev] today's DrRacket problem

2012-03-26 Thread Jordan Schatz

On Mon, Mar 26, 2012 at 10:11:06AM -0400, Matthias Felleisen wrote:
 Many of you noticed that DrRacket v5.2.1 refused to launch today, March 26.
 We sincerely apologize for this inconvenience.
 The problem is due to a so-called Easter egg, which is a visual surprise
 that one developer builds into the code for the others and our users -- a
 tradition going back to the early days of our project. The bug affects only
 DrRacket, no other Racket software. 
 As far as version 5.2.1 is concerned, it will disappear tomorrow, but it
 will return later this year.  For the upcoming release -- due out before
 the next easter egg date -- we will either install much more reliable
 test methods for the Easter eggs or we will remove them entirely.

I vote to keep the easter eggs. Software will always break, abit of fun
does the psyche good.
  Racket Developers list:

Re: [racket-dev] Racket logo

2012-02-10 Thread Jordan Schatz
On Thu, Feb 09, 2012 at 11:04:41PM -0500, Eli Barzilay wrote:
  I prefer keeping the lambda in it.[1]  Also r is much less

1+ (or 1!)
  Racket Developers list:

[racket-dev] release branch compile issue

2012-01-10 Thread Jordan Schatz
When compiling from the release branch make install dies with:

racket/racketcgc -u \
  ./../collects/setup/unixstyle-install.rkt \
  make-install-copytree ./.. \
  /home/jordan/bin//bin /home/jordan/bin//lib/racket/collects 
/home/jordan/bin//share/racket/doc /home/jordan/bin//lib 
/home/jordan/bin//include/racket /home/jordan/bin//lib/racket 
/home/jordan/bin//share/man no
/home/jordan/racket/collects/setup/compiled/unixstyle-install_rkt.zo::0: read 
(compiled): code compiled for version, not

 === context ===

make[4]: *** [copytree-run] Error 1
make[4]: Leaving directory `/home/jordan/racket/src'
make[3]: *** [install-common-middle] Error 2
make[3]: Leaving directory `/home/jordan/racket/src'
make[2]: *** [install-3m-common] Error 2
make[2]: Leaving directory `/home/jordan/racket/src'
make[1]: *** [install-3m] Error 2
make[1]: Leaving directory `/home/jordan/racket/src'
make: *** [install] Error 2
  Racket Developers list:

Re: [racket-dev] I/O scheduler change --- epoll(), kqueue(), etc.

2011-11-11 Thread Jordan Schatz
Awesome! : )

On Thu, Nov 10, 2011 at 12:38:47PM -0700, Matthew Flatt wrote:
 I've pushed a change in the way that the Racket scheduler handles I/O.
 The new implementation should scale to a large number of network
 connections, at least on Linux and BSDs (including Mac OS X).
 Formerly, if a program had many threads each blocked on on I/O, then
 the scheduler would poll each thread separately to find one to run. At
 the OS level, that polling amounted to one select() per blocked thread.
 Now, Racket internally suspends a thread that is blocked on I/O and
 registers a callback via epoll()/kqueue() (where available). The
 callback internally resumes specific threads when I/O becomes
 available; meanwhile, the thread scheduler doesn't poll or otherwise
 consider threads that are blocked on I/O.
 Similar benefits apply when multiple I/O events are grouped together in
 a `sync'. The old implementation polled each item in the `sync'
 individually, and the new one uses epoll()/kqueue().
 I'm interested to hear whether this change has any effect on real
 uses of Racket.
 One simple benchmark is below: it creates 100 blocked UDP sockets, each
 with its own blocked thread, and then it trades 1 byte 10k times
 between two threads via TCP (which forces constant thread swaps). Even
 with only 100 blocked sockets, the new Racket is 2-3 times as fast on
 my Mac OS X and Linux machines (the latter on VirtualBox). With 1000
 blocked sockets, the new Racket takes about the same time as with 100,
 while the old Racket takes longer than I'm willing to wait.
 I've tried more realistic benchmarks, such as creating N TCP
 connections, each with a blocked thread on the server side, and then
 looping to accept M new connections (with a read followed by a close
 for each new connection). The new Racket seems to scale for large N
 while the old Racket doesn't.
 #lang racket
 (define N 100)
 (define M 1)
 (define l (tcp-listen 4 5 #t))
  (lambda ()
;; Generate stuck sockets:
(for ([i (in-range N)])
  (define u (udp-open-socket))
  (udp-bind! u #f 0)
  (thread (lambda () (udp-receive! u (make-bytes 10)
;; Time communication (server side):
(define-values (ci co) (tcp-accept l))
(for ([i (in-range M)])
  (write-byte (modulo i 127) co)
  (flush-output co)
  (read-byte ci
 ;; Time communication (client side):
 (define-values (ci co) (tcp-connect localhost 4))
  (for ([i (in-range M)])
(read-byte ci)
(write-byte 7 co)
(flush-output co)))
   For list-related administrative tasks:
  For list-related administrative tasks: