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->starti
thought I would 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
# New Ticket Created by "Tanton Gibbs"
# Please include the string: [perl #820]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=820 >
Adds some additional comments to byteorder.c and adds a byteorder.dev
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 at
allow 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 w
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?
Th
# New Ticket Created by "Tanton Gibbs"
# Please include the string: [perl #15306]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15306 >
This patch does a number of things
1.) adds the RECALL command. Thi
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
>
> 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.
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 perf
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, 200
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> `/cvs
# New Ticket Created by "Tanton Gibbs"
# Please include the string: [perl #15574]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15574 >
This patch implements the AGAIN pmc preprocessor command. AGAIN s
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
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...)
> 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 destruct
> > 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,
BTW, I'm glad to see you still working on/maintaining the African Grey
variation. I think it is important to maintain alternatives. Who knows, at
some point in the future, it may be determined that this is the right way to
go. If memory for embedded systems is the only issue, then I could
defin
I just did a cvs update and tried to configure, but it said I was missing
the following files:
languages/scheme/Scheme/Builtins.pm
languages/scheme/t/logic/lists.t
Does anyone else have this problem?
Tanton
> #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
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 -
Fro
> 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 2>&1
> $ less 1_1.debug
Those both work fine.
However, if I do
perl prd-perl6.pl --batch
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 mod
I agree with this; however, I also think it would be nice to have it all in
one place. It's a nuisance to have to open every file just to see what it
is. By the time I figure out what the 60th file does, I've forgotten what
the first does. It would be nice to have the information at the top of
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
> 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
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?
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: <[EM
first 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: "Ta
> 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
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
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 Mess
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]>
S
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 [
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 pe
39 matches
Mail list logo