porting VW code to squeak

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

porting VW code to squeak

timrowledge
I have to port a big sprawl of VW code. I'm sure others must have had to in the past. Any war stories, advice from bitter experience? Tools you came up with to help?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Disclaimer:  Any errors in spelling, tact, or fact are transmission errors.



Reply | Threaded
Open this post in threaded view
|

Re: porting VW code to squeak

marcel.taeumel
Hi Tim,

if you stumble upon some GUI stuff to convert, just ask. :-)

Best,
Marcel

Am 17.12.2019 00:38:39 schrieb tim Rowledge <[hidden email]>:

I have to port a big sprawl of VW code. I'm sure others must have had to in the past. Any war stories, advice from bitter experience? Tools you came up with to help?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.





Reply | Threaded
Open this post in threaded view
|

Re: porting VW code to squeak

timrowledge


> On 2019-12-17, at 2:32 AM, Marcel Taeumel <[hidden email]> wrote:
>
> Hi Tim,
>
> if you stumble upon some GUI stuff to convert, just ask. :-)

There's only a modest amount of UI to fiddle with since much of the system is Seaside/browser based. And in fact I'm hoping to find a way to use some of Craig's amazing work to make the current local-UI be web based.

RIght now there are fun issues around namespaces, shared variables, and of course, lots of differently named classes etc. Such fun!


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His outgoing message starts with, "Hello, Mr. Answering Machine."



Reply | Threaded
Open this post in threaded view
|

Re: porting VW code to squeak

marcel.taeumel
> ...  lots of differently named classes ...

So, you can try out Squeak's environments for that? :-)

Best,
Marcel

Am 17.12.2019 22:01:49 schrieb tim Rowledge <[hidden email]>:



> On 2019-12-17, at 2:32 AM, Marcel Taeumel wrote:
>
> Hi Tim,
>
> if you stumble upon some GUI stuff to convert, just ask. :-)

There's only a modest amount of UI to fiddle with since much of the system is Seaside/browser based. And in fact I'm hoping to find a way to use some of Craig's amazing work to make the current local-UI be web based.

RIght now there are fun issues around namespaces, shared variables, and of course, lots of differently named classes etc. Such fun!


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His outgoing message starts with, "Hello, Mr. Answering Machine."





Reply | Threaded
Open this post in threaded view
|

Re: porting VW code to squeak

timrowledge


> On 2019-12-19, at 6:50 AM, Marcel Taeumel <[hidden email]> wrote:
>
> > ...  lots of differently named classes ...
>
> So, you can try out Squeak's environments for that? :-)
If I had ever read anything that appeared to explain them and the tools to use them without going insane, I might try. Personally I think it unlikely to work. Happy to be shown evidence to the contrary.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MW: Multiply Work



Reply | Threaded
Open this post in threaded view
|

Re: porting VW code to squeak

marcel.taeumel
If I recall correctly, Jakob (jr) could successfully load a second FileDirectory implementation into Squeak using the environments. Maybe he can help out?

Best,
Marcel

Am 19.12.2019 21:52:37 schrieb tim Rowledge <[hidden email]>:



> On 2019-12-19, at 6:50 AM, Marcel Taeumel wrote:
>
> > ... lots of differently named classes ...
>
> So, you can try out Squeak's environments for that? :-)
If I had ever read anything that appeared to explain them and the tools to use them without going insane, I might try. Personally I think it unlikely to work. Happy to be shown evidence to the contrary.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MW: Multiply Work





Reply | Threaded
Open this post in threaded view
|

Re: porting VW code to squeak

Jakob Reschke
Hi,

I loaded FileSystem-Git in a different environment where the FileSystem classes for Squeak were named like they are in Pharo (without the FS prefix, which was especially troublesome for the class "Path").

Environments don't take away the effort of adapting the interface (messages sent and methods) though.

Kind regards,
Jakob


Am Fr., 20. Dez. 2019 um 15:06 Uhr schrieb Marcel Taeumel <[hidden email]>:
If I recall correctly, Jakob (jr) could successfully load a second FileDirectory implementation into Squeak using the environments. Maybe he can help out?

Best,
Marcel

Am 19.12.2019 21:52:37 schrieb tim Rowledge <[hidden email]>:



> On 2019-12-19, at 6:50 AM, Marcel Taeumel wrote:
>
> > ... lots of differently named classes ...
>
> So, you can try out Squeak's environments for that? :-)
If I had ever read anything that appeared to explain them and the tools to use them without going insane, I might try. Personally I think it unlikely to work. Happy to be shown evidence to the contrary.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MW: Multiply Work






Reply | Threaded
Open this post in threaded view
|

Using Environments (was: porting VW code to squeak)

David T. Lewis
Can you explain how this worked once the FileSystem-Git package
was loaded into a different environment? If I understand correctly,
you would have the ST-80 class named 'Path' in the default Smalltalk
environment, and you would also have the FileSystem class named
'Path' in a different environment.

To start making use of FileSystem-Git in the different environment,
is it simply a matter of changing the current environment from
Smalltalk to the different environment? And/or is there some mechanism
for explicitly specifying which of the two 'Path' classes is being
referenced?

Sorry if this is a repeat question, I am quite sure that you have
explained this previously but I am (obviously) a bit confused.

Thanks,
Dave


On Fri, Dec 20, 2019 at 04:07:31PM +0100, Jakob Reschke wrote:

> Hi,
>
> I loaded FileSystem-Git in a different environment where the FileSystem
> classes for Squeak were named like they are in Pharo (without the FS
> prefix, which was especially troublesome for the class "Path").
>
> Environments don't take away the effort of adapting the interface (messages
> sent and methods) though.
>
> Kind regards,
> Jakob
>
>
> Am Fr., 20. Dez. 2019 um 15:06 Uhr schrieb Marcel Taeumel <
> [hidden email]>:
>
> > If I recall correctly, Jakob (jr) could successfully load a second
> > FileDirectory implementation into Squeak using the environments. Maybe he
> > can help out?
> >
> > Best,
> > Marcel
> >
> > Am 19.12.2019 21:52:37 schrieb tim Rowledge <[hidden email]>:
> >
> >
> > > On 2019-12-19, at 6:50 AM, Marcel Taeumel wrote:
> > >
> > > > ... lots of differently named classes ...
> > >
> > > So, you can try out Squeak's environments for that? :-)
> > If I had ever read anything that appeared to explain them and the tools to
> > use them without going insane, I might try. Personally I think it unlikely
> > to work. Happy to be shown evidence to the contrary.
> >
> >
> > tim



Reply | Threaded
Open this post in threaded view
|

Re: Using Environments (was: porting VW code to squeak)

Jakob Reschke
I'll try to recapitulate this from memory because I don't want to search for this image from 2016 and have changed the code of FileSystem-Git (the variant included with Squot) since then, so it does not need another environment any longer.

I created a new environment that imported all of Smalltalk, and then tried to load FileSystem-Git into this new environment. To make this loading work, I changed various packages and submitted the patches back in 2016/2017, so that the code loading facilities in Squeak would compile code in the "current" Environment (see Environment class>>current). So you make this environment the current one while running a block that loads the code. During that it would then complain about missing required class definitions for those classes that have different names in Pharo. So I imported specifically these classes a second time under their Pharo names from the Smalltalk environment. Eventually this environment "contained" the FileSystem-Git classes.

Code compiled in this environment would resolve Path to FSPath instead of ST80's Path. The latter was invisible in the other environment. Though you could access the ST80 Path with dynamic look-ups such as Object environment valueOf: #Path (because Object came from the original Smalltalk environment) or (Environment named: #Smalltalk) valueOf: #Path, but I didn't need that for FileSystem-Git.

Finally I imported this other environment back into Smalltalk, so all the FileSystem-Git classes became visible there (not via Smalltalk at:, but with Smalltalk globals valueOf:, and of course when compiling code with class references). Since only the declarations are exported from the other environment, not the bindings, Path still resolved to ST80 Path in the Smalltalk environment and the FileSystem-Git class names resolved to those classes in the other environment, done.

Code reproduced from mind to set up the environment and import back to Smalltalk:
(All of this happened in a workspace because as of now there are no tools for configuring environments.)
"initialize new environment"
(Environment named: 'FileSystem-Git')
   exportSelf; importSelf;
   import: Smalltalk globals.
"load FileSystem-Git"
(Environment named: 'FileSystem-Git') beCurrentDuring:
    [Metacello new "... load FileSystem-Git, or use Gofer or set the environment of the package in MCWorkingCopyBrowser, or whatever to load it"].
"repeat the above after the following changes until it loads successfully"
"import certain classes under different names"
(Environment named: 'FileSystem-Git')
    from: Smalltalk globals import: #FSPath -> #Path;
    from: Smalltalk globals import: #FSFileSystem -> #FileSystem;
    from: Smalltalk globals import: #FSReference -> #FileReference
    ...
"open browser to look at the other environment"
((Environment named: 'FileSystem-Git') valueOf: #GitRepository) browse.
"make classes of other environment visible in Smalltalk globals"
Smalltalk globals import: (Environment named: 'FileSystem-Git').

Later I added a "change environment..." menu item to the Monticello working copy menu in the Monticello browser, and introduced this MCPackageInEnvironment decorator to make it possible to load code into another environment via the Monticello tools. It works by transparently making the selected environment for the working copy "current" around the snapshot and load operations. To use this, first press +Package before loading, then yellow-click: change environment, select the prepared environment, then proceed to add repositories to the working copy and load the code from there.

Am Fr., 20. Dez. 2019 um 17:11 Uhr schrieb David T. Lewis <[hidden email]>:
Can you explain how this worked once the FileSystem-Git package
was loaded into a different environment? If I understand correctly,
you would have the ST-80 class named 'Path' in the default Smalltalk
environment, and you would also have the FileSystem class named
'Path' in a different environment.

To start making use of FileSystem-Git in the different environment,
is it simply a matter of changing the current environment from
Smalltalk to the different environment? And/or is there some mechanism
for explicitly specifying which of the two 'Path' classes is being
referenced?

Sorry if this is a repeat question, I am quite sure that you have
explained this previously but I am (obviously) a bit confused.

Thanks,
Dave


On Fri, Dec 20, 2019 at 04:07:31PM +0100, Jakob Reschke wrote:
> Hi,
>
> I loaded FileSystem-Git in a different environment where the FileSystem
> classes for Squeak were named like they are in Pharo (without the FS
> prefix, which was especially troublesome for the class "Path").
>
> Environments don't take away the effort of adapting the interface (messages
> sent and methods) though.
>
> Kind regards,
> Jakob
>
>
> Am Fr., 20. Dez. 2019 um 15:06 Uhr schrieb Marcel Taeumel <
> [hidden email]>:
>
> > If I recall correctly, Jakob (jr) could successfully load a second
> > FileDirectory implementation into Squeak using the environments. Maybe he
> > can help out?
> >
> > Best,
> > Marcel
> >
> > Am 19.12.2019 21:52:37 schrieb tim Rowledge <[hidden email]>:
> >
> >
> > > On 2019-12-19, at 6:50 AM, Marcel Taeumel wrote:
> > >
> > > > ... lots of differently named classes ...
> > >
> > > So, you can try out Squeak's environments for that? :-)
> > If I had ever read anything that appeared to explain them and the tools to
> > use them without going insane, I might try. Personally I think it unlikely
> > to work. Happy to be shown evidence to the contrary.
> >
> >
> > tim





Reply | Threaded
Open this post in threaded view
|

Re: Using Environments (was: porting VW code to squeak)

David T. Lewis
Jakob,

Thank you very much for this detailed explanation.

Dave

On Fri, Dec 20, 2019 at 11:12:32PM +0100, Jakob Reschke wrote:

> I'll try to recapitulate this from memory because I don't want to search
> for this image from 2016 and have changed the code of FileSystem-Git (the
> variant included with Squot) since then, so it does not need another
> environment any longer.
>
> I created a new environment that imported all of Smalltalk, and then tried
> to load FileSystem-Git into this new environment. To make this loading
> work, I changed various packages and submitted the patches back in
> 2016/2017, so that the code loading facilities in Squeak would compile code
> in the "current" Environment (see Environment class>>current). So you make
> this environment the current one while running a block that loads the code.
> During that it would then complain about missing required class definitions
> for those classes that have different names in Pharo. So I imported
> specifically these classes a second time under their Pharo names from the
> Smalltalk environment. Eventually this environment "contained" the
> FileSystem-Git classes.
>
> Code compiled in this environment would resolve Path to FSPath instead of
> ST80's Path. The latter was invisible in the other environment. Though you
> could access the ST80 Path with dynamic look-ups such as Object environment
> valueOf: #Path (because Object came from the original Smalltalk
> environment) or (Environment named: #Smalltalk) valueOf: #Path, but I
> didn't need that for FileSystem-Git.
>
> Finally I imported this other environment back into Smalltalk, so all the
> FileSystem-Git classes became visible there (not via Smalltalk at:, but
> with Smalltalk globals valueOf:, and of course when compiling code with
> class references). Since only the declarations are exported from the other
> environment, not the bindings, Path still resolved to ST80 Path in the
> Smalltalk environment and the FileSystem-Git class names resolved to those
> classes in the other environment, done.
>
> Code reproduced from mind to set up the environment and import back to
> Smalltalk:
> (All of this happened in a workspace because as of now there are no tools
> for configuring environments.)
> "initialize new environment"
> (Environment named: 'FileSystem-Git')
>    exportSelf; importSelf;
>    import: Smalltalk globals.
> "load FileSystem-Git"
> (Environment named: 'FileSystem-Git') beCurrentDuring:
>     [Metacello new "... load FileSystem-Git, or use Gofer or set the
> environment of the package in MCWorkingCopyBrowser, or whatever to load
> it"].
> "repeat the above after the following changes until it loads successfully"
> "import certain classes under different names"
> (Environment named: 'FileSystem-Git')
>     from: Smalltalk globals import: #FSPath -> #Path;
>     from: Smalltalk globals import: #FSFileSystem -> #FileSystem;
>     from: Smalltalk globals import: #FSReference -> #FileReference
>     ...
> "open browser to look at the other environment"
> ((Environment named: 'FileSystem-Git') valueOf: #GitRepository) browse.
> "make classes of other environment visible in Smalltalk globals"
> Smalltalk globals import: (Environment named: 'FileSystem-Git').
>
> Later I added a "change environment..." menu item to the Monticello working
> copy menu in the Monticello browser, and introduced this
> MCPackageInEnvironment decorator to make it possible to load code into
> another environment via the Monticello tools. It works by transparently
> making the selected environment for the working copy "current" around the
> snapshot and load operations. To use this, first press +Package before
> loading, then yellow-click: change environment, select the prepared
> environment, then proceed to add repositories to the working copy and load
> the code from there.
>
> Am Fr., 20. Dez. 2019 um 17:11 Uhr schrieb David T. Lewis <
> [hidden email]>:
>
> > Can you explain how this worked once the FileSystem-Git package
> > was loaded into a different environment? If I understand correctly,
> > you would have the ST-80 class named 'Path' in the default Smalltalk
> > environment, and you would also have the FileSystem class named
> > 'Path' in a different environment.
> >
> > To start making use of FileSystem-Git in the different environment,
> > is it simply a matter of changing the current environment from
> > Smalltalk to the different environment? And/or is there some mechanism
> > for explicitly specifying which of the two 'Path' classes is being
> > referenced?
> >
> > Sorry if this is a repeat question, I am quite sure that you have
> > explained this previously but I am (obviously) a bit confused.
> >
> > Thanks,
> > Dave
> >
> >
> > On Fri, Dec 20, 2019 at 04:07:31PM +0100, Jakob Reschke wrote:
> > > Hi,
> > >
> > > I loaded FileSystem-Git in a different environment where the FileSystem
> > > classes for Squeak were named like they are in Pharo (without the FS
> > > prefix, which was especially troublesome for the class "Path").
> > >
> > > Environments don't take away the effort of adapting the interface
> > (messages
> > > sent and methods) though.
> > >
> > > Kind regards,
> > > Jakob
> > >
> > >
> > > Am Fr., 20. Dez. 2019 um 15:06 Uhr schrieb Marcel Taeumel <
> > > [hidden email]>:
> > >
> > > > If I recall correctly, Jakob (jr) could successfully load a second
> > > > FileDirectory implementation into Squeak using the environments. Maybe
> > he
> > > > can help out?
> > > >
> > > > Best,
> > > > Marcel
> > > >
> > > > Am 19.12.2019 21:52:37 schrieb tim Rowledge <[hidden email]>:
> > > >
> > > >
> > > > > On 2019-12-19, at 6:50 AM, Marcel Taeumel wrote:
> > > > >
> > > > > > ... lots of differently named classes ...
> > > > >
> > > > > So, you can try out Squeak's environments for that? :-)
> > > > If I had ever read anything that appeared to explain them and the
> > tools to
> > > > use them without going insane, I might try. Personally I think it
> > unlikely
> > > > to work. Happy to be shown evidence to the contrary.
> > > >
> > > >
> > > > tim
> >
> >
> >
> >

>


Reply | Threaded
Open this post in threaded view
|

Re: Using Environments (was: porting VW code to squeak)

timrowledge
In reply to this post by Jakob Reschke
So... really easy and no trouble at all, then ;-)

> On 2019-12-20, at 2:12 PM, Jakob Reschke <[hidden email]> wrote:
>
> I'll try to recapitulate this from memory




tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: YII: Yield to Irresistable Impulse