Planet Smalltalk

I was reminded by recent posting by Joachim Tuchel (VMTRAP with VA Smalltalk due to strange bytecode differences (or whatever)), that I needed to document my own recent experience with vmtraps.

I was working with another developer at TAF debugging a VA Smalltalk 8.5.2 image in AIX when his development image died, and couldn’t be re-opened. Moments later, other developers using the same AIX machine reported that they couldn’t open development images either. Packaged images were fine, as were VAST 8.0 images. Lacking a better solution at the time, I had our system administrator bounce the box, and all was well.

I was later reminded by the fine folks at Instantiations support that I should have checked for rogue es processes, and made sure that the /tmp/es directory was clear of all files once every possible Smalltalk process was gone. The same reminder would hold true for Linux and Solaris users as well.

Just something to keep in mind when working with Smalltalk in a UNIX environment…

Situation

I have a UITableView. Each cell of the table view has a UITextField in its contentView. The table view is actually a giant form.

In iOS when a tableView has cells containing textfield, it is supposed to scroll when a textfield becomes the first responder so focused textfield is visible when the user edits its content.

It wasn’t the case for me.

Solution

Do not forget the [textField resignFirstResponder] when passing the isFirstResponder to the next textfield. Otherwise the tableView won’t scroll to the new first responder when editing.

- (BOOL)textFieldShouldReturn:(UITextField *)textField {
  NSInteger nextTag = textField.tag + 1;
  UIView* nextResponder = [self.view viewWithTag:nextTag];
  [textField resignFirstResponder];

  if (nextResponder) {
    [nextResponder becomeFirstResponder];
  }
  return YES;
}

Et voilà, the tableView will scroll as you expect.

In the previous post I briefly mentioned the new feature of the PackageLoader that went into the development version of GNU Smalltalk. Today I am going show a usage of it.

GNU Smalltalk has a database abstraction called DBI and multiple backends (MySQL, SQLite and PostgreSQL). In general I am using the SQLite backend to develop my application and depending on the users (e.g. do I need concurrent access) I will move to PostgreSQL. When moving my new application to PostgreSQL the import of data failed and this was due some issues with the conversion of Smalltalk types to PostgreSQL.

After some exploring to understand the issue I started to develop a unit test. The first thing I did was to create a test entry in the package description of DBD-PostgreSQL, fileIn a file and name a SUnit TestCase or TestSuite.

 <test>
   <sunit>DBI.PostgreSQL.PostgresTestCase<sunit>
   <filein>Tests.st</filein>
 </test>

The next thing is to start GNU Smalltalk and load the package and get the test. I cheated a bit and directly constructed a Kernel.DirPackage instance.


$ gst
st> package := Kernel.DirPackage file: 'package.xml'
st> package fileIn.
st> test := package test.
st> test fileIn.


The above code has loaded the main package (and dependencies) and the test package as well. I went ahead and manually invoked the tests I have. This can be done by sending the >>#buildSuite message to my TestCase and then calling run on the result.


st> DBI.PostgreSQL.PostgresTestCase buildSuite run
0 run, 0 passes


Now I can start to write the actual testcases. I decided to write one test per datatype. I created a >>#setUp selector that opens the database connection and creates a table that contains every built-in type of PostgreSQL as column and a >>#tearDown to close the database connection. Then I decided to write one test per datatype and started with the ones I knew that were broken. I could incrementally create tests and type the following commands to execute them.


st> test fileIn. DBI.PostgreSQL.PostgresTestCase buildSuite run


As expected my first tests were failing. I decided to use the open classes feature of Smalltalk and put the fixes to the tests into the Tests.st file and re-executed the above and my test started to pass, then I wrote another test, executed the suite, created a fix, re-loaded and ran the tests. This has worked nicely but then there was a fix that manipulated a lookup table owned by a singleton. This means that my changes to the code were not picked up as the instance was already initialized. There are multiple ways to overcome this. I could have called the initialize function of the singleton again, I could have manipulated the lookup table inside the singleton or I could have re-set the singleton. I decided to do the later using the reflection facilities of Smalltalk. I put a nil into the instanceVariable called uniqueInstance of the PGFieldConverter class.


st> DBI.PostgreSQL.PGFieldConverter instVarNamed: #uniqueInstance put: nil


After re-executing the testsuite the singleton was re-created and the next testcase was fixed. The only thing left to do was to move the fixes from the Tests.st to the right place in the original files and run make check on the entire codebase to check that everything works as expected.

Today I was in the need to create a zip archive in VASmalltalk and zip-code had been introduced with the new Monticello Importer in version 8.5.2 (application: MZZipUnzipApp)

Documentation is spare and therefore a simple code example how to create a zip archive (and as a reminder for me):

| cfsPath zipArchive |
"where all my files are located"
cfsPath := CfsPath named: 'D:\json-sendelisten'.

"my zip archive to write"
zipArchive := MZZipArchive openWrite: 'd:\test8.zip'.

"i want to add all file from that directory ..."
cfsPath fileEntries do: [ :eachFileEntry |
  | singleFile fileContent |
  singleFile := cfsPath append: eachFileEntry dName.
  
  "method from MSKCfsExtension"
  fileContent := singleFile mskGetBinaryContent.	

  zipArchive 

    "create a current file within the archive"
    createFile: eachFileEntry dName 
    comment: '' 
    method: MZConstants::Z_DEFLATED 
    level: MZConstants::Z_BESTCOMPRESSION;

    "write the binay content of the file to the archive"
    write: fileContent ;

    "close the current file in the archive"
    closeCurrentFile.
].

"close the archive"
zipArchive close.

Here’s the link to the translated page: Squeak Tutorial page translated to Serbo-Croatian.

I added a note to the page explaining what happened and why. Pretty neat.

• VW 7.4 (2005): 337776 LOC.
• VW 7.4 (2005): 338139 LOC.
• VW 7.4a (2006): 358636 LOC.
• VW 7.4b (2006): 358957 LOC.
• VW 7.4c (2006): 359419 LOC.
• VW 7.4d (2006): 358782 LOC.
• VW 7.5 (2007): 358921 LOC.
• VW 7.6 (2007): 357264 LOC.
• VW 7.6a (2008): 350093 LOC.
• VW 7.7 (2009): 345618 LOC.
• VW 7.7a (2010): 270093 LOC.
• VW 7.7.1 (2010): 270124 LOC.
• VW 7.7.1a (2010): 270119 LOC.
• VW 7.8 (2011): 261580 LOC.
• VW 7.8a (2011): 261611 LOC.
• VW 7.8b (2011): 261739 LOC.
• VW 7.8.1a (2011): 261748 LOC.
• VW 7.9 (2012): 252309 LOC.
• VW 7.10 (2013): 240880 LOC (March).

• VW 7.10 (2013): 240368 LOC (April code freeze).

GNU Smalltalk has the concept of packages for a long time. By default the gst-package application will read an XML file and then create a ZIP archive. This package format is called a Star archive in GNU Smalltalk.

When developing it is easier to just load the package from the filesystem and this is why we now have the above PackageLoader>>#loadPackageFromFile:.