> 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
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
> 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
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 t
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
> > lay
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 someo
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) ra
# New Ticket Created by Jos Visser
# Please include the string: [perl #23159]
# in the subject line of all future correspondence about this issue.
# 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 yet,
On Thu, Jul 24, 2003 at 09:17:02AM -0400, Potozniak, Andrew wrote:
> &Test::More::is(1,1,"One equals One!!");
> &Test::More::is(1,2,"Does one equal two??");
You probably don't want to be calling those with the & in front of them
either as that'll make them bypass the prototype.
And as the Test fu
--- 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.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=23159 >
>
>
> --
--- Vladimir Lipskiy <[EMAIL PROTECTED]> wrote:
> > 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 n
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
"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: Red
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 optimizatio
> > > 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 m
> >> 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 "jit/$cpuarch
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 PIO_bu
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, h
# 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.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23162 >
Hi,
I just tried to get
perl Configure.pl --miniparrot
running
following problems I
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'
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
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.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=23162 >
Thanks, applied.
miniparrot still
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 wo
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, si
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
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 th
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 config
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
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
pointe
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 coverag
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
A
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 P
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 bu
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 creatio
37 matches
Mail list logo
