Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-30 Thread Jonathan Worthington

Joshua Hoblitt [EMAIL PROTECTED] wrote:

On Tue, Oct 25, 2005 at 11:49:33PM +0100, Jonathan Worthington wrote:
 If people have free time to spend on configure stuff, might it not be
 better spent working on the real configure system that we want to have
 (e.g. a set of makefiles for each platform to build miniparrot, then
 configure is a Parrot program run by miniparrot that figures stuff out 
 that

 we need to build the full Parrot)?

Perhaps this is just me being navie but I had imagined that some form of
the existing Configure system would live on as PIR/PBC that included
with the distribution to executed by miniparrot. Someday we will be be
able to compile perl5 to PIR, right?  Or even p5 - p6 - PIR.  ;)
One would certainly hope so.  :-)  I guess this approach can work if the 
code produced by the Perl 5 compiler only contains the subset of Parrot 
functionality that MiniParrot can handle.


Jonathan 



Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-30 Thread Joshua Hoblitt
On Sun, Oct 30, 2005 at 09:13:31PM -, Jonathan Worthington wrote:
 One would certainly hope so.  :-)  I guess this approach can work if the 
 code produced by the Perl 5 compiler only contains the subset of Parrot 
 functionality that MiniParrot can handle.

The constraint can be pushed higher up the stack as well.  It might mean
that Configure.pl has to be written in some subset of p5/p6 that can be
supported by miniparrot.  Or that the compiler has a miniparrot target
that possibly fudges correctness in exchange for being less demanding on
the runtime.  In any case it probably makes more sense to figure what we
want the design of Configure.pl to look like before we start considering
implementation trade offs for a compiler the doesn't yet exist. ;)

-J

--


pgpiAxE83zYl6.pgp
Description: PGP signature


Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-25 Thread chromatic
On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote:

 Minor nit: when running Configure.pl with --nomanicheck, Configure  
 should report the MANIFEST check as skipped, not done.

particle beat me to this one, but *wow* the plugin system for
configuration is grotty.  Does anyone have a particular attachment to
it?  Would it be useful to clean it up a little bit, or does it need
patching or updating very often?

-- c



Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-25 Thread Matt Diephouse
chromatic [EMAIL PROTECTED] wrote:
 On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote:

  Minor nit: when running Configure.pl with --nomanicheck, Configure
  should report the MANIFEST check as skipped, not done.

 particle beat me to this one, but *wow* the plugin system for
 configuration is grotty.  Does anyone have a particular attachment to
 it?  Would it be useful to clean it up a little bit, or does it need
 patching or updating very often?

I can say that the one time I tried to patch it, I gave up. (My
perldoc installation got hosed, so that the executable is there but
none of the documentation is, so parrot thinks it's not there.) So
it'd definitely be nice... but I don't know that it's a very high
priority.

--
matt diephouse
http://matt.diephouse.com


Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-25 Thread jerry gay
On 10/25/05, chromatic [EMAIL PROTECTED] wrote:
 On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote:

  Minor nit: when running Configure.pl with --nomanicheck, Configure
  should report the MANIFEST check as skipped, not done.

 particle beat me to this one, but *wow* the plugin system for
 configuration is grotty.  Does anyone have a particular attachment to
 it?  Would it be useful to clean it up a little bit, or does it need
 patching or updating very often?

i'd love to see configure updated to use a better plugin system. it's
difficult to extend or maintain without serious knowledge of the magic
it uses. i already know more than i want to about configure, but i'm
still nervous about modifying it.

i've started developing a plugin architecture for $work, so i've been
thinking about plugin engines lately. if you're up for working on a
redesign, i'll gladly pitch in. even if you're looking only to clean
it up, i'd certainly appreciate the effort.

~jerry


Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-25 Thread Nicholas Clark
On Tue, Oct 25, 2005 at 01:16:27PM -0700, jerry gay wrote:

 i've started developing a plugin architecture for $work, so i've been
 thinking about plugin engines lately. if you're up for working on a
 redesign, i'll gladly pitch in. even if you're looking only to clean
 it up, i'd certainly appreciate the effort.

I've used Module::Pluggable, and liked it.

Nicholas Clark


Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-25 Thread Jonathan Worthington

chromatic [EMAIL PROTECTED] wrote:

On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote:


Minor nit: when running Configure.pl with --nomanicheck, Configure
should report the MANIFEST check as skipped, not done.


particle beat me to this one, but *wow* the plugin system for
configuration is grotty.  Does anyone have a particular attachment to
it?  Would it be useful to clean it up a little bit, or does it need
patching or updating very often?

If people have free time to spend on configure stuff, might it not be better 
spent working on the real configure system that we want to have (e.g. a set 
of makefiles for each platform to build miniparrot, then configure is a 
Parrot program run by miniparrot that figures stuff out that we need to 
build the full Parrot)?


Just a thought,

Jonathan 



Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-25 Thread Leopold Toetsch


On Oct 26, 2005, at 0:49, Jonathan Worthington wrote:

If people have free time to spend on configure stuff, might it not be 
better spent working on the real configure system that we want to have 
(e.g. a set of makefiles for each platform to build miniparrot, then 
configure is a Parrot program run by miniparrot that figures stuff out 
that we need to build the full Parrot)?


Exactly. The more that a lot of stuff [1] currently handled by 
Configure could be done either by the Makefile or just much later for 
languages/*.


Cleanup is very much welcome, as well as to revive miniparrot (the real 
one).


[1] creation of various runtime/parrot/include/*.pasm comes to my mind


Just a thought,

Jonathan


leo



Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-25 Thread Joshua Hoblitt
On Tue, Oct 25, 2005 at 10:19:50PM +0100, Nicholas Clark wrote:
 On Tue, Oct 25, 2005 at 01:16:27PM -0700, jerry gay wrote:
 
  i've started developing a plugin architecture for $work, so i've been
  thinking about plugin engines lately. if you're up for working on a
  redesign, i'll gladly pitch in. even if you're looking only to clean
  it up, i'd certainly appreciate the effort.

It's outright nasty.

 I've used Module::Pluggable, and liked it.

Anything would be an improvement. ;)

-J

--


pgpaO2zCBnEtk.pgp
Description: PGP signature


Re: Configure System (was Re: [TODO] --nomanicheck fibs)

2005-10-25 Thread Joshua Hoblitt
On Tue, Oct 25, 2005 at 11:49:33PM +0100, Jonathan Worthington wrote:
 If people have free time to spend on configure stuff, might it not be 
 better spent working on the real configure system that we want to have 
 (e.g. a set of makefiles for each platform to build miniparrot, then 
 configure is a Parrot program run by miniparrot that figures stuff out that 
 we need to build the full Parrot)?

Perhaps this is just me being navie but I had imagined that some form of
the existing Configure system would live on as PIR/PBC that included
with the distribution to executed by miniparrot.  Someday we will be be
able to compile perl5 to PIR, right?  Or even p5 - p6 - PIR.  ;)

Cheers,

-J

--


pgpeuheb3iclS.pgp
Description: PGP signature


Re: [perl #34020] [PATCH] Some tweaks to Makefiles and Configure system

2005-02-02 Thread Leopold Toetsch
Bernhard Schmalhofer (via RT) wrote:
I tried to do some cleanup of some makefiles. A patch is attached.
The files config/gen/makefiles/imcc.in and config/gen/makefiles/classes.in
can be removed from CVS.
Thanks, applied.
leo


New Configure system

2002-05-24 Thread David M. Lloyd

May I be the first to say that the new Configure system *rocks*?

No more digging through the source code to find that config option...

- D

[EMAIL PROTECTED]




Re: New Configure system

2002-05-24 Thread Dan Sugalski

At 11:53 AM -0500 5/24/02, David M. Lloyd wrote:
May I be the first to say that the new Configure system *rocks*?

I'll second that. Nice job, Brent.
-- 
 Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk



Re: on the long term Configure system

2001-09-12 Thread Simon Cozens

On Tue, Sep 11, 2001 at 04:19:12PM +0300, Jarkko Hietaniemi wrote:
 P.S.  Maybe the long term discussion should take place in
 perl6-build, to draw fire from the short term?

Thanks for thinking about this; it'd probably be a good idea to
move to perl6-build. 

Simon



Configure system

2001-09-11 Thread 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.

We have long-term and short-term goals for Parrot's configure
system.

The long-term goal is not something I want people to worry about
right now, but it would be good if people could start thinking about
it. Eventually, we want Parrot's configure to work a little like
the proposed microperl configure system.

That's to say, we build a tiny tiny version of Parrot with default
values for various config assumptions; we can ship config.h files
that work on standard Unix platforms, Win32, and so on. Then that
microparrot runs various precompiled bytecode programs which probe
the system finding out more information about the enivronment, and
produce a config file which is used to build Parrot proper.

But we can't do that right now because we don't have a very easy
way of generating those precompiled bytecode programs. So relax.

The short-term goal is really really simple and really really neat.

You'll notice that the Parrot build process currently depends on the
existence of Perl 5 to build certain header files and preprocess the
opcode table. So if we know we've got Perl 5 hanging around, we know
we've already got a config file which tells us things like how big IVs
are, what header files we have around, and so on. Furthermore, we
can write a Perl program which uses Config.pm to give us this
information in a hash, and hence we can use that to produce a config.h 
specific to a given machine.

So I'd like to see a patch which consists of a program to
automatically generate Parrot's config.h from Perl's Config.pm. You
could be really clever, and also have it conditionally include some
of the header files mentioned in parrot.h depending on whether the
i_... values in Config.pm say we have them. (You may need to move the
#includes of the system header files from parrot.h to config.h)
No prizes will be awarded for using Perl's config.h, or C preprocessor
abuse. :)

Furthermore, I'd like to see a Portability Pumpkin step forward to
warn us when we're doing things that don't go down too well on Cray
Unicos or QNX 6.

Simon



RE: Configure system

2001-09-11 Thread Brent Dax

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 certain header files and preprocess the
# opcode table. So if we know we've got Perl 5 hanging around, we know
# we've already got a config file which tells us things like how big IVs
# are, what header files we have around, and so on. Furthermore, we
# can write a Perl program which uses Config.pm to give us this
# information in a hash, and hence we can use that to produce a
# config.h
# specific to a given machine.
#
# So I'd like to see a patch which consists of a program to
# automatically generate Parrot's config.h from Perl's Config.pm. You
# could be really clever, and also have it conditionally include some
# of the header files mentioned in parrot.h depending on whether the
# i_... values in Config.pm say we have them. (You may need to move the
# #includes of the system header files from parrot.h to config.h)
# No prizes will be awarded for using Perl's config.h, or C preprocessor
# abuse. :)

I'm starting to do some hacking on this.  (Hey, I can't sleep... :^) )
Since Perl 5 already has this stuff, it seems like it should be pretty
easy.  (Famous last words?)  The $64,000 question is, what do I have to
copy over?  A simple autogenerate what's already in Parrot's config.h
is easy--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 does it need to do?

The prototype below properly defines IV and NV (most of the time) based
on Perl 5's IV and NV.  It also sets up HAS_HEADER_FOO for each of the
i_ symbols in Config.pm.  Let me know if I should change the symbol I
define.  (If the comment line with my name in it seems improper, feel
free to remove it.)

I'm on Win32, so I don't have the tools to make a diff (I'm trying to
get PPT working) so you'll have to turn it into a patch yourself.
Sorry.

--Brent Dax
[EMAIL PROTECTED]

...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet.

~~~

#!/usr/bin/perl -w
#we want -w on

#Configure.pl, written by Brent Dax

use strict;
use Config;

print END;
Parrot Configure
Copyright (C) 2001 Yet Another Society

Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.

Rules are the same as Perl 5's Configure--defaults are in
square brackets, and you can hit enter to accept them.
END

#Some versions don't seem to have ivtype or nvtype--provide
#defaults for them.
#XXX Figure out better defaults
my($iv, $nv)=(($Config{ivtype}||'long'), ($Config{nvtype}||'long
double'));
my $input;

print How big would you like integers to be? [$iv] ;
chomp($input=STDIN);
$iv=$input||$iv;

print How about your floats? [$nv] ;
chomp($input=STDIN);
$nv=$input||$nv;

my($config_h)=END_OF_CONFIG_H;
/* config.h
 *
 * Platform-specific config file
 *
 * DO NOT EDIT THIS FILE!
 * This file was autogenerated by Configure.pl--please
 * rerun that!  Changes to this file may be lost!
 *
 */

#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef $iv IV
typedef $nv NV;

typedef struct _vtable VTABLE;
typedef void DPOINTER;
typedef void SYNC;

//typedef IV *(*opcode_funcs)(void *, void *) OPFUNC;

#define FRAMES_PER_CHUNK 16

#define FRAMES_PER_PMC_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_NUM_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_INT_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_STR_REG_CHUNK FRAMES_PER_CHUNK

#define MASK_CHUNK_LOW_BITS 0xf000

END_OF_CONFIG_H


print END;
Okay.  Now I'm gonna probe Perl 5's configuration to see
what headers you have around.  This could take a bit on slow
machines...
END


#set up HAS_HEADER_
foreach(grep {/^i_/} keys %Config) {
$config_h.=defineifdef((/^i_(.*)$/));
}


$config_h.=\n#endif;

open(CONFIG_H, config.h);

print CONFIG_H $config_h;


print END;

Okay, we're done!
You can now use `make test_prog' (or your platform's equivalent to
`make')
to build your Parrot.  Happy Hacking,
The Parrot Team
END


sub defineifdef {
my $thing=shift;

if($Config{i_$thing}) {
return #define HAS_HEADER_\U$thing\E\n;
}
else {
return #undef HAS_HEADER_\U$thing\E\n; #XXX do we want this?
}
}




RE: Configure system

2001-09-11 Thread Brent Dax

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 talking
# about.  What
#  else does it need to do?
#
# I'd rather it took a config.h.in or similar and slapped the IV/NV/etc.
# typedefs in the middle. This means we can hack the template each time
# we need it to change, instead of hacking the Perl script that
# generates
# config.h.

Good idea.  Why didn't I think of it?  :^)

# Thanks for working on this.

No problem--I'm just helping the best way I can at this point.

Attached are new Configure.pl and config.ht files.  Feel free to rename
config.ht if you want.  (They may have Windows newlines, unless e-mail
clients do some translating of those behind the scenes that I don't know
about.)

--Brent Dax
[EMAIL PROTECTED]

...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet.

 Configure.pl
 config.ht