Loading a parcel into a runtime image triggers
Parcel>>triggerParcelLoaded: aParcel, which in turn accesses the change.log. A really *strange* thing is that it happened on certain PCs only. Maybe this is because the original change log was on a network path (e.g. '\\host\dir\...') and OS installations behave differently here. Anyway, there should be a safer means for intercepting source access in runtime images. The #removeAllSources method doesn't seem to be water proof. Andre |
I'm not sure what you mean by accesses the change log. And I don't seem to see anything like this happening.
If I create a runtime image whose startup action is SimpleWorkspace open, copy the SUnitPreload parcel to my current directory (since the runtime has an empty parcel path) and then in the workspace that opens evaluate Parcel ensureLoaded: 'SUnitPreload' version: nil. I don't see either an error message, or a change log created. At 01:40 PM 30/05/2006, Andre Schnoor wrote: >Loading a parcel into a runtime image triggers Parcel>>triggerParcelLoaded: aParcel, which in turn accesses the change.log. > >A really *strange* thing is that it happened on certain PCs only. Maybe this is because the original change log was on a network path (e.g. '\\host\dir\...') and OS installations behave differently here. > >Anyway, there should be a safer means for intercepting source access in runtime images. The #removeAllSources method doesn't seem to be water proof. > >Andre > -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
Unfortunately, debugging a runtime image is rather difficult. Maybe the stack trace below can help. BTW: The customized subclass of Parcel, RuntimeUpdateParcel, doesn't do anything special in this regard, it just reimplements #binaryActions, #propertiesForSave, #fileOutProperties:on: etc. I already fixed the problem (for me) by reimplementing #triggerParcelLoaded: for this class, i.e. this action is now completely ignored. The runtime image was originally stripped and saved to "t:\CS\deploy\export\nav-1.0.2\win\build\temp.im". The network drive "T:" doesn't exist on a target system. I suspect #noTargetForWrites doesn't respond correctly in all cases. It should respond with false in a runtime image. Regards, Andre -- ERROR_PATH_NOT_FOUND ("t:\CS\deploy\export\nav-1.0.2\win\build\temp.cha") Stack Summary [1] HandleRegistry>>evaluateWithFullProtection: [2] HandleRegistry>>registerValueOf: [3] PCDiskFileAccessor class(OSHandle class)>>handleValue: [4] IOAccessor class>>openFileNamed:direction:creation: [5] FileConnection>>open [6] FileConnection>>revive [7] ExternalWriteStream>>reopen [8] ExternalWriteStream(BufferedExternalStream)>>openIfClosed [9] ExternalWriteStream>>nextPut: [10] ExternalReadAppendStream>>nextPut: [11] UTF8StreamEncoder>>nextPut:on: [12] EncodedStream>>nextPut: [13] EncodedStream(Stream)>>next:putAll:startingAt: [14] EncodedStream(Stream)>>nextPutAll: [15] XMLSourceFileFormat>>checkForWrite: [16] XMLSourceFileFormat>>loadParcel:filename:on: .. should stop here in a runtime image ... [17] SourceFileManager>>loadParcelNamed:filename: [18] SourceFileManager>>loadParcel: [19] RuntimeUpdateParcel class(Parcel class)>>triggerParcelLoaded: [20] RuntimeUpdateParcel(Parcel)>>doComponentLoadedActions [21] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using: [22] RuntimeUpdateParcel(CodeComponent)>>loadFrom: [23] optimized [] in [] in [] in Parcel class>> [24] BlockClosure>>on:do: [25] optimized [] in [] in Parcel class>> [26] BlockClosure>>on:do: [27] [] in RuntimeUpdateParcel class(Parcel class)>>loadParcelCachedFrom: [28] BlockClosure>>ensure: [29] RuntimeUpdateParcel class(Parcel class)>>loadParcelCachedFrom: [30] optimized [] in [] in Parcel class>> [31] BlockClosure>>ensure: [32] RuntimeUpdateParcel class(Parcel class)>>withFileCachesDo: [33] optimized [] in Parcel class>> [34] BlockClosure>>ensure: [35] Cursor>>showWhile: [36] RuntimeUpdateParcel class(Parcel class)>>loadParcelFrom: ... |
Well, from the walkback, clearly the image has a change log and thinks it knows where it is. This is likely because of a known problem with three-step save, where the image isn't properly aware of its odd intermediate state between development and runtime, and attempts to put back the change log. This is fixed in 7.4.1. The simplest workaround is not to do a three-step save. Second simplest would I think be to force DevelopmentSystem and its methods to be deleted.
At 03:56 PM 30/05/2006, Andre Schnoor wrote: >Unfortunately, debugging a runtime image is rather difficult. Maybe the stack trace below can help. > >BTW: The customized subclass of Parcel, RuntimeUpdateParcel, doesn't do anything special in this regard, it just reimplements #binaryActions, #propertiesForSave, #fileOutProperties:on: etc. I already fixed the problem (for me) by reimplementing #triggerParcelLoaded: for this class, i.e. this action is now completely ignored. > >The runtime image was originally stripped and saved to "t:\CS\deploy\export\nav-1.0.2\win\build\temp.im". >The network drive "T:" doesn't exist on a target system. I suspect #noTargetForWrites doesn't respond correctly in all cases. It should respond with false in a runtime image. > >Regards, >Andre > >-- >ERROR_PATH_NOT_FOUND ("t:\CS\deploy\export\nav-1.0.2\win\build\temp.cha") > >Stack Summary >[1] HandleRegistry>>evaluateWithFullProtection: >[2] HandleRegistry>>registerValueOf: >[3] PCDiskFileAccessor class(OSHandle class)>>handleValue: >[4] IOAccessor class>>openFileNamed:direction:creation: >[5] FileConnection>>open >[6] FileConnection>>revive >[7] ExternalWriteStream>>reopen >[8] ExternalWriteStream(BufferedExternalStream)>>openIfClosed >[9] ExternalWriteStream>>nextPut: >[10] ExternalReadAppendStream>>nextPut: >[11] UTF8StreamEncoder>>nextPut:on: >[12] EncodedStream>>nextPut: >[13] EncodedStream(Stream)>>next:putAll:startingAt: >[14] EncodedStream(Stream)>>nextPutAll: >[15] XMLSourceFileFormat>>checkForWrite: >[16] XMLSourceFileFormat>>loadParcel:filename:on: > >.. should stop here in a runtime image ... > >[17] SourceFileManager>>loadParcelNamed:filename: >[18] SourceFileManager>>loadParcel: >[19] RuntimeUpdateParcel class(Parcel class)>>triggerParcelLoaded: >[20] RuntimeUpdateParcel(Parcel)>>doComponentLoadedActions >[21] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using: >[22] RuntimeUpdateParcel(CodeComponent)>>loadFrom: >[23] optimized [] in [] in [] in Parcel class>> >[24] BlockClosure>>on:do: >[25] optimized [] in [] in Parcel class>> >[26] BlockClosure>>on:do: >[27] [] in RuntimeUpdateParcel class(Parcel class)>>loadParcelCachedFrom: >[28] BlockClosure>>ensure: >[29] RuntimeUpdateParcel class(Parcel class)>>loadParcelCachedFrom: >[30] optimized [] in [] in Parcel class>> >[31] BlockClosure>>ensure: >[32] RuntimeUpdateParcel class(Parcel class)>>withFileCachesDo: >[33] optimized [] in Parcel class>> >[34] BlockClosure>>ensure: >[35] Cursor>>showWhile: >[36] RuntimeUpdateParcel class(Parcel class)>>loadParcelFrom: >... -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
Free forum by Nabble | Edit this page |