*Tap Tap*
Is this thing on? No messages since last Wednesday. Which admittedly makes a summarizer's life a good deal easier... -- Piers
Re: *Tap Tap*
On Mon, Jun 09, 2003 at 09:56:06AM +0100, Piers Cawley wrote: > Is this thing on? No messages since last Wednesday. Which admittedly > makes a summarizer's life a good deal easier... It looks like it is. However, your life may be easier "this week" only, given that many armed and dangerous minds have been meeting up on the perl whirl, and may be about to unleash fearsome new concepts to the world. So it may only be the calm before the storm. Or I may be wrong. Nicholas Clark
Re: *Tap Tap*
Nicholas Clark <[EMAIL PROTECTED]> writes: > On Mon, Jun 09, 2003 at 09:56:06AM +0100, Piers Cawley wrote: >> Is this thing on? No messages since last Wednesday. Which admittedly >> makes a summarizer's life a good deal easier... > > It looks like it is. > > However, your life may be easier "this week" only, given that many > armed and dangerous minds have been meeting up on the perl whirl, and > may be about to unleash fearsome new concepts to the world. So it may > only be the calm before the storm. Or I may be wrong. Ah well, I'll be in Florida for the next one, hopefully I'll be able ask some of said dangerous minds what on earth they're talking about. Anyhoo, time to get this week's summary mailed out. -- Piers
Re: This week's summary
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
> Multimethod dispatch?
> Adam Turoff asked if multimethod dispatch (MMD) was really *the* Right
> Thing (it's definitely *a* Right Thing) and suggested that it would be
> more Perlish to allow the programmer to override the dispatcher,
> allowing for all sorts of more or less cunning dispatch mechanisms
> (which isn't to say we could still have MMD tightly integrated, but it
> wouldn't be the *only* alternative to simple single dispatch). Luke
> Palmer gets the "Pointy End Grandma" award for pointing out that Perl 6
> is a '"real" programming language now' (as Adam pointed out, Perl's been
> a 'real' programming language for years), inspiring a particularly pithy
> bit of Cozeny. As far as I can tell, Adam wants to be able to dispatch
> on the runtime value of a parameter as well as on its runtime type (he's
> not alone in this). Right now you either have to do this explicitly in
> the body of the subroutine, or work out the correct macromantic
> incantations needed to allow the programmer to use 'nice' syntax for
> specifying such dispatch.
>
> Assuming I'm not misunderstanding what Adam is after, this has come up
> before (I think I asked about value based dispatch a few months back)
> and I can't remember if the decision was that MMD didn't extend to
> dispatching based on value, or if that decision hasn't been taken yet.
> If it's not been taken, I still want to be able to do
>
>multi factorial (0) { 1 }
>multi factorial ($n) { $n * factorial($n - 1) }
That's pretty much correct.
I've been musing on dispatching over the last week, and I've come
up with a few scenarios:
- pure type-based (match a method's signature, modulo superclasses)
- pure value-based (scalars with specific values)
- mixed-mode (RightMouseClick class, with 'control' modifier set/unset)
- pre-/post- methods; chains of pre-/post- methods
- AOP-style pre-/post- methods that can come and go at runtime
- Eiffel-style contract checking/enforcement
- roll-your-own inheritance mechanisms (see NEXT.pm)
I've also considered "side-effect based dispatching" for lack of a better
term: Consider an object with a whole gaggle of methods that need to check
whether the database is up before continuing. All of them fail similarly
with a "database is down" error. Why *not* factor that out into a
different set of multimethods that execute only when the database is down?
Now consider what happens if the database handles are not parameters to
each method call, but slots in the object or stored globally...
There are a few other, admittedly weird scenarios where this kind of
behavior would be desirable. All of them exhibit an AOP-ish quality.
Anyway, as Piers summarized, my concern is that if there's only two types
of dispatching, it may be artificially limiting. I'm guessing that if I
can think of three dispatching behaviors, then there may be five, and if
there really are five then there just might be as many as ten or more.
Therefore the simple dispatch/type-based MMD dispatch duality limits more
than it empowers.
I don't think this is really a problem to be solved in the domain of
macro expansion or syntactic warpage. Writing classes to handle these
rules feels like the way to go. Whether or not MMD as it's been sketched
is hardwired into the language (e.g. for performance) is less important to
me than the ability to plug in different (levels of) dispatching behaviors.
Z.
Re: This week's summary
On Mon, 9 Jun 2003, Adam Turoff wrote: > - roll-your-own inheritance mechanisms (see NEXT.pm) On a related note, you might also want to take a look at CLOS (the Common Lisp Object System) where it talks about method selection. They've got a pretty clear and general model that describes every imaginable (and unimaginable) thing you'd want to do with dispatch. It's broken into 3 steps, any one of which you can customize: - find all applicable methods - sort them in order of specificity - apply some kind of combining operation to this list (e.g. select 1st) Granted, this is hardly efficient, and from what I've seen you need to be careful in how you use MMD to get decent performance in Lisp. But it's still helpful in laying out the design space. /s
Re: This week's summary
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
Multimethod dispatch?
Assuming I'm not misunderstanding what Adam is after, this has come up
before (I think I asked about value based dispatch a few months back)
and I can't remember if the decision was that MMD didn't extend to
dispatching based on value, or if that decision hasn't been taken yet.
If it's not been taken, I still want to be able to do
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
That's a bad example, as it's really not MMD. It's a partially
pre-memoized function instead.
Which brings up a issue. Is it really MMD if you're only dispatching on
a single invocant? Most of the examples I've seen for MMD so far use
only a single invocant and are really either regular dispatch or simple
overloading instead. MMD only becomes really interesting if you
have multiple invocants possibly with best-match signature matching
involved.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re MMD [was Re: This week's summary]
On Monday, June 9, 2003, at 07:13 AM, Adam Turoff wrote:
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
Assuming I'm not misunderstanding what Adam is after, this has
come up
before (I think I asked about value based dispatch a few months
back)
and I can't remember if the decision was that MMD didn't extend to
dispatching based on value, or if that decision hasn't been taken
yet.
If it's not been taken, I still want to be able to do
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
The most recent semi-official opinion given onlist, AFAIK, was from
Damian on 3/13/03:
On Thursday, March 13, 2003, at 06:15 PM, Damian Conway wrote:
Piers Cawley wrote:
Speaking of multis and constants, Greg McCarroll wondered on IRC if
this would work:
multi factorial (Int 0) { 1 }
multi factorial (Int $n) { $n * factorial($n-1) }
Probably not. We did discuss whether multimethods should be able to be
overloaded by value, but concluded (for that week, at least ;-) that
this might prove syntactically excessive.
See the rest of his message for a marginally scary workaround.
MikeL
Re: MMD [was Re: This week's summary]
On Monday, June 9, 2003, at 09:19 AM, Mark A. Biggar wrote:
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
That's a bad example, as it's really not MMD. It's a partially
pre-memoized function instead.
It's MMD if you think of the number 0 as being a "subclass" of C
or C. In other words, you have an C class, and then a
subclass of C that binds the value to always be zero.
In a not-too-twisted fashion, you can think of any constant as being a
"subclass" of its base type, overridden to store exactly one possible
value. It's like instance-based (classless) inheritance, which we
haven't discussed much, but which I hope we eventually get to, because
it's bloody useful... Sigh...
Which brings up a issue. Is it really MMD if you're only dispatching
on
a single invocant? Most of the examples I've seen for MMD so far use
only a single invocant and are really either regular dispatch or simple
overloading instead. MMD only becomes really interesting if you
have multiple invocants possibly with best-match signature matching
involved.
I think it's a matter of semantics: a single-invocant routine is still
a "multi", and still semantically MMD, because it uses the same
internal dispatcher as an N-invocant one, and checks the same list of
possible variants. So you can have:
multi bar (Baz $b : ...); # one invocant
multi bar (Foo $f : ...); # one invocant, but different!
multi bar (Foo $f, Baz $b : ...); # two invocants
All three of those are multimethod variants of a routine named C.
The MMD mechanism has to determine which of those three variants to
use, based on the invocant(s) -- of which there may be one, or several,
for any given call to C. Even if there only happens to be one
invocant, it's still the same dispatcher, sifting through the same
possible variants.
The single-invocant C thing I still find confusing at this point
is that, for example, you can't actually have Cs! That
is, you can't do this:
class Foo {
method bar (int $i);
method bar (str $s); # ERROR
method bar (str $s1, str $s2);
}
You'd have to do this:
class Foo {
multi bar (Foo $self, int $i : ); # semicolon optional
multi bar (Foo $self, str $s : );
multi bar (Foo $self, str $s1, str $s2 : );
}
Which, internally, makes some sense -- they have to go to a more
complicated dispatcher than normal methods -- but is semantically icky,
IMO, and I hope/wish we could find a better way of expressing that.
Perhaps E6 will help.
MikeL
Re: MMD [was Re: This week's summary]
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
> multi bar (Foo $self, int $i : ); # semicolon optional
I think you meant "colon optional". The semi-colon is, I think, a syntax
error. You need the yada-yada-yada thing: "{...}".
But I agree with the main point you were wanting to make: a class-based
multimethod really should make the primary invocant ($self) implicit -- if
doing so doesn't make things even more confusing/ambiguous/nasty.
Dave.
Re: MMD [was Re: This week's summary]
On Monday, June 9, 2003, at 03:45 PM, Dave Whipp wrote:
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
multi bar (Foo $self, int $i : ); # semicolon optional
I think you meant "colon optional". The semi-colon is, I think, a
syntax
error. You need the yada-yada-yada thing: "{...}".
Sigh. Yes, thank you. This, not that:
multi bar (Foo $self, int $i : ) {...} # colon optional
It's been a bad day. :-/
MikeL
Devel::Coverage warning about POSIX.pm
A "use POSIX" statement is causing Devel::Cover to issue a warning.
I've seen it both on Linux (RH7.3/Perl 5.6.1) and Cygwin (Win2K/Perl
5.8.0). Has anyone investigated it?
[EMAIL PROTECTED] coverage]$ cat foo.pl
#!/usr/bin/perl
use strict;
use POSIX;
my $foo = shift;
if ($foo) {
print "$foo\n";
}
[EMAIL PROTECTED] coverage]$ perl -MDevel::Cover foo.pl
Devel::Cover: Can't find file "../../lib/POSIX.pm": ignored.
Devel::Cover 0.20: Collecting coverage data for branch, condition,
statement and
time.
Selecting packages matching:
Ignoring packages matching:
Ignoring packages in:
.
/usr/lib/perl5/5.6.1
/usr/lib/perl5/5.6.1/i386-linux
/usr/lib/perl5/site_perl
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl/5.6.1
/usr/lib/perl5/site_perl/5.6.1/i386-linux
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/vendor_perl/5.6.1
/usr/lib/perl5/vendor_perl/5.6.1/i386-linux
-- -- -- -- --
--
File stmt branch cond time
total
-- -- -- -- --
--
foo.pl 66.67 50.00n/an/a
60.00
Total 66.67 50.00n/an/a
60.00
-- -- -- -- --
--
--
Danny Faught
Tejas Software Consulting
http://tejasconsulting.com/
Re: Make mine SuperSized....
On Fri, 2003-06-06 at 15:12, Dan Sugalski wrote: > Our options, as I see them, are: > > 1) Make the I registers 64 bits > 2) Make some way to gang together I registers to make 64 bit things > 3) Have I registers switchable between 32 and 64 bit somehow > 4) Have separate 32 and 64 bit I registers > 5) Do guaranteed 64 bit math in PMCs > > The first is just out. It's an unreasonable slowdown on 32 bit (and > some 64 bit) machines, for no overall win. The majority of integers > will be smallish, and most of even the 32 bit range will be wasted. I don't necessarily agree that this option is gone. IREGs are basically used for one of two things. To do non-PMC integer math, and to pass things to and from Parrot's guts. (And then you're talking a store and a load. I think passing them throughout Parrot is where the problem is.) So that would leave doing non-PMC integer math. That just doesn't sound like a whole lot. (But then again, I'm assuming that most math will be PMC-based, in order to handle int->num->str->big type conversions. If we want to minimize PMC-math, then perhaps this is a bigger deal.) You know, there was a day when we'd just write some code and benchmark it to see *how* much slower it is No, no, no. Don't get up. I'll do it. :-) Gluing together most of the IREG-based arithmetics pasm files, removing the prints, and wrapping an iterator around it. Athlon 1 GHz, Linux 2.4.20. Identical Parrot configurations, save the size of INTVALs. long long INTVALs: 4.98u @ 54% long INTVALS : 4.31u @ 54% Difference, .67u @ 54%, or about 15%. (With the JIT, long long INTVALs were *much* faster, but only because they cheated and dumped core.) So what percentage of a program is using the IREGs for math? 10%? 5%? 2%? That's a 1.5% to .3% overall slow down. Keep those numbers in mind. > > I don't like option 2, since it means that we speed-penalize 64 bit > systems, which seems foolish. See below. > > Option 3 wastes half the L1 cache space that I registers takes up. > Fluffy caches--ick. Plus validating the bytecode will be... > interesting, even at runtime. See below. > > 4 isn't that bad. Not great, as it's more registers, and something of > a waste on 64 bit systems, but... See below. > > #5 is something of a cop-out, but I'm not quite sure how much. See below. > > From what I can think, we need guaranteed 64 bit integers for file > offsets, JVM & .NET support, and some fairly special-purpose math > stuff. I'd tend to discount the special-purpose math stuff--that's > not our target. JVM and .NET don't do much 64 bit stuff, but they do > some. The file offset parts are in some ways the least of it, though > we do need to have some internal support for 64 bits to get integer > values out of PMCs without loss. See below. Oh, wait. This *is* below. Okay, see here. Let's back up a step. When it comes to integers, there are two types - no pun intended - of languages. Those that care, and those that don't. Sized integer math has two properties to it, which are intertwined: dynamic range and mathematical semantics. (Dynamic range states that 8 bits can hold 8 bits worth of stuff, whether it's interpreted as signed, unsigned, or normalized (like exponents in IEEE floating point representations); as either numbers or bits. Mathematical semantics are what make (int32_t)((int8_t)0x66 + (int8_t)0x66) == (int32_t)0xffcc rather than 0x00cc.) Although there will be cases where a typed language doesn't really care how large the range or the nature of the mathematical semantics for a given type, there will be times that it does. So we've either got to provide, somehow, all types, or provide one type that emulates the semantics of all types. Untyped languages simply don't care what they get underneath, as long as they work. Except, of course, when they're trying to tie into a typed language. (Pass a 16-bit int from Java to Perl, do some stuff, and pass it back, for instance.) Hardware handles this with different ops, of course, although compilers cheat where they can (or have to). For Parrot, however, that means multiplying the number of ops by 4 or 5. (Multiple IREG ops would still be a common multiple and not an exponent, as you'd promote both integers to the same size.) I think we're op-heavy, already, and Parrot would then have to track integer sizes. (Although for untyped languages, that'd be easy, as they'd all be one size.) Plus, you'd have to map those onto the common set of IREGs. Or create 4 or 5 more. (And then decide how you handle things like integer promotion.) Of course, you could continue to handle this with one op, albeit smart enough to handle the semantics of whatever size math you're doing. That way, you'd only be doing the slow, 64-bit math when you absolutely needed to. The problem is, of course, those numbers up top I told you to remember. Writing that smart op is going to cost you far more than a mere 1.5
Re: Make mine SuperSized....
On Fri, 2003-06-06 at 16:34, Leopold Toetsch wrote: > > *) Integer constants are limited to 32 bit signed integers because > > they're inline. > > Yep. But this will cause problems with JIT/Prederef and multi threading, > and its already causing problems inside JIT on architectures with only > small immediate constants. We have to consider these upcoming problems > too. I dont see any reason, not to have optionally/additionally - or > always - integers in the const_table. There must be *some* limit, even if it's the physical limit of the machine. Either that limit is hard - Parrot cannot support integers larger than that type - or it's soft - Parrot will work around the limit by promoting to arbitrary-width numbers. If it's a soft limit (which it is), then the limit itself is arbitrary. > > > *) INTVAL is meant to be the fastest native integer type for integer > > math that's at least 32 bits. That integer registers are INTVALs is > > an unfortunate side-effect, and one I'm tempted to do something about. > > In one of the FUPs, I had a different definition: > An INTVAL is the size of the integer register. The fastest integer > type on $arch ought to be just a plain C. I think, when we look at > the problem from this side, it should be simpler. IIRC, Jarkko pointed out that that's not always true. (The *last* time I was waffling on sizes.) > I'm - as stated in the thread - for a new register type (L, long). > > They have the same relation as 32bit ints and 64 bit longs, with the > difference that we guarantee at least these sizes. I'm not an actor, nor do I play one on TV. That being said, if you can handle making Parrot keep all the registers straight, I'm not adverse to this. (What am I saying? Of course *you* can handle that. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Make mine SuperSized....
On Fri, 2003-06-06 at 21:47, Benjamin Goldberg wrote: > And for the former... well, we'd be wasting half of the memory that's in > our "32-bit" registers (since we'd still use 64 bits of storage for each > of our registers, even though we're "using" only 32 bits of it), but > there's no speed penalty, and unless there's overflow of the 32 LSB, > there's little harm in using a 64 bit integer as if it were a 32 bit > integer. > > The big waste, of course, is that if code doesn't *use* them, then it > could be wasteful/costly to save them. And it's this sort of rumination that made me think that this is all just false economics. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Class instantiation and creation
If memory serves me right, Dan Sugalski wrote: > It's possible to just go ahead and do it *all* at runtime, and have > no compile time component at all--just a series of "newclass, > addparent, addattribute" ops, assuming those are the op names we go > with. Classes just get created at code initialization time or > something. That would be cool .. a lot easier to debug this kind of thing , especially when you could dump it as imcc and have it constant evaluated as a bytecode segment (wishful thinking ;) Question #1 : Are classes allowed to have fields ? Question #2 : Visibility ? Question #3 : Static methods ? Question #4 : Static constructors ? Question #5 : Destructor semantics .. Questions #3 & #4 can be emulated and #2 is only optional but #1 & #5 are of concern .. > instantiate a new class you need a chunk of bytecode around. It's > possible that at least some of this is only doable with metadata in > bytecode, but the bytecode metadata segments can be easily created on > the fly. Hmm... like compile some imcc on the fly ? > Anyone got any feelings or opinions on this, besides "Why yes, I want > an object system"? :) Class-based info I may be missing would also be > welcome. "Why who wouldn't ?" How would the override of a method happen ? ... would it be purely by name or would you provide some way to force a method to override another of a different name ? .. Ie add a method forcibly over an occupied slot ?. Gopal -- The difference between insanity and genius is measured by success
Dewarnock attempt: Continuations Save
Piers Cawley wrote: The Continu(ation)ing Saga Jonathan Sillito posted a longish meditation on Parrot's new continuation passing calling conventions. He wondered if, now we have continuation passing, we really needed the various register stacks that were used in the old stack based calling conventions. Warnock's Dilemma currently applies. http://xrl.us/ja4 I think that Jonathan's idea sounds like a good one. It allows a function to save only those registers it needs by doing it in the creation of the continutation. Thus the worries about saveall vs save some disappear and all of the stacks might no longer be necessary. Unfortunately, I do not have any background in this area, so my instincts are likely worthless. I would, however, really like to hear from someone more skilled than I am about it. Even if they say nothing more than, "this is stupid and here is why ... " Thanks, Matt
This week's summary
The Perl 6 Summary for the week ending 20030608 It's another Monday, it's another summary and I need to get this finished so I can starting getting the house in order before we head off to Boca Raton and points north and west on the long road to Portland, Oregon. Via Vermont. (I'm English and as the poem comments, the rolling English road is "A rare road, a rocky road and one that we did tread // The day we went to Birmingham by way of Beachy Head." Just because I'm in America doesn't mean I can't take an English route to OSCON) We'll start with the internals list this week (and, given that there are only 18 or so messages in my perl6-language inbox, we may well stop there). Building IMCC as parrot It's been pretty much decided that IMCC will soon become 'the' parrot executable. Josh Wilmes, Robert Spier and Leo "Perl Foundation grant recipient" Tötsch are looking into what needs to be done to make this so. It's looking like the build system may well see some vigorous cleanup action in this process. http://xrl.us/jax The Horror! The Horror! Clint Pierce continued to expand on the internals of this Basic implementation. The more I see of his pathological examples, the gladder I am that I escaped BASIC as quickly as possible. Still, kudos to Clint once more for the effort, even if it is a tad embarrassing that the most advanced language hosted on Parrot is BASIC. (On IRC Leon Brocard and others have been heard to remark that they're? unlikely to go all out at a real language until Parrot has objects. Dan?) http://xrl.us/jay The Horror! The Horror! Part II The timely destruction thread still doesn't want to go away. Dan has been heard muttering about this on IRC. Eventually, he did more than mutter on IRC -- he stated clearly on list that 'We aren't doing reference counting' and that as far as he is concerned the matter is closed. Dan's blog also has another of his excellent "What The Heck Is" posts, this time about Garbage Collection. http://xrl.us/jaz http://xrl.us/ja2 http://xrl.us/ja3 - What the Heck is: Garbage Collection The Continu(ation)ing Saga Jonathan Sillito posted a longish meditation on Parrot's new continuation passing calling conventions. He wondered if, now we have continuation passing, we really needed the various register stacks that were used in the old stack based calling conventions. Warnock's Dilemma currently applies. http://xrl.us/ja4 Clint Pierce, IMCC tester extraordinaire Over the past couple of week's Clint Pierce has been porting his BASIC implementation over to run on IMCC. In the process of doing so he's been finding and reporting all sorts of IMCC bugs and/or misunderstandings and Leo Tötsch (usually) has either been correcting Clint's assumptions or fixing the bugs he's found. I've mentioned a few of these exchanges that generated longish threads in the past, but that hasn't covered everything that's been found, discussed and fixed. It's been great to see this sort of dialogue driving the design and implementation forward based on the needs of a real program. The thread I've linked to below is another exchange in this ongoing dialogue. Clint found a way of reliably segfaulting IMCC. Leo fixed it. And on to the next. http://xrl.us/ja5 And, on the subject of list stalwarts... Jürgen Bömmels is still working away at the Parrot IO (PIO) subsystem. In this particular patch, he's gone through the Parrot source replacing occurrences "PIO_fprintf(interpreter, PIO_STDERR(interpreter, ...)" with the better factored "PIO_eprintf(interpreter, ...)", which as well as eliminating repetition, helps to keep the IO code slightly easier to maintain. Leo applied the patch. (Although it's not mentioned explicitly elsewhere, Leo continues to keep up his astonishing productivity with various other patches to Parrot) http://xrl.us/ja6 Make mine SuperSized Bryan C. Warnock continued to discuss issues of the size of Parrot's various types, particularly the integer types that get used within a running Parrot. Bryan argues that these should ideally use a given platform's native types, worrying about guaranteed sizes only at the bytecode loading/saving stage. Dan and others commented on this (Dan essentially said that he understood what Bryan was driving at but wasn't quite sure of the way forward, and outlined his options). Discussion continues. http://xrl.us/ja7 Call "invoke" call? Jonathan Sillito submitted a patch which changes "invoke" to "call", adds some PMC access macros and updates the tests. He and Leo Tötsch discussed things for a while and I think the patch is in the process of being rewritten as result of that discussion. http://xrl.us/ja8 Constant
Current CVS broken?
Its been a while since I've looked at parrot, so I did a "cvs update -d", "perl Configure.pl", "make clean", "make" and build failed: $ make gcc -o parrot -L/usr/local/lib test_main.o blib/lib/libparrot.a -lnsl -ldl -lm -lpthread -lcrypt -lutil blib/lib/libparrot.a(jit_cpu.o)(.text+0x2ce0): In function `Parrot_jit_restart_op': : undefined reference to `Parrot_end_jit' collect2: ld returned 1 exit status make: *** [parrot] Error 1 It can't find Parrot_end_jit. Sure enough, its not there: $ nm blib/lib/libparrot.a | grep Parrot_end_jit U Parrot_end_jit $ grep --recursive Parrot_end_jit * include/parrot/jit_emit.h:static void Parrot_end_jit(Parrot_jit_info_t *, struct Parrot_Interp * ); include/parrot/jit_emit.h:Parrot_end_jit(jit_info, interpreter); jit/i386/jit_emit.h:static void Parrot_end_jit(Parrot_jit_info_t *, struct Parrot_Interp * ); jit/i386/jit_emit.h:Parrot_end_jit(jit_info, interpreter); Did I miss something obvious? Brian Wheeler [EMAIL PROTECTED]
Class instantiation and creation
Well, we can make objects and we can call methods on objects (at least the interface is specified, if not actually implemented) but actually building classes to make objects out of is still unspecified. So, time to remedy that, after which I hope we can build at least a simple "ParrotObject" class. The issue is metadata. How do you declare a class' inheritance hierarchy, its interfaces, its attributes, and its type? (At the very least, there's probably more) I can see the following . 1) A class subclasses a single parent. 2) A class subclasses a single parent and adds attributes 3) A class subclasses multiple parents 4) A class subclasses multiple parents with extra attributes 5) A class adds attributes at runtime 6) A class adds parents at runtime I'm not too worried about adding interfaces at runtime, as that doesn't do anything more, really, than adding methods at runtime. Either way's fine, it's just a bit of extra provided metadata that's only there when you query it. We're going to need to be able to do all these at runtime as well as load time, the question is how. It's possible to just go ahead and do it *all* at runtime, and have no compile time component at all--just a series of "newclass, addparent, addattribute" ops, assuming those are the op names we go with. Classes just get created at code initialization time or something. It's also possible that, except for case #1, all these things can only be done at compile time. (Which rules out 5 and 6) Classes are declared exclusively with some sort of bytecode metadata and to instantiate a new class you need a chunk of bytecode around. It's possible that at least some of this is only doable with metadata in bytecode, but the bytecode metadata segments can be easily created on the fly. Case #1 will definitely want to be doable with a single op, at runtime. It's a reasonably common operation, as these things go, as folks make anonymous child classes for single objects. I know there are good reasons to be able to do that both from a user program standpoint as well as for internal reasons. (Mainly to allow per-object method overriding without having to go through too many hoops) Part of me wants to go all-metadata for cases 2, 3, and 4, since I'm wary of the issues of doing what should be an atomic action in multiple ops. There's a loss of atomicity at the program level there, and if the classes override some of the actions (if we even allow that--does anyone allow overloading the subclassing operation?) it could get messy. #5 really has to be metadata based, as it'll be expensive as it is. Refiguring the attribute array is a constant-time operation, more or less, so doing it 6 times to add in 6 attributes seems... suboptimal. If we don't do it with metadata we'll need ops that allow adding in multiple elements in one go. #6, well... I'm not sure we should even allow #6, at least as part of the base parrot object system, but since we're going to do it anyway, we might as well do it right. The big issue with #6 being the same as #5--potentially needing to add in multiple attributes. That argues for a metadata approach, though alterations using metadata are dodgy. Anyone got any feelings or opinions on this, besides "Why yes, I want an object system"? :) Class-based info I may be missing would also be welcome. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Current CVS broken?
Brian Wheeler <[EMAIL PROTECTED]> wrote: > Its been a while since I've looked at parrot, so I did a "cvs update > -d", "perl Configure.pl", "make clean", "make" and build failed: $ make realclean should help. We don't have all dependencies in generated files sorted out that far - sorry. > It can't find Parrot_end_jit. Sure enough, its not there: Its in jit_cpu.c generated from core.jit. > Brian Wheeler leo
Re: Class instantiation and creation
Dan Sugalski wrote: Well, we can make objects and we can call methods on objects (at least the interface is specified, if not actually implemented) but actually building classes to make objects out of is still unspecified. So, time to remedy that, after which I hope we can build at least a simple "ParrotObject" class. The issue is metadata. How do you declare a class' inheritance hierarchy, its interfaces, its attributes, and its type? (At the very least, there's probably more) I can see the following . 1) A class subclasses a single parent. 2) A class subclasses a single parent and adds attributes 3) A class subclasses multiple parents 4) A class subclasses multiple parents with extra attributes 5) A class adds attributes at runtime 6) A class adds parents at runtime Why not just have 1, 2 and 3 be degenerate cases 4? We're going to need to be able to do all these at runtime as well as load time, the question is how. It's possible to just go ahead and do it *all* at runtime, and have no compile time component at all--just a series of "newclass, addparent, addattribute" ops, assuming those are the op names we go with. Classes just get created at code initialization time or something. Would "adparent" replacate the metadata of the parent into the metadata of the child or will we need to walk the inheritence tree to get the metadata about inherited attributes? Part of me wants to go all-metadata for cases 2, 3, and 4, since I'm wary of the issues of doing what should be an atomic action in multiple ops. There's a loss of atomicity at the program level there, and if the classes override some of the actions (if we even allow that--does anyone allow overloading the subclassing operation?) it could get messy. #5 really has to be metadata based, as it'll be expensive as it is. Refiguring the attribute array is a constant-time operation, more or less, so doing it 6 times to add in 6 attributes seems... suboptimal. If we don't do it with metadata we'll need ops that allow adding in multiple elements in one go. Another possibility is to have an "addslots N" op to pre-extend the class and only dynamically extend if necessary. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Current CVS broken?
On Mon, 2003-06-09 at 15:23, Leopold Toetsch wrote: > Brian Wheeler <[EMAIL PROTECTED]> wrote: > > Its been a while since I've looked at parrot, so I did a "cvs update > > -d", "perl Configure.pl", "make clean", "make" and build failed: > > $ make realclean > > should help. We don't have all dependencies in generated files sorted out > that far - sorry. > Doesn't, I'm afraid. I removed everything but the CVS directory at the top level, repopulated everything and tried to build it again with the same results Any thoughts? Brian > > It can't find Parrot_end_jit. Sure enough, its not there: > > Its in jit_cpu.c generated from core.jit. > > > Brian Wheeler > > leo
[PATCH] Borland configuration
This should let parrot compile with the free command lind tools from Borland.
Cheers
--
Andrew The
Index: config/init/hints/mswin32.pl
===
RCS file: /cvs/public/parrot/config/init/hints/mswin32.pl,v
retrieving revision 1.10
diff -r1.10 mswin32.pl
57a58,62
> my($linkflags)=Configure::Data->get(qw(linkflags));
> $linkflags =~ s/-release\s//;
> $linkflags =~ s/-machine:x86\s?//;
> $linkflags =~ s/-nodefaultlib\s//;
> $linkflags =~ s/-nologo\s//;
59c64,66
< o => '.obj',
---
> so => '.dll',
> a => '.lib',
> o => '.obj',
63a71
> cc_ldflags => '',
68d75
< cc_ldflags => '',
70a78
> linkflags => $linkflags,
71a80,87
> # bug #1 tlib cannot handle paths with forward slashes,
> #replace them with backslahes
> # bug #2 tlib also dies if files have the same name in a
> library
> #currently the only conflicting files are in the
> classes
> #directory, rename the object files so that
there is no conflict.
> ar => '$(PERL) -e "map {{ s/\\///g; if(/classes(.+)/)
> {{ system
\"move classes$1 classespmc_$1\"; s//pmc_/;}} }} @ARGV; $l =
shift @ARGV; system \"tlib.exe $l /a /C @ARGV\"; map { if( /classespmc_(.*)/
) { system \"move classespmc_$1 classes$1\"} } @ARGV"',
> ar_flags => '',
> ar_out => '',
75a92
> Configure::Data->set('link', Configure::Data->get('ld'));
Re: Class instantiation and creation
Dan Sugalski wrote: The issue is metadata. How do you declare a class' inheritance hierarchy, its interfaces, its attributes, and its type? (At the very least, there's probably more) I can see the following . 1) A class subclasses a single parent. 2) A class subclasses a single parent and adds attributes 3) A class subclasses multiple parents 4) A class subclasses multiple parents with extra attributes 5) A class adds attributes at runtime 6) A class adds parents at runtime How about removing parents or attributes at runtime? Matt
