[27999] in Perl-Users-Digest
Perl-Users Digest, Issue: 9363 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 23 21:05:45 2006
Date: Fri, 23 Jun 2006 18:05:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 23 Jun 2006 Volume: 10 Number: 9363
Today's topics:
Re: Hash of Arrays <tadmc@augustmail.com>
Re: Help - Inline::C arrayref deref? (Anno Siegel)
Re: Help Required !!!! <tadmc@augustmail.com>
Re: Help with worthy project ? <tadmc@augustmail.com>
Re: LWP::MediaTypes <benmorrow@tiscali.co.uk>
Re: Online Graphing Calculator - Perl Backend robby.walker@gmail.com
Re: passing an array to another program <benmorrow@tiscali.co.uk>
Re: Running another program in daemon server <tadmc@augustmail.com>
Re: Running another program in daemon server <benmorrow@tiscali.co.uk>
Re: Saying "latently-typed language" is making a catego <cdsmith@twu.net>
Travails of the JVM type system (was: What is Expressiv <david.nospam.hopwood@blueyonder.co.uk>
Re: use binary operator on ascii text string <David.Squire@no.spam.from.here.au>
Re: What is a type error? <david.nospam.hopwood@blueyonder.co.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 23 Jun 2006 16:53:21 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Hash of Arrays
Message-Id: <slrne9oomh.93f.tadmc@magna.augustmail.com>
John W. Krahn <someone@example.com> wrote:
> Deepu wrote:
>> %hash = (
>> FILE1 => ["STATEMAIN", "STATESUSPEND", "STATE1",
>> "STATE2", "STATERESUME", "RESET"],
>> FILE1 => ["STATEMAIN", "STATE9", "STATE10"],
>
> In Perl a hash cannot have two different keys with the same name.
Can a hash have two different keys with the same name somewhere
besides in Perl?
How do you distinguish between the two?
How does the hashing differ?
Should I take this off-topic question elsewhere? :-)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 23 Jun 2006 23:09:25 GMT
From: anno4000@radom.UUCP (Anno Siegel)
Subject: Re: Help - Inline::C arrayref deref?
Message-Id: <4g3al5F1krselU1@news.dfncis.de>
<xhoster@gmail.com> wrote in comp.lang.perl.misc:
>"Sisyphus" <sisyphus1@nomail.afraid.org> wrote:
>> I really don't know whether it's correct to be providing an AV* as the
>> argument to sv_2mortal(). There's no denying that it fixes the memory
>> leak problem, but it also produces the following warnings during the
>> compilation phase:
>
>If you cast the AV* to an SV* first, the warning goes away.
>
>sv_2mortal((SV*) av_ret);
>
>Of course, the lack of warning still doesn't prove that it is proper. I
>haven't found any examples of this in the docs, but there are plenty of
>analogs to it:
> SV* newRV_inc((SV*) thing);
> SV* newRV_noinc((SV*) thing);
It's okay. I don't know about documentation, but the perl source has
examples,
pad.c: *out_capture = sv_2mortal((SV*)newAV());
pad.c: *out_capture = sv_2mortal((SV*)newHV());
for two.
However, the code (now snipped) didn't need the newAV() at all, as far
as I can see.
Anno
Anno
------------------------------
Date: Fri, 23 Jun 2006 17:06:27 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Help Required !!!!
Message-Id: <slrne9opf3.93f.tadmc@magna.augustmail.com>
vandana <vandana@sadhanasoft.com> wrote:
> Subject: Help Required !!!!
You will get more people to help if you compose a meaningful
Subject line.
Every post here requires help. Do you think that question-answerers
read every post? They don't. They read the ones with interesting
subjects, which your's isn't.
Please see the Posting Guidelines that are posted here frequently.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 23 Jun 2006 16:45:27 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Help with worthy project ?
Message-Id: <slrne9oo7n.93f.tadmc@magna.augustmail.com>
GHBoom <hooper1@optonline.net> wrote:
>
>>
>> I suggest the first thing you do is to compile your code with warnings enabled
>> and fix all the warnings that appear (I got 17 when I did it.) And after that
>> compile your code with warnings *AND* strict enabled and when it finally
>> compiles without producing any messages from warnings and strict then you may
>> find people taking your request more seriously.
[ snip .sig, quoting .sigs is bad netiquette you know. ]
> John
Please put a proper attribution up at the top like everybody else does.
Displaying multiple points of poor netiquette will not inspire
net-savvy folks to take you seriously.
> Thanks for the suggestions, but whether to take this seriously
> or not should have nothing to do with what i wrote now. Im not a full
> time programer,
But the people you are trying to attract *are* programmers, so
being mindful of what they think is essential to attracting them.
Code that is not warnings and strict clean will not be taken
seriously by the type of people you need to reach.
> This is the reason why im looking for help in the first place....
You have about a 0.1% chance of getting that help as things
stand currently.
You'd increase your chances at least a hundredfold if it was
warnings/strict clean. You decide. :-)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 23 Jun 2006 20:05:23 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: LWP::MediaTypes
Message-Id: <jkqtm3-02k.ln1@osiris.mauzo.dyndns.org>
Quoth "spp" <sonalibhave@gmail.com>:
> hello ,
>
> I am using LWP::MeidaTypes package to get the mediatype. If it doesnt
> recognize the type it returns media type as: application/octet-stream.
> I am using its add_type function to add some extentions like bmp, php
> etc. but its add_type doesnt seem to be working.
> or may be I am doing something wrong.
>
> My code :
>
> use LWP::MediaTypes qw(add_type guess_media_type);
>
> add_type("text/special")=>qw(shtml php htm);
>
> add_type("image/special")=>qw(bmp png jpeg);
>
>
> my $type = guess_media_type("http://www.cnn.com/abc.php" );
> print "media type is". $type;
>
> #
> if i run this it prints media type is application/octet-stream
>
> can anyone please tell me what am I doing wrong?
URIs should be given as a ref to a URI object. This is not entirely
clear from the documentation.
Ben
--
"If a book is worth reading when you are six, * benmorrow@tiscali.co.uk
it is worth reading when you are sixty." [C.S.Lewis]
------------------------------
Date: 23 Jun 2006 16:37:57 -0700
From: robby.walker@gmail.com
Subject: Re: Online Graphing Calculator - Perl Backend
Message-Id: <1151105877.130274.244250@u72g2000cwu.googlegroups.com>
Hi - first - I fixed the negation bug although it's still not perfect -
the precedence is a little bit off still.
Regarding selling, GPL, etc. - it's being released as a free service
online but it is not being open sourced or sold. The company I work
at, e-Tutor (http://www.e-tutor.com), is a K-12 online school and
tutoring program. This is something we needed for our students and we
wanted to share it.
Enjoy!
- Robby
Andrew wrote:
> robby.walker@gmail.com wrote:
> > Hi,
> >
> > I've just released a full-featured online graphing calculator at
> > http://www.e-tutor.com/et2/graphing/ - the back end is built with
> > (mod_)Perl and GD.
> >
> > It requires no downloads or plugins - just JavaScript. You can track
> > points on the curve, graph multiple functions, and more. I'm also
> > interested in hearing people's feature requests.
> >
> > If you really like it, please consider digging it:
> >
> > http://digg.com/software/Online_Graphing_Calculator_2
> >
> > or voting for it on reddit.com
>
> Is this under GPL / open source? I couldn't find the licensing info.
> are you selling this software or services related thereto?
>
> andrew
------------------------------
Date: Fri, 23 Jun 2006 23:28:28 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: passing an array to another program
Message-Id: <ch6um3-mal.ln1@osiris.mauzo.dyndns.org>
Quoth guser@packetstorm.org:
> I have a scheduler program that hands off tasks to a tasking program
> like this
>
> my $retval = `tasker.pl @tasks`;
>
> where the tasks are built like this
>
> push (@tasks,"/program.pl --var=$val");
>
> the tasker program gets the data but ARGV breaks up the task strings
> into pieces
> (@ARGV)
> /program.pl [0]
> --var=var1 [1]
> /program.pl [2]
> --var=var2 [3]
>
> Where I need the data to be recieved like I passed it
> (@ARGV)
> /program.pl --var=var1 [0]
> /program.pl --var=var2 [1]
>
> Is there a way to force sending a series of strings (with spaces in in
> the string) in array format to another program so that the destination
> program can recieve each string intact without being split when
> accessing ARGV?
Do
open my $PIPE, '-|', 'program.pl', @tasks;
and then read all of the pipe.
Ben
--
Although few may originate a policy, we are all able to judge it.
Pericles of Athens, c.430 B.C.
benmorrow@tiscali.co.uk
------------------------------
Date: Fri, 23 Jun 2006 16:58:04 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Running another program in daemon server
Message-Id: <slrne9oovc.93f.tadmc@magna.augustmail.com>
Ted Zlatanov <tzz@lifelogs.com> wrote:
> Generally specify paths for system() with '/' instead of '\' and life
> will be easier and more portable.
But only for the more-than-1-arg form of system().
You cannot use forward slashes with 1-arg system() on
silly "operating systems". (I think.)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 23 Jun 2006 23:32:21 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Running another program in daemon server
Message-Id: <lo6um3-mal.ln1@osiris.mauzo.dyndns.org>
Quoth tadmc@augustmail.com:
> Ted Zlatanov <tzz@lifelogs.com> wrote:
>
> > Generally specify paths for system() with '/' instead of '\' and life
> > will be easier and more portable.
>
> But only for the more-than-1-arg form of system().
>
> You cannot use forward slashes with 1-arg system() on
> silly "operating systems". (I think.)
...unless you change your shell. :)
Ben
--
'Deserve [death]? I daresay he did. Many live that deserve death. And some die
that deserve life. Can you give it to them? Then do not be too eager to deal
out death in judgement. For even the very wise cannot see all ends.'
benmorrow@tiscali.co.uk
------------------------------
Date: Fri, 23 Jun 2006 18:01:28 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: Saying "latently-typed language" is making a category mistake
Message-Id: <MPG.1f062ebf181df5bf9896f0@news.altopia.net>
Chris Uppal wrote:
> > I'd be more careful in the analogy, there. Since type theory (as
> > applied to programming languages, anyway) is really just a set of
> > methods of proving arbitrary statements about program behaviors,
>
> Not "arbitrary" -- there is only a specific class of statements that any given
> type system can address. And, even if a given statement can be proved, then it
> might not be something that most people would want to call a statement of type
> (e.g. x > y).
[My understanding is that we're discussing static types and type theory
here. If you mean dynamic types, then what I'm about to say won't
apply.]
I acknowledge that there are things that type systems are not going to
be capable of proving. These are not excluded a priori from the set of
problems that would count as type errors if the language's type system
caught them. They are merely excluded for pragmatic reasons from the
set of errors that someone would be likely to write a type system to
check. That is the case simply because there is a decided disadvantage
in having a compiler that isn't guaranteed to ever finish compiling your
program, or that doesn't finish in polynomial time on some
representative quantity in nearly all cases, etc.
On the other hand, statements about program behavior that can be proved
in reasonable time frames are universally valid subjects for type
systems. If they don't look like type errors now, they nevertheless
will when the type system is completed to demonstrate them. If someone
were to write a language in which is could be statically proved that a
pair of expressions has the property that when each is evaluated to
their respective values x and y, (x > y) will be true, then proving this
would be a valid subject of type theory. We would then define that
property as a type, whose values are all pairs that have the property
(or, I suppose, a nominal type whose values are constrained to be pairs
that have this property, though that would get painful very quickly),
and then checking this property when that type is required -- such as
when I am passing (x - y) as a parameter to a function that requires a
positive integer -- would be called type checking.
In fact, we've come full circle. The intial point on which I disagreed
with Torben, while it was couched in a terminological dispute, was
whether there existed a (strict) subset of programming errors that are
defined to be type errors. Torben defined the relationship between
static and dynamic types in terms of when they solved "type errors",
implying that this set is the same between the two. A lot of the
questions I'm asking elsewhere in this thread are chosen to help me
understand whether such a set truly exists for the dynamic type world;
but I believe I know enough that I can absolutely deny its existence
within the realm of type theory. I believe that even Pierce's phrase
"for proving the absence of certain program behaviors" in his definition
of a type system only excludes possible proofs that are not interesting
for determining correctness, if in fact it limits the possible scope of
type systems at all.
However, your definition of type errors may be relevant for
understanding concepts of dynamic types. I had understood you to say
earlier that you thought something could validly qualify as a dynamic
type system without regard for the type of problem that it verifies
(that was denoted by "something" in a previous conversation). I suppose
I was misinterpreting you.
So your definition was:
> It seems to me that most (all ? by definition ??) kinds of reasoning where we
> want to invoke the word "type" tend to have a form where we reduce values (and
> other things we want to reason about) to equivalence classes[*] w.r.t the
> judgements we wish to make, and (usually) enrich that structure with
> more-or-less stereotypical rules about which classes are substitutable for
> which other ones. So that once we know what "type" something is, we can
> short-circuit a load of reasoning based on the language semantics, by
> translating into type-land where we already have a much simpler calculus to
> guide us to the same answer.
>
> (Or representative symbols, or... The point is just that we throw away the
> details which don't affect the judgements.)
I don't even know where I'd start in considering the forms of reasoning
that are used in proving things. Hmm. I'll have to ponder this for a
while.
> I think that, just as for static theorem proving, there is informal reasoning
> that fits the "type" label, and informal reasoning that doesn't.
So while I disagree in the static case, it seems likely that this is
true of what is meant by dynamic types, at least by most people in this
discussion. I'd previously classified you as not agreeing.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Sat, 24 Jun 2006 00:50:10 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Travails of the JVM type system (was: What is Expressiveness in a Computer Language)
Message-Id: <6%%mg.458332$tc.115682@fe2.news.blueyonder.co.uk>
Chris Uppal wrote:
> Maybe you are thinking that I mean that /because/ the JVM does verification,
> etc, at "runtime" the system is hybrid ?
>
> Anyway that is /not/ what I mean. I'm (for these purposes) completely
> uninterested in the static checking done by the Java to bytecode translator,
> javac. I'm interested in what happens to the high-level, statically typed, OO,
> language called "java bytecode" when the JVM sees it. That language has a
> strict static type system which the JVM is required to check. That's a
> /static/ check in my book -- it happens before the purportedly correct code is
> accepted, rather than while that code is running.
>
> I am also completely uninterested (for these immediate purposes) in the run
> time checking that the JVM does (the stuff that results in
> NoSuchMethodException, and the like). In the wider context of the thread, I do
> want to call that kind of thing (dynamic) type checking -- but those checks are
> not why I call the JVMs type system hybrid either.
>
> Oh well, having got that far, I may as well take another stab at "hybrid".
> Since the JVM is running a static type system without access to the whole text
> of the program, there are some things that it is expected to check which it
> can't. So it records preconditions on classes which might subsequently be
> loaded.
It does, but interestingly, it wasn't originally intended to. It was intended
to be possible to check each classfile based only on that class' explicit
dependencies, without having to record constraints on the loading of future
classes.
However, the designers made various mistakes with the design of ClassLoaders
which resulted in the original JVM type system being unsound, and hence insecure.
The problem is described in
<http://www.cis.upenn.edu/~bcpierce/courses/629/papers/Saraswat-javabug.html>
(which spells my name wrong, I just noticed).
The constraint-based approach, proposed by Liang and Bracha in
<http://www.cs.purdue.edu/homes/jv/smc/pubs/liang-oopsla98.pdf>, was adopted
in order to fix this. There were other, simpler, solutions (for example,
restricting ClassLoader delegation to a strict tree structure), but the
responsible people at Sun felt that they were insufficiently expressive.
I thought, and still think, that they were mistaken. It is important for the
type system to be no more complicated than necessary if there is to be any
confidence in the security of implementations.
In any case, as shown by
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071>, current JVM
implementations do *not* reliably support the patterns of ClassLoader delegation
that were intended to be enabled by Liang and Bracha's approach.
[This "bug" (it should be classed as an RFE) is, inexplicably given how few
programs are affected by it, the most voted-for bug in Sun's tracking system.
I get the impression that most of the commentators don't understand how
horribly complicated it would be to fix. Anyway, it hasn't been fixed for
4 years.]
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Sat, 24 Jun 2006 00:20:12 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: use binary operator on ascii text string
Message-Id: <e7hsvc$67a$1@news.ox.ac.uk>
David Squire wrote:
> David Squire wrote:
>> Sean.Dewis@gmail.com wrote:
>>> Hi everyone
>>>
>>> I'm pretty crap at perl, so I'd appreciate so help from you guys.
>>>
>>> I have a string value held in $body variable.
>>>
>>> What I need to do is manipulate each individual character value in the
>>> string with OR - "|" and then replace that character with the
>>> character's new value.
>>>
>>> I'm using chr(ord($c) | 64) to get the new value, but I'm stuck on two
>>> things: -
>>>
>>> 1) How to go through the string byte by byte and perform the OR 64 on
>>> it
>>> 2) How to get the character equivalent back into the string in the
>>> right place
>
> [snip]
>
>> Here's some code that does what I think you want, but as I have
>> described above, that is not actually that clear. I bet that there are
>> nicer ways to do this too, which others will most likely soon point
>> out :)
>
> [snip]
>
> ... such as this, which explicitly deals with bytes, rather than hoping
> that that is what characters are in the default encoding:
>
> ----
>
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> while (my $line = <DATA>) {
> chomp $line;
> my @line_array = unpack 'C*', $line;
> my @new_line_array = map {$_ | 64} @line_array;
> my $new_line = pack 'C*', @new_line_array;
> print "$new_line\n";
> }
>
> ----
Well, I might as well give the last (?) in the series, following Mumia's
suggestion:
----
#!/usr/bin/perl
use strict;
use warnings;
my $mask = 64;
while (<DATA>) {
s/(.)/chr(ord($1) | $mask)/eg;
print;
}
__DATA__
abcdefg
1234567687568
%^&*^*()&^)&^
----
Output:
abcdefg
qrstuvwvxwuvx
e^fj^jhif^if^
... though I still prefer the explicit byte-wise one above.
Cheers,
DS
------------------------------
Date: Sat, 24 Jun 2006 00:56:12 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is a type error?
Message-Id: <M40ng.475401$xt.231558@fe3.news.blueyonder.co.uk>
Pascal Costanza wrote:
> Chris Smith wrote:
>
>> While this effort to salvage the term "type error" in dynamic
>> languages is interesting, I fear it will fail. Either we'll all have
>> to admit that "type" in the dynamic sense is a psychological concept
>> with no precise technical definition (as was at least hinted by
>> Anton's post earlier, whether intentionally or not) or someone is
>> going to have to propose a technical meaning that makes sense,
>> independently of what is meant by "type" in a static system.
>
> What about this: You get a type error when the program attempts to
> invoke an operation on values that are not appropriate for this operation.
>
> Examples: adding numbers to strings; determining the string-length of a
> number; applying a function on the wrong number of parameters; applying
> a non-function; accessing an array with out-of-bound indexes; etc.
This makes essentially all run-time errors (including assertion failures,
etc.) "type errors". It is neither consistent with, nor any improvement
on, the existing vaguely defined usage.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
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 9363
***************************************
