Adds rx.t, removes duplicated rx.c and puts everything back in
alphabetical order.
Simon
--- MANIFEST.oldThu Jan 10 13:41:59 2002
+++ MANIFESTThu Jan 10 13:42:38 2002
@@ -187,10 +187,9 @@
pmc_pm.pl
register.c
resources.c
-rx.c
-rx.ops
runops_cores.c
rx.c
+rx.ops
stacks.c
s
This fixes a couple of nits in rx.c:
1. There's no newline at the end, which makes gcc unhappy.
2. We should use NULL, not 0 or "", for creating null pointers.
Simon
--- rx.c.oldWed Jan 9 22:35:14 2002
+++ rx.cThu Jan 10 14:14:36 2002
@@ -76,9 +76,9 @@
/*p
On Thu, 10 Jan 2002, Simon Glover wrote:
>
> This fixes a couple of nits in rx.c:
patch seems fine, but got me thinking...
>2. We should use NULL, not 0 or "", for creating null pointers.
"" isn't a NULL pointer although at present there isn't any difference
in the result of
string_make(I
As the subject line says.
Simon
--- macro.t.old Tue Nov 13 02:00:01 2001
+++ macro.t Thu Jan 10 15:52:28 2002
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 8;
+use Parrot::Test tests => 9;
output_is( <<'CODE', <
This patch fixes parrotpointer.pmc, which tries to return 0 from a void
function.
Index: classes/parrotpointer.pmc
===
RCS file: /home/perlcvs/parrot/classes/parrotpointer.pmc,v
retrieving revision 1.1
diff -u -r1.1 parrotpointer.pmc
Hello,
I'm not sure if this behavior was intended or not, but just in case I'm submitting
this patch.
The read op would segfault if you gave a string register as the first argument that
didn't previously have a string value in it.
--- will_fail.pasm ---
read S0, 0, 1
end
-
On Thu, 10 Jan 2002, Joshua Nye wrote:
> The read op would segfault if you gave a string register as the first argument that
>didn't previously have a string value in it.
>
> --- string.c.orig Thu Jan 10 11:26:39 2002
> +++ string.cThu Jan 10 11:27:12 2002
> @@ -71,7 +71,9 @@
> */
>
On Thu, Jan 10, 2002 at 03:06:38PM +, Alex Gough wrote:
> Also, I'm a bit concerned that our null termination games:
>
> s->bufstart = mem_sys_allocate(buflen+1);
> ...
> memset((char *)s->bufstart+s->bufused,0,1);
>
> Are going to lead to an eternity of OBO errors. Also if our
At 01:46 PM 1/10/2002 +, Simon Glover wrote:
> Adds rx.t, removes duplicated rx.c and puts everything back in
> alphabetical order.
This was my bad. Applied, and thanks.
Dan
--"it's like this"---
D
At 02:33 PM 1/10/2002 +, Simon Glover wrote:
> This fixes a couple of nits in rx.c:
>
>1. There's no newline at the end, which makes gcc unhappy.
>2. We should use NULL, not 0 or "", for creating null pointers.
Applied, thanks.
Dan
--
At 03:56 PM 1/10/2002 +, Simon Glover wrote:
> As the subject line says.
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 10:37 AM 1/10/2002 -0600, David M. Lloyd wrote:
>This patch fixes parrotpointer.pmc, which tries to return 0 from a void
>function.
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski
The enclosed patch allows one to use the if op with a PerlArray,
as in:
new P0, PerlArray
if P0, TRUE
print "false\n"
end
TRUE: print "true\n"
end
Currently, this works the same way that if(@array) does in Perl, ie
it's false if and only if the arr
At 12:15 AM 1/10/2002 +, Tim Bunce wrote:
>On Wed, Jan 09, 2002 at 04:42:51PM +, Graham Barr wrote:
> > On Tue, Jan 08, 2002 at 06:38:02PM -0500, Dan Sugalski wrote:
> > > ># Attributes are done as a hash of hashes. Each interpreter has a
> > > ># pointer to an attribute hash, whose keys a
Well, actually two bugs.
The first is an off-by-one error in key.c than can cause parrot
to segfault if hash % NUM_BUCKETS happens to be zero.
The other is a bug in the PerlHash init() code that causes new PerlHash
PMCs to start with the wrong size.
Both fixed below; also tests to preven
>
> I would strongly recommend that perl6 mandates that buffers are not nul
> terminated. Anything that needs a nul should arrange for one to be
appended.
> [eg by ensuring that the buffer is writable, extending it by one byte if
> needs be, and writing that nul, or by copying out the contents.]
>
The naming of things is getting a bit messy. I'd like to propose a
convention that I use in my work. It's compatible with the last draft
of PDD 7 that I could find:
http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html
By example:
struct somename_t { ... };
typedef struct somename
> Foo foo = (Foo) malloc(sizeof(*foo));
>? Does ANSI allow using sizeof on a variable declared on the
> same line?
Wouldn't sizeof(Foo) be safer here? At the logical time of the
call *foo points to undefined. Technically its not a deref but
still looks scary. In C++ it might be confusing if you
Eep, to answer the original subject of your mail, I think its a good idea
to start with the _t typedef standard.
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
On Thu, 10 Jan 2002, Steve Fink wrote:
> The naming of things is getting a bit messy. I'd like to propose a
> convention that I use in my work. It's compatible with the last draft
> of PDD 7 that I could find:
> http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html
I agree, we sho
On Thu, Jan 10, 2002 at 02:31:24PM -0600, David M. Lloyd wrote:
> After looking through PDD 7, I wonder: were we planning on doing any of
> this stuff? If so, maybe we should step back for a moment and do it. :-)
> If developers are expected to follow these guidelines (not that I've done
> any de
Just as the subject says.
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.72
diff -u -r1.72 core.ops
--- core.ops9 Jan 2002 17:24:11 - 1.72
+++ core.ops10 Jan 2002 21:47:29 -
I needed to use a generic stack, and the API in stacks.[ch] really
bothered me:
- it relied on the caller to maintain a pointer to the top of the
stack, rather than having a stack ADT that knows its own top. That
meant that anyone including a stack in its structure had to keep
around tw
Okay, I've abused examples/assembly/life.pasm to be a benchmark program. It
now will time generations/sec, and does rather more than mops.pasm does.
Something for testing as we go along. (The numbers are rather smaller, but
it does do a lot more than mops does)
This patch will clash with Steve Fink's stacks patch, but you get the
idea.
Also, there's gonna be a small speed hit that I don't know how to get
around. The problem is that when you save an int constant on the stack in
a mixed 32/64-bit system, the int type is 8 bytes but the pointer points
to
At 05:20 PM 1/10/2002 +, Simon Glover wrote:
> The enclosed patch allows one to use the if op with a PerlArray,
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski even
On Thu, Jan 10, 2002 at 02:31:24PM -0600, David M. Lloyd wrote:
> On Thu, 10 Jan 2002, Steve Fink wrote:
>
> > The naming of things is getting a bit messy. I'd like to propose a
> > convention that I use in my work. It's compatible with the last draft
> > of PDD 7 that I could find:
> > http://ww
On Thu, Jan 10, 2002 at 12:37:23PM -0500, Dan Sugalski wrote:
>
> >Tim [who's not really been paying attention, so ignore me if I'm being daft].
>
> Nah, you're making sense. Besides, vtables are all your fault in the first
> place, so I ought to be listening... :)
Why do I have the feeling th
At 05:57 PM 1/10/2002 +, Simon Glover wrote:
> Well, actually two bugs.
>
> The first is an off-by-one error in key.c than can cause parrot
> to segfault if hash % NUM_BUCKETS happens to be zero.
>
> The other is a bug in the PerlHash init() code that causes new PerlHash
> PMCs to start w
At 10:43 PM 1/10/2002 +, Tim Bunce wrote:
>On Thu, Jan 10, 2002 at 12:37:23PM -0500, Dan Sugalski wrote:
> >
> > >Tim [who's not really been paying attention, so ignore me if I'm being
> daft].
> >
> > Nah, you're making sense. Besides, vtables are all your fault in the first
> > place, so I
At 03:47 PM 1/10/2002 -0600, David M. Lloyd wrote:
>Just as the subject says.
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 10:43 PM 1/10/2002 +, Tim Bunce wrote:
>On Thu, Jan 10, 2002 at 12:37:23PM -0500, Dan Sugalski wrote:
> >
> > >Tim [who's not really been paying attention, so ignore me if I'm being
> daft].
> >
> > Nah, you're making sense. Besides, vtables are all your fault in the first
> > place, so I
Here is a patch that makes pbc2c generated code work with the bsr opcode. It
creates a new opcode 'enternative', and uses this to support a mixed model of
interpretation and execution of compiled C code.
Initially, an interpreter is created and started in order to execute a modified
copy of the
On Thu, Jan 10, 2002 at 03:18:33PM -0500, Melvin Smith wrote:
> Eep, to answer the original subject of your mail, I think its a good idea
> to start with the _t typedef standard.
except that POSIX (IIRC, but it's either them or ANSI) reserves all names
ending in _t for themselves. So any other na
At 01:56 PM 1/10/2002 -0800, Steve Fink wrote:
>I needed to use a generic stack, and the API in stacks.[ch] really
>bothered me:
You forgot "because it sucked" :)
Patch applied. Thanks.
Dan
--"it's like this"--
On Thu, 10 Jan 2002, Nicholas Clark wrote:
> On Thu, Jan 10, 2002 at 03:06:38PM +, Alex Gough wrote:
> > Also, I'm a bit concerned that our null termination games:
> I would strongly recommend that perl6 mandates that buffers are not nul
> terminated. Anything that needs a nul should arrange
On Thu, Jan 10, 2002 at 03:56:57PM +, Simon Glover wrote:
>
> As the subject line says.
Technically that should be a TODO.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
come sing
In message <20020110201559$[EMAIL PROTECTED]>
"Melvin Smith" <[EMAIL PROTECTED]> wrote:
> > Foo foo = (Foo) malloc(sizeof(*foo));
> >? Does ANSI allow using sizeof on a variable declared on the
> > same line?
>
> Wouldn't sizeof(Foo) be safer here? At the logical time of the
> call *f
Patch below removes some evil mucking around in string internals that
was in the regular expression engine. All (expected) tests pass on
Windows native and Cygwin. (PerlArrays and PerlHashes are still causing
segfaults on Windows native.)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Per
I'm removing this more common configuration because of the increased time
it takes to build Parrot these days. If someone else wants to pick it up,
cool, but until then I'm figuring that if the other two (mixed 32/64-bit
and pure 64-bit) work, 32-bit probably does too.
- D
<[EMAIL PROTECTED]>
On Thu, 10 Jan 2002, David M. Lloyd wrote:
> The problem is that when you save an int constant on the stack in a
> mixed 32/64-bit system, the int type is 8 bytes but the pointer points
> to four bytes of int constant and four bytes of... something else. So
> it has to be copied out into a temp
New benchmark. Yummy.
Index: Makefile.in
===
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revision 1.112
diff -a -u -r1.112 Makefile.in
--- Makefile.in 9 Jan 2002 22:35:14 - 1.112
+++ Makefile.in 11 Jan 2002 01:5
At 05:58 PM 1/10/2002 -0800, Steve Fink wrote:
>New benchmark. Yummy.
And committed. Thanks.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
Could someone construct a few regexes in both parrot and perl, and run some
benchmarks to see how we're doing with speed here? Nothing final,
certainly, but something to give us an idea of performance.
Dan
--"it's like
At 11:34 PM 1/10/2002 +, Tom Hughes wrote:
>In message <20020110201559$[EMAIL PROTECTED]>
> "Melvin Smith" <[EMAIL PROTECTED]> wrote:
>
>Well sizeof(Foo) and sizeof(*foo) are not actually the same thing
>at all there because Foo is presumably a typedef for a pointer type
>so sizeof(F
Dan Sugalski wrote:
> Okay, I've abused examples/assembly/life.pasm to be a benchmark
> program. It now will time generations/sec, and does rather more than
> mops.pasm does.
Where can I find implementations of this algorithm in other languages,
for instance for Perl 5, Python, Ruby, ..?
--
46 matches
Mail list logo
