Gregor N. Purdy sent the following bits through the ether:
> I'd like to see the folks with other language implementations speak
> up again about their current status and desires to have their stuff
> in CVS
My JVM -> Parrot stuff is going slowly, but parts of a Better Solution
are going up on C
At 04:13 PM 10/20/2001 -0700, Robert wrote:
>On Thu, 2001-10-11 at 12:24, Dan Sugalski wrote:
> > No, we don't have to do it in C. We can do it in perl, we just can't
> > require perl for the initial build. The steps would be:
> >
> > 1) Build minimal perl 6 with default parameters using platform
At 07:10 PM 10/20/2001 -0400, Sam Tregar wrote:
>PS: Can we get this into languages/scheme?
I'm OK with that.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED
Okay, we've now got minimal:
*) Parrot assembly
*) Perl
*) Python
*) JVM
*) Scheme
*) Jako
*) Ruby? (Do we? I can't remember for sure)
support for Parrot. This is a cool thing, but it brings up the questions:
1) Do we put them all in the parrot CVS tree
2) Do we require the
On Sat, Oct 20, 2001 at 10:12:55PM +0200, Mattia Barbon wrote:
> > Any volunteers to hack in distclean?
> What does it exactly do? Delete everything not in MANIFEST?
Yeah, but I did it as part of my PMC fiddling over this past weekend.
--
By God I *KNOW* what this network is for, and you can't
On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> num_type: 0, 1, 2, 3, 4, 5 for "same as you", native int, bigint, native
>float, bigfloat, object
>
> P1->vtable_funcs[VTABLE_ADD + P2->num_type](P1, P2, P0);
I don't understand the "same as you" thing; num_type is
At 11:00 PM 10/19/2001 -0400, Bryan C. Warnock wrote:
>On Friday 19 October 2001 01:46 pm, Dan Sugalski wrote:
> > I'm currently leaning either towards returning values in registers
> > [PSIN][0-4] with the total number of each type in register I0 somehow
>
>Order determination of the return v
At 02:59 PM 10/20/2001 +0100, Simon Cozens wrote:
>On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> > num_type: 0, 1, 2, 3, 4, 5 for "same as you", native int, bigint, native
> >float, bigfloat, object
> >
> > P1->vtable_funcs[VTABLE_ADD + P2->num_type](P1, P2, P0)
At 07:12 PM 10/20/2001 -0400, Sam Tregar wrote:
>On 20 Oct 2001, Gregor N. Purdy wrote:
>
> > I want to libify everything to the point where Perl wrappers around
> > the libs allow you to pass the .pasm stuff as a string and get back
> > a packfile that you can pass on to the interpreter, without
At 08:11 PM 10/20/2001 +0200, raptor wrote:
>hi,
>
>will it be possible to do this inside Perl program :
>
>
>use parrot;
>...parrot code...
>no parrot;
>OR
>
>sub mysub is parrot {
> parrot code ...
>}
I suppose. I hadn't planned on inlining parrot assembly into any other
language. (The fir
On Wed, Oct 10, 2001 at 11:27:24AM +0200, Paolo Molaro wrote:
> ... and to go a step further in sanity and maintainability, I'd suggest
> using a structure with properly typed function pointers instead of an
> array:
>
> typedef void (*parrot_pmc_add) (PMC *dest, PMC *a, PMC *b);
> typedef vo
On Sun, Oct 21, 2001 at 12:20:29PM -0400, Dan Sugalski wrote:
>
> I suppose. I hadn't planned on inlining parrot assembly into any other
> language. (The first person who suggests an asm() function *will* get
> smacked... :) You'll certainly be able to use modules written purely in
> parrot a
At 03:41 PM 10/21/2001 -0400, Rocco Caputo wrote:
>On Sun, Oct 21, 2001 at 12:20:29PM -0400, Dan Sugalski wrote:
> >
> > I suppose. I hadn't planned on inlining parrot assembly into any other
> > language. (The first person who suggests an asm() function *will* get
> > smacked... :) You'll certai
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I've given it a few places, but I don't know that I've sent it to
> perl6-internals. If not, or if I should do it again, let me know. I want to
> make sure we're all on the same page here.
Not that I recall. I tho
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> I've now changed the vtable structure to reflect this, but I'd like someone
> to confirm that the "variant" forms of the ops can be addressed the way I
> think they can. (ie. structure->base_element + 1 to get "thi
In message <[EMAIL PROTECTED]>
Jason Gloudon <[EMAIL PROTECTED]> wrote:
> The "stacktest" patch will fail on the current CVS source, due to a bug in
> push_generic_entry.
This looks good to me so I have committed it. Thanks for spotting it!
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http
On Sun, Oct 21, 2001 at 07:56:08PM +0100, Simon Cozens wrote:
> On Wed, Oct 10, 2001 at 11:27:24AM +0200, Paolo Molaro wrote:
> > ... and to go a step further in sanity and maintainability, I'd suggest
> > using a structure with properly typed function pointers instead of an
> > array:
> >
> > ty
OK, I did a little (stress "little") work on PMCs this weekend.
Let me just explain how I see PMCs as working, and then I'll explain what
I've done.
PMCs are essentially objects on which methods are called. These objects
will usually come from pre-defined "classes": Parrot will ship with a bunch
A while back I wondered if a higher-level VM might be
useful for implementing higher-level languages. I
proposed a lexically scoped machine without registers
or stacks. The response wasn't encouraging.
A quick tour through the library turned up a few
machine designs that sounded very similar to w
I'm back. I notified Simon on the tenth that I was going to be away
until today. I'm trying to catch up on the nine-hundred-odd messages
the p6? and p5p have thrown at me, so I may be realistically out of
commission for a couple days more.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Pe
20 matches
Mail list logo
