Re: AW: Memory leak
On Mon, 28 May 2001, Matthias Hanns wrote: > Hi, > > I had the same prob and lowering maxrequestsperchild helped. > > Are there possibilities to clean up the used mem on end of the > mod_perl-script manually? Or have I always set maxrequestsperchild to lower > values? If it?s possible to do it by myself, what means the overhead of > creating a new apache-thread in opposite of it in the manual clean-up? http://perl.apache.org/guide/performance.html#Limiting_the_Size_of_the_Process _ 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/
Re: Real Widgets and Template Languages
> Let's focus a bit. Specifically on requirements more than implementation - *GOOD* > All I (just my opinion) really want is a widget library for is to get and > set data in a widget and have the widget subclass know how to display > itself. In addition, there should be some mechanism for specifying how the > widget sets up it's internal state based on CGI.pm, Apache::Request, > Session data or what have you. Could I paraphrase or reinterpret what you have said to be base classes for handling widget properties and data sources? In the web world I see data coming from: static widget properties - design/configuration values user supplied values - Session and Request values data sources - RDBMS, LDAP, yadda In addition I do see a variety of flavours for this data: scalar, array, hash. Me, I want even more exotic flavours such as language sensitive (The lable property check's user's language choice and will give them back the lable in the right language). In order for a widget set to be useful we have to agree on how to pass around a certain set of potentially complex data types. READ: robust base object class with potentially fancy strategy for rationalizing a number of data sources and data structures. Additionally - when it comes to widget-specific actions - such as rendering, then you're seeing this as a subclass (or group of methods) that has been defined by the widget creator. ie/ widget->render - generic method that checks container and calls appropriate render subclass for this widget since container is HTML return widget->render_HTML or whatever. READ: object hierarchy. Objects check their parents for hints on how to do things - like pick the form to render themselves, etc. > 1. Data Validation logic. No, this does not belong there. This is a > separate library. I already have a rich Data handling library in my toolkit > that I intend to plug widgets into. All I need is to be able to get widget > data from the data handling/validation library. If I place a widget into my user interface and allow a user to specify a value how I am I to implement validation? ie/ Widget has property "choice" which can be "1","2", or "3". If the user supplies any other value I want choice to be NULL and raise an error. A - does controlling application logic enforce choice validation B - does widget have property information to say that choice property must pass some validation process? I like B because it further compartmentalizes the behaviors of the widget within its own specification. The source of the valication routines can be external to the widget and classes but the validation rules would be specified within here. > 2. External display stuff. No, I just want the widget to know how to draw > itself and only itself. It's up to a template language plugin like TT or > some other template language to provide the wrappings. Or it can be a > toolkit like your drawing forms library -- but the widget itself shouldn't > have to know about external decoration around it. Just how to draw itself. If one is to create an HTML form on a web page then all of the form elements should actually be contained within in a FORM container. The FORM container can then facillitate the correct development of HTML etc. If the widgets are used within another context then the FORM container might be necessary or it might not. But it is usually easier to ignore than try to backpeddle and whack stuff in after its kinda too late. > It's possible, but I am not quite sure because the primary complexity seems > to be the data handling (which I have already in a separate abstraction) > and the UI generation which I have already in Template Toolkit. So all I > really want is an object abstract called a Widget along with a > WidgetCollection to allow grouping widgets together that belong on a given > HTML page. The way I am seeing a solution come together is somewhat different. First of all I am now tending to really really really want to work with persistant object collections. As my application needs new widgets I instanciate a new object of that class into the app's collection of objects. Then I can set its properties as I wish. From that point onwards I can just boss the widgets around and make 'em do what I want. If you do not want to work with persistent object system then you can come up with any number of tactics to define your widget objects as needed: XML, inline code, Data::Dumper, etc. A few of my thoughts, Jay
Re: Real Widgets and Template Languages
>
>I don't understand the Widget::Controller. Can you say more about this?
>
>Also will we require XML to configure? Or is this also an optional feature
>that you more or less want for yourself but others can choose to not use?
>
Hi,
Below is running code for the Perl Widget Library.
So far, there are only two widgets.
* a generic Widget::HTML::Element
* a drop-down menu Widget::HTML::Select
Are there early comments on the interface from Perl?
Is this shaping up into what was desired?
Stephen
shark:/usr/ov/acoc/dev/src/Widget/examples> more Widget.xml Widget.2
::
Widget.xml
::
::
Widget.2
::
#!/usr/local/bin/perl
use lib "..";
use Widget;
my ($wc, $widget, @widgets);
$wc = Widget->controller();
$widget = $wc->widget("first_name");
print "First Name: ", $widget->html(), "\n";
$widget = $wc->widget("last_name");
print "Last Name: ", $widget->html(), "\n";
$widget = $wc->widget("birth_dt");
print "Birth Date: ", $widget->html(), "\n";
$widget = $wc->widget("sex");
print "Sex: ", $widget->html(), "\n";
shark:/usr/ov/acoc/dev/src/Widget/examples> Widget.2
First Name:
Last Name:
Birth Date:
Sex:
Male
Female
AW: Memory leak
Hi, I had the same prob and lowering maxrequestsperchild helped. Are there possibilities to clean up the used mem on end of the mod_perl-script manually? Or have I always set maxrequestsperchild to lower values? If it?s possible to do it by myself, what means the overhead of creating a new apache-thread in opposite of it in the manual clean-up? Matthias -Ursprungliche Nachricht- Von: Ged Haywood [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 28. Mai 2001 20:08 An: Antonios Christofides Cc: [EMAIL PROTECTED] Betreff: Re: Memory leak Hi there, On Mon, 28 May 2001, Antonios Christofides wrote: > script offers database search facilities on the web. If a search is > performed which results in many (namely 400) rows being returned, then > the httpd child that serves the request grows by 2 MB. Have a child > serve that request ten times, and its size will grow from an initial 8 > MB to 28 MB. Another ten times and it will go to around 50 MB. If a row is around 5kbytes then I don't think it's a Perl/mod_perl problem, I think you're keeping your variables hanging around in memory. Don't forget that when you use mod_perl the interpreter doesn't exit, so a lot of memory cleanup which happens at exit doesn't happen under mod_perl. What happens if you set maxrequestsperchild to ten? 73, Ged.
Re: Memory leak
Hi there, On Mon, 28 May 2001, Antonios Christofides wrote: > script offers database search facilities on the web. If a search is > performed which results in many (namely 400) rows being returned, then > the httpd child that serves the request grows by 2 MB. Have a child > serve that request ten times, and its size will grow from an initial 8 > MB to 28 MB. Another ten times and it will go to around 50 MB. If a row is around 5kbytes then I don't think it's a Perl/mod_perl problem, I think you're keeping your variables hanging around in memory. Don't forget that when you use mod_perl the interpreter doesn't exit, so a lot of memory cleanup which happens at exit doesn't happen under mod_perl. What happens if you set maxrequestsperchild to ten? 73, Ged.
Re: Apache with MOD_PERL
Hi again, On Mon, 28 May 2001, Jochen Schnapka wrote: > This does not matter anything. I think it likes to have the filename immediately after the 'f'. > tar z, by the way, works only with GNUTar. Is there any other kind? :) 73, Ged.
updated Win32 binary package
Hi, An updated perl/mod_perl/mod_ssl Win32 self-extracting binary package is available at ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-0.7.exe This includes Perl-5.6.1, Apache_1.3.20, mod_perl-1.25, mod_ssl-2.8.4-1.3.20, and openssl-0.9.6a. A number of improvements and fixes are present in these versions; especially note a major security fix for Win32 Apache and also a fix for the Apache server shutdown bug which was nicely tracked down by the Apache group. A major change in this version of the binary package is that it has been compiled with the same compile-time flags that ActiveState uses. As such, it should be compatible with ActivePerl. The Perl Package Manager (ppm) utility is included for installation of binary module packages. A number of non-core modules have been bundled in this package, making it largeish - see module_list-0.7.readme for a listing. The included Apache httpd.conf contains some sample directives for some common mod_perl modules, such as Apache::Registry, HTML::Embperl, Apache::ASP, and HTML::Mason. The included readme files contain directions for installation - please let me know if you run into any problems. best regards, randy kobes
Memory leak
Hi all. I have a huge memory leak with mod_perl. I'm using a RedHat 6.2 Linux 2.2.14 system with Perl 5.00503, Apache 1.3.14, and mod_perl 1.23. Both Apache and mod_perl come from RedHat's packages, and mod_perl runs as DSO. My script uses CGI, DBI, Apache::DBI, and HTML::Template. No errors or warnings (I have 'use strict' and '-w'). Among other things, the script offers database search facilities on the web. If a search is performed which results in many (namely 400) rows being returned, then the httpd child that serves the request grows by 2 MB. Have a child serve that request ten times, and its size will grow from an initial 8 MB to 28 MB. Another ten times and it will go to around 50 MB. I understand that my script may be expensive in memory, but it should reuse the space, shouldn't it? What can I have done so wrong? Or do you think it could be mod_perl leaking (I've heard that it has a leak when DSO)?
Re: Real Widgets and Template Languages
Hi,
Development of a straw-man set of Perl Widget Library core classes is
going well. A Sourceforge project (perl-widget) is in the process of being
set up too. (I will announce when it is set up.)
The first 0.01 release will be for public comment on
the structure and concepts of the core classes.
With regard to all of the debate on closures/classes/etc., let me say that
I intend for the PWL to be useful in a variety of environments with
different people using more or less of the features.
I am favoring flexibility over performance at the moment, so full classes
are being used to access the different features of the different systems
with which it will need to interface.
At the low end, the PWL will support the simple use that Gunther requires:
simple generation of HTML of a named widget based on configuration
information.
At the high end, Jay Lawrence and I envision much more sophisticated
features ...
but let's not let the consideration of those get in the way of
accomplishing our
first task as described above.
A Template Toolkit user should be able to say
[%PERL%]
use Widget;
$stash->{wc} = Widget->controller();
[%END%]
Birth Date: [% wc.widget("birth_date") %]
or eventually something simpler like
[% USE wc = Widget %]
Birth Date: [% wc.birth_date %]
and the appropriately configured HTML will be inserted.
For non-users of Template Toolkit, they can do the comparable perl ...
use Widget;
$wc = Widget->controller();
$widget = $wc->widget("birth_dt");
print "Birth Date: ", $widget->html(), "\n";
The rendering of this widget as HTML requires at least the following
* config information (Widget::Config)
* state information (to get the current value) (Widget::CGI::State in a
CGI environment)
The state information can be accessed from *any* source by implementing an
appropriate
WidgetState class (and using some additional,
not-yet-implemented arguments
to Widget->controller()).
see below for more comments ...
At 11:10 PM 5/28/2001 +0800, Gunther Birznieks wrote:
>At 02:16 AM 5/25/01 -0400, Stephen Adkins wrote:
>...
>>I have done the Widget.pm convenience functions and factory code.
>>I am working on the Widget::Config class to read XML config data using
>>XML::Simple.
>>Then on to Widget::Base a parent class for all implemented widgets.
>>Then on to Widget::Controller which will be handed a CGI object
>>(or Apache::Request or whatever using one of the much-commented on schemes)
>>and dispatches events detected from submit buttons, etc.
>>Then I do my first actual widget, Widget::HTML::Date.
>>I'll camp on this while I get lots of feedback.
>
>I don't understand the Widget::Controller. Can you say more about this?
The Widget::Controller (or perhaps, Widget::CGI::Controller) is the
container class
that you spoke about in your original post. I call it a Controller rather
than
a Container because I envision it being able to dispatch events generated
by the
widgets.
>Also will we require XML to configure? Or is this also an optional feature
>that you more or less want for yourself but others can choose to not use?
Configuration data is read in via the Widget::Config class, and this class can
be replaced with a class which reads config data from any other source, as
long as
it conforms to the same calling interface.
I was under the impression that XML was your desired means of writing a
config file.
Do you have a preference to use something different?
>Thanks,
> Gunther
Stephen
Re: Real Widgets and Template Languages
Gunther Birznieks wrote: > The design pattern here is that driver specific stuff goes into a > constructor or config method. But leave the rest of the methods alone. This > allows you to plug and play the objects. I like that. Every time the idea of widgets (small w) comes up, my mind wanders back to UIML [1]. In a nutshell, UIML tries to define a simple markup syntax for making device/language-agnostic user interfaces. So, theoretically, you could build Web, WAP, Tk, etc. applications from the same base document. It may be worth another look in this context. I'm not suggesting, BTW, that Widget::* stuff should be based on UIML (or any other ML du jour) only that it's a bit of prior art relevant to building client/device-neutral UIs that we might be able to borrow from. -kip [1] http://www.uiml.org/specs/uiml2/index.htm -- "Perl was written first of all to let the Artist make amoral decisions." - Larry Wall
Re: Real Widgets and Template Languages
Gunther Birznieks <[EMAIL PROTECTED]> wrote: >At 02:31 AM 5/25/01 -0400, Chip Turner wrote: >>Gunther Birznieks <[EMAIL PROTECTED]> writes: >> >> > However, I think it is reasonable to make the interface to support a >> > data source for the widgets flexible and object based to make it easy >> > for someone to write a DBI source, a DBM source, an LDAP source, an >> > Apache::Session source or whatever anyone wants really. I happen to >> > think DBI and Session sources are cool. >> >>I agree; unfortunately writing classes to interface to all of these >>would be difficult, and it would be difficult to be futureproof. When >>you hit LDAP and DBI you must then worry about databases, tables, >>servers, usernames, passwords, etc. It can become cumbersome to do >>the simple things. > >I disagree. I've written interfaces like this before to LDAP and DBI. The >constructor (or config method) on a data source is stuff like usernames/ >passwords, and in the case of LDAP, schema mappings. Hmm... Something I'd like to see is a set of classes in Perl for managing LDAP. These classes would need to be generic (configurable) enough to work with any LDAP schema. They would need to provide an audit trail, transaction log, etc., that could be used to replay changes made to LDAP. They would need to be able to enforce data consistancy across branches and data integrity. If noone gets to it before I do, I'll port my PHP code to Perl :) Oh, and locking mechanisms used must be transferable between machines -- I lock resource A on machine X and then hand off the lock to machine Y -- this code must be useful in a distributed environment (web farm) and robust enough for use in a PKI. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Re: Real Widgets and Template Languages
At 02:31 AM 5/25/01 -0400, Chip Turner wrote: >Gunther Birznieks <[EMAIL PROTECTED]> writes: > > > However, I think it is reasonable to make the interface to support a > > data source for the widgets flexible and object based to make it easy > > for someone to write a DBI source, a DBM source, an LDAP source, an > > Apache::Session source or whatever anyone wants really. I happen to > > think DBI and Session sources are cool. > >I agree; unfortunately writing classes to interface to all of these >would be difficult, and it would be difficult to be futureproof. When >you hit LDAP and DBI you must then worry about databases, tables, >servers, usernames, passwords, etc. It can become cumbersome to do >the simple things. I disagree. I've written interfaces like this before to LDAP and DBI. The constructor (or config method) on a data source is stuff like usernames/ passwords, and in the case of LDAP, schema mappings. As long as the actual methods for getting and setting the data are the same, you just can get away with making the constructor for the data source the place where you define all this driver specific stuff. The design pattern here is that driver specific stuff goes into a constructor or config method. But leave the rest of the methods alone. This allows you to plug and play the objects.
Re: Real Widgets and Template Languages
At 02:16 AM 5/25/01 -0400, Stephen Adkins wrote: >Jay, > >I think that pretty much describes what I have in mind ... >plus a few other features. > >Hopefully within a week or two (based on demands of other *paying* jobs), >I will have a working distribution with most of the bare-bones plumbing in >place and a little configurable date widget implemented. > >This will allow me to solicit feedback on the plumbing and concepts >before I go hog wild on implementing a host of widgets. >(In fact, I predict the package will be downright boring for a month or more, >to those who don't want to shape its development, while I get the >concept and the internals right.) > >I have done the Widget.pm convenience functions and factory code. >I am working on the Widget::Config class to read XML config data using >XML::Simple. >Then on to Widget::Base a parent class for all implemented widgets. >Then on to Widget::Controller which will be handed a CGI object >(or Apache::Request or whatever using one of the much-commented on schemes) >and dispatches events detected from submit buttons, etc. >Then I do my first actual widget, Widget::HTML::Date. >I'll camp on this while I get lots of feedback. I don't understand the Widget::Controller. Can you say more about this? Also will we require XML to configure? Or is this also an optional feature that you more or less want for yourself but others can choose to not use? Thanks, Gunther
Re: Real Widgets and Template Languages
I think this post is quite apt. At 02:12 AM 5/25/01 -0400, Chip Turner wrote: >Gunther Birznieks <[EMAIL PROTECTED]> writes: > > > While I think that it is clever to allow an interface to change where > > the parameters come from, I think in practice there are different > > things to expect. eg how to deal with multi-values? How to deal with > > file upload field? I think there are quirks in various libraries. > >Indeed, these are open questions that aren't dealt with so easily with >a closure. But I think for a general widget set, a closure would >work. If you want to get really tricky, you can bless the >closure... but at that point, you should just be using a class in the >first place. > > > I do not think these things are insurmountable. And Chip's suggestion > > stands a good chance of working. I do also think there are so few > > libraries to deal with parameters that it would not be an unreasonable > > design decision to make the Widget controller hard code knowledge of > > CGI.pm, Apache::Request and any others since there really aren't many. > >I disagree here; Mason, Apache::ASP, embperl, straight modperl, >CGI.pm, the various CGI accelerators, etc, are a variety of >interfaces. Anytime you have an application framework (or whatever >they're called this week), you can have a different interface to even >the simplest of things like form variables. > >Another nice thing about not requiring CGI.pm or libapreq is you can >actually feed the formvars from something besides an HTTP submission >(useful for page generation into flat html, or for testing). > > > Likewise, we might consider that CGI.pm is the primary source of > > information, but if I pass a db record set to the widget controller > > along with CGI.pm, I may want CGI.pm to override the database but if > > there is no CGI.pm value, then the value from the database field will > > be placed in the widget instead. > > > > Anyway, I am sorry if this sounds quite odd. I am not good at > > explaining things when I am tired, but I did at least want to throw > > out the idea of not being married yet to a particular way of having a > > widget consume data from a data source. > >I agree that there are a lot of various issues here for when it comes >to handling data input and output. But I think that for something >like a Widget set to be useful, it needs to be as decoupled as >possible from all external libraries, and still be able to play with >them. Now, that means one of two things. > >(a) Some kind of base class (Some people suggest using an "implied" >interface without a true abstract base class that defines the various >methods; I am very much against this because it can lead to somewhat >sloppy programming. If you're going to use objects, use them in a way >that other languages tend to use them and not as typeless chunks that >respond to various kinds of black magic poking and prodding). I >personally only see this being not-the-best-option because of >unnecessary complexity for the fairly simple task at hand. If the >task were more complicated, there is no doubt this is the proper >route. > >(b) The other option, a closure, makes the simple things simple, but >the harder things a bit harder. File uploads, for instance, and >cookies. Of course, since a Widget set rarely (if ever) would need to >display the content of an upload as part of a re-rendering of the >widget, I don't see this being a common use. Likewise, cookies don't >seem as needed to be for more or less the same reason (if you're using >raw cookies to pass complex data around, you're probably doing more >work than you need to; things like Apache::Session make life easier >without forcing you to muck with cookies at every data access point). > >It gets ugly though if you -do- want cookies. Does your abstract base >class (ABT) have to be typed for every possible pair of form var >input and cookie input methods? Is there a separate interface for >each, thus complicating the API slightly? > >The more I think about it, the more wrong it seems for the Widget >library to assume anything about where its data is coming from. It >should either be from a closure or a class based on an ABT. A third >option is that all widgets are actually generated by a generator >instance of a class; this could simplify the API so that you needn't >pass the CGI object or closure around all the time. In this case, you >could derive from this base class to create new ways of gathering data >from CGI and cookies. > >This is more or less a standard design pattern -- data interfacing. >There are a number of solutions. I just hope whatever gets written is >present and future proof enough to not depend on any particular >interface (such as CGI or libapreq), or at the very least made to >easily use others. You never know when someone else may have another >templating technology that has a different interface! I think your post makes a lot of sense. How about this as a simple proposal. Widgets s
RE: Real Widgets and Template Languages [resend]
I read this post a few times.
At 03:44 PM 5/24/01 -0400, David Harris wrote:
>[[ This is a resend.. did some cutting and pasting of code into telnet
>windows that messed it up through shell expansion. My bad. ]]
>
>I have a couple modules that might be the start of what you are calling a
>Widget system. I'm not sure if my modules are in line with the thoughts
>expressed on this list. Pardon me if this is something different: I've been
>loosely following this discussion..
>
>Using my library, whenever I want a form I specify in one list all of the
>elements along with the type of data and any validation routines. Some
>information about how the form should look is also included. My code then
>automatically generates the form (it looks like a dialogue box) from this
>information. The same informational hash is used to parse the form and
>validate the data. If the data is not validated correctly, the form is shown
>again with the validation errors and the data remaining sticky. If the data
>is validated then it is returned in a hash.
I think this is reasonable and correct direction and its good that you've
functionally broken the pieces down.
But the syntax feels like you are wrapping up too many things at once.
We don't really want to define any HTML for the individual widgets. Nor
should the widgets know how to validate themselves. Nor should the widgets
know how to draw stuff around themselves like tables.
>Here is a simplified example of the widget definitions for a form that
>allows a customer to charge money on their credit card into their balance:
>
>[
> amount => { width => "20", same_line => 1,
> label => "Amount to charge (in dollars)", _label => "Amount to
>charge",
> _looks_like => "number", _required => 1, },
>
> [{ addl_require => [{
> type => "sub",
> fields => [qw(amount)],
> sub => sub {
> my ($require, $values, $labels) = @_;
> return "You may not initiate a charge for less than \$5.00."
> if ( $values->[0] < 5 );
> return "You may not initiate a charge for more than \$900.00. If
>you really do want to
> charge this much, then you need to call us and we can do it
>for you."
> if ( $values->[0] > 900 );
> return undef;
> },
> }], }],
>]
"Simplified". :)
Well, while I think this is interesting, it is too much for a widget
library. I think this is fairly clear from the examples.
Let's focus a bit.
All I (just my opinion) really want is a widget library for is to get and
set data in a widget and have the widget subclass know how to display
itself. In addition, there should be some mechanism for specifying how the
widget sets up it's internal state based on CGI.pm, Apache::Request,
Session data or what have you.
1. Data Validation logic. No, this does not belong there. This is a
separate library. I already have a rich Data handling library in my toolkit
that I intend to plug widgets into. All I need is to be able to get widget
data from the data handling/validation library.
2. External display stuff. No, I just want the widget to know how to draw
itself and only itself. It's up to a template language plugin like TT or
some other template language to provide the wrappings. Or it can be a
toolkit like your drawing forms library -- but the widget itself shouldn't
have to know about external decoration around it. Just how to draw itself.
>This above code is showing the strains of evolution of my system. :-) Notice
I don't think it is a strain on the evolution, just that you attempt to
combine many different concepts together. I think it's too much. You can
abstract away some of these things as noted above.
>This really calls for the widgets to be embedded directly in the HTML
>template which contains the formatting a la that
>Gunther proposed.
Yes, but the widgets I propose could also go into a form builder functions
like the ones you laid out as well. The widgets are supposed to be flexible
to suit any template needs not just TT.
>This above code actually sits in a subroutine that returns a list of the
>definitional information. This list is then simply included other places so
>I can write stuff like this:
>
>[
> [qq[
> Enter your billing information and credit card.
> ]],
>
> [qq[ Billing information ]],
>
> [{ default_by_name => CUST::DbAccess::Cust::default_by_name("custs") }],
>
> CUST::InterfaceUtil::opensrs_contact_fields($country_select_box, "bill",
>"Billing"),
> undef,
>
> [qq[ Credit card information ]],
>
> [{ default_by_name => CUST::DbAccess::Ccard::default_by_name("ccards") }],
>
> CUST::InterfaceUtil::credit_card_fields(),
> undef,
>]
>
>It's great for reuse.
>
>The default_by_name does something interesting: it imports all the defaults
>for the fields (_looks_like and _required and _size) information from the
>database table. If I change the size of a text field in a table all the
>forms which us
Re: Apache with MOD_PERL
On Mon, May 28, 2001 at 01:51:45PM +0100, Ged Haywood wrote: > If you say so... I'd prefer 'tar xzvf apache_1.3.20.tar.gz' etc. This does not matter anything. tar z, by the way, works only with GNUTar. Some more info would be helpful. Which script did you call and wqhat happened then etc. ~:-Jochen -- Anything is good and useful if it's made of chocolate.
Re: Apache with MOD_PERL
Hi there, I think I follow most of this! On Mon, 28 May 2001 [EMAIL PROTECTED] wrote: > $gzip -d apache_x.xx.tar.gz > $tar xfv apache_x.xx.tar > $gzip -d mod_perl-x.xx.tar.gz > $tar xfv mod_perl-x.xx.tar If you say so... I'd prefer 'tar xzvf apache_1.3.20.tar.gz' etc. > $cd mod_perl-x.xx > $perl Makefile.PL \r >APACHE_PREFIX=/usr/local/apache \r >APACHE_SRC=/usr/local/apache_x.xx/src \r >DO_HTTPD=1 \r >USE_APACI=1 \r >EVERYTHING=1 Try that again with '\' instead of '\r' > $make install Try that again as root. 73, Ged.
Apache with MOD_PERL
Hello, I will install apache_1.3.20.tar.gz and mod_perl-1.25.tar.gz on the HP-UX OS. I have installed all perl modules e.g libwww-perl-5.48.tar.gz URI MIME-Base64 HTML-Parser libnet Digest::MD5 HTML::Tagset Finally I am doing following: $gzip -d apache_x.xx.tar.gz $tar xfv apache_x.xx.tar $gzip -d mod_perl-x.xx.tar.gz $tar xfv mod_perl-x.xx.tar $cd mod_perl-x.xx $perl Makefile.PL \r APACHE_PREFIX=/usr/local/apache \r APACHE_SRC=/usr/local/apache_x.xx/src \r DO_HTTPD=1 \r USE_APACI=1 \r EVERYTHING=1 $make $make install The mod_Perl doesn' t work correct. I get only The Apache ENVIROMENT, Is that correct? AUTH_TYPE=>Basic CONTENT_LENGTH=>13 CONTENT_TYPE=>application/x-www-form-urlencoded DOCUMENT_ROOT=>/www GATEWAY_INTERFACE=>CGI/1.1 HTTP_ACCEPT=>application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* HTTP_ACCEPT_ENCODING=>gzip, deflate HTTP_ACCEPT_LANGUAGE=>de HTTP_CONNECTION=>Keep-Alive HTTP_COOKIE=>SITESERVER=ID=c656f1fb69a804a4fec64e2f5effab5c HTTP_HOST=>fu2207.zff.zf-group.de:3000 HTTP_REFERER=>http://fu2207/test.html HTTP_USER_AGENT=>Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) PATH=>/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/usr/contrib/bin:/opt/nettladm/bin:/opt/pd/bin:/usr/bin/X11:/usr/contrib/bin/X11:/opt/upgrade/bin:/opt/hpxt/enware/bin:/sbin:/usr/sbin:/opt/langtools/bin:/opt/imake/bin:/opt/aCC/bin:/opt/CC/bin:/opt/networker/bin:/opt/hparray/bin:/usr/system/bin QUERY_STRING=> REMOTE_ADDR=>197.239.33.4 REMOTE_HOST=>fn0676 REMOTE_PORT=>1879 REMOTE_USER=>f26748 REQUEST_METHOD=>POST REQUEST_URI=>/usr-mgr/test.pl SCRIPT_FILENAME=>/www/usr_manager/cgi/test.pl SCRIPT_NAME=>/usr-mgr/test.pl SERVER_ADDR=>197.239.33.6 SERVER_ADMIN=>[EMAIL PROTECTED] SERVER_NAME=>fu2207.ttt.de SERVER_PORT=>80 SERVER_PROTOCOL=>HTTP/1.1 SERVER_SIGNATURE=> Apache/1.3.20 Server at fu2207.ttt.de Port 3000 SERVER_SOFTWARE=>Apache/1.3.20 (Unix) mod_perl/1.25 TZ=>MET-1METDST Thanks a lot for you help Best Regards Hasan -- Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
