Re: [perl #24683] [PATCH] P6C update concat and bitwise operators
Allison Randal [EMAIL PROTECTED] wrote: This patch updates the following operators and their assignment counterparts: Applied, thanks. I've added two test files, bitwise.t and concat.t, which go in t/op/ (the op/ directory doesn't exist yet) Missing? leo
[DEV] helgrind
FYI on i386/linux a part of valgrind should be able to help debug multi-threading programs: $ valgrind --skin=helgrind parrot t.pasm [ ... ] ==26713== Possible data race reading variable at 0x4141F8B0 ==26713==at 0x80CDCCE: runops_slow_core (src/runops_cores.c:115) That one is obviously ok (different threads are reading the ops image). But there are a lot of other possible races mainly in interpreter destruction, which I didn't look at yet. leo
[perl #24696] The Lowest Prices Anywhere!
# New Ticket Created by Van McGinnis # Please include the string: [perl #24696] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=24696
Re: Segfault in extend.c/ parrot_pmc_get_pointer
On Monday, December 15, 2003, at 12:58 pm, Leopold Toetsch wrote:
Arthur Bergman [EMAIL PROTECTED] wrote:
#0 0x081cef45 in Parrot_PMC_get_pointer (interp=0x82d7f78,
pmc=0x8a0)
That looks like the vtable could be corrupted.
$ p *pmc
$ p *pmc-vtable
So, after a couple of days struggling to find a lost off64_t I am able
to try again, (plus side is, I now build a threaded perl to make it
work (otherwise nasty IO problems hit me)).
So the result.
Most likely,
(gdb) p *pmc
$2 = {obj = {u = {b = {bufstart = 0x4212dfd8, buflen = 137797904}, ptrs
= {_struct_val = 0x4212dfd8, _pmc_val = 0x836a110},
int_val = 1108533208, num_val = 4.2834352799906154e-269,
string_val = 0x4212dfd8}, flags = 1886221358, pobj_version = 0}, vtable
= 0x18,
pmc_ext = 0x10}
Of course followed by a
(gdb) p *pmc-vtable
Cannot access memory at address 0x18
If it wasn't for pobj_version = 0 I would suggest it was all just
random memory I was looking at.
Any suggestions?
Maybe the PMC got destroyed by a DOD run. You can check that by
disabling DOD after Parrot_new(). (Parrot has a commandline option -G
for this). Also the pmc's flags should reflect that.
I doubt this happens since I never give parrot a chance to do anything,
there is no step that I call into parrot, just
PL_Parrot = Parrot_new(0);
Parrot_init(PL_Parrot);
then a bit later
Parrot_Int type = Parrot_PMC_typenum(PL_Parrot, Perl5LV);
Parrot_PMC_get_pointer(PL_Parrot, SvANY(sv));
Arthur
RE: testing File::Finder
On 18 December 2003 21:44 Randal L. Schwartz wrote: I can add local symlinks and hardlinks. I'll compute ownership out-of-band and compare it to the test result though... I wouldn't want someone extracting this as joebloe to fail because the uid wasn't root. :) Another thing to bear in mind ... is this a Unix-like only module? If not, then symlinks will be a no go. Win32 doesn't support them, and I would imagine there are other OSs in the same position. Computing ownership on Win32 can be done via the Win32::LoginName(), Win32::NetAdmin::LocalGroupGetMembers() and Win32::NetAdmin::GroupGetMembers() functions if you wanted a separate Win32 test script, otherwise as soon as you start calling Unixy admin programs your distribution will likely get labelled (wrongly) under CPAN testing as 'NA' on other OSs. Barbie. -- Barbie (@missbarbell.co.uk) | Birmingham Perl Mongers | http://birmingham.pm.org/
Re: testing File::Finder
Barbie == Barbie [EMAIL PROTECTED] writes: Barbie Another thing to bear in mind ... is this a Unix-like only Barbie module? If not, then symlinks will be a no go. Win32 doesn't Barbie support them, and I would imagine there are other OSs in the Barbie same position. It's not my intention to make this unix-only. It's a wrapper around File::Find, so it should work anywhere File::Find works. I'll look at the way File::Find tests itself for portability guidence. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
but true
I've been trying to follow the recent discussion on roles and properties and
traits and such, but there's something that bugs me. If I understand
correctly, adding a role at runtime using but won't override any methods
defined by the class itself (but it will override inherited methods). But then
if I create a class that has its own method of saying whether it's true or not,
does that mean that but true and but false won't do anything to it?
class Complex {
has $.real;
has $.imag;
...
#Actually, how do we define this?
method asBoolean(Complex $self:){
return $self.real || $self.imag;
}
...
then somewhere in a function
return Complex::new(0,0) but true;
Since Complex already has an implementation of whatever method decides whether
it's true or not, wouldn't just applying a property be insufficient to override
that?
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Where now the horse and the rider? Where is the horn that was blowing?
Where is the helm and the hauberk, and the bright hair flowing?
Where is the hand on the harpstring, and the red fire glowing?
Where is the spring and the harvest and the tall corn growing?
They have passed like rain on the mountain, like a wind in the meadow;
The days have gone down in the West behind the hills into shadow.
Who shall gather the smoke of the dead wood burning,
Or behold the flowing years from the Sea returning?
Re: but true
--- Adam D. Lopresto [EMAIL PROTECTED] wrote:
I've been trying to follow the recent discussion on roles and
properties and traits and such, but there's something that bugs me.
I tried for weeks before I could download the traits paper. I finally
got it this week, and it has clarified some stuff (good and bad).
If I understand correctly, adding a role at runtime using but won't
override any methods defined by the class itself (but it will
override inherited methods).
I think this is (or should be) false.
Traits added to a class cannot conflict (per the paper and $Larry), but
traits added at run-time would be a different category. Larry said
something about dynamic derivation of a singleton class, etc.
But then if I create a class that has its own method of saying
whether it's true or not, does that mean that but true and but
false won't do anything to it?
There's the rub, eh? If you define a trait, say Deaf, that is
intended to supercede normal behavior:
my $Grandma is NicePerson but Deaf;
then it doesn't work. That sort of runtimeness has to be allowed for
somehow.
One way, obviously, is to make run-time and compile-time separate, but
that doesn't work (see prior messages on mod-perl, etc).
Another way is declaration (class) versus dynamic composition
(per-object).
Another way (not orthogonal, btw) would be Larry's notion of declaring
what you intend to screw up.
class Complex {
has $.real;
has $.imag;
...
#Actually, how do we define this?
method asBoolean(Complex $self:){
return $self.real || $self.imag;
}
...
then somewhere in a function
return Complex::new(0,0) but true;
Alternatively, think of the simple properties not as Ctrait
specifications, but as method overrides.
In this case, we're dynamically modifying the method table for the
object (i.e., dynamically creating a class) such that a given method
behaves the way we want:
macro true {
.asBoolean { return 1; }
}
Complex::new(0,0) but true;
becomes
Complex::new(0,0) but .asBoolean { return 1; }
(This is syntactic sugar, not a real macro, because it couldn't handle
the Cif $complex.true form. Maybe a better macro programmer?)
Since Complex already has an implementation of whatever method
decides whether it's true or not, wouldn't just applying a property
be insufficient to override that?
That would be pointless, wouldn't it?
=Austin
Re: but true
--- Austin Hastings [EMAIL PROTECTED] wrote:
--- Adam D. Lopresto [EMAIL PROTECTED] wrote:
#Actually, how do we define this?
method asBoolean(Complex $self:){
return $self.real || $self.imag;
}
...
then somewhere in a function
return Complex::new(0,0) but true;
Alternatively, think of the simple properties not as Ctrait
specifications, but as method overrides.
In this case, we're dynamically modifying the method table for the
object (i.e., dynamically creating a class) such that a given method
behaves the way we want:
macro true {
.asBoolean { return 1; }
}
Complex::new(0,0) but true;
becomes
Complex::new(0,0) but .asBoolean { return 1; }
(This is syntactic sugar, not a real macro, because it couldn't
handle the Cif $complex.true form. Maybe a better macro
programmer?)
Since Complex already has an implementation of whatever method
decides whether it's true or not, wouldn't just applying a property
be insufficient to override that?
That would be pointless, wouldn't it?
Going further, what's Ctrue?
trait Boolean {
requires .value;
method true {+(.value) != 0; }
method false {!?.true}
}
trait true
does Boolean
{
method true { 1; }
method false { 0; }
}
trait true
does Boolean
{
method true { 0; }
method false { 1; }
}
Then:
my $x = 0 but true;
Means
my [ class $_temp0123 is Scalar does true; ] $x = 0;
Of course, when I do:
my $x = 0 but (true|false);
then what happens?
=Austin
Re: but true
On Fri, Dec 19, 2003 at 10:36:01AM -0600, Adam D. Lopresto wrote:
: I've been trying to follow the recent discussion on roles and properties and
: traits and such, but there's something that bugs me. If I understand
: correctly, adding a role at runtime using but won't override any methods
: defined by the class itself (but it will override inherited methods). But then
: if I create a class that has its own method of saying whether it's true or not,
: does that mean that but true and but false won't do anything to it?
:
: class Complex {
: has $.real;
: has $.imag;
:
: ...
:
: #Actually, how do we define this?
: method asBoolean(Complex $self:){
: return $self.real || $self.imag;
: }
:
:
: ...
:
:
: then somewhere in a function
:
: return Complex::new(0,0) but true;
:
: Since Complex already has an implementation of whatever method decides whether
: it's true or not, wouldn't just applying a property be insufficient to override
: that?
That is a problem, and you'll notice I haven't answered Jonathan Lang yet.
That's because I've been thinking about this issue all week, and I haven't
thought of a way around the problem. Which probably means that Cbut
really does imply the derivation of a new class somehow. Which in turn
implies that Cbut is probably not powerful enough yet, because it might
not only bind roles, but also new class methods to control those roles.
Maybe
$x but bar
is just shorthand for something like:
$x but class AnonClass is classof($x) does FooBar[bar] { }
(presuming that bar is an enum of type FooBar).
But it's not clear in that case how you go about caching identical
anonymous classes. Well, okay, all you have to do is memoize
the metaclass's class generator, but still...
Maybe there's an intermediate syntactic form like:
$x but subclass MyClass does FooBar[bar] { }
Or maybe the long form is just
class AnonClass is classof($x) does FooBar[bar] { }.bless($x)
except that actually putting a run-time $x into a compile-time
declaration is a bit of a problem, and it'd be nice to get rid of
the redundant $x. (Plus .bless is maybe gonna try and do things we
don't want done to $x.) On the other hand, if bar is some kind of
BUILD argument rather than a subtype, maybe it's
class AnonClass is classof($x) does FooBar { }.bless($x, foobar = bar)
Maybe with a lazy isa applied by subclass's .bless we can reduce that to:
subclass does FooBar { }.bless($x, foobar = bar)
However we write it, this derivation does do something more like a
slatheron with respect to the original class. However, a single
such slather can apply multiple roles as well as new class methods.
So all the compositional power of roles is still there within that
new class. I guess the real power of roles comes from their parallel
composition into a class, not from being able to apply them one by
one at run time. So what we need to do is make Cbut apply a new
class containing some number of collected and rationalized roles
(usually one). Call it controlled slathering...it lets you use
inheritance for slathering as it should be, while not forcing you
to use extra levels of inheritance to mix in multiple roles when
you should instead be using a composition.
I think I'm happier with that. $rubyometer += 0.3 or so. :-)
Larry
Re: but true
On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote: : Of course, when I do: : : my $x = 0 but (true|false); : : then what happens? That's the problem with making them methods. Any such operational definition is going to get you in trouble. I think I like them better as enums, because then you can have junctions of them functioning as a kind of subtype. Of course, such a junction may well give Parrot hissyfits at a lower level if there's a hardwired boolean bit that Parrot is trying to set and/or unset simultaneously, but that's perhaps a special case. I don't think we'll necessarily see such a bit for boolean, since most built-in types define their truth in terms of their actual value. It's quite a bit more likely that Parrot will get heartburn from: my $x = $*IN but (tainted|untainted); That's because there's likely to be a tainted bit in the PMC somewhere, since taintedness isn't a function of the data itself, but of its source. Larry
Re: but true
On Fri, 19 Dec 2003, Larry Wall wrote: On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote: : Of course, when I do: : : my $x = 0 but (true|false); : : then what happens? That's the problem with making them methods. Any such operational definition is going to get you in trouble. I think I like them better as enums, because then you can have junctions of them functioning as a kind of subtype. Is that thought about just traits, or also about roles? Sometime earlier Larry mentioned that roles could add multimethods, and my worry about that is this: If you simultaneously have a multi method with a signature and another without, given a particular call to this multimethod how do you choose which of the two happens if the signature matches? Disallowing such clashes seems problematic because it may mean that if the class writer used types and signatures these get forced onto the user of the class. --Abhijit
Re: but true
Abhijit A. Mahabal writes: On Fri, 19 Dec 2003, Larry Wall wrote: On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote: : Of course, when I do: : : my $x = 0 but (true|false); : : then what happens? That's the problem with making them methods. Any such operational definition is going to get you in trouble. I think I like them better as enums, because then you can have junctions of them functioning as a kind of subtype. Is that thought about just traits, or also about roles? Neither. It's just about roles. We're having another vocabulary conflict; refer to the vocabulary doc. Sometime earlier Larry mentioned that roles could add multimethods, and my worry about that is this: If you simultaneously have a multi method with a signature and another without, given a particular call to this multimethod how do you choose which of the two happens if the signature matches? Probably the same way you disambiguate when normal multimethods abound. The more specific signature wins, if it matches. Though I do see how this might introduce subtle bugs. I'm a big fan of method name-only equivalence, so I would argue that it overrides (or subsides if it isn't being slathered on), but then I don't have experience with large-scale projects. Disallowing such clashes seems problematic because it may mean that if the class writer used types and signatures these get forced onto the user of the class. Everybody's going to be using signatures, though! (Types are a different story) Yeah, the typeless one would win, I think, unless the type happens to be Any. Luke
Re: Object Order of Precedence (Was: Vocabulary)
On Mon, Dec 15, 2003 at 07:02:53PM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: Jonathan Lang wrote:
: : Let's see if I've got this straight:
: :
: : role methods supercede inherited methods;
:
: But can defer via SUPER::
:
: : class methods supercede role methods;
:
: But can defer via ROLE:: or some such.
:
: Check, and check. Of course, SUPER:: works well in single inheritence,
: but runs into problems of which superclass? in multi-inheritence; ROLE::
: would on the surface appear to have that same problem, except that...
:
: : conflicting methods from multiple roles get discarded...
:
: They aren't silently discarded--they throw a very public exception.
: (But methods with differing multi signatures are not considered to
: be conflicting, I hope.)
:
: (OK.)
Also, there will be access to the list of call candidates for SUPER::
(and presumably ROLE::) such that the class's method can get explicit
control of which super/role method or methods get called. So we can
have methods that fail-over to the next candidate. It's just not the
default way to resolve multiple methods with the same signature.
: : ...but the class may alias or exclude any of the conflicting methods
: : to explicitly resolve the dispute.
:
: Right. Another possibility is that the class's method could be
: declared to be the default multi method in case the type information
: is not sufficient to decide which role's multi method should be called.
: Maybe if it's declared multi it works that way. Otherwise it's just
: called first automatically.
:
: ...meaning that the question of which role do you mean? has already been
: addressed by the time the ROLE:: deference gets used.
No, in this case the ROLE:: deference has already given up on finding
a unique role to call, and called the class's method to break the tie,
or do something really generic, or call more than one of the role methods,
or die.
: Although I'm not following what you're saying here in terms of the third
: means of disambiguation. Could someone provide an example, please?
role Pet {
method feed (PetFood $x) {...}
}
role Predator {
method feed (PredatorFood $x) {...}
}
class DangerousPet does Pet does Predator {
}
If DangerousPet
doesn't define a feed method at all, then we might dispatch to Pet and
Predator as if their methods had an implicit multi. But maybe the
actual type of $x is sufficiently ambiguous that we can't decide whether
it's more like PetFood or PredatorFood. In that case it would throw
an exception, just as any multimethod without a default would. If you
define an ordinary method in DangerousPet:
class DangerousPet does Pet does Predator {
method feed ($x) {...}
}
then you have the ordinary case. DangerousPet::feed is always called
because the class method overrides the role methods. Presumably the
class method can dispatch to the role methods if it so chooses. But
if you say something like:
class DangerousPet does Pet does Predator {
multi method feed ($x) {...}
}
then DangerousPet::feed is called only when multimethod dispatch
would have thrown an exception. Alternately, multi's will probably have
some way of identifying the default method in any case, so maybe you
have to write it something like this:
class DangerousPet does Pet does Predator {
multi method feed ($x) is default {...}
}
that leaves the door open for real multi's within the class working
in parallel to the roles' methods:
class DangerousPet does Pet does Predator {
multi method feed ($x) is default {...}
multi method feed (DangerousPetFood $x) {...}
}
Arguably, the role's might be required to declare their methods multi
if they want to participate in this, but that's one of those things
that feel like they ought to be declared by the user rather than the
definer. On the other hand, maybe a role would feel that its method
*must* be unique, and leaving out the multi is the way to do that.
But I hate to get into the trap of culturally requiring every method
in every role to specify multi. It's a little too much like the C++
ubiquitous-const problem.
: : trait methods supercede class methods;
:
: I'm not sure traits work that way. I see them more as changing the
: metaclass rules. They feel more like macros to me, where anything
: goes, but you have to be a bit explicit and intentional.
:
: Well, the question is: the trait is providing a method with the same name
: as a method provided by the class, and type information is insufficient to
: distinguish between them; which one do I use? In the absence of
: additional conflict resolution code, the possible options as I see them
: would be:
:
: 1) the class supercedes the trait
: 2) the trait supercedes the class
: 3) an ambiguity exception gets thrown
: 4) the trait's method can't be called without explicitly naming the trait
:
: Which of these
Re: Segfault in extend.c/ parrot_pmc_get_pointer
Arthur Bergman [EMAIL PROTECTED] wrote:
On Monday, December 15, 2003, at 12:58 pm, Leopold Toetsch wrote:
(gdb) p *pmc
$2 = {obj = {u = {b = {bufstart = 0x4212dfd8, buflen = 137797904}, ptrs
= {_struct_val = 0x4212dfd8, _pmc_val = 0x836a110},
int_val = 1108533208, num_val = 4.2834352799906154e-269,
string_val = 0x4212dfd8}, flags = 1886221358, pobj_version = 0}, vtable
= 0x18,
pmc_ext = 0x10}
Doesn't look like a PMC on the free_list to me, seems to be garbage.
I doubt this happens since I never give parrot a chance to do anything,
there is no step that I call into parrot, just
Parrot_Int type = Parrot_PMC_typenum(PL_Parrot, Perl5LV);
Parrot_PMC_get_pointer(PL_Parrot, SvANY(sv));
How do you create/initialize the PMC* SvANY(sv)?
Arthur
leo
[perl #24700] We have what you need - Cheapest p[rescriptions on the internet
# New Ticket Created by April Conner # Please include the string: [perl #24700] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=24700
[perl #24701] [PATCH] Build core_ops.c etc in ops dir instead of src
# New Ticket Created by Jrgen Bmmels
# Please include the string: [perl #24701]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=24701
Hi,
the *.ops files are lying in the ops/ directory, but the generated
c-files go to the src/ directory. This is completly different from
classes/, imcc/ etc. where the generated c-files go to the same
directory. Is this difference intentional?
Otherwise does the attached patch creates the core_ops.[co] etc. in
the ops/directory.
bye
b
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.175
diff -u -r1.175 root.in
--- config/gen/makefiles/root.in 18 Dec 2003 12:20:30 - 1.175
+++ config/gen/makefiles/root.in 19 Dec 2003 16:31:50 -
@@ -233,9 +233,6 @@
$(SRC)/global_setup$(O) \
$(SRC)/interpreter$(O) \
$(SRC)/register$(O) \
-$(SRC)/core_ops$(O) \
-$(SRC)/core_ops_prederef$(O) \
-$(SRC)/core_ops_switch$(O) \
$(SRC)/memory$(O) \
$(SRC)/objects$(O) \
$(SRC)/packfile$(O) \
@@ -283,6 +280,9 @@
$(SRC)/mmd$(O) \
$(SRC)/extend$(O) \
pf/pf_items$(O) \
+$(OPS)/core_ops$(O) \
+$(OPS)/core_ops_prederef$(O) \
+$(OPS)/core_ops_switch$(O) \
${asmfun_o} \
${cg_o} \
${exec_o} \
@@ -726,8 +726,6 @@
$(SRC)/embed$(O) : $(GENERAL_H_FILES) $(INC)/debug.h
-$(SRC)/core_ops$(O) : $(GENERAL_H_FILES) $(SRC)/core_ops.c
-
$(SRC)/dataypes$(O) : $(GENERAL_H_FILES) $(SRC)/dataypes.c
$(SRC)/exit$(O) : $(GENERAL_H_FILES) $(SRC)/exit.c
@@ -741,33 +739,35 @@
$(SRC)/nci.c : $(SRC)/call_list.txt $(BUILD_TOOL)/build_nativecall.pl
$(PERL) $(BUILD_TOOL)/build_nativecall.pl $(SRC)/call_list.txt
+$(SRC)/warnings$(O) : $(GENERAL_H_FILES)
+
+$(SRC)/misc$(O) : $(GENERAL_H_FILES)
+
+$(SRC)/utils$(O) : $(GENERAL_H_FILES)
+
+$(SRC)/spf_render$(O) : $(GENERAL_H_FILES)
+
+$(SRC)/spf_vtable$(O) : $(GENERAL_H_FILES)
+
+$(OPS)/core_ops$(O) : $(GENERAL_H_FILES) $(OPS)/core_ops.c
+
#core_ops depends upon config.h so that it gets updated along with updates to config.h's version numbers
-$(SRC)/core_ops.c $(INC)/oplib/core_ops.h : $(OPS_FILES) $(BUILD_TOOL)/ops2c.pl lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(INC)/config.h lib/Parrot/OpLib/core.pm
+$(OPS)/core_ops.c $(INC)/oplib/core_ops.h : $(OPS_FILES) $(BUILD_TOOL)/ops2c.pl lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(INC)/config.h lib/Parrot/OpLib/core.pm
$(PERL) $(BUILD_TOOL)/ops2c.pl C --core
-$(SRC)/core_ops_prederef$(O) : $(GENERAL_H_FILES) $(SRC)/core_ops_prederef.c
+$(OPS)/core_ops_prederef$(O) : $(GENERAL_H_FILES) $(OPS)/core_ops_prederef.c
-$(SRC)/core_ops_prederef.c $(INC)/oplib/core_ops_prederef.h : $(OPS_FILES) $(BUILD_TOOL)/ops2c.pl lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(INC)/config.h lib/Parrot/OpLib/core.pm
+$(OPS)/core_ops_prederef.c $(INC)/oplib/core_ops_prederef.h : $(OPS_FILES) $(BUILD_TOOL)/ops2c.pl lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(INC)/config.h lib/Parrot/OpLib/core.pm
$(PERL) $(BUILD_TOOL)/ops2c.pl CPrederef --core
-$(SRC)/core_ops_switch$(O) : $(GENERAL_H_FILES) $(SRC)/core_ops_switch.c
+$(OPS)/core_ops_switch$(O) : $(GENERAL_H_FILES) $(OPS)/core_ops_switch.c
-$(SRC)/core_ops_switch.c $(INC)/oplib/core_ops_switch.h : $(OPS_FILES) $(BUILD_TOOL)/ops2c.pl lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(INC)/config.h lib/Parrot/OpLib/core.pm
+$(OPS)/core_ops_switch.c $(INC)/oplib/core_ops_switch.h : $(OPS_FILES) $(BUILD_TOOL)/ops2c.pl lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(INC)/config.h lib/Parrot/OpLib/core.pm
$(PERL) $(BUILD_TOOL)/ops2c.pl CSwitch --core
${cg_c}
${gc_c}
-
-$(SRC)/warnings$(O) : $(GENERAL_H_FILES)
-
-$(SRC)/misc$(O) : $(GENERAL_H_FILES)
-
-$(SRC)/utils$(O) : $(GENERAL_H_FILES)
-
-$(SRC)/spf_render$(O) : $(GENERAL_H_FILES)
-
-$(SRC)/spf_vtable$(O) : $(GENERAL_H_FILES)
# $(STICKY_FILES) : Configure.pl
# $(PERL) Configure.pl
Index: config/auto/cgoto.pl
===
RCS file: /cvs/public/parrot/config/auto/cgoto.pl,v
retrieving revision 1.9
diff -u -r1.9 cgoto.pl
--- config/auto/cgoto.pl 10 Dec 2003 11:44:17 - 1.9
+++ config/auto/cgoto.pl 19 Dec 2003 16:31:50 -
@@ -27,17 +27,17 @@
Configure::Data-set(
cg_h = '$(INC)/oplib/core_ops_cg.h $(INC)/oplib/core_ops_cgp.h',
cg_c = 'EOF',
-$(SRC)/core_ops_cg$(O): $(GENERAL_H_FILES) $(SRC)/core_ops_cg.c
-$(SRC)/core_ops_cgp$(O): $(GENERAL_H_FILES) $(SRC)/core_ops_cgp.c
+$(OPS)/core_ops_cg$(O): $(GENERAL_H_FILES) $(OPS)/core_ops_cg.c
+$(OPS)/core_ops_cgp$(O): $(GENERAL_H_FILES) $(OPS)/core_ops_cgp.c
-$(SRC)/core_ops_cg.c $(INC)/oplib/core_ops_cg.h: $(OPS_FILES) $(BUILD_TOOL)/ops2c.pl lib/Parrot/OpsFile.pm lib/Parrot/Op.pm lib/Parrot/OpTrans/CGoto.pm
+$(OPS)/core_ops_cg.c $(INC)/oplib/core_ops_cg.h: $(OPS_FILES) $(BUILD_TOOL)/ops2c.pl lib/Parrot/OpsFile.pm
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Leo wrote: Please try something like this: $ gdb parrot (gdb) b sig_handler (gdb) r t/op/hacks_1.pasm Program received signal SIGFPE, Arithmetic exception. [ ... ] (gdb) s Breakpoint 1, sig_handler (signum=8) at src/events.c:33 [ some more steps ] 332 longjmp(the_exception.destination, 1); (gdb) runops (interpreter=0x823df48, offset=0) at src/interpreter.c:632 (gdb) b sig_handler Breakpoint 1 at 0xed5e0: file src/events.c, line 33. (gdb) r t/op/hacks_1.pasm Starting program: /Users/allison/projects/cvs/parrot/parrot t/op/hacks_1.pasm Reading symbols for shared libraries . done not reached Program exited normally. (gdb) Allison
Re: [perl #24683] [PATCH] P6C update concat and bitwise operators
Leo wrote: I've added two test files, bitwise.t and concat.t, which go in t/op/ (the op/ directory doesn't exist yet) Missing? The directory needs to be added. We're gradually moving our way toward the test hierarchy planned on p6d: t/var t/op t/subs t/regex t/module t/class ... Or, more extensively: http://p6stories.kwiki.org/index.cgi?ProposedTestHierarchy We haven't gotten to moving all the tests yet, but I'll add new test files in the new hierarchy. Allison
Re: but true
On Fri, Dec 19, 2003 at 12:24:29PM -0700, Luke Palmer wrote: : Abhijit A. Mahabal writes: : On Fri, 19 Dec 2003, Larry Wall wrote: : : On Fri, Dec 19, 2003 at 10:23:45AM -0800, Austin Hastings wrote: : : Of course, when I do: : : : : my $x = 0 but (true|false); : : : : then what happens? : : That's the problem with making them methods. Any such operational : definition is going to get you in trouble. I think I like them better : as enums, because then you can have junctions of them functioning as : a kind of subtype. : : Is that thought about just traits, or also about roles? : : Neither. It's just about roles. We're having another vocabulary : conflict; refer to the vocabulary doc. I've been trying to capitalize Traits when I'm referring back the Traits paper, and keeping it lowercase when I mean Perl 6 compile-time traits. Sometimes it means I have to recast the sentence not to say traits at the beginning though... : Sometime earlier Larry mentioned that roles could add multimethods, : and my worry about that is this: : If you simultaneously have a multi method with a signature and : another without, given a particular call to this multimethod how do you : choose which of the two happens if the signature matches? : : Probably the same way you disambiguate when normal multimethods abound. : The more specific signature wins, if it matches. A crude distance calculation is done in typespace for all the involved parameters. It is sufficiently crude that ties can arise when we *ought* to be uncertain which method to call. In that case we'll have some way of declaring how to break the tie. If the tie can't be broken, and exception is then thrown. : Though I do see how this might introduce subtle bugs. I'm a big fan of : method name-only equivalence, so I would argue that it overrides (or : subsides if it isn't being slathered on), but then I don't have : experience with large-scale projects. These multis are intra-class multis. Outside the class, the method has only a single name. With ordinary method dispatch, you figure out which name in which class you're going to call, and only then do you notice that there are more than one of them within the class. These are multi methods, not multimethods in the classic sense. For classic multimethods you have to declare multiple instances of multi sub *foo and call it/them as a subroutine (or operator). But we've generalized multi to work in any namespace that would ordinarily reject a duplicate definition. : Disallowing such clashes seems problematic because it may mean that if : the class writer used types and signatures these get forced onto the : user of the class. Not necessarily. Remember that multi dispatch is based on run-time types, not declared types. A module could be totally ignorant of the run-time types of its values and it would still work, as long as whatever produced the values in the first place labelled them with the right type. And you have to call the right constructor in the first place to get the right values, even if you subsequently store everything in typeless variables, so nothing is really forced on the user that wasn't implicitly there to begin with. : Everybody's going to be using signatures, though! (Types are a : different story) Yeah, the typeless one would win, I think, unless the : type happens to be Any. Not sure what you mean. The typeless one is likely to lose in the sense that it's probably the furthest away in type space. But by the same token, it's likely to be the one that should be default in case of ties, unless one of the tied entrants is specially marked as better. But it's hard to know how much tie-breaking information you want to throw into the declarations, since you generally want to call the most specific entrant that will successfully handle the arguments, and most specific is a function of type distance, not which entrant yells the loudest about its own superiority. So maybe the better solution is to allow class derivations to specify their type distance if it's other than 1, just as IP routing tables can have a notion of which hops are expensive and which ones are cheap. It's probably better to attach such information to the class rather than splattering it all over multi-dom. As with IP routing, mostly it's the expensive routes that are specifically marked, and everything else defaults to 1. A derivation that redefines most of the base class's methods should probably be marked as an expensive route. (Such derivation distance could be automatically calculated, but then our mechanism is never crude enough to get ties when we probably should.) Larry
Re: Object Order of Precedence (Was: Vocabulary)
Larry Wall writes:
But if you say something like:
class DangerousPet does Pet does Predator {
multi method feed ($x) {...}
}
then DangerousPet::feed is called only when multimethod dispatch
would have thrown an exception. Alternately, multi's will probably have
some way of identifying the default method in any case, so maybe you
have to write it something like this:
class DangerousPet does Pet does Predator {
multi method feed ($x) is default {...}
}
that leaves the door open for real multi's within the class working
in parallel to the roles' methods:
class DangerousPet does Pet does Predator {
multi method feed ($x) is default {...}
multi method feed (DangerousPetFood $x) {...}
}
Arguably, the role's might be required to declare their methods multi
if they want to participate in this, but that's one of those things
that feel like they ought to be declared by the user rather than the
definer. On the other hand, maybe a role would feel that its method
*must* be unique, and leaving out the multi is the way to do that.
But I hate to get into the trap of culturally requiring every method
in every role to specify multi. It's a little too much like the C++
ubiquitous-const problem.
I'd like that roles don't have control over whether their methods are
unique, but the class does. That is, multi dispatch would be one of the
several disambiguation possibilities for role conflicts. But without
specification, name conflicts always result in error.
[...]
My hope for unifying traits and superclasses is that, if you call an
ordinary class using is, the wicked thing that it does is insert
itself into the ISA property of the class. Where that may cause
problems if you want to inherit from an existing trait that does
something else wicked. But then, traits aren't often going to be
inherited anyway, since their purpose is to break the rules. We can
maybe inherit from classof(trait) to get around any difficulties.
So I'm still thinking we do inheritance with is rather than isa.
We just have to keep our names straight. Generally, traits will
be lowercase, and true class or role names start with an uppercase
letter.
I like that. That allows for nice things like letting a class keep
track of its subclasses, or in general doing other tricky things to its
subclasses.
Inheritance is a logical association, not a functional one, so when
your classes are doing nonstandard things, you'd like to modify what
inheritance does. Definitely good.
Luke
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
On Dec 17, 2003, at 11:24 AM, Leopold Toetsch wrote: Allison Randal [EMAIL PROTECTED] wrote: $ parrot t/op/hacks_1.pasm not reached ... Does Fruntime/parrot/include/signal.pasm have an entry for SIGFPE? Is PARROT_HAS_HEADER_SIGNAL defined? Yes to both questions. The issue turns out to be that SIGFPE isn't raised on Mac OS X on divide by zero. If I hack src/core_ops.c to explicitly raise(SIGFPE) in the case of zero divisor then the tests pass, so the exception handling code seems to be working correctly. I'm not sure of the best way to fix the tests--long-term I'd expect we'd want parrot to explicitly guard against divide-by-zero (as perl5 seems to do), but I know that's not the real point of these tests. JEff
