A thought about 'Cannot locate .sources file' message

> Hi,
>
> just a thought.. maybe it worth instead of just informing user, also
> offer him to download sources file from web?
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

> Cheers,
>
> Hernán
>
> 2010/12/19 Igor Stasenko <[hidden email]>:
>> Hi,
>>
>> just a thought.. maybe it worth instead of just informing user, also
>> offer him to download sources file from web?
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>

> On Mon, Dec 20, 2010 at 05:16:41AM +0100, Alexander Lazarevi?? wrote:
>> 2010/12/20 Igor Stasenko <[hidden email]>
>>
>>> On 20 December 2010 02:09, Hern??n Morales Durand
>>> <[hidden email]> 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

> -----Original Message-----
> From: [hidden email] [mailto:squeak-
> [hidden email]] 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 <[hidden email]>
> >>
> >>> On 20 December 2010 02:09, Hern??n Morales Durand
> >>> <[hidden email]> 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