Re: development techniques

2003-01-09 Thread Andrew Wyllie
On Thu, 09 Jan 2003, Jim Martinez wrote:

> The start of a new year has me thinking of how I can improve things.  
> Like the way I develop, debug and test code.
> 
> Do you develop with an xterm tailing the logs, an emacs window (or other
> editor) to edit the script and/or the packages (and on some occassions
> httpd.conf), and a web browser (on an alternate virtual desktop)?  Do you
> pepper code with :
> 
> print "option:" . $option{$foo . "" if $debug;
print "option:" . $option{$foo} . "" if $debug;

> 
> Fairly low tech, huh.

yepi, I do that.

> At apachecon, a speaker (who neither bragged nor rambled) mentioned lwp
> use instead of (or to complement) the web browser portion.
> 
> Will the use of lwp instead of a browser improve my coding ability (either
> in terms of speed or just improving my perl coding)?  Seems like I'd have
> to spend too much time with the lwp script (tell it to first request the
> page then choose option A and B then hit the "submit" button ... )


I think the advantage of using LWP for testing is that you could write a
large series of tests which could be run frequently.  So, if you make some
little change way down in the guts of your code, you can then run all your
tests to make sure everything is still working without having to worry
about missing something along the way.  So, it may seem like a lot of
work up front, but in the long run you are better off.

There is other stuff out there that you can use for testing.  Test::Unit
come to mind, and there is a test framework I read about called puffin
(http://www.puffinhome.org/) which sounds like it could be useful.


andrew

> 
> Is there some way to improve this cycle : edit code -> refresh browser ->
> possibly look at the error log -> edit code -> ...
> 
> Or maybe you use another approach that's better?
> 
> Happy new near (9 days late),
> Big big Jim



[OT] Re: perl's memory leak

2000-12-07 Thread Andrew Wyllie

Hi Ivan,

It's not really mod_perl, but is relevant to people on the list I guess...

If you really play aorund with this, you'll find some interesting variations.
If I assign $cc using a for loop

my $c;
for ( 1..2000) { $cc .= 'a'; } 

it's a lot slower, but only uses half as much ram

also if I do the assignment first and then add a char:

my $a = $cc;   # allocates 20 more Mb for right part  
p( "assigned a" );

$a .= 'x';
p( "changed a" );

undef $a;  # deallocates $a 
p( "undefed a" );

my $b = $cc;   # allocates 20 more Mb for right part
$b .= 'a';
   # and reuses deallocated 20Mb for b
p( "defined b" );
undef $b;
p( "undefed b");


sub p {
my $mesg = shift;
  print "$mesg used memory = ".(BSD::Resource::getrusage)[2]."\n"
}

I get:

assigned a used memory = 40212
changed a used memory = 40212
undefed a used memory = 40212
defined b used memory = 40712
undefed b used memory = 40712

Which is more what you would hope to see right?


andrew


On Thu, 07 Dec 2000, Ivan E. Panchenko wrote:

> 
> 
> Today I discovered a strange behaiviour of perl, 
> and I wonder if anybody can tell me what to do with it.
> 
> The matter is that perl DOES NOT REUSE MEMORY allocated for 
> intermediate calculation results. This is specially harmful to
> data-intensive modperl applications where one perl process processes
> many queries and can leak great amount of memory.
> 
> The example is below:
> 
> use BSD::Resource; 
> my $cc = 'a' x 2000 ;# alocates 20Mb for the right part and
># 20Mb for $a
> &p;
> { my $a = $cc.'x'; # allocates 20 more Mb for right part
># and 20 for a
> &p;
>   undef $a;# deallocates $a
> }
> &p;
> { my $b = $cc.'y'; # allocates 20 more Mb for right part
># and reuses deallocated 20Mb for b 
>  &p;
>   undef $b; 
> }
> &p;
> 
> sub p { 
>   print STDERR "used memory = ".(BSD::Resource::getrusage)[2]."\n"
> }
> 
> # end of example.
> Output:
> used memory = 40772
> used memory = 79804
> used memory = 80068
> used memory = 99676
> used memory = 99700
> ##
> Here I used BSD:Resource to measure consumed memory. Its result seems to
> be correlated with the amount of memory taken by the process from the OS.
> #
> 
> This was checked on FreeBSD 3.4 and 4.2 ; and perl5.00405 5.00503 .
> Same things where noticed on Linux and probably on Solaris too.
> 
>   Ivan
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

...
Andrew  Wyllie   <[EMAIL PROTECTED]>Open Source Integrator
v.206.729.7439  __We can catify or stringify,
c.206.851.9876separately or together!__ perl-5.005_03


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




[JOB]: Seattle - perl/mod_perl programmer

2000-08-16 Thread Andrew Wyllie



Hi all,


The NewSof Group is a Seatlle based company specializing in Content
Development and building web based communities.  

We currently are looking for a Perl Programmer (~3+ yrs exp.)
comfortable with working in a UNIX environment to help us build
community/collaboration, asset managment and reporting tools.
Experience with mod_perl or an interest in learning and using
mod_perl required.  Experience with MySQL or another SQL based
database (using DBI) would also be nice.

We are a telecomuting based company, but we will require applicants
live in the Seattle area for occasional meetings at the local Tully's.

You can check out our website at http://www.newsof.com - BUT beware, it
has not been updated in quite a while.
You can see some of the work we have done for the American Cancer
Society at http://www.acscsn.org (totally mod_perl based site).


If you are interested, please forward a resume directly to
me at [EMAIL PROTECTED]



Thanks,
Andrew Wyllie




...
Andrew  Wyllie   <[EMAIL PROTECTED]>Open Source Integrator
v.206.729.7439  __We can catify or stringify,
c.206.851.9876separately or together!__ perl-5.005_03



Re: mod_perl on Cobalt servers?

2000-05-10 Thread Andrew Wyllie

Hi Bakki,


I have used mod_perl on a Cobalt Qube.  It ran ok, but I would recommend
getting a lot of memory for it.  The problems I ran into were mostly
related to the Qube not being that great of a development environment.
The Qube is great as a firewall/internet server for a small compnay, but
if you need to run 200 Virtual domains, I would recommend buying some
higher end hardware and learning how to administer it yourself.
For example, the RAQ3 has a AMD K6 200 (equiv to a pentium 200?) and
costs $1500 for a 64MB and smallish harddrive.  For $2300, I put
together a dual PIII 600 machine with 512MB RAM and 20GB disk all in a
2U case.  Shove on FreeBSD or whatever and you have a pretty sweet box.


andrew



On Wed, 10 May 2000, Bakki Kudva wrote:

> I would like to hear from anyone who has had some experience with
> mod_perl on Cobalt's Qube2(MIPS RISC) or Raq3 (x86) microservers.
> 
> * How well does this work?
> * Any differences between the Qube & Raq relative to mod_perl?
> * Any caveats?
> * How well does it work for virtual domains?
> * Does it void warranty?
> 
> The Raq3 is supposed to support 200 virtual domains but I am sure it is
> without mod_perl compiled in. What is a practical number of virt domains
> with mod_perl which can be run on this box? I have seen some blurbs
> about unsupported software (ie. anything not shipped with the box)
> voiding Cobalt warranty. Has anyone experienced problems with support
> from Cobalt on mod_perl enabled Qubes?
> 
> Thanks in advance,
> 
> bakki
> -- 
>   _ _
>  .-. |M|S|Bakki Kudva
>  |D|_|a|y|Navaco
>  |o|m|n|s|<\  420 Pasadena Drive
>  |c|e|a|t| \\ Erie, PA 16505-1037
>  |u|n|g|e|  \\http://www.navaco.com/
>  | |T|e|m|   \>   ph: 814-833-2592
> """"""""""""""""""fax:603-947-5747
> e-Docs

...
Andrew  Wyllie   <[EMAIL PROTECTED]>Open Source Integrator
v.206.729.7439  __We can catify or stringify,
c.206.851.9876separately or together!__ perl-5.005_03



Re: mod_perl weaknesses? help me build a case....

2000-04-05 Thread Andrew Wyllie

On Wed, 05 Apr 2000, Soulhuntre wrote:

> Hiya :)
> 
> > -Original Message-
> > From: Ime Smits [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 05, 2000 6:57 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: mod_perl weaknesses? help me build a case
> >
> >
> > Just because a lot of errors are openly discussed on the web (it is a
> > community built project) it it doesn't mean there are far more bugs in
> > Apache::ASP or mod_perl or Apache than in any other closed source product,
> > say IIS.
> 
> Agreed :) You know how it is when your trying to convince the guys upstairs
> to try something new :)
> 
> > I never had any problems with CPAN modules. I must say the only
> > ones I make heavy use of are the DBI and mySQL modules, which never
> crashed
> > whatsoever. I think that as long as you don't get into very experimental
> stuff, you
> > won't have any problems.
> 
> Ok, good. Like I said, most of the concerns come from the newsgroups and
> mailing list posts... we will be using DBI/mySQL and some of the XML stuff
> and a template module mostly.
> 
> > That's because Perl makes people lazy. If you code by the rules,
> > there is no problem. But it ain't a problem create memory leaking code.
> 
> That I know :) And yeah, cgi makes us lazy :) But reading through the
> caveats for mod_perl it is pretty easy to see that some of these things are
> subtle and require a hefty knowledge of perl internal stuff unless your just
> gonna "copy-n-pray" :)
> 
> > Linux/Apache::ASP I haven't experienced a segfault ever. In the beginning
> > there were some initial memory leaks, but that was my own coding proplem,
> > not a problem of perl or mod_perl or Apache.
> 
> Good to know :) Thanks!
> 
> > | 4) There does not seem to be a compatible win32/linux modperl/embedding
> > | toolkit. I can use modperl/apache/::ASP under linux, but the same setup
> > does
> > | not seem stable under win32 - and the activestate ASP perlex stuff does
> > not
> > | seem completely compatible.
> >
> > Can you give me more detail on the incompatibilities?
> 
> Well, let me turn that around, has anyone succeeded in getting mod_perl
> running well on Apache on win2k?


I have had good experiences with mod_perl/apache so far.  I do all of my
development in various UNIX environments (BSDs and Linux) and also use this
platform for my production servers.  One situation I ran into about a month
ago was the need to build a demoable version of our website that my two
CEOs could take on the road with them.  Since neither have any UNIX experience,
or maybe I should say, neither have much computer experience, I decided to
port the site onto a windows box (laptop). With the exception of Apache::Request
(which was easy to hack up a replacement--more or less) I had no problems
moving the site over - it took about a day, half of which I spent just
figuring out how to do it and getting the required software.  My configuration
is Apache with mod_perl and a MySQL database.  I should mention though that
the windows site is not a production site so I did not really pay much
attention to how well (efficiently) it is running.  All the functionality
is there which is what I was really after.

I don't use the ASP stuff so I don't know too much about that.


Hope this helps
andrew






...
Andrew  Wyllie   <[EMAIL PROTECTED]>Open Source Integrator
v.206.729.7439  __We can catify or stringify,
c.206.851.9876separately or together!__ perl-5.005_03



Re: httpd coredumps

2000-03-31 Thread Andrew Wyllie


Hi Tobias,

I ran into something like this which was being caused by a bug
in one of my scripts.  In the previous versions of Apache and
mod_perl the script just didn't work quite right, but now it
core dumped.  If you have tried this already, I would suggest
turning of all of your handlers, scripts, etc. and see what
happens.  If the server doesn't dump, start adding things back
in one at a time to see if you can nail down the problem script
or handler. 


see ya
andrew


On Fri, 31 Mar 2000, Tobias Brox wrote:

> I've installed perl 5.6.0 + Apache 1.3.12 + modperl 1.22.
> 
> An arbitrary request causes the httpd to core dump:
> 
> $ telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET / HTTP/1.0
> 
> Connection closed by foreign host.
> 
> This gets into the error log:
> [Fri Mar 31 16:23:31 2000] [notice] child pid 19804 exit signal Segmentation fault 
>(11)
> 
> pid 19804 belonged to an httpd-instance.
> 
> This happens with a clean installation, so it can't be in any of my
> scripts.  I've tried building without any other modules than mod_perl,
> and I've tried building with all the modules I want except mod_perl.
> Turning on and off the "AddModule mod_perl.c" line also affects this
> issue ... so it must be a mod_perl issue as far as I can see.
> 
> Any suggestions?  I've been fighting with this issue for several days
> now, if I can't resolve this one fairly quick I'll go for fastcgi
> instead...
> 
> -- 
> Tobias Brox (alias TobiX) - sysguy - +4722925871 - http://www.funcom.com/
> If an _urgent_ email is not acted upon within 10 minutes, you might try
> a _short_ mail to [EMAIL PROTECTED]

...
Andrew  Wyllie   <[EMAIL PROTECTED]>Open Source Integrator
v.206.729.7439  __We can catify or stringify,
c.206.851.9876separately or together!__ perl-5.005_03



Re: Perl 5.6 and mod_perl

2000-03-31 Thread Andrew Wyllie

Hi Jeff,

On Thu, 30 Mar 2000, Jeff Stuart wrote:

> Has anyone tried to use mod_perl with perl 5.6 yet?  If so, how did it go?
> Oh, are we still at 1.21 for mod_perl?  If so, when's the next release?  I
> hear that there are some important memory leak fixes in there.
> 
> --
> Jeff Stuart
> [EMAIL PROTECTED]
> 


I have Apache 1.3.12, perl 5.6.0 and mod_perl-1.22 running on a FreeBSD
box.  It all compiled wiyh no problems at all and all of my code has
continuted to work as it did previously.  One caveat though, this system
is a very fresh system, ie., I just built it last weekend so I was building
everything from scratch without and old stuff hanging around.  I ran into
one problem with DBI, something about (defined @array ) being depricated,
pretty easy to fix though.



andrew

...........
Andrew  Wyllie   <[EMAIL PROTECTED]>Open Source Integrator
v.206.729.7439  __We can catify or stringify,
c.206.851.9876separately or together!__ perl-5.005_03