out that I'm hardly one to talk, but
I'm trying to make amends with the amount of POD in newasm.
I've liked what I've seen of the Doxygen system, but it isn't
appropriate for what we're doing here, especially given the fact that
embedded POD works just fine in C, and Doxygen doesn't support perl yet.
--
Jeff <[EMAIL PROTECTED]>
e. Please try to find the above
> files and then try running Configure again.
Implied patch applied, thanks.
--
Jeff <[EMAIL PROTECTED]>
Sebastian Bergmann wrote:
>
> Jeff wrote:
> > newasm has been completely rewritten. Three surprises lurk within.
>
> sb@wopr-mobile:/usr/src/parrot> newasm
> Can't locate auto/Parrot/PakFile2/autosplit.ix in @INC (@INC contains:
> ../lib/Par
> rot/blib/arc
Clinton A Pierce wrote:
>
> At 09:17 AM 5/26/2002 +0200, Sebastian Bergmann wrote:
> >Jeff wrote:
> > > newasm has been completely rewritten. Three surprises lurk within.
> >
> >sb@wopr-mobile:/usr/src/parrot> newasm
> >Can't locate auto/Parrot/Pa
There's nothing special about the new
notation.
set P0[S0], 1
would look like
set_p_s_ic
All the brackets do is act as an alternate delimiter, and is a little
bit more restrictive than 'set P0,S0,1', in that it should only allow
sc,s, and ic types inside the brackets.
--
Jeff <[EMAIL PROTECTED]>
you want, sadly.
It's passed the tests that I managed to change over to the new style.
Feel free to report bugs and make your own changes. The most clamor that
I've heard after this seems to be an all-Perl bytecode generator, so
that's what I'll work on next.
--
Jeff <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
>
> On Tue, 28 May 2002 01:19:25 -0400 Jeff <[EMAIL PROTECTED]> wrote:
>
> >newasm now handles constants, macros, and local >labels within. Here's a
>
> Great work!
Thanks.
> >expansion. Also, they don't expand >re
Brent Dax wrote:
>
> Jeff:
> # I haven't been tracking assembly speed at all. Keep in mind
> # that a perl assembler is only a temporary measure, and it'll
> # be rewritten in C eventually. It's only written in Perl so
>
> C or PASM (or Perl 6)? The latte
explain at 12:30 am, so I won't continue.
Anyway, the old local label syntax looks like:
$foo: set I0,32
branch $foo
Now, the local label syntax (only available in macros, remember) is:
..local $foo: set I0,32 # The '.local' now sets off the macro.
branch .$foo # And '.' now prefaces the macro invocation.
So, hopefully the bad news isn't too bad. Local labels are still
available where you -really- need them, and macro syntax hasn't changed
too much, but it should be easier to assemble.
--
Jeff <[EMAIL PROTECTED]>
x27;t continue.
Anyway, the old local label syntax looks like:
$foo: set I0,32
branch $foo
Now, the local label syntax (only available in macros, remember) is:
;.local $foo: set I0,32 # The '.local' now sets off the macro.
branch .$foo # And '.' now prefaces the macro invocation.
So, hopefully the bad news isn't too bad. Local labels are still
available where you -really- need them, and macro syntax hasn't changed
too much, but it should be easier to assemble.
--
Jeff <[EMAIL PROTECTED]>
o be able to yank an instruction out of the data
> >structure and run it. The other option I guess is to fix the part of
> >the assembler which scans for and removes labels, but I couldn't get
> >that to work reliably.
>
> I think your quick fix is fine; I expect w
have my local copy patched to fix this, and
I'll be committing this fix shortly, along with multiple labels assigned
to a single instruction.
--
Jeff <[EMAIL PROTECTED]>
ts will be added for these fairly soon.
--
Jeff <[EMAIL PROTECTED]>
"qq$constant") . $_;
>warn "Constant: $@ " if $@;
Testing right now, if it passes tests I'll commit it.
Many thanks.
--
Jeff <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
27;m
glad that it worked out nicely. After the final patches are in place,
we'll do a round or so of testing and get ready for release.
--
Jeff <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
Jeff wrote:
>
> Clinton A Pierce wrote:
> >
> > I'm not at a system where diff/patch runs, but here's a fix for you. In
> > _string_constant you're trying to expand \n and friends with:
> >
> > $constant = eval "qq($constant)&q
re not subscribed, look
at:
http://lists.perl.org/showlist.cgi?name=perl6-internals
for tips on how to subscribe. CVS commit access is given out to
developers who consistently submit good patches to the mailing list.
Be Seeing You.
--
Jeff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Some tests were disabled because of recently-patched problems in the
assembler. I'm contemplating simply removing the tests that require
exceptions, because we're going to do much more with exceptions than
these (probably already deprecated) tests cover.
--
Jeff <[EMAIL PROTECTED]>
The commit pretty much says it all. Note that tests are added in
t/op/macro.t at the end.
--
Jeff <[EMAIL PROTECTED]>
he patch
actually made it to the server.
I'm not going to make this a policy, as I've been known to not follow
this policy myself, but I'd like to see tests submitted along with
things like new operations and major changes.
Just my 2 cents...
--
Jeff <[EMAIL PROTECTED]>
r hold your peace until someone else
decides to add them back to CVS. I'll rewrite the tests to 'add_n_ic'
and that ilk.
Opinions? Comments? Concerns?
--
Jeff <[EMAIL PROTECTED]>
Josef
How are we going to get people to write recursive subroutines if we have
a factorial operator? :) This is a little high-level to belong in
core.ops, but something else like math.ops or algebra.ops...
So, when are we going to have integrate_n_p_n_n? :)
--
Jeff <[EMAIL PROTECTED]>
> At least I don't think we've implemented unlimited register file size. :)
>
> I'm sure this is an easy fix, I'll look at it after dinner if someone
> else doesn't snag it.
>
> -Melvin
Implied patch applied, thanks.
--
Jeff <[EMAIL PROTECTED]>
e prepared for some more fixes
once I start testing beyond index zero.
--
Jeff <[EMAIL PROTECTED]>
s intending to
let the core split words into a PerlArray, but the simpler architecture
handling one word at a time worked out better, and obviated the need for
a split()-like routine.
--
Jeff <[EMAIL PROTECTED]>
#
# Forth interpreter
#
..constant STDIN 0
..constant PromptString "> &quo
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 *
>
> Brian
Feel free, as long as it doesn't break existing code too badly. I've
meant to add this for some time, just never gotten around to it.
--
Jeff <[EMAIL PROTECTED]>
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...
--
J
mind rewriting the patch so that it substitutes files
inline at the point of .include'ing I'll be happy to revert the old
patch and put your new one in. Sorry about the seeming change of mind,
but this is what I get for affirming stuff at obscenely late hours.
--
Jeff <[EMAIL PROTECTED]>
> --
>
> foo.pasm
> --
> print "hello "
> --
>
> foo2.pasm
> ------
> print "world\n"
> --
>
> Does that make more sense?
>
> Brian
>
> > --
> > Jeff <[EMAIL PROTECTED]>
imagine we'll
find a new use for them later on.
Catching up on a week's worth of email here...
--
Jeff <[EMAIL PROTECTED]>
. For instance, in starting to
translate the current make system to it I've found missing flag settings
(-lm &c) and some dependency situations that I may not have remembered
to take care of. Some of the fixes will be checked in over the next few
days.
Comments, criticisms &c
es 'foo.ops', 'foo.h', 'bar.c', 'bar.h', and
'makeTest.pl'. And maybe more. Again, if anyone wants the actual package
of files I'm using for testing, feel free to email me or bug me on IRC.
--
Jeff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
PMCs.
FORTH :)
If anyone can give me a good reason why we shouldn't release (short of
show-stopping bugs &c) then speak before 2000GMT or until tomorrow hold
h(er|is) peace.
--
Jeff <[EMAIL PROTECTED]>
Jeff wrote:
>
> As the message says. Code freeze tonight at midnight EDT (GMT-0400).
> I'll be tagging with PRE_REL_0.0.7 then.
Code slush at 2200, code freeze at 0030. Tag was actually named
PRE_REL_007.
> Features to be included:
>
> Perl 6 grammar
> Partial
showlist.cgi?name=perl6-internals
for tips on how to subscribe. CVS commit access is given out to
developers who consistently submit good patches to the mailing list.
"The name is Parrot. Percy Parrot."
--
Jeff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ze for this, but I came back from YAPC only to go on to Oshkosh,
and I'm just now recovering from that. Expect to see me more often from
now on, or at least so I hope.
--
Jeff <[EMAIL PROTECTED]>
Let's not forget a Python grammar, automatically generated. The tool
won't remove left-recursiveness, but it should at least help jump-start
the implementation.
--
Jeff <[EMAIL PROTECTED]>
Jerome Quelin wrote:
>
> Btw, how do you prefer me to send patch (as if I were able to send more
> patches... anyway...): plain text inside the mail or attached (such as this
> one)?
This is a great start, Jerome! A name for the patch might be a nice
touch, but it applied just f
it depends in fact from the
> encoding? How one should treat this?
It would probably be derived from the encoding used by the string the
character derives from. Look at the encoding table in the string's data
structure.
--
Jeff <[EMAIL PROTECTED]>
Jerome Quelin wrote:
>
> Hi,
>
> I'm proud to provide you with a Befunge-93 interpreter written in Parrot! I'd
> like to thanks you all of the parrot team, for giving us such a marvelous toy
> to play with.
Applied... AIEE...
--
Jeff <[EMAIL PROTECTED]>
Along with sample Ruby, Python, Java, Lisp, and Prolog grammars. Not
sure about Ruby and Python working under the translator...
--
Jeff <[EMAIL PROTECTED]>
Tom Hughes wrote:
>
> In message <[EMAIL PROTECTED]>
> Mike Lambert <[EMAIL PROTECTED]> wrote:
> Oops. That only went in yesterday... Now fixed.
>
> > Overall, tho, the patch looks extemely complete. Tracing support,
> > disassemble.pl support, debug.c support, etc. You even reduced ma
Jeff wrote:
>
> Tom Hughes wrote:
> >
> > In message <[EMAIL PROTECTED]>
> > Mike Lambert <[EMAIL PROTECTED]> wrote:
> > Oops. That only went in yesterday... Now fixed.
> >
> > > Overall, tho, the patch looks extemely complet
Jerome Quelin wrote:
>
> Sorry guys, I was putting the blame on you when trying to load a file not
> properly newline-terminated, but it was *all my fault*.
> Here's the patch.
Applied, thanks.
--
Jeff <[EMAIL PROTECTED]>
Tom Hughes wrote:
>
> In message <[EMAIL PROTECTED]>
> Jeff <[EMAIL PROTECTED]> wrote:
>
> > Jeff wrote:
> >
> > > It's not quite applying against the current build, however.
> > > classes/default.pmc was easy to fix, ass
The subject pretty much says it all. The format pretty much corresponds
to the upcoming Exegesis. Major changes were to the modifiers, and a few
syntax changes in the depths.
Sean, feel free to take what you can use (if anything) from this and
delete the rest.
--
Jeff <[EMAIL PROTECTED]>
7;bytes added' count past
Simon or Dan :)
Again, my most profuse apologies, but we have to get this thing into the
Unicode era. If it has to be kicking and screaming, my apologies but so
be it.
--
Jeff <[EMAIL PROTECTED]>
Brent Dax wrote:
>
> Jeff Goff:
> # The mass of ICU code that's been added to Parrot. It's taking
>
> Have we determined that there are no programming language and
> portablility issues yet?
>
> Are all the bits we need written in C? If not, we can
Codename Octarine
Schedule as follows:
August 29, 8am EDT: Code slush, only bug and warning fixes allowed.
August 30, 11:59pm EDT: Code freeze and pretag
August 31, 00:59 EDT: Tag and Release
--
Jeff <[EMAIL PROTECTED]>
> Is there any reason to not to use GMT times in general? I have hard
> time remembering all the different TLAs for timezones.
Not really. And unfortunately the release date moved up one day due to
some contract issues. Tag will be at 0359 GMT Sep. 2, pretag was made at
0030 GMT Sep. 2.
--
Jeff <[EMAIL PROTECTED]>
ng list,
and patches should be sent there as well. If you're not subscribed, look
at:
http://lists.perl.org/showlist.cgi?name=perl6-internals
for tips on how to subscribe. CVS commit access is given out to
developers who consistently submit good patches to the mailing list.
"The name i
eing uploaded
at the moment that doesn't have this minor problem.
--
Jeff <[EMAIL PROTECTED]>
Patch #17034 - Committed but not marked as such.
Patch #17030 - Committed but not marked as such.
Patch #17025 - Committed.
Patch #17009 - Committed.
Patch #17002 - Committed but not marked as such.
Patch #17000 - Committed.
--
Jeff <[EMAIL PROTECTED]>
ep more up-to-date. And getting rid of the
Warnock phenomenon.
Basically trying to make sure I stay on track and keep getting my job
done...
--
Jeff <[EMAIL PROTECTED]>
Jeff wrote:
>
> And some more marked as committed that got missed...
> Patch #17000 -
Ewps. It was recently pointed out to me that I accidentally reversed
#17000. The problem has been fixed, I believe. Sorry, Andy.
--
Jeff <[EMAIL PROTECTED]>
the Solaris tinderbox.
> (I sent in a patch for that #17034 which is listed as applied, but
> I don't think it actually is.)
Again, that's probably my fault. I'm temporarily abstaining from
patching until I can figure out what I've been doing wrong.
--
Jeff <[EMAIL PROTECTED]>
you explicitly declare which test directories you want
to run. Thoughts on this?
--
Jeff 'puttering with Unicode' <[EMAIL PROTECTED]>
Sean O'Rourke wrote:
>
> On Sat, 7 Sep 2002, Jeff wrote:
--snip--
> What this code is trying to say is "don't run the parser tests, because
> they're unmaintained". So probably something like
>
> grep !m{t/parser/} glob "t/*/*.t&quo
en running the
Solaris servers or find someone who's willing to work with the current
tinderbox client and set up a new Solaris system. Are there any other
people out there with Solaris servers that would like to volunteer? If
so, email to the mailing list or me privately.
--
Jeff <[EMAIL PROTECTED]>
Jeff wrote:
>
> Mike Lambert wrote:
> >
> > > First, a thank you to whoever it is who is running these test-drive
> > > machines (there's no name in the build log). Also, a thanks to Compaq
> > > for setting them up.
>
> Yes, many thanks t
Judging by the patches, this was a much earlier version than I intended to
post. In the current version, min and max are now implemented, and test files
evaluate two-operand and three-operand versions. The (<>=) operands work now
with more than two operands, and I've added tests for these with thr
27;t clear, then please ask for clarification. I keep
hoping that there's an answer to my situation that doesn't involve new
instructions, or can be implemented without a great deal of overhead.
-Jeff Goff
<[EMAIL PROTECTED]>
ren't
implemented and the notion of executing register warps on such a large data
structure to implement such things as arrays strikes me as terribly inefficient.
-Jeff
<[EMAIL PROTECTED]>
"Gregor N. Purdy" wrote:
> All --
>
> > Judging by the patches, t
ehandle, and
it should be able to handle IEEE math, with any luck.
-Jeff
<[EMAIL PROTECTED]>
with compiler-generated labels.
On the upside, this patch allows me to continue to add new instructions
to the compiler without fear of label collision.
--
--Jeff
<[EMAIL PROTECTED]>
#! perl -w
use Parrot::Test tests => 6;
output_is( <<'CODE', <
diff -ru parrot
Erps, macro.t had a slight bug. The included version of macro.t fixes it.
--Jeff
<[EMAIL PROTECTED]>
#! perl -w
use Parrot::Test tests => 7;
output_is( <<'CODE', <
to collect the number
of operators, write that, then write the operator stream out.
--Jeff
<[EMAIL PROTECTED]>
#--
#
# read_file
#
# read_file STRING, FILE_NAME
#
read_file macro R, S, CHUNK_SIZE, TEMP_STR
read(s,i|ic,i|ic) was setting the length of the string to the selected
length no matter what.
--
--Jeff
<[EMAIL PROTECTED]>
diff -ru parrot/core.ops parrot_orig/core.ops
--- parrot/core.ops Tue Nov 6 11:14:25 2001
+++ parrot_orig/core.opsWed Nov 7 20:53:05 2001
@@ -199,7
Yeah, I probably should have named the register stack 'X' or something like
that. At least we're thinking along somewhat compatible lines. I'll be eager to
see your solution...
Dan Sugalski wrote:
> At 10:34 AM 10/25/2001 -0400, Jeffrey Goff wrote:
> >pope # Resto
a in
close I0
end
This may not even vaguely resemble the I/O model we eventually adopt,
but it's one idea. Albeit a simplistic model.
--
Jeff
<[EMAIL PROTECTED]>
7,9d6
< #include
< #include
< #include
75,139d71
<
<
<
<
erent directories.
--
--Jeff
<[EMAIL PROTECTED]>
diff -ru parrot/Parrot/Assembler.pm parrot_orig/Parrot/Assembler.pm
--- parrot/Parrot/Assembler.pm Sat Nov 3 19:04:08 2001
+++ parrot_orig/Parrot/Assembler.pm Sat Nov 3 22:50:04 2001
@@ -33,7 +33,6 @@
use Getopt::Long;
use Parrot::Op;
Quite right, Ken. The new patch hopefully takes care of that issue, and
fixes an additional bug in the concat operator.
Ken Fox wrote:
> Jeff wrote:
> > diff -ru parrot/core.ops parrot_orig/core.ops
> > --- parrot/core.ops Tue Nov 6 11:14:25 2001
> > +++ parrot_orig/co
with null strings.
t/op/string.t - Added tests for ord() opcode, added a few null tests for
concat().
At a suggestion from Alex Gough, the three-argument ord opcode now
behaves like perl's arrays when given negative indices. Read the opcode
documentation for more information.
--Jeff
<[EMAIL PROTECTED]>
foo}' to '@foo@', and changing file names from
'config_h.in' to 'config.h.in'. The autoconf and configure files won't
depend upon any settings from the user's perl binaries, because that
could be misleading. The ./configure file will make all of its own
decisions about the environment.
--Jeff
<[EMAIL PROTECTED]>
Files patched:
Parrot/Assembler.pm - Changed 'replace_string_constants' to patch the
quoting
t/op/build.t - Added tests, reordered the quoting.
--
--Jeff
<[EMAIL PROTECTED]>
c - The memory allocation should likely be done elsewhere.
Currently it's done inside make_interpreter, and it should be factored
out into a different function.
pbc2c.pl - The patch breaks encapsulation by altering the {CODE} hash
keys inside the OpsFile object
--
--Jeff
<[EMAIL PROTECTED]>
diff
on't think it's a security issue, but it is a concern for compiler
writers debugging their code. Making things pseudorandom makes it
unlikely that an arena can be accessed by accident.
--Jeff
<[EMAIL PROTECTED]>
diff -ru parrot/core.ops parrot_old/core.ops
---
ing_ord
>anywhere, and cvs logs don't show a string.c update.
>
> R.
>
> > -Original Message-
> > From: Jeff [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 11:46 PM
> > To: [EMAIL PROTECTED]
> > Subject: [PATCHES] or
on't have much time to commit
>to Parrot any more; I'd very much like to make 0.0.4 my last release.
>
>I hope to contribute to Parrot in the future if things get less busy,
>but for now, I feel I've achieved my goals of putting Parrot on a solid
>footing, and it's
--- Begin Message ---
Andrew J Bromage wrote:
>
> G'day all.
>
> I'm working on the Optimizer (adding a new intermediate form to allow
> for more aggressive optimization) but mail to Jeff Goff seems to be
> bouncing. Does anyone know where he is?
>
>
Simon Glover wrote:
>
> Self-explanatory patch.
>
> Simon
>
> --- MANIFEST.oldSun Mar 24 16:03:02 2002
> +++ MANIFESTSun Mar 24 16:03:39 2002
> @@ -72,6 +72,7 @@
> examples/assembly/Makefile
> examples/assembly/bsr.pasm
> examples/assembly/call.pasm
> +examples/assembly/cat.pas
without
ending up with a completely broken Parrot for weeks and developers
screaming about "What the *HELL* is this error? Where is this library?
". If these issues have already been beaten to death and
we've moved on to more interesting issues, of course I'll be interested
there as well.
Waiting for the firestorm,
--
Der Parrot Kommisar, Jeff <[EMAIL PROTECTED]>
nly
version.
In conclusion, this approach feels more workable, and the full UTF-16
implementation details can be rolled out incrementally, rather than a
single mass migration. If this suggestion flies, I'll rewrite
strings.pdd and post it in the next few days.
--
Jeff <[EMAIL PROTECTED]>
Jeff wrote:
>
> Hong Zhang wrote:
> >
> > I think it will be relative easy to deal with different compiler
> > and different operating system. However, ICU does contain some
> > C++ code. It will make life much harder, since current Parrot
> > onl
Are, as mentioned, Unicode and keyed aggregates. Dan's volunteered to
work on keyed aggregates, which leaves me to work on Unicode. I hope to
have something put together over the weekend.
--
Jeff <[EMAIL PROTECTED]>
les appear to do such things as create iterator
wrappers, bidirectional display and normalization.
Some of the files are thicker than wrappers, but I think there's enough
code behind this C++ veneer that we can at least use it if not the
entire library.
--
Jeff <[EMAIL PROTECTED]>
l
/usr/bin/pod2html: pdd06_pasm.pod: unterminated list at =head in
paragraph 358. ignoring.
[parrot@damogran pdd]$ pod2html pdd14_bignum.pod >pdd14_bignum.pod
/usr/bin/pod2html: no title for pdd14_bignum.pod at
/usr/lib/perl5/5.6.0/Pod/Html.pm line 402.
--
Jeff <[EMAIL PROTECTED]>
Mostly announcing the new pumpking, updating the PDD list, and updating
the status page with language information and current PMC status. Other
changes to come tomorrow night, but the important stuff is up.
--
Jeff <[EMAIL PROTECTED]>
f which is keyed aggregates *will* be in the next release,
and we'll be updating the roadmap to reflect this state of affairs. Keep
watching dev.perl.org for more updates.
--
Jeff <[EMAIL PROTECTED]>
Jeff wrote:
>
> Hopefully that'll get your attention.
>
> In the interests of accomplishing something this millennium, I'm
> planning to tag version 0.0.5 at some time around 12:01am EST Monday,
> April 15. I'll be watching mail up until the deadline, so if n
pers who consistently submit good patches to the mailing list.
Have fun, and hack well.
--
Jeff <[EMAIL PROTECTED]>
; stuff like this. Hopefully someone else with more experience can figure
> out why the cgoto detection isn't working for David?
Thanks for all the detective work, guys. I was resigned to problems
showing up, but was dismayed at them showing up this early. Ah well,
better that they show up early on rather than months down the road...
--
Jeff <[EMAIL PROTECTED]>
the initial release
of the new make.pl, running it will likely EAT YOUR HARD DRIVE. Now that
I've sufficiently scared you, I'll reassure you that I'll comment out
the nasty bits that actually run the dependencies and enable some
debugging so you can watch how make.pl would have actually destroyed
your filesystem had I let it run amok.
Seriously though, with the probable exception of a few things that I
won't be
able to easily translate to the new system, it shouldn't do anything out
of the ordinary. I hope. In any case, uncomment and run at your own
peril.
--
Jeff <[EMAIL PROTECTED]>
re stopping me, I'll come at it from the front end and
get the parsing details worked out first, worrying about the actual code
generation at the end.
--
Jeff <[EMAIL PROTECTED]>
Garrett Goebel wrote:
>
> From: Jeff [mailto:[EMAIL PROTECTED]]
> >
> > I'm going to try to have the assembler done over the weekend,
> > with at the least hooks for a macro system so that people can
> > work on pieces of that.
>
> Are you working with
onder
> what happened to it.
Funny thing, Simon. I'm looking at something that purports to handle
this right now... =)
--
Jeff <[EMAIL PROTECTED]>
a
different backend that the language compilers will be able to use that
will support compilation straight to Parrot bytecode, without a .pasm
file as an intermediary. Hopefully we'll be able to use this for the
tests as well, which should speed things up by quite a bit.
--
Jeff <[EMAIL PROTECTED]>
; +++ core.ops29 Apr 2002 14:00:28 -
> @@ -2823,7 +2823,7 @@
>
> Re-enable GC
>
> -=back
> +=cut
>
> op collecton() {
>if (interpreter->GC_block_level) {
>
> --
> Ilya Martynov (http://martynov.org/)
Applied, thanks.
--
Jeff <[EMAIL PROTECTED]>
> Nick
Hi, Nick. I think that question is covered in the Parrot FAQs. Try
<http://www.parrotcode.org/faq/#why aren't you using external tool or
library x> for more information.
--
Jeff <[EMAIL PROTECTED]>
1 - 100 of 620 matches
Mail list logo
