Simon Cozens wrote:
> Larry has guaranteed that Perl 6 will be built "out of the same source tree"
> as Perl 5.
Whatever that means... i.e. not much.
> This is a major win for us in two areas. Firstly, we can reuse the
> information determined by Perl 5's Configure process to help make Perl 6
>
On Sat, Feb 17, 2001 at 12:22:44PM +, Nicholas Clark wrote:
> > Very, very, very rough example so you get the idea:
> [reassuring example]
Here's a slightly less rough example. Pipe the following code to
the attached Perl program, and look at the output on stdout, and in
vtable.h:
CLASS=sviv
On Fri, Feb 16, 2001 at 09:30:50PM +, Simon Cozens wrote:
> On Fri, Feb 16, 2001 at 04:00:05PM -0500, Sam Tregar wrote:
> > I think he meant that using a symbolic debugger is hard, not that it
> > wouldn't work. After all, when GDB is tell you that:
> >(*fooz).blazt[10].mark[0]->set(fungl
At 09:30 PM 2/16/2001 +, Simon Cozens wrote:
>The real benefit would be that the Perl program would know about all the
>methods and be able to automatically construct the vtable definitions and
>the relevant enum's, and that all the system-specific crap wouldn't show
>up in the generated C fi
On Fri, 16 Feb 2001, Simon Cozens wrote:
> Larry has guaranteed that Perl 6 will be built "out of the same source tree"
> as Perl 5. This is a major win for us in two areas. Firstly, we can reuse the
> information determined by Perl 5's Configure process to help make Perl 6
> portable:
> Second
On Fri, Feb 16, 2001 at 04:00:05PM -0500, Sam Tregar wrote:
> I think he meant that using a symbolic debugger is hard, not that it
> wouldn't work. After all, when GDB is tell you that:
>(*fooz).blazt[10].mark[0]->set(fungle(10));
> Is causing a seg fault and all you wrote was:
>$fooz->se
On Fri, 16 Feb 2001, Simon Cozens wrote:
> On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote:
> > macro languages and symbolic debuggers don't mix well.
>
> Generated output would be Real Life C. I'm thinking something along the lines
> of
> perl vtable.pl < vtable.spec > vtable.
On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote:
> macro languages and symbolic debuggers don't mix well.
Generated output would be Real Life C. I'm thinking something along the lines
of
perl vtable.pl < vtable.spec > vtable.c
which would work just fine with symbolic debuggers
On Fri, Feb 16, 2001 at 07:55:10PM +, Simon Cozens wrote:
> Secondly and more importantly, it guarantees that we've got a copy of Perl on
> hand before Perl 6 is built. This allows us to reduce the level of
> preprocessor muddling by effectively generating the C source to Perl 6 from
> templa
On Friday 16 February 2001 14:55, Simon Cozens wrote:
> Secondly and more importantly, it guarantees that we've got a copy of
Perl on
> hand before Perl 6 is built. This allows us to reduce the level of
> preprocessor muddling by effectively generating the C source to Perl 6
from
> templates and
Larry has guaranteed that Perl 6 will be built "out of the same source tree"
as Perl 5. This is a major win for us in two areas. Firstly, we can reuse the
information determined by Perl 5's Configure process to help make Perl 6
portable: for instance, I expect we'll still be using the [UI](8|16|32
11 matches
Mail list logo
