On Thursday 03 January 2002 08:40 pm, Paul Baranowski wrote:
> Hi -
> I love what you guys are doing with Parrot. I was just recently
> wondering if it would be possible to transform a program compiled down
> to machine language into byte-code, thereby automatically porting any
> app to any other
At 10:54 PM 1/3/2002 -0500, Melvin Smith wrote:
>At 10:41 PM 1/3/2002 -0500, Dan Sugalski wrote:
>>At 10:02 PM 1/3/2002 -0500, Casey West wrote:
>>>
>>> No such file: io/TODO
>>> No such file: io/io_stdio.c
>>
>>D'oh! Fixed.
>
>FYI those 2 files weren't created in the repository although the r
At 10:41 PM 1/3/2002 -0500, Dan Sugalski wrote:
>At 10:02 PM 1/3/2002 -0500, Casey West wrote:
>>
>> No such file: io/TODO
>> No such file: io/io_stdio.c
>
>D'oh! Fixed.
FYI those 2 files weren't created in the repository although the rest of
that patch was applied. In any case, it wont cause
At 06:17 PM 1/3/2002 -0800, Brent Dax wrote:
>Dan Sugalski:
># At 03:37 PM 1/3/2002 -0800, Brent Dax wrote:
># While cool, I'm interested in why? For regexes you can stash
># a pointer to
># the string buffer into an S register if you want to bypass
># even one level
># of indirection.
>
>Handles
At 09:39 PM 1/3/2002 -0500, Melvin Smith wrote:
>At 09:25 PM 1/3/2002 -0500, Dan Sugalski wrote:
>>At 06:18 PM 1/3/2002 -0800, Steve Fink wrote:
>>>Well, I have Warnock's Dilemma with respect to people with commit
>>>rights for my line numbering patch, but a vote of confidence from Alex
>>>Gough.
At 10:02 PM 1/3/2002 -0500, Casey West wrote:
>Deciding it's time for me to start digging into parrot, I grabbed it
>from CVS and tried to build but configure blew up at:
>
> Checking the MANIFEST to make sure you have a complete Parrot kit...
>
> No such file: io/TODO
> No such file: io/io_
At 02:32 PM 1/3/2002 -0800, Brent Dax wrote:
>The patch below my sig adds a new_stack() function to take care of the
>allocation and setup of "generic" stacks. It's called like:
>
> new_stack(interpreter, &base, &top);
>
>This in preparation for my third regex patch, which I should have r
Deciding it's time for me to start digging into parrot, I grabbed it
from CVS and tried to build but configure blew up at:
Checking the MANIFEST to make sure you have a complete Parrot kit...
No such file: io/TODO
No such file: io/io_stdio.c
Now looking at cvs2web on cvs.perl.org I notice
At 09:25 PM 1/3/2002 -0500, Dan Sugalski wrote:
>At 06:18 PM 1/3/2002 -0800, Steve Fink wrote:
>>Well, I have Warnock's Dilemma with respect to people with commit
>>rights for my line numbering patch, but a vote of confidence from Alex
>>Gough. So here's the PMC inheritance patch (it also includes
At 03:57 PM 1/3/2002 +, Simon Glover wrote:
> The entry in core.ops for puts(s|sc) is missing a =cut and so
> writes a load of junk in core_ops.pod. Applied patch fixes.
Applied, thanks.
Dan
--"it's like this"---
At 09:36 AM 1/3/2002 -0500, Jason Gloudon wrote:
>The PerlInt logical-or is using get_integer instead of get_bool for logical
>operations. This patch corrects that.
Applied, thanks.
Dan
--"it's like this"---
At 10:05 PM 1/2/2002 -0500, Kevin Falcone wrote:
>docs/Makefile should be removed by realclean, but isn't
>I though I saw a patch for this go by at some point
Applied, thanks.
Dan
--"it's like this"---
D
At 06:18 PM 1/3/2002 -0800, Steve Fink wrote:
>Well, I have Warnock's Dilemma with respect to people with commit
>rights for my line numbering patch, but a vote of confidence from Alex
>Gough. So here's the PMC inheritance patch (it also includes the line
>numbering patch). It supersedes both my p
Well, I have Warnock's Dilemma with respect to people with commit
rights for my line numbering patch, but a vote of confidence from Alex
Gough. So here's the PMC inheritance patch (it also includes the line
numbering patch). It supersedes both my previous pmc2c.pl patch and
the followup classes/Ma
Dan Sugalski:
# At 03:37 PM 1/3/2002 -0800, Brent Dax wrote:
# While cool, I'm interested in why? For regexes you can stash
# a pointer to
# the string buffer into an S register if you want to bypass
# even one level
# of indirection.
Handles would probably be used for other things besides regex
Hi -
I love what you guys are doing with Parrot. I was just recently
wondering if it would be possible to transform a program compiled down
to machine language into byte-code, thereby automatically porting any
app to any other machine (at least any statically-compiled app). Does
anyone see any t
At 01:24 PM 1/2/2002 -0800, Steve Fink wrote:
>Index: docs/vtables.pod
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 03:37 PM 1/3/2002 -0800, Brent Dax wrote:
>The attached patch is also in preparation for Rx3 (or whatever you want
>to call it). It implements a new Handle PMC type. Handles simply
>contain pointers. They can't be directly manipulated directly by Parrot
>bytecode; C code uses handle->vtable-
On Thursday 03 January 2002 03:43 pm, Hong Zhang wrote:
> Anyway, we should use some kind of macro for this purpose.
That's more or less what C99 does.
--
Bryan C. Warnock
[EMAIL PROTECTED]
The attached patch is also in preparation for Rx3 (or whatever you want
to call it). It implements a new Handle PMC type. Handles simply
contain pointers. They can't be directly manipulated directly by Parrot
bytecode; C code uses handle->vtable->get_value and ->set_value to
manipulate them. T
The patch below my sig adds a new_stack() function to take care of the
allocation and setup of "generic" stacks. It's called like:
new_stack(interpreter, &base, &top);
This in preparation for my third regex patch, which I should have ready
in a few days.
--Brent Dax
[EMAIL PROTECTED]
C
> > Also, the UL[L] should probably be on the inside of the ():
> >
> > stacklow => '(~0xfffULL)',
>
> I still don't see this one is safer than my proposal.
>
>~((uintptr_t) 0xfff);
Well, if you ever want to specify a constant longer than 0x7fff, you'd
better put a 'u', 'ul' or 'u
> Also, the UL[L] should probably be on the inside of the ():
>
> stacklow => '(~0xfffULL)',
I still don't see this one is safer than my proposal.
~((uintptr_t) 0xfff);
Anyway, we should use some kind of macro for this purpose.
#ifndef foo
#define foo(a) ((uintptr_t) (a))
#endif
On Thu, 3 Jan 2002, Nicholas Clark wrote:
> On Thu, Jan 03, 2002 at 08:46:31AM -0600, David M. Lloyd wrote:
> >
> > Maybe we should be using the Configure output to determine what postfix to
> > use, based on the size of ints, longs, long longs, etc., and pointers,
> > rather than "almost always"
On Thu, 3 Jan 2002, Nicholas Clark wrote:
> On Thu, Jan 03, 2002 at 08:46:31AM -0600, David M. Lloyd wrote:
>
> > Maybe we should be using the Configure output to determine what postfix to
> > use, based on the size of ints, longs, long longs, etc., and pointers,
> > rather than "almost always" b
On Thu, Jan 03, 2002 at 08:46:31AM -0600, David M. Lloyd wrote:
> On Thu, 3 Jan 2002, Bryan C. Warnock wrote:
>
> > On Thursday 03 January 2002 12:33 am, Bryan C. Warnock wrote:
> > > Looks like the chunk_base logic doesn't work on 64-bit Solaris. Every
> > > test failure I checked was centered
The entry in core.ops for puts(s|sc) is missing a =cut and so
writes a load of junk in core_ops.pod. Applied patch fixes.
Simon
--- core.ops.oldThu Jan 3 15:46:20 2002
+++ core.opsThu Jan 3 15:46:54 2002
@@ -370,6 +370,8 @@
Print $1 to standard output stream
+=cut
+
op p
On Thu, 3 Jan 2002, Jarkko Hietaniemi wrote:
> Please find attached a typescript log from a freshly rsynced parrot in
> tru64.
>
> Failed Test Status Wstat Total Fail Failed List of Failed
> -
> t/op/basic.t
Please find attached a typescript log from a freshly rsynced parrot
in tru64 (sizer -v reports 4.0F for the os release, and cc version
is V5.9-011). A bit of whinage from the compiler, mostly of the kind
cc: Warning: perlint.c, line 78: Non-void function "Parrot_PerlInt_get_string_index"
does n
On Thu, 3 Jan 2002, Bryan C. Warnock wrote:
> On Thursday 03 January 2002 12:33 am, Bryan C. Warnock wrote:
> > Looks like the chunk_base logic doesn't work on 64-bit Solaris. Every
> > test failure I checked was centered around an inaccesable address coming
> > out of STACK_CHUNK_BASE(*top) [li
The PerlInt logical-or is using get_integer instead of get_bool for logical
operations. This patch corrects that.
Perlnum and perlstring have working get_bool's, so the default logical_or and
logical_and should be sufficient. The empty methods are pointed to the default
logical_or.
Index: class
On Thursday 03 January 2002 08:11 am, Chip Turner wrote:
> The U was there for sign-correctness. Without it, gcc complains in a
> number of places. I haven't tested it on 64-bit platforms, but on
> 32-bit intel, it is necessary.
>
> uintptr_t sounds good to me, though; always using pointers seem
docs/Makefile should be removed by realclean, but isn't
I though I saw a patch for this go by at some point
Index: Makefile.in
===
RCS file: /cvs/public/parrot/Makefile.in,v
retrieving revision 1.98
diff -u -r1.98 Makefile.in
--- Ma
I am not sure why we need the U postfix in the first place. For literal
like ~0xFFF, the compiler should automatically sign-extends to our
expected size. Personally, I prefer to using ([u]intptr_t) ~0xFFF,
which is more portable. So we don't have to deal with U, UL, i64.
It is possible to use 32-
34 matches
Mail list logo
