Showing posts with label Smalltalk. Show all posts
Showing posts with label Smalltalk. Show all posts

Sunday, January 15, 2012

Space Wars Game

I've had a request to publish the space wars game.  You can download the parcel here.  I'll upload it to the Cincom Public Store repository as soon as I can.

Friday, December 9, 2011

Space Wars game in Smalltalk

My 11 year old son recently asked me to teach him how to program so he can write his own games.  Unfortunately, the kind of game he has in mind is a first-person shooter which isn't exactly the easiest way to teach an 11 year old how to program.

We talked about different kinds of games we could write.  He had no interest at all in text games like "20 questions" or "guess a number", so I told him about a game I wrote on my old 1802 computer back in the early 1980's.  It was based on the Battlestar Galactica TV series that I was watching at the time.  You would fly around a star field shooting at Cylon ships.  Tyler thought that sounded fun so we started writing it in Smalltalk.

The video below shows our progress so far.  I actually wrote most of it and I'm slowly explaining to him how it works.  It's piqued his curiosity, however.  So far, you can fly around and shoot at ships.  The ships don't explode yet, but it still shows some good progress.

Friday, October 7, 2011

GemKit and Atomic Loading revisited

Ok, I spoke too soon.  It turns out that the loading of GbcManagement didn't actually work properly.  There were 26 methods in GbcHierarchyRoot which didn't install.  After a bit of tracing, I discovered why.  The GbcHierarchyRoot class defines a new compiler for instance and class methods and that compiler was loaded in the same package as the GbcHierarchyRoot class.  This means that GbcHierarchyRoot could load before the compiler, load the methods to change to the compiler that's not loaded, then fail to compile anything else.

The solution to this is to create another package which has all the GbcHierarchyRoot methods and is loaded after GbcManagement.  This allows everything to load cleanly.

Now, on to more problems...

Thursday, October 6, 2011

GemKit and Atomic Loading

In VisualWorks 7.8, I have to turn off atomic loading in order to load the package GbcManagement. If I didn't, the load crashed with a memory overflow.

After tracing down the problem, I found that the load itself actually worked fine.  It was the step right afterward that did a purgeUnusedBindings that was failing - specifically in a method called relinkSystem.  The relinkSystem method looped through allInstances of DeferredBinding.  Maybe it was hitting an object that was garbage but hadn't yet been garbage collected.  So, I added a call to do a garbage collect just before the allInstances.  That did the trick.  GbcManagement loads perfectly every time now.

It goes to show that you have to be careful with allInstances.

Sunday, October 2, 2011

GemKit in VW7.8

So, I have GemKit running in 7.5.  I think I need to get newer versions of GemBuilder/S but it basically runs.  I thought I'd try loading it into 7.8 to see what happens.

It took several tries to get GemKit loaded into 7.8.  I learned that:
  • You can't load Searchlight before loading GemKit.  There's an interaction that causes problems.  I'll investigate that later.
  • You must turn off Atomic Loading to load GemKit. When Atomic Loading was turned on, I got into an ugly infinite loop that I couldn't interrupt and that allocated memory until it ran out and crashed.  It wasn't a pretty picture
In the end, I was able to get it loaded and get some of the basic things working.  I've also gone through and looked at all the base overrides and base extensions.  I have agreement in principle from Cincom that they would work with  me to reduce the number of overrides by adding code and hooks to the base where it makes sense and where it doesn't impact the design of the base system.

I can see already that my challenges in this project will be:
  • Getting GemKit working with Atomic Loading
  • Resolving the conflict between GemKit and Searchlight
  • Adapting GemKit to the new Glorp interface to Store
  • Adapting GemKit to the new Store Repository browsing tools.  The classes that GemKit used to extend to do this are no longer there.
  • Adapting to the newest changes to the merge tool
  • Getting Refactorings to work on GemStone code (if this is even possible)
  • Performance
So far, though, I feel like I'm off to a good start.

Loading GemKit

So, I've been able to get a 32 bit GemStone database running and connect to it from GemBuilder.  The next step is to load GemKit in VW7.5.  This is a fairly straightforward process.  The packages are all in the Cincom Public Store Repository.  You need to load them in the following order.

  • GbcManagement 4.0 0.48.0
  • GbcReleaseTools 4.0 062.0
  • GS_AllUsers_SystemUser  empty 04.0
  • GS_Globals empty 11.0
  • GS_GemKit 4.0 000.0
Next, I need to push the methods in GS_GemKit to GemStone.  There aren't many methods, so I just connected into GemStone, opened a GemStone browser, and just used copy/paste from the VW browser to the GemStone browser to move all the methods over.  If anyone has a better way of doing this, please let me know.  I then commit my changes.

With all of these packages loaded in, I need to populate my GS_Globals package with the classes in GemStone.  I first connect into GemStone with my user id and open a VisualWorks browser.  From the browser, I select GS_Globals and from a context menu select "GemKit Compare With GemStone"  This gave me a window that allowed me to select all the methods and click on "Update Image".  It seems a bit odd that it asks me to define shared variables called Nil, True and False.  I say no to each one and the load finishes without any problems.  That question about shared variables is mentioned in the documentation method GbcSourceManager class >> documentation_installation.  It's also described in the method GbcSharedVariable >> methodsNeverToDefineInClient where the array #(#nil #true #false) is commented out and the returned answer is just #().  It might be best if we can keep the original code here.  I'll investigate.

That's pretty much it.  I've been able to push code back and forth to GemStone and it seems to be working reasonably well.

Next up:  My first attempts with GemKit in VW7.8

Getting started with GemKit - part 1

I've started working on upgrading GemKit to VisualWorks 7.8.  The first order of business is to get GemKit running in the latest environment known to work.  That would be VisualWorks 7.5.  Although that version is reported to be working in VisualWorks 7.6, it hasn't been tested much in that environment so I figured that 7.5 is a better starting point.

Before I can get GemKit running, though, I need GemStone.  I have two choices - I can run the 32 bit version on my Windows laptop which is the most convenient or I can run the 64 bit version on my 64-bit Ubuntu Linux system.  Unfortunately, the processor on my laptop doesn't have the ability to run VMWare so I can't run a virtual Linux OS on the laptop.

I decide that I actually need both 32 and 64 bit GemStone versions and I'd like to make sure GemKit runs on both. So, while I upgrade Linux to the latest version of Ubuntu, I grab GemStone 6.5.8 and install it.

Installing GemStone on Windows takes some effort but if you follow the instructions carefully you can do it. One step of the instructions, however, is that you need to put your gemstone.key file into the sys directory.  Lovely.  Where do I get gemstone.key?  Good news! There's a key in the Cincom installation directory for VW7.8 under contributed/GemStone/Server/Windows.  Yay!  Bad news: the key expires April 15th, 2010 - about a year before VW7.8 was released.  Fortunately, I can fool GemStone by setting my system clock back.  It's not pretty but it works.

Ok, I have GemStone 6.5.8 running.  Now I need GemKit.  Fortunately, there are parcels available in the contributed directory.  Ok, that's another problem.  Who would have thought that the contributed directory of VisualWorks would have 32 bit version of the server but 64 but versions of GemBuilder Smalltalk?  I'm sure that it will come in handy when I connect to the Linux system, but for now, I need to find a 32 bit version of GemBuilder.

The GemStone community site allows you to download lots of versions of GemBuilder/Smalltalk.  All of them are 64 bit versions, though.  I finally managed to track down 32 bit versions in the Cincom Public Store Repository.  These seem like older versions but with a few tweaks and fixes I can get them to connect to GemStone 6.5.8.  Yay!

Installing GemStone 64 on Ubuntu Linux is a bit more challenging.  One part of the process involves verifying the checksums of all the files.  This process fails left right and center with error messages.  I suspect that this is because the installation instructions are for RedHat Linux and not Ubuntu.  Fortunately, I can skip this step and continue to install the files.  When I get to the point where I need a licence key, I decide to put it aside for now.  I'm working through my channels to get valid license keys for everything.

In part 2, I'll talk about getting GemKit running.

Tuesday, January 18, 2011

Multiple Return Values in Smalltalk

In the comments of my "Two-Sided Commit" post, I referred to a technique I heard about from my friend Anthony Lander.  I thought I'd write that up explicitly.

Sometimes, you'd really like a method to return multiple values. Suppose, for example, we have a Color object that stores its value as integers for Red, Green and Blue.  We may want to compute the Hue, Saturation and Value of the color.  If we had individual methods for hue, saturation and value, we'd have to perform the calculation three times.  Alternatively, we could write a method for the object called asHSV which returns the hue, saturation and value in an Array.  Arrays, though, are messy to deal with because the values are indexed by an integer - you can't use the names  hue, saturation, and value. We could also create an object for an HSV representation of the color but that introduces a lot of complexity. The HSV color should work interchangeably with an RGB color and that amount of work may not be justified.

Rather than have multiple return values (or returning an array of values), we can use a three-parameter block and name the parameters:

    aColor asHSVDo: [:hue :saturation :value | ... ]

Now, the asHSVDo: method can perform the conversion once and run the block with the calculated values.  We get to use nice names for the variables and we don't create extra objects we don't need.

Sometimes, this turns out to be a nice alternative when you think you need multiple return values.