Re: Inline.pm for mod_perl
On Fri, 22 Jun 2001, Matt Sergeant wrote: On Sat, 23 Jun 2001, Stas Bekman wrote: There have been a lot of interesting development around Inline:: namespace. Especially at the recent YAPC::NA (which I've skipped, but read the logs from those who were there). Especially interesting are the threads about new Inline::XS, see: http:[EMAIL PROTECTED]/ threads starting with: Inline::XS and Inline::XS explained I was wondering how all this projects onto mod_perl core and 3rd party modules. I'm not sure about the core, since Doug is an XS god, but endorsing the use of Inline for 3rd party modules where performance is crucial and the author doesn't have the XS-hard-to-acquire-skills sounds like a great idea. Except that until Inline is included in core, it won't be a widely used way to build performant code, IMHO. That's true. That's one of the reasons SWIG never made it into CPAN modules. That, and XS really isn't that hard. Like anything, it takes a bit of learning (as did mod_perl when I started using it!), and there could do to be a good book on it. Simon Cozens is working on 'Perl 5 Internals' book. I'm looking forward to put my hands on it. (search the google for 'perl 5 internals'). I personally don't buy the benefits of Inline.pm yet. The whole tweak, run thing that Brian advocates isn't sold on me, because that's exactly what I do, only it's tweak, make test... :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inline.pm for mod_perl
On Sat, 23 Jun 2001, Stas Bekman wrote: That, and XS really isn't that hard. Like anything, it takes a bit of learning (as did mod_perl when I started using it!), and there could do to be a good book on it. Simon Cozens is working on 'Perl 5 Internals' book. I'm looking forward to put my hands on it. (search the google for 'perl 5 internals'). Nat was also working on an XS book, IIRC. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inline.pm for mod_perl
On Fri, 22 Jun 2001, Matt Sergeant wrote: On Sat, 23 Jun 2001, Stas Bekman wrote: That, and XS really isn't that hard. Like anything, it takes a bit of learning (as did mod_perl when I started using it!), and there could do to be a good book on it. Simon Cozens is working on 'Perl 5 Internals' book. I'm looking forward to put my hands on it. (search the google for 'perl 5 internals'). Nat was also working on an XS book, IIRC. Not any more :( _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0 make test problems
On Sat, 23 Jun 2001, Stas Bekman wrote: I'm not sure how to approach this one. Should I log this issue somewhere in todo/ ? sure. I did. It deletes the files on shutdown. Apache-Test/lib/Apache/TestServer.pm:199: $self-clean unless $aborted; hmm, something else was causing the log to be left in tact for me. i think the default should be not to clean the files, 'make test' already runs t/TEST -clean, which those running t/TEST by hand can do if they want the files cleaned. what loglevel is this? apache LogLevel or Apache::TestTrace level? Apache::TestTrace ok, sounds good. might be useful if it also sets LogLevel, which is hardwired to debug by default. --devel then? still collides with -d. but now you can tell --deb vs --dev. But first do you agree that it'd be nice to have an option to enable a bunch of debug/development options at once. If you have some other idea for the trigger please tell me, I don't seem to come up with a nice replacement to devel/debug which doesn't start with 'd' ;) if the default is to not clean files, then -log-level (or -trace) should be enough, right? or is there more things you wanted todo in this case? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0 make test problems
On Sat, 23 Jun 2001, Stas Bekman wrote: I've 2 proposals: 1. --run-tests to be a hash option accepting: --run-tests --repeat=N --run-tests --rotate=[Y/N] with the default of --repeat=1 and --rotate=Y also may be we can do --rotate and --norotate to get the reverse instead of Y/N. I'm not sure whether it'll work with hash values. (do you have a better name choice for --rotate? is this the best word to annotate the difference between interleaving vs. appending in the 'a, b, c' example above?) 2. --run-tests[=N] --[no]rotate-tests (or simply --[no]rotate) i don't want to loose the -r shortcut. can you make -run-tests=%s and just parse the string? should be able to include all the same options in that string. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inline.pm for mod_perl
the answer on using Inline (even if it were in the perl dist) for modperl core is the same as the last time you asked. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0 make test problems
On Sat, 23 Jun 2001, Doug MacEachern wrote: On Sat, 23 Jun 2001, Stas Bekman wrote: I've 2 proposals: 1. --run-tests to be a hash option accepting: --run-tests --repeat=N --run-tests --rotate=[Y/N] with the default of --repeat=1 and --rotate=Y also may be we can do --rotate and --norotate to get the reverse instead of Y/N. I'm not sure whether it'll work with hash values. (do you have a better name choice for --rotate? is this the best word to annotate the difference between interleaving vs. appending in the 'a, b, c' example above?) 2. --run-tests[=N] --[no]rotate-tests (or simply --[no]rotate) i don't want to loose the -r shortcut. can you make -run-tests=%s and just parse the string? should be able to include all the same options in that string. sure, what would be a suggested format? --run-tests[=N:[rotate|repeat|randomize]]? (including my new idea for randomizinging the order. Any better idea for the three words that turn tests a, b into: a, a, b, b (repeat?) a, b, a, b (rotate?) b, a, a, b (random?) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rfc: 2.0 documentation project thoughts
one question we should rethink is whether to have docs in their own modperl-2.0-docs cvs tree on all in a modperl-2.0/docs subdirectory. i'm pretty sure cvs allows access control so certain people can write to docs/ but not ../ the other reason for the split is if we want to release docs more often than the rest of the distribution. if docs/ is self contained similar to Apache-Test (with its own Makefile.PL, MANIFEST, etc.), one can cd docs/ and 'make dist' for a seperate docs package. when the modperl-2.0 package is built from the top-level it will automatically include the docs thanks to MakeMaker subdir recursion. but, it docs live in modperl-2.0/../modperl-2.0-docs, we need todo special Makefile.PL magic to pick up that directory, which i think will be somewhat messy. the other question is should docs for modules live inlined in the .pm's or be in docs/pod/lib/Apache/FooModule.pod ? i would think the latter so the pdf and other doc magic stas plans can be applied to the module docs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0 make test problems
On Sun, 24 Jun 2001, Stas Bekman wrote:
sure, what would be a suggested format?
--run-tests[=N:[rotate|repeat|randomize]]? (including my new idea for
randomizinging the order. Any better idea for the three words that turn
tests a, b into:
a, a, b, b (repeat?)
a, b, a, b (rotate?)
b, a, a, b (random?)
looks good to me.
something else to look into, a recent bug has been introduced, if t/TEST
-run=2 starts the server, when $SIG{INT} is caught it should stop the
server but does not at the moment.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: rfc: 2.0 documentation project thoughts
On Sat, 23 Jun 2001, Doug MacEachern wrote: one question we should rethink is whether to have docs in their own modperl-2.0-docs cvs tree on all in a modperl-2.0/docs subdirectory. i'm pretty sure cvs allows access control so certain people can write to docs/ but not ../ I think it's just a matter of setting the right group permission on the files. So ./docs has a different group permission. the other reason for the split is if we want to release docs more often than the rest of the distribution. if docs/ is self contained similar to Apache-Test (with its own Makefile.PL, MANIFEST, etc.), one can cd docs/ and 'make dist' for a seperate docs package. when the modperl-2.0 package is built from the top-level it will automatically include the docs thanks to MakeMaker subdir recursion. but, it docs live in modperl-2.0/../modperl-2.0-docs, we need todo special Makefile.PL magic to pick up that directory, which i think will be somewhat messy. won't symlink work? I know that symlink doesn't survive cvs, so you have to do it manually (e.g. from the same Makefile.PL). Otherwise +1 on sub-dir (assuming that we work out the permissions issue). the other question is should docs for modules live inlined in the .pm's or be in docs/pod/lib/Apache/FooModule.pod ? i would think the latter so the pdf and other doc magic stas plans can be applied to the module docs. it can be both, with the doc builder retrieving bits from .pm files and using pod files as well. but it won't be easy to maintain. That's why I was asking for a separation between user and developers guides. The User guide should be more like a book where the information flows in an easy way. The developer guide can be more of a manual where there is some text linking manpages to each other, whereas the documentation of each module can be self contained, with little awareness of other modules. Of course ideally it should be more like a book, but it would be harder to achieve. So the user guide has to be made of pods and well thought out. The developers guide can be a mix of .pm and .pod files if it makes sense to keep some of the pods inside .pm files and will require some preprocessing to extract the pods from .pm before building the final doc. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inline.pm for mod_perl
On Sat, 23 Jun 2001, Ken Williams wrote: [EMAIL PROTECTED] (Matt Sergeant) wrote: Except that until Inline is included in core, it won't be a widely used way to build performant code, IMHO. Jarkko offered to put Inline into the core, and Brian actually refused. The reason is that he's got a different plan - when a module with Inline is installed and the user doesn't already have Inline, a small stub will be installed that does the loading. That way, any user back to 5.005 (maybe even 5.004?) can use Inlined modules automatically, but if it goes in the core it's just 5.8 and up. Yeah I saw that he refused on P5P, but I wasn't aware of the planned way it would work. So would the Inline stub code have to go in every module that was distributed that used Inline? Seems an odd plan. That, and XS really isn't that hard. But it's way harder than it needs to be. There are too many housekeeping details that Perl should really have been able to figure out for itself. But then that's weighted against the fact that the number of times you need to use XS isn't that many. It's not like mod_perl, where it's a universally applicable technology (in the sphere of web development), it's more like switch.pm, which is a useful thing to have to a few people who want those features. Note: I don't think Inline.pm is a bad idea. I just think it's merely interesting right now. I personally don't buy the benefits of Inline.pm yet. The whole tweak, run thing that Brian advocates isn't sold on me, because that's exactly what I do, only it's tweak, make test... I don't think the tweak/run part is the biggest benefit. It's the lack of all the XS cruft around C code, and the ability to embed C without having to create a whole new module. I've been using it myself to do some reverse-engineering of existing C code into Perl, just to make sure that I've everything right. The test scripts have been amazingly easy to manage using Inline. Yeah, I'm looking at it from a very different perspective (as a CPAN module author). Also, don't forget that Inline supports other languages too, like Java, Assembler, ... (Assembler!). True. I've used Inline::Java, and that's fantastic. Can't argue with that. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rfc: 2.0 documentation project thoughts
On Sat, 23 Jun 2001, Doug MacEachern wrote: i'm pretty sure cvs allows access control so certain people can write to docs/ but not ../ it doesn't actually; you have to rely on unix permissions. would you really trust somebody to write docs that you wouldn't trust to write code? i wouldn't. so i don't think it should be a concern. the other reason for the split is if we want to release docs more often than the rest of the distribution. if why exactly would one release docs separately? i don't see it happening in reality. keep them in the core module. the other question is should docs for modules live inlined in the .pm's or be in docs/pod/lib/Apache/FooModule.pod ? i would think the latter so the pdf and other doc magic stas plans can be applied to the module docs. i highly prefer having module doc inline. and i mean inline, interspersed amongst subs, so i can see the doc for a sub when i'm looking at its code. i get annoyed when i have to scroll to the bottom or open a second window to look at the doc for a sub :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rfc: 2.0 documentation project thoughts
On Sat, 23 Jun 2001, brian moseley wrote: On Sat, 23 Jun 2001, Doug MacEachern wrote: i'm pretty sure cvs allows access control so certain people can write to docs/ but not ../ it doesn't actually; you have to rely on unix permissions. would you really trust somebody to write docs that you wouldn't trust to write code? i wouldn't. so i don't think it should be a concern. Of course you should trust somebody to write docs. If you don't you will end up with little or no documentation at all. That's why we have cvs commit emails, so you can review the commits, which is less time consuming than actual writing. This is also a non-issue completely for the user guide, where someone who is core developer won't do a good job, because too many things are obvious to him, and which are completely not obvious to newbies and people with less knowledge. That's very important to let other people do this important part of the documentation. Of course these people shouldn't have an access to the code commit at large. Look at the httpd-docs project, which is quite successful and it's virtually separated from httpd. People who aren't necessarily committing to httpd rep, do have cvs commit perms to the httpd-docs rep. the other reason for the split is if we want to release docs more often than the rest of the distribution. if why exactly would one release docs separately? i don't see it happening in reality. keep them in the core module. given that code releases are very infrequent, as we have seen with 1.x series, releasing the updated documentation more frequently is important especially for doc fixes. You cannot release new code without updating docs, but you can release new docs without updating the code :) the other question is should docs for modules live inlined in the .pm's or be in docs/pod/lib/Apache/FooModule.pod ? i would think the latter so the pdf and other doc magic stas plans can be applied to the module docs. i highly prefer having module doc inline. and i mean inline, interspersed amongst subs, so i can see the doc for a sub when i'm looking at its code. i get annoyed when i have to scroll to the bottom or open a second window to look at the doc for a sub :) +1 As I said in my previous email, that shouldn't be of a problem for the docs project. We can mix and match inline pods and external pod files. All we need is to try to be consistent. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
