Re: [racket-dev] Demodularizer
I just pushed a few commits that should speed it up a bit. Jay On Fri, Oct 29, 2010 at 10:50 PM, Jon Rafkind rafk...@cs.utah.edu wrote: Ok nevermind about the bug, I had some leftover .zo files. When I erased my compiled directory and reran the demodularizer it worked. Another quick stat: $ time raco demod p.rkt real 3m55.563s 1.8ghz amd On 10/29/2010 10:40 PM, Jon Rafkind wrote: How do you run the resulting _merged file? I ran 'raco demod p.rkt' and got compiled/p_rkt_zo_merged.zo. Then I tried running racket on it but got an error $ ~/bin/plt/bin/racket p_rkt_zo_merged compiled/p_rkt_zo_merged.zo: read (compiled): ill-formed code (bad count: 436459 != 801349, started at 11951) Also just some quick stats: $ cat p.rkt #lang racket (define (hello) (printf Hello world!)) (hello) $ ls -l compiled/p_rkt.zo ;; just using raco make 352 $ ls -l compiled/p_rkt_zo_merged.zo 448410 Would you mind renaming the command to 'demodularize' ? On 10/29/2010 07:53 PM, Jay McCarthy wrote: Here is a message from Blake Johnson about something I just pushed for him: Jay recently committed my changes implementing raco demod, which will flatten a modular program into a single compiled module. How to use it: Run raco demod filename. This will produce a demodularized zo file called filename_merged.zo which can then be run by passing it to racket. This process can take quite a while, so if you want to see what is going on, you can set PLTSTDERR=debug or info. Once the zo file is created, it can be moved and run from anywhere because it has no dependencies. What it doesn't do (yet): - Dead code elimination This is partially implemented but doesn't handle every case properly, so it is turned off for now. - Optimize the program This is the next big thing I'm working on, which involves decompiling the zo slightly and converting it into c structs so that the existing optimizer can run on it. - Work with programs that dynamically manipulate modules This means things like DrRacket won't be able to be demodularized. We have some ideas on how to handle this, but it probably won't happen any time soon. Other improvements: zo-parse and zo-marshal should be able to handle any .zo you throw at them. Help needed: Any programs that don't work after demodularization would be helpful. Thanks, Blake Johnson At the moment, we have not measured any performance improvements, etc after using the demodularizer. At the moment, we do not anticipate that there will be any because we are not doing DCE or the re-optimization. We'll let everyone know when we measure that. For the moment, this may be of particular interest to any out there that are doing program analysis and would like whole programs. Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ 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] Demodularizer
Just for some numbers, http://drdr.racket-lang.org/21386/collects/tests/compiler/demodularizer/ used to take 5.76 minutes and now it takes 2.90 Jay On Sat, Oct 30, 2010 at 9:17 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I just pushed a few commits that should speed it up a bit. Jay On Fri, Oct 29, 2010 at 10:50 PM, Jon Rafkind rafk...@cs.utah.edu wrote: Ok nevermind about the bug, I had some leftover .zo files. When I erased my compiled directory and reran the demodularizer it worked. Another quick stat: $ time raco demod p.rkt real 3m55.563s 1.8ghz amd On 10/29/2010 10:40 PM, Jon Rafkind wrote: How do you run the resulting _merged file? I ran 'raco demod p.rkt' and got compiled/p_rkt_zo_merged.zo. Then I tried running racket on it but got an error $ ~/bin/plt/bin/racket p_rkt_zo_merged compiled/p_rkt_zo_merged.zo: read (compiled): ill-formed code (bad count: 436459 != 801349, started at 11951) Also just some quick stats: $ cat p.rkt #lang racket (define (hello) (printf Hello world!)) (hello) $ ls -l compiled/p_rkt.zo ;; just using raco make 352 $ ls -l compiled/p_rkt_zo_merged.zo 448410 Would you mind renaming the command to 'demodularize' ? On 10/29/2010 07:53 PM, Jay McCarthy wrote: Here is a message from Blake Johnson about something I just pushed for him: Jay recently committed my changes implementing raco demod, which will flatten a modular program into a single compiled module. How to use it: Run raco demod filename. This will produce a demodularized zo file called filename_merged.zo which can then be run by passing it to racket. This process can take quite a while, so if you want to see what is going on, you can set PLTSTDERR=debug or info. Once the zo file is created, it can be moved and run from anywhere because it has no dependencies. What it doesn't do (yet): - Dead code elimination This is partially implemented but doesn't handle every case properly, so it is turned off for now. - Optimize the program This is the next big thing I'm working on, which involves decompiling the zo slightly and converting it into c structs so that the existing optimizer can run on it. - Work with programs that dynamically manipulate modules This means things like DrRacket won't be able to be demodularized. We have some ideas on how to handle this, but it probably won't happen any time soon. Other improvements: zo-parse and zo-marshal should be able to handle any .zo you throw at them. Help needed: Any programs that don't work after demodularization would be helpful. Thanks, Blake Johnson At the moment, we have not measured any performance improvements, etc after using the demodularizer. At the moment, we do not anticipate that there will be any because we are not doing DCE or the re-optimization. We'll let everyone know when we measure that. For the moment, this may be of particular interest to any out there that are doing program analysis and would like whole programs. Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ 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
[racket-dev] GRacket2 builds
In case you want to try out the new gracket2 functionality, you can do that by using pre-made installers from http://pre.racket-lang.org/gr2/installers/ I will make new builds from time to time, as the branch is updated. -- ((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] Scribble Racket Code with Here Strings
On Sat, Oct 30, 2010 at 11:56 AM, Eli Barzilay e...@barzilay.org wrote: That is, the here string has been rendered as a normal string with lots of whitespace after. There's lots of ways to create strings and the documentation system can't tell them apart -- so it rendered it as a string, but then noticed that the other pieces of code are a few lines later. Isn't that a sign that we need a syntax property for here-strings, similar to 'paren-shape? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
