Robert Spier <[EMAIL PROTECTED]> writes:
> On Tue, 2001-10-23 at 20:52, Russ Allbery wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>>> Once we build miniparrot, then *everything* can be done in
>>> perl. Having hacked auto* stuff, I think that'd be a good
>>> thing. (autoconf and friends are
On Tue, 2001-10-23 at 20:52, Russ Allbery wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > Once we build miniparrot, then *everything* can be done in perl. Having
> > hacked auto* stuff, I think that'd be a good thing. (autoconf and
> > friends are unmitigated evil hacks--people just don't
When trying to make a clean checkout, I ran into these errors:
pdump.c: In function `main':
pdump.c:63: warning: passing arg 1 of `PackFile_unpack' from incompatible pointer type
pdump.c:63: warning: passing arg 2 of `PackFile_unpack' from incompatible pointer type
pdump.c:63: warning: passing a
I couldn't help but notice that the current parrot interpreter
generates a divide-by-zero error when executing 'div I0,I1,0'. I'm
currently packaging up a set of patches that adds the following set of
features to parrot:
1) An exception stack (The stack prefix is 'E')
2) Instructions push_e,
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Once we build miniparrot, then *everything* can be done in perl. Having
> hacked auto* stuff, I think that'd be a good thing. (autoconf and
> friends are unmitigated evil hacks--people just don't realize how nasty
> they are because they never need to lo
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
>> While imperfect and Unix-centric, we can (and should!) learn a lot
>> from auto{conf,make} and metaconfig.
> *nod*. I just had a look around, and most of the other languages are
> using
On Tue, Oct 23, 2001 at 12:39:17PM -0600, Nathan Torkington wrote:
> > *) Scalar PMCs
> > *) Simple I/O
> > *) A simple arena allocation system
0.03
> > *) Multiple interpreter & thread creation
> > *) Garbage collection
0.04
That's to say, 0.03 won't be released without the above three things
At 12:39 PM 10/23/2001 -0600, Nathan Torkington wrote:
>Is there a good reason to delay allocation until after the things that
>allocate memory have been written?
Yep. If the interface is in place, which it pretty much is, we can stub in
the allocation and deallocation stuff. For the moment it c
Dan Sugalski writes:
> Okay, here's a tentative list 'o stuff that is in the works for Parrot 0.03
> (and possibly 0.04):
>
> *) Scalar PMCs
> *) Simple I/O
> *) Multiple interpreter & thread creation
> *) A simple arena allocation system
> *) Garbage collection
Sweet! I guess Simon and you sh
All --
Possibly just for fun, here are some obscure trigonometric ops to
complement the trig ops we already have.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Pur
On Tue, 23 Oct 2001, Dan Sugalski wrote:
> At 12:05 PM 10/23/2001 -0400, Sam Tregar wrote:
> >PS: CVS! CVS! CVS CVS CVS!
>
> Someone send me the files needed for Scheme and I'll check 'em in.
I'll leave that to Jeff since it's his baby. You'll probably also want to
give him CVS commit privs for
At 12:05 PM 10/23/2001 -0400, Sam Tregar wrote:
>PS: CVS! CVS! CVS CVS CVS!
Someone send me the files needed for Scheme and I'll check 'em in.
Dan
--"it's like this"---
Dan Sugalski
Here's a patch to re-fix comparisions in the Scheme compiler. The
patch:
- Makes (<),(>),(<=),(>=) and (=) behave correctly on more than two
args.
- Adds tests to affirm this and fixes tests that were incorrect.
Sidenote: I don't think it's going to be possible to do static type
inf
On Tue, Oct 23, 2001 at 11:24:52AM -0400, Dan Sugalski wrote:
> >Surely we can be 'one-more' than the nearest competition, not a few dozen,
> >and feel proud?
>
> Screw the competition. We need to be better than we are.
As I thought. Then auto{foo} is out. Sorry, guys. It ain't good enough.
> A
I don't think we can solve this here. This is something that has been a
problem for some time, with solutions of various success. We already have
the options of Ant, XPInstall, RPM, and many others, but I tend to believe
that the most widely known tools are the auto* stuff. That counts for a lot.
At 11:29 AM 10/23/2001 -0400, Gregor N. Purdy wrote:
>I'm wondering if there is something we can refactor so that we don't
>have to link interpreter.o into things like like pdump. Pdump doesn't
>want to be an interpreter. It doesn't want to run ops. But, passing
>the interpreter arg into PackFile_
At 02:51 PM 10/23/2001 +0200, Bart Lateur wrote:
>On Tue, 23 Oct 2001 08:39:29 -0400, John Siracusa wrote:
>
> >As one of the few rabid Mac users on this list, let me just say that I
> >personally have no problem with classic Mac OS support being totally dropped
> >from Parrot if it'll get stuff o
At 08:39 AM 10/23/2001 -0400, John Siracusa wrote:
>(Also, I'd be much happier if those resources could be redirected to making
>sure Perl 6, apache, mod_perl, etc. all builds as easily on OS X as they do
>on, say, Solaris...but now I'm just whining ;)
I've a machine destined for MacOS X waiting
On Tue, 23 Oct 2001, Daniel Grunblatt wrote:
> Suppose auto{conf|make} is OK, won't there be any copyright issue?
Probably not.
The scripts generated by autoconf do not fall under the GPL. (They did
for autoconf-1, but that restriction was changed years ago.) The end user
need not have autoco
At 03:02 AM 10/23/2001 -0400, James Mastros wrote:
>I don't see what chr() should look like, though. What's the interface to
>multiple encodings on the opcode level? I'd like to just say that chr
>always creates a utf32 string.
Nope, can't do that.
>String encodings don't have fixed numbers in
Dan --
I'm wondering if there is something we can refactor so that we don't
have to link interpreter.o into things like like pdump. Pdump doesn't
want to be an interpreter. It doesn't want to run ops. But, passing
the interpreter arg into PackFile_unpack means the caller needs to
have one laying
At 11:10 AM 10/23/2001 -0400, Michael Fischer wrote:
>On Oct 23, Simon Cozens <[EMAIL PROTECTED]> took up a keyboard and
>banged out
> > On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
> > > While imperfect and Unix-centric, we can (and should!) learn a lot
> > > from auto{conf,ma
At 06:53 AM 10/23/2001 +0100, Simon Cozens wrote:
>On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote:
> > 1) Build minimal perl 6 with default parameters using platform build tool
>
>But "platform build tool" is going to be 'make' - the alternative is
>that we maintain and ship every fl
On Oct 23, Simon Cozens <[EMAIL PROTECTED]> took up a keyboard and banged out
> On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
> > While imperfect and Unix-centric, we can (and should!) learn a lot
> > from auto{conf,make} and metaconfig.
>
> *nod*. I just had a look around, and
Suppose auto{conf|make} is OK, won't there be any copyright issue?
And by the way, does any one have an idea of what will be the copyright of
Parrot? I would really love it to be BSD, but since I haven't contributed
(yet) with any source code/idea/anything my opinion doesn't count.
On Tue, 23 Oc
Last success was
Automated smoke report for patch Oct 20 19:00:01 2001 UTC
v0.02 on hpux using cc version B.11.11.02
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Config
On Tue, 23 Oct 2001, Simon Cozens wrote:
> On Tue, Oct 23, 2001 at 02:39:37PM +0100, Alex Gough wrote:
> > Parrot_base_vtables[enum_class_int] = (struct _vtable) {
>
> This construct is a little dodgy, but I couldn't think of
> a better way to do it. Alex, could you try manually hacking
> it to u
On Tue, Oct 23, 2001 at 02:39:37PM +0100, Alex Gough wrote:
> Parrot_base_vtables[enum_class_int] = (struct _vtable) {
This construct is a little dodgy, but I couldn't think of
a better way to do it. Alex, could you try manually hacking
it to use a temporary variable, like this:
struct _vtab
MIPSPro doesn't like us again, the following error means I cannot compile
on IRIX (gcc continues to work fine):
classes/intclass.c is generated from vtable.tbl by classes/genclass.pl,
the offending lines in the generated code are:
void Parrot_int_init (void) {
Parrot_base_vtables[enum_class_
On Tue 23 Oct 2001 14:51, Bart Lateur <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Oct 2001 08:39:29 -0400, John Siracusa wrote:
>
> >As one of the few rabid Mac users on this list, let me just say that I
> >personally have no problem with classic Mac OS support being totally dropped
> >from Parrot if
On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
> While imperfect and Unix-centric, we can (and should!) learn a lot
> from auto{conf,make} and metaconfig.
*nod*. I just had a look around, and most of the other languages are
using autoconf. But then, most of the other languages do
On Tue, 23 Oct 2001, Simon Cozens wrote:
> On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote:
> > autoconf automake libtool
>
> MVS, MacOS, cross-compilation.
True, but ... .
While imperfect and Unix-centric, we can (and should!) learn a lot
from auto{conf,make} and metaconfig.
On Tue, 23 Oct 2001 08:39:29 -0400, John Siracusa wrote:
>As one of the few rabid Mac users on this list, let me just say that I
>personally have no problem with classic Mac OS support being totally dropped
>from Parrot if it'll get stuff out the door sooner :) Classic Mac OS is
>(somewhat sadly
If you think the ideas expressed in my previous post are sensible, I
can go through my "MakeMake" and put together a design document, about
what to seek and what to avoid, as far as I can tell.
Additional issues (not mentioned in my post) would be:
* usage of the front-end
* dire
On 10/23/01 8:16 AM, Paolo Molaro wrote:
> On 10/23/01 Simon Cozens wrote:
>> On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote:
>>> autoconf automake libtool
>>
>> MVS, MacOS, cross-compilation.
> [...]
> MacOS: I guess any type of Makefile based build system would not work on
> MacOS
On 10/23/01 Simon Cozens wrote:
> On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote:
> > autoconf automake libtool
>
> MVS, MacOS, cross-compilation.
cross-compilation is not an issue at all with auto* (I'd say it makes it
almost easy to support it).
MacOS: I guess any type of Ma
On Tue, Oct 23, 2001 at 08:08:27AM +1000, Damian Conway wrote:
>
>> > To check for numericity of input, you'll write:
>> >
>> > $number = +<$fh>
>> > until defined $number;
>> >
>> > If you ignore the definedness, the C will just promote to zero
>
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote:
> > 1) Build minimal perl 6 with default parameters using platform build tool
>
> But "platform build tool" is going to be 'make' - the alternative is
> that we maintain and ship every flavou
On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote:
> autoconf automake libtool
MVS, MacOS, cross-compilation.
Consider yourself flamed; you know how to make the rest up. :)
--
"Even had to open up the case and gaze upon the hallowed peace that
graced the helpdesk that day." -
On 10/23/01 Simon Cozens wrote:
> On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote:
> > 1) Build minimal perl 6 with default parameters using platform build tool
>
> But "platform build tool" is going to be 'make' - the alternative is
> that we maintain and ship every flavour of batch
Some of you may remember (and some wish we could forget) a ramble I
posted about six months back about traffic lights and language design
and all the weird ways we get meaning out of such a small # of
symbols. One of the things I'd pondered was using color for syntax.
Well, somebody else did. I
41 matches
Mail list logo
