FAQ

Topaz 0.11 is out .. and in CVS (Finally!)

Chip Salzenberg
Apr 29, 2000 at 7:04 am
Bowing to popular demand. The release notes are below. For
instructions on using SourceForge's CVS servers for Topaz, see:

<URL:https://sourceforge.net/cvs/?group_id=1020>

Share & Enjoy!

PS: We could use a little more sophisticated Makefile system....

--------------------------------------------------------------------------

Changes in topaz 0.11:

* Organize code into subdirectories:
mem Memory management etc.
val Value and derivations
op Opcodes etc.
int Interpreter etc.
tools scripts

* Rename all FooPtr -> Foo_p, ConstFooPtr -> const_Foo_p.
* Create Counted_p_ref<> by analogy with auto_ptr_ref<>, designed
for return-by-value. Its contained pointer is always stolen.
The intent is to reduce ref thrashing.
* Likewise Buffer_ref vs. Buffer.

* New stuff in mem:
HashMisc: misc support for hash functions
HashTable: low-level hash table support
HashSet: generic container based on HashTable<>

* Defined/undefined isn't really a universal concept, so it's no
longer part of the Value interface.

* Rationalize array/hash interface. All methods must be specific
to arrays or hashes; otherwise, we can't tell if a reference is
of appropriate type or not.
* Hashes no longer contain default iterators. This change will
will require a bit of language support, but Larry sez it'll
probably work, and that's good enough for me.

* FatHash is now implemented with our own HashSet<> template
instead of the more general (and higher-overhead) map<>.

* New class: Stash, a specialized container of Globs that acts
like a Hash when it has to. (Also: GlobProxyScalar.)

* Interpreter's methods are now mostly friends, for convenience.

* Code class is now general for all functions, user-defined or
not. (Otherwise, you can't redefine a user sub with an XSUB or
vice versa.) All user-sub-specific intelligence is in
UserCodeBody, derived from the new abstract base Code::Body.

--------------------------------------------------------------------------

--
Chip Salzenberg - a.k.a. - <chip@valinux.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
reply

Search Discussions

26 responses

  • Benjamin Holzman at Apr 30, 2000 at 1:03 am ⇧
    $ uname -a
    Linux mercurium 2.2.12 #1 Thu Dec 9 00:57:08 EST 1999 i686 unknown
    $ /usr/bin/g++ -v
    Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
    gcc version 2.95.2 20000313 (Debian GNU/Linux)
    $ make
    make[1]: Entering directory `/home/bah/topaz/mem'
    /usr/bin/g++ -g -pipe -frtti -I/usr/include/g++-v3 -I.. -I../mem -I../val -I../op -I../int -fnew-exceptions -c Memory.cc
    /usr/bin/g++ -g -pipe -frtti -I/usr/include/g++-v3 -I.. -I../mem -I../val -I../op -I../int -fnew-exceptions -c Buffer.cc
    In file included from Buffer.cc:1:
    ../mem/Buffer.hh: In function `static class Perl::Buffer::Guts * Perl::Buffer::Guts::PtrPolicy<Perl::Buffer::Guts>::init()':
    ../mem/Counted.hh:119: instantiated from `Perl::Counted_p<Perl::Buffer::Guts,Perl::Buffer::Guts::PtrPolicy<Perl::Buffer::Guts> >::Counted_p()'
    ../mem/Buffer.hh:39: instantiated from here
    ../mem/Buffer.hh:142: Internal compiler error.
    ../mem/Buffer.hh:142: Please submit a full bug report.
    ../mem/Buffer.hh:142: See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
    cpp: output pipe has been closed
    make[1]: *** [Buffer.o] Error 1
    make[1]: Leaving directory `/home/bah/topaz/mem'
    make: *** [all] Error 2
  • Chip Salzenberg at Apr 30, 2000 at 1:26 am ⇧

    According to Benjamin Holzman:
    $ /usr/bin/g++ -v
    Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
    gcc version 2.95.2 20000313 (Debian GNU/Linux) [...]
    ../mem/Buffer.hh:142: Internal compiler error.
    *sigh* I think I might as well require g++ 2.96. While g++ 2.95 is
    pretty good, recent patching is so fast&furious that it's way behind
    the bug curve.

    I maintain an x86-linux build of a recent snapshot at:
    ftp://topaz.sourceforge.net/pub/topaz/

    Currently there is this version:
    egcs-20000307-i686-linux.tar.bz2

    But I'll upload a new one later today.
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • Chip Salzenberg at Apr 30, 2000 at 3:18 am ⇧
    I keep x86-linux builds of recent gcc snapshots at:
    ftp://topaz.sourceforge.net/pub/topaz/

    Now, as promised, fresh from the CVS archive to your hard disk:
    egcs-20000429-i686-linux.tar.bz2

    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • Benjamin Holzman at May 1, 2000 at 1:45 am ⇧

    On Sat, Apr 29, 2000 at 08:17:58PM -0700, Chip Salzenberg wrote:
    I keep x86-linux builds of recent gcc snapshots at:
    ftp://topaz.sourceforge.net/pub/topaz/

    Now, as promised, fresh from the CVS archive to your hard disk:
    egcs-20000429-i686-linux.tar.bz2
    Cool. Thanks. With this I got a lot further; here's where it stopped:

    /usr/local/egcs/bin/g++ -L/usr/local/egcs/lib -Wl,-rpath,/usr/local/egcs/lib -o test_buffer test_buffer.o libperl.a misc.o
    test_buffer.o: In function `Perl::Counted::~Counted(void)':
    /home/bah/topaz/mem/Buffer.hh(.gnu.linkonce.t.__ls__4PerlRQ23stdt13basic_ostream2ZcZQ23stdt11char_traits1ZcRCQ24Perl6Buffer+0x37): undefined reference to `Perl::operator<<(std::basic_ostream<char, std::char_traits<char> > &, Perl::Const_Memory)'
    collect2: ld returned 1 exit status
    make: *** [test_buffer] Error 1
  • Chip Salzenberg at May 1, 2000 at 2:13 am ⇧

    According to Benjamin Holzman:
    /usr/local/egcs/bin/g++ -L/usr/local/egcs/lib -Wl,-rpath,/usr/local/egcs/lib -o test_buffer test_buffer.o libperl.a misc.o
    test_buffer.o: In function `Perl::Counted::~Counted(void)':
    /home/bah/topaz/mem/Buffer.hh(.gnu.linkonce.t.__ls__4PerlRQ23stdt13basic_ostream2ZcZQ23stdt11char_traits1ZcRCQ24Perl6Buffer+0x37): undefined reference to `Perl::operator<<(std::basic_ostream<char, std::char_traits<char> > &, Perl::Const_Memory)'
    Hm. Could you please send a copy of your rules.mk and the output of a
    "make" after "make realclean"?
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • Benjamin Holzman at May 1, 2000 at 2:24 am ⇧

    On Sun, Apr 30, 2000 at 07:13:11PM -0700, Chip Salzenberg wrote:

    Hm. Could you please send a copy of your rules.mk and the output of a
    "make" after "make realclean"?
    Mea culpa. The post-realclean make worked fine. Neeeeevermind...

    :-)
  • Chip Salzenberg at May 1, 2000 at 3:05 am ⇧

    According to Benjamin Holzman:
    Mea culpa. The post-realclean make worked fine. Neeeeevermind...
    No prob. It looked kind of like that sort of thing.
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • John Tobey at Apr 30, 2000 at 5:08 am ⇧

    Date: Sat, 29 Apr 2000 00:04:55 -0700
    From: Chip Salzenberg <chip@valinux.com>

    Bowing to popular demand. The release notes are below. For
    instructions on using SourceForge's CVS servers for Topaz, see:

    <URL:https://sourceforge.net/cvs/?group_id=1020>

    Share & Enjoy!
    Excellent! Thanks. I think that I will learn more about Perl 5 from
    reading Topaz's header files than I did from reading Perl 5's header
    files.
    PS: We could use a little more sophisticated Makefile system....
    OK, well how about some design specs first. Is there anything
    salvageable in Configure and hints/? Is one to assume Unixy sh or
    microperl? Automake/Autoconf can do a lot for us, but maybe not
    enough (does it have standard tests for C++ features?). Would you
    agree that build dir != src dir capability is a requirement? How
    about cross-compilation?
    * Rationalize array/hash interface. All methods must be specific
    to arrays or hashes; otherwise, we can't tell if a reference is
    of appropriate type or not.
    Good. Why not use a consistent naming convention; for example:

    // Array-specific:
    - void clear_array() { set_array_size(0); }
    - virtual void set_array_size(size_t n) { array_only(); }
    + void array_clear() { array_set_size(0); }
    + virtual void array_set_size(size_t n) { array_only(); }
    virtual void array_assign_simple(size_t n, Scalar_p *vec);

    // Hash-specific:
    - virtual void clear_hash();
    - virtual void set_hash_capacity(size_t n);
    + virtual void hash_clear();
    + virtual void hash_set_capacity(size_t n);
    virtual void hash_assign_simple(size_t n, Scalar_p *vec);


    -John

    --
    John Tobey, late nite hacker <jtobey@john-edwin-tobey.org>
    \\\ ///
    ]]] With enough bugs, all eyes are shallow. [[[
    /// \\\
  • Chip Salzenberg at Apr 30, 2000 at 5:18 am ⇧

    According to John Tobey:
    Chip:
    PS: We could use a little more sophisticated Makefile system....
    OK, well how about some design specs first.
    Now that you mention it, we do need to start on a Perl-based Configure
    replacement. Just don't do anything that microperl couldn't do, and
    you can develop it with Perl 5. A good start would be to translate
    some basic functions from the current Metaconfig package and see how
    they turn out. The door is completely open to new ideas in the
    representation of configurations (i.e. config.sh can die!).

    (But all I was looking for was something a little better than what I
    have now.... Only descend into subdirs if required, don't constantly
    rebuild the libperl.a if not required, maybe a makedepend.)

    And now for something completely different: I've asked Adam Turoff to
    look at Cons, getting entirely away from the whole 'makefile' thing.
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • Jarkko Hietaniemi at Apr 30, 2000 at 5:55 am ⇧
    Being somewhat experienced in the current battlefields of Configure
    and Makefiles (and all the different makes, let's not forget that)
    I'll cast my vote for Cons, too.

    Let's be as deeply committed to Perl as we possibly can, that way we
    can make our own rules, instead of having to bend over backwards,
    while juggling a chainsaw, an electric eel, and a blowtorch. My
    advice is also not even to spit at the general direction of GNU
    configure/automake, it's just another morass, and theyt similarly (to
    Configure) assume very UNIXish shell environment. The more
    independent (os-agnostic) we are, the better.

    And yes, I would make building out of the source directory a
    requirement. That will also give us some ammunition for doing
    cross-compilation.

    --
    $jhi++; # http://www.iki.fi/jhi/
    # There is this special biologist word we use for 'stable'.
    # It is 'dead'. -- Jack Cohen
  • Chip Salzenberg at Apr 30, 2000 at 6:04 am ⇧

    According to Jarkko Hietaniemi:
    I'll cast my vote for Cons, too.
    And some voters are more equal than others.
    Let's be as deeply committed to Perl as we possibly can, that way we
    can make our own rules, instead of having to bend over backwards,
    while juggling a chainsaw, an electric eel, and a blowtorch.
    "Chainsaw? Luxury! When I started, I had to write configuration
    programs for CP/M in PL/I-80!"

    I think we'll still want to keep a minimal makefile around for the
    very very first steps required to build microperl. Then we're off!
    ... not even to spit at the general direction of GNU
    configure/automake [...]
    I shall waste none of my precious bodily fluids in so foolish an
    endeavor. The GNU build tools are, by and large, awful. GNU make
    is pretty good, but the rest are recycling fodder.
    And yes, I would make building out of the source directory a
    requirement.
    You mean, 'building outside of the source dir'? If so, three cheers.
    I'm in the habit of keeping sources in /u/src/foo/bar and building in
    /u/build/foo/bar with symlink /u/build/foo/bar/SRC -> /u/src/foo/bar.
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • John Tobey at Apr 30, 2000 at 6:13 am ⇧

    Chip Salzenberg wrote:
    According to Jarkko Hietaniemi:
    ... not even to spit at the general direction of GNU
    configure/automake [...]
    I shall waste none of my precious bodily fluids in so foolish an
    endeavor. The GNU build tools are, by and large, awful. GNU make
    is pretty good, but the rest are recycling fodder.
    Acknowledged. (Even GNU make suffers from being make.) I only hope
    we're not all saying the same thing about Cons 5 years hence. :)

    --
    John Tobey, late nite hacker <jtobey@john-edwin-tobey.org>
    \\\ ///
    ]]] With enough bugs, all eyes are shallow. [[[
    /// \\\
  • Chip Salzenberg at Apr 30, 2000 at 6:19 am ⇧

    According to John Tobey:
    I only hope we're not all saying the same thing about Cons 5 years
    hence. :)
    Oh, we probably won't be. What makes GNU Make such an improvement on
    its predecessors is its more expressive macro language. But with Cons,
    the macro language is ... Perl! <evil laughter>
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • Damien Neil at Apr 30, 2000 at 8:02 am ⇧

    On Sat, Apr 29, 2000 at 11:04:19PM -0700, Chip Salzenberg wrote:
    You mean, 'building outside of the source dir'? If so, three cheers.
    I'm in the habit of keeping sources in /u/src/foo/bar and building in
    /u/build/foo/bar with symlink /u/build/foo/bar/SRC -> /u/src/foo/bar.
    Speaking up as a satisfied cons user, I maintain the build environment
    for a moderately complex project at work. I made the decision to use
    cons rather than make, and haven't regretted it yet.

    Cons has problems. (Fortunately, one of the larger ones -- the fact that
    it's pretty hard to use if you don't know Perl -- isn't going to apply
    here.) It is, however, vastly better than make at managing complex
    build trees. It has superb dependancy tracking, and it handles building
    outside the source dir very well indeed. (Personally, I keep my objects
    in /tmp, since my home directory is on a very slow NFS server.)

    The only reason that I hesitated to recommend it here before is that
    the concept of using a build tool written in Perl seemed to pose certain
    chicken-and-egg problems. :> I'm not certain how much work it will take
    to make cons work with miniperl. You'll need to address the way it does
    dependancies, at the least -- cons requires the Digest::MD5 module. (A
    source of constant annoyance to me; I dearly wish this module was
    standard.)

    - Damien
  • Jarkko Hietaniemi at Apr 30, 2000 at 7:57 pm ⇧

    I think we'll still want to keep a minimal makefile around for the
    very very first steps required to build microperl. Then we're off!
    Yeah, something of the below complexity, and nothing much more.
    (No guarantees on the syntax, I'm making this up as I write :-)

    O = .o
    C = .c
    SRC = a$(C) b$(C) c$(C) d$(C)
    OBJ = $(SRC:$(C)=$(O))

    a$(O): a$(C) a.h
    b$(O): b$(C) b.h a.h
    c$(O): c$(C) c.h x.h
    d$(O): d$(C) d.h a.h x.h
    main$(O): main$(C)

    microperl: $(OBJ) main$(O)
    $(CC) -o $@ main$(O) $(OBJ)

    And, of course, even the above is unportable: -o. We still need Win*
    and VMS makefiles to cater their compilers' syntaxes, at least -- unless
    we still are assuming gcc.
    ... not even to spit at the general direction of GNU
    configure/automake [...]
    I shall waste none of my precious bodily fluids in so foolish an
    endeavor. The GNU build tools are, by and large, awful. GNU make
    is pretty good, but the rest are recycling fodder.
    *clap*clap*
    And yes, I would make building out of the source directory a
    requirement.
    You mean, 'building outside of the source dir'? If so, three cheers.
    Yes.

    --
    $jhi++; # http://www.iki.fi/jhi/
    # There is this special biologist word we use for 'stable'.
    # It is 'dead'. -- Jack Cohen
  • Jarkko Hietaniemi at May 1, 2000 at 4:04 am ⇧

    And yes, I would make building out of the source directory a
    requirement.
    You mean, 'building outside of the source dir'? If so, three cheers.
    Stephen Zander has been working towards an "out-source-experience" for perl5.
    Configure is supposedly already fine for this, it's the Makefiles,
    the numerous shellscripts, and MakeMaker who oppose building outside
    of the source directory such an adventure. Stephen even did have
    a rather promising patch few weeks before 5.6.0, but unfortunately
    it wasn't as portable as we hoped because there are so many different
    flavors of make out there. So it didn't go in.

    --
    $jhi++; # http://www.iki.fi/jhi/
    # There is this special biologist word we use for 'stable'.
    # It is 'dead'. -- Jack Cohen
  • Stephen Zander at May 1, 2000 at 8:36 am ⇧
    "Jarkko" == Jarkko Hietaniemi writes:
    Jarkko> So it didn't go in.

    And I haven't gone back to it since. Thanks for the reminder, Jarkko.

    --
    Stephen

    "And what do we burn apart from witches?"... "More witches!"
  • Ken Fox at May 6, 2000 at 1:20 am ⇧

    Chip Salzenberg writes:
    You mean, 'building outside of the source dir'? If so, three cheers.
    I'm in the habit of keeping sources in /u/src/foo/bar and building in
    /u/build/foo/bar with symlink /u/build/foo/bar/SRC -> /u/src/foo/bar.
    I've found that lndir (from the X11 distribution) works very well. When
    I build something, I unpack the original sources into "foo-X.Y" and then
    make a directory "OS-foo-X.Y" (where OS is SunOS, IRIX, etc.). Remove
    write permission on foo-X.Y, run "lndir ../foo-X.Y" and builds can
    happen in OS-foo-X.Y without any chance of screwing up the originals.
    The nice part of this approach is that it doesn't require any support
    from the build tools at all.

    - Ken

    --
    Ken Fox, kfox@ford.com, (313)59-44794
    ------------------------------------------------------------------------
    Ford Motor Company, Powertrain | "Is this some sort of trick
    Analytical Powertrain Methods Department | question or what?" -- Calvin
    C3P Implementation Section |
  • Bennett Todd at May 1, 2000 at 4:32 pm ⇧

    2000-04-30-01:18:25 Chip Salzenberg:
    And now for something completely different: I've asked Adam Turoff
    to look at Cons, getting entirely away from the whole 'makefile'
    thing.
    Is Cons alive?

    I didn't find anything on freshmeat or search.cpan.org, and when
    I went to the referenced debian site, I found a ".orig" tarball
    (sometimes I'm _REALLY_ glad I don't have anything to do with
    Debian), with file timestamps in November of 1996, with a perl
    script completely undocumented except for a usage message (no pod,
    even) and a postscript file created with Framemaker. The CHANGES
    file documents work from August 24, 1996 through November 12,
    1996. None of this inspires confidence.

    I'll try and give that doc a read, but this really looks like one of
    the projects that didn't survive its initial moments.

    -Bennett
  • Mark Hollomon at May 1, 2000 at 5:00 pm ⇧

    Bennett Todd wrote:

    2000-04-30-01:18:25 Chip Salzenberg:
    And now for something completely different: I've asked Adam Turoff
    to look at Cons, getting entirely away from the whole 'makefile'
    thing.
    Is Cons alive?
    try http://www.dsmit.com/cons/

    --

    Mark Hollomon
    mhh@nortelnetworks.com
    ESN 451-9008 (302)454-9008
  • Joshua N Pritikin at May 1, 2000 at 5:05 pm ⇧

    On Mon, May 01, 2000 at 12:29:52PM -0400, bet@rahul.net wrote:
    2000-04-30-01:18:25 Chip Salzenberg:
    And now for something completely different: I've asked Adam Turoff
    to look at Cons, getting entirely away from the whole 'makefile'
    thing.
    Is Cons alive?

    I didn't find anything on freshmeat or search.cpan.org, and when
    I went to the referenced debian site, I found a ".orig" tarball
    (sometimes I'm _REALLY_ glad I don't have anything to do with
    Debian), with file timestamps in November of 1996, with a perl
    script completely undocumented except for a usage message (no pod,
    even) and a postscript file created with Framemaker. The CHANGES
    file documents work from August 24, 1996 through November 12,
    1996. None of this inspires confidence.

    I'll try and give that doc a read, but this really looks like one of
    the projects that didn't survive its initial moments.
    Sheesh!

    http://www.google.com/search?q=cons&meta=lr%3D%26hl%3Den

    --
    "Never ascribe to malice that which can be explained by stupidity."
    via, but not speaking for Deutsche Bank
  • Chip Salzenberg at Apr 30, 2000 at 5:20 am ⇧

    According to John Tobey:
    I think that I will learn more about Perl 5 from reading Topaz's
    header files than I did from reading Perl 5's header files.
    It could happen. C++ encourages putting a lot more info in headers.

    Re: Consistent naming:
    - void clear_array() { set_array_size(0); }
    - virtual void set_array_size(size_t n) { array_only(); }
    + void array_clear() { array_set_size(0); }
    + virtual void array_set_size(size_t n) { array_only(); }
    virtual void array_assign_simple(size_t n, Scalar_p *vec);

    // Hash-specific:
    - virtual void clear_hash();
    - virtual void set_hash_capacity(size_t n);
    + virtual void hash_clear();
    + virtual void hash_set_capacity(size_t n);
    virtual void hash_assign_simple(size_t n, Scalar_p *vec);
    I've pondered that. I'm trying to maintain some degree of 'verb_noun'
    naming when appropriate. But visual consistency may be more valuable.
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • John Tobey at Apr 30, 2000 at 5:38 am ⇧

    Chip Salzenberg wrote:
    According to John Tobey:
    // Hash-specific:
    - virtual void clear_hash();
    - virtual void set_hash_capacity(size_t n);
    + virtual void hash_clear();
    + virtual void hash_set_capacity(size_t n);
    virtual void hash_assign_simple(size_t n, Scalar_p *vec);
    I've pondered that. I'm trying to maintain some degree of 'verb_noun'
    naming when appropriate. But visual consistency may be more valuable.
    It is a philosophical question, not just linguistic or aesthetic.
    Actually, your way is probably better, assuming the methods can
    theoretically all work on any Aggr. "clear_hash" means "clear as a
    hash" and not "I'd better be a hash so clear me".

    --
    John Tobey, late nite hacker <jtobey@john-edwin-tobey.org>
    \\\ ///
    ]]] With enough bugs, all eyes are shallow. [[[
    /// \\\
  • Chip Salzenberg at Apr 30, 2000 at 5:52 am ⇧

    According to John Tobey:
    Actually, your way is probably better, assuming the methods can
    theoretically all work on any Aggr.
    They can. Consider pseudohashes, the base pointers of all evil:

    $a = [ \%FIELDS, 1, 2, 3 ];
    %$a = (); # clear_hash()
    @$a = (); # clear_array()
    "clear_hash" means "clear as a hash" and not "I'd better be a hash
    so clear me".
    You've convinced me. My way is better. :-)
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • John van V. at May 1, 2000 at 3:15 pm ⇧
    Overrides can be setup to easily override build instructions without [meaning
    with] modifying any [every] scripts.

    Hmmm, you mean like this ??:

    use Loose; # thanks to M Schwern

    $myperl = new perl6;
    $myperl -> home(thinman@puny.vm.org);
    $myperl -> OS(PerlOS);
    $myperl -> h-w(x86);
    print $myperl -> compile;
    ...
    ...
    print $myperl -> test;
    ...
    ...
    $myperl -> {targets} = \@mynodes ;
    print $myperl -> install ;
    ...
    ...
    $myperl -> realclean ;

    $ourperl = new perl6 ;
    $outperl -> {users} = CXN::PUNY -> MemberList ;
    # Enter Password:
    $ourperl -> educate ;

    Seriously, is there a tgz or rpm out there. My rpmfind keeps croaking.

    --- "A. C. Yardley" wrote:
    What and where is cons ....
    Take a look at http://www.debian.org/Packages/stable/devel/cons.html
    and http://www.debian.org/Packages/unstable/devel/cons.html


    /acy

    =====
    John van Vlaanderen

    #############################################
    # CXN, Inc. Contact: john@thinman.com # #
    # Proud Sponsor of Perl/Unix of NY #
    # http://www.thinman.com/puny #
    #############################################

    __________________________________________________
    Do You Yahoo!?
    Talk to your friends online and get email alerts with Yahoo! Messenger.
    http://im.yahoo.com/
  • John van V. at May 1, 2000 at 5:56 pm ⇧
    I like it.

    Its 4K+ lines are clearly enough written to break them up into a number of
    smaller modules specific to their packages and methods. This would allow hooks
    for upstream applications to implement aspects of the module.

    A lot of the methods only use packages as a place to keep them, they are
    independant of the class structures. These could go into a utility modules
    like the ones I am creating from the perl power tools for NT.

    Documentation at the end implies that its success depends on the evolution of
    modules in the rest of perl. Nice !!!



    =====
    John van Vlaanderen

    #############################################
    # CXN, Inc. Contact: john@thinman.com # #
    # Proud Sponsor of Perl/Unix of NY #
    # http://www.thinman.com/puny #
    #############################################

    __________________________________________________
    Do You Yahoo!?
    Send instant messages & get email alerts with Yahoo! Messenger.
    http://im.yahoo.com/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-porters @
Notice: Undefined variable: pl_domain_short in /home/whirl/sites/grokbase/root/www/public_html__www/cc/flow/tpc.php on line 1543
categoriesperl
postedApr 29, '00 at 7:04a
activeMay 6, '00 at 1:20a
posts27
users11
websiteperl6.org

11 users in discussion

Chip Salzenberg: 10 posts John Tobey: 3 posts Benjamin Holzman: 3 posts Jarkko Hietaniemi: 3 posts John van V.: 2 posts Stephen Zander: 1 post Damien Neil: 1 post Mark Hollomon: 1 post Joshua N Pritikin: 1 post Bennett Todd: 1 post Ken Fox: 1 post