Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The draft todo/worklist

3 views
Skip to first unread message

Dan Sugalski

unread,
Jan 12, 2003, 9:39:10 PM1/12/03
to perl6-i...@perl.org
Okay, this has been sitting around for a while, and it's time to dump
it. This is reasonably high-level, and a bit terse, so I'm throwing
it out for discussion/addition/fleshing out. Comments, please. (As if
I have to ask... :)

*) freeze/thaw for PMCs
*) object, draft 2
*) Objects, implemented
*) Fixed disassembler
*) ICU building
*) Unicode encoding
*) One other non-latin encoding & charset
*) IMCC built into parrot
*) Dynamic bytecode creation spec & implementation
*) Vtable splitup
*) Exceptions
*) No warnings on compilation
*) long long and long double builds, even without perl 5 support
*) Perl 6 built as part of core build and test
*) Dynamic bytecode loading
*) z-code interpreter
*) JIT test with tinderbox tests
*) Foreign bytecode loading
*) Parrot IO fully defined and implemented
*) Working "make install"
*) Answer Leo's outstanding questions
*) Finish perl 6 regex implementation
*) Working perl 5 parser


--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Mr. Nobody

unread,
Jan 13, 2003, 1:12:33 AM1/13/03
to perl6-i...@perl.org
--- Dan Sugalski <d...@sidhe.org> wrote:
> *) ICU building
> *) Unicode encoding

Do we really need unicode in parrot? Seems to me like it dosen't really
accomplish much but making string operations much slower. People would still
be able to use it even if strings aren't encoded with it.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Brent Dax

unread,
Jan 13, 2003, 1:26:52 AM1/13/03
to Mr. Nobody, perl6-i...@perl.org
Mr. Nobody:
# --- Dan Sugalski <d...@sidhe.org> wrote:
# > *) ICU building
# > *) Unicode encoding
#
# Do we really need unicode in parrot? Seems to me like it
# dosen't really accomplish much but making string operations
# much slower. People would still be able to use it even if
# strings aren't encoded with it.

I suspect you have English blinders over your eyes.

We need to support non-ASCII encodings to support people in other
countries. We need to support Unicode so that data can be converted
between all these encodings without a combinatorial explosion of
converters.

If we don't implement Unicode ourselves, every language that uses
Unicode (including Perl, with the :uN regex modifiers) will have to
implement it--separately, slowly and probably incompletely. This is
going to lead to bugs, incompatibility, holes in functionality and other
generally Bad Things.

Would you rather that Parrot implement Unicode once and make sure it's
right, or that a dozen languages all implement their own incompatible,
broken Unicode systems?

--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be


Leopold Toetsch

unread,
Jan 13, 2003, 4:08:28 AM1/13/03
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski wrote:

> Okay, this has been sitting around for a while, and it's time to dump
> it. This is reasonably high-level, and a bit terse, so I'm throwing it
> out for discussion/addition/fleshing out. Comments, please. (As if I
> have to ask... :)


Do you have a less terse version?


> *) IMCC built into parrot


parrot is already built into imcc, though ~1 line is missing:
Parrot_readbc().


leo

James Michael Dupont

unread,
Jan 13, 2003, 9:12:59 AM1/13/03
to Dan Sugalski, perl6-i...@perl.org

--- Dan Sugalski <d...@sidhe.org> wrote:
> *) Fixed disassembler
I will volunteer to take over on this and get it working if no one has
time for it.

> *) Working "make install"
see next note :

*) Support for cross compilation
i think that it is important that we really come to terms with the new
configure tool. To be honest, i like the idea of using a perl based
configurator, and my research into autoconf and automake might feed
into this.

How far do you plan on stepping on autoconfs toes with this? Do you
want to continue with a special solution, or does not it make sense to
turn around and go back to automake and autoconf?

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

Nicholas Clark

unread,
Jan 13, 2003, 9:28:01 AM1/13/03
to James Michael DuPont, Dan Sugalski, perl6-i...@perl.org
On Mon, Jan 13, 2003 at 06:12:59AM -0800, James Michael DuPont wrote:

> *) Support for cross compilation
> i think that it is important that we really come to terms with the new
> configure tool. To be honest, i like the idea of using a perl based
> configurator, and my research into autoconf and automake might feed
> into this.
>
> How far do you plan on stepping on autoconfs toes with this? Do you
> want to continue with a special solution, or does not it make sense to
> turn around and go back to automake and autoconf?

Well, http://www.gnu.org/software/autoconf/autoconf.html says:
Autoconf is an extensible package of m4 macros that produce shell scripts
...
These scripts can adapt the packages to many kinds of UNIX-like systems

Automake says (http://www.gnu.org/software/automake/automake.html):
Automake requires the use of GNU Autoconf.

which implies that autoconf needs a shell to run the configure system it
generates. That's not going to work for Win32

(Not that I use Win32 personally, but I like things to work on Win32 because
then no-one complains that things don't work, and so I can pretend it doesn't
exist. I'm speaking personally here - other people working on parrot
probably have much less selfish views on Win32)


Or have I misunderstood all this?

Nicholas Clark

James Michael Dupont

unread,
Jan 13, 2003, 9:42:51 AM1/13/03
to Nicholas Clark, Dan Sugalski, perl6-i...@perl.org

--- Nicholas Clark <ni...@ccl4.org> wrote:
> On Mon, Jan 13, 2003 at 06:12:59AM -0800, James Michael DuPont wrote:
>
> > *) Support for cross compilation
> > i think that it is important that we really come to terms with the
> new
> > configure tool. To be honest, i like the idea of using a perl based
> > configurator, and my research into autoconf and automake might feed
> > into this.
> >
> > How far do you plan on stepping on autoconfs toes with this? Do you
> > want to continue with a special solution, or does not it make sense
> to
> > turn around and go back to automake and autoconf?
>
> Well, http://www.gnu.org/software/autoconf/autoconf.html says:
> Autoconf is an extensible package of m4 macros that produce shell
> scripts
> ...
> These scripts can adapt the packages to many kinds of UNIX-like
> systems

well, the m4 is not needed to run the configure.

>
> Automake says (http://www.gnu.org/software/automake/automake.html):
> Automake requires the use of GNU Autoconf.

automake is written in perl

>
> which implies that autoconf needs a shell to run the configure system
> it
> generates. That's not going to work for Win32

yes, unless you translate that shell into perl for execution.

>
> (Not that I use Win32 personally, but I like things to work on Win32
> because
> then no-one complains that things don't work, and so I can pretend it
> doesn't
> exist. I'm speaking personally here - other people working on parrot
> probably have much less selfish views on Win32)

I aggree that win32 is important, but as perl is ported, m4 and shell
have also been ported. (if you look at mingw32-sys and cygwin you will
see that)

Again, i like the new configure script, but it will need expansion to
handle more responsabilites. I dont like the configure scripts, but
they work, and many people support them, not the question is,
do you want to beef put the new system to handle cross compiling and
other configure responsabilities?

Do you want to make a replacement for autoconf in general?
I have been looking into bashdb, it supports the debugging of bash
scripts.

It is an idea to translate the configure scripts via bashdb into perl
and to use that to create new features for the perl configure scripts.

Also, the m4 macros can themself be modified directly into perl because
they are used to generate the configuration tests.

but this all needs lot of work and will take months to do, the question
is how far are we with configure and how happy are you with it?

Dan Sugalski

unread,
Jan 13, 2003, 10:57:37 AM1/13/03
to Mr. Nobody, perl6-i...@perl.org
At 10:12 PM -0800 1/12/03, Mr. Nobody wrote:
>--- Dan Sugalski <d...@sidhe.org> wrote:
>> *) ICU building
>> *) Unicode encoding
>
>Do we really need unicode in parrot?

Yes, we do. There's a lot of data out in the world that's Unicode-encoded.

> Seems to me like it dosen't really
>accomplish much but making string operations much slower.

Who said it would be the default encoding? The list is terse, true,
but look at the architecture. Parrot should be able to handle
multiple encodings simultaneously.

Dan Sugalski

unread,
Jan 13, 2003, 10:58:32 AM1/13/03
to Leopold Toetsch, perl6-i...@perl.org
At 10:08 AM +0100 1/13/03, Leopold Toetsch wrote:
>Dan Sugalski wrote:
>
>>Okay, this has been sitting around for a while, and it's time to
>>dump it. This is reasonably high-level, and a bit terse, so I'm
>>throwing it out for discussion/addition/fleshing out. Comments,
>>please. (As if I have to ask... :)
>
>
>Do you have a less terse version?

Not yet--I've been throwing bullet points into a file so I wouldn't
forget too many of them.

>
>>*) IMCC built into parrot
>
>
>parrot is already built into imcc, though ~1 line is missing: Parrot_readbc().

Then lets get it integrated in so a base parrot build has IMCC in it.

Dan Sugalski

unread,
Jan 13, 2003, 11:32:06 AM1/13/03
to James Michael DuPont, perl6-i...@perl.org
At 6:12 AM -0800 1/13/03, James Michael DuPont wrote:
>--- Dan Sugalski <d...@sidhe.org> wrote:
>> *) Fixed disassembler
>I will volunteer to take over on this and get it working if no one has
>time for it.

I had a fix for it in my inbox, so I applied it and this is no longer
an issue. :)

> > *) Working "make install"
>see next note :
>
>*) Support for cross compilation
>i think that it is important that we really come to terms with the new
>configure tool. To be honest, i like the idea of using a perl based
>configurator, and my research into autoconf and automake might feed
>into this.
>
>How far do you plan on stepping on autoconfs toes with this?

I don't plan on stepping on autoconf's toes only because I don't plan
on paying much attention to it. We can't rely on it since our
cross-platform needs are past what it can deliver, unfortunately.

James Michael Dupont

unread,
Jan 13, 2003, 11:46:56 AM1/13/03
to Dan Sugalski, perl6-i...@perl.org

--- Dan Sugalski <d...@sidhe.org> wrote:
> At 6:12 AM -0800 1/13/03, James Michael DuPont wrote:
> >--- Dan Sugalski <d...@sidhe.org> wrote:
> >> *) Fixed disassembler
> >I will volunteer to take over on this and get it working if no one
> has
> >time for it.
>
> I had a fix for it in my inbox, so I applied it and this is no longer
> an issue. :)

cool!

>
> > > *) Working "make install"
> >see next note :
> >
> >*) Support for cross compilation
> >i think that it is important that we really come to terms with the
> new
> >configure tool. To be honest, i like the idea of using a perl based
> >configurator, and my research into autoconf and automake might feed
> >into this.
> >
> >How far do you plan on stepping on autoconfs toes with this?
>
> I don't plan on stepping on autoconf's toes only because I don't plan
> on paying much attention to it. We can't rely on it since our
> cross-platform needs are past what it can deliver, unfortunately.

Ok, well, I would like to review how it is possible to transfer some
more logic from autoconf into Configure.pl, specifically the --host and
--target options.

I *do* like the idea of using perl instead of shell for running the
configure scripts, just would like to get a handle on how to port more
over.

The debugging of shell scripts is one thing that should be put to an
end.

0 new messages