[26224] in Perl-Users-Digest
Perl-Users Digest, Issue: 8409 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 12 18:05:29 2005
Date: Mon, 12 Sep 2005 15:05:05 -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 Mon, 12 Sep 2005 Volume: 10 Number: 8409
Today's topics:
Re: Can a Perl Programmer Pick up PHP quickly? <1usa@llenroc.ude.invalid>
Re: Can a Perl Programmer Pick up PHP quickly? rich@newsguy.com
Re: IPC::Shareable Problem with multidimentional hash xhoster@gmail.com
Re: IPC::Shareable Problem with multidimentional hash <scottalordaNOSPAM@libello.com>
Perl core dumping - possible bug? <notvalid@email.com>
Re: Perl core dumping - possible bug? <1usa@llenroc.ude.invalid>
Re: Perl core dumping - possible bug? xhoster@gmail.com
SOLVED: "Text File Busy" And Other Frustrating NFS/Perl <hal@thresholddigital.com>
Re: Space (\s) count problem <tadmc@augustmail.com>
Re: Trouble with passing quotes to perl program rich@newsguy.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 12 Sep 2005 18:14:30 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Can a Perl Programmer Pick up PHP quickly?
Message-Id: <Xns96CF90E0123A9asu1cornelledu@127.0.0.1>
axel@white-eagle.invalid.uk wrote in news:77gVe.23511$k22.15069
@fe2.news.blueyonder.co.uk:
> John Bokma <john@castleamber.com> wrote:
>> Again, there are no easy languages. PHP seems to have it origins in a
>> programmer who had little to no Perl skills, thought he could make an
>> easier "Perl" and ended up with a bigger mess. Sadly there are still
>> people adding to this mess instead of weeding out all the garbage that
>> has been crept into PHP.
>
> I remember using one of the earliest versions of PHP years ago...
> it was basically only a means of adding a counter and similar
> things to web pages. Obviously it has grown since then but
> with no overall plan except adding new features.
Indeed. http://us2.php.net/history might be of interest.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: 12 Sep 2005 11:04:57 -0700
From: rich@newsguy.com
Subject: Re: Can a Perl Programmer Pick up PHP quickly?
Message-Id: <dg4g0901vd7@drn.newsguy.com>
In article <430c9a95.299275295@news.webperception.com>, Mike says...
>
>
>I have a lot of experience with Perl and a good paying job has come up
>that requires someone to update and maintain a website written in PHP.
>
>Can a Perl programmer pick up PHP easily? Are there similarities?
>
>
>Thanks
I started off using Perl and had to pick up PHP along the way for a couple of
work projects. Perl has a lot more uses, but with regard to the same application
(web site development, accessing SQL databases, etc.) they're pretty close. Have
to get use to using functions instead of subroutines but a little practice goes
a long way. With Perl, I got into the habit of using "strict" and took some time
getting use to not having it available.
Rich
--
Newsguy -- http://newsguy.com
------------------------------
Date: 12 Sep 2005 20:31:40 GMT
From: xhoster@gmail.com
Subject: Re: IPC::Shareable Problem with multidimentional hash
Message-Id: <20050912163140.303$RF@newsreader.com>
Sébastien_Cottalorda <sppNOSPAM@libello.com> wrote:
...
> >
> > Note that this won't be very fast, because it is freezing and thawing
> > the entire data structure just to access one part of it. I suspect
> > that that is why Shareable was implemented the way it was (using
> > seperate segments for each piece) in the first place.
> >
> > Shared memory is not one of the hard things which Perl has made easy.
> >
> > Xho
> >
> Thanks a lot for your help.
> I'll try your solution.
>
> Maybe I've another one:
> My complex hash %complex_hash is particular, it's like this:
>
> %complex_hash =(
> 'code1' => {
> "Startdate" => ...,
> "Enddate" => ...,
> ...
> total = about 20 keys
> },
> 'code2' => {
> "Startdate" => ...,
> "Enddate" => ...,
> ...
> total = about 20 keys
> },
> ...
> 'code300' => {
> "Startdate" => ...,
> "Enddate" => ...,
> ...
> total = about 20 keys
> }
> );
>
> If I change it like this:
>
> %complex_hash = (
> "StarDate" => {
> 'code1' => ...,
> 'code2' => ...,
> ...
> 'code300' => ...
> },
> "Enddate" => {
> 'code1' => ...,
> 'code2' => ...,
> ...
> 'code300' => ...
> },
> ...
> about 20 primary keys
> );
>
> I'll solve a few my problem because now, it will create about 20-21
> segments each of them containing all codes.
>
> What do you think of that ?
I think that could work. Of course, it makes deleting an entry harder,
because might have to be deleted from all ~20 parallel hashes. And it is
still freezing-thawing a lot of data just to access one small element.
In fact, I was going to make exactly this "dimension swap" as a second
suggestion, but then I decided that if I were going to do that it would be
better to rear back one more step, ask what problem you are trying to use
shared memory to solve, and see if there was another solution that didn't
use shared memeory at all, or only used it for flags rather than the entire
data set. Then I decided I might not be ambitious enough to dig into so
many details, so I probably shouldn't ask for them.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Mon, 12 Sep 2005 23:48:57 +0200
From: =?ISO-8859-1?Q?S=E9bastien_Cottalorda?= <scottalordaNOSPAM@libello.com>
Subject: Re: IPC::Shareable Problem with multidimentional hash
Message-Id: <4325f72b$0$1917$626a14ce@news.free.fr>
[snip]
>>If I change it like this:
>>
>>%complex_hash = (
>> "StarDate" => {
>> 'code1' => ...,
>> 'code2' => ...,
>> ...
>> 'code300' => ...
>> },
>> "Enddate" => {
>> 'code1' => ...,
>> 'code2' => ...,
>> ...
>> 'code300' => ...
>> },
>> ...
>> about 20 primary keys
>>);
>>
>>I'll solve a few my problem because now, it will create about 20-21
>>segments each of them containing all codes.
>>
>>What do you think of that ?
>
>
> I think that could work. Of course, it makes deleting an entry harder,
> because might have to be deleted from all ~20 parallel hashes. And it is
> still freezing-thawing a lot of data just to access one small element.
>
> In fact, I was going to make exactly this "dimension swap" as a second
> suggestion, but then I decided that if I were going to do that it would be
> better to rear back one more step, ask what problem you are trying to use
> shared memory to solve, and see if there was another solution that didn't
> use shared memeory at all, or only used it for flags rather than the entire
> data set. Then I decided I might not be ambitious enough to dig into so
> many details, so I probably shouldn't ask for them.
>
>
> Xho
>
I need to share datas for some cooperatives programs.
I'm developping a car park access control based on internet reservation.
My customers reserves their car park, and then comes and see me.
In the share memory, I need to share all informations concerning the
customers reservations, but i need too to share the equipments status,
the real time counters (how free are all of my car parks , ect ...) ect ...
I plan to use the shared memory because the access is faster than on a
flat file (I think).
Certains API screens (the main one in fact) contain the real time
counters and last equipments errors => I need to display them very fast.
That's why I plan to use shared memory.
I found another solution of my problem:
Creating a one level hash like this, and process with string replacement :
%hash = (
'code1' => '2005010112345620050101232323...',
'code2' => '...'
...
)
I only need another hash table to make the mapping between 'key name'
and (position-length) like this:
%detail_hash = (
'startdate' => [ 0 , 14 ],
'enddate' => [ 14 , 14 ],
...
)
It's more complicate because I need to check every field before setting
them or replacing them, but the sharedmemory part is quite little.
The advantage: One segment per hash.
The Inconvenient: It's hard to manage.
Sebastien
------------------------------
Date: Mon, 12 Sep 2005 18:48:47 GMT
From: Ala Qumsieh <notvalid@email.com>
Subject: Perl core dumping - possible bug?
Message-Id: <j4kVe.335$Op3.121@newssvr25.news.prodigy.net>
Hi all,
The following snippet coredumps in both perl5.6.1 and perl5.8.3 on both
linux and solaris, as well as perl5.8.0 on winXP:
% perl -Mstrict -wle 'map {map {print "x" for 1 .. 5} 1..5} 1..5'
Interestingly, the following coredumps in 5.6.1, but not in 5.8.0 or 5.8.3:
% perl -Mstrict -wle 'map {print "x" for 1 .. 5} 1..5'
Am I doing something wrong, or have I stumbled upon some Perl bug?
Can someone please confirm with the latest stable release 5.8.7?
Thanks,
--Ala
------------------------------
Date: Mon, 12 Sep 2005 19:05:39 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Perl core dumping - possible bug?
Message-Id: <Xns96CF998C659E8asu1cornelledu@127.0.0.1>
Ala Qumsieh <notvalid@email.com> wrote in
news:j4kVe.335$Op3.121@newssvr25.news.prodigy.net:
> The following snippet coredumps in both perl5.6.1 and perl5.8.3 on
> both linux and solaris, as well as perl5.8.0 on winXP:
>
> % perl -Mstrict -wle 'map {map {print "x" for 1 .. 5} 1..5} 1..5'
>
> Interestingly, the following coredumps in 5.6.1, but not in 5.8.0 or
> 5.8.3:
>
> % perl -Mstrict -wle 'map {print "x" for 1 .. 5} 1..5'
>
> Am I doing something wrong, or have I stumbled upon some Perl bug?
> Can someone please confirm with the latest stable release 5.8.7?
Confirmed.
D:\Home> perl -v
This is perl, v5.8.7 built for MSWin32-x86-multi-thread
(with 7 registered patches, see perl -V for more detail)
This is on WinXP SP2 AMD64
asu1@recex:~ > perl -v
This is perl, v5.8.7 built for i386-freebsd-64int
This is on FreeBSD 5.4 Athlon.
In both cases, I get a segfault.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: 12 Sep 2005 19:40:13 GMT
From: xhoster@gmail.com
Subject: Re: Perl core dumping - possible bug?
Message-Id: <20050912154013.378$US@newsreader.com>
Ala Qumsieh <notvalid@email.com> wrote:
> Hi all,
>
> The following snippet coredumps in both perl5.6.1 and perl5.8.3 on both
> linux and solaris, as well as perl5.8.0 on winXP:
>
> % perl -Mstrict -wle 'map {map {print "x" for 1 .. 5} 1..5} 1..5'
>
> Interestingly, the following coredumps in 5.6.1, but not in 5.8.0 or
> 5.8.3:
>
> % perl -Mstrict -wle 'map {print "x" for 1 .. 5} 1..5'
>
> Am I doing something wrong, or have I stumbled upon some Perl bug?
I'd say both. The desire to do this seems perverse, to me. But it
still shouldn't seg fault.
> Can someone please confirm with the latest stable release 5.8.7?
Confirmed on 5.8.7 on Linux.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Mon, 12 Sep 2005 15:36:31 -0400
From: Hal Vaughan <hal@thresholddigital.com>
Subject: SOLVED: "Text File Busy" And Other Frustrating NFS/Perl Errors
Message-Id: <gK2dnf03grtfRbjeRVn-rA@comcast.com>
A good while back I searched Google and posted in a number of forums about a
problem I had with Perl. I am (and was) using 2 computers, both running
MEPIS Linux, which is Debian based, so this problem might happen with
Debian or other distros as well. On my workstation, I was using Kate,
which is a text editor with a console in the bottom of the window. Kate
was on the workstation, but in the console, I connect to my server, the
system I'm programming on, with ssh. That means I am actually editing the
Perl file on one computer (my workstation), by reading and writing through
an NFS mounted directory, and I am running it on another (my server).
The first problem I had was that when I saved my script through NFS, then
tried to run it, I always got this error message:
/usr/bin/perl: bad interpreter: Text file busy
It would last up to about 10 seconds, after which I could run the file. I
searched newsgroups on Usenet and mailing lists and general Google searches
for a problem like this. (After all, why use something like Perl if I had
to wait to run a program as if I were compiling?) I found a number of
other people had similar problems, and in some groups the given solution
was simply to wait 24 hours for NFS to make the file available to all.
Since I found no answer, I got used to waiting 10 seconds to run a script
(and be thankful I didn't have to wait 24 hours!).
Then, the other night, when I was exhausted, my eyes were blurry and I
literally almost could not focus on my monitor, I noticed another problem.
I was so exhausted I thought I was not paying attention or just missed
something, but this was a problem I had suspected before. Even though I
could barely stay awake, I forced myself to track what was going on and be
sure I wasn't imaging things. I was finally able to prove MY CHANGES IN MY
SCRIPTS DIDN'T ALWAYS SHOW UP WHEN I SAVED! The worksation would see
changes, but when I ran the program on the server, nothing was changed. I
finally would add an extra print statement to see what was going on -- and
change NOTHING else -- and not only did the program start printing out the
extra data, but it started working like it should with my change in it.
Now it is important to note these changes were in Perl modules. When I
tried to run a just edited Perl program, I'd get the "text file busy" error
I mentioned above. If the program used a module, and the module was just
edited, I would not get that error, so I could edit a module on the
workstation, save it to the NFS mount, run a program on the server that
used that module, and it would run.
However, sometimes the changes would not appear on the server when I ran it.
I finally figured out that the changes might be cached somewhere or not
synchronized yet. I don't if adding the 2nd change and saving again forced
a buffer to be written out, or if the changes in the modules were not
getting to the server for that same pesky 10 seconds it took for me to stop
getting the "text file busy" error, but the changes in the program did not
show up when first saved, and did later.
At this point I felt like I had gone down the rabbit hole and my LAN was
going to have to be renamed Wonderland, things seemed so strange. I
*thought* the problem was NFS, but wasn't even sure, at that point, what
terms to use in searching. With the kind help of some people in the
Libranet-OT group at Yahoo (not a Libranet group -- the Libranet OT group
is made up of people that got tired of the Libranet support list being
censored and left Libranet's list and the distro but wanted to continue
their discussions) and some people on the Debian Users list (through
debian.org), I got some tips, found out I was missing the program exportfs,
posted that info, and finally the saving grace, one short message that
included a one line answer:
install nfs-kernel-server.
In Debian, that means running:
apt-get install nfs-kernel-server
as root. I did, and got errors as it tried to configure my /etc/exports
file. I had to edit my exports file a few times to make sure it worked.
It turned out my problem was only extra spaces. I won't go into the format
of this file, since that's posted in many other areas. I will say that my
options for each system were (rw,sync).
I don't know the name of the nfs-kernel-server package for RPM systems, but
basically, by making sure I had the rw,sync options set for each system
in /etc/exports, making sure the file was formatted properly, installing
this package, and, afterwards, running:
exportfs -ra
(which was probably already run when apt-get installed the package), I
found the frustrating "text file busy" error was gone.
Since I've seen this error in many posts, but never found an answer to it, I
thought I'd post this where I've asked for help, so others can find it via
Google and such in the future. I'm not an expert on NFS, and I really
don't know any other things to do to work with this problem other than what
I've posted. This is what fixed it for me. No more "text file busy"
errors, and no more Wonderland behavior of not updating saved files. If
you're having the same problem, I hope this fixes it . If it doesn't, I
really can't tell you what to try next, but I figure this info alone will
help a good number of people.
Hal
------------------------------
Date: Mon, 12 Sep 2005 08:51:19 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Space (\s) count problem
Message-Id: <slrndib1un.rg8.tadmc@magna.augustmail.com>
Huub <> wrote:
>
>> perldoc -f tr
>>
>> tr/// The transliteration operator. Same as "y///". See perlop.
>>
>> perldoc perlop
>>
>
> I have tried to get into the FAQ html, but get a timeout each time.
There is no reference to the Perl FAQ in what I wrote.
There is no reference to HTML in what I wrote.
Have we entered the "Twilight Zone"?
The docs for your perl should be on your hard disk already, no need
for an internet connection to access them.
>>>Apart from that, I want to actually read each
>>>character (into an array) until the white space is reached.
>>
>> Then you misled us with your poor choice of Subject header.
>>
>
> Not really.
Yes really.
You said you wanted to count characters.
Someone told you how to count characters.
You said that you want to store characters too.
If you keep changing the specification the problem will never be solved.
>>>array is e.g. @woord1(1..$max1),
>> Arrays in Perl are indexed inside of [square] brackets, not (parenthesis).
>
> I started out with [] but got an error. So I tried this an didn't get an
> error.
You should avoid practicing cargo-cult programming such as that.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 12 Sep 2005 10:50:44 -0700
From: rich@newsguy.com
Subject: Re: Trouble with passing quotes to perl program
Message-Id: <dg4f5k01t8m@drn.newsguy.com>
In article <k8iVe.10791$_84.3381@newsread1.news.atl.earthlink.net>, Julie
says...
>
>I am trying to send to a perl program with parameters that have quotes in
>them:
>my "special" day
>shoe measures 3.5" in length
>etc
>etc
>
>the program automatically takes parameters as quotes like
>test.pl "arg1" "this is arg2" "this is arg3"
>and it works fine for the items without quotes, but If I pass the above
>examples with the quotes, the args get messed up.
>
>what can I do to preserve the quotes?
>
>Thanks in advance
>
>
It doesn't sound like a problem with the Perl program, but maybe how they're
being formatted before being sent to it. You may need to modify the sending
program to append a \ before any " characters, then put quotes on both ends of
the text string before adding it as a parameter. That way the end result would
look similar to this...
test.pl "my \"special\" day" "shoe measures 3.5\" in length"
That way $ARGV[0] and $ARVG[1] would keep the original quotes.
Rich
--
Newsguy -- http://newsguy.com
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 8409
***************************************
