Problem with overrides in runtime image
Locked
Problem with overrides in runtime image
 
|
I'm having problems loading "patch" parcels into a runtime image,
because Overrides happen to access class comments and method sources (which are absent from the runtime product). It's getting more and more frustrating to poke around in the Override class tree and apply fixes here and there ... Is there a better and simpler solution for this? - How can Overrides be best disabled in a runtime image? - Is this perhaps associated with the "3 Step Snapshot" of RTP? Thanks in advance for any suggestion. Andre |
Re: Problem with overrides in runtime image
|
|
In BottomFeeder, I reload parcels with updates/new code/overrides at
runtime, and I use this code to do the actual parcel load: [[Parcel loadParcelFrom: parcelFile] on: Parcel parcelAlreadyLoadedSignal, CodeStorageError do: [:ex | ex resume: true]] on: DuplicateBindingsError do: [:ex | ex resume] At 09:49 AM 8/23/2006, you wrote: >I'm having problems loading "patch" parcels into a runtime image, >because Overrides happen to access class comments and method sources >(which are absent from the runtime product). It's getting more and >more frustrating to poke around in the Override class tree and apply >fixes here and there ... Is there a better and simpler solution for this? > >- How can Overrides be best disabled in a runtime image? >- Is this perhaps associated with the "3 Step Snapshot" of RTP? > >Thanks in advance for any suggestion. > >Andre > > <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView |
Re: Problem with overrides in runtime image
|
|
Thanks for the advice, James, but it doesn't seem to work in my case.
I wrapped RuntimeUpdateParcel>>loadFrom: with your code. BTW, RuntimeUpdateParcel is a subclass of Parcel and does nothing special. It's purpose is to keep a registry of loaded updates in a class instance variable and ignore #triggerParcelLoaded: in order to not mess up with source code updates at runtime. I suspect that CodeComponent class>>handleCodeReaderSignalsDo:for: catches all the exceptions already, so they won't reach the outer handler. It also seems that overrides are created anyway - exceptions raised or not. Here's a stack trace: ##### Error, because XML.SAX stuff isn't found (related to source management) [1] LiteralBindingReference(Object)>>error: [2] LiteralBindingReference(GeneralBindingReference)>>binding [3] LiteralBindingReference(GeneralBindingReference)>>value [4] DocumentationSystem class>>isCommentWithoutXML: [5] optimized [] in SourceFileManager>> [6] SourceFileManager>>retrieveStringAt:using:format:ifAbsent: [7] SourceFileManager>>documentationAt:ifAbsent: [8] ChimeraZoomButton class(ClassDescription)>>stDocumentation [9] ChimeraZoomButton class(ClassDescription)>>comment [10] OverridenClass>>from: [11] Override class>>forClassOrNameSpace: ##### here's where overrides are created [12] CodeReader>>relocateOrReplaceName:from:to:map: [13] optimized [] in [] in CodeReader>> [14] optimized [] in CodeReader>> [15] OrderedCollection>>do: [16] CodeReader>>shadow:of:do: [17] optimized [] in CodeReader>> [18] OrderedCollection>>do: [19] CodeReader>>shadow:of:do: [20] optimized [] in CodeReader>> [21] BlockClosure>>on:do: [22] optimized [] in SystemUtils class>> [23] BlockClosure>>ensure: [24] SystemUtils class>>modifySystem: [25] CodeReader>>installBindingsInSystem [26] optimized [] in CodeReader>> [27] BlockClosure>>ifCurtailed: [28] CodeReader>>installInSystem [29] optimized [] in CodeComponent>> [30] BlockClosure>>on:do: ##### This one catches many exceptions: [31] RuntimeUpdateParcel class(CodeComponent class)>>handleCodeReaderSignalsDo:for: [32] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using: [33] optimized [] in [] in RuntimeUpdateParcel>> [34] BlockClosure>>on:do: [35] optimized [] in RuntimeUpdateParcel>> [36] BlockClosure>>on:do: ##### here's where I wrapped your exception handling: [37] RuntimeUpdateParcel>>loadFrom: James Robertson wrote: > In BottomFeeder, I reload parcels with updates/new code/overrides at > runtime, and I use this code to do the actual parcel load: > > [[Parcel loadParcelFrom: parcelFile] on: Parcel > parcelAlreadyLoadedSignal, CodeStorageError > do: [:ex | ex resume: true]] > on: DuplicateBindingsError > do: [:ex | ex resume] > > > > At 09:49 AM 8/23/2006, you wrote: >> I'm having problems loading "patch" parcels into a runtime image, >> because Overrides happen to access class comments and method sources >> (which are absent from the runtime product). It's getting more and >> more frustrating to poke around in the Override class tree and apply >> fixes here and there ... Is there a better and simpler solution for >> this? >> >> - How can Overrides be best disabled in a runtime image? >> - Is this perhaps associated with the "3 Step Snapshot" of RTP? >> >> Thanks in advance for any suggestion. >> >> Andre >> >> > |
Re: Problem with overrides in runtime image
|
|
Ok, in your case it looks like code that is being referenced is
stripped. I modify the system such that it doesn't try to write to the change file as well. At 11:00 AM 8/23/2006, you wrote: >Thanks for the advice, James, but it doesn't seem to work in my case. > >I wrapped RuntimeUpdateParcel>>loadFrom: with your code. BTW, >RuntimeUpdateParcel is a subclass of Parcel and does nothing >special. It's purpose is to keep a registry of loaded updates in a >class instance variable and ignore #triggerParcelLoaded: in order to >not mess up with source code updates at runtime. > >I suspect that > > CodeComponent class>>handleCodeReaderSignalsDo:for: > >catches all the exceptions already, so they won't reach the outer >handler. It also seems that overrides are created anyway - >exceptions raised or not. > >Here's a stack trace: > > ##### Error, because XML.SAX stuff isn't found (related to > source management) >[1] LiteralBindingReference(Object)>>error: >[2] LiteralBindingReference(GeneralBindingReference)>>binding >[3] LiteralBindingReference(GeneralBindingReference)>>value >[4] DocumentationSystem class>>isCommentWithoutXML: >[5] optimized [] in SourceFileManager>> >[6] SourceFileManager>>retrieveStringAt:using:format:ifAbsent: >[7] SourceFileManager>>documentationAt:ifAbsent: >[8] ChimeraZoomButton class(ClassDescription)>>stDocumentation >[9] ChimeraZoomButton class(ClassDescription)>>comment >[10] OverridenClass>>from: >[11] Override class>>forClassOrNameSpace: > > ##### here's where overrides are created >[12] CodeReader>>relocateOrReplaceName:from:to:map: >[13] optimized [] in [] in CodeReader>> >[14] optimized [] in CodeReader>> >[15] OrderedCollection>>do: >[16] CodeReader>>shadow:of:do: >[17] optimized [] in CodeReader>> >[18] OrderedCollection>>do: >[19] CodeReader>>shadow:of:do: >[20] optimized [] in CodeReader>> >[21] BlockClosure>>on:do: >[22] optimized [] in SystemUtils class>> >[23] BlockClosure>>ensure: >[24] SystemUtils class>>modifySystem: >[25] CodeReader>>installBindingsInSystem >[26] optimized [] in CodeReader>> >[27] BlockClosure>>ifCurtailed: >[28] CodeReader>>installInSystem >[29] optimized [] in CodeComponent>> >[30] BlockClosure>>on:do: > > ##### This one catches many exceptions: >[31] RuntimeUpdateParcel class(CodeComponent >class)>>handleCodeReaderSignalsDo:for: >[32] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using: >[33] optimized [] in [] in RuntimeUpdateParcel>> >[34] BlockClosure>>on:do: >[35] optimized [] in RuntimeUpdateParcel>> >[36] BlockClosure>>on:do: > > ##### here's where I wrapped your exception handling: >[37] RuntimeUpdateParcel>>loadFrom: > > > > >James Robertson wrote: >>In BottomFeeder, I reload parcels with updates/new code/overrides >>at runtime, and I use this code to do the actual parcel load: >> >> [[Parcel loadParcelFrom: parcelFile] on: Parcel >> parcelAlreadyLoadedSignal, CodeStorageError >> do: [:ex | ex resume: true]] >> on: DuplicateBindingsError >> do: [:ex | ex resume] >> >> >> >>At 09:49 AM 8/23/2006, you wrote: >>>I'm having problems loading "patch" parcels into a runtime image, >>>because Overrides happen to access class comments and method >>>sources (which are absent from the runtime product). It's getting >>>more and more frustrating to poke around in the Override class >>>tree and apply fixes here and there ... Is there a better and >>>simpler solution for this? >>> >>>- How can Overrides be best disabled in a runtime image? >>>- Is this perhaps associated with the "3 Step Snapshot" of RTP? >>> >>>Thanks in advance for any suggestion. >>> >>>Andre >>> <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView |
Re: Problem with overrides in runtime image
|
|
Meanwhile I found a quick & dirty solution. I've got a package "Runtime
Patches" with lots of really ugly hacks and overrides loaded into a runtime product only. There I simply skipped the saving of comments and sources in the Override initialization methods. This seems to work fine. However, I encountered the next problem already: Loading a new version of a class with an added instance variable seems to require the recompilation of the class tree .... well, that's definitely impossible with the compiler being removed and sources stripped and abandoned. It's obvious that updates by means of parcel loading has its limits. I'd better use them for smaller bug fixes only and no longer try to deploy "binary change sets" (which are hard to implement). This however also means: Everytime it happens a class' instance vars have changed, I need to either put the whole class tree into a parcel (in binary form incl. all methods), or release a new major version from scratch. Andre -- James Robertson wrote: > Ok, in your case it looks like code that is being referenced is > stripped. I modify the system such that it doesn't try to write to > the change file as well. > > At 11:00 AM 8/23/2006, you wrote: >> Thanks for the advice, James, but it doesn't seem to work in my case. >> >> I wrapped RuntimeUpdateParcel>>loadFrom: with your code. BTW, >> RuntimeUpdateParcel is a subclass of Parcel and does nothing special. >> It's purpose is to keep a registry of loaded updates in a class >> instance variable and ignore #triggerParcelLoaded: in order to not >> mess up with source code updates at runtime. >> >> I suspect that >> >> CodeComponent class>>handleCodeReaderSignalsDo:for: >> >> catches all the exceptions already, so they won't reach the outer >> handler. It also seems that overrides are created anyway - exceptions >> raised or not. >> >> Here's a stack trace: >> >> ##### Error, because XML.SAX stuff isn't found (related to source >> management) >> [1] LiteralBindingReference(Object)>>error: >> [2] LiteralBindingReference(GeneralBindingReference)>>binding >> [3] LiteralBindingReference(GeneralBindingReference)>>value >> [4] DocumentationSystem class>>isCommentWithoutXML: >> [5] optimized [] in SourceFileManager>> >> [6] SourceFileManager>>retrieveStringAt:using:format:ifAbsent: >> [7] SourceFileManager>>documentationAt:ifAbsent: >> [8] ChimeraZoomButton class(ClassDescription)>>stDocumentation >> [9] ChimeraZoomButton class(ClassDescription)>>comment >> [10] OverridenClass>>from: >> [11] Override class>>forClassOrNameSpace: >> >> ##### here's where overrides are created >> [12] CodeReader>>relocateOrReplaceName:from:to:map: >> [13] optimized [] in [] in CodeReader>> >> [14] optimized [] in CodeReader>> >> [15] OrderedCollection>>do: >> [16] CodeReader>>shadow:of:do: >> [17] optimized [] in CodeReader>> >> [18] OrderedCollection>>do: >> [19] CodeReader>>shadow:of:do: >> [20] optimized [] in CodeReader>> >> [21] BlockClosure>>on:do: >> [22] optimized [] in SystemUtils class>> >> [23] BlockClosure>>ensure: >> [24] SystemUtils class>>modifySystem: >> [25] CodeReader>>installBindingsInSystem >> [26] optimized [] in CodeReader>> >> [27] BlockClosure>>ifCurtailed: >> [28] CodeReader>>installInSystem >> [29] optimized [] in CodeComponent>> >> [30] BlockClosure>>on:do: >> >> ##### This one catches many exceptions: >> [31] RuntimeUpdateParcel class(CodeComponent >> class)>>handleCodeReaderSignalsDo:for: >> [32] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using: >> [33] optimized [] in [] in RuntimeUpdateParcel>> >> [34] BlockClosure>>on:do: >> [35] optimized [] in RuntimeUpdateParcel>> >> [36] BlockClosure>>on:do: >> >> ##### here's where I wrapped your exception handling: >> [37] RuntimeUpdateParcel>>loadFrom: >> >> >> >> >> James Robertson wrote: >>> In BottomFeeder, I reload parcels with updates/new code/overrides at >>> runtime, and I use this code to do the actual parcel load: >>> >>> [[Parcel loadParcelFrom: parcelFile] on: Parcel >>> parcelAlreadyLoadedSignal, CodeStorageError >>> do: [:ex | ex resume: true]] >>> on: DuplicateBindingsError >>> do: [:ex | ex resume] >>> >>> >>> >>> At 09:49 AM 8/23/2006, you wrote: >>>> I'm having problems loading "patch" parcels into a runtime image, >>>> because Overrides happen to access class comments and method >>>> sources (which are absent from the runtime product). It's getting >>>> more and more frustrating to poke around in the Override class tree >>>> and apply fixes here and there ... Is there a better and simpler >>>> solution for this? >>>> >>>> - How can Overrides be best disabled in a runtime image? >>>> - Is this perhaps associated with the "3 Step Snapshot" of RTP? >>>> >>>> Thanks in advance for any suggestion. >>>> >>>> Andre >>>> > > <Talk Small and Carry a Big Class Library> > James Robertson, Product Manager, Cincom Smalltalk > http://www.cincomsmalltalk.com/blog/blogView > > |
Re: Problem with overrides in runtime image
|
|
Just include the compiler in the runtime - it's an option in RTP.
At 12:33 PM 8/23/2006, you wrote: >Meanwhile I found a quick & dirty solution. I've got a package >"Runtime Patches" with lots of really ugly hacks and overrides >loaded into a runtime product only. There I simply skipped the >saving of comments and sources in the Override initialization >methods. This seems to work fine. > >However, I encountered the next problem already: Loading a new >version of a class with an added instance variable seems to require >the recompilation of the class tree .... well, that's definitely >impossible with the compiler being removed and sources stripped and abandoned. > >It's obvious that updates by means of parcel loading has its limits. >I'd better use them for smaller bug fixes only and no longer try to >deploy "binary change sets" (which are hard to implement). > >This however also means: Everytime it happens a class' instance vars >have changed, I need to either put the whole class tree into a >parcel (in binary form incl. all methods), or release a new major >version from scratch. > >Andre > >-- > >James Robertson wrote: >>Ok, in your case it looks like code that is being referenced is >>stripped. I modify the system such that it doesn't try to write to >>the change file as well. >> >>At 11:00 AM 8/23/2006, you wrote: >>>Thanks for the advice, James, but it doesn't seem to work in my case. >>> >>>I wrapped RuntimeUpdateParcel>>loadFrom: with your code. BTW, >>>RuntimeUpdateParcel is a subclass of Parcel and does nothing >>>special. It's purpose is to keep a registry of loaded updates in a >>>class instance variable and ignore #triggerParcelLoaded: in order >>>to not mess up with source code updates at runtime. >>> >>>I suspect that >>> >>> CodeComponent class>>handleCodeReaderSignalsDo:for: >>> >>>catches all the exceptions already, so they won't reach the outer >>>handler. It also seems that overrides are created anyway - >>>exceptions raised or not. >>> >>>Here's a stack trace: >>> >>> ##### Error, because XML.SAX stuff isn't found (related to >>> source management) >>>[1] LiteralBindingReference(Object)>>error: >>>[2] LiteralBindingReference(GeneralBindingReference)>>binding >>>[3] LiteralBindingReference(GeneralBindingReference)>>value >>>[4] DocumentationSystem class>>isCommentWithoutXML: >>>[5] optimized [] in SourceFileManager>> >>>[6] SourceFileManager>>retrieveStringAt:using:format:ifAbsent: >>>[7] SourceFileManager>>documentationAt:ifAbsent: >>>[8] ChimeraZoomButton class(ClassDescription)>>stDocumentation >>>[9] ChimeraZoomButton class(ClassDescription)>>comment >>>[10] OverridenClass>>from: >>>[11] Override class>>forClassOrNameSpace: >>> >>> ##### here's where overrides are created >>>[12] CodeReader>>relocateOrReplaceName:from:to:map: >>>[13] optimized [] in [] in CodeReader>> >>>[14] optimized [] in CodeReader>> >>>[15] OrderedCollection>>do: >>>[16] CodeReader>>shadow:of:do: >>>[17] optimized [] in CodeReader>> >>>[18] OrderedCollection>>do: >>>[19] CodeReader>>shadow:of:do: >>>[20] optimized [] in CodeReader>> >>>[21] BlockClosure>>on:do: >>>[22] optimized [] in SystemUtils class>> >>>[23] BlockClosure>>ensure: >>>[24] SystemUtils class>>modifySystem: >>>[25] CodeReader>>installBindingsInSystem >>>[26] optimized [] in CodeReader>> >>>[27] BlockClosure>>ifCurtailed: >>>[28] CodeReader>>installInSystem >>>[29] optimized [] in CodeComponent>> >>>[30] BlockClosure>>on:do: >>> >>> ##### This one catches many exceptions: >>>[31] RuntimeUpdateParcel class(CodeComponent >>>class)>>handleCodeReaderSignalsDo:for: >>>[32] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using: >>>[33] optimized [] in [] in RuntimeUpdateParcel>> >>>[34] BlockClosure>>on:do: >>>[35] optimized [] in RuntimeUpdateParcel>> >>>[36] BlockClosure>>on:do: >>> >>> ##### here's where I wrapped your exception handling: >>>[37] RuntimeUpdateParcel>>loadFrom: >>> >>> >>> >>> >>>James Robertson wrote: >>>>In BottomFeeder, I reload parcels with updates/new code/overrides >>>>at runtime, and I use this code to do the actual parcel load: >>>> >>>> [[Parcel loadParcelFrom: parcelFile] on: Parcel >>>> parcelAlreadyLoadedSignal, CodeStorageError >>>> do: [:ex | ex resume: true]] >>>> on: DuplicateBindingsError >>>> do: [:ex | ex resume] >>>> >>>> >>>> >>>>At 09:49 AM 8/23/2006, you wrote: >>>>>I'm having problems loading "patch" parcels into a runtime >>>>>image, because Overrides happen to access class comments and >>>>>method sources (which are absent from the runtime product). It's >>>>>getting more and more frustrating to poke around in the Override >>>>>class tree and apply fixes here and there ... Is there a better >>>>>and simpler solution for this? >>>>> >>>>>- How can Overrides be best disabled in a runtime image? >>>>>- Is this perhaps associated with the "3 Step Snapshot" of RTP? >>>>> >>>>>Thanks in advance for any suggestion. >>>>> >>>>>Andre >> >><Talk Small and Carry a Big Class Library> >>James Robertson, Product Manager, Cincom Smalltalk >>http://www.cincomsmalltalk.com/blog/blogView >> <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView |
RE: Problem with overrides in runtime image
|
|
In reply to this post by Andre Schnoor
There is another issue with class definition updates using patch parcels one should be aware of:
If you add two inst vars on different levels in an already present class hierarchy in one single parcel, the class loader really has a problem with inst var indexes afterwards. We still wait for the corresponding AR to be resolved. These wrong inst var indexes can lead to bugs that are nasty to find at all because values are suddenly stored in the wrong slots in these classes and "nonsense" debugger stacks arise from that effect... Thomas > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] > Sent: Wednesday, August 23, 2006 6:33 PM > To: [hidden email] > Subject: Re: Problem with overrides in runtime image > > Meanwhile I found a quick & dirty solution. I've got a > package "Runtime > Patches" with lots of really ugly hacks and overrides loaded into a > runtime product only. There I simply skipped the saving of > comments and > sources in the Override initialization methods. This seems to > work fine. > > However, I encountered the next problem already: Loading a > new version > of a class with an added instance variable seems to require the > recompilation of the class tree .... well, that's definitely > impossible > with the compiler being removed and sources stripped and abandoned. > > It's obvious that updates by means of parcel loading has its > limits. I'd > better use them for smaller bug fixes only and no longer try > to deploy > "binary change sets" (which are hard to implement). > > This however also means: Everytime it happens a class' instance vars > have changed, I need to either put the whole class tree into a parcel > (in binary form incl. all methods), or release a new major > version from > scratch. > > Andre > > -- > > James Robertson wrote: > > Ok, in your case it looks like code that is being referenced is > > stripped. I modify the system such that it doesn't try to write to > > the change file as well. > > > > At 11:00 AM 8/23/2006, you wrote: > >> Thanks for the advice, James, but it doesn't seem to work > in my case. > >> > >> I wrapped RuntimeUpdateParcel>>loadFrom: with your code. BTW, > >> RuntimeUpdateParcel is a subclass of Parcel and does > nothing special. > >> It's purpose is to keep a registry of loaded updates in a class > >> instance variable and ignore #triggerParcelLoaded: in order to not > >> mess up with source code updates at runtime. > >> > >> I suspect that > >> > >> CodeComponent class>>handleCodeReaderSignalsDo:for: > >> > >> catches all the exceptions already, so they won't reach the outer > >> handler. It also seems that overrides are created anyway - > exceptions > >> raised or not. > >> > >> Here's a stack trace: > >> > >> ##### Error, because XML.SAX stuff isn't found (related > to source > >> management) > >> [1] LiteralBindingReference(Object)>>error: > >> [2] LiteralBindingReference(GeneralBindingReference)>>binding > >> [3] LiteralBindingReference(GeneralBindingReference)>>value > >> [4] DocumentationSystem class>>isCommentWithoutXML: > >> [5] optimized [] in SourceFileManager>> > >> [6] SourceFileManager>>retrieveStringAt:using:format:ifAbsent: > >> [7] SourceFileManager>>documentationAt:ifAbsent: > >> [8] ChimeraZoomButton class(ClassDescription)>>stDocumentation > >> [9] ChimeraZoomButton class(ClassDescription)>>comment > >> [10] OverridenClass>>from: > >> [11] Override class>>forClassOrNameSpace: > >> > >> ##### here's where overrides are created > >> [12] CodeReader>>relocateOrReplaceName:from:to:map: > >> [13] optimized [] in [] in CodeReader>> > >> [14] optimized [] in CodeReader>> > >> [15] OrderedCollection>>do: > >> [16] CodeReader>>shadow:of:do: > >> [17] optimized [] in CodeReader>> > >> [18] OrderedCollection>>do: > >> [19] CodeReader>>shadow:of:do: > >> [20] optimized [] in CodeReader>> > >> [21] BlockClosure>>on:do: > >> [22] optimized [] in SystemUtils class>> > >> [23] BlockClosure>>ensure: > >> [24] SystemUtils class>>modifySystem: > >> [25] CodeReader>>installBindingsInSystem > >> [26] optimized [] in CodeReader>> > >> [27] BlockClosure>>ifCurtailed: > >> [28] CodeReader>>installInSystem > >> [29] optimized [] in CodeComponent>> > >> [30] BlockClosure>>on:do: > >> > >> ##### This one catches many exceptions: > >> [31] RuntimeUpdateParcel class(CodeComponent > >> class)>>handleCodeReaderSignalsDo:for: > >> [32] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using: > >> [33] optimized [] in [] in RuntimeUpdateParcel>> > >> [34] BlockClosure>>on:do: > >> [35] optimized [] in RuntimeUpdateParcel>> > >> [36] BlockClosure>>on:do: > >> > >> ##### here's where I wrapped your exception handling: > >> [37] RuntimeUpdateParcel>>loadFrom: > >> > >> > >> > >> > >> James Robertson wrote: > >>> In BottomFeeder, I reload parcels with updates/new > code/overrides at > >>> runtime, and I use this code to do the actual parcel load: > >>> > >>> [[Parcel loadParcelFrom: parcelFile] on: Parcel > >>> parcelAlreadyLoadedSignal, CodeStorageError > >>> do: [:ex | ex resume: true]] > >>> on: DuplicateBindingsError > >>> do: [:ex | ex resume] > >>> > >>> > >>> > >>> At 09:49 AM 8/23/2006, you wrote: > >>>> I'm having problems loading "patch" parcels into a > runtime image, > >>>> because Overrides happen to access class comments and method > >>>> sources (which are absent from the runtime product). > It's getting > >>>> more and more frustrating to poke around in the Override > class tree > >>>> and apply fixes here and there ... Is there a better and simpler > >>>> solution for this? > >>>> > >>>> - How can Overrides be best disabled in a runtime image? > >>>> - Is this perhaps associated with the "3 Step Snapshot" of RTP? > >>>> > >>>> Thanks in advance for any suggestion. > >>>> > >>>> Andre > >>>> > > > > <Talk Small and Carry a Big Class Library> > > James Robertson, Product Manager, Cincom Smalltalk > > http://www.cincomsmalltalk.com/blog/blogView > > > > > > |
Re: Problem with overrides in runtime image
|
|
In reply to this post by James Robertson-3
James Robertson wrote:
> Just include the compiler in the runtime - it's an option in RTP. I know, but this is not an option for our products. This would result in a huge security threat. The deployed products have to be sealed and safe (as far as possible). Our market is extremely competitive and crowded by motivated crackers (who fortunately know nothing about Smalltalk - yet). Hence, no sources, no compiler. Andre |
Re: Problem with overrides in runtime image
|
|
In reply to this post by Andre Schnoor
hmm. w/o the compiler, you won't be able to load a large variety of
updates. So long as you don't include any browsing tools (like Trippy), what's the real risk? At 01:35 PM 8/23/2006, you wrote: >James Robertson wrote: >>Just include the compiler in the runtime - it's an option in RTP. > >I know, but this is not an option for our products. This would >result in a huge security threat. The deployed products have to be >sealed and safe (as far as possible). Our market is extremely >competitive and crowded by motivated crackers (who fortunately know >nothing about Smalltalk - yet). Hence, no sources, no compiler. > >Andre <Talk Small and Carry a Big Class Library> James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView |
Re: Problem with overrides in runtime image
|
|
In reply to this post by Andre Schnoor
At 01:35 PM 8/23/2006, Andre Schnoor wrote:
>James Robertson wrote: >>Just include the compiler in the runtime - it's an option in RTP. > >I know, but this is not an option for our products. This would result in a huge security threat. The deployed products have to be sealed and safe (as far as possible). Our market is extremely competitive and crowded by motivated crackers (who fortunately know nothing about Smalltalk - yet). Hence, no sources, no compiler. I would think there's an inherent conflict between wanting a runtime which is fully sealed and safe, and one which allows arbitrary updates to be loaded. -- 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 |
Re: Problem with overrides in runtime image
|
|
The direction the industry seems to have taken for secure updates is a
secure update server. But signed parcels might also be viable. Dave Alan Knight wrote: > At 01:35 PM 8/23/2006, Andre Schnoor wrote: >> James Robertson wrote: >>> Just include the compiler in the runtime - it's an option in RTP. >> I know, but this is not an option for our products. This would result in a huge security threat. The deployed products have to be sealed and safe (as far as possible). Our market is extremely competitive and crowded by motivated crackers (who fortunately know nothing about Smalltalk - yet). Hence, no sources, no compiler. > > I would think there's an inherent conflict between wanting a runtime which is fully sealed and safe, and one which allows arbitrary updates to be loaded. > > -- > 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 > > |
Re: Problem with overrides in runtime image
|
|
In reply to this post by Andre Schnoor
James Robertson wrote:
> hmm. w/o the compiler, you won't be able to load a large variety of > updates. So long as you don't include any browsing tools (like > Trippy), what's the real risk? The uncertainty is the risk. Smalltalk being an open system, there are many potential backdoors included with VW (all those command line options ... it is impossible for me to investigate all of them, also regarding the huge VM source code). I have to be sure to disable any possibility to get some sort of "script" executed. Removing the compiler is safe. Encrypting parcels is also a good solution (I'm using signed parcels already). The downside is that I probably have to limit updates to bug fixes only. Anyway, for a commercial product, that's already a substantial benefit. Andre |
RE: Problem with overrides in runtime image
|
|
In reply to this post by Andre Schnoor
>> James Robertson wrote:
>> hmm. w/o the compiler, you won't be able to load a large variety of >> updates. As far as I remember, you can use BOSS to supply updates to classes, without the compiler. Although as Alan pointed out, if there is ANY way to update the system (even just methods or values), it can be cracked and used against you. But then, even if there is no way to update the system, it can be cracked. > > So long as you don't include any browsing tools (like > > Trippy), what's the real risk?> > > Andre Schnoor wrote: > The uncertainty is the risk. Smalltalk being an open system, there are > many potential backdoors included with VW (all those command line > options ... it is impossible for me to investigate all of them, You can turn them all off easily with settings in VW and RTP. > also regarding the huge VM source code Especially if you distribute with the .dll. The visual.exe version is somewhat safer. > Removing the compiler is safe. There is some level of risk these days, as so many more things rely on it. Back in VW 3, when because of licensing terms you normally couldn't distribute an executable including it, the system had to work without it. Still, removing it doesn't actually help you much at all in terms of security. If someone can hack your program, they can most definitely provide methods as byte code rather than source, so no need for the compiler. Of course it's one extra bar in the gate, but not much of one. > Encrypting parcels is also a good solution (I'm using signed > parcels already). You definitely want signed and encrypted updates - the signing mostly to make them tamperproof. Hope this helps! Steve |
Re: Problem with overrides in runtime image
|
|
As far as I remember, you can use BOSS to supply updates to classes, without the compiler. Although as Alan pointed out, if there is ANY way to update the system (even just methods or values), it can be cracked and used against you. But then, even if there is no way to update the system, it can be cracked. Of course can it be cracked, even with signed and encrypted parcels. But, given the numerous other measures I've taken (can't elaborate on that here), it will be extremely tedious and hard. I doubt a serious Smalltalker will have much fun doing this. Moreover, attacking one of the very few (hopefully successful) commercial B2C Smalltalk apps would also seriously harm the ST scene. Everybody will know "the black hat is among us" ;-) The real issue is: Will people accept a cracked version as a permanent substitute for the original? That's all I care about. If a cracked version is full of obvious artifacts, not eligible to technical support or patches, not able to exchange files with legal versions etc (I've taken several measures in this regard), then nobody who is seriously interested in the product will use a pirated copy for long. If I lose less than 30% of revenues to piracy in the mid term, that'll be just enough to keep the shop alive. If it's less than 20%, my motivation will also stay alive.
Yes, thanks for the thoughts regarding VW3 and the compiler. My apps run fine without it, but I'll have an eye an that. Andre |
Re: Problem with overrides in runtime image
|
|
In reply to this post by Andre Schnoor
I can't reproduce this in a 7.4.1 image by creating a runtime with a workspace open, and evaluating
Parcel loadParcelFrom: .... on a parcel that overrides a class definition. I've explicitly remove the XML parser from the system, and it doesn't ever appear to get there. It appears to me that in a runtime, which presumably will have sources removed, that it shouldn't ever get through to that stage, because it shouldn't be finding any non-empty strings to operate on. At 11:00 AM 8/23/2006, Andre Schnoor wrote: >Thanks for the advice, James, but it doesn't seem to work in my case. > >I wrapped RuntimeUpdateParcel>>loadFrom: with your code. BTW, RuntimeUpdateParcel is a subclass of Parcel and does nothing special. It's purpose is to keep a registry of loaded updates in a class instance variable and ignore #triggerParcelLoaded: in order to not mess up with source code updates at runtime. > >I suspect that > > CodeComponent class>>handleCodeReaderSignalsDo:for: > >catches all the exceptions already, so they won't reach the outer handler. It also seems that overrides are created anyway - exceptions raised or not. > >Here's a stack trace: > > ##### Error, because XML.SAX stuff isn't found (related to source management) >[1] LiteralBindingReference(Object)>>error: >[2] LiteralBindingReference(GeneralBindingReference)>>binding >[3] LiteralBindingReference(GeneralBindingReference)>>value >[4] DocumentationSystem class>>isCommentWithoutXML: >[5] optimized [] in SourceFileManager>> >[6] SourceFileManager>>retrieveStringAt:using:format:ifAbsent: >[7] SourceFileManager>>documentationAt:ifAbsent: >[8] ChimeraZoomButton class(ClassDescription)>>stDocumentation >[9] ChimeraZoomButton class(ClassDescription)>>comment >[10] OverridenClass>>from: >[11] Override class>>forClassOrNameSpace: > > ##### here's where overrides are created >[12] CodeReader>>relocateOrReplaceName:from:to:map: >[13] optimized [] in [] in CodeReader>> >[14] optimized [] in CodeReader>> >[15] OrderedCollection>>do: >[16] CodeReader>>shadow:of:do: >[17] optimized [] in CodeReader>> >[18] OrderedCollection>>do: >[19] CodeReader>>shadow:of:do: >[20] optimized [] in CodeReader>> >[21] BlockClosure>>on:do: >[22] optimized [] in SystemUtils class>> >[23] BlockClosure>>ensure: >[24] SystemUtils class>>modifySystem: >[25] CodeReader>>installBindingsInSystem >[26] optimized [] in CodeReader>> >[27] BlockClosure>>ifCurtailed: >[28] CodeReader>>installInSystem >[29] optimized [] in CodeComponent>> >[30] BlockClosure>>on:do: > > ##### This one catches many exceptions: >[31] RuntimeUpdateParcel class(CodeComponent class)>>handleCodeReaderSignalsDo:for: >[32] RuntimeUpdateParcel(CodeComponent)>>loadFrom:using: >[33] optimized [] in [] in RuntimeUpdateParcel>> >[34] BlockClosure>>on:do: >[35] optimized [] in RuntimeUpdateParcel>> >[36] BlockClosure>>on:do: > > ##### here's where I wrapped your exception handling: >[37] RuntimeUpdateParcel>>loadFrom: > > > > >James Robertson wrote: >>In BottomFeeder, I reload parcels with updates/new code/overrides at runtime, and I use this code to do the actual parcel load: >> >> [[Parcel loadParcelFrom: parcelFile] on: Parcel parcelAlreadyLoadedSignal, CodeStorageError >> do: [:ex | ex resume: true]] >> on: DuplicateBindingsError >> do: [:ex | ex resume] >> >> >> >>At 09:49 AM 8/23/2006, you wrote: >>>I'm having problems loading "patch" parcels into a runtime image, because Overrides happen to access class comments and method sources (which are absent from the runtime product). It's getting more and more frustrating to poke around in the Override class tree and apply fixes here and there ... Is there a better and simpler solution for this? >>> >>>- How can Overrides be best disabled in a runtime image? >>>- Is this perhaps associated with the "3 Step Snapshot" of RTP? >>> >>>Thanks in advance for any suggestion. >>> >>>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 |
Re: Problem with overrides in runtime image
|
|
Alan,
thank you for examining this issue. Your mention of "non-empty strings" made me wonder, if some of my stripping code might cause the problem. Because I found complete code comments in a stripped image, I started setting the comments of all packages, parcels and bundles to "String new" during the packaging process - perhaps I should set them to nil instead? Andre (here's the code) cleanUpComments "Remove all comments from packages, parcels and classes" self cleanUpCommentsIn: Store.Package; cleanUpCommentsIn: Store.Bundle; cleanUpCommentsIn: Store.PackageModel; cleanUpCommentsIn: Store.BundleModel; cleanUpCommentsIn: Store.Parcel. cleanUpCommentsIn: aCodeComponentClass "Remove comments from packages, bundles and parcels" aCodeComponentClass allInstances do:[ :p | p commentOrNil isNil ifFalse:[ p comment: String new ]]. Alan Knight schrieb: I can't reproduce this in a 7.4.1 image by creating a runtime with a workspace open, and evaluating Parcel loadParcelFrom: .... on a parcel that overrides a class definition. I've explicitly remove the XML parser from the system, and it doesn't ever appear to get there. It appears to me that in a runtime, which presumably will have sources removed, that it shouldn't ever get through to that stage, because it shouldn't be finding any non-empty strings to operate on. At 11:00 AM 8/23/2006, Andre Schnoor wrote: |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |