Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Two hours ago, Neil Toronto wrote:
> On 11/24/2012 05:36 PM, Eli Barzilay wrote:
> > I'm probably missing the problem, which wouldn't be surprising
> > since I didn't even tried to look up the `array' documentation...
>
> Well, it didn't exist until I pushed it on Saturday night, so
> looking it up wouldn't have done you any good. :D
(ThereYouGo™.)
> > 2. Alternatively, the last paragraph that you wrote above can also be
> >easily translated by just replacing "[" with "#(", so the array
> >[...]
> >
> > Am I missing something?
>
> Nope. This works really well, so thanks for the fantastical idea.
> I'm keeping it.
(OK, I'll assume that I'm on track then...)
> I considered having array data implicitly quoted, like in vector
> syntax. With nested data, though, the number of design options
> grows quickly, the rules get complicated, and printing becomes a
> nightmare.
>
> For example, it's common to have arrays of Indexes, or (Vectorof
> Index), which would have to print like this with implicit quoting:
>
>(array `#[,'#(0 0) ,'#(0 1)])
>
> Just working out the algorithm to print such a thing made me want to
> curl up and whimper.
Three sidenotes:
1. You probably mean (array `#[,`#(0 0) ,`#(0 1)]), right?
2. There's no real need for producing that yourself -- the racket
printer will do the necessary work, and in this case since
it's all just self-quoting values, then it will show it in a simple
way: (array '#[#(0 0) #(0 1)]). To see what I mean by "do the
necessary work for you", just add
(struct foo () #:transparent)
and then use a few (foo)s in the vector syntax to see what I mean.
3. And besides, doing such algorithms is usually easier than it
sounds. (And IME, they're a perfect example where developement
with test cases makes things way easier...)
So it sounds like there are two related issues: the syntax for code
that produces these things, and the printed syntax -- and they're
related because you want them to be the same. If you choose to go
with the idiomatic thing where vectors (not your arrays) are
implicitly quoted, then things are relatively simple for you, but they
can be hard for users who want to write lots of expressions in them.
For example, I'll need to write something like
(define (±1 i)
(array `#(,(sub1 i) ,i ,(add1 i
make it return a 3x3 array, and you get some less convenient thing
like
(define 1- sub1)
(define 1+ add1)
(define (±1 i j)
(array `#(#(,(list (1- i) (1- j)) ,(list i (1- j)) ,(list (1+ i) (1- j)))
#(,(list (1- i) j ) ,(list i j ) ,(list (1+ i) j ))
#(,(list (1- i) (1+ j)) ,(list i (1+ j)) ,(list (1+ i) (1+ j))
Your other choice is to make `array' a macro that implicitly
quasi-quotes all #(...) expressions and unquotes all other expressions
so you never need to unquote things but you do need to quote lists.
Maybe you can keep the simple thing simple, and for such cases where
there are lots of expressions that you need, have another variant as
this kind of macro? Something like this:
(define-syntax implicitly-unquoted
(syntax-rules ()
[(_ #(x ...)) `#(,(implicitly-unquoted x) ...)]
[(_ x)x]))
(define-syntax-rule (array* xs) (array (implicitly-unquoted xs)))
(define (±1 i j)
(array* #(#((list (1- i) (1- j)) (list i (1- j)) (list (1+ i) (1- j)))
#((list (1- i) j ) (list i j ) (list (1+ i) j ))
#((list (1- i) (1+ j)) (list i (1+ j)) (list (1+ i) (1+ j))
?
--
((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] Square-bracket-sensitive macros in Scribble sandboxes
On 11/24/2012 05:36 PM, Eli Barzilay wrote:
I'm probably missing the problem, which wouldn't be surprising since I
didn't even tried to look up the `array' documentation...
Well, it didn't exist until I pushed it on Saturday night, so looking it
up wouldn't have done you any good. :D
But, there are two things that seem relevant:
1. For just plain vector syntax, you still have quasiquotes do the
usual thing, it only happens that #(...)s are implicitly quoted.
[...]
I... did not know that. Thanks!
2. Alternatively, the last paragraph that you wrote above can also be
easily translated by just replacing "[" with "#(", so the array
macro distinguishes its contents based on that:
-> (define-syntax foo
(syntax-rules ()
[(foo #(x ...)) (list 'array x ...)]
[(foo x)(list 'datum x)]))
-> (foo (+ 1 2))
'(datum 3)
-> (foo #((+ 1 2)))
'(array 3)
It's obviously a trivially simple example, but if you currently
just dispatch on the paren-shape, then using #(...) instead should
work just as well, be more robust, and not introduce the
shape-dependent feature.
Am I missing something?
Nope. This works really well, so thanks for the fantastical idea. I'm
keeping it.
I considered having array data implicitly quoted, like in vector syntax.
With nested data, though, the number of design options grows quickly,
the rules get complicated, and printing becomes a nightmare.
For example, it's common to have arrays of Indexes, or (Vectorof Index),
which would have to print like this with implicit quoting:
(array `#[,'#(0 0) ,'#(0 1)])
Just working out the algorithm to print such a thing made me want to
curl up and whimper.
Neil ⊥
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] indentation: the rb tree didn't help, but a hack to stick-to-next-sexp might
If you're really worried about the allocation, you can work at the snip level and pass in a buffer to be filled in with characters, you know. :) On Mon, Nov 26, 2012 at 2:44 PM, Danny Yoo wrote: > >> and call it a bunch (inside an 'or', one branch for each of those >> strings that are currently in the second argument to member; or well, >> even use a for/or, I guess). Or, if you wanted, you could change your >> existing code to push the 'or' inside the 'and' and then drop the >> promise. > > > > Ok, I'll rewrite the code without the promise, and push to master. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] indentation: the rb tree didn't help, but a hack to stick-to-next-sexp might
> and call it a bunch (inside an 'or', one branch for each of those > strings that are currently in the second argument to member; or well, > even use a for/or, I guess). Or, if you wanted, you could change your > existing code to push the 'or' inside the 'and' and then drop the > promise. > Ok, I'll rewrite the code without the promise, and push to master. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementation of bit vectors
There's also an implementation of bitvectors in db/private/generic/sql-data (sql-bits) that uses bytes, if you want to do a comparison. If a standard bit-vector library gets added, I'll switch the db library to use that instead. Ryan On 11/26/2012 01:43 PM, Jens Axel Søgaard wrote: Hi All, I have implemented an alternative version of bit-vectors using bignums to represent the bits. As is the bignum implementation is much slower, than the vector-of-fixnum one. The main reason as far as I can tell is due to bit-vector-set! . Since bignums aren't mutable I can not simply flip a bit and need to compute a new bignum. Unless bignums are sharing limbs this will be slow for large bit-vectors. Another possibility is that I have missed something obvious. The functions bit-vector-set! is here: (define (bit-vector-set! bv n b) ; bv is a bit-vector ; n is the bit number ; b is #f or #t (define bits (bit-vector-bits bv)) (define mask (arithmetic-shift 1 n)) (cond [b (set-bit-vector-bits! bv (bitwise-ior bits mask))] [(bitwise-bit-set? bits n) (set-bit-vector-bits! bv (bitwise-xor bits mask))] [else (void)])) The entire implementation is here: https://github.com/soegaard/racket/blob/4b299ea66a77100538940794cd799cb88929b7e3/collects/data/bit-vector-bignum.rkt The benchmark is here: https://github.com/soegaard/racket/blob/4b299ea66a77100538940794cd799cb88929b7e3/collects/data/benchmark-bit-vector-representations.rkt _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] indentation: the rb tree didn't help, but a hack to stick-to-next-sexp might
I'd write a helper function like this: (define (has? str) (equal? str (get-text start-pos (+ start-pos (string-length str) and call it a bunch (inside an 'or', one branch for each of those strings that are currently in the second argument to member; or well, even use a for/or, I guess). Or, if you wanted, you could change your existing code to push the 'or' inside the 'and' and then drop the promise. I also don't know why calling forward-match is that expensive. Probably worth following up a little there, I agree. Robby On Mon, Nov 26, 2012 at 12:45 PM, Danny Yoo wrote: > > On Mon, Nov 26, 2012 at 11:31 AM, Robby Findler > wrote: >> >> That kind of thing makes a lot of sense to me. >> >> I'd probably write the code a little bit differently, having a >> function that takes a string and sees if the text starting at >> start-pos matches that string instead of having to special case the >> numbers 1, 2, 3, 5, and 7. This will also let you just put the call to >> forward-match in the second arm of the 'and', so you can avoid the >> promise. >> > > > Can you elaborate what you mean? Do you mean to say to do: > > (get-text pos (min (last-position) (+ pos K))) > > for sufficiently large enough K, and then do the string matching from there? > > > Also do you have an intuition as to why forward-match is expensive? My > understanding is that it only tokenizes the portion of the buffer that got > dirty, so there should be so much reuse of the existing tokens that this > shouldn't be that bad. I guess I need to stare at the code some more. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] indentation: the rb tree didn't help, but a hack to stick-to-next-sexp might
On Mon, Nov 26, 2012 at 11:31 AM, Robby Findler wrote: > That kind of thing makes a lot of sense to me. > > I'd probably write the code a little bit differently, having a > function that takes a string and sees if the text starting at > start-pos matches that string instead of having to special case the > numbers 1, 2, 3, 5, and 7. This will also let you just put the call to > forward-match in the second arm of the 'and', so you can avoid the > promise. > > Can you elaborate what you mean? Do you mean to say to do: (get-text pos (min (last-position) (+ pos K))) for sufficiently large enough K, and then do the string matching from there? Also do you have an intuition as to why forward-match is expensive? My understanding is that it only tokenizes the portion of the buffer that got dirty, so there should be so much reuse of the existing tokens that this shouldn't be that bad. I guess I need to stare at the code some more. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementation of bit vectors
Hi All, I have implemented an alternative version of bit-vectors using bignums to represent the bits. As is the bignum implementation is much slower, than the vector-of-fixnum one. The main reason as far as I can tell is due to bit-vector-set! . Since bignums aren't mutable I can not simply flip a bit and need to compute a new bignum. Unless bignums are sharing limbs this will be slow for large bit-vectors. Another possibility is that I have missed something obvious. The functions bit-vector-set! is here: (define (bit-vector-set! bv n b) ; bv is a bit-vector ; n is the bit number ; b is #f or #t (define bits (bit-vector-bits bv)) (define mask (arithmetic-shift 1 n)) (cond [b (set-bit-vector-bits! bv (bitwise-ior bits mask))] [(bitwise-bit-set? bits n) (set-bit-vector-bits! bv (bitwise-xor bits mask))] [else (void)])) The entire implementation is here: https://github.com/soegaard/racket/blob/4b299ea66a77100538940794cd799cb88929b7e3/collects/data/bit-vector-bignum.rkt The benchmark is here: https://github.com/soegaard/racket/blob/4b299ea66a77100538940794cd799cb88929b7e3/collects/data/benchmark-bit-vector-representations.rkt -- Jens Axel Søgaard _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] indentation: the rb tree didn't help, but a hack to stick-to-next-sexp might
That kind of thing makes a lot of sense to me. I'd probably write the code a little bit differently, having a function that takes a string and sees if the text starting at start-pos matches that string instead of having to special case the numbers 1, 2, 3, 5, and 7. This will also let you just put the call to forward-match in the second arm of the 'and', so you can avoid the promise. And finally, this is the exact *opposite* of a premature optimization! It's the perfect kind! The kind based on real data and that actually matters! Robby On Mon, Nov 26, 2012 at 12:28 AM, Danny Yoo wrote: > At least, as far as I can tell, it does not perform any better than the > splay tree. It's actually about a second slower when indenting > drracket/private/unit.rkt. Darn it. > > > However, I did find something that's slightly nutty: the following patch > appears to greatly improve indentation: > > > https://github.com/dyoo/racket/commit/36670d335d72bb164f3e5dbd97763d69664337a2 > > > This crazy code is motivated by the following snippets from the profiler, > when a profile call is wrapped around tabify-selection: > > > > loop [34] > 0.1% > get-backward-sexp method in > ...k/private/racket.rkt:425:2 [28] 99.9% > [37] 50648(61.1%) 0(0.0%) stick-to-next-sexp? method in > ...k/private/racket.rkt:425:2 ... > do-forward-match method in > ...rk/private/color.rkt:71:2 [50] 99.9% > > ... > > > get-forward-sexp method in > ...k/private/racket.rkt:425:2 [38]17.1% > stick-to-next-sexp? method in > ...k/private/racket.rkt:425:2 [37] 82.9% > [50] 61043(73.6%)53(0.1%) do-forward-match method in > ...rk/private/color.rkt:71:2 ... > colorer-driver method in > ...rk/private/color.rkt:71:2 [66] 99.8% > match-forward method in paren-tree% [72] > 0.1% > > > > If I'm reading the profiler output correctly, this is saying that 61% of the > time is being spent in stick-to-next-sexp?, and that in stick-to-next-sexp?, > the majority of the time goes through do-forward-match. In the diff above, > I made the code speculatively match the text: if it fails, there's no need > to call do-forward-match. I reasoned that it looked expensive to call: > maybe we can avoid it in the common case. > > I'm seeing indentation times cut by 50%; I've been staring at this all day, > so I don't trust myself yet. Can anyone else confirm that that they see a > similarly dramatic improvement in tabification when this hack is in place? > > > I have not committed this yet because it's kludgy code. :) I know the > above is not quite the right way to solve the problem, but it seems like it > would be worthwhile to do something like this. Of course, it would be > better to fix forward-match so it isn't so expensive. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25762: master branch updated
Great, thanks! On Mon, Nov 26, 2012 at 3:24 PM, Robby Findler wrote: > Okay, I've pushed a fix for a bug that would explain the latest > stacktrace. Please let me know if you spot more problems! > > Thanks, > Robby > > On Mon, Nov 26, 2012 at 12:18 PM, Robby Findler > wrote: > > Well, probably what's happening is that you got an error earlier and that > > error left DrRacket in a strange state. Are you seeing any of this before > > you see the first "internal error" box? > > > > Meanwhile, I've pushed 2 fixes and the stacktrace you sent earlier is > > definitely helping me hone in on another one (the one you saw while > looking > > at an error in drracket). > > > > (The commit below actually fixes one bug.) > > > > Robby > > > > > > On Monday, November 26, 2012, James Swaine wrote: > >> > >> Is anyone else seeing strange behavior in DrRacket since this latest > round > >> of DrRacket-related commits? Here's what I'm seeing: > >> > >> -With definitions/interactions side by side, sometimes the vertical > scroll > >> bar in the interactions window disappears for no reason. > >> -Saving a file can sometimes render the definitions window unresponsive. > >> Occasionally the definitions window will still respond but won't allow > me to > >> edit code anymore. > >> -If I switch from one tab to another and then back to the original, the > >> definitions window sometimes becomes blank. > >> -If I run a program that raises an error, viewing the stack trace by > >> clicking on the icon in the interactions window can cause DrRacket to > raise > >> an error (I only saw this once, and unfortunately I don't have the error > >> message). > >> -The status bar area that displays information about background > expansion > >> can arbitrarily disappear, however the label providing the information > (e.g. > >> "Background expansion finished") remains and appears to be superimposed > on > >> top of the definitions window. > >> > >> I don't have specific steps to reproduce yet so I'm not able to submit > bug > >> report(s), but I'll see what I can come up with. Maybe I'm the only one > >> experiencing this. > >> > >> > >> > >> > >> On Mon, Nov 26, 2012 at 10:55 AM, wrote: > >>> > >>> robby has updated `master' from 569af52ffc to ba89a5da92. > >>> http://git.racket-lang.org/plt/569af52ffc..ba89a5da92 > >>> > >>> =[ One Commit > ]= > >>> Directory summary: > >>> 100.0% collects/framework/private/ > >>> > >>> ~~ > >>> > >>> ba89a5d Robby Findler 2012-11-26 07:54 > >>> : > >>> | fix bug in error checking code > >>> : > >>> M collects/framework/private/text.rkt | 14 -- > >>> > >>> =[ Overall Diff > ]=== > >>> > >>> collects/framework/private/text.rkt > >>> ~~~ > >>> --- OLD/collects/framework/private/text.rkt > >>> +++ NEW/collects/framework/private/text.rkt > >>> @@ -42,12 +42,14 @@ > >>> (define-struct rectangle (left top right bottom style color) > #:inspector > >>> #f) > >>> > >>> (define (build-rectangle left top right bottom style color) > >>> - (when (right . < . left) > >>> -(error 'build-rectangle "found right to the right of left: ~s" > >>> - (list left top right bottom style color))) > >>> - (when (bottom . < . top) > >>> -(error 'build-rectangle "found bottom above top: ~s" > >>> - (list left top right bottom style color))) > >>> + (unless (or (symbol? right) (symbol? left)) > >>> +(when (right . < . left) > >>> + (error 'build-rectangle "found right to the right of left: ~s" > >>> + (list left top right bottom style color > >>> + (unless (or (symbol? top) (symbol? bottom)) > >>> +(when (bottom . < . top) > >>> + (error 'build-rectangle "found bottom above top: ~s" > >>> + (list left top right bottom style color > >>>(make-rectangle left top right bottom style color)) > >>> > >>> > >> > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25762: master branch updated
Okay, I've pushed a fix for a bug that would explain the latest stacktrace. Please let me know if you spot more problems! Thanks, Robby On Mon, Nov 26, 2012 at 12:18 PM, Robby Findler wrote: > Well, probably what's happening is that you got an error earlier and that > error left DrRacket in a strange state. Are you seeing any of this before > you see the first "internal error" box? > > Meanwhile, I've pushed 2 fixes and the stacktrace you sent earlier is > definitely helping me hone in on another one (the one you saw while looking > at an error in drracket). > > (The commit below actually fixes one bug.) > > Robby > > > On Monday, November 26, 2012, James Swaine wrote: >> >> Is anyone else seeing strange behavior in DrRacket since this latest round >> of DrRacket-related commits? Here's what I'm seeing: >> >> -With definitions/interactions side by side, sometimes the vertical scroll >> bar in the interactions window disappears for no reason. >> -Saving a file can sometimes render the definitions window unresponsive. >> Occasionally the definitions window will still respond but won't allow me to >> edit code anymore. >> -If I switch from one tab to another and then back to the original, the >> definitions window sometimes becomes blank. >> -If I run a program that raises an error, viewing the stack trace by >> clicking on the icon in the interactions window can cause DrRacket to raise >> an error (I only saw this once, and unfortunately I don't have the error >> message). >> -The status bar area that displays information about background expansion >> can arbitrarily disappear, however the label providing the information (e.g. >> "Background expansion finished") remains and appears to be superimposed on >> top of the definitions window. >> >> I don't have specific steps to reproduce yet so I'm not able to submit bug >> report(s), but I'll see what I can come up with. Maybe I'm the only one >> experiencing this. >> >> >> >> >> On Mon, Nov 26, 2012 at 10:55 AM, wrote: >>> >>> robby has updated `master' from 569af52ffc to ba89a5da92. >>> http://git.racket-lang.org/plt/569af52ffc..ba89a5da92 >>> >>> =[ One Commit ]= >>> Directory summary: >>> 100.0% collects/framework/private/ >>> >>> ~~ >>> >>> ba89a5d Robby Findler 2012-11-26 07:54 >>> : >>> | fix bug in error checking code >>> : >>> M collects/framework/private/text.rkt | 14 -- >>> >>> =[ Overall Diff ]=== >>> >>> collects/framework/private/text.rkt >>> ~~~ >>> --- OLD/collects/framework/private/text.rkt >>> +++ NEW/collects/framework/private/text.rkt >>> @@ -42,12 +42,14 @@ >>> (define-struct rectangle (left top right bottom style color) #:inspector >>> #f) >>> >>> (define (build-rectangle left top right bottom style color) >>> - (when (right . < . left) >>> -(error 'build-rectangle "found right to the right of left: ~s" >>> - (list left top right bottom style color))) >>> - (when (bottom . < . top) >>> -(error 'build-rectangle "found bottom above top: ~s" >>> - (list left top right bottom style color))) >>> + (unless (or (symbol? right) (symbol? left)) >>> +(when (right . < . left) >>> + (error 'build-rectangle "found right to the right of left: ~s" >>> + (list left top right bottom style color >>> + (unless (or (symbol? top) (symbol? bottom)) >>> +(when (bottom . < . top) >>> + (error 'build-rectangle "found bottom above top: ~s" >>> + (list left top right bottom style color >>>(make-rectangle left top right bottom style color)) >>> >>> >> > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25762: master branch updated
Well, probably what's happening is that you got an error earlier and that error left DrRacket in a strange state. Are you seeing any of this before you see the first "internal error" box? Meanwhile, I've pushed 2 fixes and the stacktrace you sent earlier is definitely helping me hone in on another one (the one you saw while looking at an error in drracket). (The commit below actually fixes one bug.) Robby On Monday, November 26, 2012, James Swaine wrote: > Is anyone else seeing strange behavior in DrRacket since this latest round > of DrRacket-related commits? Here's what I'm seeing: > > -With definitions/interactions side by side, sometimes the vertical scroll > bar in the interactions window disappears for no reason. > -Saving a file can sometimes render the definitions window unresponsive. > Occasionally the definitions window will still respond but won't allow me > to edit code anymore. > -If I switch from one tab to another and then back to the original, the > definitions window sometimes becomes blank. > -If I run a program that raises an error, viewing the stack trace by > clicking on the icon in the interactions window can cause DrRacket to raise > an error (I only saw this once, and unfortunately I don't have the error > message). > -The status bar area that displays information about background expansion > can arbitrarily disappear, however the label providing the information > (e.g. "Background expansion finished") remains and appears to be > superimposed on top of the definitions window. > > I don't have specific steps to reproduce yet so I'm not able to submit bug > report(s), but I'll see what I can come up with. Maybe I'm the only one > experiencing this. > > > > > On Mon, Nov 26, 2012 at 10:55 AM, 'cvml', 'ro...@racket-lang.org');> > > wrote: > >> robby has updated `master' from 569af52ffc to ba89a5da92. >> http://git.racket-lang.org/plt/569af52ffc..ba89a5da92 >> >> =[ One Commit ]= >> Directory summary: >> 100.0% collects/framework/private/ >> >> ~~ >> >> ba89a5d Robby Findler > 'ro...@racket-lang.org');>> 2012-11-26 07:54 >> : >> | fix bug in error checking code >> : >> M collects/framework/private/text.rkt | 14 -- >> >> =[ Overall Diff ]=== >> >> collects/framework/private/text.rkt >> ~~~ >> --- OLD/collects/framework/private/text.rkt >> +++ NEW/collects/framework/private/text.rkt >> @@ -42,12 +42,14 @@ >> (define-struct rectangle (left top right bottom style color) #:inspector >> #f) >> >> (define (build-rectangle left top right bottom style color) >> - (when (right . < . left) >> -(error 'build-rectangle "found right to the right of left: ~s" >> - (list left top right bottom style color))) >> - (when (bottom . < . top) >> -(error 'build-rectangle "found bottom above top: ~s" >> - (list left top right bottom style color))) >> + (unless (or (symbol? right) (symbol? left)) >> +(when (right . < . left) >> + (error 'build-rectangle "found right to the right of left: ~s" >> + (list left top right bottom style color >> + (unless (or (symbol? top) (symbol? bottom)) >> +(when (bottom . < . top) >> + (error 'build-rectangle "found bottom above top: ~s" >> + (list left top right bottom style color >>(make-rectangle left top right bottom style color)) >> >> >> > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
+1 On Nov 26, 2012, at 11:06 AM, Robby Findler wrote: > I think we should change 'case'. > > I think we should also add a clear note to the documentation for case saying > "this is not the same as 'case' in Scheme because it uses equal?, not eqv?" > and giving a few examples to show the difference to head off any confusion. > > Robby > > On Monday, November 26, 2012, Jon Zeppieri wrote: > The 'case-check' branch of my github fork now implements Robby's > suggestion. [https://github.com/97jaz/racket/tree/case-check] > > I ran the full build (including documentation), ran > collects/tests/run-automated-tests.rkt, and started up and played > around with DrRacket. The only logged messages were from the tests I > added, which specifically test the new behavior. > > -Jon > > On Sun, Nov 25, 2012 at 11:29 PM, Jon Zeppieri wrote: > > Thanks! -J > > > > On Sun, Nov 25, 2012 at 10:59 PM, Sam Tobin-Hochstadt > > wrote: > >> On Sun, Nov 25, 2012 at 10:50 PM, Jon Zeppieri wrote: > >>> > >>> Is there a way to give check-em a type for TR without breaking it for > >>> non-typed code? > >> > >> Yes, you should add an entry to typed-racket/base-env/base-special-env > >> for `check-em`. Note that you'll have to specify which module > >> `check-em` is defined in. > >> > >> -- > >> sam th > >> sa...@ccs.neu.edu > _ > 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] [plt] Push #25762: master branch updated
Is anyone else seeing strange behavior in DrRacket since this latest round of DrRacket-related commits? Here's what I'm seeing: -With definitions/interactions side by side, sometimes the vertical scroll bar in the interactions window disappears for no reason. -Saving a file can sometimes render the definitions window unresponsive. Occasionally the definitions window will still respond but won't allow me to edit code anymore. -If I switch from one tab to another and then back to the original, the definitions window sometimes becomes blank. -If I run a program that raises an error, viewing the stack trace by clicking on the icon in the interactions window can cause DrRacket to raise an error (I only saw this once, and unfortunately I don't have the error message). -The status bar area that displays information about background expansion can arbitrarily disappear, however the label providing the information (e.g. "Background expansion finished") remains and appears to be superimposed on top of the definitions window. I don't have specific steps to reproduce yet so I'm not able to submit bug report(s), but I'll see what I can come up with. Maybe I'm the only one experiencing this. On Mon, Nov 26, 2012 at 10:55 AM, wrote: > robby has updated `master' from 569af52ffc to ba89a5da92. > http://git.racket-lang.org/plt/569af52ffc..ba89a5da92 > > =[ One Commit ]= > Directory summary: > 100.0% collects/framework/private/ > > ~~ > > ba89a5d Robby Findler 2012-11-26 07:54 > : > | fix bug in error checking code > : > M collects/framework/private/text.rkt | 14 -- > > =[ Overall Diff ]=== > > collects/framework/private/text.rkt > ~~~ > --- OLD/collects/framework/private/text.rkt > +++ NEW/collects/framework/private/text.rkt > @@ -42,12 +42,14 @@ > (define-struct rectangle (left top right bottom style color) #:inspector > #f) > > (define (build-rectangle left top right bottom style color) > - (when (right . < . left) > -(error 'build-rectangle "found right to the right of left: ~s" > - (list left top right bottom style color))) > - (when (bottom . < . top) > -(error 'build-rectangle "found bottom above top: ~s" > - (list left top right bottom style color))) > + (unless (or (symbol? right) (symbol? left)) > +(when (right . < . left) > + (error 'build-rectangle "found right to the right of left: ~s" > + (list left top right bottom style color > + (unless (or (symbol? top) (symbol? bottom)) > +(when (bottom . < . top) > + (error 'build-rectangle "found bottom above top: ~s" > + (list left top right bottom style color >(make-rectangle left top right bottom style color)) > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
I think we should change 'case'. I think we should also add a clear note to the documentation for case saying "this is not the same as 'case' in Scheme because it uses equal?, not eqv?" and giving a few examples to show the difference to head off any confusion. Robby On Monday, November 26, 2012, Jon Zeppieri wrote: > The 'case-check' branch of my github fork now implements Robby's > suggestion. [https://github.com/97jaz/racket/tree/case-check] > > I ran the full build (including documentation), ran > collects/tests/run-automated-tests.rkt, and started up and played > around with DrRacket. The only logged messages were from the tests I > added, which specifically test the new behavior. > > -Jon > > On Sun, Nov 25, 2012 at 11:29 PM, Jon Zeppieri > > > wrote: > > Thanks! -J > > > > On Sun, Nov 25, 2012 at 10:59 PM, Sam Tobin-Hochstadt > > > > wrote: > >> On Sun, Nov 25, 2012 at 10:50 PM, Jon Zeppieri > >> > > wrote: > >>> > >>> Is there a way to give check-em a type for TR without breaking it for > >>> non-typed code? > >> > >> Yes, you should add an entry to typed-racket/base-env/base-special-env > >> for `check-em`. Note that you'll have to specify which module > >> `check-em` is defined in. > >> > >> -- > >> sam th > >> sa...@ccs.neu.edu > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 'case' using equal?
The 'case-check' branch of my github fork now implements Robby's suggestion. [https://github.com/97jaz/racket/tree/case-check] I ran the full build (including documentation), ran collects/tests/run-automated-tests.rkt, and started up and played around with DrRacket. The only logged messages were from the tests I added, which specifically test the new behavior. -Jon On Sun, Nov 25, 2012 at 11:29 PM, Jon Zeppieri wrote: > Thanks! -J > > On Sun, Nov 25, 2012 at 10:59 PM, Sam Tobin-Hochstadt > wrote: >> On Sun, Nov 25, 2012 at 10:50 PM, Jon Zeppieri wrote: >>> >>> Is there a way to give check-em a type for TR without breaking it for >>> non-typed code? >> >> Yes, you should add an entry to typed-racket/base-env/base-special-env >> for `check-em`. Note that you'll have to specify which module >> `check-em` is defined in. >> >> -- >> sam th >> sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
