On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
> With this patch, the new tests still pass on Linux/x86. The patch uses
> STRING->strstart to avoid leaking a malloc'd buffer when throwing an
> exception, which may or may not be considered kosher in this situatio
On Mon, Aug 4, 2008 at 11:27 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
> parrot_debugger has some unresolved symbols.
Quick fix applied in r30006
--
Salu2
On Sun, Aug 3, 2008 at 8:03 PM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
> The patch looks good to me, but the pdd25cx merge seems to have broken
> parrot_debugger.c altogether; it won't even compile any more.
I've applied a quick fix in r30006 to make it build again.
--
Salu2
On Thu, Jul 31, 2008 at 8:20 PM, via RT Will Coleda
<[EMAIL PROTECTED]> wrote:
> The parrot_debugger version should, IMO, be identical to the parrot
> version. (e.g., it's currently reporting as 0.4 instead of 0.6.x.)
Done in r30034
--
Salu2
On Thu, Aug 7, 2008 at 2:06 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
> make headerizer is trying to operate on files generated by make. Given
> that it's supposed to be updating the header files based on the C
> sources, this seems vaguely reasonable, so I would suggest that the
> problem is act
On Fri, Aug 8, 2008 at 9:12 AM, chromatic <[EMAIL PROTECTED]> wrote:
> On Thursday 07 August 2008 23:50:54 [EMAIL PROTECTED] wrote:
>> Add a return continuation attribute to the Exception pmc and fill it in the
>> throw opcode.
>>
>>
>> Modified: trunk/src/ops/core.ops
>> ==
On Fri, Aug 8, 2008 at 2:16 PM, Tim Heckman <[EMAIL PROTECTED]> wrote:
> Wasn't able to build parrot for smoke testing. This was using the MS Visual
> C++ compiler.
>
>
> src\ops\core_ops.c
> src\ops\core.ops(821) : error C2275: 'opcode_t' : illegal use of this type
> as an
> expression
Please try
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 "pr
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.
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 a
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/ji
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
execu
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
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
Hello.
The current grammar for ATTR in pmc2c allows declarations of the form:
* 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 c
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
Hearing no objections, and because I needed it to be able to do tests
with mysqlclient, applied in r30790
--
Salu2
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
>
After some brief comment on irc, applied in r30833
--
Salu2
Sorry, the code I poste was bad. The valid form is:
$P1 = new ['Exception'], $P0 # create new exception object
--
Salu2
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
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
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
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',
> 's
> 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:
Par
>> 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"
>> 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
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.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=58704 >
> li
> 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
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
>> 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. Bu
> 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 o
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_STR
>> 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 writ
> 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 comm
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 ;)
>> 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 i
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
>> +
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
>> +=item C
>> +
>> +Removes the element at C.
>> +
>> +=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();
Applied with some changes in r31335
--
Salu2
On Mon, Sep 22, 2008 at 12:34 AM, NotFound <[EMAIL PROTECTED]> wrote:
>>> +=item C
>>> +
>>> +Removes the element at C.
>>> +
>>> +=cut
>>> +
>>> +*/
>>> +
>>> +VTABLE void delete_keyed_int(INTVAL key) {
>
>> 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 bett
Patches to bigint, complex, float and string applied in r31370, thanks.
--
Salu2
>> 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:
> Thanks. There is little bit more patches.
Applied in r31381, with some changes in the env.pmc part to avoid
repeated calls.
--
Salu2
> 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
> 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 in
>> > 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
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
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
> (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
>> > 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
> 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 #43
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
> 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
> 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 a
>> 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
> (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 argument
> 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 validat
>> 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 ro
On Wed, Oct 8, 2008 at 4:56 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> The problem appears to be that src/pmc/complex.pmc makes use of
> RE() and IM() macros that no longer work for subclasses of the Complex PMC
> and try to poke float values directly into the PMC struct. Unfortunately,
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 implemen
>> 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
CPU_ARCH implemented in r31982
--
Salu2
> '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 us
> As of r32075, 'make; make headerizer' still breaks the build.
Fixed in r32079
--
Salu2
> 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
min
On Wed, Oct 22, 2008 at 6:28 PM, Bernhard Schmalhofer via RT
<[EMAIL PROTECTED]> wrote:
>> Done in r30914: changed name to Parrot__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 depre
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 ve
> 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
> 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'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
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
> Currently, IMCC still has a 2-digit limit for PASM registers.
> I think we can easily extend this to any number, as long as it fits in
> an INTVAL.
Last time I checked, register allocator and some other imcc parts used
unsigned char for register numbers in several places.
--
Salu2
> 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++ --c
On Wed, Dec 17, 2008 at 12:52 AM, chromatic 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 argumen
Method added in r36305, created TT #264 about it.
--
Salu2
> 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
Hello
I'm trying to clean some warnings in parrot C source files and found
this casts in packfile/pf_items.c:
fetch_buf_le_8(u.buf, (unsigned char *) b);
fetch_buf_be_8(u.buf, (unsigned char *) b);
But the function definitions are (in src/byteorder.c):
void
fetch_buf_le_8(ARGOUT(unsigned char
Hello.
As I said in a previous message, there are two casts in pf_items.c
that are unnecessary and seems to be wrong.
This patch removes both, avoiding warnings. Tested in Ubuntu 7.10 on
Intel platform.
--
Salu2
Index: src/packfile/pf_items.c
Hello.
I sent to the list the message to parrotbug, and later to parrotbug
the apology message to the list, sorry.
--
Salu2
Hello.
> This is where I ran into problems. Is get_string constable? It seems
> possible that someone somewhere would want to cache a stringification
> that was computationally intensive, for later reuse. So now (as
> bernhard kindly pointed out to me), this is starting to sound like a
> d
On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester <[EMAIL PROTECTED]> wrote:
> Just popping in to say that we cannot const any parms to vtable methods.
> Parrot can't impose promises on the called code.
So take for example In default.pmc the method get_class:
VTABLE PMC *get_class() :const
That is
On Mon, Apr 21, 2008 at 12:25 AM, Mark Glines <[EMAIL PROTECTED]> wrote:
> (Still debatable whether the rest of that #else clause in parrot.h is
> valid, if it's causing issues like this one.)
This patch can avoid future problems, by defining and using using
specific macros.
I searched the sou
Hello
> Just popping in to say that we cannot const any parms to vtable methods.
> Parrot can't impose promises on the called code.
The attached patch drops the :const attribute in isa and get_class
methods. A lot of cast warnings disappear, and all tests pass in my
system.
--
Salu2
Index: src
Hello
> The following lines that use the STRUCT_COPY macro are generating
> build warnings.
>
> src/charset/ascii.c:792: warning: the address of 'base_set' will
> always evaluate as 'true'
(snip)
> For example, the last line here is:
>
> STRUCT_COPY(return_encoding, &base_encoding);
>
> but
On Sat, Apr 26, 2008 at 8:16 PM, chromatic <[EMAIL PROTECTED]> wrote:
> That seems cleaner to me; want to try that patch?
I'm out for the weekend, tomorrow I will work on it.
--
Salu2
On Sat, Apr 26, 2008 at 8:16 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > A possible solution is to add another macro taking as second argument
> > the struct instead of a pointer.
> That seems cleaner to me; want to try that patch?
The attached patch adds the macro STRUCT_COPY_ST, and uses it
On Mon, Apr 28, 2008 at 8:15 PM, NotFound <[EMAIL PROTECTED]> wrote:
> All test pass with 27216 in my system (Ubuntu 8.04)
Sorry, I mean 27219, 27216 was from the modified files.
--
Salu2
On Mon, Apr 28, 2008 at 10:05 PM, chromatic <[EMAIL PROTECTED]> wrote:
> I renamed it to STRUCT_COPY_FROM_STRUCT (but that's only a little better than
> your version) and applied it as r27222.
Thanks, but in 27222 looks like only include/parrot/parrot.h reflects
the changes, not the files in sr
The attached patch redoes the changes in these files with the new name.
--
Salu2
Index: src/encodings/utf16.c
===
--- src/encodings/utf16.c (revisión: 27222)
+++ src/encodings/utf16.c (copia de trabajo)
@@ -708,7 +708,7 @@
On Mon, Oct 22, 2007 at 2:24 PM, via RT Paul Cochrane
<[EMAIL PROTECTED]> wrote:
> "TODO mul"
The attached patch is a simple implementation using
mul and adds the operation in the multiply test in
complex.t (don't know if it's the correct place).
--
Salu2
Index: src/pmc/integer.pmc
===
> > > Lurkers (potential contributors.) Posting it on use.perl.org (and/or
> > > various other feed sources) would reach more of us.
> > But do those lurkers actually exist? My gut says no. My gut says
> > that the people who would be interested in a summary are already on
> > the list.
I
On Mon, May 5, 2008 at 2:52 AM, via RT Tom Erdevig
<[EMAIL PROTECTED]> wrote:
> Parrot segfaults running this:
> .sub _ :main
> null S0
> loadlib P0, S0
> .end
> The segfault is caused by src/dynext.c:Parrot_load_lib setting
> its local lib_name variable to NULL and then passing it al
On Tue, May 6, 2008 at 7:42 AM, chromatic <[EMAIL PROTECTED]> wrote:
> I prefer this patch. It fixes the problem closer to its source. Does it
> work
> for you?
Works for me, but I wonder if the set_string_native function still
needs the fix, or an assertion about a forbidden combination of
On Fri, Oct 5, 2007 at 10:50 PM, via RT Paul Cochrane
<[EMAIL PROTECTED]> wrote:
> In src/debug.c:PDB_cond() there is the todo item:
>
> /* XXX Does /this/ have to do with the fact that PASM registers used to
> * have
> * maximum of 2 digits? If so, there should be a while loop, I think.
>
> In src/objects.c:Parrot_add_attribute() there is the todo item:
>
> /* TODO escape NUL char */
>
> I think this applies to calling real_exception just afterwards.
According a discussion in #parrot this function and some related parts
is dead code. The attached patch removes it.
--
Salu2
Ind
> In src/objects.c:Parrot_single_subclass() there is the todo item:
>
> /* XXX not really threadsafe but good enough for now */
>
> This needs to be made threadsafe.
This ticket can be closed, as Parrot_single_subclass was dead code and
has been removed.
Looking a this, I discovered that the s
Sorry, forgot to attach the patch file.
--
Salu2
Index: src/pmc/class.pmc
===
--- src/pmc/class.pmc (revisión: 27379)
+++ src/pmc/class.pmc (copia de trabajo)
@@ -644,8 +644,11 @@
/* If we already have an attribute of thi
1 - 100 of 247 matches
Mail list logo
