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
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
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
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 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
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++
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
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
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
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
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
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
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
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
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 usage
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
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
===
---
(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
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 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
Done in r31684 after MMD changes, adding the test from the previous patch.
Updated information: we added recently a workaround to the utf8 downcase
function, by moving code already present out of the ICU #if block.
This workaround delegates to the ascii downcase when the string has only
codepoints in the ascii range (the way used to do that check is
debatable, must be
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 are
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
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
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.
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 creating a
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
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 ?
--
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
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
This check can be removed from default.pmc. Property values should not
be returned by get_attr_str.
Done in r31509
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
Fixed in r31508
It turns out that the namespace was a red herring. The real problem is
that when iterating over a hash, you cannot assign to a PMC register; it
must be a string register. So if the base collection is a hash, this
segfaults:
$P0 = shift iterator
But this works fine:
$S0 =
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
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
Thanks. There is little bit more patches.
Applied in r31381, with some changes in the env.pmc part to avoid
repeated calls.
--
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 better.
Done
Patches to bigint, complex, float and string applied in r31370, thanks.
--
Salu2
Applied with some changes in r31335
--
Salu2
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
+=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 =
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 is not
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
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
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
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
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
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
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
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
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
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
rakudo: sub foo($x?, :$y = 2){ say $x~|~$y}; foo(:y(3));
exp_evalbot
OUTPUT[|]
This appears to be a bug in Parrot (now RT#54860). When that's fixed
this one should be fixed also.
RT#54860 is fixed, verified:
rakudo: sub foo($x?, :$y = 2){ say $x~|~$y};
I've recently commited a fix on null string constants. I think it was
the same problem described here. I compiled the pir file and pdumped
without a problem, it shows the DATA = NULL my fix introduced.
Can you verify the problem is gone?
This falls under the I/O PDD, the next milestone. Hold for a couple of
days. I've added it to the tasklist for the milestone:
The print and say opcodes had already been changed some weeks ago, now
both call PIO_printf on INT and NUM.
By the way, now FLOATVAL_FMT is used instead of %f
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',
Fixed in r30870, added a test in r30900. Closing ticket.
Added a test in r30902. Closing ticket.
The code in this ticket does not parse. Is using obsolete syntax? Can
someone provide an updated version?
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:
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
Applied in r30907, thanks.
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
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
fix
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
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
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
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.
Done in r30574
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
Fixed in r30533
Closing ticket
Fixed in r30537, closing ticket.
Done in r30570
Verbose output is now controlled by the 'echo' command. If more debugger
output control is needed, create specific tickets.
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
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 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
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
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).
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.
--
Fixed
Solved in r30203, debugger command line buffers are now created and
destroyed during creation and destruction of the debugger instance.
1 - 100 of 239 matches
Mail list logo
