(To use Simon's nomenclature)
The long term goal of the Parrot build system (of which configuring is
the major part) is to bootstrap itself from ground zero, a la Parrot
von Münchausen.
Ground zero is here defined as a simple C file (possibly augmented by
one or more simple C headers) and a C co
On Tue 11 Sep 2001 01:35, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> Yes, I'm still interested. Don't know how much I'll have time,
> though, (even after 5.8.0, that is). But I guess (together with Andy)
> we can at least tell horror stories about all the possible ways of how
> *not* to do i
On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote:
> This patch (temporarily) fixes the missing _ic on comparison opcodes.
Didn't apply cleanly. Can you try again from CVS?
Simon
On Mon, Sep 10, 2001 at 11:42:01PM -0700, Matthew Cline wrote:
> This is a first stab at the configure stuff for Parrot.
Damn, I knew I should have got that mail out last night. Sorry,
Matthew.
Simon
On Mon, Sep 10, 2001 at 09:44:24PM -0400, Bryan C. Warnock wrote:
> Following patch defers output of opcode until the end of an error-free run.
> Also introduces a primitive '-c' option to allow checking of assembly only
> (a la Perl).
Sort-of applied. Because I couldn't apply the previous patch
On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl wrote:
> > It's not a prioirty, but it's so much easier to walk the
> > correct path from the start. Since it's all Parrot, it's even easier.
>
> Hear, hear! I remember the pain in 5.005_5* of turning off
> PERL_POLLUTE. I expect that ther
One of the items on the Parrot TODO is to build a Configure
system. I don't want to spark up the old metaconfig-versus-autoconf
debate again, so I'll clarify what I mean.
We have long-term and short-term goals for Parrot's configure
system.
The long-term goal is not something I want people to wo
On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> Have you guys seen Topaz?
I may have heard of it, yes.
> The other major suggestion I have is to avoid "void *"
> interfaces.
I'm using void * to avoid char *. :)
> Do we really need a string_make() that takes
> the encoding enum?
On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote:
> This patch (temporarily) fixes the missing _ic on comparison opcodes.
I'd also like to publically question the wisdom of changing *too much*
of the assembly before we have an assembler that's smart enough to
grok both styles of c
Simon Cozens:
# One of the items on the Parrot TODO is to build a Configure
# system. I don't want to spark up the old metaconfig-versus-autoconf
# debate again, so I'll clarify what I mean.
...
# You'll notice that the Parrot build process currently depends on the
# existence of Perl 5 to build c
On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote:
> A simple "autogenerate what's already in Parrot's config.h" is easy
This is a good start.
> --I've already written a prototype (pasted after my sig)--but
> seems like it's too easy considering what you're talking about. What
> else do
On Mon, 10 Sep 2001 18:48:01 -0400, Dan Sugalski wrote:
>At 12:35 AM 9/11/2001 +0200, Bart Lateur wrote:
>>On Mon, 10 Sep 2001 17:13:44 -0400, Dan Sugalski wrote:
>>
>> >Who the heck is going to override arctangent? (No, don't tell me, I don't
>> >want to know)
>>
>>Perhaps you do. Think BigFloat
Simon Cozens:
# On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote:
# > A simple "autogenerate what's already in Parrot's config.h" is easy
#
# This is a good start.
#
# > --I've already written a prototype (pasted after my sig)--but
# > seems like it's too easy considering what you're talk
http://cobolforgcc.sourceforge.net/cobol_14.html
On Tue, Sep 11, 2001 at 02:49:24AM -0700, Brent Dax wrote:
> Attached are new Configure.pl and config.ht files. Feel free to rename
> config.ht if you want.
I did. Thanks, applied. Now go to sleep. :)
Simon
On Tuesday 11 September 2001 01:14 am, Simon Cozens wrote:
> On Mon, Sep 10, 2001 at 11:42:01PM -0700, Matthew Cline wrote:
> > This is a first stab at the configure stuff for Parrot.
> Damn, I knew I should have got that mail out last night. Sorry,
> Matthew.
Well, the autoconf/automake confi
On Tue, Sep 11, 2001 at 03:06:27AM -0700, Matthew Cline wrote:
> Is parrot going to have it's own makefile generator, or should it use
> autoconf?
Please read my other mail on this.
Simon
Seeing as Simon's gone to all the trouble of releasing the source to
Parrot now, I wondered what I could have a play with. I've did simple
Parrot assembler and thought about different types of bytecode. Like
bytecode for the Java virtual machine, which it turns out is stack
based. Could I convert
On Tuesday 11 September 2001 04:13 am, Simon Cozens wrote:
> On Mon, Sep 10, 2001 at 09:24:33PM -0400, Bryan C. Warnock wrote:
> > This patch (temporarily) fixes the missing _ic on comparison opcodes.
>
> Didn't apply cleanly. Can you try again from CVS?
>
> Simon
I'll wait until the rest of the
Hi.
I've just tried getting Parrot running on a Solaris 8 box here, but it's
coredumping on me with test2.pasm and test3.pasm:
cass87:pak:~/data2/parrot$ ./test_prog test.pbc
I reg 1 is 1000206849
I reg 5 is 1000206859
I reg 2 is 1000
I reg 2 is 10
I reg 4 is 3000
N reg 1 is 3000.
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl
> wrote:
> > > It's not a prioirty, but it's so much easier to walk
> the
> > > correct path from the start. Since it's all Parrot,
> it's even easier.
> >
> > Hear, hear! I remember the pain i
It seems to me that Parrot should expose a "feature
testing" API. Something on the order of
int [read: boolean] par_has_feature(PAR_STRING *feature);
(yes, I _do_ think that claiming STRING is unnecessary
namespace pollution - sepecially as ANSI compilers, AFAIK,
aren't required to be case-sensi
At 05:25 AM 9/11/2001 -0700, Benjamin Stuhl wrote:
>However, before I do this, I would like to bring up
>the question of prefixes once again. Do we really need a 7
>letter, mixed-case prefix (Parrot_)?
Externally exposed, yes.
That's not to say that the programmer working inside the core needs t
Simon Cozens wrote:
> On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> > Have you guys seen Topaz?
>
> I may have heard of it, yes.
That's it? You're rejecting all of that work without
learning anything from it? Building strings on buffers
looked like a really good idea.
In general I
Folks,
If anyone was planning to go to the Boston perlmongers meeting to see the
parrot demo, be aware that the meeting has been cancelled. We'll try again
at the next meeting.
Dan
--"it's like this"--
On Tue, Sep 11, 2001 at 12:15:37PM -0400, Ken Fox wrote:
> Simon Cozens wrote:
> > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> > > Have you guys seen Topaz?
> >
> > I may have heard of it, yes.
>
> That's it? You're rejecting all of that work without
> learning anything from it?
At 01:35 PM 9/11/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > If you're speaking of multiple buffers for a string or something like that,
> > you're looking at too low a level. That's something that should go in the
> > variables, not in the string bits. (We do *not* want all string ops slo
Simon Cozens writes:
> I am in two minds here. I want to have Parrot_... prefices on
> functions even if they're *not* completely necessary /pour
> encourager les autres/. However, I don't want to go the way of
> opening up everything in a public API righht now, because once
> you've exported a s
At 12:15 PM 9/11/2001 -0400, Ken Fox wrote:
>Simon Cozens wrote:
> > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> > > Have you guys seen Topaz?
> >
> > I may have heard of it, yes.
>
>That's it? You're rejecting all of that work without
>learning anything from it? Building strings on
On Tue, Sep 11, 2001 at 10:20:57AM -0600, Nathan Torkington wrote:
> Part of "configuration" could be building a #define pile so you can
> use foo and bar in the .c files, but they're invisibly translated into
> Parrot_ and so on equivalents.
If I do this, people *will* complain I'm going the way
"Bryan C. Warnock" wrote:
> On Monday 10 September 2001 09:30 pm, Dan Sugalski wrote:
> > gotos into scopes might not be allowed.
>
> That's how it currently is for most scopes, and it certainly saves a
> whole lot of trouble and inconsistencies.
I'm not sure I understand what you mean. Perl 5 a
At 12:41 PM 9/11/2001 -0400, Ken Fox wrote:
>And of course the keywords last, next and redo are just restricted
>gotos. Those are able to leave one or more scopes.
Leaving scopes is easy. You just walk up the stack and deconstruct things.
(Or, in this case, potentially run the end-of-scope code
It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is
fine. The coredump doesn't show much, only that it keeled over at
interpreter.c line 16, which is the while() loop.
Once upon a time Philip Kendall shaped the electrons to say...
>
>
> Hi.
>
> I've just tried getting Pa
Dan Sugalski wrote:
> If you're speaking of multiple buffers for a string or something like that,
> you're looking at too low a level. That's something that should go in the
> variables, not in the string bits. (We do *not* want all string ops slow to
> support flexibility of this sort. Only the b
On Tuesday 11 September 2001 12:41 pm, Ken Fox wrote:
> I'm not sure I understand what you mean. Perl 5 allows us to enter
> and leave scopes with goto:
Perl 5 allows you to leave most scopes (sort being the only exception), but
just over half the constructs that introduce scope allow you to ent
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote:
> Nothing should read out of interp_guts.h. That's autogenerated from
> opcode_table. Or it was yesterday, but things might've changed. :)
Sorry, but things have changed. This is now where the op number assignments
are stored.
Simon
On Mon, Sep 10, 2001 at 09:10:17PM -0400, Bryan C. Warnock wrote:
> Okay, we'll start small. "length_s_i" is backwards - should be "length_i_s".
> Patch fixes code and test.
Thanks, applied.
37 matches
Mail list logo
