Re: [racket-dev] API naming conventions (Push #25466)
On 10/16/2012 05:43 PM, Robby Findler wrote: Plus, we should just have match built into all of the binding forms. +5 Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
>> Another data point: If "define/match" expands to a "define" of a procedure >> that dispatches to a set of implementations based on a pattern-match of >> actual arguments... then the name is exactly what I'd expect for such a >> feature in a Scheme dialect. > > That is, in fact, exactly what it does. Cool! My students have been writing code that way for years, and I've been telling them "There are languages in which that would work, but Scheme isn't one of them." (define (swap (make-posn x y)) (make-posn y x)) Next question: is there a version of this that's simple enough for beginning students to use? Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] API naming conventions (Push #25466)
For the record, I find having two things that combine match and define in different ways where the name difference is - vs / and swapping the order of the words to be quite unfortunate. Plus, we should just have match built into all of the binding forms. Robby On Tue, Oct 16, 2012 at 5:48 PM, Eli Barzilay wrote: > A few minutes ago, Matthias Felleisen wrote: >> >> Eli, can you explain again -- perhaps in different words -- why >> define/match is a bad name? I understand that we have match-define >> and define/match now. While I agree that having two of these forms >> with remotely related functionality is possibly confusing, I don't >> see why match-define is really a better kind of name than >> define/match. > > Well, I suggested `match-define' (before I realized that there was > already one) because it follows the same naming convention for the > rest of the library. > > >> If you are saying, that define/match is bad because it is too >> distinct from match-define I understand the name argument. > > If that was the only issue, then I wouldn't have objected so strongly > to it -- but the fact that there *is* an existing `match-define', and > the fact that it does something different, mean that the match > interface becomes extremely confusing. And that's not only for > newbies -- I can easily see myself not remembering which one of them > is doing which job. > > > A bit later, John Clements wrote: >> >> Violent agreement; I'm saying that the *names* are the same (modulo >> a stylistic choice), not that the meanings are the same. > > As for an attempt to explain why they're a bad combination, John > indeed put it nicely here. We have two forms whose meaning is a > combination of a `define' and a `match', and hanging the difference on > the order of the two terms (and a `/' vs a `-') means that for human > readers, the difference is far from apparent. > > And Matthias Felleisen added: >> >> (I really dislike match-define. But it's historic so we're stuck.) > > I completely agree -- I'd prefer a `define-match' or a `define/match', > in the same way that I'd also prefer a `let-match' etc. (And I also > agree that the historic choice is an important restriction.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] API naming conventions (Push #25466)
A few minutes ago, Matthias Felleisen wrote: > > Eli, can you explain again -- perhaps in different words -- why > define/match is a bad name? I understand that we have match-define > and define/match now. While I agree that having two of these forms > with remotely related functionality is possibly confusing, I don't > see why match-define is really a better kind of name than > define/match. Well, I suggested `match-define' (before I realized that there was already one) because it follows the same naming convention for the rest of the library. > If you are saying, that define/match is bad because it is too > distinct from match-define I understand the name argument. If that was the only issue, then I wouldn't have objected so strongly to it -- but the fact that there *is* an existing `match-define', and the fact that it does something different, mean that the match interface becomes extremely confusing. And that's not only for newbies -- I can easily see myself not remembering which one of them is doing which job. A bit later, John Clements wrote: > > Violent agreement; I'm saying that the *names* are the same (modulo > a stylistic choice), not that the meanings are the same. As for an attempt to explain why they're a bad combination, John indeed put it nicely here. We have two forms whose meaning is a combination of a `define' and a `match', and hanging the difference on the order of the two terms (and a `/' vs a `-') means that for human readers, the difference is far from apparent. And Matthias Felleisen added: > > (I really dislike match-define. But it's historic so we're stuck.) I completely agree -- I'd prefer a `define-match' or a `define/match', in the same way that I'd also prefer a `let-match' etc. (And I also agree that the historic choice is an important restriction.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] API naming conventions (Push #25466)
This answers it. John just rephrased my guess (last two lines) at your possible answer. (I really dislike match-define. But it's historic so we're stuck.) On Oct 16, 2012, at 6:41 PM, Eli Barzilay wrote: > Just now, John Clements wrote: >> >> If this were about changing the name of match-define to >> define/match, I'd have no objection, but the problem is that we now >> have two forms with names that are identical, modulo a stylistic >> choice. > > It's not -- they have two different meanings. > > >> It's as though we had a let/values and a values-let; what kind of >> difference in meaning would a user expect to see between these two? > > Exactly. (I'll reply more to Matthias's question.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >http://barzilay.org/ Maze is Life! smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] API naming conventions (Push #25466)
On Oct 16, 2012, at 3:41 PM, Eli Barzilay wrote: > Just now, John Clements wrote: >> >> If this were about changing the name of match-define to >> define/match, I'd have no objection, but the problem is that we now >> have two forms with names that are identical, modulo a stylistic >> choice. > > It's not -- they have two different meanings. Violent agreement; I'm saying that the *names* are the same (modulo a stylistic choice), not that the meanings are the same. John > > >> It's as though we had a let/values and a values-let; what kind of >> difference in meaning would a user expect to see between these two? > > Exactly. (I'll reply more to Matthias's question.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >http://barzilay.org/ Maze is Life! smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] API naming conventions (Push #25466)
Just now, John Clements wrote: > > If this were about changing the name of match-define to > define/match, I'd have no objection, but the problem is that we now > have two forms with names that are identical, modulo a stylistic > choice. It's not -- they have two different meanings. > It's as though we had a let/values and a values-let; what kind of > difference in meaning would a user expect to see between these two? Exactly. (I'll reply more to Matthias's question.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] API naming conventions (Push #25466)
On Oct 16, 2012, at 3:34 PM, Matthias Felleisen wrote: > > Eli, can you explain again -- perhaps in different words -- why define/match > is a bad name? I understand that we have match-define and define/match now. > While I agree that having two of these forms with remotely related > functionality is possibly confusing, I don't see why match-define is really a > better kind of name than define/match. > > If you are saying, that define/match is bad because it is too distinct from > match-define I understand the name argument. > > [I might be guilty of having inspired the keyword match-define. Even if so, I > find it dead-ugly now. define/match tells me define with match, and I can > guess the rest.] If this were about changing the name of match-define to define/match, I'd have no objection, but the problem is that we now have two forms with names that are identical, modulo a stylistic choice. It's as though we had a let/values and a values-let; what kind of difference in meaning would a user expect to see between these two? John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] API naming conventions (Push #25466)
Eli, can you explain again -- perhaps in different words -- why define/match is a bad name? I understand that we have match-define and define/match now. While I agree that having two of these forms with remotely related functionality is possibly confusing, I don't see why match-define is really a better kind of name than define/match. If you are saying, that define/match is bad because it is too distinct from match-define I understand the name argument. [I might be guilty of having inspired the keyword match-define. Even if so, I find it dead-ugly now. define/match tells me define with match, and I can guess the rest.] smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
I second this sentence, except for the 'Scheme dialect' part. On Oct 16, 2012, at 5:02 PM, Neil Van Dyke wrote: > John Clements wrote at 10/16/2012 04:51 PM: >> Data point: I have no idea what define/match does, and the name by itself >> does nothing to enlighten me. >> > > Another data point: If "define/match" expands to a "define" of a procedure > that dispatches to a set of implementations based on a pattern-match of > actual arguments... then the name is exactly what I'd expect for such a > feature in a Scheme dialect. > > Neil V. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] API naming conventions (Push #25466)
Two hours ago, Sam Tobin-Hochstadt wrote: > > `match-define*` would be much worse -- it isn't a variant on > `match-define`, nor does it resemble any of the other `match-X` > forms. The difference is very similar to the difference between `match-lambda', `match-lambda*', and `match-lambda**', in that they're both `define'-like forms only one has the extra (...) syntactic sugar. But this is not as important as the fact that an API with both `define/match' and `match-define' in it is a bad idea. More than that, if you really view them as things that are so different, then you should agree that this is a bad confusion. If you want more ideas, then maybe `match-defun' or `match-defn' or simply `match-define-function'. In any case, if you don't see why having the two current names is bad, then please find someone who does, and please¹⁴⁹ find a good name. An hour ago, Neil Van Dyke wrote: > John Clements wrote at 10/16/2012 04:51 PM: > > Data point: I have no idea what define/match does, and the name by > > itself does nothing to enlighten me. > > Another data point: If "define/match" expands to a "define" of a > procedure that dispatches to a set of implementations based on a > pattern-match of actual arguments... then the name is exactly what > I'd expect for such a feature in a Scheme dialect. The problem is not in knowing what it does -- it's in knowing how it is different from `match-define'. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25487: master branch updated
On 2012-10-16 15:27:46 -0400, mfl...@racket-lang.org wrote:
> 843c722 Matthew Flatt 2012-10-16 15:10
> :
> | add an argument to `{chaperone,impersonate}-prompt-tag'
> |
> | The new argument gets to filter results that come from a
> | non-composable continuation that replaces one delimited
> | by a prompt using the chaperoned/impersonated prompt tag.
Thanks. One thing I noticed is that I don't think this is quite enough
to build contracts that provide full protection for `call/cc`. Let me
demonstrate with an example:
;; ---
;; In this "component", we define a prompt tag
;; and install a prompt. We call `abort-k` which
;; is an unknown function imported from the other
;; component.
#lang racket
(define pt (make-continuation-prompt-tag))
(define (do-test)
(+ 1
(call-with-continuation-prompt
(lambda ()
(+ 1 (abort-k 1)))
pt)))
;; We export the prompt tag with a chaperone
;; that checks that the values we get from a
;; `call/cc` are numbers as we expect.
(define ipt
(chaperone-prompt-tag
pt
values values
(lambda (x)
(if (number? x) x
(error "wrong type")
;; component boundary -
;; In this component, we build an `abort-k`
;; that sends a string to the prompt.
;;
;; Note that it uses the chaperoned prompt tag
(define abort-k
(call-with-continuation-prompt
(lambda ()
(let ([v ; client side uses impersonation
(call/cc (lambda (k) k) ipt)])
(if (procedure? v)
v
(format "~a" v
ipt))
;; component boundary -
;; This raises an exception because the chaperone
;; on the `call/cc` side is not triggered. Only
;; the prompt side will ever trigger.
(do-test)
;; ---
The summary is that I think we need to do the `call/cc`
redirection on both sides: the prompt *and* the caller of
the aborting continuation.
Cheers,
Asumu
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] module mismatch with .zos
On Tue, Oct 16, 2012 at 12:04 PM, Robby Findler wrote: > (FWIW, it is not really wrong to consider this behavior a bug at a > number of different levels (why rely on timestamps? why does > compilation not produce the same thing each time?) and it is something > we've struggled with for a long time, so maybe your experience here > will give us another piece to the puzzle on dealing with this issue > overall.) > > Yes, compilation not being idempotent has come up as an issue for us. It's certainly lower priority though... > Robby > > -- Dan Liebgold[dan.liebg...@gmail.com] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
On Tue, Oct 16, 2012 at 5:02 PM, Neil Van Dyke wrote: > John Clements wrote at 10/16/2012 04:51 PM: > >> Data point: I have no idea what define/match does, and the name by itself >> does nothing to enlighten me. > > Another data point: If "define/match" expands to a "define" of a procedure > that dispatches to a set of implementations based on a pattern-match of > actual arguments... then the name is exactly what I'd expect for such a > feature in a Scheme dialect. That is, in fact, exactly what it does. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
John Clements wrote at 10/16/2012 04:51 PM: Data point: I have no idea what define/match does, and the name by itself does nothing to enlighten me. Another data point: If "define/match" expands to a "define" of a procedure that dispatches to a set of implementations based on a pattern-match of actual arguments... then the name is exactly what I'd expect for such a feature in a Scheme dialect. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
On Oct 16, 2012, at 12:58 PM, Sam Tobin-Hochstadt wrote: > On Tue, Oct 16, 2012 at 3:54 PM, Eli Barzilay wrote: >> A few minutes ago, Sam Tobin-Hochstadt wrote: >>> On Tue, Oct 16, 2012 at 3:39 PM, Eli Barzilay wrote: A few minutes ago, Sam Tobin-Hochstadt wrote: >>> >>> Unfortunately, we have only one thing we can vary here -- the name. >>> So while I'd be happy to hear better names for `define/match`, it >>> would be wrong to call it `match-define`, and it's a valuable form >>> and I plan to keep it. >> >> Yes, the name is what should vary here, I had nothing to say about >> what it does. Please¹⁷ change it. Even a `match-define*' would be >> better than `define/match'. > > `match-define*` would be much worse -- it isn't a variant on > `match-define`, nor does it resemble any of the other `match-X` forms. Data point: I have no idea what define/match does, and the name by itself does nothing to enlighten me. John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
On Tue, Oct 16, 2012 at 3:54 PM, Eli Barzilay wrote: > A few minutes ago, Sam Tobin-Hochstadt wrote: >> On Tue, Oct 16, 2012 at 3:39 PM, Eli Barzilay wrote: >> > A few minutes ago, Sam Tobin-Hochstadt wrote: >> >> On Tue, Oct 16, 2012 at 3:10 PM, Eli Barzilay wrote: >> >> > Just now, Jay McCarthy wrote: >> >> >> match-define is something else >> >> > >> >> > Indeed it is -- which makes the whole thing even more >> >> > confusing. I can't help imagining a newbie's reaction when >> >> > they're told that >> >> > >> >> > Oh, here's your mistake -- you've used match-define where you >> >> > should have used define/match. >> >> > >> >> > >> >> > IMO, this is bad enough to withdraw it if there's no good name >> >> > for it. >> >> >> >> I think both names are in keeping with the appropriate >> >> conventions -- `match-define` is a variant of `define` but with >> >> patterns in the binding positions, just like `match-let` and >> >> `match-lambda` etc. I don't think this is any different from >> >> `regexp-match` vs `regexp-match*`, for example. >> > >> > Yes, both names follow conventions, only different ones. It's the >> > mixture of convention that make the above newbie situation look so >> > ridiculously confusing. >> >> Unfortunately, we have only one thing we can vary here -- the name. >> So while I'd be happy to hear better names for `define/match`, it >> would be wrong to call it `match-define`, and it's a valuable form >> and I plan to keep it. > > Yes, the name is what should vary here, I had nothing to say about > what it does. Please¹⁷ change it. Even a `match-define*' would be > better than `define/match'. `match-define*` would be much worse -- it isn't a variant on `match-define`, nor does it resemble any of the other `match-X` forms. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
A few minutes ago, Sam Tobin-Hochstadt wrote: > On Tue, Oct 16, 2012 at 3:39 PM, Eli Barzilay wrote: > > A few minutes ago, Sam Tobin-Hochstadt wrote: > >> On Tue, Oct 16, 2012 at 3:10 PM, Eli Barzilay wrote: > >> > Just now, Jay McCarthy wrote: > >> >> match-define is something else > >> > > >> > Indeed it is -- which makes the whole thing even more > >> > confusing. I can't help imagining a newbie's reaction when > >> > they're told that > >> > > >> > Oh, here's your mistake -- you've used match-define where you > >> > should have used define/match. > >> > > >> > > >> > IMO, this is bad enough to withdraw it if there's no good name > >> > for it. > >> > >> I think both names are in keeping with the appropriate > >> conventions -- `match-define` is a variant of `define` but with > >> patterns in the binding positions, just like `match-let` and > >> `match-lambda` etc. I don't think this is any different from > >> `regexp-match` vs `regexp-match*`, for example. > > > > Yes, both names follow conventions, only different ones. It's the > > mixture of convention that make the above newbie situation look so > > ridiculously confusing. > > Unfortunately, we have only one thing we can vary here -- the name. > So while I'd be happy to hear better names for `define/match`, it > would be wrong to call it `match-define`, and it's a valuable form > and I plan to keep it. Yes, the name is what should vary here, I had nothing to say about what it does. Please¹⁷ change it. Even a `match-define*' would be better than `define/match'. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
On Tue, Oct 16, 2012 at 3:39 PM, Eli Barzilay wrote: > A few minutes ago, Sam Tobin-Hochstadt wrote: >> On Tue, Oct 16, 2012 at 3:10 PM, Eli Barzilay wrote: >> > Just now, Jay McCarthy wrote: >> >> match-define is something else >> > >> > Indeed it is -- which makes the whole thing even more confusing. I >> > can't help imagining a newbie's reaction when they're told that >> > >> > Oh, here's your mistake -- you've used match-define where you should >> > have used define/match. >> > >> > >> > IMO, this is bad enough to withdraw it if there's no good name for it. >> >> I think both names are in keeping with the appropriate conventions -- >> `match-define` is a variant of `define` but with patterns in the >> binding positions, just like `match-let` and `match-lambda` etc. I >> don't think this is any different from `regexp-match` vs >> `regexp-match*`, for example. > > Yes, both names follow conventions, only different ones. It's the > mixture of convention that make the above newbie situation look so > ridiculously confusing. Unfortunately, we have only one thing we can vary here -- the name. So while I'd be happy to hear better names for `define/match`, it would be wrong to call it `match-define`, and it's a valuable form and I plan to keep it. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
A few minutes ago, Sam Tobin-Hochstadt wrote: > On Tue, Oct 16, 2012 at 3:10 PM, Eli Barzilay wrote: > > Just now, Jay McCarthy wrote: > >> match-define is something else > > > > Indeed it is -- which makes the whole thing even more confusing. I > > can't help imagining a newbie's reaction when they're told that > > > > Oh, here's your mistake -- you've used match-define where you should > > have used define/match. > > > > > > IMO, this is bad enough to withdraw it if there's no good name for it. > > I think both names are in keeping with the appropriate conventions -- > `match-define` is a variant of `define` but with patterns in the > binding positions, just like `match-let` and `match-lambda` etc. I > don't think this is any different from `regexp-match` vs > `regexp-match*`, for example. Yes, both names follow conventions, only different ones. It's the mixture of convention that make the above newbie situation look so ridiculously confusing. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
On Tue, Oct 16, 2012 at 3:10 PM, Eli Barzilay wrote: > Just now, Jay McCarthy wrote: >> match-define is something else > > Indeed it is -- which makes the whole thing even more confusing. I > can't help imagining a newbie's reaction when they're told that > > Oh, here's your mistake -- you've used match-define where you should > have used define/match. > > > IMO, this is bad enough to withdraw it if there's no good name for it. I think both names are in keeping with the appropriate conventions -- `match-define` is a variant of `define` but with patterns in the binding positions, just like `match-let` and `match-lambda` etc. I don't think this is any different from `regexp-match` vs `regexp-match*`, for example. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] module mismatch with .zos
To be clear, we don't have any steps between sync in perforce and running racket. This is for "end" users who don't edit or compile source. It is also part of a toolchain where Racket is just one optional piece and so we can't really spare the time to build zos at this particular point. We really do need to distribute a package that is ready to run. Perforce is our method for distributing a lot of other stuff already so adding a new method is not trivial. Storing things centrally is a nice approach but as I brought up in my last thread it is prohibitively slow. It's sounding like my best approach is to put together a collects path that contains just .zo files and also put together some sort of build automation to create that tree. That would arrange updating and distribution that would fit in our environment. (and if that tree could be archived into 1 or few file(s) I'd be in hog heaven) Thank you guys for your time and effort on this. Dan On Tue, Oct 16, 2012 at 12:23 PM, Matthew Flatt wrote: > At Tue, 16 Oct 2012 14:04:32 -0500, Robby Findler wrote: > > Besides what Eli says, another approach is to run 'raco setup -Dxi' > > after getting things out of perforce. That uses hashes for the files > > to determine what to compile (so nothing will get compiled if the zos > > are actually right), but it updates the timestamps (so racket won't > > get confused). > > I think that's a good option. > > I think it's fine to omit ".rkt" files and ".dep" files, in which case > timestamps on ".zo" files don't matter. > > (You could also keep ".dep" files along with ".zo" files, in which case > timestamps still don't matter, but that doesn't seem useful.) > > -- Dan Liebgold[dan.liebg...@gmail.com] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] module mismatch with .zos
At Tue, 16 Oct 2012 14:04:32 -0500, Robby Findler wrote: > Besides what Eli says, another approach is to run 'raco setup -Dxi' > after getting things out of perforce. That uses hashes for the files > to determine what to compile (so nothing will get compiled if the zos > are actually right), but it updates the timestamps (so racket won't > get confused). I think that's a good option. I think it's fine to omit ".rkt" files and ".dep" files, in which case timestamps on ".zo" files don't matter. (You could also keep ".dep" files along with ".zo" files, in which case timestamps still don't matter, but that doesn't seem useful.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
Just now, Jay McCarthy wrote: > match-define is something else Indeed it is -- which makes the whole thing even more confusing. I can't help imagining a newbie's reaction when they're told that Oh, here's your mistake -- you've used match-define where you should have used define/match. IMO, this is bad enough to withdraw it if there's no good name for it. > On Tue, Oct 16, 2012 at 1:03 PM, Eli Barzilay wrote: > > Two days ago, stch...@racket-lang.org wrote: > >> @deftogether[( > >> +@defform[(define/match (head args) match*-clause ...)] > >> @defform[(match-lambda clause ...)] > >> @defform[(match-lambda* clause ...)] > >> @defform[(match-let ([pat expr] ...) body ...+)] > > > > I don't know if nobody paid any attention to this, but the above looks > > *really* ugly. Please³ rename it to `match-define'. > > > > (Yes, it's true that this won't get recognized as a definition form > > using drr's usual regexp, but that's already true for the other match > > forms.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
match-define is something else On Tue, Oct 16, 2012 at 1:03 PM, Eli Barzilay wrote: > Two days ago, stch...@racket-lang.org wrote: >> @deftogether[( >> +@defform[(define/match (head args) match*-clause ...)] >> @defform[(match-lambda clause ...)] >> @defform[(match-lambda* clause ...)] >> @defform[(match-let ([pat expr] ...) body ...+)] > > I don't know if nobody paid any attention to this, but the above looks > *really* ugly. Please³ rename it to `match-define'. > > (Yes, it's true that this won't get recognized as a definition form > using drr's usual regexp, but that's already true for the other match > forms.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > > _ > Racket Developers list: > http://lists.racket-lang.org/dev -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] module mismatch with .zos
Besides what Eli says, another approach is to run 'raco setup -Dxi' after getting things out of perforce. That uses hashes for the files to determine what to compile (so nothing will get compiled if the zos are actually right), but it updates the timestamps (so racket won't get confused). This is probably easier/better than changing racket to ignore .rkt files. (FWIW, it is not really wrong to consider this behavior a bug at a number of different levels (why rely on timestamps? why does compilation not produce the same thing each time?) and it is something we've struggled with for a long time, so maybe your experience here will give us another piece to the puzzle on dealing with this issue overall.) Robby On Tue, Oct 16, 2012 at 1:56 PM, Eli Barzilay wrote: > A few minutes ago, Dan Liebgold wrote: >> It seems like the timestamps among just the .zo and .dep files will cause us >> issues as well due to how Perforce works. When you sync, Perforce sets the >> timestamp of the file to the time of sync. If I sync all of a Racket >> distribution my file timestamps will not be coherent from Racket's point of >> view, right? >> >> As far as I can tell, one of these things must change for our setup to be >> reliable: >> >> - use of precompilation (going without .zos entirely should eliminate this >> problem) >> - use of Perforce; with proper timestamps Racket will not complain >> - the compilation manager; if we change the default implementation to ignore >> timestamps and just go by file existence we should be ok >> >> Does this sound like an accurate assessment? > > FWIW, it sounds like a bad idea to distribute .zo files (or any other > compilation results in any language) through a CMS. You'd get the > same problems with git, and I think that svn was fine but even there > you'd have some issues to consider. So I'd get rid of #2. > > I also think that #3 is dangerous -- it looks like it's a recipe for > all kinds of nasty surprises when things don't work right. > > I'd try to go with a variant of #1: have a simple conventional > repository with just source code files. Then tell people how to get > it to build so work can go on as usual. And finally, you can do > something similar to what we use in the nightly builds (though > probably everyone ignores it these days): compile the tree yourself, > and create a tarball with the resulting .zo and .dep files, then write > a quick script that untars it on top of a repository. I don't know if > perforce has any scriptability feature, but with git the whole thing > can be packaged into a new in-house git command. > > But to make it more complete -- if you still want to try the .zo > distribution via the repository, you can try to make people use `raco > setup' with the `--trust-zos' flag which (IIRC) makes it assume that > the zo files are all updated and just update the file time stamps. > (I'm not completely sure about it; but I do remember this being added > as a result of a similar situation where you end up with the correct > .zo files but broken time stamps.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
Two days ago, stch...@racket-lang.org wrote: > @deftogether[( > +@defform[(define/match (head args) match*-clause ...)] > @defform[(match-lambda clause ...)] > @defform[(match-lambda* clause ...)] > @defform[(match-let ([pat expr] ...) body ...+)] I don't know if nobody paid any attention to this, but the above looks *really* ugly. Please³ rename it to `match-define'. (Yes, it's true that this won't get recognized as a definition form using drr's usual regexp, but that's already true for the other match forms.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] module mismatch with .zos
A few minutes ago, Dan Liebgold wrote: > It seems like the timestamps among just the .zo and .dep files will cause us > issues as well due to how Perforce works. When you sync, Perforce sets the > timestamp of the file to the time of sync. If I sync all of a Racket > distribution my file timestamps will not be coherent from Racket's point of > view, right? > > As far as I can tell, one of these things must change for our setup to be > reliable: > > - use of precompilation (going without .zos entirely should eliminate this > problem) > - use of Perforce; with proper timestamps Racket will not complain > - the compilation manager; if we change the default implementation to ignore > timestamps and just go by file existence we should be ok > > Does this sound like an accurate assessment? FWIW, it sounds like a bad idea to distribute .zo files (or any other compilation results in any language) through a CMS. You'd get the same problems with git, and I think that svn was fine but even there you'd have some issues to consider. So I'd get rid of #2. I also think that #3 is dangerous -- it looks like it's a recipe for all kinds of nasty surprises when things don't work right. I'd try to go with a variant of #1: have a simple conventional repository with just source code files. Then tell people how to get it to build so work can go on as usual. And finally, you can do something similar to what we use in the nightly builds (though probably everyone ignores it these days): compile the tree yourself, and create a tarball with the resulting .zo and .dep files, then write a quick script that untars it on top of a repository. I don't know if perforce has any scriptability feature, but with git the whole thing can be packaged into a new in-house git command. But to make it more complete -- if you still want to try the .zo distribution via the repository, you can try to make people use `raco setup' with the `--trust-zos' flag which (IIRC) makes it assume that the zo files are all updated and just update the file time stamps. (I'm not completely sure about it; but I do remember this being added as a result of a similar situation where you end up with the correct .zo files but broken time stamps.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] module mismatch with .zos
It seems like the timestamps among just the .zo and .dep files will cause us issues as well due to how Perforce works. When you sync, Perforce sets the timestamp of the file to the time of sync. If I sync all of a Racket distribution my file timestamps will not be coherent from Racket's point of view, right? As far as I can tell, one of these things must change for our setup to be reliable: - use of precompilation (going without .zos entirely should eliminate this problem) - use of Perforce; with proper timestamps Racket will not complain - the compilation manager; if we change the default implementation to ignore timestamps and just go by file existence we should be ok Does this sound like an accurate assessment? Thanks, Dan On Mon, Oct 15, 2012 at 7:01 PM, Robby Findler wrote: > On Mon, Oct 15, 2012 at 7:59 PM, Dan Liebgold > wrote: > > On Mon, Oct 15, 2012 at 5:23 PM, Matthew Flatt > wrote: > >> > >> Is there any chance that the ".zo" file timestamps became earlier than > >> the ".rkt" timestamps on end-users' machines? > >> > > > > Yes that is possible... we're distributing using Perforce, which > timestamps > > files at the time of syncing. Would that give the result I'm seeing? > > > > I'm guessing I should supply a custom compile-manager to ignore rkt > files. > > This is certainly a case where we would like to only care about .zos. > > You could just omit the source files, if you really don't care about > them being there. > > Robby > -- Dan Liebgold[dan.liebg...@gmail.com] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] gc much slower in DrR?
On Oct 15, 2012, at 5:47 PM, Matthew Flatt wrote: > Any difference with 9dd83008a6 (just pushed)? I just built from source. Short version: yes, much better. Longer version: DrR still has somewhat longer pauses, but they're now in the 6-10ms range: GC: 0:min @ 242,118K(+159,225K)[+31,728K]; free 24,751K(-24,751K) 31ms @ 57771 GC: 0:min @ 250,704K(+150,639K)[+31,728K]; free 33,064K(-33,064K) 11ms @ 58198 GC: 0:min @ 250,407K(+150,936K)[+31,728K]; free 32,724K(-32,724K) 5ms @ 58611 GC: 0:min @ 250,466K(+150,877K)[+31,728K]; free 32,738K(-32,738K) 6ms @ 59057 GC: 0:min @ 250,496K(+150,847K)[+31,728K]; free 32,723K(-32,723K) 10ms @ 59452 GC: 0:min @ 250,540K(+150,803K)[+31,728K]; free 32,729K(-32,729K) 5ms @ 59865 GC: 0:min @ 250,610K(+150,733K)[+31,728K]; free 32,754K(-32,754K) 5ms @ 60290 GC: 0:min @ 250,639K(+150,704K)[+31,728K]; free 32,734K(-32,734K) 5ms @ 60758 GC: 0:min @ 250,704K(+150,639K)[+31,728K]; free 32,752K(-32,752K) 6ms @ 61176 GC: 0:min @ 250,720K(+150,623K)[+31,728K]; free 32,720K(-32,720K) 6ms @ 61595 GC: 0:min @ 250,767K(+150,576K)[+31,728K]; free 32,722K(-32,722K) 8ms @ 62003 GC: 0:min @ 250,812K(+150,531K)[+31,728K]; free 32,720K(-32,720K) 6ms @ 62429 GC: 0:min @ 250,860K(+150,483K)[+31,728K]; free 32,725K(-32,725K) 9ms @ 62871 GC: 0:min @ 250,902K(+150,441K)[+31,728K]; free 32,727K(-32,727K) 5ms @ 63270 GC: 0:min @ 250,943K(+150,400K)[+31,728K]; free 32,725K(-32,725K) 5ms @ 63687 GC: 0:min @ 250,985K(+150,358K)[+31,728K]; free 32,718K(-32,718K) 10ms @ 64103 Here's command-line racket: GC: 0:min @ 121,746K(+43,341K)[+9,788K]; free 32,712K(-32,712K) 5ms @ 7033 GC: 0:min @ 121,801K(+43,286K)[+9,788K]; free 32,736K(-32,736K) 5ms @ 7467 GC: 0:min @ 121,832K(+43,255K)[+9,788K]; free 32,734K(-32,734K) 3ms @ 7906 GC: 0:min @ 121,866K(+43,221K)[+9,788K]; free 32,733K(-32,733K) 3ms @ 8342 GC: 0:min @ 121,900K(+43,187K)[+9,788K]; free 32,734K(-32,734K) 3ms @ 8791 GC: 0:min @ 121,966K(+43,121K)[+9,788K]; free 32,732K(-32,732K) 4ms @ 9221 GC: 0:min @ 122,002K(+43,085K)[+9,788K]; free 32,741K(-32,741K) 5ms @ 9649 GC: 0:min @ 122,029K(+43,058K)[+9,788K]; free 32,732K(-32,732K) 5ms @ 10092 GC: 0:min @ 122,064K(+43,023K)[+9,788K]; free 32,732K(-32,732K) 3ms @ 10533 GC: 0:min @ 122,100K(+42,987K)[+9,788K]; free 32,741K(-32,741K) 2ms @ 10980 GC: 0:min @ 122,127K(+42,960K)[+9,788K]; free 32,732K(-32,732K) 3ms @ 11424 GC: 0:min @ 122,162K(+42,925K)[+9,788K]; free 32,732K(-32,732K) 4ms @ 11847 GC: 0:min @ 122,197K(+42,890K)[+9,788K]; free 32,734K(-32,734K) 4ms @ 12296 GC: 0:min @ 122,231K(+42,856K)[+9,788K]; free 32,736K(-32,736K) 2ms @ 12734 GC: 0:min @ 122,262K(+42,825K)[+9,788K]; free 32,730K(-32,730K) 2ms @ 13171 GC: 0:min @ 122,300K(+42,787K)[+9,788K]; free 32,739K(-32,739K) 3ms @ 13616 GC: 0:min @ 122,393K(+42,694K)[+9,788K]; free 32,732K(-32,732K) 4ms @ 14067 GC: 0:min @ 122,428K(+42,659K)[+9,788K]; free 32,725K(-32,725K) 3ms @ 14504 GC: 0:min @ 122,470K(+42,617K)[+9,788K]; free 32,726K(-32,726K) 2ms @ 14951 GC: 0:min @ 122,512K(+42,575K)[+9,788K]; free 32,734K(-32,734K) 5ms @ 15427 GC: 0:min @ 122,545K(+42,542K)[+9,788K]; free 32,732K(-32,732K) 2ms @ 15881 GC: 0:min @ 122,580K(+42,507K)[+9,788K]; free 32,729K(-32,729K) 4ms @ 16330 GC: 0:min @ 122,618K(+42,469K)[+9,792K]; free 32,731K(-32,731K) 3ms @ 16771 So, it appears that things have improved a lot… maybe for *both* of them. I also see that DrR's memory use is much lower, which may simply be because I haven't been running the process as long. Also, I was a bit more careful this time, and counted the number of GCs; in the case of DrR, I saw 17 pauses in 30 seconds or about 34 pauses per minute, whereas command-line racket has only 23. Either way, I'm a happy camper. Thanks! … will this go into the upcoming release? John > > At Thu, 11 Oct 2012 15:43:49 -0700, John Clements wrote: >> I'm trying to run signal-based audio programs, and I'm finding that DrR is >> using well over 10x the time to perform the same GC's as command-line >> racket. >> Let me be more specific: I'm running a program that does a little filtering >> to >> combine a couple of oscillators, using big-bang. Running this program in >> DrR, I >> see GC logs that look like this: >> >> GC: 0:min @ 711,798K(+89,158K)[+46,912K]; free 32,654K(-32,654K) 66ms @ >> 2058318 >> GC: 0:min @ 712,070K(+88,886K)[+46,912K]; free 32,667K(-32,667K) 69ms @ >> 2059160 >> GC: 0:min @ 712,421K(+88,534K)[+46,916K]; free 32,724K(-32,724K) 71ms @ >> 2059963 >> GC: 0:min @ 712,621K(+88,334K)[+46,916K]; free 32,698K(-32,698K) 68ms @ >> 2060857 >> GC: 0:min @ 713,411K(+87,545K)[+46,916K]; free 33,103K(-33,103K) 80ms @ >> 2061605 >> GC: 0:min @ 713,424K(+87,532K)[+46,916K]; free 32,815K(-32,815K) 78ms @ >> 2062341 >> GC: 0:min @ 714,273K(+86,683K)[+46,916K]; free 33,363K(-33,363K) 75ms @ >> 2062872 >> GC: 0:min @ 715,799K(+85,157K)[+46,916K]; free 30,988K(-30,988K) 104ms @ >> 2063857 >> … >> >> These GCs are happening about 17 times in every 30 seconds; given the amount >>
