[28096] in Perl-Users-Digest
Perl-Users Digest, Issue: 9460 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 13 06:05:41 2006
Date: Thu, 13 Jul 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 Thu, 13 Jul 2006 Volume: 10 Number: 9460
Today's topics:
Re: Bad protocol 'tcp' <garrett.hennessey@gmail.com>
Re: Bad protocol 'tcp' <rvtol+news@isolution.nl>
Re: finding perl info on google can be hard <jurgenex@hotmail.com>
Micro-pump is cool idea for future computer chips studyandtelecom@yahoo.com
Re: RSS feeds and HTML special characters <john@castleamber.com>
Re: RSS feeds and HTML special characters <john@castleamber.com>
unexpected error with Exporter <dcutter@gmx.de>
Re: What is a type error? <david.nospam.hopwood@blueyonder.co.uk>
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <rossberg@ps.uni-sb.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 12 Jul 2006 15:08:12 -0700
From: "Garrett" <garrett.hennessey@gmail.com>
Subject: Re: Bad protocol 'tcp'
Message-Id: <1152742092.440883.141300@75g2000cwc.googlegroups.com>
Mark -
You're example code (assuming I change the path to c:\winnt\... from
c:\windows\...) works fine. It prints nothing (as it should).
I don't see how this a windows problem. The other programming languages
I use (c++, java, etc) don't have this problem. And I can use the
network with email, web, ftp, telnet, ssh, nfs, etc fine with other
programs. Perl is the only one who complains.
Garrett
Mark Clements wrote:
> garrett.hennessey@gmail.com wrote:
> > Thanks Mark -
> >
> > This supports my belief that for whatever reason, my 'protocol' file is
> > never being used. Any ideas why this may happen?
> >
>
> Pass. What does
>
> use strict;
> use warnings;
>
>
> my $protocolFilePath = q(C:\Windows\System32\Drivers\Etc\Protocol);
> my $protocolFH;
>
> open ( $protocolFH, "<", $protocolFilePath )
> or die "could not open $protocolFilePath for read: $!";
>
>
> give you?
>
> Beyond that, I have a few leads in mind but I'm no Windows expert and so
> they're little more than conjecture. There are people in here with
> vastly more experience than me, although this appears to be more of a
> Windows question than Perl.
>
> regards,
>
> Mark
------------------------------
Date: Thu, 13 Jul 2006 01:28:34 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Bad protocol 'tcp'
Message-Id: <e9484e.1dc.1@news.isolution.nl>
garrett.hennessey@gmail.com schreef:
> One big clue I have is that any call to 'getprotobyname' returns an
> empty string. This is also true for 'getprotobynumber'. This same call
> on the other computers returns the appropriate values as indicated in
> the protocol file.
What does this print:
perl -wle "$,=qq{,$/}; print getprotobyname q{tcp}"
And this:
perl -V:getpr.*
What are the values of the environment variables "SystemRoot" and
"windir"?
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Thu, 13 Jul 2006 00:08:45 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: finding perl info on google can be hard
Message-Id: <hagtg.15258$Wh7.9304@trnddc07>
ilikesluts@gmail.com wrote:
> [...] Using google to find some types of info is
> easy, find other types of info is hard. It depends on what
> characters are in the search. You see, google only handles alpha
> numeric characters.
Ok, well, fine, whatever.
In which way are the limitation or non-limitations of Google related to
Perl?
juye
------------------------------
Date: 13 Jul 2006 02:50:37 -0700
From: studyandtelecom@yahoo.com
Subject: Micro-pump is cool idea for future computer chips
Message-Id: <1152784237.006479.66220@75g2000cwc.googlegroups.com>
Micro-pump is cool idea for future computer chips
http://www.studyandjobs.com/Micro_pump.html
or visit
http://www.studyandjobs.com/IT_study.htm
Regards
------------------------------
Date: 13 Jul 2006 00:27:00 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: RSS feeds and HTML special characters
Message-Id: <Xns97FEC5DA6EFE1castleamber@130.133.1.4>
Ben Morrow <benmorrow@tiscali.co.uk> wrote:
>
> Quoth John Bokma <john@castleamber.com>:
>> "Alan J. Flavell" <flavell@physics.gla.ac.uk> wrote:
>>
>> > Hope this clears things up a bit.
>>
>> Thanks it does (i hope). So it's safe to assume that browsers handle
>> HTML internally as utf8 no matter how it's offered by the webserver?
> ^^^^
> *Unicode*, not UTF8
Yup, my mistake.
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: 13 Jul 2006 00:28:49 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: RSS feeds and HTML special characters
Message-Id: <Xns97FEC62919769castleamber@130.133.1.4>
"Alan J. Flavell" <flavell@physics.gla.ac.uk> wrote:
> Hoping the audience haven't all gone to sleep yet,
Still awake, and thanks Alan and Ben (and others I might have missed).
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: 13 Jul 2006 03:01:06 -0700
From: "Daniel" <dcutter@gmx.de>
Subject: unexpected error with Exporter
Message-Id: <1152784866.464620.84080@m73g2000cwd.googlegroups.com>
I've got quite a large programme that's working just fine except for a
few minor bugs and several design flaws. So I've decided to clean it up
a bit. It uses several self-written objects and modules, so I thought a
good way to start would be to put them in a sub directory. But I get an
error: "Undefined subroutine &main::d1 called at a.pl...". I've reduced
everything down to this:
#### main programme (./a.pl)
#!perl
use strict;
use warnings;
use bb;
use cc::dd;
b1();
d1();
#### module bb (./bb.pm)
package bb;
use strict;
use warnings;
use Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw(b1);
sub b1 { print "b1\n" }
1;
#### module dd in local sub directory cc (./cc/dd.pm)
package dd;
use strict;
use warnings;
use Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw(d1);
sub d1 { print "d1\n" }
1;
"b1" get's printed. But if I move the same code to the sub directory
and just alter the use statement (in my example as dd and d1) I get the
above error message.
The module dd does get loaded: the original file had an END block that
does get executed after the error message.
This is Windows XP SP2 with ActiveState 5.8.8
What did I do wrong? I thought moving the packages to a different place
would only need a alteration of the use statement. But it seems that is
not so. Any ideas?
Regards
Daniel Cutter
------------------------------
Date: Wed, 12 Jul 2006 23:17:31 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is a type error?
Message-Id: <fqftg.311080$8W1.234575@fe1.news.blueyonder.co.uk>
Marshall wrote:
> Joachim Durchholz wrote:
[...]
>>Preconditions/postconditions can express anything you want, and they are
>>an absolutely natural extensions of what's commonly called a type
>>(actually the more powerful type systems have quite a broad overlap with
>>assertions).
>>I'd essentially want to have an assertion language, with primitives for
>>type expressions.
>
> Now, I'm not fully up to speed on DBC. The contract specifications,
> these are specified statically, but checked dynamically, is that
> right? In other words, we can consider contracts in light of
> inheritance, but the actual verification and checking happens
> at runtime, yes?
For DBC as implemented in Eiffel, yes.
> Wouldn't it be possible to do them at compile time? (Although
> this raises decidability issues.)
It is certainly possible to prove statically that some assertions cannot fail.
The ESC/Java 2 (http://secure.ucd.ie/products/opensource/ESCJava2/docs.html)
tool for JML (http://www.cs.iastate.edu/~leavens/JML/) is one system that does
this -- although some limitations and usability problems are described in
<http://secure.ucd.ie/products/opensource/ESCJava2/ESCTools/papers/CASSIS2004.pdf>.
> Mightn't it also be possible to
> leave it up to the programmer whether a given contract
> was compile-time or runtime?
That would be possible, but IMHO a better option would be for an IDE to give
an indication (by highlighting, for example), which contracts are dynamically
checked and which are static.
This property is, after all, not something that the program should depend on.
It is determined by how good the static checker currently is, and we want to be
able to improve checkers (and perhaps even allow them to regress slightly in
order to simplify them) without changing programs.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: 12 Jul 2006 19:19:48 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152757188.426777.216560@h48g2000cwc.googlegroups.com>
Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Marshall schrieb:
> >>> I can see the lack of a formal model being an issue, but is the
> >>> imperative bit really all that much of an obstacle? How hard
> >>> is it really to deal with assignment? Or does the issue have
> >>> more to do with pointers, aliasing, etc.?
> >> Actually aliasing is *the* hard issue.
> >
> > Okay, sure. Nice explanation.
> >
> > But one minor point: you describe this as an issue with "imperative"
> > languages. But aliasing is a problem associated with pointers,
> > not with assignment.
>
> Aliasing is not a problem if the aliased data is immutable.
Okay, sure. But for the problem you describe, both imperativeness
and the presence of pointers is each necessary but not sufficient;
it is the two together that causes the problem. So it strikes
me (again, a very minor point) as inaccurate to describe this as
a problem with imperative languages per se.
> > One can have assignment, or other forms
> > of destructive update, without pointers; they are not part of the
> > definition of "imperative."
>
> Sure.
> You can have either of destructive updates and pointers without
> incurring aliasing problems. As soon as they are combined, there's trouble.
Right. To me the response to this clear: give up pointers. Imperative
operations are too useful to give up; indeed they are a requirement
for certain problems. Pointers on the other hand add nothing except
efficiency and a lot of confusion. They should be considered an
implementation technique only, hidden behind some pointerless
computational model.
I recognize that this is likely to be a controversial opinion.
> Functional programming languages often drop assignment entirely. (This
> is less inefficient than one would think. If everything is immutable,
> you can freely share data structures and avoid some copying, and you can
> share across abstraction barriers. In programs with mutable values,
> programmers are forced to choose the lesser evil of either copying
> entire data structures or doing a cross-abstraction analysis of who
> updates what elements of what data structure. A concrete example: the
> first thing that Windows does when accepting userland data structures
> is... to copy them; this were unnecessary if the structures were immutable.)
I heartily support immutability as the default, for these and other
reasons.
> Some functional languages restrict assignment so that there can exist at
> most a single reference to any mutable data structure. That way, there's
> still no aliasing problems, but you can still update in place where it's
> really, really necessary.
Are we speaking of uniqueness types now? I haven't read much about
them, but it certainly seems like an intriguing concept.
> I know of no professional language that doesn't have references of some
> kind.
Ah, well. I suppose I could mention prolog or mercury, but then
you used that troublesome word "professional." So I will instead
mention a language which, if one goes by number of search results
on hotjobs.com for "xxx progammer" for different value of xxx, is
more popular than Java and twice as popular as C++. It lacks
pointers (although I understand they are beginning to creep in
in the latest version of the standard.) It also posesses a quite
sophisticated set of facilities for declarative integrity constraints.
Yet for some reason it is typically ignored by language designers.
http://hotjobs.yahoo.com/jobseeker/jobsearch/search_results.html?keywords_all=sql+programmer
Marshall
------------------------------
Date: 12 Jul 2006 19:44:28 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152758668.738197.54170@p79g2000cwp.googlegroups.com>
David Hopwood wrote:
> Marshall wrote:
>
> > Wouldn't it be possible to do them at compile time? (Although
> > this raises decidability issues.)
>
> It is certainly possible to prove statically that some assertions cannot fail.
>
> The ESC/Java 2 (http://secure.ucd.ie/products/opensource/ESCJava2/docs.html)
> tool for JML (http://www.cs.iastate.edu/~leavens/JML/) is one system that does
> this -- although some limitations and usability problems are described in
> <http://secure.ucd.ie/products/opensource/ESCJava2/ESCTools/papers/CASSIS2004.pdf>.
I look forward to reading this. I read a paper on JML a while ago and
found it quite interesting.
> > Mightn't it also be possible to
> > leave it up to the programmer whether a given contract
> > was compile-time or runtime?
>
> That would be possible, but IMHO a better option would be for an IDE to give
> an indication (by highlighting, for example), which contracts are dynamically
> checked and which are static.
>
> This property is, after all, not something that the program should depend on.
> It is determined by how good the static checker currently is, and we want to be
> able to improve checkers (and perhaps even allow them to regress slightly in
> order to simplify them) without changing programs.
Hmmm. I have heard that argument before and I'm conflicted.
I can think of more reasons than just runtime safety for which I'd
want proofs. Termination for example, in highly critical code;
not something for which a runtime check will suffice. On the
other hand the points you raise are good ones, and affect
the usability of the language.
Marshall
------------------------------
Date: Wed, 12 Jul 2006 21:15:11 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f1f68abb8043a7398978d@news.altopia.net>
Marshall <marshall.spight@gmail.com> wrote:
> David Hopwood wrote:
> > Marshall wrote:
> > > Mightn't it also be possible to
> > > leave it up to the programmer whether a given contract
> > > was compile-time or runtime?
> >
> > That would be possible, but IMHO a better option would be for an IDE to give
> > an indication (by highlighting, for example), which contracts are dynamically
> > checked and which are static.
> >
> > This property is, after all, not something that the program should depend on.
> > It is determined by how good the static checker currently is, and we want to be
> > able to improve checkers (and perhaps even allow them to regress slightly in
> > order to simplify them) without changing programs.
>
> Hmmm. I have heard that argument before and I'm conflicted.
>
> I can think of more reasons than just runtime safety for which I'd
> want proofs. Termination for example, in highly critical code;
> not something for which a runtime check will suffice. On the
> other hand the points you raise are good ones, and affect
> the usability of the language.
There doesn't seem to be a point of disagreement here. Programmers
often need to require certain properties to be checked at compile-time.
Others could go either way. There is no property that a program would
rationally desire to *require* be checked at runtime; that would only
occur because the compiler doesn't know how to check it at compile time.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Thu, 13 Jul 2006 10:37:30 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is a type error?
Message-Id: <e950oa$a11al$2@hades.rz.uni-saarland.de>
Marshall wrote:
>
> Okay, sure. But for the problem you describe, both imperativeness
> and the presence of pointers is each necessary but not sufficient;
> it is the two together that causes the problem. So it strikes
> me (again, a very minor point) as inaccurate to describe this as
> a problem with imperative languages per se.
>
> [...]
>
> Right. To me the response to this clear: give up pointers. Imperative
> operations are too useful to give up; indeed they are a requirement
> for certain problems. Pointers on the other hand add nothing except
> efficiency and a lot of confusion. They should be considered an
> implementation technique only, hidden behind some pointerless
> computational model.
Don't get yourself distracted by the low-level notion of "pointer". The
problem *really* is mutability and the associated notion of identity,
which explicit pointers just exhibit on a very low level.
When you have a language with mutable types (e.g. mutable arrays) then
objects of these types have identity, which is observable through
assignment. This is regardless of whether identity is an explicit
concept (like it becomes with pointers and comparison of pointer values,
i.e. addresses).
Consequently, you cannot possibly get rid of aliasing issues without
getting rid of (unrestricted) mutability. Mutability implies object
identity implies aliasing problems.
On the other hand, pointers are totally a futile concept without
mutability: if everything is immutable, it is useless to distinguish
between an object and a pointer to it.
In other words, pointers are essentially just an *aspect* of mutability
in lower-level languages. On a sufficiently high level of abstraction,
it does not make much sense to differentiate between both concepts -
pointers are just mutable objects holding other mutable objects
(immutable pointer types exist, but are only interesting if you also
have pointer arithmetics - which, however, is largely equivalent to
arrays, i.e. not particularly relevant either).
- 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 9460
***************************************
