> 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 i
>> 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 happen
> 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 reje
> 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
> 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
Method added in r36305, created TT #264 about it.
--
Salu2
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
> 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
> 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
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
>> 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
> 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'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
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_
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
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
> 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
> As of r32075, 'make; make headerizer' still breaks the build.
Fixed in r32079
--
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
Problem fixed and test added, closing ticket.
CPU_ARCH implemented in r31982
--
Salu2
>> 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
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
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,
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/comp
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 re
Done in r31684 after MMD changes, adding the test from the previous patch.
>> 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
> 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
> (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
>> 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
> 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
> 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
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
> 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
>> > 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
> (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.
--
Salu2
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
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.
>> > 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
> 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
Fixed in r31508
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 res
> This check can be removed from default.pmc. Property values should not
> be returned by get_attr_str.
Done in r31509
> 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:
>
>
> 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
> Thanks. There is little bit more patches.
Applied in r31381, with some changes in the env.pmc part to avoid
repeated calls.
--
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:
Patches to bigint, complex, float and string applied in r31370, thanks.
--
Salu2
>> 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
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) {
>
Applied with some changes in r31335
--
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();
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
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
>> +
>> 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
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 ;)
> 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
>> 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
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
> 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
>> 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
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
> 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"
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?
> >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"~"
> 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 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
>> 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
Applied in r30907, thanks.
>> 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"
> 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 code in this ticket does not parse. Is using obsolete syntax? Can
someone provide an updated version?
Added a test in r30902. Closing ticket.
Fixed in r30870, added a test in r30900. Closing ticket.
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
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
No objections and no problems, closing ticket.
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
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
Sorry, the code I poste was bad. The valid form is:
$P1 = new ['Exception'], $P0 # create new exception object
--
Salu2
After some brief comment on irc, applied in r30833
--
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
>
Hearing no objections, and because I needed it to be able to do tests
with mysqlclient, applied in r30790
--
Salu2
PDB_next no longer executes opcodes by himself, now is done in the
debugger runloop. Closing ticket.
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
Done in r30574
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
Verbose output is now controlled by the 'echo' command. If more debugger
output control is needed, create specific tickets.
Done in r30570
Fixed in r30537, closing ticket.
Closing ticket
Fixed in r30533
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
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 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 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 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 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.
1 - 100 of 245 matches
Mail list logo
