Thanks, applied (with a few typographical tweaks by me).
Simon
On 3 Aug 2003, Luke Palmer wrote:
This fix has worked fine with JIT until now, so I suspect the problem
is elsewhere.
Bug confirmed here (although I need a slightly longer string to trigger
it). Here's a stacktrace:
---
On Sun, 3 Aug 2003, Daniel Grunblatt wrote:
On Sunday 03 August 2003 15:27, Simon Glover wrote:
On 3 Aug 2003, Luke Palmer wrote:
This fix has worked fine with JIT until now, so I suspect the problem
is elsewhere.
Bug confirmed here (although I need a slightly longer string
On Thu, 31 Jul 2003, Sebastian Bergmann wrote:
Is it the intended behaviour of make distclean to delete all files
under the CVS/ directories, thus rendering succeeding cvs upd calls
impossible?
As I understand it, make distclean is what you would do before
packaging up Parrot for a
Thanks, applied.
Simon
On Tue, 29 Jul 2003, H.Merijn Brand wrote:
On Tue 29 Jul 2003 16:40, Leopold Toetsch [EMAIL PROTECTED] wrote:
Hi Merijn,
HP-UX 11.00/32 2 CPU:
:
io/io_buf.c
cpp: io/io_buf.c, line 65: warning 2001: Redefinition of macro MAX.
cpp: io/io_buf.c, line 66: warning 2001: Redefinition of
On 29 Jul 2003, Juergen Boemmels wrote:
Simon Glover [EMAIL PROTECTED] writes:
On Tue, 29 Jul 2003, H.Merijn Brand wrote:
iii) protect them with #ifdef MAX/#endif
I bet the definition of MAX and MIN on HP-UX is identical to my
definition.
I would not be surprised.
Ok, here
On 29 Jul 2003, Luke Palmer wrote:
G'day,
For a complete list of instructions, grab the cvs and look at the
various .ops files. They are scattered with POD documentation about
each op they implement.
The same documentation can also be found in the docs/ops/ subdirectory
-- it's
On Tue, 29 Jul 2003, Jos Visser wrote:
On Tue, Jul 29, 2003 at 09:11:15AM -0700 it came to pass that Mr. Nobody wrote:
I don't think it's worth adding extra overhead to lexical variables just to
support broken pasm. There are many ways to crash parrot with bad code - but
it's OK, since
On Tue, 29 Jul 2003, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
Try and explain what invoke is supposed to do. NB this still needs work
[ snip ]
+=item void* invoke(INTERP, PMC* self, void* next)
[ snap ]
+It should set up the environment for the sub
On Mon, 28 Jul 2003, Vladimir Lipskiy wrote:
I'm getting an awful lot of spf_render.c(578) : warning C4761: integral
size mismatch in argument; conversion supplied while making.
Line 578 in spf_render.c is:
gen_sprintf_call(interpreter, tc, info, ch);
The problem seems to be the
On Mon, 28 Jul 2003, Tim Howell wrote:
?tches from a few days ago to allow executable creation, the current CVS no
longer compiles properly on my MacOS X 10.2.6 box. The error I get is:
exec_save.c:319:16: #if with no expression
make: *** [exec_save.o] Error 1
The following patch seems
On Sun, 20 Jul 2003, Jürgen Bömmels wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #23063]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23063
Hello,
for searching memory
On Sat, 26 Jul 2003, Jonathan Worthington wrote:
# New Ticket Created by Jonathan Worthington
# Please include the string: [perl #23136]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23136
Hi,
Am I allowed
Thanks, applied, with a couple of tweaks of my own.
Simon
1. What is init_pmc_properties supposed to do?
(It's currently in vtable.tbl, but isn't documented in PDD02.)
2. What, precisely, do invoke and invoke_pmc do?
(These are documented, but the prototypes given in PDD02 don't
agree with the ones used the the vtables).
Specifically,
On Thu, 24 Jul 2003, Daniel Grunblatt wrote:
I have checked in a first attempt to make parrot generate an executable.
It works fine on x86 - OpenBSD/linux/FreeBSD and should also work on NetBSD
It's not working for me on Linux/x86 -- the build is failing with:
In file included from
On Thu, 24 Jul 2003, Daniel Grunblatt wrote:
On Thursday 24 July 2003 15:55, Juergen Boemmels wrote:
Magic: 7f 45 4c 46 01 01 01
00
--
00 00 00 00 00 00 00 00
OS/ABI:UNIX - System V
Patch is in, please resync and try it.
It's now dieing with:
In
It now builds and tests fine.
Simon
On Wed, 23 Jul 2003, Lars Balker Rasmussen wrote:
Simon Glover [EMAIL PROTECTED] writes:
OK, I've just created a new ops subdirectory in the docs directory, and
changed the docs makefile so that each *.ops file creates a corresponding
*.pod file in there. Everything works OK for me
I think I've figured out why these tests are failing on some, but not
all, platforms -- it's a GC bug. Specifically, we're not including the
class_hash as part of the root set, so the garbage collector can
potentially reclaim it before we try to use it.
The patch below seems to fix the
On Wed, 23 Jul 2003, Dan Sugalski wrote:
At 1:45 PM -0400 7/23/03, Simon Glover wrote:
I think I've figured out why these tests are failing on some, but not
all, platforms -- it's a GC bug. Specifically, we're not including the
class_hash as part of the root set, so the garbage
On Wed, 23 Jul 2003, Lars Balker Rasmussen wrote:
# New Ticket Created by Lars Balker Rasmussen
# Please include the string: [perl #23102]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23102
[i386, FreeBSD 5.0]
Test number 6 in io.t is failing on a number of the tinderboxes with
a double-free error.
Test 6 does this:
open P0, temp.file,
clone P1, P0
read S0, P1, 1024
print S0
end
And the clone function in the ParrotIO vtable does this:
void clone (PMC *dest) {
On Tue, 22 Jul 2003, Brent Dax wrote:
The core.ops split has been committed. Documentation has been fixed up,
and all the copyright stuff should be correct.
Please remember to reassemble any Parrot bytecode files you currently
have.
A fresh checkout builds and tests fine here
On Tue, 22 Jul 2003, Brent Dax wrote:
# One point - should we update the docs Makefile to spit out
documentation
# for all of the ops files? At the moment we're only doing this for
io.ops
# and core.ops (which just got a lot smaller).
This is probably a good idea.
OK, I've just
OK, this should be fixed in CVS -- I just added/subtracted 1 as
appropriate so that the test is no longer sensitive to whether
0 == -0 (since this wasn't what we were supposed to be testing here).
Simon
On Thu, 17 Jul 2003, Dan Sugalski wrote:
At 9:24 AM +0200 7/17/03, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
For instance, in findclass, you have:
if (VTABLE_get_pmc_keyed(interpreter, interpreter-class_hash,
key_new_string
Of course, if you apply the previous patch, you'll also need to apply
this one...
Simon
--- MANIFEST.oldFri Jul 18 13:35:04 2003
+++ MANIFESTFri Jul 18 13:35:41 2003
@@ -1861,6 +1861,7 @@
t/pmc/managedstruct.t []
t/pmc/multiarray.t
Dan,
I've been playing about with the new object stuff you added today, and
I've noticed a couple of problems.
Firstly, when your doing the initialization for a new ParrotClass PMC,
you create an Array to hold various other PMCs, but you don't size the
array; this means that when you
On Tue, 15 Jul 2003, Will Coleda wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #22998]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22998
Supresses a perldoc warning on
The PMC version of this op (ie cmod_p_p_p) is identical in
implementation to the plain mod op (mod_p_p_p), which seems rather
pointless. Would anybody object if we just got rid of it?
Simon
I think the read write ops in core.ops are obsolete as well;
the patch below removes them.
Simon
--- core.ops.oldTue Jul 8 10:18:46 2003
+++ core.opsTue Jul 8 10:19:36 2003
@@ -86,7 +86,6 @@
=cut
-
=item Berr(out INT)
@@ -113,47
On Tue, 8 Jul 2003, [EMAIL PROTECTED] (via RT) wrote:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #22901]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22901
Multi-line string
On Tue, 8 Jul 2003, Nicholas Clark wrote:
On Tue, Jul 08, 2003 at 06:48:02PM -, Simon Glover wrote:
cvsuser 03/07/08 11:48:02
Modified:.debug.c
Log:
Add missing \ in multiline strings -- patch courtesy of [EMAIL PROTECTED]
Delete a breakpoint.\n\n
On Tue, 1 Jul 2003, Dan Sugalski wrote:
This dies on 9 tests on OS X, and I think from the complaints that
valgrind will also be very unhappy, but I'm putting it in so it can
be thumped by other folks as well as me.
I think I might have figured out why valgrind's unhappy. We're
currently
On Mon, 30 Jun 2003, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
With a fresh checkout, I get:
imcc.y:401: conflicting types for `YYSTYPE'
imcparser.h:6: previous declaration of `YYSTYPE'
/usr/lib/bison.simple: In function `yyparse':
/usr/lib/bison.simple:432
A further data point: the tests pass if I use IMCC to assemble them,
rather than assemble.pl
Simon
On Thu, 3 Apr 2003, Cal Henderson wrote:
patch to correct typos in rx.ops
patch follows sig
Thanks, applied.
Simon
On Tue, 25 Feb 2003, Jerome Quelin wrote:
I want to include concurrent-funge support.
I'm not even going to ask :-)
Simon
On Thu, 20 Feb 2003, Nicholas Clark wrote:
If I
perl Configure.pl --cgoto=0 make all test
then the build fails with:
ccache /usr/local/bin/gcc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H
-I/usr/local/include -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline
-Wshadow -Wpointer-arith
On Thu, 20 Feb 2003, Simon Glover wrote:
On Thu, 20 Feb 2003, Nicholas Clark wrote:
If I
perl Configure.pl --cgoto=0 make all test
then the build fails with:
ccache /usr/local/bin/gcc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H
-I/usr/local/include -Wall -Wstrict-prototypes
On Tue, 18 Feb 2003 [EMAIL PROTECTED] wrote:
I think --optimize alone is busted.
You'd be right: the code adding the optimization flags to the list of
compiler flags is only executed if 'debugging' is defined, which is
only the case when the --debugging flag has been used.
The patches
On Sat, 15 Feb 2003 [EMAIL PROTECTED] wrote:
I've been tinkering with the queens.jako example, trying to make it work
with strings
instead of bit fields. Along the way, I had a parrot segfault aparently
due to substr
and a (null) string register. Its probably my fault such a call was being
Hi all.
The new CGP code causes compilation of interpreter.c to fail if
HAVE_COMPUTED_GOTO is undefined. This is because it references
Parrot_DynOp_core_cgp_0_0_9, which is defined in core_ops_cgp.h,
and the latter is only included when HAVE_COMPUTED_GOTO is defined. This
bug appears to be
Here's another data-point, for Linux/x86: with a fresh check-out, parrot
is passing all of its tests, but most of the imcc tests are failing.
Specifically, I get:
Failed Test Stat Wstat Total Fail Failed List of Failed
Hi,
I've just noticed that we've been building IMCC without any of our
customary set of compiler warnings switched on. This is fairly easy
to fix, but unsurprisingly has revealed a bunch of warnings that
need to be eliminated. I've fixed a number of the more simple ones,
and hope to tackle
On Mon, 16 Dec 2002, Leopold Toetsch wrote:
Simon Glover wrote:
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c). This creates a
new Scratchpad PMC, and subsequently also creates two new lists
On Sat, 14 Dec 2002, Steve Fink wrote:
I notice that the current tree doesn't pass the tests even on my
rather forgiving machine, so there's some work to do. :-) (MANIFEST is
broken again, and nci.t is failing. I'll fix the first now.)
nci.t has started failing because we're only skipping
I've just commited the appended fix, which should hopefully reduce the
number of failures in the Tinderbox.
Simon
--- interpreter.c.old Sat Dec 14 18:26:45 2002
+++ interpreter.c Sat Dec 14 18:44:49 2002
@@ -591,7 +591,7 @@ Parrot_really_destroy(int exit_code, voi
chunks[1]
On Thu, 12 Dec 2002, Sean O'Rourke wrote:
# New Ticket Created by Sean O'Rourke
# Please include the string: [perl #19090]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19090
The following defines a macro
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
Simon Glover wrote:
On Wed, 11 Dec 2002, Dan Sugalski wrote:
Are in. You can now get, set, delete, and get a hash of PMC
properties. (Hopefully)
Alas, no tests. Working on that, but if someone wants to beat me to
it, feel free.
I
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
Simon Glover wrote:
Also, the above code (and the original version) still segfaults if I run
it with --gc-debug.
With my recent changes in dod.c/headers.c checked out from CVS?
Yep. I've just double-checked with a completely fresh check
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
Simon Glover wrote:
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
Simon Glover wrote:
Also, the above code (and the original version) still segfaults if I run
it with --gc-debug.
With my recent changes in dod.c/headers.c checked out from CVS
On Wed, 11 Dec 2002, Dan Sugalski wrote:
Are in. You can now get, set, delete, and get a hash of PMC
properties. (Hopefully)
Alas, no tests. Working on that, but if someone wants to beat me to
it, feel free.
I would expect this:
new P0, .PerlInt
new P1, .PerlInt
On Wed, 11 Dec 2002, Simon Glover wrote:
Is this a bug, or am I misunderstanding how properties are supposed to
work?
Well, there's definitely a bug somewhere, as the previously posted
example causes a segfault if run with --gc-debug. Backtrace follows:
#0 0x08075bb1 in hash_lookup
On Tue, 19 Nov 2002, Steve Fink wrote:
t/op/lexicals.t 6 1536 66 100.00% 1-6
t/pmc/multiarra 2 512 32 66.67% 2-3
t/pmc/scratchpa 3 768 33 100.00% 1-3
I can get these to fail on
On Sat, 19 Oct 2002, Leopold Toetsch wrote:
Andy Dougherty (via RT) wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18008]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18008
On Wed, 16 Oct 2002, Leopold Toetsch wrote:
There is somewhere a mailing list cvs something for checkins.
[EMAIL PROTECTED]
(and an archive on the web at archive.develooper.com)
Simon
On Sun, 13 Oct 2002, Steve Fink wrote:
[Discussion snipped]
Yes, I get this also. I was trying to figure out how to properly use
TODO or SKIP or something to suppress this, but none of them worked
quite right -- it would say that the failed test was a TODO, but it
still counted it as a
I've just tried to write PASM like:
new P0, .IntList
new P1, .PerlInt
set P1, 20
set P0[0], P1
...
end
only to have it fail with the message:
'Subscript on something that's not an aggregate!'
Is this a bug or a feature?
Simon
On Wed, 9 Oct 2002, Dan Sugalski wrote:
At 7:42 PM -0700 10/8/02, Steve Fink wrote:
Thanks, applied.
Who came up with the idea of two-argument ne, anyway? That's kind of
bizarre.
Definitely bizarre. I think I'd rather not have it, it doesn't make much sense.
Easily done. Patch below
On Wed, 9 Oct 2002, Nicholas Clark wrote:
On Wed, Oct 09, 2002 at 02:14:50AM -0400, Tanton Gibbs wrote:
In order, the other significant compiler warnings I see are:
perlhash.pmc: In function `Parrot_PerlHash_get_pmc_keyed':
perlhash.pmc:192: warning: passing arg 2 of pointer to function
On Wed, 9 Oct 2002, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Simon Glover [EMAIL PROTECTED] wrote:
This one happens because entry is a HASH_ENTRY*, but get_pmc_keyed is
expecting a PMC*. However, by this point in the function, we've already
verified that entry
On Tue, 1 Oct 2002, Robert Spier wrote:
http://www.parrotcode.org/openpatches
There are a _lot_ of Pending patches.
Within a few weeks, I hope to have an automated email nudging about
this weekly.
Here's a couple more that I just stumbled across - they've not been
picked up
On Mon, 12 Aug 2002, Jerome Quelin wrote:
Thus, I thought this one was the one I wanted. So:
LOAD:
read S0, 256
chopn S0, 1 # trailing newline
open I10, S0, r
eq I10, 0, ERR_IO
set S1, # Accumulator
LOAD_READ:
read S1, I10, 256
I think you forgot to attach the patch...
Simon
On 22 Jul 2002, Jonathan Sillito wrote:
I had a small patch ready for docs/core_ops.pod, but I see that the file
has been removed, so now I am not sure where to put the description of
the invoke op.
Oh, no it hasn't... core_ops.pod is autogenerated from core.ops during
the build process,
On Mon, 22 Jul 2002, Nicholas Clark wrote:
Do pmc files get turned pretty directly into C code?
Yes.
void set_bignum (PMC* value) {
/* XXX not sure if this can be optimized further safely */
// SELF-cache.struct_val = (DPOINTER*)value-vtable-get_bignum(INTERP,
On Tue, 2 Jul 2002, Dan Sugalski wrote:
At 2:37 PM -0500 7/2/02, brian wheeler wrote:
I saw this was a TODO item in core.ops.
Applied, thanks.
Tests, from anyone, would be much appreciated.
Will these do?
Simon
--- t/op/string.t.old Tue Jul 2 16:59:23 2002
+++ t/op/string.t
On Sun, 28 Apr 2002, Mike Lambert wrote:
Clint brought a small assembler string but to my attention, and I found
another bug while fixing the first. Bugs were:
a) 'abc' was turned into 'a[sc:1]c' before being turned into [sc:2]
b) 'a\b' was printing being stored as a\b and not ab
On Wed, 24 Apr 2002, Dan Sugalski wrote:
I've added set_addr, which gets the address of a label, like so:
set_addr I3, FOO
and fixed jump and jsr to actually work with absolute addresses.
This generates a stack of warnings of the form:
core.ops:473: warning: assignment makes
On Wed, 24 Apr 2002, Steve Fink wrote:
On Wed, Apr 24, 2002 at 03:22:57PM -0400, Simon Glover wrote:
--- core.ops.oldWed Apr 24 15:07:05 2002
+++ core.opsWed Apr 24 15:22:03 2002
-470,7 +470,7
Sets register $1 to the current address plus the offset $2
inline op
On Tue, 23 Apr 2002, Dan Sugalski wrote:
At 12:25 PM +0200 4/19/02, Peter Gibbs wrote:
Mike Lambert wrote:
This effect is exacerbated by the fact that set S1, S2 does a
string_copy - I am still not sure what is supposed to happen here; I believe
that the pure set opcode should just be
I was playing around a bit with the set_keyed and get_keyed ops and found
that this:
new P0, PerlArray
set I0, 0
LOOP: set_keyed P0, I0, I0
inc I0
lt I0, 1, LOOP
end
causes Parrot to segfault.
The culprit appears to be this bit of code
On Wed, 17 Apr 2002, Roman Hunt wrote:
Ehlo:
I'm not too sure if this is necessary but it seems logical to get things
into charsets our compilers can handle. Hopefully this is the correct
approach . . . . also this should NULL terminate in the event that the
entire buffer had not yet
On Wed, 17 Apr 2002, Roman Hunt wrote:
On Wed, 17 Apr 2002, Simon Glover wrote:
# +cstring[s-buflen + 1] = 0;
good grief
#
#
# This is a buffer overflow; I'm not quite sure what you're trying to do,
# but this certainly doesn't do it.
shouldnt cstring[s-bufused +1] = \0
On Wed, 17 Apr 2002, Brent Dax wrote:
Dan Sugalski:
# Okay, here are the milestones. Each is worth a point release. If we
# manage to take them in this order, great. :)
Rough dependency tree:
Arrays
Regular expressions (backreference storage)
Parser (probably)
OK, this is advance warning that I'm about to be reposting a bunch
of patches of mine which appear to have succumbed to Warnock's Dilemma.
The first three should be uncontroversial: there's a documentation fix-up
for core.ops, and new tests for strings and stacks. The last one is
rather
- Adds documentation for the two-arg. form of print
- Rewritten description for rotate_up that's hopefully clearer
Simon
--- core.ops.oldWed Apr 17 16:27:49 2002
+++ core.opsWed Apr 17 16:27:55 2002
-229,8 +229,13
=item Bprint(in INT, in NUM)
+=item Bprint(in INT, in STR)
+
- Tests for the 5-argument form of substr
Simon
--- string.t.oldSat Apr 6 19:56:32 2002
+++ string.tSat Apr 6 20:38:59 2002
-1,6 +1,6
#! perl -w
-use Parrot::Test tests = 64;
+use Parrot::Test tests = 76;
output_is( 'CODE', OUTPUT, set_s_s|sc );
set S4, JAPH\n
The enclosed patch makes a number of changes to perlstring.pmc, to bring
it in line with my understanding of how PMCs are supposed to work.
Specifically, unless we _know_ the type of the source and destination PMCs,
we should always access them through their get_... and set_... methods.
In
On Wed, 17 Apr 2002, Dave Mitchell wrote:
On Wed, Apr 17, 2002 at 04:34:12PM -0400, Simon Glover wrote:
On Wed, 17 Apr 2002, Brent Dax wrote:
Dan Sugalski:
# Okay, here are the milestones. Each is worth a point release. If we
# manage to take them in this order, great
This patch tidies up the formatting of string_substr and string_replace,
adds a bunch of comments, and moves a couple of assignments closer to
where the variables are actually used; none of the functionality should
be affected. All tests still pass (including the ones in a previous patch
What should the substr ops produce if given a negative length argument?
At the moment, the four-arg. form hands back an empty string, while
the five-arg. form hands back a copy of the original string, ie:
set S0, abcdefg
substr S1, S0, 0, -1
print S1
print \n
and
set S2,
On Mon, 15 Apr 2002, Dan Sugalski wrote:
At 10:26 PM +0200 4/15/02, Peter Gibbs wrote:
Note that string_grow still has the problem with not bothering to allocate a
new buffer if copysize is zero, e.g. if we are expanding a previously empty
buffer.
I have submitted a patch for this
Compiling parrot with gcc's -Wredundant_decls option shows up a few
places where we're declaring functions twice in the same header file.
Patch below fixes.
Simon
--- include/parrot/chartype.h.old Tue Apr 16 22:33:46 2002
+++ include/parrot/chartype.h Tue Apr 16 22:31:56 2002
On Tue, 16 Apr 2002, Josh Wilmes wrote:
Applied, thanks. Had to change the chartype.h part a bit, as it didn't
want to apply on its own. I am not sure why.
Anyway, it's in. Is there a reason not to include -Wredundant_decls in
our default warnings flags?
I've just tried it out in
We no longer pass a PMC pointer into pmc_new, but the comment hasn't been
changed to reflect that. Patch below corrects, and also adds an
appropriate comment for pmc_new_sized.
Simon
--- pmc.c.old Thu Apr 11 18:02:16 2002
+++ pmc.c Thu Apr 11 18:17:30 2002
-16,14 +16,12
#include
This patch tidies up a few of the comments in string.c, and fixes one
actual documentation bug -- namely, string_chopn removes the last
n _characters_, not the last n _bytes_.
Simon
--- string.c.oldThu Apr 11 19:01:31 2002
+++ string.cThu Apr 11 19:06:47 2002
-87,7 +87,7
}
The enclosed patch makes a number of changes to perlstring.pmc, to bring
it in line with my understanding of how PMCs are supposed to work.
Specifically, unless we _know_ the type of the source and destination PMCs,
we should always access them through their get_... and set_... methods.
In
This patch contains several more tests for the stack ops, in
particular for rotate_up.
Simon
--- t/op/stacks.t.old Sat Apr 6 13:47:09 2002
+++ t/op/stacks.t Sat Apr 6 14:58:01 2002
-1,6 +1,6
#! perl -w
-use Parrot::Test tests = 20;
+use Parrot::Test tests = 28;
use
Enclosed patch adds a number of tests for the 5-argument form of
substr.
Simon
--- t/op/string.t.old Sat Apr 6 19:56:32 2002
+++ t/op/string.t Sat Apr 6 20:38:59 2002
-1,6 +1,6
#! perl -w
-use Parrot::Test tests = 64;
+use Parrot::Test tests = 76;
output_is( 'CODE', OUTPUT,
The enclosed patch expands (and hopefully clarifies) the documentation
for rotate_up, plus fixes one or two other niggles in the docs.
Simon
--- core.ops.oldSat Apr 6 19:12:43 2002
+++ core.opsSat Apr 6 21:12:42 2002
-229,8 +229,13
=item Bprint(in INT, in NUM)
+=item
Self-explanatory patch.
Simon
--- MANIFEST.oldSun Mar 24 16:03:02 2002
+++ MANIFESTSun Mar 24 16:03:39 2002
-72,6 +72,7
examples/assembly/Makefile
examples/assembly/bsr.pasm
examples/assembly/call.pasm
+examples/assembly/cat.pasm
examples/assembly/euclid.pasm
This code:
set I0, 0
FOO: set S0, I0
savec S0
inc I0
lt I0, 256, FOO
rotate_up 2
restore S1
print S1
print \n
end
makes Parrot segfault. This seems to be due to an off-by-one error in
stack_entry(..) that uncovers itself if
The enclosed patch adds tests for the new savec and set Sx, Iy ops,
and also provides a test for the bug described in my previous email.
Simon
--- t/op/stacks.t.old Sun Mar 24 16:35:26 2002
+++ t/op/stacks.t Sun Mar 24 17:45:23 2002
-1,6 +1,6
#! perl -w
-use Parrot::Test tests =
On Thu, 21 Mar 2002, Michel J Lambert wrote:
+//KEY_PAIR src_key_p, dest_key_p;
+//KEY src_key, dest_key;
[etc.]
These need to be C-style comments; not every compiler will accept the
C++ style ones.
Simon
We can now get usage information for test_parrot without having to
grep the source.
Simon
--- docs/running.pod.oldTue Mar 19 09:57:02 2002
+++ docs/running.podTue Mar 19 09:57:45 2002
-40,7 +40,7
running Cmake shared.
Ctest_parrot also has several debugging and
101 - 200 of 277 matches
Mail list logo
