Re: [racket-dev] adding preferences
nevermind, I see preferences:add-to-general-checkbox-panel in drracket/private/main.rkt On 11/01/2010 10:27 PM, Jon Rafkind wrote: > I currently have a preference to enabling/disabling line numbers in the > 'view' menu which is easy to set up in drracket/collects/main.rkt. A > user asked me to add a checkbox they could select in > edit->preferences->general which I see is controlled by > framework/private/preferences.rkt but I can't seem to get a reference to > the definitions text from there. I suppose I can make the preference set > the 'drracket:show-line-numbers property but it would be nice if it > could dynamically update the line numbers, much like 'view->show line > numbers' currently does. > > Is there a way to get to the definitions text in those callbacks? > _ > 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] adding preferences
I currently have a preference to enabling/disabling line numbers in the 'view' menu which is easy to set up in drracket/collects/main.rkt. A user asked me to add a checkbox they could select in edit->preferences->general which I see is controlled by framework/private/preferences.rkt but I can't seem to get a reference to the definitions text from there. I suppose I can make the preference set the 'drracket:show-line-numbers property but it would be nice if it could dynamically update the line numbers, much like 'view->show line numbers' currently does. Is there a way to get to the definitions text in those callbacks? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
At Mon, 1 Nov 2010 10:33:10 -0600, Doug Williams wrote: > I'll test it this evening when I am back home. > > The animated-canvas class actually keeps two bitmaps - one for painting from > and one for drawing to. The swap-bitmaps methods swaps those and repaints > the canvas. I'm not sure which of those the new canvas backing store would > replace. If I understand, then it replaces both. In GRacket2, call `suspend-flush' before clearing the canvas to redraw, and call `resume-flush' followed by `flush' at the point where you formerly swapped the bitmaps. The program below illustrates. When you run it, you should see color bars move slowly to the left. The drawing is intentionally slow, and if you set `sync?' to #f, it will flicker horribly. (Of course, you'll need the latest gr2 for the example to work right.) GRacket1 doesn't give you much control over the timing of canvas refresh. You could only say "please refresh", and sometime later `on-paint' would be called --- so an animation canvas needed to keep a bitmap for the current display state to respond to those `on-paint' calls. Meanwhile, you could draw into the other bitmap for the next scene. GRacket2 gives you more control, in a sense. If a canvas is in suspended-flush mode, then `resume-flush', `flush', `suspend-flush' effectively moves the current state of the canvas onto the screen, and then you can immediately start drawing again for the next scene. On some platforms, it's possible to expose the state of a flush-suspended canvas. When running the example below under Windows, if you drag another window over the one with the bars, then you can see intermediate states that would not otherwise be flushed. Similarly, if you try that with most window managers under X, the canvas just stays unrefreshed until it is flushed. In those cases, a buffer bitmap could provide better results; if drawing takes a *very* long time and you expect users to manipulate the surrounding GUI meanwhile, then a pair of bitmaps still may be the way to go. My guess is that your uses of an animation canvas will work well by just controlling flushes. #lang racket/gui (define SIZE 600) (define f (new frame% [label "Color Bars"] [width SIZE] [height SIZE])) (define c (new canvas% [parent f])) (send f show #t) (define sync? #t) (define (start-drawing dc) (when sync? (send dc suspend-flush))) (define (end-drawing dc) (when sync? (send dc resume-flush) (send dc flush))) (define (go) (let ([dc (send c get-dc)]) (for ([d (in-naturals)]) (start-drawing dc) (send dc erase) ;; Draw somthing slow that changes with d (for ([n (in-range 0 SIZE)]) (send dc set-pen (make-object color% (remainder (+ n d) 256) (remainder (* 2 (+ n d)) 256) (remainder (* 3 (+ n d)) 256)) 1 'solid) (send dc draw-line n 0 n SIZE)) (end-drawing dc (thread go) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket-bug] all/11365: syntax definitions in interactions -- namespace mismatch: errortrace-key
Two hours ago, Stevie Strickland wrote: > > Just tried it two ways: launching directly from the Dock and by > finding the .app package in the Finder and launching it there. Both > ways failed to pick up the git information. Feel free to drop by my > desk to try things. As almost expected now, this turned out to be a result of the fact that OSX ignores your environment scripts when you run stuff from the Finder. I solved this by adding two things: * If it's OSX, and no `git' was found in the path, then try "/opt/local/bin/git". This looks like the common place to get it installed on OSX (please correct me if it's wrong). * If no `git' executable was found, try to see if there's a toplevel ".git/HEAD" file, and if it leads to a SHA1 (usually it's a symbolic reference to a branch file with the SHA1). (This should cover almost all cases -- it could break since git makes it possible to have the git tree be in a different place, but there's no git command to run to do this accurately.) I also added a comment to the file that explains the string. (Note: git does have a $Id$ facility, but that inserts the SHA1 of the containing file -- that's a constant checksum that depends only on the file contents, and therefore it is useless in identifying the actual revision that was used.) -- ((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] [DrDr] R21402 (timeout 0) (unclean 3) (stderr 5) (changes 37)
On Mon, Nov 1, 2010 at 10:56 AM, wrote: > DrDr has finished building push #21402 after 32.39m. > > http://drdr.racket-lang.org/21402/ > > noel: > You are receiving this email because a file you are responsible for > has a condition that may need inspecting. > stderr: > http://drdr.racket-lang.org/21402/collects/tests/rackunit/standalone.rkt > > > jay: > You are receiving this email because a file you are responsible for > has a condition that may need inspecting. > stderr: > http://drdr.racket-lang.org/21402/collects/tests/rackunit/standalone.rkt > Any idea how this could be different on my machine vs DrDr? Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] A Workshop on Racket
PLT holds annual internal workshops where we synchronize our efforts. Based on discussions with members of the community, we are considering holding an open workshop for our entire user population. Depending on interest, the workshop is likely to feature presentations by: * Matthew Flatt on the future of Racket * Matthias Felleisen on the future of the HtDP Curriculum * Robby Findler on new developments in DrRacket as well as tutorials by: * Ryan Culpepper on creating Domain-Specific Languages * Jay McCarthy on Web Development with Racket * Shriram Krishnamurthi on teaching algorithmic content in an accelerated HtDP/2e course Also we are hoping that some of you might be interested in presenting ideas, requests, experiences, and plans that others may be interested in. Participants will have to pay for their travel, lodging and (most) meals, while we will try to pick up the tab for other workshop expenses. It would greatly help us if anyone interested in attending such a workshop could point your browser to http://www.surveymonkey.com/s/Y8CP8G8 and fill out our quick survey. Please do so even if we have informally polled you before on some of these questions. Filling out the survey doesn't commit you to anything. If you have any other comments, questions, or feedback, please send them to me directly. For the organizers, Sam Tobin-Hochstadt _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
I'll test it this evening when I am back home. The animated-canvas class actually keeps two bitmaps - one for painting from and one for drawing to. The swap-bitmaps methods swaps those and repaints the canvas. I'm not sure which of those the new canvas backing store would replace. Doug On Mon, Nov 1, 2010 at 9:07 AM, Matthew Flatt wrote: > At Sun, 31 Oct 2010 16:29:08 -0600, Doug Williams wrote: > > The animated-canvas library that I have on PLaneT has two examples. The > > histogram-test.rkt example works as expected. The lines.rkt example draws > a > > few lines and then locks up. Adding a (yield) after (send canvas > > swap-bitmaps) in line 55 gets it to run - sort of. The animation is > fairly > > smooth for 10 sets of lines, but is really strange at 50 (for example) - > > with this machine on the old GRacket it would be smooth at 100. And, my > stop > > button implementation doesn't work will - it just sets a global and the > > graphics routines exit when they see it set - it eventually stops, but > may > > require 10 to 15 seconds or so. I suspect that the animated-canvas > > functionality for double-buffering may not be needed anymore and the > 'flush' > > operations are what I need to look at. > > > > The interactions.ss file in the simulation package on PLaneT also > required a > > (yield) after line 107 to give the animation effect - there is no double > > buffering or anything here. But, with that added, it seems to run fine. > > I've pushed changes to make the canvas refresh without `yield'. Can you > check with the latest version? > > > You're right that double-buffering usually should not be needed > anymore, since all canvases now have a backing buffer. As an example, > text editors (like the ones in DrRacket) used to have their own backing > buffer, and they don't anymore. > > There are cases where you need precise control over the timing of > flushes. The new `suspend-flush' and `resume-flush' methods on `dc<%>' > give you extra control over the timing of flushes, and often that extra > control is enough. (Text editors use those methods to group a refresh > of the editor.) Since `suspend-flush' doesn't absolutely prevent > flushes, however, an extra backing buffer would be needed if it's > important to never show an intermediate drawing state. > > Finally, you might still want an explicit backing buffer to stage a > complex drawing so that it can be moved onscreen quickly. Slideshow, > for example, still draws a next slide offscreen (when it is otherwise > idle) so that it can display the slide instantly when you advance the > show. > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21390: master branch updated
This broke the mz-bin distribution, because it added the syntax colorer to Scribble's dependencies: http://drdr.racket-lang.org/21390/collects/meta/check-dists.rkt Jay On Sun, Oct 31, 2010 at 7:39 AM, wrote: > mflatt has updated `master' from 17f1230bba to aa7c4b53d9. > http://git.racket-lang.org/plt/17f1230bba..aa7c4b53d9 > > =[ 1 Commits ]== > > Directory summary: > 76.1% collects/scribble/private/ > 23.1% collects/scribblings/scribble/ > > ~~ > > aa7c4b5 Matthew Flatt 2010-10-31 07:07 > : > | add `codeblock' to Scribble > : > M collects/scribble/manual.rkt | 2 + > A collects/scribble/private/manual-code.rkt > M collects/scribblings/scribble/how-to-paper.scrbl | 32 +++- > M collects/scribblings/scribble/manual.scrbl | 54 +++ > > =[ Overall Diff ]=== > > collects/scribble/manual.rkt > > --- OLD/collects/scribble/manual.rkt > +++ NEW/collects/scribble/manual.rkt > @@ -2,6 +2,7 @@ > (require "base.ss" > "private/manual-style.ss" > "private/manual-scheme.ss" > + "private/manual-code.ss" > "private/manual-mod.ss" > "private/manual-tech.ss" > "private/manual-bib.ss" > @@ -18,6 +19,7 @@ > (all-from-out "base.ss" > "private/manual-style.ss" > "private/manual-scheme.ss" > + "private/manual-code.ss" > "private/manual-mod.ss" > "private/manual-tech.ss" > "private/manual-bib.ss" > > collects/scribble/private/manual-code.rkt > ~ > --- /dev/null > +++ NEW/collects/scribble/private/manual-code.rkt > @@ -0,0 +1,194 @@ > +#lang racket/base > +(require syntax/strip-context > + syntax-color/module-lexer > + "../racket.rkt" > + "../core.rkt" > + "../base.rkt" > + "manual-scheme.rkt" > + (for-syntax racket/base > + syntax/parse)) > + > +(provide codeblock > + typeset-code) > + > +(define-syntax (codeblock stx) > + (syntax-parse stx > + [(_ (~seq (~or (~optional (~seq #:expand expand-expr:expr) > + #:defaults ([expand-expr #'#f]) > + #:name "#:expand keyword") > + (~optional (~seq #:indent indent-expr:expr) > + #:defaults ([indent-expr #'2]) > + #:name "#:expand keyword") > + (~optional (~seq #:keep-lang-line? > keep-lang-line?-expr:expr) > + #:defaults ([keep-lang-line?-expr #'#t]) > + #:name "#:keep-lang-line? keyword") > + (~optional (~seq #:context context-expr:expr) > + #:name "#:context keyword")) > + ...) > + str ...) > + #`(typeset-code str ... > + #:expand expand-expr > + #:keep-lang-line? keep-lang-line?-expr > + #:indent indent-expr > + #:context #,(if (attribute context-expr) > + #'context-expr > + (or > + (let ([v #'(str ...)]) > + (and (pair? (syntax-e v)) > + #`#'#,(car (syntax-e v > + #'#f)))])) > + > +(define (typeset-code #:context [context #f] > + #:expand [expand #f] > + #:indent [indent 2] > + #:keep-lang-line? [keep-lang-line? #t] > + . strs) > + (let* ([str (apply string-append strs)] > + [bstr (string->bytes/utf-8 (regexp-replace* #rx"(?m:^$)" str > "\xA0"))] > + [in (open-input-bytes bstr)]) > + (let* ([tokens > + (let loop ([mode #f]) > + (let-values ([(lexeme type data start end backup-delta mode) > + (module-lexer in 0 mode)]) > + (if (eof-object? lexeme) > + null > + (cons (list type (sub1 start) (sub1 end) 0) > + (loop mode)] > + [substring* (lambda (bstr start [end (bytes-length bstr)]) > + (bytes->string/utf-8 (subbytes bstr start end)))] > + [e (parameterize ([read-accept-reader #t]) > + ((or expand > + (lambda (stx) > + (if context > + (replace-context context stx) > + stx))) > + (read-syntax 'prog (open-input-bytes bstr] > + [ids (let loop ([e e]) > + (c
Re: [racket-dev] try the GRacket2 branch
At Sun, 31 Oct 2010 16:29:08 -0600, Doug Williams wrote: > The animated-canvas library that I have on PLaneT has two examples. The > histogram-test.rkt example works as expected. The lines.rkt example draws a > few lines and then locks up. Adding a (yield) after (send canvas > swap-bitmaps) in line 55 gets it to run - sort of. The animation is fairly > smooth for 10 sets of lines, but is really strange at 50 (for example) - > with this machine on the old GRacket it would be smooth at 100. And, my stop > button implementation doesn't work will - it just sets a global and the > graphics routines exit when they see it set - it eventually stops, but may > require 10 to 15 seconds or so. I suspect that the animated-canvas > functionality for double-buffering may not be needed anymore and the 'flush' > operations are what I need to look at. > > The interactions.ss file in the simulation package on PLaneT also required a > (yield) after line 107 to give the animation effect - there is no double > buffering or anything here. But, with that added, it seems to run fine. I've pushed changes to make the canvas refresh without `yield'. Can you check with the latest version? You're right that double-buffering usually should not be needed anymore, since all canvases now have a backing buffer. As an example, text editors (like the ones in DrRacket) used to have their own backing buffer, and they don't anymore. There are cases where you need precise control over the timing of flushes. The new `suspend-flush' and `resume-flush' methods on `dc<%>' give you extra control over the timing of flushes, and often that extra control is enough. (Text editors use those methods to group a refresh of the editor.) Since `suspend-flush' doesn't absolutely prevent flushes, however, an extra backing buffer would be needed if it's important to never show an intermediate drawing state. Finally, you might still want an explicit backing buffer to stage a complex drawing so that it can be moved onscreen quickly. Slideshow, for example, still draws a next slide offscreen (when it is otherwise idle) so that it can display the slide instantly when you advance the show. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21393: master branch updated
Right, I wanted this experiment to be available to the next person who wonders whether `apply-reduction-relation*' should use a trie. A comment at the relevant place in the code points to the removed commit: http://git.racket-lang.org/plt/blobdiff/152084d5ce6ef49df3ec25c18e40069950146041..f9b64fa2b894ceb0795e4865b6b5f938e9738e81:/collects/redex/private/reduction-semantics.rkt On Sun, Oct 31, 2010 at 10:57 PM, Jay McCarthy wrote: > I believe Casey actually wants this code in the history. > > Jay > > Sent from my iPhone > > On Oct 31, 2010, at 9:16 PM, Eli Barzilay wrote: > >> Four minutes ago, Sam Tobin-Hochstadt wrote: >>> On Sun, Oct 31, 2010 at 6:32 PM, wrote: 152084d Casey Klein 2010-10-31 17:13 : | Adds an experiment in using a trie in `apply-reduction-relation*' ~~ f9b64fa Casey Klein 2010-10-31 17:28 : | Removes `apply-reduction-relation*' trie experiment >>> >>> You should learn about 'git rebase -i', with which you can drop >>> commits entirely. >> >> Actually, in this case a more convenient tool is `git commit --amend' >> which is a way to commit "more stuff" with the previous commit. >> >> -- >> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >> http://barzilay.org/ Maze is Life! >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
