search

GemTalk / Rowan

a new project/package manager for Smalltalk that supports FileTree and Tonel repositories, and is independent of Monticello and Metacello
MIT License
13 stars 7 forks source link

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

Closed dalehenrich closed 5 months ago

dalehenrich commented 5 months ago

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...

dalehenrich commented 5 months ago

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

dalehenrich commented 5 months ago

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 ...

dalehenrich commented 5 months ago

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

dalehenrich commented 5 months ago

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

dalehenrich commented 5 months ago

internal battery tests pass

dalehenrich commented 5 months ago

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

dalehenrich commented 5 months ago

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

dalehenrich commented 5 months ago

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

dalehenrich commented 5 months ago

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

dalehenrich commented 5 months ago

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 ...

dalehenrich commented 5 months ago

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 ...

dalehenrich commented 5 months ago

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 ...