Hey everyone - I've pushed my work into the latest main branch. Please pull and test when you have a chance!
David On Fri, Apr 20, 2012 at 7:38 PM, chm <[email protected]> wrote: > 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<dcmertens.perl@gmail.** >> com <[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<http://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<http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters> >> > > -- "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
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
