cvs commit: modperl-2.0/src/modules/perl modperl_env.c
dougm 2002/06/01 16:42:08
Modified:src/modules/perl modperl_env.c
Log:
pass the PATH and TZ environment variables at startup by default as 1.xx did
Revision ChangesPath
1.25 +22 -0 modperl-2.0/src/modules/perl/modperl_env.c
Index: modperl_env.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_env.c,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- modperl_env.c 30 May 2002 23:35:02 - 1.24
+++ modperl_env.c 1 Jun 2002 23:42:07 - 1.25
-85,10 +85,32
modperl_env_tie(mg_flags);
}
+/* list of environment variables to pass by default */
+static const char *MP_env_pass_defaults[] = {
+PATH, TZ, NULL
+};
+
void modperl_env_configure_server(pTHX_ apr_pool_t *p, server_rec *s)
{
/* XXX: propagate scfg-SetEnv to environ */
MP_dSCFG(s);
+int i = 0;
+
+for (i=0; MP_env_pass_defaults[i]; i++) {
+const char *key = MP_env_pass_defaults[i];
+char *val;
+
+if (apr_table_get(scfg-SetEnv, key) ||
+apr_table_get(scfg-PassEnv, key))
+{
+continue; /* already configured */
+}
+
+if ((val = getenv(key))) {
+apr_table_set(scfg-PassEnv, key, val);
+}
+}
+
modperl_env_table_populate(aTHX_ scfg-SetEnv);
modperl_env_table_populate(aTHX_ scfg-PassEnv);
}
cvs commit: modperl-2.0 Changes
dougm 2002/06/01 20:20:35
Modified:.Changes
Log:
update Changes
Revision ChangesPath
1.15 +12 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Changes 29 May 2002 16:31:44 - 1.14
+++ Changes 2 Jun 2002 03:20:35 - 1.15
@@ -10,6 +10,18 @@
=item 1.99_02-dev
+pass the PATH and TZ environment variables at startup by default as 1.xx did
+
+fix ModPerl::Util::exit segv with 5.6.0
+
+no longer support 5.7.x perl development versions
+
+added compat for Apache::Table-new
+
+various fixes to compile/run on darwin
+
+server-scope Perl{Set,Pass}Env config now propagated to %ENV at startup
+
use SvOK(sv) instead of sv == PL_sv_undef to detect undef values in xs
[Stephen Clouse [EMAIL PROTECTED]]
cvs commit: modperl-2.0 Changes
dougm 2002/06/01 20:21:43 Modified:.Changes Log: releasing 1.99_02 Revision ChangesPath 1.16 +1 -1 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- Changes 2 Jun 2002 03:20:35 - 1.15 +++ Changes 2 Jun 2002 03:21:43 - 1.16 -8,7 +8,7 =over 3 -=item 1.99_02-dev +=item 1.99_02 - June 1, 2002 pass the PATH and TZ environment variables at startup by default as 1.xx did
cvs commit: modperl-2.0/lib mod_perl.pm
dougm 2002/06/01 20:25:53
Modified:.Changes
lib mod_perl.pm
Log:
bump version
Revision ChangesPath
1.17 +2 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- Changes 2 Jun 2002 03:21:43 - 1.16
+++ Changes 2 Jun 2002 03:25:53 - 1.17
-8,6 +8,8
=over 3
+=item 1.99_03-dev
+
=item 1.99_02 - June 1, 2002
pass the PATH and TZ environment variables at startup by default as 1.xx did
1.3 +1 -1 modperl-2.0/lib/mod_perl.pm
Index: mod_perl.pm
===
RCS file: /home/cvs/modperl-2.0/lib/mod_perl.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- mod_perl.pm 7 Apr 2002 05:08:31 - 1.2
+++ mod_perl.pm 2 Jun 2002 03:25:53 - 1.3
-4,7 +4,7
use strict;
BEGIN {
-our $VERSION = 1.9902;
+our $VERSION = 1.9903;
}
1;
PERL Internals access
If anyone there can give me some pointers to how to access the syntax tree for an executing Perl program, _from within that program_, I would be very grateful. I suspect this may not be possible. The O::Backend system seems to require the Perl program execute with overloaded Ops (example : Terse) and so the "normal" execution of the code is forfeited. I havefiddled with Devel::OpProf to get at what internal opcodes have executed, but really want to have my perl program somehow obtain the same large text dump created by a -MO=Terse printing, as part of my program's execution. I don't want to call Terse over the source .pl file either... sorry! #!/usr/bin/perl my $terse_dump_of_this = foo_magic_B::something; #code code code code Kind regards, Craig. ** This email is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. When addressed to our clients, any opinions or advice contained in this Email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 93357000 and destroy the original message. Thank You. **M
RE: separating C from V in MVC
From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 22:42 To: 'Ray Zimmerman'; modperl List; Mason List Jesse, thanks for your comments, I found them very interesting. I am comfortable with Perl and Web programming (though previously not the two together) and am about to embark on development of a new product for an ASP, so have considerable interest at this stage of the proceedings. I would like to ask some further questions, please forgive the extensive haircut of your comments: applying a design pattern such as MVC is not a panacea I agree - I much prefer Perlish DWIM dweomer Model: The business logic. Not related to the UI at all. View: The user interface. Controller: The glue between the View and the Model. ... the Model is simply a Perl module... make it entirely separate from the user interface... the methods... being called from a web application, a cron script, or an email-based interface Makes sense, in old-style speak [yes, I am approaching 'Ancient of Days' status] this seems to indicate the Model accepts method calls and returns data that will be rendered elsewhere. In our planned development, there is a LOT of tabular data - do you use any standards for the data being returned to the Controller? eg do you use a struct [ie hash/array Perl primitive] or do you return an object? eg a table object etc? The View, in a web application, is really the HTML output. Sounds good, so I could also pass the Models returned data to a different flavoured rendering view eg PDF, Spreadsheet, Text etc. This sounds a lot like our existing Perl reporting infra which does exactly that. W3 did a huge amount of analysis on layout and style as part of the CSS specs. In our setup, the table objects contain lots of style info. It is easy to render complex tables in PDF [as HTML will be] but formats like Excel are very hard, as there are layout constraints [eg a column can have only one width for the entire page - we call this the 'Highlander Effect'] Is this true of your setup? does the Model returned data contain lots of style hints? Or do you leave this completely to the View layer? How does the view layer know for example to render an Error cell as RED in HTML but blue in Excel due to Excel palette limitations? Optimally, the View avoids *ALL* application logic. - so the Model has to say RED rather than ERROR? but that wouldn't work if rendering something where RED is illegible? Our reporting knows about basic things like Error, Good, User Date / Numeric preferences etc. At my company we use HTML::Template ... it's damn fast, too will look at this - is there a list somewhere? The Controller connects the View to the Model... takes user input ... translates it into method calls on the Model... then takes output from the Model and passes it to your View. Sounds like Controller only interacts with one Model? I would assume that a Controller might collect data from a number of Models, and then pass the collection of data to a View? What controls the overall layout? e.g. what is the equivalent of the 'Grid Bag' layout manager - is this done in the Controller? and then passed to the View with all the data from a set of Models? Or do you make the Controller minimalist and have a meta-Model that assembles all the sub-Models into a layout. CGI::Application modules will do some reading on this also then. separating the View from Controller is a problem. I guess this is a balance between purist and DWIMism, but as we already have this separation for reporting, I would like to extend it into our dynamic web page generation. If you have to work with an SPS such as Mason but you still want to separate your View from your Controller, you have to work twice as hard. Interesting! Jesse, I found your posting extremely useful - thank you very much! Regards Jeff
Re: PERL Internals access
Burton, Craig wrote: If anyone there can give me some pointers to how to access the syntax tree for an executing Perl program, _from within that program_, I would be very grateful. I suspect this may not be possible. The O::Backend system seems to require the Perl program execute with overloaded Ops (example : Terse) and so the normal execution of the code is forfeited. I have fiddled with Devel::OpProf to get at what internal opcodes have executed, but really want to have my perl program somehow obtain the same large text dump created by a -MO=Terse printing, as part of my program's execution. I don't want to call Terse over the source .pl file either... sorry! Is something like B::Generate is what you are looking for? e.g. see: http://www.perl.com/pub/a/2002/05/07/optree.html Simon had an interesting paper in the last OSC's proceeding paper. I don't know if it's available online. It was called: B::Generate + Source Filters = use Python; In any case you probably want to move this discussion to some other perl specific list/forum, unless it has something to do with mod_perl. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: separating C from V in MVC
From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 01 June 2002 00:17 To: Rob Nagler Cc: [EMAIL PROTECTED] The same template? How does the layout manager help with that? Does it modify the template? It would make more sense to me if this were a sort of abstraction to factor out common layout ideas from multiple templates. The layout manager is more complex than a static template. It takes a collection of data and meta-data and creates a document tree that is not a specific rendering flavour - the DOM might subsequently be rendered in NS4.0 HTML, IE5.01+ HTML, Excel, PDF etc. without requiring (every page) x (every format) x (every option) templates. ... That doesn't require a layout manager though. Simple templating is fine for that, i.e. two different templates (views). In most circumstances it is ok to have templates that are specific to one output flavour, possible with some simple alts. But what if I have 40 pages that I want to render in: IE5+HTML, NS4-HTML, Excel, HP-PCL5 and PDF - and I also want SIMPLE views of each page. This would result in 40 x 5 x 2 = 400 templates. For every change in a basic page, I have to keep 9 other templates in other languages in step. If the number of output formats and page variants is not trivial, it might make more sense to have an active component that creates the document tree, and passes it to simple components that know how to render a DOM in the desired output format. All in all, I think the MVC+template approach described is fine for most of the type of dynamic sites currently available on the web. But I work for a small ASP and we have to manage rapidly changing complex dynamic sites and complex user reporting requirements, with minimal work. We don't have any HTML specialists, but rather a few very good technical generalists. I think that for us a meta-data layout driven approach will be more effective. We do however plan to borrow all the good ideas we can find from any other model, including MVC+template. Our planned move to mod_perl is mostly due to the benefits we have seen from out Perl data processing and reporting - hence the desire to join both the web and DP infra at the hip. Regards Jeff
RE: separating C from V in MVC
At 15:09 01.06.2002, Jeff wrote: From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 01 June 2002 00:17 To: Rob Nagler Cc: [EMAIL PROTECTED] The same template? How does the layout manager help with that? Does it modify the template? It would make more sense to me if this were a sort of abstraction to factor out common layout ideas from multiple templates. The layout manager is more complex than a static template. It takes a collection of data and meta-data and creates a document tree that is not a specific rendering flavour - the DOM might subsequently be rendered in NS4.0 HTML, IE5.01+ HTML, Excel, PDF etc. without requiring (every page) x (every format) x (every option) templates. Well, as I see this, it isn't a problem. The layout manager takes the place of the view, as it essentially decides how things should be rendered. You then have two stages in your view, but the same techniques apply (as the 2nd stage of the view isn't really specific to any model or controller). -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: separating C from V in MVC
I forgot to ask one thing about Jesse's comments. I don't think the standard HTML::Template has support for formatting numbers, dates, etc. How do you make sure that it's done consistently in your applications? It seems problematic to me to require the programmers to do work when a designer wants to change the number of decimals in a page, for example. -- Barry Hoggard Tristan Media LLC e: [EMAIL PROTECTED] p: 212-627-1596 aim: hoggardb
RE: separating C from V in MVC
From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]] Sent: 01 June 2002 18:10 To: Jeff Well, as I see this, it isn't a problem. The layout manager takes the place of the view, as it essentially decides how things should be rendered. You then have two stages in your view, but the same techniques apply (as the 2nd stage of the view isn't really specific to any model or controller). It is interesting to try and fit our approach into the MVC+template pattern, and I guess it comes down to where you draw the line. I think that the layout manager / creation of the document object model is not really part of a View, as a single DOM can be passed to a number of rendering components. I see it more as something the controller creates and passes to all of the Views that you want to implement. For example lets say that I want to present both a web page, and also render an Excel report in response to a single query [the page gets sent back to the requestor, the Excel gets saved into the db as a blob for later download]. I would see this happening like this: Controller: 1) creates collection of Models and model meta-data 2) creates DOM using layout hints in meta-data 3) passes DOM to HTML View and reaps the HTML rendering 4) passes DOM to Excel View and reaps the Excel rendering 5) saves the Excel rendering in the DB as a blob 6) returns the HTML view to the page requester As you can see from this outline, the controller manages the creation of the DOM outside either the HTML or Excel views. I see the Controller as also responsible for deciding what to do with the results of rendering the DOM in Excel or HTML formats - Views don't decide how their results should be distributed. In the above example, the Controller might decide to return the Excel object to the client, and save the HTML view into a cache or blob etc etc. This is my current thinking. Now that I have heard more details from the MVC folks on the list, I will have to sit down and spend some mental effort in assimilating MVC+template into what we currently do, and see what sort of beast emerges. Regards Jeff
RE: separating C from V in MVC
From: Barry Hoggard [mailto:[EMAIL PROTECTED]] Sent: 01 June 2002 19:16 I don't think the standard HTML::Template has support for formatting numbers, dates, etc. Perrin indicated that you can extend HTML::Template in some way to accommodate this, but I am not yet sure of the details. How do you make sure that it's done consistently in your applications? It seems problematic to me to require the programmers to do work when a designer wants to change the number of decimals in a page, for example. In our reporting infra we handle this by extending the number of basic data types to include things like cash value quantity interest rate market price and then set up a central store of meta-data that says xxx = cash value yyy = interest rate and then set up the extended data types cash value = '#,##0.00' quantity = '#,##0' we also allow field specific overrides zzz= '#,###' [blank when zero] All our components use the meta-data to determine how the result should look. In Excel, quantities are rendered with both a numeric value and a picture. Excel itself handles the commify. In PDF, the rendering component has to create a commified string representation with the correct number of dps. By centralising the meta-data and having rendering components that use your meta-data, you can globally change the accuracy or presentation rules in all view formats. At present, all our folks are Perl literate, so the metadata is very easily managed in a series of Perl modules, but there is nothing stopping you from storing it in a DB, text file etc and creating a non-technical user maintenance interface. Regards Jeff
RE: separating C from V in MVC
At 21:14 01.06.2002, Jeff wrote: From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]] Sent: 01 June 2002 18:10 To: Jeff Well, as I see this, it isn't a problem. The layout manager takes the place of the view, as it essentially decides how things should be rendered. You then have two stages in your view, but the same techniques apply (as the 2nd stage of the view isn't really specific to any model or controller). This is my current thinking. Now that I have heard more details from the MVC folks on the list, I will have to sit down and spend some mental effort in assimilating MVC+template into what we currently do, and see what sort of beast emerges. Well, as you see, MVC is more something of a way of thinking. I guess it's up to everyone to adapt it to their own needs. You decide what you think is best, but your layout manager idea clearly brings new light to this discussion. -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: separating C from V in MVC
From: Rob Nagler [mailto:[EMAIL PROTECTED]] Sent: 31 May 2002 23:48 Models can only express meta info about the data, not the context in which the data is rendered. Some info, like placement, is conditional on the grouping which is chosen by the view. A layout manager abstracts placement using meta data supplied by the model and context supplied by the view. This is an interesting comment. We have so far tried [successfully] to keep our document object models completely independent of the rendering component, which means the same DOM can be passed to an Excel/PDF/etc component for rendering. The challenge of course is that it is much easy to render complex things in HTML than for example Excel which imposes a global tablular view where a column can only have one width for a page. Excel does however support multiple pages, but HTML doesn't [frames?]. Whilst one can rely on scroll-bars for HTML, PDF rendering requires the component to decide on wrapping or truncating to fit page widths. We relied heavily on the layout analysis that the W3 did for CSS and HTML when desiging our DOM class, and so HTML rendering is easy. As Rob mentions in one of his emails, the HTML rendering component does not actually have to calculate final layout, as this is done by the browser. Final layouts do have to be managed by some of our other rendering components - the PDF rendering component has to understand all flow, wrap, alignment, trunctation etc layout info. Your comment seems to hint that maybe the DOM should take into account the target rendering flavour eg craft a complex DOM for HTML but a simple DOM for Excel. We chose to make our rendering components all accept complex DOMs and then make their own decisions on to best render them taking into account limitations of the target format. I don't know if this was the right decision, but it has met our requirements for fast reporting development times for over a year now, and I am hoping to take it into the HTML world. I somehow feel that the MVC and MVC+template patterns described so far in the discussions go a long way towards, but do not quite reach our desired level of reusable infra. Templating is an interesting variant, but actually solves a different problem. Perhaps we are wanting too much! I can certainly see that the MVC+ template approach is simpler, and this is the strongest point in its favour. Regards Jeff
ANNOUNCE: mod_perl-1.27
The URL
http://perl.apache.org/dist/mod_perl-1.27.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.27.tar.gz
size: 372525 bytes
md5: bd07f4f1065eb0d0a8d8004219357d8c
Changes since 1.26:
workaround Cwd bug in 5.8.0-RC1 that breaks apache configuration on solaris
fix get_set_PVp() to properly set NULL values when passing in undef
thanks to Lyle Brooks for the spot
[Stephen Clouse [EMAIL PROTECTED]]
Apache::Registry/PerlRun/RegistryNG errors are now saved
in $r-notes('error-notes')
[Jesse Erlbaum [EMAIL PROTECTED]]
fix Win32 build problems with spaces in shell arguments
[Randy Kobes [EMAIL PROTECTED]]
make sure DynaLoader is loaded before XSLoader to workaround possible
segv when using mod_perl as a dso with perl 5.6.1
autoset PERL_USELARGEFILES=0 if needed
fix taint issues with bleedperl
fix bug in modules/util test
[Tatsuhiko Miyagawa [EMAIL PROTECTED]]
Adjust the mailling list addresses
's|\@apache\.org|\@perl.apache.org|' [Stas Bekman [EMAIL PROTECTED]]
Apache::PerlRun will now localize $SIG{__{DIE,WARN}__}
thanks to Jon Coulter for the spot
PERL5LIB support now properly unshifts paths into @INC rather than push
[Tatsuhiko Miyagawa [EMAIL PROTECTED]]
do not clear symbol tables within a package in perl_clear_symtab()
used by directive handler extensions
[Stephen Clouse [EMAIL PROTECTED]]
properly deal with $r-status codes (e.g. redirect) in
Apache::RegistryNG [Geoff Young [EMAIL PROTECTED]]
allow $r-auth_name and $r-auth_type to be set on win32
[John Kelly [EMAIL PROTECTED]]
fix compilation for win32 w/ apache 1.3.22+
[Randy Kobes [EMAIL PROTECTED]]
fix multiple %LocationMatch in Perl sections bug
[Salvador Ortiz Garcia [EMAIL PROTECTED]]
rip -D_GNU_SOURCE out of Perl 5.7.3+'s ccflags, which modperl doesn't
need and apache won't compile with [Stas Bekman [EMAIL PROTECTED]]
make sure PerlSetEnv variables are visible after first access
to each child [Geoff Young [EMAIL PROTECTED]]
workaround Apache::Constants::AUTOLOAD problem with bleedperl
the first flag argument to perl cannot start with space, since perl tries
to open the -spi.bak as a file. fix that in the win32 case.
[Stas Bekman [EMAIL PROTECTED]]
starting from perl 5.7.3 for tied filehandles, tiedscalar magic is applied
to the IO slot of the GP rather than the GV itself. adjust the TIEHANDLE
macro to work properly under 5.7.3+. [Charles Jardine [EMAIL PROTECTED],
Stas Bekman [EMAIL PROTECTED]]
added perl_perl_merge_dir_config and array_header2avrv symbols to
mod_perl.def for win32 and mod_perl.exp for aix.
[Randy Kobes [EMAIL PROTECTED]]
INSTALL.apaci: added an explanation of how perl has to be built in
order to use DSO without problems (copied from the guide) based on
email from Doug. [Stas Bekman [EMAIL PROTECTED]]
warn if Perl is configured with -Duseshrplib and a libperl.so is found
in a place where it should not be, example: /lib /usr/lib or /usr/local/lib
fix potential segv in Apache::URI-rpath
[Vyacheslav Zamyatin [EMAIL PROTECTED]]
require URI::URL to work with newer libwww-perl
allow overriding of container directive handlers using the func parameter
[Geoffrey Young [EMAIL PROTECTED]]
enable directive handler support for TAKE13
[Geoffrey Young [EMAIL PROTECTED]]
---
Enjoy,
-Doug
ANNOUNCE: mod_perl-1.99_02
The URL
http://perl.apache.org/dist/mod_perl-1.99_02.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_02.tar.gz
size: 378436 bytes
md5: b08c12adc1a8ae4ce7a111f8d5fe0b43
Changes since 1.99_02:
pass the PATH and TZ environment variables at startup by default as 1.xx did
fix ModPerl::Util::exit segv with 5.6.0
no longer support 5.7.x perl development versions
added compat for Apache::Table-new
various fixes to compile/run on darwin
server-scope Perl{Set,Pass}Env config now propagated to %ENV at startup
use SvOK(sv) instead of sv == PL_sv_undef to detect undef values in xs
[Stephen Clouse [EMAIL PROTECTED]]
complete Apache::Util 1.x compat
added Apache::MPM_IS_THREADED constant
added compat function for Apache::Constants::SERVER_VERSION
added Apache::Constants::export stub for compat
added noop stubs for timeout functions removed from 2.0:
$r-{soft,hard,reset,kill}_timeout
turned on PerlOptions +GlobalRequest by default for perl-script handler
unless it is explicitly turned off with PerlOptions -GlobalRequest
added APR::OS::thread_current function
added support for 1.x $r-subprocess_env functionality
added support for $r-push_handlers(PerlHandler = ...)
added support for $r-proxyreq to detect proxy requests
$r-content_type($val) now calls ap_set_content_type underneath
add the err_header_out() wrapper to Apache::compat + corresponding tests
[Stas Bekman]
fix $r-dir_config lookup of values set in the server context
added Apache::REDIRECT shortcut constant
various fixes for method handlers
use Apache::ServerUtil in Apache::compat so Apache-server works in compat
mode [Dave Rolsky [EMAIL PROTECTED]]
add Apache::Util::unescape_uri alias to Apache::unescape_url in Apache::compat
change Apache::unescape_url to return the escaped url as 1.x does
disabled term coloring by default (enable with env var APACHE_TEST_COLOR=1)
fix for APR::IpSubnet-new to check return status apr_ipsubnet_create
enabled APR::SockAddr module
turn on binmode for filehandle used in $r-send_fd
get MP_{TRACE,DEBUG} Makefile.PL options working on win32
various fixes to build/run with bleedperl
various fixes for win32 to get make test passing
moved constuct_{url,server} methods to Apache::URI module
implement Apache::URI::parse in Apache::compat
give Perl*Handlers precedence over other handlers by using APR_HOOK_FIRST
rather than APR_HOOK_LAST
workaround bug in 5.6.1 when XSLoader loads DynaLoader, wiping out any
dl handles it had been keeping track of.
tidy up test to run standalone (without modperl test config)
[Stas Bekman]
override T_PTROBJ INPUT typemap to croak if object is not a blessed
reference, to prevent possible segv from e.g. Apache::Server-process
apr_lock.h is gone; disable APR::Lock for the moment
enabled the Apache::Process module
fix ModPerl::Util::exit to clear $@ before calling Perl_croak
cut down on some build noise
fix 'PerlOptions +GlobalRequest' when used within subrequests
get rid of some subroutine redefined warnings in ModPerl::MM that
show up with newer bleedperls.
a few fixes for Apache::compat [Dave Rolsky [EMAIL PROTECTED]]
---
Enjoy,
-Doug
5.8.0 RC1 has been released; please help testing it
In case you've missed this announcement, please help test Perl 5.8.0-RC1. The just released mod_perl-1.27 and mod_perl-1.99_02 were tested with this release and work properly on several platforms we were able to test on. Please make sure that when 5.8.0 is released it works for you (both mod_perl(s) and 3rd party Perl modules). - Forwarded message from Jarkko Hietaniemi [EMAIL PROTECTED] - =head1 Perl 5.8.0 Release Candidate 1 The Perl 5 developer team is pleased to announce the Release Candidate 1 of Perl 5.8.0. Please test extensively. Your help in testing the upcoming perl 5.8.0 is much appreciated. This is a source code release, not a binary release. You will need a C development environment. Please note that Perl 5.8.0 is a major new release of Perl containing many new features, enhancements to existing features and bug fixes. This version is Release Candidate 1; the purpose of this version is to permit and encourage the Perl community to conduct extensive testing and to report problems so that we, and the owners of affected Perl packages, have an opportunity to correct them. Because the process of testing the vast quantity of Perl software will take time, and because issues uncovered by this testing may result in further changes or corrections to Perl 5.8.0 and the various Perl packages, WE DO NOT RECOMMEND USING RELEASE CANDIDATE 1 IN A PRODUCTION ENVIRONMENT. Please wait for the final version of Perl 5.8.0 for production use. As always, you should conduct an appropriate level of testing before using any new product in your production environment. As specified in the licenses for Perl (see the files named Artistic or Copying), THIS PACKAGE IS PROVIDED WITH ABSOLUTELY NO WARRANTY. New Release Candidates will come out about weekly until we are satisfied with the results, at which point the final 5.8.0 will be released. =head1 Where To Get It The 5.8.0 RC1 is now available at http://mirrors.kernel.org/cpan/src/perl-5.8.0-RC1.tgz http://cpan.valueclick.com/src/perl-5.8.0-RC1.tgz ftp://ftp.leo.org/pub/CPAN/src/perl-5.8.0-RC1.tgz ftp://ftp.funet.fi/pub/CPAN/src/perl-5.8.0-RC1.tgz and as the CPAN mirrors catch up, in the src/ subdirectory of your nearest friendly CPAN mirror. The size of the file is 10913451 bytes and the MD5 checksum for the file is f595a07df28eb9e40d4d27281a9b37a9 perl-5.8.0-RC1.tgz This release should work in all UNIX/Linux and Microsoft environments, and in other environments which have POSIX/UNIX interfaces, such as BeOS, Cygwin, MPE/iX, NetWare, OS/2, QNX, VMS, VOS, and z/OS, and the appropriate C compilation environment. A MacOS Classic port requires a little bit more work but it should become available soon-- follow http://dev.macperl.org/ =head1 Why To Get It For the list of changes in 5.8.0 see the pod/perldelta.pod, available separately online at http://mirrors.kernel.org/cpan/doc/perldelta.pod http://cpan.valuelick.com/doc/perldelta.pod ftp://ftp.leo.org/pub/CPAN/doc/perldelta.pod ftp://ftp.funet.fi/pub/CPAN/doc/perldelta.pod (and again, eventually at all CPAN mirrors-- note, though, that these URLs are not permanent, they will be removed when the final 5.8.0 is released) The .tgz file will unpack into a directory called perl-5.8.0-RC1. =head1 How To Do It You will configure, build, and test Perl. Below is a short summary, for the full story read the INSTALL file. =head2 Configuring If you are in a UNIX-like system, you can setup Perl for compilation by changing into the perl-5.8.0-RC1 directory and issuing the following command: sh Configure -des This will simply select all the defaults for your system, INCLUDING defaulting to install in the usual location for production software. (So don't run make install if you run Configure this way!) If you are not in a UNIX-like system (say, Win32), please read the INSTALL file and any possible platform specific README files for further instructions, and skip the parts below that don't apply to your platform. If you want to go through Configure interactively (for example to change the default installation directories), do just sh Configure =head2 Building To build Perl issue the command make all Note that the build times can vary considerably. Perl 5.8.0 is about twice the size of 5.6.1, and some source code files are quite large, so your compiler might have hard time processing them. On a fast modern system with lots of CPU and memory the build can be a matter of ten minutes, but on slower/older/more heavily loaded systems it can take up to eight hours, while half an hour to an hour being common. =head2 Testing After the build has finished, it's time to test the build. make test Again, testing times vary a lot. Perl 5.8.0 has more than five times the tests of Perl 5.6.1. Fifteen minutes to half an hour is quite normal, but a slow system may easily take an hour or more. If
cvs commit: modperl/lib mod_perl.pm
dougm 2002/06/01 20:02:51
Modified:.Changes
lib mod_perl.pm
Log:
bump version to 1.27
Revision ChangesPath
1.649 +1 -1 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.648
retrieving revision 1.649
diff -u -r1.648 -r1.649
--- Changes 2 Jun 2002 02:59:37 - 1.648
+++ Changes 2 Jun 2002 03:02:51 - 1.649
-8,7 +8,7
=over 3
-=item 1.26_01-dev
+=item 1.27 - June 1, 2002
workaround Cwd bug in 5.8.0-RC1 that breaks apache configuration on solaris
1.54 +1 -1 modperl/lib/mod_perl.pm
Index: mod_perl.pm
===
RCS file: /home/cvs/modperl/lib/mod_perl.pm,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- mod_perl.pm 12 Jul 2001 02:27:28 - 1.53
+++ mod_perl.pm 2 Jun 2002 03:02:51 - 1.54
-4,7 +4,7
use DynaLoader ();
BEGIN {
-$mod_perl::VERSION = 1.2601;
+$mod_perl::VERSION = 1.27;
}
sub boot {
cvs commit: modperl/lib mod_perl.pm
dougm 2002/06/01 20:07:13
Modified:.Changes
lib mod_perl.pm
Log:
bump version
Revision ChangesPath
1.650 +2 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.649
retrieving revision 1.650
diff -u -r1.649 -r1.650
--- Changes 2 Jun 2002 03:02:51 - 1.649
+++ Changes 2 Jun 2002 03:07:13 - 1.650
-8,6 +8,8
=over 3
+=item 1.27_01-dev
+
=item 1.27 - June 1, 2002
workaround Cwd bug in 5.8.0-RC1 that breaks apache configuration on solaris
1.55 +1 -1 modperl/lib/mod_perl.pm
Index: mod_perl.pm
===
RCS file: /home/cvs/modperl/lib/mod_perl.pm,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- mod_perl.pm 2 Jun 2002 03:02:51 - 1.54
+++ mod_perl.pm 2 Jun 2002 03:07:13 - 1.55
-4,7 +4,7
use DynaLoader ();
BEGIN {
-$mod_perl::VERSION = 1.27;
+$mod_perl::VERSION = 1.2701;
}
sub boot {
