RE: methods for license conversion

---

> From: [hidden email]

---

Don't get caught with egg on your face.    Play Chicktionary! 

J J schrieb: Morphic is what exists for Squeak.
Alas designing and implementing a new (and powerful) GUI framework is
not an easy job. Have a look at Widgetry, VW's new GUI framework.
It has been designed and implemented for quite a long time. It took more
than a year and isn't even finished yet!
It is easy to be dissatisfied with what Morphic has become over the
years. And it is easy to talk and dream of a better world but
who has the time, energy and resources to actually do it?
There have been several attempts to enhance Morphic thus far (Zurgle
comes to my mind). None of these tries were successful (in that it is
used e.g. in Squeak itself nowadays). Most of these projects are starved
in an unfinished state. Most of them are abandoned now (at least to my
knowledge).
Oh, and what happened to Tweak? It was traded as a candidate for
replacing Morphic...

I think that refactorings, corrections and reductions in Morphic are
more promising as long as Squeak is a pet for most of the community members.

Andreas

Andreas Wacknitz wrote:
> Oh, and what happened to Tweak? It was traded as a candidate for
> replacing Morphic...

What about it? It's being used successfully in Croquet.

Cheers,
   - Andreas

Andreas Raab schrieb:
> Andreas Wacknitz wrote:
>> Oh, and what happened to Tweak? It was traded as a candidate for
>> replacing Morphic...
>
> What about it? It's being used successfully in Croquet.
>
I have no doubts. But I haven't heard anything about Tweak as a
replacement candidate for Morphic lately.

Regards
Andreas

---

> Date: Mon, 9 Jul 2007 02:10:24 +0300
> From: [hidden email]
> To: [hidden email]
> Subject: Re: methods for license conversion
>
> I implemented a scratch replacement of Canvas/Display stuff to use GL
> via FFI for drawing morphic with squeak. Premiliary, based on rough
> calculations it renders desktop 3 to 5 times faster than currently
> used Balloon/BitBlt.

Even using FFI, it is so much faster?  I was under the impression that FFI was itself slow?  What would happen if a plugin were made the GL calls?  How much faster do you think that would make it (if any)?

---

PC Magazine’s 2007 editors’ choice for best web mail—award-winning Windows Live Hotmail. Check it out!

On 21/07/07, J J <[hidden email]> wrote: I examined how FFI callout implemented. There are many tests to ensure
that you calling FFI function with sane parameters, also, most of them
require a conversion (or coercion) to corresponding to C types.
I don't think that primitives will be faster than ffi - you still need
to perform same checking and type conversions for each external
function you call.
Also, someone may be tempted to implement plugin with primitives which
have higher level API, than OpenGL have, but i simply against this
approach. Yes, we can gain substantional speed boost using primitives,
but for this we need to design own architecture and support it, extend
it , and debug it e.t.c.
All this leads to bulk and poorly manageable C code. Even if someone,
having tons of free time and dedication, will implement plugin to use
GL, i'll still will not use it, because of reasons above.

> ________________________________
> PC Magazine's 2007 editors' choice for best web mail—award-winning Windows
> Live Hotmail. Check it out!
>
>
>

On Jul 21, 2007, at 1:10 AM, sig wrote:

> All this leads to bulk and poorly manageable C code. Even if someone,
> having tons of free time and dedication, will implement plugin to use
> GL, i'll still will not use it, because of reasons above.


In my experience in building plugins versus FFI calls, the number of  
people willing to build plugins
and maintain them is about mmm about 4 people, or some other really  
small number. If there is a
bug then the probability it will get fixed is *low* and the  
probability that just anyone can fix it is even
lower. This might sound a bit harsh but it's I think reality.

However with FFI the probability that just anyone can fix a bug  
becomes very high, also distributing
that fix is high too. People debate if it's slower, fine run away and  
do some benchmarks. Unless you're
doing 100 million calls you won't be able to see any difference.

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===