<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 5:17 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wed, Jun 04, 2014 at 09:36:46AM +0200, Bert Freudenberg wrote:<br>
> > If I hadn't had access to the working laptop, I don't know what I<br>
> > would have done. Hopefully we'll be able to improve Squeak's<br>
> > accessibility someday..<br>
><br>
> Doesn't get much easier than<br>
><br>
> apt-get install squeak-vm<br>
><br>
<br>
</div>Indeed :-)<br>
<div class=""><br>
<br>
> If that doesn't work, file a bug report.<br>
><br>
> That won't get you Cog at the moment. But it could, if someone put in the effort.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
<br>
</div>For the near term, the source packages should be separate. It is easy to manage<br>
that way, and we should not allow the task of merging the trunk and oscog code<br>
bases to stand in the way of providing good Linux installation packages for<br>
both Cog and squeak-vm. We should name the packages in some way that emphasizes<br>
that they are strongly related. The "squeak-vm" name is established and makes<br>
sense, so possibly "squeak-cogvm" or something similar could be used.<br>
<div class=""><br>
> 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.<br>
><br>
<br>
</div>This is the right direction, and the /usr/bin/squeak script already contains<br>
hooks for the Cog executable, with the intent that Cog should be selected<br>
where possible, and fall back on an interpreter VM for images that require it.<br>
My own opinion is that this is premature, because 32 and 64 bit modules cannot<br>
be mixed, and I think we have now reached at the point where 64 bit platforms<br>
are the norm rather than the exception. Nevertheless, the hooks are in place<br>
and we should aim in that direction.<br>
<div class=""><br>
> 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).<br>
><br>
> - Bert -<br>
<br>
</div>In my view, supporting one or more Linux distros is an important function,<br>
and in many ways similar to the platform owner role that we have traditionally<br>
used within the VM team, in which the original authors of the various VM platform<br>
implementations (initially John, Ian, Andreas, Tim) have assumed responsibility<br>
for specific OS platforms. We have never really had someone officially in the<br>
role of coordinating Linux distributions of the VMs, for which the ability to<br>
build from source is critical, and where various licensing issues may come<br>
into play.<br>
<br>
Bert has provided leadership in making the initial Linux distributions happen,<br>
but I'm not sure that he intended this to be an ongoing responsibility (Bert,<br>
please correct me if I'm wrong). So if someone is interested in taking on some<br>
work in that area, please do speak up. Discussion should go to the vm-dev list.<br>
<br>
I think it is important to say also that that Eliot is currently providing<br>
a range of Cog VMs on various platforms at the same time that he is doing<br>
cutting edge new work on VMs and object memories. We are all grateful and<br>
happily taking advantage of that work, but as a community we need to support<br>
this, and if someone can put some energy into providing supported packages<br>
for both squeak-vm and Cog for Linux distributions, I think that it would be<br>
a welcome contribution.<br></blockquote><div><br></div><div>+1.</div><div><br></div></div>-- <br>best,<div>Eliot</div>
</div></div>