Tony Olekshy wrote:
Glenn Linderman wrote:
I do recall seeing this quote; however, replacing AUTOLOAD is a very
specific instance of resuming from or retrying a fault condition. And
even though a retry mechanism could be generalized from AUTOLOAD to
handling other conditions, it was
Tony Olekshy wrote:
Glenn Linderman wrote:
Just to point out that fatal is, indeed, as several people keep
saying, truly in the eye of the catcher.
That said, none of the currently proposed mechanisms permit
"resume from fault" semantics, much less "resume from hardware
fault"
"BSOD" = huh? Oh, Blue Screen of Death.
Certainly if the OS doesn't support trapping an error, then the language running on it
cannot either. But if the OS does, then the language could. If the language could,
then the question remains whether it should, and that's a -language topic that
At 06:00 PM 8/21/00 -0700, Larry Wall wrote:
[EMAIL PROTECTED] writes:
: How about this then:
:
: In a void context, Cdump dumps the program's current opcode representation
: to its filehandle argument (or STDOUT, by default).
It's not clear to me that reusing a lame keyword for this is the
Dan Sugalski writes:
: What I've been hoping for is:
:
: 1) The ability to dump the program and its current state out into something
: that can be reloaded later. (Though filehandles and other
: external-interface things make this tricky)
:
: 2) The ability to dump out a variable and all its
2) The ability to dump out a variable and all its attached state into
something that can be loaded in later somewhere else.
To hope to do this completely and correctly is courageous.
my @funx = ();
for my $name (qw/violet purple cream/) {
push @funx, sub {
print
Tom Christiansen writes:
: 2) The ability to dump out a variable and all its attached state into
: something that can be loaded in later somewhere else.
:
: To hope to do this completely and correctly is courageous.
:
: my @funx = ();
: for my $name (qw/violet purple cream/) {
:
Tom Christiansen wrote:
2) The ability to dump out a variable and all its attached state into
something that can be loaded in later somewhere else.
To hope to do this completely and correctly is courageous.
my @funx = ();
for my $name (qw/violet purple cream/) {
push
At 11:32 AM 8/23/00 -0700, Larry Wall wrote:
Tom Christiansen writes:
: 2) The ability to dump out a variable and all its attached state into
: something that can be loaded in later somewhere else.
:
: To hope to do this completely and correctly is courageous.
:
: my @funx = ();
: for my
At 03:47 PM 8/23/00 -0400, David Corbin wrote:
Tom Christiansen wrote:
2) The ability to dump out a variable and all its attached state into
something that can be loaded in later somewhere else.
To hope to do this completely and correctly is courageous.
my @funx = ();
for
On Wed, 23 Aug 2000, Buddha Buck wrote:
Perhaps someone should RFC the new special variable ME, which is
predefined to be the whole program. Who knows? Perhaps it would then make
sense to use @_ at the top level, as if the program was invoked as
"ME(@ARGV);"...
Doesn't a lot of OO work
Doesn't a lot of OO work (esp. on the Mac) tend to do this?
The first thing they do in their application is instantiate an
application (mainly, itself, without the application instantiation) and
run it.
That's right. All "pure" object-oriented languages work this way: the
On Wed, 23 Aug 2000 17:24:23 -0600 (MDT), Nathan Torkington wrote:
Compile the main() program code into a subroutine called 0, and you're
off!
0 anyone? :-)
(that's digit 0, by analogy to $0)
What would be nice about this, is that then you could use "return" in a
script to stop execution.
--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
errors, people that want to write fatal errors can switch to using "warn
...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue
firmly planted
At 02:48 AM 8/24/00 +0200, Markus Peter wrote:
--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
errors, people that want to write fatal errors can switch to using "warn
...; exit ( 250 );" instead of "die ...;"
Dan Sugalski wrote:
Markus Peter wrote:
There is no such thing as an ultimately fatal error - it should
always be up to the user of a module wether the program should
die, but I guess you see that the same and will answer me with
"use eval" then ;-)
I hope you're speaking from a
Dan Sugalski wrote:
At 02:48 AM 8/24/00 +0200, Markus Peter wrote:
--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
errors, people that want to write fatal errors can switch to using "warn
...; exit ( 250
Glenn Linderman wrote:
Just to point out that fatal is, indeed, as several people keep
saying, truly in the eye of the catcher.
That said, none of the currently proposed mechanisms permit
"resume from fault" semantics, much less "resume from hardware
fault" semantics. Sounds like good RFC
Damian Conway wrote:
Tom's opcode dumping functionality could, in principle, be added to
Data::Dumper as it stands.
My proposal was merely that CData::Dumper::Dumper body-snatch Cdump.
But that's a crummy name for it, unix legacy not withstanding.
Is someone working on an RFC? IIRC, it
Tom Christiansen wrote:
Hmm, what about CHECK blocks?
CHECK blocks would be great! But of course, they work in memory,
which is not useful for persisting program state across executions,
or moving it across machines.
--
John Porter
We're building the house of the future together.
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of perl should be removed from the langauge.
Here's a few things that I would venture to say that none of the
"perl5 is my first perl" people have probably ever actually used.
reset # How
I've very rarely found cases where ?? was useful and // didn't work, and
never in regular code.
From the Camel:
The C?? operator is most useful when an ordinary pattern match
would find the last rather than the first occurrence:
open DICT, "/usr/dict/words" or die "Can't open
Tom Christiansen writes:
: I've very rarely found cases where ?? was useful and // didn't work, and
: never in regular code.
:
: From the Camel:
:
: The C?? operator is most useful when an ordinary pattern match
: would find the last rather than the first occurrence:
:
: open
On Mon, 21 Aug 2000 06:11:02 -0600, Tom Christiansen wrote:
$first = $1 if ?(^neur.*)?;
$first ||= $1 if /(^neur.*)/;
Now if only we had a shortcut operator which would continue only if the
LHS was not defined...
--
Bart.
From: Damian Conway [mailto:[EMAIL PROTECTED]]
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what dump was always meant to do.
Instant program migration:
host-a:foo.pl: print SOCKET dump;
host-b:bar.pl: { local $/; eval SOCKET };
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump
Damian Conway writes:
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
host-b:bar.pl: { local $/; eval SOCKET };
Or:
sub suspend { open $fh, "$_[0]" or die;
It would be nice if a human readable dump were possible. So please don't
completely dump the idea of Data::Dumper functionality in the core.
These are different things. And the bytecodes can always be B::Deparse'd, or
whatever we come up with for uncompilation.
Not that proper marshalling
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Hmm, what about CHECK blocks?
--tom
On Mon, Aug 21, 2000 at 03:43:44PM -0600, Tom Christiansen wrote:
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Isn't
: In a void context, Cdump dumps the program's current opcode
: representation to its filehandle argument (or STDOUT, by
: default).
It's not clear to me that reusing a lame keyword for this is the
highest design goal. Let's come up with a real interface, and then if
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Not much :-)
Maybe:
dump "FILE:"
but not just a
On Sat, 5 Aug 2000 09:44:47 -0500, Jonathan Scott Duff wrote:
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of perl should be removed from the langauge.
Here's a few things that I would venture to say that none of the
"perl5 is my first perl" people
On Tue, Aug 08, 2000 at 06:34:19PM -0500, Mike Pastore wrote:
Perl++
perm -- good old hairy perl, finally under control.
Running and ducking,
--Steve
The discussion of a new name for perl6 is amusing but irrelevant.
It's not like this list doesn't get enough traffic already. Thanks for
ceasing and desisting.
Nat
[EMAIL PROTECTED] writes:
: Most of the requests for deletion seem to begin with, "This isn't
: used..."
:
: To which, "*I* use it." is a very valid argument.
:
: Agreed. The real problem with ?...? is that it complicates the hell out
: of the parser. So long as the special
On Tue, 8 Aug 2000 11:25:56 -0500, Jonathan Scott Duff wrote:
Someone proposed (I think I deleted that email) to make
while (FH) { ... }
work like
while (FH) { chomp; ... }
Guilty.
I've benchmarked the above codes, with '...' replaced by nothing, chomp
vs. the -l command
?pattern? # one-time match
Oi! Scott! No!
I use this in one-liners, and it's _dead_ handy. Of course, if it's
modularized as Dan suggests, which has no effect at language level, I
wouldn't be unhappy.
Mx.
--
See, the stars are shining bright
Everything's all right tonight
Martyn J. Pearce sent the following bits through the ether:
I use this in one-liners, and it's _dead_ handy
May I suggest that Perl6 will be a different language? I've seen the
"I use it, don't change it" argument a couple of times now and it's
not a strong enough argument. The whole point is
Leon Brocard [EMAIL PROTECTED] writes:
Martyn J. Pearce sent the following bits through the ether:
I use this in one-liners, and it's _dead_ handy
May I suggest that Perl6 will be a different language? I've seen the
"I use it, don't change it" argument a couple of times now and it's
On Tue, 08 Aug 2000, Leon Brocard wrote:
Martyn J. Pearce sent the following bits through the ether:
I use this in one-liners, and it's _dead_ handy
May I suggest that Perl6 will be a different language? I've seen the
"I use it, don't change it" argument a couple of times now and it's
As long as were culling, might want to consider removing chomp() and
possibly chop(). The language provides other ways to accomplish those thru a
simple regex, and if the "println" suggestion I made was "too specific" then
certainly chomp() is as well.
Just a thought to chomp on..
E
On Tue, Aug 08, 2000 at 03:46:45PM +, Ed Mills wrote:
As long as were culling, might want to consider removing chomp() and
possibly chop(). The language provides other ways to accomplish those thru a
simple regex, and if the "println" suggestion I made was "too specific" then
Thus it was written in the epistle of Jonathan Scott Duff,
Someone proposed (I think I deleted that email) to make
while (FH) { ... }
work like
while (FH) { chomp; ... }
I'm not sure if I'm the someone you meant, but if so, the proposal was to make
while
Bennett Todd wrote:
There are many intents and points to this project. As _I_ see them,
they include, in no particular order:
- cleaning up the language definition, where practical without
losing the distinctive appeal of perl to happy perl programmers;
- cleaning up the
On Tue, Aug 08, 2000 at 01:53:21PM -0400, Ted Ashton wrote:
I'm not sure if I'm the someone you meant, but if so, the proposal was to make
while (chomp(FH)) { ... }
work like
while (FH) { chomp; ... }
Oh. I think I'd prefer to see chomp() go away and be replaced by
Bennett Todd [EMAIL PROTECTED] writes:
The poster you are replying to said "I use this in one-liners, and it's
_dead_ handy."; that conjures up the idioms like
perl -nle 'print if 1.. ?^$?' [filename]
which barfs out only the header; replace "if" with "unless" and it
chops the head
Most of the requests for deletion seem to begin with, "This isn't
used..."
To which, "*I* use it." is a very valid argument.
Agreed. The real problem with ?...? is that it complicates the hell out
of the parser. So long as the special magic is retained for m?...?, I
would
Perl++
:)
On Tue, 8 Aug 2000, Bryan C. Warnock wrote:
On Tue, 08 Aug 2000, Bennett Todd wrote:
If perl6 substantially fails to fill the important roles that perl5
fills, we should stop screwing everybody up by calling it "perl",
and call it something else.
Hmmm. I vote for
Today around 6:55pm, Bryan C. Warnock hammered out this masterpiece:
: chop, chomp, (champ, chimp, chump, chap, and chip, which, respectively,
: deletes all leading and trailing whitespace characters, all leading
: whitespace characters, all trailing whitespace characters, the first
: and last
], "Brust, Corwin" [EMAIL PROTECTED],
[EMAIL PROTECTED], 'Simply Hao' [EMAIL PROTECTED]
Subject: Re: Things to remove
Date: Tue, 8 Aug 2000 13:21:56 -0500
On Tue, Aug 08, 2000 at 01:53:21PM -0400, Ted Ashton wrote:
I'm not sure if I'm the someone you meant, but if so, the proposal wa
On Tue, 08 Aug 2000, Ed Mills wrote:
As long as were culling, might want to consider removing chomp() and
possibly chop(). The language provides other ways to accomplish those thru a
simple regex,
Then we should remove regexs instead. :-)
and if the "println" suggestion I made was "too
On Tue, 08 Aug 2000, Bennett Todd wrote:
If perl6 substantially fails to fill the important roles that perl5
fills, we should stop screwing everybody up by calling it "perl",
and call it something else.
Hmmm. I vote for "Edsel."
--
Bryan C. Warnock
([EMAIL PROTECTED])
Personally, I don't think I've ever used any of these, but I really
don't want to speak for everyone.
Maybe an RFC "Functions and Variables to Remove in Perl 6" ?
-Nate
Jonathan Scott Duff wrote:
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of
Jonathan Scott Duff writes:
: Here in my pre-caffiene morning trance it occurs to me that a few of
: the "fringe" features of perl should be removed from the langauge.
: Here's a few things that I would venture to say that none of the
: "perl5 is my first perl" people have probably ever actually
On Sat, 05 Aug 2000, Nathan Wiger wrote:
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of perl should be removed from the langauge.
Here's a few things that I would venture to say that none of the
"perl5 is my first perl" people have probably
At 09:17 AM 8/5/00 -0700, Larry Wall wrote:
I'm not enamoured of the study interface, but the algorithm is
definitely a win on certain classes of data. The basic problem with
study is that it needs incestuous hooks into how you do string
searching. So even if we moved study out into an external
58 matches
Mail list logo
