"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 hasn
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,
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
> e
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
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 go
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
> >>...;
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 speakin
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 .
--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 plante
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 on cheek.]
Bart Lateur wrote:
> On Wed, 23 Aug 2000 17:24:23 -
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 execu
Larry Wall writes:
> Now all we have to do is make the program a variable, and the two
> requirements become one.
Compile the main() program code into a subroutine called 0, and you're
off!
&0 anyone? :-)
(that's digit 0, by analogy to $0)
Nat
> 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: th
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
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
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 = ();
>:
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/) {
>
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/) {
:
>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 "I
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)
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)
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 a
At 06:00 PM 8/21/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: How about this then:
>:
>: In a void context, C 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
>h
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.
Damian Conway wrote:
>
> Tom's opcode dumping functionality could, in principle, be added to
> Data::Dumper as it stands.
>
> My proposal was merely that C<&Data::Dumper::Dumper> body-snatch C.
But that's a crummy name for it, unix legacy not withstanding.
Is someone working on an RFC? IIRC,
> > 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
> : In a void context, C 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
[EMAIL PROTECTED] writes:
: How about this then:
:
: In a void context, C 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 inter
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?
I
> 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
>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 isn
Damian Conway writes:
> If domeone is putting this RFC together, please remember to propose
> that C and C should handle opcodes as well as source:
>
> host-a:foo.pl: dump SOCKET;
>
> host-b:bar.pl: { local $/; eval };
>
> Or:
>
> sub suspend { open $fh, ">$_[0]" or die; d
> Instant program migration:
>
> host-a:foo.pl: print SOCKET dump;
>
> host-b:bar.pl: { local $/; eval };
If domeone is putting this RFC together, please remember to propose
that C and C should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
> In a void context, C dumps the program's current opcode representation
> to its filehandle argument (or STDOUT, by default).
>
> In a scalar or list context, C dumps nothing, but rather returns the
> I of its arguments (or of the current state of the entire
> program, by default).
Instant prog
> > > 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
> 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
> 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 cont
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.
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 DIC
>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 w
>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 #
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])
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 "t
43 matches
Mail list logo
