Re: [OT] Stack Operation
Jonathan M. Hollin wrote to [EMAIL PROTECTED]: Can anyone offer me some pointers (pun intended) on how to implement a stack in Perl with an array? Perl has two simple builtin functions for treating an array like a stack. See push() and pop(). Basically: my @stack; push @stack, e3; push @stack, e2; push @stack, e1; print pop(@stack); print pop(@stack); print pop(@stack); Output is: e1e2e3 I need to have an array of elements as follows: 0 - e1 1 - e2 2 - e3 ... And I need to be able to insert items: e4 needs to go into $array[1]. Does it *have* to? That would be expensive. push() and pop() keep the head element at the end of the array, so push() and pop() are each O(1) operations. By rearranging the array for every push() and pop() to keep the head at [1] (or [0]), your operations are now O(n). 1 and 2 need to move down (or up or left or right - depending on how you visualise arrays) yet retain their contents: Again, expensive. I can't think of a reason you'd need to do this for a traditional stack. Even if you're extending the idea of a stack to include other functions, you probably just need to reverse your logic to start from the last element of the array. And, you guessed it, I need to be able to remove elements, and have the others move down... pop() How do I implement this in code anyone? See above. push() and pop() are very simple functions you could write yourself in about 1 line apiece. Fortunately, you don't have to. :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] SaskNow Technologies - http://www.sasknow.com 901 1st Avenue North - Saskatoon, SK - S7K 1Y4 Tel: 306-664-3600 Fax: 306-244-7037 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
RE: [OT] Stack Operation
Tim Tompkins wrote to Ben Mathews: Honestly, I didn't see where any of those libs would assist what the poster wanted to accomplish. What's wrong with splice? For implementing a traditional stack, the splice operation (or any operation which has to rearrange the list every time an element is pushed or popped) will be much more expensive than the constant-time push() and pop(). That, and push()/pop() have the benefit of abstracting the underlying data representation. :-) The idea in any memory stack implementation is to not have to move the elements. You can abstract away from that to make more sense for a given application, but, in memory, you still want the growth end of the stack to be variable. If you don't buy any of that, unshift() and shift() instead, for the O(n) versions of push() and pop(). :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] SaskNow Technologies - http://www.sasknow.com 901 1st Avenue North - Saskatoon, SK - S7K 1Y4 Tel: 306-664-3600 Fax: 306-244-7037 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Image manipulation recommendation?
Hi all, I hope this isn't too far off topic. I'm working on a mod_perl web project in which it would be *really* quite handy if I could dynamically rasterize text over existing images. What I would ideally like is a pointer to a good Perl library that will allow me to take an existing image (gif, png, or jpg), and fairly easily render Type 1 (preferred) or Truetype fonts overtop of the image, and return the result. Caching the result would be a bonus. For this project, ease of implementation far outweighs the need for bells and whistles. I'd rather not have to learn a complex API just to throw some dynamic text on an image. :-) Thanks, - Ryan -- Ryan Thompson [EMAIL PROTECTED] SaskNow Technologies - http://www.sasknow.com 901 1st Avenue North - Saskatoon, SK - S7K 1Y4 Tel: 306-664-3600 Fax: 306-664-3630 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Invoke PHP scripts?
Hi there, Apologies if this has been asked 2^32 times, but I couldn't seem to find anything in the archives or on the web which would solve my problem. I'm developing a large-ish web site in which I would like to use a combination of mod_perl (90%) and PHP (10%). I have run into a roadblock trying to include the output of a PHP script from a mod_perl script. This would do fine: my $r = Apache-request(); return $r-lookup_uri($url)-run; But (and I am familiar with why this happens) run() dumps the results to STDOUT, so the final HTML does not come through in the correct order. I tried to use Apache::SSI in this manner: my $r = Apache-request(); my $ssi = Apache::SSI-new($contents, $r); return $ssi-get_output(); (Where $contents is the raw PHP source), but, possibly because of some Content-type mixup, the output is returned as expected (i.e., not dumped to stdout), but the PHP source is not interpreted. So, in short, I need another way to invoke a PHP script from my mod_perl application... exactly what !--#include virtual=... -- would do. Help..? :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] SaskNow Technologies - http://www.sasknow.com 901 1st Avenue North - Saskatoon, SK - S7K 1Y4 Tel: 306-664-3600 Fax: 306-664-3630 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Global configuration
Hi all, I did a brief search of the archives, and the web, but found few ideas that address this issue... which seems odd, because this is a very common problem with typical mod_perl applications. What I have is a large distributed mod_perl application, with many packages strewn throughout a hierarchy of classes on the filesystem of a server. This application code is either replicated to different servers, or shared over a read-only NFS partition. Each server needs to be able to set a small number of constant global options at compile time, which should be stored in a configuration file on the local filesystem. So, is there an accepted, right way to suck in a local configuration file at compile time? And, what's the best way to scope these globals so that they are visible to the classes and subclasses in the system that need to read them? I want to keep coupling to a minimum, as there is a lot of reused and reusable code. Again, these values can and should be considered immutable during execution. RTFM answers gratefully accepted :-) Thanks! - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: Fast template system. Ideas,theorys and tools
Jason Czerak wrote to [EMAIL PROTECTED]:
In fact, if I use this cache system and disable all parsing (i.e.,
just use it to include straight HTML into mod_perl apps), I can serve
150-200 requests/second on the same system.
With my parsing regexps enabled, it drops to 50-60 requests/second.
First. I would love to know what kinda machine your using here. :)
It's part of a testing environment. Nothing fancy... Lightly loaded
single CPU PII-400MHz, 512MB RAM, Adaptec Ultra160 SCSI (no RAID),
FreeBSD 4.4-RELEASE, with some in-house kernel patches applied, latest
MySQL, mod_perl, modules.. It's great for testing, because when we
move things to the REAL server (more power, more load), I know they'll
be at least as fast over there and won't crack under pressure :-)
The database this runs off of has several tables. The smallest has
about 15K rows. The largest is pushing 300K rows.
3rd. my sql queries are not the most optimized and mostly tossed
together. But then again my developemnt tables are not that big at
all.
This might be one of your largest areas to improve upon. Thanks to
practical and theoretical experience with RDBMS', I write fairly well
optimized SQL when I throw things together, but I recently rewrote a
JOIN in one of my applications that was fast enough and doubled the
observed performance (oops.. should have noticed that the first time).
Check your table design and indexing, too, as these are areas which
are tremendously important, that many people overlook.
Even a development table that is not that big might be a few
thousand rows. If your query is poorly designed, and your DBMS has to
read every row in the table, you're going to take a noticeable hit
over a number of queries. Worse yet, if, for example, you're taking
the cartesian product by mistake (this is easy enough to do), pretty
quickly you've got hundreds of thousands of rows to deal with. :-)
I guess what I'm saying is, never underestimate the importance of
carefully constructed SQL.
Keep in mind that my times are based also on the time it takes to
make the transmission of the data from server to client as well as
the time it takes to compile the template and do sql queries. Im
not sure if your times are factoring that in. Locally times are
.08/sec but remotely from T1 to cable times are .16/sec to .20/sec
depending on network conditions and size of html file at the time
naturally. Some of the html files can be about 50K in size we
found.
Generally when testing application performance, it is wise to
eliminate highly variable things like network performance. Network
importance might be significant in your application deployment, but
you can test that in isolation with the many great network tools out
there.
Also, pages will do about 3 sql queries on average plus queries to
the Apache::Session state information.
Take advantage of query caching... Instead of
$cursor = $dbh-prepare('SELECT * FROM yourtable WHERE foo = bar');
use
$cursor = $dbh-prepare('SELECT * FROM yourtable WHERE foo = ?');
$cursor-bind_param(1,bar);
This way, your SQL database will cache the queries so that they do not
have to be parsed and examined each time. Note that this does NOT
cache the results of the queries. You can do that, as well, but can
lead to nasty surprises.
Also, try to limit the total number of SQL queries you make per
request. Take advantage of joins, group by, etc, if you can.
Do these numbers sound right? There are places were I could move
from doing SQL to keeping some data in Apache::Session. but it
would be small speed improments unless the catagories are very
deep, I do have recursive SQL queries inplace for some things.
Your talking 50 to 60/sec as slow. So I dunno what is 'fast'.
I optimized a few things wrt. the parsing and am now seeing
110-115/sec pretty consistently. IIRC, this server won't handle much
more than that without SQL.
- Ryan
--
Ryan Thompson [EMAIL PROTECTED]
Network Administrator, Accounts
SaskNow Technologies - http://www.sasknow.com
#106-380 3120 8th St E - Saskatoon, SK - S7H 0W2
Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon
Toll-Free: 877-727-5669 (877-SASKNOW) North America
Fast template system
Hey everybody, Some time ago, I coded an HTML template engine that runs under mod_perl that allows a mod_perl application to parse variables, simple conditionals, and nested include files in an HTML file read from disk (or from my module's very quick memory cache). Trouble is, all the regexps I'm using to substitute variables, handle conditionals, etc, are extremely slow. (In fact, they are the bottleneck in several applications that do other expensive things like SQL queries on large tables). I have done some work to optimize the regexps, but my stuff is still only able to handle about 50-60 requests per second. (Without my template module, the same scripts can achieve 120-130 r/s on the same machine, making the same SQL queries). There must be a faster way. I have thought about pre-compiling each HTML file into a Perl module, but there would have to be an automated (and secure) way to suck these in if the original file changes. Either that, or maybe someone has written a better parser. My code looks something like this, to give you an idea of what I need: pMy name is: !-- name --/p !--#ifdef age -- pMy age is: !-- age --/p !--#endif -- To keep things simple and relatively efficient, I don't allow nested IFs. I've used HTML comments so that WYSIWYG editors or HTML validators don't complain. I've looked at some other template systems, and haven't really found much that interests me. Maybe someone can spark my interest again. Any thoughts? - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: Fast template system
Dave Hodgkinson wrote to Ryan Thompson: Ryan Thompson [EMAIL PROTECTED] writes: Any thoughts? You really have to ask?!!! Yes!! :-) I've tried or at least taken a critical look at most of the template systems out there, and they are either far too simple (i.e., variable expansion only), far too complex, or use constructs/syntax that break HTML validation. * _Dave thinks: Template Toolit. I've looked at TT (and have heard it's praises sung), but it requires Perl 5.6.0, which is, unfortunately, not yet stable on all of the production systems my projects are deployed on. The syntax and features look about right, though... So it is something I might try when 5.6.0 is more widely deployed. So far, the only complaint about my system is that it is slower than it needs to be. It works under 5.005, can be installed ANYWHERE, caches content, doesn't break HTML validation, is proven to be easy for non-programmers to use, and has been through about three years of careful development and production testing. So, I'm willing to try something different.. but this is not a decision I take lightly. :-) Thanks, - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: Fast template system
Kenny Gatdula wrote to Ryan Thompson and [EMAIL PROTECTED]: At 02:18 PM 12/30/2001 -0600, Ryan Thompson wrote: Any thoughts? Have a look at this document that compares most of the template engines out there. http://perl.apache.org/features/tmpl-cmp.html Thanks, I wasn't aware of that page. I think you'll have an easy time converting your homegrown templates over to Template Toolkit, and, since it's fast, it should meet your needs. here's your example using tt's syntax. pMy name is: [% name %]/p [% IF age %] [...] Yeah, TT is good, all right, especially with the ability to change the start and end tags to something more compliant, like !-- and --. I'd gladly switch, if someone knows how to get it working on FreeBSD -STABLE without breaking everything else :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: Fast template system
[EMAIL PROTECTED] wrote to Ryan Thompson: Ryan Thompson wrote: Yeah, TT is good, all right, especially with the ability to change the start and end tags to something more compliant, like !-- and --. I'd gladly switch, if someone knows how to get it working on FreeBSD -STABLE without breaking everything else :-) Update your ports tree. Version 2.06 (the latest) is there and it works with the Perl in FreeBSD 4.4 OK... Thanks. Looks like that was committed on Dec 3. The last time I tried to build TT was a few days prior to that, at the time when it was still apparently forbidden. Once I saw it was dependent on 5.6.0, I was not optimistic that a future update to the port would bring in 5.005_03 compatibility. - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Template-Toolkit performance tuning
Hello again,
Thanks for all the good replies on the template issue. I had forgotten
how much of a powder-keg that subject was... lucky nobody lit a match
:-)
Anyways, I've re-written one of my modules using TT to try it out, but
I am less than satisfied with the performance... To the point where I
think I may have missed an important step. Here's the details:
The template I'm testing uses about 10
[% IF variable %]Do something with $variable[% END %]
type of blocks. Nothing horribly complex.
With my previous template system, with the same logic, I could serve
on the order of 50 requests per second on the same system. Doing a
straight conversion, I'm seeing only 7.5 requests per second under TT
for the same content. Ugh! Help!
Here's a snipped of what I've done:
use Template;
my %vars;
$var{foo} = bar; # About 30 scalars like this
.
.
my $tt = new Template({INTERPOLATE = 1});
$tt-process($file, \%vars);
Everything displays fine, and no errors/warnings show up... It's just
horribly slow. At ~150ms per request, the delay is noticeable on our
local LAN.
Without delving deeper than I already have into the documentation, I
suspect that the template files are not being cached, resulting in a
disk hit on every request. Not good! There must be a way around this.
Any thoughts?
Thanks,
- Ryan
--
Ryan Thompson [EMAIL PROTECTED]
Network Administrator, Accounts
SaskNow Technologies - http://www.sasknow.com
#106-380 3120 8th St E - Saskatoon, SK - S7H 0W2
Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon
Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: Fast template system
Mark Maunder wrote to Ryan Thompson: Ryan Thompson wrote: There must be a faster way. I have thought about pre-compiling each HTML file into a Perl module, but there would have to be an automated (and secure) way to suck these in if the original file changes. Either that, or maybe someone has written a better parser. My code looks something like this, to give you an idea of what I need: Sure there are tons of good template systems out there. I think someone made a comment about writing a template system being a right of passage as a perl developer. But it's also more fun to do it yourself. :-) I guess you've tried compiling your regex with the o modifier? Yep, problem is there are several of them. I've done some work recently to simplify things, which might have a positive effect. Also, have you tried caching your HTML in global package variables instead of shared memory? I think it may be a bit faster than shared memory segments like Apache::Cache uses. (The first request for each child will be slower, but after they've each served once, they'll all be fast). Does your engine stat (access) the html file on disk for each request? You mentioned you're caching, but perhaps you're checking for changes to the file. Try to stat as My caching algorithm uses 2 levels: When an HTML file is requested, the instance of my template class checks in its memory cache. If it finds it there, great... everything is done within that server process. If it's not in the memory cache, it checks in a central MySQL cache database on the local machine. These requests are on the order of a few ms, thanks to an optimized query and Apache::DBI. NOT a big deal. If it's not in either cache, it takes it's lumps and goes to disk. In each cache, I use a TTL. (time() + $TTL), which is configurable, and usually set to something like 5 minutes in production, or 60 seconds during development/bug fixes. (And, for this kind of data, 5 minutes is pretty granular, as templates don't change very often.. but setting it any higher would, on average, have only a negligible improvement in performance at the risk of annoying developers :-). And, with debugging in my template module turned on, it has been observed that cache misses are VERY infrequent ( 0.1% of all requests). In fact, if I use this cache system and disable all parsing (i.e., just use it to include straight HTML into mod_perl apps), I can serve 150-200 requests/second on the same system. With my parsing regexps enabled, it drops to 50-60 requests/second. So, to me, it is clear where performance needs to be improved. :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
DBD::mysql and libmysqlclient.so.10
Hi everybody, I hope I'm asking this on the right forum... But this question involves several different packages :-) On a FreeBSD 4.4 system, I am trying to use DBD::mysql (in my library, I have use Mysql) with mod_perl 1.26. However, when running under mod_perl (and ONLY when running under mod_perl, it seems), I receive the following error (lines wrapped, here) in my apache log, and the execution fails: Can't load '/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/DBD/mysql/mysql.so' for module DBD::mysql: Shared object libmysqlclient.so.10 not found at /usr/libdata/perl/5.00503/Dynaloader.pm line 169. libmysqlclient.so.10 DOES exist, and has been successfully configured with ldconfig. And, scripts NOT running under mod_perl can use Mysql without a problem. I expect this may be a FAQ, and I swear I've run across this before, but haven't had any luck grepping my notes. Help? :-) Thanks, - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: DBD::mysql and libmysqlclient.so.10
Ged Haywood wrote to Ryan Thompson: Hi there, On Thu, 29 Nov 2001, Ryan Thompson wrote: Can't load '/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/DBD/mysql/mysql.so' for module DBD::mysql: Shared object libmysqlclient.so.10 not found at /usr/libdata/perl/5.00503/Dynaloader.pm line 169. libmysqlclient.so.10 DOES exist, [snip] Just a shot in the dark... Are you getting any core dumps/segfaults? Nope. Nothing is dumping core. In fact, the ONLY error reported in the Apache logs is the one quoted, above. (Then, of course, there are several other errors as it goes up the call stack to my script itself, where it dies, and I get a 500 error in the browser). If the httpd process dumped core this early, I would expect to see Document contained no data. Thanks, - Ryan If you check the Dynaloader docs I think you'll find that this message sometimes appears if the code called by it fails. You might be better asking at a DBI list. 73, Ged. -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
RE: :mysql and libmysqlclient.so.10
William Rusch wrote to Ryan Thompson and [EMAIL PROTECTED]: Ryan Thompson wrote: Can't load '/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/DBD/mysql/mysql.so' for module DBD::mysql: Shared object libmysqlclient.so.10 not found at /usr/libdata/perl/5.00503/Dynaloader.pm line 169. libmysqlclient.so.10 DOES exist, and has been successfully configured with ldconfig. And, scripts NOT running under mod_perl can use Mysql without a problem. Usually when I see an error like this i suspect the ld_library_path needs to be set to include the missing dynamic library. Try setting it to include your mysql/lib folder if this could be the problem. Just to clarify... this library IS configured with ldconfig... so, unless I'm mistaken (which is quite possible :-), wouldn't setting LD_LIBRARY_PATH be unnecessary? If I'm wrong, where is the best place to set LD_LIBRARY_PATH? # ldconfig -r | grep mysql search directories: /usr/lib:/usr/lib/compat:/usr/local/lib: /usr/local/lib/mysql 69:-lmysqlclient.10 = /usr/local/lib/mysql/libmysqlclient.so.10 libmysqlclient.so.10 exists in the above location, has all appropriate permissions, no write bits set on it, or the parent directory, and it WORKS with the mysql client utilities (or do they link it statically?). The same scripts ALSO work in plain CGI directories not using mod_perl, which is one of the main reasons I'm asking on this list ;-) Thanks, - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
RE: :mysql and libmysqlclient.so.10
William Rusch wrote to Ryan Thompson:
I use oracle and with DBI I had a similiar problem. although I
could run all the oracle client software without having to set
this variable i had to set it when i connected through dbi,however
this happened with standard cgi's as well.
I usually set it in my connection subroutine ie..
$ENV{'LD_LIBRARY_PATH'} = '/path to library';
$dbh = DBI-connect(..);
I use true64 and linux so I'm not even positive that the
LD_LIBRARY_PATH is the right environment variable for freebsd. But
if it is, it's worth trying.
maybe the ld_library_path got altered on the mod_perl
compilation wouldn't really have a clue beyond that.
Hi William (and everyone else who has replied),
Thanks for the replies. I have tried all of the suggestions that you
and others have recommended (including some ideas of my own). So far,
I'm still stuck at the same place I was when this all started
yesterday ;-)
Here is what I have tried so far, to sum things up:
Running ldconfig -R to make sure libmysqlclient.so.10 is in the list
$ENV{'LD_LIBRARY_PATH'} = '/usr/local/lib/mysql', or
$ENV{'LD_LIBRARY_PATH'} = '/usr/local/lib/mysql/'
PerlSetEnv LD_LIBRARY_PATH /usr/local/lib/mysql
Checked library locations, file permissions, configuration, etc from a
working installation on FreeBSD 3.5 with mod_perl 1.25. (No
differences found, except the FreeBSD 3.5 box uses an older version of
libmysqlclient.so).
And then full restart Apache (apachectl stop apachectl start) after
trying each one of these.
I HAVEN'T yet striven to recompile mod_perl, but I suspect that may be
where I am headed next. mod_perl is compiled as a DSO, with APXS.
- Ryan
--
Ryan Thompson [EMAIL PROTECTED]
Network Administrator, Accounts
SaskNow Technologies - http://www.sasknow.com
#106-380 3120 8th St E - Saskatoon, SK - S7H 0W2
Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon
Toll-Free: 877-727-5669 (877-SASKNOW) North America
SOLVED: DBD::mysql and libmysqlclient.so.10
Ryan Thompson wrote to William Rusch: I HAVEN'T yet striven to recompile mod_perl, but I suspect that may be where I am headed next. mod_perl is compiled as a DSO, with APXS. OK, I figured it out myself this time. :-) I had tried to re-make mod_perl, which itself didn't solve the problem. What happened, however, was I messed up the order of the dependencies. I had installed Mysql prior to installing mod_perl, which, apparently, was the wrong thing to do. I deinstalled Mysql (thanks to the FreeBSD ports collection ;-) and then did make reinstall, which apparently knocked things back to where they should be, with mod_perl. Strange, but true! ;-) Thanks for the help, - Ryan -- Ryan Thompson [EMAIL PROTECTED] Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
