Steve Fink wrote:
Hm. Sorry. I assumed that if it worked for me, it would work for
anyone. Robert has fixed one permission problem recently; can you give
it another try?
I tried: RT/perl: Modify ticket #18034
Set patch status to Applied
Results
* Permission Denied
And with: RT/perl:
Steve Fink wrote:
I suppose I ought to try to wrap up a release one of these days.
- Artificial goal: I want the list of pending patches to be smaller
than one screenfull before I release. Fortunately, I have a large
screen.
I did set 2 of them to Applied. I'll wade through my
In message [EMAIL PROTECTED]
Steve Fink [EMAIL PROTECTED] wrote:
* Keyed access
- Another discussion that's gone over my head. Leo has a scheme to
dramatically reduce the number of instructions, at the cost of
requiring a couple of opcodes for keyed accesses; Dan says that
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #18064]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18064
Parrot currently fails test 75 of t/pmc/pmc.t with --gc-debug but passes
without
On Wed, 23 Oct 2002, Steve Fink wrote:
I suppose I ought to try to wrap up a release one of these days. I've
been thinking about the possibilities, but I'm not sure about the
current state of a couple of things. And what I'd most like to see
right now is some stabilization. So I'll list my
Steve Fink writes:
I don't know exactly who has the permissions to do these things, but
I'm pretty sure that if you have commit access then you also have RT
futzing access.
^^^ this isn't true. The permissions are seperate (but obviously
should be related.)
-R
At 7:41 PM +0200 10/23/02, Leopold Toetsch wrote:
Possible (feature/architectural) goals for 0.0.9
* PMC cleanup
- Leo did a huge amount of work on this, but there are a few things left:
- array.pmc still autocreates something called PerlUndef
At 4:51 PM -0500 10/20/02, Allen Short wrote:
The ops described in PDD 6 and docs/parrot_assembly.pod for
scratchpads appear to be subtly different from the ones actually in
core.ops. In particular, i was led astray by the docs referring to the
newpad op and core.ops implementing new_pad. which
At 10:21 AM +0200 10/23/02, Leopold Toetsch wrote:
And second, while you are at it, could you provide some PBC
versioning, which get checked at packfile load time as discussed in
fingerprinting PBC files.
Yes, *please*. We need this info in the header and it needs to be
checked on load time.
On Wed, 23 Oct 2002, Leopold Toetsch wrote:
So changing own requests seems to be ok.
That's what I just observed too. I can change my own tickets, but I
can't do anything to any others.
--
Andy Dougherty [EMAIL PROTECTED]
At 8:23 AM +0200 10/22/02, Leopold Toetsch wrote:
Juergen Boemmels wrote:
... Also no vtable function has to
decide wether its called with 1, 2 or 3 keyed elements.
Yes, another advantage, I didn't think of. Currently all _keyed
vtable calls have to check, it the key is really there. This
At 4:57 PM +0200 10/19/02, Leopold Toetsch wrote:
struct {
can;
has;
isa;
union {
scalar_vtable;
aggregate_vtable;
object_vtable;
};
VTABLE;
Rather than a union, there'd be a set of pointers to various vtable pieces.
But a scalar (PerlInt) doesn't
Steve Fink wrote:
- Stratospheric rehydrocalibration amplifiers for the .NET people
(er... or something; I can't remember what they needed)
The ability to embed arbitrary data in a pbc file under a
named section. This data needs to be readable by the program
when it runs, but is
At 7:43 AM +1000 10/24/02, Rhys Weatherley wrote:
Steve Fink wrote:
- Stratospheric rehydrocalibration amplifiers for the .NET people
(er... or something; I can't remember what they needed)
The ability to embed arbitrary data in a pbc file under a
named section. This data needs
Steve Fink:
# - requires sprintf* to work on PPC. (Brent -- what's the status?)
Dan said that he would give me an account on a PPC machine so I could
debug this, but that hasn't happened yet.
# * Exceptions
# - I haven't been paying much attention to developments on this,
#
Erik Lechak:
# While trying to figure it out I rewrote Config.pl and some supporting
# files. They were just a little too complex for my taste. I have
# included the files because I don't feel confident enough to
# make them a
# patch.
Can you please *please* PLEASE generate a patch? 'cvs
On Oct-19, Bryan C. Warnock wrote:
On Fri, 2002-10-11 at 15:19, Erik Lechak wrote:
Almost got to this one within a week! ;-)
2) When I reply should I 'reply to all' or just reply to
perl6-internals? (This is my first mailing list)
I know Dan addressed part of this in his reply,
On Wed, 23 Oct 2002, Rhys Weatherley wrote:
Martin D Kealey wrote:
[Frank Farance's paper] specification based extended integer range
[at] http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/.
Very interesting proposal. I wish they had adopted it. Would
have saved me a lot
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18056]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18056
This patch is the beginning of an effort to make
19 matches
Mail list logo
