Is there a technical automated upgrade path from Digitalk to VW?
How does this work from the financial point of view? Victor |
First will not call it upgrade but migration.. Nothing beyond to my knowledge exists in smalltalk migration automated, except for what Synchrony System purports to offer.. ( that too either from VisualAge to VW/Java.. that itself is semi-automated)
My approach for a similar framework has been to run the converter from source dialect code to XML ( preferably runtime realization of it) and then run the conversion other way XML to target dialect. This will offer future extensions in much more modular way then straight conversions..
From a framework standpoint over a 6-18 month period one can achieve about 30-75%( maybe 90%) automation.. of this framework capability to convert code.. but I guess the balance of 10-25%+ code will have to be dealt with manually. Fully automated conversion can work if the source dialect code is within a known minimal boundary of api's viz: only GUI, DB and nothing more.. each additional API it calls/uses.. will add to its complexity viz: distributed computing/ WebServices/FFI/ etc...
Using services of someone/unit conversant with both dialects thoroughly would help shrink effort/timeframes and perhaps be an essential minima unless the source program is a very basic code.
regards skrishnamachari On 7/3/07,
Victor <[hidden email]> wrote: Is there a technical automated upgrade path from Digitalk to VW? |
Sudhakar Krishnamachari ha scritto:
> First will not call it upgrade but migration.. > > I guess Rossetta XML interchange format will offer the very basic > file-in capability.. beyond that there are innumerable challenges of > migration as even dialects of Smalltalk have very significant > differences apart from the common "ANSI/Smalltalk-80" base. > > Nothing beyond to my knowledge exists in smalltalk migration automated, > except for what Synchrony System purports to offer.. ( that too either > from VisualAge to VW/Java.. that itself is semi-automated) > > My approach for a similar framework has been to run the converter from > source dialect code to XML ( preferably runtime realization of it) and > then run the conversion other way XML to target dialect. This will offer > future extensions in much more modular way then straight conversions.. > > From a framework standpoint over a 6-18 month period one can achieve > about 30-75%( maybe 90%) automation.. of this framework capability to > convert code.. but I guess the balance of 10-25%+ code will have to be > dealt with manually. Fully automated conversion can work if the source > dialect code is within a known minimal boundary of api's viz: only GUI, > DB and nothing more.. each additional API it calls/uses.. will add to > its complexity viz: distributed computing/ WebServices/FFI/ etc... > > Using services of someone/unit conversant with both dialects thoroughly > would help shrink effort/timeframes and perhaps be an essential minima > unless the source program is a very basic code. > > > regards > skrishnamachari > > > On 7/3/07, * Victor* <[hidden email] > <mailto:[hidden email]>> wrote: > > Is there a technical automated upgrade path from Digitalk to VW? > How does this work from the financial point of view? > > Victor > My 0,02 Euro : many years ago I switched some hundreds of classes from Digitalk to another Smalltalk target platform and was a live-running (we didn' stop and branch the development) and semi-automated process (with a Smalltalk language scanner and a handful of little scripts). The first step was loading all our classes under ... Squeak (with some SystemDictionary trickery). Of course the system it didn't run under Squeak, but can be loaded on the target environmnt, so we fired the second step : we factored, duplicated and splitted the OS-related classes (or even methods) and "profiled" the switching (one-liner) methods in two big file-ins, one for Digitalk/OS2 and one for Visualage/Windows. And it worked very well : after seven years and the death of OS/2 my former colleagues still develop (and sell ...) that system (a graphical job shop scheduler). The "switching" architecture (tied mainly to the presentation layer) was eventully removed after the last OS/2 customer updated the system. The elapsed time was around one year with two people involved (not full time), one for the architecture (I) and one very very very skilled on the target environmnent (ciao Luca !!!). Your mileage can vary : that system was very structured and the "presentation" related classes were well localized and encapsulated; maybe you'll need some refactory in advance. Best wishes, and if you need some more detail ... drop me two lines. Davide (working now on the Jxxx side of object oriented ...) -- Ing. Davide Grandi [hidden email] |
In reply to this post by skrish
Victor, Synchrony offers a migration path from VSE
to VW. We’ve done this sort of migration in the past. Indeed, this is not just code translation.
From the perspective of language, there’s very little difference between
the dialects in terms of syntax. However, as Skrishnamachari
states, it is a migration and not a wizard-like, click-on-the-button solution. Synchrony provides a complete solution for transforming an application
from one Smalltalk dialect to another and fully supports the entire lifecycle of
coexistence between ongoing development and migration. Our technology is also
licensable and with some training and mentoring, a large portion of the
migration can be done by the customer. Feel free to visit our website http://www.sync-sys.com
and contact us directly for more information. From: Sudhakar
Krishnamachari [mailto:[hidden email]] First will not call it upgrade but migration.. I guess Rossetta XML interchange format will offer the very basic
file-in capability.. beyond that there are innumerable challenges of migration
as even dialects of Smalltalk have very significant differences apart from the
common "ANSI/Smalltalk-80" bas. Nothing beyond to my knowledge exists in smalltalk migration automated,
except for what Synchrony System purports to offer.. ( that too either from
VisualAge to VW/Java.. that itself is semi-automated) My approach for a similar framework has been to run the converter from
source dialect code to XML ( preferably runtime realization of it) and then run
the conversion other way XML to target dialect. This will offer future
extensions in much more modular way then straight conversions.. From a framework standpoint over a 6-18 month period one can achieve
about 30-75%( maybe 90%) automation.. of this framework capability to convert
code.. but I guess the balance of 10-25%+ code will have to be dealt with
manually. Fully automated conversion can work if the source dialect code is
within a known minimal boundary of api's viz: only GUI, DB and nothing more..
each additional API it calls/uses.. will add to its complexity viz: distributed
computing/ WebServices/FFI/ etc... Using services of someone/unit conversant with both dialects thoroughly
would help shrink effort/timeframes and perhaps be an essential minima unless
the source program is a very basic code. regards skrishnamachari On 7/3/07, Victor
<[hidden email]>
wrote: Is there a technical
automated upgrade path from Digitalk to VW?
|
Free forum by Nabble | Edit this page |