Christoph Otto wrote:
If those are your thoughts on the subject, then it seems to make sense
to add the pdd format test to make test. The attached patch does this.
I'll apply it and mark this ticket as resolved before the next
#parrotsketch unless there are any objections.
Excellent idea.
The scalar PMC is abstract, but it contains multis that need registration with
the MMD system at initialization time. PMCs containing multis register those
multis in their Parrot_PMC name_class_init() functions.
At least, non-abstract PMCs do.
I ran into a similar problem with my vtable
Christoph Otto via RT wrote:
If there isn't a technical reason why this is necessary, there's no
reason to create such a limitation. If there is such a reason, just
pick something big and make the code enforce it.
The PDD should of course be kept in sync with reality, but that simply
entails a
chromatic wrote:
The scalar PMC is abstract, but it contains multis that need registration with
the MMD system at initialization time. PMCs containing multis register those
multis in their Parrot_PMC name_class_init() functions.
At least, non-abstract PMCs do.
I ran into a similar problem
Christoph Otto via RT wrote:
Is this something we want to go ahead with or should this ticket be
rejected?
I've had it on my hiveminder todo list for over a month now. The problem
is, it's not only a matter of annoying fiddly bookkeeping work now, it's
also annoying fiddly bookkeeping work
Christoph Otto via RT wrote:
I'll sign up to do the grunt work to fix the failing tests if someone
makes a decision on what the consistent behavior should be.
This falls under the I/O PDD, the next milestone. Hold for a couple of
days. I've added it to the tasklist for the milestone:
On Fri Sep 05 00:18:19 2008, [EMAIL PROTECTED] wrote:
Bob Rogers wrote:
From: chromatic [EMAIL PROTECTED]
Fixed in r30286.
-- c
Terrific; thanks. (Especially since it looks like something I may
have
seen in other circumstances, but could not reproduce.)
# New Ticket Created by Christoph Otto
# Please include the string: [perl #58670]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58670
make cover is broken, apparently because of the use of Dl_info and a couple
NotFound wrote:
Given that the name will be mainly used via macros, a long and
meaningful name can be used, such as Parrot_PMCdata_PMCname
That's a good refinement, we can make the change after the next release.
The attached patch does it. There is a lot of changes, I suspect many
of them are
Applied in r30888. cotto is going to check its functioning on Cygwin,
but it did no harm on Darwin and Linux, so I'm committing it now.
Thank you very much.
kid51
Agreed that this particular ticket is not useful. Resolve it and replace
it with a [CAGE] ticket with explicit instructions on converting all
existing 'sprintf', 'strcat', etc calls with calls to 'snprintf',
'strlcat', etc. (Also include a list of all calls that should be converted.)
This can
# New Ticket Created by Allison Randal
# Please include the string: [perl #58672]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58672
For SUPER and NEXT, provide a way of returning a list or iterator for
access to
On Mon Sep 08 00:01:08 2008, [EMAIL PROTECTED] wrote:
Christoph Otto wrote:
If those are your thoughts on the subject, then it seems to make sense
to add the pdd format test to make test. The attached patch does this.
I'll apply it and mark this ticket as resolved before the next
On Mon, Sep 8, 2008 at 9:31 AM, Allison Randal via RT
[EMAIL PROTECTED] wrote:
Agreed that this particular ticket is not useful. Resolve it and replace
it with a [CAGE] ticket with explicit instructions on converting all
existing 'sprintf', 'strcat', etc calls with calls to 'snprintf',
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Sep 8 13:00:01 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with
# New Ticket Created by Bob Rogers
# Please include the string: [perl #58660]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58660
The attached tarball illustrates the problem (which has been around
for a while):
# New Ticket Created by Christoph Otto
# Please include the string: [perl #58668]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58668
src/exceptions.c has some brokenness that caused gcc to barf during make cover
On Sun, Sep 7, 2008 at 11:06 PM, jerry gay [EMAIL PROTECTED] wrote:
On Tue, Jul 1, 2008 at 7:17 AM, Will Coleda via RT
[EMAIL PROTECTED] wrote:
On Thu Jun 26 11:01:00 2008, [EMAIL PROTECTED] wrote:
chromatic wrote:
T::H 3 is only a requirement for people who want to type 'make
smolder'
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote:
a) Do abstract base classes as currently implemented in Parrot serve any
useful purpose? If not, eliminate them.
can they be replaced by roles?
~jerry
On Monday 08 September 2008 07:36:51 jerry gay wrote:
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote:
a) Do abstract base classes as currently implemented in Parrot serve any
useful purpose? If not, eliminate them.
can they be replaced by roles?
Exactly my thought.
Author: allison
Date: Mon Sep 8 09:39:36 2008
New Revision: 30891
Modified:
trunk/docs/pdds/draft/pdd30_install.pod
Log:
[pdd] An initial round of comments and edits to the Installation PDD.
Modified: trunk/docs/pdds/draft/pdd30_install.pod
I've just committed an initial pass on the Installation PDD. It's
looking good, definitely a good start. I've included some comments to
seed further discussion and development of the draft.
Also, we'll need to include more details on the installation of Parrot
itself (the draft leans pretty
Author: chromatic
Date: Mon Sep 8 10:22:15 2008
New Revision: 30892
Modified:
trunk/docs/pdds/draft/pdd30_install.pod
Log:
[PDD] Fixed linebreaking in PDD 30 draft to conform to coding standards.
Modified: trunk/docs/pdds/draft/pdd30_install.pod
On Mon Sep 08 01:18:37 2008, [EMAIL PROTECTED] wrote:
Christoph Otto via RT wrote:
Is this something we want to go ahead with or should this ticket be
rejected?
I've had it on my hiveminder todo list for over a month now. The problem
is, it's not only a matter of annoying fiddly
On Mon Sep 08 00:12:44 2008, cotto wrote:
On Mon Sep 08 00:01:08 2008, [EMAIL PROTECTED] wrote:
Christoph Otto wrote:
If those are your thoughts on the subject, then it seems to make
sense
to add the pdd format test to make test. The attached patch does
this.
I'll apply it and
On Mon Jul 07 00:13:20 2008, [EMAIL PROTECTED] wrote:
On Sunday 06 July 2008 22:17:12 Andrew Johnson via RT wrote:
On Sun Jul 06 11:03:37 2008, japhb wrote:
Better yet, we should replace the inherently insecure quicksort
algorithm (insecure in the vulnerable to algorithmic attack
Fixed in r30870, added a test in r30900. Closing ticket.
Added a test in r30902. Closing ticket.
The code in this ticket does not parse. Is using obsolete syntax? Can
someone provide an updated version?
On Mon Sep 08 04:23:37 2008, [EMAIL PROTECTED] wrote:
Applied in r30888. cotto is going to check its functioning on Cygwin,
but it did no harm on Darwin and Linux, so I'm committing it now.
Thank you very much.
kid51
It looks good on Cygwin too, so I'm marking this resolved.
Reading through the updated code, it seems that (using Task as an
example):
Parrot_PMCdata_Task
is not much clearer than the original Parrot_Task was. Let's go with:
Parrot_Task_attributes
A fast ack'ing of: Parrot_[_a-zA-Z]+_attributes for possible
collisions shows only:
On Fri Sep 05 12:16:25 2008, cotto wrote:
On Tue May 27 13:33:11 2008, [EMAIL PROTECTED] wrote:
Running this program:
sub foo($a) {say $a} ; my $x = ;
on Ubuntu 8.04 with latest Parrot from svn gives this:
$ ./perl6 test.p6
Statement not terminated properly at line 1, near
On Mon Apr 09 01:29:52 2007, pcoch wrote:
In the file src/ops/debug.ops in the debug_break() op, there is an
explicit exit(0), which is marked as being not an ok thing to do.
This issue needs to be investigated and fixed.
It looks like the explicit exit in debug_break() is gone, so I'm marking
Author: coke
Date: Mon Sep 8 12:59:30 2008
New Revision: 30913
Modified:
trunk/docs/pdds/draft/pdd30_install.pod
Log:
[codingstd] Fix YASF.
Modified: trunk/docs/pdds/draft/pdd30_install.pod
==
---
On Mon, Sep 08, 2008 at 09:28:47AM -0700, NotFound via RT wrote:
The code in this ticket does not parse. Is using obsolete syntax? Can
someone provide an updated version?
Perhaps:
.sub main
.local pmc foo
foo = get_global 'foo'
foo('x' = 1, 'y' = 2)
The attached patch does it. There is a lot of changes, I suspect many
of them are candidates for replacing with use of the SET_ATTR and
GET_ATTR macros. Maybe defining a macro SELF_DATA_TYPE will be a
convenient shortcut.
Reading through the updated code, it seems that (using Task as an
Applied in r30907, thanks.
Author: rurban
Date: Mon Sep 8 12:07:23 2008
New Revision: 30910
Modified:
trunk/docs/pdds/draft/pdd30_install.pod
Log:
[pdd30] incoorporate allisons critic
Modified: trunk/docs/pdds/draft/pdd30_install.pod
==
---
On Tue Sep 11 03:32:51 2007, pcoch wrote:
Having a look through PDD03 I noticed the TODO item left by Chip:
=head3 Overflow
If too many values are provided to fit into the given target
registers, Parrot
will throw an exception. Note that if the final target is a P
register with
Author: julianalbo
Date: Mon Sep 8 13:50:52 2008
New Revision: 30914
Modified:
trunk/docs/pdds/pdd17_pmc.pod
Changes in other areas also in this revision:
Modified:
trunk/languages/lua/src/pmc/luauserdata.pmc
trunk/languages/perl6/src/pmc/mutablevar.pmc
On Monday 08 September 2008 12:57:00 Christoph Otto via RT wrote:
On Tue Sep 11 03:32:51 2007, pcoch wrote:
Having a look through PDD03 I noticed the TODO item left by Chip:
=head3 Overflow
If too many values are provided to fit into the given target
registers, Parrot
will
On Thu Feb 21 12:15:06 2008, Whiteknight wrote:
What would be the best way to handle this? We certainly don't need to do
anything on systems where INT_MAX == -INT_MIN, but a simple compiler
directive should help to detect that case.
In the event that abs(INT_MIN) abs(INT_MAX), should we
On Mon Oct 22 07:01:59 2007, pcoch wrote:
In src/pmc/hash.pmc:thaw() there is the todo item:
/* TODO make a better interface for hash creation
... do this.
Where do we want to go with this?
What would be the best way to handle this? We certainly don't need to do
anything on systems where INT_MAX == -INT_MIN, but a simple compiler
directive should help to detect that case.
In the event that abs(INT_MIN) abs(INT_MAX), should we silently
saturate the result to INT_MAX, or should
On Sat Sep 06 20:55:36 2008, [EMAIL PROTECTED] wrote:
... or we could use SIGUSR for the tests, I suppose. We're not using
real-time signals elsewhere in Parrot right now.
All I can really say at this point is, Patches welcome. From my
googling about SIGUSR, it appears we'd have to trap
On Tue Aug 19 19:28:43 2008, [EMAIL PROTECTED] wrote:
A net total of 5 t/configure/*.t files were eliminated tonight as part
of r30368 (RT 57780).
And I've been able to consolidate a few more over the past few weeks.
We now have 47 tests, down from a high of about 61.
This post is addressed to those of you who (a) have Perl 5 programming
skills and (b) have been lurking on the list or on #parrot without yet
dipping your toes in the water.
I have a number of projects, some of which are already in the form of RT
tickets, some not, which require only Perl 5
Patrick R. Michaud wrote:
Fixing this shouldn't be all that difficult -- in particular,
I think that src/pmc/resizablepmcarray.pmc lines 205-206 should
be changed from
- if (key = PMC_int_val(SELF))
- SELF.set_integer_native(key+1);
to something like
+ if (key =
48 matches
Mail list logo
