Re: [perl #39855] [CAGE] configuration: define MIN/MAX macros for all integral typedefs
It looks like those comments in platform_limits.h are out-of-place. PARROT_INTVAL_MIN and PARROT_INTVAL_MAX are defined in include/parrot/config.h, although the definition may not be as flexible as the macros in perl.h that Nicholas mentioned. It might be beneficial to incorporate them into what we're currently using, but I'm not a good judge of that. The definitions in parrot's config.h come, as one would expect, from config/auto/format.pm. (TT #530 addresses this.) It should be pretty simple to add the code needed to figure out which macros to use for the missing min/max values. platform_limits.h is intended for platforms where there is no limits.h and the macros must be taken from another include file, or explicitly defined. Also, when someone wants to build with different integer types and the detection of appropriate limit values for that types fails. config.h conditionally does his own definitions after including platform_limits. If that definitions do the right thing platform_limits does not need to do nothing. Consequently, the generic version does nothing. -- Salu2
Re: [perl #44499] [TODO] Move cstrings to String Structure
I tried to apply this patch to svn head, but it's different enough that much of it will need to be rewritten. If this is something worth pursuing, I'm willing to reimplement and apply the patch (if NotFound isn't interested). If not, this ticket should be rejected. Reject it. I'll take a look at the last patch to see if something is still applicable. -- Salu2
Re: [perl #39855] [CAGE] configuration: define MIN/MAX macros for all integral typedefs
It's great to have INTVAL and UINTVAL, but without MAX_INTVAL it's kind of hard to work with them in some respects. All integral typedefs should have min/max macros. Syntax not a big deal, it can be fixed later, just don't break anything when introducing them. Nothing has happened on this ticket since it was introduced in 2006. Do we need MIN/MAX macros? If so, why, or where do we expect them to be used? The current intended names for that macros are PARROT_INTVAL_MAX, PARROT_INTVAL_MIN, and so on. The last work in this matter is: include/parrot/platform_limits.h -- Salu2
Re: [perl #43687] [TODO] combine abstract search with other search in lib/Parrot/Docs/File.pm
I propose rejecting this ticket as unnecessary. The code may not be optimal, but it works fine and isn't even particularly hacky or broken. +1 -- Salu2
Re: [perl #56262] [RFC] chr opcode
I'll apply this patch in two days if I hear no objection -- or sooner if the other contributors to this thread approve. +1 -- Salu2
Re: [perl #37700] [TODO] Changing Default STDOUT/STDERR Filehandles for PIR Code
Method added in r36305, created TT #264 about it. -- Salu2
Re: [perl #37700] [TODO] Changing Default STDOUT/STDERR Filehandles for PIR Code
On Wed, Dec 17, 2008 at 12:52 AM, chromatic chroma...@wgz.org wrote:
On Tuesday 16 December 2008 15:40:32 Allison Randal via RT wrote:
The simple solution is to add opcodes for 'setstdin', 'setstdout', and
'setstderr' that change the interpreter's stored FileHandle PMCs to a
PMC passed in as an argument. This will not effect any C code that
directly calls the low-level read/write functions instead of using the
Parrot_io_* functions, but then C code should pretty much always use the
Parrot_io_* functions. (Some exceptions to the general rule apply, like
when the code specifically needs to override any user changes to
STD[IN|OUT|ERR]).
Do these need to be opcodes? Can they be methods on the interpreter instead?
Here is patch:
Index: src/pmc/parrotinterpreter.pmc
===
--- src/pmc/parrotinterpreter.pmc (revision 36072)
+++ src/pmc/parrotinterpreter.pmc (working copy)
@@ -30,6 +30,8 @@
#include parrot/dynext.h
#include pmc_class.h
+#include ../io/io_private.h
+
/*
=item Cvoid
@@ -718,7 +720,17 @@
Parrot_register_HLL_type(INTERP, hll_id, core_type_id, hll_type_id);
}
+METHOD stdhandle(INTVAL fileno, PMC *newhandle :optional) {
+PMC * handle = PMCNULL;
+if (fileno = PIO_STDIN_FILENO fileno = PIO_STDERR_FILENO) {
+handle = interp-piodata-table[fileno];
+if (!PMC_IS_NULL(newhandle))
+interp-piodata-table[fileno] = newhandle;
+}
+RETURN(PMC *handle);
+}
+
}
/*
And a test:
$ cat handle.pir
.sub main
.local pmc interp, nullout, stdout
interp = getinterp
nullout = open '/dev/null', 'w'
stdout = interp.'stdhandle'(1, nullout)
stdout.'print'(Hello\n)
say 'Hi'
interp.'stdhandle'(1, stdout)
say 'Bye'
.end
$ ./parrot handle.pir
Hello
Bye
--
Salu2
Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC
I just tried to build parrot with g++ on darwin/intel to see if I could replicate the initial failure reported in the ticket, but am unable to. (g++ is detected as gcc, and then we pass it an option that makes it explode.) What Configure options do you used? I usually do: --cc=g++ --cxx=g++ --ld=g++ --link=g++ -- Salu2
Re: [perl #55504] [BUG] Failing test t/op/spawnw.t
On Sun, Nov 23, 2008 at 10:41 PM, James Keenan via RT [EMAIL PROTECTED] wrote: On Wed Sep 10 19:48:04 2008, [EMAIL PROTECTED] wrote: Can someone evaluate where we stand with respect to the issues in this RT? Thank you very much. kid51 Still hoping for feedback on these issues. Several parts of the configure process now set LANG to C before doing some check and restore it after. I didn't fixed yet the bison part expecting a more generic approach under the assumtion that the few people that use --maintainer can set LANG themselves before configuring. Don't have any notice of someone having the bad lang problem trying the PERL_BADLANG approach. We can just set this value in Configure.pl and in the Makefile and check smolder results for possible problems. -- Salu2
Re: [perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
With the following example (and the other patches to Parrot_ex_throw_from_op_args added by NotFound++), I'm able to run the following version and get to 250,000 without any difficulty. $ cat x.pir .sub 'main' .local pmc i i = new 'Integer' do_loop: say i push_eh do_inc $P0 = find_method i, succ i.$P0() do_inc: pop_eh inc i goto do_loop .end $ ./parrot x.pir 0 1 2 3 4 ... 249997 249998 24 25 250001 250002 ^C (The top(1) command on my machine seems to indicate a small memory leak in the above, but it does run a significant ways, and I didn't investigate further.) I've noticed an anomaly: if you add .get_results($P0) after pop_eh nothing bag happens, but if you put it before, it starts leaking a lot of memory. -- Salu2
Re: [perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
I've noticed an anomaly: if you add .get_results($P0) after pop_eh nothing bag happens, but if you put it before, it starts leaking a lot of memory. Is that after r32226? Before it was leaking both ways, I think. -- Salu2
[perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
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 Parrot_ex_throw_from_op_args to simplfy the throwing in cases like this. But we still need a way to handle the exceptions thrown from C.
Re: [perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
I'm working on a patch that defines the helper function Parrot_ex_throw_from_op_args to simplfy the throwing in cases like this. After discussion in #parrotsketch, added this function in r3 -- Salu2
Re: Parrot on mobile platforms?
Don't you think it would be important to start working in this direction? Maybe to try to get someone work on this or to get sponsorship in that direction? I think the easier step towards this goal may be to make cross compiling works with two well-known platforms. For example, targeting mingw from linux, using the cross mingw package from the distro. -- Salu2
Re: [perl #48014] [DEPRECATED] PMC union struct
On Wed, Oct 22, 2008 at 6:28 PM, Bernhard Schmalhofer via RT [EMAIL PROTECTED] wrote: Done in r30914: changed name to Parrot_type_attributes, fixed codingstd, changed also pmc in languages lua and perl6, and updated pdd17_pmc.pod Does this mean that this ticket can be closed and the deprecation item in DEPRECATED.pod be removed? No, this was just a helper step. -- Salu2
Re: [perl #60060] [BUG] Parrot_readbc() does too many stat()s
On Thu, Oct 23, 2008 at 1:43 AM, via RT Stephane Payrard [EMAIL PROTECTED] wrote: This results in 4 stat()s per pbc. opening the file and using Parrot_fstat_info_intval() instead of Parrot_stat_info_intval() will be less costly. this means retooling readbc() that now stats the file to verify it can open it. I think will be faster and cleaner to have a function that takes a file handler. That way the search functions can just try to open a file instead of doing stat call for any directory in the search paths, and then pass a file path to do even more stat on it. -- Salu2
Re: [perl #57690] [BUG] make headerizer breaks build
As of r32075, 'make; make headerizer' still breaks the build. Fixed in r32079 -- Salu2
Re: [perl #58988] [RFC] Parrot_get_runtime_prefix function
'STRING *' is vastly preferable to 'char *' anywhere it can be used. Mark the old one as deprecated, replace all calls to 'Parrot_get_runtime_prefix' with calls to 'Parrot_get_runtime_path', and after a standard one release deprecation cycle remove the old function. Replaced a remaining usage and added a note in the =item of Parrot_get_runtime_prefix about his deprecation in r32054 -- Salu2
[perl #59544] open(null) kills parrot
Problem fixed and test added, closing ticket.
Re: [perl #59722] [TODO] implement rest of sysinfo_s code
CPU_ARCH implemented in r31982 -- Salu2
Re: [perl #59544] open(null) kills parrot
Where to put a test for this? There is no t/ops/io.t and creating a file for each io opcode seems excessive Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one on the list, which I'll create a branch for later this week). Created and added open null tests in r31950 -- Salu2
Re: [perl #59722] [TODO] implement rest of sysinfo_s code
On Wed, Oct 8, 2008 at 6:34 PM, via RT Jerry Gay [EMAIL PROTECTED] wrote: currently, the sysinfo_s op, implemented in src/inter_misc.c, is incomplete: (snip) one effect of this partial implementation is that the $*OSVER variable in rakudo always contains the empty string. Initial implementation of OS_VERSION and OS_VERSION_NUMBER commited in r31387 CPU_ARCH and CPU_TYPE may need some more config support. By the way, why those last items does not have the PARROT_ prefix? -- Salu2
[perl #59630] [BUG] Complex subtraction fails for subclasses of Complex
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
===
--- src/pmc/complex.pmc (revision 31697)
+++ src/pmc/complex.pmc (working copy)
@@ -758,14 +758,21 @@
*/
MULTI PMC *subtract(Complex value, PMC *dest) {
-if (dest)
-VTABLE_morph(INTERP, dest, SELF-vtable-base_type);
+if (dest) {
+ if(! VTABLE_isa(INTERP, dest, CONST_STRING(INTERP, 'Complex')))
+VTABLE_morph(INTERP, dest, SELF-vtable-base_type);
+}
else
-dest = pmc_new(INTERP, SELF-vtable-base_type);
+dest = VTABLE_clone(INTERP, SELF);
-RE(dest) = RE(SELF) - RE(value);
-IM(dest) = IM(SELF) - IM(value);
-
+{
+FLOATVAL re1 = VTABLE_get_number_keyed_int(INTERP, SELF, 0);
+FLOATVAL im1 = VTABLE_get_number_keyed_int(INTERP, SELF, 1);
+FLOATVAL re2 = VTABLE_get_number_keyed_int(INTERP, value, 0);
+FLOATVAL im2 = VTABLE_get_number_keyed_int(INTERP, value, 1);
+VTABLE_set_number_keyed_int(INTERP, dest, 0, re1 - re2);
+VTABLE_set_number_keyed_int(INTERP, dest, 1, im1 - im2);
+}
return dest;
}
Re: Should the Length of string_substr() Ever Be Negative?
(I'm making as many parameters and struct members unsigned as possible so that the compiler can warn us if we ever use signed values with them. This is one nice way to check some of our assumptions.) But sting_substr is called directly from opcodes, then the simpler way is that his arguments reflects directly those of the registers implied, and make all checks and conversions desired inside the function. -- Salu2
Re: Should the Length of string_substr() Ever Be Negative?
I'd say the fact that it has to do checking within the routine anyway is no reason not to add checks to catch errors earlier. Making the signature programmer-friendlier is like adding javascript validation to a web form - sure, the target of the submission still has to do its own validation, but it's still helpful for the user to do it up front. But a fake signature makes errors harder to find and can make optimized builds works different as normal ones. We had already have lot of problems with arguments declared as non null that the compiler can't enforce. We can make two versions of the risky functions, but then we have the problem of ensure that the correct one in used i each case. -- Salu2
Re: Should the Length of string_substr() Ever Be Negative?
But a fake signature makes errors harder to find and can make optimized builds works different as normal ones. I'm not sure how the signature is fake. An unsigned integer is a subset of integer. Parrot doesn't have a set of $U registers for unsigned ints, does it? I suppose the routine that's directly called from PIR could be wrapped by a separate one that gets called from Perl6 by way of the stricter signature. The function is called from an opcode with the value of a signed integer register (yes, there are no unsigned integer registers). Then if the function parameter is declared as unsigned, in that sense is fake. Unsigned integer is not a subset of integer, it has a broader positive range. All this in the parrot opcodes and his C support functions level. But if you talk about perl6, this is not applicable, the perl6 function can have any wanted signature, it will never call the function directly, it emits the opcode that will call it and can insert any check or change of his argument. If the sub implementation allows accidental sign changes, this will be his own bug. -- Salu2
[perl #46629] [TODO] [C] Implement multiplication of integers with complex numbers
Done in r31684 after MMD changes, adding the test from the previous patch.
[perl #48108] [BUG] downcase opcode fails on unicode strings w/o icu
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 revisited during strings pdd work). Extend it to codepoints in the iso-8859-1 range is not so easy, will need to check the string content. Attempt to transcode will be not helpful if the transcode function used also require ICU.
Re: [perl #59590] Parse Error for 'make splint'
When fiddling with 'make splint' I ran into a Splint parse error:
src/exceptions.c:500:25: Variable size initialized to type int, expects
size_t: backtrace(array, 32)
src/exceptions.c:503:36: Unrecognized format code: %zd stack frames (max
trace depth is %d).\n
src/exceptions.c:507:17: Unrecognized identifier: Dl_info
src/exceptions.c:507:26: Parse Error. (For help on parse errors, see
splint -help parseerrors.)
The backtrace function returns int, but this code was using size_t,
and the size_t usage is the reason for the z format modifirer. Fixed
in r31617
'dladdr()' and 'Dl_info' seem to be not in POSIX, but seem to be a
common extension.
I tried passing '+gnu-extensions' on the splint command line, but that
didn't help.
I also tried to define the missing type Dl_info with a preprocessor
directive, but that didn't help
either.
SPLINTFLAGS_TEST = \
+posixlib
-DDl_info=struct { const char *dli_fname; void *dli_fbase; const
char *dli_sname; void *dli_saddr; } \
You can try: -D__GNU_SOURCE
--
Salu2
Re: [perl #59614] Wrong PC/line reported in handler arg-passing error
The problem is that pc 9/line 3 is the location of the invokecc instruction that calls the erring test sub, not the location of the get_results instruction where the problem is detected. I'm not sure how to fix this, because it messes greatly with the modularity of how return addresses are tracked. But I think it really ought to be fixed before the next release -- that or the arg-checking requirement for exception handlers should be relaxed, at least temporarily. I stumbled onto this when Kea-CL fell afoul of the exception handling arg change introduced in r31294 (about which I don't recall seeing any mention on the list). Because of the misplaced error message, it took me a while to track it down. I had the same problem some days ago, and also take me a while to figure the reason. I agree this is an annoying problem. -- Salu2
Re: [perl #59112] Failing test in t/examples/library.t
Your point is very interesting. However, if you believe this issue merits more extended discussion, I would recommend you open up a new RT ticket, perhaps in the [RFC] category (or [RFP] or whatever it's called). I would like to keep the discussion in *this* RT focused on the issues Carl raised with respect to config step auto::pcre. We need to know what's happening. I see two possibilities: - The pcre library detected by the configure probe is static. Don't know what to do in that case, with static linkage the dynamic symbols needed for NCI may not be available, some static support for the library inside parrot may be required. - The library is dynamic but cannot be located at runtime. This can happen if is located in a place the dynamic linker does not search. In that case, the symbols can be found in the main process (at least in Linux) if the dynamic loading attempt fails. We can check this (in Linux, again), by looking for pcre in the output of: ldd parrot We must know what pcre library files are available, where are located, and if this place is searched by the dynamic linking at runtime (in Linux, listed in ldconfig configuration files). The problem can be just the lack of a libpcre.so symbolic link to libpcre.so.some_version_number Note that in the dynamic case, if the library can be found by the dynamic runtime linker we don't need any configure support at all. You can build --without-pcre and have pcre available anyway. -- Salu2
Re: [svn:parrot] r31570 - trunk/src/ops
On Thu, Oct 2, 2008 at 11:00 PM, chromatic [EMAIL PROTECTED] wrote: Can anything in the PIO_open() path throw an exception? If so, these strings will leak. In a first look, it does not throw, but given that it calls layer functions, one never can be sure. But I don't see a better solution that does not involve exception handlers, until we start working on the strings pdd. (This makes me wonder *why* PIO_open() takes C strings.) I thinked about that, but fixing only that function will be a liitle gain, just moving the problems to another point. Changing the IO layer interface can be the better way. -- Salu2
[perl #59532] say typeof(namespace) gives a segfault
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.
Re: [perl #59538] [BUG] imcc freezes (compute_dominance_frontiers) -- Possible fix
Looks correct. Tested on Linux i386, parrot test pass, perl6 test pass, test program in the RT does not hang and the generated pbc contains the expected opcodes. Good work! -- Salu2
Re: [perl #59546] [PATCH] Combine hash exists/get into a new opcode (5% performance gain)
I think will be better the other way, using the return value to flag existence, and passing a pointer to store the result. This will allow shorter and cleaner code. -- Salu2
Re: [perl #59544] open(null) kills parrot
(I'd expect an exception to be raised instead.) PIR code: ..sub 'foo' :main $S0 = null $P0 = open $S0, '' ..end output: src/string.c:2106: failed assertion 's' Fixed in r31565 , but several questions opened: Where to put a test for this? There is no t/ops/io.t and creating a file for each io opcode seems excessive Care must be taken in all places that uses string_to_cstring after some resource allocation (for example, other string_to_cstring) to avoid leaks. -- Salu2
Re: [perl #59546] [PATCH] Combine hash exists/get into a new opcode (5% performance gain)
I think will be better the other way, using the return value to flag existence, and passing a pointer to store the result. This will allow shorter and cleaner code. Another possibility might be to avoid the extra parameter altogether, returning NULL (not PMCNULL) if the element doesn't exist. I think that way is less clear, and I like better to have the same interface for PMC and non PMC versions. -- Salu2
Re: [perl #59542] null hash keys give segfault
maybe a duplicate of #43485 PIR code to reproduce: ..sub 'foo' :main $S0 = null $P0 = new 'Hash' # no crash without next line $P0['yum'] = 5 $P1 = $P0[$S0] ..end Fixed in r31566, together with a test adapted from this code. Don't know if is related to #43485 ? -- Salu2
Re: [perl #59112] Failing test in t/examples/library.t
auto::pcre - Does your platform support pcreyes, 6.7. With this version installed, I could not reproduce the error you reported. See: http://smolder.plusthree.com/app/public_projects/tap_stream/5784/392 So could this be a problem with PCRE 7.7, or how it installs on your OS? The config test for pcre try to compile a test program. The pcre.pir dynamically loads the pcre library. So if, for example, you have only a static pcre lib, it will detect it but fails to use. -- Salu2
Re: [perl #59112] Failing test in t/examples/library.t
The config test for pcre try to compile a test program. The pcre.pir dynamically loads the pcre library. So if, for example, you have only a static pcre lib, it will detect it but fails to use. That makes sense. Can we change the config test to link against a dynamic pcre? Patches welcome. I'm cc-ing ambs, who was the original contributor of this config step and the associated C probe, to see if he can help out. I see a more generic problem. Several modules add lib links to the parrot executable. Makes sense to link static libraries if that is the intention, but is not convenient to link dynamics that can be, and are, dynamically linked at runtime. This way adds unneeded dependences to the binary packages. Also, if the libraries are linked to the parrot executable or the parrot library makes no sense to fail if they can not be located at runtime. We need some way to know that the library is already linked and his symbols available, without forcing all modules that use a library to check for both cases. -- Salu2
[perl #46667] [TODO] [C] Do we need properties in the default object system?
This check can be removed from default.pmc. Property values should not be returned by get_attr_str. Done in r31509
[perl #57690] [BUG] make headerizer breaks build
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 the problem. Alternatively, we could rearrange the way the header files are ordered/created, and ensure all function prototypes are included after all data type definitions. Or we can declare the typedef for IMC_Unit in imc.h before the #include of the other imcc headers, with a forward declaration of _IMC_Unit. Done in r31517. Ticket let opened to hear possible problems.
[perl #46083] [TODO] Fix memory leak in src/pmc/parrotio.pmc:open()
Fixed in r31508
[perl #54220] [BUG] Segfault when iterating with PMCs instead of strings
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 = shift iterator Of course, segfaulting is still *bad*, so this ticket should remain open and switch focus to the real problem. Is this still a problem? I do a few tests and all seems to work.
Re: [perl #59336] [BUG] Parrot fails integer comparisons when integers are 2^31 apart
I suspect the problem is that the integer greater than operation is performing a subtraction between the two (signed long) values being compared, but the result of the subtraction is outside of the range of signed longs. Correct. Fixed in r31419 -- Salu2
Re: [perl #57728] [TODO] avoid 2038 bug if we haven't already.
we definitely need date/time pmc(s?) not only to have a common epoch across platforms, but to deal with 2038. in particular, we should leverage schwern's work on perl to address the 2038 bug. ~jerry We definitely haven't already fixed this. Here's an easy test using libfaketime: $ cat time.pir .sub main :main .local int time_int time time_int say time_int .end $ ./parrot time.pir 113121 $ LD_PRELOAD=/usr/src/libfaketime-0.8/libfaketime.so.1 FAKETIME=+40y ./parrot time.pir -1811314167 We can't make this example work. If you use an INTVAL, and the INTVAL can be signed 32 bits, there is no way to have a more than 31 bits unsigned stored on it as such. -- Salu2
Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.
Thanks. There is little bit more patches. Applied in r31381, with some changes in the env.pmc part to avoid repeated calls. -- Salu2
Re: [svn:parrot] r31324 - trunk/src/pmc
Will be better to change FixedIntegerArray to implement elements by calling get_integer? And then use get_integer in all relevant places in ResizableIntegerArray? Looks more clear to me to get the value with get_integer and set it with set_integer_native. Yes, that's definitely better. Done in r31361 (fixed) and r31362 (resizable). -- Salu2
Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.
Patches to bigint, complex, float and string applied in r31370, thanks. -- Salu2
Re: [perl #57776] [BUG] PIO_buf_read segfault
Applied with some changes in r31335 -- Salu2
Re: [svn:parrot] r31324 - trunk/src/pmc
On Mon, Sep 22, 2008 at 12:34 AM, NotFound [EMAIL PROTECTED] wrote:
+=item Cvoid delete_keyed_int(INTVAL key)
+
+Removes the element at Ckey.
+
+=cut
+
+*/
+
+VTABLE void delete_keyed_int(INTVAL key) {
+INTVAL size = PMC_int_val(SELF);
With the use of the set_integer_native entry later, this should probably be:
INTVAL size = SELF.get_integer();
I borrowed it from the shift and unshift functions. Maybe a complete
revision of this PMC will be the way to go. I'll take a look tomorrow.
After some looking: other functions on this pmc uses elements, that is
implemented in the parent, FixedIntegerArray. FixedIntegerArray
implements get_integer by calling elements, so looks like elements is
the 'boss'.
Will be better to change FixedIntegerArray to implement elements by
calling get_integer? And then use get_integer in all relevant places
in ResizableIntegerArray? Looks more clear to me to get the value with
get_integer and set it with set_integer_native.
--
Salu2
Re: [svn:parrot] r31324 - trunk/src/pmc
+=item Cvoid delete_keyed_int(INTVAL key)
+
+Removes the element at Ckey.
+
+=cut
+
+*/
+
+VTABLE void delete_keyed_int(INTVAL key) {
+INTVAL size = PMC_int_val(SELF);
With the use of the set_integer_native entry later, this should probably be:
INTVAL size = SELF.get_integer();
I borrowed it from the shift and unshift functions. Maybe a complete
revision of this PMC will be the way to go. I'll take a look tomorrow.
--
Salu2
Re: [perl #58866] calling a PIR sub with 206 params segfaults parrot
I changed the fix in r31230 to allocate char instead of char *, adjusted the formula for buffer size and added a comment explaining it to lower the level of black magic, and added a check for each item, dropping the XXX comment that asked for it. I hope this is enough understanding of the error ;) -- Salu2
Re: [perl #58726] [PATCH] add the option encoding to Configure.pl
Can you explain a bit more about the rationale for adding this option to Configure.pl? I think I is necessary to tell parrot to work on a computer with utf-8 encoding also with the same encoding, so that for example the following PASM-code works: set S0, Ö123\n That code is not supposed to work. Encoding and charset must be specified. Is not good that pir or pasm code meaning be dependent of locale specifics of the system. Also in several operating systems is not the computer who is working with some charset and encoding or other, is each process (depending of user settings on locale env vars, for example). So establishing an immutable global default is not a good idea. -- Salu2
Re: [svn:parrot] r31230 - in trunk: compilers/imcc src src/pmc
On Thu, Sep 18, 2008 at 8:14 PM, chromatic [EMAIL PROTECTED] wrote:
-char* buf = mem_allocate_n_typed(5*n+1, char *);
+/* Assumptions:
+ * Flags has no more than 3 hex digits
+ * Plus 0x and , gives 6 char for arg
+ * 4 more for: ( , ), and
+ * 1 more for C string 0 delimiter
+ * Last item has no , but we can forget that to avoid
+ * to have to check for 0 args.
+ */
+unsigned int bufsize = 6 * n + 5;
+char * buf = mem_allocate_n_typed(bufsize, char);
strcpy(buf, \();
for (i = 0; i n; i++) {
The comment helps, but defining these magic numbers as magic constants might
be even clearer (but please keep the comment).
I think that setting a constant is sort of establishing it as a
documented value, and I don't think that document who many digits can
have the hex representation of flags is good, or it must be done in a
file other than the one that defines the flags.
+PARROT_ASSERT(strlen(buf) + strlen(s) bufsize);
+strcat(buf, s);
That only helps with debug builds; if there are possible inputs we won't
discover in our testing, we might as well make this an unconditional test and
throw an exception if something goes wrong here. IMCC is user-facing, so I
want to be paranoid.
After some thinking I must agree. I hope that this code will be
refactored before 1.0, but we can't be sure.
The problem is that I don't know what severity must be used, and if it
the exception must be catched by the main imcc entry points or let it
propagate to the caller. Maybe all imcc fail conditions must throw
exceptions, for the benefit of load_bytecode invocations.
--
Salu2
Re: [perl #51262] [BUG] Segfault in pdump
Changed in r31328: now string DATA use string_escape_string and delimit with double quotes, avoiding the need to a special case for empty strings and giving less problematic results with non ascii encodings and control characters. -- Salu2
Re: [perl #58866] calling a PIR sub with 206 params segfaults parrot
It certainly shouldn't segfault. But, the question is: why does it segfault at 206 parameters? Throwing an exception to avoid an error we don't understand isn't good for the long-term health of the VM. The problem is located inside compilers/imcc/pcc.c:pcc_get_args function. It has the comment /* XXX check avail len */ just at the point where the segfault happens. char buf[1024] is the variable overrunned. -- Salu2
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
Defining the hash entries for the subs in PIR syntax is awful. So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. For p6 we must ensure that every parrot package has a perl6 also then. Not good. So pl, pir or the simple nqp. The libs and scripts could be written in Perl 6 and compiled to bytecode. In this way the languages would need no full Perl 6, just some *.pbc files. That can open a can of worms. The .pbc generated from perl6 will need installed perl6 .pbc files for perl6 objects, builtins, who knows what more. Worse, it can use eval'ed strings that needs the compiler. It will not be nice to talk about language neutrality while requiring perl6 to install a completely unrelated language. -- Salu2
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal [EMAIL PROTECTED] wrote: chromatic wrote: That C string leaks. We should have a diagnostic printf which supports the %Ss format we use in exception formatting strings. We have one, it's called PIO_fprintf. But, it's only used once in the repository, in an STM macro. We have more: PIO_printf, PIO_eprintf, Parrot_printf, Parrot_eprintf and Parrot_fprintf. The Parrot_ ones are a wrapper around the PIO_s, with added check for extern usage, and that does not need #include io files. The eprintf ones are adequate for diagnostic messages. But note that his usage with a NULL interpreter argument is flawed, only adequate for plain strings. But if you have a parrot string surely you have a parrot interpreter. -- Salu2
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
We have more: PIO_printf, PIO_eprintf, Parrot_printf, Parrot_eprintf and Parrot_fprintf. The Parrot_ ones are a wrapper around the PIO_s, with added check for extern usage, and that does not need #include io files. Yes, to be more accurate, we have a whole range of PIO functions. But, the fact that they're used so rarely makes me doubt whether they're particularly reliable. From other perspective: if they are not used, we never be sure that they are reliable. If we access to string internals to avoid his usage, we are actively making strings less reliable. And no wonder that %Ss is rarely used, a lot of people doesn't even know that it exists. And if they never see it used in place of code where will be the correct solution, we can hardly blame them. By the way, as mentioned in other thread there is a problem with plain %s in parrot printf-alike functions. It does not handle well a NULL c string. This must be fixed. And before, given the current implementation, the behavior of string_make and his successor in the strings pdd, when receiving a NULL c string must be documented and implemented, or we risk to plague the code base with lots of more workarounds. -- Salu2
Re: [perl #51262] [BUG] Segfault in pdump
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? I assume you are referring to r30756 of src/packdump.c? Yes, that does avoid the segfault (though it reports the string value as NULL instead of ''). But isn't this really a bug in PIO_printf handling of %.*s? The NULL is my fault, I put it that way for easy searchability while testing. You are right, the value is an empty string and must be reported like that. The printf-alike parrot functions seem to have a problem with NULL c strings, yes, we will solve this quickly (I hope). But printf-alikes can't know the NULL is really a parrot empty string, because we dropped that information by the fact of passing a c string instead of the parrot string. So I think the correct solution will be to stop accessing string internals and using the parrot strings api. In the meantime, what we need to know now in this ticket is if the segfault is no longer present in all platforms reported. -- Salu2
Re: building parrot with clang + llvm
On Wed, Sep 10, 2008 at 8:12 PM, chromatic [EMAIL PROTECTED] wrote: The line numbers reported by clang seem sensible enough, but do they match values in src/pmc/default.str? Mine contains: #define _CONST_STRING_45 80 #define _CONST_STRING_103 534 #define _CONST_STRING_144 _CONST_STRING_103 #define _CONST_STRING_182 _CONST_STRING_144 #define _CONST_STRING_626 535 #define _CONST_STRING_1033 3 #define _CONST_STRING_973 536 #define _CONST_STRING_951 _CONST_STRING_973 These are .pmc file line numbers, it isn't? Looks like llvmc does not honor #line directives. -- Salu2
Re: [perl #58704] [BUG] t/src/compiler.t failures with VC++ / Win32
On Tue, Sep 9, 2008 at 5:23 AM, via RT Tim Heckman [EMAIL PROTECTED] wrote: # New Ticket Created by Tim Heckman # Please include the string: [perl #58704] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58704 link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib But, if I run this command using the documented linker option of /LIBPATH it *still* fails. link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib What are the error messages in this case? -- Salu2
Re: request for help (only a little :-): build pirc on linux
I put the commands that I'm using in the README file (but that's for MSVC on windows), but I don't have any knowledge on how to do this on linux. There is no README file in compilers/pirc/new -- Salu2
[perl #54800] ignoring named arguments if there is an optional positional argument missing
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}; foo(:y(3));
OUTPUT[Use of uninitialized value|3]
[perl #51262] [BUG] Segfault in pdump
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?
[perl #55196] [BUG] print/say opcodes have different float precision
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
Re: [perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful
On Mon, Sep 8, 2008 at 9:31 AM, Allison Randal via RT [EMAIL PROTECTED] wrote: Agreed that this particular ticket is not useful. Resolve it and replace it with a [CAGE] ticket with explicit instructions on converting all existing 'sprintf', 'strcat', etc calls with calls to 'snprintf', 'strlcat', etc. (Also include a list of all calls that should be converted.) I disagree on the all part. strlcat and strlcpy are not always the best repalcement. When the C string length is known memcpy is a simpler and faster solution. For example in config/gen/platform/generic/env.c we have: int name_len = strlen(name); int val_len = strlen(value); char *envs = malloc(name_len + 1 + val_len + 1); if (envs == NULL) return; /* Save a bit of time, by using the fact we already have the lengths, avoiding strcat */ strcpy(envs, name); strcpy(envs + name_len, =); strcpy(envs + name_len + 1, value); The memcpy way can be: memcpy(envs, name, name_len); envs[name_len] = '='; memcpy(envs + name_len + 1, value, val_len + 1); This code can be encapsulated on a function or a macro, and add inside it checks for non-nullness and lengths in debug builds. Regarding snprintf, according linux man page is in the C99, BSD and XOPEN standards, not on older ansi C, and I think we don't have that as a requirement for the C compiler usable to build parrot. And a replacement for this is not so easy to write and test as the others. -- Salu2
[perl #53926] [BUG] :optional and :slurpy :named fails when called with :named :flat
Fixed in r30870, added a test in r30900. Closing ticket.
[perl #54860] [BUG] problem with optional named parameters
Added a test in r30902. Closing ticket.
[perl #46457] [BUG][IMCC] long sub invocation with named parameters
The code in this ticket does not parse. Is using obsolete syntax? Can someone provide an updated version?
Re: [perl #48014] [DEPRECATED] PMC union struct
Reading through the updated code, it seems that (using Task as an example): Parrot_PMCdata_Task is not much clearer than the original Parrot_Task was. Let's go with: Parrot_Task_attributes A fast ack'ing of: Parrot_[_a-zA-Z]+_attributes for possible collisions shows only: Parrot_Class_nci_attributes Parrot_Role_nci_attributes We can live with this. (Fortunately, with the string PMCdata in all the type names, it should be easy to write an automatic search-and-replace.) That was the main reason for using a long ugly name. -- Salu2
Re: [perl #48014] [DEPRECATED] PMC union struct
The attached patch does it. There is a lot of changes, I suspect many of them are candidates for replacing with use of the SET_ATTR and GET_ATTR macros. Maybe defining a macro SELF_DATA_TYPE will be a convenient shortcut. Reading through the updated code, it seems that (using Task as an example): Parrot_PMCdata_Task is not much clearer than the original Parrot_Task was. Let's go with: Parrot_Task_attributes (Fortunately, with the string PMCdata in all the type names, it should be easy to write an automatic search-and-replace.) I only modified and tested parrot core, surely several languages needs some patching. Also, don't fixed line length codingstd. I expect approval before taken care of that, Otherwise approved, and thanks! Done in r30914: changed name to Parrot_type_attributes, fixed codingstd, changed also pmc in languages lua and perl6, and updated pdd17_pmc.pod -- Salu2
[perl #58680] [PATCH] new PLATFORM Linux S/390
Applied in r30907, thanks.
Re: [perl #46635] [TODO] [C] Check overflow for -maxint in absolute()
What would be the best way to handle this? We certainly don't need to do anything on systems where INT_MAX == -INT_MIN, but a simple compiler directive should help to detect that case. In the event that abs(INT_MIN) abs(INT_MAX), should we silently saturate the result to INT_MAX, or should we error? I'll be happy to put in a patch for this once I know what the behavior should be. --Andrew Whitworth Any ruling on this? The current implementation is wrong. abs takes and returns an int, but parrot INTVAL is not guaranteed to be int. Even worse, Trying to take the absolute value of the most negative integer is not defined (from the linux man page, and the C standard if I remember well). So is not granted that we can take decisions based on the result of abs, must be done before. To obtain a safe implementation, abs must be avoided. -- Salu2
Re: [perl #58308] [PATCH] Implementation fo string_str_rindex and rindex op.
Last revision of string.pmc patch, and of t/pmc/string.t patch, applied in r30853 See the ticket, several messages where not CCed to the list. -- Salu2
Re: [perl #42693] [BUG] method overload in pir subclass of pmc pccmethod leaves object undefined
coke says: The PIR code in this ticket now causes a Bus error on osx/386 (r25175) Also segfaults in linux/386 for me. I added an assertion that catch the fault in r30859 -- Salu2
Re: [PATCH][perl #58030] Bugfix of Named parameter passing errors
On Sun, Aug 17, 2008 at 9:20 AM, mhelix [EMAIL PROTECTED] wrote: The first named parameter isn't set if optional parameters are missing. The function Parrot_process_args didn't save the value of the argument. I used memcpy to copy the UnionVal. If there's a neater way to do that please fix my fix :) . It only adds a couple of lines to src/inter_call.c. Here's the diffstat output: Patch applied with some style changes in r30870 Looks like it solves several known problems, good job! -- Salu2
Re: [perl #48320] [BUG] Example in pdd23 doesn't work
On Sat, Sep 6, 2008 at 3:34 AM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
On Sat Feb 16 17:23:47 2008, coke wrote:
The example in the PDD now reads:
$P0 = new 'String'
$P0 = something bad happened
$P1 = new ['parrot';'exception'], $P0 # create new exception object
throw $P1 # throw it
This code continues to not work. Would it be DTRT to copy/pasta some
code from t/pmc/exception.t, such as the throw - no handler test?
The attached patch makes it work. It also allows:
$P0 = new 'Hash'
$P0 ['severity'] = 1
$P0 ['message'] = 'something bad happened'
$P1 = new ['parrot';'exception'], $P0 # create new exception object
throw $P1 # throw it
Not sure if this is the desired design. Comments?
--
Salu2
Index: src/pmc/exception.pmc
===
--- src/pmc/exception.pmc (revision 30822)
+++ src/pmc/exception.pmc (working copy)
@@ -101,6 +101,40 @@
/*
+=item Cvoid init_pmc()
+
+Initializes the exception with supplied values.
+
+=cut
+
+*/
+
+VTABLE void init_pmc(PMC *values) {
+Parrot_Exception * const core_struct =
+mem_allocate_zeroed_typed(Parrot_Exception);
+INTVAL ishash = VTABLE_isa(interp, values, CONST_STRING(interp, 'Hash'));
+
+/* Set flags for custom DOD mark and destroy. */
+PObj_custom_mark_SET(SELF);
+PObj_active_destroy_SET(SELF);
+
+/* Set up the core struct and default values for the exception object. */
+PMC_data(SELF) = core_struct;
+core_struct-severity = ishash ?
+VTABLE_get_integer_keyed_str(interp, values, CONST_STRING(interp, 'severity')) :
+0;
+core_struct-handled= 0;
+core_struct-message= ishash ?
+VTABLE_get_string_keyed_str(interp, values, CONST_STRING(interp, 'message')) :
+VTABLE_get_string(interp, values);
+core_struct-payload= PMCNULL;
+core_struct-resume = PMCNULL;
+core_struct-stacktrace = PMCNULL;
+core_struct-handler_iter = PMCNULL;
+}
+
+/*
+
=item Cvoid mark()
Mark any active exception data as live.
Re: [perl #48320] [BUG] Example in pdd23 doesn't work
After some brief comment on irc, applied in r30833 -- Salu2
Re: [perl #48320] [BUG] Example in pdd23 doesn't work
Sorry, the code I poste was bad. The valid form is: $P1 = new ['Exception'], $P0 # create new exception object -- Salu2
Re: [perl #58438] [PATCH] nci can't pass NULL string arguments
Hearing no objections, and because I needed it to be able to do tests with mysqlclient, applied in r30790 -- Salu2
[perl #46119] [TODO] Handle resume opcodes in PDB_next()
PDB_next no longer executes opcodes by himself, now is done in the debugger runloop. Closing ticket.
Re: struct and pointer to pointer in ATTR
On Thu, Aug 28, 2008 at 11:33 AM, Allison Randal [EMAIL PROTECTED] wrote: Approved for application. But, keep in mind that ATTRs other than INTVAL, FLOATVAL, STRING *, and PMC * cannot have automatic GET_ATTR/SET_ATTR accessor macros generated for them, and any C PMCs with these low-level ATTRs cannot be subclassed from PIR/HLLs. Applied in r30617 the pmc2c part and in r30618 the perl6multisub part. -- Salu2
struct and pointer to pointer in ATTR
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 pointer to a
pointer. This can be easily solved.
candidate_info is a struct declared in the pmc file (as typedef struct
candidate_info { ... } candidate_info), then his declaration is not
viewable at the point of inclusion of the generated h file. This can
be solved by declaring the ATTR with type struct candidate_info
instead of candidate_info, but the grammar for ATTR does not allow it.
I think that allowing struct in ATTR is the simpler solution to the
second problem, because the intended usage is for struct used
internally in the pmc, not for his documented interface.
The attached patch changes the ATTR grammar and uses the changes to
clean the workarounds currently used in perl6multsub pmc. It passes
all coretest on my system, both building with C or with C++.
--
Salu2
Index: lib/Parrot/Pmc2c/Parser.pm
===
--- lib/Parrot/Pmc2c/Parser.pm (revisión: 30584)
+++ lib/Parrot/Pmc2c/Parser.pm (copia de trabajo)
@@ -105,7 +105,7 @@
# type
\s+
-(INTVAL|FLOATVAL|STRING\s+\*|PMC\s+\*|\w+\s+\*|Parrot_\w*)
+(INTVAL|FLOATVAL|STRING\s+\*|PMC\s+\*|(?:struct\s+)?\w+\s+\*+|Parrot_\w*)
# name
\s*
Index: languages/perl6/src/pmc/perl6multisub.pmc
===
--- languages/perl6/src/pmc/perl6multisub.pmc (revisión: 30584)
+++ languages/perl6/src/pmc/perl6multisub.pmc (copia de trabajo)
@@ -553,7 +553,7 @@
pmclass Perl6MultiSub extends MultiSub need_ext dynpmc group perl6_group {
ATTR PMC *candidates;
-ATTR void *candidates_sorted;
+ATTR struct candidate_info **candidates_sorted;
/*
@@ -618,15 +618,7 @@
/* Make sure that we have a candidate list built. */
candidate_info **candidates = NULL;
PMC *unsorted;
-{
-/* Use an aux var to get the attribute, because of
- * current problems with the declaration of
- * attributes.
- */
-void *aux;
-GETATTR_Perl6MultiSub_candidates_sorted(interp, SELF, aux);
-candidates = (candidate_info **)aux;
-}
+GETATTR_Perl6MultiSub_candidates_sorted(interp, SELF, candidates);
GETATTR_Perl6MultiSub_candidates(interp, SELF, unsorted);
if (!candidates) {
candidates = sort_candidiates(interp, unsorted);
[perl #46125] [TODO] Verify that register is in range in PDB_check_condition()
Done in r30574
Re: [perl #58358] parrot_debugger - Undefined command: ñì¶ñì¶
On Mon, Aug 25, 2008 at 10:38 PM, chromatic [EMAIL PROTECTED] wrote: I can't reproduce that, but does this patch fix it? Done in r30558, that way is cleaner. -- Salu2
[perl #46121] [TODO] Add while loop to increment through commands correctly in PDB_cond()
Fixed in r30533
[perl #57474] [pdb] parrot debugger segfault
Closing ticket
[perl #58358] parrot_debugger - Undefined com mand: ñì¶ñì¶
Fixed in r30537, closing ticket.
[perl #46117] [TODO] Handle command error and print out script line in PDB_script_file()
Done in r30570
[perl #46115] [TODO] Avoid the verbose output in PDB_script_file() or add a -v flag?
Verbose output is now controlled by the 'echo' command. If more debugger output control is needed, create specific tickets.
Re: [perl #57474] [pdb] parrot debugger segfault
On Thu, Jul 31, 2008 at 8:19 PM, via RT Will Coleda [EMAIL PROTECTED] wrote: Running `parrot_debugger` over the tcl library code generates either a segfault or a crash, depending. It does not fail for me in r30535 Currently parrot_debugger does not disasseble automatically a pbc, but executing disassemble at PDB prompt does not fail also. -- Salu2
Re: [perl #58358] parrot_debugger - Undefined command: ñì¶ñì¶
On Mon, Aug 25, 2008 at 4:16 PM, via RT Will Coleda [EMAIL PROTECTED] wrote: Hitting enter immediately after successfully starting the debugger throws an error. Fixed in r30537 -- Salu2
Re: gsoc_nci merge
On Fri, Aug 22, 2008 at 9:51 PM, Kevin Tew [EMAIL PROTECTED] wrote: 0015a810 t Parrot_store_arg little t means its not exported. set_nci_* functions should probably be moved elsewhere. as well as the Parrot_jit_build_call_func I found Parrot_jit_build_call_func in src/jit/i386/jit_emit.h, so I made my changes in place. Parrot_store_arg lacked the PARROT_API attribute. Fixed in r30457 -- Salu2
Re: [PATCH] Help catching gc errors in HLL
On Mon, Jun 2, 2008 at 7:18 PM, chromatic [EMAIL PROTECTED] wrote: I like the general idea, but I wonder if there's something cleaner than an environment variable. Nothing really comes to mind at the moment besides making argument processing even uglier in IMCC's main.c. Let's think about it for a little bit, but I really like the idea. I've included a 'gcdebug' command in parrot_debugger that toggles a garbage collection cycle before each opcode in the debugger runloop, allowing the functionality proposed in this patch (when parrot_debugger reaches a more stable state). -- Salu2
Re: [perl #58044] Segfault in t/op/exceptions.t:30 with CGP core
On Sun, Aug 17, 2008 at 9:35 PM, via RT Bob Rogers [EMAIL PROTECTED] wrote: Here's another curious test failure: Using the CGP core, t/op/exceptions.t:30 (the new on for Resumable exceptions, r30123) fails with a segfault, but only if invoked through t/harness (i.e. it works for prove). The following make target may be helpful: test-cgp-exceptions: $(PERL) t/harness --gc-debug --running-make-test -C t/op/exceptions.t The reason of the segfault is that n_regs_used in current context in NULL. I've put an assertion in r30348 that checks that condition in the do_prederef function. -- Salu2
Re: [perl #58054] t/op/exceptions.t:30 segfaults in switched core
On Mon, Aug 18, 2008 at 1:33 AM, via RT Bob Rogers [EMAIL PROTECTED] wrote: Running t/op/exceptions.t:30 segfaults using the switched core (parrot -S). The same test fails in the CGP core [see RT#58044], but in a different place. The assertion I added for RT#58044 also catches this. -- Salu2
[perl #57930] [BUG] Smolder failure
Fixed
[perl #46109] [TODO] Where does string get freed in PDB_get_command()?
Solved in r30203, debugger command line buffers are now created and destroyed during creation and destruction of the debugger instance.
