Re: Here Docs
Jim Gibson wrote:
Joseph L. Casale:
Inside a here doc, how can I force an expression to be evaluated
such as localtime [...]
You can use the trick mentioned in 'perldoc -q string' How do I expand
function calls in a string?, referencing, then dereferencing an array, but
it is ugly [...]
What makes you say it is ugly?
To me it is just another useful language feature.
But it needs plenty of space. :)
I use $ in here-docs as well:
perl -wle'
my @id = 1..5;
my $sql = do {
local $ = q{,}; #
SQL;
SELECT
id
, name
FROM
things
WHERE
id IN (@id)
SQL
};
print $sql;
'
For those that are not familiar with C$,
change it in the above code to for example qq{\n,\t}
and see the difference in the output.
--
Ruud
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Teaching Perl
Dear Friends, I'm looking for some help from the Perl community. I hope this is the right place to ask for information. I'm putting together a website aimed at high school students and teachers, and would like to make sure the following page is as good as possible: http://programming.dojo.net.nz/languages/perl/index In particular, Why would I learn this language? section needs to have a few paragraphs. I don't use Perl predominantly so I hoped that you could provide the main reasons why Perl is a language someone would want to learn about. It would also be great if someone could rewrite the Perl source code example so that it is as close as possible to the C implementation: http://programming.dojo.net.nz/languages/c/index It should still use the Perl features where it makes sense. It would be great if you could include comments explaining how it works and what is happening (like the C example). Any other suggestions or ideas for the Perl page would be fantastic, and any suggestions to other pages in general is also very helpful. http://programming.dojo.net.nz/ Kind regards, Samuel
Re: Still pondering working with hashs
Harry Putnam wrote:
Shawn H Corey shawnhco...@gmail.com writes:
Harry Putnam wrote:
But, is there an easier way?
Invert both hashes and find the keys in both inverses.
[...]
Thanks for the nice working script... Lots to learn there.
But not sure how to get at the information I asked about with it.
Maybe because there was a type in my post.
Harry wrote:
The idea is to determine what is one hash but not the other in terms
^
in
of values ... as above.
Harry Putnam wrote:
Have quite a lot of trouble getting my pea brain around working even
with simple hashs.
What I hope to do is compare hashes and a few different ways.
If you want to find those in one but no the other, change the if:
for my $name ( keys %inverse_h1 ){
if( exists $inverse_h2{$name} ){
# print $name exists in both hashes:\n,
# Data::Dumper-Dump( [ $inverse_h1{$name},
$inverse_h2{$name} ], [ 'h1', 'h2' ] ),
# \n;
}else{
print $name exists in only h1\n;
}
}
--
Just my 0.0002 million dollars worth,
Shawn
Programming is as much about organization and communication
as it is about coding.
I like Perl; it's the only language where you can bless your
thingy.
Eliminate software piracy: use only FLOSS.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Still pondering working with hashs
Harry Putnam wrote:
What I hope to do is compare hashes and a few different ways.
determine what is in one and not in the other for example.
These exmple hashes are supposed to represent file names.
The hashes are created by making the key the full path and file name,
and the value just the end filename
my %h1 = (
'./b/f1' = 'f1',
'./b/c/fa' = 'fa',
'./b/l/c/f2' = 'f2',
'./b/g/f/r/fb' = 'fb'
);
my %h2 = (
'./b/fb'= 'fb',
'./b/c/fd' = 'fd',
'./b/l/c/f2'= 'f2',
'./b/g/f/r/fc' = 'fc',
'./b/g/h/r/fb' = 'fb'
I think you want to find filenames that exist in multiple paths.
So you could create a hash like this:
(
'f1' = [ 'p1', 'p4' ],
'f2' = [ 'p1', 'p2', 'p4' ],
...
)
(read f as filename and p as pathname)
In that way, you would have, per filename, a list of all paths.
An example that shows you the commands that exist more than once in your
path:
perl -Mstrict -MData::Dumper -MFile::Basename=basename,dirname -wle'
my %h;
for my $dir ( split :, $ENV{PATH} ) {
push @{ $h{ basename($_) } }, dirname($_) for glob $dir/*;
}
@{ $h{ $_ } } 2 and delete $h{ $_ } for keys %h;
print Dumper( \%h );
' |less
Similar without File::Basename
perl -Mstrict -MData::Dumper -wle'
my %h;
for my $dir ( split :, $ENV{PATH} ) {
m{(.*/)(.*)} and push @{ $h{ $2 } }, $1 for glob $dir/*;
}
@{ $h{ $_ } } 2 and delete $h{ $_ } for keys %h;
print Dumper( \%h );
' |less
--
Ruud
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: testing if divisible by?
On Sat, May 1, 2010 at 7:45 AM, Philip Potter philip.g.pot...@gmail.com wrote: On 1 May 2010 12:15, Paul opensou...@unixoses.com wrote: Hello all. How can I test to see if a number is divisible by say, 40? Thanks. Use the modulo operator %. Given integers $x and $y, the expression $x % $y gives the remainder when $x is divided by $y. As a result, if (and only if) $x is exactly divisible by $y, $x % $y is equal to 0. And there's the rub: number ne integer. % is fine if you're only interested in integers, but if you want to compare other numbers use fmod() from POSIX.pm: perl -MPOSIX -wle 'print POSIX::fmod(35, 17.5)' It's considerably slower than %, but it gets the job done. HTH, -- jay -- This email and attachment(s): [ ] blogable; [ x ] ask first; [ ] private and confidential daggerquill [at] gmail [dot] com http://www.tuaw.com http://www.downloadsquad.com http://www.engatiki.org values of β will give rise to dom! -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Teaching Perl
Samuel Williams wrote:
Dear Friends,
Hello,
It would also be great if someone could rewrite the Perl source code
example so that it is as close as possible to the C implementation:
http://programming.dojo.net.nz/languages/c/index
/* Include the standard input / output functions */
#include stdio.h
int main()
{
/* Initialize the array of doors to 0 (closed) */
char is_open[100] = {0};
Why are you creating an array of 101 elements when you only use 100?
Your comment says you initialize the array but you only initialize the
first element.
int pass, door;
/* Process the doors */
for (pass = 0; pass 100; ++pass)
for (door = pass; door 100; door += pass+1)
is_open[door] = !is_open[door];
/* Print out the results */
for (door = 0; door 100; ++door)
printf(Door #%d is %s.\n, door+1, (is_open[door] ? open. :
closed.));
return 0;
}
sub main()
{
# Initialize the array of doors to 0 (closed)
$is_open[100] = 0;
# Process the doors
for ($pass = 0; $pass 100; ++$pass){
for ($door = $pass; $door 100; $door += $pass+1){
$is_open[$door] = !$is_open[$door];}}
# Print out the results
for ($door = 0; $door 100; ++$door){
printf(Door #%d is %s.\n, $door+1, ($is_open[$door] ? open.
: closed.));}
return 0;
}
John
--
The programmer is fighting against the two most
destructive forces in the universe: entropy and
human stupidity. -- Damian Conway
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: testing if divisible by?
2010/5/3 Jay Savage daggerqu...@gmail.com: On Sat, May 1, 2010 at 7:45 AM, Philip Potter philip.g.pot...@gmail.com wrote: On 1 May 2010 12:15, Paul opensou...@unixoses.com wrote: Hello all. How can I test to see if a number is divisible by say, 40? Use the modulo operator %. Given integers $x and $y, the expression $x And there's the rub: number ne integer. % is fine if you're only interested in integers, but if you want to compare other numbers use fmod() from POSIX.pm: perl -MPOSIX -wle 'print POSIX::fmod(35, 17.5)' fmod is a fine replacement for % in general for testing remainders of floating-point valued quotients, but using it as a divisibility test requires caution and serious consideration of a different approach. It has the same issues as a floating-point equality test: that is, because floating-point is an inexact representation, the results can depend on whether a value was rounded up or down: D:\perl -MPOSIX -wle print POSIX::fmod(0.2, 0.1) 0 D:\perl -MPOSIX -wle print POSIX::fmod(0.3, 0.1) 0.1 D:\perl -MPOSIX -wle print POSIX::fmod(0.4, 0.1) 0 D:\perl -MPOSIX -wle print POSIX::fmod(0.5, 0.1) 0.1 These examples have strange results because 0.1 is not exactly representable in binary floating-point. Phil -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Teaching Perl
On Monday 03 May 2010 15:08:34 Samuel Williams wrote:
Dear Friends,
I'm looking for some help from the Perl community. I hope this is the right
place to ask for information.
It may be, but you may also wish to ask on advoc...@perl.org
I'm putting together a website aimed at high school students and teachers,
and would like to make sure the following page is as good as possible:
http://programming.dojo.net.nz/languages/perl/index
In particular, Why would I learn this language? section needs to have a
few paragraphs. I don't use Perl predominantly so I hoped that you could
provide the main reasons why Perl is a language someone would want to
learn about.
I've concentrated some answers to such questions about Perl advocacy on the
Perl Beginners' Site:
* http://perl-begin.org/
* http://perl-begin.org/learn/#why-learn
It would also be great if someone could rewrite the Perl source code
example so that it is as close as possible to the C implementation:
http://programming.dojo.net.nz/languages/c/index
It should still use the Perl features where it makes sense. It would be
great if you could include comments explaining how it works and what is
happening (like the C example).
Here is my Perl version without comments:
[code]
#!/usr/bin/perl
use strict;
use warnings;
my $num_doors = 100;
my @is_open = ((0) x $num_doors);
for my $pass (0 .. ($num_doors-1))
{
my $door = $pass;
while ($door $num_doors)
{
$is_open[$door] = !$is_open[$door];
}
continue
{
$door += $pass+1;
}
}
foreach my $door (0 .. $#is_open)
{
printf(Door #%d is %s.\n,
$door+1, ($is_open[$door] ? open : closed)
);
}
[/code]
Here it is with a few comments added:
[code]
#!/usr/bin/perl
use strict;
use warnings;
# Define the number of doors, to avoid magic numbers.
my $num_doors = 100;
# All the doors are closed by default.
my @is_open = ((0) x $num_doors);
# Loop over the passes of all the doors.
for my $pass (0 .. ($num_doors-1))
{
my $door = $pass;
# Loop over all the doors in the pass.
while ($door $num_doors)
{
# Flip the door's state.
$is_open[$door] = !$is_open[$door];
}
continue
{
# Advance the door number.
$door += $pass+1;
}
}
# Print the status of all the doors.
foreach my $door (0 .. $#is_open)
{
printf(Door #%d is %s.\n,
$door+1, ($is_open[$door] ? open : closed)
);
}
[/code]
Note that any moderately experienced Perl programmer will have no problem
understanding the program without the comments, but I've included them here
for people who are not familiar with Perl at all.
Any other suggestions or ideas for the Perl page would be fantastic,
Well, it's not entirely accurate that Perl is interpreted. As a matter of
fact, its default implementation (called perl5) is a P-code-based virtual
machine that compiles the human-friendly Perl code into bytecode and then
executes this bytecode.
including both lexical scope and dynamic scope. - while in Perl you can use
lexical scoping for the my variables and dynamic scoping for the package-
scope variables (use vars() , our, etc.), we still prefer to avoid using
the dynamic scoping for package-scope variables as much as possible, and
generally won't recommend it.
I would recommend you include a link to http://perl-begin.org/ on that page.
Saying that Perl supports both imperative and function features is a huge
understatement of Perl's multi-paradigm capabilities that include many other
paradigms - most of which are included on http://perl-begin.org/ in the
various sections.
Hope it helps.
Regards,
Shlomi Fish
and
any suggestions to other pages in general is also very helpful.
http://programming.dojo.net.nz/
Kind regards,
Samuel
--
-
Shlomi Fish http://www.shlomifish.org/
Interview with Ben Collins-Sussman - http://shlom.in/sussman
God considered inflicting XSLT as the tenth plague of Egypt, but then
decided against it because he thought it would be too evil.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Teaching Perl
Hi John,
On Monday 03 May 2010 17:42:16 John W. Krahn wrote:
Samuel Williams wrote:
Dear Friends,
Hello,
It would also be great if someone could rewrite the Perl source code
example so that it is as close as possible to the C implementation:
http://programming.dojo.net.nz/languages/c/index
/* Include the standard input / output functions */
#include stdio.h
int main()
{
/* Initialize the array of doors to 0 (closed) */
char is_open[100] = {0};
Why are you creating an array of 101 elements when you only use 100?
Your comment says you initialize the array but you only initialize the
first element.
Actually, in C:
1. A type_t myarray[100]; will initialise an array that can be indexed
from 0 to 99 - 100 elements in total. Likewish myarray[10] will be indexed
from 0 to 9, etc.
2. The {0} is a shortened initialisation to allocate all the elements as 0.
int pass, door;
/* Process the doors */
for (pass = 0; pass 100; ++pass)
for (door = pass; door 100; door += pass+1)
is_open[door] = !is_open[door];
/* Print out the results */
for (door = 0; door 100; ++door)
printf(Door #%d is %s.\n, door+1, (is_open[door] ? open. :
closed.));
return 0;
}
sub main()
{
1. Why did you put everything in a main fuction? Perl is not C.
2. Why the () after the main? You shouldn't specify prototypes.
# Initialize the array of doors to 0 (closed)
$is_open[100] = 0;
1. Why didn't you declare @is_open? You should have used strict and warnings.
2. This will initialise the element of index 100 (actually the 101st element)
to 0 and all the elements before it (assuming they did not exist beforehand)
to undef. You probably want @is_open = ((0) x 100) instead.
# Process the doors
for ($pass = 0; $pass 100; ++$pass){
1. PBP recommends against doing C-style for loops.
2. you should declare pass again.
3. You should have some space before the { (I start it on a newline and have
my reasons for that but I accept the other style).
for ($door = $pass; $door 100; $door += $pass+1){
$is_open[$door] = !$is_open[$door];}}
Ahmmm.. why didn't you put the two } in separate lines? Perl is not Lisp.
# Print out the results
for ($door = 0; $door 100; ++$door){
printf(Door #%d is %s.\n, $door+1, ($is_open[$door] ? open.
: closed.));}
Just a note - the C program has a bug where the strings had a trailing .
which was also included in the printf's formatting string. It should not be
reproduced in the Perl program.
Regards,
Shlomi Fish
return 0;
}
John
--
-
Shlomi Fish http://www.shlomifish.org/
Rethinking CPAN - http://shlom.in/rethinking-cpan
God considered inflicting XSLT as the tenth plague of Egypt, but then
decided against it because he thought it would be too evil.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Teaching Perl
Dear John,
Apparently (according to the people in irc.freenode.org#c) that initializer
sets the whole array to zero. I queried this too, but apparently its correct.
Thanks for your implementation.
Kind regards,
Samuel
On 4/05/2010, at 2:42 AM, John W. Krahn wrote:
Samuel Williams wrote:
Dear Friends,
Hello,
It would also be great if someone could rewrite the Perl source code
example so that it is as close as possible to the C implementation:
http://programming.dojo.net.nz/languages/c/index
/* Include the standard input / output functions */
#include stdio.h
int main()
{
/* Initialize the array of doors to 0 (closed) */
char is_open[100] = {0};
Why are you creating an array of 101 elements when you only use 100? Your
comment says you initialize the array but you only initialize the first
element.
int pass, door;
/* Process the doors */
for (pass = 0; pass 100; ++pass)
for (door = pass; door 100; door += pass+1)
is_open[door] = !is_open[door];
/* Print out the results */
for (door = 0; door 100; ++door)
printf(Door #%d is %s.\n, door+1, (is_open[door] ? open. :
closed.));
return 0;
}
sub main()
{
# Initialize the array of doors to 0 (closed)
$is_open[100] = 0;
# Process the doors
for ($pass = 0; $pass 100; ++$pass){
for ($door = $pass; $door 100; $door += $pass+1){
$is_open[$door] = !$is_open[$door];}}
# Print out the results
for ($door = 0; $door 100; ++$door){
printf(Door #%d is %s.\n, $door+1, ($is_open[$door] ? open. :
closed.));}
return 0;
}
John
--
The programmer is fighting against the two most
destructive forces in the universe: entropy and
human stupidity. -- Damian Conway
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Still pondering working with hashs
John W. Krahn jwkr...@shaw.ca writes:
Harry Putnam wrote:
my %h1 = (
'./b/f1' = 'f1',
'./b/c/fa' = 'fa',
'./b/l/c/f2' = 'f2',
'./b/g/f/r/fb' = 'fb'
);
my %h2 = (
'./b/fb'= 'fb', './b/c/fd'
= 'fd',
'./b/l/c/f2'= 'f2',
'./b/g/f/r/fc' = 'fc',
'./b/g/h/r/fb' = 'fb'
);
In your previous example you used two different paths, so why does
this example have only one path and why do './b/l/c/f2' and
./b/g/f/r/fb' show up in both hashes but the other values do not?
About the single base path... it was just an oversite... the result of
copy pasting the first hash I typed out before I started fiddling with
them to get the problem a little more realistic... and never thought
to change the base path.
Your observation is right on the money though.. as in the real case
there are definitely two different root paths. In fact its really the
only reason to need two hashes.
Your second question is, again poor observation on my part... but
doesn't change the task really.
In fact, the base path is actually discarded in the final result.
base1/some/path/file
base2/path/file
Will actually be moved like this (roughly):
move:
base1/some/path/file
(minus the existing root)
to this path:
base2/path/file
(minus the existing root)
So: some/path/file
to: path/file
In here:
newbase/path/file
So doesn't the chore I tried for a simple example of remain the same?
That is, to identify which end file names are present in either hash
regardless of the rest of the path?
The example task was just to find the matching end names.
The task I'm after really has 2 major components... and a third
component that depends on those three for its input.
The actual project is a merging of two file structures that have many
similar files, many identical files, and many file in one but not the other.
One hierarchy is vastly larger than the other. Any files in it, but
not the smaller one, can be deleted.
Any files in the smaller one and not the larger need to remain in the
final product.
The problem gets more complicated with what is left.
Many are identical except for the path and I don't mean just the root
path.
So the name and paths in the larger structure that contain files
identical to files in the smaller structure... will be moved to
overwrite their twins in still a different root..
That is, we are building up a third hierarchy that contains a merger
of the 2 hashed structures in a specific way.
That isn't actually quite right either... really I'm trying to create
a list of cmds that will create such a merged structure.
No files are actually manipulated (yet) just drawing up a list of
things to do to create a merged structure.
Looking back at what I wrote above... its confusing as heck... sorry
I'm not better at explaining what I'm trying to do.
---- ---=--- -
Of course first generate the hashes (in terms of File::Find).
h1{$File::Find::name} = $_
h2{$File::Find::name} = $_
so that the keys are File::Find::name and values are $_
1) find all files (end of path filenames) that are in one
and not the other
2) Ditto the other way round
3) Find all that match on end name (but maybe not path) and dispatch
them through means of a dispatch table, in one of 3 basic ways.
remove
add
overwrite twin
Part 3, I've actually got something of a handle on.. from other
helpful posts here regarding `dispatch tables'.
I'm looking for better ways to get 1 and 2 done with minimal effort.
I actually am able to get the needed results now... I was asking just
for better ways to do it and in the course of things provided somewhat
inaccurate examples as you've noted.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Still pondering working with hashs
Shawn H Corey shawnhco...@gmail.com writes:
[...]
If you want to find those in one but no the other, change the if:
for my $name ( keys %inverse_h1 ){
if( exists $inverse_h2{$name} ){
# print $name exists in both hashes:\n,
# Data::Dumper-Dump( [ $inverse_h1{$name},
$inverse_h2{$name} ], [ 'h1', 'h2' ] ),
# \n;
}else{
print $name exists in only h1\n;
}
}
I guess you didn't mean to leave Data::Dumper[...] commented?
With that uncommented, yes it does just that. Again thanks for the
practical code.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Still pondering working with hashs
Dr.Ruud rvtol+use...@isolution.nl writes:
[...] snipped poorly written example
I think you want to find filenames that exist in multiple paths.
As John K. has noted... my example was misleading. If you were to
prepend a different root directory to each list of filenames in my
example it would be much more like what I'm trying to figure out.
But your guess still stands. Only doesn't quite get to the scope of the
problem. Yes, files that exist on multiple paths, but there are also
many matched names that are not actually the same file.
Its actually a little more complex than that... since some of the
matches are the right file but do have slight differences that will
show in the sizes. Not so many like that... but I have seen a few so
far.
The matched files that do exist on different paths will eventually be
run through a dispatch table to ..er,, be dispatched.
In my full script... that problem is dealt with in a dispatch table
where one of the choices is to print the sizes of all matches.
Allowing the user to see at a glance which file is likely to be the
real match... and prepares (an external) diff... if there is still any
doubt.
So, many (most) of the matched files need to go through human hands
for final actions.
Some things the user is likely to know at a glance if presented with a
full filename from hash1 and several matches from hash2. Whereas it
would be quite hard (for me) to code an automated solution. Hence the
dispatch table
I'm not familiar enough with Data::Dumper and its output. All the
brackets and stuff are confusing. In your examples... not so much.
In fact not at all. (I'm talking about the output here. but in the
code, it is confusing... I'm not sharp enough to just follow it
without serious study)
So I'll need to figure out how to fix data::Dumper output so matches
can be listed and the list run through a dispatch table.
In every case where there is a match, no matter how many, they'll need
to be listed as numbered choices where typing a number will select the one
that is useful, and typing a letter representing a sub function will
dispatch those two files (one from h1, one from h2) as needed.
I haven't worked out how the number gets passed into the function yet
so have tried just listing the files and in some cases user can paste
a filename into a function through a menu..
(But that is a different subject)
I have written such a table. Where all sub functions are a single
letter.
`sub A {blah}'
etc
Currently feeding it by collecting the matches to an end filename from
hash1 of all matching files in hash2 into an array.
(That array contains the same kind of information as your examples
display.)
Then print a numbered list and the menu (like snippet below) of the
dispatch table (snippet below) and possible functions.
---- ---=--- -
my %dispt = (
A = sub { print File to add (enter name) ;
chomp(my $answer = STDIN);
if (! -f $answer) {
print $answer not found on file system\n;
print No action taken\n;
}else {
print A($answer) . \n;
};
},
D = sub { print D(@matches) .\n; },
[...]
Z = sub { print Z(@matches) .\n; },
[...]
---- ---=--- -
while ($cnt == 1) {
print press A to add to `add' list\n,
press D for external diff line to copy paste\n,
[...]
press Z to see file sizes\n,
[...]
---- ---=--- -
I'm doing that without involving Data::Dumper.
Do you think it would be better done using Data::Dumper?
First I'd have to learn how to use Data::Dumper
Both you and Shawn have shown its great utility.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Teaching Perl
Dear Shlomi,
Are you able to write a version that uses a function called doors?
Kind regards,
Samuel
On 4/05/2010, at 3:01 AM, Shlomi Fish wrote:
Hi John,
On Monday 03 May 2010 17:42:16 John W. Krahn wrote:
Samuel Williams wrote:
Dear Friends,
Hello,
It would also be great if someone could rewrite the Perl source code
example so that it is as close as possible to the C implementation:
http://programming.dojo.net.nz/languages/c/index
/* Include the standard input / output functions */
#include stdio.h
int main()
{
/* Initialize the array of doors to 0 (closed) */
char is_open[100] = {0};
Why are you creating an array of 101 elements when you only use 100?
Your comment says you initialize the array but you only initialize the
first element.
Actually, in C:
1. A type_t myarray[100]; will initialise an array that can be indexed
from 0 to 99 - 100 elements in total. Likewish myarray[10] will be indexed
from 0 to 9, etc.
2. The {0} is a shortened initialisation to allocate all the elements as 0.
int pass, door;
/* Process the doors */
for (pass = 0; pass 100; ++pass)
for (door = pass; door 100; door += pass+1)
is_open[door] = !is_open[door];
/* Print out the results */
for (door = 0; door 100; ++door)
printf(Door #%d is %s.\n, door+1, (is_open[door] ? open. :
closed.));
return 0;
}
sub main()
{
1. Why did you put everything in a main fuction? Perl is not C.
2. Why the () after the main? You shouldn't specify prototypes.
# Initialize the array of doors to 0 (closed)
$is_open[100] = 0;
1. Why didn't you declare @is_open? You should have used strict and warnings.
2. This will initialise the element of index 100 (actually the 101st element)
to 0 and all the elements before it (assuming they did not exist beforehand)
to undef. You probably want @is_open = ((0) x 100) instead.
# Process the doors
for ($pass = 0; $pass 100; ++$pass){
1. PBP recommends against doing C-style for loops.
2. you should declare pass again.
3. You should have some space before the { (I start it on a newline and
have
my reasons for that but I accept the other style).
for ($door = $pass; $door 100; $door += $pass+1){
$is_open[$door] = !$is_open[$door];}}
Ahmmm.. why didn't you put the two } in separate lines? Perl is not Lisp.
# Print out the results
for ($door = 0; $door 100; ++$door){
printf(Door #%d is %s.\n, $door+1, ($is_open[$door] ? open.
: closed.));}
Just a note - the C program has a bug where the strings had a trailing .
which was also included in the printf's formatting string. It should not be
reproduced in the Perl program.
Regards,
Shlomi Fish
return 0;
}
John
--
-
Shlomi Fish http://www.shlomifish.org/
Rethinking CPAN - http://shlom.in/rethinking-cpan
God considered inflicting XSLT as the tenth plague of Egypt, but then
decided against it because he thought it would be too evil.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Still pondering working with hashs
On 5/3/10 Mon May 3, 2010 9:35 AM, Harry Putnam rea...@newsguy.com scribbled: [long problem description snipped] I'm doing that without involving Data::Dumper. Do you think it would be better done using Data::Dumper? First I'd have to learn how to use Data::Dumper The usual purpose of using Data::Dumper (DD) is to print out a complex data structure to see what is there. This is only for debugging purposes. Once you have a program working, you can delete all references to DD. However, it is usually better to comment out the lines that use DD or use a conditional flag to disable them, since you may need them in the future if you discover a problem. I don't think anybody is saying use Data::Dumper to implement your algorithm or simplify your program. (There is another reason to use Data::Dumper -- to store a data structure in a data file and reconstruct it in a later invocation of a program, but that is not being suggested here, and there are other modules that do that better.) So create your hashes and implement your testing algorithms without using Data::Dumper. Then use it to print your hashes if you are confused about what they contain. There is a package variable $Data::Dumper::Indent that you can set to change how Data::Dumper formats its output. The default value is 2. I sometimes use the following to get a more compact output: $Data::Dumper::Indent = 1; See the Data::Dumper documentation for other options that affect the output. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Still pondering working with hashs
HP == Harry Putnam rea...@newsguy.com writes: HP Its actually a little more complex than that... since some of the HP matches are the right file but do have slight differences that will HP show in the sizes. Not so many like that... but I have seen a few so HP far. this is what has been bothering me here. you haven't yet spit out a proper problem specification. as i kept saying comparing dir trees is tricky and you kept showing incomplete examples which now all seem to be wrong as you just made a major change in the 'spec'. now duplicate filenames could actually be different files vs just copies in different places. this is a whole other mess of fish. so learn this before you get in deeper. always have a proper specification in ENGLISH before you design or code. a major change like this can cause a complete redesign of all your previous work. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com - -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Still pondering working with hashs
Uri Guttman u...@stemsystems.com writes: this is what has been bothering me here. you haven't yet spit out a proper problem specification. as i kept saying comparing dir trees is tricky and you kept showing incomplete examples which now all seem to be wrong as you just made a major change in the 'spec'. now duplicate filenames could actually be different files vs just copies in different places. this is a whole other mess of fish. None of what I've shown contradicts the full program... quit karping about it. Sloppy... yes, I have been. I wonder if that might be because I don't really have a good idea of what I'm doing or how to do it. What a surprise... that's why its called perl.beginners. so learn this before you get in deeper. always have a proper specification in ENGLISH before you design or code. a major change like this can cause a complete redesign of all your previous work. This is nonesense and absolutely wrong. Please don't give such poor advice to anyone else. Not a major change at all.. I've gotten much much farther along with what has been posted and responded to. I hope no one takes you seriously with that. Like many before me, I'm working this out as I go along. In the beginning I didn't know what a full program would look like. I took some time with the examples I tried to raise here ... much more than I should admit to. This stuff comes hard to me. Other helpful posters have shown clear working examples... most of them now appear in this program in one way or another. I've learned so much here that now I can probably put it fully in words. Maybe even ones you'd approve of. But could I have started there not a chance. So please engage some shred of common sense before routinely posting constant karping and even seriously wrong headed advice like this. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Still pondering working with hashs
Jim Gibson jimsgib...@gmail.com writes: The usual purpose of using Data::Dumper (DD) is to print out a complex data What an excellent synopsis of how DD fits into stuff like this. Thanks a lot... I was on the verge of starting to really pound away trying to learn DD and how to use it. I mean making it the guts of the program... not as debugger. At least now I don't have the feeling I've had it completely wrong so far. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Still pondering working with hashs
HP == Harry Putnam rea...@newsguy.com writes: HP Uri Guttman u...@stemsystems.com writes: this is what has been bothering me here. you haven't yet spit out a proper problem specification. as i kept saying comparing dir trees is tricky and you kept showing incomplete examples which now all seem to be wrong as you just made a major change in the 'spec'. now duplicate filenames could actually be different files vs just copies in different places. this is a whole other mess of fish. HP None of what I've shown contradicts the full program... quit karping HP about it. Sloppy... yes, I have been. I wonder if that might be HP because I don't really have a good idea of what I'm doing or how to do HP it. What a surprise... that's why its called perl.beginners. true about your perl but this is more than that. you haven't described what the issues or goals are yet. how can you (or us) tell if the program is correct unless you have something to which to compare the results? that is what the goal is. you have changed it recently when you realized you had duplicate filenames with different paths and they were different files. you never stated what the actual purpose of this was. this is also called the XY problem (google it). so learn this before you get in deeper. always have a proper specification in ENGLISH before you design or code. a major change like this can cause a complete redesign of all your previous work. HP This is nonesense and absolutely wrong. Please don't give such poor HP advice to anyone else. nope. been doing this for 35 years and it is solid advice. you can't do a proper program unless you have a proper goal which is what the specification is. HP Not a major change at all.. I've gotten much much farther along with HP what has been posted and responded to. it is a major change. it affects how the dir tree comparison is to be done which is the heart of the application. HP I hope no one takes you seriously with that. Like many before me, I'm HP working this out as I go along. In the beginning I didn't know what a HP full program would look like. I took some time with the examples I HP tried to raise here ... much more than I should admit to. This stuff HP comes hard to me. this is not about programming but understanding your problem and needs. that is the goal. do you drive around aimlessly until you actually go by a store which may have what you want? HP Other helpful posters have shown clear working examples... most of HP them now appear in this program in one way or another. in one way or the others. because they never got the full picture. some of the code has been thrown away which is a waste of everyone's time. think about that. HP I've learned so much here that now I can probably put it fully in HP words. Maybe even ones you'd approve of. sure but there are better ways to learn too. writing up a goal is one of them. even if it does change (and they do) they give you and others a target to shoot at. your specs have been very fluid and not clear as i keep saying. HP But could I have started there not a chance. So please engage HP some shred of common sense before routinely posting constant karping HP and even seriously wrong headed advice like this. wrong again. you could easily have written up a short goal document. i have some directory trees which may have duplicate filenames and those files could be the same or actual different files. i want to scan the two trees, compare them and locate common filenames in both. then i want users to be able to choose from menu what to do with the files when dups are found. that is close to what you are doing. was that too hard to write? you are really closing your eyes here and just driving around. sure you have learned some coding skills but you aren't seeing the bigger picture. this will keep biting you until you discover it yourself with more experience. that deep experience is what i am offering here and you are refusing it. note that others aren't refuting what i am saying, they all work with goal documents at some time or other. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com - -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Still pondering working with hashs
On 3 May 2010 20:56, Uri Guttman u...@stemsystems.com wrote: HP == Harry Putnam rea...@newsguy.com writes: HP Uri Guttman u...@stemsystems.com writes: this is what has been bothering me here. you haven't yet spit out a proper problem specification. as i kept saying comparing dir trees is tricky and you kept showing incomplete examples which now all seem to be wrong as you just made a major change in the 'spec'. now duplicate filenames could actually be different files vs just copies in different places. this is a whole other mess of fish. HP None of what I've shown contradicts the full program... quit karping HP about it. Sloppy... yes, I have been. I wonder if that might be HP because I don't really have a good idea of what I'm doing or how to do HP it. What a surprise... that's why its called perl.beginners. [snip] you could easily have written up a short goal document. i have some directory trees which may have duplicate filenames and those files could be the same or actual different files. i want to scan the two trees, compare them and locate common filenames in both. then i want users to be able to choose from menu what to do with the files when dups are found. that is close to what you are doing. was that too hard to write? you are really closing your eyes here and just driving around. sure you have learned some coding skills but you aren't seeing the bigger picture. this will keep biting you until you discover it yourself with more experience. that deep experience is what i am offering here and you are refusing it. note that others aren't refuting what i am saying, they all work with goal documents at some time or other. I have to support what Uri says here. You shouldn't start writing *any* code at all until you know what you want it to do. If you don't know what you want to do, you're groping in the dark. If you ask for help, people can't give you the help you need because they don't know what you want to do either. Every software engineering method incorporates this principle, usually as a step called requirements analysis. It's a fancy way of saying what do I want to do? Phil -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Still pondering working with hashs
Philip Potter philip.g.pot...@gmail.com writes: [...] Both you and Uri are right to a degree. I have to respect Uris' experience, but in fact I have presented goals at every step in this thread. Uri just doesn't want to recognize them. 1) how to find what files are in one tree but not the other I've received a few good techniqes to do that... goal accomplished. 2) ditto but reverse Samething applies. 3) how to find all the matches again, reponses supplied some good code that could be edited to my purposes. 4) How to setup a dispatch table... involved in other threads more than here but still the same project (Again, good solid posts, more than one by Uri himself as I recall - goal accomplished) 5) How to use Data::Dumper for this kind of stuff - goal accomplished I have to support what Uri says here. You shouldn't start writing *any* code at all until you know what you want it to do. If you don't know what you want to do, you're groping in the dark. If you ask for help, people can't give you the help you need because they don't know what you want to do either. I have done that at every step... and people have been thoroughly capable of giving sound help. Uri is talking through his hat. Every software engineering method incorporates this principle, usually as a step called requirements analysis. It's a fancy way of saying what do I want to do? That is the kind of `always true' thing one might say. I forgot what the term is but it means its fairly meaningless and mainly sounds good. But none the less true. About driving around not knowing where I'm going. I'd wager a full pension check that everyone here has done that and maybe not so long ago. Uri asked would I do that A resounding YES. I'd first check a map or maybe make some calls (that is, research a bit) and then if I still wasn't sure... I'd go have a look, and try to find what ever it is I was after. That's exactly what most people would do if they really wanted to get somewhere or find something. Concerning people having wasted there time where has that happened? Literally every response has been put to work here. If not on this exact program then another. I really hope none of the responders feel they have wasted there time. If they do, that is MY fault... and likely at least partially because I didn't understand the information given me. I'll say for the record I've received very professional and thorough help here... Also, a truly amazing level of patience has been shown to me. I haven't always been able to understand the information presented... But I often keep these threads and refer back to them when I do begin to understand a little better. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Still pondering working with hashs
Uri Guttman u...@stemsystems.com writes: nope. been doing this for 35 years and it is solid advice. you can't do a proper program unless you have a proper goal which is what the specification is. Thank you Uncle Uri. I guess I just don't yet know how to make use all you present as help. Some of it looks suspiciously like hair splitting and karping of the first order. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Still pondering working with hashs
HP == Harry Putnam rea...@newsguy.com writes: HP Uri Guttman u...@stemsystems.com writes: nope. been doing this for 35 years and it is solid advice. you can't do a proper program unless you have a proper goal which is what the specification is. HP Thank you Uncle Uri. I guess I just don't yet know how to make use HP all you present as help. if you can't understand something, then ask about it. we can't read your mind, only your rants! :) HP Some of it looks suspiciously like hair splitting and karping of the HP first order. what you think is hair splitting, we think of as moving mountains. this is what experience in developing projects (big and small) tells us. you came here to learn perl. there is much more to programming than learning a particular language. in fact most programming skills and knowledge is language independent and that is also important to know. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com - -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Perl modules to process PDF files
Hi All, I need to process some PDF files to do some complex validation (like checking the colour of icons, position etc). I was wondering if Perl comes with some handy modules to process PDF files? AFAIK even professional tools like QTP are not good with processing PDF files. Cheers, Parag
