Re: [racket-dev] relative lines of C in gracket vs. gracket2
At Thu, 28 Oct 2010 10:48:43 -0700, John Clements wrote: I took a look at the size of our C code base (all files ending in .c, .h, .cpp, and .cxx, not including those with 'xsrc' in the path) to see how much smaller gracket2 is, and (assuming I didn't miss something major) the difference is truly impressive. The below is ... | wc | sort -n | tail, so it's just the 9 biggest and the total from each. So, if I'm reading this correctly, we've gone from ~590K lines of C to about ~340K lines of C. That's amazing. In one way, you undercounted: .cc was used for about 55k lines of C++ code. At the same time, it's overcounting to include the libpng, libjpeg, etc. sources that we have in our repo for convenience. GRacket2 still depends on those libraries, but it either uses the versions that you have installed or uses binaries that are downloaded during a build. I would break it down like this: C C++ that we C C++ included Total maintain [*] for convenience [**] GRacket1 455k190k 645k GRacket2 252k 85k 337k * Racket run-time: 227k (including 15k for GCs) GUI (gr1 only): 197k MysX, MzCom, SrP: 25k ** Image parsers (gr1 only): 105k Boehm GC and libffi: 85k Overall, GRacket2 replaces about 200k lines of C and C++ (on top of Xt, Win32, and Carbon) with about 30k lines of Racket code (on top of Gtk, Win32, and Cocoa) plus Cairo and Pango. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sharing cpointers between namespaces
At Thu, 28 Oct 2010 14:46:30 -0700, John Clements wrote: Specifically, I moved the define-struct of cpointer into a module by itself, called ffi/unsafe/cvector-def; that way, my tool.rkt file can require this one-line module and attach it to the user's namespace using 'reset-console'. BUT: the cvector.rkt file wants to use protect-out to prevent others from using make-cvector explicitly, and I'm not sure how to do this after moving the structure definition into another file. Did you use `protect-out' to export from the new file? That should be all you need to do, unless I misunderstand. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] relative lines of C in gracket vs. gracket2
Go, Matthew! :) Slay the evil beast. Robby On Fri, Oct 29, 2010 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 28 Oct 2010 10:48:43 -0700, John Clements wrote: I took a look at the size of our C code base (all files ending in .c, .h, .cpp, and .cxx, not including those with 'xsrc' in the path) to see how much smaller gracket2 is, and (assuming I didn't miss something major) the difference is truly impressive. The below is ... | wc | sort -n | tail, so it's just the 9 biggest and the total from each. So, if I'm reading this correctly, we've gone from ~590K lines of C to about ~340K lines of C. That's amazing. In one way, you undercounted: .cc was used for about 55k lines of C++ code. At the same time, it's overcounting to include the libpng, libjpeg, etc. sources that we have in our repo for convenience. GRacket2 still depends on those libraries, but it either uses the versions that you have installed or uses binaries that are downloaded during a build. I would break it down like this: C C++ that we C C++ included Total maintain [*] for convenience [**] GRacket1 455k 190k 645k GRacket2 252k 85k 337k * Racket run-time: 227k (including 15k for GCs) GUI (gr1 only): 197k MysX, MzCom, SrP: 25k ** Image parsers (gr1 only): 105k Boehm GC and libffi: 85k Overall, GRacket2 replaces about 200k lines of C and C++ (on top of Xt, Win32, and Carbon) with about 30k lines of Racket code (on top of Gtk, Win32, and Cocoa) plus Cairo and Pango. _ 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] non-reproducible gr2 bug heads-up
I had a not-easily-reproducible problem today where the tab-change keybinding (shift-cmd-right) was not working as expected. In particular, hitting with two tabs open and the first one shown would switch briefly to the second, then pop back to the first. As I've said, I don't know how to reproduce this, so this isn't a bug report, just a heads-up. BTW, I like the new tabbing look in Mac Gr2; it looks more compact. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Scribble Racket Code with Here Strings
I sometimes use here strings for readability when building queries, etc.
For example:
(let-values (((variables results)
(get-repository-query-tuple r
#---
select * from {x} sys:repositoryID {y}
using namespace
sys = http://www.openrdf.org/config/repository#
---
#:query-language 'SERQL)))
(printf Repository ids = ~s~n
(for/list ((bindings (in-list results)))
(binding-string (bindings-ref bindings 'y)
But I haven't found a good way to document this (as Racket code) in
Scribble. Everything I've tried renders like:
(let-values (((variables results)(
get-repository-query-tuple r select * from {x}
sys:repositoryID {y}\r\nusing namespace\r\n sys =
http://www.openrdf.org/config/repository#\r
#:query-language 'SERQL)))(printf Repository ids = ~s~n(
for/list ((bindings (in-list results))) (binding-string (
bindings-ref bindings 'y)
That is, the here string has been rendered as a normal string with lots of
whitespace after.
Any ideas?
Doug
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
[racket-dev] Yikes! Images in science collection could be much smaller
Your science collection stores images as bitmaps. Storing them as png's instead reduces their size by about 99%. This is lossless, so there's no reduction in quality. If I'm doing the math correctly, this could reduce the size of the installed science collection from about 78 megabytes to about 7 megabytes (it looks like there are three copies of everything). John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Yikes! Images in science collection could be much smaller
I'm in the process of updating all of my collections to Racket. I have most of the smaller ones done - animated-canvas, describe (with documentation this time), packed-binary, and uuid - with only table-panel left to go. Right now I'm finishing up the documentation for my new sesame library - an interface to the Sesame RDF triples store - that I'll release this weekend. [I need it for my 'real' job.] Then I'll move on to the 'big three' - science, simulation, and inference. They'll take me a while because of their size and complexity.But, I'll redo the graphics to PNG format at that time. On Fri, Oct 29, 2010 at 6:45 PM, John Clements cleme...@brinckerhoff.orgwrote: Your science collection stores images as bitmaps. Storing them as png's instead reduces their size by about 99%. This is lossless, so there's no reduction in quality. If I'm doing the math correctly, this could reduce the size of the installed science collection from about 78 megabytes to about 7 megabytes (it looks like there are three copies of everything). John _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Demodularizer
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 -- 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] Demodularizer
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
Re: [racket-dev] Demodularizer
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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
