Re: Commercial app demo

2000-02-11 Thread Gidon Wise

I must confess that I wrote a buggy but small script that makes perl 
code unreadable. I promise. It basically removes comments, excess white space, and 
changes all the
identifiers to weird names. It was during a 
silly moment and I'm not proud. But, if you can get it to be any uglier, 
we can use it to generate secret codes in perl :). I'd suggest moving 
all the strings to the front and doing some random reversible operations 
as a final bit of ugliness.

http://www.gidon.com/scratch/

Matt Sergeant wrote:
 
 On Thu, 10 Feb 2000, Fabrice Scemama wrote:
  There's another way. We can't build pre-compiled modules easily,
  but even when you code in C or Java, desassemblers can extract
  some source from the binaries you deliver. As far as perl scripts are
  concerned, a workaround consists in trivially removing all comments
  and \n from the source, which makes it as hard to understand as
  raw C desassembled code.
 
 Maybe the way _you_ write code :)
 
 --
 Matt/
 
 Details: FastNet Software Ltd - XML, Perl, Databases.
 Tagline: High Performance Web Solutions
 Web Sites: http://come.to/fastnet http://sergeant.org
 Available for Consultancy, Contracts and Training.



Re: Getting/storing big text

1999-12-13 Thread Gidon Wise

[EMAIL PROTECTED] wrote:
 
 Hi,
 
 Can folks please tell me what's the best way to pass large-ish amounts of
 data between invocations of a CGI script. 
If you have HUGE amounts of data which is way more than 3K,
then See CGI.pm and multipart/form-data.
For a big form, just make sure you use method=POST in the HTML.



Re: mod_perl Programmers demand is going up...

1999-12-03 Thread Gidon Wise

Hello Everybody,

I believe it is true. We could have more more mod_perl programmers.
I think that the biggest problem/opportunity that mod_perl has in terms
of proliferation amongst programmers/users is that Hosts currently
do not provide mod_perl on cheap virtual server package. 

I think a whole lot of perl programmers and non perl programmers
would move to mod_perl if the service was provided.

Currently in The Guide it discusses 3 possibilities for Hosts.
http://perl.apache.org/guide/multiuser.html#ISPs_providing_mod_perl_services

Are there any other ways that we can suggest to hosts
which are easier for all involved? I am not that experienced with mod_perl
so I cannot propose a robust solution. But I do believe there must be one.

Even a limited/special version or configuration of mod_perl would do.

Why is just offering PerlRun, or something like it, not an option?
I don't know PerlRun, but doesn't that clean things up a bit?

The PHP people managed to get into the Virtual server space
and I think it has been a great boost for the Hosts and the low
budget Customers. But there are a lot of perl programmers and 
perl programs out there that could use the boost as well. And even
programmers who have the resources, when they choose which language 
to use, sometimes have to consider that instances of their programs 
will be used by people without the resources to have mod_perl.

A limited mod_perl that Hosts can use and advertise
could help mod_perl and a whole lot of perl programmers
to use Perl on the smaller, acorn-like, projects.
It would also encourage new programmers to use perl
as they toy on their first projects.

In anycase, thanks for listening to my pep talk, and good morning!


Stas Bekman wrote:
 
 Hi, folks
 
 You wouldn't beleive but I receive a great deal of mod_perl job offers.
 Here is a partial quote of the most generic content of the offer:
 
   At any rate, we're finding it very hard to find mod_perl people and I
   thought maybe you could refer me to someone you know. I can tell you
   more about the client and the positions if you're interested.
 
 Which makes me thinking that we are too few and the demand is growing
 (which is good for us :), but from the other side it's bad for mod_perl,
 as when a project staff understands the power of mod_perl and want to use
 it but have no experience with mod_perl and can hire none of mod_perl
 programmers, there is no other choice left as to use some other probably
 worse technology because they could dig up the required man power that has
 the required knowledge in the other field.
 
 Now the question is: if this is truth and you feel the same way, how do we
 make the world know that there is a great demand for mod_perl programmers
 and that people should learn mod_perl and not the stright-forward choice
 like VB, ASP or other technology that drives the web?
 
 Ideas?
 
 ___
 Stas Bekman  mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas
 Perl,CGI,Apache,Linux,Web,Java,PC at  www.singlesheaven.com/stas/TULARC
 www.apache.org   www.perl.com  == www.modperl.com  ||  perl.apache.org
 single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com



Re: Image::Magick and mod_perl

1999-11-20 Thread Gidon Wise

 If each transaction lasts a
 couple of seconds, it this a Bad Thing?   
 
I have always wondered about the point of using Mod_Perl vs Mod_CGI
where the program takes a couple of seconds to run completely. 
To put it another way. Mod_Perl saves you some valuable time
which can make a difference if you have normal CGI programs
which run in the milliseconds. But who cares about a couple of 100 millis
if your program needs a couple of 1000 millis to complete?

It seems to me that it is probably better to just use a light weight
apache which is more parallel and easier for such applications.

My questions is how slow in seconds can a CGI be, before it is too
slow for Mod_Perl to help?  

This whole line of reasoning assumes that:
1) The CGI cannot be sped up by caching or leaving stuff resident in memory.
2) The CGI doesn't take seconds to load itself in memory in addition to its
   seconds of time that it takes to run.