[22932] in Perl-Users-Digest
Perl-Users Digest, Issue: 5152 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jun 29 11:05:43 2003
Date: Sun, 29 Jun 2003 08:05:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 29 Jun 2003 Volume: 10 Number: 5152
Today's topics:
Re: BTree examples ?? (Kenjis Kaan)
directory access problem (stegger)
Fast CGI Vs Java Application Servers <chppxf1@NOSPAM_yahoo.com.au>
Re: Fast CGI Vs Java Application Servers (Alan Gauld)
Re: Fast CGI Vs Java Application Servers (David N. Welton)
Re: Fast CGI Vs Java Application Servers <irmen@-NOSPAM-REMOVETHIS-xs4all.nl>
Re: Fast CGI Vs Java Application Servers (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=)
Re: Fast CGI Vs Java Application Servers <irmen@-NOSPAM-REMOVETHIS-xs4all.nl>
Re: Fast CGI Vs Java Application Servers <kennykb@acm.org>
Re: Fast CGI Vs Java Application Servers <amk@amk.ca>
Re: Fast CGI Vs Java Application Servers (Cameron Laird)
Re: Fast CGI Vs Java Application Servers (Ng Pheng Siong)
Re: Perl -e `"dir a*.txt"` (Joe Smith)
Re: Perl 5.6 and Perl 5.8 (Joe Smith)
Perl keeps me from throwing up while programming java (Bryan Castillo)
perl\site\lib\auto\... (DLLs, LIB, EXP etc) to anothe (Kenjis Kaan)
Re: perl\site\lib\auto\... (DLLs, LIB, EXP etc) to an <randy@theoryx5.uwinnipeg.ca>
Re: Testing perlfuncs (getopt) for true/false. (yeah i' (Tad McClellan)
Re: URL checking <flavell@mail.cern.ch>
Re: Yet another "undefined reference to `_WinMain@16'" (Sam Denton)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 28 Jun 2003 23:50:43 -0700
From: tivolinewbie@canada.com (Kenjis Kaan)
Subject: Re: BTree examples ??
Message-Id: <6a8ba9f8.0306282250.6b78a4f8@posting.google.com>
There has go to be a way to use BTree.pm (its floating around the
internet) without resorting to the fancy DB_File with all the bells
and whistles. All I want is just ot create a simple file containing
BTree objects so I can then search and replace records at will. I
think DB_File is an overkill unless I can put everything in the
development directory which becomes part of the install package. I
notice the only thing BTree.pm is missing is the delete operation.
Which is really weird, I remember studying this stuffs back in school,
and the books shows you some code with insert etc, but the delete is
left as an exercise. Its beyond me that some guy would write the
BTree.pm but left out the delete operations. I know its a bit harder
to implement, but if you are going to do it, might as well make it
complete so people can use it.
"Paul Marquess" <paul.marquess@btinternet.com> wrote in message news:<3efc67a3$0$18488$ed9e5944@reading.news.pipex.net>...
> "Kenjis Kaan" <tivolinewbie@canada.com> wrote in message
> news:6a8ba9f8.0306270501.1b436eb0@posting.google.com...
> > Hello. I am wondering if anyone has an example of using BTree for
> > storing data on a disk file.?? I found some BTree modules on the
> > web, but none give example of how you would then store it and retrieve
> > it from disk drive. I have a need to store hundred of thousands of
> > key, data values but told not to use a RDBMS. It would be nice if I
> > can get some sample of that actually shows the write to disk and
> > subsequent retrieval from it, which then allows you to do search for
> > records by supplying a key. TIA
>
> The DB_File module, that comes with Perl, has a btree opion. You can easily
> store hundres of thousands of key/data pairs in it.
>
> The example below is derived from the docuemntation that comes with DB_File
>
> use warnings ;
> use strict ;
> use DB_File ;
>
> my %h ;
> tie %h, "DB_File", "tree", O_RDWR|O_CREAT, 0666, $DB_BTREE
> or die "Cannot open file 'tree': $!\n" ;
>
> # Add a key/value pair to the file
> $h{'Wall'} = 'Larry' ;
> $h{'Smith'} = 'John' ;
> $h{'mouse'} = 'mickey' ;
> $h{'duck'} = 'donald' ;
>
> # Delete
> delete $h{"duck"} ;
>
> # Cycle through the keys printing them in order.
> # Note it is not necessary to sort the keys as
> # the btree will have kept them in order automatically.
> foreach (keys %h)
> { print "$_\n" }
>
> untie %h ;
>
> Paul
------------------------------
Date: 29 Jun 2003 07:43:56 -0700
From: iaegger@hta.fhz.ch (stegger)
Subject: directory access problem
Message-Id: <f4c61bfa.0306290643.284ed387@posting.google.com>
I am a perl newbie and should solve a script problem.
I have defined a directory in the smbldap_conf.pm file similar to the
following line:
$mk_ntpasswd = "/usr/local/sbin/mkntpwd";
Then in the smbldap-passwd.pl the line below generates an unexpected
output and the script behaves not like expected
Perl line which gerates the error:
my $ntpwd = `$mk_ntpasswd '$pass'`;
The error (or output)
sh: /usr/local/sbin/mkntpwd: is a directory
Thanks for any suggestions
--
Stefan
------------------------------
Date: Sun, 29 Jun 2003 17:01:07 +0800
From: Charles Handy <chppxf1@NOSPAM_yahoo.com.au>
Subject: Fast CGI Vs Java Application Servers
Message-Id: <kAxLa.592$_I3.34571@nnrp1.ozemail.com.au>
How does FastCGI compare against java Apps running in java app servers
like TomCat, Sun One, WebLogic and WebSphere? Is there a business case
for switching from CGI to Java? Performance? Productivity? Features?
Object orientation? Code Reuse?
Any opinions?
------------------------------
Date: Sun, 29 Jun 2003 09:37:55 GMT
From: alan.gauld@btinternet.com (Alan Gauld)
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <3efeb1fc.573830905@news.blueyonder.co.uk>
On Sun, 29 Jun 2003 17:01:07 +0800, Charles Handy
<chppxf1@NOSPAM_yahoo.com.au> wrote:
> How does FastCGI compare against java Apps running in java app servers
> like TomCat, Sun One, WebLogic and WebSphere?
That depends on how your CGI apps are written. If its in QBASIC
running on apache on an NT box then probably the websphere
solution would be faster. If its Perl or Python then you might
not see much difference. If its C/C++ you might even find the CGI
route faster.
> Is there a business case for switching from CGI to Java?
You can make a business case for just about anything if you
try...
> Performance?
See above
> Productivity?
Perl/Python CGI will almoist certainy develop faster than Java.
C++ is about the same IME
> Features?
Maybe, Java's built in networking/security features are a big
plus, maybe the biggest plus.
> Object orientation?
Nope, you can do that in Perl and certainly in Python (or Ruby).
> Code Reuse?
Nope, that's much more about project organisation than
programming language.
> Any opinions?
Lots but I'm trying to stay objective! :-)
Bottom line is: Does what you do now work for you? If so, don't
fix what's not broken...
Alan G.
------------------------------
Date: Sun, 29 Jun 2003 10:37:39 GMT
From: davidw@dedasys.com (David N. Welton)
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <874r29rwvu.fsf@dedasys.com>
alan.gauld@btinternet.com (Alan Gauld) writes:
> > Is there a business case for switching from CGI to Java?
As someone said, "java is great for engineering next generation
solutions to enable maximization of developer income by means of
enhanced buzzword use".
> > Features?
> Maybe, Java's built in networking/security features are a big plus,
> maybe the biggest plus.
For most of the other answers, Tcl scores about where Perl and Python
do, give or take some here and there. Here, it is worth mentioning
that Tcl has a very nice security architecture of its own, that you
can control from Tcl itself quite easily.
> > Object orientation?
> Nope, you can do that in Perl and certainly in Python (or Ruby).
Or Tcl with an extension like [Incr Tcl].
> Bottom line is: Does what you do now work for you? If so, don't fix
> what's not broken...
Excellent suggestion.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
------------------------------
Date: Sun, 29 Jun 2003 12:44:26 +0200
From: Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl>
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <3efec309$0$49100$e4fe514c@news.xs4all.nl>
Charles Handy wrote:
>
> How does FastCGI compare against java Apps running in java app servers
> like TomCat, Sun One, WebLogic and WebSphere?
A (fast)CGI program compared to the actual Java program may not be
much of a difference, depending on the program of course. What is
a *huge* difference is that the Java app is running inside an
*application server*. A (J2EE) Application Server provides a
rich environment on which to base your scalable enterprise applications:
- security
- connectivity
- scalability (performance, clustering)
- maintainability / managability
- error reporting/logging
- component based (EJBs)
- database connectivity and object persistence
- transactions
- ...
All of these are standardized in some way (as part of J2EE).
In theory you can move your J2EE application to a different
environment running on a different vendor's app server without
much sweat.
You don't have any of this readily available when writing (fast)CGI
applications; you have to implement all of these yourself.
--Irmen de Jong
------------------------------
Date: 29 Jun 2003 13:14:13 +0200
From: mru@users.sourceforge.net (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=)
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <yw1xn0g116gq.fsf@fruxo.e.kth.se>
Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes:
> > How does FastCGI compare against java Apps running in java app
> > servers like TomCat, Sun One, WebLogic and WebSphere?
>
>
> A (fast)CGI program compared to the actual Java program may not be
> much of a difference, depending on the program of course. What is
> a *huge* difference is that the Java app is running inside an
> *application server*. A (J2EE) Application Server provides a
> rich environment on which to base your scalable enterprise applications:
> - security
> - connectivity
> - scalability (performance, clustering)
> - maintainability / managability
> - error reporting/logging
> - component based (EJBs)
> - database connectivity and object persistence
> - transactions
> - ...
Someone mentioned buzzwords elsewhere in this thread.
> All of these are standardized in some way (as part of J2EE).
> In theory you can move your J2EE application to a different
> environment running on a different vendor's app server without
> much sweat.
That is, after you spent three weeks trying to figure out the correct
classpath, if one even exists.
> You don't have any of this readily available when writing (fast)CGI
> applications; you have to implement all of these yourself.
Hey, it could be fun.
--
Måns Rullgård
mru@users.sf.net
------------------------------
Date: Sun, 29 Jun 2003 13:58:40 +0200
From: Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl>
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <3efed46f$0$49115$e4fe514c@news.xs4all.nl>
Måns Rullgård wrote:
> Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes:
>
>
>>>How does FastCGI compare against java Apps running in java app
>>>servers like TomCat, Sun One, WebLogic and WebSphere?
>>
>>
>>A (fast)CGI program compared to the actual Java program may not be
>>much of a difference, depending on the program of course. What is
>>a *huge* difference is that the Java app is running inside an
>>*application server*. A (J2EE) Application Server provides a
>>rich environment on which to base your scalable enterprise applications:
>>- security
>>- connectivity
>>- scalability (performance, clustering)
>>- maintainability / managability
>>- error reporting/logging
>>- component based (EJBs)
>>- database connectivity and object persistence
>>- transactions
>>- ...
>
>
> Someone mentioned buzzwords elsewhere in this thread.
Very true ;-)
But the fact remains, that you get the above mentioned things
in one way or another when using an application server.
Wether you *need* them is a totally different matter.
As somebody else pointed out, if what you do now works for you,
don't fix what's not broken...
>>All of these are standardized in some way (as part of J2EE).
>>In theory you can move your J2EE application to a different
>>environment running on a different vendor's app server without
>>much sweat.
>
>
> That is, after you spent three weeks trying to figure out the correct
> classpath, if one even exists.
That's why I said "in theory".
Classpath issues are the least of your problems.
(and really should not take you more than an hour to figure out).
>>You don't have any of this readily available when writing (fast)CGI
>>applications; you have to implement all of these yourself.
>
>
> Hey, it could be fun.
I cannot imagine how it can be fun to design, build and test your
own XA transaction layer or object persistence.
But, for simple web applications, it *is* fun to build them from
the ground up. You learn a lot by doing so.
--Irmen de Jong
------------------------------
Date: Sun, 29 Jun 2003 09:05:59 -0400
From: Kevin Kenny <kennykb@acm.org>
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <3EFEE437.E963BC5B@acm.org>
Charles Handy wrote:
>
> How does FastCGI compare against java Apps running in java app servers
> like TomCat, Sun One, WebLogic and WebSphere? Is there a business case
> for switching from CGI to Java? Performance? Productivity? Features?
> Object orientation? Code Reuse?
>
> Any opinions?
When anyone talks about scrapping working code, I refer them to
http://www.joelonsoftware.com/articles/fog0000000069.html
Generally speaking, there's no good reason to ditch stuff that
works. Buzzword compliance is one of the worst reasons.
(Ditching particularly bad *components* of stuff that works
is sometimes the right thing...)
Performance: By the time you've finished your reimplementation,
Moore's Law will have caught up with you.
Productivity: Whose productivity? See the article cited above.
Features: What do you need? Does it exist in your current
environment? Is there an add-in that gives it without needing
to redevelop?
Object orientation: Tcl (with SnIT, IncrTcl, ...) supports it.
Perl supports it. Python supports it. The object models are
different, and zealots will say, "only .... is *really* object
oriented." Don't trust zealots.
Code reuse: Excuse me? You want code reuse, and you're talking
about redeveloping existing product?
If it ain't broke, don't fix it.
--
73 de ke9tv/2, Kevin
------------------------------
Date: Sun, 29 Jun 2003 08:26:28 -0500
From: "A.M. Kuchling" <amk@amk.ca>
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <4tmdnTTPGfqZdGOjRTvU2Q@speakeasy.net>
On Sun, 29 Jun 2003 17:01:07 +0800,
Charles Handy <chppxf1@NOSPAM_yahoo.com.au> wrote:
> How does FastCGI compare against java Apps running in java app servers
> like TomCat, Sun One, WebLogic and WebSphere?
> Is there a business case for switching from CGI to Java?
You're confusing an interface with a programming language. Most Java
application servers (indeed, most application servers in any language) use a
structure similar to FastCGI; the HTTP server packages up the information in
the client request, passes it to a long-running process which does the work,
and sends back the results. The difference is that FastCGI (or the similar
but easier-to-implement SCGI) has a public specification, while most
application servers invent their own protocol that isn't specified and that
no one else uses.
--amk
------------------------------
Date: Sun, 29 Jun 2003 13:36:37 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <vftqr5m0agm0bc@corp.supernews.com>
In article <3efed46f$0$49115$e4fe514c@news.xs4all.nl>,
Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> wrote:
>Måns Rullgård wrote:
>> Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes:
>>
>>
>>>>How does FastCGI compare against java Apps running in java app
>>>>servers like TomCat, Sun One, WebLogic and WebSphere?
>>>
>>>
>>>A (fast)CGI program compared to the actual Java program may not be
>>>much of a difference, depending on the program of course. What is
>>>a *huge* difference is that the Java app is running inside an
>>>*application server*. A (J2EE) Application Server provides a
>>>rich environment on which to base your scalable enterprise applications:
>>>- security
>>>- connectivity
>>>- scalability (performance, clustering)
>>>- maintainability / managability
>>>- error reporting/logging
>>>- component based (EJBs)
>>>- database connectivity and object persistence
>>>- transactions
>>>- ...
>>
>>
>> Someone mentioned buzzwords elsewhere in this thread.
>
>Very true ;-)
>
>But the fact remains, that you get the above mentioned things
>in one way or another when using an application server.
>Wether you *need* them is a totally different matter.
>As somebody else pointed out, if what you do now works for you,
>don't fix what's not broken...
>
>>>All of these are standardized in some way (as part of J2EE).
>>>In theory you can move your J2EE application to a different
>>>environment running on a different vendor's app server without
>>>much sweat.
>>
>>
>> That is, after you spent three weeks trying to figure out the correct
>> classpath, if one even exists.
>
>That's why I said "in theory".
>Classpath issues are the least of your problems.
>(and really should not take you more than an hour to figure out).
>
>>>You don't have any of this readily available when writing (fast)CGI
>>>applications; you have to implement all of these yourself.
>>
>>
>> Hey, it could be fun.
>
>I cannot imagine how it can be fun to design, build and test your
>own XA transaction layer or object persistence.
>
>But, for simple web applications, it *is* fun to build them from
>the ground up. You learn a lot by doing so.
>
>--Irmen de Jong
>
Me, too.
Kevin, Irmen, et al. have already covered all the high points.
Here are my reactions: in big-department, J2EE-committed groups,
there often is utter incomprehension about what we're saying. When
we seriously propose CGI (or FastCGI) with a "toy" language like
Python or Tcl, they see that as the rough equivalent to grinding
flour by hand, rather than buying a loaf of bread at the grocery.
Some decision-makers don't even believe existence proofs that CGI-
based approaches can meet requirements.
Application servers do have some wonderful functionality; it's
quite hard to find EJB service, load-leveling, some senses of
object persistence, ... as supplied by Tomcat, WebSphere, in the
"scripting language" world.
Java-oriented people underappreciate the extent to which applica-
tion servers *need* such built-ins, simply because development is
so clumsy with them. VERY few of the sites that have paid for
Web clustering *need* it, in any sense that I can understand,
except to compensate for problems the clustering-aware software
itself creates. More generally, application server-based projects
oriented to Java simply have big, big start-up costs. It can be
quicker writing a new little logging facility in Perl than just
trying to get the application server working at all. That's what
I've seen, at least.
Be very careful about the "security" argument. Yes, Java is a
"secure" language--in very specific senses. The security require-
ments of your particular situation might be entirely orthogonal.
In the dimensions that matter to you, Perl or Tcl might be *better*
than Java in supplying the kind of security you're after.
--
Cameron Laird <Cameron@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
------------------------------
Date: 29 Jun 2003 13:31:07 GMT
From: ngps@netmemetic.com (Ng Pheng Siong)
Subject: Re: Fast CGI Vs Java Application Servers
Message-Id: <bdmpmr$bqd$1@reader01.singnet.com.sg>
According to Alan Gauld <alan.gauld@btinternet.com>:
> On Sun, 29 Jun 2003 17:01:07 +0800, Charles Handy
> <chppxf1@NOSPAM_yahoo.com.au> wrote:
> > How does FastCGI compare against java Apps running in java app servers
> > like TomCat, Sun One, WebLogic and WebSphere?
>
> That depends on how your CGI apps are written.
OP is talking about _FastCGI_, http://www.fastcgi.com/, very loosely like
mod_perl, mod_python, mod_tcl/neowebscript/whatever.
--
Ng Pheng Siong <ngps@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
------------------------------
Date: Sun, 29 Jun 2003 08:20:05 GMT
From: inwap@inwap.com (Joe Smith)
Subject: Re: Perl -e `"dir a*.txt"`
Message-Id: <VixLa.123$603.7415@iad-read.news.verio.net>
In article <slrnbfikuf.1pi.vek@station02.ohout.pharmapartners.nl>,
Villy Kruse <nobody> wrote:
>On Wed, 25 Jun 2003 10:55:37 +0800,
> YOKETSL <yoketsl@singnet.com.sg> wrote:
>>I am using Activestate Perl 5.8.0 build 806 on Windows 98SE.
>> Perl -e `"dir a*.bat"`
There is an obvious typo: You have the double-quotes and backticks
in the wrong order. The following works under cmd.exe on Win-XP:
C:\WINDOWS>perl -e "print `dir *.ini`"
>Check the FAQ:
>
>perldoc -q "Why don't perl one-liners work on my DOS/Mac/VMS system?"
For one-line examples using single quotes and double quotes, I
recommend installing Cygwin (www.cygwin.com) on your PC.
$ cd c:/windows
$ perl -e '$_=`ls -l *.ini`; print "Results:>>$_<<\n"'
That example shows Unix-like behavior (The 'bash' shell and
the 'ls' command) available on Win-9x systems.
-Joe
--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.
------------------------------
Date: Sun, 29 Jun 2003 07:47:18 GMT
From: inwap@inwap.com (Joe Smith)
Subject: Re: Perl 5.6 and Perl 5.8
Message-Id: <aQwLa.122$603.7415@iad-read.news.verio.net>
In article <3EFA91CE.19926486@hochfeiler.it>,
Alvise Valsecchi <alvise@hochfeiler.it> wrote:
>Here stands my problem: I wrote a network daemon that has been working
>fine under Perl 5.6 and Red Hat 7.3 for many months.
>
>Then I installed Red Hat 8, and Perl 5.8 that comes togheter, and the
>script started failing continuously.
There are a lot of things that fail with RedHat-8, straight out of the
box. For instance, the 'man' command. Instead of hyphens or double
hyphens, it produces en-dash and em-dash, which do not have
displayable glyphs in the default font.
I found that adding this to my .login file helps:
if ($?LANG) then
if ($LANG == en_US.UTF-8) setenv LANG en_US # RedHat-8.0 KDE font errors
endif
Perl-5.8 is sensitive to LANG being set to any UTF setting.
Try using a non-UTF setting before running your perl programs.
-Joe
--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.
------------------------------
Date: 29 Jun 2003 05:15:11 -0700
From: rook_5150@yahoo.com (Bryan Castillo)
Subject: Perl keeps me from throwing up while programming java
Message-Id: <1bff1830.0306290415.59148497@posting.google.com>
use strict;
use warnings;
use Tk;
my $top = MainWindow->new();
my $t1 = $top->Scrolled(
'Text', -scrollbars=>'se',
-height=>5, -width=>40, -wrap=>'none'
)->grid(
-row=>0,-col=>0,-sticky=>'nsew'
);
my $t2 = $top->Scrolled(
'Text', -scrollbars=>'se',
-height=>5, -width=>40, -wrap=>'none'
)->grid(
-row=>1,-col=>0,-sticky=>'nsew'
);
my $btn = $top->Button(-text=>'Generate (Java Crap)',
-command=>[\&generate, $t1, $t2])
->grid(
-row=>2,-col=>0,-sticky=>'e'
);
$top->gridRowconfigure(0, -weight=>1);
$top->gridRowconfigure(1, -weight=>1);
$top->gridRowconfigure(2, -weight=>0);
$top->gridColumnconfigure(0, -weight=>1);
MainLoop;
# generate getters and setters for those !@*&*n beans!
sub generate {
my ($t1, $t2) = @_;
my $text = $t1->get("0.0", "end");
my @lines = split /[\r\n]+/, $text;
my $out = '';
foreach my $line (@lines) {
if ($line =~ /
(\w+)\s* # variable type
(\[[\d\s]*\])?\s* # array type?
(\w+)\s* # variable name
(\[[\d\s]*\])?\s* # array type?
[;=]/x)
{
my ($type, $var) = ($1,$3);
my $array = $2 || $4;
$type .= " []" if ($array)
my $var_uc = ucfirst($var);
$out .= sprintf
" public %s get%s {\n return this.%s;\n }\n",
$type, $var_uc, $var;
$out .= sprintf
" public void set%s(%s %s) {\n this.%s = %s;\n }\n\n",
$var_uc, $type, $var, $var, $var;
}
}
$t2->delete("0.0", "end");
$t2->insert('end', $out);
}
# thats all I really had to say
------------------------------
Date: 28 Jun 2003 23:45:25 -0700
From: tivolinewbie@canada.com (Kenjis Kaan)
Subject: perl\site\lib\auto\... (DLLs, LIB, EXP etc) to another location under your dev directory?
Message-Id: <6a8ba9f8.0306282245.3bb9474a@posting.google.com>
Would it be possible to move support files under
perl\site\lib\auto\... (DLLs, LIB, EXP etc) to another location
under your dev directory? I am developing perl applications that will
then be pushed down to end users PC as a package. I need to make this
package self contained so that when it sits on the client PC it can be
run right away. The problem is that there is only a basic Perl
installation on the end users PC with non of the fancy modules
installed. So I would like to be able to create my application in
such a way that I can put the DLLs/LIB of the package in the current
directory, as well as the module.pm itself. I wonder if perl will
allow you to do that. I notice whenever I install a package, it puts
all the DLLs,LIB files into the perl\site\lib\auto directory. I don't
want ot have to go and install various package on thousands of PCs
before an application can be run. There has to be a way so that you
can put the DLLs eg. DB_File.dll and DB_File.lib inside the current
development directory containing the codes I am developing. So when I
hand the complete product over to who ever use it, the thing will run
right away. You just can't expect end user to know how to install
perl packages.
------------------------------
Date: Sun, 29 Jun 2003 09:52:38 -0500
From: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>
Subject: Re: perl\site\lib\auto\... (DLLs, LIB, EXP etc) to another location under your dev directory?
Message-Id: <P2DLa.20131$I7.30848@news1.mts.net>
"Kenjis Kaan" <tivolinewbie@canada.com> wrote in message
news:6a8ba9f8.0306282245.3bb9474a@posting.google.com...
> Would it be possible to move support files under
> perl\site\lib\auto\... (DLLs, LIB, EXP etc) to another location
> under your dev directory?
[ ... ]
If your users are running ActivePerl, you can create a ppm package
(http://aspn.activestate.com/ASPN/docs/ActivePerl/faq/ActivePerl-faq2.html)
which users can install with the ppm utility. Alternatively, after
building the package, you could distribute the blib/ directory,
which users can then include as, eg, 'perl -Mblib ...'.
best regards,
randy kobes
------------------------------
Date: Sun, 29 Jun 2003 01:10:41 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Testing perlfuncs (getopt) for true/false. (yeah i'm newbie.)
Message-Id: <slrnbft0n1.6qu.tadmc@magna.augustmail.com>
ThePotPlants <thepotplants@yahoo.com> wrote:
> Any help (which doesn't include RTFM) would be greatly appreciated
So long then.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 29 Jun 2003 11:42:18 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: URL checking
Message-Id: <Pine.LNX.4.53.0306291134130.27085@lxplus012.cern.ch>
On Sat, Jun 28, Tad McClellan inscribed on the eternal scroll:
> Mandy <mandy100@ihug.com.au> wrote:
>
> > 1. Does a given page exist on a remote site
>
> Try and "fetch" it, if you get a good-looking response, then
> the resource exists.
Indeed. But if you don't actually want the contents of the page, then
a HEAD request is more efficient.
According to the specs, the answers from HEAD and GET should be
equivalent for this purpose. If they aren't then there's something
wrong with the remote server, but normally the approach is OK in my
experience.
OK, if it's just a one-off request then the difference is no matter,
but if this was for some kind of production-line checker then the
difference in terms of network resources could add up.
cheers
------------------------------
Date: 29 Jun 2003 06:38:54 -0700
From: dejanews@email.com (Sam Denton)
Subject: Re: Yet another "undefined reference to `_WinMain@16'" in cygwin
Message-Id: <3c863a7a.0306290538.58310144@posting.google.com>
"A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu> wrote in message news:<Xns93A8676006B3Dasu1cornelledu@132.236.56.8>...
> dejanews@email.com (Sam Denton) wrote in
> news:3c863a7a.0306272123.2b827030@posting.google.com:
>
> > I'm getting this message when linking under Cygwin. I've googled the
> > message text and found several of "voodoo" fixes (i.e. "This worked
> > for me but I don't know why"). I've blindly tried several of them,
> > but none of them worked.
>
> I do not _know_ the solution, but have you looked at
>
> http://cygwin.com/faq/faq_toc.html#TOC95
This was the place where I saw the one fix that I hadn't tried.
Again, I was uncertain of the effects of having a 'main()' in a DLL.
So, I've tried it. It worked, but it turned out to be a red herring.
See below.
> and
>
> http://cygwin.com/cygwin-ug-net/dll.html
>
> I am only asking this because I do not see a `shared' flag anywhere, and it
> looks like, from the line
>
> > LD_RUN_PATH="/usr/local/lib" g++ -s -L/usr/local/lib Plotter.o
>
> you are stripping symbols. Again, I am no expert on cygwin, but those look
> like problem spots to me. Have you tried asking this question on the cygwin
> mailing list?
>
> Sinan.
Ah, this did the trick!
Adding the dummy 'main()' got me past the "undefined reference to
`_WinMain@16'" but then I got stuck during the 'make test' phase,
getting the message
"Can't find 'boot_Graphics__Plotter' symbol in [...].dll", which a
quick google didn't help with. Apparently, no one who has run into
this has ever posted the solution anywhere (thus this long-winded
answer). For examples of this, see
http://www.google.com/search?q=perl+cygwin+"can't+find+*+symbol"+dll
Adding the '-shared' flag works! I did not have to remove the '-s'
flag, and I was able to remove the dummy 'main()' as well.
Thank you for your assistance.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5152
***************************************
