[squeak-dev] A thought about 'Cannot locate .sources file' message

Ron Teitelbaum ron at usmedrec.com
Tue Dec 21 16:31:14 UTC 2010


Production images don't have sources files.  This is a development issue.  I
think the message is fine.

Ron Teitelbaum

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-
> dev-bounces at lists.squeakfoundation.org] On Behalf Of Bert Freudenberg
> Sent: Monday, December 20, 2010 6:55 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] A thought about 'Cannot locate .sources file'
> message
> 
> 
> On 21.12.2010, at 00:34, David T. Lewis wrote:
> 
> > On Mon, Dec 20, 2010 at 05:16:41AM +0100, Alexander Lazarevi?? wrote:
> >> 2010/12/20 Igor Stasenko <siguctua at gmail.com>
> >>
> >>> On 20 December 2010 02:09, Hern??n Morales Durand
> >>> <hernan.morales at gmail.com> wrote:
> >>>> Yes, or locate it in a directory and/or copy to the current one. By
> >>>> the way, it could be configured a location for just having only one
> >>>> sources file?
> >>>
> >>> +1 . it would be nice to be able to specify a system-wide location
> >>> +for
> >>> .sources files,
> >>> so any image could look for them at this place first than looking at
> >>> current directory.
> >>>
> >>
> >> First the sources are searched at the vmPath, then at the imagePath
> >> and finally at the defaultPath (which could be the same as the
> >> imagePath, see [1]).
> >> On Unix the vmPath will be no option for a central directory to hold
> >> the sources files, because it's usually /usr/bin, unless you have
> >> installed your vm locally in your home directory.
> >> I think it would be nice to have a vm SystemAttribute to hold the
> >> sources path. This could be defined during installation, overridden
> >> by .ini files, command line switches, props or whatever and always
> >> default to vmPath if no other info is available. But the reception
> >> for this change wasn't so good as far as I remember, maybe mainly
> >> because the issue isn't so pressing while running on Windows/MacOS
> >> (or that everything that defines the concept of having a sources file
> should be completely on the image side).
> >>
> >> Alex
> >>
> >> [1] FileDirectory class openSources: fullSourcesName forImage:
> >> imageName
> >
> > I don't like the idea of adding a system attribute because it adds a
> > dependency on the VM version, and also because the issue can be
> > handled completely in the image.
> >
> > Given that the concern exists only for Unix VM installations, we can
> > make use of existing installation directory conventions. The Unix VMs
> > are installed under /usr/local/lib/squeak/ with a different
> > subdirectory for each version of the VM (e.g.
> > /usr/local/lib/squeak/4.4.1-2329/). Thus a solution would be to put
> > the sources files for all images (Squeak, Pharo,
> > etc) under /usr/local/lib/squeak/. In this scenario, the image would
> > look first in the vmPath (e.g. /usr/local/lib/squeak/4.4.1-2329/) and
> > then look one level up in /usr/local/lib/squeak/. This would be
> > harmless for non-Unix platforms, and would address the problem for
> > Unix. All sources files could be shared from a single location, and no
> > new concepts or VM modifications are needed.
> >
> > Patch attached to illustrate the approach.
> >
> > Dave
> 
> The proper location would be under /usr/(local/)share/ because the image
is
> platform independent and thus sharable between architectures, where
> binaries and libraries are not. What you are proposing is as much a hack
as
> just looking in vmPath. Just sayin' ;)
> 
> However, opinions about "proper" locations differ. I agree with Alex that
the
> actual location should be configurable by the system maintainer. OTOH the
> VM really has no business knowing about source files. I'd think adding a
> primitive to read an environment variable might serve this best. It would
be
> generally useful, and should not do much harm security-wise (it should be
> guarded by the SecurityPlugin to be really safe).
> 
> - Bert -
> 
> 





More information about the Squeak-dev mailing list