Migrating from 2.3.1 to 2.4.4

Jon Paynter wrote:

Hi,
 I Downloaded the updated GLASS appliance today, and started the upgrade process from 2.3.1 to 2.4.4.  In the process I found one annoyance - the 2.4.4 pharo image doesnt like to have an IP address in session description.
 in 2.3.1 - this works fine:
OGApplianceSessionDescription new
 name: 'Glass';
 stoneHost: '192.168.1.102';
 stoneName: 'seaside';
 yourself.
 But trying the same pattern in a 2.4.4 pharo image doesnt work.  I changed the IP to that of the new appliance and tried to login, but I get a walkback "The GemStone session has lost its connection to the Stone Repository monitor., SocketRead failed"
In order to fix it, I added an entry to my hosts file in windows and then connections went fine.

Aha! This is something that has come up just recently in another context (see Issue 162 in glassdb), but I hadn't had time to characterize what is going on ... it looks like there was a change in 2.4.4 that has affected this ... I'll have to dig a bit to get an explanation...

 but the real problem seems to be in performance.  Since my application has no data to speak of, I just went to fileout my classes from the 2.3.1 pharo image and file them into the 2.4.4 pharo image. the 2.3.1:  Login to Glass, open Omnibrowser, Select class category, right click -> file out.  8min later, it had completed the file out.  The resulting file was only 443k so there should be no size issues to speak of.  Fileing out other categories, give me the same performance problems. 5mins to create a 202kb .gs file 1min to create a 48kb .gs file
2mins to create a 51kb .gs file
and then around 45 seconds to file out a category with only 2 classes.  the resulting .gs file was 12k.

For GLASS, I recommend using Monticello for transferring code around as it is far superior to using fileouts.

I haven't spent a lot of time with the fileout code (you may find that there is no filein menu item:), but based on experience, operations involving ClassOrganizers can be very inefficient and presumably that is what you are seeing...

 I saw simmilar performance issues when trying to load the the .gs files into the 2.4.4 - but I suspect that was mainly due to the vmware graphics performance on the character terminal.
 Once things were filed in, I also found the Omnibrowser does not get updated with new classes and methods unless I log out and log back in.  Doing a simple abort had no visible effect (unlike in the 32bit version of gemstone when I connect with a visualworks image).  Not really a showstopper, but highly annoying if multiple developers are working on the same stone.

The OmniBrowser system is event-based and I have not hooked up the events to the filein mechanisme ... the events _are_ hooked up for Monticello, so the browsers stay in sycnh as you load code through Monticello.

As I alluded to before the ClassOrganizer is extremely inefficient - there is a caching version in GLASS - but it isn't practical to flush the cache on every abort ...

GLASS is tuned for single user development and the use of Monticello.

 Any clues what changes happened between the 2.3.1 and 2.4.4 pharo images such that i can no longer connect by using an IP address?
Also, any clues on the file-out performance issues?
 Lastly - Ive noticed that just a simple login takes much longer when compared to the 32bit version of gemstone.  2-3 seconds with glass vs < 1 second on the 32bit version with vw76.

During the login process for GLASS there is some code being compiled on the server and probably the longest delay comes from calculating the currentVersion of GLASS...

Dale

Jon Paynter wrote:

Thanks Dale.
 Looks like its time to learn Monticello.
Is there a Monticello for beginners document somewhere that I can look over? Or some instructions on how to move my code from one stone to another?
 

I think there is good documentation in the Pharo by Example book (http://pharobyexample.org/)...

Dale

Hello Jon,

Have you solved your problem?  Do you mind tell me how?  I have the
same issue (migrating from 2.3 to 2.4).  I assumed that I could export
a .mcz file and copy this file to the server where 2.4 is installed.
And then 'import' it. But maybe I am missing something.

The older code is in GemStone 2.3.1.0.1 under Linux.  I used GemTools
beta6 and just migrated to beta8 to see if it helps.

While I was able to create a Monticello package, I cannot find a
matching .mcz file anywhere. The default repository seems to be named
'cache'.

Trying to add a directoryt repository, I hit a bug. When I try to add
a directory as repository, under MCCmdNewRepository | Execute, the
call to obConfigure terminates because later a #directory is not
defined (in OBGemStonePlaform class | handleDirectoryRequest:)

execute

       | types labels cls repos |
       types := MCRepository allConcreteSubclasses asArray.
       labels := types collect: [:ea | ea description].
       cls := OBChoiceRequest
               prompt: 'Repository type:'
               labels: labels
               values: types.
       cls == nil ifTrue: [ ^self ].
       repos := cls obConfigure.
       repos ~~ nil ifTrue: [ target repositoryGroup addRepository: repos ].
       self refresh



Cheers,
Thierry

Jon Paynter wrote:

Well I read over the 1 chapter on monticello.  it seems pretty straitforward except for a few things I dont get when trying to use the glass monticello brower:
- how do I tell what package a class is a member of?  Theres nothing in the omnibrowser that shows this.

GLASS uses the same convention as Pharo. The name of the package is mapped onto the class category and for "loose" methods, the method category is named *package-name. I thought that that would be covered in the Pharo book.

- how do I tell whats actually loaded?   The book says look for an underlined package name.. but Nothing is underlined when I open the repository browser.

This sounds like a fonts issue ... I assume that you are using the one-click ... I will check into this and see if we can update the one-click to use better fonts.

- I have about 200 classes that need to be put into packages, and the monticello browser seems to lack a multi-select.  is there a fast way to do this?

The fastest way to do this is to write a script like the following:

 #("list of class names to be packaged in Package-A") do: [:className |
 (Smalltalk at: className) category: 'Package-A' ].

Then use the 'Add package' menu item to add the package to Monticello ...

I recommend that you use a server directory (i.e., located on the machine where the gem process is running and accessed directly by the gem). Using a directory repository means that the repository will be created on the machine on which the client is running and the bits are pushed across the wire to the client (which is very slow)...

Jon Paynter wrote:

On Wed, Sep 22, 2010 at 11:54 AM, Dale Henrichs <[hidden email] <mailto:[hidden email]>> wrote:

   Jon Paynter wrote:

...SNIP...

I got that far...  the new classes are actually in different symbol dictionaries due to being created in the 32bit version of gemstone.  so I have something like this:
MyNewDictionaryCore do: [ : item |  item category: 'Core' ].
MyNewDictionaryGame do: [ : item |  item category: 'Game' ].
MyNewDictionaryInterfaces do: [ : item |  item category: 'Interfaces' ].
 Which works fine to categorize things the way i want.
But what would the add package method be?  or is that done via the monticello browser?

I'd have to dig around ... Monticello was not written with a nice api for programmatic manipulation of packages ... If you have too many packages to deal with manually let me know and I'll snoop around in the code...