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