Daniel Grunblatt wrote:
>
> Err, Jeff just told me to see the -E flag.
Which may not be well-documented. It expands the macros and constants
(and now include files) and stops at that stage, returning the
postprocessed text on STDOUT. I'll add documentation for this shortly...
--
Jeff <[EMAIL PRO
brian wheeler wrote:
>
> I've implemented a .include directive for the new assembler. It
> basically changes the preprocessor to shift through the source file, and
> when an include is found, the included file is unshifted to the
> beginning.
>
> Should I commit it?
>
> Brian
Feel free, as lo
Jeff wrote:
>
> For your edification/amusement/nightmares...
>
> A FORTH interpreter.
>
> Doesn't do much, but it -will- compile words. It accepts the following
> input:
>
> > 3 : square ( n -- n ) dup * ; : cube ( n -- n )
> square> dup square * ;
> cube> .
> 27>
>
> I'll be adding new words
Err, Jeff just told me to see the -E flag.
Daniel Grunblatt.
On Sat, 22 Jun 2002, Daniel Grunblatt wrote:
> It would be cute if you change the debugger to load all the included files
> as well.
>
> Daniel Grunblatt.
>
>
> On 21 Jun 2002, brian wheeler wrote:
>
> > I've implemented a .include d
It would be cute if you change the debugger to load all the included files
as well.
Daniel Grunblatt.
On 21 Jun 2002, brian wheeler wrote:
> I've implemented a .include directive for the new assembler. It
> basically changes the preprocessor to shift through the source file, and
> when an inc
I've implemented a .include directive for the new assembler. It
basically changes the preprocessor to shift through the source file, and
when an include is found, the included file is unshifted to the
beginning.
Should I commit it?
Brian
--- assemble.pl 17 Jun 2002 03:18:17 - 1.74
++
For your edification/amusement/nightmares...
A FORTH interpreter.
Doesn't do much, but it -will- compile words. It accepts the following
input:
> 3 : square ( n -- n ) dup * ; : cube ( n -- n )
square> dup square * ;
cube> .
27>
I'll be adding new words as the fancy strikes me. As you can see
On Fri, Jun 21, 2002 at 06:22:40PM -0400, Melvin Smith wrote:
> At 10:22 PM 6/21/2002 +0200, Jerome Vouillon wrote:
> >Ok. Then, you should do the converse to what you are mentionning in
> >your patch: instead of inlining a context in the interpreter structure
> >(Parrot_Interp), you should add a
At 10:22 PM 6/21/2002 +0200, Jerome Vouillon wrote:
>On Fri, Jun 21, 2002 at 02:33:33PM -0400, Melvin Smith wrote:
> > Now, if you look at it and say we can do a "lightweight"
> > interpreter, I think that is what I'm trying to accomplish, but I'm
> > calling it Parrot_Context.
>
>Ok. Then, you s
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #723]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=723 >
We've currently got torture tests for the I, S and P stacks, but not for
the N sta
On Fri, Jun 21, 2002 at 02:33:33PM -0400, Melvin Smith wrote:
> Now, if you look at it and say we can do a "lightweight"
> interpreter, I think that is what I'm trying to accomplish, but I'm
> calling it Parrot_Context.
Ok. Then, you should do the converse to what you are mentionning in
your pat
At 07:57 PM 6/21/2002 +0200, Jerome Vouillon wrote:
>On Fri, Jun 21, 2002 at 12:49:27PM -0400, Melvin Smith wrote:
> > >- Each co-routine should probably have its own interpreter.
> >
> > I'm not sure about this one. I think we can accomplish it without
> > the full overhead of a new interpreter.
On Fri, Jun 21, 2002 at 12:49:27PM -0400, Melvin Smith wrote:
> >- Each co-routine should probably have its own interpreter.
>
> I'm not sure about this one. I think we can accomplish it without
> the full overhead of a new interpreter.
I don't understand. It should not be much more expansive t
Well, there's now a _keyed_int form for every _keyed vtable method.
PDD02 has a summary of how these new methods work.
Also, I've added push/pop/shift/unshift vtable methods. There are no ops
that use these yet.
So if anyone wants to a make a (first?) contribution, the following needs
to be do
At 06:34 PM 6/21/2002 +0200, Jerome Vouillon wrote:
>On Thu, Jun 20, 2002 at 12:26:11AM -0400, Melvin Smith wrote:
> > Given that it seems capturing and restoring a context is the most
> > expensive part, should we make default routines lightweight (execute
> > on caller stack rather than getting
On Fri, 21 Jun 2002, Jerome Vouillon wrote:
> On Thu, Jun 20, 2002 at 12:26:11AM -0400, Melvin Smith wrote:
> > Given that it seems capturing and restoring a context is the most
> > expensive part, should we make default routines lightweight (execute
> > on caller stack rather than getting their
On Thu, Jun 20, 2002 at 12:26:11AM -0400, Melvin Smith wrote:
> Given that it seems capturing and restoring a context is the most
> expensive part, should we make default routines lightweight (execute
> on caller stack rather than getting their own) and only make
> continuations and co-routines ta
On Thu, 20 Jun 2002 11:11:39 -0600 (MDT), Luke Palmer wrote:
> > If the hyperness of a vmethod depends on the type of PMC it belongs to, we
> > need to force every operand to a specific type (scalar or list/array), even
> > if it looks like it's already the right type:
> >
> > $r = \@a; # Or i
http://www.perl.org/perl6 is a bit behind. Anyone care to update and include
apo-5? And Damian's tour info.
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 632 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11. Smoki
19 matches
Mail list logo
