Re: This week's summary
Piers Cawley [EMAIL PROTECTED] wrote: More CPS shenanigans I get the strong feeling that Leo Tötsch isn't entirely happy with the new Continuation Passing Style regime. No, I'm really happy with CPS. Restoring the whole context by invoke'ing the return continuation is a very elegant and efficient way to do it, not speaking from tail calls ... He's worried that the P6C tests break, ... albeit this is still an issue. Nobody answered, if we need another Sub class implementing the old invoke/ret scheme ... ... and that CPS subs are some 3 times slower for calling the sub. ... while this is solved. Jonathans patch that went in originally had this bad performance. But with separating the Sub/Continuation setup from the actual subroutine call (which amongst other things my patches did), performance is back again at the old level. In fact the current CPS implementation is faster then the old invoke/ret scheme. I estimate the final speed, when all needed context things are saved, to be about the same as invoke/ret w/o much context saving. Whee! My first anniversary! Congrats and thanks for your great summaries. leo
Re: [perl #22767] IMCC/Parrot leak and eventual segfault (partially solved)
Clinton A. Pierce [EMAIL PROTECTED] wrote: Found the bug. Mostly MEA CULPA. A thousand pardons to the good Parrot folk. When calling a sub like this: .arg 0 call _foo It's probably a good thing to take the 0 off the stack at some point. Thanks again for your bug report and thorough checking all kind of parrot limits. I've added a check for too deeply nested stacks now. Your first test program now bails out at: 25342 Stack 'User' too deep The limit is currently fixed at 100 chunks, but could easily be changed with a new opcode, e.g. stack_limit .Stack, limit. The stack_height() call could also be optimized then as well as other code pieces which are walking the stack from the base. leo
[perl #22762] [PATCH] perl 5.005's mkdir required the 'mask' argument
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #22762]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22762
This patch is necessary to get parrot to build with perl 5.00503 -- the
mode argument to mkdir() wasn't optional back then. I'd apply it
myself, but cvs doesn't seem to like me today, and I'm tired of
fighting it. (My login apparently succeeds, but the commit fails
claiming I don't have 'write' privs.)
--- parrot-current/config/gen/makefiles/root.in Fri May 30 11:00:09 2003
+++ parrot-andy/config/gen/makefiles/root.inWed Jun 11 15:26:29 2003
@@ -150,7 +150,7 @@
PERL = ${perl}
# Make directory; do not die if dir exists.
-MKDIR = $(PERL) -e ${PQ}-d or mkdir $$_ or die foreach @ARGV${PQ}
+MKDIR = $(PERL) -e ${PQ}-d or mkdir $$_,0777 or die foreach @ARGV${PQ}
###
--
Andy Dougherty [EMAIL PROTECTED]
[perl #22765] Unary '+' is not symmetric to unary '-' in languages/perl6
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #22765] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22765 Hi, when playing with the stuff in 'languages/perl6', I noticed that code like print( +42, \n ); didn't do the right thing. 'perl6' printed '42' but forgot about the \n. The cause seemed to me that '+' isn't set up as an unary operator in 'P6C/Parser.pm'. After adding '+' in 'Parser.pm' and in a couple of othe files, it now seems to behave as expected. On my Linux machine there are some other tests failing in t/compiler, but these seem not to be related to unary '+'. One of these failures is a 'inf' vs. 'Inf' issue. A patch is attached. CU, Bernhard -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! -- attachment 1 -- url: http://rt.perl.org/rt2/attach/59761/44242/d4c34a/prefix_pos.patch prefix_pos.patch Description: prefix_pos.patch
Re: [ANNOUNCE] Test::Warn::None 0.02
On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote: I'm looking for comment or suggestions about this new module. It's independent of and complementary to Test::Warn. It tests that your test script didn't emit any warnings. Just add use Test::More::None; to the top your test script, update your plan (if you've got one) and that's it. You'll get an extra test, executed after your script ends checking whether there were any warnings. If there were you'll get a full run down of them including a stack trace. Good idea. Too bad about the plan calculation hackery necesssary. :( -- Me? A robot? That's rediculous! For one thing, that doesn't compute at all!
Re: [ANNOUNCE] Test::Warn::None 0.02
-BEGIN PGP SIGNED MESSAGE- Moin, On 23-Jun-03 Michael G Schwern carved into stone: On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote: I'm looking for comment or suggestions about this new module. It's independent of and complementary to Test::Warn. It tests that your test script didn't emit any warnings. Just add use Test::More::None; to the top your test script, update your plan (if you've got one) and that's it. You'll get an extra test, executed after your script ends checking whether there were any warnings. If there were you'll get a full run down of them including a stack trace. Good idea. Too bad about the plan calculation hackery necesssary. :( hat class=devel Can't nowarings() call Test::More::plan_add(1) or something like this? /hat Cheers, Tels - -- Signed on Tue Jun 24 10:43:41 2003 with http://bloodgate.com/tels.asc perl -MDev::Bollocks -le'print Dev::Bollocks-rand()' widespreadedly supply compelling partnerships http://www.notcpa.org/ You have the freedom to run any code. Yet. http://bloodgate.com/perl My current Perl projects -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPvgPRXcLPEOTuEwVAQGjZwf9FOP5nCLq0biUbPAuoDst+KN/O5v8NaiD NNWp4Frp3cYiJ0WQDyRAuse9Slc0rLX9h0rxJCj1e8mKanO+Ey8lCUJJt4qG9C+5 hOacRQZ6eSh0Unb1WCAQAMXaMozC3kxgVZ/ArVRMG8Wqz843anaC0doDOHarK/BI he/gU0D+bPzycd7VwdxxTvmJSkvWfuPlhj4AvqCUXh/k/eBX44noa1PYTQgj6yKz nvba4OhadDe6bBLzeX3c/nrsgvCnF5Mh80mhQp9BS0oLm4yAa8jMliqI5/Y3nk88 d1nqoLtiJ6bBNiQmSz63q44GrOD/v5DfoR6bS4uNhqKaUbNmDrRYzQ== =KSIZ -END PGP SIGNATURE-
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 10:59:43AM +0200, Tels wrote: On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote: I'm looking for comment or suggestions about this new module. It's independent of and complementary to Test::Warn. It tests that your test script didn't emit any warnings. Just add use Test::More::None; Typo? to the top your test script, update your plan (if you've got one) and that's it. You'll get an extra test, executed after your script ends checking whether there were any warnings. If there were you'll get a full run down of them including a stack trace. Good idea. Too bad about the plan calculation hackery necesssary. :( hat class=devel Can't nowarings() call Test::More::plan_add(1) or something like this? /hat Consider the following. use Test::More; use Test::Warn::None; plan tests = 42; To make this work I'd have to overhaul the internal Test::Builder planning system to allow Test::Warn::None to say I'm going to add an extra test, please remember this fact. I can be convinced its worth it. -- Life is like a sewer. What you get out of it depends on what you put into it. - Tom Lehrer
Re: [ANNOUNCE] Test::Warn::None 0.02
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 24-Jun-03 Michael G Schwern carved into stone:
On Tue, Jun 24, 2003 at 10:59:43AM +0200, Tels wrote:
On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote:
Good idea. Too bad about the plan calculation hackery necesssary. :(
hat class=devel
Can't nowarings() call Test::More::plan_add(1) or something like this?
/hat
Consider the following.
use Test::More;
use Test::Warn::None;
plan tests = 42;
To make this work I'd have to overhaul the internal Test::Builder
planning system to allow Test::Warn::None to say I'm going to add an
extra test, please remember this fact. I can be convinced its worth it.
IIUC, we have:
# manual way
use Test::More;
use Test::Warn::None;
BEGIN
{
plan = tests 1 + 1; # one extra for no warnings
}
ok ()
no_warnings();
and:
# automatic way (not yet)
use Test::More;
use Test::Warn::None;
BEGIN
{
plan tests = 1;
}
ok (...);
no_warnings();
Neither the manual way nor the automatic way can be fooled, except that
you remove the use Test::Warn::None line. (Either way would
screem if the no_warnings() would no longer be called). So as a vivid plan
user, I would be for the way that requires less typing.
Actually, I can see that Test::Warn::None could make the no_warnings() line
obsolete by calling this automatically in an END block. So:
# fully automatic way, washes your socks and makes coffee
use Test::More;
use Test::Warn::None;
BEGIN { plan tests = 1; }
ok (...);
(use Test::Warn::None qw/auto/ or something might also work if you
don't want to change the interface)
As to the overhaul: wouldn't one extra variable with the extra tests do
plan for be enough? Sorry, I probably assume to much simplicity behind
the scenes :)
I would like this, because I plan to use Test::Warn on more than one 20+
test-scripts testsuite, and I could even see how this could be added to the
core which has even more scripts :)
Best wishes,
Tefeels bad for just wanting more features without any contributionls
- --
Signed on Tue Jun 24 12:36:15 2003 with http://bloodgate.com/tels.asc
perl -MDev::Bollocks -le'print Dev::Bollocks-rand()'
continuously deploy efficient functionalities
http://www.notcpa.org/ You have the freedom to run any code. Yet.
http://bloodgate.com/perl My current Perl projects
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPvgppncLPEOTuEwVAQF0oQf+OfU+k7Z3Rv02khEObEo+W/LMQgNpkmPS
TpigCsLOy8Mnk1y4wRY+iGqKyydXvAI8MtmFnYl+90L4xi3R/uifDz5rwhoxoXJk
e8Xx8ZXU9koijK4hCHZgQ2YBE9rt8qmfSo/elEbLBxT929NNyZeaKhw9tpHbAnNq
NKTIYAmv0nfJMhLdJofXXOgHvUmbkzuE4L5B5hCoC1Ej1hLdTcTc8hzJoOjKX41y
3ST8rBAZi/bzgeG4EnSS2maDiRdt5hvNd6g29XDoo9XujjplQjYEuuMi2nzanxj9
MuI3mXg8qE+pHJjqO/WSbnMqQl9LDxkpYkbIlDlHHMUyQHP8okavzQ==
=MU0t
-END PGP SIGNATURE-
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 11:37, Tels wrote: Actually, I can see that Test::Warn::None could make the no_warnings() line obsolete by calling this automatically in an END block. So: It IS obsolete. I DOES call it from an END block ;-) F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 11:22, Michael G Schwern wrote: use Test::More::None; Typo? Yeso. hat class=devel Can't nowarings() call Test::More::plan_add(1) or something like this? /hat Consider the following. use Test::More; use Test::Warn::None; plan tests = 42; To make this work I'd have to overhaul the internal Test::Builder planning system to allow Test::Warn::None to say I'm going to add an extra test, please remember this fact. I can be convinced its worth it. It seems like a good idea to me. Are there any other modules that would use it? F
Re: [ANNOUNCE] Test::Warn::None 0.02
-BEGIN PGP SIGNED MESSAGE- Moin, On 24-Jun-03 Fergal Daly carved into stone: On Tuesday 24 June 2003 11:37, Tels wrote: Actually, I can see that Test::Warn::None could make the no_warnings() line obsolete by calling this automatically in an END block. So: It IS obsolete. I DOES call it from an END block ;-) Uh - *hides in a corner for the rest of the day* Cheers, Tels - -- Signed on Tue Jun 24 13:04:19 2003 with http://bloodgate.com/tels.asc perl -MDev::Bollocks -le'print Dev::Bollocks-rand()' conveniently industrialize bleeding-edge technologies http://www.notcpa.org/ You have the freedom to run any code. Yet. http://bloodgate.com/perl My current Perl projects -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPvgwM3cLPEOTuEwVAQGMbgf7BHTxc7QXaLJYcSCWRtjtaxPWKH081Kmn +fqa2VavcIWzN5taXXsn0I2113eAfvMCxDu6UNtNv9UX6mXePUgQFO4+zI3Q4l4P eO6JOLXzOUJUpDhkZlXSepHaTnnYIC5bhBBaRsGlUvjb4iqgONUEm82f1milNWVQ mVle2ykJxZSMZ2wX24XNWib/do0sNwuu1sxdqp2ksYAvrMkhzgpz4NhWfaqG1PKk RXkKr9G/6gxQPEi61QpcACoQQkNgS1YzSV7+ispmBq2XBRRceLoQU80VuLHYfdf2 LGzeGAXMXUuPPnCMhErFFJzL7Sv/87uOMJRAdfovP5Nf1uDVAFH9Og== =3c/i -END PGP SIGNATURE-
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 12:04, Tels wrote: It IS obsolete. I DOES call it from an END block ;-) Uh - *hides in a corner for the rest of the day* It happens to the best of us. I've updated the docs to make this more clear. Also how about calling it Test::Warn::Auto? I'm not particularly happy with None, F
Re: [ANNOUNCE] Test::Warn::None 0.02
Fergal Daly wrote: Also how about calling it Test::Warn::Auto? I'm not particularly happy with None, +1 for ::Auto. BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. (Avoiding to span perl interpreters at each test would be a bonus.)
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 12:36, Rafael Garcia-Suarez wrote: +1 for ::Auto. BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. (Avoiding to span perl interpreters at each test would be a bonus.) I think Test::Warn is what you want although I haven't really explored it, F
Re: [perl #22765] Unary '+' is not symmetric to unary '-' in languages/perl6
Looks good, except that this needs to make sure an int is being
returned, e.g.
+42- 42
+forty-two - 0
The lazy man in me would just shove it through an int reg, but that
loses precision if we go to bignums. Though for the moment I can't
think of a better way.
/s
+# unary plus.
+sub prefix_pos {
+my $x = shift;
+my $tmp = $x-args-val;
+my $res = newtmp;
+code(END);
+ $res = $tmp
+END
+return scalar_in_context($res, $x-{ctx});
+}
On Mon, 23 Jun 2003, Bernhard Schmalhofer wrote:
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #22765]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22765
Hi,
when playing with the stuff in 'languages/perl6', I noticed that code like
print( +42, \n );
didn't do the right thing. 'perl6' printed '42' but forgot about the \n.
The cause seemed to me that '+' isn't set up as an unary operator in
'P6C/Parser.pm'.
After adding '+' in 'Parser.pm' and in a couple of othe files, it now seems
to behave as expected.
On my Linux machine there are some other tests failing in t/compiler, but
these seem not to be related to unary '+'.
One of these failures is a 'inf' vs. 'Inf' issue.
A patch is attached.
CU, Bernhard
--
+++ GMX - Mail, Messaging more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/59761/44242/d4c34a/prefix_pos.patch
Re: This week's summary
On Tue, 24 Jun 2003, Leopold Toetsch wrote: Piers Cawley [EMAIL PROTECTED] wrote: He's worried that the P6C tests break, ... albeit this is still an issue. Nobody answered, if we need another Sub class implementing the old invoke/ret scheme ... I'd say no. P6C is now compiling to an obsolete architecture. While we should all step back and be impressed at how well Intel has maintained backward compatibility in the x86, there's no particular reason we should do so ourselves. Rather, someone (me) needs to port P6C to the new machine. Whee! My first anniversary! Congrats and thanks for your great summaries. Seconded. /s
Re: This week's summary
Sean O'Rourke [EMAIL PROTECTED] wrote: ... Rather, someone (me) needs to port P6C to the new machine. Which is currently not quite possible. Someone (me;-) has to implement imcc/docs/calling_conventions first - adopted for CPS. I'd rather not have the HL spit out all registers according to pdd03. Also the register allocator needs rework due to the CPS scheme. /s leo
Re: This week's summary
On Tue, Jun 24, 2003 at 06:14:52AM -0700, Sean O'Rourke wrote: On Tue, 24 Jun 2003, Leopold Toetsch wrote: [...] Nobody answered, if we need another Sub class implementing the old invoke/ret scheme ... I'd say no. P6C is now compiling to an obsolete architecture. While we should all step back and be impressed at how well Intel has maintained backward compatibility in the x86, there's no particular reason we should do so ourselves. Rather, someone (me) needs to port P6C to the new machine. /me shows ignorance yet again. For those of us who are not hardware types...what is the new machine? The Itanium? Does that really have enough market penetration at this point to be a worthy target? Or is the idea that, by the time Parrot is finished, it WILL have massive market penetration? Piers Cawley [EMAIL PROTECTED] wrote: Whee! My first anniversary! Congrats and thanks for your great summaries. Seconded. Thirded. Although the doings of the internals list fascinate me, they are usually totally over my head, so I long ago unsub'd. It's great to be able to follow along via the summaries. --Dks
Re: This week's summary
On Tue, Jun 24, 2003 at 07:58:32AM -0700, David Storrs wrote: /me shows ignorance yet again. For those of us who are not hardware types...what is the new machine? The Itanium? Does that really have enough market penetration at this point to be a worthy target? Or is the idea that, by the time Parrot is finished, it WILL have massive market penetration? The machine they're talking about is parrot. A virtual machine, but a machine none the less. The new machine is the new calling conventions recently implemented. andrew -- Aquarius: (Jan. 20 - Feb. 18) Heartbreak is in the stars for you this week when the woman of your dreams confesses she cannot love a man with such an unholy appetite for pie.
Re: This week's summary
On Tue, Jun 24, 2003 at 04:04:29PM +0100, Andrew Wilson wrote: On Tue, Jun 24, 2003 at 07:58:32AM -0700, David Storrs wrote: /me shows ignorance yet again. For those of us who are not hardware types...what is the new machine? The Itanium? Does that really have enough market The machine they're talking about is parrot. A virtual machine, but a machine none the less. The new machine is the new calling conventions recently implemented. andrew Ah. Of course; I got confused by the x86 references and took them too literally. Thanks for setting me straight. --Dks
Lightweight Object Existance Proxies
This idea seems to fit in a lot of places. It's more of a design
pattern than anything else, but one I think P6 can use to good effect
in the standard library.
Lightweight Object Existance (LOE) Proxies
An LOE proxy is an object that proxies for another, heavier, object
that (maybe) doesn't exist.
The idea is that when creating an object, either from scratch or
rehydrating/thawing an object stored offline or serializing an object
stored on a separate node, is expensive or undefined, an LOE proxy can
be used.
This proxy could be used when a network of objects is being
instantiated, when a particularly smart garbage collector knew how to
push unused but persistent objects out of memory, and by some other,
sleazier, code (below).
It occurred to me yesterday, while reading DDJ, that this is a good way
to implement a ThreadLocal storage variable:
A thread will have its own scope. This behaves as you expect a scope to
behave with respect to other thread scopes, and serves as a divider
between the lexical scope of subs entered in the thread and scopes
active for this thread because they were entered in the parent thread
before the current thread was spawned.
An object declared Cis ThreadLocal would simply create a shared
reference to an anonymous object in the threads scratchpad, and use
run-time resolution.
Thus:
sub A {
...
}
my $a is ThreadLocal;
for (0..10) {
thread A;
}
Each thread would share the global scope, and behind the global scope
the zero-thread scope (which contains nothing).
The Cthread call would create a thread scope, which would then be
overlain with a subroutine scope for sub A.
Scope stack:
Thread[Main]
::Global
Thread[0..10]
::A
The ThreadLocal object lives in ::Global context. If it were a valid
object that had to implement its own semantics, it would likely be slow
( buggy!) unless there were also some sort of direct copy on access
support implemented in core (and perhaps slow even then).
But if the object were itself an LOE proxy, the proxy could dynamically
instantiate the new object and dispatch appropriately:
class ThreadLocal {
has%.thread2client;
method DISPATCH($self: $method, @args)
{
my $t = callcc($caller.cc, get_current_thread);
my $client = %.thread2client{$t} //= new $.class;
SUPER.DISPATCH($client, $method, @args);
}
}
=Austin
Re: object initialisers
On Thu, Jun 12, 2003 at 04:02:50PM +0200, Rafael Garcia-Suarez wrote:
Nicholas Clark wrote:
class Foo {
...
std::size_t spare = 0
std::size_t allocate = 4096
std::size_t min_readline = 80
and have the compiler know that if I specify a member initialiser in my
my constructor, then that should be used, otherwise to default to using
the value I say. (To avoid the inevitable search/replace if I want to
change that value)
That's actually valid Java syntax (modulo a trailing C;). The default
value can be any expression (as long as it doesn't involve a reference
to the object being constructed, IIRC).
In fact Java provides a notion of instance initialiser, run before
any specific constructor you're invoking, that initialises such fields,
and may run other code.
This wasn't quite what I was thinking about. I was more for typing
laziness (and avoiding cutpaste) - I'd like a default for the
instance initialiser, but only to be used (by the compiler's code
generator) if I don't specify a specific initialiser in that (overloaded)
constructor.
But currently I'm having my mind warped by C++, so I may not be sane.
Nicholas Clark
Re: object initialisers
--- Nicholas Clark [EMAIL PROTECTED] wrote:
This wasn't quite what I was thinking about. I was more for typing
laziness (and avoiding cutpaste) - I'd like a default for the
instance initialiser, but only to be used (by the compiler's code
generator) if I don't specify a specific initialiser in that
(overloaded) constructor.
Would that be:
class X {
has $.attr1;
has $.attr2;
method new($class: ?$.attr1, ?$.attr2) {
$.attr1 //= 0; # Default value
$.attr2 //= 0; # Default value
}
}
Where the $.attr1 syntax is the already-discussed
quick-constructor-assign shortcut, and the //= allows you to specify
a default if the arglist failed?
=Austin
RE: Exceptions
Piers Cawley: Dan Sugalski [EMAIL PROTECTED] writes: Exception handlers really strike me as anonymous lexically scoped subroutines that get called with just one parameter--the exception object. So, we grab another register for 'current exception continuation'? Then when code throws an exception it just takes the exception continuation and if that can't handle the exception it takes *its* current exception continuation and so on up the exception chain? -- I think The Plan (tm) is to attach the exception handler to system stack frames. When an exception is thrown, we pop frames off the system stack until we reach one with an exception handler attached. This has several benefits: 1) It means the system stack is exactly where it should be when we call the exception handler. 2) It automatically restores outer exception handlers when inner ones go out of scope. (Sorry about the formatting--I just reinstalled Windows, and I'm still settling in here.) --Brent Dax [EMAIL PROTECTED]
Re: Exceptions
At 8:53 AM -0400 6/23/03, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: Okay, now that we're well on our way to getting sub/method/whatever calling down and working, I want to point us towards what I'm thinking of for exceptions. Exception handlers really strike me as anonymous lexically scoped subroutines that get called with just one parameter--the exception object. As far as the engine should be concerned, when an exception is taken we just take a continuation with the address being the start of the code that handles the exception. They need to get pushed on the system stack so we can walk up it at runtime when an exception is called looking for handlers. So, we grab another register for 'current exception continuation'? Nope. The exception goes onto the control stack. When an exception is thrown we walk up the control stack frames until we find an exception handler entry, at which point we invoke the continuation associated with it, passing in the exception information. (Though we may put the exception info out-of-band, since I can see wanting to retain all the registers for Truly Clever exception handlers...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #22762] [PATCH] perl 5.005's mkdir required the 'mask' argument
On Mon, Jun 23, 2003 at 04:15:35PM +, Andy Dougherty wrote: This patch is necessary to get parrot to build with perl 5.00503 -- the mode argument to mkdir() wasn't optional back then. I'd apply it myself, but cvs doesn't seem to like me today, and I'm tired of fighting it. (My login apparently succeeds, but the commit fails claiming I don't have 'write' privs.) Thanks applied Nicholas Clark
Re: [perl #22767] IMCC/Parrot leak and eventual segfault (partially solved)
At 10:33 AM +0200 6/24/03, Leopold Toetsch wrote: Clinton A. Pierce [EMAIL PROTECTED] wrote: Found the bug. Mostly MEA CULPA. A thousand pardons to the good Parrot folk. When calling a sub like this: .arg 0 call _foo It's probably a good thing to take the 0 off the stack at some point. Thanks again for your bug report and thorough checking all kind of parrot limits. I've added a check for too deeply nested stacks now. Your first test program now bails out at: 25342 Stack 'User' too deep The limit is currently fixed at 100 chunks, but could easily be changed with a new opcode, e.g. stack_limit .Stack, limit. This sounds like a good option, though 100 might be a bit small, since I plan on giving new frames on pushes to COW'd stack chunks. (No reason not to (well, besides the performance hit) and it makes some coroutine stuff easier) I probably ought to get started on the stack-chunk-as-PMC patch for garbage collection of stack frames. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 19:56, Michael G Schwern wrote: I don't quite understsand what spanning perl interpreters means. Neither did I until just now. I think it's the fact that forks will cause the END to run multiple times. It would be nice if Test::Builder gave a method to give us access to $Original_Pid. I suppose I can track it myself though, F
Re: [ANNOUNCE] Test::Warn::None 0.02
All this make sure no warnings fired is good thinking. But why not roll it into Test::Harness, and make it switch selectable? It's really T::H that we want keeping an eye on this, right? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 20:04, Andy Lester wrote: All this make sure no warnings fired is good thinking. But why not roll it into Test::Harness, and make it switch selectable? It's really T::H that we want keeping an eye on this, right? Possibly... ...except how does Test::Harness know the difference between a diagnostic and and a warning that began with #? Or indeed the difference between something printed on STDOUT and something that came out via warn or the 'warnings' modules? F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 19:55, Michael G Schwern wrote: I like Test::Warn::None or some variation on it. Or even Test::NoWarnings. Doesn't have to sit in the Test::Warn namespace. Test::NoWarnings sounds good to me. What is the correct etiquette for abandoning a namespace? Just delete the files with PAUSE or should I leave a pointer behind? Not too important with this module but I'm just curious, F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 20:31, Michael G Schwern wrote: If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes to mind. That's cool, I never saw that before. It's also a pretty convincing argument for an I'm going to add an extra test method in Test::Builder, F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 12:37:36PM +0100, Fergal Daly wrote: Also how about calling it Test::Warn::Auto? I'm not particularly happy with None, Test::Warn::Auto doesn't say anything about its main purpose: to ensure that you have no warnings. Instead it documents an implementation detail, that the check for no warnings is automatic. I like Test::Warn::None or some variation on it. Or even Test::NoWarnings. Doesn't have to sit in the Test::Warn namespace. -- You're the sickest teenager I've ever set my wallet on.
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 12:07:19PM +0100, Fergal Daly wrote: Consider the following. use Test::More; use Test::Warn::None; plan tests = 42; To make this work I'd have to overhaul the internal Test::Builder planning system to allow Test::Warn::None to say I'm going to add an extra test, please remember this fact. I can be convinced its worth it. It seems like a good idea to me. Are there any other modules that would use it? Potentially, but I can't think of anything at the moment. -- Loon.
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 01:36:52PM +0200, Rafael Garcia-Suarez wrote: BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. There's Test::Warn, but I don't think it does anything special with registered warning classes. (Avoiding to span perl interpreters at each test would be a bonus.) I don't quite understsand what spanning perl interpreters means. -- It's Yellowing Laudanum time!
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 02:04:25PM -0500, Andy Lester wrote: All this make sure no warnings fired is good thinking. But why not roll it into Test::Harness, and make it switch selectable? It's really T::H that we want keeping an eye on this, right? No, its definately a test feature. Much easier to set up (no MakeMaker muckery), finer granularity (can be done on a per test file basis rather than a whole suite) and can distinguish between warnings and diagnostic output (ie. warn() vs diag() vs print STDERR). Besides, Test::Harness can't portably trap STDERR. If you can figure out a way to do it that would solve lots of problems. If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes to mind. -- Congratulations, you're a thieving bastard... Now give me back my pants. That's MISTER Pants! -- Ian's Adventures In Morrowind http://www.machall.com/morrowind/page3.html
Re: [ANNOUNCE] Test::Warn::None 0.02
Michael G Schwern wrote in perl.qa : On Tue, Jun 24, 2003 at 01:36:52PM +0200, Rafael Garcia-Suarez wrote: BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. There's Test::Warn, but I don't think it does anything special with registered warning classes. It doesn't support them for now, according to the docs. (Avoiding to span perl interpreters at each test would be a bonus.) I don't quite understsand what spanning perl interpreters means. qx// (like lib/warnings.t in the perl core) -- Is it any wonder the world's gone insane, with information come to be the only real medium of exchange ? -- Thomas Pynchon, Gravity's Rainbow
Re: [ANNOUNCE] Test::Warn::None 0.02
Michael G Schwern wrote in perl.qa : On Tue, Jun 24, 2003 at 02:04:25PM -0500, Andy Lester wrote: All this make sure no warnings fired is good thinking. But why not roll it into Test::Harness, and make it switch selectable? It's really T::H that we want keeping an eye on this, right? No, its definately a test feature. Much easier to set up (no MakeMaker muckery), finer granularity (can be done on a per test file basis rather than a whole suite) and can distinguish between warnings and diagnostic output (ie. warn() vs diag() vs print STDERR). Besides, Test::Harness can't portably trap STDERR. If you can figure out a way to do it that would solve lots of problems. If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes to mind. Provided that all test scripts are written with a Test::Warn::None-compatible plan(). -- Don't use color combinations that cause problems for people with color blindness in its various forms. -- W3C, HTML 4.01 Specification, 6.5.1
