GemTalk/Rowan

(v3) looks like the filetree format used by Rowan is not compatible with Pharo format ...

Closed this issue · 12 comments

Here's an example from the tode project.

Before:

rogue:tode>cd repository/Tode-GemStone-Core3x.v37.package/TDGemStoneTool.extension/instance
rogue:instance>ls
checkGcLock..st		 gshalt.st    gsMfc.wait.buffer.cpu..st		    gssslLog.st
checkSystemIsVoting..st  gsmfc..1.st  gsreferences.st			    systemIsVoting.st
gshaltOnOutOfMemory..st  gsMfc..2.st  gsReferencesTo.into.inMemory.max..st  waitForVoteStateIdle.st

After:

bosch:tode>cd repository/Tode-GemStone-Core3x.v37.package/TDGemStoneTool.extension/instance
bosch:instance>ls
checkGcLock..st		 gshaltOnOutOfMemory..st  gsmfc..1.st  gsmfc..2.st  gsMfc.wait.buffer.cpu..st  gsReferencesTo.into.inMemory.max..st  systemIsVoting.st
checkSystemIsVoting..st  gshalt.st		  gsMfc..1.st  gsMfc..2.st  gsreferences.st	       gssslLog.st			     waitForVoteStateIdle.st

Git diff for the directory:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	repository/Tode-GemStone-Core3x.v37.package/TDGemStoneTool.extension/instance/gsMfc..1.st
	repository/Tode-GemStone-Core3x.v37.package/TDGemStoneTool.extension/instance/gsmfc..2.st

this is happening all over the place ... the numbering system seems to be invoked in reverse order...

Looks like sort order is different ... 3.7.0 tode image:

{ 'gsmfc:' . 'gsMfc:' } sorted 
anArray( 'gsmfc:', 'gsMfc:') 

'gsmfc:' <= 'gsMfc:'
 true

Unicode16 usingUnicodeCompares
 true

3.7.1 Rowan image:

{ 'gsmfc:' . 'gsMfc:' } sort
anArray( 'gsMfc:', 'gsmfc:')

'gsmfc:' <= 'gsMfc:'
 false

Unicode16 usingUnicodeCompares
  false

Rowan needs to use unicode comparison for filetree purposes regardless of whether or not unicode comparison mode is being used or not

While the above statement is true ... the image that I was using when I wrote out the files from (rowan3_3.7.1 created by Rowan4GsDevKit tests/test_generate.sh script) is using unicode compares:

{
{ 'gsmfc:' . 'gsMfc:' } sort  .

'gsmfc:' <= 'gsMfc:' .
 
Unicode16 usingUnicodeCompares .
}
 anArray( anArray( 'gsmfc:', 'gsMfc:'), true, true)

So there is more to the mystery...for the particular case I am seeing ...

it seems that the case insensitive code path has not been exercised up to this point, as the code sends the message #sorted: which is not (or perhaps no longer) implemented in Rowan 3 ... in the GsDevKit image, sorted happened to be defined ... nonetheless, now is a good time for a proper test and a proper implementation

Turns out that the filetree code was sorting the printString of the method definition !!!???***### ... just plain wrong ...

internal battery tests pass

package properties.json files need to end in newlines to be compatible with GsDevKit filetree details

commentStamp property for methods, should be preserved in class properties ...

added RwRowanCrooked9Test >> testIssue920_2 that uses RowaCrooked9:spec_0012 to validate that commentStamp property is now preserved ...

with the last commit (e7ed936) it looks like we've addressed all of the discrepancies for GsDevit filetree format

Some projects are clean and some are not ... presumably the differences are due to filetree format changes over the years ...

  1. commentStamp field is not being retained by the loaded class
  2. "variable" type turned into "normal"
  3. Pharo format with respect to field order and [] handling (closing ] is on new line)
  4. %20 instead of spaces in class category fields
  5. "gsOptions" handling is different (in type not separate field)

Sooo ... there is a mixed bag of formats out there ... which means I cannot avoid dirtying some projects on write, because there are conflicting format styles ... reflecting the age of the various projects/packages ...

I'm inclined to match styles with Pharo ... and probably open a separate bug.

The attached file is a sampling of diffs for the Grease class properties.json files:

filetree_diffs.txt

It is likely that this reflects the current filetree format used by Pharo and if I'm going to settle on one , then it should be Pharo ...

Okay ... after attempting to work through the filetree format issues by looking at git diffs as I changed the format details, I found that there are clearly multiple filetree formats being used within a single project!!!

So two things need to happen ... I need to ensure that only the files that have changed are written ... I thought I was doing that already in Rowan, but it seems that there are files that are "always written" by Rowan that probably shouldn't be ...

The differences that are showing up are in the package properties.json files and the class definitions ... ... and I'm not sure why these files are being written, unless they are being unconditionally written ...

can successfully load a Seaside/Grease project into Rowan3 and no writes are made to the filetree projects ... Filetree format has been updated to match the most recently written packages in Seaside/Grease as well ...call this good ...