[racket-dev] Is this expected behavior?
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 context...: /usr/local/lib/racket/collects/racket/unit.rkt: [running body] standard-module-name-resolver /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! /usr/local/lib/racket/collects/racket/private/misc.rkt:87:7 I think it has to do with the new module system? - Jordan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] today's DrRacket problem
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: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket logo
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 unique.[2] 1+ (or 1!) _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] release branch compile issue
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 5.2.0.5, not 5.2.0.900 === context === standard-module-name-resolver 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: http://lists.racket-lang.org/dev
Re: [racket-dev] I/O scheduler change --- epoll(), kqueue(), etc.
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)) (thread (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)) (time (for ([i (in-range M)]) (read-byte ci) (write-byte 7 co) (flush-output co))) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
