[23161] in Perl-Users-Digest
Perl-Users Digest, Issue: 5382 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 17 21:10:38 2003
Date: Sun, 17 Aug 2003 18:10:10 -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, 17 Aug 2003 Volume: 10 Number: 5382
Today's topics:
Re: mod_perl 2 Setup ? <pkent77tea@yahoo.com.tea>
Module::Build is yet more broken... <nospam-abuse@ilyaz.org>
Re: Module::Build is yet more broken... (Sam Holden)
Re: Module::Build is yet more broken... <pkent77tea@yahoo.com.tea>
Re: Perl and recursive copying? <gellyfish@gellyfish.com>
Re: Problem with join and unicode <abuseonly@sgrail.org>
Re: Regex Question (Tad McClellan)
Re: single entry window with input being sent to 2..n x <gellyfish@gellyfish.com>
Re: Testing whether a subroutine exists (symbolic ref) <REMOVEsdnCAPS@comcast.net>
Re: <bwalton@rochester.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Aug 2003 01:01:37 +0100
From: pkent <pkent77tea@yahoo.com.tea>
Subject: Re: mod_perl 2 Setup ?
Message-Id: <pkent77tea-74BD3D.01013618082003@usenet.force9.net>
In article <bhnaet$q4c$1@news.freedom2surf.net>,
"Bob Welton" <welton_bob@nospam_hotmail.com> wrote:
> I am running Red Hat 9 that has Apache 2 installed with the build. I have
> been trying to set up mod_perl 2 but have had lots of problems and don't
> think its working. How can I check if its installed ?
>
> I have tried # httpd -l and get:
> Compiled in modules:
> core.c
> prefork.c
> http_core.c
> mod_so.c
>
> Should mod_perl appear here in version 2 ?
On my SuSE Linux system mod_perl was a separate package (i.e. an RPM)
which I had to install separately from the mail apache install. Have a
look in your system configuration tool (it's called YAST in SuSE linux,
for example) and see if you can add a mod_perl package. I reckon that's
the easiest thing to start with.
Also you can try using the locate program and look for mod_perl.so -
this is what I get on my machine:
$ locate mod_perl.so
/usr/local/apache2/modules/mod_perl.so
That will at least tell you if the module is on the disk somewhere.
Similarly try to 'locate Apache2/ModPerl'
P
--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply
------------------------------
Date: Sun, 17 Aug 2003 23:45:05 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Module::Build is yet more broken...
Message-Id: <bhp421$gn6$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Ted Zlatanov
<tzz@lifelogs.com>], who wrote in article <4nwudcefxz.fsf@lockgroove.bwh.harvard.edu>:
> > I missed the start of this thread but this reminds me of:
> > http://magnonel.guild.net/~schwern/talks/MakeMaker_Is_DOOMED/slides/
> That was really useful, thanks. It answered pretty much every
> question I had.
While I too consider MakeMaker a broken architecture, this Module::Build
idea is much more broken (not even speaking about the faulty logic in
the presentation cited above).
The beauty of Makefile.PL user interface (as opposed to the - faulty -
packager's interface) is that it was shell-, OS-, filesystem-,
etc-independent. Now comes Build - and the invocation has the ./file
syntax, which is system-dependent!
So now the README for a distribution should contain "If you are on
..., ..., or ..., use the following commands to build this package; if
you are on ..., ..., use these commands; otherwise you are on your
own, since I do not know the shell syntax there". Or if it does not,
it's the users who are delegated the responsibility to find this
out...
This problem might have been trivial to fix when Module::Build was
young - the fault is with trying to mimic MakeMaker's UI ;-) ;-(. But
judging by the reports, now Module::Build may be entrenched enough so
that its UI can't be changed. (Without the packages' READMEs
containing "If the version of Module::Build is less than ..., use the
following commands, otherwise use..." :-().
IMO, one should have abandon `make' and `make test'-like commands at
all, doing the `make; make test' step by default during the `perl
FirstStep.PL' phase. If the finer control is needed, one should be
able to specify this by arguments on the FirstStep.PL line. E.g., one
possible syntax for the standard invocation might have been
perl FirstStep.PL do=config do=build do=test do=install
(with `do=config do=build do=test' being the default if no do= options
are given). [Here FirstStep is just a placeholder, of course...]
Hope this helps,
Ilya
------------------------------
Date: 17 Aug 2003 23:55:44 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: Module::Build is yet more broken...
Message-Id: <slrnbk05g0.ah8.sholden@flexal.cs.usyd.edu.au>
On Sun, 17 Aug 2003 23:45:05 +0000 (UTC),
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> [A complimentary Cc of this posting was sent to
> Ted Zlatanov
><tzz@lifelogs.com>], who wrote in article <4nwudcefxz.fsf@lockgroove.bwh.harvard.edu>:
>> > I missed the start of this thread but this reminds me of:
>> > http://magnonel.guild.net/~schwern/talks/MakeMaker_Is_DOOMED/slides/
>
>> That was really useful, thanks. It answered pretty much every
>> question I had.
>
> While I too consider MakeMaker a broken architecture, this Module::Build
> idea is much more broken (not even speaking about the faulty logic in
> the presentation cited above).
>
> The beauty of Makefile.PL user interface (as opposed to the - faulty -
> packager's interface) is that it was shell-, OS-, filesystem-,
> etc-independent. Now comes Build - and the invocation has the ./file
> syntax, which is system-dependent!
Surely it could just say:
perl Build.PL
perl Build test
perl Build install
Instead of:
perl Makefile.PL
make test
make install
One less system depedant thing (making sure make is available and in the
appropriate path). If perl can't be executed, then installing modules is
probably not the most important problem to fix...
[snip the rest]
I agree with most of that
perl Build.PL test
perl Build.PL install
or
perl Build.PL test install
seems better to me - if the initial 'perl Build.PL' step is time intensive then
the module can cache the result after all (maybe in a file called ./Build :).
--
Sam Holden
------------------------------
Date: Mon, 18 Aug 2003 01:50:50 +0100
From: pkent <pkent77tea@yahoo.com.tea>
Subject: Re: Module::Build is yet more broken...
Message-Id: <pkent77tea-8804F1.01505018082003@usenet.force9.net>
In article <bhp421$gn6$1@agate.berkeley.edu>,
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> [A complimentary Cc of this posting was sent to
> Ted Zlatanov
> <tzz@lifelogs.com>], who wrote in article
> <4nwudcefxz.fsf@lockgroove.bwh.harvard.edu>:
> > > I missed the start of this thread but this reminds me of:
> > > http://magnonel.guild.net/~schwern/talks/MakeMaker_Is_DOOMED/slides/
...
> The beauty of Makefile.PL user interface (as opposed to the - faulty -
> packager's interface) is that it was shell-, OS-, filesystem-,
> etc-independent. Now comes Build - and the invocation has the ./file
> syntax, which is system-dependent!
I think that was an example of the invocation on a Unix-like system,
just as '/usr/bin/make' is a possible command line in the traditional
perl-module-building process. On my MacPerl system I would not type
anything, because for most users there is nowhere to type... droplets
and double-clicking are alternatives. Saying './Foo' doesn't (afaik)
work on VMS systems, nor any other system (AmigaOS?) where the directory
naming isn't Unix-like.
That's not to say I know much nor endorse Module::Build. I do think that
using make(1) was initially a Good Idea. I do think that this whole idea
of necessarily "using an external make-like tool" is a Bad Idea. Here's
why: when I want to install a module I have, to begin with, a directory
full of files. I want to install them in the Right Place. I _do not_
care how they get there. I'm goal-oriented, not process-oriented. So,
this is what I want to achieve:
check the distro is complete
ask the user some questions (e.g. "What's your http proxy?")
build some documentation from the perl (man pages, html, whatever is
appropriate)
do whatever autosplit-related gubbins needs to be done
alter the shebang line in programs
run 0 or more test programs
install, whatever that means, the docs and the perl modules in the right
place.
None of that -requires- make. But on a Unix system it can be done with
make. The thing is that I don't care -how- it's done, I just want
certain goals achieved. Even if I had XS code I don't -need- make, even
on a unix system. Perl is quite capable of saying:
system('/usr/bin/gcc', '-foo', '-bar'....
And perl is quite capable of copying files around, manifying things,
etc. All by itself without a makefile (or batch script or whatever)
firing off commands.
Now that's not to say that make is bad. It's a fine program and does
some very clever things, and I use it most days. But it's not actually
necessary, when you actually think about the requirements outlined
above. It is very valuable though if you want complex dependencies
worked out. I expect this becomes more apparent with XS modules (not
sure myself - I tend to only compile them on Unix-ish systems)
OTOH the standard 'Makefile.PL' way of doing things does have the
benefit of being a piece of cake and very very standard. Any replacement
should probably be a kind of 'behind the scenes, under the hood' change
than won't affect how people usually work. So to sum up, it's all pretty
tricky :-)
P
--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply
------------------------------
Date: Sun, 17 Aug 2003 23:42:22 GMT
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Perl and recursive copying?
Message-Id: <ypU%a.11$Yx6.2912@news.dircon.co.uk>
Tad McClellan <tadmc@augustmail.com> wrote:
> James Willmore <jwillmore@cyberia.com> wrote:
> > tadmc@augustmail.com (Tad McClellan) wrote in message news:<slrnbjopo1.8ei.tadmc@magna.augustmail.com>...
>
>
> >> You should always prefer lexical variables over package
> >> variables, except when you can't.
>
> > Okay, now you've given me a concept to read about (lexical). I seen
> > it, heard about it, and, I fear greatly to say this, but don't
> > understand it.
>
>
> Lexical variables are the ones that are _easy_ to understand.
>
> It is package variables that are harder to understand.
>
Conceptually, perhaps, yes. But the term _lexical_ itself occludes
the simplicity of the idea. The term _package_ finds expression in the
perl syntax and is similar in its use there as it is in human languages,
whereas the _lexical_ is an uncommon word and it appears to be used in an
essentially metaphorical manner in describing the scope of stuff in Perl.
The perlfaq item:
How can I access a dynamic variable while a
similarly named lexical is in scope?
seems to make a further leap by assuming the reader will fill in the
'ly scoped variable' (yes, the patch is in the post :-)
So on balance I'm not surprised that people find lexically scoped thingies
( and how much more difficult it is on the brain when these things aren't
simple identifiers like variables) more difficult to understand than
package scoped ones.
Now what was my point again?
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
------------------------------
Date: Sun, 17 Aug 2003 23:00:29 GMT
From: derek / nul <abuseonly@sgrail.org>
Subject: Re: Problem with join and unicode
Message-Id: <kp10kv8rg3s9ria2p5i35f8f424s7p452b@4ax.com>
On Sun, 17 Aug 2003 18:32:52 +0200, "Alan J. Flavell" <flavell@mail.cern.ch>
wrote:
<snip>
>One thing that I tried was putting a :crlf layer after the
>:encoding(utf16le) on the open statement. Well, this then resulted
>in the newlines being handled as expected, but it somehow screwed-up
>the recognition of the BOM. If the text contained any non-ASCII
>characters I'm concerned that it would upset those too?
>
>Yes, sure, I _could_ do what the original poster was aiming at,
>reading the stuff in binary, decoding it explicitly, and fooling with
>the details of newlines for myself. But if the wheel has already been
>invented, I wanna use it, right?
>
>At this point I decided that I didn't really understand what the
>documentation was telling me to do, so I decided to ask. Help?
Alan, thanks for that.
At least I am not going mad.
I had got to the point where I knew that x0d0a was part of the problem, I just
didn't know why.
anyone else that would like a copy of an M$ UTF16LE file
http://www.sgrail.org/files/gp9.zip
Derek
------------------------------
Date: Sun, 17 Aug 2003 17:14:18 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Regex Question
Message-Id: <slrnbjvvhq.luh.tadmc@magna.augustmail.com>
Mike Flannigan <mikeflan@earthlink.net> wrote:
>
> Got a pretty simple question for you'all. This matches
[ snip m// ]
> What am I missing here?
unpack() is useful with fixed width fields.
> TP,DMS, 35.020041249, -94.3847918870,12/31/1989,00:00:00,1
my( undef, $num1, undef, $num2 ) = unpack 'A8 A12 A3 A13', $_;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 17 Aug 2003 23:58:03 GMT
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: single entry window with input being sent to 2..n xterms simultaneously
Message-Id: <fEU%a.12$Yx6.2912@news.dircon.co.uk>
Rob Petty <robsjobs@hotmail.com> wrote:
> I am using a Linux box as a fill-in for a Sun Cluster "cluster console" machine. The only thing I am missing is the ability to
> open three windows:
> 1 is a small window like a Perl/Tk with a simple text input box.
> 2 are normal xterm windows
>
> Each xterm window can have direct text input individually, but the
> kicker is that typing in the smaller window with just the text box
> sends the text to both xterm windows at the same time. (One entry
> for configuration info and any other valid CLI command, two outputs)
>
At a guess (and I really can't be arsed to experiment right now ) you might
be able to use X11::Protocol to send the appropriate X events to the xterm
windows however you may need information about those windows that might not
be available easily to the Perl program. I'd start by looking in the X
documentation.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
------------------------------
Date: Sun, 17 Aug 2003 20:00:32 -0500
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Testing whether a subroutine exists (symbolic ref)
Message-Id: <Xns93DAD5A273560sdn.comcast@206.127.4.25>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Arvin Portlock <apollock11@hotmail.com> wrote in news:bhoiv5$5gh$1
@agate.berkeley.edu:
> I'm having a look at some old code which uses symbolic subroutine
> references (I know, A Very Bad Thing). I simply want to test whether
> the named subroutine actually exists in the code. This simple pro-
> gram:
>
> my $sub_name = "mySub";
> my $sub_ref = sub { &{"$sub_name"} };
You're going way too many levels deep there. Just do:
my $sub_name = 'mySub';
if (defined &$sub_name)
{
...
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0AlEmPeouIeTNHoEQLnZwCfVmffCzF5fMM3dzN6epFdjvVXU/wAn2um
e4akcOro+OpEK6YS4c06SJHN
=uOeL
-----END PGP SIGNATURE-----
------------------------------
Date: Sat, 19 Jul 2003 01:59:56 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re:
Message-Id: <3F18A600.3040306@rochester.rr.com>
Ron wrote:
> Tried this code get a server 500 error.
>
> Anyone know what's wrong with it?
>
> if $DayName eq "Select a Day" or $RouteName eq "Select A Route") {
(---^
> dienice("Please use the back button on your browser to fill out the Day
> & Route fields.");
> }
...
> Ron
...
--
Bob Walton
------------------------------
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 5382
***************************************
