[27932] in Perl-Users-Digest
Perl-Users Digest, Issue: 9296 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 14 14:05:59 2006
Date: Wed, 14 Jun 2006 11:05:05 -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 Wed, 14 Jun 2006 Volume: 10 Number: 9296
Today's topics:
Boolean expression <mdudley@king-cart.com>
Re: Boolean expression <glennj@ncf.ca>
Re: Boolean expression <noreply@gunnar.cc>
Re: Boolean expression <mritty@gmail.com>
Re: Boolean expression <tadmc@augustmail.com>
Re: Converting XML to Perl structures FAST <ignoramus7096@NOSPAM.7096.invalid>
Re: how to call a function using variable <phaylon@dunkelheit.at>
Re: IE Mechanize urls -- what about escaping? nsb_tsd@eml.cc
Re: IE Mechanize urls -- what about escaping? nsb_tsd@eml.cc
question installing DBD::mysql <"v.niekerk at hccnet.nl">
substr() hassle, *n*x vs. Win32 <peace.is.our.profession@gmx.de>
Re: substr() hassle, *n*x vs. Win32 <peace.is.our.profession@gmx.de>
Re: substr() hassle, *n*x vs. Win32 <benmorrow@tiscali.co.uk>
Re: substr() hassle, *n*x vs. Win32 xhoster@gmail.com
Re: substr() hassle, *n*x vs. Win32 xhoster@gmail.com
Re: The Nature of the "Unix Philosophy" (long) (Walter Roberson)
Re: The Nature of the "Unix Philosophy" (long) luz_a_gue@latinmail.com
Re: The Nature of the "Unix Philosophy" (long) <hawk007@flight.us>
Re: The Nature of the "Unix Philosophy" (long) <albalmer@att.net>
Re: UTF-8 subject in an email <rvtol+news@isolution.nl>
Re: UTF-8 subject in an email <ynleder@nspark.org>
Re: What is Expressiveness in a Computer Language (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Re: What is Expressiveness in a Computer Language <raffaelcavallaro@pas-d'espam-s'il-vous-plait-mac.com>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 14 Jun 2006 12:10:40 -0400
From: Marshall Dudley <mdudley@king-cart.com>
Subject: Boolean expression
Message-Id: <449034FF.A060F01A@king-cart.com>
What is wrong with this code. When it should evaluate to 1, it is
evaluation to null:
my $intlfree = 1;
my $upscountry = "AB";
&printboolean;
$intlfree = "";
&printboolean;
$upscountry = "US";
&printboolean;
sub printboolean {
my $freeok = $intlfree or ($upscountry =~ /^us/i);
print "$intlfree - $upscountry - $freeok\n";
}
perl testfree.pl
1 - AB - 1
- AB -
- US - (should be 1)
$upscountry = "US";
&printboolean;
sub printboolean {
# my $freeok = $intlfree or ($upscountry =~ /^us/i);
my $freeok = ($upscountry =~ /^us/i) or $intlfree;
print "$intlfree - $upscountry - $freeok\n";
}
perl testfree.pl
1 - AB - (should be 1)
- AB -
- US - 1
Thanks,
Marshall
------------------------------
Date: 14 Jun 2006 16:23:46 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: Boolean expression
Message-Id: <slrne90e0i.i06.glennj@smeagol.ncf.ca>
At 2006-06-14 12:10PM, Marshall Dudley <mdudley@king-cart.com> wrote:
> my $freeok = $intlfree or ($upscountry =~ /^us/i);
Precedence. Read perldoc perlop
use
my $freeok = ($intlfree or ($upscountry =~ /^us/i));
or
my $freeok = $intlfree || ($upscountry =~ /^us/i);
--
Glenn Jackman
Ulterior Designer
------------------------------
Date: Wed, 14 Jun 2006 18:30:45 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Boolean expression
Message-Id: <4farptF1hob9nU1@individual.net>
Marshall Dudley wrote:
> What is wrong with this code. When it should evaluate to 1, it is
> evaluation to null:
>
> my $intlfree = 1;
> my $upscountry = "AB";
> &printboolean;
> $intlfree = "";
> &printboolean;
> $upscountry = "US";
> &printboolean;
>
> sub printboolean {
> my $freeok = $intlfree or ($upscountry =~ /^us/i);
---------------------------------^^
Try the || operator instead. They differ with respect to precedence.
perldoc perlop
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 14 Jun 2006 09:41:18 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: Boolean expression
Message-Id: <1150303278.100536.80220@y41g2000cwy.googlegroups.com>
Marshall Dudley wrote:
> What is wrong with this code. When it should evaluate to 1, it is
> evaluation to null:
> my $freeok = $intlfree or ($upscountry =~ /^us/i);
Others gave you the answer, so I'll point out that when you're thinking
that you're seeing an expression differently than Perl is seeing it,
the -MO=Deparse,-p option is a good tool to have. It puts parentheses
everywhere they can be put, to explicitly delineate the precedence of
each component of your statement:
$ perl -MO=Deparse,-p -e'my $freeok = $intlfree or ($upscountry =~
/^us/i);'
((my $freeok = $intlfree) or ($upscountry =~ /^us/i));
-e syntax OK
$ perl -MO=Deparse,-p -e'my $freeok = $intlfree || ($upscountry =~
/^us/i);'
(my $freeok = ($intlfree || ($upscountry =~ /^us/i)));
-e syntax OK
Paul Lalli
------------------------------
Date: Wed, 14 Jun 2006 11:49:39 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Boolean expression
Message-Id: <slrne90fh3.1aj.tadmc@magna.augustmail.com>
Glenn Jackman <glennj@ncf.ca> wrote:
> At 2006-06-14 12:10PM, Marshall Dudley <mdudley@king-cart.com> wrote:
>> my $freeok = $intlfree or ($upscountry =~ /^us/i);
>
> Precedence. Read perldoc perlop
>
> use
> my $freeok = ($intlfree or ($upscountry =~ /^us/i));
> or
> my $freeok = $intlfree || ($upscountry =~ /^us/i);
or
my $freeok = $intlfree || $upscountry =~ /^us/i;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 14 Jun 2006 13:09:28 GMT
From: Ignoramus7096 <ignoramus7096@NOSPAM.7096.invalid>
Subject: Re: Converting XML to Perl structures FAST
Message-Id: <cUTjg.38665$Z44.23764@fe34.usenetserver.com>
On Wed, 14 Jun 2006 10:53:03 +0200, Michel Rodriguez <mirod@xmltwig.com> wrote:
> Ignoramus17503 wrote:
>> On 13 Jun 2006 01:35:08 GMT, John Bokma <john@castleamber.com> wrote:
>>
>>>Ignoramus17503 <ignoramus17503@NOSPAM.17503.invalid> wrote:
>>>
>>>
>>>>I installed XML::Twig, and things seem, so far, to be a lot faster and
>>>>CPU use is way down. It is not quite as easy to use, but I can live
>>>>with it.
>>>
>>>Uhm, how easy do you want it? Study the manual and the examples.
>>
>>
>> Well, here's how I accessed data with XML::Simple:
>>
>> my $price = $item->{SellingStatus}->{CurrentPrice}->{content};
>>
>> Here's how I access it with XML::Twig:
>>
>> $price = $item->first_child( 'SellingStatus' )->first_child( 'CurrentPrice' )->text;
>
> If you do $item->simplify, then you get the exact same structure as with
> XML::Simple (if there is any difference you can report this as a bug).
Thanks, that's a great tip, I will use it in the future.
> Also if you find any memory leak, report it, and hopefully I can fix the
> bug.
Well, I have used it quite a lot by now, and I see no problems. I
mentioned memory leaks as a mere possibility, in relation to
XML::Simple, not XML::Twig.
Thank you for your fine work. I may add support of XML::Twig to
Net::eBay as a user option.
i
------------------------------
Date: 14 Jun 2006 10:10:06 GMT
From: Robert Sedlacek <phaylon@dunkelheit.at>
Subject: Re: how to call a function using variable
Message-Id: <448fe07e$0$11064$9b4e6d93@newsread4.arcor-online.net>
Brian McCauley <nobull67@gmail.com> wrote
>
> I prefer...
> {
> no strict 'refs';
> $a ="Net::SNMP::Message::$function"->();
> }
>
> This is better because
>
> 1) It has a big red flag saying "I'm using symrefs"
>
> 2) It does not pass any unwanted arguments
>
> 3) It cannot be abused to call functions except in namespaces
> starting Net::SNMP::Message:
It's not exactly the same though. Your version wouldn't care for
inheritance. But there's also
my $res = Net::SNMP::Message->can( $function )->( @args );
By splitting this up, you'd also get an easy way of verifying that the
function really exists.
> Note: other people will probably tell you not to use a symbol table as
> dispatch table but to write your own. There are often (usually) good
> reasons to follow that advice, but this is possbily not one of those
> occasions.
Possibly. Care to elaborate why you think it's not? A dispatch table
has more advantages than just keeping things away from the symbol table.
It is a kind of defined interface, and it doesn't matter what closure
lies behind. This can come in handy compared to function or method
calls.
p
--
Better to reign in hell than to serve in heaven.
-- John Milton, Paradise Lost
------------------------------
Date: 14 Jun 2006 10:18:32 -0700
From: nsb_tsd@eml.cc
Subject: Re: IE Mechanize urls -- what about escaping?
Message-Id: <1150305512.371095.278390@c74g2000cwc.googlegroups.com>
> WTF is IE->get???
Win32::IE::Mechanize object.
> Why are you doing a bitwise and of two scalars??
>
Duh! I thought I was catenating them.
Good catch!
> Print the value of it and debug from there.
Yeah, should have been using plus or dot for string cat.
Thanks!
------------------------------
Date: 14 Jun 2006 11:02:02 -0700
From: nsb_tsd@eml.cc
Subject: Re: IE Mechanize urls -- what about escaping?
Message-Id: <1150308121.993041.288190@u72g2000cwu.googlegroups.com>
> Well, you could debug your code by looking if the value is escaped or
> not at any point when the code runs (just for the debug work,
> obviously), like
>
> print "1. URL is now $urlnow\n";
> print "2. URL is now $urlnow\n";
> ...
>
Thanks, I tried that, and saw the %2Fs etc, so I thought it was already
unescaped.
The problem turned out to be the misplaced & operator.
> --------------
> #!perl
> use strict; use warnings; use URI::Escape;
> my $string
> ='2FxxxD%2Fxxa%2FS%2FasdfF%2Fbsa%2FNIL%2FNIL%2FXF%252';
> print uri_unescape($string);
> --------------
cool, will keep that in mind.
cheers,
nb
------------------------------
Date: Wed, 14 Jun 2006 19:57:40 +0200
From: Huub <"v.niekerk at hccnet.nl">
Subject: question installing DBD::mysql
Message-Id: <449049c8$0$32302$e4fe514c@dreader25.news.xs4all.nl>
Hi,
I'm trying to install DBD::mysql, but it reports it can't connect to the
local MySQL server. This is correct, since that server is on another
machine. The --help says I should use <host=....>, but I can't figure
out what the syntax for that is. I tried "install DBD::mysql --host=xxx"
where I tried both IP number as machinename for xxx. No such luck.
Any help is appreciated.
Huub
------------------------------
Date: Wed, 14 Jun 2006 12:48:09 +0200
From: Mirco Wahab <peace.is.our.profession@gmx.de>
Subject: substr() hassle, *n*x vs. Win32
Message-Id: <e6opo1$dfv$1@mlucom4.urz.uni-halle.de>
While trying to get along with some
"C to perl" interfacing, I stumbled
upon substr when using it to 'lvalue'
a packed scalar structure to a portion
of its string like
substr( $data, $offsett, $size ) = pack "ddd", $x, $y, $z;
which works fine (in the context I use it)
under Perl-587 (Inline::C 0.44) in Linux.
At a Win32-environment (Activeperl 587,
nmake, cl) this seem to fail sometimes.
Maybe I made a mistake that I'm not
aware of.
I'll include a short example where this
problem occurs. A C-function is called,
which allocates an SV* and writes
geometrical data (double) to it.
Back in perl, this data is unpacked
an printed (checked visually).
Then, this date is accessed by Perls
substr(), which works, as said, under
Linux but not under windows. The data
in $data gets messed up, as if perl
would cur out a portion of the string
and insert a new one of different size.
Thanks in advance,
Mirco
==>
#!/usr/lib/perl
use strict;
use warnings;
my $bsize = P3Dsize(); # sizeof(struct) from C
my $strct = "d3i"; # (atual) format of the above
my $vlen = 6; # number of elements to work with
my ($data, $x, $y, $z, $id, $blk); # some declarations
makesomevector_of($vlen, $data); # call into inline c
for my $idx (0 .. $vlen-1 ) {
# first: access structures and print (always fine!)
$blk = substr $data, $idx*$bsize, $bsize; # take out structure
($x, $y, $z, $id) = unpack $strct, $blk ; # unpack it
print " $x\t$y\t$z\t[$id]\n"; # print it (fine)
# second: access structures from Perl, !seems to fail in Win32!
substr( $data, $idx*$bsize, $bsize ) = pack $strct, $x+1, $y+1, $z+1, $id+1;
# third: access structures again and print (fails badly under W32/nmake/cl)
$blk = substr $data, $idx*$bsize, $bsize; # re-take structure
($x, $y, $z, $id) = unpack $strct, $blk; # unpack it
print "+$x\t$y\t$z\t[$id]+\n"; # print it (prints garbage!)
}
use Inline C => <<'END_OF_C_CODE';
typedef struct {
double x, y, z;
int id;
} P3D;
int P3Dsize() { return sizeof(P3D); }
int makesomevector_of(int Count, SV* perl_sv)
{
int id, blocksize = Count * P3Dsize();
P3D* pvec = (P3D*) malloc(blocksize);
if(pvec) {
for(id=0; id<Count; id++){
double val = id+1;
pvec[id].id = id;
pvec[id].x = val;
pvec[id].y = val*val;
pvec[id].z = val*val*val;
}
sv_setpvn( perl_sv, (char *)pvec, blocksize );
return 1;
}
return 0;
}
END_OF_C_CODE
------------------------------
Date: Wed, 14 Jun 2006 15:25:48 +0200
From: Mirco Wahab <peace.is.our.profession@gmx.de>
Subject: Re: substr() hassle, *n*x vs. Win32
Message-Id: <e6p2vk$g5k$1@mlucom4.urz.uni-halle.de>
Thus spoke Mirco Wahab (on 2006-06-14 12:48):
>
> substr( $data, $offsett, $size ) = pack "ddd", $x, $y, $z;
> [Problem]
I could - after some fiddling - spot the problem
and I'm wondering if there aren't some receipes for
that one ...
The problem is, I had a C structural type
struct {
double x, y, z;
int n;
};
and would tell that it is 28 bytes in size,
corresponding to a "dddi" pack format.
But actually each compiler has had its
own thinking about this, and - of course,
its the structure alignment problem, which
shines through here.
In the case above, my gcc 3.3.3 would tell
out of the box: "C struct size is 28 bytes"
whereas my VC6/cl would insist:
"C struct size is 32 bytes"
I could fix the Win32-problem simply by
changing the pack-format from (28 byte) "dddi"
to (32 byte) "dddii". This leads of course
to phenomenal failures in the Linux-version ;-)
It looks like one could have a cheap and fast
vector interface by writing stuff directly
into scalars (if $n gets larger than 10^5),
if not the only problem that hit me was the
compiler specific alignment problem.
How do I solve this?
Another question: if I return a C-generated
SV* back to perl via return(SV*), do I have
to 'mortalize' anything - or does perl take
care of that?
(Source example attached)
Regards
Mirco
==>
#!/usr/lib/perl
use strict;
use warnings;
my $vlen = 6; # number of elements to work with
my $bsize = P3Dsize(); # sizeof(struct) from C
my $strct = "dddi"; # (actual) format, padded to sizeof(struct)
my ($blk, $x, $y, $z, $n); # some declarations
print "C struct size is: $bsize bytes\n";
# call into inline c
my $data = makesomevector_of( $vlen ) or die "couldn't allocate\n";
for my $idx (0 .. $vlen-1 ) {
# first: access structures and print (always fine!)
$blk = substr $data, $idx*$bsize, $bsize; # take out structure
($x, $y, $z, $n) = unpack $strct, $blk; # unpack it
print " $x\t$y\t$z\t[$n]\n"; # print it (fine)
# second: access structures from Perl (simply increment by 9)
substr( $data, $idx*$bsize, $bsize ) = pack $strct, $x+9, $y+9, $z+9, $n+9;
# third: look into structures again and print them
$blk = substr $data, $idx*$bsize, $bsize; # re-take structure
($x, $y, $z, $n) = unpack $strct, $blk; # unpack it
print "+$x\t$y\t$z\t[$n]+\n"; # print it
}
use Inline C => <<'END_OF_C_CODE';
typedef struct {
double x, y, z;
int n; // always check structure alignment by
} P3D; // sizeof(struct) vs. sizeof(all members)
int P3Dsize() { return sizeof(P3D); }
SV* makesomevector_of(int Count)
{
int i, blocksize = Count * P3Dsize();
P3D* pvec = (P3D*) malloc(blocksize);
SV* perl_sv = newSV(0);
if(pvec) {
for(i=0; i<Count; i++){
double val = i+1;
pvec[i].n = i;
pvec[i].x = val;
pvec[i].y = val*val;
pvec[i].z = val*val*val;
}
sv_setpvn( perl_sv, (char *)pvec, blocksize );
free( pvec );
}
return perl_sv;
}
END_OF_C_CODE
------------------------------
Date: Wed, 14 Jun 2006 15:25:39 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: substr() hassle, *n*x vs. Win32
Message-Id: <3si5m3-khl.ln1@osiris.mauzo.dyndns.org>
Quoth Mirco Wahab <peace.is.our.profession@gmx.de>:
> Thus spoke Mirco Wahab (on 2006-06-14 12:48):
>
> >
> > substr( $data, $offsett, $size ) = pack "ddd", $x, $y, $z;
> > [Problem]
>
> I could - after some fiddling - spot the problem
> and I'm wondering if there aren't some receipes for
> that one ...
>
> The problem is, I had a C structural type
>
> struct {
> double x, y, z;
> int n;
> };
>
> and would tell that it is 28 bytes in size,
> corresponding to a "dddi" pack format.
>
> But actually each compiler has had its
> own thinking about this, and - of course,
> its the structure alignment problem, which
> shines through here.
>
> In the case above, my gcc 3.3.3 would tell
> out of the box: "C struct size is 28 bytes"
> whereas my VC6/cl would insist:
> "C struct size is 32 bytes"
>
> I could fix the Win32-problem simply by
> changing the pack-format from (28 byte) "dddi"
> to (32 byte) "dddii". This leads of course
Better would be one of "dddixx" or "dddxxi" depending on where the
space is. You can use the offsetof() C macro to find out.
> to phenomenal failures in the Linux-version ;-)
>
> It looks like one could have a cheap and fast
> vector interface by writing stuff directly
> into scalars (if $n gets larger than 10^5),
> if not the only problem that hit me was the
> compiler specific alignment problem.
You may want to look at Bit::Vector.
> How do I solve this?
One way is to use Inline::Struct.
Another is to have your Makefile.PL compile a little test program that
uses offsetof to work out the right template and prints it out. Then you
can substitute this into your .pm.
> Another question: if I return a C-generated
> SV* back to perl via return(SV*), do I have
> to 'mortalize' anything - or does perl take
> care of that?
Have you read Inline::C-Cookbook? If you return a SV*, Inline::C will
mortalize it for you. Otherwise, you must do it yourself.
> (Source example attached)
>
> ==>
> #!/usr/lib/perl
> use strict;
> use warnings;
>
> my $vlen = 6; # number of elements to work with
> my $bsize = P3Dsize(); # sizeof(struct) from C
> my $strct = "dddi"; # (actual) format, padded to sizeof(struct)
> my ($blk, $x, $y, $z, $n); # some declarations
> print "C struct size is: $bsize bytes\n";
>
> # call into inline c
> my $data = makesomevector_of( $vlen ) or die "couldn't allocate\n";
>
> for my $idx (0 .. $vlen-1 ) {
> # first: access structures and print (always fine!)
> $blk = substr $data, $idx*$bsize, $bsize; # take out structure
> ($x, $y, $z, $n) = unpack $strct, $blk; # unpack it
> print " $x\t$y\t$z\t[$n]\n"; # print it (fine)
>
> # second: access structures from Perl (simply increment by 9)
> substr( $data, $idx*$bsize, $bsize ) = pack $strct, $x+9, $y+9, $z+9, $n+9;
>
> # third: look into structures again and print them
> $blk = substr $data, $idx*$bsize, $bsize; # re-take structure
> ($x, $y, $z, $n) = unpack $strct, $blk; # unpack it
> print "+$x\t$y\t$z\t[$n]+\n"; # print it
> }
>
> use Inline C => <<'END_OF_C_CODE';
>
> typedef struct {
> double x, y, z;
> int n; // always check structure alignment by
> } P3D; // sizeof(struct) vs. sizeof(all members)
>
> int P3Dsize() { return sizeof(P3D); }
>
> SV* makesomevector_of(int Count)
> {
> int i, blocksize = Count * P3Dsize();
> P3D* pvec = (P3D*) malloc(blocksize);
Don't use malloc! Use New/Safefree, which is the perl interface to the
allocator.
> SV* perl_sv = newSV(0);
You should probably use NEWSV instead, and it would be more efficient to
allocate string space straight away.
Ben
--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. benmorrow@tiscali.co.uk
------------------------------
Date: 14 Jun 2006 15:56:51 GMT
From: xhoster@gmail.com
Subject: Re: substr() hassle, *n*x vs. Win32
Message-Id: <20060614115709.164$1O@newsreader.com>
Mirco Wahab <peace.is.our.profession@gmx.de> wrote:
> Thus spoke Mirco Wahab (on 2006-06-14 12:48):
>
> >
> > substr( $data, $offsett, $size ) = pack "ddd", $x, $y, $z;
> > [Problem]
>
> I could - after some fiddling - spot the problem
> and I'm wondering if there aren't some receipes for
> that one ...
>
> The problem is, I had a C structural type
>
> struct {
> double x, y, z;
> int n;
> };
>
> and would tell that it is 28 bytes in size,
> corresponding to a "dddi" pack format.
>
> But actually each compiler has had its
> own thinking about this, and - of course,
> its the structure alignment problem, which
> shines through here.
>
...
>
> It looks like one could have a cheap and fast
> vector interface by writing stuff directly
> into scalars (if $n gets larger than 10^5),
> if not the only problem that hit me was the
> compiler specific alignment problem.
>
> How do I solve this?
I think the simple answer is that you don't solve this. You can't
take on the performance power of C without taking its liabilities, one
of which is the nonportability of structs. So you can circumvent it
in several ways, but they depend on what you are trying to do. You
could use four independent arrays (3 for doubles and one for int), although
there may be alignment problems there as well. Or you could just fiddle
with it until it works on your machine and then accept that it will not be
portable.
>
> Another question: if I return a C-generated
> SV* back to perl via return(SV*), do I have
> to 'mortalize' anything - or does perl take
> care of that?
In this case, Perl takes care of it. I know this for two reasons. I ran
your code in a loop and noticed no memory leak, I added a
sv_2mortal(perl_sv) and ran your code and got "Attempt to free unreferenced
scalar" errors. Alas, I don't know how you figure these things out from
first principles.
I generally side step these issues by making a string of the right length
in perl, and then passing that string into the Inline code for the C to
fill in and use.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 14 Jun 2006 16:04:33 GMT
From: xhoster@gmail.com
Subject: Re: substr() hassle, *n*x vs. Win32
Message-Id: <20060614120451.921$nL@newsreader.com>
xhoster@gmail.com wrote:
> ...
> >
> > It looks like one could have a cheap and fast
> > vector interface by writing stuff directly
> > into scalars (if $n gets larger than 10^5),
> > if not the only problem that hit me was the
> > compiler specific alignment problem.
> >
> > How do I solve this?
>
> I think the simple answer is that you don't solve this. You can't
> take on the performance power of C without taking its liabilities, one
> of which is the nonportability of structs. So you can circumvent it
> in several ways, but they depend on what you are trying to do. You
> could use four independent arrays (3 for doubles and one for int),
> although there may be alignment problems there as well. Or you could
> just fiddle with it until it works on your machine and then accept that
> it will not be portable.
>
> >
> > Another question: if I return a C-generated
> > SV* back to perl via return(SV*), do I have
> > to 'mortalize' anything - or does perl take
> > care of that?
>
> In this case, Perl takes care of it. I know this for two reasons. I ran
> your code in a loop and noticed no memory leak, I added a
> sv_2mortal(perl_sv) and ran your code and got "Attempt to free
> unreferenced scalar" errors. Alas, I don't know how you figure these
> things out from first principles.
On both of these, never mind me. Listen to Ben. He really knows what he
is doing. If I'd seen his post before I started composing my own, I
wouldn't have responded.
> I generally side step these issues by making a string of the right length
> in perl, and then passing that string into the Inline code for the C to
> fill in and use.
Well, but I do still like doing this.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Wed, 14 Jun 2006 13:40:58 +0000 (UTC)
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: The Nature of the "Unix Philosophy" (long)
Message-Id: <e6p3la$fjf$1@canopus.cc.umanitoba.ca>
In article <128ut3uqitovuff@corp.supernews.com>,
SM Ryan <wyrmwif@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
># Commercial software tends towards one huge tool that can be used to
>Except for Linux and BSD, Unix is commercial software.
Linux is not UNIX. BSD isn't either.
UNIX is a trademark of The Open Group (www.opengroup.org); see
www.unix.org for OpenGroup's unix section.
No Linux or BSD systems have passed the UNIX certification programs.
The list is: http://www.opengroup.org/openbrand/register/
and can be summarized as: Solaris, AIX, UnixWare (SCO),
HP-UX, IRIX (SGI), NCR UNIX, UX (NEC)
There is a Linux Base certification from OpenGroup that 12 different
companies have passed.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
------------------------------
Date: 14 Jun 2006 06:44:47 -0700
From: luz_a_gue@latinmail.com
Subject: Re: The Nature of the "Unix Philosophy" (long)
Message-Id: <1150292687.086082.81870@f6g2000cwb.googlegroups.com>
John Bokma: What the fuck is this?
Not that I support Xah, but obviously you are the main dick in this
thread.
24-May . [ 48: John Bokma ]> Re: John Bokma harassment
24-May . < 23: John Bokma > `->
24-May . < 39: John Bokma > `->
23-May . < 35: John Bokma > `-> Re: Software Needs
Philosophers
24-May . < 40: John Bokma > `-> Re: John Bokma
harassment
29-May . < 22: John Bokma > `->
24-May . < 12: John Bokma > `->
30-May . < 15: John Bokma > `->
30-May . < 23: John Bokma > `->
25-May . < 13: John Bokma > `->
24-May . < 65: John Bokma > `->
24-May . < 17: John Bokma > `->
25-May . < 16: John Bokma > `->
30-May . < 14: John Bokma > `->
24-May . < 12: John Bokma > `->
24-May . < 32: John Bokma > `->
25-May . < 12: John Bokma > `->
24-May . < 31: John Bokma > `->
26-May . < 24: John Bokma > `-> Re: OT: Quote ?
26-May . < 32: John Bokma > `-> OT: Navarth
26-May . < 14: John Bokma > `-> Re: John Bokma
harassment
24-May . < 50: John Bokma > `->
26-May . < 31: John Bokma > `-> Re: OT: Quote ?
26-May . < 59: John Bokma > `-> Re: John Bokma
harassment
27-May . < 41: John Bokma > `->
------------------------------
Date: 14 Jun 2006 07:04:10 -0700
From: "Andrew" <hawk007@flight.us>
Subject: Re: The Nature of the "Unix Philosophy" (long)
Message-Id: <1150293850.852151.114140@p79g2000cwp.googlegroups.com>
SM Ryan wrote:
> # Commercial software tends towards one huge tool that can be used to
>
> Except for Linux and BSD, Unix is commercial software.
Speaking strictly of the OS, yes (for most derivatives of BSD,
excepting, of course, Apple Mac OS X)
But the discussion encompassed both the OS and applications, i thought.
Although, I don't know the statistics on the crossover -- what
percentage of, say, SCO Unix users install OSS applications today? (And
which apps?) My guess is that such hybridizing is widespread; I mean,
why would they hesitate to take advantage of free, quality apps, even
if they *are* on a proprietary OS?
Anyone have data on that?
andrew
------------------------------
Date: Wed, 14 Jun 2006 16:34:56 GMT
From: Al Balmer <albalmer@att.net>
Subject: Re: The Nature of the "Unix Philosophy" (long)
Message-Id: <fje0929l37g48lv5mdtgc147u5iinqgc6o@4ax.com>
On 14 Jun 2006 06:44:47 -0700, luz_a_gue@latinmail.com wrote:
>John Bokma: What the fuck is this?
>
>Not that I support Xah, but obviously you are the main dick in this
>thread.
Both John Bokma and dicks are off-topic in comp.lang.c.
Please take your spat elsewhere.
--
Al Balmer
Sun City, AZ
------------------------------
Date: Wed, 14 Jun 2006 12:33:47 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: UTF-8 subject in an email
Message-Id: <e6ovr9.94.1@news.isolution.nl>
Yohan N. Leder schreef:
> Ruud:
>> Check the "Content" header fields too, you'll need ones like:
>> Content-Type: text/plain; charset="UTF-8"
>> Content-Transfer-Encoding: 8bit
>> for the body to be recognized as encoded in UTF-8.
>
> Already done, but now we know the responsible is Eudora which ignore
> the charset.
Some mailers assume that the charset for the body can also be used for
the Subject, certainly when there are characters >127 in the Subject.
But that is not compliant.
About Eudora, see also:
http://www.cit.cornell.edu/computer/email/thunderbird/overview.html
http://windharp.de/software/utf8iso.htm
>> A compliant Subject-header can only have 7-bit characters, so you
>> need to do
>> use utf8 ;
>> my $subject = encode( 'MIME_Header', 'Subject: boīte' ) ;
>>
>> Test:
>> perl -MEncode -le 'print "Subject: " . encode("MIME-Header",
>> "bo\x{00EE}te")' prints: Subject: =?UTF-8?B?Ym/DrnRl?=
>
> Agreed, but sure now Eudora (as some others clients emails) is the
> only responsible.
Eudora is dead.
Not all Eudora's were the same:
http://www.bd8.com/eudora/multilingual/
> So, I've decided to check if convertible to ISO-8859-1 using encode()
> with CHECK in eval{}, then do it if possible or take an alternative
> way if not (like : sending text as attachment too, or build an HTML
> oriented email ; not choosen at this time)
Yes, that is the nice way.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Wed, 14 Jun 2006 14:29:05 +0200
From: Yohan N. Leder <ynleder@nspark.org>
Subject: Re: UTF-8 subject in an email
Message-Id: <MPG.1efa1f7ee9a1ccba98989e@news.tiscali.fr>
In article <e6ovr9.94.1@news.isolution.nl>, rvtol+news@isolution.nl
says...
> About Eudora, see also:
> http://www.cit.cornell.edu/computer/email/thunderbird/overview.html
> http://windharp.de/software/utf8iso.htm
Yes, thanks, downloaded and installed yesterday, but it doesn't does the
job in every case :
- it works partially for the body : well take care of the "Content-Type:
text/plain; charset=utf-8" statement, but "Content-Transfer-Encoding:
8bit" appear in body as if it was simple text rather than a statement.
- it doesn't do anything for the word-encoded subject in some cases (not
the context in mind).
Well, however, it seems there ware other client around which ignore UTF-
8 : so, no choice !
> Eudora is dead.
> Not all Eudora's were the same:
> http://www.bd8.com/eudora/multilingual/
Hoping not. It should be not so hard to add UTF-8 support in all next
versions, whatever be the localization. Or, maybe, in the original
English one for starting. Or, why not, as first step, that Qualcomm and
assimilated integrate the utf8iso plugin in the standard package, then
improve it.
> > So, I've decided to check if convertible to ISO-8859-1 using encode()
> > with CHECK in eval{}, then do it if possible or take an alternative
> > way if not (like : sending text as attachment too, or build an HTML
> > oriented email ; not choosen at this time)
>
> Yes, that is the nice way.
Thaks, it's in progress...
------------------------------
Date: 14 Jun 2006 15:42:25 +0200
From: torbenm@app-1.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <7zpshbsvjy.fsf@app-1.diku.dk>
"Joe Marshall" <eval.apply@gmail.com> writes:
> > On the Expressive Power of Programming Languages, by Matthias
> > Felleisen, 1990.
> > http://www.ccs.neu.edu/home/cobbe/pl-seminar-jr/notes/2003-sep-26/expressive-slides.pdf
>
> The gist of the paper is this: Some computer languages seem to be
> `more expressive' than others. But anything that can be computed in
> one Turing complete language can be computed in any other Turing
> complete language. Clearly the notion of expressiveness isn't
> concerned with ultimately computing the answer.
>
> Felleisen's paper puts forth a formal definition of expressiveness
> in terms of semantic equivilances of small, local constructs. In
> his definition, wholescale program transformation is disallowed so
> you cannot appeal to Turing completeness to claim program
> equivalence.
I think expressiveness is more subtle than this. Basically, it boils
down to: "How quickly can I write a program to solve my problem?".
There are several aspects relevant to this issue, some of which are:
- Compactness: How much do I have to type to do what I want?
- Naturality: How much effort does it take to convert the concepts of
my problem into the concepts of the language?
- Feedback: Will the language provide sensible feedback when I write
nonsensical things?
- Reuse: How much effort does it take to reuse/change code to solve a
similar problem?
Compactness is hard to measure. It isn't really about the number of
characters needed in a program, as I don't think one-character symbols
instead of longer keywords make a language more expressive. It is
better to count lexical units, but if there are too many different
predefined keywords and operators, this isn't reasonable either.
Also, the presence of opaque one-liners doesn't make a language
expressible. Additionally, as mentioned above, Turing-completeness
(TC) allows you to implement any TC language in any other, so above a
certain size, the choice of language doesn't affect size. But
something like (number of symbols in program)/log(number of different
symbols) is not too bad. If programs are allowed to use standard
libraries, the identifiers in the libraries should be counted in the
number of different symbols.
Naturality is very difficult to get a grip on, and it strongly depends
on the type of problem you want to solve. So it only makes sense to
talk about expressiveness relative to a set of problem domains. If
this set is small, domain-specific languages win hands down, so if you
want to compare expressiveness of general-purpose languages, you need
a large set of very different problems. And even with a single
problem, it is hard to get an objective measure of how difficult it is
to map the problem's concepts to those of the language. But you can
normally observe whether you need to overspecify the concept (i.e.,
you are required to make arbitrary decisions when mapping from concept
to data), if the mapping is onto (i.e., can you construct data that
isn't sensible in the problem domain) and how much redundancy your
representation has.
Feedback is a mixture of several things. Partly, it is related to
naturality, as a close match between problem concepts and language
concepts makes it less likely that you will express nonsense (relative
to the problem domain) that makes sense in the language. For example,
if you have to code everything as natural numbers, untyped pure lambda
calculus or S-expressions, there is a good chance that you can get
nonsense past the compiler. Additionally, it is about how difficult
it is to tie an observation about a computed result to a point in the
program.
Measuring reuse depends partly on what is meant by problems being
similar and also on whether you at the time you write the original
code can predict what types of problems you might later want to solve,
i.e., if you can prepare the code for reuse. Some languages provide
strong mechanisms for reuse (templates, object hierarchies, etc.), but
many of those require that you can predict how the code is going to be
reused. So, maybe, you should measure how difficult it is to reuse a
piece of code that is _not_ written with reuse in mind.
This reminds me a bit of last years ICFP contest, where part of the
problem was adapting to a change in specification after the code was
written.
> Expressiveness isn't necessarily a good thing. For instance, in C,
> you can express the addresses of variables by using pointers. You
> cannot express the same thing in Java, and most people consider this
> to be a good idea.
I think this is pretty much covered by the above points on naturality
and feedback: Knowing the address of a value or object is an
overspecification unless the address maps back into something in the
problem domain.
On a similar note, is a statically typed langauge more or less
expressive than a dynamically typed language? Some would say less, as
you can write programs in a dynamically typed language that you can't
compile in a statically typed language (without a lot of encoding),
whereas the converse isn't true. However, I think this is misleading,
as it ignores the feedback issue: It takes longer for the average
programmer to get the program working in the dynamically typed
language.
Torben
------------------------------
Date: Wed, 14 Jun 2006 10:51:05 -0400
From: Raffael Cavallaro <raffaelcavallaro@pas-d'espam-s'il-vous-plait-mac.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <2006061410510511272-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2006-06-14 09:42:25 -0400, torbenm@app-1.diku.dk (Torben Ęgidius
Mogensen) said:
> It takes longer for the average
> programmer to get the program working in the dynamically typed
> language.
Though I agree with much of your post I would say that many here find
the opposite to be true - it takes us longer to get a program working
in a statically typed language because we have to keep adding/changing
things to get the compiler to stop complaining and actually compile and
run a program which would be perfectly permissible in a dynamically
typed language such as common lisp - for example - heterogeneous lists
and forward references to as yet non-existent functions.
------------------------------
Date: 14 Jun 2006 08:12:12 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150297932.458202.227360@c74g2000cwc.googlegroups.com>
Torben =C6gidius Mogensen wrote:
> On a similar note, is a statically typed langauge more or less
> expressive than a dynamically typed language? Some would say less, as
> you can write programs in a dynamically typed language that you can't
> compile in a statically typed language (without a lot of encoding),
> whereas the converse isn't true. However, I think this is misleading,
> as it ignores the feedback issue: It takes longer for the average
> programmer to get the program working in the dynamically typed
> language.
>From the point of view purely of expressiveness I'd say it's rather
different.
If a language can express constraints of one kind that is an increase
in expressiveness.
If a language requires constraint to be in one particular way thats a
decrease in expressiveness.
So I would say languages that can be statically typed and can be
dynamically typed are the most expressive. Languages that require
static typing or are dynamic but cannot express static typing are less
expressive.
This meets my experience of what useful in practice too, static typing
for everything is painful for writing simple code. Pure dynamic typing
is painful when writing complex code because it makes impossible a
layer of error checking that could otherwise be useful.
------------------------------
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 9296
***************************************
