Smalltalk › Cincom › VisualWorks

[vwnc] Platform priorities

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 46 messages Options
123
Travis Griggs-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Travis Griggs-3
On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:

> A major change in VM graphics support would be a new major number,  
> so there would be no expectation of backwards compatibility. Some of  
> the 7.* VMs have broken backward compatibility anyway in some way.

So, I'm curious, just as a thought experiment. I can completely  
guarantee, that this is completely Travis talking in a "what if" sort  
of way, with absolutely no prior discussion about this with any one  
else from Cincom, so you don't have to worry about what this portends.

What if the next few VW releases, at *most* a year apart, possibly  
less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They  
wouldn't be backwards compatible, they may require some work to  
upgrade code, but it couldn't be too bad, because the release cycle  
was kept smaller (incremental) and we have the onus of having to make  
the IDE and other tools work with any changes (eat our own dogfood).  
But without the bw compat constraint, progress might be made quicker.

Just curious.

--
Travis Griggs
Objologist
"An idea, like a ghost, must be spoken to a little before it will  
explain itself." - Charles Dickens

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Dennis smith-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Dennis smith-4
We'll take that as a cincom commitment of course :)

I guess it depends on what you mean by "not backwards compatible".
With more than 1000 GUI's, painted not built with code, and with some code-built GUI bits,
we were definitely concerned about the work that we foresaw with Widgetry, but were mentally planning
for it.

So again, it depends (for me) on exactly how its "not bw".

We will of course live with whatever comes ...

Travis Griggs wrote: 
On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:

  
A major change in VM graphics support would be a new major number,  
so there would be no expectation of backwards compatibility. Some of  
the 7.* VMs have broken backward compatibility anyway in some way.
    

So, I'm curious, just as a thought experiment. I can completely  
guarantee, that this is completely Travis talking in a "what if" sort  
of way, with absolutely no prior discussion about this with any one  
else from Cincom, so you don't have to worry about what this portends.

What if the next few VW releases, at *most* a year apart, possibly  
less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They  
wouldn't be backwards compatible, they may require some work to  
upgrade code, but it couldn't be too bad, because the release cycle  
was kept smaller (incremental) and we have the onus of having to make  
the IDE and other tools work with any changes (eat our own dogfood).  
But without the bw compat constraint, progress might be made quicker.

Just curious.

--
Travis Griggs
Objologist
"An idea, like a ghost, must be spoken to a little before it will  
explain itself." - Charles Dickens

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Randy Coulman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Randy Coulman
In reply to this post by Travis Griggs-3

On Mon, Nov 30, 2009 at 4:52 PM, Travis Griggs <[hidden email]> wrote:

What if the next few VW releases, at *most* a year apart, possibly
less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They
wouldn't be backwards compatible, they may require some work to
upgrade code, but it couldn't be too bad, because the release cycle
was kept smaller (incremental) and we have the onus of having to make
the IDE and other tools work with any changes (eat our own dogfood).
But without the bw compat constraint, progress might be made quicker.


We tend to keep VMs and images in sync, so this wouldn't be a problem for us.  As long as the porting effort was reasonably small, we'd even be able to keep up, I think.

Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
James Robertson-7
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

James Robertson-7
In reply to this post by Steven Kelly
Bear in mind that way back in the day, we compiled the libraries for Oracle and Sybase into the VM on Unix platforms.  The problem with that was that we often ended up a couple of release cycles behind those vendors, and customers would wonder why they were stuck on a specific DB library version.

I fear that compiling the cairo libs into the VM would lead us to the same place, and ultimately, back to the same shared library decision we came to back then.



The CairoGraphics package might get integrated directly into
visual.im, or even base.im, who knows. But the C library will not be
compiled into the VM.

:-(.

The drawback of this, is that you get away from the "it's just one
executable" model. Which we didn't have anyway because of the image.

At least on Windows we do, with reshacker and visual.exe.

Alan pointed out to me that MPL actually might allow us to link the
cairo libs with the VM. Would have to do some more research, but it
might be possible. Still not sure it's desirable from all pov, but
it's interesting.

:-). It would certainly bear looking at!

Do you intend for the VM to continue to do drawing the old way (e.g. GDI
on Windows), so Cairo will remain an optional add-on - quite possibly
requiring different calls to use?

Or since Cairo is a superset of the VM's current graphics support, and
following similar logic to Eliot and Andre earlier, would it be
relatively easy (or at least efficient) to completely replace the
current graphics primitives with Cairo?

Or would it be best to take this opportunity to rewrite the whole of the
GraphicsContext tree? Either just with a more modern approach and Cairo
primitives, or to move many things up from the VM to the image?

Cheers,
Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


James Robertson
Cincom Smalltalk Product Evangelist
Talk Small and Carry a Big Class Library





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Travis Griggs-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Travis Griggs-3
In reply to this post by Travis Griggs-3
On Nov 30, 2009, at 3:42 PM, Travis Griggs wrote:

>>
>> I'm delighted to see the work on Cairo and OpenGL, and hope
>> functionality like that makes its way into the base graphics system
>> of VW soon. IMHO having bolt-on DLLs etc. doesn't work for the cross
>> platform story: downloading and maybe even compiling 3rd party DLLs
>> for several different platforms is acceptable for preview code, but
>> not in production - at least not for a core component of the system
>> like graphics.

And here's my other off the wall disavowed question. In the continued  
interest of "tuning" some of the great feedback we've been getting on  
this and other threads.

Here is a list of supported platforms for VisualWorks 7.7. Or at least  
close, I've probably got an error or two in here:

Windows 2000+
MacOS X 10.4+
MaxOS X - X11
HP-UX 11.11+
IBM AIX 5.2+
Linux32/x86 (2.4 kernel, up to ancient versions of X11)+
Linux64/x86 (2.4 kernel, up to ancient versions of X11)+
Linux32/PPC (2.4 kernel, up to ancient versions of X11)+
Solaris/Sparc32 8+
Solaris/Sparc64 8+


We provide a turnkey precompiled library for Cairo for the first two  
in the list. Getting that was not too hard, but it IS work. Work that  
will go on. As we move into these other platforms, it gets harder.  
Since people don't do snazzy desktop development of ANY sort of AIX,  
especially 5.2 (2004), then there's not a lot of support for getting  
Cairo compiled there. I'm sure it's doable, but it gets harder and  
harder as we move in to these platforms. E.g, Cairo working Solaris  
10, is something a number of people have demonstrated is doable, doing  
it on 8, is a tougher proposition.

Given the enthusiasm to see Cairo integrated to a higher degree, how  
much effort does Cincom put into making it work on these other  
platforms? Which ones? Do we consign some of them to only headless/
server environments? Do we support it on just some platforms, which  
means we won't use it at all in any of our core tools probably, and  
therefore we won't "eat our own dogfood" as well?

--
Travis Griggs
Objologist
For every adage, there is an equal and contrary un-adage

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Joachim Geidel
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Joachim Geidel
In reply to this post by Steven Kelly

Am 01.12.09 01:28 schrieb Steven Kelly:
> Or would it be best to take this opportunity to rewrite the whole of the
> GraphicsContext tree?

Two years ago, I experimented with a CairoWrapper which would automagically
render all its components with Cairo instead of the VM primitives. Some
widgets need a couple of additional methods, and ComposedText would have to
be rewritten (have a look at what happens during text layout, and you'll
agree). My conclusion was that it would be feasible to switch over to Cairo
without too much effort. Rewriting ComposedText and its neighborhood will be
the most expensive part of this.

The experimental code is in the public repository:

CairoGraphics-Wrappers
CairoGraphics-Wrappers-Examples
CairoGraphics-Widgets
CairoGraphics-Windows

This was done with VW 7.5 and Cairo 1.4. I don't know if the code is
compatible with the latest versions of VW, CairoGraphics and the Cairo
library.

The experiment went as far as switching a whole image to Cairo :-) by
evaluating

  CairoGraphics.UseCairoForAllWindows := true.

If you search the archives of vwnc for the subject "Cairofying VisualWorks"
of Oct 28, 2007, you'll find my summary of the experiment and a screenshot
of a Refactoring Browser drawn with Cairo.

Cheers,
Joachim Geidel
 


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Steven Kelly
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Steven Kelly
In reply to this post by Steven Kelly
Travis Griggs wrote:
> What if the next few VW releases, at *most* a year apart, possibly
> less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They
> wouldn't be backwards compatible, they may require some work to
> upgrade code, but it couldn't be too bad, because the release cycle
> was kept smaller (incremental) and we have the onus of having to make
> the IDE and other tools work with any changes (eat our own dogfood).
> But without the bw compat constraint, progress might be made quicker.

The VM doesn't need to be backwards compatible. If the image isn't going
to be backwards compatible with our code, we'd like to know about it
early, so we can adjust our own development, or maybe have an influence
on Cincom's decisions about backwards compatibility.

The downside for Cincom would be when they need to back-port VM bug
corrections to several versions, as part of supporting older VM
versions. If you keep the VM build environments for each release, that
shouldn't be a big problem.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Steven Kelly
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Steven Kelly
In reply to this post by Steven Kelly
James Robertson wrote 01 December 2009 04:04:
> Bear in mind that way back in the day, we compiled the libraries for
> Oracle and Sybase into the VM on Unix platforms.  The problem with that
> was that we often ended up a couple of release cycles behind those
> vendors, and customers would wonder why they were stuck on a specific
> DB library version.
>
> I fear that compiling the cairo libs into the VM would lead us to the
> same place, and ultimately, back to the same shared library decision we
> came to back then.

In effect, the current Windows VM is equally locked in to the ancient Windows GDI library. Customers do indeed wonder why it hasn't been updated ;-).

Currently we can choose between "vwnt.exe + vwntoe.dll" or a single visual.exe, which effectively includes the DLL. Maybe Cairo could work in a similar way? Those who want the latest and greatest could use vwnt.exe + vwntoe.dll + cairo.dll (supplied by Cincom, but download or compile your own if you like), but visual.exe would contain everything.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Steven Kelly
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Steven Kelly
In reply to this post by Steven Kelly
> Here is a list of supported platforms for VisualWorks 7.7. Or at least
> close, I've probably got an error or two in here:
>
> Windows 2000+
> MacOS X 10.4+
> MaxOS X - X11
> HP-UX 11.11+
> IBM AIX 5.2+
> Linux32/x86 (2.4 kernel, up to ancient versions of X11)+
> Linux64/x86 (2.4 kernel, up to ancient versions of X11)+
> Linux32/PPC (2.4 kernel, up to ancient versions of X11)+
> Solaris/Sparc32 8+
> Solaris/Sparc64 8+
>
>
> We provide a turnkey precompiled library for Cairo for the first two
> in the list. Getting that was not too hard, but it IS work. Work that
> will go on. As we move into these other platforms, it gets harder.

As long as Cairo was (is?) an experiment, it was fine to support only
certain platforms. Whatever happens to Cairo, VW definitely needs a
major overhaul of its graphics capabilities. For that to work, the new
facilities need to completely replace the old ones. You simply don't
have the resources to support two radically different graphics engines
on every platform (I only presume to tell you this because I'm sure you
know it anyway!).

If Cairo is to be the new engine - and it looks the best bet at the
moment - it would ideally work everywhere. Getting the X11 version
working would probably cover most of the work for the remaining
platforms, so the situation perhaps isn't as bad as it looks (based on
what I understand of the similarities in current graphics code in the VM
for those X11 platforms).

If there is a real show-stopper in getting Cairo working on the *nix
platforms, I suppose you'd have to consider keeping it in the VM, so you
can better hide the difference between Cairo and non-Cairo platforms.
The non-Cairo platforms simply wouldn't support alpha, antialiasing
etc., and would draw gradient fills with a single colour.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Holger Kleinsorgen-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Holger Kleinsorgen-4
In reply to this post by Travis Griggs-3
Travis Griggs wrote:
>  From a low level point of view, what you see in preview, is the basic  
> approach we *will* stick to with Cairo. We provide a precompiled DLL.  
> You don't have to download it, you don't have to compile it. It's  
> placed right next to your VM, so you don't even have to move it, other  
> than if you move the VM, you have to move the dll along with it.
>
> The CairoGraphics package might get integrated directly into  
> visual.im, or even base.im, who knows. But the C library will not be  
> compiled into the VM.

dynamically linking the Cairo library is IMHO an advantage. If Cairo
evolves (new features, bugfixes, performance improvements), we can
immediately switch to the new version, instead of having to wait for the
next VM build (which might include other "unwanted" changes).

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Andre Schnoor
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Andre Schnoor
In reply to this post by Travis Griggs-3

Am 01.12.2009 um 01:52 schrieb Travis Griggs:

> What if the next few VW releases, at *most* a year apart, possibly
> less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They
> wouldn't be backwards compatible, they may require some work to
> upgrade code, but it couldn't be too bad, because the release cycle
> was kept smaller (incremental) and we have the onus of having to make
> the IDE and other tools work with any changes (eat our own dogfood).
> But without the bw compat constraint, progress might be made quicker.

That's a thought into the right direction, IMO.

I always dreamt of a spin-off redone from scratch, based on the "best  
of" we currently have, getting rid of old stuff that gets in the way  
of a lean and modern Smalltalk platform. That would mean carrying  
everything to the current state of the art without worrying about  
backwards compatibility.

Eventually existing VW apps could be ported/moved to that next  
generation platform incrementally. It shouldn't be too hard to fire up  
some tools that translate to new idioms.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Holger Kleinsorgen-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Holger Kleinsorgen-4
In reply to this post by Travis Griggs-3
Travis Griggs wrote:
> On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:
>

> What if the next few VW releases, at *most* a year apart, possibly  
> less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They  
> wouldn't be backwards compatible, they may require some work to  
> upgrade code, but it couldn't be too bad, because the release cycle  
> was kept smaller (incremental) and we have the onus of having to make  
> the IDE and other tools work with any changes (eat our own dogfood).  
> But without the bw compat constraint, progress might be made quicker.

If there are changes that are not backwards compatible, upgrading has to
be worth the effort, either for our customers, or us as developers
(perferably both ;).  Changes are not bad. Backwards compatibility has a
price, too.

Besides, switching to a new VW release already means adjusting various
packages. These are usually either development tools/extensions, or base
patches.

If the changes consist of code cleanups/changes that make it "just"
easier for Cincom to implement other stuff, or just feel better, then
answer would be probably "no", though.  That doesn't mean that those
changes are not welcome, or not necessary.


Additionaly, to maintain the current stable release, this release model
could be a accompanied by a "public patch repository":

- upon release, the whole supported code base is published to a
repository (read-only)

- patches are published to this repository.

This way, patches are more visible and easier to fetch than from the
resoultion portal, which I strongly dislike because it's a totally
seperate system.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Maarten Mostert-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Maarten Mostert-2
In reply to this post by Eliot Miranda-2

It would be really interesting to know what cincoms engineering team is thinking about this subject:

http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003405.html

If I understand this corrently (not sure though) this solution can theoretically be integrated int he VW and then
provide a true solution for animations which as we all know are an integral part of modern UI's.

@+Maarten,


> Message du 30/11/09 01:46
> De : "Eliot Miranda"
> A : "vwnc NC"
> Copie à :
> Objet : Re: [vwnc] Platform priorities
>
> On Sun, Nov 29, 2009 at 3:33 PM, Andre Schnoor  wrote:
>
> >
> > Am 29.11.2009 um 21:55 schrieb Eliot Miranda:
> >
> > And for that you get to discard the event queue road block in the VM and
> > hook up to native event pumps. What would make that much easier is throwing
> > away my overengineered and underperformant threaded FFI in place of David
> > Simmons' architecture that I've recently implemented in Squeak. But that
> > can be done independently in parallel.
> >
> > That'll be a huge step towards a much smaller much more focussed VM which
> > doesn't get in the way of APIs and concentrates on providing effective fast
> > and simple access to them.
> >
> >
> > I absolutely agree, but, at least on the Mac this would need a natively
> > multi-threaded VM, as all GUI code is required to run on the thread that
> > owns the event loop. This can not be achieved with green threads.
> >
>
> I'm not talking about green threads ;) See
> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003405.html
>
>
> > Andre
> >
> >
>
>
> [ (pas de nom de fichier) (0.1 Ko) ]


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Mike Hales
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Mike Hales
In reply to this post by Travis Griggs-3
I would gladly trade a little more work in porting/upgrading to a new release for an acceleration in progress in the base system. Especially with regards to GUI and graphics.

What if the next few VW releases, at *most* a year apart, possibly
less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They
wouldn't be backwards compatible, they may require some work to
upgrade code, but it couldn't be too bad, because the release cycle
was kept smaller (incremental) and we have the onus of having to make
the IDE and other tools work with any changes (eat our own dogfood).
But without the bw compat constraint, progress might be made quicker.




Mike Hales
Engineering Manager
KnowledgeScape
www.kscape.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
thomas.hawker
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

thomas.hawker
In reply to this post by Travis Griggs-3

Travis,

 

While I’m all for more frequent releases, especially for bug fixes and incremental improvements and additions to the technology base, I don’t see that it will be practical to limit backward compatibility.  The problem with your approach is that, in order to avoid major migration hassles, you have to move your code base every new release, at worst every other release.  Our enterprise client is still running VW5i!  We’re planning on moving it to VW7.7 next year, but the project is formidable.  (We’ve already put more than a couple of man-years on it and haven’t yet gotten to a reliable, testable code base.)  With VW7.7 I have to rewrite all of my Store extensions from VW7.6 because of the switchover to Glorp.

 

Some level of backward compatibility is a must.  We might not need that much at the VM level, but we can’t afford to do major platform (hardware or software) upgrades more than once every three years.  The kind of effort involved requires significant scheduling and planning – typically on the order of 9 months or so.  If you had VW releases every 6-9 months, we’d be 3+ releases behind every time we scheduled a migration.  Extensive BWC support would be essential!

 

Cheers!

 

Tom Hawker

--------------------------

Senior Framework Developer

--------------------------

Home        +1 (408) 274-4128

Office      +1 (408) 576-6591

Mobile      +1 (408) 835-3643

 

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs
Sent: Monday, November 30, 2009 4:52 PM
To: VWNC List
Subject: Re: [vwnc] Platform priorities

 

On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:

 

> A major change in VM graphics support would be a new major number, 

> so there would be no expectation of backwards compatibility. Some of 

> the 7.* VMs have broken backward compatibility anyway in some way.

 

So, I'm curious, just as a thought experiment. I can completely 

guarantee, that this is completely Travis talking in a "what if" sort 

of way, with absolutely no prior discussion about this with any one 

else from Cincom, so you don't have to worry about what this portends.

 

What if the next few VW releases, at *most* a year apart, possibly 

less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They 

wouldn't be backwards compatible, they may require some work to 

upgrade code, but it couldn't be too bad, because the release cycle 

was kept smaller (incremental) and we have the onus of having to make 

the IDE and other tools work with any changes (eat our own dogfood). 

But without the bw compat constraint, progress might be made quicker.

 

Just curious.

 

--

Travis Griggs

Objologist

"An idea, like a ghost, must be spoken to a little before it will 

explain itself." - Charles Dickens

 

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
thomas.hawker
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

thomas.hawker

I’ve spent the past couple of days reading through this entire list.  In terms of GUI upgrades, especially for native widgets, could someone please explain why that is really so infeasible?  I must be dense, so could you use small words?  J  While it may take a release or two to get there, it seems that we have all of the pieces [or thought experiments] in place to do it:

 

  1. Move the GUI out of the VM.  Use Cairo as the base.  This permits completely headless images.
  2. For native widgets, do it all by DLL, even direct access to X11, Quartz, or whatnot.
  3. To facilitate this, resurrect Widgetry or at least move to something with cleaner structural separation.
    1. A pane could be an emulated pane or a native pane.
    2. Native artists follow, which interface to the DLL calls to do what you want.
    3. Native agents and event interaction could be facilitated by some of the multi-threaded VM discussions (such as that one by Eliot).
    4. Build hierarchical and peer packages, so that you can move [gradually] to full implementation while providing immediate functionality where you can.
  4. I would add:  give serious thought on how to dynamically memory-map segments to handle the chameleon effect (that is, map on reference without saving).

                                                                                                                                                              

I think one objective is to be able to do this polymorphically:  native and emulated widgets on the same window.  It can’t be such a hard thing, since an emulated widget is really nothing more than a direct draw capability to the underlying window canvas.  All the drawing primitives ultimately do that, so the adjustments should come naturally simply by moving behavior into the image.  Where we have “LookPolicy” we’d add “NativeUIPolicy” or something.

 

I’m not denying that this wouldn’t take some significant work, but at this stage it could at least be planned or prototyped.

 

Cheers!

 

Tom Hawker

Senior Framework Developer

Home

+1 (408) 274-4128

The Environment:

We take it personally

Office

+1 (408) 576-6591

Mobile

+1 (408) 835-3643

 

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.
IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Dmytryk, Igor
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Dmytryk, Igor
In reply to this post by thomas.hawker
Message
Travis,
 
I share Tom's view.  We are generally a "quiet" CINCOM customer...but this thread makes me nervous.  We tend to defer VW migrations because of the extensive effort required in the past (we are currently on 7.2).  My concern is that if previous "backward-compatible" releases were painful for us, what extra effort may be needed for a "non-backward-compatible" release?  I would hope clients like us get "consideration" during your release planning.
 
Interesting discussion.
 
Thanks,
 
Igor Dmytryk
Export Development Canada
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, December 01, 2009 1:26 PM
To: [hidden email]; [hidden email]
Subject: Re: [vwnc] Platform priorities

Travis,

 

While I’m all for more frequent releases, especially for bug fixes and incremental improvements and additions to the technology base, I don’t see that it will be practical to limit backward compatibility.  The problem with your approach is that, in order to avoid major migration hassles, you have to move your code base every new release, at worst every other release.  Our enterprise client is still running VW5i!  We’re planning on moving it to VW7.7 next year, but the project is formidable.  (We’ve already put more than a couple of man-years on it and haven’t yet gotten to a reliable, testable code base.)  With VW7.7 I have to rewrite all of my Store extensions from VW7.6 because of the switchover to Glorp.

 

Some level of backward compatibility is a must.  We might not need that much at the VM level, but we can’t afford to do major platform (hardware or software) upgrades more than once every three years.  The kind of effort involved requires significant scheduling and planning – typically on the order of 9 months or so.  If you had VW releases every 6-9 months, we’d be 3+ releases behind every time we scheduled a migration.  Extensive BWC support would be essential!

 

Cheers!

 

Tom Hawker

--------------------------

Senior Framework Developer

--------------------------

Home        +1 (408) 274-4128

Office      +1 (408) 576-6591

Mobile      +1 (408) 835-3643

 

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs
Sent: Monday, November 30, 2009 4:52 PM
To: VWNC List
Subject: Re: [vwnc] Platform priorities

 

On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:

 

> A major change in VM graphics support would be a new major number, 

> so there would be no expectation of backwards compatibility. Some of 

> the 7.* VMs have broken backward compatibility anyway in some way.

 

So, I'm curious, just as a thought experiment. I can completely 

guarantee, that this is completely Travis talking in a "what if" sort 

of way, with absolutely no prior discussion about this with any one 

else from Cincom, so you don't have to worry about what this portends.

 

What if the next few VW releases, at *most* a year apart, possibly 

less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They 

wouldn't be backwards compatible, they may require some work to 

upgrade code, but it couldn't be too bad, because the release cycle 

was kept smaller (incremental) and we have the onus of having to make 

the IDE and other tools work with any changes (eat our own dogfood). 

But without the bw compat constraint, progress might be made quicker.

 

Just curious.

 

--

Travis Griggs

Objologist

"An idea, like a ghost, must be spoken to a little before it will 

explain itself." - Charles Dickens

 

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Paul Baumann
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Paul Baumann
In reply to this post by thomas.hawker
In simple terms...
 
It is infeasible by common approach.
 
The way to eat an elephant is...one bite at a time. The Widgetry elephant couldn't be swallowed in one sitting even with several years of preparation. The problem wasn't that Sames needed more time or encouragement, but that increasingly Cincom's customers were expected to swallow really-really hard and Cincom finally came to realize that they wouldn't. End result was that Cincom practically starved itself figuring out how to consume that damn elephant in one sitting and decided to find something else to eat instead.
 
In general...
 
Focus on finding solutions to the small problems at hand; the bigger problems work themselves out over time and opportunities become easier to exploit. In an environment of Liberty, you don't need to risk for grand ambitions because you have the daily satisfaction of having taken one step closer in a direction that was demonstrably correct and practical.
 
Furthermore...
 
I want to see Cincom developers anxious to fix problems and incorporate solutions instead of being stressed by a list of scheduled requirements. The best code often comes from a useful but complicated body of code that incrementally evolved into a work of art--to a form not originally anticipated. Bad code comes from replacing one complicated mass of code with another with some new forced twist--and then needing to support both. Bad code happens from a legacy of resisting refinements to "working" code.
 
When I send a fix to Cincom, I want it released in product to customers within a month or two (this is why open-source works; not because it is "free"). There is a cost involved in sending code to Cincom instead of just hacking a workaround into place. It is cheaper to just fix the problem here and hope Cincom never changes code in a way that breaks a workaround. For several years now, that has unfortunately been the most effective approach. Fix it and forget about wasting time sharing or even communicating the fix. I'd encourage a system that makes it more practical for me to share fixes with more than an excuse in return.
 
Cincom doesn't need to eat the entire elephant, but they do have to encourage others to join them at the table and offer them a carving knife and a fork.
 
Paul Baumann 
 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, December 01, 2009 2:27 PM
To: [hidden email]; [hidden email]; [hidden email]
Subject: Re: [vwnc] Platform priorities

I’ve spent the past couple of days reading through this entire list.  In terms of GUI upgrades, especially for native widgets, could someone please explain why that is really so infeasible?  I must be dense, so could you use small words?  J  While it may take a release or two to get there, it seems that we have all of the pieces [or thought experiments] in place to do it:

 

  1. Move the GUI out of the VM.  Use Cairo as the base.  This permits completely headless images.
  2. For native widgets, do it all by DLL, even direct access to X11, Quartz, or whatnot.
  3. To facilitate this, resurrect Widgetry or at least move to something with cleaner structural separation.
    1. A pane could be an emulated pane or a native pane.
    2. Native artists follow, which interface to the DLL calls to do what you want.
    3. Native agents and event interaction could be facilitated by some of the multi-threaded VM discussions (such as that one by Eliot).
    4. Build hierarchical and peer packages, so that you can move [gradually] to full implementation while providing immediate functionality where you can.
  4. I would add:  give serious thought on how to dynamically memory-map segments to handle the chameleon effect (that is, map on reference without saving).

                                                                                                                                                              

I think one objective is to be able to do this polymorphically:  native and emulated widgets on the same window.  It can’t be such a hard thing, since an emulated widget is really nothing more than a direct draw capability to the underlying window canvas.  All the drawing primitives ultimately do that, so the adjustments should come naturally simply by moving behavior into the image.  Where we have “LookPolicy” we’d add “NativeUIPolicy” or something.

 

I’m not denying that this wouldn’t take some significant work, but at this stage it could at least be planned or prototyped.

 

Cheers!

 

Tom Hawker

Senior Framework Developer

Home

+1 (408) 274-4128

The Environment:

We take it personally

Office

+1 (408) 576-6591

Mobile

+1 (408) 835-3643

 

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.
 
IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
James Robertson-7
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

James Robertson-7
In reply to this post by thomas.hawker
Umm, Thomas: how did you write this after explaining how critical backward compatibility is?

And to be clear, Widgetry is not being resurrected.


James Robertson
Cincom Smalltalk Product Evangelist
Talk Small and Carry a Big Class Library




On Dec 1, 2009, at 2:26 PM, <[hidden email]> <[hidden email]> wrote:

I’ve spent the past couple of days reading through this entire list.  In terms of GUI upgrades, especially for native widgets, could someone please explain why that is really so infeasible?  I must be dense, so could you use small words?  J  While it may take a release or two to get there, it seems that we have all of the pieces [or thought experiments] in place to do it:

 

  1. Move the GUI out of the VM.  Use Cairo as the base.  This permits completely headless images.
  2. For native widgets, do it all by DLL, even direct access to X11, Quartz, or whatnot.
  3. To facilitate this, resurrect Widgetry or at least move to something with cleaner structural separation.
    1. A pane could be an emulated pane or a native pane.
    2. Native artists follow, which interface to the DLL calls to do what you want.
    3. Native agents and event interaction could be facilitated by some of the multi-threaded VM discussions (such as that one by Eliot).
    4. Build hierarchical and peer packages, so that you can move [gradually] to full implementation while providing immediate functionality where you can.
  4. I would add:  give serious thought on how to dynamically memory-map segments to handle the chameleon effect (that is, map on reference without saving).

                                                                                                                                                              

I think one objective is to be able to do this polymorphically:  native and emulated widgets on the same window.  It can’t be such a hard thing, since an emulated widget is really nothing more than a direct draw capability to the underlying window canvas.  All the drawing primitives ultimately do that, so the adjustments should come naturally simply by moving behavior into the image.  Where we have “LookPolicy” we’d add “NativeUIPolicy” or something.

 

I’m not denying that this wouldn’t take some significant work, but at this stage it could at least be planned or prototyped.

 

Cheers!

 

Tom Hawker
<image001.gif>
Senior Framework Developer
Home
+1 (408) 274-4128
<image002.gif>The Environment:
We take it personally
Office
+1 (408) 576-6591
Mobile
+1 (408) 835-3643

 

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.
IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Alan Knight-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [vwnc] Platform priorities

Alan Knight-2
In reply to this post by Dmytryk, Igor
Yes, clients like you certainly get consideration. Please note the first two sentences of Travis' question :-)

At 04:09 PM 2009-12-01, Dmytryk, Igor wrote:

Travis,
 
I share Tom's view.  We are generally a "quiet" CINCOM customer...but this thread makes me nervous.  We tend to defer VW migrations because of the extensive effort required in the past (we are currently on 7.2).  My concern is that if previous "backward-compatible" releases were painful for us, what extra effort may be needed for a "non-backward-compatible" release?  I would hope clients like us get "consideration" during your release planning.
 
Interesting discussion.
 
Thanks,
 
Igor Dmytryk
Export Development Canada
 
-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, December 01, 2009 1:26 PM
To: [hidden email]; [hidden email]
Subject: Re: [vwnc] Platform priorities
Travis,

 
While I’m all for more frequent releases, especially for bug fixes and incremental improvements and additions to the technology base, I don’t see that it will be practical to limit backward compatibility.  The problem with your approach is that, in order to avoid major migration hassles, you have to move your code base every new release, at worst every other release.  Our enterprise client is still running VW5i!  We’re planning on moving it to VW7.7 next year, but the project is formidable.  (We’ve already put more than a couple of man-years on it and haven’t yet gotten to a reliable, testable code base.)  With VW7.7 I have to rewrite all of my Store extensions from VW7.6 because of the switchover to Glorp.

 
Some level of backward compatibility is a must.  We might not need that much at the VM level, but we can’t afford to do major platform (hardware or software) upgrades more than once every three years.  The kind of effort involved requires significant scheduling and planning – typically on the order of 9 months or so.  If you had VW releases every 6-9 months, we’d be 3+ releases behind every time we scheduled a migration.  Extensive BWC support would be essential!

 
Cheers!

 
Tom Hawker
--------------------------
Senior Framework Developer
--------------------------
Home        +1 (408) 274-4128
Office      +1 (408) 576-6591
Mobile      +1 (408) 835-3643

 

 
-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Travis Griggs
Sent: Monday, November 30, 2009 4:52 PM
To: VWNC List
Subject: Re: [vwnc] Platform priorities

 
On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:

 
> A major change in VM graphics support would be a new major number, 

> so there would be no expectation of backwards compatibility. Some of 

> the 7.* VMs have broken backward compatibility anyway in some way.

 
So, I'm curious, just as a thought experiment. I can completely 

guarantee, that this is completely Travis talking in a "what if" sort 

of way, with absolutely no prior discussion about this with any one 

else from Cincom, so you don't have to worry about what this portends.

 
What if the next few VW releases, at *most* a year apart, possibly 

less, were a series of integral releases. VW 8, VW 9, VW 10, etc. They 

wouldn't be backwards compatible, they may require some work to 

upgrade code, but it couldn't be too bad, because the release cycle 

was kept smaller (incremental) and we have the onus of having to make 

the IDE and other tools work with any changes (eat our own dogfood). 

But without the bw compat constraint, progress might be made quicker.

 
Just curious.

 
--
Travis Griggs
Objologist
"An idea, like a ghost, must be spoken to a little before it will 

explain itself." - Charles Dickens

 
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 
IMPORTANT NOTICE


Email from OOCL is confidential and may be legally privileged. 
If it is not


intended for you, please delete it immediately unread.  The
internet


cannot guarantee that this communication is free of viruses,
interception


or interference and anyone who communicates with us by email is
taken


to accept the risks in doing so.  Without limitation, OOCL and
its affiliates


accept no liability whatsoever and howsoever arising in connection
with


the use of this email.  Under no circumstances shall this email
constitute


a binding agreement to carry or for provision of carriage services by
OOCL,


which is subject to the availability of carrier's equipment and
vessels and


the terms and conditions of OOCL's standard bill of lading which is
also


available at
http://www.oocl.com
.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
123
Free forum by Nabble Edit this page