My own Squeak direction

El dom, 15-11-2009 a las 12:17 -0500, Chris Cunnington escribió:

> I'm content to watch Pharo take new Seaside releases and disappear over the horizon.

Taking with them half the new users that Squeak has got the last 3
years.


>
> Chris
--
Miguel Cobá
http://miguel.leugim.com.mx

I built a 64bit VM a few years ago and converted one of my images. I had
some success but I don't remember the issues I had run into with the image
conversion.

Travis

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of David T.
Lewis
Sent: Sunday, November 15, 2009 6:20 AM
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] 64 bit images

On Sun, Nov 15, 2009 at 02:39:24PM +0100, Bert Freudenberg wrote:
> On 15.11.2009, at 03:46, Travis Kay wrote:
>
> >  I would like to see [..] 64bit (image too)
>
> Curious: what would you do if you could have a huge image?

Good question. The original Squeak 64-bit image is about five years
old now, and does not seem to have attracted much interest of a practical
nature:

  http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz

An updated version of this image, suitable for use on current Squeak
VMs, is here:

  http://squeakvm.org/squeak64/sq64-dtl.zip

You do need to build your own VM to use this image. There is nothing
exotic about it, you just have to click the "64-bit image" checkbox
on VMMaker to activate the 64-bit object memory version.

John McIntosh with support from ESUG is planning to do new work for
a Mac VM, including 64-bit object memory support. Hopefully this will
encourage new interest in the topic.

Help needed: Currently there is no way to convert new images (Squeak trunk,
Cuis, Pharo, etc) into 64-bit format. If anyone has some expertise with
SystemTracer, it would be good to get this working.

  http://bugs.squeak.org/view.php?id=5239
  http://bugs.squeak.org/view.php?id=5240

Dave
 

> My long-term vision for Squeak is to bring it back to being a medium for
> personal dynamic media. I want Squeak to be a fun, educational, small,
> dynamic, media-centric environment.

Great. There is nothing like Squeak in that arena, that's where it
belongs IMO.

> I'd be interested in hearing what others working on and in Squeak have
> to say about their own directions.

I'm building on top of Squeak. The base you propose, a medium for
personal dynamic media, is exactly what I need to be maintained. On top
of that I'm developing a very dynamic and rather ambitious musical
composition environment. It is a slow-paced long-term project, steadily
evolved for almost ten years now (although it did not start in Squeak).
My main need is that Squeak remains mostly backward-compatible, as it
currently is (I'm talking about the trunk).

At the moment the only sore point I have is the lack of MIDI support in
the linux VM.

Otherwise, rather pleased at the current spirit in squeak-dev.


best,

Stef

> - Music. I want to make music with Squeak. Has anyone heard of Siren
> or DynaPiano?

see Musical Objects for Squeak, my own project:
http://www.zogotounga.net/comp/squeak/sqgeo.htm

feedback welcome...

Stef

On Sat, Nov 14, 2009 at 03:28:49PM -0800, Andreas Raab wrote:
>
> I'd be interested in hearing what others working on and in Squeak have
> to say about their own directions. Together it should give a pretty
> comprehensive understanding about where Squeak is headed in practice.

I plan to continue working on various Squeak projects in my spare time.
In the future I would like to be able to do this as a retirement project
if my brain holds out, possibly a few more years at the current rate
of decline ;-)

I will continue maintaining my current projects (OSProcess, TimeZoneDatabase,
etc) as well as contributing to VMMaker and Squeak trunk where I can.
I would also like to contribute to updating Etoys and Squeak in a more
coordinated way.

I think that multimedia capabilities make Squeak very appealing. I also
like the extreme scalability of the environment, with everything from
a Spoon minimal image up to 64-bit object memories, SqueakNOS up to
large scale servers, and all done with an interpreter written mainly
in Smalltalk.

I take a rather dim view of "professional software" in general, and
that line of development does not interest me much. Well, except for
Seaside and AIDA, which are great.

One of these days I'd like to try integrating Squeak with BCPL such
that Squeak could be a host environment for BCPL/Cintpos and vice-versa.

Dave

>>>>> "Chris" == Chris Cunnington <[hidden email]> writes:

Chris> It's clear to me from things Julian Fitzel has said that the Seaside
Chris> maintainers will not be porting to Squeak. They plan to develop for
Chris> Pharo exclusively.

I don't think you're reading that the same way I read it.  I think they're
saying that while they aren't intentionally breaking it for Squeak core, they
also won't have anyone serving as the "canary in the coal mine" to see if it
has broken.

And so far, it hasn't.  3.0 works just fine on Squeak-trunk.  I actually think
that anything that Seaside breaks can be fixed by making Squeak-trunk support
what Pharo has.  Ultimately, there shouldn't need to be a different layer for
"Squeak Compat" vs "Pharo Compat".  Squeak *is* Pharo.  Pharo *is* Squeak.
They just have redundant dev teams. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Juan Vuletich wrote:
> My own Squeak direction is described in
> http://www.jvuletich.org/Cuis/Index.html . As it seems to be
> incompatible with that of many in the community, it requires a fork.
>
> Aside from that, I fully support your direction, and I'll try to keep
> helping. Of course, I'd be delighted if at least some of my objectives
> were adopted for Squeak too.

While it is good to avoid forking as much as possible, I always like to
remind people that Squeak 3.8 was a merge of four forks (squeak.org 3.7,
Squeakland, SmallLand and OpenCroquet) and that merges might also happen
in the future. My own vision, described below, requires a radical
rewrite of ObjectMemory and a significant patch of message sending in
Interpreter. So this will probably require a fork as well (we shall see
- I had hoped to be able to work on this starting in August, but now
next January seems more likely).

I would like for there to be a single, world-wide image for Squeak. This
would be split up into many relatively small, immutable files for
storage. A given machine probably wouldn't have access to the whole set
of files at any one time. This image would support multiple simultaneous
viewpoints such that if you have a pointer to an object and I have a
pointer to the same object we might get different results when sending
the exact same message. The viewpoints are managed mostly manually with
a reasonable visual representation.

Each node only loads into RAM as much of the global image as it needs to
run its current code. Several nodes might collaborate by loading
different parts of the image and sending messages to each other.
Alternatively, several nodes might load the same parts of the image and
keep in sync with the TeaTime scheme. Machines with 16 thousand
SiliconSqueak cores are in the early planning stage, which gives you an
idea of how far I think we can scale this.

At the other extreme, a headless application running on a single core
with only the barest parts of the image that it needs to support it
should fit easily in just 128KB of memory. Other applications might have
fancy multimedia features and I would like the option to have as much of
this in Squeak so that bare hardware is a practical platform, even as
Squeak makes better and better use of native features in other OSes. I
would like SqueakNOS to be safer and more robust than current OSes.

-- Jecel

On Sunday 15 November 2009 04:58:49 am Andreas Raab wrote:
> Folks -
>
> I feel like the recent discussion about directions left us without much
> progress in terms of where we think Squeak is headed. I actually don't
> think this is particularly hard to formulate, since as we all know,
> Squeak will be headed where we make it head to. In other words, I think
> we could come up with a pretty good idea of where Squeak will be headed
> if those people who actually contribute tell a little bit more about
> their interests and directions. So let me be the first to start here:
Thank you for the initiative. My own interests for Squeak are:

* Make Squeak run off removable flash memory devices gracefully. This will
require elimination of redundant saves of project files (Squeaklets), use of
RAM file systems for temporary directories, better integration with host's
desktop manager dialogs, launchers that autodetect path settings before
launching Squeak etc.

* Indic language support but without an explosion in the size of the image due
to a profusion of fonts.
 ** TeX-like text layout engines in Squeak to handle multi-lingual paragraphs.
 ** Add Metafont-like capabilities to Squeak where one-time glyphs can be
generated on the fly and saved in the image as a regular object.
 ** Extend Morphs to derive shapes from scripts like PS or SVG in preparation
for a zoomable interface.
 ** Virtual keyboard and input methods

My dream is to see Squeak become a mobile digital environment for learners
across the world that frees (atleast isolates) them from dependencies on
specific machines, machine architecture and form factors.

Subbu

On 11/14/09 9:28 PM, "Andreas Raab" <[hidden email]> wrote:


I trying to do exact you are writing now, nice to see Master of Masters
doing what I only dream.

Edgar

On 11/15/09 12:20 PM, "David T. Lewis" <[hidden email]> wrote:

> John McIntosh with support from ESUG is planning to do new work for
> a Mac VM, including 64-bit object memory support. Hopefully this will
> encourage new interest in the topic.

I try the last VM I have and don't work .
John, you have a ready to run one ? Where ?

Edgar

Andreas Raab wrote:
Amen!

>> My own Squeak direction is described in
>> http://www.jvuletich.org/Cuis/Index.html . As it seems to be
>> incompatible with that of many in the community, it requires a fork.
>
> I don't think that the goals are incompatible. With more work on
> modularity, I think that your goals can be a subset of those in the
> larger community (just as my goals are a subset of those).

Yes, you are right. When modularity in Squeak gets good enough, Cuis
could merge back. That would be great.

I'd like to know about where we don't agree.Your opinion is very
valuable to me. Besides, it would help me think on making optional
packages for a Squeak kernel with the specific features of Cuis I'd like
to keep.


Cheers,
Juan Vuletich

Jecel Assumpcao Jr wrote:
I wonder what do you have in mind as typical uses for this
functionality. While I applaud efforts on modernizing Smalltalk, I'm a
bit reluctant of changes to the language semantics.

> Each node only loads into RAM as much of the global image as it needs to
> run its current code. Several nodes might collaborate by loading
> different parts of the image and sending messages to each other.
> Alternatively, several nodes might load the same parts of the image and
> keep in sync with the TeaTime scheme. Machines with 16 thousand
> SiliconSqueak cores are in the early planning stage, which gives you an
> idea of how far I think we can scale this.
>  

Wow! Experimenting with such a system would be fantastic!


Great.

Cheers,
Juan Vuletich

Juan Vuletich wrote:
> Jecel Assumpcao Jr wrote:
> > Juan Vuletich wrote:
> > [single, world-wide image for Squeak]
>
> I wonder what do you have in mind as typical uses for this
> functionality.

Right - it was silly of me to go into some technical details of how I
hope to achieve my goals without explaining first what these goals are:

I want it to be easy and elegant to create and share persistent objects
using Squeak.

Solutions like Monticello+package universes/squeakmap are a bit too
complicated for me and yet don't do some things that I want.
Deltastreams would improve that somewhat. Keith's scripts solve some
problems by automating stuff at the cost of making manual other things
that I would like to be automatic. I find Spoon very interesting though
I don't think it will scale to the level I want. The Squeakland and
Scratch use projects to share, but that isn't very robust since these
have very strict requirements about the environment into which they can
be loaded without be explicit about what these requirements are.

> While I applaud efforts on modernizing Smalltalk, I'm a
> bit reluctant of changes to the language semantics.

Though I have no problems with cleaning up Smalltalk's semantics (as
should be obvious from my participation in the Self community), I did
not include any such changes in my vision for Squeak. In fact, I also
participate in the ANSI Smalltalk effort which would bring Squeak closer
to the other Smalltalks rather than make even more different than it
already is. I don't think changing how images are saved and loaded has
any effect on the language semantics though it might change how you use
it (just like adding virtual memory doesn't change C, but might allow a
different programming style).

> > [16 thousand SiliconSqueak cores]
>
> Wow! Experimenting with such a system would be fantastic!

There are a few steps before we get there. I'll keep the community
informed of any progress we make.

-- Jecel

Hi guys!

Gotta chime in somewhere here and since Jecel mentioned DS... :)

Jecel Assumpcao Jr wrote:
> I want it to be easy and elegant to create and share persistent objects
> using Squeak.
>
> Solutions like Monticello+package universes/squeakmap are a bit too
> complicated for me and yet don't do some things that I want.

I don't associate those tools much with "persistent objects", mostly
(well, SM can do Projects so sure...) with source code.

> Deltastreams would improve that somewhat.

Eventually and hopefully. Since Brest I haven't had any time at all to
put on "private Squeaking" though. But it is still there on the back
burner. :)

Otherwise I:

- Really like what Andreas wrote. :)
- Will hopefully work on web stuff using Seaside in near future "for pay".
- Continue working on Gjallar and DeltaStreams.
- Will work on improving the CouchDB client code.
- Am highly interested in getting Squeak running on Android, in whatever
fashion. I am trying but its... hard to merge build systems etc.
- Really want Squeak to "move on".

We shouldn't be too afraid of changing and fixing stuff! I really like
the latest Set/Dictionary improvements - for the simple fact that
somebody actually DARES to touch that stuff again. More, more!

If we could also get say... some really slick concurrency mechanisms
(Promises? Asynch messages?) either into a really good library and/or
into the language - I really think we should stop being so afraid of
modifying the language and its core. That is my incoherent point really.

Regarding Pharo etc, IMHO it's "just a fork". And forks are good.
Really. :) As long as we don't build fences between them (mentally or
technically).

regards, Göran

PS. I really love all the exciting stuff on vm-dev (threaded VM, Cog,
event based VM etc).

Jecel Assumpcao Jr wrote:
Well, the part I didn't get was: "This image would support multiple
simultaneous viewpoints such that if you have a pointer to an object and
I have a pointer to the same object we might get different results when
sending the exact same message." How does this help sharing persistent
objects?

By changing the language semantics I meant what you say about sending
the same message to the same object and getting different results...
Doesn't that change language semantics?

>>> [16 thousand SiliconSqueak cores]
>>>      
>> Wow! Experimenting with such a system would be fantastic!
>>    
>
> There are a few steps before we get there. I'll keep the community
> informed of any progress we make.
>
> -- Jece

Thanks!

Cheers,
Juan Vuletich

Hi Andreas,  Hi All,

On 2009-11-16 21:22, Eliot Miranda wrote:

Hi Andreas,  Hi All,

    here's an interesting rant: http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html from one Jeff Bone.  I think he's wrong on implementation and right on general direction.  He wants current stuff (web, files, regular expressions) to be easy, but (IMO) he's wrong to think that the only way to get there is to put in direct linguistic support.  Why this rant might be relevant to our discussion is that it shows what some current programmers look for in a system and that if one can do what he wants one has a better chance of competing to grow the community, and growing the community can help in reaching other goals.

Anyway, 2¢, grist to the mill, etc.

+1000

Rant of the year!

Karl

Göran Krampe wrote:
> Gotta chime in somewhere here and since Jecel mentioned DS... :)

It wouldn't make sense to make plans for the future while ignoring stuff
that is being developed.

> Jecel Assumpcao Jr wrote:
> > I want it to be easy and elegant to create and share persistent objects
> > using Squeak.
> >
> > Solutions like Monticello+package universes/squeakmap are a bit too
> > complicated for me and yet don't do some things that I want.
>
> I don't associate those tools much with "persistent objects", mostly
> (well, SM can do Projects so sure...) with source code.

True, as the other thread about SAR vs MC shows. Some people would love
a source-only Squeak but that is not the direction I want to go - I
don't want to have to write some method to get something like the old
"Play with me" windows, for example.

> > Deltastreams would improve that somewhat.
>
> Eventually and hopefully. Since Brest I haven't had any time at all to
> put on "private Squeaking" though. But it is still there on the back
> burner. :)

In this discussion we haven't specified dates, so I imagined a roadmap
of at least a few years.
 
> Otherwise I:
>
> - Really like what Andreas wrote. :)
> - Will hopefully work on web stuff using Seaside in near future "for pay".
> - Continue working on Gjallar and DeltaStreams.
> - Will work on improving the CouchDB client code.
> - Am highly interested in getting Squeak running on Android, in whatever
> fashion. I am trying but its... hard to merge build systems etc.
> - Really want Squeak to "move on".

Great plans!

> We shouldn't be too afraid of changing and fixing stuff! I really like
> the latest Set/Dictionary improvements - for the simple fact that
> somebody actually DARES to touch that stuff again. More, more!

It is also interesting to have discussions around the changes. You will
never make everybody happy, but it is good to listen to what they have
to say. In the end, though, I always like to point out that older
Squeaks will always be there and are a valid option for those who can't
deal with the current changes.

> If we could also get say... some really slick concurrency mechanisms
> (Promises? Asynch messages?) either into a really good library and/or
> into the language - I really think we should stop being so afraid of
> modifying the language and its core. That is my incoherent point really.

As I implied in my previous email, I am embedding remote message passing
into the send bytecode itself. I know many people hate that and will
quote famous papers showing how stupid it is to treat local and remote
messages the same. But I don't agree - to me what is stupid is to think
that local messages won't fail (why have an exceptions framework,
then?), won't timeout (how about an infinite loop in #drawOn:?) and so
on.

> Regarding Pharo etc, IMHO it's "just a fork". And forks are good.
> Really. :) As long as we don't build fences between them (mentally or
> technically).

Unfortunately it is a bit harder to exchange code between Squeak, Etoys,
Pharo and Cobalt using Monticello instead of changesets. Geeting stuff
from Cuis into the trunk seemed to happen easily enough, though since I
wasn't the one who did the work I can't be is this impression is
correct.

> PS. I really love all the exciting stuff on vm-dev (threaded VM, Cog,
> event based VM etc).

Yeah, it isn't easy to keep up.

-- Jecel