cvs commit: modperl-2.0/lib/Apache Build.pm
dougm 2002/06/18 18:26:28
Modified:lib/Apache Build.pm
Log:
need to check ccflags rather than optimize for -DDEBUGGING
Revision ChangesPath
1.100 +1 -1 modperl-2.0/lib/Apache/Build.pm
Index: Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.99
retrieving revision 1.100
diff -u -r1.99 -r1.100
--- Build.pm 17 Jun 2002 19:42:49 - 1.99
+++ Build.pm 19 Jun 2002 01:26:28 - 1.100
-285,7 +285,7
$val ||= $Config{optimize};
if ($self-{MP_DEBUG}) {
-return ' ' unless $val =~ /-DDEBUGGING/;
+return ' ' unless $Config{ccflags} =~ /-DDEBUGGING/;
}
$val;
cvs commit: modperl-2.0/lib/Apache Build.pm
dougm 2002/06/18 18:32:58
Modified:lib/Apache Build.pm
Log:
only win32 has -DDEBUGGING in both optimize and ccflags
Revision ChangesPath
1.101 +2 -1 modperl-2.0/lib/Apache/Build.pm
Index: Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.100
retrieving revision 1.101
diff -u -r1.100 -r1.101
--- Build.pm 19 Jun 2002 01:26:28 - 1.100
+++ Build.pm 19 Jun 2002 01:32:58 - 1.101
-252,7 +252,8
$fixup-(\$cflags);
}
-if ($self-{MP_DEBUG}) {
+if (WIN32 and $self-{MP_DEBUG}) {
+#only win32 has -DDEBUGGING in both optimize and ccflags
my $optim = $Config{optimize};
unless ($optim =~ /-DDEBUGGING/) {
cvs commit: modperl-2.0/src/modules/perl modperl_perl_includes.h modperl_util.c
dougm 2002/06/18 19:02:24
Modified:src/modules/perl modperl_perl_includes.h modperl_util.c
Log:
use mg_find to look for ~ magic in modperl_xs_sv2request_rec as there may be other
magic in the chain
Revision ChangesPath
1.15 +4 -0 modperl-2.0/src/modules/perl/modperl_perl_includes.h
Index: modperl_perl_includes.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl_includes.h,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- modperl_perl_includes.h 31 May 2002 01:06:39 - 1.14
+++ modperl_perl_includes.h 19 Jun 2002 02:02:24 - 1.15
-67,6 +67,10
# define PERL_MAGIC_tied 'P'
#endif
+#ifndef PERL_MAGIC_ext
+# define PERL_MAGIC_ext '~'
+#endif
+
#if defined(__APPLE__) !defined(PERL_CORE) !defined(environ)
# include crt_externs.h
# define environ (*_NSGetEnviron())
1.45 +2 -2 modperl-2.0/src/modules/perl/modperl_util.c
Index: modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- modperl_util.c31 May 2002 01:06:39 - 1.44
+++ modperl_util.c19 Jun 2002 02:02:24 - 1.45
-120,8 +120,8
return r;
}
-if ((mg = SvMAGIC(sv))) {
-return MgTypeExt(mg) ? (request_rec *)mg-mg_ptr : NULL;
+if ((mg = mg_find(sv, PERL_MAGIC_ext))) {
+return (request_rec *)mg-mg_ptr;
}
else {
if (classname !sv_derived_from(in, classname)) {
cvs commit: modperl-2.0/xs/Apache/Log Apache__Log.h
dougm 2002/06/18 22:18:04
Modified:lib/ModPerl WrapXS.pm
src/modules/perl mod_perl.h modperl_perl_includes.h
modperl_util.c modperl_util.h
xs/Apache/Log Apache__Log.h
Log:
get the -DPERL_CORE optimization working again
Revision ChangesPath
1.47 +1 -1 modperl-2.0/lib/ModPerl/WrapXS.pm
Index: WrapXS.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/WrapXS.pm,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- WrapXS.pm 11 Jun 2002 16:27:57 - 1.46
+++ WrapXS.pm 19 Jun 2002 05:18:04 - 1.47
-397,7 +397,7
my $str = ;
if (my $boot = $self-typemap-{function_map}-{boot}-{$module}) {
-$str = 'mpxs_' . $self-cname($module) . _BOOT(aTHXo);\n;
+$str = 'mpxs_' . $self-cname($module) . _BOOT(aTHX);\n;
}
$str;
1.47 +1 -1 modperl-2.0/src/modules/perl/mod_perl.h
Index: mod_perl.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- mod_perl.h16 Jun 2002 01:07:37 - 1.46
+++ mod_perl.h19 Jun 2002 05:18:04 - 1.47
-75,7 +75,7
apr_pool_t *modperl_server_pool(void);
PerlInterpreter *modperl_startup(server_rec *s, apr_pool_t *p);
int modperl_perl_destruct_level(void);
-void xs_init(pTHXo);
+void xs_init(pTHX);
void modperl_response_init(request_rec *r);
void modperl_response_finish(request_rec *r);
1.16 +2 -0 modperl-2.0/src/modules/perl/modperl_perl_includes.h
Index: modperl_perl_includes.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl_includes.h,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- modperl_perl_includes.h 19 Jun 2002 02:02:24 - 1.15
+++ modperl_perl_includes.h 19 Jun 2002 05:18:04 - 1.16
-9,6 +9,8
#define PERLIO_NOT_STDIO 0
+#include config.h
+
/*
* sizeof(struct PerlInterpreter) changes #ifdef USE_LARGE_FILES
* apache-2.0 cannot be compiled with lfs because of sendfile.h
1.46 +1 -1 modperl-2.0/src/modules/perl/modperl_util.c
Index: modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- modperl_util.c19 Jun 2002 02:02:24 - 1.45
+++ modperl_util.c19 Jun 2002 05:18:04 - 1.46
-292,7 +292,7
#define dl_librefs DynaLoader::dl_librefs
#define dl_modules DynaLoader::dl_modules
-void modperl_xs_dl_handles_clear(pTHXo)
+void modperl_xs_dl_handles_clear(pTHX)
{
AV *librefs = get_av(dl_librefs, FALSE);
if (librefs) {
1.34 +1 -1 modperl-2.0/src/modules/perl/modperl_util.h
Index: modperl_util.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.h,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- modperl_util.h23 May 2002 22:18:47 - 1.33
+++ modperl_util.h19 Jun 2002 05:18:04 - 1.34
-73,7 +73,7
char *modperl_server_desc(server_rec *s, apr_pool_t *p);
-void modperl_xs_dl_handles_clear(pTHXo);
+void modperl_xs_dl_handles_clear(pTHX);
apr_array_header_t *modperl_xs_dl_handles_get(pTHX_ apr_pool_t *p);
1.10 +1 -1 modperl-2.0/xs/Apache/Log/Apache__Log.h
Index: Apache__Log.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/Log/Apache__Log.h,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Apache__Log.h 26 Mar 2002 03:37:47 - 1.9
+++ Apache__Log.h 19 Jun 2002 05:18:04 - 1.10
-1,4 +1,4
-static void mpxs_Apache__Log_BOOT(pTHXo)
+static void mpxs_Apache__Log_BOOT(pTHX)
{
av_push(get_av(Apache::Log::Request::ISA,TRUE),
newSVpv(Apache::Log,11));
Re: Naming convention for Apache 2 modules.
At 11:31 18.06.2002, Andy Wardley wrote: I've been playing around with Apache 2 and mod_perl 1.99 and considering the changes I'll need to make to Apache::Template to make it play nicely under the new world order. Given that I want to continue to support Apache::Template for v1 users, should I create another module, say Apache2::Template, or is there some preferred approach to v1/v2 compatabilities that I should consider? I've read the compat.html doc and understand that I might be able to support Apache::Template as it is with the help of the Apache2 compatability module. However, I'm sure there are some parts, server/dir merging in particular (which seem to be broken in v1 anyway), which are going to need new implementations for v2, so I figure it's probably worth forking the codebase sooner rather than later. What about making the 2.0 module follow the conventions I posted about earlier? Something like Apache::Framework::Template? -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Mon, 17 Jun 2002, Slava Bizyayev wrote: Yes, absolutely. And no one on the earth may restrict your rights to log anything you feel important in your own handler. Just every overhead decrements the number of your prospective users. And when you try to dictate your very own needs (or fantasies) to be accepted as a standard, you are incorrect. It was my reply to Valerio_Valdez. He had asked me why I need logging. I had answered him. You said me once again about another ways of logging. I know them. Thank you. I do not try to dictate anyone my needs or fantasies. Relax and do anything in fixup handler and tutorial - I would try not disturb you in any way and hope that is the last my email on this subject. Igor Sysoev http://sysoev.ru
Apache:: module organization and getting it to work with PAUSE
Hi people, Time for a post that's a little different than your usual New user and New module e-mails :) I'm posting here since it seems like the most appropriate place to discuss these issues. I adressed an issue on the mod_perl list lately concerning the Apache:: namespace organization. As you may know, all mod_perl modules are currently grouped under Apache::, which creates a pretty extensive mess now that there are many of them. You can see the thread here: http://mathforum.org/epigone/modperl/skeldkendtrau . The RFC was generally well received, so I think we are going to go through with it. Of course, we cannot change the current modules, but it would be preferable to get new modules to follow certain conventions, like others on CPAN. Why am I adressing you? Because Randy suggested, and I agreed, that some kind of module listing in categories would be interesting for the modules and for the mod_perl community--probably having a page dedicated to mod_perl modules. However, we don't want one person to maintain such a category: just like PAUSE exists to avoid one person to take care of all CPAN modules, it would be preferable to get module authors to categorize their modules themselves. This can only be done satisfactorily with PAUSE, to handle password protection etc... So I'm wondering if this is doable: for example, on the Register namespace page, there could be a category called mod_perl modules, which would then bring you to a second page where you choose your mod_perl category. Just tell me what you think. It would be interesting to get this working. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: [RFC] Change our habits in module naming?
At 13:22 18.06.2002, Stas Bekman wrote: [when suggesting things please give people some time to respond, especially given the crazy traffic at this list lately. I just had a chance to read this thread.] Sorry. I'm -1 on renaming. Here is why: I never talked about renaming. I talked about new modules. - Not all modules fit into suggested categories, some modules belong to several ones. Of course, but just like on regular CPAN you choose a category even if it might not be *exactly* the one you're looking for, it's possible to choose a namespace because it's what's most appropriate for a module. If there's really a problem, then a new namespace could be created, there's nothing wrong with that. - We definitely don't want the hell to break loose by pushing the authors to rename their modules. Think of all the documents which aren't under our control which refer to these module names! Books and articles to start with. As I said, I didn't say we should rename existing modules. - This is also doesn't help with the move to 2.0, because many modules will work with both versions without changes, or with some internal changes transparent to users. It doesn't force authors to rename their modules. And with the Apache2/ dir trick, there is no reason for doing that at all. The Apache2/ trick doesn't help *people* follow module namings. My proposal is mainly targeted at peoples' minds: we like organization, that's why we have namespaces in the first place! It'd be great though to have guidelines for developing Apache:: modules and their name conventions. There feel free to suggest a better categorization. Oops, didn't see this one :) Well, that was mostly my suggestion. It's just about the naming for new modules. And I'm -1 on maintaining a separate catalog. Here is why: CPAN is already categorizing Apache:: modules. http://www.cpan.org/modules/00modlist.long.html#ID15_WorldWideW (just scroll down till you get to Apache::) all we need is to add #Apache and the problem solved. We have already tried to maintain apache-modlist.html, which just didn't work, the file was neglected and many new modules aren't there. Whereas they are in the CPAN listing. May be instead of potentially wasting efforts here, the effort should go to help improve 00modlist.long.html, so both Apache and other Perl categories will benefit from this. I'm quite sure that Andreas and folks who bring you CPAN will be glad to get any help in this direction. Andreas please correct me if I'm wrong. That's why I contacted [EMAIL PROTECTED] I feel too that this would belong in the Perl module listing (although that didn't appear clearly in my other e-mail), but my proposal to PAUSE was just there to allow module authors to do their classification. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Naming convention for Apache 2 modules.
At 13:26 18.06.2002, Stas Bekman wrote: Andy Wardley wrote: I've been playing around with Apache 2 and mod_perl 1.99 and considering the changes I'll need to make to Apache::Template to make it play nicely under the new world order. Given that I want to continue to support Apache::Template for v1 users, should I create another module, say Apache2::Template, or is there some preferred approach to v1/v2 compatabilities that I should consider? I've read the compat.html doc and understand that I might be able to support Apache::Template as it is with the help of the Apache2 compatability module. However, I'm sure there are some parts, server/dir merging in particular (which seem to be broken in v1 anyway), which are going to need new implementations for v2, so I figure it's probably worth forking the codebase sooner rather than later. No Andy, no need to rename, you can either maintain the two in one module (if it's not too messy, which is the case if you have a lot of C) or just two different versions which will install themselves into different dirs. Here are some preliminary notes discussing these issues. http://perl.apache.org/release/docs/2.0/devel/porting_from_1.x/porting_from_1.x.html Feel free to help improving on these. Of course the MP_INST_APACHE2=1 mechanism needs to become available to to other module writers. Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: custom directives, again...
* Noam Solomon [EMAIL PROTECTED] [2002-06-17 17:49]: I sent out a plea for help last week, but probably didn't provide enough information for a quick solution. The problem is that I'm using Apache::OpenIndex (which is similar to Apache::AutoIndex) and have not been able to get the apache server on the production box to detect a custom directive it defines (OpenIndexOptions). I didn't have this problem on my development machine, so I'm baffled as to its origin. [-- snip --] Here's some salient bits of the httpd.conf: # GLOBAL MOD_PERL CONFIG IfDefine HAVE_PERL AddModule mod_perl.c PerlRequire /home/httpd/startup.pl PerlFreshRestart On etc.. PerlRequire /home/httpd/mason/handler.pl /IfModule # END GLOBAL MOD_PERL CONFIG Make sure that you pull in the module using PerlModule, and not from use in a PerlRequire. PerlModule does some bootstrapping to make sure that directives are passed to your module, rather than let Apache try to do something with them. (darren) -- Make no laws whatever concerning speech, and speech will be free; so soon as you make a declaration on paper that speech shall be free, you will have a hundred lawyers proving that freedom does not mean abuse, nor liberty license; and they will define and define freedom out of existence. -- Voltarine de Cleyre
Re: Naming convention for Apache 2 modules.
[CC'ing Andreas again] Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. That's true :( I hope Andreas can make PAUSE index both versions so CPAN.pm will display the two, but for that we need some sort convention so PAUSE can use to decide on. Andreas, any ideas regarding this issue? Thanks! __ 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: Naming convention for Apache 2 modules.
On 2002.06.18 09:57 Stas Bekman wrote: [CC'ing Andreas again] Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. That's true :( I hope Andreas can make PAUSE index both versions so CPAN.pm will display the two, but for that we need some sort convention so PAUSE can use to decide on. Andreas, any ideas regarding this issue? An alternative approach could involve placing the functionality specific to mod_perl 2.0 in a sub-module, then conditionally importing that submodule depending on the value of $Apache::Registry::VERSION. Ian
Re: separating C from V in MVC
[sorry for the broken References - I've just joined the list and am replying to a post in the archives] On Sat, 15 Jun 2002, Perrin Harkins said: An Object-Relational mapper takes objects and stores them in a relational database, as transparently as possible. I think the most pure example of this I've seen in the Perl world is Tangram (www.tangram-persistence.org). SPOPS is also an O-R mapper (actually, its a generic Object persistence mechanism but it seems to most feature-rich when used with an RDBMS). A Relational-Object takes a relational database, and provides access to it (select, insert, update, delete) via objects. Class::DBI, Alzabo, and DBIx::RecordSet are examples of such a beast. I would actually put Class::DBI in with the first set. I'd have to disagree. Maybe Mike had something different in mind when he created Class::DBI, but as the current active developer on it, I'm definitely pushing it in the R-O direction. Like Dave, I always start by thinking of my database schema and then Class::DBI provides a way to translate that, table - class, row - object, column - method. Throw in some simple relationship builders and a sprinking of syntactic sugar, and that's pretty much there is to Class::DBI. To me the difference is not O/R vs R/O, since both of them go both directions. Rather it's a question of what you're modelling in your objects. I think one of the main differences is in what ways you want to be able to manipulate your data. With an R/O approach the Perl classes are just one of the possible views into your data. If you feel like it you can also do your normal SQL type things on it. In fact one of the deliberate strengths of Class::DBI is that you can very easily port an existing roll-your-own-SQL-in-Perl approach over to it gradually. With O/R approaches the object is usually the primary source of the data and the database is just a temporary storage system used for persistence. You probably _could_ go executing arbitrary commands against the database, but it's frowned upon. Things like Tangram model the domain objects, i.e. concerts, seats, people. Things like Alzabo model the database objects, i.e. tables, rows, foreign keys. I think on this front they both try to do both. Class::DBI does anyway. It assumes that you're going to create your database schema in a way that these are fairly much interchangable. Tony
Re: Error Handling
Gregory Matthews wrote:
Thank you for the link.
[Gregory, please remember to keep the threads on the list and not to
take them private without being asked to and worse, not sharing the
knowledge with the rest of the community]
This is the route I would like to go (My::Exeption). Could you please
provide a simple example of how I would utilize this in my code.
If you have the mod_perl cookbook, check the recipe 8.6 (it's not online).
otherwise depending on your needs you simply generate the response and
set the return code accordingly. For example as 8.6 suggests:
use Apache::Constants qw(SERVER_ERROR);
$r-custom_response(SERVER_ERROR, send more coffee);
Can somebody please submit a patch to this doc
http://perl.apache.org/release/docs/general/perl_reference.html#Exception_Handling_for_mod_perl
with a nice complete example, which does the exception handling and
generates a custom error response to user plus does the logging? The
existing material is nice, but misses real examples.
For example, I've uploaded Exeption.pm to the My directory.
I've inserted use My::Exeption; into my code.
Now, if I want to catch an internal server error and display a custom
message based on what caused the error, how would I call this module
from my code?
For example, say I try to load a module, use HTML::Template, which is
not available.
that would be a complile time error, which you cannot catch with eval
{}, you must use 'require() HTML::Template' for performing the run-time
testing.
This would cause an internal server error that I would
like to catch and display in neatly formatted HTML stating that.
The idea is that you try {} catch {} in perl:
eval {
require oops_i_did_it_again;
};
if ($@) {
my_exception_handler($@);
}
now inside my_exception_handler you do whatever you want, log to
error_log and send a nice error message to a user, or just log and
return SERVER_ERROR, or just send a message to a user if it's a user
error. Matt's section was showing how to use AUTOLOAD to autovivify
packages for each exception, but in really it should be a solid set of
classes that you should write. So start from the example above and work
from there.
The simplest my_exception_handler does:
sub my_exception_handler { die $_[0] }
__
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: Naming convention for Apache 2 modules.
Ian D. Stewart wrote: On 2002.06.18 09:57 Stas Bekman wrote: [CC'ing Andreas again] Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. That's true :( I hope Andreas can make PAUSE index both versions so CPAN.pm will display the two, but for that we need some sort convention so PAUSE can use to decide on. Andreas, any ideas regarding this issue? An alternative approach could involve placing the functionality specific to mod_perl 2.0 in a sub-module, then conditionally importing that submodule depending on the value of $Apache::Registry::VERSION. This is not the case for the complex modules involving C, XS, custom directives and lots of code. As a module author I'd rather have a separate code base without gazillions of #ifdefs and perl side version checking. It's very unlikely that you will be able to extract mod_perl 2.0 specific functionality into a sub-module, because most of the Apache:: modules are using the mod_perl 2.0 API everywhere in the code. __ 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
mod_perl module documentation
It has long frustrated me that there was no mod_perl module documentation, in the style of the standard Apache module documentation. I don't mean to bash the docs that are there - clearly, they are of exceptional quality. But I wanted something like the standard module docs. So, rather than complaining, which would seem to be, at best, in poor taste, given the quantity of stuff that folks like Stas have already written, I've started on a mod_perl module doc, based on the Apache 2.0 module documentation XML template. You can see the first cut at http://www.apacheadmin.com/mod_perl.html I know, it is gravely lacking, and needs help. And I intend to do something about that. But I have a few questions before I burn a lot of time on that. Where, if anywhere, should such a document go? Yeah, it can stay where it is, but I would not think that anyone would think to look there. Has someone already done this, and I'm just missing it? I know that there is similar information at http://www.apacheref.com/ref/mod_perl.html but I was hesitant to steal that wholesale. Besides, everyone should buy Ralf's book, and I don't want to dilute that in any way. ;-) Is there currently, or are there any plans for, a mod_perl documentation cvs repository, where something like this could live? Anyways, tell me what you think. I have the original XML, which is vastly more useful than the HTML output, and would be glad to give that to anyone that wants it. -- CooperMcGregor, Inc. Apache, Perl, and mod_perl More #! for your $
Re: mod_perl module documentation
Rich Bowen wrote: It has long frustrated me that there was no mod_perl module documentation, in the style of the standard Apache module documentation. I don't mean to bash the docs that are there - clearly, they are of exceptional quality. But I wanted something like the standard module docs. So, rather than complaining, which would seem to be, at best, in poor taste, given the quantity of stuff that folks like Stas have already written, I've started on a mod_perl module doc, based on the Apache 2.0 module documentation XML template. You can see the first cut at http://www.apacheadmin.com/mod_perl.html I know, it is gravely lacking, and needs help. And I intend to do something about that. But I have a few questions before I burn a lot of time on that. If you plan to leave it just as it's now (bare bones) it's ok. But if you plan to really write full fledged docs, please don't. Why duplicated efforts and confuse users with inconsistent documentation which is already *huge*. Have you see the work we have done in the last half a year? http://perl.apache.org/release/docs/ I've been working on docs similar to your doc recently: http://perl.apache.org/release/docs/2.0/user/config/config.html http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html not very different than yours but adhers to the rest of the documentation. We already have 106 pods (2.3MB) and growing. So if you want to help please join the docs list and let's talk there: http://perl.apache.org/release/maillist/docs-dev.html#Subscription_Information we may come up with an idea to make Apache style docs as well, but only bare bones with pointers to the real docs. let's talk over docs-dev. Where, if anywhere, should such a document go? Yeah, it can stay where it is, but I would not think that anyone would think to look there. we have it already. Has someone already done this, and I'm just missing it? I know that there is similar information at http://www.apacheref.com/ref/mod_perl.html but I was hesitant to steal that wholesale. Besides, everyone should buy Ralf's book, and I don't want to dilute that in any way. ;-) Is there currently, or are there any plans for, a mod_perl documentation cvs repository, where something like this could live? the repository exists for some 9 months, called modperl-docs Anyways, tell me what you think. I have the original XML, which is vastly more useful than the HTML output, and would be glad to give that to anyone that wants it. see above __ 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: tutorials (was: Re: rfc Apache::Dynagzip)
It's not quite the truth again. It is not a private email; it is a public mailing list. Everyone writing here expects the replies and comments from any other subscriber, especially from the main speaker of the thread. Igor seems upset with the current (not still final) results of this discussion, which HE tried to turn selfishly to a wrong way. Impolite style of discussions accomplished with attempts to hide some information and to provide some fantasies instead of real results of professional research does not work on this professional mailing list. That's right, instead of the main discussion we've spent a lot of time to learn a lesson, how the impolite selfish guy playing fool with professionals is punished finally, but wasn't it a fun? Ok, let me consider the lesson is over, and we may now go back to the main subject of this discussion. Just a few important conclusions: It's nothing bad to be wrong, or to make mistakes. Everyone does sometimes. We join our efforts, knowledge, and expertise in discussions to help each other to make every job well done with full respect of efforts, knowledge, and expertise of every participant. That 's why we can compete successfully in this world. I firmly believe that Igor will be back in our discussions soon, equipped with right behavior, and no one of us will ever mention his old mistake. Thanks, Slava From: Igor Sysoev [EMAIL PROTECTED] It was my reply to Valerio_Valdez. He had asked me why I need logging. I had answered him. You said me once again about another ways of logging. I know them. Thank you. I do not try to dictate anyone my needs or fantasies. Relax and do anything in fixup handler and tutorial - I would try not disturb you in any way and hope that is the last my email on this subject. Igor Sysoev http://sysoev.ru
Re: mod_perl module documentation
On Tue, Jun 18, 2002 at 01:30:47PM -0400, Rich Bowen wrote: It has long frustrated me that there was no mod_perl module documentation, in the style of the standard Apache module documentation. I don't mean to bash the docs that are there - clearly, they are of exceptional quality. But I wanted something like the standard module docs. So, rather than complaining, which would seem to be, at best, in poor taste, given the quantity of stuff that folks like Stas have already written, I've started on a mod_perl module doc, based on the Apache 2.0 module documentation XML template. You can see the first cut at http://www.apacheadmin.com/mod_perl.html I like it a lot - but then again, I'm a big fan of the apache docs, so this format is a big hit with me :) I like the guide, but once you've been through it a couple of times then this is the sort of document you need IMHO. Short, concise and more of a reference is the way to go, and it makes life simpler for someone like me who admins apache more than mod_perl. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: mod_perl module documentation
Just speaking as a mod_perl user/developer, I think the format of Rich's docs is excellent. Since these are directives that belong in httpd.conf, it makes sense for their documentation to look like the documentation of other non-perl directives that belong in httpd.conf. Organization-wise, Rich's docs seem like a reference, whereas most of the docs Stas points to seem to be more tutorial or task-oriented in nature. Perhaps Rich's docs should remain fairly slim, with links to more comprehensive discussion in the 'tutorial/howto' docs? Would that be maintainable? Wes Stas Bekman [EMAIL PROTECTED] on 06/18/2002 02:09:51 PM To: Rich Bowen [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: mod_perl module documentation Rich Bowen wrote: It has long frustrated me that there was no mod_perl module documentation, in the style of the standard Apache module documentation. I don't mean to bash the docs that are there - clearly, they are of exceptional quality. But I wanted something like the standard module docs. So, rather than complaining, which would seem to be, at best, in poor taste, given the quantity of stuff that folks like Stas have already written, I've started on a mod_perl module doc, based on the Apache 2.0 module documentation XML template. You can see the first cut at http://www.apacheadmin.com/mod_perl.html I know, it is gravely lacking, and needs help. And I intend to do something about that. But I have a few questions before I burn a lot of time on that. If you plan to leave it just as it's now (bare bones) it's ok. But if you plan to really write full fledged docs, please don't. Why duplicated efforts and confuse users with inconsistent documentation which is already *huge*. Have you see the work we have done in the last half a year? http://perl.apache.org/release/docs/ I've been working on docs similar to your doc recently: http://perl.apache.org/release/docs/2.0/user/config/config.html http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html not very different than yours but adhers to the rest of the documentation. We already have 106 pods (2.3MB) and growing. So if you want to help please join the docs list and let's talk there: http://perl.apache.org/release/maillist/docs-dev.html#Subscription_Information we may come up with an idea to make Apache style docs as well, but only bare bones with pointers to the real docs. let's talk over docs-dev. Where, if anywhere, should such a document go? Yeah, it can stay where it is, but I would not think that anyone would think to look there. we have it already. Has someone already done this, and I'm just missing it? I know that there is similar information at http://www.apacheref.com/ref/mod_perl.html but I was hesitant to steal that wholesale. Besides, everyone should buy Ralf's book, and I don't want to dilute that in any way. ;-) Is there currently, or are there any plans for, a mod_perl documentation cvs repository, where something like this could live? the repository exists for some 9 months, called modperl-docs Anyways, tell me what you think. I have the original XML, which is vastly more useful than the HTML output, and would be glad to give that to anyone that wants it. see above __ 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: mod_perl module documentation
At 13:30 18.06.2002 -0400, you wrote: http://www.apacheadmin.com/mod_perl.html Great. I explicitely missed this before. Especially the context information is useful if you have to do things via .htaccess as much as possible. Thanx, Joachim -- ... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen.- Bertolt Brecht - Leben des Galilei
erros: Attempt to free non-existent shared string during global destruction.
Not sure if this has been brought up before. I compiled and installed mod_perl/1.27 via apxs like so: $ perl Makefile.PL EVERYTHING=1 USE_APXS=1 WITH_APXS=/usr/local/sbin/apxs $ cd apaci $ make $ make install The installation went well, I did a graceful and it wouldn't restart, instead apache shutdown and it spit out aprox. 2,880 lines in my logs that said: Attempt to free non-existent shared string during global destruction. Seems like it got stuck in a loop trying to do a graceful restart. So I used apachectl. to start the server and it started fine, with the module. It seems that everytime I do a graceful retstart it crashes and spits out the exact same amount of lines (apprx 2,880) in my logs, same message. Again it runs fine (apache and the module (libperl.so)) until I do a graceful. Luckily, I made a backup of my old libperl.so. I removed the newly installed module (1.27) and put back my old one (1.25) and I no,longer have problems with a graceful restart. I'm using Darwin/OSX 10.1.5 apache/1.3.23 perl/5.6.0, Any suggestions???
Re: separating C from V in MVC
Tony Bowden wrote: I'd have to disagree. Maybe Mike had something different in mind when he created Class::DBI, but as the current active developer on it, I'm definitely pushing it in the R-O direction. Like Dave, I always start by thinking of my database schema and then Class::DBI provides a way to translate that, table - class, row - object, column - method. Throw in some simple relationship builders and a sprinking of syntactic sugar, and that's pretty much there is to Class::DBI. Tangram may have loftier goals, but in general that's pretty much all there is to any of them. And I don't think that the angle you approach your data design from -- classes or tables -- has much bearing on which tool you would use, with the possible exception of Tangram. SPOPS is explicit about wanting to support legacy schemas without changes. I think that in this realm there is Tangram, which tries to bring some extra stuff like database modelling of object inheritance and queries written in perl, and everything else. Things like Tangram model the domain objects, i.e. concerts, seats, people. Things like Alzabo model the database objects, i.e. tables, rows, foreign keys. I think on this front they both try to do both. Class::DBI does anyway. My casual perusal of the documentation certainly made it look like Class::DBI hid a lot more of the database stuff than Alzabo. After the configuration is done, the database concepts like foreign keys are never explict. I guess my point here is simply that I think there isn't so much difference between most of these tools and that characterizing them as being anti-database or too heavy is not accurate. As a sort of wrap-up to this round of O/R technology discussion, I want to post a link to this quote from the author of SPOPS where he talks about the practical limitations of SQL abstraction. I thought it was a pretty astute observation: http://perlmonks.org/index.pl?node_id=162259 - Perrin
