I just wanted to let the list know that with the following configure options
--cgoto=0 --jitcapable=0 --execcapable=0
I had 100% pass rate on all cygwin tests. I know some people have had
trouble with cygwin in the past, so I thought I would share my success.
Another thing that helps is using
TLA = Three Letter Acronymn
- Original Message -
From: Paul [EMAIL PROTECTED]
To: Leopold Toetsch [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 11:21 AM
Subject: Re: This week's Perl 6 Summary [OT]
---
Also, cygwin won't do
perl -i
correctly, you MUST have
perl -i.bak
or something similar.
- Original Message -
From: Garrett Goebel [EMAIL PROTECTED]
To: 'Juergen Boemmels' [EMAIL PROTECTED]; Joe Wilson
[EMAIL PROTECTED]
Cc: Steve Fink [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday,
Yes, languages should now use IMCC as their target. Basically, they
generate IMCC instructions without regards for optimization and such so that
only a lexer/parser is needed. Take a look at the bf and ook languages for
an example. I think perl6 is also heading there.
Tanton
- Original
I also have a C++ compiler under development that uses flex + btyacc +
TreeCC that I can send on request. I must say that TreeCC is an extremely
nice system and one I highly recommend.
- Original Message -
From: Gopal V [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 17,
Are the Tru64 registers scanned for live PMCs/Buffers? I don't know
what things would typically get missed that way, but it's a known
problem for most architectures (or was until recently? What's the
status on this?)
I don't know if they are or not. How could you tell?
Does Tru64 have
dimension (0,0 - 0,20) as well as the first element
of the first dimension...(1,0). But it is wrong for all of the others. It
becomes 1 instead of 10. I have no clue yet why...still looking into it.
However, all tests pass on Tru64 if --gc-debug is off.
- Original Message -
From: Tanton Gibbs
I'm looking at the Tru64 problem.
The manifest problem is trivial:
languages/jako/docs/jako.pod needs to be added to the MANIFEST
The multiarray problem only occurs if you turn on --gc-debug...still looking
at it
Tanton
- Original Message -
From: Steve Fink [EMAIL PROTECTED]
To: [EMAIL
I agree that it seems wrong to change the name of an already established
language. However, I also don't like the fact that something with the name
Brainfuck comes with the core of parrot. What if we moved its
distribution out of CVS and just put it on the webpage, or something of that
nature?
on ARM, lots of these two:
In file included from ../include/parrot/register.h:16,
from ../include/parrot/interpreter.h:42,
from ../include/parrot/parrot.h:160,
from array.c:27:
.../include/parrot/string.h:59: warning: padding struct size
Great document. I have a couple of comments.
1.) The beginning talks a lot about people doing this on the job. A lot
of developers on open source projects are students, you might wish to
mention something just to acknowledge that they do exist. I know it is
petty, but it never hurts to feed
There were a number of warnings which read something like
structure padded for alignment of member value in debug.h
This can be trivially fixed by reordering the structure members ( I hope).
This patch works fine on cygwin, but I would like to see some other
platforms (especially 64 bit) try it
I hate to say this, but I'm still in favor of POD. It has all of the
functionality required
and is the official commenting style of parrot and perl. I personally find
POD distasteful,
but since it is the norm, then I think we should stick with it.
- Original Message -
From: Erik Lechak
I disagree.
I don't like Java that much (for many reasons), but I have nothing but
respect for the massive amount of documentation that is easily accessible
as
a direct result of JavaDoc. I personnaly feel that it greatly helped java
achieve the success it has. If all of parrot's module
What is annoying is that on my cygwin system, everytime I type make it
rebuilds everything starting from Configure. It doesn't matter if I have
touched anything or not. In other words
perl Configure.pl make
will run Configure.pl twice.
Very annoying.
Tanton
- Original Message -
Hhm - could you track this further down?
For failing e.g. 1_1.p6:
$ ./perl6 -vwk t/compiler/1_1.p6
$ ../imcc/imcc -d -d -d t/compiler/1_1.imc 1_1.debug 21
$ less 1_1.debug
Those both work fine.
However, if I do
perl prd-perl6.pl
#17517 build system, permanent Configure runs - annoying at least
I wish someone would commit this one as this does fix a very annoying
problem, especially on cygwin.
Tanton
In this case, it is quite likely that many programs will get that flag
set. In which case, we'll need to be doing a DOD run at the end of most
blocks
I would hope not. The only things which will set this flag are those items
needing deterministic destruction, not all
items with a
my $fh = IO::File-new(...)
anywhere in the program or its libraries would trigger this slow
behaviour
for the rest of the program.
No. That's why we make it a counter. When a DOD run is made we recalc
the number of deterministci destructions needed.
But, more than likely, the file
One thing that might be worth noting is that the current CVS version does do
some unintended COW things. My previous patch (the RECALL - AGAIN) thing
attempted to fix this but has not been applied. Basically, when setting a
value that was previously a non-string value (integer, float, etc...)
How Freudian can you get. The subject on this email should have been RECALL
renamed to AGAIN. It took me until now to realize this.
Sorry,
Tanton
- Original Message -
From: Tanton Gibbs (via RT) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 25, 2002 2:36 PM
Subject
# New Ticket Created by Tanton Gibbs
# Please include the string: [perl #15574]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15574
This patch implements the AGAIN pmc preprocessor command. AGAIN should be
used
Does anyone know why I keep getting this:
$ cvs diff diff.out
cvs server: failed to create lock directory for `/cvs/public/parrot/Parrot'
(/cvs/public/parrot/Parrot/#cvs.lock): No such file or directory
cvs server: failed to obtain dir lock in repository
`/cvs/public/parrot/Parrot'
cvs [server
TG Does anyone know why I keep getting this:
TG $ cvs diff diff.out
TG cvs server: failed to create lock directory for
`/cvs/public/parrot/Parrot'
TG (/cvs/public/parrot/Parrot/#cvs.lock): No such file or directory
TG cvs server: failed to obtain dir lock in repository
TG
Sure, that's pretty trivial to fix. What is the general concensus.
REINVOKE is fine with me, does that sound good?
- Original Message -
From: [EMAIL PROTECTED]
To: Tanton Gibbs [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 23, 2002 8:37 PM
Subject: Re: pmc RECALL command
Sure,
the basic problem is that in perlint.pmc we have something like:
void set_string( PMC* value ) {
CHANGE_TYPE( SELF, PerlString );
SELF-data = value-data
}
In other words implement a COW strategy after being changed into a
PerlString. However, in perlstring.pmc
the following is
# New Ticket Created by Tanton Gibbs
# Please include the string: [perl #15306]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15306
This patch does a number of things
1.) adds the RECALL command. This command
I stated #4 wrong...it should be perlnum.pmc not perlint.pmc
- Original Message -
From: Tanton Gibbs (via RT) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 22, 2002 12:26 AM
Subject: [perl #15306] [PATCH] pmc RECALL command implemented
# New Ticket Created by Tanton Gibbs
I stated #4 wrong...it should be perlnum.pmc not perlint.pmc
[snip exceedingly long unnecessary repost...]
It's late...I didn't mean to take up your bandwidth :(
sorry about that.
Ok, I would like to try and summarize what should be done for .dev files
1.) .dev files should not be used to describe individual
functions. Instead, the .c file that contains the function
should be used.
2.) .dev files should contain the sections as mentioned in PDD07.
3.) .dev files
This is the .dev file for dod.c
I realize that the garbage collection is still kind of (ok very) volatile
right now, but I thought we could go
ahead and have this for people to look at and make
comments on.
BTW, I submitted this patch to the RT system, but
it refused my email...any idea why?
Yes, after looking at this, I agree with Andy (and don't worry I don't think
you're picking on it,
I picked a small file so we could play with it until we found what we liked)
that it is a maintenence
headache to duplicate all of the functions.
However, I do think it is nice to be able to look
viewing of only the POD information.
Tanton
- Original Message -
From: John Porter [EMAIL PROTECTED]
To: Perl6 Internals [EMAIL PROTECTED]
Sent: Wednesday, July 17, 2002 2:39 PM
Subject: Re: [PATCH] .dev files.
Tanton Gibbs wrote:
. . . That saves a person digging through
the .c
# New Ticket Created by Tanton Gibbs
# Please include the string: [perl #820]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=820
Adds some additional comments to byteorder.c and adds a byteorder.dev file.
Tanton
start with a
small file and make sure everyone likes it before proceeding.
Thanks!
Tanton Gibbs
byteorder.diff
Description: Binary data
byteorder.dev
Description: Binary data
You could break it up into:
else if( rx-startindex == 0 ) {
goto OFFSET($2);
}
else {
--rx-startindex
}
- Original Message -
From: Andy Dougherty [EMAIL PROTECTED]
To: Perl6 Internals [EMAIL PROTECTED]
Sent: Tuesday, January 15, 2002 1:47 PM
Subject: gcc warnings: rx-startindex
36 matches
Mail list logo
