Re: [racket-dev] Expression comments
On Wednesday, Harry Spier wrote: > Dear list members, > I've just received an email that the bug report >http://bugs.racket-lang.org/query/?cmd=view&pr=12375 > I initially submitted about this has been closed. But I'm not clear > from the e-mail whether it is now intended to leave the commented > out s-expressions gray or to follow up and change the behaviour > based on the developer members comments to this thread. (FWIW, these emails were a result of me doing some cleanup with bug owners. The actual closing of this bug was in 2011.) -- ((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] Pull request for make-base-eval
On 2/22/13 7:05 PM, David Van Horn wrote: This is a pull request to make racket/scribble make-base-eval more like racket/sandbox make-evaluator, which was useful to me, but I wasn't sure if the current design avoided this for some reason. This should be a backwards compatible change, but I have not tested it. https://github.com/plt/racket/pull/256 Actually this only seems to work when run from within DrRacket. The following example works fine from DrRacket, but gives an error from the command line using raco scribble: namespace-attach-module: a different module with the same name is already in the destination namespace #lang scribble/manual @(require scribble/eval) @(define the-eval (make-base-eval #:lang 'racket)) @examples[#:eval the-eval (add1 7)] It's not at all clear to me how to resolve the problem. David _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Pull request for make-base-eval
This is a pull request to make racket/scribble make-base-eval more like racket/sandbox make-evaluator, which was useful to me, but I wasn't sure if the current design avoided this for some reason. This should be a backwards compatible change, but I have not tested it. https://github.com/plt/racket/pull/256 Thanks, David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Stumped!
I didn't investigate your program to be sure it isn't some other bug, but the potential for this kind of bad behavior has always been with us, yes. Robby On Fri, Feb 22, 2013 at 3:59 PM, Pierpaolo Bernardi wrote: > So, it has always behaved like this? I'm really surprised that I have > never been bitten by this before. 8^) > > > On Fri, Feb 22, 2013 at 10:51 PM, Robby Findler > wrote: > > I think that the lack of information about tail calls can be particularly > > pernicious in the presence of multiple value errors. It would be good to > do > > better, but I'm not sure how. The errortrace library contains what we > > currently do so you'd want to experiment there if you have an idea. > > > > Robby > > > > > > On Fri, Feb 22, 2013 at 1:13 PM, Pierpaolo Bernardi > > > wrote: > >> > >> On Fri, Feb 22, 2013 at 4:40 PM, Ryan Culpepper > wrote: > >> > The line > >> > > >> > (date-day quando)99 > >> > > >> > looks pretty suspicious; with the 99 there, the first branch of the > >> > enclosing 'if' expression returns 8 values but the second branch > returns > >> > 7 > >> > values. > >> > >> Yes, that was the source of the error (a mistake due to me pressing > >> the Num Lock key inadvertently). > >> > >> What had me stumped is that DrRacket gives no hint about the location > >> of the error. Not even the right file! > >> _ > >> Racket Developers list: > >> http://lists.racket-lang.org/dev > > > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26344: master branch updated
Well, I didn't try to explain _that_ part of the issue here (what I called "b" in my message on the audit trail). It is much more complex and based more on conjecture, so I'm hesitant to even try especially when the existing discussion covers a more general, related problem that is likely to satisfy people. (I hope.) Robby On Fri, Feb 22, 2013 at 3:56 PM, Sam Tobin-Hochstadt wrote: > Ok, that makes sense. > > I think you should maybe add the word "floor" in the nitty-gritty > documentation. You might also link from that discussion in the docs > to the Cairo docs here: http://cairographics.org/operators/ . > However, I can't find anything where they say they round down rather > than to nearest. Grrr. Makes me glad for the Racket documentation > (such as all the nitty-gritty sections you've written). > > On Fri, Feb 22, 2013 at 4:49 PM, Robby Findler > wrote: > > No, I don't think it does. The drawing operation is called "over" and it > > takes two colors (rgb, say), and an alpha and produces a color (rgb). So > you > > always start with some solid color in the background and draw the shape > on > > top of it, resulting in another color that some other shape can be drawn > on > > top of. > > > > > > On Fri, Feb 22, 2013 at 3:45 PM, Sam Tobin-Hochstadt > > wrote: > >> > >> On Fri, Feb 22, 2013 at 4:40 PM, wrote: > >> > > >> > + The list of colors is obtained by drawing the image on a white > >> > + background and then reading off the colors of the pixels that were > >> > drawn. > >> > >> Is there a particular reason to choose white, as opposed to clear, for > >> the background in this test? Does drawing on a "clear" background > >> even make any sense in this case? > >> > >> Sam > > > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Stumped!
So, it has always behaved like this? I'm really surprised that I have never been bitten by this before. 8^) On Fri, Feb 22, 2013 at 10:51 PM, Robby Findler wrote: > I think that the lack of information about tail calls can be particularly > pernicious in the presence of multiple value errors. It would be good to do > better, but I'm not sure how. The errortrace library contains what we > currently do so you'd want to experiment there if you have an idea. > > Robby > > > On Fri, Feb 22, 2013 at 1:13 PM, Pierpaolo Bernardi > wrote: >> >> On Fri, Feb 22, 2013 at 4:40 PM, Ryan Culpepper wrote: >> > The line >> > >> > (date-day quando)99 >> > >> > looks pretty suspicious; with the 99 there, the first branch of the >> > enclosing 'if' expression returns 8 values but the second branch returns >> > 7 >> > values. >> >> Yes, that was the source of the error (a mistake due to me pressing >> the Num Lock key inadvertently). >> >> What had me stumped is that DrRacket gives no hint about the location >> of the error. Not even the right file! >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26344: master branch updated
Ok, that makes sense. I think you should maybe add the word "floor" in the nitty-gritty documentation. You might also link from that discussion in the docs to the Cairo docs here: http://cairographics.org/operators/ . However, I can't find anything where they say they round down rather than to nearest. Grrr. Makes me glad for the Racket documentation (such as all the nitty-gritty sections you've written). On Fri, Feb 22, 2013 at 4:49 PM, Robby Findler wrote: > No, I don't think it does. The drawing operation is called "over" and it > takes two colors (rgb, say), and an alpha and produces a color (rgb). So you > always start with some solid color in the background and draw the shape on > top of it, resulting in another color that some other shape can be drawn on > top of. > > > On Fri, Feb 22, 2013 at 3:45 PM, Sam Tobin-Hochstadt > wrote: >> >> On Fri, Feb 22, 2013 at 4:40 PM, wrote: >> > >> > + The list of colors is obtained by drawing the image on a white >> > + background and then reading off the colors of the pixels that were >> > drawn. >> >> Is there a particular reason to choose white, as opposed to clear, for >> the background in this test? Does drawing on a "clear" background >> even make any sense in this case? >> >> Sam > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Stumped!
I think that the lack of information about tail calls can be particularly pernicious in the presence of multiple value errors. It would be good to do better, but I'm not sure how. The errortrace library contains what we currently do so you'd want to experiment there if you have an idea. Robby On Fri, Feb 22, 2013 at 1:13 PM, Pierpaolo Bernardi wrote: > On Fri, Feb 22, 2013 at 4:40 PM, Ryan Culpepper wrote: > > The line > > > > (date-day quando)99 > > > > looks pretty suspicious; with the 99 there, the first branch of the > > enclosing 'if' expression returns 8 values but the second branch returns > 7 > > values. > > Yes, that was the source of the error (a mistake due to me pressing > the Num Lock key inadvertently). > > What had me stumped is that DrRacket gives no hint about the location > of the error. Not even the right file! > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26344: master branch updated
No, I don't think it does. The drawing operation is called "over" and it takes two colors (rgb, say), and an alpha and produces a color (rgb). So you always start with some solid color in the background and draw the shape on top of it, resulting in another color that some other shape can be drawn on top of. On Fri, Feb 22, 2013 at 3:45 PM, Sam Tobin-Hochstadt wrote: > On Fri, Feb 22, 2013 at 4:40 PM, wrote: > > > > + The list of colors is obtained by drawing the image on a white > > + background and then reading off the colors of the pixels that were > drawn. > > Is there a particular reason to choose white, as opposed to clear, for > the background in this test? Does drawing on a "clear" background > even make any sense in this case? > > Sam > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26344: master branch updated
On Fri, Feb 22, 2013 at 4:40 PM, wrote: > > + The list of colors is obtained by drawing the image on a white > + background and then reading off the colors of the pixels that were drawn. Is there a particular reason to choose white, as opposed to clear, for the background in this test? Does drawing on a "clear" background even make any sense in this case? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Stumped!
On Fri, Feb 22, 2013 at 4:40 PM, Ryan Culpepper wrote: > The line > > (date-day quando)99 > > looks pretty suspicious; with the 99 there, the first branch of the > enclosing 'if' expression returns 8 values but the second branch returns 7 > values. Yes, that was the source of the error (a mistake due to me pressing the Num Lock key inadvertently). What had me stumped is that DrRacket gives no hint about the location of the error. Not even the right file! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Stumped!
The line (date-day quando)99 looks pretty suspicious; with the 99 there, the first branch of the enclosing 'if' expression returns 8 values but the second branch returns 7 values. Ryan On 02/22/2013 09:48 AM, Pierpaolo Bernardi wrote: This one got me stumped for a while. I don't remember a case like this ever occurring in the past, so I'm thinking that maybe this is a regression? In DrRacket, with debugging and stacktrace enabled in all the buffers involved, when I run the file strano.rkt, I get this error: Welcome to DrRacket, version 5.3.3.3--2013-02-16(1ddacff/a) [3m]. Language: racket [custom]; memory limit: 16000 MB. . . result arity mismatch; expected number of values not received expected: 7 received: 8 from: in: local-binding form values...: 2013 2 22 99 14 17 36.15819 0 And the region of source highlighted is the let*-values expression starting at line 28 in strano.rkt. However, the error is not there: it's in the function equation-of-time-alt at line 272 in astronomia.rkt, and DrRacket gave me no hint of where the error actually happened. If this is what DrRacket always did, I'm surprised I had not stumped over this before. If it's a novelty, then I don't like it. 8^) (I'm attaching the two files mentioned, for reference. They are not compilable alone, because there are other components missing, one of these being a foreign library. I can supply all of the missing sources, if requested. I can also supply the library as a win64 dll (and can compile it for win32 too)) Cheers P. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Stumped!
This one got me stumped for a while. I don't remember a case like this ever occurring in the past, so I'm thinking that maybe this is a regression? In DrRacket, with debugging and stacktrace enabled in all the buffers involved, when I run the file strano.rkt, I get this error: Welcome to DrRacket, version 5.3.3.3--2013-02-16(1ddacff/a) [3m]. Language: racket [custom]; memory limit: 16000 MB. . . result arity mismatch; expected number of values not received expected: 7 received: 8 from: in: local-binding form values...: 2013 2 22 99 14 17 36.15819 0 And the region of source highlighted is the let*-values expression starting at line 28 in strano.rkt. However, the error is not there: it's in the function equation-of-time-alt at line 272 in astronomia.rkt, and DrRacket gave me no hint of where the error actually happened. If this is what DrRacket always did, I'm surprised I had not stumped over this before. If it's a novelty, then I don't like it. 8^) (I'm attaching the two files mentioned, for reference. They are not compilable alone, because there are other components missing, one of these being a foreign library. I can supply all of the missing sources, if requested. I can also supply the library as a win64 dll (and can compile it for win32 too)) Cheers P. strano.rkt Description: Binary data astronomia.rkt Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
