Re: [perl #53990] [CAGE] [PATCH] warnings in compilers/imcc/optimizer.c
I have seen now that the functions if'ed out by DO_LOOP_OPTIMIZATION are mentioned and proposed for deletion in #46291, this ticket can be merged with him or closed. -- Salu2
Re: [perl #45993] [TODO] Check parent class attribute additions when child class attributes already exist
> In src/objects.c:Parrot_add_attribute() there is the todo item: This function was dead code and has been deleted in #45989 / * TODO check if someone is trying to add attributes to a parent class * while there are already child class attrs */ The checks are in add_parent on the class pmc. The ticket can be closed. -- Salu2
Re: [perl #45977] [TODO] Create all class structures in constant PMC pool
On Tue, Oct 2, 2007 at 7:47 PM, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote: > In src/objects.c:Parrot_new_class() there is the todo item: > > /* TODO create all class structures in constant PMC pool */ This function no longer exists. Looks like class creation now is done by calling pmc_new_init_src. -- Salu2
Re: [perl #45969] [TODO] fail_if_exist() uses global class registry
On Tue, Oct 2, 2007 at 7:43 PM, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote: > In src/objects.c fail_if_exist() has the todo item: > XXX uses global class registry > I'm guessing by this comment that it shouldn't? This function no longer exists. -- Salu2
Re: [perl #45971] [TODO] Get printable name for real_exception() in fail_if_exist()
On Tue, Oct 2, 2007 at 7:44 PM, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote: > In src/objects.c there is the todo item within fail_if_exist(): > /* TODO get printable name */ This function no longer exists. -- Salu2
[perl #54182] [PATCH] languages/PIR build failures
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #54182]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54182 >
Attached patch fixes the syntax errors that prevent languages/PIR to
build in r27508.
Still the tests don't work, it seems partly because 'make' generates a
file pirc.pbc while the test harness expects a file pir.pbc.
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Index: languages/PIR/src/pir.pg
===
--- languages/PIR/src/pir.pg (revision 27508)
+++ languages/PIR/src/pir.pg (working copy)
@@ -624,11 +624,11 @@
}
token stringsingle {
-\' \'
+\' \'
}
token stringdouble {
-'"' '"'
+'"' '"'
}
token type {
Index: languages/PIR/src/pasm/pasm_args.pg
===
--- languages/PIR/src/pasm/pasm_args.pg (revision 27508)
+++ languages/PIR/src/pasm/pasm_args.pg (working copy)
@@ -34,18 +34,18 @@
rule arg_exp_exp_lab {
- [ \, | ]
+ [ \, | ]
- [ \, | ]
+ [ \, | ]
}
rule isXX_args {
- [ | ]
- [ \, | ]
- [ | ]
- [ \,| ]
- [ | ]
+ [ | ]
+ [ ',' | ]
+ [ | ]
+ [ ',' | ]
+ [ | ]
}
rule arg_get_params {
@@ -53,12 +53,12 @@
}
rule param_flag_list {
- [ \" | \' | ]
- [ \( | ]
+ [ \" | \' | ]
+ [ \( | ]
?
- [ \) | ]
- [ \" | \' | ]
- [ \, | ]
+ [ \) | ]
+ [ \" | \' | ]
+ [ \, | ]
}
rule arg_pmc_var_list {
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
"John M. Dlugosz" wrote: > Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote: > > Pm (>): > > > > > In Rakudo's case, we just haven't implemented read-only traits > > > on variables yet. > >> > > > > Goodie. I guessed as much. > > > > > >> But yes, I expect that it will be caught as > > > a compile-time error. > >> > > > > And do you agree it's reasonable to expect this of every compiler? > > > > // Carl > > > > > I think that is the point of declared types. But, something like > > no strong_type_check :rw > > in scope can turn that off, in case you want to play dirty tricks. What is the point of be able to mark things readonly if the compiler does reject assignment attempts? What is the point of marking things readonly if you can turn it off? --
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
"Me Here" (>), John (>>), Carl (>>>), Patrick (): >> >> But yes, I expect that it will be caught as >> > > a compile-time error. >> >> >> > >> > And do you agree it's reasonable to expect this of every compiler? >> >> I think that is the point of declared types. But, something like >> >> no strong_type_check :rw >> >> in scope can turn that off, in case you want to play dirty tricks. > > What is the point of be able to mark things readonly if the compiler > does reject assignment attempts? Oh, as long as you predeclare that you're breaking the rules, I'm fine. We're not making stuff impossible just for the heck of it -- this isn't Java. > What is the point of marking things readonly if you can turn it off? There are many possible reasons, I think. * The code that declares the variable readonly might not be available to you (compiled to bytecode, fetched by RCP etc), * or it might be available but used by other clients which expect the variable to be read-only. * You might be writing a one-time hack, which can be done the easy way by turning off read-only checking. * You might be writing test code, which is greatly simplified by your just reaching in an changing the damn thing. In short, I have no problem with _turning off_ read-only checking. That, I think, can be done on a suit-yourself basis. I'm arguing for _having_ read-only checking at compile level (which everyone seemingly agrees on), and spec-requiring of a compiler to check this (and here opinions divide). // Carl
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
On 2008 May 15, at 1:30, Me Here wrote: "John M. Dlugosz" wrote: no strong_type_check :rw in scope can turn that off, in case you want to play dirty tricks. What is the point of be able to mark things readonly if the compiler does reject assignment attempts? (assuming you meant "doesn't") What is the point of marking things readonly if you can turn it off? Documentation. Backward type-API compatibility. I am unsure at this point if this applies to Perl 6, but in Haskell it is possible to do in-place update by diving into IO behind the scenes with (read-only by default) data structures. In this case "is ro" would be a reminder that the caller has expectations that you must be careful not to violate while you're working behind the curtain. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
[perl #45969] [TODO] fail_if_exist() uses global class registry
On Thu May 15 01:17:26 2008, [EMAIL PROTECTED] wrote: > On Tue, Oct 2, 2007 at 7:43 PM, via RT Paul Cochrane > <[EMAIL PROTECTED]> wrote: > > > In src/objects.c fail_if_exist() has the todo item: > > XXX uses global class registry > > I'm guessing by this comment that it shouldn't? > > This function no longer exists. > Good catch, closing ticket.
Custom vtables in objects
PDD15 says: : =item - Objects may have a custom vtable or use a class-wide vtable. How does one do this? Also, at one time it was mentioned that we would have a way to add roles to individual objects -- is that still on the table? Pm
[perl #45977] [TODO] Create all class structures in constant PMC pool
Closed.
[perl #45971] [TODO] Get printable name for real_exception() in fail_if_exist()
Closed.
Re: [perl #46895] [TODO] [Pir/C] Investigate and correct incorrect recursion depth counting in debug backtrace
On Thu, Oct 25, 2007 at 5:28 PM, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote: > # XXX > # in plain functional run-loop result is 999 > # other run-loops report 998 > # TODO investigate this after interpreter strtup is done > # see also TODO in src/embed.c I can't reproduce the problem, and looking at the revisions of src/embed.c around the date of this ticket I don't see any TODO related. -- Salu2
Re: [perl #54220] AutoReply: [BUG] Segfault when iterating a namespace
I said: > The attached short PIR program shows the problem -- parrot segfaults on > the first shift operation when iterating over a namespace. It turns out that the namespace was a red herring. The real problem is that when iterating over a hash, you cannot assign to a PMC register; it must be a string register. So if the base collection is a hash, this segfaults: $P0 = shift iterator But this works fine: $S0 = shift iterator Of course, segfaulting is still *bad*, so this ticket should remain open and switch focus to the real problem. -'f
[perl #54220] [BUG] Segfault when iterating a namespace
# New Ticket Created by Geoffrey Broadwell # Please include the string: [perl #54220] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=54220 > The attached short PIR program shows the problem -- parrot segfaults on the first shift operation when iterating over a namespace. -'f # The following test program segfaults when attempting to iterate: # # $ ./parrot namespace_iter.pir # Symbols found: 81 # Segfaults on next line ... # Segmentation fault .sub main :main .local pmc my_namespace my_namespace = get_namespace .local int num_symbols num_symbols = elements my_namespace print 'Symbols found: ' print num_symbols print "\n" .local pmc iterator, symbol iterator = new 'Iterator', my_namespace iter_loop: unless iterator goto iter_end print "Segfaults on next line ...\n" symbol = shift iterator print "Never reached!\n" print symbol print "\n" goto iter_loop iter_end: .end
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
"Carl Mäsak" wrote: > > What is the point of marking things readonly if you can turn it off? > > There are many possible reasons, I think. > > * The code that declares the variable readonly might not be available > to you (compiled to bytecode, fetched by RCP etc), > * or it might be available but used by other clients which expect the > variable to be read-only. > * You might be writing a one-time hack, which can be done the easy way > by turning off read-only checking. > * You might be writing test code, which is greatly simplified by your > just reaching in an changing the damn thing. > > In short, I have no problem with _turning off_ read-only checking. > That, I think, can be done on a suit-yourself basis. > > I'm arguing for having read-only checking at compile level (which > everyone seemingly agrees on), and spec-requiring of a compiler to > check this (and here opinions divide). > > // Carl And that pretty much sums up about half of the traffic on this list. Speculative considerations of theoretically possible scenarios without any consideration of whether they would ever actually arise. Or be useful if they did. The result is a spec so complex that there is almost no chance of verification against it, even if enough people understand the intersection between all the speculative what-ifs and the few more concrete 'will's and 'must be's, to actually come close to implementing it. Perl made it's name by adopting the useful, pragmatic parts of other languages, and leaving out all the abstract, purely theoretical and only useful to one-legged, six-fingered theologians on wet Wednesdays in October. Sometimes it's a good idea to return to the beginning and ask yourself why do we want this feature in the first place. What does adding the ability to mark variables or parameters RO by the programmer using the language? In Perl 5, people are beginning to jump through hoops in order to achieve encapsulation that cannot be subverted. Giving module/subroutine users the ability to ignore the authors mutability annotations makes them worthless. What does adding the default assumption that subroutine or method parameters are RO buy the language implementor? This provision could be used my the language implementor to achieve some extra level of efficiency by allowing them to hoist RO values into registers; avoid locking of RO values in threaded environments; perform compile-time constant folding and expression substitutions (term-rewriting); and similar. The moment you allow the RO annotations to be overridden at either compile-time or runtime, those optimisations go out the window. In other words, if you allow RO annotations to be overridden, all the benefits that could accrue from having them go out the window, so you might as well simplify everyones life and discard them all together. Now maybe that's the way to go. Historically, the few places where the readonly attribute is applied in Perl 5 it tends to create anomalies and rarely improves performance. But if you are serious about providing the facility, don't go screwing it up for the benefit of the six guys in the world that could count their number on one hand, on one of four days a year when the sun might shine anyway. b. --
[perl #54230] [BUG] [PATCH] Loops in class hierarchies
# New Ticket Created by NotFound
# Please include the string: [perl #54230]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54230 >
Hello.
Parrot lacks loop avoidance in class hierarchy. This examples segfaults:
.sub main
$P1 = newclass 'Foo'
addparent $P1, $P1
.end
.sub main
$P1 = newclass 'Foo'
$P2 = newclass 'Bar'
addparent $P1, $P2
addparent $P2, $P1
.end
The attached patch modifies add_parent in class, checking that the new
parent is not self, and that none of his parents is.
It checks the complete list of parents to work the same way even on
override of isa. The intention is to avoid the fault in MRO, not to
forbid experiments with inheritance.
No tests yet, this patch is for evaluation and discussion.
--
Salu2
Index: src/pmc/class.pmc
===
--- src/pmc/class.pmc (revisión: 27516)
+++ src/pmc/class.pmc (copia de trabajo)
@@ -729,7 +729,7 @@
STRING * const parent_name = VTABLE_get_string(interp, parent);
/* get number of direct parents */
-const int parent_count = VTABLE_elements(interp, _class->parents);
+int parent_count = VTABLE_elements(interp, _class->parents);
int index; /* loop iterator */
@@ -744,6 +744,9 @@
real_exception(interp, NULL, E_TypeError, "Parent isn't a Class.");
return;
}
+/* Check is not self */
+if (parent == SELF)
+real_exception(interp, NULL, E_TypeError, "Can't be own parent");
/* iterate over all direct parents, check whether this class already has
* the parent being added.
@@ -768,6 +771,19 @@
}
+/* Check that none of the parents is self */
+parent_count = VTABLE_elements(interp,
+PARROT_CLASS(parent)->all_parents);
+for (index = 0; index < parent_count; index++) {
+/* get the next parent */
+PMC * const current_parent = VTABLE_get_pmc_keyed_int(interp,
+PARROT_CLASS(parent)->all_parents, index);
+if (current_parent == SELF)
+real_exception(interp, NULL, E_TypeError,
+"Loop in class hierarchy: '%S' is an ancestor of '%S'.",
+VTABLE_get_string(interp, SELF),
+VTABLE_get_string(interp, parent));
+}
/* Add to the lists of our immediate parents and all parents. */
VTABLE_push_pmc(interp, _class->parents, parent);
Re: duplicate symbols
On Sunday 02 September 2007 10:37:13 Jeff Horwitz wrote: > not surprisingly, it looks like some symbols in libparrot conflict with > exported symbols from other libraries. i ran into this when testing > mod_parrot on an apache server with PHP 5 configured: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1077226080 (LWP 9187)] > 0x4065c4a4 in list_length () from /usr/local/apache2/modules/libphp5.so > (gdb) bt > #0 0x4065c4a4 in list_length () from > /usr/local/apache2/modules/libphp5.so > #1 0x40b7f47a in visit_loop_todo_list (interp=0x825c488, current=0x0, > info=0xb4e0) at src/pmc_freeze.c:1426 > #2 0x40b7f781 in run_thaw (interp=0x825c488, image=0x840978c, > what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1554 > #3 0x40b7f9c6 in Parrot_thaw (interp=0x825c488, image=0x840978c) > at src/pmc_freeze.c:1663 > > [snip] > > obviously parrot is looking for src/list.c:list_length, but instead gets > PHP5's list_length, which is already loaded into apache. i'm sure this > problem exists for other functions -- any ideas for how to address this? > we could prepend a Parrot_ prefix for the PARROT_API functions (which > list_length is), but that may not be appropriate for all situations. I see no reason anything in src/list.c needs PARROT_API. Any objections? -- c
[perl #54236] [TODO] Allow Parrot Hashes to have PMC keys
# New Ticket Created by Geoffrey Broadwell # Please include the string: [perl #54236] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=54236 > As seen in 54220, I discovered to my chagrin that not only do Parrot hashes have only string keys, that trying to pull the keys out as PMCs (presumably Strings) fails. Aside from the ugly failure, this design seems broken in the face of languages like Perl6 that expect to be able to use non-string hash keys. Both for direct use by Perl6 internals, and for interoperability with other languages, it seems like at least one core Parrot hash class should use PMC keys. These should be either readable directly as PMCs, or stringified if assigned to a string register. (This latter case may be optimized if the key PMC is a String, of course, but that's a different issue). This ticket can be considered in some sense the converse of 54220. That ticket asks that ordinary string keys be extractable as String PMCs, whereas this one asks that general PMC keys work, and that they stringify if extracted as ordinary strings. -'f
Re: "All classes imply the existence of a role of the same name."
Overloading "final" was Java's rather inept attempt to define objects with value semantics rather than container semantics Can you tell me more about that, or point to something?
