Created track ticket TT #804 as RFC with a patch that modifies throwing
of exceptions from C that might solve this problem. With it the pir
example runs forever.
Please put comments about it on trac, not here.
This example fails because the op find_method uses
Parrot_ex_throw_from_c_args, that handles the exception in an inner
runloop. From an opcode is better to use Parrot_ex_throw_from_op, wich
jumps to the handler in the current runloop.
I'm working on a patch that defines the helper function
Problem fixed and test added, closing ticket.
I've done some work in this problem. The attached patch is a way to make
the examples work but I think this is not the way to go, or a lot of
functions in a lot of pmc will need changes.
Index: src/pmc/complex.pmc
===
---
Done in r31684 after MMD changes, adding the test from the previous patch.
Updated information: we added recently a workaround to the utf8 downcase
function, by moving code already present out of the ICU #if block.
This workaround delegates to the ascii downcase when the string has only
codepoints in the ascii range (the way used to do that check is
debatable, must be
The problem is that the vtable function get_class return NULL. This is
easily fixable, but the root of the problem is that the _class attribute
is set in init as PMCNULL, but later it contains NULL.
On Mar. Ago. 12 15:05:57 2008, Whiteknight wrote:
This probably isn't headerizer's fault, it's more likely the fault of
IMCC for being so damn complicated. We could change all the function
definitions in the IMCC related files to use struct _IMC_Unit instead
of IMC_Unit which would resolve
This check can be removed from default.pmc. Property values should not
be returned by get_attr_str.
Done in r31509
Fixed in r31508
It turns out that the namespace was a red herring. The real problem is
that when iterating over a hash, you cannot assign to a PMC register; it
must be a string register. So if the base collection is a hash, this
segfaults:
$P0 = shift iterator
But this works fine:
$S0 =
rakudo: sub foo($x?, :$y = 2){ say $x~|~$y}; foo(:y(3));
exp_evalbot
OUTPUT[|]
This appears to be a bug in Parrot (now RT#54860). When that's fixed
this one should be fixed also.
RT#54860 is fixed, verified:
rakudo: sub foo($x?, :$y = 2){ say $x~|~$y};
I've recently commited a fix on null string constants. I think it was
the same problem described here. I compiled the pir file and pdumped
without a problem, it shows the DATA = NULL my fix introduced.
Can you verify the problem is gone?
This falls under the I/O PDD, the next milestone. Hold for a couple of
days. I've added it to the tasklist for the milestone:
The print and say opcodes had already been changed some weeks ago, now
both call PIO_printf on INT and NUM.
By the way, now FLOATVAL_FMT is used instead of %f
Fixed in r30870, added a test in r30900. Closing ticket.
Added a test in r30902. Closing ticket.
The code in this ticket does not parse. Is using obsolete syntax? Can
someone provide an updated version?
Applied in r30907, thanks.
No objections and no problems, closing ticket.
PDB_next no longer executes opcodes by himself, now is done in the
debugger runloop. Closing ticket.
Done in r30574
Fixed in r30533
Closing ticket
Fixed in r30537, closing ticket.
Done in r30570
Verbose output is now controlled by the 'echo' command. If more debugger
output control is needed, create specific tickets.
Fixed
Solved in r30203, debugger command line buffers are now created and
destroyed during creation and destruction of the debugger instance.
Closing ticket.
Added NEWS entry in r29587. Closing ticket.
Comments on irc confirms the problems are solved. Closing ticket.
On Mie. Mar. 14 11:46:38 2007, [EMAIL PROTECTED] wrote:
I keep getting a test failure on t/op/stringu.t with test 25 on
ppc-darwin(and likely all big endian systems with icu installed).
Parrot outputs \x00A\x00B when the test expects A\x00B\x00 to be
printed.
Is this still a problem?
This problem is fixed by other similar problem whose ticket was not
linked to this. r29358 unskip the test.
Closing ticket.
fperraud fixed an issue in lib/Parrot/Docs/Section/C.pm in r29329
Closing ticket
Closing ticket
The const string bug has been solved, so this patch is less useful.
Also, some benchmarking shows no significant improvements.
So, ticket rejected.
imcc_init is now called during interpreter initialization. Does that
solve this problem?
Hearing no objections, ticket closed.
Closing ticket
Closing ticket
After some discussion on irc, rejected, it only hides problems.
Applied in r29250
Patch applied in r29201, keep ticket open for some days.
Closing ticket
Applied in r29171
Rejected TODO item, closing ticket.
Given the previous comments, and having now some working code that
depends of *not* throwing, I will close this ticket in a few days if no
one objects.
The attached patch changes string_rep_compatible so that when called
with utf8_encoding and iso_8859_1_encoding returns utf8. Looks that this
solves the problem and breaks nothing.
Index: src/string.c
===
--- src/string.c (revisión:
This is a cleaner version.
Index: src/string.c
===
--- src/string.c (revisión: 28553)
+++ src/string.c (copia de trabajo)
@@ -265,7 +265,7 @@
/* Set up the cstring cache, then load the basic encodings and charsets */
if
Forget previous patch, is broken. I'll keep working on it.
Another try. Builds and pass tests both with C and C++.
Index: src/string.c
===
--- src/string.c (revisión: 28565)
+++ src/string.c (copia de trabajo)
@@ -265,7 +265,7 @@
/* Set up the cstring cache, then load the basic
By chromatic's suggestion, here is a different approach: change pmc_type
signature to allow a null string argument, returning enum_type_undef in
that case.
Other changes in this patch are replacing 0 with enum_type_undef in the
same function, and adding a test in t/pmc/namespace.t checking that
Another attempt: this is a minimalistic change that does not broke any
test in parrot nor in rakudo, and can avoid segfaulting in other related
usages.
Index: src/pmc/namespace.pmc
===
--- src/pmc/namespace.pmc (revisión: 28239)
+++
On Mie. Jun. 11 06:48:06 2008, bacek wrote:
Trivial reproducible bug: in rakudo 'say 1 ~~ Perl6Scalar'.
There is patch for src/ops/object.ops
I tried another way: less checks, not more. See attached patch.
$ ./perl6 -e'say 1 ~~ Perl6Scalar'
Null PMC access in invoke()
current instr.:
Given that the patch has been applied, and the hcf issue is explained
and reflected in #55040, I close this ticket.
Hearing no opposition, ticket closed.
The opcode tested crash parrot intentionally, a crash is the intended
result, not a bug.
Closed.
Closed.
59 matches
Mail list logo
