Compiler messages

On Nov 13, 2007 3:46 PM, Bill Schwab <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029


>>> [hidden email] 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; [hidden email]; http://www.rowledge.org/tim 
"Bother" said Pooh, when Piglet stubbed his fag out on the semtex.


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029


>>> [hidden email] 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: [hidden email]
> [mailto:[hidden email]]On Behalf Of Bill
Schwab
> Sent: 13 November 2007 6:50 PM
> To: [hidden email]
> Subject: Re: [UI] Compiler messages
>
>
> Tim,
>
> I take exception: Colin's code does not stop the messages: it
enables 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
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- A room temperature IQ.



_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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!

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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:


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

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
framework for Squeak.  Any flaws?  It is a lot of wasted work to write
and then have someone else rewrite a framework, but it might solve the
problem.  At least the rewrite would occur with the benefit of tests.

With some cleverness, Morphs as views, native widgets, SVG, etc., are
hopefully just different types of views in the framework.

As a practical matter, I have a few too many Squeak images for my own
good.  I need to archive them all, mine code out of them, and create one
image that will move back and forth between Linux and Windows.  Any
thoughts on 3.9 vs. 3.10?  For 3.9, I would want the
delay/queue/semaphore fixes; IIRC, those are included in 3.10??

Bill




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

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 11/19/07 8:50 PM >>>
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!
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
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Forgot to comment a bit on my thoughts about SVG (when used within the UI  
framework). I see it [SVG] as a good way to constrain/limit the things  
which can possibly addressed by a new UI. Did not mean to implement it,  
just use it as a stop condition (i.e. what not to do/address when  
developing a framework).

On Tue, 20 Nov 2007 15:37:39 +0100, Gary Chambers wrote:

Was meant to just do enough to export from a system with new UI framework  
to another system with same UI framework, but more than just  
fileOut/fileIn of source code. Perhaps just enough to make one system  
[computer] that can serve components to clients via some connection.

:)

>
>> - 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

Sure.

>> - 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

Sounds good. But raises questions, what+how. Roles? More general? More  
specific?


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

        a concise (programmatic) construction framework would be nice as a basis
for graphical tools. Code generation-reintegration is, IMHO, more flexible
and explict than live prototypes. It is alway good to know that there is a
basis for recreating a (specific) UI for a system. Similar to the concept of
the image, good to know that it can (essentially) be regenerated if
corruption problems occur.

>
> 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
> framework for Squeak.  Any flaws?  It is a lot of wasted work to write
> and then have someone else rewrite a framework, but it might solve the
> problem.  At least the rewrite would occur with the benefit of tests.
>

        MVP, as I remember, predates Dolphin in research terms...

> With some cleverness, Morphs as views, native widgets, SVG, etc., are
> hopefully just different types of views in the framework.
>

        Indeed, though a mechanism (call it a theme or configuration perhaps) to
bind a coherent set of things together will help. If things are
cross-pluggable then it should be easy to mix-n-match to suit any need.

> As a practical matter, I have a few too many Squeak images for my own
> good.  I need to archive them all, mine code out of them, and create one
> image that will move back and forth between Linux and Windows.  Any
> thoughts on 3.9 vs. 3.10?  For 3.9, I would want the
> delay/queue/semaphore fixes; IIRC, those are included in 3.10??
>
> Bill

        Since I'm currently working on deployment to customers I'll be sticking
with 3.9 (fixes applied) for the moment. Others in the office are on the
3.10 dev beta images. Once our release is stable we'll migrate to 3.10 in
the background, I don't forsee any real problems, not the right time to
abandon 3.9 for our deliverables just yet.

        Found another process related bug i may have to air in the dev list. Looks
like Process>>isTerminated is not thread safe/and/or correct. Have has
instances where a live process has responded "true" to isTerminated,
briefly! (we are using quite a few processes at various priorities -
preemption bites!)

        For me, for a fresh start, I'd like to start at "the bottom", basic
drawing/interation (Cairo/BitBlt/Balloon/GTK etc). Perhaps we can meet
halfway...


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

I think basing a UI on SVG would be a great idea. Proper rounded corners for
a start ;-) Not to mention, being vector-based for adapting to
screen/printer/visual-device resolution. As the thme stuff has gone on,
generally resticting to shapes/gradients has worked well. Of course, some
things are easier with bitmaps but that's down to the current (somewhat)
limited support for vector graphics in Balloon.

I might dig out the old-slow-code I did for SVG on top of Balloon...
(SVGMorph on SqueakMap).
Was pretty experimental but had at least one satisfied user!



Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

Gary,

MVP indeed predates OA's work, but I have to walk a fine line of making
something compatible and untainted.  I do not think I can serve as a
coder on a clean version.  Tests I can write and distribute.

As for you starting at the bottom and me at the top, that's perfect!
You clearly have great skill at graphical coding, and have a lot of MVP
work that can stress test my (non-existent, so far) MVP framework; I
also have meta data->code translators that can push it.  A design goal
should be to allow the view hierarchy to change; OA anticipated that,
and it makes sense to continue and extend it.  If the effort succeeds,
we can begin work on a clean room version knowing that success is
possible.

3.9 it is.  I am very pleased to see you also using processes.  The
first tangible system I would be likely to port is a serial
communication multiplexer.  It makes heavy use of streams[*], and
arguably heavy use of processes.  The latter is murky to me, as my
earliest evaluations of Squeak included a reality check on the scheduler
and synchronization; at the time people reported dwarfing my
requirements without problems.  The more recent "fix this or we switch
to Java" discussions were unsettling, though you reported having
improved results with the resulting patches.

[*] I would very much like to put teeth into EndOfStream.  I might even
see how to do it.  As I see it, silent truncation by #next: is an
accident waiting to happen, and exception handling is the answer.  The
problem would be getting it accepted.

Bill





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

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> [hidden email] 11/20/07 10:06 AM >>>


        a concise (programmatic) construction framework would be nice as
a basis
for graphical tools. Code generation-reintegration is, IMHO, more
flexible
and explict than live prototypes. It is alway good to know that there is
a
basis for recreating a (specific) UI for a system. Similar to the
concept of
the image, good to know that it can (essentially) be regenerated if
corruption problems occur.

>
> 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
> framework for Squeak.  Any flaws?  It is a lot of wasted work to write
> and then have someone else rewrite a framework, but it might solve the
> problem.  At least the rewrite would occur with the benefit of tests.
>

        MVP, as I remember, predates Dolphin in research terms...

> With some cleverness, Morphs as views, native widgets, SVG, etc., are
> hopefully just different types of views in the framework.
>

        Indeed, though a mechanism (call it a theme or configuration
perhaps) to
bind a coherent set of things together will help. If things are
cross-pluggable then it should be easy to mix-n-match to suit any need.

> As a practical matter, I have a few too many Squeak images for my own
> good.  I need to archive them all, mine code out of them, and create
one
> image that will move back and forth between Linux and Windows.  Any
> thoughts on 3.9 vs. 3.10?  For 3.9, I would want the
> delay/queue/semaphore fixes; IIRC, those are included in 3.10??
>
> Bill

        Since I'm currently working on deployment to customers I'll be
sticking
with 3.9 (fixes applied) for the moment. Others in the office are on the
3.10 dev beta images. Once our release is stable we'll migrate to 3.10
in
the background, I don't forsee any real problems, not the right time to
abandon 3.9 for our deliverables just yet.

        Found another process related bug i may have to air in the dev
list. Looks
like Process>>isTerminated is not thread safe/and/or correct. Have has
instances where a live process has responded "true" to isTerminated,
briefly! (we are using quite a few processes at various priorities -
preemption bites!)

        For me, for a fresh start, I'd like to start at "the bottom",
basic
drawing/interation (Cairo/BitBlt/Balloon/GTK etc). Perhaps we can meet
halfway...


_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui