Re: [svn:parrot] r27357 - in branches/pdd25cx: compilers/imcc include/parrot src src/charset src/gc src/ops src/pmc t/pmc
chromatic wrote: These are the headerizer changes that bother me the most. Feel free to revert them. Allison
Re: [perl #53714] [PATCH] ...further thoughts on proposed fix
Digging a little further into the consequences of null_lib_name.patch, I see trouble ahead if the new library PMC is cloned into another interpreter. The fix lets you create a library PMC with no '_lib_name' property, but src/dynext.c:Parrot_clone_lib_into assumes that every library PMC has one. It causes a 'Null PMC access in get_string()' exception when it tries to clone the non-existent '_lib_name' prop. Is there a reason why Parrot_clone_lib_into wants to copy a hard-coded set of string properties? What is the intended use of the '_lib_name' property? No code in parrot currently touches it except to store it in new library PMCs and to copy it when cloning them. Maybe we should clone it conditionally, just as null_lib_name.patch creates it conditionally? Either that, or make sure that every library PMC always does have a '_lib_name' property. Tom
[perl #53802] [PATCH] GLUT callbacks: cleaner implementation
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #53802]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53802 >
The attached patch mainly cleans up the implementation of GLUT
callbacks, simplifying code both internally and in the PIR-visible API.
It also includes two other small cleanups in the OpenGL code:
1. a missing libglutcb build dependency that may fix a 'make -j2'
problem on Mac OS X, as per tetragon
2. use the 'die string' opcode rather than a manually generated
string exception in OpenGL.pir, as per pmichaud
-'f
=== config/gen/call_list/opengl.in
==
--- config/gen/call_list/opengl.in (revision 5082)
+++ config/gen/call_list/opengl.in (local)
@@ -1,7 +1,7 @@
# Used by OpenGL (including GLU and GLUT)
v3p
-vPP
-vPPi
-vPPii
+vJP
+vJPi
+vJPii
vfff
v
=== config/gen/makefiles/root.in
==
--- config/gen/makefiles/root.in (revision 5082)
+++ config/gen/makefiles/root.in (local)
@@ -2185,7 +2185,7 @@
@[EMAIL PROTECTED]@ $(SRC_DIR)/nci_test$(O) $(C_LIBS)
# for use by runtime/parrot/library/OpenGL.pir
-$(LIBGLUTCB_SO): $(SRC_DIR)/glut_callbacks$(O)
+$(LIBGLUTCB_SO): $(LIBPARROT) $(SRC_DIR)/glut_callbacks$(O)
$(LD) $(LD_LOAD_FLAGS) @ncilib_link_extra@ $(LDFLAGS) \
@[EMAIL PROTECTED]@ $(SRC_DIR)/glut_callbacks$(O) $(C_LIBS)
=== config/gen/opengl.pm
==
--- config/gen/opengl.pm (revision 5082)
+++ config/gen/opengl.pm (local)
@@ -251,8 +251,8 @@
foreach (@callbacks) {
$enums .= "$_->{enum},\n";
-$thunks.= " void $_->{thunk}($_->{proto});\n";
-$reg_funcs .= "PARROT_API void $_->{glutcb}(PMC *, PMC *);\n";
+$thunks.= " void $_->{thunk}($_->{proto});\n";
+$reg_funcs .= "PARROT_API void $_->{glutcb}(Parrot_Interp, PMC *);\n";
}
my $header = <= 4
- void glut_joystick_func(unsigned int, int, int, int);
-PARROT_API void glutcbJoystickFunc(PMC *, PMC *, int);
+ void glut_joystick_func(unsigned int, int, int, int);
+PARROT_API void glutcbJoystickFunc(Parrot_Interp, PMC *, int);
#endif
$thunks
$reg_funcs
-/* Never store a null interp in callback_data */
-void
-check_notnull_cb(PMC *interp_pmc, PMC *sub)
+/* Make sure that interp and sub are sane before running callback sub */
+/* : Should this do the moral equivalent of PANIC? */
+int
+is_safe(PARROT_INTERP, PMC *sub)
{
-if (PMC_IS_NULL(interp_pmc) || (Parrot_Interp) PMC_data(interp_pmc) == NULL)
-PANIC((Parrot_Interp) PMC_data(interp_pmc),
- "cannot register callback with null interpreter");
-}
-
-
-/* PANIC before running callback sub if interp or sub are insane;
- return unwrapped Parrot_Interp if everything OK */
-Parrot_Interp
-verify_safe(PMC *interp_pmc, PMC *sub)
-{
-Parrot_Interp interp = (Parrot_Interp) PMC_data(interp_pmc);
-
/* : Verify that interp still exists */
/* : Verify that sub exists in interp */
-
-return PMC_IS_NULL(sub) ? NULL : interp;
+
+return PMC_IS_NULL(sub) ? 0 : 1;
}
@@ -351,7 +338,7 @@
# special timer-related arguments that do not follow the template of all
# of the other GLUT callbacks
-=item C
+=item C
Register a Sub PMC to handle GLUT Timer callbacks.
@@ -362,24 +349,20 @@
void
glut_timer_func(int data)
{
-PMC *sub= callback_data[GLUT_CB_TIMER].sub;
-PMC *interp_pmc = callback_data[GLUT_CB_TIMER].interp_pmc;
+Parrot_Interp interp = callback_data[GLUT_CB_TIMER].interp;
+PMC *sub = callback_data[GLUT_CB_TIMER].sub;
-Parrot_Interp interp = verify_safe(interp_pmc, sub);
-
-if (interp)
+if (is_safe(interp, sub))
Parrot_runops_fromc_args_event(interp, sub, "vi", data);
}
PARROT_API
void
-glutcbTimerFunc(PMC *interp_pmc, PMC *sub, unsigned int milliseconds, int data)
+glutcbTimerFunc(PARROT_INTERP, PMC *sub, unsigned int milliseconds, int data)
{
-check_notnull_cb(interp_pmc, sub);
+callback_data[GLUT_CB_TIMER].interp = interp;
+callback_data[GLUT_CB_TIMER].sub= sub;
-callback_data[GLUT_CB_TIMER].sub= sub;
-callback_data[GLUT_CB_TIMER].interp_pmc = interp_pmc;
-
if (sub == PMCNULL)
glutTimerFunc(0, NULL, 0);
else
@@ -390,7 +373,7 @@
#if GLUT_API_VERSION >= 4
/*
-=item C
+=item C
Register a Sub PMC to handle GLUT Joystick callbacks.
@@ -401,31 +384,26 @@
void
glut_joystick_func(unsigned int buttons, int xaxis, int yaxis, int zaxis)
{
-PMC *sub= callback_data[GLUT_CB_JOYSTICK].sub;
-PMC *interp_pmc = callback_data[GLUT_CB_JOYSTICK].interp_pmc;
+Parrot_Interp interp = callback_data[GLUT_CB_JOYSTI
Re: [perl #39329] Check to make sure PMC_str_val, etc. are used appropriately
On Tue, May 06, 2008 at 09:38:56PM -0700, Patrick R. Michaud via RT wrote:
> I think this ticket is ready to be closed. A lot of the PMC_* items
> were likely fixed as part of the pdd15oo change, and the problem I cited
> has apparently been fixed.
Looking a bit further, there are still a few instances of PMC_int_val
in MMD routines in integer.pmc that look suspicious to me.
For example, src/pmc/integer.pmc lines 414-417 read:
MMD_DEFAULT: {
VTABLE_set_number_native(INTERP, SELF,
PMC_int_val(SELF) + VTABLE_get_number(INTERP, value));
}
and it's not clear if that PMC_int_val(SELF) needs to be
SELF.get_integer() .
Also, the code itself seems a little inconsistent: In some
places we have SELF.get_integer() and other places have
VTABLE_get_integer(INTERP, SELF) -- and it's not entirely clear
why one would be used over the other. Overall, the sections of
code that I perused seem to lean towards the .get_integer() form.
I don't know if we need similar reviews for string.pmc and float.pmc.
But this ticket seems sort of nebulous -- how will we know when to
close it?
Pm
[perl #39132] [DEPRECATED] pirtidy
On Fri Jul 13 18:51:14 2007, coke wrote: > Someone suggested using the PIR parser written in TGE to output PIR, > and have *that* be our > pretty printer. > > Good idea. If that happens, just kill the perl module. Changed my mind. There's no point in keeping a half baked version of something we know we're going to throw out, especially if no one is using it today. Let's remove it. Since this a tack on tool, not core functionality, it can be removed before the next release.
[perl #53834] [TODO] modify pge subrule parsing
# New Ticket Created by Jerry Gay # Please include the string: [perl #53834] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53834 > changes to subrule design in S05 have not yet been reflected in PGE. specifically, ~ aliases of the form ~ modified handling of ~ changes to the relevant source is in compilers/pge/PGE/Perl6Regex.pir, in the parse_subrule sub. YES. this is not a very detailed ticket. i expect it's life to be short.
Re: [perl #45989] [TODO] [PATCH] Escape the NULL character within Parrot_add_attribute()
> In src/objects.c:Parrot_add_attribute() there is the todo item:
>
> /* TODO escape NUL char */
>
> I think this applies to calling real_exception just afterwards.
According a discussion in #parrot this function and some related parts
is dead code. The attached patch removes it.
--
Salu2
Index: src/oo.c
===
--- src/oo.c (revisión: 27376)
+++ src/oo.c (copia de trabajo)
@@ -768,116 +768,6 @@
/*
-=item C
-
-Subclass a class. Single parent class, nice and straightforward. If
-C is C, this is an anonymous subclass we're creating,
-function.
-
-=cut
-
-*/
-
-PARROT_API
-PARROT_WARN_UNUSED_RESULT
-PARROT_CANNOT_RETURN_NULL
-PMC *
-Parrot_single_subclass(PARROT_INTERP, ARGIN(PMC *base_class), ARGIN_NULLOK(PMC *name))
-{
-PMC *child_class, *parents, *temp_pmc, *mro;
-SLOTTYPE *child_class_array;
-int parent_is_class;
-
-/* Set the classname, if we have one */
-if (!PMC_IS_NULL(name)) {
-fail_if_type_exists(interp, name);
-}
-else {
-/* RT#45975 not really threadsafe but good enough for now */
-static int anon_count;
-STRING * const child_class_name =
-Parrot_sprintf_c(interp, "%c%canon_%d", 0, 0, ++anon_count);
-name = pmc_new(interp, enum_class_String);
-VTABLE_set_string_native(interp, name, child_class_name);
-}
-
-/* ParrotClass is the baseclass anyway, so build just a new class */
-if (base_class == interp->vtables[enum_class_Class]->pmc_class)
-return pmc_new_init(interp, enum_class_Class, name);
-
-parent_is_class = PObj_is_class_TEST(base_class);
-child_class = pmc_new(interp, enum_class_Class);
-
-/* Hang an array off the data pointer */
-set_attrib_array_size(child_class, PCD_MAX);
-child_class_array = PMC_data_typed(child_class, SLOTTYPE *);
-set_attrib_flags(child_class);
-
-/* We will have five entries in this array */
-
-/* We have the same number of attributes as our parent */
-CLASS_ATTRIB_COUNT(child_class) = parent_is_class ?
-CLASS_ATTRIB_COUNT(base_class) : 0;
-
-/* Our parent class array has a single member in it */
-parents = pmc_new(interp, enum_class_ResizablePMCArray);
-
-VTABLE_set_integer_native(interp, parents, 1);
-VTABLE_set_pmc_keyed_int(interp, parents, 0, base_class);
-
-set_attrib_num(child_class, child_class_array, PCD_PARENTS, parents);
-set_attrib_num(child_class, child_class_array, PCD_CLASS_NAME, name);
-
-/* Our mro list is a clone of our parent's mro list,
- * with our self unshifted onto the beginning */
-mro = VTABLE_clone(interp, base_class->vtable->mro);
-VTABLE_unshift_pmc(interp, mro, child_class);
-
-/* But we have no attributes of our own. Yet */
-temp_pmc = pmc_new(interp, enum_class_ResizablePMCArray);
-set_attrib_num(child_class, child_class_array, PCD_CLASS_ATTRIBUTES,
-temp_pmc);
-
-parrot_class_register(interp, name, child_class, base_class, mro);
-rebuild_attrib_stuff(interp, child_class);
-
-if (!parent_is_class) {
-/* we append one attribute to hold the PMC */
-Parrot_add_attribute(interp, child_class,
-CONST_STRING(interp, "__value"));
-/*
- * then create a vtable derived from ParrotObject and
- * deleg_pmc - the ParrotObject vtable is already built
- */
-create_deleg_pmc_vtable(interp, child_class, 1);
-}
-else {
-/*
- * if any parent isa PMC, then still individual vtables might
- * be overridden in this subclass
- */
-int i;
-int any_pmc_parent = 0;
-const int n = VTABLE_elements(interp, mro);
-
-/* 0 = this, 1 = parent (handled above), 2 = grandpa */
-for (i = 2; i < n; ++i) {
-const PMC * const parent = VTABLE_get_pmc_keyed_int(interp, mro, i);
-if (!PObj_is_class_TEST(parent)) {
-any_pmc_parent = 1;
-break;
-}
-}
-if (any_pmc_parent)
-create_deleg_pmc_vtable(interp, child_class, 0);
-}
-
-return child_class;
-}
-
-
-/*
-
=item C
Looks for the class named C and returns it if it exists.
@@ -1798,59 +1688,6 @@
}
-/*
-
-=item C
-
-Adds the attribute C to the class.
-
- Life is ever so much easier if a class keeps its attributes at the
- end of the attribute array, since we don't have to insert and
- reorder attributes. Inserting's no big deal, especially since we're
- going to break horribly if you insert into a class that's been
- subclassed, but it'll do for now.
-
-=cut
-
-*/
-
-PARROT_API
-INTVAL
-Parrot_add_attribute(PARROT_INTERP, ARGIN(PMC *_class), ARGIN(STRING *attr))
-{
-STRING *full_attr_name;
-SLOTTYPE * const class_array = (SLOTTYPE *)PMC_data(_class);
-STRING * const class_name = VTABL
Re: [perl #45989] [TODO] [PATCH] Escape the NULL character within Parrot_add_attribute()
On Wednesday 07 May 2008 11:54:31 NotFound wrote: > According a discussion in #parrot this function and some related parts > is dead code. The attached patch removes it. Thanks, applied as r27377. -- c
Re: [perl #53270] [TODO] Rename/refactor _handle_mswin32()
On Sat, Apr 26, 2008 at 10:15:05AM -0700, James Keenan via RT wrote: > On Sat Apr 26 09:37:06 2008, geoff wrote: > > On Sat, 2008-04-26 at 09:25 -0700, James Keenan via RT wrote: > > > > +are to be added. Wordspace-delimited string. > > > > Did you mean "Whitespace-delimited"? > > No, because I don't want people adding tabs here. > > But would 'single whitespace' be more clear? I would prefer the phrase "space delimited string" since a tab character could be a single whitespace? > Thanks for taking a look at this. > > kid51 Bob
[perl #53270] [TODO] Rename/refactor _handle_mswin32()
On Wed May 07 13:45:37 2008, [EMAIL PROTECTED] wrote: > > I would prefer the phrase "space delimited string" since a tab > character could be a single whitespace? > Cf. http://svn.perl.org/parrot/trunk/lib/Parrot/Configure/Step/Methods.pm What ultimately was committed to trunk was: "Single whitespace-delimited string." -- in 4 locations. Since the ticket was resolved a week ago and there have been no other complaints, my inclination is to let things stand as they are. If one of the meta-committers feels the documentation is unsatisfactory, she/he can change it. Thanks for taking a look at this. kid51
[perl #45975] [TODO] [PATCH] Make Parrot_single_subclass() threadsafe
> In src/objects.c:Parrot_single_subclass() there is the todo item:
>
> /* XXX not really threadsafe but good enough for now */
>
> This needs to be made threadsafe.
This ticket can be closed, as Parrot_single_subclass was dead code and
has been removed.
Looking a this, I discovered that the subclass function in default.pmc
contains a call to Parrot_single_subclass, but this function is not
present in default.c and there is no error nor warning about that
fact. Is this a behavior expected?
Anyway, the attached patch removes it.
--
Salu2
Index: src/pmc/default.pmc
===
--- src/pmc/default.pmc (revisión: 27383)
+++ src/pmc/default.pmc (copia de trabajo)
@@ -981,21 +981,6 @@
/*
-
-=item C
-
-Creates a subclass, optionally with a given C.
-
-=cut
-
-*/
-
-PMC *subclass(PMC *name) {
-return Parrot_single_subclass(INTERP, SELF, name);
-}
-
-/*
-
=item C
Returns SELF. A PMC is its own class.
Re: [perl #45975] [TODO] [PATCH] Make Parrot_single_subclass() threadsafe
NotFound wrote: Looking a this, I discovered that the subclass function in default.pmc contains a call to Parrot_single_subclass, but this function is not present in default.c and there is no error nor warning about that fact. Is this a behavior expected? Anyway, the attached patch removes it. It should be removed, since the subclass v-table method was removed. Haven't got time to do it myself right now, but this patch can be applied by whoever gets chance. Thanks, Jonathan
[perl #53606] [TODO] pge - change syntax of <.foo: arg> subrule calls
Fixed in r27384, closing ticket. Pm
[perl #53834] [TODO] modify pge subrule parsing
As of r27389 most of the above changes are made, except that we can't yet switch (zero-width assertion) because there are still a number of languages and/or tools that are using as the non-capturing syntax. For now I've listed the syntax as deprecated and we can switch it immediately following the next release. I've also added a note to DEPRECATED.pod . Thanks! Pm
[perl #45975] [TODO] Make Parrot_single_subclass() threadsafe
On Wed May 07 16:53:11 2008, [EMAIL PROTECTED] wrote: > Thanks, applied as r27388. (Hitting the list with this thanks message. Thanks!)
[perl #53418] mk_language_shell.pl does not create folders outside of the language folder
Fixed in r27390. The step for automatically creating the makefile only works for things in the languages/ subdirectory, so I modified mk_languages_shell.pl to only attempt the reconfigure if a path wasn't given. Thanks, Pm
[perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Sun Apr 20 19:01:44 2008, [EMAIL PROTECTED] wrote: > > I would like to propose both short-term and long-term remedies. > > Short-term: If you are proposing a new configuration step, or doing > a significant overhaul of any existing step, please post an RT with > the code and with a [TODO] tag several days ahead of time. This will > give people a chance to run it on different OSes right away, without > compromising trunk. And if I get advance notice of any new config > step, I pledge to work with you to develop tests for that step. > Since I filed this RT, two completely new configuration step classes have been added -- neither of which was preceded by an RT. So it is evident that the committers do not like this suggestion. > Long-term: We need a Parrot design document on configuration. Such > a document should cover what configuration is, why we have decided to > include the configuration steps already there, what we need and what > we don't need. Such a document should distinguish between what we > need between now and 1.0 OTOH and post-1.0 OTO. > There has been no support for this suggestion from the key people. So I am withdrawing this ticket and classifying it as rejected. kid51
Re: This week on parrot?
On May 5, 2008, Andy Lester wrote: > On May 5, 2008, at 10:23 AM, Eric Wilhelm wrote: > > Lurkers (potential contributors.) Posting it on use.perl.org (and/or > > various other feed sources) would reach more of us. > > But do those lurkers actually exist? My gut says no. My gut says > that the people who would be interested in a summary are already on > the list. I'm a lurker (or was...), I'm on the list, but don't find the time to read it most of the time so a (bi?)weekly review would be nice. > I guess what I'd really like to see would be something aimed higher > than the p5p summaries are. It'd be something that could be > interesting to a wider range of readers, not just the people who care > about the nitty gritty of PGE/PIR/whatever. "This fabulous technology > brings is this much closer to Rakudo being reality." > > -- > Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance -- Thomas Fjellstrom [EMAIL PROTECTED]
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On Wed, 2008-05-07 at 18:22 -0700, James Keenan via RT wrote: > On Sun Apr 20 19:01:44 2008, [EMAIL PROTECTED] wrote: > > > > I would like to propose both short-term and long-term remedies. > > > > Short-term: If you are proposing a new configuration step, or doing > > a significant overhaul of any existing step, please post an RT with > > the code and with a [TODO] tag several days ahead of time. This will > > give people a chance to run it on different OSes right away, without > > compromising trunk. And if I get advance notice of any new config > > step, I pledge to work with you to develop tests for that step. > > > > Since I filed this RT, two completely new configuration step classes > have been added -- neither of which was preceded by an RT. So it is > evident that the committers do not like this suggestion. I hope that you are not referring to config/gen/call_list here -- I definitely tried to follow your request. I created my patch only after specifically asking you for anything you wanted from a new config step. I then posted my patch to RT to create the new step a week and a half ago, and responded quickly to objections. Then I waited until yesterday before beginning to pester chromatic (since he had done the main review) to accept or reject. He asked for changes, I submitted a new patch to his specs, and he then accepted and committed the change. Total time between RT and commit: over 9 days. > > Long-term: We need a Parrot design document on configuration. Such > > a document should cover what configuration is, why we have decided to > > include the configuration steps already there, what we need and what > > we don't need. Such a document should distinguish between what we > > need between now and 1.0 OTOH and post-1.0 OTO. > > There has been no support for this suggestion from the key people. I know I don't qualify as "key people" (not being a committer), but I and others agreed such a document would be a good thing. > So I am withdrawing this ticket and classifying it as rejected. I think Warnock applies, rather than assuming you got -1 from all voters. -'f
