Glenn Linderman wrote:
Tony Olekshy wrote:
Hi, it's me again. Not to be a pain, but RFC 88 does say:
Hey, no pain.
retry
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
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 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
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
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 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
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 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
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
At 09:37 AM 8/23/00 -0700, Larry Wall wrote:
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
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
: 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
In a void context, Cdump dumps the program's current opcode representation
to its filehandle argument (or STDOUT, by default).
In a scalar or list context, Cdump dumps nothing, but rather returns the
Isource code of its arguments (or of the current state of the entire
program, by default).
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;
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
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
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
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.
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
[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
highest design goal. Let's come up with a real
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.
I was
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.
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])
30 matches
Mail list logo
