[28230] in Perl-Users-Digest
Perl-Users Digest, Issue: 9594 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 12 00:05:43 2006
Date: Fri, 11 Aug 2006 21:05:03 -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 Fri, 11 Aug 2006 Volume: 10 Number: 9594
Today's topics:
Re: autosave everytime loops runs <benmorrow@tiscali.co.uk>
Re: flock not locking <benmorrow@tiscali.co.uk>
Re: Implicit iterator variable $_ changing to ### upon <dbasch@yahoo.com>
Re: Implicit iterator variable $_ changing to ### upon <mumia.w.18.spam+nospam.usenet@earthlink.net>
Re: Implicit iterator variable $_ changing to ### upon <uri@stemsystems.com>
Re: Is there arithmetic sequence represents? <benmorrow@tiscali.co.uk>
jobs.perl.org <DJStunks@gmail.com>
Re: jobs.perl.org <uri@stemsystems.com>
Re: Parsing text to array <benmorrow@tiscali.co.uk>
Re: regex and utf8 characters (german umlauts) <benmorrow@tiscali.co.uk>
Re: win32 sysread on socket hangs when requested == rec <none@not.no>
Re: win32 sysread on socket hangs when requested == rec <jgibson@mail.arc.nasa.gov>
Re: win32::printer and text formatting <diavolo-verde@libero.it>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 11 Aug 2006 23:27:49 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: autosave everytime loops runs
Message-Id: <5scvq3-7qj.ln1@osiris.mauzo.dyndns.org>
Quoth Jim Gibson <jgibson@mail.arc.nasa.gov>:
> In article <1155321938.120111.274250@75g2000cwc.googlegroups.com>, Shan
> <Shani718@gmail.com> wrote:
>
> > ok so I have the following:
> >
> > open my $OUT, '>', 'write.tsv' or die "Error: $!";
> >
> > write.tsv is the file I want my results printed to.
> >
> > I want the file to be saved everytime a loop runs so that if the
> > program crashes I still have the information that was processed.
>
> Perl doesn't have a "save" statement. I believe what you are saying is
> that you want to write your data out to the file every time the loop
> runs. So do so.
You may also want to see the methods 'flush' and 'sync' in IO::Handle
(hint: you want to use both of them, in that order :) ), or the special
var $|.
> > So i guess I need a save statement inside the loop but i Dont know of
> > any statements, do yoo?
>
> The Perl statements to write to a file are print and printf (and in
> more complex or binary applications, write and syswrite.
More complex, maybe. print and printf both handle binary data just fine.
Ben
--
Outside of a dog, a book is a man's best friend.
Inside of a dog, it's too dark to read.
benmorrow@tiscali.co.uk Groucho Marx
------------------------------
Date: Fri, 11 Aug 2006 23:19:43 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: flock not locking
Message-Id: <vccvq3-7qj.ln1@osiris.mauzo.dyndns.org>
Quoth xhoster@gmail.com:
> Ben Morrow <benmorrow@tiscali.co.uk> wrote:
> > Quoth xargle@eh.org:
>
> > > while(1)
> > > {
> > > print STDOUT getpid() . " requesting LOCK_EX\n";
> > > flock LOCKFILE,2 or die "cant flock: $!"; # 2 = LOCK_EX, exclusive
> > > lock
> >
> > Don't *ever* hardcode flock values. Get them from the Fcntl module:
> >
> > use Fcntl qw/:flock/;
> >
> > flock LOCKFILE, LOCK_EX;
> >
> > > print STDOUT getpid() . " has gained LOCK_EX\n";
> > > my $client = $socket->accept();
> > > print STDOUT getpid() . " accepted connection from " .
> > > $client->sockhost . " and will unlock listener\n";
> > > flock LOCKFILE,8 or die "cant flock: $!"; # 8 = LOCK_UN, unlock
> >
> > This may have been one of the rare cases that an explicit LOCK_UN wasn't
> > a bug, but as you have to reopen the file to get a new lock anyway
> > you're better off closing it to unlock.
>
> I don't agree with you in this specific context. He only needs to open the
> file once per process, i.e. once per fork. He can simply lock and unlock
> it inside the accept loop (or at least I see no reason he can't do it that
> way). There is no need to (re)open the file after every accept, only after
> every fork.
You are right (of course :) ). However, there's no *harm* in reopening
the file either (as each child opens it individually, the problem of
someone moving the file out from under you is not being dealt with
anyway), and I at least find variable scope a natural way of dealing
with resources that need freeing.
Ben
--
Although few may originate a policy, we are all able to judge it.
Pericles of Athens, c.430 B.C.
benmorrow@tiscali.co.uk
------------------------------
Date: 11 Aug 2006 15:22:43 -0700
From: "Derek Basch" <dbasch@yahoo.com>
Subject: Re: Implicit iterator variable $_ changing to ### upon variable assignment?
Message-Id: <1155334963.027305.111550@p79g2000cwp.googlegroups.com>
Michele Dondi wrote:
> On 11 Aug 2006 13:34:56 -0700, "Derek Basch" <dbasch@yahoo.com> wrote:
>
> > foreach $_ ($self->accessors()) {
> > print "$_\n";
> > my $value = $self->_accessor_class($_)->get($_);
> ^^ ^^
> ^^ ^^
>
> [snip]
>
> >$self->accessors returns an array of accessor names
>
> So far so fine.
>
> >$self->_accessor_class returns a hash ref to a class
>
> Which happens to be... what?!?
A subclass of Class::Accessor.
> And what does it expect as an argument?
An accessor name.
>
> >$self->get returns a scalar value
>
> And what does it expect as an argument?
An accessor name.
> But most importantly in the code above get() is not a method of $self,
> but of the object _accessor_class($_).
Yes, $self is an aggregated class and the get methods are different for
each aggregated class.
Class_B <---has a---$self----has a---> Class_A
| |
v v
sub get() sub get()
> All in all it seems *strange*, although not strictly impossible, that
> you want to pass $_ to both methods above.
$self uses the name of the accessor (_accessor_class) to determine
which aggregated class has the proper get function. get takes the
accessor name to know which value to get.
> Also the fact that
> accessors() returns an array of accessor names suggest that you are
> fiddling with symrefs. You may return proper $method refs, and call
> them like thus instead:
>
> my $value = $self->$method(...);
I suppose calling:
get('accessor_name')
is essentially like using a symref but I think this is what would be
what would be considered a true symref call:
foreach $_ ($self->accessors()) {
my $value = $self->_accessor_class($_)->$_;
}
The only other way I can think of to handle this would be to return a
hash of method references from the accessors() function:
foreach $_ ($self->accessors()) {
my $value = $self->_accessor_class($_)->{'$_'};
}
and isn't that exactly what a class hash reference is in Perl?
I apologize for not being verbose enough with my example but I didn't
want to put 300 lines of code in my message. 300 lines would have been
the concise version too.
Thanks for the help,
Derek Basch
OkbridgeDatabase::Gps->mk_accessors(OkbridgeDatabase::Gps->accessors());
sub accessors {
my @accessors = (
'password',
'user_id',
'first_login',
'last_login',
>
> To make a long story short: hard to say anything without looking at
> the rest of your code. So, as usual, may you prepare a suitable
> minimal but complete example exhibiting the problem? Also you'd better
> state more clearly what you're actually trying to do.
>
>
> Michele
> --
> {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
> (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
> .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
> 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 11 Aug 2006 23:04:25 GMT
From: "Mumia W." <mumia.w.18.spam+nospam.usenet@earthlink.net>
Subject: Re: Implicit iterator variable $_ changing to ### upon variable assignment?
Message-Id: <Z18Dg.3102$Qf.1311@newsread2.news.pas.earthlink.net>
On 08/11/2006 04:22 PM, Derek Basch wrote:
> Derek Basch wrote:
>> Derek Basch wrote:
>>> Hello all,
>>>
>>> I have ran into a very confusing problem and I hoped someone could help
>>> me. This function is supposed to return a hash of the accessors and
>>> their associated values for a given class.
>>>
>>>
>>> ------------------------------------------
>>> package Test;
>>>
>>> sub accessors_values {
>>> my $self = shift;
>>> my %accessors_values;
>>>
>>> foreach $_ ($self->accessors()) {
>>> print "$_\n";
>>> my $value = $self->_accessor_class($_)->get($_);
>>> print "$_ : $value\n";
>>> }
>>> return %accessors_values;
>>> }
>>>
>>> ........
>>>
>>> ------------------------------------------
>>>
>>> Gives this output:
>>> ------------------------------------------
>>> password
>>> ### : carefree
>>> user_id
>>> ### : 323227
>>> first_login
>>> ### : 2006.08.08.12.47.13
>>> last_login
>>> ### : 2006.08.08.12.47.13
>>> ------------------------------------------
>>>
>>> Where the heck is the '###' coming from? How is assigning a value to
>>> the $value variable causing the implicit iterator variable $_ to become
>>> '###' ?
>>>
>>> The functions that the code calls are large so I will give a synopsis
>>> of what they return:
>>>
>>> $self->accessors returns an array of accessor names
>>> $self->_accessor_class returns a hash ref to a class
>>> $self->get returns a scalar value
>>>
>>> Any help is greatly appreciated.
>>>
>>> Thanks,
>>> Derek Basch
>> I answered my own question. The implicit iterator was apparently being
>> set to "##" by one of the functions that I called from within the sub.
>> I didn't realize that it could be affected in such a way. Live and
>> learn I guess.
>>
>> Thanks Anyways,
>> Derek Basch
>
> Note that the way I found this error was by trying to do this:
>
> %accessors_values = map { $iter =>
> $self->_accessor_class($iter)->get($iter) } $self->accessors();
>
> The foreach above was my attempt to break the problem into smaller
> units for testing.
> So, you can solve this problem by not using the implicit iterator with
> a foreach loop.
>
> What I didn't mention was that the get function above uses a "while
> <FILEHANDLE>"
> loop. The "while <FILEHANDLE>" loop uses an implicit iterator and the
> map function also uses an implicit iterator.
>
> So, if you use map with an EXPR that uses the "while <FILEHANDLE>"
> idiom the map implicit iterator value will be replaced with the "while
> <FILEHANDLE>" implicit iterator value. You must use foreach instead of
> map.
>
> I hope that helps someone in the future :)
>
> Derek Basch
>
Indeed it probably will; it'll remind people to use local ;-)
#!/usr/bin/perl
package Tryit;
use strict;
use warnings;
my @fun = map { get(); $_ } (1..4);
print "@fun\n";
sub get {
# What happens when you comment out the "local"
# below?
local $_;
while (<DATA>) {
last if /###/;
}
}
__DATA__
nothing here
### more hash marks ###
------------------------------
Date: Fri, 11 Aug 2006 23:19:58 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Implicit iterator variable $_ changing to ### upon variable assignment?
Message-Id: <x7hd0ivdwh.fsf@mail.sysarch.com>
>>>>> "MW" == Mumia W <mumia.w.18.spam+nospam.usenet@earthlink.net> writes:
MW> On 08/11/2006 04:22 PM, Derek Basch wrote:
>> Note that the way I found this error was by trying to do this:
>> %accessors_values = map { $iter =>
>> $self->_accessor_class($iter)->get($iter) } $self->accessors();
>> The foreach above was my attempt to break the problem into smaller
>> units for testing.
>> So, you can solve this problem by not using the implicit iterator with
>> a foreach loop.
>> What I didn't mention was that the get function above uses a "while
>> <FILEHANDLE>" loop. The "while <FILEHANDLE>" loop uses an implicit
>> iterator and the map function also uses an implicit iterator.
>> So, if you use map with an EXPR that uses the "while <FILEHANDLE>"
>> idiom the map implicit iterator value will be replaced with the
>> "while <FILEHANDLE>" implicit iterator value. You must use foreach
>> instead of map.
>> I hope that helps someone in the future :)
>> Derek Basch
>>
MW> Indeed it probably will; it'll remind people to use local ;-)
better if it reminds people to not use $_ all the time. with loops it is
much better to use a lexical var and then you never can have anything
like this happen. and your code becomes easier to read as you have a
named variable for each loop and it is lexical and never is seen by any
called subs or maps.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Fri, 11 Aug 2006 22:56:44 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Is there arithmetic sequence represents?
Message-Id: <s1bvq3-pdj.ln1@osiris.mauzo.dyndns.org>
Quoth Ted Zlatanov <tzz@lifelogs.com>:
> On 10 Aug 2006, anno4000@radom.zrz.tu-berlin.de wrote:
>
> > Ted Zlatanov <tzz@lifelogs.com> wrote in comp.lang.perl.misc:
>
> >> my $start = shift @_;
> >
> > "shift @_" is the same as just "shift", which is much more common in
> > this function.
>
> I know this. I prefer to be explicit. I also say "shift @ARGV" in
> the main body, so it's clear what I'm shifting.
It is clear what you're shifting: an unqualified 'shift' shifts off the
current argument list (in all cases). Writing the @_ explicitly simply
causes someone who knows Perl to have to do a double-take and verify
that the code is in fact shifting @_.
> >> my $increment = shift @_;
> >> my $end = shift @_;
> >
> > If you have many arguments to pass (three is many), most people
> > would write that:
> >
> > my ( $start, $increment, $end) = @_;
>
> Great. My style is to do one per line, so I can comment each one
> separately. I am aware of the (very minor) penalty, I think clear
> comments are worth the sacrifice.
If you need to comment every parameter of a function (except in very
special cases) then you really need to give your variables better names
:). A comment (or, better, POD) above the function explaining what
parameters it takes and what they signify is, of course, a good idea.
OTOH, putting every parameter on its own line with its own bit of '=
shift @_;' boilerplate makes it much harder to see what the function is
actually doing.
> >> my @ret;
> >>
> >> while ($start <= $end)
> >> {
> >> push @ret, $start;
> >> $start += $increment;
> >> }
> >>
> >> return @ret;
> >> }
> >>
> >> print "$_\n" foreach matlab_list(2, 2, 12);
> >
> > There's nothing wrong with your function, but it's awfully roundabout.
> > Apart from the argument-passing, you failed to follow Tony Curtis'
> > advice (still preserved near the beginning) to use map for list
> > generation. Your loop can be replaced with a little arithmetic
> > and a map:
> >
> > sub matlab_list {
> > my ( $start, $inc, $end) = @_;
> > map $start + $inc*$_, 0 .. ($end - $start)/$inc;
> > }
>
> I think my function is more suitable for a beginner example. The
> function you show is absolutely terrible for that purpose IMHO. In
> terms of efficiency I agree with you, but I wasn't aiming for that.
Efficiency has nothing to do with it: Anno's version is much clearer. I
would perhaps agree that for a beginner who has some experience with
C-like or Pascal-like languages an explanation of what map does in terms
of a loop might be helpful, but if we wish to teach people to write Perl
as opposed to C-as-a-subset-of-Perl then this is a very good example of
when map makes things substantially simpler. (Not that there's anything
*wrong* with writing C-as-a-subset-of-Perl if that's all someone is
prepared or able to learn, but I would have thought that in this group
we should be encouraging people to learn to use Perl properly. Otherwise
they'll never love it :).)
Ben
--
The cosmos, at best, is like a rubbish heap scattered at random.
Heraclitus
benmorrow@tiscali.co.uk
------------------------------
Date: 11 Aug 2006 16:31:03 -0700
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: jobs.perl.org
Message-Id: <1155339063.294201.143390@p79g2000cwp.googlegroups.com>
Hey all,
Earlier this week I counselled a poster here in clpm to visit
jobs.perl.org in order to find a Perl developer/consultant willing to
take on his specific, if simple, task.
(http://groups.google.com/group/comp.lang.perl.misc/msg/7aade7d5b89ab749)
I thought I ought to investigate jobs.perl.org myself as I think I
could start addressing simple script requirements such as the one
above. I assumed it would be a simple transaction - perl code in
return for PayPal or something similar. However, after visiting the
site, most of the posts (almost all that I saw) were for permanent or
semi-permanent positions. Is this the right site for one-off script
requests like the one above? If so, any tips on finding those needles
in the haystacks of "real" jobs?
I know many of you have you have your own websites advertising your
Perl consulting skills and this may be another route, but I really
didn't want to get that serious.
Anyway, any tips or ideas would be appreciated.
TIA,
-jp
------------------------------
Date: Fri, 11 Aug 2006 23:30:51 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: jobs.perl.org
Message-Id: <x7d5b6vdec.fsf@mail.sysarch.com>
>>>>> "DS" == DJ Stunks <DJStunks@gmail.com> writes:
DS> I thought I ought to investigate jobs.perl.org myself as I think I
DS> could start addressing simple script requirements such as the one
DS> above. I assumed it would be a simple transaction - perl code in
DS> return for PayPal or something similar. However, after visiting the
DS> site, most of the posts (almost all that I saw) were for permanent or
DS> semi-permanent positions. Is this the right site for one-off script
DS> requests like the one above? If so, any tips on finding those needles
DS> in the haystacks of "real" jobs?
there are some of those one off jobs posted there but not a large
number. my problem with small jobs like that is that they are usually
poorly specified and also for very low pay. unless you can whip out
functioning code in no time and somehow make it do something like what
they want, these jobs become exercises in pain and slavery. they often
have moving targets due to the poor specs and they can sometimes be hard
to get paid upon delivery. note that this not an indictment of the jobs
list (which i founded many years ago) but of small one off projects in
general.
and there are sites/lists for those sorts of jobs and i stopped going to
them. site names like rentacoder or guru etc. you bid on poorly written
specs (e.g. i want a site like google.com in 1 week for $200) against
others who specialize in whipping out those dinky projects. you spend
more time bidding then developing. some even have requests for perl but
once you read typical job requirements you will be scared away too
(unless you have the mentality to hack those projects and make a
living).
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Fri, 11 Aug 2006 22:40:57 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Parsing text to array
Message-Id: <94avq3-pdj.ln1@osiris.mauzo.dyndns.org>
Quoth Ala Qumsieh <notvalid@email.com>:
> usenet@DavidFilmer.com wrote:
>
> > Philipp wrote:
> >>Or should I use split and iterate through
> >
> >
> > That would be the worst approach.
>
> The worst in what sense? And compared to what?
> It seems to me to be much easier to comprehend by someone else reading
> the code,
...who doesn't know Perl at all. If you're going to code for people like
that you might as well give up.
> as compared with Anno's map() solution.
Which is entirely standard Perl. Not understanding map is nearly as bad
as not understanding hashes: it is a fundamental part of Perl.
Ben
--
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks] benmorrow@tiscali.co.uk
------------------------------
Date: Fri, 11 Aug 2006 23:16:26 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: regex and utf8 characters (german umlauts)
Message-Id: <q6cvq3-7qj.ln1@osiris.mauzo.dyndns.org>
Quoth Ted Zlatanov <tzz@lifelogs.com>:
> On 10 Aug 2006, benmorrow@tiscali.co.uk wrote:
> > Quoth Ted Zlatanov <tzz@lifelogs.com>:
> >> On 10 Aug 2006, ext-dirk.heinrichs@nokia.com wrote:
> >>
> >>> the following little perl snippet
> >>>
> >>> perl -e '($string = "AAA <c4><c4><c4> BBB CCC DDD") =~
> >>> s/(\p{IsUpper}+)/\L\u\1\E/g; print $string . "\n"'
<snip my comment>
> >>> gives this result:
> >>>
> >>> Aaa <c4><c4><c4> Bbb Ccc Ddd
> >>>
> >>> How do I turn those umlauts into "<c4><e4><e4>" also? I tried adding
> >>> "use utf8;", but that didn't help.
> >>
> >> The utf8 pragma won't make a difference. <e4> is ASCII code 196.
> >
> > There is No Such Thing as 'ASCII code 196'. ASCII only goes up to 127.
> >
> > As the post arrived here, the section of code represented above by
> > '<c4><c4><c4>' is 3 bytes long. This is not valid UTF8, so if these
> > three bytes are actually in your file you have a problem.
>
> The OP had a word made of three A-umlaut characters, to indicate that
> the second and third were not lowercased automatically.
The OP had three bytes 0xc4. Whether or not this is three A-umlaut
characters depends on what encoding you are assuming the source is
written in. In UTF-8, these three bytes are invalid. In ASCII, these
three bytes are invalid. In ISO8859-1 they are three A-umlaut
characters. In ISO8859-7 (to pick a random example) it is three capital
deltas.
> The ord() of those is 196, which is 0xC4 in hex. The OP wants the
> second and third to become 0xE4 which is a-umlaut. Did I
> misunderstand something?
The ord of A-umlaut is 0xc4, yes. This is not relevant here: which bytes
are used to represent a character depend on which encoding is in use.
This is not just irrelevant nit-picking: it really matters. See
http://www.joelonsoftware.com/articles/Unicode.html .
> Where is it implied that utf8 encoding matters?
The OP stated that he tried adding 'use utf8;'. This is a statement to
Perl that his source is in UTF8, which in this case is not true. What he
should have done was added the statement 'use encoding "iso8859-1";',
which is true. Lieing to Perl is almost never a good idea :).
> I really think this is a locale issue.
It's not. It's to do with perl's rather nasty[0] bytewards-compatibility
mode.
Ben
[0] In case anyone gets the wrong idea, this is not a criticism. The
problem required to be solved (work both with people who want proper
Unicode handling and people who want to carry on assuming all charsets
are single-byte supersets of ASCII, without anyone noticing anything
weird's going on) is ultimately insoluble, and perl generally does a
good job. When it doesn't it can always be persuaded to by the addition
of appropriate calls to Encode.
--
Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
'Alcestis') [ flame, and falls out of sight. ] benmorrow@tiscali.co.uk
------------------------------
Date: Fri, 11 Aug 2006 17:08:31 -0700
From: Frank Fredstone <none@not.no>
Subject: Re: win32 sysread on socket hangs when requested == received
Message-Id: <87y7tun7cw.fsf@not.no>
Frank Fredstone <none@not.no> writes:
> My client blocks if the number of characters sysread reads are the same
> as the number requested, e.g.:
I'm confused actually. It's not that it is the number of bytes that
are requested. It will return 0 once.
If sysread returns 0, and the socket is not closed, it
will block if I call sysread again, while waiting for more data.
So, if I determine that the next read is going to block, how do I
avoid the blocking, but still check for more data?
the end
> my $sock = new IO::Socket::INET (PeerAddr => 'localhost',
> PeerPort => "$ARGV[0]",
> Proto => 'tcp',
> );
> die "Could not create socket: $!\n" unless $sock;
>
> # the result is the same without the following line
> binmode $sock, ':utf8';
>
> $sock->blocking(0);
> my $buf = "";
> while (1) {
> my $tmp = "";
> my $res = sysread $sock, $tmp, 134;
> printf STDERR "res=%d\n", $res;
> if (defined $res) {
> if ($res < 1) {
> last;
> }
> } elsif ($! == EWOULDBLOCK) {
> next;
> } else {
> die "sysread() error: $!";
> }
> $buf .= $tmp;
> print STDERR "buf=$buf\n";
> if (length($tmp) < 134) {
> last;
> }
>
> With the above code, if 133 or 135 characters are sent by the server,
> it works, but if 134 are sent, the next sysread never returns.
>
> The same is true for exact multiples, e.g. if 268 characters are received
> with 134 requested, the last sysread hangs.
>
> Do you know a solution to this?
------------------------------
Date: Fri, 11 Aug 2006 17:13:34 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: win32 sysread on socket hangs when requested == received
Message-Id: <110820061713346393%jgibson@mail.arc.nasa.gov>
In article <877j1fnkw1.fsf@not.no>, Frank Fredstone <none@not.no> wrote:
> My client blocks if the number of characters sysread reads are the same
> as the number requested, e.g.:
>
> my $sock = new IO::Socket::INET (PeerAddr => 'localhost',
> PeerPort => "$ARGV[0]",
> Proto => 'tcp',
> );
> die "Could not create socket: $!\n" unless $sock;
>
> # the result is the same without the following line
> binmode $sock, ':utf8';
If this line doesn't matter, then please leave it out.
>
> $sock->blocking(0);
> my $buf = "";
> while (1) {
> my $tmp = "";
> my $res = sysread $sock, $tmp, 134;
> printf STDERR "res=%d\n", $res;
> if (defined $res) {
> if ($res < 1) {
> last;
> }
> } elsif ($! == EWOULDBLOCK) {
> next;
> } else {
> die "sysread() error: $!";
> }
> $buf .= $tmp;
> print STDERR "buf=$buf\n";
> if (length($tmp) < 134) {
> last;
> }
This code has a syntax error.
>
> With the above code, if 133 or 135 characters are sent by the server,
> it works, but if 134 are sent, the next sysread never returns.
It doesn't block on my system (perl 5.8.6, Mac OS 10.4).
>
> The same is true for exact multiples, e.g. if 268 characters are received
> with 134 requested, the last sysread hangs.
>
> Do you know a solution to this?
Use select (or IO::Select) to see if data is waiting before trying to
read.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: 11 Aug 2006 16:16:52 -0700
From: "diavolo-verde@libero.it" <diavolo-verde@libero.it>
Subject: Re: win32::printer and text formatting
Message-Id: <1155338212.258786.106810@75g2000cwc.googlegroups.com>
Dr.Ruud ha scritto:
> The Write method has a "format" parameter:
>
> ($width, $height) = $dc->Write($price, $x, $y, RIGHT);
>
>
> diavolo, see the documentation about the reference point.
thanks, RIGHT is my friend, I'm getting what I wanted :-).
BR,
Davide
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9594
***************************************
