On Fri, Sep 06, 2002 at 08:09:21PM -0700, Sean O'Rourke wrote:
> On Fri, 6 Sep 2002, Steve Fink wrote:
> > > > - Make sure P6C::IMCC::code() adds a newline after every line
> > > > (I was getting two consecutive lines of code smashed together)
> > >
> > > This will probably make the output pretty ugly. I'd rather find the
> > > culprit for the smashed-together lines, or only add a newline if there
> > > isn't one already.
> >
> > The behavior before this patch seems inconsistent. It unconditionally
> > appends a newline to the end of every line in the passed-in array
> > except for the last one.
>
> You're right -- it's sort of trying to do two things -- append an array of
> line (adding newlines), and append a chunk of code as-is. Unfortunately,
> it doesn't work for the former, and since I typically haven't used it that
> way, I've never noticed the lack. Typical usage is
>
> code(<<END);
> lines of pasm
> go here
> END
>
> so adding newlines is not useful in the common case.
Ah, I see. Right now, I'm letting languages/regex just spew out its
usual enormous array of PASM lines, and I was passing that straight to
code().
> > I'm very impressed by P6C. This is the first time I've looked at it
> > seriously (I'm trying to do the languages/regex integration),
>
> Glad you like it, though now that you're doing regexes, I'll have to stop
> playing around with them, I guess :(.
I'd rather you kept going, actually. I don't think this integration is
really going to bear fruit for quite a while, especially since I'm
starting work next Monday. And I've been spending more time twisting
around IMCC than actually working on the integration. And you're way
ahead of me in terms of integrating with Perl6. I just have the basic
regexps, with optimizations; you have at least the start of array
matching, hypotheticals, the various cuts, etc. (And I think there's a
pretty good chance I'll be able to use a lot of your stuff without
change for most of that.)
> Do you have any plans to port languages/regex to the Rx ops and/or
> port them to it?
I don't really believe in the rx ops anymore, so no. I was thinking I
might do something like what Angel did once things are really working
-- see what op combinations are frequent enough that combining them
together will get a significant speed boost. But for the most part,
I'm trying very hard to use vanilla PASM ops. Hopefully the JIT will
reward me.
> As for the eval/autoload bit -- what particular parts are a problem?
Let me go back and try it again... ok, when I trace into
P6C::Binop::val(), $ops{$op}->($x) goes straight to eval"" land. Same
for P6C::guard::val()'s $guards{$x->name}->($x). One of them seems to
be Class::Struct, which is probably unavoidable. The other is
SelfLoader. I don't know if it's really something that should be
changed, but it's harder to get a feel for the control flow by
stepping through in the debugger this way.
> > Bug report: perl6 -e 'print 1 if /a/' calls P6C::IMCC::rule::val(),
> > which does an rx_popindex immediately and runs out of stack.
>
> Hm... That's probably not the desired behavior, but '$_' is only
> implemented for given/when (and maybe a couple of other places), so it's
> not too surprising that badness occurs.
Yeah, I figured that. Okay, here's another one: your last commit to
IMCC.pm added a call to P6C::Parser::Reset(), which doesn't exist in
the checked-in version.
