Klaas-Jan Stol wrote:
On Sat, Aug 30, 2008 at 11:04 AM, Allison Randal [EMAIL PROTECTED] wrote:
Yes, it will be deprecated, or at least renamed. The C.return directive
without parentheses is an old convention for passing a single return result,
and must always be sandwiched between
Bob Rogers wrote:
My sense of the usage on this list is that multisub means a MultiSub
PMC and a multimethod is what you add to the MultiSub when you define
a sub with the :multi keyword. Am I the only one who finds this a
useful distinction?
Oh, I see. No wonder this conversation has been
Klaas-Jan Stol wrote:
This is another one of those muddy cases in PIR where words conflict when
they shouldn't. I can't think of any way that it's actually useful to have a
variable named 'add' prevent you from using the opcode 'add'.
.. but of course, I don't want to exclude it. If it is
Geoffrey Broadwell via RT wrote:
What is the replacement for the old regular variants that use a
pre-existing destination?
A few years ago when I was doing copious Perl 5 PDL work, I found that
in certain loops I would get bottlenecked entirely by creation and
destruction of temporaries. I
Bob Rogers wrote:
Just single dispatch. A method that's single dispatched, is... a method.
True. Nevertheless, the two kinds of method are treated quite
differently by Parrot, both when being defined and when being called.
That is why it is awkward not to have concise names for both kinds.
Bob Rogers wrote:
So you prefer the plain term method for method that is not a
multimethod? That seems prone to confusion. What do you suggest for
the generic term?
It's not prone to confusion. By definition, a method is a invoked on a
single invocant (an instance of the class that
Reini Urban wrote:
Problem:
Most packages will not accept packages with /usr/bin/scheme,
/usr/bin/lisp, /usr/bin/forth, /usr/bin/lua, /usr/bin/tclsh
were these are the parrot implementations.
Of course we don't want to hijack existing language executables in the
distribution packages. But,
Reini Urban wrote:
I hope you know that this #+() syntax is the only existing syntax.
It is widely used since about 20 years.
The rest is something new we came up with.
It's high time for a little progress. Sheesh, in 1988 we were excited by
computers with 1 MB of RAM. ;)
Allison
Reini Urban wrote:
Ok, so there will be pugs, perl -Mv6 and rakudo | parrot-perl6
Maybe both /usr/bin/rakudo and /usr/bin/perl6 should be symlinked to
/usr/bin/parrot-perl6 then.
Currently there's only a /usr/bin/perl6 being installed.
This really should be made ready for the September
Patrick R. Michaud wrote:
On Fri, Aug 29, 2008 at 06:10:21PM +0200, Reini Urban wrote:
2008/8/29 Allison Randal:
... the $0 handling will be built in to Parrot, so the
user could also easily create their own 'ln -s' aliases.
Within the PCT::HLLCompiler I assume.
PCT::HLLCompiler can't do
Reini Urban wrote:
And I'm tempted to add: Actually even the 1984 version of lisps are
still technically and syntax-wise far advanced over the perl and
parrot state of today. I see not much of a progress.
Philosophically, I agree. In my usual Parrot architecture talk there's a
slide right
Reini Urban wrote:
I have one more draft.
chromatic told me write up such a thing, but it's not finished yet.
It could go to the cygwin070patches branch which is really a
parrot_install branch, but also to HEAD.
This needs some technical review because but I'm still a beginner
in what is
NotFound wrote:
Hello.
The current grammar for ATTR in pmc2c allows declarations of the form:
type * varname
In the perl6multisub pmc we have the attribute candidates_sorted whose
intended type is candidate_info **, having two problems:
The current grammar allows a single pointer, not a
Bob Rogers wrote:
OK, here's my straw-man proposal for a language interoperability
framework; my apologies for sitting on it so long. It's still pretty
messy, but I'm sure it will benefit more from other viewpoints at this
stage than from polishing.
Thanks, added to trunk as
Allison Randal wrote:
Bob Rogers wrote:
OK, here's my straw-man proposal for a language interoperability
framework; my apologies for sitting on it so long. It's still pretty
messy, but I'm sure it will benefit more from other viewpoints at this
stage than from polishing.
Thanks, added
[EMAIL PROTECTED] wrote:
Opcode names are not reserved words in PIR, and may be used as variable names.
For example, you can define a local variable named Cprint. [See RT #24251]
+Note that by using an opcode name as a local variable name, the variable will
+Ihide the opcode name, effectively
Moritz Lenz wrote:
[EMAIL PROTECTED] wrote:
+{{ Is the term unimethod acceptable here? -- rgr, 29-Jul-08. }}
I think for dispatch the term is single dispatch, and unimethod
could thus be single method.
Just single dispatch. A method that's single dispatched, is... a method.
Allison
[EMAIL PROTECTED] wrote:
+PIR keywords, on the other hand, Iare reserved, and cannot be used as
+identifiers. Some opcode names (Cif, Cunless) are, in fact, PIR keywords,
+which therefore cannot be used as identifiers.
If the PDD says the keywords are reserved, it also needs to say what the
Reini Urban wrote:
A new idea:
===
#IF(darwin):
#ALSO:# MACOSX_DEPLOYMENT_TARGET must be defined for OS X
#ALSO:export MACOSX_DEPLOYMENT_TARGET := @osx_version@
Just a little too much complexity, for not enough benefit.
The POD for this change:
Looks good.
For legacy the old
Will Coleda wrote:
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
That's probably the
Patrick R. Michaud wrote:
On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote:
That's backwards. Loading the language module is what registers the
compiler. The user never needs to access the compiler object for a
particular language directly unless they're compiling code from
James Keenan via RT wrote:
On Mon Aug 25 13:15:16 2008, [EMAIL PROTECTED] wrote:
Generally recommend attaching patches as files ending in .patch (as
documented in docs/submissions.pod) for the sanity of the patch
monsters.
Well, since it's in the docs, I will withdraw the suggestion.
On Mon, 25 Aug 2008, Reini Urban wrote:
To clarify my bold statement:
The ALGOL-like syntax is not sane because,
* it is hard to parse,
Not actually true. It's just different to parse. And, in general Parrot
optimizes for making code easy to *read* even if it is slightly harder
to parse. We
jerry gay wrote:
#+ and #- is lisp so I don't want to destroy #+ the syntax rules.
#IF(): is quite short and easy to read.
i know it was all caps before, but do we need to continue that trend?
i find it ugly.
All-caps is the Parrot coding standard for macros and #defines, and
these fall in
jerry gay wrote:
On Tue, Aug 26, 2008 at 9:16 AM, Reini Urban [EMAIL PROTECTED] wrote:
jerry gay schrieb:
On Tue, Aug 26, 2008 at 2:34 AM, Reini Urban [EMAIL PROTECTED] wrote:
I'll go now for something like
#IF(key1|key2(key3!key4))
To make sure, that means basically the same thing as the
Will Coleda wrote:
Moritz Lenz wrote:
Reini Urban wrote:
Actually I stumbled over quite a lot of dangling references in the docs.
Including, but not limited to, references to PDDS that still live in
draft/, but are references to be in docs/pdds/ directly.
What should we do with all these?
Reini Urban wrote:
In lib/Parrot/Configure/Compiler.pm, I agree that 'CONDITIONED_LINE' and
'INVERSE_CONDITIONED_LINE' aren't the clearest names, but '+' and '-' are
far less clear. Change them to something meaningful like 'SHOW_LINE_IF' and
'HIDE_LINE_IF'. We can note the change in
James Keenan via RT wrote:
3. For future reference, submit bug reports to:
[EMAIL PROTECTED] I recommend beginning Subject line with:
[BUG]. And I recommend submitting patches as email attachment ending in
: .txt (because that seems to render best in browsers, mail, news
interfaces).
Reini Urban wrote:
You want one patch only against HEAD? That's easy.
But I dislike the idea, as it violates the usage of single tickets.
This is different than the usual case as it's a collection of dependent
patches that can't be evaluated independently. Splitting them out is
actually
Reini Urban wrote:
The issue is not the CPAN SW, which can easily be fixed somewhen (no-index),
the CPAN mirror network and the popularity is what parrot should look
forward to, IMHO
For that purpose, we're better off targeting the much larger
distribution networks of Debian, Ubuntu, Red
Klaas-Jan Stol (via RT) wrote:
Parrot has an instruction called 'set_addr', that stores the address of a
label into an integer register.
IMCC (and pdd19_pir) defines a short-cut for this op, called 'addr'.
$I0 = addr XYZ
I propose to remove this shortcut; should anybody want to use it, just
Moritz Lenz wrote:
On #perl6 somebody just asked if there were up-to-date windows builds of
parrot somewhere, he had googled for 'parrot windows'. The parrotwin32
project didn't show up in his search (but it's first for 'parrot win32').
I think we should improve that situation. Suggestions:
Kevin Tew wrote:
I still think too much junk is in jit_emit.h
The patch attached shows how I would re-factor it.
That's a sane refactor. Thumbs up.
Allison
Reini Urban wrote:
Moritz Lenz schrieb:
Against which svn revision should I apply those patches for testing?
I'll try to be uptodate against HEAD with the patches in my SVN repo.
But things are changing fast over there.
config/gen/makefiles/root.in was changed by the ncigen merge
Will Coleda wrote:
In general, I'm not a fan of the AUTHOR sections. As you've noted,
they can get stale or out of sync pretty easily.
A lot of this information is captured in the version control metadata,
CREDITS, and RESPONSIBLE_PARTIES, and if someone's looking to get a
question answered,
Reini Urban wrote:
As my number of patches is too big, and the size is too big,
I update them only in my public SVN repo, not in the tickets anymore.
And the order in which they should be applied is important.
See
James E Keenan wrote:
Are these happening notwithstanding the patches I applied for RTs 57956,
57958 and 58036?
The stray test files are gone now, and not recreated by 'make test',
'perl Configure.pl', or 'perl Configure.pl --test=configure'.
Thanks!
Allison
[EMAIL PROTECTED] wrote:
{WS}.{WS} means concatenation (as in $P0 . $P1)
{WS}. means concatenation (as in $P0 .$P1)
.{WS} means concatenation (as in $P0. $P1)
. means method call (as in $P0.$P1)
You can simplify even further and make these two syntax errors:
{WS}. means concatenation (as
Stephen Weeks (via RT) wrote:
There are some issues that need to be resolved for resumable exceptions.
The first issue I've run into is that Parrot_cx_find_handler_local marks
the exception handler as used when it finds it and ignores already-used
exception handlers.
This is an intentional
Thanks, applied in r30349.
Andrew Whitworth wrote:
I created a new branch tonight, /branches/pdd09gc to try to continue
some of my GC work from the summer with a blank slate. I have a few
cleanup jobs I want to do first, so that it should be easier to add in
a new GC without having so many problems as I had. One thing
chromatic wrote:
If it's *close* (and mostly passing tests) we can always throw it back
into trunk immediately after a monthly release and give ourselves 4
weeks to clean it up.
The important thing to remember is that the GSOC project wasn't revamp
the GC system to meet the new spec it was
Will Coleda wrote:
Please open a ticket tracking this if we're not going to apply it
right now so we don't miss it for next release.
CPAN is great for distributing Perl modules, but simply can't handle
Parrot. As soon as we have the alternate FTP site up, we're done with CPAN.
Allison
Running 'make test' now fills the main directory of the repository with
junk files like:
test_98093.out
test_37653.c
test_98093.ldo
test_97159.c
The offending tests need to be modified to clean up after themselves.
Allison
Patrick R. Michaud wrote:
What I'm trying to do is to test the ability to resume after
exceptions thrown by Cfoo. The Cmain sub above sets up
a handler to catch exceptions, then calls Cfoo. The handler
simply resumes any exception that is caught. The Cfoo sub
prints 'ok 1', throws an
Klaas-Jan Stol wrote:
I'm sorry, but this is not the case. It is in fact valid:
running:
==
.sub main
newclass $P0, foo
$P1 = new foo
$P1 .hi() # note the space before the dot
$P1. hi() # note the space after the dot
.end
.namespace [foo]
.sub hi :method
print
Bob Rogers wrote:
We're going to a completely stackless virtual machine.
But Parrot is already stackless. The dynamic_env slot to which I assume
you refer is really a tree with upward pointers.
To be clear, Parrot will have no *global* stack. The data structure
implementing the stack
Klaas-Jan Stol wrote:
On Sat, Aug 16, 2008 at 9:41 AM, Allison Randal [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
On Wed Aug 06 05:53:07 2008, kjs wrote:
My proposal would be to change the concatenate dot into
.., which
Will Coleda wrote:
Any automatic mapping between multiple languages will fall down at some
point in a very ugly way. I imagine modules will be developed to allow you
to, for example, mask all Python types from within your Perl 6 code as Perl
6 types. But users will always have the ability to go
Klaas-Jan Stol wrote:
Therefore, my proposal is to remove the .globalconst directive;
whenever you need to have a global const, use .const outside of a
subroutine.
whenever you need to have a local const (in a sub), use .const inside a
subroutine.
If we're going to remove one, let's deprecate
Klaas-Jan Stol wrote:
On Wed Aug 06 05:53:07 2008, kjs wrote:
My proposal would be to change the concatenate dot into .., which looks
like it, but is more explicit, and will prevent such mistakes.
I agree that there should be some change. I've run into this problem
myself in the past, and
Jeff Horwitz wrote:
i'd like to have an option in mod_parrot to clear all user-generated
data (globals, namespaces, subs, etc.) from an interpreter, leaving any
bytecode that has been loaded (e.g. compilers). the point here is to
eliminate problems caused by data persistence on hosted web
chromatic wrote:
On Thursday 07 August 2008 08:26:19 Bob Rogers wrote:
I once suggested a null register allocator that would do this
globally, but this is a better idea. The only use case I can think of
is debugging, particularly of the register allocator, but that's still
important.
In
François Perrad wrote:
Ok, Lua tests pass, but the behavior has changed.
(The tests were written to check the exception message, not the full
back trace)
The pushaction allowed to retrieve the backtrace where the exception
occurred.
The backtrace from the exception handler is alway the same
Bob Rogers wrote:
From: Allison Randal [EMAIL PROTECTED]
The biggest changes you'll notice are the new exception system, a vastly
reduced usage of the remaining stack (though it's not completely removed
yet), and the fact that pushaction subs no longer fire on scope exit
I've posted the task list for the MMD branch to the wiki:
http://www.perlfoundation.org/parrot/index.cgi?pdd27mmd_tasklist
There's really only one task: merge the two MMD implementations into
one. But, I've split it out into a series of smaller tasks so we can
share the work and track
Wherever two or more of you are gathered together...
Bernhard and I are currently in the lobby at Hotel Centrum, 2 blocks
south-west from the main train station (Kobenhavns H) on the corner of
Istedgade and Helgolandsgade. Free wireless is available.
Will send an update if the location
We could use a few volunteers to port pages from parrotcode.org to the
new Parrot website. It's a simple repetitive task, view source on the
original page and paste the main HTML into the new CMS. (Ignoring any
pages automatically generated from Pod in the repository, because we'll
handle
Will Coleda wrote:
I agree that any removed feature should have a deprecation cycle;
Here's my pitch for how we've already done that; the list of
deprecated features has RTs; the RT listed what was going to have to
happen for some time now; This covers us on the deprecation
notification.
I am
The simple answer is Parrot won't do any automatic mapping of types
between HLLs. If you call a Python library function that returns a
Python Dictionary type, you'll get back a Python Dictionary PMC. You can
interact with it as a string keyed hash (because it implements the
string keyed vtable
Jonathan Worthington wrote:
Hi,
Rakudo is currently failing t\spec\S12-class\attributes.t. This turns
out not to be an issue with attributes, but rather exceptions. The test
does:
my $c = Counter.new();
try {
$c.x
}
ok($!, 'no public accessor for private attribute');
And fails because
Merged pdd25cx branch into trunk in r29952. Deleted branch in r29953.
Committed a fix to tcl in branch (r29940) to pull from the correct
slot. All tests now pass. I'd like to see this segfault/assert/boom
addressed before we merge back, just in case.
Resolved in r29941, by throwing an exception when requesting an
attribute that doesn't exist, or an attribute
Jonathan Worthington wrote:
Patrick and I will be hacking on the 12th and the 16th. If you've not
seen Copenhagen before, I could forgive you for wanting to spend a day
enjoying the city rather than hacking though - it's nice! :-)
I have, in fact, seen Copenhagen before, and if it weren't
chromatic and I have fixed the majority of the language issues (see
child tickets for specific comments). I will merge the branch back into
trunk first thing tomorrow morning (Saturday, August 2nd).
In r29934 of the branch, I can't even get tcl to build, it keeps
complaining about calls to tcl_error_s which it says doesn't exist.
Since you mentioned you were eliminating the versions of tcl_error
identical to 'die', I went through and replaced the calls to tcl_error
with calls to die. It
I just merged in the pdd25cx branch. Resolving all the conflicts took
several hours (124 files, 1 minute or more per file...), but otherwise
it went smoothly.
The biggest changes you'll notice are the new exception system, a vastly
reduced usage of the remaining stack (though it's not
Bernhard Schmalhofer wrote:
We could always do the 12th AND the 16th, just for fun and bonus
productivity (if everyone isn't exhausted from a day of hacking and
three days of conference)? ;-)
I'm also flexible. 12th and 16th sounds good to me.
I've booked to arrive in Copenhagen on the
Allison Randal wrote:
Bob Rogers wrote:
The attached patch (against the trunk) adds a case which fails in
pdd25cx but works in trunk. Should I go ahead and commit it, and if so,
to branch, trunk or both?
Looks like you forgot to attach the patch.
Got it, thanks. That patch demonstrates
Bob Rogers wrote:
The attached patch (against the trunk) adds a case which fails in
pdd25cx but works in trunk. Should I go ahead and commit it, and if so,
to branch, trunk or both?
Looks like you forgot to attach the patch.
Allison
Moritz Lenz wrote:
I also get errors in parrot's PGE tests (I guess they are known already;
if not I can happily send the details)
I get no errors in PGE's tests on Mac OS X or Ubuntu as of r29552, so
please send the details.
Allison
Bob Rogers wrote:
The same Kea-CL tests are failing in pdd25cx revision 29565 as I
mentioned in this message:
From: Bob Rogers [EMAIL PROTECTED]
Date: Tue, 8 Jul 2008 22:21:06 -0400
. . . I am seeing three test failures when it should execute a
pushaction sub, but does not. Two
Allison Randal wrote:
Moritz Lenz wrote:
I also get errors in parrot's PGE tests (I guess they are known already;
if not I can happily send the details)
I get no errors in PGE's tests on Mac OS X or Ubuntu as of r29552, so
please send the details.
Oh, but do make sure you've updated
After temporarily disabling the graph coloring register allocator, the
pdd25cx branch passes all Parrot tests. Please run the tests for your
language and report/debug any test failures that are different than the
test failures in trunk.
The plan is to merge the branch back into trunk on
Moritz Lenz wrote:
NotFound wrote:
To open another can of worms, I think that we can live without
character set specification. We can stablish that the character set is
always unicode, and to deal only with encodings.
We had that discussion already, and the answer was no for several reasons:
On Fri Jul 11 09:41:21 2008, julianalbo wrote:
There is a problem with the autogenerated name: in several cases there
are other things with that name. For example, for the float.pmc we
have the Parrot_Float type defined in include/parrot/config.h
Given that the name will be mainly used via
We're planning to meet Saturday after OSCON for a Perl 6/Parrot
hackathon. Location still to be determined, but it will be somewhere
close to the OSCON convention center.
Allison
Allison Randal wrote:
We're planning to meet Saturday after OSCON for a Perl 6/Parrot
hackathon. Location still to be determined, but it will be somewhere
close to the OSCON convention center.
Location confirmed:
Urban Grind East
2214 NE Oregon St.
Portland, OR 97232
Saturday July 26th, 9am
A bit more detail on the conversion process for a PMC:
1) Find the core data of the PMC, and convert it into a series of ATTR
statement at the beginning of the pmclass block. So, if the PMC uses
only 'PMC_int_val', create a single entry: 'ATTR INTVAL integer_data;'
(Pick a meaningful name, and
Andrew Whitworth via RT wrote:
With some help from DietCoke, we got most of the problem solved.
However, several tests are failing now, especially those dealing with
overriding the invoke vtable method.
One error specifically caught my eye, from t/pmc/namespace.t:1672:
sub 'main' :main
$P0
If you happen to be at YAPC::NA, we're having a brief, informal meeting
about the foundation tonight at 6:30.
http://conferences.mongueurs.net/yn2008/wiki?node=Parrot%20Foundation%20BOF
Allison
I've integrated all comments (from individuals and lawyers). Final
review before we file:
http://www.perlfoundation.org/parrot/index.cgi?a_foundation_for_parrot
Allison
Resolved in r28017.
chromatic via RT wrote:
Do you mean that r28017 fixed it (which doesn't make sense to me), or that you
can't reproduce it after r28017?
Can't reproduce it.
Allison
chromatic via RT wrote:
Standard dance: 'make realclean'?
Yup.
That's directly from an isa opcode. Is $2 NULL or is $2-vtable NULL or is
$2-vtable-isa_pmc NULL?
Demacrofying, that's:
(gdb) print ((interp)-ctx)-bp_ps.regs_p[-1L-(2)]
$1 = (PMC *) 0xa52ab0
So $2 isn't null. and:
Patrick R. Michaud wrote:
Since there's a fair amount of existing code that may be doing
slurpy positionals before named parameters, I propose, perhaps
as an interim step, that we say that positional slurpy array
parameters must come after all positional and lookahead parameters
(but could come
(After talking about it on the phone today.) From the Parrot side, we
have basically 3 binary factors: named (or not), positional (or not),
and optional/required.
The unmarked case is a required parameter that can be passed as a
positional argument and can't be passed as a named argument.
Jonathan Worthington wrote:
Bob Rogers wrote:
Jonathan Worthington wrote:
Is the idea sane, and is the name of the adverb OK? If so, I'll go ahead
and implement it (with changes as needed).
The idea is generally sane.
It is a good idea. I think I would call it :class, though.
I
chromatic wrote:
[...]
These are the headerizer changes that bother me the most.
Reverted in r27414.
Allison
There will always be a few situations where it's not possible to throw a
real exception (because there's no interpreter argument, or it's an
error within the exception subsystem, etc.). So, we need to keep one
simple fatal error sub around. I replaced 'internal_exception' with
'exit_fatal' in the
chromatic wrote:
These are the headerizer changes that bother me the most.
Feel free to revert them.
Allison
Yes, PDD 19 can talk about 'subroutines' rather than 'compilation
units'. (I just did a quick skim of the file, and a simple search and
replace changing 'compilation unit' to 'subroutine' will work fine.)
In imcc.y, change 'compilation_unit' and 'compilation_units' to
something more general like
Will Coleda wrote:
On Tue, May 6, 2008 at 1:23 AM, Will Coleda [EMAIL PROTECTED] wrote:
The goal for 1.0 is to ship languages separately from parrot; Can we
get a brief summary of what sort of licensing/copyright issues apply
when the languages are removed from perl.org repository?
My
Allison Randal wrote:
Presumably the handled opcode will remove the exception Task from the
scheduler and resume execution at the appropriate point. Presumably
also the declining to handle an exception (the replacement for
rethrow) will cause the scheduler to move to the next exception
Klaas-Jan Stol wrote:
hi,
it seems that there is overlap in the strings pdd (28) and the strings
implementation document in docs/strings.pod.
I'm not sure if this is a good idea; I think these should be merged.
If so, I'll open a ticket to do so (but wanted to check first)
There's overlap
Will Coleda via RT wrote:
On Sun Aug 15 13:35:26 2004, coke wrote:
Automate string vtable generation
(From the TODO file)
This is a very old TODO with no information cut and pasted by yours
truly from the TODO file we used to have.
Anyone thinks it's worth doing (and can actually explain
Will Coleda schrieb:
Can we get an idea of how many parrot hackers are planning on
attending YAPC::EU this year? (will be held in Copenhagen, Denmark, on
13-15 August 2008.)
[...]
Bernhard Schmalhofer wrote:
Is there enough critical mass that would warrant a Mini-hackathon?
I'm now
Off-and-on over the past year there have been sporadic conversations
about starting a foundation for Parrot separate from the Perl
Foundation. With 1.0 approaching, it's making more and more sense.
Parrot will be better able to approach the Python, Ruby, PHP, Lua, etc
communities if we're
chromatic wrote:
From the wiki at
http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks :
* Deprecate rethrow.
The replacement seems to be that an exception handler declines to handle an
exception. This is the default behavior; an exception handler explicitly
notifies the
Bob Rogers wrote:
From: Klaas-Jan Stol [EMAIL PROTECTED]
about the removal of internal_exception: the specified ticket (in the
list on the wiki) does not have a conclusion: no final decision seems
to be have made on that issue. What's more, a quick check on a few
calls to
101 - 200 of 845 matches
Mail list logo
