Re: [racket-dev] RFC: Coding Guidelines
On Sat, Aug 28, 2010 at 5:34 PM, Eli Barzilay wrote: > I (finally) read this and the thread that went on at the time, and I > don't see any point in all of this, besides a vage plea to encourage > tests, and a slightly more concrete (but impractical) call for stress > tests. I think laying down general philosophy is useful. It sets a tone. However, I agree with most of your other points though I'm less concerned about the ownership of code side, probably 'cause I don't have to deal with everyday. > * "\"Primum non nocere\"" -- after looking this up (bad for such a > document), I strongly disagree with it. IIUC, it reads as "if it > works, don't mess with it" Idiomatically that would be "if it ain't broke, don't fix it". I too strongly disagree with this. > * Yet another huge ommision from such a document is style. This comes > in several flavors: Yes. This is one of the most important aspect IMO. Consistent style makes it easy for anyone to navigate the code base. We have evolved a house style at Untyped and it is useful. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] RFC: Coding Guidelines
On Sep 2, Noel Welsh wrote: > On Sat, Aug 28, 2010 at 5:34 PM, Eli Barzilay wrote: > > I (finally) read this and the thread that went on at the time, and > > I don't see any point in all of this, besides a vage plea to > > encourage tests, and a slightly more concrete (but impractical) > > call for stress tests. > > I think laying down general philosophy is useful. It sets a tone. > However, I agree with most of your other points though I'm less > concerned about the ownership of code side, probably 'cause I don't > have to deal with everyday. Well -- you do, in a sense. When something is broken, someone needs to fix it. There's tons of stuff that is (or has) bitrotting away since there's no proper owner to take care of some code, or bugs in code with no clear owner need to wait for someone to volunteer to do the work -- and that's less likely to happen. My worry re ownership is that making a mess there will lead to more of these problems. To make a concrete example, there's some unstable code now that is a big extension to a big library -- and if the theoretical plan where the unstable manager merges that code in, we get three people involved: (a) the original author of the library, (b) the author of the extension, and (c) the unstable manager. Now what happens to bugs in the resulting extended library? To me, this sounds like a recipe for one of those silly volleyball moments where the three players stand next to the ball with "I thought *you'd* pick it" looks. Because of this, I much rather see such extension getting in by (b) cooperating with (a) to get the extension in. With the result being - (a) making sure he knows all the bits and becoming the owner of the result; - (b) becoming the owner of the resulting extended library; - or deciding on a clear separation where the two parts are visible (possibly involving work on either side), and the two maintain their own bits. > > * "\"Primum non nocere\"" -- after looking this up (bad for such a > > document), I strongly disagree with it. IIUC, it reads as "if > > it works, don't mess with it" > > Idiomatically that would be "if it ain't broke, don't fix it". I too > strongly disagree with this. (Yeah, I saw that -- and the context that it's coming from is dealing with a very different kind of machine, where the rules are very different...) -- ((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
Re: [racket-dev] RFC: Coding Guidelines
On Thu, Sep 2, 2010 at 11:57 AM, Eli Barzilay wrote: > Well -- you do, in a sense. When something is broken, someone needs > to fix it. There's tons of stuff that is (or has) bitrotting away > since there's no proper owner to take care of some code, or bugs in > code with no clear owner need to wait for someone to volunteer to do > the work -- and that's less likely to happen. Agreed. I think less stuff should be in the core, and this would go some way to solving the problem. I think you want this as well. To elaborate, I think Racket should still come with all the libraries it currently does but 1) they should have versions like Planet does and 2) they should be distributable independently of Racket core. This way a particular library update is independent of updates to other libraries or the core. N. > My worry re ownership is that making a mess there will lead to more of > these problems. To make a concrete example, there's some unstable > code now that is a big extension to a big library -- and if the > theoretical plan where the unstable manager merges that code in, we > get three people involved: (a) the original author of the library, (b) > the author of the extension, and (c) the unstable manager. Now what > happens to bugs in the resulting extended library? To me, this sounds > like a recipe for one of those silly volleyball moments where the > three players stand next to the ball with "I thought *you'd* pick it" > looks. > > Because of this, I much rather see such extension getting in by (b) > cooperating with (a) to get the extension in. With the result being > - (a) making sure he knows all the bits and becoming the owner of > the result; > - (b) becoming the owner of the resulting extended library; > - or deciding on a clear separation where the two parts are visible > (possibly involving work on either side), and the two maintain their > own bits. > > >> > * "\"Primum non nocere\"" -- after looking this up (bad for such a >> > document), I strongly disagree with it. IIUC, it reads as "if >> > it works, don't mess with it" >> >> Idiomatically that would be "if it ain't broke, don't fix it". I too >> strongly disagree with this. > > (Yeah, I saw that -- and the context that it's coming from is dealing > with a very different kind of machine, where the rules are very > different...) > > -- > ((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
Re: [racket-dev] RFC: Coding Guidelines
On Sep 2, Noel Welsh wrote: > On Thu, Sep 2, 2010 at 11:57 AM, Eli Barzilay wrote: > > Well -- you do, in a sense. When something is broken, someone > > needs to fix it. There's tons of stuff that is (or has) > > bitrotting away since there's no proper owner to take care of some > > code, or bugs in code with no clear owner need to wait for someone > > to volunteer to do the work -- and that's less likely to happen. > > Agreed. I think less stuff should be in the core, and this would go > some way to solving the problem. I think you want this as well. Yes, I want this -- but the ownership issue is still pending as long as the libraries in question are maintained in the plt repository as a group effort. > To elaborate, I think Racket should still come with all the > libraries it currently does but 1) they should have versions like > Planet does and 2) they should be distributable independently of > Racket core. This way a particular library update is independent of > updates to other libraries or the core. (Yes, that's the plan.) -- ((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
[racket-dev] Universe double buffering
Why doesn't 2htdp/universe use double-buffering? --- nadeem _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Universe double buffering
Why do you think it doesn't? On Sep 2, 2010, at 8:52 AM, Nadeem Abdul Hamid wrote: > Why doesn't 2htdp/universe use double-buffering? > > --- nadeem > _ > 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] Universe double buffering
> Why do you think it doesn't? (I'm assuming you mean: "What makes me think that it is not double-buffering?") ... I have a list of 15 thumbnail images of people and a function that places pairs of them side by side, using above/beside to create a 133 x 581 image. i.e. choose-and-show-pairs : (listof image) -> image Now, when I do: (big-bang PIC-LIST (on-draw choose-and-show-pairs)) I see each individual image getting laid out, one by one, rather excrutiatingly slowly. The choose-and-show-pairs actually randomizes the pairing up, and so if I move the mouse over the canvas, apparently the redraw handler is called, so I see a new set of pairs getting laid out, very slowly. I would have expected a double-buffered implementation to lay out the images in memory on some bitmap buffer and then quickly transfer the bitmap buffer to the canvas, so you don't actually witness the effect of all the above/beside operations happening. > > > > > On Sep 2, 2010, at 8:52 AM, Nadeem Abdul Hamid wrote: > >> Why doesn't 2htdp/universe use double-buffering? >> >> --- nadeem >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > -- Nadeem Abdul Hamid Associate Professor, Computer Science Berry College PO Box 5014 2277 Martha Berry Hwy NW Mount Berry, GA 30149-5014 (706) 368-5632 http://cs.berry.edu/~nhamid/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Universe double buffering
It sounds like there is also a performance problem there too. If you don't mind supplying a program for us to play with to see if we can do better, that would be helpful (but no promises ). Robby On Thu, Sep 2, 2010 at 8:15 AM, Nadeem Abdul Hamid wrote: >> Why do you think it doesn't? > > (I'm assuming you mean: "What makes me think that it is not > double-buffering?") ... > > I have a list of 15 thumbnail images of people and a function that > places pairs of them side by side, using above/beside to create a 133 > x 581 image. i.e. > choose-and-show-pairs : (listof image) -> image > > Now, when I do: > (big-bang PIC-LIST > (on-draw choose-and-show-pairs)) > > I see each individual image getting laid out, one by one, rather > excrutiatingly slowly. The choose-and-show-pairs actually randomizes > the pairing up, and so if I move the mouse over the canvas, apparently > the redraw handler is called, so I see a new set of pairs getting laid > out, very slowly. > > I would have expected a double-buffered implementation to lay out the > images in memory on some bitmap buffer and then quickly transfer the > bitmap buffer to the canvas, so you don't actually witness the effect > of all the above/beside operations happening. > > >> >> >> >> >> On Sep 2, 2010, at 8:52 AM, Nadeem Abdul Hamid wrote: >> >>> Why doesn't 2htdp/universe use double-buffering? >>> >>> --- nadeem >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >> >> > > > > -- > Nadeem Abdul Hamid > Associate Professor, Computer Science > Berry College > PO Box 5014 > 2277 Martha Berry Hwy NW > Mount Berry, GA 30149-5014 > (706) 368-5632 > http://cs.berry.edu/~nhamid/ > _ > 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] Universe double buffering
What happens if you restart drracket and try the same program again? (If the double buffering appears to come back I think I know what happened.) Robby On Thu, Sep 2, 2010 at 8:15 AM, Nadeem Abdul Hamid wrote: >> Why do you think it doesn't? > > (I'm assuming you mean: "What makes me think that it is not > double-buffering?") ... > > I have a list of 15 thumbnail images of people and a function that > places pairs of them side by side, using above/beside to create a 133 > x 581 image. i.e. > choose-and-show-pairs : (listof image) -> image > > Now, when I do: > (big-bang PIC-LIST > (on-draw choose-and-show-pairs)) > > I see each individual image getting laid out, one by one, rather > excrutiatingly slowly. The choose-and-show-pairs actually randomizes > the pairing up, and so if I move the mouse over the canvas, apparently > the redraw handler is called, so I see a new set of pairs getting laid > out, very slowly. > > I would have expected a double-buffered implementation to lay out the > images in memory on some bitmap buffer and then quickly transfer the > bitmap buffer to the canvas, so you don't actually witness the effect > of all the above/beside operations happening. > > >> >> >> >> >> On Sep 2, 2010, at 8:52 AM, Nadeem Abdul Hamid wrote: >> >>> Why doesn't 2htdp/universe use double-buffering? >>> >>> --- nadeem >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >> >> > > > > -- > Nadeem Abdul Hamid > Associate Professor, Computer Science > Berry College > PO Box 5014 > 2277 Martha Berry Hwy NW > Mount Berry, GA 30149-5014 > (706) 368-5632 > http://cs.berry.edu/~nhamid/ > _ > 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] Universe double buffering
It still behaves the same. I can literally capture a screenshot of the canvas at any point where only a portion of the pictures have been drawn on it. On Thu, Sep 2, 2010 at 9:53 AM, Robby Findler wrote: > What happens if you restart drracket and try the same program again? > (If the double buffering appears to come back I think I know what > happened.) > > Robby > > On Thu, Sep 2, 2010 at 8:15 AM, Nadeem Abdul Hamid wrote: >>> Why do you think it doesn't? >> >> (I'm assuming you mean: "What makes me think that it is not >> double-buffering?") ... >> >> I have a list of 15 thumbnail images of people and a function that >> places pairs of them side by side, using above/beside to create a 133 >> x 581 image. i.e. >> choose-and-show-pairs : (listof image) -> image >> >> Now, when I do: >> (big-bang PIC-LIST >> (on-draw choose-and-show-pairs)) >> >> I see each individual image getting laid out, one by one, rather >> excrutiatingly slowly. The choose-and-show-pairs actually randomizes >> the pairing up, and so if I move the mouse over the canvas, apparently >> the redraw handler is called, so I see a new set of pairs getting laid >> out, very slowly. >> >> I would have expected a double-buffered implementation to lay out the >> images in memory on some bitmap buffer and then quickly transfer the >> bitmap buffer to the canvas, so you don't actually witness the effect >> of all the above/beside operations happening. >> >> >>> >>> >>> >>> >>> On Sep 2, 2010, at 8:52 AM, Nadeem Abdul Hamid wrote: >>> Why doesn't 2htdp/universe use double-buffering? --- nadeem _ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] match/fail*: re-inventing the wheel for better error messages with match?
Match is fantastic, and sometimes you want finer control over the error
messages. This morning I whipped up a "match/fail*" macro, which successively
matches against a sequence of patterns, and allows you to specify a separate
fail message for each "layer".
It's a simple macro, and I give a use of it (my use of it) below, followed by
its simple definition.
FWIW, I *love* how check syntax shows the binding arrows from the pattern
variables to the uses, outside of the defining clause.
Is there something like this already in an existing library? If not, would this
be useful to anyone?
John
p.s.: the use of syntax-parse in the definition of the macro was awesome, and
produced at least one really nice error message for me.
;; first-line-checker : string -> (or/c string symbol)
;; returns a string, indicating an error message, or 'success,
;; indicating success.
(provide first-line-checker)
(define (first-line-checker first-line)
(match/fail* 'success
[(tokenize-string first-line) `("public" ,rest ...) "This function
signature must begin with the word \"public\"."]
[rest `(,(? type-name? ty) ,rest ...) (format "After the word public, you
need a type name.")]
[ty "int" "This function's return type must be \"int\"."]
[rest `(,pre ... "(" ,args ... ")" ,leftover ...) "A function header must
contain a pair of parentheses around the argument list."]
[leftover `() "There shouldn't be anything after the right-paren (\")\")."]
[pre `(,name) (if (empty? pre)
"There must be a function name between the type of the
function and the argument list."
"The function name (a single word) is the only thing that
comes between the type of the function and the argument list.")]
[name "getApproxAge" "The name of the function should be \"getApproxAge\"."]
[args `(,arg1 ... "," ,arg2 ...) "You need a comma in the argument list to
separate the two arguments."]
[arg1 `(,arg1ty ,arg1name) "The first argument should consist of a type and
a name (exactly two words)."]
[arg1ty (? type-name? _) "The first part of the first argument must be a
type."]
[arg1ty "int" "The first argument should be of type \"int\"."]
[arg1name "birthYear" "The name of the first argument should be
\"birthYear\"."]
[arg2 `(,arg2ty ,arg2name) "The second argument should consist of a type
and a name."]
[arg2ty (? type-name? _) "The first part of the second argument must be a
type."]
[arg2ty "int" "The second argument should be of type \"int\"."]
[arg2name "birthYear" "The name of the second argument should be
\"birthYear\"."]))
;; the match/fail macro.
;; A use of match/fail contains a single 'success' value
;; followed by a bunch of fail clauses. Each fail clause
;; matches a value against a pattern and signals the given
;; error if it fails. If it succeeds, it goes on to the
;; next clause. Note that pattern variables bound in each
;; pattern may be used in the remaining clauses.
(define-syntax (match/fail* stx)
(define-syntax-class match/fail-clause
#:description "match/fail clause"
;; pat:expr *can't* be right here...
(pattern (val:expr pat:expr fail:expr)))
(syntax-parse stx
[(_ retval) #'retval]
[(_ retval:expr clause:match/fail-clause more-clauses ...)
#`(match clause.val
[clause.pat (match/fail* retval more-clauses ...)]
[fail clause.fail])]))
smime.p7s
Description: S/MIME cryptographic signature
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Patching a distribution
At Thu, 2 Sep 2010 12:24:20 -0400, Eric Dobson wrote: > I am trying to create a patch for 5.0.1 in the form of a plt file that > will backport fixes to plai. To do this I also need to backport the > new define-struct. For my class, I'm using an implementation of `define-type' that is different from both the one in 5.0.1 and in 5.0.1.3. It doesn't require the latest `define-struct'. See http://www.cs.utah.edu/~mflatt/tmp/plai_5.0.1_patched/ Students install the "plai" replacement via the ".plt" on this page: http://www.eng.utah.edu/~cs5510/ FWIW, that ".plt" is built with `--replace', but not with `--all-users'. Each student installs it themselves. The documentation from the main installation is still used, even though the collection is replaced in the user-specific area. > I am getting bugs after installation about bytecode mismatches. I'm > wondering if I am doing this correctly and if there is a better way of > doing this? > > I put everything in a folder called collects with the correct inner > structure, and then run the following command to make the plt file. > > raco pack --at-plt --all-users --replace ++setup racket ++setup plai > plai.plt collects It's not going to work well to replace "rackets/private/define-struct.rkt"; the whole Racket bytecode tree would have to be recompiled. Instead, I think you want the alternate "datatype.rkt" --- though it's possible that you need even more repairs in the alternate "datatype.rkt". _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] docs don't make sense
http://docs.racket-lang.org/drracket/extending-drracket.html?q=teachpack#(part._teachpacks) - As an example, the following teachpack provides a lazy cons implementation. To test it, be sure to save it in a file named "lazycons.ss". ... Then, in this program: ... the list all-nums is bound to an infinite list of ascending numbers. - 1. It's not clear why one must "be sure to" save it in that particular name. 2. The above docs don't say to actually *install* the Teachpack. Presumably #2 meant to reference "lazycons.ss". But the "be sure to" is misleading (the name is meaningless). Also, the .ss should probably be .rkt. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] docs don't make sense
I've pushed local fixes. Please feel free to push a better revision if you have the energy. Robby On Thu, Sep 2, 2010 at 4:40 PM, Shriram Krishnamurthi wrote: > http://docs.racket-lang.org/drracket/extending-drracket.html?q=teachpack#(part._teachpacks) > > - > As an example, the following teachpack provides a lazy cons > implementation. To test it, be sure to save it in a file named > "lazycons.ss". > > ... > > Then, in this program: > > ... > > the list all-nums is bound to an infinite list of ascending numbers. > - > > 1. It's not clear why one must "be sure to" save it in that particular name. > > 2. The above docs don't say to actually *install* the Teachpack. > > Presumably #2 meant to reference "lazycons.ss". But the "be sure to" > is misleading (the name is meaningless). > > Also, the .ss should probably be .rkt. > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Problem with GC or with my machine?
I am getting the following error... And this is the only message I get... SIGSEGV MAPERR si_code 1 fault on addr 0xfffc This often means 0xfffc isn't getting marked, and was prematurely freed Aborted What does it mean? Has anyone seen this? If you want to take a look at the code that is causing this, let me know. Hari _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
