Porting visual age applications to visualworks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Porting visual age applications to visualworks

Andrés Garagiola
Do you know any tools that could make easier porting visual age applications to visualworks?

Is there any way to find the equivalent visual works classes of visual age core classes?

For example:
    AbtTimestamp    Timestamp
    Block                 BlockClosure     
   
Those are simple examples but in other cases translation gets more complicated. For example, CfsFile is the class to handle files in visualage and visualworks uses the class Filename, and the protocol between these two classes is very different.

Thanks,
Andrés
Reply | Threaded
Open this post in threaded view
|

RE: Porting visual age applications to visualworks

szorin

Hello Andres,

 

Our company name is Synchrony Systems and we specialize in porting Smalltalk Application across Smalltalk platforms and to alternative, non-Smalltalk platforms.

The real challenge in porting VAST to VW is the user interface.

 

Our technology offers an automated, systematic and interactive way to port applications across Smalltalk platforms. We know how deal with:

 

  1. Class Library Transformation which includes classes, messages and protocols, configuration management (Envy to Store for example), Pools, etc…
  2. User Interface which includes layout, property settings and dependencies (for example connections to visual moving to aspect model in VisualWorks)

 

Depending on the size of the application, such migrations could take 6 to 12 months of effort, so they should not be underestimated.

 

For additional information, please feel to contact us directly.

 

Regards,

Slavik

 

                   

Slavik Zorin

President

Synchrony Systems, Inc.

580 White Plains Road, Suite 205

Tarrytown, NY, 10591

Tel: 1 (914) 332-7772x610

D/l: 1 (914) 703-6610

Fax: 1 (914) 332-7773

www.synchronysystems.com

 

 

 


From: Andrés Garagiola [mailto:[hidden email]]
Sent: Thursday, May 24, 2007 11:48 AM
To: [hidden email]
Subject: Porting visual age applications to visualworks

 

Do you know any tools that could make easier porting visual age applications to visualworks?

Is there any way to find the equivalent visual works classes of visual age core classes?

For example:
    AbtTimestamp    Timestamp
    Block                 BlockClosure     
   
Those are simple examples but in other cases translation gets more complicated. For example, CfsFile is the class to handle files in visualage and visualworks uses the class Filename, and the protocol between these two classes is very different.

Thanks,
Andrés

Reply | Threaded
Open this post in threaded view
|

Re: Porting visual age applications to visualworks

OCIT
ah I feel a disturbance in the force :)

Slavik:

Perhaps you could show an example of this wonderful technology at one of  
the NYC Smalltalk meetings :)

--

having said that there have been some attempts at helping this process of  
porting or Smalltalk cross - dialect portability. Rosetta comes to mind.  
Also recently I noticed our friend Bruce has shared "Sport" an effort at  
cross-dialect portability he has employed with his OpenSkills system. That  
I believe is available at the Cincom public repository. I have lost track  
of Rosetta.

I believe that there also may be some other CampSmalltalk driven efforts,  
perhaps others could chime in.

hth,

-Charles

On Thu, 24 May 2007 12:47:47 -0400, Slavik Zorin <[hidden email]>  
wrote:

> Hello Andres,
>
>
> Our company name is Synchrony Systems and we specialize in porting  
> Smalltalk
> Application across Smalltalk platforms and to alternative, non-Smalltalk
> platforms.
>
> The real challenge in porting VAST to VW is the user interface.
>
>
> Our technology offers an automated, systematic and interactive way to  
> port
> applications across Smalltalk platforms. We know how deal with:
>
>
> 1. Class Library Transformation which includes classes, messages and
> protocols, configuration management (Envy to Store for example), Pools,  
> etc…
> 2. User Interface which includes layout, property settings and
> dependencies (for example connections to visual moving to aspect model in
> VisualWorks)
>
>
> Depending on the size of the application, such migrations could take 6  
> to 12
> months of effort, so they should not be underestimated.
>
>
> For additional information, please feel to contact us directly.
>
>
> Regards,
>
> Slavik
>
>
>
> Slavik Zorin
>
> President
>
> Synchrony Systems, Inc.
>
> 580 White Plains Road, Suite 205
>
> Tarrytown, NY, 10591
>
> Tel: 1 (914) 332-7772x610
>
> D/l: 1 (914) 703-6610
>
> Fax: 1 (914) 332-7773
>
> www.synchronysystems.com <http://www.synchronysystems.com/>
>
>
>
>
>   _____
>
> From: Andrés Garagiola [mailto:[hidden email]]
> Sent: Thursday, May 24, 2007 11:48 AM
> To: [hidden email]
> Subject: Porting visual age applications to visualworks
>
>
> Do you know any tools that could make easier porting visual age  
> applications
> to visualworks?
>
> Is there any way to find the equivalent visual works classes of visual  
> age
> core classes?
>
> For example:
>     AbtTimestamp    Timestamp
>     Block                 BlockClosure
> Those are simple examples but in other cases translation gets more
> complicated. For example, CfsFile is the class to handle files in  
> visualage
> and visualworks uses the class Filename, and the protocol between these  
> two
> classes is very different.
>
> Thanks,
> Andrés
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: Porting visual age applications to visualworks

Runar Jordahl
In reply to this post by Andrés Garagiola
One important issue -- in addition to what others have mentioned -- is
source code control system. I have written a bit about the differences
between Store and Envy here:
http://www.cincomsmalltalk.com/userblogs/runarj/blogArchive?month=4&year=2004

Runar Jordahl

Reply | Threaded
Open this post in threaded view
|

RE: Porting visual age applications to visualworks

szorin
In reply to this post by OCIT
Charles:

>> Slavik:
>> ah I feel a disturbance in the force :)

I know it is not a wide-spread knowledge, but for the years we've been in
migration business, we've been talking about migrations across ALL Smalltalk
platforms. Our non-exclusive partnership with IBM produced dozens of
successfully completed migrations from all commercial Smalltalk platforms
(Dolphin included) to VisualAge Smalltalk. I've had several attempts with
Cincom in the past but they showed no interest to pursue this business.

>> Perhaps you could show an example of this wonderful technology at one of

>> the NYC Smalltalk meetings :)

I hope to take you up on your invitation to present at STUG this summer.
Of course, I appreciate the invitation also :)

>>having said that there have been some attempts at helping this process of

>>porting or Smalltalk cross - dialect portability.
>>...

The cross-dialect portability only goes so far...
If we're talking about ANSI Smalltalk, it only covers the Kernel Library
(meaning Magnitudes, Collections, Behavior, etc...). The real challenge is
how to deal with platform specific "Frameworks", 3rd party components, User
Interface, etc..., and in general, migrate between programming paradigm
shifts (e.g. event model to MVC). I am not familiar with Bruce's work. It
sounds very useful if your goal is to write portable Smalltalk code. It is
still a migration problem if you are trying to have an existing application
us this library instead of the specific library of the platform. I also lost
track of Rosetta so I cannot comment of their porting capabilities.

Regards,
Slavik


On Thu, 24 May 2007 12:47:47 -0400, Slavik Zorin <[hidden email]>  
wrote:

> Hello Andres,
>
>
> Our company name is Synchrony Systems and we specialize in porting  
> Smalltalk
> Application across Smalltalk platforms and to alternative, non-Smalltalk
> platforms.
>
> The real challenge in porting VAST to VW is the user interface.
>
>
> Our technology offers an automated, systematic and interactive way to  
> port
> applications across Smalltalk platforms. We know how deal with:
>
>
> 1. Class Library Transformation which includes classes, messages and
> protocols, configuration management (Envy to Store for example), Pools,  
> etc…
> 2. User Interface which includes layout, property settings and
> dependencies (for example connections to visual moving to aspect model in
> VisualWorks)
>
>
> Depending on the size of the application, such migrations could take 6  
> to 12
> months of effort, so they should not be underestimated.
>
>
> For additional information, please feel to contact us directly.
>
>
> Regards,
>
> Slavik
>
>
>
> Slavik Zorin
>
> President
>
> Synchrony Systems, Inc.
>
> 580 White Plains Road, Suite 205
>
> Tarrytown, NY, 10591
>
> Tel: 1 (914) 332-7772x610
>
> D/l: 1 (914) 703-6610
>
> Fax: 1 (914) 332-7773
>
> www.synchronysystems.com <http://www.synchronysystems.com/>
>
>
>
>
>   _____
>
> From: Andrés Garagiola [mailto:[hidden email]]
> Sent: Thursday, May 24, 2007 11:48 AM
> To: [hidden email]
> Subject: Porting visual age applications to visualworks
>
>
> Do you know any tools that could make easier porting visual age  
> applications
> to visualworks?
>
> Is there any way to find the equivalent visual works classes of visual  
> age
> core classes?
>
> For example:
>     AbtTimestamp    Timestamp
>     Block                 BlockClosure
> Those are simple examples but in other cases translation gets more
> complicated. For example, CfsFile is the class to handle files in  
> visualage
> and visualworks uses the class Filename, and the protocol between these  
> two
> classes is very different.
>
> Thanks,
> Andrés
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: Porting visual age applications to visualworks

OCIT
Slavik:

yes, and to be fair I know that. On the other hand I think that there may  
be the perception that your ties to IBM were so tight that porting away  
 from VA Smalltalk would not have been in your self-interest. Of course,  
perceptions are just perceptions.

In anycase , you are welcomed to try to dispel any perceptions :)

Our next slot available is at the end of June, we are off July and August  
but the Fall is pretty open at the moment, end of September would be great.

Looking forward to it, hey bring Florin along :)

-Charles


On Thu, 24 May 2007 17:14:56 -0400, Slavik Zorin <[hidden email]>  
wrote:

> Charles:
>
>>> Slavik:
>>> ah I feel a disturbance in the force :)
>
> I know it is not a wide-spread knowledge, but for the years we've been in
> migration business, we've been talking about migrations across ALL  
> Smalltalk
> platforms. Our non-exclusive partnership with IBM produced dozens of
> successfully completed migrations from all commercial Smalltalk platforms
> (Dolphin included) to VisualAge Smalltalk. I've had several attempts with
> Cincom in the past but they showed no interest to pursue this business.
>
>>> Perhaps you could show an example of this wonderful technology at one  
>>> of
>
>>> the NYC Smalltalk meetings :)
>
> I hope to take you up on your invitation to present at STUG this summer.
> Of course, I appreciate the invitation also :)
>
>>> having said that there have been some attempts at helping this process  
>>> of
>
>>> porting or Smalltalk cross - dialect portability.
>>> ...
>
> The cross-dialect portability only goes so far...
> If we're talking about ANSI Smalltalk, it only covers the Kernel Library
> (meaning Magnitudes, Collections, Behavior, etc...). The real challenge  
> is
> how to deal with platform specific "Frameworks", 3rd party components,  
> User
> Interface, etc..., and in general, migrate between programming paradigm
> shifts (e.g. event model to MVC). I am not familiar with Bruce's work. It
> sounds very useful if your goal is to write portable Smalltalk code. It  
> is
> still a migration problem if you are trying to have an existing  
> application
> us this library instead of the specific library of the platform. I also  
> lost
> track of Rosetta so I cannot comment of their porting capabilities.
>
> Regards,
> Slavik
>
>
> On Thu, 24 May 2007 12:47:47 -0400, Slavik Zorin <[hidden email]>
> wrote:
>
>> Hello Andres,
>>
>>
>> Our company name is Synchrony Systems and we specialize in porting
>> Smalltalk
>> Application across Smalltalk platforms and to alternative, non-Smalltalk
>> platforms.
>>
>> The real challenge in porting VAST to VW is the user interface.
>>
>>
>> Our technology offers an automated, systematic and interactive way to
>> port
>> applications across Smalltalk platforms. We know how deal with:
>>
>>
>> 1. Class Library Transformation which includes classes, messages and
>> protocols, configuration management (Envy to Store for example), Pools,
>> etc…
>> 2. User Interface which includes layout, property settings and
>> dependencies (for example connections to visual moving to aspect model  
>> in
>> VisualWorks)
>>
>>
>> Depending on the size of the application, such migrations could take 6
>> to 12
>> months of effort, so they should not be underestimated.
>>
>>
>> For additional information, please feel to contact us directly.
>>
>>
>> Regards,
>>
>> Slavik
>>
>>
>>
>> Slavik Zorin
>>
>> President
>>
>> Synchrony Systems, Inc.
>>
>> 580 White Plains Road, Suite 205
>>
>> Tarrytown, NY, 10591
>>
>> Tel: 1 (914) 332-7772x610
>>
>> D/l: 1 (914) 703-6610
>>
>> Fax: 1 (914) 332-7773
>>
>> www.synchronysystems.com <http://www.synchronysystems.com/>
>>
>>
>>
>>
>>   _____
>>
>> From: Andrés Garagiola [mailto:[hidden email]]
>> Sent: Thursday, May 24, 2007 11:48 AM
>> To: [hidden email]
>> Subject: Porting visual age applications to visualworks
>>
>>
>> Do you know any tools that could make easier porting visual age
>> applications
>> to visualworks?
>>
>> Is there any way to find the equivalent visual works classes of visual
>> age
>> core classes?
>>
>> For example:
>>     AbtTimestamp    Timestamp
>>     Block                 BlockClosure
>> Those are simple examples but in other cases translation gets more
>> complicated. For example, CfsFile is the class to handle files in
>> visualage
>> and visualworks uses the class Filename, and the protocol between these
>> two
>> classes is very different.
>>
>> Thanks,
>> Andrés
>>
>
>
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

RE: Porting visual age applications to visualworks

szorin
Indeed, perceptions are reality; to change reality we must change
perceptions...

We'll see if we can be ready for end of June. I know you'll need our
commitment real soon. End of September we're in Europe so it will then have
to be October.

Slavik

-----Original Message-----
From: Charles A. Monteiro [mailto:[hidden email]]
Sent: Friday, May 25, 2007 9:36 AM
To: [hidden email]; 'Andrés Garagiola'
Cc: [hidden email]
Subject: Re: Porting visual age applications to visualworks

Slavik:

yes, and to be fair I know that. On the other hand I think that there may  
be the perception that your ties to IBM were so tight that porting away  
 from VA Smalltalk would not have been in your self-interest. Of course,  
perceptions are just perceptions.

In anycase , you are welcomed to try to dispel any perceptions :)

Our next slot available is at the end of June, we are off July and August  
but the Fall is pretty open at the moment, end of September would be great.

Looking forward to it, hey bring Florin along :)

-Charles


On Thu, 24 May 2007 17:14:56 -0400, Slavik Zorin <[hidden email]>  
wrote:

> Charles:
>
>>> Slavik:
>>> ah I feel a disturbance in the force :)
>
> I know it is not a wide-spread knowledge, but for the years we've been in
> migration business, we've been talking about migrations across ALL  
> Smalltalk
> platforms. Our non-exclusive partnership with IBM produced dozens of
> successfully completed migrations from all commercial Smalltalk platforms
> (Dolphin included) to VisualAge Smalltalk. I've had several attempts with
> Cincom in the past but they showed no interest to pursue this business.
>
>>> Perhaps you could show an example of this wonderful technology at one  
>>> of
>
>>> the NYC Smalltalk meetings :)
>
> I hope to take you up on your invitation to present at STUG this summer.
> Of course, I appreciate the invitation also :)
>
>>> having said that there have been some attempts at helping this process  
>>> of
>
>>> porting or Smalltalk cross - dialect portability.
>>> ...
>
> The cross-dialect portability only goes so far...
> If we're talking about ANSI Smalltalk, it only covers the Kernel Library
> (meaning Magnitudes, Collections, Behavior, etc...). The real challenge  
> is
> how to deal with platform specific "Frameworks", 3rd party components,  
> User
> Interface, etc..., and in general, migrate between programming paradigm
> shifts (e.g. event model to MVC). I am not familiar with Bruce's work. It
> sounds very useful if your goal is to write portable Smalltalk code. It  
> is
> still a migration problem if you are trying to have an existing  
> application
> us this library instead of the specific library of the platform. I also  
> lost
> track of Rosetta so I cannot comment of their porting capabilities.
>
> Regards,
> Slavik
>
>
> On Thu, 24 May 2007 12:47:47 -0400, Slavik Zorin <[hidden email]>
> wrote:
>
>> Hello Andres,
>>
>>
>> Our company name is Synchrony Systems and we specialize in porting
>> Smalltalk
>> Application across Smalltalk platforms and to alternative, non-Smalltalk
>> platforms.
>>
>> The real challenge in porting VAST to VW is the user interface.
>>
>>
>> Our technology offers an automated, systematic and interactive way to
>> port
>> applications across Smalltalk platforms. We know how deal with:
>>
>>
>> 1. Class Library Transformation which includes classes, messages and
>> protocols, configuration management (Envy to Store for example), Pools,
>> etc…
>> 2. User Interface which includes layout, property settings and
>> dependencies (for example connections to visual moving to aspect model  
>> in
>> VisualWorks)
>>
>>
>> Depending on the size of the application, such migrations could take 6
>> to 12
>> months of effort, so they should not be underestimated.
>>
>>
>> For additional information, please feel to contact us directly.
>>
>>
>> Regards,
>>
>> Slavik
>>
>>
>>
>> Slavik Zorin
>>
>> President
>>
>> Synchrony Systems, Inc.
>>
>> 580 White Plains Road, Suite 205
>>
>> Tarrytown, NY, 10591
>>
>> Tel: 1 (914) 332-7772x610
>>
>> D/l: 1 (914) 703-6610
>>
>> Fax: 1 (914) 332-7773
>>
>> www.synchronysystems.com <http://www.synchronysystems.com/>
>>
>>
>>
>>
>>   _____
>>
>> From: Andrés Garagiola [mailto:[hidden email]]
>> Sent: Thursday, May 24, 2007 11:48 AM
>> To: [hidden email]
>> Subject: Porting visual age applications to visualworks
>>
>>
>> Do you know any tools that could make easier porting visual age
>> applications
>> to visualworks?
>>
>> Is there any way to find the equivalent visual works classes of visual
>> age
>> core classes?
>>
>> For example:
>>     AbtTimestamp    Timestamp
>>     Block                 BlockClosure
>> Those are simple examples but in other cases translation gets more
>> complicated. For example, CfsFile is the class to handle files in
>> visualage
>> and visualworks uses the class Filename, and the protocol between these
>> two
>> classes is very different.
>>
>> Thanks,
>> Andrés
>>
>
>
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: Porting visual age applications to visualworks

Dave Stevenson-2
Slavik,

Speaking of perceptions...

 > I've had several attempts with Cincom in the past but they showed no
interest to pursue this business.

Judging by your website, your SMT software does support migration
between Smalltalks (if you dig deep enough and read the small print),
but nowhere do you *advocate* it (not that I found at least). On the
contrary, you seem to be advocating migration away from Smalltalk,
implying that Java is a prerequisite to complying with industry
standards. I can't speak for Cincom on this issue, but personally this
would not seem to instill confidence in a Smalltalk vendor as a
potential partner.

Dave

Slavik Zorin wrote:

> Indeed, perceptions are reality; to change reality we must change
> perceptions...
>
> We'll see if we can be ready for end of June. I know you'll need our
> commitment real soon. End of September we're in Europe so it will then have
> to be October.
>
> Slavik
>
> -----Original Message-----
> From: Charles A. Monteiro [mailto:[hidden email]]
> Sent: Friday, May 25, 2007 9:36 AM
> To: [hidden email]; 'Andrés Garagiola'
> Cc: [hidden email]
> Subject: Re: Porting visual age applications to visualworks
>
> Slavik:
>
> yes, and to be fair I know that. On the other hand I think that there may  
> be the perception that your ties to IBM were so tight that porting away  
>  from VA Smalltalk would not have been in your self-interest. Of course,  
> perceptions are just perceptions.
>
> In anycase , you are welcomed to try to dispel any perceptions :)
>
> Our next slot available is at the end of June, we are off July and August  
> but the Fall is pretty open at the moment, end of September would be great.
>
> Looking forward to it, hey bring Florin along :)
>
> -Charles
>
>
> On Thu, 24 May 2007 17:14:56 -0400, Slavik Zorin <[hidden email]>  
> wrote:
>
>> Charles:
>>
>>>> Slavik:
>>>> ah I feel a disturbance in the force :)
>> I know it is not a wide-spread knowledge, but for the years we've been in
>> migration business, we've been talking about migrations across ALL  
>> Smalltalk
>> platforms. Our non-exclusive partnership with IBM produced dozens of
>> successfully completed migrations from all commercial Smalltalk platforms
>> (Dolphin included) to VisualAge Smalltalk. I've had several attempts with
>> Cincom in the past but they showed no interest to pursue this business.
>>
>>>> Perhaps you could show an example of this wonderful technology at one  
>>>> of
>>>> the NYC Smalltalk meetings :)
>> I hope to take you up on your invitation to present at STUG this summer.
>> Of course, I appreciate the invitation also :)
>>
>>>> having said that there have been some attempts at helping this process  
>>>> of
>>>> porting or Smalltalk cross - dialect portability.
>>>> ...
>> The cross-dialect portability only goes so far...
>> If we're talking about ANSI Smalltalk, it only covers the Kernel Library
>> (meaning Magnitudes, Collections, Behavior, etc...). The real challenge  
>> is
>> how to deal with platform specific "Frameworks", 3rd party components,  
>> User
>> Interface, etc..., and in general, migrate between programming paradigm
>> shifts (e.g. event model to MVC). I am not familiar with Bruce's work. It
>> sounds very useful if your goal is to write portable Smalltalk code. It  
>> is
>> still a migration problem if you are trying to have an existing  
>> application
>> us this library instead of the specific library of the platform. I also  
>> lost
>> track of Rosetta so I cannot comment of their porting capabilities.
>>
>> Regards,
>> Slavik
>>
>>
>> On Thu, 24 May 2007 12:47:47 -0400, Slavik Zorin <[hidden email]>
>> wrote:
>>
>>> Hello Andres,
>>>
>>>
>>> Our company name is Synchrony Systems and we specialize in porting
>>> Smalltalk
>>> Application across Smalltalk platforms and to alternative, non-Smalltalk
>>> platforms.
>>>
>>> The real challenge in porting VAST to VW is the user interface.
>>>
>>>
>>> Our technology offers an automated, systematic and interactive way to
>>> port
>>> applications across Smalltalk platforms. We know how deal with:
>>>
>>>
>>> 1. Class Library Transformation which includes classes, messages and
>>> protocols, configuration management (Envy to Store for example), Pools,
>>> etc…
>>> 2. User Interface which includes layout, property settings and
>>> dependencies (for example connections to visual moving to aspect model  
>>> in
>>> VisualWorks)
>>>
>>>
>>> Depending on the size of the application, such migrations could take 6
>>> to 12
>>> months of effort, so they should not be underestimated.
>>>
>>>
>>> For additional information, please feel to contact us directly.
>>>
>>>
>>> Regards,
>>>
>>> Slavik
>>>
>>>
>>>
>>> Slavik Zorin
>>>
>>> President
>>>
>>> Synchrony Systems, Inc.
>>>
>>> 580 White Plains Road, Suite 205
>>>
>>> Tarrytown, NY, 10591
>>>
>>> Tel: 1 (914) 332-7772x610
>>>
>>> D/l: 1 (914) 703-6610
>>>
>>> Fax: 1 (914) 332-7773
>>>
>>> www.synchronysystems.com <http://www.synchronysystems.com/>
>>>
>>>
>>>
>>>
>>>   _____
>>>
>>> From: Andrés Garagiola [mailto:[hidden email]]
>>> Sent: Thursday, May 24, 2007 11:48 AM
>>> To: [hidden email]
>>> Subject: Porting visual age applications to visualworks
>>>
>>>
>>> Do you know any tools that could make easier porting visual age
>>> applications
>>> to visualworks?
>>>
>>> Is there any way to find the equivalent visual works classes of visual
>>> age
>>> core classes?
>>>
>>> For example:
>>>     AbtTimestamp    Timestamp
>>>     Block                 BlockClosure
>>> Those are simple examples but in other cases translation gets more
>>> complicated. For example, CfsFile is the class to handle files in
>>> visualage
>>> and visualworks uses the class Filename, and the protocol between these
>>> two
>>> classes is very different.
>>>
>>> Thanks,
>>> Andrés
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Porting visual age applications to visualworks

szorin
Dave,

I agree that our website makes a particular impression.
As you can imagine, websites change often; ours has and will once again
shortly to reflect our latest offerings.

Synchrony's core business has been to migrate and modernize Smalltalk
applications. Our experience shows that it takes a committed Smalltalk
vendor to drive migrations to their platform. It only takes but a few days
to update a website accordingly if the partnership is formed.

Slavik
------


Speaking of perceptions...

 > I've had several attempts with Cincom in the past but they showed no
interest to pursue this business.

Judging by your website, your SMT software does support migration
between Smalltalks (if you dig deep enough and read the small print),
but nowhere do you *advocate* it (not that I found at least). On the
contrary, you seem to be advocating migration away from Smalltalk,
implying that Java is a prerequisite to complying with industry
standards. I can't speak for Cincom on this issue, but personally this
would not seem to instill confidence in a Smalltalk vendor as a
potential partner.

Dave

Slavik Zorin wrote:
> Indeed, perceptions are reality; to change reality we must change
> perceptions...
>
> We'll see if we can be ready for end of June. I know you'll need our
> commitment real soon. End of September we're in Europe so it will then
have

> to be October.
>
> Slavik
>
> -----Original Message-----
> From: Charles A. Monteiro [mailto:[hidden email]]
> Sent: Friday, May 25, 2007 9:36 AM
> To: [hidden email]; 'Andrés Garagiola'
> Cc: [hidden email]
> Subject: Re: Porting visual age applications to visualworks
>
> Slavik:
>
> yes, and to be fair I know that. On the other hand I think that there may

> be the perception that your ties to IBM were so tight that porting away  
>  from VA Smalltalk would not have been in your self-interest. Of course,  
> perceptions are just perceptions.
>
> In anycase , you are welcomed to try to dispel any perceptions :)
>
> Our next slot available is at the end of June, we are off July and August

> but the Fall is pretty open at the moment, end of September would be
great.

>
> Looking forward to it, hey bring Florin along :)
>
> -Charles
>
>
> On Thu, 24 May 2007 17:14:56 -0400, Slavik Zorin <[hidden email]>  
> wrote:
>
>> Charles:
>>
>>>> Slavik:
>>>> ah I feel a disturbance in the force :)
>> I know it is not a wide-spread knowledge, but for the years we've been in
>> migration business, we've been talking about migrations across ALL  
>> Smalltalk
>> platforms. Our non-exclusive partnership with IBM produced dozens of
>> successfully completed migrations from all commercial Smalltalk platforms
>> (Dolphin included) to VisualAge Smalltalk. I've had several attempts with
>> Cincom in the past but they showed no interest to pursue this business.
>>
>>>> Perhaps you could show an example of this wonderful technology at one  
>>>> of
>>>> the NYC Smalltalk meetings :)
>> I hope to take you up on your invitation to present at STUG this summer.
>> Of course, I appreciate the invitation also :)
>>
>>>> having said that there have been some attempts at helping this process

>>>> of
>>>> porting or Smalltalk cross - dialect portability.
>>>> ...
>> The cross-dialect portability only goes so far...
>> If we're talking about ANSI Smalltalk, it only covers the Kernel Library
>> (meaning Magnitudes, Collections, Behavior, etc...). The real challenge  
>> is
>> how to deal with platform specific "Frameworks", 3rd party components,  
>> User
>> Interface, etc..., and in general, migrate between programming paradigm
>> shifts (e.g. event model to MVC). I am not familiar with Bruce's work. It
>> sounds very useful if your goal is to write portable Smalltalk code. It  
>> is
>> still a migration problem if you are trying to have an existing  
>> application
>> us this library instead of the specific library of the platform. I also  
>> lost
>> track of Rosetta so I cannot comment of their porting capabilities.
>>
>> Regards,
>> Slavik
>>
>>
>> On Thu, 24 May 2007 12:47:47 -0400, Slavik Zorin <[hidden email]>
>> wrote:
>>
>>> Hello Andres,
>>>
>>>
>>> Our company name is Synchrony Systems and we specialize in porting
>>> Smalltalk
>>> Application across Smalltalk platforms and to alternative, non-Smalltalk
>>> platforms.
>>>
>>> The real challenge in porting VAST to VW is the user interface.
>>>
>>>
>>> Our technology offers an automated, systematic and interactive way to
>>> port
>>> applications across Smalltalk platforms. We know how deal with:
>>>
>>>
>>> 1. Class Library Transformation which includes classes, messages and
>>> protocols, configuration management (Envy to Store for example), Pools,
>>> etc…
>>> 2. User Interface which includes layout, property settings and
>>> dependencies (for example connections to visual moving to aspect model  
>>> in
>>> VisualWorks)
>>>
>>>
>>> Depending on the size of the application, such migrations could take 6
>>> to 12
>>> months of effort, so they should not be underestimated.
>>>
>>>
>>> For additional information, please feel to contact us directly.
>>>
>>>
>>> Regards,
>>>
>>> Slavik
>>>
>>>
>>>
>>> Slavik Zorin
>>>
>>> President
>>>
>>> Synchrony Systems, Inc.
>>>
>>> 580 White Plains Road, Suite 205
>>>
>>> Tarrytown, NY, 10591
>>>
>>> Tel: 1 (914) 332-7772x610
>>>
>>> D/l: 1 (914) 703-6610
>>>
>>> Fax: 1 (914) 332-7773
>>>
>>> www.synchronysystems.com <http://www.synchronysystems.com/>
>>>
>>>
>>>
>>>
>>>   _____
>>>
>>> From: Andrés Garagiola [mailto:[hidden email]]
>>> Sent: Thursday, May 24, 2007 11:48 AM
>>> To: [hidden email]
>>> Subject: Porting visual age applications to visualworks
>>>
>>>
>>> Do you know any tools that could make easier porting visual age
>>> applications
>>> to visualworks?
>>>
>>> Is there any way to find the equivalent visual works classes of visual
>>> age
>>> core classes?
>>>
>>> For example:
>>>     AbtTimestamp    Timestamp
>>>     Block                 BlockClosure
>>> Those are simple examples but in other cases translation gets more
>>> complicated. For example, CfsFile is the class to handle files in
>>> visualage
>>> and visualworks uses the class Filename, and the protocol between these
>>> two
>>> classes is very different.
>>>
>>> Thanks,
>>> Andrés
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Porting visual age applications to visualworks

OCIT
In reply to this post by Dave Stevenson-2
yes, I do think that the language on the site needs to be cleaned up a  
bit, this notion of "industry standard" language is so "passe" anyhow,  
really, when people are building apps using PHP, Python, Ruby on Rails,  
when Adobe is spending money on stuff like FLEX. Web Services, god help  
us, probably qualifies ans an industry standard, Java , C#, .NET, these  
are just players. Smalltalk is still standing and its definitely a player.

I think that there are definitely some VA Smalltalk shops out there that  
would like to port over to VW if they did not think it just about  
impossible, so this indeed may be a viable business to pursue.

Impressions do matter and I think that a potential partner wants to feel  
that the other partner is "into them".

So I have to agree with Dave :) and especially since I personally know  
that certainly Slavik is not anti Smalltalk.

-Charles


On Tue, 29 May 2007 14:44:40 -0400, Dave Stevenson <[hidden email]>  
wrote:

> Slavik,
>
> Speaking of perceptions...
>
>  > I've had several attempts with Cincom in the past but they showed no  
> interest to pursue this business.
>
> Judging by your website, your SMT software does support migration  
> between Smalltalks (if you dig deep enough and read the small print),  
> but nowhere do you *advocate* it (not that I found at least). On the  
> contrary, you seem to be advocating migration away from Smalltalk,  
> implying that Java is a prerequisite to complying with industry  
> standards. I can't speak for Cincom on this issue, but personally this  
> would not seem to instill confidence in a Smalltalk vendor as a  
> potential partner.
>
> Dave
>
> Slavik Zorin wrote:
>> Indeed, perceptions are reality; to change reality we must change
>> perceptions...
>>  We'll see if we can be ready for end of June. I know you'll need our
>> commitment real soon. End of September we're in Europe so it will then  
>> have
>> to be October.
>>  Slavik
>>  -----Original Message-----
>> From: Charles A. Monteiro [mailto:[hidden email]] Sent: Friday, May  
>> 25, 2007 9:36 AM
>> To: [hidden email]; 'Andrés Garagiola'
>> Cc: [hidden email]
>> Subject: Re: Porting visual age applications to visualworks
>>  Slavik:
>>  yes, and to be fair I know that. On the other hand I think that there  
>> may  be the perception that your ties to IBM were so tight that porting  
>> away   from VA Smalltalk would not have been in your self-interest. Of  
>> course,  perceptions are just perceptions.
>>  In anycase , you are welcomed to try to dispel any perceptions :)
>>  Our next slot available is at the end of June, we are off July and  
>> August  but the Fall is pretty open at the moment, end of September  
>> would be great.
>>  Looking forward to it, hey bring Florin along :)
>>  -Charles
>>   On Thu, 24 May 2007 17:14:56 -0400, Slavik Zorin  
>> <[hidden email]>  wrote:
>>
>>> Charles:
>>>
>>>>> Slavik:
>>>>> ah I feel a disturbance in the force :)
>>> I know it is not a wide-spread knowledge, but for the years we've been  
>>> in
>>> migration business, we've been talking about migrations across ALL  
>>> Smalltalk
>>> platforms. Our non-exclusive partnership with IBM produced dozens of
>>> successfully completed migrations from all commercial Smalltalk  
>>> platforms
>>> (Dolphin included) to VisualAge Smalltalk. I've had several attempts  
>>> with
>>> Cincom in the past but they showed no interest to pursue this business.
>>>
>>>>> Perhaps you could show an example of this wonderful technology at  
>>>>> one  of
>>>>> the NYC Smalltalk meetings :)
>>> I hope to take you up on your invitation to present at STUG this  
>>> summer.
>>> Of course, I appreciate the invitation also :)
>>>
>>>>> having said that there have been some attempts at helping this  
>>>>> process  of
>>>>> porting or Smalltalk cross - dialect portability.
>>>>> ...
>>> The cross-dialect portability only goes so far...
>>> If we're talking about ANSI Smalltalk, it only covers the Kernel  
>>> Library
>>> (meaning Magnitudes, Collections, Behavior, etc...). The real  
>>> challenge  is
>>> how to deal with platform specific "Frameworks", 3rd party  
>>> components,  User
>>> Interface, etc..., and in general, migrate between programming paradigm
>>> shifts (e.g. event model to MVC). I am not familiar with Bruce's work.  
>>> It
>>> sounds very useful if your goal is to write portable Smalltalk code.  
>>> It  is
>>> still a migration problem if you are trying to have an existing  
>>> application
>>> us this library instead of the specific library of the platform. I  
>>> also  lost
>>> track of Rosetta so I cannot comment of their porting capabilities.
>>>
>>> Regards,
>>> Slavik
>>>
>>>
>>> On Thu, 24 May 2007 12:47:47 -0400, Slavik Zorin <[hidden email]>
>>> wrote:
>>>
>>>> Hello Andres,
>>>>
>>>>
>>>> Our company name is Synchrony Systems and we specialize in porting
>>>> Smalltalk
>>>> Application across Smalltalk platforms and to alternative,  
>>>> non-Smalltalk
>>>> platforms.
>>>>
>>>> The real challenge in porting VAST to VW is the user interface.
>>>>
>>>>
>>>> Our technology offers an automated, systematic and interactive way to
>>>> port
>>>> applications across Smalltalk platforms. We know how deal with:
>>>>
>>>>
>>>> 1. Class Library Transformation which includes classes, messages and
>>>> protocols, configuration management (Envy to Store for example),  
>>>> Pools,
>>>> etc…
>>>> 2. User Interface which includes layout, property settings and
>>>> dependencies (for example connections to visual moving to aspect  
>>>> model  in
>>>> VisualWorks)
>>>>
>>>>
>>>> Depending on the size of the application, such migrations could take 6
>>>> to 12
>>>> months of effort, so they should not be underestimated.
>>>>
>>>>
>>>> For additional information, please feel to contact us directly.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Slavik
>>>>
>>>>
>>>>
>>>> Slavik Zorin
>>>>
>>>> President
>>>>
>>>> Synchrony Systems, Inc.
>>>>
>>>> 580 White Plains Road, Suite 205
>>>>
>>>> Tarrytown, NY, 10591
>>>>
>>>> Tel: 1 (914) 332-7772x610
>>>>
>>>> D/l: 1 (914) 703-6610
>>>>
>>>> Fax: 1 (914) 332-7773
>>>>
>>>> www.synchronysystems.com <http://www.synchronysystems.com/>
>>>>
>>>>
>>>>
>>>>
>>>>   _____
>>>>
>>>> From: Andrés Garagiola [mailto:[hidden email]]
>>>> Sent: Thursday, May 24, 2007 11:48 AM
>>>> To: [hidden email]
>>>> Subject: Porting visual age applications to visualworks
>>>>
>>>>
>>>> Do you know any tools that could make easier porting visual age
>>>> applications
>>>> to visualworks?
>>>>
>>>> Is there any way to find the equivalent visual works classes of visual
>>>> age
>>>> core classes?
>>>>
>>>> For example:
>>>>     AbtTimestamp    Timestamp
>>>>     Block                 BlockClosure
>>>> Those are simple examples but in other cases translation gets more
>>>> complicated. For example, CfsFile is the class to handle files in
>>>> visualage
>>>> and visualworks uses the class Filename, and the protocol between  
>>>> these
>>>> two
>>>> classes is very different.
>>>>
>>>> Thanks,
>>>> Andrés
>>>>
>>>
>>>
>>
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/