G'day,
I'm doing a bit of research and having a bit of fun reimplementing the PHP
parser, I've been using Python and dParser.sf.net (http://dparser.sf.net A
scannerless GLR parser).
I'm almost to the point where I can start taking an AST and doing code
generation, and I'd really like to be
G'day,
I'm doing a bit of research and having a bit of fun reimplementing
the PHP parser, I've been using Python and dParser.sf.net
(http://dparser.sf.net A scannerless GLR parser).
I'm almost to the point where I can start taking an AST and doing
code generation, and I'd really like to
Josh Wilmes wrote:
For some reason, this only occurs when imcc is built with tcc- it works fine
with the other compilers. I don't know what this error is meant to mean,
so i'm not quite sure how to troubleshoot it.
Any ideas?
[EMAIL PROTECTED]:~/devel/parrot% ./parrot t/op/arithmetics_38.pasm
Jonathan Worthington:
LIB : fatal error LNK1181: cannot open input file jit_cpu.obj
NMAKE : fatal error U1077: 'lib' : return code '0x49d'
Stop.
There *is* code in config/auto/jit.pl to disable JIT on Win32, so I'm not
sure why Parrot's trying to compile it. I *do* know that it was
Benjamin Goldberg wrote:
Joseph Ryan wrote:
Benjamin Goldberg wrote:
K Stol wrote:
The register stuff, I presume, is register allocation and the like?
When targeting IMCC, you can use an infinite amount of registers. Just
keep a counter in the code generator, each time a new register is
Echoing all compiler flags clutters the screen too much, so that
warnings easily can get missed.
Earlier I used to run make -s which silents make.
Still better would be:
- echo compiler flags once
- echo filenames only
- let the work depending on -s was given to make or not or such
Yepper.
I have a question about the status of my patches:
[perl #23034][PATCH] Implementation of methods for PIOs
[perl #23124][PATCH] [PATCH] Standard filehandles in the interpreter
are now PMCs.
There was very little feedback to this.
Can someone give me some feedback to the patches or if
This should go to the list also:
Gregor N. Purdy [EMAIL PROTECTED] writes:
Juergen --
Juergen Boemmels wrote:
Write
PutS
Why are there two diffrent calls to write data to an io, with only a
slightly different prototype. This is code-duplication in every
layer. I can't think
At 15:10 +0200 7/29/03, Juergen Boemmels wrote:
I have a question about the status of my patches:
[perl #23034][PATCH] Implementation of methods for PIOs
[perl #23124][PATCH] [PATCH] Standard filehandles in the interpreter
are now PMCs.
There was very little feedback to this.
Can
# New Ticket Created by Jos Visser
# Please include the string: [perl #23159]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23159
Description:
Klaas-Jan asked about this a while back--sorry it's taken so long to
get an answer.
If you read back through the list and other stuff I've written, it's
pretty clear that while I like CPS, I wasn't convinced that CPS was
the way to go, but if you look at the parrot code now, we use CPS.
Why?
Juergen Boemmels wrote:
I have a question about the status of my patches:
[perl #23034][PATCH] Implementation of methods for PIOs
[perl #23124][PATCH] [PATCH] Standard filehandles in the interpreter
are now PMCs.
There was very little feedback to this.
I didn't have a closer look
Perl 6 Summary for the week ending 20030727
Welcome to another in the ongoing series of Perl 6 summaries in which
your faintly frazzled summarizer attempts to find a native speaker of
Esperanto to translate this opening paragraph in honour of the huge
amount of money (1371 Euros)
--- Jos Visser [EMAIL PROTECTED] wrote:
# New Ticket Created by Jos Visser
# Please include the string: [perl #23159]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23159
On Tue 29 Jul 2003 16:40, Leopold Toetsch [EMAIL PROTECTED] wrote:
Hi Merijn,
Available:
HP-UX 11.00 32bit 1 or 2 CPU's HP C-ANSI-C and gcc-3.3
HP-UX 11.00 64bit 1 or 2 CPU's HP C-ANSI-C and gcc-3.3
HP-UX 10.20 32bit HP C-ANSI-C and gcc-3.3
AIX 4.3 32bit
Vladimir Lipskiy [EMAIL PROTECTED] writes:
if (-e jit/$cpuarch/core.jit and not $osname == 'MSWin32'){
ITYM:
if (-e jit/$cpuarch/core.jit and $osname ne 'MSWin32') {
--
Lars Balker Rasmussen Consult::Perl
On Tue, 29 Jul 2003, H.Merijn Brand wrote:
On Tue 29 Jul 2003 16:40, Leopold Toetsch [EMAIL PROTECTED] wrote:
Hi Merijn,
HP-UX 11.00/32 2 CPU:
:
io/io_buf.c
cpp: io/io_buf.c, line 65: warning 2001: Redefinition of macro MAX.
cpp: io/io_buf.c, line 66: warning 2001: Redefinition of
Parrot now has basic PCC (Parrot Calling Convention) support inside the
PIR assembler.
1) no fancy stuff like register renumbering
2) only the upper half of all registers are preserved currently
TODO:
- tests
- more tests
- docs
- still more tests
- optimize register usage
- tail call
There *is* code in config/auto/jit.pl to disable JIT on Win32, so I'm
not
sure why Parrot's trying to compile it. I *do* know that it was
working
fine before the exec stuff went in--perhaps looking at the diffs on
jit.pl
will be enlightening. Unfortunately, I'm away from my home
if (-e jit/$cpuarch/core.jit and $osname ne 'MSWin32') {
Yeah, you're right. Thanks.
Index: jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.18
diff -r1.18 jit.pl
71c71
if (-e
Index: io/io_buf.c
===
RCS file: /cvs/public/parrot/io/io_buf.c,v
retrieving revision 1.6
diff -u -r1.6 io_buf.c
--- io/io_buf.c 21 Jul 2003 18:00:45 - 1.6
+++ io/io_buf.c 29 Jul 2003 18:31:39 -
@@ -62,9 +62,6 @@
size_t
On 29 Jul 2003, Juergen Boemmels wrote:
Simon Glover [EMAIL PROTECTED] writes:
On Tue, 29 Jul 2003, H.Merijn Brand wrote:
iii) protect them with #ifdef MAX/#endif
I bet the definition of MAX and MIN on HP-UX is identical to my
definition.
I would not be surprised.
Ok, here is the
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #23162]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23162
Hi,
I just tried to get
perl Configure.pl --miniparrot
running
following
On 29 Jul 2003, Luke Palmer wrote:
G'day,
For a complete list of instructions, grab the cvs and look at the
various .ops files. They are scattered with POD documentation about
each op they implement.
The same documentation can also be found in the docs/ops/ subdirectory
-- it's
On Tue, 29 Jul 2003, Jürgen Bömmels wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #23162]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23162
Thanks, applied.
miniparrot
On Tue, Jul 29, 2003 at 09:11:15AM -0700 it came to pass that Mr. Nobody wrote:
I don't think it's worth adding extra overhead to lexical variables just to
support broken pasm. There are many ways to crash parrot with bad code - but
it's OK, since compilers of higher level languages simply
On Tue, 29 Jul 2003, Jos Visser wrote:
On Tue, Jul 29, 2003 at 09:11:15AM -0700 it came to pass that Mr. Nobody wrote:
I don't think it's worth adding extra overhead to lexical variables just to
support broken pasm. There are many ways to crash parrot with bad code - but
it's OK, since
Simon Glover [EMAIL PROTECTED] wrote:
Try and explain what invoke is supposed to do. NB this still needs work
[ snip ]
+=item void* invoke(INTERP, PMC* self, void* next)
[ snap ]
+It should set up the environment for the sub, and should return the
+location at which operation flow
On Tue, 29 Jul 2003, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
Try and explain what invoke is supposed to do. NB this still needs work
[ snip ]
+=item void* invoke(INTERP, PMC* self, void* next)
[ snap ]
+It should set up the environment for the sub, and
Simon Glover wrote:
Therefore the decision was taken that we should not guarantee that Parrot
should never segfault when fed bad assembler;
... in the fast run case, but we will provide a save environment, that
does do all kinds of bounds checking, check byte code, have a reduced
and
One thing we don't have is a complete set of coverage tests for the
parrot opcodes. (Nor stats as to which ops do actually get covered by
our current test suite) This would be a good thing to have,
especially if we could add it into the make test target to generate a
coverage report as part of
Piers Cawley [EMAIL PROTECTED] wrote:
Okay, okay, PONIE really stands for 'Perl On New Internal Engine'.
That's that what they say. Actually it was: PONIEPONIE:
Perl5 Obsoletes Nasty Internals Entirely:
Parrot Occupies Numerous Interpreters Everywhere
But that was to bulky. Or too many
I have checked in a patch to make the following work:
./parrot -o life.o examples/assembly/life.pbc
So, don't use test_main anymore.
I made this storing the pointer to the -o argument in the interpreter string
register 0 to make it visible from inside the core, instead of adding another
Dan Sugalski wrote:
One thing we don't have is a complete set of coverage tests for the
parrot opcodes. (Nor stats as to which ops do actually get covered by
our current test suite) This would be a good thing to have, especially
if we could add it into the make test target to generate a
There is http://www.hitchhiker.org/parrot_coverage/, which is built by
tools/dev/parrot_coverage.pl.
Any enhancements made there should show up in the next run.
I disabled it about a month ago when it started going into an endless loop
on a test.
I'll try turning it back on though.
--Josh
On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote:
Therefore the decision was taken that we should not guarantee that
Parrot
should never segfault when fed bad assembler; the creation of invalid
assembler is a compiler bug, and should be fixed at the compiler
level.
If people write
On Tuesday 29 July 2003 21:10, chromatic wrote:
On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote:
Therefore the decision was taken that we should not guarantee that
Parrot
should never segfault when fed bad assembler; the creation of invalid
assembler is a compiler bug, and
At 20:54 -0300 7/29/03, Daniel Grunblatt wrote:
On Tuesday 29 July 2003 21:10, chromatic wrote:
On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote:
Therefore the decision was taken that we should not guarantee that
Parrot
should never segfault when fed bad assembler; the creation
38 matches
Mail list logo
