Re: Apache::ASP #include file
On Aug 26, [EMAIL PROTECTED] contorted a few electrons to say... Philip Philip Mak wrote: Philip Philip Recently, I reinstalled mod_perl and Apache::ASP on my system in order to Philip fix a problem I was having with ASP not using the new version of perl on Philip my system. However, I'm having problem with some old code. Philip Philip I used to do this: Philip Philip In httpd.conf: PerlSetVar IncludesDir /home/goamembers/www Philip In an ASP script: !--#include file="/index.inc"-- Philip Philip Notice the "/" in "/index.inc". This would force it to get index.inc from Philip /home/goamembers/www, instead of the current directory. This makes it kind Philip of like !--#include virtual-- does with respect to filenames that start Philip with "/" (but include virtual cannot be used to inline asp code). Philip Philip Philip That functionality was never intended to be supported, and Philip am surprised it ever worked! How painful would it be for Philip you to change your includes to be like !--#include file="index.inc"-- while we are on this topic, is there any chance Apache::ASP could look at IncludesDir when executing global.asa? it doesn't seem to AFAICT. jr -- Joel W. Reed412-257-3881 Verbosity leads to unclear, inarticulate things. PGP signature
Re: mod_perl weaknesses? help me build a case....
On Apr 05, [EMAIL PROTECTED] hacked the bitstream to say... Soulhuntre Hiya! Soulhuntre 1) It is VERY easy to have arcane errors in mod_perl code, and that code is Soulhuntre not as easily debugged as one could hope. While it seems that we can be very Soulhuntre careful with our own code and avoid much of this - there are numerous issues Soulhuntre about CPAN modules, that means much of the advantage of perl is called into Soulhuntre question. OTOH, it seems (from my lurking on this list occasional posts) that there are many gurus who are kind enough to help out when you have a problem. i would choose carefully which CPAN modules you rely on of course. Soulhuntre Soulhuntre 2) It seems that the stability of Apache is adversely effected - with the Soulhuntre most common reccomendations being that the apache config should be tailored Soulhuntre to restart the children every x requests to prevent memory creeping crud. Soulhuntre Soulhuntre 3) There are LOTS of posts about segfaults with bad code - this is scary :) Soulhuntre It seems like the perl core has a way to go to be ready for this? i agree with your sentiments. not sure why segfaults are not avoidable... the apache process model deals with this far better than iis to be sure though. Soulhuntre Soulhuntre 4) There does not seem to be a compatible win32/linux modperl/embedding Soulhuntre toolkit. I can use modperl/apache/::ASP under linux, but the same setup does Soulhuntre not seem stable under win32 - and the activestate ASP perlex stuff does not Soulhuntre seem completely compatible. we are using Apache::ASP with swigged c++ - perl objects, and running the same code under IIS w/ASP and ActivePerlScript. this lets you drop writing hard-to-codedebug COM crap. check out http://www.swig.org. jr -- Joel W. Reed http://ruby.ddiworld.com/jreed ---I have a 33.6Kbps modem and 1.5bps fingers---
[OT] javascript to perlscript porting tool
I've posted a simple program that may help you if you're trying to port windoze javascript-based ASP pages to Apache::ASP. you can find it here... http://ruby.ddiworld.com/jreed/web/software/asp2pl.html jr -- Joel W. Reed http://ruby.ddiworld.com/jreed -Did You Know? (DYK?): A group of storks is called a mustering.-
Re: [PATCH] in memory $Application object for Apache::ASP
On Mar 29, [EMAIL PROTECTED] hacked the bitstream to say...
Joshua Joel Reed wrote:
Joshua
Joshua this may be a dumb patch to Apache::ASP (at least it is my first).
Joshua
Joshua Rationale:
Joshua
Joshua i have the following issues with the current implementation of $Application
Joshua
Joshua 1. everything you store in $Application-{foo} must be
Joshua serializable my MLDBM. (right?) i have SWIG'd c++ classes for
Joshua which this will not work.
Joshua
Joshua 2. limitation #1 seems to limit Apache:ASP's usefulness as a
Joshua cross-platform solution to ActivePerl/IIS/ASP scripts you
Joshua want to move to linux, etc. i want to do this - not sure if
Joshua this is really a key thing for joshua though...
Joshua ...
Joshua
Joshua What you are talking about is just a global that you access
Joshua in your scripts. You could declare this in your global.asa
Joshua with
Joshua
Joshua use vars qw($Application2);
Joshua
Joshua Then just use it like $Application2-{key} = $value;
Joshua
Joshua I use this kind of in process data caching all the time,
Joshua and you will see that Apache::DBI does something similar.
only then i don't have API consistency from NT/iis/asp... maybe
this is a unreasonable goal of mine... :(
Joshua
Joshua What you don't get here is interprocess communication
Joshua which is what the use of $Application is geared for, that
Joshua the data is stored is some process neutral location, so
Joshua web requests may access the data independent of the httpd
Joshua process they are coming from.
Joshua
yes this is the killer with making my stuff work for both iis/asp modperl.
do you have any suggestions for an api consistent solution? maybe i could
hack up something where $Application data was obtainable thru IPC? the
killer is the serialization requirement as i'm dealing with perl encapsulated
c++ objects...
thanks for your feedback,
jr
--
Joel W. Reed http://ruby.ddiworld.com/jreed
---A few cans short of a six pack, Six short.---
Re: [PATCH] in memory $Application object for Apache::ASP
On Mar 29, [EMAIL PROTECTED] hacked the bitstream to say... modperl Joshua What you don't get here is interprocess communication modperl Joshua which is what the use of $Application is geared for, that modperl Joshua the data is stored is some process neutral location, so modperl Joshua web requests may access the data independent of the httpd modperl Joshua process they are coming from. modperl Joshua modperl modperl yes this is the killer with making my stuff work for both iis/asp modperl. modperl do you have any suggestions for an api consistent solution? maybe i could modperl hack up something where $Application data was obtainable thru IPC? the modperl killer is the serialization requirement as i'm dealing with perl encapsulated modperl c++ objects... sorry to respond to myself but i just realized a got momentarily confused. what i would love to have is api consistent (w/ IIS/ASP) means of all scripts served by apache process "foo" to be able to access the $Application data and that this data doesn't have a must-be-serializable requirement. Apache::ASP currently provides $Application data thru MLDBM serialization that is available to ALL apache processes. i could imagine at least some people porting IIS/ASP/ActivePerlScript applications to apache/mod_perl would appreciate someway to do what i'm trying to do. under IIS lots of folks make COM objects, stuff them in $Application and all the IIS threads use the $App data just fine. when these folks port to apache/linux use must drop COM (thus i'm wrapping straight C++ libraries into Perl objects with SWIG), but i still need this can't-require serialization-support for $Application data requirement and would gladly accept each process having its own $Application data. what about a configuration option that was something like... PerlSetVar AppDataPerProcess (0|1) jr -- Joel W. Reed http://ruby.ddiworld.com/jreed "This is a job for.. AACK! WAAUGHHH!! ...someone else." - Calvin
[PATCH] in memory $Application object for Apache::ASP
this may be a dumb patch to Apache::ASP (at least it is my first).
Rationale:
i have the following issues with the current implementation of $Application
1. everything you store in $Application-{foo} must be
serializable my MLDBM. (right?) i have SWIG'd c++ classes for
which this will not work.
2. limitation #1 seems to limit Apache:ASP's usefulness as a
cross-platform solution to ActivePerl/IIS/ASP scripts you
want to move to linux, etc. i want to do this - not sure if
this is really a key thing for joshua though...
So the following patch (which i really hope joshua comments on ;)
fixes my problems (or so it seems). i've made an $Application2 object
which uses the implementation from the mod_perl guide to make a
global variable accessible by all scripts. (i'd love for this to become
the real $Application). It doesn't do everything else $Application
does at this point, but does demonstrate the idea works on my SWIG'd
c++ stuff.
i'd love to know if i'm totally of the wall or how to improve this
idea. seems like it would be faster, more like IIS/ASP, and remove
the serializable requirement, although it would jack up memory
requirements i would imagine. i'd be glad to incorporate any suggested
improvements to make it acceptable to Joshua for inclusion in
Apache::ASP...
--- ASP.pm Thu Feb 3 20:35:08 2000
+++ /usr/lib/perl5/site_perl/5.005/Apache/ASP.pmTue Mar 28 16:00:19 2000
@@ -1154,6 +1154,8 @@
# "use vars qw(\$".join(" \$",@Apache::ASP::Objects).');',
"sub $subid { ",
' return(1) unless $_[0]; ', #@_ = ();',
+ "use vars qw(%Application2);",
+ "*Application2 = \\%Apache::ASP::InMemoryApplicationObject::Application2;",
$$script,
'}',
);
@@ -2115,6 +2117,8 @@
$strict,
"use vars qw(\$".join(" \$",@Apache::ASP::Objects).');',
"use lib qw($self-{asp}-{global});",
+"use vars qw(%Application2);",
+"*Application2 =
+\\%Apache::ASP::InMemoryApplicationObject::Application2;",
$code,
'sub exit { $main::Response-End(); } ',
'1;',
@@ -4464,6 +4468,13 @@
sub connection { shift; }
+1;
+
+package Apache::ASP::InMemoryApplicationObject;
+use strict;
+use vars qw(%Application2);
+%Application2 = (
+);
1;
__END__
--
Joel W. Reed http://ruby.ddiworld.com/jreed
Daddy, why doesn't this magnet pick up this floppy disk?
