[31741] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 3004 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jun 26 00:09:22 2010

Date: Fri, 25 Jun 2010 21:09:06 -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, 25 Jun 2010     Volume: 11 Number: 3004

Today's topics:
        bulk flush input <jak@isp2dial.com>
    Re: bulk flush input <ben@morrow.me.uk>
    Re: bulk flush input <jak@isp2dial.com>
    Re: How to use Regex to breakdown a pattern and use the <gjwpp88@gmail.com>
        Perl in the workplace <cartercc@gmail.com>
        Perl in the workplace <cartercc@gmail.com>
    Re: Perl in the workplace <marc.girod@gmail.com>
    Re: Perl in the workplace (Bradley K. Sherman)
    Re: Perl in the workplace <jak@isp2dial.com>
    Re: Perl in the workplace <tadmc@seesig.invalid>
    Re: Perl in the workplace <peter@makholm.net>
    Re: problem sending email using MIME::Lite from gmail's <hjp-usenet2@hjp.at>
    Re: Proposing a new module: Parallel::Loops <tzz@lifelogs.com>
    Re: Proposing a new module: Parallel::Loops <ben@morrow.me.uk>
    Re: UNIX datagram sockets <mvdwege@mail.com>
    Re: UNIX datagram sockets <jak@isp2dial.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sat, 26 Jun 2010 01:28:29 +0000
From: John Kelly <jak@isp2dial.com>
Subject: bulk flush input
Message-Id: <jbla26h8vtg9orfqcanmgm5jc0unp69ldk@4ax.com>


#!/usr/bin/perl

use strict;
use warnings;

my $data;

while (<>) {
    chomp;
    if (!$data && $_) {
        $data = $_;
    }
}

print "data=$data\n";


This code reads STDIN and remembers the first non-empty line.  That's
all it cares about.

But it also keeps reading till EOF, acting like the "cat" utility, to
flush the extra input and avoid broken pipe errors.

But reading line by line, just to throw away the unwanted garbage, is
inefficient.  I would like to jump out of the loop and "bulk flush" the
remaining input stream.

I don't think 

>$io->flush 

>flush causes perl to flush any buffered data at the perlio
>api level. Any unread data in the buffer will be discarded,

will work, because that it flushes the buffer, not the entire input
stream.  I want to flush the whole file.  And keep in mind, I don't want
a broken pipe either.

Suggestions?



-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 


------------------------------

Date: Sat, 26 Jun 2010 03:21:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: bulk flush input
Message-Id: <kp4gf7-rme1.ln1@osiris.mauzo.dyndns.org>


Quoth John Kelly <jak@isp2dial.com>:
> 
> #!/usr/bin/perl
> 
> use strict;
> use warnings;
> 
> my $data;
> 
> while (<>) {
>     chomp;
>     if (!$data && $_) {
>         $data = $_;
>     }
> }
> 
> print "data=$data\n";
> 
> 
> This code reads STDIN and remembers the first non-empty line.  That's
> all it cares about.

No, it remembers the first line that doesn't evaluate to boolean false.
Since you are chomping the lines, a line containing only "0" will be
considered 'empty'. You want to check length $data.

> But it also keeps reading till EOF, acting like the "cat" utility, to
> flush the extra input and avoid broken pipe errors.
> 
> But reading line by line, just to throw away the unwanted garbage, is
> inefficient.  I would like to jump out of the loop and "bulk flush" the
> remaining input stream.
> 
> I don't think 
> 
> >$io->flush 
> 
> >flush causes perl to flush any buffered data at the perlio
> >api level. Any unread data in the buffer will be discarded,
> 
> will work, because that it flushes the buffer, not the entire input
> stream.  I want to flush the whole file.  And keep in mind, I don't want
> a broken pipe either.
> 
> Suggestions?

    my $data;
    while (<>) {
        chomp;
        length or next;
        $data = $_;
        last;
    }
    {
        local $/ = \2048;
        1 while <>;
    }

Ben



------------------------------

Date: Sat, 26 Jun 2010 02:47:24 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: bulk flush input
Message-Id: <8bqa26d5vn4artd6hldlmpp7jbvkgunpuq@4ax.com>

On Sat, 26 Jun 2010 03:21:08 +0100, Ben Morrow <ben@morrow.me.uk> wrote:

>
>Quoth John Kelly <jak@isp2dial.com>:
>> 
>> #!/usr/bin/perl
>> 
>> use strict;
>> use warnings;
>> 
>> my $data;
>> 
>> while (<>) {
>>     chomp;
>>     if (!$data && $_) {
>>         $data = $_;
>>     }
>> }
>> 
>> print "data=$data\n";
>> 
>> 
>> This code reads STDIN and remembers the first non-empty line.  That's
>> all it cares about.
>
>No, it remembers the first line that doesn't evaluate to boolean false.
>Since you are chomping the lines, a line containing only "0" will be
>considered 'empty'. You want to check length $data.

Yeah, shot myself in the foot again.



>> But it also keeps reading till EOF, acting like the "cat" utility, to
>> flush the extra input and avoid broken pipe errors.
>> 
>> But reading line by line, just to throw away the unwanted garbage, is
>> inefficient.  I would like to jump out of the loop and "bulk flush" the
>> remaining input stream.
>> 
>> I don't think 
>> 
>> >$io->flush 
>> 
>> >flush causes perl to flush any buffered data at the perlio
>> >api level. Any unread data in the buffer will be discarded,
>> 
>> will work, because that it flushes the buffer, not the entire input
>> stream.  I want to flush the whole file.  And keep in mind, I don't want
>> a broken pipe either.
>> 
>> Suggestions?
>
>    my $data;
>    while (<>) {
>        chomp;
>        length or next;
>        $data = $_;
>        last;
>    }
>    {
>        local $/ = \2048;
>        1 while <>;
>    }
>
>Ben

That looks interesting,  I get the first part, the rest will give me
something to chew on ...

Thanks.




-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 


------------------------------

Date: Fri, 25 Jun 2010 10:46:10 -0700 (PDT)
From: ChrisC <gjwpp88@gmail.com>
Subject: Re: How to use Regex to breakdown a pattern and use the pattern to  break down a string
Message-Id: <89c383e0-b132-43e0-8089-a921d5bd0a15@k39g2000yqb.googlegroups.com>

Tad,

I inverted the pattern, SORRY!  It should be "#######XX"

Regards

Jerry


------------------------------

Date: Fri, 25 Jun 2010 06:21:34 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Perl in the workplace
Message-Id: <5adbca05-bb76-425b-ac61-847fb970fdb6@a30g2000yqn.googlegroups.com>

At lunch Wednesday, I took a computer book to read. A stranger asked
me about the book and we struck up a conversation. We conversation was
about technologies used in the workplace (she has an IT job) and the
conversation got around to Perl.

She told me about a job she had previously, where she was told when
she reported to work that one of the other workers had written a
number of Perl scripts, and that she had help run and maintain them.
This was apparently a case where the worker had automated processes
and the employer found them useful enough to keep around.

I told her about my experience -- my job involves reading and writing
data to/from a large institutional database and creating various kinds
of reports. When I started, it was all done by hand, reports were
usually done with MS Office, primarily Excel. I started automating the
big, daily tasks that were critical but also error prone, and now
(five years later) have automated almost all our routine tasks using
Perl. This was a 'bottom up' effort, as none of my upstream knows
Perl.

That got me to wondering. How much of Perl usage is bottom up, rather
than top down? The large businesses in my area pick a technology
(.NET, Java, C++, Struts, Rails, etc.) and require everyone to use
that technology. The people locally that I know who use Perl use it
for individual projects, without official approval or even knowledge.

Is this typical? Or do some significant number of companies make a
deliberate decision to use Perl and impose it in a top down fashion?
Are there any instances of companies having a significant Perl base
and converting it into another technology because of the perceived
unsuitability of Perl?

CC.


------------------------------

Date: Fri, 25 Jun 2010 06:30:09 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Perl in the workplace
Message-Id: <a805bfd4-108f-41f3-8150-18aeef6a3aff@5g2000yqz.googlegroups.com>

At lunch Wednesday, I took a computer book to read. A stranger asked
me about the book and we struck up a conversation. We conversation was
about technologies used in the workplace (she has an IT job) and the
conversation got around to Perl.

She told me about a job she had previously, where she was told when
she reported to work that one of the other workers had written a
number of Perl scripts, and that she had help run and maintain them.
This was apparently a case where the worker had automated processes
and the employer found them useful enough to keep around.

I told her about my experience -- my job involves reading and writing
data to/from a large institutional database and creating various kinds
of reports. When I started, it was all done by hand, reports were
usually done with MS Office, primarily Excel. I started automating the
big, daily tasks that were critical but also error prone, and now
(five years later) have automated almost all our routine tasks using
Perl. This was a 'bottom up' effort, as none of my upstream knows
Perl.

That got me to wondering. How much of Perl usage is bottom up, rather
than top down? The large businesses in my area pick a technology
(.NET, Java, C++, Struts, Rails, etc.) and require everyone to use
that technology. The people locally that I know who use Perl use it
for individual projects, without official approval or even knowledge.

Is this typical? Or do some significant number of companies make a
deliberate decision to use Perl and impose it in a top down fashion?
Are there any instances of companies having a significant Perl base
and converting it into another technology because of the perceived
unsuitability of Perl?

CC.


------------------------------

Date: Fri, 25 Jun 2010 06:38:11 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Perl in the workplace
Message-Id: <3f96e0e7-175d-4614-b390-1dda1811ecc9@d16g2000yqb.googlegroups.com>

On Jun 25, 2:30=A0pm, ccc31807 <carte...@gmail.com> wrote:

> Is this typical? Or do some significant number of companies make a
> deliberate decision to use Perl and impose it in a top down fashion?

Conjecture:

Big companies impose top-down commercial/expensive tools, and adopt
bottom-up free/cheap ones.

The management who is in charge of the expenses has no competence/
interest in technology anyway. They get interested in the budget:
picking expensive tools, they grow their budget, and thus their own
power inside the company.

The game is for them to justify the costs, thus to force people to use
the tool.

Marc


------------------------------

Date: Fri, 25 Jun 2010 13:45:37 +0000 (UTC)
From: bks@panix.com (Bradley K. Sherman)
Subject: Re: Perl in the workplace
Message-Id: <i02bu1$8as$1@reader1.panix.com>

In article <5adbca05-bb76-425b-ac61-847fb970fdb6@a30g2000yqn.googlegroups.com>,
ccc31807  <cartercc@gmail.com> wrote:
>
>That got me to wondering. How much of Perl usage is bottom up, rather
>than top down? The large businesses in my area pick a technology
>(.NET, Java, C++, Struts, Rails, etc.) and require everyone to use
>that technology. The people locally that I know who use Perl use it
>for individual projects, without official approval or even knowledge.
>
>Is this typical?
> ...

Yes, Perl is much better at getting work done than in satisfying
the needs of people in blue-sky meetings.

    --bks



------------------------------

Date: Fri, 25 Jun 2010 13:54:46 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: Perl in the workplace
Message-Id: <k6d926hms09018h8i1akvdhk4vkoma5tvb@4ax.com>

On Fri, 25 Jun 2010 06:38:11 -0700 (PDT), Marc Girod
<marc.girod@gmail.com> wrote:

>The management who is in charge of the expenses has no competence/
>interest in technology anyway. They get interested in the budget:
>picking expensive tools, they grow their budget, and thus their own
>power inside the company.

It's a Dilbert world.



-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 


------------------------------

Date: Fri, 25 Jun 2010 09:01:38 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Perl in the workplace
Message-Id: <slrni29dd6.laa.tadmc@tadbox.sbcglobal.net>

ccc31807 <cartercc@gmail.com> wrote:

> How much of Perl usage is bottom up, rather
> than top down? 


Most of it.


> The large businesses in my area pick a technology
> (.NET, Java, C++, Struts, Rails, etc.) and require everyone to use
> that technology. The people locally that I know who use Perl use it
> for individual projects, without official approval or even knowledge.
>
> Is this typical? 


Yes.


> Or do some significant number of companies make a
> deliberate decision to use Perl and impose it in a top down fashion?


That happens too, but it is rare. 

I expect that even those are the result of someone using Perl as
you describe above (and then getting promoted to a policy-making
position).

Those are the companies I try to find when I need a contract :-)


-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.


------------------------------

Date: Fri, 25 Jun 2010 16:35:45 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: Perl in the workplace
Message-Id: <874ogrqiwu.fsf@vps1.hacking.dk>

ccc31807 <cartercc@gmail.com> writes:

> That got me to wondering. How much of Perl usage is bottom up, rather
> than top down? The large businesses in my area pick a technology
> (.NET, Java, C++, Struts, Rails, etc.) and require everyone to use
> that technology. The people locally that I know who use Perl use it
> for individual projects, without official approval or even knowledge.

I have an idea that most Perl programmers says

  - Chose the right tool for the job, which happens to be Perl.

Where some other language advocates says

  - Chose Java, which happens to be the right tool for the job.

For a given project the difference isn't clear. Both the Perl
programmer and the Java programmer will chose his previously prefered
language. But in the long term I think that the difference is that
advocates of these other languages is more likeliy to push for their
language to become company wide standard.

But then again - all generalizations suck.

//Makholm


------------------------------

Date: Fri, 25 Jun 2010 19:05:05 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: problem sending email using MIME::Lite from gmail's stmp server
Message-Id: <slrni29oe3.72p.hjp-usenet2@hrunkner.hjp.at>

On 2010-06-21 15:42, Ted Byers <r.ted.byers@gmail.com> wrote:
> I have tried everything suggested in this thread.  Always the result
> was the same, even after using cid as directed.  I do not understand
> why.
>
> However, I do have progress.
>
> In my quest for additional information, I found
> Email::MIME::CreateHTML.  It does make things much simpler.  With it,
> I need only two statements to make the message:
>
> my %objects = (
>                 "logo.jpg" => "template.files/image002.jpg"
>         );
>
> $message = Email::MIME->create_html(
>                 header => [
>                         From => $from_user,
>                         To => $to_user,
>                         Subject => "testing Connie's email",
>                 ],
>                 body => $html_template,
>                 embed => 0, #<--
>                 inline_css => 0,     #<--
>                 objects => \%objects #<--
>         );
>
> The improvement this produces is twofold.  First, the html body is
> invariably properly displayed.  Second, ythe linked in image is
> displayed in the right place.  However, also invariably, only half of
> the logo.jpg is displayed; this despite there being enough space being
> available in the browser to display it all.

Your script works for me. I get an email which I can display in
thunderbird. A image which is only partially displayed looks like an
encoding problem to me. Are you running on Windows? If so, it is
possible that Email::MIME::CreateHTML doesn't open the image properly in
binary mode (on Unixes there is no difference, so such a bug might go
undetected).

	hp



------------------------------

Date: Fri, 25 Jun 2010 10:33:17 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Proposing a new module: Parallel::Loops
Message-Id: <876317gm9u.fsf@lifelogs.com>

On Fri, 25 Jun 2010 01:14:11 -0700 (PDT) Peter Valdemar Mørch <4ux6as402@sneakemail.com> wrote: 

PVM> On Jun 25, 3:16 am, Ben Morrow <b...@morrow.me.uk> wrote:
>> OK; how is this different from forks and forks::shared?

PVM> It is _much_ more similar to forks and forks::shared than to Coro.

PVM> While the forks and forks::shared API emulate the API of threads and
PVM> threads::shared (perfectly?), Parallel::Loops tries to emulate the
PVM> standard foreach and while loops as close as possible as in:

PVM> $pl->foreach(\@input, sub {
PVM>    $output{$_} = do_some_hefty_calculation($_);
PVM> });

I like that syntax better personally than join() and detach().

PVM> I guess Parallel::Loops could have been written with forks and
PVM> forks::shared, and only provided syntactic sugar. (In fact it uses
PVM> Parallel::ForkManager and Tie::Hash/Tie::Array instead.)

`forks' brings in socket IPC which can be an issue.  Your approach seems
a little cleaner IIUC.

Ted


------------------------------

Date: Fri, 25 Jun 2010 23:34:14 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Proposing a new module: Parallel::Loops
Message-Id: <6gnff7-01c1.ln1@osiris.mauzo.dyndns.org>


Quoth Ted Zlatanov <tzz@lifelogs.com>:
> On Fri, 25 Jun 2010 01:14:11 -0700 (PDT) Peter Valdemar Mørch
> <4ux6as402@sneakemail.com> wrote: 
> 
> PVM> On Jun 25, 3:16 am, Ben Morrow <b...@morrow.me.uk> wrote:
> >> OK; how is this different from forks and forks::shared?
> 
> PVM> It is _much_ more similar to forks and forks::shared than to Coro.
> 
> PVM> While the forks and forks::shared API emulate the API of threads and
> PVM> threads::shared (perfectly?), Parallel::Loops tries to emulate the
> PVM> standard foreach and while loops as close as possible as in:
> 
> PVM> $pl->foreach(\@input, sub {
> PVM>    $output{$_} = do_some_hefty_calculation($_);
> PVM> });
> 
> I like that syntax better personally than join() and detach().

Personally I find

    my %output :shared;

    for my $i (@input) {
        async {
            $output{$i} = do_some_hefty_calculation($i);
        }
    }

somewhat clearer, but that's just a matter of taste. (With 5.10
presumably a 'my $_' would make $_ work too.)
            
> PVM> I guess Parallel::Loops could have been written with forks and
> PVM> forks::shared, and only provided syntactic sugar. (In fact it uses
> PVM> Parallel::ForkManager and Tie::Hash/Tie::Array instead.)
> 
> `forks' brings in socket IPC which can be an issue.  Your approach seems
> a little cleaner IIUC.

THe IPC has to be done *somehow*. Sockets are probably as reliable as
any other mechanism.

Ben



------------------------------

Date: Fri, 25 Jun 2010 13:50:53 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: UNIX datagram sockets
Message-Id: <86ocezuy8y.fsf@gareth.avalon.lan>

"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:

> On 2010-06-23 04:39, John Kelly <jak@isp2dial.com> wrote:
>>
>> Stein has an example of UNIX datagram sockets in his Networking book,
>> but it includes other ideas that, to me, made it hard to see the forest
>> for the trees.  So I distilled it down to the bare essential elements
>> related to socket setup.
>
> I thought there should be lots of examples floating around on the web,
> but they seem hard to find (maybe my Google-Fu is weak, or maybe nobody
> uses Unix datagram sockets (I know I don't)). So I think your example is
> useful.

Try looking for 'Unix Domain Sockets'. The first hit of that + 'Perl'
gives an excerpt from the Perl Cookbook.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.


------------------------------

Date: Fri, 25 Jun 2010 13:50:55 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: UNIX datagram sockets
Message-Id: <kac926hqb9a4vlcb5272teqr3of4l5d1vj@4ax.com>

On Fri, 25 Jun 2010 13:50:53 +0200, Mart van de Wege <mvdwege@mail.com>
wrote:

>"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>
>> On 2010-06-23 04:39, John Kelly <jak@isp2dial.com> wrote:
>>>
>>> Stein has an example of UNIX datagram sockets in his Networking book,
>>> but it includes other ideas that, to me, made it hard to see the forest
>>> for the trees.  So I distilled it down to the bare essential elements
>>> related to socket setup.
>>
>> I thought there should be lots of examples floating around on the web,
>> but they seem hard to find (maybe my Google-Fu is weak, or maybe nobody
>> uses Unix datagram sockets (I know I don't)). So I think your example is
>> useful.
>
>Try looking for 'Unix Domain Sockets'. The first hit of that + 'Perl'
>gives an excerpt from the Perl Cookbook.

Too bad that example won't work.  Can you google any that do?


-- 
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
 


------------------------------

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 3004
***************************************


home help back first fref pref prev next nref lref last post