Re: [racket-dev] try the GRacket2 branch
I should have paid more attention to your observation that it might be related to sawfish. Eli ran into the same problem, and the latest development version now avoids annoying sawfish. Let me know if you still see problems. At Sat, 30 Oct 2010 20:31:43 +0200, Jose A. Ortega Ruiz wrote: On Sat, Oct 30 2010, Matthew Flatt wrote: At Fri, 29 Oct 2010 01:04:02 +0200, Jose A. Ortega Ruiz wrote: In a build from a checkout of a few minutes ago, drracket dies on me when i try to resize its window, with the following message to the console: The program 'unknown' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 4084 error_code 8 request_code 59 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) I've tried to pass --sync to drracket, but it complains that the flag is not recognized. This is on a debian unstable box with gtk 2.20.1. This happens consistently for you, I guess? I tried a Debian Unstable install (with Gtk 2.20.1), and it worked ok for me, so I'm not sure what's different. Yes, it happens all the time. I just tried with plain gracket, and it displays an error that might be more informative (this, again, happens when i try to resize the main window): ./gracket make-bytes: out of memory making byte string of length 17169122912 === context === /home/jao/src/scheme/racket/collects/racket/draw/private/bitmap.rkt:66:2 /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3596:0: continue-make-super /home/jao/src/scheme/racket/collects/mred/private/wx/gtk/dc.rkt:27:2 /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3546:0: continue-make-object /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3468:2: make-object /home/jao/src/scheme/racket/collects/mred/private/wx/common/backing-dc.rkt:106:4 : get-cr method in backing-dc% /home/jao/src/scheme/racket/collects/racket/draw/private/dc.rkt:623:4: set-clipping-rect method in dc% /home/jao/src/scheme/racket/collects/mred/private/wxme/text.rkt:4933:2: refresh method in text% /home/jao/src/scheme/racket/collects/mred/private/wxme/editor-canvas.rkt:586:2: redraw method in editor-canvas% /home/jao/src/scheme/racket/collects/mred/private/wxme/text.rkt:2503:2: set-max-width method in text% /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:149:2: call-with-break-parameterization /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:265:2: call-with-exception-handler /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:149:2: call-with-break-parameterization /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:265:2: call-with-exception-handler /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:359:7 /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:396:26 make-bytes: out of memory making byte string of length 17169122912 === context === /home/jao/src/scheme/racket/collects/racket/draw/private/bitmap.rkt:66:2 /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3596:0: continue-make-super /home/jao/src/scheme/racket/collects/mred/private/wx/gtk/dc.rkt:27:2 /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3546:0: continue-make-object /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3468:2: make-object /home/jao/src/scheme/racket/collects/mred/private/wx/common/backing-dc.rkt:106:4 : get-cr method in backing-dc% /home/jao/src/scheme/racket/collects/mred/private/wx/common/canvas-mixin.rkt:137 :13 /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:359:7 /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:396:26 on-size in window%: expected argument of type exact integer in [0, 1]; given 65535 === context === /home/jao/src/scheme/racket/collects/mred/private/mrwindow.rkt:144:17: on-size method in ...private/mrwindow.rkt:127:4 /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:149:2: call-with-break-parameterization /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:265:2: call-with-exception-handler /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:359:7 /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:396:26 Instead of `--sync', you could provide the `-synchronous' option (i.e, the old X-style flag, which GRacket supports for compatibility with the old version and translates to `--sync' for Gtk).
Re: [racket-dev] try the GRacket2 branch
On Thu, Oct 28, 2010 at 2:25 AM, Matthew Flatt mfl...@cs.utah.edu wrote: The git repository now includes a gr2 branch for the new implementation of `racket/gui', which we've been informally calling GRacket2. What are the plans for merging between the master and gr2 branches? Right now, I can no longer use gr2 most of the time since it needs fixes to the macro-stepper, but those are only available on 'master'. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
At Fri, 5 Nov 2010 12:21:25 -0400, Sam Tobin-Hochstadt wrote: On Thu, Oct 28, 2010 at 2:25 AM, Matthew Flatt mfl...@cs.utah.edu wrote: The git repository now includes a gr2 branch for the new implementation of `racket/gui', which we've been informally calling GRacket2. What are the plans for merging between the master and gr2 branches? I will merge gr2 to the master branch as soon as I have time to do it. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
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] try the GRacket2 branch
I got GRacket2 running under Ubuntu. In general, things work as expected. It is my animations that I'm most concerned about and some work and some don't. I've only tried the ones that are available on PLaneT - I haven't even checked any of the others yet. 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 guess I need a better understanding of how the new canvas is working in order to deprecate the animated-canvas capability for my animations. Any thoughts, Matthew? Doug On Thu, Oct 28, 2010 at 12:25 AM, Matthew Flatt mfl...@cs.utah.edu wrote: The git repository now includes a gr2 branch for the new implementation of `racket/gui', which we've been informally calling GRacket2. ... _ 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] try the GRacket2 branch
At Sun, 31 Oct 2010 16:29:08 -0600, Doug Williams wrote: 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 guess I need a better understanding of how the new canvas is working in order to deprecate the animated-canvas capability for my animations. Any thoughts, Matthew? You shouldn't have to add a `yield', but I see that it's currently necessary to get canvas updates for Gtk and Win32. I'll work on that. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
At Fri, 29 Oct 2010 01:04:02 +0200, Jose A. Ortega Ruiz wrote: In a build from a checkout of a few minutes ago, drracket dies on me when i try to resize its window, with the following message to the console: The program 'unknown' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 4084 error_code 8 request_code 59 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) I've tried to pass --sync to drracket, but it complains that the flag is not recognized. This is on a debian unstable box with gtk 2.20.1. This happens consistently for you, I guess? I tried a Debian Unstable install (with Gtk 2.20.1), and it worked ok for me, so I'm not sure what's different. Instead of `--sync', you could provide the `-synchronous' option (i.e, the old X-style flag, which GRacket supports for compatibility with the old version and translates to `--sync' for Gtk). Combining that flag with gdb, you might be able to get some information. Thanks, Matthew _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
On Sat, Oct 30 2010, Matthew Flatt wrote: At Fri, 29 Oct 2010 01:04:02 +0200, Jose A. Ortega Ruiz wrote: In a build from a checkout of a few minutes ago, drracket dies on me when i try to resize its window, with the following message to the console: The program 'unknown' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 4084 error_code 8 request_code 59 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) I've tried to pass --sync to drracket, but it complains that the flag is not recognized. This is on a debian unstable box with gtk 2.20.1. This happens consistently for you, I guess? I tried a Debian Unstable install (with Gtk 2.20.1), and it worked ok for me, so I'm not sure what's different. Yes, it happens all the time. I just tried with plain gracket, and it displays an error that might be more informative (this, again, happens when i try to resize the main window): ./gracket make-bytes: out of memory making byte string of length 17169122912 === context === /home/jao/src/scheme/racket/collects/racket/draw/private/bitmap.rkt:66:2 /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3596:0: continue-make-super /home/jao/src/scheme/racket/collects/mred/private/wx/gtk/dc.rkt:27:2 /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3546:0: continue-make-object /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3468:2: make-object /home/jao/src/scheme/racket/collects/mred/private/wx/common/backing-dc.rkt:106:4: get-cr method in backing-dc% /home/jao/src/scheme/racket/collects/racket/draw/private/dc.rkt:623:4: set-clipping-rect method in dc% /home/jao/src/scheme/racket/collects/mred/private/wxme/text.rkt:4933:2: refresh method in text% /home/jao/src/scheme/racket/collects/mred/private/wxme/editor-canvas.rkt:586:2: redraw method in editor-canvas% /home/jao/src/scheme/racket/collects/mred/private/wxme/text.rkt:2503:2: set-max-width method in text% /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:149:2: call-with-break-parameterization /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:265:2: call-with-exception-handler /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:149:2: call-with-break-parameterization /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:265:2: call-with-exception-handler /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:359:7 /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:396:26 make-bytes: out of memory making byte string of length 17169122912 === context === /home/jao/src/scheme/racket/collects/racket/draw/private/bitmap.rkt:66:2 /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3596:0: continue-make-super /home/jao/src/scheme/racket/collects/mred/private/wx/gtk/dc.rkt:27:2 /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3546:0: continue-make-object /home/jao/src/scheme/racket/collects/racket/private/class-internal.rkt:3468:2: make-object /home/jao/src/scheme/racket/collects/mred/private/wx/common/backing-dc.rkt:106:4: get-cr method in backing-dc% /home/jao/src/scheme/racket/collects/mred/private/wx/common/canvas-mixin.rkt:137:13 /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:359:7 /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:396:26 on-size in window%: expected argument of type exact integer in [0, 1]; given 65535 === context === /home/jao/src/scheme/racket/collects/mred/private/mrwindow.rkt:144:17: on-size method in ...private/mrwindow.rkt:127:4 /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:149:2: call-with-break-parameterization /home/jao/src/scheme/racket/collects/racket/private/more-scheme.rkt:265:2: call-with-exception-handler /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:359:7 /home/jao/src/scheme/racket/collects/mred/private/wx/common/queue.rkt:396:26 Instead of `--sync', you could provide the `-synchronous' option (i.e, the old X-style flag, which GRacket supports for compatibility with the old version and translates to `--sync' for Gtk). Combining that flag with gdb, you might be able to get some information. I'll try that, thanks. I will try also with another window manager: this is using sawfish, and could be its fault. jao _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
I apologize in advance if I'm jumping the gun a bit here. I'm not sure if 64 bit Mac builds are an immediate goal of GR2. It does build under 10.6.4 and produce working executables. However, it appears there are still some issues there, as scrolling in the source pane doesn't work correctly. The scrollbars size correctly and respond to both mouse navigation and keyboard navigation within the displayed source. The source pane doesn't actually scroll though. Without any indication of whether 64 bit support on OS X was intended for this iteration, I didn't explore further. On Oct 28, 2010, at 2:25 AM, Matthew Flatt wrote: More immediately, it's time for you to try out the gr2 branch for everyday work. I've switched to GRacket2 for SirMail, Slideshow, and DrRacket --- even during lecture. All library functionality is in place, but I'm sure that gaps and problems will show up as we put the library to work (and I know that some of the tests still fail). I expect to see many bug reports; once the bug reports slow down, I'll take that as a sign that GRacket2 can move to master branch. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
At Sat, 30 Oct 2010 14:56:30 -0400, Gene Diveglia wrote: I apologize in advance if I'm jumping the gun a bit here. I'm not sure if 64 bit Mac builds are an immediate goal of GR2. It's a near-term goal, at least. After things are working well on the currently supported platforms, I plan to work on 64-bit Mac OS X and Windows versions. I don't expect that to take too long. Thanks for trying out gr2! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
Maybe I screwed something up but I can't tell if I'm running gr2 or not. I built the gr2 branch and ran drscheme but so far it looks exactly the same as gr1 (which I am positive is actually gr1). Is there an easy way to tell if I'm running gr2? Or should gr2 look identical to gr1? On 10/28/2010 12:25 AM, Matthew Flatt wrote: The git repository now includes a gr2 branch for the new implementation of `racket/gui', which we've been informally calling GRacket2. The new `racket/gui' is intended to be mostly compatible with the current library, but there are some significant incompatibilities. Those differences are described below in a copy of the Porting from v5.0.x to vX.Y notes that are linked from the Release Notes page of the documentation. GRacket2 is a misnomer in the sense that you can use the new `racket/gui' with just `racket'. Furthermore, the drawing layer is mostly unbundled from the GUI layer into a separate `racket/draw' library, so you can manipulate images without a GUI (e.g., without an X11 connection). The documentation doesn't yet reflect the GUI--Draw split, Slideshow's pict library doesn't yet use `racket/draw', etc., but I hope to get to that next. More immediately, it's time for you to try out the gr2 branch for everyday work. I've switched to GRacket2 for SirMail, Slideshow, and DrRacket --- even during lecture. All library functionality is in place, but I'm sure that gaps and problems will show up as we put the library to work (and I know that some of the tests still fail). I expect to see many bug reports; once the bug reports slow down, I'll take that as a sign that GRacket2 can move to master branch. GRacket, Racket, Drawing, and GUIs -- Version X.Y includes two major changes to the Racket drawing and GUI API: * The drawing portion of the GUI toolbox is now available as a separate layer: `racket/draw'. This layer can be used independent of the `racket/gui/base' library, although `racket/gui' re-exports `racket/draw'. (The `racket/draw' library is built on top of the widely used Cairo drawing library and Pango text-rendering library.) * The GRacket executable is no longer strictly necessary for running GUI programs; the `racket/gui/base' library can be used from Racket. The GRacket executable still offers some additional GUI-specific functiontality however. Most notably, GRacket is a GUI application under Windows (as opposed to a console application, which is launched slightly differently by the OS), GRacket is a bundle under Mac OS X (so the dock icon is the Racket logo, for example), and GRacket manages single-instance mode for Windows and X. The drawing and GUI libraries have also changed in further small ways. Bitmaps --- Drawing to a bitmap may not produce the same results as drawing to a canvas. Use the `make-screen-bitmap' function (from `racket/gui') or the `make-bitmap' method of `canvas%' to obtain a bitmap that uses the same drawing algorithms as a canvas. A color bitmap can have an alpha channel, instead of just a mask bitmap. When drawing a bitmap, alpha channels are used more consistently and automatically than mask bitmaps. More significantly, drawing into a bitmap with an alpha channel preserves the drawn alphas; for example, drawing a line in the middle of an empty bitmap produces an image with non-zero alpha only at the drawn line. Only bitmaps created with the new `make-gl-bitmap' function support OpenGL drawing. Use the new `make-bitmap', `read-bitmap', `make-monochrome-bitmap', `make-screen-bitmap', and `make-gl-bitmap' functions to create bitmaps, instead of using `make-object' with `bitmap%'. The new constructors are less overloaded and provide more modern defaults (such as alpha channels by default). Image formats can be read into a `bitmap%' from from input ports, instead of requiring a file path. A newly created bitmap has an empty content (i.e., white with zero alpha), instead of unspecified content. Canvases Drawing to a canvas always draws into a bitmap that is kept offscreen and periodically flushed onto the screen. The new `suspend-flush' and `resume-flush' methods of `canvas%' provide some control over the timing of the flushes, which in many cases avoids the need for (additional) double buffering of canvas content. OpenGL drawing in a canvas requires supplying 'gl as a style when creating the `canvas%' instance. OpenGL and normal dc% drawing no longer mix reliably in a canvas. Drawing-Context Transformations --- A `dc%' instance supports rotation (via `set-rotation'), negative scaling factors for flipping, and a general transformation matrix (via `set-initial-matrix'). A transformation matrix has the form `(vector xx xy yx yy x0 y0)', where a point (x1, y1) is transformed to a point (x2, y2)
Re: [racket-dev] try the GRacket2 branch
The version number on GRacket2 right now is 5.0.2.2. At Thu, 28 Oct 2010 11:26:43 -0600, Jon Rafkind wrote: Maybe I screwed something up but I can't tell if I'm running gr2 or not. I built the gr2 branch and ran drscheme but so far it looks exactly the same as gr1 (which I am positive is actually gr1). Is there an easy way to tell if I'm running gr2? Or should gr2 look identical to gr1? On 10/28/2010 12:25 AM, Matthew Flatt wrote: The git repository now includes a gr2 branch for the new implementation of `racket/gui', which we've been informally calling GRacket2. The new `racket/gui' is intended to be mostly compatible with the current library, but there are some significant incompatibilities. Those differences are described below in a copy of the Porting from v5.0.x to vX.Y notes that are linked from the Release Notes page of the documentation. GRacket2 is a misnomer in the sense that you can use the new `racket/gui' with just `racket'. Furthermore, the drawing layer is mostly unbundled from the GUI layer into a separate `racket/draw' library, so you can manipulate images without a GUI (e.g., without an X11 connection). The documentation doesn't yet reflect the GUI--Draw split, Slideshow's pict library doesn't yet use `racket/draw', etc., but I hope to get to that next. More immediately, it's time for you to try out the gr2 branch for everyday work. I've switched to GRacket2 for SirMail, Slideshow, and DrRacket --- even during lecture. All library functionality is in place, but I'm sure that gaps and problems will show up as we put the library to work (and I know that some of the tests still fail). I expect to see many bug reports; once the bug reports slow down, I'll take that as a sign that GRacket2 can move to master branch. GRacket, Racket, Drawing, and GUIs -- Version X.Y includes two major changes to the Racket drawing and GUI API: * The drawing portion of the GUI toolbox is now available as a separate layer: `racket/draw'. This layer can be used independent of the `racket/gui/base' library, although `racket/gui' re-exports `racket/draw'. (The `racket/draw' library is built on top of the widely used Cairo drawing library and Pango text-rendering library.) * The GRacket executable is no longer strictly necessary for running GUI programs; the `racket/gui/base' library can be used from Racket. The GRacket executable still offers some additional GUI-specific functiontality however. Most notably, GRacket is a GUI application under Windows (as opposed to a console application, which is launched slightly differently by the OS), GRacket is a bundle under Mac OS X (so the dock icon is the Racket logo, for example), and GRacket manages single-instance mode for Windows and X. The drawing and GUI libraries have also changed in further small ways. Bitmaps --- Drawing to a bitmap may not produce the same results as drawing to a canvas. Use the `make-screen-bitmap' function (from `racket/gui') or the `make-bitmap' method of `canvas%' to obtain a bitmap that uses the same drawing algorithms as a canvas. A color bitmap can have an alpha channel, instead of just a mask bitmap. When drawing a bitmap, alpha channels are used more consistently and automatically than mask bitmaps. More significantly, drawing into a bitmap with an alpha channel preserves the drawn alphas; for example, drawing a line in the middle of an empty bitmap produces an image with non-zero alpha only at the drawn line. Only bitmaps created with the new `make-gl-bitmap' function support OpenGL drawing. Use the new `make-bitmap', `read-bitmap', `make-monochrome-bitmap', `make-screen-bitmap', and `make-gl-bitmap' functions to create bitmaps, instead of using `make-object' with `bitmap%'. The new constructors are less overloaded and provide more modern defaults (such as alpha channels by default). Image formats can be read into a `bitmap%' from from input ports, instead of requiring a file path. A newly created bitmap has an empty content (i.e., white with zero alpha), instead of unspecified content. Canvases Drawing to a canvas always draws into a bitmap that is kept offscreen and periodically flushed onto the screen. The new `suspend-flush' and `resume-flush' methods of `canvas%' provide some control over the timing of the flushes, which in many cases avoids the need for (additional) double buffering of canvas content. OpenGL drawing in a canvas requires supplying 'gl as a style when creating the `canvas%' instance. OpenGL and normal dc% drawing no longer mix reliably in a canvas. Drawing-Context Transformations --- A `dc%' instance supports rotation (via `set-rotation'), negative
Re: [racket-dev] try the GRacket2 branch
Under ubuntu the menus are ubuntu colors instead of grey. Under mac os x, the splash screen's progress bar is slightly taller. Robby On Thu, Oct 28, 2010 at 12:42 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The version number on GRacket2 right now is 5.0.2.2. At Thu, 28 Oct 2010 11:26:43 -0600, Jon Rafkind wrote: Maybe I screwed something up but I can't tell if I'm running gr2 or not. I built the gr2 branch and ran drscheme but so far it looks exactly the same as gr1 (which I am positive is actually gr1). Is there an easy way to tell if I'm running gr2? Or should gr2 look identical to gr1? On 10/28/2010 12:25 AM, Matthew Flatt wrote: The git repository now includes a gr2 branch for the new implementation of `racket/gui', which we've been informally calling GRacket2. The new `racket/gui' is intended to be mostly compatible with the current library, but there are some significant incompatibilities. Those differences are described below in a copy of the Porting from v5.0.x to vX.Y notes that are linked from the Release Notes page of the documentation. GRacket2 is a misnomer in the sense that you can use the new `racket/gui' with just `racket'. Furthermore, the drawing layer is mostly unbundled from the GUI layer into a separate `racket/draw' library, so you can manipulate images without a GUI (e.g., without an X11 connection). The documentation doesn't yet reflect the GUI--Draw split, Slideshow's pict library doesn't yet use `racket/draw', etc., but I hope to get to that next. More immediately, it's time for you to try out the gr2 branch for everyday work. I've switched to GRacket2 for SirMail, Slideshow, and DrRacket --- even during lecture. All library functionality is in place, but I'm sure that gaps and problems will show up as we put the library to work (and I know that some of the tests still fail). I expect to see many bug reports; once the bug reports slow down, I'll take that as a sign that GRacket2 can move to master branch. GRacket, Racket, Drawing, and GUIs -- Version X.Y includes two major changes to the Racket drawing and GUI API: * The drawing portion of the GUI toolbox is now available as a separate layer: `racket/draw'. This layer can be used independent of the `racket/gui/base' library, although `racket/gui' re-exports `racket/draw'. (The `racket/draw' library is built on top of the widely used Cairo drawing library and Pango text-rendering library.) * The GRacket executable is no longer strictly necessary for running GUI programs; the `racket/gui/base' library can be used from Racket. The GRacket executable still offers some additional GUI-specific functiontality however. Most notably, GRacket is a GUI application under Windows (as opposed to a console application, which is launched slightly differently by the OS), GRacket is a bundle under Mac OS X (so the dock icon is the Racket logo, for example), and GRacket manages single-instance mode for Windows and X. The drawing and GUI libraries have also changed in further small ways. Bitmaps --- Drawing to a bitmap may not produce the same results as drawing to a canvas. Use the `make-screen-bitmap' function (from `racket/gui') or the `make-bitmap' method of `canvas%' to obtain a bitmap that uses the same drawing algorithms as a canvas. A color bitmap can have an alpha channel, instead of just a mask bitmap. When drawing a bitmap, alpha channels are used more consistently and automatically than mask bitmaps. More significantly, drawing into a bitmap with an alpha channel preserves the drawn alphas; for example, drawing a line in the middle of an empty bitmap produces an image with non-zero alpha only at the drawn line. Only bitmaps created with the new `make-gl-bitmap' function support OpenGL drawing. Use the new `make-bitmap', `read-bitmap', `make-monochrome-bitmap', `make-screen-bitmap', and `make-gl-bitmap' functions to create bitmaps, instead of using `make-object' with `bitmap%'. The new constructors are less overloaded and provide more modern defaults (such as alpha channels by default). Image formats can be read into a `bitmap%' from from input ports, instead of requiring a file path. A newly created bitmap has an empty content (i.e., white with zero alpha), instead of unspecified content. Canvases Drawing to a canvas always draws into a bitmap that is kept offscreen and periodically flushed onto the screen. The new `suspend-flush' and `resume-flush' methods of `canvas%' provide some control over the timing of the flushes, which in many cases avoids the need for (additional) double buffering of canvas content. OpenGL drawing in a canvas requires supplying 'gl as a style when creating the `canvas%' instance.
Re: [racket-dev] try the GRacket2 branch
I got it to work, I think my initial trouble was I ran $ git checkout -b gr2 instead of $ git checkout gr2 On 10/28/2010 12:11 PM, Robby Findler wrote: Under ubuntu the menus are ubuntu colors instead of grey. Under mac os x, the splash screen's progress bar is slightly taller. Robby On Thu, Oct 28, 2010 at 12:42 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The version number on GRacket2 right now is 5.0.2.2. At Thu, 28 Oct 2010 11:26:43 -0600, Jon Rafkind wrote: Maybe I screwed something up but I can't tell if I'm running gr2 or not. I built the gr2 branch and ran drscheme but so far it looks exactly the same as gr1 (which I am positive is actually gr1). Is there an easy way to tell if I'm running gr2? Or should gr2 look identical to gr1? On 10/28/2010 12:25 AM, Matthew Flatt wrote: The git repository now includes a gr2 branch for the new implementation of `racket/gui', which we've been informally calling GRacket2. The new `racket/gui' is intended to be mostly compatible with the current library, but there are some significant incompatibilities. Those differences are described below in a copy of the Porting from v5.0.x to vX.Y notes that are linked from the Release Notes page of the documentation. GRacket2 is a misnomer in the sense that you can use the new `racket/gui' with just `racket'. Furthermore, the drawing layer is mostly unbundled from the GUI layer into a separate `racket/draw' library, so you can manipulate images without a GUI (e.g., without an X11 connection). The documentation doesn't yet reflect the GUI--Draw split, Slideshow's pict library doesn't yet use `racket/draw', etc., but I hope to get to that next. More immediately, it's time for you to try out the gr2 branch for everyday work. I've switched to GRacket2 for SirMail, Slideshow, and DrRacket --- even during lecture. All library functionality is in place, but I'm sure that gaps and problems will show up as we put the library to work (and I know that some of the tests still fail). I expect to see many bug reports; once the bug reports slow down, I'll take that as a sign that GRacket2 can move to master branch. GRacket, Racket, Drawing, and GUIs -- Version X.Y includes two major changes to the Racket drawing and GUI API: * The drawing portion of the GUI toolbox is now available as a separate layer: `racket/draw'. This layer can be used independent of the `racket/gui/base' library, although `racket/gui' re-exports `racket/draw'. (The `racket/draw' library is built on top of the widely used Cairo drawing library and Pango text-rendering library.) * The GRacket executable is no longer strictly necessary for running GUI programs; the `racket/gui/base' library can be used from Racket. The GRacket executable still offers some additional GUI-specific functiontality however. Most notably, GRacket is a GUI application under Windows (as opposed to a console application, which is launched slightly differently by the OS), GRacket is a bundle under Mac OS X (so the dock icon is the Racket logo, for example), and GRacket manages single-instance mode for Windows and X. The drawing and GUI libraries have also changed in further small ways. Bitmaps --- Drawing to a bitmap may not produce the same results as drawing to a canvas. Use the `make-screen-bitmap' function (from `racket/gui') or the `make-bitmap' method of `canvas%' to obtain a bitmap that uses the same drawing algorithms as a canvas. A color bitmap can have an alpha channel, instead of just a mask bitmap. When drawing a bitmap, alpha channels are used more consistently and automatically than mask bitmaps. More significantly, drawing into a bitmap with an alpha channel preserves the drawn alphas; for example, drawing a line in the middle of an empty bitmap produces an image with non-zero alpha only at the drawn line. Only bitmaps created with the new `make-gl-bitmap' function support OpenGL drawing. Use the new `make-bitmap', `read-bitmap', `make-monochrome-bitmap', `make-screen-bitmap', and `make-gl-bitmap' functions to create bitmaps, instead of using `make-object' with `bitmap%'. The new constructors are less overloaded and provide more modern defaults (such as alpha channels by default). Image formats can be read into a `bitmap%' from from input ports, instead of requiring a file path. A newly created bitmap has an empty content (i.e., white with zero alpha), instead of unspecified content. Canvases Drawing to a canvas always draws into a bitmap that is kept offscreen and periodically flushed onto the screen. The new `suspend-flush' and `resume-flush' methods of `canvas%' provide some control over the timing of the flushes, which in many cases avoids the need for (additional) double buffering of canvas content. OpenGL drawing in a canvas requires
Re: [racket-dev] try the GRacket2 branch
On Thu, Oct 28, 2010 at 1:25 AM, Matthew Flatt mfl...@cs.utah.edu wrote: More immediately, it's time for you to try out the gr2 branch for everyday work. In case there's anyone else who wants to try but (somehow) knows even less about git than I do, here's what I did to checkout the branch. $ git clone g...@git.racket-lang.org:plt gr2 $ git branch gr2 origin/gr2 $ git checkout gr2 It seems to have worked, but there may be a more git-savvy way to do it. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
On 10/28/2010 01:05 PM, Casey Klein wrote: On Thu, Oct 28, 2010 at 1:25 AM, Matthew Flatt mfl...@cs.utah.edu wrote: More immediately, it's time for you to try out the gr2 branch for everyday work. In case there's anyone else who wants to try but (somehow) knows even less about git than I do, here's what I did to checkout the branch. $ git clone g...@git.racket-lang.org:plt gr2 $ git branch gr2 origin/gr2 $ git checkout gr2 It seems to have worked, but there may be a more git-savvy way to do it. You should be able to do just $ git clone ... $ git checkout gr2 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
On Oct 28, 2010, at 3:05 PM, Casey Klein wrote: On Thu, Oct 28, 2010 at 1:25 AM, Matthew Flatt mfl...@cs.utah.edu wrote: More immediately, it's time for you to try out the gr2 branch for everyday work. In case there's anyone else who wants to try but (somehow) knows even less about git than I do, here's what I did to checkout the branch. $ git clone g...@git.racket-lang.org:plt gr2 If you're only interested in that branch when cloning, you can clone with the -b option and the branch name: git clone g...@git.racket-lang.org:plt -b gr2 gr2 Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] try the GRacket2 branch
Hi, In a build from a checkout of a few minutes ago, drracket dies on me when i try to resize its window, with the following message to the console: The program 'unknown' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 4084 error_code 8 request_code 59 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) I've tried to pass --sync to drracket, but it complains that the flag is not recognized. This is on a debian unstable box with gtk 2.20.1. Cheers, jao _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
