[31398] in Perl-Users-Digest
Perl-Users Digest, Issue: 2650 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Oct 25 18:09:42 2009
Date: Sun, 25 Oct 2009 15:09:08 -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 Sun, 25 Oct 2009 Volume: 11 Number: 2650
Today's topics:
Re: 6 images in tile format(google maps) <dwayne.triffitt@gmail.com>
Re: File locking using threads dba.9999@gmail.com
Re: File locking using threads <timothy.hill@gmail.com>
Re: File locking using threads (Jens Thoms Toerring)
Re: File locking using threads <timothy.hill@gmail.com>
Re: File locking using threads (Jens Thoms Toerring)
Re: File locking using threads <timothy.hill@gmail.com>
Re: File locking using threads (Jens Thoms Toerring)
Re: Indirection in a hash <hjp-usenet2@hjp.at>
Re: Indirection in a hash <hjp-usenet2@hjp.at>
Shifting error codes <marc.girod@gmail.com>
Re: Shifting error codes (Jens Thoms Toerring)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 25 Oct 2009 12:52:24 -0700 (PDT)
From: Dwayne Triffitt <dwayne.triffitt@gmail.com>
Subject: Re: 6 images in tile format(google maps)
Message-Id: <332e88c7-7766-4b6e-858c-823936fb79de@q40g2000prh.googlegroups.com>
just a small recap on the progress i have made,
If anyones looking for the code that is
#!/usr/local/bin/perl -w
use Tk; #<< NEED THIS
use Tk::widgets qw/JPEG PNG/; #<< NEED THIS FOR PNG IMAGES
use strict;
use warnings;
##start with a new window##
my $mw = MainWindow->new();
$mw->geometry("768x640");
$mw->title(" Tasdawg Window Tk v0.01");
##add icon(marker) and first tile(map)
my $icon = $mw->Photo(-file=>'marker.png');
my $tile1 = $mw->Photo(-file=>'1/1.png');
##Create the canvas to draw these too.
my $c1 = $mw->Canvas(-width => 768, -height => 768,
#-tile => $tile, # tile one image to the background(maybe
add all images togeather?)
-relief => 'sunken',
);
$c1->pack(-side => 'left');
##now create the image on the canvas
$c1->createImage(128, 128, -image => $tile1);
## using button 1 to add marker to the image canvas
$mw->Tk::bind("<ButtonPress-1>", [\&pimg, Ev('x'), Ev('y') ]);
##the sub function for the button being pressed
MainLoop;
sub pimg {
my ($canv, $x, $y) = @_;
my $x1 = $canv->canvasx($x);
my $y1 = $canv->canvasx($y);
# print "$x1 $y1\n";
#$c1->pack(-side => 'left');
$c1->createImage($x1, $y1, -image => $icon, -tags =>
['move']);
$current = $c1;
}
##p.s This code wont work - it is only a snippet from my code, that
has a lot more in it.
But thats the basic's
Now to tile an image see this line
$c1->createImage(128, 128, -image => $tile1);
for every 128,128 is the pixal Y axis and X axis
adding a second image u go like this
$c1->createImage(128, 384, -image => $tile2);
b-cos my images are 256x256 i have to come down 128 pixals at first
and then plus the image and get 384
here is a "768x640" tile'd map - all images displayed the same 3x3
map.
$c1->createImage(128, 128, -image => $tile1);
$c1->createImage(128, 384, -image => $tile2);
$c1->createImage(128, 640, -image => $tile3);
$c1->createImage(384, 128, -image => $tile4);
$c1->createImage(384, 384, -image => $tile5);
$c1->createImage(384, 640, -image => $tile6);
$c1->createImage(640, 128, -image => $tile4);
$c1->createImage(640, 384, -image => $tile5);
$c1->createImage(640, 640, -image => $tile6);
Easy as that - will post again on the improvement of not defining
images and getting them from the directory as and making each 3 images
go down in column's moving to next 3 images and then again for last 3
images. making total of 9 images in the canvas. also going to add a
pixal to LAT LON if anyone is interested in that.
------------------------------
Date: 25 Oct 2009 05:15:28 -0700
From: dba.9999@gmail.com
Subject: Re: File locking using threads
Message-Id: <hc1fh002gc7@drn.newsguy.com>
In article <48e6e1e3-bc67-4171-83a5-d39b4b5d38ac@r36g2000vbn.googlegroups.com>,
Prince Al says...
>sub flock_test {
> open(my $fh, ">", "/tmp/flock_test.dat");
> my $sleep_1 = $_[0];
> my $sleep_2 = $_[1];
> my $thread_name = $_[2];
>
> sleep $sleep_1;
why do you even have to lock the file via flock. Threads can lock
variables and that is faster and safer. Just create a shared variable
which you can use as a semaphore between threads. Unless that variable
is locked first, no thread can write to the file. Release the lock
once written.
I have done this in my of my scripts and it works great.
------------------------------
Date: Sun, 25 Oct 2009 11:35:16 -0700 (PDT)
From: Prince Al <timothy.hill@gmail.com>
Subject: Re: File locking using threads
Message-Id: <483becc6-0cc6-4065-baab-69b84fd73113@p9g2000vbl.googlegroups.com>
Hi,
Many thanks for the replies so far - very much appreciated! I tried
your various suggestions on my Linux machine and they worked like a
charm, however, moving this code onto the work servers did not prove
quite so fruitful... This are running Solaris (HP-UX B.11.11 U) and
given the way most things are at my company, configured incorrectly!
To answer a question posed above, the reason I want to lock a file
instead of using shared variables is because there will potentially be
many instances of the final script running and I want a way to manage
machine resources. I am writing a data load scheduler by the way...
So, when an instance of the script wants to grab a resource, it locks
the file and subtracts 1 (for example) from the number contained in
the file and when it finishes, it locks the file and adds 1 to the
contents of the file. In a nutshell.
Hopefully that is clear enough! Again, thanks in advance for any
assitance :)
Cheers
Tim
------------------------------
Date: 25 Oct 2009 18:55:38 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: File locking using threads
Message-Id: <7kjl9aF3atbq1U1@mid.uni-berlin.de>
Prince Al <timothy.hill@gmail.com> wrote:
> Many thanks for the replies so far - very much appreciated! I tried
> your various suggestions on my Linux machine and they worked like a
> charm, however, moving this code onto the work servers did not prove
> quite so fruitful... This are running Solaris (HP-UX B.11.11 U) and
> given the way most things are at my company, configured incorrectly!
Out of curiosity, How was it mis-configured not to let you get a
lock on a file? The only thing I can think of at the moment is
that the file to be locked is on an NFS mounted disk and the
normal (non-Perl but POSIX) flock() function often does not
work with NFS - and usually Perl's flock() function is based on
POSIX's flock() function. If that should be the case you might
be better off using the POSIX fcntl() function, with one way to
do that would be to use a module I uploaded to CPAN, called
File::FcntlLock (current version is 0.12).
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Sun, 25 Oct 2009 13:21:46 -0700 (PDT)
From: Prince Al <timothy.hill@gmail.com>
Subject: Re: File locking using threads
Message-Id: <42db6621-b282-4a17-b60f-3e1e8f6d4dbd@m20g2000vbp.googlegroups.com>
On Oct 25, 6:55=A0pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> Out of curiosity, How was it mis-configured not to let you get a
> lock on afile? The only thing I can think of at the moment is
> that thefileto be locked is on an NFS mounted disk ...
Hi Jens,
Sorry, after re-reading my post, I realised that bit might have been
unclear! I have no idea if there is a mis-configuration - I was just
musing out loud and was wondering if there could be such a scenario to
prevent this from working. Instead of placing the file to be locked
in /tmp, I have placed it in my home directory to test the scenario
about different mounts out, with the same results...
My current script is pasted below, oh, and the version of Perl we have
on the server is 5.8.3, if that is any use.
Thanks again for any help!
Cheers
Tim
#!usr/bin/perl
use strict;
use threads;
use Fcntl qw/:flock/;
my @args_1 =3D (5, 20, "Thread 1");
my @args_2 =3D (10, 5, "Thread 2");
my $thr_1 =3D threads->new(\&flock_test,5, 20, "Thread 1");
my $thr_2 =3D threads->new(\&flock_test,10, 5, "Thread 2");
$_->join for $thr_1,$thr_2;
sub flock_test {
open(my $fh, ">", "/home/thill/flock_test.dat");
my $sleep_1 =3D $_[0];
my $sleep_2 =3D $_[1];
my $thread_name =3D $_[2];
sleep $sleep_1;
#flock($fh,LOCK_EX) || die "Could not acquire the lock\n";
print "$thread_name: acquired lock!\n";
sleep $sleep_2;
close $fh;
print "$thread_name: released lock!\n";
}
------------------------------
Date: 25 Oct 2009 20:46:18 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: File locking using threads
Message-Id: <7kjroqF3a09bmU1@mid.uni-berlin.de>
Prince Al <timothy.hill@gmail.com> wrote:
> On Oct 25, 6:55Â pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> > Out of curiosity, How was it mis-configured not to let you get a
> > lock on afile? The only thing I can think of at the moment is
> > that thefileto be locked is on an NFS mounted disk ...
> Sorry, after re-reading my post, I realised that bit might have been
> unclear! I have no idea if there is a mis-configuration - I was just
> musing out loud and was wondering if there could be such a scenario to
> prevent this from working. Instead of placing the file to be locked
> in /tmp, I have placed it in my home directory to test the scenario
> about different mounts out, with the same results...
> My current script is pasted below, oh, and the version of Perl we have
> on the server is 5.8.3, if that is any use.
> #!usr/bin/perl
That's rather likely meant to be
#!/usr/bin/perl
> use strict;
> use threads;
> use Fcntl qw/:flock/;
> my @args_1 = (5, 20, "Thread 1");
> my @args_2 = (10, 5, "Thread 2");
> my $thr_1 = threads->new(\&flock_test,5, 20, "Thread 1");
> my $thr_2 = threads->new(\&flock_test,10, 5, "Thread 2");
> $_->join for $thr_1,$thr_2;
> sub flock_test {
> open(my $fh, ">", "/home/thill/flock_test.dat");
> my $sleep_1 = $_[0];
> my $sleep_2 = $_[1];
> my $thread_name = $_[2];
> sleep $sleep_1;
> #flock($fh,LOCK_EX) || die "Could not acquire the lock\n";
> print "$thread_name: acquired lock!\n";
> sleep $sleep_2;
> close $fh;
> print "$thread_name: released lock!\n";
> }
Mmm, since you commented out the line where flock() is called
I would expect that you won't get a lock but also no error
message that locking failed;-)
Another thing I notice, which might result in trouble, is that
both threads open the file in write mode ('>'). That leads to
both threads emptying the file (i.e. possibly modifying it)
before asking for the lock which, as far as I have understood
your intentions, isn't what you're planning to do. I guess it
would make more sense to use '+<' (or '>>') instead of '>' when
opening the file to avoid that.
And, BTW, using 'use warnings;' is usually rather useful;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Sun, 25 Oct 2009 14:07:21 -0700 (PDT)
From: Prince Al <timothy.hill@gmail.com>
Subject: Re: File locking using threads
Message-Id: <941ec334-63cc-4b3c-aad1-6fad2708700c@q14g2000vbi.googlegroups.com>
On Oct 25, 8:46=A0pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> #!/usr/bin/perl
Thanks - corrected.
> Mmm, since you commented out the line where flock() is called
> I would expect that you won't get a lock but also no error
> message that locking failed;-)
Dang - not making a good first impression here, am I?! I did actually
notice this just before I replied and tested the code without the
crucial line commented out, but same result. I obviously forgot to re-
copy the updated code...
> Another thing I notice, which might result in trouble, is that
> both threads open the file in write mode ('>'). That leads to
> both threads emptying the file (i.e. possibly modifying it)
> before asking for the lock which, as far as I have understood
> your intentions, isn't what you're planning to do. I guess it
> would make more sense to use '+<' (or '>>') instead of '>' when
> opening the file to avoid that.
Fair point, thank you.
> And, BTW, using 'use warnings;' is usually rather useful;-)
Done
------------------------------
Date: 25 Oct 2009 21:21:25 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: File locking using threads
Message-Id: <7kjtqlF35pppeU1@mid.uni-berlin.de>
Prince Al <timothy.hill@gmail.com> wrote:
> > Mmm, since you commented out the line where flock() is called
> > I would expect that you won't get a lock but also no error
> > message that locking failed;-)
> Dang - not making a good first impression here, am I?! I did actually
> notice this just before I replied and tested the code without the
> crucial line commented out, but same result. I obviously forgot to re-
> copy the updated code...
S**t happens;-) But what is actually the "same result"? And
are you sure that your home directory isn't on a NFS mounted
partition or that flock() on the system you're testing this
on works with NFS partitons? I guess the man page for flock(2)
should tell you (or, if it's silent abut that topic it might
be better to assume that that it doesn't work wit NFS).
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Sun, 25 Oct 2009 22:49:28 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Indirection in a hash
Message-Id: <slrnhe9hv9.v56.hjp-usenet2@hrunkner.hjp.at>
On 2009-10-23 06:25, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Mart van de Wege <mvdwege@mail.com> wrote:
>>jt@toerring.de (Jens Thoms Toerring) writes:
>>> "multidimensional arrays" (I put that in parantheses since there
>>> aren't real multi- dimensional arrays in Perl but instead you use
>>> arrays of array references to emulate them).
>>
>>(ITYM quotes, not parentheses).
>>
>>What is the difference? Surely this is the most obvious way to implement
>>multidimensional arrays on a lower level?
>
> Actually no because individual elements cannot be accessed directly with
> O(1) by pre-calculating the memory location. Instead in Perl the
> low-level implementation has to follow the reference chain for each and
> every access.
Unless you are talking about constant indexes, the complexity is the
same: O(n) for n dimensions in both cases.
But the operations are different: With a multidimensional array, it's a
multiplication and an addition for each dimension; with a nested array
of references (that's called an Iliffe vector, btw) it's a memory
reference and an addition for each dimension. So which one is faster
depends on the relative speed of a memory access and a multiplication.
On modern CPUs, a multiplication is a lot faster than a memory access,
so multidimensional arrays are faster. However, 20+ years ago that wasn't
so clear: In one of our introductory programming courses we had to
implement some algorithm with both multidimensional arrays and Iliffe
vectors and compare speed and memory consumption. The example was to
show that it's a tradeoff (the rows were of different lengths, so the
Iliffe vector saved space), but we didn't implement in on a VAX (as the
assistand had) but on an 8086, which had slow multiplication (something
like 100-150 cycles, IIRC) and fast memory accesses: So the Iliffe
implementation was both smaller and faster ;-).
>>And if Perl's "array of references" is functionally equivalent to a
>>multidimensional array (and it is), then isn't it a multidimensional
>>array?
>
> That is debateable. Depending upon which level of abstraction you are
> talking about a yes is as justifiable as a no.
Consider this example:
@a = ([1, 2], [3, 4]);
@b = $a[1];
If @a was a two-dimensional array (or an array of arrays), then I would
expect @b to contain (3, 4) after this snippet. But it doesn't. Instead
@b contains only one element which is a reference to an array. I have to
explicitely derefence $a[1]:
@b = @{ $a[1] };
For me that is sufficiently different from the semantics of a
multidimensional array that I cannot view Perl Iliffe arrays of
references as multidimensional arrays.
Note that this is a difference at the language level - it has nothing to
do with the implementation.
hp
------------------------------
Date: Sun, 25 Oct 2009 23:01:02 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Indirection in a hash
Message-Id: <slrnhe9il0.v56.hjp-usenet2@hrunkner.hjp.at>
On 2009-10-23 06:56, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "MvdW" == Mart van de Wege <mvdwege@mail.com> writes:
> MvdW> Surely this is only true if the dimensions are of unknown
> MvdW> size. If your data model is such that you expect to have fixed
> MvdW> size arrays, you can still directly index into it, even with
> MvdW> Perl's model.
>
> no you can't. with perl all array accesses require looping over each
> dimension.
I think "looping over each dimension" may be ambiguous. To clarify,
consider a 3-dimensional array with n_x * n_y * n_z elements.
With a multidimensional array, to access a[x][y][z], a C compiler would
generate code like this (pseudo assembly):
r1 <- x * n_y
r1 <- r1 + y
r1 <- r1 * n_z
r1 <- r1 + z
r1 <- a[r1]
With an Iliffe vector, the code would look like this:
r1 <- a[x]
r1 <- r1[y]
r1 <- r1[z]
hp
------------------------------
Date: Sun, 25 Oct 2009 11:07:38 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Shifting error codes
Message-Id: <cc77263c-183b-410d-b86a-c94c48edbc14@g1g2000vbr.googlegroups.com>
Hi,
The code I maintain used to shift values meant as exit codes.
# Shift the status up so it looks like an exit status.
$rc = $2 << 8;
This practice seemed justified by the paragraph on $? in perlvar,
although, and this is my question, I am not sure how to read it
anymore.
I found that the return codes were not as expected:
$ perl -e 'exit 255'; echo $?
255
$ perl -e 'exit 256'; echo $?
0
So, should one ever shift codes leftwards,
or only rightwards codes received from sub-processes?
Thanks,
Marc
------------------------------
Date: 25 Oct 2009 21:33:49 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: Shifting error codes
Message-Id: <7kjuhtF3a3gtfU1@mid.uni-berlin.de>
Marc Girod <marc.girod@gmail.com> wrote:
> The code I maintain used to shift values meant as exit codes.
> # Shift the status up so it looks like an exit status.
> $rc = $2 << 8;
> This practice seemed justified by the paragraph on $? in perlvar,
> although, and this is my question, I am not sure how to read it
> anymore.
> I found that the return codes were not as expected:
> $ perl -e 'exit 255'; echo $?
> 255
> $ perl -e 'exit 256'; echo $?
> 0
Looks like you're on some kind of UNIX. And on UNIX the exit
value of a program is the lowest 8 bits of the return status
value only (i.e. a value between 0 and 255), higher bits being
used for information why the process stopped (e.g. normally by
calling exit() or because it was killed due to a signal etc.).
IIRC, higher order bits in the value passed to exit() simply
get masked out, so they don't make it through to '$?'.
> So, should one ever shift codes leftwards,
As long as you can guarantee that the result isn't larger
than 255 it's ok, otherwise things won't work as expected.
> or only rightwards codes received from sub-processes?
Sorry, but I don't understand what's meant by this.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 2650
***************************************
