[racket-dev] Racket runs on 64-bit ubuntu, right?
I have a student who hasn't succeeded in running compiled-from-source DrRacket on 64-bit ubuntu. Specifically, he claims it dumps core with SIGSEGV MAPERR si_code 1 fault on addr 0x4 Aborted on startup. I have *not* tried to verify this myself, so he's almost certainly made a minor mistake. I'm writing this just in case one of you has a knee-jerk oh yeah, that doesn't work to give me. Otherwise, please ignore this e-mail. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] single-instantiation trick: kludgy workaround for planet packages?
A couple of weeks ago, you showed me the trick that rackunit uses to allow single-instantiation of a modules. I'm now trying to do this for a planet package, and it looks like I have to change the required module from being a relative to being an absolute path. That is: (require (prefix-in drlink: private/drracket-link)) must become (require (prefix-in drlink: (planet drracket-link.rkt (clements rsound.plt) private))) This works, but seems extremely fragile. Does it make sense to you that this would be required? Without it, I get the error below: namespace-attach-module: unknown module (in the source namespace): #resolved-module-path:/Users/clements/clements/planet-collects/rsound/private/drracket-link.rkt === context === /Users/clements/plt/collects/drracket/private/rep.rkt:1660:6: initialize-console method in ...cket/private/rep.rkt:508:4 /Users/clements/plt/collects/drracket/private/unit.rkt:4755:4: create-new-drscheme-frame /Users/clements/plt/collects/drracket/private/main.rkt:663:0: make-basic /Users/clements/plt/collects/drracket/tool-lib.rkt: [running body] /Users/clements/plt/collects/drracket/private/drracket-normal.rkt: [running body] /Users/clements/plt/collects/drracket/drracket.rkt: [running body] semi-happy, John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21156: master branch updated
On Sep 28, 2010, at 8:23 AM, Eli Barzilay wrote: Can we please not have this?? The whole point of having uniform names is that you can use require/provide things easily so there's no need for a library. Sure, I don't feel strongly about it. Done. To be clear, my use case is this: I'm trying to debug a seg fault in a large library, with 500 uses of 'unsafe-' operators. I want to see whether using the corresponding safe variants eliminates the crash. The global search and replace is a bit of a pain; replacing racket/unsafe/ops with racket/unsafe/safe-ops is much easier. Naturally, though, you can always roll your own as needed. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21156: master branch updated
On Sep 28, 2010, at 10:09 AM, Eli Barzilay wrote: An hour ago, John Clements wrote: On Sep 28, 2010, at 8:23 AM, Eli Barzilay wrote: Can we please not have this?? The whole point of having uniform names is that you can use require/provide things easily so there's no need for a library. Sure, I don't feel strongly about it. Done. Thanks(!) I should have clarified further -- what we have at the momemt is a consisten use of an unsafe part in the path for potentially segfaulting functionality. So having some unsafe/safe thing doesn't make much sense (and begs the question about undebugging some things with unsafe/safe/unsafe). In any case, I think that something that would have made you happier is for the `unsafe/foo' libraries to provide the same name as the safe ones. This way you'd only need to toggle the `unsafe/' prefix on or off. (I'd like that change too, but we're probably deep enough in the current setup to change that...) I thought about this, but I really like the current setup, where the unsafe-ness must be indicated at the use of the function. I think this is especially true of common primitives like vector-length. If I were debugging a piece of code, it would never occur to me that an ordinary-looking call to 'vector-length' might actually be unsafe. To be clear, my use case is this: I'm trying to debug a seg fault in a large library, with 500 uses of 'unsafe-' operators. I want to see whether using the corresponding safe variants eliminates the crash. The global search and replace is a bit of a pain; replacing racket/unsafe/ops with racket/unsafe/safe-ops is much easier. Naturally, though, you can always roll your own as needed. First, I think that what was suggested earlier should work -- changing this: (require unsafe/foo) - (require (prefix-in unsafe- foo)) This doesn't work for (require racket/unsafe/ops); that's why I wanted to add it. But the more common use case (which I've done in a number of places) is to use `foo' first, make sure the code runs and write a ton of tests, then turn the require into one that *drops* the `unsafe-' prefix. This frightens me, for the reasons I describe above. A slightly different approach is in `racket/private/sort' -- define names that are used throughout, and switch the definition from a safe one to an unsafe one. That sounds like what you described before, though perhaps I'm not understanding you. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] random-access file reading
I want to read a chunk from the middle of a 50-megabyte file. As far as I can see, there are no random-access file primitives currently in DrRacket. Also, I don't see a skip-bytes, so it looks like I should be allocating a junk buffer and then repeatedly calling read-bytes to read the skipped portion into the junk buffer. Tell me if there's a simpler way to do this; doc pointers always appreciated. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] safe version of racket/unsafe/ops?
I'm sure I'm just missing something obvious here, but is there a library that provides things like unsafe-vector-length that are actually references to the safe versions? I have a core dump occurring in (someone else's) unsafe code, and I'd much rather just import a different library than go through and take out the unsafe everywhere. I know that TR has such a library (mutatis mutandis). If it doesn't already exist, could I create racket/unsafe/safe-ops ? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] safe version of racket/unsafe/ops?
On Sep 27, 2010, at 3:45 PM, Robby Findler wrote: How about prefix-in with unsafe- as the prefix? You still have to specify the right set of functions, right? But yes, that's all I'm thinking of. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] File is really large ( 5 MB), really open?
I accidentally opened a sound file in DrRacket today; cue six minutes of thrashing and computer unhappiness. Would it be okay if I added a second-check dialog to DrRacket that checked the size of a file before opening it, and asked for confirmation before opening files larger than, say, 5MB? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] u8vector-cpointer documented but unimplemented
The function u8vector-cpointer is documented, but doesn't exist; this is presumably because the u8vector functions are actually byte-string functions, but it's not clear to me whether the absence of u8vector-cpointer is an oversight or whether it would violate abstractions in bad ways and hence simply shouldn't exist. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] File is really large ( 5 MB), really open?
On Sep 26, 2010, at 9:58 PM, Jake Eakle wrote: I would humbly suggest that this dialog should, in order of ease-to-implement a) display the size of the file, b) let the user know why they might not wish to proceed, and c) give some indication of how much memory they should probably have in order to expect reasonable performance. Sounds good to me: go for it! John Clements smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] speeding up 16-bit integer adds
I'm trying to add together big buffers. The following code creates two big fat buffers of 16-bit integers, and adds them together destructively. It looks to me like this code *could* run really fast, but it doesn't; this takes about 8.5 seconds. Changing + to unsafe-fx+ has no detectable effect. Is there allocation going on in the inner loop? I'd hoped that since an _sint16 fits safely in 31 bits, that no memory would be allocated in the inner loop. Grr! Any suggestions? (I ran a similar test on floats, and C ran about 64x faster, about a tenth of a second). Doc pointers appreciated as always, John #lang racket (require ffi/unsafe) (define (make-buffer-of-small-random-ints len) (let ([buf (malloc _sint16 len)]) (for ([i (in-range len)]) (ptr-set! buf _sint16 i 73)) buf)) (define buf-len (* 44100 2 200)) (define b1 (make-buffer-of-small-random-ints buf-len)) (define b2 (make-buffer-of-small-random-ints buf-len)) (time (for ([i (in-range buf-len)]) (ptr-set! b1 _sint16 i (+ (ptr-ref b1 _sint16 i) (ptr-ref b2 _sint16 i) smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] speeding up 16-bit integer adds
On Sep 23, 2010, at 8:16 PM, Matthew Flatt wrote: One more thought: Do you get to pick whether you use 16-bit integers or 64-bit floating-point numbers? The `flvector-' and `f64vector-' operations are inlined by the JIT and recognized for unboxing, so using flonum vectors and operations could be much faster than using raw pointers and 16-bit integers. Well, that's an option, albeit a somewhat unappetizing one; as the 44100 in my code no doubt signaled, I'm reading and writing sound data here, and both 16-bit ints and 32-bit floats are fairly common. 64-bit floats will be another factor of 2 in memory, for a total of 42 megabytes per minute. I ran some tests, using flvectors and unsafe operations everywhere. (Code below.) My tests called for 400 seconds of audio, or 282 Megabytes, and this made DrRacket flustered. Restarting and running with half that size yielded (quite variable) times between 1 and 3 seconds, so that appears about twice as fast as the fixed-point one. I'm tempted to write a little C code, but then of course I have to compile it separately for every darn platform. Thanks again for your help, John #lang racket (require ffi/unsafe racket/flonum racket/unsafe/ops) (define (make-buffer-of-small-randoms len) (let ([buf (make-flvector len)]) (for ([i (in-range len)]) (unsafe-flvector-set! buf i 0.73)) buf)) (define buf-len (* 44100 2 100)) (define b1 (make-buffer-of-small-randoms buf-len)) (define b2 (make-buffer-of-small-randoms buf-len)) (time (for ([i (in-range buf-len)]) (unsafe-flvector-set! b1 i (unsafe-fl+ (unsafe-flvector-ref b1 i) (unsafe-flvector-ref b2 i) smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] speeding up 16-bit integer adds
On Sep 23, 2010, at 9:46 PM, John Clements wrote: On Sep 23, 2010, at 8:16 PM, Matthew Flatt wrote: One more thought: Do you get to pick whether you use 16-bit integers or 64-bit floating-point numbers? The `flvector-' and `f64vector-' operations are inlined by the JIT and recognized for unboxing, so using flonum vectors and operations could be much faster than using raw pointers and 16-bit integers. Well, that's an option, albeit a somewhat unappetizing one; as the 44100 in my code no doubt signaled, I'm reading and writing sound data here, and both 16-bit ints and 32-bit floats are fairly common. 64-bit floats will be another factor of 2 in memory, for a total of 42 megabytes per minute. I ran some tests, using flvectors and unsafe operations everywhere. (Code below.) Update before going to bed; re-running the C tests with doubles everywhere and the same setup (simply adding together two big buffers) took about half a second, so in fact in this instance Racket is less that 10x slower, which is as fast as I would expect it to be. So basically, it sounds like the flvectors are the way to go, if I can stomach the memory usage. Thanks again, John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] rename + changes = bad? (was: Fwd: [plt] Push #21110: master branch updated)
Oof... it looks like doing a rename plus a few changes pretty effectively hides
those changes, though I can dig them out with 'git annotate'. Do we have a
policy (or should we have) a policy stating that you shouldn't put a rename and
modifications to that file in the same commit?
John
Begin forwarded message:
From: cleme...@racket-lang.org
Date: September 17, 2010 10:19:37 AM PDT
To: dev@racket-lang.org
Subject: [plt] Push #21110: master branch updated
clements has updated `master' from 04defa4937 to a095ebc326.
http://git.racket-lang.org/plt/04defa4937..a095ebc326
=[ 1 Commits ]==
Directory summary:
100.0% collects/test-engine/
~~
a095ebc John Clements cleme...@racket-lang.org 2010-09-17 10:18
:
| added format arg to printf to avoid corner-case printf bugs, rackety changes
:
M collects/test-engine/racket-tests.rkt |2 +-
M collects/test-engine/test-display.scm |2 +-
R collects/test-engine/{test-engine.scm = test-engine.rkt} (99%)
=[ Overall Diff ]===
collects/test-engine/racket-tests.rkt
~
--- OLD/collects/test-engine/racket-tests.rkt
+++ NEW/collects/test-engine/racket-tests.rkt
@@ -5,7 +5,7 @@
scheme/match
lang/private/continuation-mark-key
(only scheme/base for memf findf)
- test-engine.scm
+ test-engine.rkt
test-info.scm
)
collects/test-engine/test-display.scm
~
--- OLD/collects/test-engine/test-display.scm
+++ NEW/collects/test-engine/test-display.scm
@@ -6,7 +6,7 @@
framework
string-constants
test-info.scm
- test-engine.scm
+ test-engine.rkt
print.ss
(except-in deinprogramm/signature/signature signature-violation) ;
clashes with test-engine
deinprogramm/quickcheck/quickcheck)
*** See above for renames and copies ***
smime.p7s
Description: S/MIME cryptographic signature
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] rename + changes = bad? (was: Fwd: [plt] Push #21110: master branch updated)
On Sep 17, 2010, at 11:03 AM, Sam Tobin-Hochstadt wrote: On Fri, Sep 17, 2010 at 1:36 PM, John Clements cleme...@brinckerhoff.org wrote: Oof... it looks like doing a rename plus a few changes pretty effectively hides those changes, though I can dig them out with 'git annotate'. Do we have a policy (or should we have) a policy stating that you shouldn't put a rename and modifications to that file in the same commit? I believe that this is an issue with Eli's email formatting script, and not with git itself (the github diff is fine: http://github.com/plt/racket/commit/a095ebc326aa35b5b19f314080855db5d55ed49b Github seems to do a better job than 'git diff' or 'git show' with these; both of these simply showed me an entire file of lines added and an entire file of lines deleted. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Shared-instantiation modules
Seems like a FAQ, but: I want to associate a single sound player with a drscheme process. When student code runs, it needs to send messages to that sound player. I want to make sure there's only one running at a time. The first thing that pops into my head is some kind of shared-require form, but I don't see such a thing. The second thing that pops into my head is a tool; I understand how I can set up a tool so that it gets run only once at startup, and creates a value that gets associated with every DrRacket frame. Unfortunately, I can't figure out the second part of the equation: how does a user program then connect to the DrRacket frame to get the value? I don't want to make the user click some extra button every time they run their program, and I *really* don't want to mess around with language levels and manipulating the user's source code. Basically, I just want a process-level global value. I must be missing something really obvious, here. Thanks, John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Shared-instantiation modules
On Sep 10, 2010, at 8:17 PM, Eli Barzilay wrote: On Sep 10, Robby Findler wrote: FWIW, this is one path that tools can use to circumvent DrRacket's property (well, the property we work towards anyways) that no program can cause DrRacket itself to crash or freeze. So if you do provide things to the user's program in this manner, please try to keep that invariant in mind. Actually, for John's case I think that what he really needs is to be able to break more than just drracket... There was a plan at some point to have a single process-global hash table which he'd be able to use for cases where some external resource is concerned -- and this sounds like what is really needed here. For example, he'll need it if he wants to make sounds at syntax time. [This is also related to some huge and bloody flamewar on c.l.s a few years ago, re the ability to implement IO buffering in racket.] Sounds at syntax time :) I certainly hadn't thought about that, and it seems unlikely that my first-quarter students will be clamoring for it, either. Nevertheless, it's true that a process-global hash table for external resources is more or less what I was thinking about. The question is (for the moment) moot, though, because it looks like the tool interface does everything I need. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket-bug] all/11166: stepper index off by one
On Sep 7, 2010, at 6:56 AM, mlsm...@cs.vassar.edu wrote: A new problem report is waiting at http://bugs.racket-lang.org/query/?cmd=viewpr=11166 Reported by Marc Smith for release: 5.0.1 *** Description: When stepping through a program in BSL, the stepper shows current progress, e.g., 0/3, 1/3, 2/3 But since the step numbers start at 0, the progress only goes to (n-1)/n, and not n/n when the user has stepped through the entire program. I didn't notice this situation, but my students did during class, which became their first lesson in 0-based indexing (for better or worse). Thanks! Marc That was a deliberate choice, though I could be convinced that it was the wrong one; I think I was trying to mirror the behavior of the current search command. Any other opinions? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Q. about live snips
I'm writing code for beginners that produces sound values. I'd like to render these values as snips that have a start and a stop button. My first experiment looked like this: #lang racket (require racket/gui) (define f (make-object image-snip% /Users/clements/plt/collects/icons/mini-plt.xpm)) (define (g) (send f load-file /Users/clements/plt/collects/icons/j.gif)) This worked in the sense that the value was rendered graphically, but didn't work in the sense that calling (g) didn't change an already-displayed image. Viz: inline: Screen shot 2010-09-07 at 3.37.28 PM.png This suggests to me that it would be hard to implement a sound-player-snip that updated itself to display its status. My hope is that I'm wrong, and there's some easy way to make snips live in this sense. Any help greatly appreciated. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] match/fail*: re-inventing the wheel for better error messages with match?
Match is fantastic, and sometimes you want finer control over the error messages. This morning I whipped up a match/fail* macro, which successively matches against a sequence of patterns, and allows you to specify a separate fail message for each layer. It's a simple macro, and I give a use of it (my use of it) below, followed by its simple definition. FWIW, I *love* how check syntax shows the binding arrows from the pattern variables to the uses, outside of the defining clause. Is there something like this already in an existing library? If not, would this be useful to anyone? John p.s.: the use of syntax-parse in the definition of the macro was awesome, and produced at least one really nice error message for me. ;; first-line-checker : string - (or/c string symbol) ;; returns a string, indicating an error message, or 'success, ;; indicating success. (provide first-line-checker) (define (first-line-checker first-line) (match/fail* 'success [(tokenize-string first-line) `(public ,rest ...) This function signature must begin with the word \public\.] [rest `(,(? type-name? ty) ,rest ...) (format After the word public, you need a type name.)] [ty int This function's return type must be \int\.] [rest `(,pre ... ( ,args ... ) ,leftover ...) A function header must contain a pair of parentheses around the argument list.] [leftover `() There shouldn't be anything after the right-paren (\)\).] [pre `(,name) (if (empty? pre) There must be a function name between the type of the function and the argument list. The function name (a single word) is the only thing that comes between the type of the function and the argument list.)] [name getApproxAge The name of the function should be \getApproxAge\.] [args `(,arg1 ... , ,arg2 ...) You need a comma in the argument list to separate the two arguments.] [arg1 `(,arg1ty ,arg1name) The first argument should consist of a type and a name (exactly two words).] [arg1ty (? type-name? _) The first part of the first argument must be a type.] [arg1ty int The first argument should be of type \int\.] [arg1name birthYear The name of the first argument should be \birthYear\.] [arg2 `(,arg2ty ,arg2name) The second argument should consist of a type and a name.] [arg2ty (? type-name? _) The first part of the second argument must be a type.] [arg2ty int The second argument should be of type \int\.] [arg2name birthYear The name of the second argument should be \birthYear\.])) ;; the match/fail macro. ;; A use of match/fail contains a single 'success' value ;; followed by a bunch of fail clauses. Each fail clause ;; matches a value against a pattern and signals the given ;; error if it fails. If it succeeds, it goes on to the ;; next clause. Note that pattern variables bound in each ;; pattern may be used in the remaining clauses. (define-syntax (match/fail* stx) (define-syntax-class match/fail-clause #:description match/fail clause ;; pat:expr *can't* be right here... (pattern (val:expr pat:expr fail:expr))) (syntax-parse stx [(_ retval) #'retval] [(_ retval:expr clause:match/fail-clause more-clauses ...) #`(match clause.val [clause.pat (match/fail* retval more-clauses ...)] [fail clause.fail])])) smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] parallel raco setup failing on Linux machine?
On Sep 1, 2010, at 1:55 PM, John Clements wrote: I'm trying to run 'make install' on a Linux VPS, and it's halting -- at different points -- with errors that look like this: ... raco setup: made: framework raco setup: made: browser/private raco setup: made: framework/private raco setup: made: games raco setup: made: graphics raco setup: made: graphics/scribblings raco setup: made: frtime (FrTime) raco setup: made: gui-debugger match: no matching clause for (list (list (cc '(#path:frtime) #path:/home/clements/plt/collects/frtime frtime (FrTime) #procedure:info? #path:/home/clements/plt/collects #path:/home/clements/plt/collects/info-domain/compiled/cache.rktd '((lib frtime) 1 0)) scribblings... === context === /home/clements/plt/collects/racket/match/runtime.rkt:19:0: match:error /home/clements/plt/collects/setup/parallel-do.rkt:102:69 /home/clements/plt/collects/setup/setup-unit.rkt:601:17: thunk make[1]: *** [install-3m] Error 1 make[1]: Leaving directory `/home/clements/plt/src/build' make: *** [install] Error 2 ESC]0;cleme...@li21-127: ~/plt/src/build^gcleme...@li21-127:~/plt/src/build$ FWIW, this is today's commit 4c35af2eef7fe95efe89a465e221443b1b653702 . More info: the system log suggests that this is what happens when a process is killed for running out of memory (thanks, logcheck!). I'm guessing that the parallel build could observe and report this more transparently. John Here's the log, FWIW: This email is sent by logcheck. If you no longer wish to receive such mails, you can either deinstall the logcheck package or modify its configuration file (/etc/logcheck/logcheck.conf). System Events =-=-=-=-=-=-= Sep 1 16:41:58 li21-127 kernel: oom-killer: gfp_mask=0x201d2, order=0 Sep 1 16:41:58 li21-127 kernel: [c014f979] out_of_memory+0x1c9/0x200 Sep 1 16:41:58 li21-127 kernel: [c015172f] __alloc_pages+0x28f/0x310 Sep 1 16:41:58 li21-127 kernel: [c0152af9] __do_page_cache_readahead+0x139/0x2f0 Sep 1 16:41:58 li21-127 kernel: [c014a30d] __delayacct_blkio_end+0x2d/0x60 Sep 1 16:41:58 li21-127 kernel: [c04e294b] __wait_on_bit_lock+0x5b/0x70 Sep 1 16:41:58 li21-127 kernel: [c014bbc0] sync_page+0x0/0x60 Sep 1 16:41:58 li21-127 kernel: [c014bbae] __lock_page+0x7e/0x90 Sep 1 16:41:58 li21-127 kernel: [c014c812] filemap_nopage+0x2f2/0x3f0 Sep 1 16:41:58 li21-127 kernel: [c015b504] __handle_mm_fault+0x1d4/0x18a0 Sep 1 16:41:58 li21-127 kernel: [c014f217] mempool_free+0x77/0x90 Sep 1 16:41:58 li21-127 kernel: [c033704a] elv_next_request+0x12a/0x210 Sep 1 16:41:58 li21-127 kernel: [c01782f0] bio_endio+0x40/0x80 Sep 1 16:41:58 li21-127 kernel: [c038e629] do_blkif_request+0x29/0x3c0 Sep 1 16:41:58 li21-127 kernel: [c014f217] mempool_free+0x77/0x90 Sep 1 16:41:58 li21-127 kernel: [c033c23d] blk_start_queue+0x6d/0xb0 Sep 1 16:41:58 li21-127 kernel: [c038eb88] blkif_int+0x198/0x230 Sep 1 16:41:58 li21-127 kernel: [c0112127] do_page_fault+0x797/0xbb8 Sep 1 16:41:58 li21-127 kernel: [c0111990] do_page_fault+0x0/0xbb8 Sep 1 16:41:58 li21-127 kernel: [c01055df] error_code+0x2b/0x30 Sep 1 16:41:58 li21-127 kernel: Mem-info: Sep 1 16:41:58 li21-127 kernel: DMA per-cpu: Sep 1 16:41:58 li21-127 kernel: cpu 0 hot: high 0, batch 1 used:0 Sep 1 16:41:58 li21-127 kernel: cpu 0 cold: high 0, batch 1 used:0 Sep 1 16:41:58 li21-127 kernel: cpu 1 hot: high 0, batch 1 used:0 Sep 1 16:41:58 li21-127 kernel: cpu 1 cold: high 0, batch 1 used:0 Sep 1 16:41:58 li21-127 kernel: cpu 2 hot: high 0, batch 1 used:0 Sep 1 16:41:58 li21-127 kernel: cpu 2 cold: high 0, batch 1 used:0 Sep 1 16:41:58 li21-127 kernel: cpu 3 hot: high 0, batch 1 used:0 Sep 1 16:41:58 li21-127 kernel: cpu 3 cold: high 0, batch 1 used:0 Sep 1 16:41:58 li21-127 kernel: DMA32 per-cpu: empty Sep 1 16:41:58 li21-127 kernel: Normal per-cpu: Sep 1 16:41:58 li21-127 kernel: cpu 0 hot: high 186, batch 31 used:28 Sep 1 16:41:58 li21-127 kernel: cpu 0 cold: high 62, batch 15 used:51 Sep 1 16:41:58 li21-127 kernel: cpu 1 hot: high 186, batch 31 used:109 Sep 1 16:41:58 li21-127 kernel: cpu 1 cold: high 62, batch 15 used:60 Sep 1 16:41:58 li21-127 kernel: cpu 2 hot: high 186, batch 31 used:16 Sep 1 16:41:58 li21-127 kernel: cpu 2 cold: high 62, batch 15 used:45 Sep 1 16:41:58 li21-127 kernel: cpu 3 hot: high 186, batch 31 used:178 Sep 1 16:41:58 li21-127 kernel: cpu 3 cold: high 62, batch 15 used:34 Sep 1 16:41:58 li21-127 kernel: HighMem per-cpu: empty Sep 1 16:41:58 li21-127 kernel: Free pages:4908kB (0kB HighMem) Sep 1 16:41:58 li21-127 kernel: Active:60124 inactive:60041 dirty:0 writeback:0 unstable:0 free:1227 slab:3459 mapped:17 pagetables:902 Sep 1 16:41:58 li21-127 kernel: DMA free:2104kB min:88kB low:108kB high:132kB active:3612kB inactive:3500kB present:16384kB pages_scanned:11649 all_unreclaimable? yes Sep 1 16:41:58 li21-127 kernel: lowmem_reserve[]: 0 0 504 504 Sep 1 16:41:58 li21-127 kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active
[racket-dev] drdrdown?
Is DrDr down? The latest build I see on drdr.racket-lang.org is from 2010-08-25. Apologies if I missed an announcement. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket stuffs
On Aug 26, 2010, at 2:51 PM, Eli Barzilay wrote: On Aug 17, Eli Barzilay wrote: So now I have these counts: http://tmp.barzilay.org/r1.png 4 http://tmp.barzilay.org/r3.png 1 http://tmp.barzilay.org/r4.png 2 Update on this: the first version (r1 above) was by far the most popular one, and it's the one on the zazzle store now. I just got a batch of round stickers (with and without urls) and bumper stickers, and they look very nice (and they're from before the minor adjustment to the url line). This is all at: http://www.zazzle.com/elibarzilay Wait... seven dollars to ship a single bumper sticker!? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] stepper UI question
On Aug 26, 2010, at 10:59 AM, Shriram Krishnamurthi wrote: Got it. Thanks for all the inputs and for the great suggestion! A couple of comments: 1) I could very well be mis-stating his position, but I think that Guillaume felt quite strongly that the reductions should occur in the definitions window. Guillaume? 2) you describe showing steps only for non-definitions; that seems like a needless restriction. Most definitions won't have steps, but those that do should probably be step-able. This will require at least some change to Robby's click on a result suggestion, since definitions don't currently produce output text. Perhaps this is why you (Robby?) suggested excluding these. 3) It's not clear how you want to handle test cases; they don't currently generate anything in the interactions window, and yet this sounds like the thing that you're *most* likely to want to be able to step. For the sake of argument, let me propose something: the result of generate-report (the hidden summary-generation call that check-expect inserts) should be a snip that shows up in the interactions window, called (e.g.) Test Report. Clicking on this (right-clicking on this?) should open a window showing the test cases in some tabular format, indicating which ones succeeded and which ones failed. Selecting one of these, the user could choose to see its steps. Additional hidden benefit of this structure: because of the syntactic fol-de-rol that surrounds test cases, it should be fairly easy in such a tabular window to also show those test cases that didn't get run at all, because an earlier one caused a runtime error. Finally, we probably want to think a bit about what happens on a runaway computation. The current stepper handles this reasonably; it would be nice if the user could step through these computations to see what went wrong. Most of my initial thoughts on how to handle this require unpleasantly significant changes to the way that the interactions window works. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] stepper UI question
On Aug 26, 2010, at 5:23 PM, Shriram Krishnamurthi wrote: I know Guillaume proposed to do it in the context of the editor. I'm unconvinced that that's the right way to go. At any rate, integrating into an existing bit of infrastructure (def'ns or inter's) is going to be much more complex than an off-line prototype that people can critique. So we should do that regardless. You and Kathy raise good and interesting points. This tells me that there is not yet a good answer to *where* the stepper should run. I believe this is quite separable from *how* the stepper runs, ie, how it displays the sequence of expressions. Since I feel that is currently the biggest problem with it, it seems wise that we focus on the latter for now. Once we make some real progress on that high-order bit, we can see what percolates up. Do others agree that this is the high-order bit? If not (and perhaps even if so), can you articulate why? I do agree. Your original message seemed to be entirely focused on the *where* question, which I think is why it's what we've all been discussing. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Aug 17, 2010, at 4:27 PM, Jay McCarthy wrote: On Tue, Aug 17, 2010 at 2:24 PM, John Clements cleme...@brinckerhoff.org wrote: On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: We're attempting to write down coding guidelines for the project. Here is a first attempt: http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html Please comment. You write As long as your code fulfills its promises and meets each of these criteria, you can push incrementally. For example, I may be working on adding an exhaustive queue library to Racket. I imagine supporting 30 different functions across 5 different queue implementations. I don't have to wait to push until all 150 function implementations are documented, tested, and stressed. I can push whenever I make progress on each of the required points. Either this is contradictory, or I'm misunderstanding it. The first paragraph suggests that the code must meet each of the criteria; the second suggests that as long as it's *closer* to meeting the required criteria, it's fine. Maybe you can help me say it better. What I'm trying to get at is that 150 functions is perfect to me, but if I only promise 30 functions and meet the criteria for each of them, then I can commit even though it is not perfect. Progress here is meeting the 4 points for each new function I push. Okay, so every individual piece that's committed should meet the criteria. I think that's the most sensible reading of what you wrote, but it also frightens me. I don't think that very much of our current code meets these criteria, and I'm worried that trying to enforce them is going to pull us into a sinkhole of no-new-functionality. I suppose that we should write down what we want before we figure out how to get there, though. As far as this piece text is concerned, I think I would replace that last sentence with essentially what you wrote in response: For example, I may be working on adding an exhaustive queue library to Racket. I imagine supporting 30 different functions across 5 different queue implementations, for a total of 150 functions. If I have just 30 of these documented, tested, and stressed, then it's fine for me to push. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Aug 17, 2010, at 3:57 PM, Jay McCarthy wrote: We're attempting to write down coding guidelines for the project. Here is a first attempt: http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html and that you and your readers will so in the future Will so? Should that have been will also? Or do so? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Added Sierpinski example to wikipedia page
I happened upon the Racket wikipedia page again, and yet again the Hello World section made me want to cry. So I deleted it, and replaced it with the straightforward version of racket's Hello, World! program, viz.: #lang racket Hello, World! ...then I added the sierpinski example from the racket-lang front page. I'm hoping that whoever wrote this code will either not object, or change it. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] x86_64 libs not available to 32-bit ffi, right?
Reality check: I can't use the Racket ffi libraries to load 64-bit x86_64 shared libs, can I? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
On Jul 30, 2010, at 6:47 AM, Robby Findler wrote: On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay e...@barzilay.org wrote: IMO, this thing is missing the point (the usual parens, ewww! one), as long as it ignores infix. Seems to me that this point directly contradicts one of Shriram's design goals, namely showing that + is no more special than append or one of your own functions. That may be true, but it doesn't counter Eli's point, which I think is entirely valid. I had precisely the same reaction when I saw that code. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Windows test bundle 29M vs. 47M for other platforms?
On this page http://pre.racket-lang.org/release/installers/ the reported size of the Windows installer is 29M, vs. about 47 or 48 M for other platforms. I see that this was true of the 5.0 release as well, so this is probably expected, but I'm curious: why is this? Is it just that the other platforms are distributed uncompressed and rely upon dynamic compression? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] make xml structs transparent?
Is there some good reason why the 'document' and 'prolog' structures in the xml library are not transparent? In the just trying to see what's there stage of programming, it would be a lot simpler not to have to dig through them with explicit accessors. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] [scribble] rendering syntax
On Jun 9, 2010, at 5:05 AM, Sam Tobin-Hochstadt wrote:
On Tue, Jun 8, 2010 at 11:27 PM, Eric Tanter etan...@dcc.uchile.cl wrote:
Yes, Carl got my point right. And yes, that's like showing square brackets
in the stepper ;)
Right now, the two cases are slightly asymmetric, since there's a
syntax property indicating the use of [] or {}, but none indicating
the use of ', #', #`, etc. Similarly there's no syntax property
indicating the difference between (a b) and (a . (b)) (something I
once tried to fix, but gave up on).
Wait... what!?
I had no idea. Well, that's *great* news!
Next question: is there a way to push this through pretty-print? I looked for
a mechanism in the docs, but didn't find one.
Perhaps the stepper should just forget about using pretty-print. Is the
editor's indentation machinery exposed in a way that could be used by the
stepper?
John
smime.p7s
Description: S/MIME cryptographic signature
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
[racket-dev] Wikipedia page
I've taken a first crack at creating a Racket (programming language) page in wikipedia, simply by copying the first few chunks of the PLT Scheme page. This is a bit experimental, because it may be that Wikipedia has an existing mechanism for renaming, so I figured I'd just spend five minutes on it and wait for Wikipedia admins to tell me if I'm doing something redundant. FWIW, there's also a DrScheme page to update and presumably a whole pile of references to PLT scheme, membership in various categories, etc. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
