Hi David- It sounds nice but I don't know when I'll get a chance to check it out. I'm in crunch mode trying to finish my 64bit-index-support. My recent benchmarks showed me that, in addition to the 300MB-ish memory limits from cygwin the performance is 1/2 that of native win32 perl so I *really* need to get win32 perl PDL up to where I can stop using cygwin PDL....
--Chris On 4/20/2012 4:22 PM, David Mertens wrote:
Bump! :-) On Mon, Apr 16, 2012 at 12:55 PM, David Mertens<[email protected]>wrote:Hey folks - On the plane ride I decided to tackle the stupid use of PDL::PP's /* comments */, which break user-end multiline comments. Here's the commit message, which explains my reasoning: PP generates lots of code. Some of that code is confusing at first blush, so PP added C-style multiline comments to help anybody examining the generated XS. Unfortunately, if a user had a bug in their code's logic and attempted to debug by commenting out large swaths of their PP code, the non-nesting of C-style comments would invariably lead to weird compile failures. My proposed solution is to #define the symbol PDL_COMMENT(comment), thus allowing any commentary such as this: _internal_var->value /* get some internal thing */ to be replaced with something like this: _internal_var->value PDL_COMMENT("get some internal thing") It's a bit more verbose, but it enables users to use multiline comments in the way described above. This *does not* modify any user-generated code apart from adding the new preprocessor symbol PDL_COMMENT. It is *only* used when PDL::PP *itself* wants to insert a comment without breaking user-end /* comments */. As such, you will never need to use it unless you actually mess with PDL::PP and related code generation modules. It does add the new preprocessor symbol PDL_COMMENT to all .xs files generated using PDL::PP, but I figure that's a safe bet, and an easy one-time fix (the user can change their own functions or preprocessor symbol that happens to be named PDL_COMMENT). This is a change to PDL::PP, and as such it could break things. I am fairly certain it does not and I request that anybody with concerns *please* try to check out the branch and run tests on PDL in the next couple of days. If I do not receive any negative reports, I intend to merge this branch into the main branch some time later this week. Instructions for trying out the branch are given below. Thanks! David To check out the work, do the following: # Make sure you're up-to-date with SF.net's repo: git pull # If you have any uncommitted work, stash it first: git stash # to be restored at the end # Create a new branch git branch david-pp-stuff # check out the branch git checkout david-pp-stuff # Pull the latest from my github repo git pull git://github.com/run4flat/pdl.git # Basic build and test: make prove -vb t/inline-comment-test.t # If that works, try recompiling everything to make sure it *really* works: perl Makefile.PL make make test # If you have any extensions that you want to specifically check, you need to install it. # When you're all done, switch back to main branch: git checkout master # remove the feature branch from your machine as it's no longer necessary: git branch -D david-pp-stuff # rebuild your PDL, if it broke and you installed it. # Finally, recover any of your previously uncommitted work: git stash pop -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan_______________________________________________ PDL-porters mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
