Compiler messages

[Jason Johnson-5]

On Nov 13, 2007 3:46 PM, Bill Schwab <BSchwab@...> wrote:
>
> I am
> starting to wonder whether exceptions or events are a good fit, as they
> both have overhead (especially exceptions??) that might be a problem
> when loading large change sets.

Why would the exceptions be a problem if they are not fired?  If they
are fired then the user has to take action anyway.  Or am I missing
something?  Maybe presence of exceptions causes extra tracing in the
stacks or something?
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Bill Schwab]

Tim,

You are correct that it would be better to log the information vs.
supressing it entirely.  You compiler subclass idea should allow that,
and w/o the burden of doing something that has to be adopted by the
wider community in order to have remotely lasting value.

I still think that exceptions are an inefficient solution to this
particular problem.  It strikes me as being similar to using #on:do: to
protect #at: when #at:ifAbsent: can suffice.  Exceptions of course have
the power to "tunnel across the stack," but in this case, I suspect an
optional context argument or extension of one that already exists is the
preferred approach.  #on:do: has overhead even if the exception is not
raised, and even more if it is raised.  It seems a heavy price to pay
when loading large amounts of code.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab@...
Tel: [phone]
FAX: [phone]


>>> tim@... 11/13/2007 2:17 PM >>>

On 13-Nov-07, at 10:50 AM, Bill Schwab wrote:

> Tim,
>
> I take exception:

I'll raise your exception...

>

I don't think you actually want to prevent the error messages (aside  
from the radical approach that I've always tried to follow - don't  
make mistakes) as such. Error messages are the weakness leaving the  
code. Catch it and squeeze it to extract the truthiness for
reinsertion.

tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim 
"Bother" said Pooh, when Piglet stubbed his fag out on the semtex.


_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Bill Schwab]

Gary,

Agreed, with the caveat that I am currently thinking contexts are
preferred to exceptions in this case (for speed).  Of course, that would
require changing a LOT of code, where the exception solution can be
stealthy.  Changing default actions is a worthy compromise.  I will take
a shot at it.

This reminds me of EndOfStream.  I would very much like to see #next:,
#next, etc. raise exceptions on stream exhaustion, with #nextOrNil and
#nextAvailable: truncating w/o errors.  When a stream unexpected hits
bottom, I like to know about then vs. waiting for incomplete data to
confuse higher layers.  Unfortunately, the default actions appear not to
be relevant in that case.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab@...
Tel: [phone]
FAX: [phone]


>>> gazzaguru2@... 11/13/2007 2:07 PM >>>
So Bill, if you want to suppress the messages, change the default
action for
the exceptions now, or make them preference based, debugger based,
whatever.
At least there is a nicer way to handle things now. I'm not sure under
what
circumstances you'd want the popups now... I guess a preference would
be
best (interactive or logged (to Transcript)). But that can now be done
in
the default handler, rather then the (model) Parser code.

Just my thoughts...

> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]On Behalf Of Bill
Schwab
> Sent: 13 November 2007 6:50 PM
> To: ui@...
> Subject: Re: [UI] Compiler messages
>
>
> Tim,
>
> I take exception: Colin's code does not stop the messages: it
enables

> the IDE to do so.  Your idea of a compiler subclass is well-taken.
>
> Bill
>
>
>
>
>
> Wilhelm K. Schwab, Ph.D.
> University of Florida
> Department of Anesthesiology
> PO Box 100254
> Gainesville, FL 32610-0254
>
> Email: bschwab@...
> Tel: [phone]
> FAX: [phone]
>
>
> >>> tim@... 11/13/2007 1:03 PM >>>
>
> On 13-Nov-07, at 9:18 AM, Bill Schwab wrote:
>
> > Colin,
> >
> > First, not meaning to be dense, I load the code and the compiler
> > continues to nag me over both selectors and variables.  Do I need

to
>
> > set
> > the mode, or does you fix work only with specific browsers?
>
> Take a look at the code Bill; Colin made changes to abstract the
> notifications by raising specific signals instead of explicitly
using
>
> menus. If you want to handle the exceptions you can. The
defaultAction
>
> is to open a menu as before, a very logical and reasonable choice.
>
> > I would probably opt to simply patch it enough to stop the
nonsense,
>
> > at
> > least to start.
>
> That's exactly what Colin's code does. It stops the nonsense and
> provides a way for clients to do what they need as well as leaving
the
>
> system fully functional when there is no specific handling of
errors.
>
> The next part of the job would be to find all the relevant places
> where the Parser is used (ie start with all senders of the public
> access protocols in the Parser class) and to decide whether to
handle
>
> the exceptions or not. Without digging into it too far I'd suggest
> that a subclass of Compiler (called perhaps InteractiveCompiler) be
> built that handled all the exceptions with menus  or preferably
better
>
> dialogues. Then the various browsers would be altered to use
> InteractiveCompiler instead of the plain old Compiler. This could
even

>
> allow nicer behaviour such as showing where a shadowed varname is
> 'originally' used, stuff integrated into the actual browser.
> Eventually you could change the defaultAction for the exceptions to
> just open a debugger since they'd now be more of a system error. For
> any batch loading system - like a changeset loader or whatever - you
> would add another subclass of Compiler (say ChangeSetLoaderCompiler)
> that handles the exceptions appropriately. If you look at
> PositionableStream>fileInAnnouncing: you'll see how some of that is
> curently handled, more as a bad example than anything. Also look at
> all references to InMidstOfFileinNotification. Err, yuck.
>
> tim
> --
> tim Rowledge; tim@...; http://www.rowledge.org/tim 
> Strange OpCodes: BOZO: Use Multics operating system
>
>
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui 
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui 

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[tim Rowledge]

On 13-Nov-07, at 2:47 PM, Bill Schwab wrote:

Gary,

Agreed, with the caveat that I am currently thinking contexts are
preferred to exceptions in this case (for speed).

[snip]

This reminds me of EndOfStream. 

Whoah, neddy!

This really isn't much like that at all. An EndOfStream exception might possibly cause a noticeable slowdown in a tight stream based loop, assuming that the rest of the work being done in said loop is trivial. Having exceptions involved in compiling is hardly the same; compiling is a pretty big job!

Having a 'signal exception' in your code costs nothing much, especially of course if it is not actually executed - the normal case. Actually raising the exception costs a scan of the execution stack - done in primitive code that is rather well written - with a check in Squeak code at each place where an exception handler context is found. If you had a really deep stack with an exception handler not relevant to your code at every other level (why it can't be at every level is left as an exercise for the student) then raising an exception would of course take some time.

Compile speed is rarely much of an issue and hasn't been for decades in ST code. Unless of course you're loading megabytes of the stuff at a gulp, in which case I'd politely suggest your overall process sucks. 

tim

--

tim Rowledge; tim@...; http://www.rowledge.org/tim

Useful random insult:- A room temperature IQ.

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Colin Putney]

On 13-Nov-07, at 2:47 PM, Bill Schwab wrote:

> Agreed, with the caveat that I am currently thinking contexts are
> preferred to exceptions in this case (for speed).  Of course, that  
> would
> require changing a LOT of code, where the exception solution can be
> stealthy.  Changing default actions is a worthy compromise.  I will  
> take
> a shot at it.

Tim is right, speed is just not an issue here. Exceptions only get  
raised if the compiler is in "interactive" mode, as when invoked from  
a browser. In that case, compilation takes milliseconds, and adding a  
few microseconds doesn't matter. Further, if the exception handler  
interacts with the user, the time to raise an exception is dwarfed by  
the time spend waiting for the user to react.

Colin
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Bill Schwab]

Tim,

That's not the "dimension" I had in mind: I was referring to the use of
default actions.  Unfortunately, giving teeth to EndOfStream appears not
to be as simple as changing the default action.

In the affected application (parsing medical data streams), I already
have to protect against exceptions from other sources, so the speed hit
for creating the handler is already in place.  I would much rather have
the exception arise "honestly" from reading off the end of a mal-formed
(or mis-identfied) stream than to wait for some screwy knock-on effect
of silent truncation.  The real fear is that the truncated data _might_
appear valid.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab@...
Tel: [phone]
FAX: [phone]

>>> tim@... 11/13/07 6:03 PM >>>

> [snip]
>
> This reminds me of EndOfStream.
Whoah, neddy!

This really isn't much like that at all. An EndOfStream exception  
might possibly cause a noticeable slowdown in a tight stream based  
loop, assuming that the rest of the work being done in said loop is  
trivial. Having exceptions involved in compiling is hardly the same;  
compiling is a pretty big job!

Having a 'signal exception' in your code costs nothing much,  
especially of course if it is not actually executed - the normal case.  
Actually raising the exception costs a scan of the execution stack -  
done in primitive code that is rather well written - with a check in  
Squeak code at each place where an exception handler context is found.  
If you had a really deep stack with an exception handler not relevant  
to your code at every other level (why it can't be at every level is  
left as an exercise for the student) then raising an exception would  
of course take some time.

Compile speed is rarely much of an issue and hasn't been for decades  
in ST code. Unless of course you're loading megabytes of the stuff at  
a gulp, in which case I'd politely suggest your overall process sucks.


tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim
Useful random insult:- A room temperature IQ.



_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Bill Schwab]

Colin,

I respectfully disagree.  Exceptions shine when a problem is detected
(e.g. end of stream) in code that cannot be expected to know how to
handle it.  Exceptions both propagate the information to a level that
can be expected to cope with it, and prevent silent failures by faulting
if the exception is not handled.  That is exactly what is required in my
medical data parsing example.  In the case of the compiler, it can (and
I submit should) all be handled with messages to a context since the
scenario is fairly focused.

This is both a concern of mine (ensuring robust stream behavior in a
critical and complex system) and something of a long-term agenda to
avoid wasteful programming.  Bloatware happens a few bytes and
microseconds at a time.

Again, in the compiler example, I agree with the plan, but see it as a
clever way of compensating for configuration management deficiencies
rather than being an appropriate technological choice.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab@...
Tel: [phone]
FAX: [phone]

>>> cputney@... 11/13/07 7:14 PM >>>

On 13-Nov-07, at 2:47 PM, Bill Schwab wrote:

> Agreed, with the caveat that I am currently thinking contexts are
> preferred to exceptions in this case (for speed).  Of course, that  
> would
> require changing a LOT of code, where the exception solution can be
> stealthy.  Changing default actions is a worthy compromise.  I will  
> take
> a shot at it.

Tim is right, speed is just not an issue here. Exceptions only get  
raised if the compiler is in "interactive" mode, as when invoked from  
a browser. In that case, compilation takes milliseconds, and adding a  
few microseconds doesn't matter. Further, if the exception handler  
interacts with the user, the time to raise an exception is dwarfed by  
the time spend waiting for the user to react.

Colin
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Gary Chambers-4]

It will be a quite intrusive set of modifications...
Currently, themed menus are available when using the Theme directly (or via
the TEasilyThemed trait). This will be about some extensions to UIManager to
indirect the creation of menus. Of course, the PSUIManager will use the
theme support while the extensions will leave things open.

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Bill Schwab]

Gary,

Obviously, it is your call.  I will admit that Squeak's menus could use
a face lift, but I am much more concerned about Morphic/hand weirdness
(feel) than the appearance (which has improved over time).  So, if they
look and work better, I won't complain.  If you decide that there are
more important battles to fight with the required effort, so be it.

Another slant would be to ask what else you might do for Squeak if you
left the menus alone?  You might throw some ideas at us to see what
resonates as needing work.  That said, I am very grateful for your
sharing your changes with us, and will happily go along for the ride.

Does that help?

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab@...
Tel: [phone]
FAX: [phone]

>>> gazzaguru2@... 11/19/07 11:49 AM >>>
It will be a quite intrusive set of modifications...
Currently, themed menus are available when using the Theme directly (or
via
the TEasilyThemed trait). This will be about some extensions to
UIManager to
indirect the creation of menus. Of course, the PSUIManager will use the
theme support while the extensions will leave things open.

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[matthewf]

On Mon, Nov 19, 2007 at 02:17:47PM -0500, Bill Schwab wrote:
> Gary,
>
> Obviously, it is your call.  I will admit that Squeak's menus could use
> a face lift, but I am much more concerned about Morphic/hand weirdness
> (feel) than the appearance (which has improved over time).  So, if they
> look and work better, I won't complain.  If you decide that there are
> more important battles to fight with the required effort, so be it.

I fixed the Menu hand weirdness in
http://bugs.squeak.org/view.php?id=6687

Load MenuMorph-BetterMouseHandling.2.cs. I don't know if this
should go in UI enhancements or base Morphic. I use this change
set in all my images (and can't live without it anymore). I
haven't tried to push it other than by announcing it here (on the
UI list) once before.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Gary Chambers-4]

Will try that as a (feel) start...
As for other efforts, I'm game for it...
Just the (maybe last) uncharted territory in themeability...

-------

This was a question to gauge the importance of having menus themed as
standard, in the general IDE sense... more of fixing what we have rather
than the new big thing.

In terms of "the new big thing" I think we have to become very much more
focussed. That means really working together. Perhaps everyone could make a
prototype system to demonstrate to us all... then work together with the
best bits?

As a start, we should be able to easily conform to any particular "look and
feel"... take the Java abstraction classes as an example. We could also
incorporate "native" (Win32/GTK) as part of the framework (different to the
"emulated" Java). I'd really like anything we do to be non-exclusive and
all-encompassing, both potentially attainable goals.

Might sound a bit "bloaty" but a framework that can plug-and-play our
concepts would be nice...

I think it comes down to the way(s) you want to be able to describe a
user-interface. Need to be able to express the intention of the ui in a
flexible manner but, also, for some applications, have exact control (plus a
lot of in-betweens). ToolBuilder does a lot of that, but is not yet rich
enough to do the latter...

There is no easy answer, however... yet. All speculation welcomed!

> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]On Behalf Of Matthew
> Fulmer
> Sent: 19 November 2007 8:38 PM
> To: ui@...
> Subject: [UI] Re: MenuMorph hand weirdness
>
>
> On Mon, Nov 19, 2007 at 02:17:47PM -0500, Bill Schwab wrote:
> > Gary,
> >
> > Obviously, it is your call.  I will admit that Squeak's menus could use
> > a face lift, but I am much more concerned about Morphic/hand weirdness
> > (feel) than the appearance (which has improved over time).  So, if they
> > look and work better, I won't complain.  If you decide that there are
> > more important battles to fight with the required effort, so be it.
>
> I fixed the Menu hand weirdness in
> http://bugs.squeak.org/view.php?id=6687
>
> Load MenuMorph-BetterMouseHandling.2.cs. I don't know if this
> should go in UI enhancements or base Morphic. I use this change
> set in all my images (and can't live without it anymore). I
> haven't tried to push it other than by announcing it here (on the
> UI list) once before.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Klaus D. Witzel]

I'm not the experpert on how and where to start with a *general* UI  
framwork but I follow Gary's invitation to "All speculation welcomed".

Having read the LivelyKernel-SourceCode-0.7, I noticed the following (list  
not necessarily complete):

- orientated towards a possible WebOS
- resources have URL (basic interoperability of material)
- imports, exports to/from other of the same kind
- graphical base objects out of the SVG box
- SVG+style is teachable to/learnable by the masses
- widgets look easy to use/reuse
- small # of support classes besides the UI framework
- worlds, hands, morphs, ticks are shoulders+neck of that Atlas
- Events / bindings are like a scripter expects them
- no observable restrictions to animations (limited only by SVG, good)
- things can be glued together without headaches,
  within the limitations (good) of SVG

For sure some of the concepts of LivelyKernel require that mixIns/traits  
are supported but, who cares with a dynamic language and living objects.

And there is that remarkable comment, "my kingdom for a Smalltalk block!"  
in Core.js :-D

So my question is, how about borrowing some things from LivelyKernel?

/Klaus

On Tue, 20 Nov 2007 02:50:22 +0100, Gary Chambers wrote:

> Will try that as a (feel) start...
> As for other efforts, I'm game for it...
> Just the (maybe last) uncharted territory in themeability...
>
> -------
>
> This was a question to gauge the importance of having menus themed as
> standard, in the general IDE sense... more of fixing what we have rather
> than the new big thing.
>
> In terms of "the new big thing" I think we have to become very much more
> focussed. That means really working together. Perhaps everyone could  
> make a
> prototype system to demonstrate to us all... then work together with the
> best bits?
>
> As a start, we should be able to easily conform to any particular "look  
> and
> feel"... take the Java abstraction classes as an example. We could also
> incorporate "native" (Win32/GTK) as part of the framework (different to  
> the
> "emulated" Java). I'd really like anything we do to be non-exclusive and
> all-encompassing, both potentially attainable goals.
>
> Might sound a bit "bloaty" but a framework that can plug-and-play our
> concepts would be nice...
>
> I think it comes down to the way(s) you want to be able to describe a
> user-interface. Need to be able to express the intention of the ui in a
> flexible manner but, also, for some applications, have exact control  
> (plus a
> lot of in-betweens). ToolBuilder does a lot of that, but is not yet rich
> enough to do the latter...
>
> There is no easy answer, however... yet. All speculation welcomed!
>
>> -----Original Message-----
>> From: ui-bounces@...
>> [mailto:ui-bounces@...]On Behalf Of Matthew
>> Fulmer
>> Sent: 19 November 2007 8:38 PM
>> To: ui@...
>> Subject: [UI] Re: MenuMorph hand weirdness
>>
>>
>> On Mon, Nov 19, 2007 at 02:17:47PM -0500, Bill Schwab wrote:
>> > Gary,
>> >
>> > Obviously, it is your call.  I will admit that Squeak's menus could  
>> use
>> > a face lift, but I am much more concerned about Morphic/hand weirdness
>> > (feel) than the appearance (which has improved over time).  So, if  
>> they
>> > look and work better, I won't complain.  If you decide that there are
>> > more important battles to fight with the required effort, so be it.
>>
>> I fixed the Menu hand weirdness in
>> http://bugs.squeak.org/view.php?id=6687
>>
>> Load MenuMorph-BetterMouseHandling.2.cs. I don't know if this
>> should go in UI enhancements or base Morphic. I use this change
>> set in all my images (and can't live without it anymore). I
>> haven't tried to push it other than by announcing it here (on the
>> UI list) once before.
>>
>> --
>> Matthew Fulmer -- http://mtfulmer.wordpress.com/
>> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>> _______________________________________________
>> UI mailing list
>> UI@...
>> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Gary Chambers-4]

The "big thing" just got bigger :-)...
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Klaus D. Witzel]

On Tue, 20 Nov 2007 15:14:46 +0100, Gary Chambers wrote:

> The "big thing" just got bigger :-)...

Good to know :) What's to be cut away, what's to be focused on?

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Gary Chambers-4]

Some thoughts on this...

> Having read the LivelyKernel-SourceCode-0.7, I noticed the
> following (list
> not necessarily complete):
>
> - orientated towards a possible WebOS

        have a clear separation between ui definition and presentation

> - resources have URL (basic interoperability of material)

        URIs would be good to adopt, any ui element can be described via a URI

> - imports, exports to/from other of the same kind

        not sure quite what you mean here Klaus

> - graphical base objects out of the SVG box

        have done a bit with SVG (as far as Balloon could manage, Cairo would be a
nice alternative presentation layer, still use Balloon for fallback (with
limitations) for platforms that don't support Cairo (pdas etc).

> - SVG+style is teachable to/learnable by the masses

        and is a standard. would be nice

> - widgets look easy to use/reuse

        indeed... a better composite model would be nice (wishes I coul plug in
different fillStyles at the moment... since they go to the lowest level it
is not currently possible to define a new type of fillStyle that is
composited programatically)

> - small # of support classes besides the UI framework

        with the right framework there'd probably be no "extra" support classes

> - worlds, hands, morphs, ticks are shoulders+neck of that Atlas

        or just one kind of head-of-the-hydra

> - Events / bindings are like a scripter expects them

        when...do... but also asynchronous, like updatingXXMorph - an independent
observer

> - no observable restrictions to animations (limited only by SVG, good)

        down to the in-framework support classes

> - things can be glued together without headaches,
>   within the limitations (good) of SVG

        perhaps no complex interfaces, just individual aspects that can be combined

>
> For sure some of the concepts of LivelyKernel require that mixIns/traits
> are supported but, who cares with a dynamic language and living objects.
>
> And there is that remarkable comment, "my kingdom for a Smalltalk
> block!"

        I like that one!

>
> So my question is, how about borrowing some things from LivelyKernel?

        indeed...

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[Bill Schwab]

Gary,

In terms of describing an interface, I immediately zoom out to the two
ways one might approach it: graphical editing, and writing code.  The
nature of the GUI editor and the language are "just details."  IMHO,
both methods are essential for happy programmers.  I have some GUI
generating/translating tools that I would expect to port to whatever
Smalltalk system I end up using; they speak MVP.  If I land in Squeak,
it will have an MVP framework, if only because I will write one out of
frustration :)

As I have mentioned before, I am concerned that any MVP work I do would
be tainted with Object Arts' intellectual property.  However, if I
create a framework (tainted) and my own tests for it (by definition
clean - right???), then the tests could be the basis for a clean MVP