Newbie Help with Hashes

J

James Bonanno

Hello;

I've written a basic program that will scan a directory, and then
build a basic tree and turn that into HTML. The program is using the
File::Find::Rule and HTML::Template modules. I am building a basic
"project manager/reporting" software. I've arranged all my projects on
my computer in this strucutre:

Projects
--- Project1
----------Visio
----------Word
----------Schematics
----------Verilog
--- Project2
----------Visio
----------Word
----------Schematics
----------Verilog

. . . and so on. What I really want to do is to be able to have
"irregular" numbers of subprojects under each project, and gracefully
handle them with my code. For example, if Project1 contained a
subdirectory "Excel" in addition to Visio,Word,Schematic, and Verilog,
I'd like the program to be able to handle that rather than having a
"fixed number" of subprojects. My code is shown below, where the my
%row hash is the problem. I want to be able to make proj1, proj2,
proj3 a "dynamic size". I'm a newbie at perl, please forgive my
approach if another is clearly more obvious. Any suggestions are
welcome.
Thanks,

James

use File::Find::Rule;
use HTML::Template;

$root = "C:/DATA_JAMES/Projects/";
@projects_to_display = &dirscan_root("$root");

# Build an array of project names
@projects = &dirscan("$root");

# Build a hash of multi-value keys associating
# each project with its various subprojects/subdirectories
foreach $dir ( @projects ) {
$HoA{$dir} = [dirscan_root($dir)];
}

my $template = HTML::Template->new(filename => 'Find_Dir.html');
my @loop; # the loop data will be put in here

# fill in the loop, sorted by directory name
foreach my $name (sort keys %HoA) {
# get the directory and three proejcts from HoA hash
my ($dir, $proj1, $proj2, $proj3) = @{$HoA{$name}};
# make a new row for each project - the keys are <TMPL_VAR> names
# and the values are subprojects
my %row = (
dir => $name,
proj1 => $proj1,
proj2 => $proj2,
proj3 => $proj3,
);

# put this row into the loop by reference
push(@loop, \%row);
}
$nowstring = localtime;
# call param to fill in the loop with the loop data by reference.
$template->param(project_loop => \@loop);
$template->param(path => $nowstring);
print "Content-Type: text/html\n\n";
# print the template
print $template->output;

# This function scans the given directory and returns
# every subdirectory
sub dirscan_root{
$dir_to_scan = shift(@_);
@tree=File::Find::Rule->directory->relative->maxdepth(1)->in
("$dir_to_scan");
shift(@tree);
return (@tree);
};

# This function scans the given directory and returns
# an array with subdirectories indicated with a full path
sub dirscan{
$dir_to_scan = shift(@_);
@tree=File::Find::Rule->directory->maxdepth(1)->in("$dir_to_scan");
shift(@tree);
return (@tree);
};
 
J

James Bonanno

mooseshoes said:
<snip>

What I really want to do is to be able to have

<<< It appears that you may be in need of data strucure with an extra
dimension. Consider using an HoAoA so you can have varying numbers of
items per project. The best way to think of this data structure is a "hash
whose value references an array which references a second array." That
should help you add and extract items from it. Be sure to check out
various helpful perldocs on data structures and references.

Moose

====> Thanks Moose. I will look at the problem using the HoAoA approach. Kind
Regards, James
 
T

Tad McClellan

James Bonanno said:
use File::Find::Rule;
use HTML::Template;


You are missing these:

use strict;
use warnings;

@projects_to_display = &dirscan_root("$root");


Three different mistakes all folded in to a single line of code.

Impressive! :)

my @projects_to_display = dirscan_root($root);


Declare your variables (use strict will _require_ you to do so).

Don't use ampersand on function calls (see perlsub.pod for what
that form of function call does).

perldoc -q vars

What's wrong with always quoting "$vars"?
 
I

Iain Truskett

* Purl Gurl <[email protected]>:

(quoted text by
- Joseph N. Hall, Effective Perl Programming
co-authored by Randal Schwartz
)

[...]
"Not everything runs cleanly under -w or use strict.
...starting off examples with my($this, $that) isn't
going to make them more readable....

The full quote:

Not everything runs cleanly under -w or use strict (see
Item 36). I advise all Perl programmers to make use of
both -w and use strict regularly. However, starting off
all the examples with my($this, $that) isn't going to
make them more readable, and it's readability that's
important here.

What he's saying here is that having all the appropriate
declarations and stuff in his examples in the book would be
counter productive.
...individual warnings cannot be turned on or off....
...no lexical scoped warnings....

Out of date. These were both introduced in 5.6.
...warnings impose a small speed penalty on programs.

Irrelevant in most cases. Remember that EPP was released in
1997. The speed of the average machine has improved
dramatically and any speed loss from warnings is superbly
paid off by you always getting them. See fatal warnings
below.
...use -w at least long enough that the results are
no longer suprising...

The full quote:

I recommend that programmers new to the Perl language,
regardless of their experience in other languages, use
-w at least long enough that the results are no longer
surprising. You should also use -w in combination with
use strict when developing code for important
applications or for public distribution. Of course, if
you are an "all warnings, all the time" sort of
programmer, just turn it on and keep it on.
Warnings should be turned off for code that is released
to the world."

Which, in my opinion, is not good. That last sentence
(sloppy editing you've been doing, Purl Gurl) goes on to
say:

"[...] much as assert() tests shouldn't be compiled into
final versions of C programs."

For a view opposite to the one in EPP, see "The Pragmatic
Programmer" by Dave Thomas and Andy Hunt, page 123. The gist
is that it's better to have a program stop than to go on
blindly, potentially corrupting data.

And in 5.6, you can even do:

use warnings FATAL => 'all';

which makes all warnings into errors. Look! Automatic
assertions. Marvellous.
"Learn how to use Perl effectively."
- Kira

Please. Do. For a start, remember to think about what you
read, rather than blindly agree. Some of your other posts
decry Cargo Culting. I recommend you do the same -- Culting
is bad whether it's from books or from usenet.



cheers,
 
T

Tassilo v. Parseval

Also sprach Purl Gurl:
Tad McClellan wrote:


Those are development tools and should be used when needed.
Dogmatic inclusion in all scripts serves no purpose and is
bad advice. Learn about strict and warnings rather than
simply toss them in because someone told you to do so.

Like all "things" in programming, strict and warnings offer
advantages and disadvantages. For some circumstances, use of
either can create more problems than resolved, although both
are generally good development tools.

Use strict and use warnings when you need help developing
a Perl script or to help you find problems later. Use both
if you are a beginner, after learning what they do, and
do not do.

Remove strict and warnings in a final script version to
improve efficiency, and to avoid security pitfalls.

You wont improve the efficiency by removing warnings or strict by a
measurable degree. Two third of strictures happen at compile-time for
instance.

Warnings wont do harm either since the code to check for warnings is
executed regardless of whether you have warnings enabled or not (it has
to be like that, otherwise perl can't figure out whether to warn or
not).

So the only slow-down warnings infer is when emitted a message to
stderr. But you usually use warnings in order to wipe out these warnings
during the development stage so this slow-down shouldn't ever happen.

Tassilo
 
T

Tassilo v. Parseval

Also sprach Purl Gurl:
Tassilo v. Parseval wrote:

This is untrue. Joseph Hall, in his book "Effective Perl Programming,"
which is co-authored by Randal Schwartz, verifies a loss of efficiency.
You read my direct quote of Joseph Hall.

Yes, I read it. Nonetheless I think the statement's wrong.

The person who comes up with this assertion should actually explain to
me how this can happen on the C source-level.
Previously, you have read my periodic articles providing benchmark
results on this topic. My tests measure a two percent to six percent
increase in efficiency by removing strict and warnings. Actual increase
in efficiency is directly proportionate to script complexity, with
warnings exhibiting the greater effect on script efficiency.

I remember very well having made a benchmark myself (and posted here)
that exhibits the opposite of what you claim to have figured out. I
might add: I don't have real faith in your benchmarking-skills.

Search google-groups.
Three well known experts disagree with you.

Joseph Hall and Randal L. Schwartz...I fail to spot the third one.

Tassilo
 
J

James Bonanno

You are missing these:

use strict;
use warnings;




Three different mistakes all folded in to a single line of code.

Impressive! :)

my @projects_to_display = dirscan_root($root);


Declare your variables (use strict will _require_ you to do so).

Don't use ampersand on function calls (see perlsub.pod for what
that form of function call does).

perldoc -q vars

What's wrong with always quoting "$vars"?

Tad;

I recommend to you to seek a Master of Business Administration degree
with a concentration in marketing. In that course of learning, you
will discover more strategic marketing concepts for your consulting
business rather than flaming a rather straightforward question on a
discussion group.

James
 
U

Uri Guttman

JB> Tad;

JB> I recommend to you to seek a Master of Business Administration
JB> degree with a concentration in marketing. In that course of
JB> learning, you will discover more strategic marketing concepts for
JB> your consulting business rather than flaming a rather
JB> straightforward question on a discussion group.

and you are a fool if you think that was flaming. tad pointed out some
very common newbie bugs and problems with your code. as you are also
under the spell of moronzilla, the local troll. she may have satisfied
your current perl need but wait until you disagree with her or get into
a problem space where she won't tread (which is most of perl itself, she
sticks to simple text stuff and no regexes or refs - baby perl in the
extreme).

so go along your merry perl life and realize that you are backing the
wrong side here. search google for the history of tad's posting and of
moronzilla's. if you can't see the difference, you belong to her and woe
is you.

and this is not a flame even though you will probably take it as such.

uri
 
I

Iain Truskett

* Purl Gurl said:
Iain said:
Purl Gurl wrote: (snipped)
(quoted text by
- Joseph N. Hall, Effective Perl Programming
co-authored by Randal Schwartz [...]
The full quote:
Not everything runs cleanly under -w or use strict (see
Item 36). I advise all Perl programmers to make use of
both -w and use strict regularly. However, starting off
all the examples with my($this, $that) isn't going to
make them more readable, and it's readability that's
important here.
What he's saying here is that having all the appropriate
declarations and stuff in his examples in the book would be
counter productive.
Same logic applies for code examples posted to this group.
More often than not, you boys use a lack of strict and warnings
in posted code examples, to legitimize flaming an author.

"you boys".

Anyway. Often the problem in the code is clearly illustrated
by perl itself if the author enables strict and warnings.
Often the author was ignorant of strict and warnings and
should be enlightened. Often the only person who will regard
it as flaming is you.

As Mr Hall and Mr Schwartz write (though I've often wondered
about what it was that Mr Schwartz wrote as the book says
"with" rather than "and"):

I recommend that programmers new to the Perl language,
regardless of their experience in other languages, use
-w at least long enough that the results are no longer
surprising.
Otherwords, you are looking for an excuse to troll.

Just as you do when you see people recommend strict and
warnings or any other good practice.
Additionally, you boys dogmatically preach all scripts should
* always * include strict and warnings. That is bad advice
especially in lieu of you boys not mentioning problems which
can about, by following your dogmatic dictates.

"you boys". "can about".

It's good advice. Perhaps the advice could be augmented to
point to the documentation for strict and warnings so any
problems are brought to the original poster's attention?

First stage: the programmer doesn't know about strict or
warnings and blithely programs away, periodically wondering
why his or her program doesn't work, sometimes spotting
misnamed variables or realizing that variables don't have
values at various places (among other things). Maybe they
wonder if that stuff can be found automatically? Maybe they
give up on Perl because they don't know that it can be?

Second stage: the programmer finds out about strict and
warnings. And they use it. They suddenly find they can find
stupid errors faster, sometimes they'll also see warnings
about their variables having values they shouldn't (or,
rather, not having values when they should). If they're
lucky, they discover "use warnings FATAL => 'all';".

Third stage: They understand what strict and warnings are
offering and know enough Perl to write code that may need
strict 'refs' disabled, or something like that. They know
when and when not to use features of the language.

In short:
1 - Ignorance
2 - Practising
3 - Understanding

It's a road they should undertake themselves.

[..]
My guess is Perl version 5.6.x is the most used version of
Perl.

Excellent. You're not disagreeing with what I say. In fact,
it's a statement that supports what I say. Superb.
Perl version 5.8.x is not very popular and, a guess,
often removed after installation because it breaks scripts
and because it is so buggy.

Curious. Didn't break any of mine. Maybe I should stop
writing code that is strict and warning clean? That way I
might experience some of this pain.
It would be of interest to locate statistics on which
version of Perl is most often used by individuals and
servers. I strongly suspect, this would be Perl 5.6 or
lower.

I suspect the former will be 5.6 or later while the latter
will be 5.6 or earlier. That said, most servers have at
least 5.005_03 these days with 5.004 remaining only in
either places it isn't used or places where progress is
inhibited by lack of a good testing environment (I speak
from experience there).

As 5.6 is "the most used version", then we should certainly
mention the use of its features, such as the warnings pragma.
A two to six percent loss in script efficiency is not
irrelevant. This is an unacceptable amount of efficiency
loss.
My presumption is you hold an opinion both Joseph Hall and
Randal Schwartz are wrong about this.

I think you forgot the word "that". Your presumption is
incorrect. From what the book you're quoting says:

Run-time warnings impose a small speed penalty on
programs.

The 2-6% figure is one you came up with, correct? Forgive me
for not trusting your skills at benchmarking.

2-6% loss _is_ irrelevant. If you disagree, perhaps you
should be writing in C rather than Perl? After all, the
difference there is far greater. Worry yourself more about
50% loss. Or even 15-20%. 2-6% is negligible and often
amortized by the recovery.
Then you are writing insecure Perl scripts and advising others
to do the same. This is not wise.

'insecure'. Please, go on. Particularly in the case of 5.6's
fatal warnings, I'm currently failing to see how having code
that will abort if it reaches an inconsistent state and also
forces the programmer to take more care with their data is
making a program 'insecure'. The opposite is more probable.

There's arguably a case for when your program is being run
on different versions of Perl and thus particular warnings
may appear or not. This is a feature though as it indicates
precisely where you should examine your code to ensure that
its behaviour is correct for that edition of Perl. Without
the warning, your program could be getting itself into knots
and quite probably doing something you'll regret when you
get the results.

Not good when you're dealing with important things.
I agree with both Joseph Hall and Randal Schwartz on this.

Good for you. In other let's quote another book now:

"[5] You are using warnings, right? You can enable them
with either -w or use warnings;"

(look, he's humorously assuming you're using warnings)

"If you tried running this, Perl may have given you a
helpful diagnostic message as a warning. If you didn't
get the warning, perhaps you didn't have warnings turned
on, either with the -w switch or with the use warnings
pragma. Even if you don't usually use Perl's warnings,
you should enable them during debugging. (How long would
it take you to debug this without Perl's warnings to
help you? How long would it take to enable Perl's
warnings? 'Nuff said.)"

(both from "Learning Perl Objects, References and Modules"
--- Randal Schwartz.)
You are flaunting your ignorance which is poorly veiled by
verbosity.

Whereas yours is exceptionally poorly veiled by inarticulacy?
English is a wonderful language. Forgive me I indulge in the
pleasure of using it. I far prefer to clarify and refine my
meaning than to offer short, sharp statements that are likely
to be misconstrued due to perceptions and misperceptions of
the meanings of the words I choose.


cheers,
 
H

Helgi Briem

I recommend to you to seek a Master of Business Administration degree
with a concentration in marketing. In that course of learning, you
will discover more strategic marketing concepts for your consulting
business rather than flaming a rather straightforward question on a
discussion group.

Tad McCellan is a genuine Perl expert. You would
be well advised to take his recommendations seriously.

If you consider his post "flaming" you haven't been
around Usenet very long. I can see no sign of flaming
in his post.

You would also be well advised to ignore any and
all recommendations given by "Purl Gurl", aka Godzilla
aka Kira. He/she/it is a troll who comes here for the
sole purpose of inciting arguments, sowing disinformation
and misleading beginners with false advice.
 
T

Tad McClellan

James Bonanno said:
(e-mail address removed) (Tad McClellan) wrote in message


Tad;

I recommend to you to seek a Master of Business Administration degree
with a concentration in marketing.


Thank you for your concern, but my Master of Software Engineering
degree is much more useful as an independent.

Consultants sell their expertise, I sell software engineering services,
I don't consult on administering businesses.

In that course of learning,


Where did you get _your_ MBA from?

I'm having difficulty evaluating the value of your recommendation,
as I am unaware of your qualifications.

I'm sure you are speaking from experience, I just cannot locate
any evidence of it.

Has your MBA helped with your consulting business?

you
will discover more strategic marketing concepts for your consulting
business


I've been self-employed as a consultant for 6 years, I know from
experience what it takes to continue independently.

How long have you been on your own?

rather than flaming a rather straightforward question on a


That was not a flame.

You posted code that contained mistakes...

discussion group.


.... and I discussed the mistakes.

Would you have instead preferred to keep making those mistakes?


If you think my advice was incorrect, or you don't understand
why I suggested what I did, then please followup asking for
clarification.

If you think my advice was sound, then what is the problem?

I discussed Perl here. It appears that you couldn't find anything
to say about my Perl advice, so you had to dip down into the .sig
to find something to talk about.


Resorting to ad hominem is a clear indication of which side of
a discussion is in the weaker position.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,819
Latest member
masterdaster

Latest Threads

Top