[27966] in Perl-Users-Digest
Perl-Users Digest, Issue: 9330 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 21 06:05:38 2006
Date: Wed, 21 Jun 2006 03: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, 21 Jun 2006 Volume: 10 Number: 9330
Today's topics:
Re: asyncrhronous system call <David.Squire@no.spam.from.here.au>
Re: Gtk2-perl <thepoet_nospam@arcor.de>
Re: Help - Inline::C arrayref deref? <leegee@gmail.com>
Re: How to pronounce $ <rvtol+news@isolution.nl>
Re: how to replace this like <img width=100 ...> with < <mark.clementsREMOVETHIS@wanadoo.fr>
Re: OO Perl help for a dot Net convert? <siegel@zrz.tu-berlin.de>
Re: Question: Inline::C module packaging? <leegee@gmail.com>
Re: two servers listening on same port ? sc_wizard29@hotmail.com
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 Jun 2006 10:23:18 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: asyncrhronous system call
Message-Id: <e7b366$p69$1@news.ox.ac.uk>
Tad McClellan wrote:
> David Squire <David.Squire@no.spam.from.here.au> wrote:
>> Spin wrote:
>
>>> as I understand it
>>> exec() runs the process but abandons the script
>> Are you talking about perl? That's not what perl exec does.
>
>
> Yes it is.
Arghh. Somehow I was seeing and thinking eval :(
------------------------------
Date: Wed, 21 Jun 2006 09:43:49 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Gtk2-perl
Message-Id: <4498f8b5$0$4497$9b4e6d93@newsread2.arcor-online.net>
prameela wrote:
> Hai All,
>
> I developed one application in Gtk2-perl.I craeted one setup
> for this.To run my application in remote systems i installed gtk 2.8.6
> runtime installer,because my gtk version is 2.8.6.My problem is when i
> run my application with the same thing in WindowsNT4 it is showing
> error as ......
>
>
> The procedure entrypoint FlashWindowEx could not be
> located in the dynamic link library USER32.dll
>
>
> Can anyone suggest solutin for this.
Hi,
FlashWindowEx isn't available in NT4, but dynamic fallback to
FlashWindow has only been added from version 2.8.8 upward. So you
will most probably have to update.
HTH
-Chris
------------------------------
Date: 21 Jun 2006 01:59:13 -0700
From: "Lee" <leegee@gmail.com>
Subject: Re: Help - Inline::C arrayref deref?
Message-Id: <1150880353.051288.269910@c74g2000cwc.googlegroups.com>
xhoster@gmail.com wrote:
> "Sisyphus" <sisyphus1@nomail.afraid.org> wrote:
> > Also, I was puzzled by the SvREFCNT_inc() call in the original code.
>
> You are right, that also shouldn't be there. I had cleaned it up but
> forgot to mention doing so. That one is particularly pernicious, because
> it causes the leak to occur in the regular Perl code.
Could you please explain? I'm confused because my XS and perlguts is
minimal. If I replace this:
AV* av_pcm = newAV();
if (SvROK(rpcm) && (SvTYPE(SvRV(rpcm)) == SVt_PVAV))
av_pcm = (AV*)SvREFCNT_inc(SvRV(rpcm));
with this:
AV* av_pcm = newAV();
av_pcm = (AV*)(SvRV(rpcm));
I get told, "Attempt to free unreferenced scalar: SV 0xb79d7540"
Lee
------------------------------
Date: Wed, 21 Jun 2006 11:40:45 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: How to pronounce $
Message-Id: <e7bbdt.16k.1@news.isolution.nl>
Tim Hammerquist schreef:
> AFAICT, the accepted standard, as mentioned elsewhere in this thread,
> is "$tring" and "@rray". Try that.
ITYM: $calar and @rray
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Wed, 21 Jun 2006 09:47:25 +0200
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: how to replace this like <img width=100 ...> with <img width="100" ...>
Message-Id: <4498f984$0$1031$ba4acef3@news.orange.fr>
Tad McClellan wrote:
> Jürgen Exner <jurgenex@hotmail.com> wrote:
>> zhanye815@gmail.com wrote:
>>> i want to write a script to convert the html to xhtml,so i want to use
>>> the regular expression
>
>> What ever happened to read first, then ask?
>
>> AFAIR there was even a sample program in the HTML::Parser package that did
>> something very similar to what you are asking for.
>
>
> Searching CPAN, or even Google, for "html2xhtml" finds stuff.
>
> I guess we must then guess that this OP did not even look...
>
But that's the trick, isn't it? Knowing exactly what to look for only
comes from experience. The "x2y" idiom is (I'd argue) a unixism. It's a
little unfair to say "why didn't you search for 'xyz123'? simple" when
it isn't at all obvious, unless one is vastly experienced, that one
needed to search for 'xyz123'. This is particularly the case with perldoc -q
eg
F:\Documents and Settings\Mark>perldoc -q html
Found in F:\Perl\lib\pod\perlfaq9.pod
How do I remove HTML from a string?
If I were the OP and had read this, am not sure I'd have read that
particular item any further.
I'd agree, though, that the OP doesn't appear to have done much research
of his own here.
Mark
------------------------------
Date: Wed, 21 Jun 2006 11:15:12 +0200
From: Anno Siegel <siegel@zrz.tu-berlin.de>
Subject: Re: OO Perl help for a dot Net convert?
Message-Id: <4fsh4bF1klqj7U1@news.dfncis.de>
Peter J. Holzer wrote:
> Anno Siegel wrote:
>> Peter J. Holzer wrote:
>>> ben.wilder@gmail.com wrote:
>>
>> [snippage]
>>
>>> So I think, passing references to arrays is generally the best way.
>>>
>>> You can of course make a copy of the array in the constructor:
>>>
>>> _myFavouriteArtists => [ @{ $arg{myFavouriteArtists} } ],
>>>
>>> if you want to. I found this rarely to be necessary,
>>
>> It is practically always necessary to copy any references before
>> using them in an object. Just consider a loop like this:
>>
>> while ( <> ) {
>> my ( $first, $last, $age, @artists) = split;
>> push @somewhere, MyPackage->new( $first, $last, $age, \
>> @artists);
>> }
>>
>> All the objects created in this loop will *share* their internal
>> myFavouriteArtists array and will show the same favourite artists
>> unless you copy the array on object creation.
>
> Actually, no. In this case each run through the loop will create a new
> instance of @artists.
You are right, my example doesn't show what I wanted to show. If
@artists was declared outside of the loop for some reason, the effect
I described will happen (untested again):
my ($first, $last, @artists);
push @somewhere, MyPackage->new( $first, $last, $age, \ @artists)
while <>;
In general, it is not a good idea to use references given from outside
directly in an object. If you do, the users of the class must be
told.
Anno
------------------------------
Date: 21 Jun 2006 02:07:39 -0700
From: "Lee" <leegee@gmail.com>
Subject: Re: Question: Inline::C module packaging?
Message-Id: <1150880859.640166.29670@g10g2000cwb.googlegroups.com>
xhoster@gmail.com wrote:
> "Lee" <leegee@gmail.com> wrote:
> > Ben Morrow wrote:
> > > Quoth "Lee" <leegee@gmail.com>:
> > > > Is there a preferred method of packaging an Inline::C module, perhaps
> > > > one that would compile the C in the correct place during the
> > > > installation, rather than on first run?
> > >
> > > Read the docs for Inline.
> >
> > Me too, but it says:
> >
> > Finally, you need to modify the Makefile.PL. Simply change:
> > use ExtUtils::MakeMaker;
> > to
> > use Inline::MakeMaker;
> >
> > Won't that upset machines and users that don't have Inline installed?
> >
> > Neither did the Iline docs help me solve errors along the lines of "No
> > rule to make target ... needed by `pure_all'," for which I copied
> > something from
> > http://search.cpan.org/src/FXN/Algorithm-Combinatorics-0.10/Makefile.PL.
> >
> > And then there's the whole business of supplying NAME/VERSION and
> > having to disable one to run make test, which is not something I would
> > like to pass on to my end-users.
>
> So why didn't you mention all this stuff in your original post? If you
> did, we wouldn't have to shame it out of you but suggesting that maybe you
> should read the manual.
Since the manual did not answer the question, I still think RTFM was
the wrong response, as it usually is. But that's usenet, I suppose.
------------------------------
Date: 21 Jun 2006 00:16:03 -0700
From: sc_wizard29@hotmail.com
Subject: Re: two servers listening on same port ?
Message-Id: <1150874163.360765.142000@c74g2000cwc.googlegroups.com>
Thanks everyone for your answers... here are two versions of a simple
server that "solve" the multiple binding problem on windows (for the
ones too busy to read all the replies ;)
#!/usr/bin/perl -w
use strict;
use Socket;
my $port = 2000;
my $proto = getprotobyname('tcp');
socket(Server, PF_INET, SOCK_STREAM, $proto) || die "socket: $!";
bind(Server, sockaddr_in($port, INADDR_ANY)) || die "bind: $!";
listen(Server,SOMAXCONN) || die "listen: $!";
print "Server : server started on port $port\n";
while(1) {}
#!/usr/bin/perl -w
use strict;
use IO::Socket;
my $port=8080;
my $server = IO::Socket::INET->new(Proto => 'tcp',
LocalPort => $port,
Listen => SOMAXCONN);
die "can't setup server" unless $server;
print "Server : server started on port $port\n";
while(1) {}
------------------------------
Date: Wed, 21 Jun 2006 07:33:55 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <DD6mg.26347$VE1.23482@newssvr14.news.prodigy.com>
Marshall wrote:
> Joe Marshall wrote:
>
>>They *do* have a related meaning. Consider this code fragment:
>>(car "a string")
>>[...]
>>Both `static typing' and `dynamic typing' (in the colloquial sense) are
>>strategies to detect this sort of error.
>
>
> The thing is though, that putting it that way makes it seems as
> if the two approaches are doing the same exact thing, but
> just at different times: runtime vs. compile time. But they're
> not the same thing. Passing the static check at compile
> time is universally quantifying the absence of the class
> of error; passing the dynamic check at runtime is existentially
> quantifying the absence of the error. A further difference is
> the fact that in the dynamically typed language, the error is
> found during the evaluation of the expression; in a statically
> typed language, errors are found without attempting to evaluate
> the expression.
>
> I find everything about the differences between static and
> dynamic to be frustratingly complex and subtle.
Let me add another complex subtlety, then: the above description misses
an important point, which is that *automated* type checking is not the
whole story. I.e. that compile time/runtime distinction is a kind of
red herring.
In fact, automated type checking is orthogonal to the question of the
existence of types. It's perfectly possible to write fully typed
programs in a (good) dynamically-checked language.
In a statically-checked language, people tend to confuse automated
static checking with the existence of types, because they're thinking in
a strictly formal sense: they're restricting their world view to what
they see "within" the language.
Then they look at programs in a dynamically-checked language, and see
checks happening at runtime, and they assume that this means that the
program is "untyped".
It's certainly close enough to say that the *language* is untyped. One
could also say that a program, as seen by the language, is untyped.
But a program as seen by the programmer has types: the programmer
performs (static) type inference when reasoning about the program, and
debugs those inferences when debugging the program, finally ending up
with a program which has a perfectly good type scheme. It's may be
messy compared to say an HM type scheme, and it's usually not proved to
be perfect, but that again is an orthogonal issue.
Mathematicians operated for thousands of years without automated
checking of proofs, so you can't argue that because a
dynamically-checked program hasn't had its type scheme proved correct,
that it somehow doesn't have types. That would be a bit like arguing
that we didn't have Math until automated theorem provers came along.
These observations affect the battle over terminology in various ways.
I'll enumerate a few.
1. "Untyped" is really quite a misleading term, unless you're talking
about something like the untyped lambda calculus. That, I will agree,
can reasonably be called untyped.
2. "Type-free" as suggested by Chris Smith is equally misleading. It's
only correct in a relative sense, in a narrow formal domain which
ignores the process of reasoning about types which is inevitably
performed by human programmers, in any language.
3. A really natural term to refer to types which programmers reason
about, even if they are not statically checked, is "latent types". It
captures the situation very well intuitively, and it has plenty of
precedent -- e.g. it's mentioned in the Scheme reports, R5RS and its
predecessors, going back at least a decade or so (haven't dug to check
when it first appeared).
4. Type theorists like to say that "universal" types can be used in a
statically-typed language to subsume "dynamic types". Those theorists
are right, the term "dynamic type", with its inextricable association
with runtime checks, definitely gets in the way here. It might be
enlightening to rephrase this: what's really happening is that universal
types allow you to embed a latently-typed program in a
statically-checked language. The latent types don't go anywhere,
they're still latent in the program with universal types. The program's
statically-checked type scheme doesn't capture the latent types.
Describing it in these terms clarifies what's actually happening.
5. Dynamic checks are only part of the mechanism used to verify latent
types. They shouldn't be focused on as being the primary equivalent to
static checks. The closest equivalent to the static checks is a
combination of human reasoning and testing, in which dynamic checks play
an important but ultimately not a fundamental part. You could debug a
program and get the type scheme correct without dynamic checks, it would
just be more difficult.
So, will y'all just switch from using "dynamically typed" to "latently
typed", and stop talking about any real programs in real programming
languages as being "untyped" or "type-free", unless you really are
talking about situations in which human reasoning doesn't come into
play? I think you'll find it'll help to reason more clearly about this
whole issue.
Thanks for your cooperation!!
Anton
------------------------------
Date: Wed, 21 Jun 2006 09:42:22 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4fsbivF1jqb81U1@individual.net>
David Hopwood wrote:
> Pascal Costanza wrote:
>> Rob Thorpe wrote:
>>> Pascal Costanza wrote:
>>>> Matthias Blume wrote:
>>>>> Pascal Costanza <pc@p-cos.net> writes:
>>>>>
>>>>>> (slot-value p 'address) is an attempt to access the field 'address in
>>>>>> the object p. In many languages, the notation for this is p.address.
>>>>>>
>>>>>> Although the class definition for person doesn't mention the field
>>>>>> address, the call to (eval (read)) allows the user to change the
>>>>>> definition of the class person and update its existing
>>>>>> instances. Therefore at runtime, the call to (slot-value p 'adress)
>>>>>> has a chance to succeed.
>>>>> I am quite comfortable with the thought that this sort of evil would
>>>>> get rejected by a statically typed language. :-)
>>>> This sort of feature is clearly not meant for you. ;-P
>>> To be fair though that kind of thing would only really be used while
>>> debugging a program.
>>> Its no different than adding a new member to a class while in the
>>> debugger.
>>>
>>> There are other places where you might add a slot to an object at
>>> runtime, but they would be done in tidier ways.
>> Yes, but the question remains how a static type system can deal with
>> this kind of updates.
>
> It's not difficult in principle:
>
> - for each class [*], define a function which converts an 'old' value of
> that class to a 'new' value (the ability to do this is necessary anyway
> to support some kinds of upgrade). A default conversion function may be
> autogenerated if the class definition has changed only in minor ways.
Yep, this is more or less exactly how CLOS does it. (The conversion
function is called update-instance-for-redefined-class, and you can
provide your own methods on it.)
> - typecheck the new program and the conversion functions, using the old
> type definitions for the argument of each conversion function, and the
> new type definitions for its result.
The problem here is: The program is already executing, so this typecheck
isn't performed at compile-time, in the strict sense of the word (i.e.,
before the program is deployed). It may still be a syntactic analysis,
but you don't get the kind of guarantees anymore that you typically
expect from a static type checker _before_ the program is started in the
first place.
(It's really important to understand that the idea is to use this for
deployed programs - albeit hopefully in a more structured fashion - and
not only for debugging. The example I have given is an extreme one that
you would probably not use as such in a "real-world" setting, but it
shows that there is a boundary beyond which static type systems cannot
be used in a meaningful way anymore, at least as far as I can tell.)
> - have the debugger apply the conversions to all values, and then resume
> the program.
In CLOS, this conversion is defined as part of the language proper, but
this is mostly because Common Lisp doesn't make a sharp distinction
between debugging capabilities and "regular" language features. (I think
it's a good thing that there is no strong barrier against having
debugging capabilities in a deployed program.)
> [*] or nearest equivalent in a non-OO language.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: 21 Jun 2006 11:23:18 +0200
From: torbenm@app-3.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <7zzmg6amm1.fsf@app-3.diku.dk>
"Rob Thorpe" <robert.thorpe@antenova.com> writes:
> Andreas Rossberg wrote:
>
> > No, variables are insignificant in this context. You can consider a
> > language without variables at all (such languages exist, and they can
> > even be Turing-complete) and still have evaluation, values, and a
> > non-trivial type system.
>
> Hmm. You're right, ML is no-where in my definition since it has no
> variables.
That's not true. ML has variables in the mathematical sense of
variables -- symbols that can be associated with different values at
different times. What it doesn't have is mutable variables (though it
can get the effect of those by having variables be immutable
references to mutable memory locations).
What Andreas was alluding to was presumably FP-style languages where
functions or relations are built by composing functions or relations
without ever naming values.
Torben
------------------------------
Date: Wed, 21 Jun 2006 11:06:01 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7b25p$8v164$1@hades.rz.uni-saarland.de>
David Hopwood wrote:
>
> Oh, but it *does* make sense to talk about dynamic tagging in a statically
> typed language.
It even makes perfect sense to talk about dynamic typing in a statically
typed language - but keeping the terminology straight, this rather
refers to something like described in the well-known paper of the same
title (and its numerous follow-ups):
Martin Abadi, Luca Cardelli, Benjamin Pierce, Gordon Plotkin
Dynamic typing in a statically-typed language.
Proc. 16th Symposium on Principles of Programming Languages, 1989
/ TOPLAS 13(2), 1991
Note how this is totally different from simple tagging, because it deals
with real types at runtime.
- Andreas
------------------------------
Date: 21 Jun 2006 02:50:42 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150883442.498308.226730@b68g2000cwa.googlegroups.com>
Matthias Blume wrote:
> "Rob Thorpe" <robert.thorpe@antenova.com> writes:
>
> > I think we're discussing this at cross-purposes. In a language like C
> > or another statically typed language there is no information passed
> > with values indicating their type.
>
> You seem to be confusing "does not have a type" with "no type
> information is passed at runtime".
>
> > Have a look in a C compiler if you don't believe me.
>
> Believe me, I have.
In a C compiler the compiler has no idea what the values are in the
program.
It knows only their type in that it knows the type of the variable they
are contained within.
Would you agree with that?
> > No it doesn't. Casting reinterprets a value of one type as a value of
> > another type.
> > There is a difference. If I cast an unsigned integer 2000000000 to a
> > signed integer in C on the machine I'm using then the result I will get
> > will not make any sense.
>
> Which result are you getting? What does it mean to "make sense"?
Well the right one actually, bad example.
But, if I cast an unsigned int 2500000000 to signed I get -1794967296.
------------------------------
Date: Wed, 21 Jun 2006 11:53:13 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7b4u9$8v164$2@hades.rz.uni-saarland.de>
Rob Thorpe wrote:
>
> I think this should make it clear. If I have a "xyz" in lisp I know it
> is a string.
> If I have "xyz" in an untyped language like assembler it may be
> anything, two pointers in binary, an integer, a bitfield. There is no
> data at compile time or runtime to tell what it is, the programmer has
> to remember.
You have to distinguish between values (at the level of language
semantics) and their low-level representation (at the implementation
level). In a high-level language, the latter should be completely
immaterial to the semantics, and hence not interesting for the discussion.
>>No, variables are insignificant in this context. You can consider a
>>language without variables at all (such languages exist, and they can
>>even be Turing-complete) and still have evaluation, values, and a
>>non-trivial type system.
>
> Hmm. You're right, ML is no-where in my definition since it has no
> variables.
Um, it has. Mind you, it has no /mutable/ variables, but that was not
even what I was talking about.
>>>But the value itself has no type
>>
>>You mean that the type of the value is not represented at runtime? True,
>>but that's simply because the type system is static. It's not the same
>>as saying it has no type.
>
> Well, is it even represented at compile time?
> The compiler doesn't know in general what values will exist at runtime,
> it knows only what types variables have. Sometimes it only has partial
> knowledge and sometimes the programmer deliberately overrides it. From
> what knowledge it you could say it know what types values will have.
Again, variables are insignificant. From the structure of an expression
the type system derives the type of the resulting value. An expression
may contain variables, and then the type system generally must know (or
be able to derive) their types too, but that's a separate issue. Most
values are anonymous. Nevertheless their types are known.
> Unfortunately it's often necessary to break static type systems.
Your definitely using the wrong static language then. ;-)
- Andreas
------------------------------
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 9330
***************************************
