On Wed, Jul 9, 2008 at 9:33 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
> The other warnings I get on Solaris are just these:
>
> "src/stm/backend.c", line 969: warning: statement not reached
> "./src/pmc/nci.pmc", line 486: warning: statement not reached
> "src/encodings/utf16.c", line 326: war
On Thu, Jul 10, 2008 at 7:44 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
>> Except the src/pmc/nci.pmc line 486, there is not such line in the
>> file, and I'm unable to locate the problem.
>
> If you look in the generated src/pmc/nci.c file at line 486, it has a #line
> directive that purports
I changed the signature from PMC * to const PMC * in r29253, otherwise
using it with const gives warings in C and fails in C++.
What is the reason to have an interp parameter? Looks like an
unnecessary overhead in a frequently used function.
--
Salu2
>> src/exec_cpu.c
>> src/jit/i386/core.jit: In function 'Parrot_eq_n_n_ic_exec':
>> src/jit/i386/core.jit:1031: error: 'DO' undeclared (first use in
>> this function)
Looks like it was just a DO/do typo, but the file has been changed
before I can try to do some test.
--
Salu2
> Looks like it was just a DO/do typo, but the file has been changed
> before I can try to do some test.
No, it was a bad diagnostic from svn, my change has been commited.
--
Salu2
On Thu, Jul 3, 2008 at 11:12 PM, Allison Randal via RT
<[EMAIL PROTECTED]> wrote:
> A bit more detail on the conversion process for a PMC:
(snip)
> 3) Change 'init' and 'init_pmc' to initialize the auto-generated struct
> instead of whatever initialization it was doing before. For example, if
> it
Patch applied in r29301
I changed the test, because the unicode: prefixed string is utf8 by
default according the specs, and the current implementation seems to
agree, so the result in utf8 is the expectation both with or without
icu.
--
Salu2
> When #39930 is resolved, we can eliminate the workaround.
After applying a patch to #39930 in r29301, deleted this workaround in r29304
--
Salu2
Applied in r29309
--
Salu2
Applied in r29356 with modified and enhanced test.
--
Salu2
On Sat, Jul 12, 2008 at 10:57 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 12, 2008 at 3:30 PM, NotFound via RT
> <[EMAIL PROTECTED]> wrote:
>> imcc_init is now called during interpreter initialization. Does that
>> solve this problem?
>
> I'd s
On Tue, Jul 15, 2008 at 3:58 PM, via RT Will Coleda
<[EMAIL PROTECTED]> wrote:
> -- Forwarded message --
> From: Reini Urban <[EMAIL PROTECTED]>
> Date: Tue, Jul 15, 2008 at 9:52 AM
> Subject: .parrot_current_rev
> To: [EMAIL PROTECTED]
> Worse, the logic the set the current revisi
On Tue, Jul 15, 2008 at 3:58 PM, Reini Urban via RT
<[EMAIL PROTECTED]> wrote:
> This got warnocked for 0.6.4
>
> rename the debugger, not the disassembler.
I don't like the name parrot_pdb. 'parrot Parrot DeBugger' ? Looks redundant.
I'll vote for parrot_debug
--
Salu2
I fixed the problem in r29488, but I don't have any windows
environment available to test.
--
Salu2
>> I don't like the name parrot_pdb. 'parrot Parrot DeBugger' ? Looks
>> redundant.
After some discussion in #parrotsketch, the name parrot_debugger wins.
--
Salu2
> After some discussion in #parrotsketch, the name parrot_debugger wins.
Done in r29496, waiting for comments and fixes before closing the ticket.
--
Salu2
On Tue, Jul 15, 2008 at 11:45 PM, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> IMESHO, the encoding of the source code should have no bearing on the
> interpretation of string literal escape sequences within that source
> code. "\ab" should mean U+00AB no matter whether the surrounding
> source code
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. Ascii is an encoding
that maps directly to codepoints and only allows 0-127 values.
iso-8859-1 is the same with 0-25
> * Unicode isn't necessarily universal, or might stop to be so in future.
> If a character is not representable in Unicode, and you chose to use
> Unicode for everything, you're screwed
There are provision for private usage codepoints.
> * related to the previous point, some other character enco
On Wed, Jul 16, 2008 at 1:32 AM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
>> Worse, the logic the set the current revision for svn updates is
>> wrong.
> No, the logic was correct. As particle said on #parrot yesterday,
> ".parrot_current_rev should always reflect the last time you ran 'per
Fixed parrot_debugger test in r29508
--
Salu2
On Wed, Jul 16, 2008 at 6:08 AM, Tim Heckman <[EMAIL PROTECTED]> wrote:
> Starting in r29489, .parrot_current_rev contains "0" instead of the revision
> number.
I was using a simplified way to call svn info avoiding locale
dependencies, and forgot to replace with a more generic way.
Fixed in r295
On Wed, Jul 16, 2008 at 12:45 AM, <[EMAIL PROTECTED]> wrote:
> I just ran a test on XP-Home (using Strawberry Perl) after updating to
> r29495. Configure.pl creates the file (whether or not it was present), but
> the value appears to be a constant 0. (Make test and perl6 have no
> effect.)
Pleas
On Wed, Jul 16, 2008 at 1:12 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> I think this new subroutine could use some refactoring:
Yes, my goal was to fix the problem as fast as possible, and I'm not
very fluent with perl.
> If no one gets to this today I will try to work on this this even
On Wed, Jul 16, 2008 at 1:13 AM, Moritz Lenz
<[EMAIL PROTECTED]> wrote:
> NotFound wrote:
>>> * Unicode isn't necessarily universal, or might stop to be so in future.
>>> If a character is not representable in Unicode, and you chose to use
>>> Unicode fo
On Thu, Jul 17, 2008 at 5:20 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
> The thing is, there's a tendency for data for a particular program or
> application to all be from the same character set (if, for example, you're
> parsing a series of files, munging the data in some way, and writing out
On Thu, Jul 17, 2008 at 9:46 AM, François Perrad
<[EMAIL PROTECTED]> wrote:
> pdb was renamed parrot_debugger, but not installable_pdb.
Done in r29556, thanks.
--
Salu2
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
1 - 100 of 245 matches
Mail list logo
