"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:
> >
> > 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 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" peopl
On Tue, 8 Aug 2000 11:25:56 -0500, Jonathan Scott Duff wrote:
>Someone proposed (I think I deleted that email) to make
>
> while () { ... }
>
>work like
>
> while () { chomp; ... }
Guilty.
I've benchmarked the above codes, with '...' replaced by nothing, chomp
vs. the -l command
[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
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
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
On Tue, 08 Aug 2000, Casey R. Tweten wrote:
> 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 t
t;To: Ed Mills <[EMAIL PROTECTED]>, "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 wr
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 ch
Today around 6:34pm, Mike Pastore hammered out this masterpiece:
: Perl++
PERL
[Casey ducks and runs for cover ;]
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$
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 fo
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
> 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 su
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
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()) { ... }
>
> work like
>
> while () { chomp; ... }
Oh. I think I'd prefer to see chomp() go away and be replaced by
s
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 imple
2000-08-08-04:42:00 Leon Brocard:
> 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?
If perl6 substantially fails to fill the important roles that perl5
fills, we should stop
Thus it was written in the epistle of Jonathan Scott Duff,
>
> Someone proposed (I think I deleted that email) to make
>
> while () { ... }
>
> work like
>
> while () { chomp; ... }
I'm not sure if I'm the someone you meant, but if so, the proposal was to make
while (c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] 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" the
On Tue, Aug 08, 2000 at 11:12:40AM -0500, Brust, Corwin wrote:
> From: Simply Hao [mailto:[EMAIL PROTECTED]]
>
> >> might want to consider removing chomp() and possibly chop().
> >
> >They're faster than regexes, right?
>
>
> Dunno about faster but so sweet.
>
> I like
>
> while (
From: Simply Hao [mailto:[EMAIL PROTECTED]]
>> might want to consider removing chomp() and possibly chop().
>
>They're faster than regexes, right?
Dunno about faster but so sweet.
I like
while (<>) { print chomp }
better then
while (<>{
s/$/$//;
p
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
> certa
> might want to consider removing chomp() and possibly chop().
They're faster than regexes, right?
-Hao
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
___
Thus it was written in the epistle of Leon Brocard,
> 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?
Actually, I think the point is that Perl6 won't be a different lang
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 i
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
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
> ?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
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 exter
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 pr
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 u
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 o
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
73 matches
Mail list logo
