[22870] in Perl-Users-Digest
Perl-Users Digest, Issue: 5091 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jun 7 18:10:31 2003
Date: Sat, 7 Jun 2003 15:10:09 -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 Sat, 7 Jun 2003 Volume: 10 Number: 5091
Today's topics:
Re: Strange errors with huge hash <flavell@mail.cern.ch>
Re: Strange errors with huge hash <res1uzbe@verizon.net>
Re: Strange errors with huge hash <uri@stemsystems.com>
Re: Strange errors with huge hash <res1uzbe@verizon.net>
Re: Strange errors with huge hash <uri@stemsystems.com>
Re: Strange errors with huge hash <res1uzbe@verizon.net>
Re: Strange errors with huge hash <bwalton@rochester.rr.com>
Re: Strange errors with huge hash <res1uzbe@verizon.net>
Re: Strange errors with huge hash <res1uzbe@verizon.net>
Re: Strange errors with huge hash (Michael G.)
Re: Strange observation (Go Perl)
Re: Unable to lock array <bob@nowhere.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 7 Jun 2003 20:07:18 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Strange errors with huge hash
Message-Id: <Pine.LNX.4.53.0306071957410.11037@lxplus081.cern.ch>
On Sat, Jun 7, emcee inscribed on the eternal scroll:
> Whether I can or am allowed to are two different things, most of the
> services I use have clauses in their terms about running binary code.
"Own modules" and "binary code" are two different issues, though.
> > If, on the other hand, you had said that you were writing your own
> > modules as a learning exercise, even though you wouldn't necessarily
> > use them in production for preference, then I think you'd have rated
> > to get a more sympathetic hearing here - what say the regulars?
>
> This is why I'm always hesitant about going here for help,
Is that really supposed to be a response to what I just said?
> nobody can just except the code as it is and help you with it,
> instead they insist on critiquing portions of it unrelated to the
> problem.
I'm pretty-much an amateur around here, but you get here the
collective wisdom of a whole bunch of production-hardened
professionals who would like to see you doing a good job. They
understandably can't and won't shut their eyes to any issues that they
see in postings, irrespective of whether the questioner _thought_ they
were relevant to their immediate problem. I feel I've learned a lot
from them: the last thing I would want to do would be to try and
impose rules on what they may or may not comment on when a question is
raised.
As for the policies of server hosts: if they force their customers to
use their own worst efforts at re-invented wheels in preference to
using peer-reviewed and debugged modules, then they pretty-much
deserve their servers to be infested with the kind of insecure
Matt-factor cargo cult code that the regulars here wouldn't be seen
dead associating themselves with.
good luck (you may well need it :-} )
------------------------------
Date: Sat, 07 Jun 2003 18:35:01 GMT
From: emcee <res1uzbe@verizon.net>
Subject: Re: Strange errors with huge hash
Message-Id: <pfqEa.62152$Pb.57535@nwrddc01.gnilink.net>
Uri Guttman wrote:
> that makes no sense at all. how can you run your own code and not other
> code? and what does that have to do with binary stuff? and data::dumper
> which was recommended comes with perl already and works fine. so why
> reinvent that wheel and with bugs to boot?
If the premade option is just pure perl why bother? When I first needed
this module I looked into data::dumper, it was more than I need, why
load 586 line module (minus comments and pod) when my 76 line module
does only what I need it to, and works fine save for a single bug that
has only showed up once when dealing with a very large hash, and could
likely be solved without alot of trouble.
> no, you post here, it becomes an open discussion. you can't control what
> people write here. hell, we can't get moronzilla to shut up.
When did I say I could control what people write here?
> your choice. but your real problem has been addressed. it is your fault
> if you don't accept the answers and not the groups for feeding you what
> you think you need. that attitude is very bad for any coder or
> professional.
No, my problem was that when evaling code that stores a large hash, perl
give errors that don't appear to be there, atleast not at the place it
says. Nobody has addressed that, instead they've addressed that what
module I use.
------------------------------
Date: Sat, 07 Jun 2003 18:44:51 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Strange errors with huge hash
Message-Id: <x7r865wwv0.fsf@mail.sysarch.com>
>>>>> "e" == emcee <res1uzbe@verizon.net> writes:
e> Uri Guttman wrote:
>> that makes no sense at all. how can you run your own code and not
>> other code? and what does that have to do with binary stuff? and
>> data::dumper which was recommended comes with perl already and
>> works fine. so why reinvent that wheel and with bugs to boot?
e> If the premade option is just pure perl why bother? When I first
e> needed this module I looked into data::dumper, it was more than I
e> need, why load 586 line module (minus comments and pod) when my 76
e> line module does only what I need it to, and works fine save for a
e> single bug that has only showed up once when dealing with a very
e> large hash, and could likely be solved without alot of trouble.
you are not making any sense. you have a bug, data::dumper doesn't. the
line count doesn't matter if it works and your code doesn't.
how much time did you take to write you broken code? how much time would
you have saved using a working module? how much time have you wasted
here (and who knows where else) trying to fix your bug? your time should
be more valuable to you than some dumb notion of it has too many lines
and does more than i need. your priorities are screwed up.
>> no, you post here, it becomes an open discussion. you can't control
>> what people write here. hell, we can't get moronzilla to shut up.
e> When did I say I could control what people write here?
you said:
This is why I'm always hesitant about going here for help,
nobody can just except the code as it is and help you with it,
instead they insist on critiquing portions of it unrelated to
the problem.
that is requesting that people only answer your code questions and not
unrelated stuff. that is requesting control over what people post in
response to your post. you imply you want control and i said you can't
get it. simple. please learn to follow the thread.
>> your choice. but your real problem has been addressed. it is your
>> fault if you don't accept the answers and not the groups for
>> feeding you what you think you need. that attitude is very bad for
>> any coder or professional.
e> No, my problem was that when evaling code that stores a large hash,
e> perl give errors that don't appear to be there, atleast not at the
e> place it says. Nobody has addressed that, instead they've
e> addressed that what module I use.
and you have not shown your code, your generated code or anything else
that would help. you just whined about how data::dumper isn't good enoug
for you or you can use it or you can't install modules or some other
crap. so you don't get answers like you expect since you don't give out
information that can allow us to fix your bug. but in any case, i still
say you should use data::dumper. you have not stated a single (even
close to) valid reason why you shouldn't use it. it works, it is on your
system and eval works with it just fine. so go ahead and spend more time
on this and whine some more. the answer is still to use data::dumper.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sat, 07 Jun 2003 18:57:42 GMT
From: emcee <res1uzbe@verizon.net>
Subject: Re: Strange errors with huge hash
Message-Id: <GAqEa.62170$Pb.5107@nwrddc01.gnilink.net>
Uri Guttman wrote:
>>>>>>"e" == emcee <res1uzbe@verizon.net> writes:
> you are not making any sense. you have a bug, data::dumper doesn't. the
> line count doesn't matter if it works and your code doesn't.
>
> how much time did you take to write you broken code? how much time would
> you have saved using a working module? how much time have you wasted
> here (and who knows where else) trying to fix your bug? your time should
> be more valuable to you than some dumb notion of it has too many lines
> and does more than i need. your priorities are screwed up.
I like to take a little more time and make more efficent code. I guess
that may not be your coding style, but that's ok because its not your code.
> that is requesting that people only answer your code questions and not
> unrelated stuff. that is requesting control over what people post in
> response to your post. you imply you want control and i said you can't
> get it. simple. please learn to follow the thread.
I would prefer people people address my problem rather than unrelated
issues they have with my code, but I understand I have no control over
what people write.
> and you have not shown your code, your generated code or anything else
> that would help.
Yes, I have, I gave an exact excerpt of the generated code perl takes
issue with, I can't give the entire thing since its over 4800 lines long.
------------------------------
Date: Sat, 07 Jun 2003 19:16:37 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Strange errors with huge hash
Message-Id: <x7n0gtwve3.fsf@mail.sysarch.com>
>>>>> "e" == emcee <res1uzbe@verizon.net> writes:
e> Uri Guttman wrote:
>>>>>>> "e" == emcee <res1uzbe@verizon.net> writes:
>> you are not making any sense. you have a bug, data::dumper
>> doesn't. the line count doesn't matter if it works and your code
>> doesn't. how much time did you take to write you broken code? how
>> much time would you have saved using a working module? how much
>> time have you wasted here (and who knows where else) trying to fix
>> your bug? your time should be more valuable to you than some dumb
>> notion of it has too many lines and does more than i need. your
>> priorities are screwed up.
e> I like to take a little more time and make more efficent code. I
e> guess that may not be your coding style, but that's ok because its
e> not your code.
if you are concerned with efficiency before correctness, then i am glad
it is not my code. premature optimization is evil. you have yet to learn
that. and since your servers are those barebones massively shared ones,
who cares how fast a hit takes?
>> that is requesting that people only answer your code questions and
>> not unrelated stuff. that is requesting control over what people
>> post in response to your post. you imply you want control and i
>> said you can't get it. simple. please learn to follow the thread.
e> I would prefer people people address my problem rather than
e> unrelated issues they have with my code, but I understand I have no
e> control over what people write.
>> and you have not shown your code, your generated code or anything
>> else that would help.
e> Yes, I have, I gave an exact excerpt of the generated code perl
e> takes issue with, I can't give the entire thing since its over 4800
e> lines long.
you haven't shown the original data structure, the code that spits out
that part of it and enough of the output code. and now you claim it is
4800 lines long when before you claimed your version of dumper was only
76 lines long? make up your mind. the problem is supposedly in your
dumper rewrite and not with the massive rest.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sat, 07 Jun 2003 19:31:19 GMT
From: emcee <res1uzbe@verizon.net>
Subject: Re: Strange errors with huge hash
Message-Id: <b4rEa.62180$Pb.53874@nwrddc01.gnilink.net>
Uri Guttman wrote:
> if you are concerned with efficiency before correctness, then i am glad
> it is not my code. premature optimization is evil. you have yet to learn
> that. and since your servers are those barebones massively shared ones,
> who cares how fast a hit takes?
Ok, lets say I made a non-optimised system for storing a hash. I would
have used Data::Dumper, that obviously works fine, I can move on to an
optimised solution.
I care how long a hit takes, and if the script is ran alot I'm sure the
sysadmin will as well.
> you haven't shown the original data structure, the code that spits out
> that part of it and enough of the output code. and now you claim it is
> 4800 lines long when before you claimed your version of dumper was only
> 76 lines long? make up your mind. the problem is supposedly in your
> dumper rewrite and not with the massive rest.
>
> uri
>
No, the generated code is 4800 lines, the module is as follows:
package msh;
use File::Spec;
$path=File::Spec->rel2abs($INC{'msh.pm'});
$path=~s/msh\.pm$//;
mkdir($path."data") unless -e($path."data");
use safe;
$cpt=new Safe;
sub clear_errors
{
$!=undef;
$@=undef;
}
sub error
{
$last_error=$_[0];
0;
}
sub create_hash
{
&clear_errors;
open(HASH, ">$_[0]") or return 0;
close(HASH);
open(HASH, "$_[0]") or return 0;
1;
}
sub open_hash
{
&clear_errors;
$hashes{$_[1]}=$_[0];
(open(HASH, $path."data/$_[0].msh") or
create_hash($path."data/$_[0].msh")) or return &error($!);
flock(HASH,1);
$cpt->reval(join '', <HASH>);
close(HASH);
return &error($@) if $@;
%{$_[1]}=%Safe::Root0::hash;
$last_hash=$_[1];
1;
}
sub save_hash
{
($hash=shift or $hash=$last_hash) or return &error('No hash open');
($file=shift or $file=$hashes{$hash}) or return &error('That hash
isn\'t open');
open(HASH, '>'.$path."data/$file.msh") or return &error($!);
flock(HASH,2);
$hasht=undef;
$hasht.='%hash=(';
&walk($hash, keys %{$hash});
chop $hasht;
print HASH $hasht;
print HASH ');';
close(HASH);
1;
}
sub walk
{
my $hash=shift;
foreach(@_)
{
s/'/\'/g;
s/\\/\\\\/g;
if(ref $hash->{$_})
{
$hasht.="'$_'=>{";
&walk($hash->{$_}, keys %{$hash->{$_}});
chop $hasht;
$hasht.="},";
}
else
{
$hash->{$_}=~s/'/\'/g;
$hash->{$_}=~s/\\/\\\\/g;
$hasht.="'$_'=>'$hash->{$_}',";
}
}
}
1;
------------------------------
Date: Sat, 07 Jun 2003 20:24:09 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Strange errors with huge hash
Message-Id: <3EE24949.7040603@rochester.rr.com>
emcee wrote:
> Uri Guttman wrote:
>
...
> use File::Spec;
...
Hmmmm...interesting philosophy here. You won't
use Data::Dumper;
but you will
use File::Spec;
Why didn't you rewrite File::Spec too?
--
Bob Walton
------------------------------
Date: Sat, 07 Jun 2003 20:29:25 GMT
From: emcee <res1uzbe@verizon.net>
Subject: Re: Strange errors with huge hash
Message-Id: <FWrEa.62331$Pb.60016@nwrddc01.gnilink.net>
Bob Walton wrote:
> emcee wrote:
>
>> Uri Guttman wrote:
>>
> ...
>
>> use File::Spec;
>
>
> ...
>
> Hmmmm...interesting philosophy here. You won't
>
> use Data::Dumper;
>
> but you will
>
> use File::Spec;
>
> Why didn't you rewrite File::Spec too?
>
It was the only way I could get the full path to the module, or else I
would have left it out altogether.
------------------------------
Date: Sat, 07 Jun 2003 20:52:26 GMT
From: emcee <res1uzbe@verizon.net>
Subject: Re: Strange errors with huge hash
Message-Id: <egsEa.62452$Pb.9207@nwrddc01.gnilink.net>
emcee wrote:
> package msh;
> use File::Spec;
> $path=File::Spec->rel2abs($INC{'msh.pm'});
> $path=~s/msh\.pm$//;
> mkdir($path."data") unless -e($path."data");
>
> ect...
>
> $hash->{$_}=~s/'/\'/g;
> $hash->{$_}=~s/\\/\\\\/g;
> $hasht.="'$_'=>'$hash->{$_}',";
> }
> }
> }
> 1;
>
So does no one has any ideas what I'm doing wrong here (except of course
using a custom module), or is no one willing to help me?
Remember it works fine pretty all time except for this particular
instance involving a very large hash. Should I be escaping something I'm
not before adding it to the file? Would it help if I walk through what
each part does?
------------------------------
Date: Sat, 07 Jun 2003 20:56:45 GMT
From: uhuh@nono.net (Michael G.)
Subject: Re: Strange errors with huge hash
Message-Id: <3ee25104.78358203@news.charter.net>
On Sat, 7 Jun 2003 20:07:18 +0200, "Alan J. Flavell"
<flavell@mail.cern.ch> wrote:
[...]
>As for the policies of server hosts: if they force their customers to
>use their own worst efforts at re-invented wheels in preference to
>using peer-reviewed and debugged modules, then they pretty-much
>deserve their servers to be infested with the kind of insecure
>Matt-factor cargo cult code that the regulars here wouldn't be seen
>dead associating themselves with.
"Cargo cult code" is pretty clear to me, but what do you mean by
"Matt-factor?" Enquiring minds want to know...
------------------------------
Date: 7 Jun 2003 11:57:24 -0700
From: puissant00@yahoo.com (Go Perl)
Subject: Re: Strange observation
Message-Id: <d3825316.0306071057.647676b@posting.google.com>
Basically there are 18 fields in the input line 15 are present and are
assigned some values 16 and17 the application takes default value and
the 20the field is the identifier 70. which i am trying to compare and
hence the ifels loop to compare the $read==70 or not. My problem is
there are 80 columns and each numberis given 4 columns. If i use
$read[7]==70 it is working and printing the numbers but if i use
$read[16]==70 its not working which it is supposed to and the line
formatting is same %4d * 15 %20d = 80 columns 15 for 15 numbers and
then forgetting some default values after these numbers nad moving to
end of the line which is 70 hence %20d. Now my question is why is the
order not working like read[16] as the end of the line and read[7] is
working fine.
------------------------------
Date: Sat, 07 Jun 2003 13:57:03 -0500
From: bob <bob@nowhere.com>
Subject: Re: Unable to lock array
Message-Id: <3ee23572$1_1@127.0.0.1>
Why not do the 'shift udList' in the outer loop and pass the name into the
threaded process?
On Fri, 06 Jun 2003 06:50:41 -0500, Mahboob wrote:
>
> It spawns 6 threads and my initial intention is that each thread should
> grab (by shift) one file name from the list and print it. But all 6
> threads are printing the same file name. What is the fix for this?
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
------------------------------
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 5091
***************************************
