Re: Initializers, finalizers, and fallbacks
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, here's a sketch of where I'm going with the initialization,
finalization, and fallback method locating.
As the current init scheme isn't really flying (and not in sync with
this proposal) here is a first hack to get it running.
CONSTRUCT is the method we call when we're building the object from
scratch. We call it on the object and if the object wants to
redispatch to parents, it better do so. We'll catch that it's being
redispatched and call the proper parent class method even if it has a
different name.
BUILD is the method we call when we're building the object. We call
this on *every* class in the object's hierarchy that it exists in. No
redispatching, it's all automatic.
[ ... ]
Also, these properties are on *names*, not method PMCs. We get a
two-step look up the property, then look up the method the property
names thing,
Here is a sample program:
$ cat o.imc
.sub _main
$P0 = newclass A
$P1 = new PerlString
$P1 = _new
setprop $P0, BUILD, $P1
$I0 = find_type A
$P2 = new PerlString
$P2 = argument\n
.local pmc obj
obj = new $I0, $P2
print done\n
end
.end
.namespace [A]
.sub _new method
.param pmc arg
print new\n
print arg
.end
.sub __init method
print init\n
.end
The new scheme is currently turned on only, if the environment variable
CALL__BUILD is set so that old code isn't broken immediately:
$ CALL__BUILD=1 parrot o.imc
new
argument
done
$ parrot o.imc
init
done
The obj = new Iclass can now take an optional initializer which is
passed as first PMC arument to the BUILD or CONSTRUCT method. It's up to
the class what this is, but we should probably define some scheme for
HLL interoperbility.
Comments welcome,
leo
--- parrot/include/parrot/objects.h Sat Apr 3 18:00:20 2004
+++ parrot-leo/include/parrot/objects.h Tue Apr 6 10:10:56 2004
@@ -44,6 +44,7 @@
PMC *Parrot_remove_parent(Parrot_Interp, PMC *, PMC *);
PMC *Parrot_multi_subclass(Parrot_Interp, PMC *, STRING *);
void Parrot_instantiate_object(Parrot_Interp, PMC *);
+void Parrot_instantiate_object_init(Parrot_Interp, PMC *, PMC *);
INTVAL Parrot_object_isa(Parrot_Interp interpreter, PMC *, PMC *);
PMC *Parrot_new_method_cache(Parrot_Interp);
PMC *Parrot_find_method_with_cache(Parrot_Interp, PMC *, STRING *);
--- parrot/src/objects.cMon Apr 5 11:24:49 2004
+++ parrot-leo/src/objects.cTue Apr 6 10:21:56 2004
@@ -440,6 +440,7 @@
/* Reset the init method to our instantiation method */
new_vtable-init = Parrot_instantiate_object;
+new_vtable-init_pmc = Parrot_instantiate_object_init;
new_class-vtable = new_vtable;
/* Put our new vtable in the global table */
@@ -458,16 +459,32 @@
return new_type;
}
+static PMC*
+get_init_meth(Parrot_Interp interpreter, PMC *class, const char * init_name)
+{
+PMC *prop;
+STRING *prop_s, *meth;
+prop_s = const_string(interpreter, init_name);
+prop = VTABLE_getprop(interpreter, class, prop_s);
+if (!VTABLE_defined(interpreter, prop))
+return NULL;
+meth = VTABLE_get_string(interpreter, prop);
+return Parrot_find_method_with_cache(interpreter, class, meth);
+}
static void
-do_initcall(Parrot_Interp interpreter, PMC* class, PMC *object)
+do_initcall(Parrot_Interp interpreter, PMC* class, PMC *object, PMC *init)
{
-
SLOTTYPE *class_data = PMC_data(class);
PMC *classsearch_array = get_attrib_num(class_data, PCD_ALL_PARENTS);
PMC *parent_class;
INTVAL i, nparents;
+int free_it;
+/*
+ * XXX compat mode
+ */
+if (!Parrot_getenv(CALL__BUILD, free_it)) {
nparents = VTABLE_elements(interpreter, classsearch_array);
for (i = nparents - 1; i = 0; --i) {
parent_class = VTABLE_get_pmc_keyed_int(interpreter,
@@ -476,12 +493,60 @@
object, parent_class);
}
Parrot_base_vtables[enum_class_delegate]-init(interpreter, object);
+}
+else {
+/*
+ * 1) if class has a CONSTRUCT property run it on the object
+ *no redispatch
+ */
+PMC *meth = get_init_meth(interpreter, class, CONSTRUCT);
+if (meth) {
+/* XXX S0 isn't set - create runops_method */
+PMC *p2 = REG_PMC(2); /* preserve current self */
+REG_PMC(2) = object;
+if (init)
+Parrot_runops_fromc_args_save(interpreter, meth, vP, init);
+else
+Parrot_runops_fromc_save(interpreter, meth);
+REG_PMC(2) = p2;
+}
+/*
+ * 2. if class has a BUILD property call it for all classes
+ *in reverse search order - this class last.
+ */
+nparents = VTABLE_elements(interpreter, classsearch_array);
+for (i = nparents - 1; i = 0; --i) {
+parent_class = VTABLE_get_pmc_keyed_int(interpreter,
+classsearch_array, i);
+meth =
Re: tests for change #22539
Jim Cromie wrote: Heres a 'working' version of my earlier proposal, patched against [EMAIL PROTECTED] I hope you find it useful for regression testing of the optimizer, and the opcode generation phases. Thanks, applied to bleadperl as change #22664.
Re: New SDL Parrot Bindings Underway
On Mon, Apr 05, 2004 at 09:33:15PM -0700, chromatic wrote: On Mon, 2004-03-29 at 23:33, chromatic wrote: With the improved object system in place, I've been porting the existing SDL Parrot bindings. Here's a quick status update. With helpful suggestions from Jens and Allison, I've just finished porting the existing files in examples/sdl to the new libraries. They're a lot nicer. This is probably a (dumb) parrot question rather than SDL, but I'd have expected these: find_type app_type, 'SDL::App' .namespace [ 'MoveLogo::EventHandler' ] to be more like find_type app_type, 'SDL', 'App' or: find_type app_type, [ 'SDL', 'App' ] .namespace [ 'MoveLogo', 'EventHandler' ] Would either/both of those work and you're just opting to have double colons 'inside' a non-nested namespace name, or am I misunderstanding how nested namespaces do/should/will work? Tim.
Re: New SDL Parrot Bindings Underway
Tim Bunce [EMAIL PROTECTED] wrote: find_type app_type, 'SDL', 'App' or: find_type app_type, [ 'SDL', 'App' ] No. Cfind_type finds a class enum. These types are kept in an array - no hierarchy. .namespace [ 'MoveLogo', 'EventHandler' ] That *would* be: .namespace [ 'MoveLogo'; 'EventHandler' ] *if* nested namespaces were implemented. Tim. leo
Re: Parrot on Vax/OpenBSD
Marcus Thiesen [EMAIL PROTECTED] wrote: Hi, The results of the test suite are here: http://www.thiesen.org/parrottest/vax-openbsd-3.5-beta.txt Doesn't look too bad. There are oviously problems with floats. All native_pbc/number tests are failing. Also type conversions are broken. To fix this we need information about VAX native data types and float format internals. Have fun, Marcus P.S.: I send a Patch yesterday to change the misc.h Got lost. leo
Re: new method
At 1:16 PM -0700 4/4/04, chromatic wrote: On Sun, 2004-04-04 at 10:17, Leopold Toetsch wrote: .sub __init method is AFAIK the constructor. It gets called automatically for all parent classes and the class itself and is the best place to put attributes for objects in place and set these to their default values. I personally want to pass arguments to the initializer (constructor really isn't the right term). I expect HLLs will want to do the same. If we set a convention that the initializer is always called BUILD or CREAT(E), that's fine. I'd like to set or follow a wise convention now. It's not going to be called either--this'll be one of those things where there'll be a property on the method marking it as the constructor. The current scheme's really inadequate for real new methods--what we've got is more akin to an allocator rather than a real constructor. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: __find_method Overrideable From PASM/PIR?
At 9:26 AM +0200 4/5/04, Leopold Toetsch wrote: Chromatic [EMAIL PROTECTED] wrote: According to PDD15, defining a method called __find_method() in my PASM or PIR would allow Perl 5 AUTOLOAD-like behavior. That's a cut'n'paste error in pdd15 - at least now. It needs fixing--the docs, that is, not the method. Making a custom find_method is going to require a bit more thought, and it might well need some other interesting stuff. (It ought not be inheritable, for example, because then you'd need find_method to find find_method...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Q: attribute opcodes
At 9:25 PM +0200 4/3/04, Leopold Toetsch wrote:
Shouldn't {g,s}etattribute opcodes call vtable methods of the object?
Well... no, not really. There's no need for this as such. Properties
are on the PMC as a whole, so you really don't have any idea what the
structure of the PMC is. Attributes are all class-specific and the
class code *does* have deep knowledge of the structure of the object,
at least at the moment.
At some point we'll need to see about some generalized
structure--maybe. It depends a lot on whether anyone actually cares
or not. I can see a big not here, in which case vtable-ing the
things won't buy us anything but a performance hit.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Parrot on Vax/OpenBSD
Leopold Toetsch wrote: Marcus Thiesen [EMAIL PROTECTED] wrote: Hi, The results of the test suite are here: http://www.thiesen.org/parrottest/vax-openbsd-3.5-beta.txt Doesn't look too bad. There are oviously problems with floats. All native_pbc/number tests are failing. Also type conversions are broken. To fix this we need information about VAX native data types and float format internals. http://h71000.www7.hp.com/doc/73final/4515/4515pro_013.html http://owen.sj.ca.us/rkowen/howto/fltpt/ http://home.earthlink.net/~mrob/pub/math/floatformats.html
Re: Fun with nondeterministic searches
At 9:12 AM +0100 4/2/04, Piers Cawley wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: When you make a full continuation with clone, can't you chase up its continuation chain and mark its reachable continuations (and only those continuations) as non recyclable? (This is one of the reasons I think that a Continuation should have an explicit copy of the continuation that was current when it was made, rather than relying on savetop/pushtopp to capture it.) We need getting at the call chain anyway. But storing P1 elsewhere seems not to be the right thing. OTOH a subroutine using integers only would preserve it's context just with Cpushtopi, if P1 is saved elsewhere. Your proposal smells like: the return continuation is normally hidden (i.e. not in any register, just in the context). Some opcode like Cget_current_cont makes it available for backtracking or such. That certainly makes sense to me; can anyone think of cases where having/making an explicit return continuation is a good thing? I'm OK with moving the return continuation out of P1 and into somewhere else--I can even see throwing it on the control stack. (Or a special register, I can live with that as well) Explicitly making the continuation is generally unneccessary--most calls ought to be callcc type calls, with plain call with user-supplied continuations for tail call situations or cases where one wants to do Evil Things. (Which is why it ought always be available) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Need a roundup of pending object stuff
Dan Sugalski wrote: So we can get the damn thing nailed down and done. If there's something pending throw it on as a reply and we'll gather them up and see about making it work. Someone conversant with the OO bits of the Python bytecode should do a side-by-side feature comparison to see which way the pie is likely to fly. (Not that urgent, but a similar exercise for the Java bytecode wouldn't hurt overmuch.)
Re: Initializers, finalizers, and fallbacks
At 10:29 PM -0800 4/1/04, chromatic wrote: On Wed, 2004-03-03 at 09:39, Dan Sugalski wrote: Okay, here's a sketch of where I'm going with the initialization, finalization, and fallback method locating. We need to do this because we're in the semi-unenviable position of supporting multiple languages that do this but that *don't* aggree on method names. So we can't depend on those. So, what we're going to do is introduce six properties: FALLBACK CONSTRUCT BUILD FINALIZE DELETE CLEANUP Suppose I have, for the sake of argument, a pointer to a struct that comes from an external C library. In which method under this scheme would I tell that library to free the memory? Should be FINALIZE. As I look at that list I get a distinct What the *hell* was I thinking? feeling, though. I'm trying to figure out what the point of DELETE and CLEANUP were. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: __find_method Overrideable From PASM/PIR?
On Tue, 2004-04-06 at 07:46, Dan Sugalski wrote: It needs fixing--the docs, that is, not the method. Making a custom find_method is going to require a bit more thought, and it might well need some other interesting stuff. (It ought not be inheritable, for example, because then you'd need find_method to find find_method...) That's fine. I don't need it now -- Allison suggested a much simpler scheme that works with what's implemented now. -- c
Re: Need a roundup of pending object stuff
On Tue, 2004-04-06 at 08:42, Dan Sugalski wrote: So we can get the damn thing nailed down and done. If there's something pending throw it on as a reply and we'll gather them up and see about making it work. I'd like to: - pass arguments to a constructor (or initializer, or whatever you want to call it) without calling a separate method explicitly. The BUILD property Leo suggested looks like it'll work. - free memory for external data from an object finalizer (or destructor, or whatever you want to call it), again without calling a separate method explicitly. Throwing a FINALIZE property on the class looks like it'll also work. I don't need reliable time of destruction, as long as it's not a slow memory leak. - use nested namespaces properly, though what I have now will work for now. -- c
[PATCH] OpenBSD on non i386 platforms
[This is a repost because the ticket system can't handle MIME encoded mail] Hi, as I pointed out in my Parrot on Alpha post I had to do a change to the OpenBSD platform.h file in order to get it to run on other platforms. As I ran now into the same problem giving parrot a try on a Vax, I think this might be worth commiting. I ran the tests on the Alpha with this file and it works on i386 as well. Vax I can't tell by now because OpenBSD doesn't support dynamic linking on that platform and I'm looking for a way to get parrot linking without it. Have fun, Marcus -- :: Marcus Thiesen :: www.thiesen.org :: ICQ#108989768 :: 0x754675F2 :: It is the duty of every citizen according to his best capacities to give validity to his convictions in political affairs Albert Einstein --- config/gen/platform/openbsd/misc.h.~1.1.~ Thu Feb 19 18:06:17 2004 +++ config/gen/platform/openbsd/misc.h Sat Apr 3 18:03:45 2004 @@ -2,7 +2,7 @@ ** Miscellaneous: */ -#include i386/exec.h +#include sys/exec.h #ifdef NATIVE_EXEC_ELF #define PARROT_OPENBSD_ELF pgp0.pgp Description: signature
Re: New SDL Parrot Bindings Underway
Hi! Sorry for delay, I had less time than I expected. On Sunday 04 April 2004 19:45, chromatic wrote: On Sun, 2004-04-04 at 10:04, Jens Rieks wrote: I think I prefer letting SDL::App be the main entry point for SDL applications, because *something* has to initialize SDL. So that anyone who wants to use SDL has to subclass from SDL::App? No, they just have to use SDL::App or write their own code to call the NCI subs themselves. Sounds okay. Isn't it possible to do it when loading the SDL bytecode? Yes, but it's not as easy. Why not? Maybe create a pseudo class SDL::NCI when it does not exists, and attach the NCI PMCs to it as properties? Then it is possible to use get_class nci, SDL::NCI getprop nci, SetVideoMode, nci nci( ... ) I now think we should put all of the struct layouts in SDL.imc, so people who want to write their own interface can do so against that, not SDL::App. The structs can also go into a special class, or maybe everything into a single SDL::_intern class. I'm not sure if it is a bug, but @LOAD sections are called everytime load_bytecode is called. If you load the SDL bytecode twice, all classes are registered a second time, which will raise an exception. I'm not sure if it is a bug or a future, though. There are some other next to @LOAD and @MAIN, but I can not find the list at the moment. I think that may be a bug, but we could protect against it. Yes. I am using 'find_method I0, myclass; if I0 1 goto END' in my new files. Indeed. But the main surface has to be usable with the same interface like every other surface. That's true. You're right; let's just return an SDL::Surface from SDL::App::init() or BUILD() or whatever it is and tell people that this is the main surface. Okay. We should raise an exception if it does not work, but I have no idea how to do that. I know how to raise an exception, what I don't know is how to check if a NCI function returned NULL. I will work on this. I'll prepare an example how to use exceptions. One other design problem I am considering right now is how to hide the difference between a double-buffered and a single-buffered surface. With a single-buffered surface you have to call UpdateRect() on the main surface explicitly. With a double-buffered surface, you only call flip(). From a game-developer point of view, this should not be hidden. Both are different techniques requiring different redraw strategies. Different method names for different techniques then? Different SDL::Surface subclasses for double-buffered and single-buffered? Good idea. What do you think about a hash interface for event handling? newsub key, .Sub, _key_x app[SDLK_x] = key -- c jens
Re: New SDL Parrot Bindings Underway
At 7:42 PM +0200 4/6/04, Jens Rieks wrote: What do you think about a hash interface for event handling? newsub key, .Sub, _key_x app[SDLK_x] = key I think... I think I need to get cracking on the event handling spec. I'd prefer SDL to use parrot's built-in event handling system, but for that to happen we first have to *have* a built-in event handling system... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot on Vax/OpenBSD
Jarkko Hietaniemi wrote: Leopold Toetsch wrote: Marcus Thiesen [EMAIL PROTECTED] wrote: Hi, The results of the test suite are here: http://www.thiesen.org/parrottest/vax-openbsd-3.5-beta.txt Doesn't look too bad. There are oviously problems with floats. All native_pbc/number tests are failing. Also type conversions are broken. To fix this we need information about VAX native data types and float format internals. http://h71000.www7.hp.com/doc/73final/4515/4515pro_013.html http://owen.sj.ca.us/rkowen/howto/fltpt/ http://home.earthlink.net/~mrob/pub/math/floatformats.html This looks nice: http://www.opengroup.org/onlinepubs/9629399/chap14.htm VAX D, F, G, and H formats, and also the Cray and IBM formats.
Re: New SDL Parrot Bindings Underway
Hi, sorry, this message was meant to go to chromatic only. I modified my mail client setting to automatically add the mailinglist address some weeks ago, I should revert to the old settings :-) On Tuesday 06 April 2004 19:46, Dan Sugalski wrote: At 7:42 PM +0200 4/6/04, Jens Rieks wrote: What do you think about a hash interface for event handling? newsub key, .Sub, _key_x app[SDLK_x] = key I think... I think I need to get cracking on the event handling spec. I'd prefer SDL to use parrot's built-in event handling system, but for that to happen we first have to *have* a built-in event handling system... SDL events are meant, I proposed the hash-like access to avoid problems with constants. Will parrot's event handling mechanism also apply to foreign event sources (also QT, GKT and others)? jens
Re: New SDL Parrot Bindings Underway
At 8:04 PM +0200 4/6/04, Jens Rieks wrote: Hi, sorry, this message was meant to go to chromatic only. I modified my mail client setting to automatically add the mailinglist address some weeks ago, I should revert to the old settings :-) On Tuesday 06 April 2004 19:46, Dan Sugalski wrote: At 7:42 PM +0200 4/6/04, Jens Rieks wrote: What do you think about a hash interface for event handling? newsub key, .Sub, _key_x app[SDLK_x] = key I think... I think I need to get cracking on the event handling spec. I'd prefer SDL to use parrot's built-in event handling system, but for that to happen we first have to *have* a built-in event handling system... SDL events are meant, I proposed the hash-like access to avoid problems with constants. Will parrot's event handling mechanism also apply to foreign event sources (also QT, GKT and others)? Yes. What I ultimately want is a single unified system that handles all asynchronous things, including timers, signals, and IO. (And events from a windowing system count as IO, at least to me) I think I have a scheme or, rather, I have a scheme that I think will work, but needs a little fleshing out. Got a few other things to take care of first, then I'll get a discussion of this going and we can see where we go from here. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Fun with nondeterministic searches
Dan Sugalski writes: I'm OK with moving the return continuation out of P1 and into somewhere else--I can even see throwing it on the control stack. (Or a special register, I can live with that as well) I'd like to express my vote of confidence for an RC register, which is put in the context structure. Piers has made it clear that P1 needs special handling, and I'd rather have special handling in a special register. IMCC would probably like it, too. Luke
Caller Continuation register (was Re: Fun with nondeterministic searches)
At 1:24 PM -0600 4/6/04, Luke Palmer wrote: Dan Sugalski writes: I'm OK with moving the return continuation out of P1 and into somewhere else--I can even see throwing it on the control stack. (Or a special register, I can live with that as well) I'd like to express my vote of confidence for an RC register, which is put in the context structure. Piers has made it clear that P1 needs special handling, and I'd rather have special handling in a special register. It'd probably make caller and other forms of stack walking easier too, if we do Interesting Things with it, as we'd just walk the chain of continuations back. Hrm. Okay, it's still early in the week, so I'm not feeling the pressure to Just Make A Decision. Discussion for and against is, I think, warranted before we change, yet again, the calling conventions. :) (Though in this case it can be supplemental, leaving the retcont in P1 as a convenience) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[NEW] Stream library ready
Hi all, here is a working version of my new Stream library. I will add more documentation later this month, the examples should be enough to understand the usage. After using assign to attach a source to the stream, you can use the read method to fetch a string from the stream. The connected method returns 1 if the stream is connected, 0 otherwise. read returns a null string (can be tested with isnull) if the stream end has been reached. The dump method calls read and prints the result in an escaped form, until the stream end has been reached Please have a look at the examples in examples/streams/ jens PS: The attached file also contains the needed library/Data/Escape.imc file which contains a function that escapes a string (refactored from Data::Dumper). Stream.tgz Description: application/tgz
Re: Language Interoperability
On 4/6/2004 11:06 AM, Dan Sugalski wrote: At 6:12 AM -0400 4/4/04, Randy W. Sims wrote: [Scheme 1: hierarchy munging] [Scheme 2: loadable-library style plugins] Is there anything in the above that stands out as potentially being problematic? Well, there are a lot of languages that really dislike having their inheritance hierarchy change at runtime, so the first scheme might be rather problematic. (I also think it's likely a really bad misuse of inheritance, but that's a matter of opinion) Scheme 2 is also much safer from a pure security standpoint. Personally it's what I'd prefer. Design-wise, that pretty well sums up my opinion also. Unfortunately, I think I'm outnumbered. :( I think I was rather hoping for a technical knockout with a language iteroperability argument, but... Can you really have a perl class inherit from a ruby class which inherits from a python class which inherits from a perl class, etc, etc, ad nauseam? Thanks, Randy. BTW, Is there going to be a seperate mailing-list for module authors making the transition to Parrot and Perl 6? I'm not sure if topics like this are appropriate for this list.
