[BUG] Abandon Sources Failure in 3.2

Scott Wallace squeak-dev at lists.squeakfoundation.org
Sun Oct 20 22:42:22 UTC 2002


Michael,

What you're describing is actually unrelated to "abandon sources," 
which actually undertakes to *preserve* some aspects of the full 
development environment when for some reason sources cannot be 
available.

For *sealing off* the development environment, see, for example:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-July/016300.html

Hope this helps,

   -- Scott


At 9:29 AM -0600 10/16/02, michael.cole at nimiq.net wrote:
>Scott,
>
>Thanks once again for the detailed and thoughtful reply. I will try the
>workaround.
>
>The interest in 'abandon sources' is to be able to deliver an
>application, hardened to make it impossible for the user to see or
>modify the code. I have been under the impression that 'abandon sources'
>is at least part of the answer to this need.
>
>I suppose the most general question (to the list) is this. What needs to
>be done (in 3.2 and in 3.3) to deliver a squeak-based application where,
>minimally:
>	- the user cannot access any code
>	- the user cannot modify the application (so no squeak code executable
>from text etc.)
>	- access to the ctrl-alt programming support is turned off (save for
>clipboard cut, paste and undo) [Did there not used to be such an option
>in preferences? What is now there doesn't have this effect.]
>
>I'm sure there are other criteria for application delivery that others
>can add to this list.
>
>My sense was that these issues were high on the agenda in the stable
>squeak movelet, but I've not seen much recently regarding application
>delivery per se.
>
>Squeak is already doing real work in the real world. Hardening it to the
>rigors of the harsh world where people will break applications in ways
>one never imagines is critical to ensure squeak gets off on the right
>foot when it is ready for its close up (and I my view it is already
>there).
>
>Michael Cole
>michael.cole at nimiq.net
>
>Scott Wallace <scott.wallace at squeakland.org> wrote:
>  >
>>  Hi again, Michael,
>>
>>  (There are others on the Squeak list better qualified to respond to
>>  this than I, but since no one else has, here's what I can come up
>>  with:)
>>
>>
>>  First a question:
>>
>>  Are you certain you *need* to use "abandonSources"?
>>
>>  I don't think anyone else has had occasion to use abandonSources for
>>  a very long time -- anyone trying this anytime recently would have
>>  encountered the same sequence of difficulties you've encountered ;-).
>>
>>  You don't need to "abandonSources" to operate without a sources file.
>>  You just ship your code without a sources file, and all should be
>>  well.  Similarly, a .changes file is optional -- just ship without it.
>>
>>  By simply setting the "warnIfNoSourcesFile" preference to "false",
>>  your user will not see the warnings that otherwise come when you
>  > start up an image and the sources file cannot be found.  Similarly
>  > for "wornIfNoChangesFile".
>  >
>  > All you're losing (I *think* -- someone will surely correct me if I'm
>  > wrong) by simply omitting the sources file is the ability to see nice
>  > temp-names and nice formal-argument-names and comments and original
>  > source-code formatting when viewing code.
>  >
>  > So perhaps you're best served by abandoning the use of
>  > abandonSources.  In which case you need read no further.
>  >
>  > ***********
>  >
>  > That having been said...
>  >
>  > At issue here is a method whose temp-names string is 441-characters
>>  long, whereas the qCompress: method works properly only for
>>  temp-name-strings up to 256 characters long.
>>
>>  I spoke to Dan about this last week, and he said that there should be
>>  a simple workaround, such that the format that places qCompressed
>>  temp-names in the trailer would *not* be used if the aggregate
>>  temp-names string is seen to be too long.
>>
>>  Still, it's going to require Dan, or Bill Dargel (whose initials from
>>  four years ago still are still emblazoned on the #abandonSources
>>  method,) or someone else willing to bite the bullet here, to make the
>>  fix.
>>
>>  Incidentally, the method in question has a 206-character-long
>  > selector, and 12 arguments, and 35 temp names.
>>
>>  Class: GeniePlugIn     Selector:
>> 
>>#primSameClassAbsoluteStrokeDistanceMyPoints:otherPoints:myVectors:otherVectors:mySquaredLengths:otherSquaredLengths:myAngles:otherAngles:maxSizeAndReferenceFlag:rowBase:rowInsertRemove:rowInsertRemoveCount:
>  >
>>  (Even more incidentally, this 206-character-long-selector is not the
>>  longest in the system; there is another that is 221-characters long,
>>  and btw five others that are also longer than 100-characters in
>>  length.)
>>
>>  I offer, attached, a little fileout that works around the limitation
>>  in this one GeniePlugIn method by reassigning its temp-names to be
>>  t1, t2, etc. (I did this by filing out the method from an image that
>>  had no access to sources or temps, so it had to resort to pure
>>  decompilation.)  If you file this cs into your system, you should be
>>  able to get further in your quest for abandoning sources, if you're
>>  still interested in doing that ;-)
>>
>>  Hope this helps.
>>
>>  Cheers,
>>
>>    -- Scott
>>
>>
>>
>>
>>  At 9:57 AM -0600 10/7/02, cole at nimiqinc.com wrote:
>>  >Scott,
>>  >
>>  >Thanks for the quick reply. Editing the method solved that problem, but
>>  >I now get another error complaining of an improper store in the
>>  >CompiledMethod copyWithTempNames qCompress method. Again, I have
>>  >confirmed the same error in a stock 3.2 image.
>>  >
>>  >Michael
>>  >
>>  >
>>  >
>>  >Scott Wallace <scott.wallace at squeakland.org> wrote:
>>  >>  Michael,
>>  >>
>>  >>  Very interesting!  Indeed, the decompiled version of this method
>>  >>  (Morph.mouseDownPriority) cannot be recompiled because it has code
>>  >>  (viz. the #flag: call) after the logical method end.
>>  >>
>>  >>  An easy workaround is:  before abandoning sources, just submit a
>>  >>  revised version of this problematic method in which you have removed
>>  >  > the #flag call, which has no functional role in the method anyway.
>>  >>  The replacement method could be the following:
>>  >>
>>  >>  ------
>>  >>
>>  >  > !Morph methodsFor: 'events-processing' stamp: 'sw 10/5/2002 01:18'!
>>  >  > mouseDownPriority
>>  >>	"Return the default mouse down priority for the receiver"
>>  >  >
>>  >  >	^ (self isPartsDonor or: [self isPartsBin])
>>  >  >		ifTrue:	[50]
>>  >  >		ifFalse:	[0]! !
>>  >  >
>>  >  > ------
>>  >  >
>>  >  > With any luck, this is the only method that has this problem, but if
>>  >>  any others are revealed, they can be dealt with in the same way.
>>  >>
>>  >>  Hope this helps,
>>  >>
>>  >>     -- Scott
>>  >>
>>  >>
>  > >>
>>  >>  At 11:55 AM -0600 10/4/02, cole at nimiqinc.com wrote:
>>  >>  >Hi,
>>  >>  >
>>  >>  >In trying to deliver a small application based on 3.2 I found that I am
>>  >  > >unable to successfullt abandon sources. The failure comes 
>>with a syntax
>>  >  > >error in Morph events-processing MouseDownPriority:
>>  >  > >
>>  >  > >mouseDownPriority
>>  >>  >	(self isPartsDonor
>>  >>  >			or: [self isPartsBin])
>>  >>  >		ifTrue: [^ 50].
>>  >>  >	^ 0.
>>  >>  >	End of block expected ->self flag: #workAround
>>  >>  >
>>  >>  >I checked this in a stock 3.2 image and was also unable to abandon
>>  >  > >sources (but did not get exactly the same error message).
>>  >  > >
>>  >  > >Any ideas?
>>  >  > >
>>  >  > >
>  > >  > >Michael



More information about the Squeak-dev mailing list