Creating 1 file w/ the contents of 7 other files mixed randomly.

[Anno Siegel]

Paul Lalli wrote:
[...]

I stand partially corrected. This will not print the warnings I had
envisioned. Although *why* it doesn't print them, I couldn't begin to
guess:
perl -we'
my @foo = (1..10);
while ($#foo > -1) {
my $i = rand(@foo);
print "$foo[$i] ";
delete $foo[$i];
}
'
This gives output of:
7 6 3 5 10 4 9 1 2 8
with no warnings.

Hmmm... I see the expected warnings (v5.8.7).

Anno

 

[John Bokma]

...for small values of "works". It will load the module but not
import anything from it.

Ok missed that one and hence stand corrected (I ran into it when I used
Mime::Lite, see http://johnbokma.com/mexit/2005/05/18/ )

Anyway, my point is: spell module names correctly, especially when bashing
a newbie ( I mean: how often are "we" telling people to copy paste
instead to type?)

 

[Harry]

Wow, you must be a brave little coder, posting a Perl4 Matt Wright script
here. And one that only prints a single line from a file instead of
randomising the entire file.

I'm no coder.
I search instead.

another one to go.

ftp://ftp.lscp.ehess.fr/pub/pallier/shuffle.zip

 

[Paul Lalli]

Paul Lalli wrote:

perl -we'
my @foo = (1..10);
while ($#foo > -1) {
my $i = rand(@foo);
print "$foo[$i] ";
delete $foo[$i];
}
'
This gives output of:
7 6 3 5 10 4 9 1 2 8
with no warnings.

Hmmm... I see the expected warnings (v5.8.7).

Huh. Interesting. I only tested with with 5.6.1 (solaris), and got no
warnings. I just tested again with the other two versions available to
me right now... 5.8.4 (solaris) and 5.8.8 (MSWin32) do indeed give the
warnings.

Perhaps I was right originally, that this was a bug in the 5.6 release,
and 5.8 fixed it?

Good to know, in any case. Thanks, Anno.

Paul Lalli

 

[DJ Stunks]

Very much so, thank you.

Perhaps in the future, when you're looking for advice or 'constructive
criticism', you will be more open to suggestions, rather than
stubbornly digging in your heels and forcing people to take time to
explain the reasons behind elementary programming concepts in small,
one syllable words you can clearly understand.

By the way, frequently one is their own 'maintenance programmer' and
every element of style - including variable names, scoping, and
indentation - will save you time and headaches in the future and will,
in turn, help you become a better, more efficient programmer.

And buy _Perl Best Practices_ by Damian "Pastor" Conway and read it.
Cover to cover.

-jp

 

[Uri Guttman]

H> I'm no coder.
H> I search instead.

H> another one to go.

H> ftp://ftp.lscp.ehess.fr/pub/pallier/shuffle.zip

if it ain't on cpan, it ain't worth looking at. this is not a comment on
the code but the coder. note that almost no scripts derived from matt's
or selena or other similar code is on the cpan. you should search cpan
before you search the web for perl stuff.

uri

 

[Charles DeRykus]

This is a common misperception. Adding to the confusion is the fact
that this expectation *is* exactly how delete works on hashes.

I recommend:
1) making sure you read `perldoc -f delete`
2) never using delete() on arrays. Instead, use splice() (and read
`perldoc -f splice`)

Agree totally. I'd like to chime in with a doc suggestion too:

delete EXPR
Given an expression that specifies a hash element,
array element, hash slice, or array slice, deletes
the specified element(s) from the hash or array.
...


Although, the existing doc opener above spells out the differing
semantics later on, this immediately seeds confusion.

An emphatic, early statement and re-ordering some of the deferred
array explanations would help dispel confusion IMO:


Given an expression that specifies a a hash element or hash
slice, deletes the specified element(s) from the hash. In
contrast, deleting an array element or array slice, replaces
that element with its initial, undefined value and, if the
array elements happen to be at the end, the size of the array
will shrink to the highest element that tests true for exists()
(or 0 if no such element exists).
...

 

[Sherm Pendley]

At present I don't feel inclined to follow this practice, purely
because I still don't fully understand the difference

If you don't understand the difference, it seems to me the most prudent
thing to do would be to follow the advice of those who *do* understand
it...

(experience may change my mind of course

.... and then change your mind if/when you're experienced enough to know
when it's appropriate to do so.

sherm--

 

[Harry]

H> another one to go.
H> ftp://ftp.lscp.ehess.fr/pub/pallier/shuffle.zip

if it ain't on cpan, it ain't worth looking at. this is not a comment on
the code but the coder. note that almost no scripts derived from matt's
or selena or other similar code is on the cpan. you should search cpan
before you search the web for perl stuff.

And in the following thread...
http://groups.google.ca/group/comp....be3d0/7166b26b677b25c6?hl=en#7166b26b677b25c6


Jim Gibson wrote:
# Anybody can
# upload a module to CPAN. Some modules are well-designed and written
and
# thoroughly tested. However, that is not always the case.

kinda agree with what Jim said.

 

[usenet]

As for Paul Lalli...Put the newsgroups down for awhile dog.

I'll come back when I learn a little more about "netiquette."

One thing you will discover as you study "netiquette" is that it is
good to "lurk" for awhile in a newsgroup to get a "feel" for it before
posting there. Many newsgroups (especially technical ones) have a
changing collection of newbies (such as yourself), a few tiresome
trolls (such as robic0) and a respected core group of highly skilled
and knowledgeable experts (such as Paul Lalli). Insulting the experts
might amuse the trolls, but usually gets you ignored (killfiled) by the
other experts (Sinan has killfiled you, and if Tad has not done
likewise then it shows an uncharacteristic degree of tolerance).

CONTINUING to insult the respected experts after they have done you the
FAVOR of pointing out your errors (in very polite terms) continues to
lower your quota of goodwill. As more experts ignore or killfile you,
the quality of assistance you receive declines, because only the
newbies and trolls will see or respond to your questions.

 

[game4itguy]

If you don't understand the difference, it seems to me the most prudent
thing to do would be to follow the advice of those who *do* understand
it...


... and then change your mind if/when you're experienced enough to know
when it's appropriate to do so.

Again I'm afraid I disagree. If the object of learning Perl is indeed
to "learn" the language, then surely I would be better served by
following a flawed path and making my own mistakes rather than being
told the correct way of doing things without the slightest idea of why
they are the "correct way"? This seems to me to be the very point of
this newsgroup in fact, in terms of helping people to solve inaccurate
perl scripts rather than simply writing people's scripts for them? In
my mind mistakes are a powerful learning tool, and are much more
valuable than simply following 'best practice' and getting things right
because someone else told you how to do things. Of course in this case
it is all theoretical as Paul adequately demonstrated why, in this
instance, my own methods were wrong.

 

[game4itguy]

Perhaps in the future, when you're looking for advice or 'constructive
criticism', you will be more open to suggestions, rather than
stubbornly digging in your heels and forcing people to take time to
explain the reasons behind elementary programming concepts in small,
one syllable words you can clearly understand.

I'm sorry, but I find this a rather unjustified response. I don't
believe I "forced" anybody to reply to my questions, I merely asked for
clarification on issues I didn't fully understand. I also do not think
it is particularly wise to suggest that people who are new to Perl
should not question responses that they do not understand. Surely the
point is to learn, and if somebody like Paul is willing to explain then
all the better? And might I suggest that whilst the issues in this
thread may be considered elementary by you, for people who are new to
Perl, such as myself, they are not.

 

[A. Sinan Unur]

(e-mail address removed) wrote in

If the object of learning Perl is indeed to "learn" the language,
then surely I would be better served by following a flawed path
and making my own mistakes rather than being told the correct way
of doing things without the slightest idea of why
they are the "correct way"?

So, you won't believe boiling water is hot unless you first burn your
hand?

Of course, people can and should learn from their mistakes, but ignoring
the experience of others, and learning only through mistakes is not an
effective way to learn.

Sinan
--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html

 

[game4itguy]

(e-mail address removed) wrote in


So, you won't believe boiling water is hot unless you first burn your
hand?

Fair point, but at the same time a child who touches a steaming iron
won't touch it again. Elaborating on your metaphor and relating it to
this threat, wouldn't the stituation be one similar to the following:

Advice from those with experience: "Only make tea with boiling water."

If I'm given no reason for doing this I would have two options. a) make
tea with boiling water as suggested, enjoy the taste and never know why
I shouldn't make it with cold water. b) make tea with cold water and
realise why the advice stands.

With regard to your specific metaphor, my point is that whilst I do
*believe* there to be a reason for the suggestion ("boiling water is
hot"), if I'm not given an explanation for the statement ("because such
and such") then I have no choice but to experiment with the flawed
solution to discover the pitfall for myself ("you first burn your
hand").

 

[Uri Guttman]

g> Fair point, but at the same time a child who touches a steaming iron
g> won't touch it again. Elaborating on your metaphor and relating it to
g> this threat, wouldn't the stituation be one similar to the following:

this is called trial and error. but when coding, you have can a major
disconnect between the trial and error. let's say you write your crappy
(and it is crappy) code and it sorta works. but in 6 months you want to
change it and you can't understand your own code. the actual timeframe
for forgetting the reasons behind code decisions is more like 4
weeks. so now you have to waste time figuring out what the hell you
meant when you wrote that code. of course you haven't experienced this
and you will say, it is a fine lesson for me to learn. but it won't
happen for months or longer. in the mean time you keep writing code in
your crappy (and uncorrected) style. it accumulates and your poor coding
habits solidify which will make it even harder to change when you
finally learn why it is bad. and avoiding boiling water is a single
lesson to learn. coding style (forget about coding logic) has hundreds
of rules with reasons behind them that have been codified over 50 years
of software development. this is called experience. in all professions,
(even your legal one) experience matters. would you allow some green
lawyer to try an important case by himself and let him learn a lesson
when he loses the case? which of the many mistakes will he learn from
and who will tell him what the correct legal way should be? maybe this
analogy works for you. if it does then you should listen carefully to
your coding betters when they tell you that coding style is
IMPORTANT. it is no less important than how legal documents are
formatted and edited and that they use that gibberish known as
legalese. all coding has its own accepted conventions which includes
indenting, good name selection, minimal scoping, etc. you may not
understand why these are important but you MUST ACCEPT that they
are. us experienced pros are telling you this. now let's see if your
legal mind can handle this and if you will change your attitude. our
profession has its knowledge base of which you know little. ignoring it
is foolish. i will end with this:

a non-coder who codes for himself has a fool for a client.

<familiar?>

uri

 

[Michele Dondi]

Say I've got 7 files ( file1.txt - file7.txt) and I want to combine the
lines from all 7 files into one file (file8.txt) but I want the line
order to be randomly mixed. In other words, I want file8.txt to
contain all the lines from file1.txt through file7.txt but in random
order so that each pass produces a different file8.txt. Might someone

(Although I agree with most-everyone-else's critics on your post)

file8.txt

Michele

 

[Michele Dondi]

#/usr/bin/perl -w

use warnings; # is more flexible and thus recommended nowadays

@files = qw( file1.txt file2.txt file3.txt ); # etc.

use strict; # as well

i.e.: help perl help you not to do mistakes.

open OUT,">file8.txt";

Hmm, didn't mommy tell you to ALWAYS check the return values of
open()'s

@lines = ();

The assignment is pleonastic.

for (@files) {
open F,$_;
while (<F>) { push @lines,$_ }
};

So all in all you're reimplementing @ARGV. Whatever, since you keep
all lines anyway, why not slurp them all at once? That is

while ($#lines > -1) {

while (@lines)

$i = int(rand($#lines+1));

int rand @lines;

($_) = splice(@lines,$i,1);
print OUT;

perldoc -q shuffle


Michele

 

[Tad McClellan]

[ Sorry for piggy-backing on Sherm's post, but my news feed has gone
flaky lately, and I don't expect to ever see the post he is
replying to.
]




eg:

You should look both ways before crossing the street.


While in the form of a "dictate", that criticism is pretty
clearly "constructive", even when you do not understand why
you should do it.



You may get hit by a bus before you fully understand why you
should look both ways.

If you don't understand the difference, it seems to me the most prudent
thing to do would be to follow the advice of those who *do* understand
it...

Yeah, becoming a grease spot before you get time to do the research
could be a real bummer.



When self-teaching, you should realize that you probably are
missing many fundamentals.

When you come across one, you have basically 3 choices:

1) take a pause from what you are really doing, and go
figure out this missing fundamental.

2) take it "on faith", and maybe hope to figure it out later
(but in the meantime you get the benefit that made it a
fundamental in the first place).

3) ignore it (and learn first-hand what thousands have already
learned the hard way).


You may choose to repeat the mistakes of those that went before you,
but that is such an inefficient method of learning that a
conscientious practitioner would feel compelled to at least let
you know that you are making it harder on yourself than it needs to be.

... and then change your mind if/when you're experienced enough to know
when it's appropriate to do so.

Controlling variable scope (ie. "globals are bad!") has been
industry practice for decades, nothing specific to Perl in that.

To understand applying that fundamental to Perl, see:

"Coping with Scoping":

http://perl.plover.com/FAQs/Namespaces.html

 

[game4itguy]

g> Fair point, but at the same time a child who touches a steaming iron
g> won't touch it again. Elaborating on your metaphor and relating it to
g> this threat, wouldn't the stituation be one similar to the following:

this is called trial and error. but when coding, you have can a major
disconnect between the trial and error. let's say you write your crappy [snip]

Again, I disagree with you but I shall stop this conversation now as it
appears to have got your back up and that wasn't my intent. Although I
don't feel your style of personally attacking somebody (I've been
called many things, but a lawyer has to rank up there with the worst of
them!) you disagree with is a very productive one. Thanks to everyone
for all the replies though, I found it an interesting thread.

 

[Tad McClellan]

the issues in this
thread may be considered elementary by you, for people who are new to
Perl, such as myself, they are not.

The issues[1,2] in this thread are elementary to all of programming.

So it is not being "new to Perl" that explains your missing them,
it is being "new to programming" that explains it.

It is not far-fetched to assume that folks posting a a comp.lang.*
newsgroup are Programmers (and Programmers know many languages).

So "you should control variable scope" or "you should indent to
expose the program's structure" is most often enough for
the poster to say "Oh yeah" and be done with it.

IOW, answerers don't know what level of answer is required
when the OP says "new to Perl" when they should have said
"new to programming" instead.

OTOH, we can't really expect raw beginners to be able to distinguish
the "best practice" from "how to implement that practice in the <blank>
programming language".





[1] limiting variable scope.

[2] writing code "for humans" rather than "for machines".