On Wed, Jun 4, 2014 at 5:17 PM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Wed, Jun 04, 2014 at 09:36:46AM +0200, Bert Freudenberg wrote:
> > > If I hadn't had access to the working laptop, I don't know what I
> > > would have done.  Hopefully we'll be able to improve Squeak's
> > > accessibility someday..
> >
> > Doesn't get much easier than
> >
> >       apt-get install squeak-vm
> >
>
> Indeed :-)
>
>
> > If that doesn't work, file a bug report.
> >
> > That won't get you Cog at the moment. But it could, if someone put in
> the effort.
> >
> > Tim's new Scratch release would be a fine incentive if it was packaged
> to require either a Cog or Stack VM. This worked for Etoys, which I
> packaged to require a Squeak VM package. That's why a Squeak VM is now in
> every major Linux distro.
> >
> > Of course, that plan would require to get two new packages into all
> distros, which isn't exactly easy. Another plan would be to package the
> interpreter and cog in a single source package and just call that the new
> release. Then this would be picked up almost automatically by the distro
> maintainers.
> >
>
> For the near term, the source packages should be separate. It is easy to
> manage
> that way, and we should not allow the task of merging the trunk and oscog
> code
> bases to stand in the way of providing good Linux installation packages for
> both Cog and squeak-vm. We should name the packages in some way that
> emphasizes
> that they are strongly related. The "squeak-vm" name is established and
> makes
> sense, so possibly "squeak-cogvm" or something similar could be used.
>
> > Long-term this might even be the better plan because then the user
> wouldn't have to worry which VM to use for which image. We might even be
> able to consolidate the VMs into a single executable which chooses a
> pluggable execution engine and object memory at runtime.
> >
>
> This is the right direction, and the /usr/bin/squeak script already
> contains
> hooks for the Cog executable, with the intent that Cog should be selected
> where possible, and fall back on an interpreter VM for images that require
> it.
> My own opinion is that this is premature, because 32 and 64 bit modules
> cannot
> be mixed, and I think we have now reached at the point where 64 bit
> platforms
> are the norm rather than the exception. Nevertheless, the hooks are in
> place
> and we should aim in that direction.
>
> > So, basically this just requires some effort on making nice source
> packages for distro maintainers. David and lately tty have been working
> towards that, and maybe someone else can join in (and be it just testing
> and commenting in what they produce).
> >
> > - Bert -
>
> In my view, supporting one or more Linux distros is an important function,
> and in many ways similar to the platform owner role that we have
> traditionally
> used within the VM team, in which the original authors of the various VM
> platform
> implementations (initially John, Ian, Andreas, Tim) have assumed
> responsibility
> for specific OS platforms. We have never really had someone officially in
> the
> role of coordinating Linux distributions of the VMs, for which the ability
> to
> build from source is critical, and where various licensing issues may come
> into play.
>
> Bert has provided leadership in making the initial Linux distributions
> happen,
> but I'm not sure that he intended this to be an ongoing responsibility
> (Bert,
> please correct me if I'm wrong). So if someone is interested in taking on
> some
> work in that area, please do speak up. Discussion should go to the vm-dev
> list.
>
> I think it is important to say also that that Eliot is currently providing
> a range of Cog VMs on various platforms at the same time that he is doing
> cutting edge new work on VMs and object memories. We are all grateful and
> happily taking advantage of that work, but as a community we need to
> support
> this, and if someone can put some energy into providing supported packages
> for both squeak-vm and Cog for Linux distributions, I think that it would
> be
> a welcome contribution.
>

+1.

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140604/2724e824/attachment.htm