[23623] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 5830 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 19 18:05:45 2003

Date: Wed, 19 Nov 2003 15:05:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Wed, 19 Nov 2003     Volume: 10 Number: 5830

Today's topics:
    Re: [OT] Re: Creating UNICODE filenames with PERL 5.8 (Malcolm Dew-Jones)
    Re: [OT] Re: Creating UNICODE filenames with PERL 5.8 (Malcolm Dew-Jones)
    Re: [OT] Re: Creating UNICODE filenames with PERL 5.8 (Malcolm Dew-Jones)
    Re: Calling a sql script from perl (JR)
    Re: Calling a sql script from perl (Malcolm Dew-Jones)
    Re: comments on JAPH? <bik.mido@tiscalinet.it>
    Re: Creating UNICODE filenames with PERL 5.8 <usenet@morrow.me.uk>
    Re: Creating UNICODE filenames with PERL 5.8 (Malcolm Dew-Jones)
        DES has no destroy.al <ggershSNACK@CAKEctc.net>
    Re: Error trapping $RS_ADO->Open($SQL_ADO, $Conn_ADO, 1 <nospam@nospam.com>
    Re: Image::Magick memory leak question <usenet@morrow.me.uk>
    Re: Image::Magick memory leak question <stanb@panix.com>
    Re: Image::Magick memory leak question <mgjv@tradingpost.com.au>
        Mail Spool Truncation <mhunter@uclink.berkeley.edu>
    Re: Matching two arrays, and returning the "rest" (Chris Charley)
    Re: Matching two arrays, and returning the "rest" (JR)
    Re: MIME::Lite - From email address to name of the comp (David Efflandt)
    Re: MIME::Lite - From email address to name of the comp <jtoth@acm.org>
    Re: MIME::Lite - From email address to name of the comp <jtoth@acm.org>
    Re: MIME::Lite - From email address to name of the comp <noreply@gunnar.cc>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: 19 Nov 2003 11:51:37 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: [OT] Re: Creating UNICODE filenames with PERL 5.8
Message-Id: <3fbbc9c9@news.victoria.tc.ca>

Ben Liddicott (ben.liddicott@comodogroup.com) wrote:
: Some history required...


: "Ben Morrow" <usenet@morrow.me.uk> wrote in message
: news:bpel00$sl6$1@wisteria.csv.warwick.ac.uk...
: > yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones) wrote:
: > > Ben Morrow (usenet@morrow.me.uk) wrote:
: > > : OK, your problem here is that Win2k is being stupid about Unicode: any
: > > : sensible OS that understood UTF8 would be fine :).
: > >
: > > Hum, NT has been handling unicode for at least ten years (3.5, 1993) by
: > > the simple expedient of using 16 bit characters.  It is hardware that is
: > > stupid, by continuing to use ancient tiny 8 bit elementary units.
: >
: > OK, I invited that with gratuitous OS-bashing :)... nevertheless:
: >
: > 1. Unicode is *NOT* a 16-bit character set. UTF16 is an evil bodge to
: >    work around those who started assuming it was before the standards
: >    were properly in place.

: Unicode 1.0 WAS a 16-bit character set. So there. UTF16 is a representation
: of Unicode 3.0 which is selected to be backwards compatible with Unicode
: 1.0.

: The reason why NT doesn't use UTF-8 is that --- wait for it --- it wasn't
: invented back then. UTF-8 was specified in 1993, and adopted as an ISO
: standard in 1994. Windows NT shipped in 1993, after 5 years in development.
: Guess what: Decision on character set had to be made in the eighties.

: Yes, they got it wrong. They should have selected UTF-8. They should have
: INVENTED UTF-8.

Well no.  The original philosophy of unicode was to simply increase
character size.  If "alternative" hardware such as alpha, powerpc, etc,
(which were already incompatible with old hardware in many ways)  had been
designed to use 16 bits of data as the smallest addressable unit of data
then the NT decision would have been an extremely good one.



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

Date: 19 Nov 2003 12:05:21 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: [OT] Re: Creating UNICODE filenames with PERL 5.8
Message-Id: <3fbbcd01@news.victoria.tc.ca>

Ben Morrow (usenet@morrow.me.uk) wrote:
: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones) wrote:
: > Ben Morrow (usenet@morrow.me.uk) wrote:
: > : OK, your problem here is that Win2k is being stupid about Unicode: any
: > : sensible OS that understood UTF8 would be fine :).
: > 
: > Hum, NT has been handling unicode for at least ten years (3.5, 1993) by
: > the simple expedient of using 16 bit characters.  It is hardware that is
: > stupid, by continuing to use ancient tiny 8 bit elementary units.

: OK, I invited that with gratuitous OS-bashing :)... nevertheless:

: 2. Given that the world does, in fact, use 8-bit bytes, any 16-bit
:    encoding has this small problem of endianness... again, solved
:    (IMHO) less-than-elegantly by the Unicode Consortium.

Endianness is a hardware problem.  16 bit character hardware would not
have this problem.  For other hardware, this is identical to the problem
encountered when transmitting numeric values over mediums such as the
internet, and is solved just as easily, (and as it has been) by specifying
the order in which the hi and lo parts are transmitted.

: 3. Given that the most widespread character set is likely to be either
:    ASCII or Chinese ideograms, and ideograms won't fit into less than
:    16 bits anyway, it seems pretty silly to encode a 7-bit charset
:    with 16 bits per character.

Hum, did you notice the contradiction in what you say "character set" and 
"ideograms".

You might also say it seams silly to encode a 7-bit charset in 8 bits.  I
think it's silly to worry about a few bits of storage when the simplicity
of software involved in handling larger characters would be greatly
enhanced by simply updating the size of characters.  Simply look at the
number of years and bugs it has taken to introduce unicode handling to
many applications, and compare that to the time it took for the NT team
originally to update notepad - it consisted basically of recompiling it
with characters defined to be a larger size.


: 4. It also seems pretty silly to break everything in the world that
:    relies on a byte of 0 meaning end-of-string, not to mention '/'
:    being '/' (or '\', or whatever, as appropriate).

huh? if you used 16 bit characters then the (16 bit) character with
numeric value of 0 is still the null byte.



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

Date: 19 Nov 2003 12:09:23 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: [OT] Re: Creating UNICODE filenames with PERL 5.8
Message-Id: <3fbbcdf3@news.victoria.tc.ca>

Ben Morrow (usenet@morrow.me.uk) wrote:


: > So you can knock them for not having the foresignt to know that 65535
: > characters wouldn't be enough.

: I can also knock them for not having changed in the ten years since
: NT3.5 was released. It is not *that* difficult a change to implement,
: as Perl 5.8 has demonstrated; even though it has some nasty bits,
: ditto.

If any alternative hardware had used 16 bit characters then perl 4 would
have had built in 65535 characters support on those platforms, with
virtually no changes, as would every other application handling character
data.



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

Date: 19 Nov 2003 12:53:03 -0800
From: jrolandumuc@yahoo.com (JR)
Subject: Re: Calling a sql script from perl
Message-Id: <b386d54b.0311191253.3a944f4d@posting.google.com>

dn_perl@hotmail.com (dn_perl@hotmail.com) wrote in message news:<97314b5b.0311161809.658244a5@posting.google.com>...
> I am calling a shell script from a perl script and the shell script
> invokes an sql script. I would like to invoke the sql script direct
> from perl.
> How can I do it?
> 
> 
> Perl script :
> -----------------------
> system("call_shell_script 'input_file' ");
> -----------------------
> 
> 
> Contents of shell script 'call_shell_script' :
> 
> ------------
> #!/bin/ksh 
> LOGSQL=rep.log 
> sqlplus -s << EOH 2>gen_rep.errlog 
> userid/passwd 
> spool ${LOGSQL} 
> @call_sql_script.sql 
> spool off 
> EOH 
> ------------
> 
> 
> Can I simply combine the two steps above with these lines in perl
> script :
> (I don't have access to perl environment today, so can't try this
> out.)
> 
> ------------
> system("sqlplus  -s << EOH 2>gen_rep.errlog");
> userid/passwd 
> spool ${LOGSQL} 
> @call_sql_script.sql 
> spool off 
> EOH 
> ------------------
> 
> 
> Thanks In Advance.

I have run into the problem you describe several times, and think I
may have a solution for you (at least within the UNIX environment, and
connecting to the an Oracle database).

The problem is that the SQL*PLUS environment needs to be set before
you can call SQL*PLUS from within a perl program (doing a system
callout doesn't work alone, because SQL*PLUS doesn't inherently know
it's own environment, or at least that's what my DBA tells me).

As an aside, I use a class that stores this info. in one of my
directories, and by using that class, I only need one line to actually
call SQL*PLUS within my perl scripts (my actual SQL*PLUS statement),
using OO notation (if you want a copy of the class, I'll mail it to
you; it's very simple and also something you could easily write on
your own, with just a basic understanding of OO programming in
Perl-I'm certainly no expert).  Errors and valid data sets are
returned in an array as they would otherwise appear within SQL*PLUS. 
If you can't install DBI (where I work, DBI is installed on some of
our UNIX machines, but not others, and I'm not allowed to install it
where it doesn't exist.  What a pain), I suggest doing something like
rolling your own class and using the internals of the class to handle
your connections.  This will make easier the process of handling
Oracle version changes (you'll only have to change one line in one
class, as opposed to changing myriad lines in many scripts).

Anyway, the below code should get you started (all you need to do is
just change the connect, settings, query and maybe the environment). 
Good luck.

#!/perl -w
use strict;
use diagnostics;

my $rec;
$rec->{ENVIRONMENT} = '9.2.0';
@{$rec->{PATH}}     = `set path=\$PATH`;

$rec->{CONNECT}     = 'jroland/jroland@devlp';
@{$rec->{SETTINGS}} = 'set wrap off pagesize 0';
@{$rec->{QUERY}}    = 'select table_name from user_tables;';

my $script = "SQL_OUTFILE" . time . ".SQL";
my $sfile = "$script" . "_OUTFILE";

open OUTFILE, ">$script" or die "Cannot open $script: $!";
print OUTFILE join "\n", @{$rec->{SETTINGS}}, "spool $sfile", 
                         @{$rec->{QUERY}}, "spool off", "exit;";
close OUTFILE or die "Cannot close $script: $!";

`@{$rec->{PATH}} sqlplus $rec->{CONNECT} \@$script`;

open CLASS_SPOOLFILE, "$sfile" or die "Cannot open $sfile: $!";
while(<CLASS_SPOOLFILE>) {
   chomp; 
   push @{$rec->{QUERY_RETURNS}}, $_;
}
close CLASS_SPOOLFILE or die "Cannot close $sfile: $!";

`rm $script $sfile`;

print "$_\n" for (@{$rec->{QUERY_RETURNS}});


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

Date: 19 Nov 2003 13:53:26 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: Calling a sql script from perl
Message-Id: <3fbbe656@news.victoria.tc.ca>

dn_perl@hotmail.com (dn_perl@hotmail.com) wrote:
: I am calling a shell script from a perl script and the shell script
: invokes an sql script. I would like to invoke the sql script direct
: from perl.
: How can I do it?

Untested, but based by memory on working code

my $username='orauser';
my $password='orapass';

system( qq{
 . oracle_setup_shell_script
sqlplus <<EOS
$username/$password
\@oracle_script.sql
exit
EOS
}); # end qq, end system


OR similarly

system( qq{
 . oracle_setup_shell_script
sqlplus <<EOS
$username/$password
select * from your_table;
exit
EOS
}); # end qq, end system


The above is fine if you simply want to display some data, or invoke a 
procedure, etc.

If you need perl to interact with the data then use DBI.


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

Date: Wed, 19 Nov 2003 23:10:40 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: comments on JAPH?
Message-Id: <4qknrv0pt75p36gjp055gj49m6a0f76mca@4ax.com>

On Tue, 18 Nov 2003 20:56:00 +0100, Thomas Kratz
<ThomasKratz@REMOVEwebCAPS.de> wrote:

>> (i) it doesn't work, for the following meaning of "doesn't work": it
>> prints "J" and then exits!
>
>That's because you are on Win* are you? It will work when you
>change the 14 in the first line to 15.

Let's say that I'm both on Win* and on Linux, perl 5.8.0 on both...

>> and that there's an __END__ token. Isn't it that you're maybe trying
>> to do something like '*ARGV=DATA'?
>
>More like '*STDIN=DATA'. It is just to be able to say getc instead of 
>getc(DATA).
>
>Using ARGV would be an alternative (and the above problem would vanish).
>I just found out that you can't paste the lines via STDIN (always tested 
>with a file :-( ). The DATA filehandle seems to be missing. I have to look 
>that up.

Huh?!?


Michele
-- 
# This prints: Just another Perl hacker,
seek DATA,15,0 and  print   q... <DATA>;
__END__


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

Date: Wed, 19 Nov 2003 19:36:00 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Creating UNICODE filenames with PERL 5.8
Message-Id: <bpggn0$hlp$1@wisteria.csv.warwick.ac.uk>

yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones) wrote:
> Alan J. Flavell (flavell@ph.gla.ac.uk) wrote:
> : On Wed, 18 Nov 2003, Malcolm Dew-Jones wrote:
> 
> : > Hum, NT has been handling unicode for at least ten years (3.5, 1993) by
> : > the simple expedient of using 16 bit characters.
> 
> : ...which unfortunately turns out to be somewhat of a mistake, seeing
> : that Unicode went and broke the 16-bit boundary.
> 
> Which was also a mistake.  "character" now includes all the heiroglyphics
> of places like china, (but why not all the heiroglyphics of, say, ancient
> egypt?

Proposed.

>  why not all the standardized international road symbols?

I see no reason why these should not also be added.

> ).  When
> the arabians invented the modern idea of characters then it became widely
> recognized as much more powerful, fundamentally better, and fundamentally
> "different" than the old single-picture-means-a-word method of writing.  
> Now we have jumped backwards 1800 years. 

I think this is a little arrogant, to say the least. Chinese ideograms
(which are not the same as hieroglyphs) have served the need of the
Chinese admirably: two people from opposite ends of the country,
speaking mutually un-intelligible languages, can nevertheless
communicate perfectly through the existence of a common form of
writing.

Apart from that, one of the basic reasons for inventing 'other' character
encodings was so that one could write his own name without resorting
to markup. There are an awful lot of people whose names require
Chinese ideograms to spell...

Note that I do not disagree with you that many of the choices about
what is 'in' and what 'out' of Unicode seem more than a little
arbitrary... :)

> Things like chinese writing
> should not be treated using standardized application level encodings, just
> as we now standarize many markup languages for encoding other higher level
> data. ($0.02)

I'm afraid I don't follow what you mean here.

> : And then there's legacy data to think about.
> 
> stored on legacy systems, and manipulated using legacy software and 
> hardware.  
> 
> This is murhpy's law.  Because the old systems have been successful, new
> systems can't be made better.

They can, and are being. Intelligence just needs to be applied at
every stage. A case in point: utf8 both keeps legacy compatibility
*and* is more extensible than ucs2.

> : Interestingly, those early codes regularly had shift-in and shift-out
> : codes to extend their repertoire.  A practice which faded out for a
> : while, 
> 
> yes, as soon as hardware costs made larger characters possible, they got 
> rid of the gludginess.

Agreed, shifting is nasty and has serious problems, such as getting
out of sync. UTF16 surrogates, though, are pure eeevilll.....

Ben

-- 
               EAT
               KIDS                                          (...er, whoops...)
               FOR                                             ben@morrow.me.uk
               99p


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

Date: 19 Nov 2003 11:41:07 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: Creating UNICODE filenames with PERL 5.8
Message-Id: <3fbbc753@news.victoria.tc.ca>

Malcolm Dew-Jones (yf110@vtn1.victoria.tc.ca) wrote:

: Now we have jumped backwards 1800 years.  Things like chinese writing
: should not be treated using standardized application level encodings, just
         ^^^
: as we now standarize many markup languages for encoding other higher level
: data. ($0.02)

when he meant to say

: should be treated using standardized application level encodings, just
        ^
: as we now standarize many markup languages for encoding other higher level
: data. ($0.02)




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

Date: Wed, 19 Nov 2003 16:08:21 -0500
From: Greg G <ggershSNACK@CAKEctc.net>
Subject: DES has no destroy.al
Message-Id: <vMadnbacCeFyRiaiRVn-tw@ctc.net>


I've got some perl code that's using Crypt::CBC in which I'm generating 
a DES key like so:
my $cipher = Crypt::CBC->new( {'key'             => '12345678',
                             'cipher'          => 'DES',
			    'iv'              => '87654321',
			    'regenerate_key'  => 0,   # default true
			    'padding'         => 'space',
			    'prepend_iv'      => 0
	 		    });

Well, at some point, the process falls down.  I'm not sure exactly where 
in the perl code this is happening, but truss tells me this:

stat("/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Crypt/DES/DESTROY.al", 
0x000C1434) Err#2 ENOENT
open("/usr/local/lib/perl5/5.00503/sun4-solaris/auto/Crypt/DES/DESTROY.al", 
  O_RDONLY) Err#2 ENOENT
open("/usr/local/lib/perl5/5.00503/auto/Crypt/DES/DESTROY.al", O_RDONLY) 
Err#2 ENOENT
open("/usr/local/lib/perl5/site_perl/5.005/sun4-solaris/auto/Crypt/DES/DESTROY.al", 
O_RDONLY) Err#2 ENOENT
open("/usr/local/lib/perl5/site_perl/5.005/auto/Crypt/DES/DESTROY.al", 
O_RDONLY) Err#2 ENOENT
open("./auto/Crypt/DES/DESTROY.al", O_RDONLY)   Err#2 ENOENT

As far as I can tell DES doesn't *have* a DESTROY.al.  What does this 
mean, and how can I fix it?  (Yes, it's an old version of perl, I 
realize that.  I'd prefer not to upgrade it at this point if I don't 
have to.)

Thanks.

-Greg G



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

Date: Wed, 19 Nov 2003 12:55:45 -0800
From: "Geek" <nospam@nospam.com>
Subject: Re: Error trapping $RS_ADO->Open($SQL_ADO, $Conn_ADO, 1, 1)
Message-Id: <3fbb685f$1@cpns1.saic.com>

Thank you very much! :)


"Ben Liddicott" <ben.liddicott@comodogroup.com> wrote in message
news:bpfq78$hjb$1@kylie.comodogroup.com...
> My mistake: If you want your objects to croak on error, you have to say:
>
>     Win32::OLE->Option(Warn=>3);
>
> Otherwise you can check FAILED(Win32::OLE::LastError()), where:
>
>     sub FAILED($){$_[0] & 0x80000000;}
>     sub SUCCEEDED($){not ($_[0] & 0x80000000);}
>     $Conn_ADO->Open($DSN_ADO);  #<-- *** This one ***
>     SUCCEEDED(Win32::OLE::LastError()) or croak(Win32::OLE::LastError());
>
>
> Values of LastError without the top bit set are success codes, which you
> won't see often.
>
> There are other options too. perldoc Win32::OLE for more.
>
> Cheers,
> Ben Liddicott
>
>
> "Ben Liddicott" <ben.liddicott@comodogroup.com> wrote in message
> news:bpfor3$fph$1@kylie.comodogroup.com...
> > eval{
> >     $Conn_ADO->Open($DSN_ADO);  #<-- *** This one ***
> > }
> > if($@){
> >     # Failed to open.
> > }
> >
> > Or even better:
> >
> > use Error;
> >
> > try{
> >     # do something that might die or croak.
> >     $Conn_ADO->Open($DSN_ADO);  #<-- *** This one ***
> >
> > }otherwise{
> >     # died or croaked. Do something about it.
> >
> > };# don't forget the semicolon
>
>




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

Date: Wed, 19 Nov 2003 19:08:55 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Image::Magick memory leak question
Message-Id: <bpgf47$fei$2@wisteria.csv.warwick.ac.uk>


Stan Brown <stanb@panix.com> wrote:
> OK, I've got this memory leak down to a 3 line example:
> 
> 
> my $image = Image::Magick->new(magick=>'GIF',font=>'clean');
>     $image->Read($l_tmpfile);
>     undef $image;
>     
> In a loop leaks memory. 
> 
> Can anyone tell me if I'm doing somethign wrong here?

Not by my reading of the Image::Magick docs. I never have liked
imagemagick: the couple of looks I took at the source a while ago did
*not* inspire me with confidence. I could find no record at all, for
most of the API, of who was responsible for freeing the various bits
of memory.

When I'm doing something like this I usually use system() and the
NetPBM utilities; you may prefer GD or Image::Imlib2.

Alternatively, if you can find a convenient place in your loop to
re-exec() yourself, that will cut the leaks short.

Ben

-- 
perl -e'print map {/.(.)/s} sort unpack "a2"x26, pack "N"x13,
qw/1632265075 1651865445 1685354798 1696626283 1752131169 1769237618
1801808488 1830841936 1886550130 1914728293 1936225377 1969451372
2047502190/'                                                 # ben@morrow.me.uk


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

Date: Wed, 19 Nov 2003 19:57:31 +0000 (UTC)
From: Stan Brown <stanb@panix.com>
Subject: Re: Image::Magick memory leak question
Message-Id: <bpghvb$sac$1@reader2.panix.com>

In <bpgf47$fei$2@wisteria.csv.warwick.ac.uk> Ben Morrow <usenet@morrow.me.uk> writes:


>Stan Brown <stanb@panix.com> wrote:
>> OK, I've got this memory leak down to a 3 line example:
>> 
>> 
>> my $image = Image::Magick->new(magick=>'GIF',font=>'clean');
>>     $image->Read($l_tmpfile);
>>     undef $image;
>>     
>> In a loop leaks memory. 
>> 
>> Can anyone tell me if I'm doing somethign wrong here?

>Not by my reading of the Image::Magick docs. I never have liked
>imagemagick: the couple of looks I took at the source a while ago did
>*not* inspire me with confidence. I could find no record at all, for
>most of the API, of who was responsible for freeing the various bits
>of memory.

>When I'm doing something like this I usually use system() and the
>NetPBM utilities; you may prefer GD or Image::Imlib2.

>Alternatively, if you can find a convenient place in your loop to
>re-exec() yourself, that will cut the leaks short.

Thanks, you have been a big help on this!

I'm a bit hesitant to uses systen() as in the long term, I would like to be
able to capture images at a failry high rate of speed.

In addition, I spent about 10 minutes trying to figure out how to do the
equivelant commnad from the comand line using the Imagemagick tools, and
never did get it to work, so building the system() call for that would eb
problematic.

But, as you have pointed out, I do have other tools to choose from. I think
thta I will satrt examining them.

BTW, adding  @$image = ();, right before the undef $image; call seems to
have drasticly lowered the ammount of memory that it's leaking.

Does that make any sens at all? I would hhave thoughtthat the undef would
have deleted all parts of the $image object. Am I wrong?

-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
						-- Benjamin Franklin


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

Date: 19 Nov 2003 21:51:37 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: Image::Magick memory leak question
Message-Id: <slrnbrnpfa.q43.mgjv@verbruggen.comdyn.com.au>

On Wed, 19 Nov 2003 17:46:32 +0000 (UTC),
	Stan Brown <stanb@panix.com> wrote:
> OK, I've got this memory leak down to a 3 line example:
> 
> 
> my $image = Image::Magick->new(magick=>'GIF',font=>'clean');
>     $image->Read($l_tmpfile);
>     undef $image;

You should check the success or failure of these calls, and if this is
in the body of a loop, that undef is unnecessary. However, neither
would fix any memory leaks.

> In a loop leaks memory. 
> 
> Can anyone tell me if I'm doing somethign wrong here?

What's your version of Image::Magick? Are you using the latest? If
you are, then please report this to the Image::Magick maintainers as
an issue, and include output of perl -V and your OS version
information.

I've seen memory leaks in certain older versions of Image::Magick, but
they generally get fixed.

Martien
-- 
                        | 
Martien Verbruggen      | 
Trading Post Australia  | values of Beta will give rise to dom!
                        | 


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

Date: Wed, 19 Nov 2003 22:46:19 +0000 (UTC)
From: Mike Hunter <mhunter@uclink.berkeley.edu>
Subject: Mail Spool Truncation
Message-Id: <slrnbrnsi4.1ve.mhunter@celeste.net.berkeley.edu>

Hey everybody,

I'm looking to write a script that truncates a certain mailbox to a reasonable
size, in case I get a flood of messages to it.  Before I go and write a script
to do this, is there a cpan package I'm missing?  Mail::Spool doesn't seem to
do it.

Thanks,

Mike


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

Date: 19 Nov 2003 12:06:50 -0800
From: charley@pulsenet.com (Chris Charley)
Subject: Re: Matching two arrays, and returning the "rest"
Message-Id: <4f7ed6d.0311191206.75a396a2@posting.google.com>

petersson@my-deja.com (petersson) wrote in message news:<b35c5297.0311190733.133d75d6@posting.google.com>...
> Hi,
> 
> I have two arrays. The first one contains a list of items. For
> example:
> 
> abc
> bca
> bac
> cab
> acb
> 
> My second one contains fewer items, but parts of the individual items
> match with the items in my first array.
> 
> 12_bca
> 21_acb
> 22_cab
> 
> Hence that the "bca" in "12_bca" above matches with the single "bca"
> in my first array, like this:
> 
> abc
> bca : 12_bca
> bac
> cab : 22_cab
> acb : 21_acb
> 
> Now I want a function that returns the items from my first array that
> doesn't partially match any of the items in my second array. Like
> this:
> 
> abc
> bac
> 
> Note: the example above is extremely simplified.
Hi
The following will do it   :-)

#!/usr/bin/perl
use strict;
use warnings;

my @a1 = qw /abc bca bac cab acb/;
my @a2 = qw /12_bca 21_acb 22_cab/;

my @unseen;
for my $first (@a1) {
	my $idx;
	for my $second (@a2) {
		$idx = index($second, $first);
		last unless $idx == -1;
	}
	push @unseen, $first if $idx == -1;
}
print "@unseen\n";

Chris


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

Date: 19 Nov 2003 14:51:17 -0800
From: jrolandumuc@yahoo.com (JR)
Subject: Re: Matching two arrays, and returning the "rest"
Message-Id: <b386d54b.0311191451.72076a06@posting.google.com>

petersson@my-deja.com (petersson) wrote in message news:<b35c5297.0311190733.133d75d6@posting.google.com>...
> Hi,
> 
> I have two arrays. The first one contains a list of items. For
> example:
> 
> abc
> bca
> bac
> cab
> acb
> 
> My second one contains fewer items, but parts of the individual items
> match with the items in my first array.
> 
> 12_bca
> 21_acb
> 22_cab
> 
> Hence that the "bca" in "12_bca" above matches with the single "bca"
> in my first array, like this:
> 
> abc
> bca : 12_bca
> bac
> cab : 22_cab
> acb : 21_acb
> 
> Now I want a function that returns the items from my first array that
> doesn't partially match any of the items in my second array. Like
> this:
> 
> abc
> bac
> 
> Note: the example above is extremely simplified. Splitting the second
> array on the "_" sign won't work... Anyone done this before? Knows of
> a simple solution?
> 
> Thanks in advance
> 
> /s

This seems to do what you want, if I correctly understand your goal.

#!/perl -w
use strict;
use diagnostics;

my @a=( 'abc',    'bca',    'bac', 'cab', 'acb' );
my @b=( '12_bca', '21_acb', '22_cab');

## tested twice...
for my $x (@a) { print qq|"$x" not in \@b.\n| if(!grep /$x/, @b) }


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

Date: Wed, 19 Nov 2003 19:27:28 +0000 (UTC)
From: efflandt@xnet.com (David Efflandt)
Subject: Re: MIME::Lite - From email address to name of the company..
Message-Id: <slrnbrnh10.mke.efflandt@typhoon.xnet.com>

On Wed, 19 Nov 2003, Ben Morrow <usenet@morrow.me.uk> wrote:
> [don't top-post]
> 
> "John B. Kim" <provicon@earthlink.net> wrote:
>> "Tintin" <me@privacy.net> wrote in message
>> >
>> > Hint, look at the format of your email, ie: "John B. Kim"
>> > <provicon@earthlink.net>
>>
>> I tried,
>> 
>>     'JinuAcademy <askjinu@yahoo.com>';
>> 
>> But I get the following error message:
>>     @ or "." expected after "JinuAcademy"
> 
> Try again. Compare
> 
> JinuAcademy <askjinu@yahoo.com>
> 
> with
> 
> "John B. Kim" <provicon@earthlink.net>
> 
> . Spot the difference?

Actually 'JinuAcademy <askjinu@yahoo.com>' (if that is what it actually 
is) should work with a compliant program or mailer, if the plain name is 
nothing but alpha-numeric characters or whitespace.  In the latter case 
quotes are required for '"John B. Kim" <provicon@earthlink.net>' because 
of the dot in the name.

Another depreciated method is 'askjinu@yahoo.com (JinuAcademy)' or 
'provicon@earthlink.net (John B. Kim)'.

-- 
David Efflandt - All spam ignored  http://www.de-srv.com/


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

Date: Wed, 19 Nov 2003 21:01:16 +0000 (UTC)
From: Jim Toth <jtoth@acm.org>
Subject: Re: MIME::Lite - From email address to name of the company..
Message-Id: <slrnbrnmgs.bd7.jtoth@baka.acw.vcu.edu>

In article <slrnbrnh10.mke.efflandt@typhoon.xnet.com>, David Efflandt wrote:
> On Wed, 19 Nov 2003, Ben Morrow <usenet@morrow.me.uk> wrote:
>> "John B. Kim" <provicon@earthlink.net> wrote:
>>> I tried,
>>> 
>>>     'JinuAcademy <askjinu@yahoo.com>';
>>> 
>>> But I get the following error message:
>>>     @ or "." expected after "JinuAcademy"
>> 
>> Try again. Compare
>> 
>> JinuAcademy <askjinu@yahoo.com>
>> 
>> with
>> 
>> "John B. Kim" <provicon@earthlink.net>
>> 
>> . Spot the difference?
> 
> Actually 'JinuAcademy <askjinu@yahoo.com>' (if that is what it actually 
> is) should work with a compliant program or mailer, if the plain name is 
> nothing but alpha-numeric characters or whitespace.  In the latter case 
> quotes are required for '"John B. Kim" <provicon@earthlink.net>' because 
> of the dot in the name.

While what you say is true, I *think*, looking at the docs to
MIME::Lite, that MIME::Lite is insufficiently compliant:

  WARNINGS
       Good-vs-bad email addresses with send_by_smtp()

       If using send_by_smtp(), be aware that you are forcing
       MIME::Lite to extract email addresses out of a possible list
       provided in the "To:", "Cc:", and "Bcc:" fields.  This is
       tricky stuff, and as such only the following sorts of addresses
       will work reliably:

           username
           full.name@some.host.com
           "Name, Full" <full.name@some.host.com>

       This last form is discouraged because SMTP must be able to get
       at the name or name@domain portion.

       Disclaimer: MIME::Lite was never intended to be a Mail User
       Agent, so please don't expect a full implementation of RFC-822.
       Restrict yourself to the common forms of Internet addresses
       described herein, and you should be fine.  If this is not
       feasible, then consider using MIME::Lite to prepare your
       message only, and using Net::SMTP explicitly to send your
       message.

So changing it to '"JinuAcademy" <askjinu@yahoo.com>', while not
required by the RFCs, might be enough to make MIME::Lite happy; if
that's not enough to make the OP happy, Mail::SMTP ought to be used
to do the actual sending.

I probably ought to go test this to make sure, since the last form
mentioned in the man page would need to be quoted regardless.

-- 
Jim Toth
jtoth@acm.org


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

Date: Wed, 19 Nov 2003 21:19:48 +0000 (UTC)
From: Jim Toth <jtoth@acm.org>
Subject: Re: MIME::Lite - From email address to name of the company..
Message-Id: <slrnbrnnjk.bd7.jtoth@baka.acw.vcu.edu>

In article <slrnbrnmgs.bd7.jtoth@baka.acw.vcu.edu>, Jim Toth wrote:
[much snippage]
>        Disclaimer: MIME::Lite was never intended to be a Mail User
>        Agent, so please don't expect a full implementation of RFC-822.
>        Restrict yourself to the common forms of Internet addresses
>        described herein, and you should be fine.  If this is not
>        feasible, then consider using MIME::Lite to prepare your
>        message only, and using Net::SMTP explicitly to send your
>        message.
> 
> So changing it to '"JinuAcademy" <askjinu@yahoo.com>', while not
> required by the RFCs, might be enough to make MIME::Lite happy; if
> that's not enough to make the OP happy, Mail::SMTP ought to be used
> to do the actual sending.
> 
> I probably ought to go test this to make sure, since the last form
> mentioned in the man page would need to be quoted regardless.

Testing good.

Using both 

  'Jim Toth <jtoth@acm.org>'

and 

  '"Jim Toth" <jtoth@acm.org>'

were accepted just fine using send_by_smtp.  So, um, never mind.

-- 
Jim Toth
jtoth@acm.org


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

Date: Wed, 19 Nov 2003 23:09:32 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: MIME::Lite - From email address to name of the company..
Message-Id: <bpgq54$1mfhfa$1@ID-184292.news.uni-berlin.de>

Jim Toth wrote:
> In article <slrnbrnmgs.bd7.jtoth@baka.acw.vcu.edu>, Jim Toth wrote:
> [much snippage]
> 
>>       Disclaimer: MIME::Lite was never intended to be a Mail User 
>>       Agent, so please don't expect a full implementation of
>>       RFC-822. Restrict yourself to the common forms of Internet
>>       addresses described herein, and you should be fine.  If
>>       this is not feasible, then consider using MIME::Lite to
>>       prepare your message only, and using Net::SMTP explicitly
>>       to send your message.
>> 
>> So changing it to '"JinuAcademy" <askjinu@yahoo.com>', while not 
>> required by the RFCs, might be enough to make MIME::Lite happy;
>> if that's not enough to make the OP happy, Mail::SMTP ought to be
>> used to do the actual sending.
>> 
>> I probably ought to go test this to make sure, since the last
>> form mentioned in the man page would need to be quoted
>> regardless.
> 
> Testing good.
> 
> Using both
> 
>   'Jim Toth <jtoth@acm.org>'
> 
> and
> 
>   '"Jim Toth" <jtoth@acm.org>'
> 
> were accepted just fine using send_by_smtp.  So, um, never mind.

I made a couple of tests, too (version 3.01 of MIME::Lite), and my
result was not that good. I found that it accepts

     JinuAcademy <askjinu@yahoo.com>

in the "To:" field, but not:

     Jinu Academy <askjinu@yahoo.com>

i.e. to be able to include whitespace in the real name, I had to use
double-quotes:

     "Jinu Academy" <askjinu@yahoo.com>

Unlike for OP, it accepted the second form in the "From:" field, though.

I'm a little surprised, since I have noticed that MIME::Lite is 
frequently recommended in these groups. I'm using Mail::Sender myself, 
and have never encountered this kind of problem.

-- 
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl



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

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.  

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


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