Re: [racket-dev] [plt] Push #20578: master branch updated
Just using the core of even-read didn't work. It would start to read after parse-statement had returned and then my parser would just sit there because the port wasn't returning EOF. I think it is a bug. Jay On Fri, Jun 25, 2010 at 10:44 PM, Eli Barzilay e...@barzilay.org wrote: On Jun 26, j...@racket-lang.org wrote: + ; XXX This is almost certainly wrong. + (define (even-read src ip) + (begin0 + (parameterize ([current-source-name src]) + (datum-syntax #f (parse-statement ip))) + (current-read-interaction odd-read))) + (define (odd-read src ip) + (current-read-interaction even-read) + eof) + + (current-read-interaction + even-read)) This is not just wrong -- it is likely to break things randomly. Something like -- if you happen to invoke the datalog reader indirectly (like just `read' a file in the language), you'd end up with one of these readers as a side-effect. This is exactly how the scribble/text language messed things up in a very confusing way: by banging `current-print' to do its own thing. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #20578: master branch updated
You are right. I used it and it works. Nice! Jay On Sat, Jun 26, 2010 at 4:58 PM, Robby Findler ro...@eecs.northwestern.edu wrote: It should be set by the 'configure-runtime thunk (from module-language-info), right? (I'm not sure about the bug, tho.) Robby On Sat, Jun 26, 2010 at 8:47 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Just using the core of even-read didn't work. It would start to read after parse-statement had returned and then my parser would just sit there because the port wasn't returning EOF. I think it is a bug. Jay On Fri, Jun 25, 2010 at 10:44 PM, Eli Barzilay e...@barzilay.org wrote: On Jun 26, j...@racket-lang.org wrote: + ; XXX This is almost certainly wrong. + (define (even-read src ip) + (begin0 + (parameterize ([current-source-name src]) + (datum-syntax #f (parse-statement ip))) + (current-read-interaction odd-read))) + (define (odd-read src ip) + (current-read-interaction even-read) + eof) + + (current-read-interaction + even-read)) This is not just wrong -- it is likely to break things randomly. Something like -- if you happen to invoke the datalog reader indirectly (like just `read' a file in the language), you'd end up with one of these readers as a side-effect. This is exactly how the scribble/text language messed things up in a very confusing way: by banging `current-print' to do its own thing. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] proposal: `data' collection
On Fri, Jul 2, 2010 at 5:17 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Those numbers seem pretty small in today's disk sizes, but I do agree that there is value in being able to divide up the distribution and to be able to stratify things so we can better keep track of our dependencies. I feel like I routinely download programs and dev environments where the distribution is over 100MBs. (BTW, just a random question: have you thought about trying to visualize the collection-level dependencies with, say, dot?) My student did that. It is absurd. I'll CC him to get the image. Jay It seems like you're after something that would allow multiple collections with the same name. Is that part of it, all of it, or mostly irrelevant to your main issue? Robby On Fri, Jul 2, 2010 at 1:15 AM, Eli Barzilay e...@barzilay.org wrote: [Sorry for the late reply.] On Jun 30, Matthias Felleisen wrote: Which part is a symptom? My request for a description when there's no owner? The no-owner fact? The unstable collects? All of the above. Here are some questions that can demonstrate the problem better: 1. What text would you expect to find in the purpose.txt file of `unstable'? Of `data'? 2. My course code is installed in a local collection named `pl'. Why would I need to rename it if a new `pl' module was added to the racket distribution? 3. Say that you want to install apache on your machine. What would you think if your OS tells you that you need to install powerpoint for that? 4. Assuming that there is a `data' collection with a few known data structures implemented, what happens when there's another data structure that happens to be just the thing for some project X and otherwise it's not too useful, or at least it seems that way. Why can't project X come with a new data/foo module? In any case, keep in mind that there is another way to make me stop saying coherent and package -- give up the idea of ever getting a smaller racket distribution, and the problem is solved. We won't even need the distribution specs, since everything will be included... (From my POV, this would work out great since it looks like the general attitude towards it is that it's just something that *I* choose to be concerned with, and otherwise there's no problems.) For reference, here's a table of installer sizes (the Windows one, which has the highest compression) and source bundle size (the unix one, which has the highest compression in the sources bundles), with roughly one representative per year: bin src ver year size size --- 53 1998 2.6M 103 2000 3.4M 4.6M 200 2001 4.3M 6.7M 203 2002 4.8M 6.0M 205 2003 5.8M 7.6M 209 2004 8.4M 11M 300 2005 12M 13M 372 2007 14M 15M 4.0 2008 22M 14M 4.2 2009 25M 15M 5.0 2010 28M 16M -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] internal-definition parsing
On Thu, Jul 8, 2010 at 11:19 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jul 7, 2010, at 5:55 PM, Eli Barzilay wrote: Some examples that show how useful this is: * In the lazy language you want the implicit begin to force all expressions except for the last one. * I've redefined the implicit begin (in an ugly way) for my course language to force all non-tail expressions to have a `Void' type. * The scribble/text language should really return a list of all values instead of just the last one. It currently provides `text' that builds on `begin/collect', which allows each block of consecutive definitions to be mutually recursive -- this is now a problem in that it's different in a subtle way than the default implicit begin. I think that a good goal is to have all of these uses available as simple macro definitions. If you take the lazy use as an example, then just a single `#%body' thing is not enough: since it needs to force only expressions, then having a `#%body' means that it will need to do its own crawling over the expressions to find which ones are not definitions and force them. So it looks like another special #% macro would be needed, and even that is not enough to implement the last one conveniently, since it needs to collect all non-definition expressions and combine them. 1. Three distinct examples (plus Algol, which could benefit too) sound like enough. 2. I do not understand why #%body isn't enough. Couldn't #%body locally expand to the point where defs and exps are distinguished? 3. Also, I am beginning to wonder whether the right name is #%block-begin of #%body-begin 4. The next thing to consider is whether #%module-begin and #%block-begin are truly separate features. In a sense, we now should say that modules are just bodies. Or is there a difference? #%module-begin as the top level controlling macro is a distinguishing feature. Requires and provides can only be there and you know there's only one application. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] multiple key-press
As far as I know, at the lowest level there is no multiple key press event even in the OS. If they want to do that, they should change their world to record the current key press state: (define-struct the-world (keys . everything-else)) and at the start of `on-tick' look at the collective impact of all the keys, resetting it to 'empty' when the new world is returned. That's more like how actually game engines work anyways. Jay On Thu, Jul 22, 2010 at 7:25 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: I just spoke with a room of high-school students studying Universe programming in a summer course at Brown. One major complaint was that they couldn't do multi-key-presses. For instance, they want to use WASD navigation combined with a right-side key for firing, and want to be able to fire and navigate at the same time. They've been using Shift, but the general consensus amongst the kids was this was Not Cool. Basically, they felt like they were being cheated out of building a real game. I don't know what it would take to support this. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] multiple key-press
On Thu, Jul 22, 2010 at 7:38 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: As far as I know, at the lowest level there is no multiple key press event even in the OS. Yes, that's why I had scare-quotes in my message. If they want to do that, they should change their world to record the current key press state: I told them that. But the problem is that inversion of control makes the world structure and its logic *significantly* uglier. We could change world/universe to automatically do this batching of key presses and have an interaction-rate similar to the tick-rate. I'm not sure THAT would be much better, but it would be less tedious, etc. Jay I have considered this issue. I decided that these kinds of kids should be introduced to Universe programs as opposed to World programs. That's way cooler than silly one-keyboard games. Doom is silly? Duke Nukem 3D is silly? Perhaps you do indeed know a great deal about games. But perhaps you have a more limited understanding of your audience. Shriram -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #20751: master branch updated
This commit finishes adding 'define-datatype' and 'match' to ASL per Shriram's request. I'd like comments and improvements on a few things: 1) The documentation -- most of the ASL docs are very vague, presumably because the book covers it, but in this case that's not true 2) The subset of match supported 3) The way I've prevented escaping to the larger part of ASL. Jay On Thu, Jul 22, 2010 at 3:40 PM, j...@racket-lang.org wrote: jay has updated `master' from 9eb053d4db to 407dcee206. http://git.racket-lang.org/plt/9eb053d4db..407dcee206 =[ 2 Commits ]== Directory summary: 45.5% collects/lang/private/ 15.2% collects/scribblings/htdp-langs/ 38.1% collects/tests/racket/ ~~ eeada45 Jay McCarthy j...@racket-lang.org 2010-07-22 15:12 : | Fixing error string : M collects/lang/private/teachprims.rkt | 2 +- ~~ 407dcee Jay McCarthy j...@racket-lang.org 2010-07-22 15:39 : | Adding match to ASL : M collects/lang/htdp-advanced.rkt | 1 + M collects/lang/posn.rkt | 1 + M collects/lang/private/teach.rkt | 133 - M collects/scribblings/htdp-langs/advanced.scrbl | 48 +++- M collects/tests/racket/advanced.rktl | 96 +++ M collects/tests/racket/bega-adv.rktl | 10 -- M collects/tests/racket/beg-adv.rktl | 7 - =[ Overall Diff ]=== collects/lang/htdp-advanced.rkt ~~~ --- OLD/collects/lang/htdp-advanced.rkt +++ NEW/collects/lang/htdp-advanced.rkt @@ -48,6 +48,7 @@ [advanced-when when] [advanced-unless unless] [advanced-case case] + [advanced-match match] [advanced-delay delay] [advanced-module-begin #%module-begin] ) collects/lang/posn.rkt ~~ --- OLD/collects/lang/posn.rkt +++ NEW/collects/lang/posn.rkt @@ -4,6 +4,7 @@ ;; The posn struct for the teaching languages (provide struct:posn make-posn posn? posn-x posn-y set-posn-x! set-posn-y! + (rename-out (posn posn-id)) (rename-out (posn-signature posn))) (struct posn (x y) #:mutable #:transparent) collects/lang/private/teach.rkt ~~~ --- OLD/collects/lang/private/teach.rkt +++ NEW/collects/lang/private/teach.rkt @@ -49,7 +49,10 @@ (rename deinprogramm/quickcheck/quickcheck quickcheck:property property) test-engine/scheme-tests scheme/class - (only lang/private/teachprims beginner-equal? beginner-equal~?)) + ../posn.rkt + (only lang/private/teachprims + beginner-equal? beginner-equal~? + advanced-cons advanced-list*)) (require-for-syntax teachhelp.ss teach-shared.ss syntax/kerncase @@ -209,6 +212,7 @@ advanced-begin advanced-begin0 advanced-case + advanced-match advanced-shared advanced-delay) @@ -2520,6 +2524,133 @@ (with-syntax ([clauses clauses]) (syntax/loc stx (case v-expr . clauses)] [_else (bad-use-error 'case stx)] + + ;; match (advanced) + (define (advanced-match/proc stx) + (ensure-expression + stx + (lambda () + (syntax-case stx () + [(_) + (teach-syntax-error + 'match + stx + #f + expected an expression after `match', but nothing's there)] + [(_ expr) + (teach-syntax-error + 'match + stx + #f + expected a pattern--answer clause after the expression following `match', but nothing's there)] + [(_ v-expr clause ...) + (let ([clauses (syntax-list (syntax (clause ...)))]) + (for-each + (lambda (clause) + (syntax-case clause () + [(pattern answer ...) + (let ([pattern (syntax pattern)] + [answers (syntax-list (syntax (answer ...)))]) + (check-single-expression 'match + for the answer in a `match' clause + clause + answers + null))] + [() + (teach-syntax-error + 'match + stx + clause + expected a pattern--answer clause, but found an empty clause
Re: [racket-dev] Release Announcement for v5.0.1
On Fri, Jul 23, 2010 at 6:19 PM, Eli Barzilay e...@barzilay.org wrote: Some suggested items below, if you have items, please mail me text that describes those that you think should be mentioned, and verify that the rest should not. -- Matthew: * sha1 functionality (default from openssl, also a racket implementation) * `racket/foreign' (or `scheme/foreign') + `unsafe!' moved to `ffi/unsafe', more ffi reorganization (mostly 4acba84b, b7c18463) * Maybe also `struct' and related changes (new definition, struct name as the constructor)? * async-apply support in the FFI. (768a3721) * full continuations can escape past a continuation barrier (49ad3096) * internal-definition contexts allow expressions mixed with definitions; the new `#%stratified-body' form can be used for bodies without this feature. (54216b5c) * New subprocess support in custodians (`current-subprocess-custodian-mode', `subprocess-group-enabled') * Additional flonum operations with unsafe variants. * The racket value printer uses constructor+quote style; update Guide and Quick. * `in-directory'. * `racket/set'. * Improved regexp stuff? * Chaperones (73807aef) * (an extensible) `raco' replaces setup-plt, mzc, etc. * `eprintf' and `displayln' Kevin: * Parallel build Sam/Vincent: * Types for fixnums, flonums, etc? Anything else? Robby: * radial-star? flipping bitmaps? Jay: * Datalog, Racklog, sexper variant of first, prolog variant of second. Datalog - A lightweight deductive database system with Racket integration is available in the `datalog' package and with `#lang datalog'. Racklog - Prolog-style logic programming in Racket, adapted from the Schelog package, is in the core * `formlet*'? (Maybe also 7b61ba02?) web-server/formlets adds a 'formlet*' form that allows dynamic formlet construction, as opposed to 'formlet' which requires syntactic Xexprs and static formlets. A few new library formlets are available as well. * Teaching language extensions, if they're included in the release (possibly only for the edu message) The Advanced Student Language now supports hash-table primitives, `define-datatype' for defining sets of related structs, and `match' for pattern matching. Ryan: * Any public (and documented) syntax/parse macro debugger additions? * macro-debugger/emit? * GUI for rackunit? Casey: * Redex news? Eli: * `generator' required to be (generator () body ...), due to planned extensions. Stevie: * Contract news? (eg, a57b0d81, 24c5a9ae, 99bb46d2) [Note that mirror sites can take a while to catch up with the new downloads.] Feedback Welcome, -- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
Basically, CPAN is a way of distributing and finding tarballs that have Perl code it in. The CPAN tool installs these things into a system or user directory of collects. People have written Perl modules that overload the module lookup to find and download new CPAN packages if necessary. If PLaneT worked the same way, it would just be a way of distributing our .plt files. We'd have a more powerful planet tool to deal with these. Instead, we make the syntactic difference YC mentions. -- If PLaneT didn't work this way, then when I have a file that reads (require ds), it isn't meaningful without additional information about what packages ( versions thereof) should be installed before compiling and running it. One argument in favour of how PLaneT currently works is that this additional information is in the language (something I see as a design principle behind Racket) because we instead write (require (planet nintendo/ds)). Thinking about the location of this additional information points to me that we currently have only internal linking of packages. I can imagine an external linkage where, for example, the nearest info.rkt file specified what packages needed to be installed. [Perl modules have something similar to that actually.] Jay On Tue, Jul 27, 2010 at 8:06 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I looked at the message where you link and I didn't see how one would go about this. I guess the idea is that you'd eliminate the syntactic difference between a planet-located library and one in the distribution and then require on some external source to know where the package is located? Something like that? How would that work? Robby On Tue, Jul 27, 2010 at 8:17 PM, YC yinso.c...@gmail.com wrote: IMHO planet works very well and shouldn't have issue to scale beyond a few thousand packages if it ever gets to that point. However, to get there I believe planet first needs one major upgrade - it needs to become location transparent - meaning that requiring modules in COLLECTS and PLANET look exactly the same from code perspective. With this change the invisible cultural divide between planet and core distribution will disappear, and core team can tap into the work of module developers, which in turn will help module developers feel more involved in the community - the virtuous cycle can then be built to gain momentum to increase the community. I have discussed the issues in detail back in January in the thread http://lists.racket-lang.org/users/archive/2010-January/037703.html - and love to discuss further if others are interested. Cheers, yc On Tue, Jul 27, 2010 at 2:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
I think we can and must improve the browsing, searching, rating, etc parts of PLaneT. There's no shame in copying Hackage, CPAN, etc on these areas because they are probably very wise in their decisions. I would like to make DrDr build and test every PLaneT package on some basis (perhaps when the version number changes), but I'll have to make DrDr capable of running untrusted code to do that and there's the can of worms related to system dependencies. Jay On Tue, Jul 27, 2010 at 3:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
Look up the 'paren-shape stx property.
Jay
On Wed, Jul 28, 2010 at 12:17 PM, Shriram Krishnamurthi s...@cs.brown.edu
wrote:
That does sound like the right level, in that this isn't a new
language -- by design.
I started out by trying to create a new syntax; then I realized I
didn't need to; then that I didn't *want* to. By then I was locked
into this file structure and didn't come up for air. I probably
didn't peel off enough layers.
Before I can move forward, I still need to resolve the syntactic
ambiguity. As I understand it, Racket doesn't give me enough
information to distinguish {...} from (...) from [...]. Is that right
and, if so, is there any chance that will change? [Zodiac did that
-;.] I don't want a solution that looks like go look in the MrEd
buffer for I'd rather not do a reader extension for it because
the extra keystrokes will add up.
Shriram
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay
The glory of God is Intelligence - DC 93
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
At first I thought, how is this different than Honu?
If this isn't a reader, I don't see it being fundamentally different
from Honu. (Many of the same ideas are recreated, actually. The macro
slack term, for example, is exactly what Jon does.)
I think there is a place for a non-sexp reader like the @ reader, but
optimized for something other than text. But I don't like P4P's ad-hoc
set of special keywords like defvar: etc rather than a uniform rule.
If the parser has to know about these, then P4P is not extensible in
the same way as the sexp or @ readers.
A constructive suggestion: treat a trailing : as a special parser cue,
treating {s specially, taking the meaningful indentation ideas, etc.
Jay
On Wed, Jul 28, 2010 at 11:45 AM, Shriram Krishnamurthi s...@cs.brown.edu
wrote:
I've been vexed for a while about parenthetical syntax: I love it,
appreciate what it offers, but also recognize that no amount of
teaching or arguing alters how people perceive it. With the switch to
Racket, and our continuing interest in user interface issues, I
believe it is wise to consider an optional alternate syntax.
I finally had a breakthrough last weekend on how to create a syntax
that may be more palateable without losing the essence of
parenthetical syntax. As a preview, it does incorporate indentation,
but in a good way. You'll see.
Feedback welcome. The most important is whether you spot any flaws
regarding predictable parsing.
Here's a *non-permanent* URL where you can learn more:
http://www.cs.brown.edu/~sk/tmp/P4P/
Shriram
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay
The glory of God is Intelligence - DC 93
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Regher continues his excellent tutorial on undefined behavior language specifications
Creating a large piece of safety-critical or security-critical code in C or C++ is the programming equivalent of crossing an 8-lane freeway blindfolded. On Fri, Jul 30, 2010 at 12:39 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Here's parts 2: http://blog.regehr.org/archives/232 and 3: http://blog.regehr.org/archives/226 and if you missed part 1, you should really check it out: http://blog.regehr.org/archives/213 Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
On Mon, Aug 2, 2010 at 4:31 AM, Eli Barzilay e...@barzilay.org wrote: On Aug 2, Matthias Felleisen wrote: On Aug 2, 2010, at 6:11 AM, Eli Barzilay wrote: And for the (near) future -- figure out what's happenning in the teaching languages. I get the impression that things are moving there almost randomly. No, this isn't random; it is unsynchronized: (Yeah, I used random in a random sense...) -- Shriram asked Jay to add define-datatype (and hashes? was there more?) define-datatype, match, hashes These are the commits: http://github.com/plt/racket/commit/407dcee206678785b4b87bb513d7ba5f55ad8ab5 http://github.com/plt/racket/commit/eeada45868d73c02b59f5c1ecd16e414d5a114ac http://github.com/plt/racket/commit/9eb053d4db1efd2881e1f749ad6b1eb12a6e8152 -- Robby, Mike, and I decided to move signatures into BSL, ... but I underestimated when I'd get to the translation of the documentation So: 1. I propose to release as is: no addition to ASL, no docs for signatures 2. I propose to sync at PLT Day, in person. OK -- that leaves messes #1 (are Jay's changes included or not?) and #2 (test it properly) to sort out. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
We should try to make sure that only commit messages from commits in the release branch are considered for the release notes process. Do we a script that does it or does someone pick through them manually? Jay On Mon, Aug 2, 2010 at 1:14 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Eli: are you saying that those commits were not included in the testing bundles? If so, why do we need to re-run the release tests? (Or is there something else?) Robby On Mon, Aug 2, 2010 at 2:12 PM, Eli Barzilay e...@barzilay.org wrote: On Aug 2, Jay McCarthy wrote: On Mon, Aug 2, 2010 at 4:31 AM, Eli Barzilay e...@barzilay.org wrote: On Aug 2, Matthias Felleisen wrote: On Aug 2, 2010, at 6:11 AM, Eli Barzilay wrote: And for the (near) future -- figure out what's happenning in the teaching languages. I get the impression that things are moving there almost randomly. No, this isn't random; it is unsynchronized: (Yeah, I used random in a random sense...) -- Shriram asked Jay to add define-datatype (and hashes? was there more?) define-datatype, match, hashes These are the commits: http://github.com/plt/racket/commit/407dcee206678785b4b87bb513d7ba5f55ad8ab5 http://github.com/plt/racket/commit/eeada45868d73c02b59f5c1ecd16e414d5a114ac http://github.com/plt/racket/commit/9eb053d4db1efd2881e1f749ad6b1eb12a6e8152 (For future references, the sha1 is all that is needed.) None of these commits are included. This leaves the last mess: running proper tests. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] experiment of the unified require syntax == Re: haskell's 'hell of a lot of libraries', planet
your own internal packages now. When multi-repo becomes available, you can still use bzlib/planet to host your own repo. On Wed, Jul 28, 2010 at 7:03 AM, Dave Gurnell d.j.gurn...@gmail.com wrote: I'd personally be in favour of a leaner core distribution with more code in external packages, so I can choose what I download when I'm only interested in a single web application. Once the collects and planet require syntax are unified - moving the currently-core packages to planet will become a snap. At that time it might even be possible to have build your own distribution by picking your own packages. On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke n...@neilvandyke.org wrote: Then, somehow I would like to prevent packages in the contributed repository from overriding those in the core and internal repositories. Guaranteeing this through naming, like Java packages, is one way, though that could be cumbersome. Now I think about it, it might make sense to have local repo able to overwrite core repo in case you want to patch the core code. In that case the module resolve I proposed earlier would have to be changed to: Try lookup the package in planet cache If #1 fails, lookup in COLLECTS If #2 fails, try lookup the package in planet repo On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke n...@neilvandyke.org wrote: Package signing to authenticate the packager still seems useful, like it did in the beginning, but that could be revisited in context of whatever other improvements are made. I like what ASDF has to offer here. The only thing I would add is that this auth mechanism should be optional (perhaps as a policy per repo). All my additional 2 cents. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] RFC: Coding Guidelines
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. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
It may be a typo in the source material. http://www.ccs.neu.edu/home/matthias/HtDP2e/prologue.html#(part._not) On Tue, Aug 17, 2010 at 2:21 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 and that you and your readers will so in the future Will so? Should that have been will also? Or do so? John -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
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. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
I hope I've incorporated much of the feedback from this thread: http://faculty.cs.byu.edu/~jay/tmp/201008161509-guidelines.html Jay On Thu, Aug 19, 2010 at 8:14 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Yes. I started using the phrase I have bug reports, therefore I exist at Rice. I think Jay should add this phrase right next to the other quote. On Aug 19, 2010, at 10:03 AM, Robby Findler wrote: Guys: we need one more thing to go into the beginning of these guidelines. Specifically, we should say (something like) Bugs are something to be proud of; not to be ashamed of. the rationale being that there are always bugs, but if they are unknown bugs then it means your software is not being used. It is the way we choose to fight our bugs that determines our character, not their presence or absence. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] collects descriptions
On Aug 22, 2010, at 10:23 PM, Jon Rafkind rafk...@cs.utah.edu wrote: Can someone provide me a somewhat brief description of what the following directories in the collects/ tree contain? * scribble The implementation of scribble * scribblings The documentation for most of the core system (guide, reference, htdp langs, etc) * scriblib Auxiliary scribble libraries, they have their own documentation linked from the top level I have a vague impression but I don't understand the whole picture.. I think someone (Matthias?) requested a README file for each collect directory, I could put the information provided in such a file for each of these directories. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev Jay PS I am up because my daughter was just born. Naturally I thought to respond to a mailing list post. :P _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] hashes in ASL
What documentation are you looking at? http://docs.racket-lang.org/htdp-langs/advanced-prim-ops.html#(part._(lib._htdp-advanced..ss._lang)._.Hash_.Tables) As far as the immutable functions, when I sent you the list of the functions I intended to add, those were not on it. They were intentionally left out to make the addition smaller and simpler. They can be added if you think it is important. [Ditto with your previous email about the optional argument to the constructors. I was waiting to respond with Done.] Jay On Tue, Aug 24, 2010 at 10:09 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Hashes seem to have been added to ASL in a haphazard way. For some reason the MUTABLE hash operations are present, but not the IMmutable ones. Also, the docs don't seem to reflect their existence. Anyone? (Jay, did you push this?) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] require sub-forms
There is not now but we could make a module that only exported them so you could provide all-from-out it and thus centralize the list of subforms. That's the cleanest idea I have. (You don't want to hear my really bad ideas) Jay Sent from my iPhone On Aug 24, 2010, at 8:46 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Is there a way to say give me all the require sub-forms instead of having to enumerate them explicitly: (provide require only-in except-in prefix-in rename-in combine-in only-meta-in for-syntax for-template for-label for-meta) thereby missing some in future extensions of the base language? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] gc vs assignment
On Tue, Aug 24, 2010 at 3:47 PM, Neil Toronto neil.toro...@gmail.com wrote: Matthias Felleisen wrote: Catching up with some mail. Neil wrote: Avoiding allocation reduces GC collects, which reduces stutters and hitches. My (possibly old) understanding of GC and mutation tell me that this is one of those prejudices that programmers should get rid of. Every mutation goes across an access barrier in a GC like ours and can thus be much more expensive than a lightweight allocation. This was certainly true for early generational collectors. I do know that the hordes of Java programmers who invaded GCLand forced GC builders to make C/C++-like programs in Java work reasonably fast with collectors and so collectors changed. In my defense, I was talking about framerate, not total or average cost of memory management. A GC pause in my game test app lasts 50ms to 200ms, which causes a hitch: a noticeable, temporary drop in framerate and responsiveness, in this case down to 20Hz to 5Hz. For comparison, 60Hz is an ideal minimum. A sequence of minor hitches is a stutter; sometimes Racket's GC pause causes those as well. Inflicting hitches on users in a twitch game is a cardinal sin. In non-twitch games they are eye-wrenching, especially when everything else is smooth. Games are really almost real-time apps. Totally disagree. Here's a crazy forum where you will find people complaining about how a recent release (DeathSmiles - North America for Xbox360) is garbage because there isn't ENOUGH slowdown as compared to the Japanese 360 or XBox release: http://www.aksysgames.com/forums/topic/732 I do agree that you personally don't want a drop in frame rate and that the GC gets in your way of achieving that goal. Jay I'm still doing the game universe-style, so I haven't moved to mutation yet. I'm halfheartedly considering it. I'll probably try an allocation pool of same/similar-sized arrays first. I'd gladly pay half of my ideal 16ms per frame to eliminate hitches. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] futures waiting for scheme_make_envunbox
On Wed, Aug 25, 2010 at 8:07 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Aug 25, 2010 at 9:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 25 Aug 2010 09:42:40 -0400, Sam Tobin-Hochstadt wrote: While trying to use futures to parallelize a simple piece of code, I was able to remove all of the waiting except for this: future: 3 waiting for runtime at 1282743524205.783936: [scheme_make_envunbox] which happens continuously. What causes this function to be invoked, and how can I eliminate it? It happens when initializing a local variable that is assigned via `set!'. Probably we should inline scheme_make_envunbox() in JIT-generated code. Ok, that's kind of surprising. It seems that Typed Racket's optimizer is transforming the program in such a way that the bytecode compiler inserts `set!' where it wasn't before. I've attached the relevant file (which is just TR applied to the mandlebrot example from the futures paper). When the #:optimize keyword is used, the futures wait on `scheme_make_envunbox'. When it isn't used, there's much less waiting (just allocation and jitting). Unfortunately, trying to decompile this file produces an error in the decompiler: [sa...@punge:~/tmp plt] raco decompile mandelbrot.rkt hash-ref: no value found for key: 1128 Blake will see if this is a bug fixed in our local changes or something else he should fix and he'll send you the decompiled result in either case. Jay so it's hard to tell exactly what's happening. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] require sub-forms
On Wed, Aug 25, 2010 at 8:18 AM, Eli Barzilay e...@barzilay.org wrote: On Aug 25, Jay McCarthy wrote: On Tue, Aug 24, 2010 at 10:18 PM, Eli Barzilay e...@barzilay.org wrote: On Aug 24, Jay McCarthy wrote: There is not now but we could make a module that only exported them so you could provide all-from-out it and thus centralize the list of subforms. That's the cleanest idea I have. This assumes you want only the core ones, and not things that are defined in other libraries (like in `racket/require'). (You don't want to hear my really bad ideas) (#rx-in$ ?) That's not my bad idea, which might not be so bad actually. I'm imagine a new require/provide transformer that names sets of exports: in require/provide.rkt : (define-export-set require-sub-forms only-in except-in ...) (define-export-set provide-sub-forms all-defined-out all-from-out ...) ; These expand to static information [...] But it won't be a solution to the problem, because these definitions would appear in a place that is not where they were made -- so when a new form is added to the core language, someone needs to remember to update these export sets wherever they're defined. So it looks much better to me to put the sets where the forms are defined -- but that's practically the same as your earlier suggestion to organize the code so that the bindings all conveniently come from a single module. (My other guess was something like `filtered-out' that checks the bindings and filters only those that have a value that is the right kind of transformer -- but I'm not sure that this can work.) I agree that it's basically the same when done right, which is why I initially suggested the simpler solution. I think the one benefit of these export sets is that they make it a language abstraction rather than a convention of where to put files. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] hashes in ASL
This change will be pushed momentarily. Jay On Sat, Aug 21, 2010 at 7:04 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Why does make-hash require one argument, rather than just taking zero like make-hash in Racket does? ASL is anyway a language with state, so it's perfectly meaningful to create an empty hash table and update it. Furthermore, many algorithms begin with an empty hash table. This argument strikes me as entirely gratuitous...but maybe there's some bigger picture of ASL I'm missing. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] hashes in ASL
Just pushed an update with optional argument constructors and immutable hash operations. Jay On Tue, Aug 24, 2010 at 11:36 AM, Jay McCarthy jay.mccar...@gmail.com wrote: What documentation are you looking at? http://docs.racket-lang.org/htdp-langs/advanced-prim-ops.html#(part._(lib._htdp-advanced..ss._lang)._.Hash_.Tables) As far as the immutable functions, when I sent you the list of the functions I intended to add, those were not on it. They were intentionally left out to make the addition smaller and simpler. They can be added if you think it is important. [Ditto with your previous email about the optional argument to the constructors. I was waiting to respond with Done.] Jay On Tue, Aug 24, 2010 at 10:09 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Hashes seem to have been added to ASL in a haphazard way. For some reason the MUTABLE hash operations are present, but not the IMmutable ones. Also, the docs don't seem to reflect their existence. Anyone? (Jay, did you push this?) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] drdrdown?
Over the past few weeks, it has been stalling during the git fetch. The process tree looks like this: 5907 ?S 0:00 \_ /usr/bin/git fetch http://git.racket-lang.org/plt.git 5908 ?S 0:00 \_ git-remote-http http://git.racket-lang.org/plt.git http://git.racket-lang.org/plt.git 5911 ?S 0:00 \_ git fetch-pack --stateless-rpc --lock-pack --thin --no-progress http://git.racket-lang.org/plt.git EAD 5912 ?S 0:00 \_ git fetch-pack --stateless-rpc --lock-pack --thin --no-progress http://git.racket-lang.org/plt.git EAD I'll have to spend some time debugging it on Monday. [If anyone knows why it would stop at that point, I'd like to know.] This output might be from git: error: RPC failed; result=56, HTTP code = 200 I've manually restarted it so it should be fine until I can debug again. Jay On Sat, Aug 28, 2010 at 10:25 AM, John Clements cleme...@brinckerhoff.org wrote: 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] relationship between define-struct and struct
The student languages have a completely separate implementation of define-struct from Racket. [lang/private/teach.rkt: do-define-struct: line 716 For a reason unknown to me, the struct type descriptor [line 805] returned by make-struct-type does not get defined (although it does check to make sure it could be defined.) [line 931] I'm not entirely sure why this is although I anticipate that is has to do with the fact that such a value has no worth in *SL, because there are no operations on it. Thus it would be very awkward in the docs to say that a thing is defined with define-struct that has no meaning to students. Since struct-out expects this thing to be defined, it errors. It is a bit awkward that the error suggests that it should have been imported, rather than defined in the file. Jay On Sat, Aug 28, 2010 at 1:23 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: What is the relationship between define-struct and struct in Racket 5.0.1? By define-struct I mean the construct provided in ASL. In my custom language I have (define-struct tv (tag value)) (provide (struct-out tv)) and I get the error struct-out: no import for structure-type identifier in: struct:tv Is this because define-struct suppresses the struct:tv structure-type information? (If so, why?) ((And if so, is there a way to make struct-out work shy of copying the implementation of define-struct and adding/removing the line that hides this?)) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] raco dwim
This seems like a coherent thing for it to do, but not something that I would personally use. I don't think I'd use it or like having it there because the more complicated the algorithm it uses to choose what to run, the more complicate the algorithm I run in my brain to predict what it will do has to be. Basically, I think I am likely to make mistakes this way. As an aside, I thought we talked about this back when 'raco' was created about whether it should also serve as 'racket'. Jay On Fri, Sep 10, 2010 at 5:42 AM, Eli Barzilay e...@barzilay.org wrote: I'm revising my course content now, and I ran into the change that Robby committed a while ago to `raco setup' where it no longer installs plt files by default. I didn't know what would be the best thing to do with it, but I think that there's no problems keeping such instructions with setup-plt -- since the files are still .plt files. But when I was thinking about that, I reazlied that since `raco' looks for the first unambiguous prefix, it's doing a kind of a dwim search. So why not go the whole way? Running raco with some string can: * Run the specified command if there is one. * If it specifies a valid (symbolic) require, require it (as in `racket -l') -- a `foo' collection is effectively defining a `raco foo' command, and the same for `foo/bar'. * If it specifies an existing filename that looks like - *.rkt, require the file (as in `racket -u') - *.rktl, load the file (as in `racket -r') - *.plt (possibly more than one), install it [Otherwise it can look in the file for some magic header and decide what to do (#lang = require it, some future magic string for a package file = install it), but this might be a bad idea: sticking to a .suffix means that it can be made reliable if raco commands cannot use . or .suffix for the few knowns suffixes.] * If something was required (through a symbolic require path or *.rkt), and if doing so provided a `#%top-interaction' binding, then start a repl. (Or do that with a language configuration option.) ? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21079: master branch updated
I didn't see any data/heap tests. Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] the new `racket/gui' --- now with bug reports
The other URL is fine, it gives you all the github information about the repo (commit log, browser, etc), whereas the .git is the thing that you give to the git command line. Jay On Tue, Sep 14, 2010 at 5:03 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Sun, Sep 12, 2010 at 11:40 AM, Matthew Flatt mfl...@cs.utah.edu wrote: The code is still hosted here: http://github.com/mflatt/gr2 This should be http://github.com/mflatt/gr2.git I believe. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket documentation
contain an implementation of a new function that adds the functionality people might be looking for but that isn’t in the API already. Users gradually approach reasonable information, and thus the comments become a good source. They even explore potential bugs or use cases beyond the examples and corner cases. On the whole, from reading PHP documentation one can quickly understand a function with its descriptions and examples, hone in on the function one really wants with lists of similar functions, warnings, and user comments, and gain a better understanding of tricky or missing features with user discussion. This results in a community that can work very efficiently even when they don’t already know (or don’t remember) the function they need or details of how it works. Thus many people can quickly learn how to use PHP. Conclusion Prior to comparing Racket to PHP, I always thought it would be nice to have examples given for every function. I believe that in addition to this, there should be a user comments section. This section will eventually provide data on common pitfalls, similar functions, desired functionality, etc. that the core team can take into account both to improve their documentation and the Racket API itself. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] safe version of racket/unsafe/ops?
In principle I think it is a good idea, though I expect me and others will quibble over any name you pick. Jay On Mon, Sep 27, 2010 at 4:04 PM, John Clements cleme...@brinckerhoff.org wrote: 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] random-access file reading
I think you want file-position http://docs.racket-lang.org/reference/port-buffers.html#(def._((quote._~23~25kernel)._file-position)) Jay On Tue, Sep 28, 2010 at 3:15 PM, John Clements cleme...@brinckerhoff.org wrote: 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] ffi vectors
Okay. I'm kind of glad that I came up with the normal thing.
I'll put it on my infinitely long list of TODO items to come back and
extend the ctypes so that they can specify both aspects of their size.
Jay
On Thu, Sep 30, 2010 at 7:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I guess I misunderstood what you were looking for.
It would be nice to have a compact ctype that adapts like the C array
type to different contexts. For my FFI tasks, I've gotten by with
structure types like `_float4'; I manually choose between `_float4' or
`_float4-pointer' as needed in different contexts (the former for
`malloc' or a struct member, the latter for a function argument or
result). That strategy was was particularly awkward for a struct that
contained an array of 32 bytes, though.
At Thu, 30 Sep 2010 17:19:43 -0600, Jay McCarthy wrote:
Yes, but this program:
typedef float float4[4];
typedef struct {
float4 a;
float b;
} astruct;
void go(float4 a, astruct b)
{
printf(in go: %d\n, sizeof(a));
printf(in go: %d\n, sizeof(float4));
printf(in go: %d\n, sizeof(b));
printf(in go: %d\n, sizeof(astruct));
}
int main() {
float4 a;
astruct b;
printf(in main: %d\n, sizeof(a));
printf(in main: %d\n, sizeof(float4));
printf(in main: %d\n, sizeof(b));
printf(in main: %d\n, sizeof(astruct));
go(a, b);
}
produces
in main: 16
in main: 16
in main: 20
in main: 20
in go: 8
in go: 16
in go: 20
in go: 20
The FFI is not just used for making function calls, it is also used
for specify structures and malloc-ing on behalf of the functions you
want to call. It is very awkward to make cstructs that are the correct
size and malloc the right amount without similar functionality to C in
this regard.
Jay
On Thu, Sep 30, 2010 at 4:51 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
When you run this program on a 32-bit machine:
#include stdio.h
void go(float a[4])
{
printf(in go: %d\n, sizeof(a));
}
int main() {
float a[4];
printf(in main: %d\n, sizeof(a));
go(a);
}
you'll see in main: 16 and in go: 4.
As far as I know, the 4 in void go(float a[4]) is ignored. It's
really the same as void go(float a[]) or void go(float *a). Unless
the declaration of an array variable is allocating the variable, the
variable is really a pointer, and sizeof() reflects that.
Along the same lines, a `_cvector' in the FFI always has a pointer
size, because it's always like a pointer.
A `(_cvector o _float 4)' or `(_f32vector o 4)' is probably
what you want, if the function you'll calling fills in the vector. A
`_float4-pointer' (not `_float4'!) if you allocate it yourself or
`(_pointer o _float4)' is also fine.
At Thu, 30 Sep 2010 16:41:29 -0600, Jay McCarthy wrote:
I'd like to be able to define ctypes like I would make a typedef in C like
typedef float float4[4];
But it doesn't seem like this works in the FFI. See the program below
with its awkward work-around:
#lang racket
(require ffi/unsafe
ffi/unsafe/cvector
ffi/vector
tests/eli-tester)
(test
(ctype-sizeof _float) = 4
(ctype-sizeof _cvector) = 4
(ctype-sizeof (_cvector i _float)) = 4
(ctype-sizeof (_cvector o _float 4)) = (* 4 4)
(ctype-sizeof (_cvector io _float 4)) = (* 4 4)
(ctype-sizeof _f32vector) = 4
(ctype-sizeof (_f32vector i)) = 4
(ctype-sizeof (_f32vector o 4)) = (* 4 4)
(ctype-sizeof (_f32vector io 4)) = (* 4 4)
(local [(define-cstruct _float4
([f0 _float]
[f1 _float]
[f2 _float]
[f3 _float]))]
(test
(ctype-sizeof _float4) = 16)))
Output is:
test: 5/11 test failures:
unsaved-editor4119:11:1: test failure in (ctype-sizeof (_cvector i
_float))
expected: 4
got: error: expand: unbound identifier in module
unsaved-editor4119:12:1: test failure in (ctype-sizeof (_cvector o _float
4))
expected: 16
got: 4
unsaved-editor4119:13:1: test failure in (ctype-sizeof (_cvector io _float
4))
expected: 16
got: error: expand: unbound identifier in module
unsaved-editor4119:17:1: test failure in (ctype-sizeof (_f32vector o 4))
expected: 16
got: 4
unsaved-editor4119:18:1: test failure in (ctype-sizeof (_f32vector io 4))
expected: 16
got: error: expand: unbound identifier in module
Normally I would just go do this, but I don't really understand the
FFI. If someone can point me appropriately, I'll go do it.
Jay
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay
The glory of God is Intelligence - DC 93
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http
Re: [racket-dev] #:namespace
That's not how the #:namespace argument ever worked. #:namespace takes a list of module names that are shared between the server and the servlets. In the case of the command-line tool, this is effectively a way to make some modules shared between different servlets, through the common party of the server. Since those servlet modules haven't been run, there's no confusing because they've always been evaluated in the same namespace. In contrast, web-server/insta, serve/servlet, and dispatch/servlet all take a closure rather than a module name as the servlet. This closure must have come from some namespace and it causes weird, unexpected behavior to not allow it to use the same namespace it came from when it runs. Basically, the addition of the #:namespace argument in the first place was just a knee-jerk reaction on my part making dispatch/servlet do everything that dispatch-servlets does without really thinking through whether it needed/made sense to have each feature. Jay On Mon, Oct 4, 2010 at 7:41 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It sounds like one could work around this by taking whatever was passed to #:namespace and making the servlets move over to that namespace, at least. Robby On Mon, Oct 4, 2010 at 8:28 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I didn't realize the handin server used it when I removed it. It definitely doesn't need it. The #:namespace argument made it so the closure given as the request handler was called in a different namespace than it was evaluated in, causing a reinstantiation of the module and other weirdness. For example, #lang web-server/insta (require (only-in some-stateful-module.rkt set-a! unbox-a)) ; where a defaults to Hello World (set-a! Hello World, not) (define (start req) (unbox-a)) would evaluate to Hello World instead of Hello World, not, because some-stateful-module was not shared with the new namespace. This seems incredibly wrong, so I removed the namespace argument and the request handler closure is simply evaluated in the namespace it came from. The #:namespace argument is still useful for other servlets that come from serve/servlet, because they are loaded from disk and may need to share some modules with the main one, but should otherwise be isolated. Jay On Mon, Oct 4, 2010 at 5:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Probably there was some mail on this topic, but... Why did `dispatch/servlet' lose its `#:namespace' argument? The handin server was using that argument, so it no longer runs. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #:namespace
I didn't realize the handin server used it when I removed it. It definitely doesn't need it. The #:namespace argument made it so the closure given as the request handler was called in a different namespace than it was evaluated in, causing a reinstantiation of the module and other weirdness. For example, #lang web-server/insta (require (only-in some-stateful-module.rkt set-a! unbox-a)) ; where a defaults to Hello World (set-a! Hello World, not) (define (start req) (unbox-a)) would evaluate to Hello World instead of Hello World, not, because some-stateful-module was not shared with the new namespace. This seems incredibly wrong, so I removed the namespace argument and the request handler closure is simply evaluated in the namespace it came from. The #:namespace argument is still useful for other servlets that come from serve/servlet, because they are loaded from disk and may need to share some modules with the main one, but should otherwise be isolated. Jay On Mon, Oct 4, 2010 at 5:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Probably there was some mail on this topic, but... Why did `dispatch/servlet' lose its `#:namespace' argument? The handin server was using that argument, so it no longer runs. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #:namespace
On Mon, Oct 4, 2010 at 8:17 AM, Eli Barzilay e...@barzilay.org wrote: 40 minutes ago, Jay McCarthy wrote: [...] I removed the namespace argument and the request handler closure is simply evaluated in the namespace it came from. The relevant piece of code: #lang racket/base (require ... handin-server/private/logger ...) (provide run) (define (run) ... (run-servlet dispatcher #:namespace '(... handin-server/private/logger ...) #:log-file (get-conf 'web-log-file)) ...) does the above mean that the logger will be shared because there is no new instantiation of this code? Yup Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
I agree. As far as students go, I've found that my PLAI students (juniors) adapted very fast to #t and #f from the teaching languages and that even they accidentally try to quote true and false within the single week I teach them with the student languages. So overall I think that #true and #false are good there and I don't see any problem with them being available elsewhere... just not the default. Jay On Sun, Oct 10, 2010 at 8:12 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sun, Oct 10, 2010 at 9:39 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Any other opinions? Personally, I find #true and #false visually ugly, and I also agree with Eli's feelings on terseness. I don't think I've ever accidentally confused #t and #f personally, so I'm not in favor of changing outside of the student languages. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] fuzz testing the bytecode reader
I hope it doesn't delete DrDr's hard drive. Jay On Tue, Oct 19, 2010 at 1:51 PM, Carl Eastlund c...@ccs.neu.edu wrote: Caveat Emptor: be wary of running code designed to produce random, unsafe results if the computer you are running it on has any data you really care about. Chances of catastrophic failure *should* be low, but they may not be, and sometimes lightning does strike anyway. Carl Eastlund On Tue, Oct 19, 2010 at 4:42 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Earlier today, I wrote a simple fuzz tester for bytecode reading and evaluation. The code is attached. It takes an existing zo file, reads it in as bytes, randomly flips some small portion of the bits (0.1%), and then `read's and `eval's the results. This extremely quickly finds segfaults in Racket. Here's a deterministic segfault with git HEAD: [sa...@hermes:~/tmp] racket fuzz.rkt -s 1046626898 -f ~/sw/plt/collects/redex/tests/compiled/lw-test-util_rkt.zo DrDr Ignore! random-seed 1046626898 name: /home/samth/sw/plt/collects/redex/tests/compiled/lw-test-util_rkt.zo SIGSEGV MAPERR si_code 1 fault on addr 0x616ec898 Aborted Here's how to traverse a bunch of files to find a segfault: racket fuzz.rkt -d ~/sw/plt/collects/redex/ I'll be adding this to the tree in the stress tests soon. Thanks to Robby for advice on the code, and to Lars Hansen for the idea. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.0.2
On Thu, Oct 21, 2010 at 5:07 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: Checklist items for the v5.0.2 release (using the v5.0.1.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test v5.0.2.1 by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * Matthew Flatt mfl...@cs.utah.edu - Racket Tests - Languages Tests - GRacket Tests (Also check that `gracket -z' and `gracket-text' still works in Windows and Mac OS X) - mzc Tests - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests - JPR's test suite. - Create an executable from a BSL program. Updates: - Racket Updates: update HISTORY - GRacket Updates: update README, HISTORY (updates should show v5.0.2 as the most current version) - Update man pages in racket/man/man1: racket.1, gracket.1, raco.1 Email me to pick the changes when they're done, or tell me if there are no such changes. * Robby Findler ro...@eecs.northwestern.edu - DrRacket Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests Updates: - DrRacket Updates: update HISTORY (updates should show v5.0.2 as the most current version) - Ensure that previous version of DrRacket's preference files still starts up with new DrRacket - Update man pages in racket/man/man1: drracket.1 Email me to pick the changes when they're done, or tell me if there are no such changes. * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.0.2 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen matth...@ccs.neu.edu - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.0.2 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Casey Klein clkl...@eecs.northwestern.edu - Redex Tests Updates: - Redex Updates: update HISTORY (updates should show v5.0.2 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Ryan Culpepper ry...@ccs.neu.edu - Macro Debugger Tests - Syntax Classifier Tests * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests All passed. * Paul Steckler st...@stecksoft.com - MysterX Tests - MzCOM Tests * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Chongkai Zhu c...@cs.utah.edu - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Sam Tobin-Hochstadt sa...@ccs.neu.edu - Match Tests - Typed Scheme Tests * Stevie Strickland sstri...@ccs.neu.edu - Unit Contract Tests - Contract Region Tests * Eli Barzilay e...@barzilay.org - Swindle Tests - Plot Tests - Verify that the unix installer works in both modes - Racket Tree: compare new distribution tree to previous one Version Updates: if a major change has happened, update the version number in: - racket/collects/mzscheme/info.rkt - racket/collects/mred/info.rkt * Doug Williams m.douglas.willi...@gmail.com - Plot Tests * Greg Cooper g...@cs.brown.edu - FrTime Tests * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) * Jon Rafkind rafk...@cs.utah.edu Release tests for (one of the) linux releases: - Test that the `racket' and `racket-textual' source releases compile fine - Test that the binary installers for both work, try each one in both normal and unix-style installation modes. (just ubuntu) * Shriram Krishnamurthi s...@cs.brown.edu Tour: check the tour and generate a new one if needed
Re: [racket-dev] [plt] Push #21341: master branch updated
I like the change, but I object to late changes in releases. The build script may be an okay exception. My net opinion is no opinion. Jay On Tue, Oct 26, 2010 at 5:28 AM, Eli Barzilay e...@barzilay.org wrote: Does anyone have a preference or an objection to use this change in the release? * The important bit here is the sh installers for unix -- they're currently using `plt' and `mz'. (There were some complaints about this.) * It's easy to verify -- just run the generated installers. (And look inside the source tgz/zip files.) Even if there are problems, fixing them is just repackaging the installers, keeping the same contents. (Clarification: I don't have an opinion.) A few seconds ago, e...@racket-lang.org wrote: 2cda694 Eli Barzilay e...@racket-lang.org 2010-10-26 07:10 : | Fix the names used by the `sh', `tgz', and `zip' installers to use | `racket', `racket-textual' and `racket-full' instead of `plt', `mz', and | `full'. | | (Also use uniform argument names in packaging functions.) : M collects/meta/build/build | 108 +- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.0.2 changelog
On Tue, Oct 26, 2010 at 12:34 PM, Jon Rafkind rafk...@cs.utah.edu wrote: Here is the raw changelog for 5.0.2. If you would like to summarize your changes please do so, otherwise someone (me/eli/ryan) will do it for you. If there are any other important items to note for this release please make a note of them. Matthew Flatt commit bf4fc2574c06132fece7342219fe6ea589e42f6d fix syntax colorer for #true and #false commit 99df8e126790077c11b4363a273ebf777bff8514 allow internal definitions in `when', `unless', `cond, `case', `match' commit 15302dc844ecf931145f895677cc8eb765b69960 adjust futures to decouple blocked futures from worker threads which required adding a notion of lightweight continuation to the runtime system, where a lightweight continuation involves only frames from JIT0generated code (so that details of the stack layout are known, for example) Mike Sperber commit 38cf78e213ee8f246ce322becb419aaed6ec2391 Allow specifying arbitary expressions in a signature declaration. Fixes PR 11282 Vincent St-Amour commit 8baa1682af76965400ab1071a46f8ba50f7c7165 Turned the optimizer on by default. commit 8d6230956dc8c207c097a389fa1f0c7273bb55b7 Documented the optimizer. Jon Rafkind commit d112eb4ceb8b94aebf1f699d1591386579e07a22 add line numbers pane to drracket Will M. Farr commit beb21754564fa8f20eae7e0e3109f2c1d06260c4 Added flvector-copy (with tests and docs). commit 82096abb1b6fd4a8872f528437ba95c44a4aedba Added interation forms for/vector, for*/vector, for/flvector, and for*/flvector and for-clause in-flvector. Jay McCarthy commit 01a41a812e83d0fb3a31940de0b52504ac4bbdb6 Closing pr11216. Adding one armed check-error to teaching languages. commit d17deb5fef8342e2dc25b6ddd027bd71d6373a8f Adding hash table functions to ASL commit 407dcee206678785b4b87bb513d7ba5f55ad8ab5 Adding match to ASL commit 347e946548c26bd51b682284816aa7f6f34b2d92 Adding WebSocket support I don't know where this list came from but it is lacking. There are some changes to PLAI and to the Web server. Jay Stevie Strickland commit ec0711bf4996dde06ecddbc8fcb95f44987a6915 Add chaperone contract-related properties. * Flat contracts are chaperone contracts, and chaperone contracts are (proxy) contracts. * Check in chaperone contracts that a chaperone (or chaperone-friendly value) is indeed returned. Ryan Culpepper commit 5a8d2f010e9e7858ff8c32ffadf73adac11cd98a added data/gvector, docs (need tests) commit d7a87c79e0211071fecb8474e6f7f66317b089d4 Merged changes to syntax/parse Changed backtracking algorithm, runtime representations - syntax classes, ~describe no longer implicitly commit - ~describe no longer delimits effect of cut Added keyword optional args for stxclasses Added ~do and #:do, ~post, ~commit and #:commit, ~delimit-cut and #:no-delimit-cut Added syntax/parse/debug, syntax/parse/experimental/* - expr/c for contracting macro sub-expressions moved from syntax/parse to syntax/parse/experimental/contract - syntax class reflection (~reflect, ~splicing-reflect) - eh-alternative-sets (~eh-var) - provide-syntax-class/contract (only for params, not attrs so far) Changed ~fail to not include POST progress (#:fail still does) old (~fail _) is now (~post (~fail _)) Made msg argument of ~fail optional Removed generic repetition constraint violated msg Removed atom-in-list stxclass Removed unnecessary datum-syntax on cdr of pair pattern massive improvements to long-list microbenchmarks Optimization: integrable syntax classes (id, expr, keyword) need better measurements Optimization: ad hoc elimination of head/tail choice point for (EH ... . ()) patterns Added unstable/wrapc (proc version of expr/c) Robby Findler commit 5e01ac55373d2987410da7d95f26f42535cfae3b added a pinhole property to images commit 561ac12a91e02fbc298272cc97d96e00d92f98ae got started on the -i parser Sam Tobin-Hochstadt commit 0635fc6d7542ea412e4586ca6ca051fdd2d91adb Create data/ collection. - Initially populated with queues, skip-lists, and interval-maps from unstable/ - Tests in tests/data, docs in data/scribblings Jens Axel Søgaard commit 64c3a98e45bda91b39eb811456ab409b72f0936e Added triangle/sss, triangle/ass, triangle/sas, triangle/ssa, triangle/aas, triangle/asa, and, triangle/saa. Kevin Tew commit 5bb2e148de87457ebb4790287d3b83b872c91a78 Parallel docs build _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93
Re: [racket-dev] 5.0.2 changelog
Here are some change logs entries for me: Web Server - formlets now provide more HTML form elements; make-xexpr-response supports a preamble for DTD declarations; serve/servlet supports stateless servlets PLAI - correct source locations in test printing; corrected test printing; various GC language improvements and fixes OpenSSL - ssl-tcp-addresses compatible with tcp-addresses Match - compiler now uses unsafe operations to improve performance (we've observed 2x on match intensive loads) *SL - one-armed check-error; hash operations added to ASL; define-datatype added to ASL Net - WebSocket implementation added You may not find them important. On Wed, Oct 27, 2010 at 11:40 PM, Jon Rafkind rafk...@cs.utah.edu wrote: Please find your name below and provide some blurb for the 5.0.2 changelog Author: Jay McCarthy j...@racket-lang.org - Adding define-datatype to ASL - PLAI changes - Webserver changes Author: Sam Tobin-Hochstadt sa...@racket-lang.org Faster loading of TR files? Author: Casey Klein clkl...@racket-lang.org redex things? Author: Matthew Flatt mfl...@racket-lang.org Modules spliced at the file level instead of collection level. Internal definitions for `when', `unless', `cond', `case', and `match' #true and #false forms Author: Robby Findler ro...@racket-lang.org - Check syntax changes - triangle primitives Author: Jay McCarthy j...@racket-lang.org - New hash functions Author: ryan - data/gvector - syntax/parse updates _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] relative lines of C in gracket vs. gracket2
That's tail -9 so he's dropped all the other things. Jay On Thu, Oct 28, 2010 at 11:58 AM, Joe Marshall jmarsh...@alum.mit.edu wrote: On Thu, Oct 28, 2010 at 10:48 AM, John Clements cleme...@brinckerhoff.org wrote: So, if I'm reading this correctly, we've gone from ~590K lines of C to about ~340K lines of C. That's amazing. Something is wrong. In your listing, the only two lines that have changed are these: 8404 22017 233781 ./racket/src/thread.c 9132 24942 230277 ./racket/src/port.c from the original: 8380 21961 233205 ./racket/src/thread.c 9123 24924 230059 ./racket/src/port.c Which seems to be a difference of 33 lines. I don't see where the 590K to 340K is coming from. -- ~jrm _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Demodularizer
Here is a message from Blake Johnson about something I just pushed for him: Jay recently committed my changes implementing raco demod, which will flatten a modular program into a single compiled module. How to use it: Run raco demod filename. This will produce a demodularized zo file called filename_merged.zo which can then be run by passing it to racket. This process can take quite a while, so if you want to see what is going on, you can set PLTSTDERR=debug or info. Once the zo file is created, it can be moved and run from anywhere because it has no dependencies. What it doesn't do (yet): - Dead code elimination This is partially implemented but doesn't handle every case properly, so it is turned off for now. - Optimize the program This is the next big thing I'm working on, which involves decompiling the zo slightly and converting it into c structs so that the existing optimizer can run on it. - Work with programs that dynamically manipulate modules This means things like DrRacket won't be able to be demodularized. We have some ideas on how to handle this, but it probably won't happen any time soon. Other improvements: zo-parse and zo-marshal should be able to handle any .zo you throw at them. Help needed: Any programs that don't work after demodularization would be helpful. Thanks, Blake Johnson At the moment, we have not measured any performance improvements, etc after using the demodularizer. At the moment, we do not anticipate that there will be any because we are not doing DCE or the re-optimization. We'll let everyone know when we measure that. For the moment, this may be of particular interest to any out there that are doing program analysis and would like whole programs. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Demodularizer
I just pushed a few commits that should speed it up a bit. Jay On Fri, Oct 29, 2010 at 10:50 PM, Jon Rafkind rafk...@cs.utah.edu wrote: Ok nevermind about the bug, I had some leftover .zo files. When I erased my compiled directory and reran the demodularizer it worked. Another quick stat: $ time raco demod p.rkt real 3m55.563s 1.8ghz amd On 10/29/2010 10:40 PM, Jon Rafkind wrote: How do you run the resulting _merged file? I ran 'raco demod p.rkt' and got compiled/p_rkt_zo_merged.zo. Then I tried running racket on it but got an error $ ~/bin/plt/bin/racket p_rkt_zo_merged compiled/p_rkt_zo_merged.zo: read (compiled): ill-formed code (bad count: 436459 != 801349, started at 11951) Also just some quick stats: $ cat p.rkt #lang racket (define (hello) (printf Hello world!)) (hello) $ ls -l compiled/p_rkt.zo ;; just using raco make 352 $ ls -l compiled/p_rkt_zo_merged.zo 448410 Would you mind renaming the command to 'demodularize' ? On 10/29/2010 07:53 PM, Jay McCarthy wrote: Here is a message from Blake Johnson about something I just pushed for him: Jay recently committed my changes implementing raco demod, which will flatten a modular program into a single compiled module. How to use it: Run raco demod filename. This will produce a demodularized zo file called filename_merged.zo which can then be run by passing it to racket. This process can take quite a while, so if you want to see what is going on, you can set PLTSTDERR=debug or info. Once the zo file is created, it can be moved and run from anywhere because it has no dependencies. What it doesn't do (yet): - Dead code elimination This is partially implemented but doesn't handle every case properly, so it is turned off for now. - Optimize the program This is the next big thing I'm working on, which involves decompiling the zo slightly and converting it into c structs so that the existing optimizer can run on it. - Work with programs that dynamically manipulate modules This means things like DrRacket won't be able to be demodularized. We have some ideas on how to handle this, but it probably won't happen any time soon. Other improvements: zo-parse and zo-marshal should be able to handle any .zo you throw at them. Help needed: Any programs that don't work after demodularization would be helpful. Thanks, Blake Johnson At the moment, we have not measured any performance improvements, etc after using the demodularizer. At the moment, we do not anticipate that there will be any because we are not doing DCE or the re-optimization. We'll let everyone know when we measure that. For the moment, this may be of particular interest to any out there that are doing program analysis and would like whole programs. Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Demodularizer
Just for some numbers, http://drdr.racket-lang.org/21386/collects/tests/compiler/demodularizer/ used to take 5.76 minutes and now it takes 2.90 Jay On Sat, Oct 30, 2010 at 9:17 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I just pushed a few commits that should speed it up a bit. Jay On Fri, Oct 29, 2010 at 10:50 PM, Jon Rafkind rafk...@cs.utah.edu wrote: Ok nevermind about the bug, I had some leftover .zo files. When I erased my compiled directory and reran the demodularizer it worked. Another quick stat: $ time raco demod p.rkt real 3m55.563s 1.8ghz amd On 10/29/2010 10:40 PM, Jon Rafkind wrote: How do you run the resulting _merged file? I ran 'raco demod p.rkt' and got compiled/p_rkt_zo_merged.zo. Then I tried running racket on it but got an error $ ~/bin/plt/bin/racket p_rkt_zo_merged compiled/p_rkt_zo_merged.zo: read (compiled): ill-formed code (bad count: 436459 != 801349, started at 11951) Also just some quick stats: $ cat p.rkt #lang racket (define (hello) (printf Hello world!)) (hello) $ ls -l compiled/p_rkt.zo ;; just using raco make 352 $ ls -l compiled/p_rkt_zo_merged.zo 448410 Would you mind renaming the command to 'demodularize' ? On 10/29/2010 07:53 PM, Jay McCarthy wrote: Here is a message from Blake Johnson about something I just pushed for him: Jay recently committed my changes implementing raco demod, which will flatten a modular program into a single compiled module. How to use it: Run raco demod filename. This will produce a demodularized zo file called filename_merged.zo which can then be run by passing it to racket. This process can take quite a while, so if you want to see what is going on, you can set PLTSTDERR=debug or info. Once the zo file is created, it can be moved and run from anywhere because it has no dependencies. What it doesn't do (yet): - Dead code elimination This is partially implemented but doesn't handle every case properly, so it is turned off for now. - Optimize the program This is the next big thing I'm working on, which involves decompiling the zo slightly and converting it into c structs so that the existing optimizer can run on it. - Work with programs that dynamically manipulate modules This means things like DrRacket won't be able to be demodularized. We have some ideas on how to handle this, but it probably won't happen any time soon. Other improvements: zo-parse and zo-marshal should be able to handle any .zo you throw at them. Help needed: Any programs that don't work after demodularization would be helpful. Thanks, Blake Johnson At the moment, we have not measured any performance improvements, etc after using the demodularizer. At the moment, we do not anticipate that there will be any because we are not doing DCE or the re-optimization. We'll let everyone know when we measure that. For the moment, this may be of particular interest to any out there that are doing program analysis and would like whole programs. Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21390: master branch updated
~~
--- OLD/collects/scribblings/scribble/manual.scrbl
+++ NEW/collects/scribblings/scribble/manual.scrbl
@@ -30,6 +30,60 @@ includes a @racket[latex-defaults] @tech{style property}.
@;
�...@section[#:tag scribble:manual:code]{Typesetting Code}
+...@defform/subs[(codeblock option ... str-expr ...+)
+ ([option (code:line #:indent indent-expr)
+ (code:line #:expand expand-expr)
+ (code:line #:context context-expr)
+ (code:line #:keep-lang-line? keep-expr)])
+ #:contracts ([indent-expr exact-nonnegative-integer?]
+ [expand-expr (or/c #f (syntax-object? . - .
syntax-object?))]
+ [context-expr syntax-object?]
+ [keep-expr any/c])]{
+
+Parses the code formed by the strings produced by the
+...@racket[str-expr]s as a Racket module and produces a @tech{block} that
+typesets the code. The code is indented by the amount specified by
+...@racket[indent-expr], which defaults to @racket[2].
+
+When @racket[expand-expr] produces @racket[#f] (which is the default),
+identifiers in the typeset code are colored and linked based on
+for-label bindings in the lexical environment of the syntax object
+provided by @racket[context-expr]. The default @racket[context-expr]
+has the same lexical context as the first @racket[str-expr].
+
+When @racket[expand-expr] produces a procedure, it is used to
+macro-expand the parsed program, and syntax coloring is based on the
+parsed program.
+
+When @racket[keep-lang-line?-expr] produces a true value (the
+default), the @hash-lang[] line in the input is preserved in the
+typeset output, otherwise the first line is dropped.
+
+For example,
+
+...@codeblock[#:keep-lang-line? #f]||{
+ #lang scribble/manual
+ �...@codeblock|{
+ #lang scribble/manual
+ �...@codeblock{
+ #lang scribble/manual
+ �...@title{hello}
+ }
+ }|
+}||
+
+produces the typeset result
+
+ �...@codeblock|{
+ #lang scribble/manual
+ �...@codeblock{
+ #lang scribble/manual
+ �...@title{hello}
+ }
+ }|
+
+}
+
�...@defform[(racketblock datum ...)]{
Typesets the @racket[datum] sequence as a table of Racket code inset
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay
The glory of God is Intelligence - DC 93
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] getpid
There's a lot of useful stuff in mzlib that should stick around. For example, mzlib/thread's run-server is very nice. Jay On Tue, Nov 2, 2010 at 12:25 PM, Eli Barzilay e...@barzilay.org wrote: Two minutes ago, Carl Eastlund wrote: The function 'getpid' is provided by 'mzlib/os' but nothing in 'racket/*'. Is it deprecated for a reason, or has it simply not been moved to a new library? It's not deprecated. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 64-bit Mac OS X (was: try the GRacket2 branch)
Can we make 64bit the default on OS X if it is available in the configure script? Jay On Sat, Nov 6, 2010 at 9:37 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 30 Oct 2010 16:40:00 -0600, Matthew Flatt wrote: At Sat, 30 Oct 2010 14:56:30 -0400, Gene Diveglia wrote: I apologize in advance if I'm jumping the gun a bit here. I'm not sure if 64 bit Mac builds are an immediate goal of GR2. It's a near-term goal, at least. After things are working well on the currently supported platforms, I plan to work on 64-bit Mac OS X and Windows versions. I don't expect that to take too long. 64-bit Mac support was closer to working than I thought. Running the `racket/gui' test suite turned up only this bug, and it's now fixed. (The problem was a mismatch between `float' and `double' return types when getting the value of a scroll bar.) So, let's declare that 64-bit Mac OS X is supported for v5.0.99.1 and later. Please continue to use it and report any other bugs you find. 64-bit Windows support will take longer. Unlike the Cocoa binding, where I tried 64-bit builds early in the development process, I haven't yet tried a 64-bit Windows build. In case anyone missed the note on the users lists: Don't try the gr2 branch anymore. Development has moved to the master branch, and the gr2 branch is gone. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [DrDr] R21445 (timeout 1) (unclean 715) (stderr 715) (changes 32)
I thought the whole point of the build process is that it gets the libraries if they are missing? Jay On Mon, Nov 8, 2010 at 7:27 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Nov 8, 2010 at 9:12 PM, d...@racket-lang.org wrote: DrDr has finished building push #21445 after 29.06m. Unfortunately, these builds are currently failing to test anything b/c the gtk libraries are missing on the DrDr machine. When you fix this, you might want to re-run all the builds since gr2 landed. -- sam th sa...@ccs.neu.edu -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [DrDr] R21445 (timeout 1) (unclean 715) (stderr 715) (changes 32)
Anyways, I think I got them (apt-get install libgtk2-dev) and restarted the builds Jay On Mon, Nov 8, 2010 at 7:34 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I thought the whole point of the build process is that it gets the libraries if they are missing? Jay On Mon, Nov 8, 2010 at 7:27 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Nov 8, 2010 at 9:12 PM, d...@racket-lang.org wrote: DrDr has finished building push #21445 after 29.06m. Unfortunately, these builds are currently failing to test anything b/c the gtk libraries are missing on the DrDr machine. When you fix this, you might want to re-run all the builds since gr2 landed. -- sam th sa...@ccs.neu.edu -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21487: master branch updated
You cannot reverse a sequence. You meant (in-list (reverse ...)) Jay On Tue, Nov 9, 2010 at 1:49 PM, clkl...@racket-lang.org wrote: clklein has updated `master' from 02f301b3b7 to 0d1578cbb1. http://git.racket-lang.org/plt/02f301b3b7..0d1578cbb1 =[ 1 Commits ]== Directory summary: 100.0% collects/meta/drdr/graphs/ ~~ 0d1578c Casey Klein clkl...@racket-lang.org 2010-11-09 14:46 : | Displays the panes in descending order (to match graph's time axis) : M collects/meta/drdr/graphs/build-graph.ss | 2 +- =[ Overall Diff ]=== collects/meta/drdr/graphs/build-graph.ss --- OLD/collects/meta/drdr/graphs/build-graph.ss +++ NEW/collects/meta/drdr/graphs/build-graph.ss @@ -614,7 +614,7 @@ (span ((id rev_and_duration)) )) (tt (span ((id timings)) )) - ,@(for/list ((graphs (in-list graphss)) + ,@(for/list ((graphs (reverse (in-list graphss))) (i (in-naturals))) `(map ((name ,(format revmap~a i))) ,@(graphs-areas graphs i))) -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] set operations
I think it is a good idea. Any objectors? Jay On Wed, Nov 10, 2010 at 12:40 PM, David Van Horn dvanh...@ccs.neu.edu wrote: The set library is missing a convenient way of selecting an element from a set, making it hard to write recursive functions matching the inductive structure of a set. Could you add this function, or something like it? (define (set-choose s) (let ((x (for/first ([x (in-set s)]) x))) (values x (set-remove s x David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] How about adding this simple list-shuffling procedure to racket?
I think we should put in a list shuffler into the core. Which should we use? The faster one? Jay On Thu, Nov 11, 2010 at 11:26 AM, Eli Barzilay e...@barzilay.org wrote: 5 minutes ago, Neil Toronto wrote: Carl Eastlund wrote: It's pick a random, uniform ordering, and then sort based on it. The random keys are chosen per element and cached (hence #:cache-keys? #t), not per comparison. Spanking good point, my good man. I think you're right. It's a very common method, and the classic example of the decorate-map-strip method that has some perl-guy's name slapped on it now. The wikipedia page on FY is pretty decent -- and one concern that I've encountered in the past is that it's sensitive to what that page calls modulo bias. The decorated version is more robust, especially with (random) that works at the highest `random' granularity. (BTW, to compare them you should use some (random 1000) thing to avoid the fp cost.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] How about adding this simple list-shuffling procedure to racket?
Not by me. On Fri, Nov 12, 2010 at 2:25 PM, Eli Barzilay e...@barzilay.org wrote: Any objections to `shuffle' in `racket/list'? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] proposed clarification to async-apply docs
The typesetting on async-apply clearly refers to the argument rather than to a well-known function. This is a convention of the docs that I don't think merits special attention here, although this case may indicate we should make a how to read the documentation section that points out these conventions. Jay On Tue, Nov 16, 2010 at 1:26 PM, John Clements cleme...@brinckerhoff.org wrote: My quick reading of the documentation for the #:async-apply argument to the _fun form led to a misunderstanding; the docs seemed to be suggesting that some built-in 'async-apply' procedure was doing all of these magical things, whereas the point was to indicate that the *user* must provide an async-apply that behaves correctly. I wound up going through and replacing 'async-apply' with 'the given async-apply procedure' in about five places. I think the text is clearer now; let me know if I shouldn't commit these changes. Otherwise, I'll commit them locally and push them sometime soon. John pcp062767pcs:~/plt/collects/scribblings/foreign clements$ git diff types.scrbl diff --git a/collects/scribblings/foreign/types.scrbl b/collects/scribblings/foreign/types.scrbl index 9d753ac..233f48d 100644 --- a/collects/scribblings/foreign/types.scrbl +++ b/collects/scribblings/foreign/types.scrbl @@ -401,19 +401,22 @@ procedure with the generated procedure type can be applied in a foreign thread (i.e., an OS-level thread other than the one used to run Racket). The call in the foreign thread is transferred to the OS-level thread that runs Racket, but the Racket-level thread (in the -sense of @racket[thread]) is unspecified; the job of -...@scheme[async-apply] is to arrange for the callback procedure to be -run in a suitable Racket thread. The @scheme[async-apply] function is +sense of @racket[thread]) is unspecified; the job of the provided +...@scheme[async-apply] procedure is to arrange for the callback procedure to be +run in a suitable Racket thread. The given @scheme[async-apply] procedure is applied to a thunk that encapsulates the specific callback invocation, and the foreign OS-level thread blocks until the thunk is called and completes; the thunk must be called exactly once, and the callback -invocation must return normally. The @scheme[async-apply] procedure +invocation must return normally. The given @scheme[async-apply] procedure itself is called in atomic mode (see @scheme[atomic?] above). If the callback is known to complete quickly, requires no synchronization, and works independent of the Racket thread in which it runs, then -...@scheme[async-apply] can apply the thunk directly. Otherwise, -...@racket[async-apply] must arrange for the thunk to be applied in a -suitable Racket thread sometime after @racket[async-apply] itself +it is safe for the given +...@scheme[async-apply] procedure to apply the thunk directly. Otherwise, +the given @racket[async-apply] procedure +must arrange for the thunk to be applied in a +suitable Racket thread sometime after the given +...@racket[async-apply] procedure itself returns; if the thunk raises an exception or synchronizes within an unsuitable Racket-level thread, it can deadlock or otherwise damage the Racket process. Foreign-thread detection to trigger pcp062767pcs:~/plt/collects/scribblings/foreign clements$ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Nov 27, 2010 at 4:31 AM, Neil Van Dyke n...@neilvandyke.org wrote: * I'd like to efficiently support SXML, as well as my new union of SXML and xexprs, by writing while traversing the data structure, without introducing an extra copy by first converting to byte string. Perhaps response/c could permit a closure to write the content and perhaps to produce or write the headers, or something similar? (Ideally, this does not require plugging together components using units and signatures; sometimes those tools are indispensable, but they're also cumbersome.) I've just added response/port for this purpose, although it only provides the ability to stream the content, the headers must be produced beforehand. Is that a game breaker? * I'd say that using SXML or xexprs for HTML and XML responses from a Web server is the normal and preferred way to implement most pages. Using these efficiently should be easy for people to do in substantial systems, such as by letting them define their own wrapper procedure or syntax for making a response of their preferred type. Using SXML or xexprs for output should also give good demo in tutorials and pilot apps, so it would be nice if people doing #lang simple-web-server or whatever could have a simple and terse way of saying send an HTML response from this SXML or xexpr, with all the continuation magic, such as using one procedure or syntax name, rather than two to four. BTW, SXML and xexprs are a big win for Web development. For one large system in PLT Scheme, the architects have repeatedly mentioned the productivity benefits of SXML for HTML pages as one of the major advantages of using Scheme. I very much agree; I wonder if the single 'make-xexpr-response' will be too much overhead. Jay -- http://www.neilvandyke.org/ -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Nov 29, 2010 at 3:41 AM, Nevo sakur.dea...@gmail.com wrote: Hi Jay: I have a question as to what you refer as backwards incompatible. Most Web applications will become contract violators because they are returning Xexprs directly to send/suspend, etc rather than returning response data structures. I will also be cleaning up the old response data-structures, so even those applications will have a break as well. Jay Will the old way (bytes response format) be workable since currently my blog server is setup by using some libs from untyped from planet and I'm not sure if this change will have any impact to those libs? Thanks, regardless of that, this change looks great so I don't need to worry about escaping and content insertion. Thank you! Nevo On 27 November 2010 08:55, Jay McCarthy jay.mccar...@gmail.com wrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. -- Details -- Everywhere that the server expects a response uses the response/c contract http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) This allows the native HTTP response data structures, Xexprs, and lists that start with bytes (the MIME type) where everything after is a byte string or normal string. [I have no idea where that last thing came from, but it was in the legacy server and I've kept it compatible.] In addition to backwards incompatibility, this could make Web programming a bit more verbose, because you'd have to explicitly call make-xexpr-response to construct the response from the Xexpr. I could ease that a little bit by changing its name to xexpr or something similar. Any ideas on the best way to deal with this? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Refactoring in-vector and friends
I've read the commit and it looks like a good change. I presume you've re-run the tests and you'll write new tests for the new vector types? Jay On Wed, Dec 1, 2010 at 8:41 AM, Noel Welsh noelwe...@gmail.com wrote: Hi all, I spent (far too much) time this morning refactoring the definition of in-vector to expose the building blocks to compose these macro/functions. After refactoring the code for defining in-vector is: (define-:vector-like-gen :vector-gen unsafe-vector-ref) (define-in-vector-like in-vector vector vector? vector-length :vector-gen) (define-sequence-syntax *in-vector (lambda () #'in-vector) (make-in-vector-like #'vector? #'unsafe-vector-length #'in-vector #'unsafe-vector-ref)) This could obviously be made smaller but it sufficient to enable reuse for in-flvector (my goal), in-f64vector etc. In doing so I split for.rkt into three (I couldn't handle refactoring the 1000+ lines of for.rkt; I needed something smaller to understand it all). Since this is a moderately large change I'm looking for comments/objections before committing. If you have objections please let me know -- if I don't hear any I'll commit tomorrow. Diff is attached. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Here is my current plan: Add web-server/compat/0 directory with, e.g., web-server/compat/0/http/response-structs to hold compatibility bindings to bridge the old http/response-structs and the new http/response-structs In that directory is the attached README. What do you think? Jay On Tue, Nov 30, 2010 at 11:14 AM, Eli Barzilay e...@barzilay.org wrote: Three hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay e...@barzilay.org wrote: Two hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay e...@barzilay.org wrote: The problem here is that there is no name to change -- it's the implicit coercion of xexpr values to a response. Why can't there be two libraries, one that coerces and one that doesn't? More generally, one that acts the same as the current library and one that is intended for new code? That would require a new `web-server' module, as well as a whole bunch of other modules. I know. Even worse, writing a module using one web server library, and using it in the other won't work, since it's a dynamic property of how the result is getting used. (I think it may be possible to be creative to avoid these things being errors when you mix; but maybe it is better to have an error when you mix; I don't have a strong opinion here but I'd try to make mixing work so people can migrate piecemeal.) [I don't see a way to do that.] As I said before, we have done this with the class system many times. We have done this with other parts of the system as well (not as many times tho). It is not a simple thing. That said, massive backwards incompatibility as Jay is proposing seems wrong. I'll leave this Jay, but I think that there are some important points: * Doing the same for the web server will be much more problematic since there are many interface modules that do the implicit coercion. It looks to me like the only way to do that will be a new toplevel `web-server' collection. * Even in the case of the class system, one of the transitions was going the other way -- renaming the old one (still available as `mzlib/class100') instead of having the new one under a new name. * The fact that this is much more problematic in the web server's case, combined with the fact that the change itself is much more minor (compared to the class system changes), is -- IMO -- a strong indication that a backward-compatible change via a parameter is the right way to go (defaulting to the same as it does now). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 README Description: Binary data _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Giving special consideration to Eli and YC's perspectives, I've come up with the following way out of this problem. I found a way to provide a global hook that is tasteful to me. I've created dynamic/c. Here's a little example: Examples: (define p (make-parameter any/c)) (define c (dynamic/c string? p number?)) (contract c 123 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:5:0; expected number?, given: 123 (p (coerce/c string-number)) (contract c 123 'pos 'neg) 123 (contract c 123a 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:8:0; Coercion failed The Web Server will define response/c as (dynamic/c any/c current-response/c response?) and provide the current-response/c parameter for customization. The default will be no coercion, but Xexpr conversion will be easily accessible. A compatibility library will automatically set current-response/c appropriately. Attached is the new compatibility README. I hope this will satisfy all. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 README Description: Binary data _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
All dynamic/c does is apply three contracts in a particular order where one is dynamic. coerce/c strongly implies that the function is coercion, but its implementation is similar to how the contract system must already use projection functions (ie it cannot confirm that are actually projections; it just applies them and uses the result) The default value of current-response/c is a projection (any/c) The compatibility library does not provide anything with the /c suffix that is a coercion --- it gives normalize-response and automatically sets current-response/c, but doesn't give anything that implies it is a contract Thus, the only thing that IMHO should irk you is xexpr-response/c that has the /c suffix and uses coerce/c with an actual coercion. Is that the case? What do you want me to call it? Jay On Sun, Dec 5, 2010 at 6:46 AM, Robby Findler ro...@eecs.northwestern.eduwrote: You've made a contract that isn't a projection, but does a coercion? I'd be happier if you instead made your own separate wrappers and didn't use /c and didn't call this a contract. Robby On Sun, Dec 5, 2010 at 12:29 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Giving special consideration to Eli and YC's perspectives, I've come up with the following way out of this problem. I found a way to provide a global hook that is tasteful to me. I've created dynamic/c. Here's a little example: Examples: (define p (make-parameter any/c)) (define c (dynamic/c string? p number?)) (contract c 123 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:5:0; expected number?, given: 123 (p (coerce/c string-number)) (contract c 123 'pos 'neg) 123 (contract c 123a 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:8:0; Coercion failed The Web Server will define response/c as (dynamic/c any/c current-response/c response?) and provide the current-response/c parameter for customization. The default will be no coercion, but Xexpr conversion will be easily accessible. A compatibility library will automatically set current-response/c appropriately. Attached is the new compatibility README. I hope this will satisfy all. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
These contracts are not thrown at dynamic places. The contract is always at the module boundary/etc, but its meaning if affected by the dynamic context of the particular boundary crossing. [1] I'm been thinking about why I want to use contracts for this purpose. The alternative is to put an any/c contract in all the places I currently have response/c and as the first thing in all those functions call current-any-response [or as the last thing on returns] on the input argument. I would then have to put a note in all the documentation of those any/c that it doesn't REALLY accept anything, instead in other accepts things that the dynamic current-any-response will turn into a response. If the coercion failed, then I would have to throw an error, which be purely dynamic with no blame information because it would not be associated with a contract boundary. In contrast, using a contract for this purpose allows me to centralize the documentation and behavior of these arguments, get correct blame on places where the coercion fails, and abstract the coercion out of the code that is using it into its interface. These are all great wins. In my opinion, if I did not use contracts, the only elegant thing to do would be to recreate something almost exactly like the contract system but called the coercion system. That is absurd to me when contracts already do exactly this. Am I just not clever enough to think of another elegant way? Why is there so much resistance to using the contract system in a perfectly legal way according to its own definition contracts? [2] [i.e. projection functions are not forced to be projections by any means. / contracts already break eq?/equal?-ness / etc] Jay 1. We already have such context-sensitive contracts: http://docs.racket-lang.org/xml/index.html#(def._((lib._xml/main..rkt)._permissive/c)) permissive/c exists to allow DrRacket to embed more snips inside the XML boxes, which are otherwise not XML elements. 2. make-contract's projection keyword has the contract (- any/c any/c) The example of make-contract coerces the procedure by restricting how many arguments rather than checking that when it is given that number of arguments it is used properly, etc. Only flat and chaperone contracts attempt to enforce projection-ness. On Sun, Dec 5, 2010 at 9:31 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: Jay, coercions aka casts in our world are compound words with - in between them. Why do you need a new name? (There is an inconsistency in their behavior. To wit Welcome to Racket v5.0.99.4. (integer-char 1000) integer-char: expects argument of type exact integer in [0,#x10], not in [#xD800,#xDFFF]; given 1000 === context === /Users/matthias/plt/collects/racket/private/misc.rkt:78:7 (string-number a10) #f But that is a historical problem.) ;; --- I am also reluctant to throw contracts at dynamic places. Contract boundaries should be syntactically distinct, e.g., module boundaries or define/contract. ;; --- I think you're really just checking an assertion. So perhaps you want to go with /a as a suffix. -- Matthias -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Yes, since I am allowing users to customize the coercion behavior, I could either have them provide two functions: a coercion-applies? function and a coercion function; OR I could have them just provide the coercion function and I will check the answer and re-run it inside of the function body. The other issue is that finding all the places where I should apply the coercion inside the body of the function is difficult, because I need to do it at every place where a response/c could flow in (relatively easy) and every place where a response/c could flow out (much hard, esp. with continuations). Contracts on functions are very nice in their ability to do stuff to inputs and outputs. Jay On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: The string-number primitive is probably closer to what Jay wants to do. The only contract I can think of for string-number is ;; Number - Boolean (define (string-number-able? x) (number? (string-number x))) So the real problem is a performance problem, which a lazy interpretation of contracts by the compiler might be able to eliminate. Is this the true problem Jay -- Matthias On Dec 6, 2010, at 9:45 AM, Robby Findler wrote: Let's be clear here: our inability to enforce projectionness is in no way condoning the two coercianlike contracts that you have now written. That said, the only value I see to contracts that only signal errors (or do nothing) is that programmers know what to expect from them. The downsides you mention are well taken, of course. In this specific case, your message seems slightly confused: certainly you should be able to use a contract to ensure that the coercion will always succeed. Let's assume you have done that and now discuss only where the coercing bit of the contract goes. Is it in a higher order position? Is it something that describes an interface to your module or can it be considered an internal detail? As a possible guide by analogy, consider the path-string? Predicate. It is the contract on many functions the ultimately is connected to some kind of a coercion somehwere buried inside the racket primitives for dealing with the filesystem. Is that like what you want to do? If so, how would your arguments hold up for that part of our system? Robby On Monday, December 6, 2010, Jay McCarthy jay.mccar...@gmail.com wrote: These contracts are not thrown at dynamic places. The contract is always at the module boundary/etc, but its meaning if affected by the dynamic context of the particular boundary crossing. [1] I'm been thinking about why I want to use contracts for this purpose. The alternative is to put an any/c contract in all the places I currently have response/c and as the first thing in all those functions call current-any-response [or as the last thing on returns] on the input argument. I would then have to put a note in all the documentation of those any/c that it doesn't REALLY accept anything, instead in other accepts things that the dynamic current-any-response will turn into a response. If the coercion failed, then I would have to throw an error, which be purely dynamic with no blame information because it would not be associated with a contract boundary. In contrast, using a contract for this purpose allows me to centralize the documentation and behavior of these arguments, get correct blame on places where the coercion fails, and abstract the coercion out of the code that is using it into its interface. These are all great wins. In my opinion, if I did not use contracts, the only elegant thing to do would be to recreate something almost exactly like the contract system but called the coercion system. That is absurd to me when contracts already do exactly this. Am I just not clever enough to think of another elegant way? Why is there so much resistance to using the contract system in a perfectly legal way according to its own definition contracts? [2] [i.e. projection functions are not forced to be projections by any means. / contracts already break eq?/equal?-ness / etc] Jay 1. We already have such context-sensitive contracts: http://docs.racket-lang.org/xml/index.html#(def._((lib._xml/main..rkt)._permissive/c)) permissive/c exists to allow DrRacket to embed more snips inside the XML boxes, which are otherwise not XML elements. 2. make-contract's projection keyword has the contract (- any/c any/c) The example of make-contract coerces the procedure by restricting how many arguments rather than checking that when it is given that number of arguments it is used properly, etc. Only flat and chaperone contracts attempt to enforce projection-ness. On Sun, Dec 5, 2010 at 9:31 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Jay, coercions aka casts in our world are compound words with - in between them. Why do you need a new name
Re: [racket-dev] Removing Xexpr preference from Web Server
That's why dynamic/c has a pre/c and post/c. Before it uses the user's contract, it applies pre/c. After it applies post/c. This ensures that the user's contract actually coerces to a response? Jay On Mon, Dec 6, 2010 at 9:25 AM, Robby Findler ro...@eecs.northwestern.eduwrote: On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Yes, since I am allowing users to customize the coercion behavior, I could either have them provide two functions: a coercion-applies? function and a coercion function; OR I could have them just provide the coercion function and I will check the answer and re-run it inside of the function body. The other issue is that finding all the places where I should apply the coercion inside the body of the function is difficult, because I need to do it at every place where a response/c could flow in (relatively easy) and every place where a response/c could flow out (much hard, esp. with continuations). Contracts on functions are very nice in their ability to do stuff to inputs and outputs. I think I need more help to understand the programming problem better. Why are your users supplying you a contract that you are using to protect your functions? That is how can you use anything about that contract to avoid errors in your programs? Robby Jay On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: The string-number primitive is probably closer to what Jay wants to do. The only contract I can think of for string-number is ;; Number - Boolean (define (string-number-able? x) (number? (string-number x))) So the real problem is a performance problem, which a lazy interpretation of contracts by the compiler might be able to eliminate. Is this the true problem Jay -- Matthias On Dec 6, 2010, at 9:45 AM, Robby Findler wrote: Let's be clear here: our inability to enforce projectionness is in no way condoning the two coercianlike contracts that you have now written. That said, the only value I see to contracts that only signal errors (or do nothing) is that programmers know what to expect from them. The downsides you mention are well taken, of course. In this specific case, your message seems slightly confused: certainly you should be able to use a contract to ensure that the coercion will always succeed. Let's assume you have done that and now discuss only where the coercing bit of the contract goes. Is it in a higher order position? Is it something that describes an interface to your module or can it be considered an internal detail? As a possible guide by analogy, consider the path-string? Predicate. It is the contract on many functions the ultimately is connected to some kind of a coercion somehwere buried inside the racket primitives for dealing with the filesystem. Is that like what you want to do? If so, how would your arguments hold up for that part of our system? Robby On Monday, December 6, 2010, Jay McCarthy jay.mccar...@gmail.com wrote: These contracts are not thrown at dynamic places. The contract is always at the module boundary/etc, but its meaning if affected by the dynamic context of the particular boundary crossing. [1] I'm been thinking about why I want to use contracts for this purpose. The alternative is to put an any/c contract in all the places I currently have response/c and as the first thing in all those functions call current-any-response [or as the last thing on returns] on the input argument. I would then have to put a note in all the documentation of those any/c that it doesn't REALLY accept anything, instead in other accepts things that the dynamic current-any-response will turn into a response. If the coercion failed, then I would have to throw an error, which be purely dynamic with no blame information because it would not be associated with a contract boundary. In contrast, using a contract for this purpose allows me to centralize the documentation and behavior of these arguments, get correct blame on places where the coercion fails, and abstract the coercion out of the code that is using it into its interface. These are all great wins. In my opinion, if I did not use contracts, the only elegant thing to do would be to recreate something almost exactly like the contract system but called the coercion system. That is absurd to me when contracts already do exactly this. Am I just not clever enough to think of another elegant way? Why is there so much resistance to using the contract system in a perfectly legal way according to its own definition contracts? [2] [i.e. projection functions are not forced to be projections by any means. / contracts already break eq?/equal?-ness / etc] Jay 1. We already have such context-sensitive contracts
Re: [racket-dev] Removing Xexpr preference from Web Server
I believe that this line of discussion is on target. Interoperability is between boundaries. Our contract system is really good at finding and interposing between these boundaries, so it is natural to use it in that way. There is a notion of blame in interoperability too, when the cast fails. Jay On Mon, Dec 6, 2010 at 9:46 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: The interoperability comment just hit me. What we might be discovering is basically Jacob's thesis in practice. It isn't so much contracts+X that we're looking at to implement interoperability, but contracts = interop-stuff + blame-mechnism + possibly-more. Jay is trying to reuse the first part of this sum -- for purposes that Jacob's thesis seems to imply: contract-like stuff is good to establish interop invariants. Let's see whether the Lazy-Plain Racket experiment bears this out. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Maybe dynamic/c isn't clear enough... its definition is pretty short: (define (dynamic/c pre parameter post) (define pre-ctc (coerce-contract 'pre pre)) (define post-ctc (coerce-contract 'post post)) (make-contract #:name (build-compound-type-name 'dynamic pre-ctc parameter post-ctc) #:projection (λ (b) (define pre-proj ((contract-projection pre-ctc) b)) (define post-proj ((contract-projection post-ctc) b)) (λ (x) (define dyn-proj ((contract-projection (coerce-contract 'dynamic (parameter))) b)) (post-proj (dyn-proj (pre-proj x))) The system provides pre and post, so it can offer protection to the coercion as well as receive protection FROM the coercion. But the coercion comes from a parameter which is exposed to the user. The one I use in the web-server is: (dynamic/c any/c current-response/c response?) where response? is the data structure predicate that the internal plumbing uses. Jay On Mon, Dec 6, 2010 at 9:51 AM, Jay McCarthy jay.mccar...@gmail.com wrote: That's why dynamic/c has a pre/c and post/c. Before it uses the user's contract, it applies pre/c. After it applies post/c. This ensures that the user's contract actually coerces to a response? Jay On Mon, Dec 6, 2010 at 9:25 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Yes, since I am allowing users to customize the coercion behavior, I could either have them provide two functions: a coercion-applies? function and a coercion function; OR I could have them just provide the coercion function and I will check the answer and re-run it inside of the function body. The other issue is that finding all the places where I should apply the coercion inside the body of the function is difficult, because I need to do it at every place where a response/c could flow in (relatively easy) and every place where a response/c could flow out (much hard, esp. with continuations). Contracts on functions are very nice in their ability to do stuff to inputs and outputs. I think I need more help to understand the programming problem better. Why are your users supplying you a contract that you are using to protect your functions? That is how can you use anything about that contract to avoid errors in your programs? Robby Jay On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: The string-number primitive is probably closer to what Jay wants to do. The only contract I can think of for string-number is ;; Number - Boolean (define (string-number-able? x) (number? (string-number x))) So the real problem is a performance problem, which a lazy interpretation of contracts by the compiler might be able to eliminate. Is this the true problem Jay -- Matthias On Dec 6, 2010, at 9:45 AM, Robby Findler wrote: Let's be clear here: our inability to enforce projectionness is in no way condoning the two coercianlike contracts that you have now written. That said, the only value I see to contracts that only signal errors (or do nothing) is that programmers know what to expect from them. The downsides you mention are well taken, of course. In this specific case, your message seems slightly confused: certainly you should be able to use a contract to ensure that the coercion will always succeed. Let's assume you have done that and now discuss only where the coercing bit of the contract goes. Is it in a higher order position? Is it something that describes an interface to your module or can it be considered an internal detail? As a possible guide by analogy, consider the path-string? Predicate. It is the contract on many functions the ultimately is connected to some kind of a coercion somehwere buried inside the racket primitives for dealing with the filesystem. Is that like what you want to do? If so, how would your arguments hold up for that part of our system? Robby On Monday, December 6, 2010, Jay McCarthy jay.mccar...@gmail.com wrote: These contracts are not thrown at dynamic places. The contract is always at the module boundary/etc, but its meaning if affected by the dynamic context of the particular boundary crossing. [1] I'm been thinking about why I want to use contracts for this purpose. The alternative is to put an any/c contract in all the places I currently have response/c and as the first thing in all those functions call current-any-response [or as the last thing on returns] on the input argument. I would then have to put a note in all the documentation of those any/c that it doesn't REALLY accept anything, instead in other accepts things that the dynamic current-any-response will turn into a response. If the coercion failed, then I would have to throw
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler ro...@eecs.northwestern.eduwrote: Who should be blamed if the coercion does not return a response? The provider of the coercion should be blamed, but that is not possible [I think] so the positive party of the whole dynamic/c is blamed. Is there a contract on current-response/c? (I assume that the /c there is a misnomer and it really is a parameter that holds a contact/coercion, not a contract.) current-response/c is contracted with (parameter/c contract?) The /c is not a misnomer, you are just parsing it wrong. Read it as (parameter (contract response)) not (contract (parameter response)), where /c is the post-fix syntax for (contract x) and current- is the pre-fix syntax for (parameter x) Jay Robby On Mon, Dec 6, 2010 at 10:55 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Maybe dynamic/c isn't clear enough... its definition is pretty short: (define (dynamic/c pre parameter post) (define pre-ctc (coerce-contract 'pre pre)) (define post-ctc (coerce-contract 'post post)) (make-contract #:name (build-compound-type-name 'dynamic pre-ctc parameter post-ctc) #:projection (λ (b) (define pre-proj ((contract-projection pre-ctc) b)) (define post-proj ((contract-projection post-ctc) b)) (λ (x) (define dyn-proj ((contract-projection (coerce-contract 'dynamic (parameter))) b)) (post-proj (dyn-proj (pre-proj x))) The system provides pre and post, so it can offer protection to the coercion as well as receive protection FROM the coercion. But the coercion comes from a parameter which is exposed to the user. The one I use in the web-server is: (dynamic/c any/c current-response/c response?) where response? is the data structure predicate that the internal plumbing uses. Jay On Mon, Dec 6, 2010 at 9:51 AM, Jay McCarthy jay.mccar...@gmail.com wrote: That's why dynamic/c has a pre/c and post/c. Before it uses the user's contract, it applies pre/c. After it applies post/c. This ensures that the user's contract actually coerces to a response? Jay On Mon, Dec 6, 2010 at 9:25 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Yes, since I am allowing users to customize the coercion behavior, I could either have them provide two functions: a coercion-applies? function and a coercion function; OR I could have them just provide the coercion function and I will check the answer and re-run it inside of the function body. The other issue is that finding all the places where I should apply the coercion inside the body of the function is difficult, because I need to do it at every place where a response/c could flow in (relatively easy) and every place where a response/c could flow out (much hard, esp. with continuations). Contracts on functions are very nice in their ability to do stuff to inputs and outputs. I think I need more help to understand the programming problem better. Why are your users supplying you a contract that you are using to protect your functions? That is how can you use anything about that contract to avoid errors in your programs? Robby Jay On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: The string-number primitive is probably closer to what Jay wants to do. The only contract I can think of for string-number is ;; Number - Boolean (define (string-number-able? x) (number? (string-number x))) So the real problem is a performance problem, which a lazy interpretation of contracts by the compiler might be able to eliminate. Is this the true problem Jay -- Matthias On Dec 6, 2010, at 9:45 AM, Robby Findler wrote: Let's be clear here: our inability to enforce projectionness is in no way condoning the two coercianlike contracts that you have now written. That said, the only value I see to contracts that only signal errors (or do nothing) is that programmers know what to expect from them. The downsides you mention are well taken, of course. In this specific case, your message seems slightly confused: certainly you should be able to use a contract to ensure that the coercion will always succeed. Let's assume you have done that and now discuss only where the coercing bit of the contract goes. Is it in a higher order position? Is it something that describes an interface to your module or can it be considered an internal detail? As a possible guide by analogy, consider the path-string? Predicate. It is the contract on many functions the ultimately is connected to some kind of a coercion somehwere buried inside the racket primitives
Re: [racket-dev] Removing Xexpr preference from Web Server
Yes, the idea is that you can set the parameter inside your servlet and that will effect the thread-cell for your servlet thread. Or, you can parameterize before you serve/servlet or send/suspend for a sub-component of your servlet with a different response representation Jay On Mon, Dec 6, 2010 at 10:18 AM, Robby Findler ro...@eecs.northwestern.eduwrote: Also: is this really supposed to be a parameter? That is, do you use parameterize with it? (If so, how does that interact with the ho stuff?) Robby On Mon, Dec 6, 2010 at 11:16 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Who should be blamed if the coercion does not return a response? Is there a contract on current-response/c? (I assume that the /c there is a misnomer and it really is a parameter that holds a contact/coercion, not a contract.) Robby On Mon, Dec 6, 2010 at 10:55 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Maybe dynamic/c isn't clear enough... its definition is pretty short: (define (dynamic/c pre parameter post) (define pre-ctc (coerce-contract 'pre pre)) (define post-ctc (coerce-contract 'post post)) (make-contract #:name (build-compound-type-name 'dynamic pre-ctc parameter post-ctc) #:projection (λ (b) (define pre-proj ((contract-projection pre-ctc) b)) (define post-proj ((contract-projection post-ctc) b)) (λ (x) (define dyn-proj ((contract-projection (coerce-contract 'dynamic (parameter))) b)) (post-proj (dyn-proj (pre-proj x))) The system provides pre and post, so it can offer protection to the coercion as well as receive protection FROM the coercion. But the coercion comes from a parameter which is exposed to the user. The one I use in the web-server is: (dynamic/c any/c current-response/c response?) where response? is the data structure predicate that the internal plumbing uses. Jay On Mon, Dec 6, 2010 at 9:51 AM, Jay McCarthy jay.mccar...@gmail.com wrote: That's why dynamic/c has a pre/c and post/c. Before it uses the user's contract, it applies pre/c. After it applies post/c. This ensures that the user's contract actually coerces to a response? Jay On Mon, Dec 6, 2010 at 9:25 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Yes, since I am allowing users to customize the coercion behavior, I could either have them provide two functions: a coercion-applies? function and a coercion function; OR I could have them just provide the coercion function and I will check the answer and re-run it inside of the function body. The other issue is that finding all the places where I should apply the coercion inside the body of the function is difficult, because I need to do it at every place where a response/c could flow in (relatively easy) and every place where a response/c could flow out (much hard, esp. with continuations). Contracts on functions are very nice in their ability to do stuff to inputs and outputs. I think I need more help to understand the programming problem better. Why are your users supplying you a contract that you are using to protect your functions? That is how can you use anything about that contract to avoid errors in your programs? Robby Jay On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: The string-number primitive is probably closer to what Jay wants to do. The only contract I can think of for string-number is ;; Number - Boolean (define (string-number-able? x) (number? (string-number x))) So the real problem is a performance problem, which a lazy interpretation of contracts by the compiler might be able to eliminate. Is this the true problem Jay -- Matthias On Dec 6, 2010, at 9:45 AM, Robby Findler wrote: Let's be clear here: our inability to enforce projectionness is in no way condoning the two coercianlike contracts that you have now written. That said, the only value I see to contracts that only signal errors (or do nothing) is that programmers know what to expect from them. The downsides you mention are well taken, of course. In this specific case, your message seems slightly confused: certainly you should be able to use a contract to ensure that the coercion will always succeed. Let's assume you have done that and now discuss only where the coercing bit of the contract goes. Is it in a higher order position? Is it something that describes an interface to your module or can it be considered an internal detail? As a possible guide by analogy, consider the path-string? Predicate. It is the contract on many functions the ultimately is connected
Re: [racket-dev] Hacking on the collects
I've done it and it wasn't as nice as getting a patch. Jay On Mon, Dec 6, 2010 at 10:19 AM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: On Mon, Dec 6, 2010 at 12:16 PM, Jay McCarthy jay.mccar...@gmail.com wrote: If you do a pull request on github, it will not be useful because github is a mirror and I'll just need to get the patch some other way anyways. I'd rather you sent the patch directly to me. This isn't quite right. As Eli explained (I think on this list), it's easy to merge from a separate github repository. I find it easier than fiddling with the git patch management commands. -- sam th sa...@ccs.neu.edu -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Dec 6, 2010 at 9:32 PM, Eli Barzilay e...@barzilay.org wrote: 11 hours ago, Jay McCarthy wrote: On Mon, Dec 6, 2010 at 10:16 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Who should be blamed if the coercion does not return a response? The provider of the coercion should be blamed, but that is not possible [I think] so the positive party of the whole dynamic/c is blamed. Is there a contract on current-response/c? (I assume that the /c there is a misnomer and it really is a parameter that holds a contact/coercion, not a contract.) current-response/c is contracted with (parameter/c contract?) From a bypasser POV, I see something that involves three contracts combined somehow, where one contract is coming from a parameter that is itself contracted... and my first thought is that I sure hope I won't need to deal with all of that when I want to just use the thing. You'll just touch the parameter. What's unclear to me is why is all of this necessary in contrast to a (contracted) parameter that holds a coercion function? The nice thing about the contract is that it is a centralized place for me to use the coercion from. Otherwise, I have to track down all the places that get contracted as response/c (some are inputs and some are outputs) and run the coercion on them. Then all those places will get any/c contracts and some note about being coerced, which I find inelegant. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
The only response struct that will be left is what response/port was. Jay On Mon, Dec 6, 2010 at 9:38 PM, Eli Barzilay e...@barzilay.org wrote: Two days ago, Jay McCarthy wrote: In that directory is the attached README. Perhaps you wrote about this elsewhere, but what's unclear to me is why `response/port' goes away? I liked the idea of using it as the basic way of communicating reponses back to the server -- without any coercions other than outputting some response. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
I've just committed the culmination of this thread. I've removed the coercive contracts and replaced them with a global imperative any-response hook that defaults to off but can easily be turned on to support X-exprs or the old behavior of the Web Server. Jay On Fri, Nov 26, 2010 at 5:55 PM, Jay McCarthy jay.mccar...@gmail.comwrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. -- Details -- Everywhere that the server expects a response uses the response/c contract http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) This allows the native HTTP response data structures, Xexprs, and lists that start with bytes (the MIME type) where everything after is a byte string or normal string. [I have no idea where that last thing came from, but it was in the legacy server and I've kept it compatible.] In addition to backwards incompatibility, this could make Web programming a bit more verbose, because you'd have to explicitly call make-xexpr-response to construct the response from the Xexpr. I could ease that a little bit by changing its name to xexpr or something similar. Any ideas on the best way to deal with this? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr 'shmget' errors
Alright. I have 4096 shared memory segments with nothing attached to them. I think this means that gr2 has a bug because it is not returning them, maybe by not closing gdk properly? Jay On Wed, Dec 8, 2010 at 1:47 PM, Jay McCarthy jay.mccar...@gmail.com wrote: We talked about it on IRC. I looked up the error and it says there is no more shared memory. I checked all my limits and they are all extremely high. I don't think it is a real problem with the machine, but I don't exactly know. If anyone can give me advice about what this means, let me know. Jay On Wed, Dec 8, 2010 at 11:58 AM, John Clements cleme...@brinckerhoff.orgwrote: I'm seeing this result from DrDr on one of my files: (gracket:19767): Gdk-WARNING **: shmget failed: error 28 (No space left on device) ... and I'm assuming that it's a drdr issue related to running files that involve graphical display, and that I don't need to worry about it. Is this correct? Apologies if I missed discussion of this. John -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] DrDr 'shmget' errors
I do not, but maybe these accrued because DrDr used to use a hierarchy of X servers and Xvnc servers and maybe the VNCs were breaking it. Jay On Wed, Dec 15, 2010 at 9:36 AM, Matthew Flatt mfl...@cs.utah.edu wrote: When I run `gracket' on one of my Linux virtual machines to an X server on the same machine, I see that a shared-memory segment is allocated (according to `ipcs -m'). But when I exit or kill -9 the `gracket' process, then the segment goes away. When I use an X server on a different machine, I don't see a new shared-memory segment. Do you see something different in any of those cases? At Wed, 8 Dec 2010 14:16:24 -0700, Jay McCarthy wrote: Alright. I have 4096 shared memory segments with nothing attached to them. I think this means that gr2 has a bug because it is not returning them, maybe by not closing gdk properly? Jay On Wed, Dec 8, 2010 at 1:47 PM, Jay McCarthy jay.mccar...@gmail.com wrote: We talked about it on IRC. I looked up the error and it says there is no more shared memory. I checked all my limits and they are all extremely high. I don't think it is a real problem with the machine, but I don't exactly know. If anyone can give me advice about what this means, let me know. Jay On Wed, Dec 8, 2010 at 11:58 AM, John Clements cleme...@brinckerhoff.orgwrote: I'm seeing this result from DrDr on one of my files: (gracket:19767): Gdk-WARNING **: shmget failed: error 28 (No space left on device) ... and I'm assuming that it's a drdr issue related to running files that involve graphical display, and that I don't need to worry about it. Is this correct? Apologies if I missed discussion of this. John -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about fields in Racket OO
Does 'define' really mean 'make a field'? I thought fields had to be specially designated so that get-field would know about them... Yes, this program errors: #lang racket (define c% (class* object% () (field [x 1]) (define y 2) (super-new))) (define o (new c%)) (field-names o) (get-field x o) (get-field y o) -- I agree that 'define' is like making a field, but fields are something special too. Jay On Thu, Dec 16, 2010 at 6:51 AM, Robby Findler ro...@eecs.northwestern.eduwrote: On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg mark.engelb...@gmail.com wrote: OK, it works when the set! occurs after the super-new. I didn't think set! would work at all in a class definition (as opposed to within a method); I was thinking of the whole system of defining classes as more of a declarative DSL that only allowed certain constructs. You've probably already figured this out, but the body of a class is a series of definitions and expressions like at the top-level but 'define' taking on the meaning of 'make a field', and a bunch of new definitions appearing. The new stuff says what the methods are, but everything else is just executed in sequence as if it were in the body of the initializer (if this were in Java, say). hth, Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about fields in Racket OO
This seems like a trivial point because the class system doesn't have to track these things and they are in fact part of the closures of the methods, so I don't see in what sense they are fields. Perhaps I am blinded by my reading of the implementation. I certainly agree they are essentially fields, but I can't but think of them as closed-over variables. Jay On Thu, Dec 16, 2010 at 7:00 AM, Carl Eastlund c...@ccs.neu.edu wrote: To quote the class* documentation: ( http://docs.racket-lang.org/reference/createclass.html#%28part._clfields%29 ) Each field, init-field, and non-method define-values clause in a class declares one or more new fields for the class. Fields declared with field or init-field are public. So only the public ones are accessible via get-field. Carl Eastlund On Thu, Dec 16, 2010 at 8:56 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Does 'define' really mean 'make a field'? I thought fields had to be specially designated so that get-field would know about them... Yes, this program errors: #lang racket (define c% (class* object% () (field [x 1]) (define y 2) (super-new))) (define o (new c%)) (field-names o) (get-field x o) (get-field y o) -- I agree that 'define' is like making a field, but fields are something special too. Jay On Thu, Dec 16, 2010 at 6:51 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Dec 16, 2010 at 12:22 AM, Mark Engelberg mark.engelb...@gmail.com wrote: OK, it works when the set! occurs after the super-new. I didn't think set! would work at all in a class definition (as opposed to within a method); I was thinking of the whole system of defining classes as more of a declarative DSL that only allowed certain constructs. You've probably already figured this out, but the body of a class is a series of definitions and expressions like at the top-level but 'define' taking on the meaning of 'make a field', and a bunch of new definitions appearing. The new stuff says what the methods are, but everything else is just executed in sequence as if it were in the body of the initializer (if this were in Java, say). hth, Robby -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] replacement for #:namespace arg in dispatch/servlet
The option was removed because it didn't do anything. #:namespace in other places in the Web Server is used to allow dynamically loaded code to share module instantiations with the Web Server (and therefore with each other.) dispatch/servlet does not dynamic load any code. It runs a servlet that is passed as a closure argument. That closure has whatever namespace the author of the servlet wants it to and it would be misleading to have this argument that really only effects dynamic loading of code within the servlet itself. The handin server should just work if you delete the argument, because as I said, it isn't doing anything. Jay 2011/1/2 John Clements cleme...@brinckerhoff.org: I'm trying to use the 'handin-server' code, which depends on a now-defunct #:namespace argument to dispatch/servlet. Your change eliminating this argument (commit c7995e247e8300) was in response to Shriram's PR about port number assignments, but that doesn't help me to figure out why that argument would have disappeared. I'm guessing that it's going to be something simple like using parameterize on current-namespace instead of specifying it as an optional argument, but since the handin server code isn't mine, I wouldn't be confident that my change was a sane one. So: is there a simple mechanism that replaces this optional argument? John Clements -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
That's what the force option for a rebasing fetch is for, to accept overwriting the history on the machine. [For example, on Matthew's gr2 branch, he would regularly do this.] Jay 2011/1/7 Robby Findler ro...@eecs.northwestern.edu: Can I do that once I've pushed to robby/plt? What happens to other machines that have unsquashed versions of those commits? Robby On Fri, Jan 7, 2011 at 9:43 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I like to do an interactive rebase and squash commits together: git rebase -i HEAD^^10 where 10 is how many commits ahead of the master I am Jay 2011/1/7 Robby Findler ro...@eecs.northwestern.edu: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
I like to do an interactive rebase and squash commits together: git rebase -i HEAD^^10 where 10 is how many commits ahead of the master I am Jay 2011/1/7 Robby Findler ro...@eecs.northwestern.edu: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Temporal Contracts and Match Automata
I've recently prepared an extension to the contract system based on some work that Cormac Flanagan and I did. The code is available at: https://github.com/jeapostrophe/exp/tree/master/temporal-ctcs The documentation is available at: http://faculty.cs.byu.edu/~jay/tmp/20110107-tempc/temp-c/ and http://faculty.cs.byu.edu/~jay/tmp/20110107-tempc/automata/ Here is a short example: (with-monitor (cons/c (label 'malloc (- addr?)) (label 'free (- addr? void?))) (complement (seq (star _) (dseq (call 'free addr) (seq (star (not (ret 'malloc (== addr (call 'free (== addr))) This creates a contract for a pair of functions, malloc and free, where the contract system ensures the malloc always returns addresses and free takes address and returns void. Additionally, the monitoring system ensures that the only legal interactions between these functions and their clients are those that do not end in a double free (a free followed by a free without a malloc of the same address in between.) Should this code be a PLaneT package or should it go into the core? I think it is quite a big extension over racket/contract. What do you think generally? Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] input methods under Unix/X
2011/1/17 Matthew Flatt mfl...@cs.utah.edu: I've finally enabled input-method support in `racket/gui' under X. (Input methods have long been supported for Windows and Mac OS X.) Maybe it doesn't count as input method support, but I've recently switched to the Japanese localization of OS X with the Koeteri system and when I do not explicitly choose the Latin input method nothing appears in DrRacket when I type. (For example, normally (basically all other OS X apps) in hiragana mode when I type ichi it appears as いち for a moment, but when I press down I can change it to 一. But in DrRacket, nothing appears at all the whole time.) Jay One consequence of this change is that, under X, Shift-Ctl-U 3 B B Return probably inserts `λ' anywhere that you can type in a Racket GUI program, since Shift-Ctl-U triggers a mode in the default(?) Gtk input method to type Unicode characters by their hexadecimal code points. More usefully to many, CJK input should now work under Gtk. Key-event handling is complex, and there are lots of ways that this change could go wrong. Keep an eye out for new event-handling problems under X. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] changing #lang plai to depend on racket rather than scheme?
2011/1/19 John Clements cleme...@brinckerhoff.org: I went looking for the immutable hash table functions in plai today, and I discovered that since plai is based on #lang scheme rather than #lang racket, you need to use old names in a bunch of places. Just for the heck of it, I went ahead and changed scheme - racket in two places in plai/main.rkt, and... things seem to work fine. However, I don't see a test suite that I could run to check this. 1) Is there a test suite somewhere? The obvious one would be running all of the code in the PLAI textbook. There are very small test suites for the core library (datatype and test) in tests/plai 2) Is there some reason why this change would be a bad idea or cause problems? I can't think of anything, because so much of the book's use of library functions is very minimal. I'd go ahead and do it. Jay John _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
2011/1/31 Ryan Culpepper ry...@ccs.neu.edu: * Jay McCarthy jay.mccar...@gmail.com - Web Server Tests - XML Tests - HTML Tests - PLAI Tests - Racklog tests - Datalog tests All passed -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
I've looked into this and I think it is a regression of GR2. The dc% interface documentation lists a huge number of functions, but racket/draw/private/dc-intf.rkt only has draw-text in the interface. As far as I can tell, this is fine enough because all the functions are implemented by the different dcs. But, it is a problem because make-generic requires the interface object to have the method name. In this case, FrTime needs draw-ellipse to work. A simple way to test is to run frtime/demos/mouse.rkt The FrTime code in question should really be rewritten/removed though, because it is a fork of the graphics collects. But nonetheless, this is a real gr2 regression. Jay 2011/2/3 Gregory Cooper ghcoo...@gmail.com: On Mon, Jan 31, 2011 at 2:50 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: * Greg Cooper g...@cs.brown.edu - FrTime Tests It looks like the graphics / GUI integration for FrTime has broken. I don't think anyone's using FrTime, so it might be best just to remove it. (I don't have commit access, so someone else would have to do it.) Greg _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
I'll update and re-run the FrTime test then for Greg Jay 2011/2/4 Matthew Flatt mfl...@cs.utah.edu: At Fri, 4 Feb 2011 15:02:18 -0700, Jay McCarthy wrote: I've looked into this and I think it is a regression of GR2. Thanks for investigating! The dc% interface documentation lists a huge number of functions, but racket/draw/private/dc-intf.rkt only has draw-text in the interface. Fixed this morning. A simple way to test is to run frtime/demos/mouse.rkt That now works for me. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1
The Fred GUI doesn't seem to work. I can't adjust the sliders on demos/orbit-mouse.rkt for example. I see no output on the console though. I'm not really sure where to check from there. I will try to trace it through Jay 2011/2/4 Jay McCarthy jay.mccar...@gmail.com: I'll update and re-run the FrTime test then for Greg Jay 2011/2/4 Matthew Flatt mfl...@cs.utah.edu: At Fri, 4 Feb 2011 15:02:18 -0700, Jay McCarthy wrote: I've looked into this and I think it is a regression of GR2. Thanks for investigating! The dc% interface documentation lists a huge number of functions, but racket/draw/private/dc-intf.rkt only has draw-text in the interface. Fixed this morning. A simple way to test is to run frtime/demos/mouse.rkt That now works for me. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] response/sxml ?
It does not. I removed the preference for xexprs with the assumption that others would write efficient response functions for other popular formats. Jay 2011/2/9 John Clements cleme...@brinckerhoff.org: I'm scrumbling through the web server source, and it looks to me like there's a response/xexpr but no response/sxml ... yet. Right? I'm guessing I could do a half-assed job of building it, but I want to make sure it doesn't already exist. John -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] drafting the v5.1 release announcement
* Web Server --- backwards incompatible change that prevents X-expressions and lists of bytes from being directly returned from servlets. This will increase performance for those types of responses and allow easier experimentation with response types. Please read PLTHOME/collects/web-server/compat/0/README to learn about porting your servlets forward. Don’t worry. It’s easy. 2011/2/9 Matthew Flatt mfl...@cs.utah.edu: Let's get the ball rolling on the release announcement. Here are draft bullets for the drawing and GUI libraries: * The `racket/draw' library --- which implements the drawing half the GUI toolkit --- is a new implementation built on top of the Cairo drawing library and the Pango text-rendering library. The `racket/draw' library can be used independent of the `racket/gui/base' library and without a graphics display (e.g., without an X11 connection). The new library has one small incompatibility with the old GUI toolbox: 'xor drawing is no longer supported. The new library has many additional features: rotation and general affine transformations, PDF and SVG drawing contexts, gradients, and alpha-channel bitmaps. * The `racket/gui/base' library is a new implementation built on top of Win32 under Windows, Cocoa (instead of Carbon) under Mac OS X, and Gtk (instead of Xt) under Unix/X. Unix/X users will see the biggest difference with this change. DrRacket and all Racket GUI programs take on the desktop theme for menus, buttons, and other GUI widgets. The GRacket executable is no longer strictly necessary for running GUI programs, because the `racket/gui/base' library can be used from Racket. To the degree that a platform distinguishes GUI and console applications, however, the GRacket executable still offers some additional GUI-specific functionality (e.g., single-instance support). The new library includes small incompatibilities with the old GUI toolbox: the `send-event', `current-ps-afm-file-paths', and `current-ps-cmap-file-paths' functions have been removed. The `racket/gui/base' library re-exports `racket/draw', so it includes the same drawing functionality as before (except for 'xor drawing). _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] drafting the v5.1 release announcement
administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
Can we pull the Wine trick of having a script that runs during compilation that downloads the file from a well-known location? Jay 2011/2/18 Eli Barzilay e...@barzilay.org: There are problematic latex files in collects/scribble/jfp/jfp.cls and sigplan/sigplanconf.cls. The latter has a copyright line but no license specified, and the first is much worse, since it explicitly states: %% This software may only be used in the preparation of journal %% articles or books or parts of books to be published by Cambridge %% University Press. Any other use constitutes an infringement of %% copyright. Does anyone know of some compatible but open files? (If not, then it sounds like it'll be a major PITA.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Packaging
You may recall from the meeting over the summer that I promised a packaging Christmas present to Racket. I'm over a month late, but here it is: http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html I lay out some goals for the new packaging system and make a concrete proposal. Please share your feedback so I can direct my efforts better. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
(I noticed automatic upgrades and freezing being an explicit operation but there may be other places). Do you have a rationale for deviating from this seemingly nice property? I agree with Sam's explanation. I do think it is valuable to be able to do this sometimes, which is why I think there should be an explicit pkg freeze web-server that ensures that the EXACT versions, with no upgrades, are used for the currently installed web-server package until it is unfrozen. 2011/2/18 Gregory Woodhouse gregwoodho...@me.com: If you do this, please at least make installing the full documentation an option. Not everyone can ensure that they will always be online when working with Racket. Absolutely. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
I don't feel strongly about this and you seem to, so supposing we support any conflicting installations, it makes sense for Planet 2.0 to have both major and minor versions. Jay 2011/2/19 Robby Findler ro...@eecs.northwestern.edu: On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Good point Jay 2011/2/19 Eli Barzilay e...@barzilay.org: 5 hours ago, Jay McCarthy wrote: 2011/2/18 Jos Koot jos.k...@telefonica.net: For a simple windows 7 user as I it is rather difficult to use command line instructions. I plead for an easy to use gui for making contributions. I think this is orthogonal to the project, but I do mention how important it is to have an easy way of getting packages post-installation. I was imagining that this would be a separate GUI tool that was auto-launched on Windows installation and suggested on first launch of DrRacket. General reminder: when you're at the first launch step, you're already beyond the point of adding installation wide content. You're some student in some class that is annoyed at their sysadmins not installing something, and annoyed at the constant popups since they're working on public machines that are getting wiped on every logout. Or you're a sysadmin that gets annoyed at the fact that the need to interact with the installer. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] form:binding / request utilities
That sounds reasonable. Here are a few things: 1) I almost exclusively use formlets, where these issues are basically taken care of. I suggest checking them out. 2) Would it be good for the request struct to be a prop:dict where the dictionary is the bindings? Would that be confusing because it is also plausible to dictionary on the headers? 3) Part of what you want is just request-bindings, but request-bindings has lots of subtle bugs. For example, HTTP does not mandate UTF-8, so naive conversion to Racket strings can crash. HTTP differentiates between form bindings and file bindings---for files you definitely want the bytes and you should also be able to get the filename. 4) The docs are in web-server/scribblings/http.scrbl; The tests are in tests/web-server/private/request-test.rkt and tests/web-server/servlet/bindings-test.rkt Jay 2011/3/4 John Clements cleme...@brinckerhoff.org: I'm doing a web-server/insta example in class, and one of my students (Arlo White, cc:'ed) pointed out that the existing framework for extracting bindings seems to be missing a bunch of useful functions. In particular, he volunteered to implement a few of the functions from the Spring framework, most notably a function that accepts a request and a name and returns the string associated with that name in the request's bindings. Like hash-ref, it would allow you to specify your own failure behavior. I've run into this myself, and it's always a pain to operate on the request structures. Would you be open to adding a few functions like this to the web-server (if we provide them, along with docs and tests)? Looking at the documentation, it appears that there's some cleanup that just never made it to the top of someone's list. John -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
