Modular Squeak

Paul Fernhout pdfernhout at kurtz-fernhout.com
Tue Sep 26 14:40:46 UTC 2000


Les Tyrrell wrote:
> > How can we get your approach integrated into mainline Squeak?
> 
> A better question would be how do we get mainline Squeak embedded into the modular approach.

OK!

> As I see it, the best route is to first of all identify all those folks who are doing
> similar things, and get them onboard. [snip]
  
OK. Anyone else care to chime in?

> Second, in terms of bringing Squeak into this world, at this time I think the best approach is
> to start from the very first release and work forwards.  

Much agreement. Might I suggest 1.13 or 1.16 as the last release
pre-Disney? Then we could incorporate a clear licensing apporach to
contributions (i.e. every specific contribution has a license granted by
a specific organization or person with reference to a paper document or
email granting permission -- and unlicensed contributions are flagged as
such so the end user knows the liability).

I tried to run 1.13 and 1.16 on my NT system a few months back but had a
problems looking at the sources.

> The reason I prefer this approach
> is because I believe it is much easier for a single person ( or small number of persons )
> to start when Squeak was small to tackle problems such as class initialization.
> [Snip] 

OK.

> However, before I could do that with my system I need to have some form of source code
> management in place.  

At the NYSTUG meeting I attended last Thursday, there was a serious
mention that IBM was sunsetting ENVY (I wasn't sure if this was just for
VisualWorks or for VisualAge too). This would seem to open the field
some for Smalltalk source code control. And Cincom was promoting StORE
as the replacement. Anyone who can comment further on this and the
timetable?

> It is sufficient if it works for a single user, with the chance
> to grow into a system that could act a software component server.  

OK.

> To be useful, such
> a system ought to have many of the properties described for Collage, which appears to
> have many properties in common with the Personal Information Environment as described
> by Goldstein and Bobrow, "A Layered Approach to Software Design", which can be found
> in the book "Interactive Programming Environments", McGraw-Hill 1984
> ( ISBN 0-07-003885-6 ).  It's possible that there is an extreme overhead penalty for
> trying something like this, but I'd like to have a go at it to see.  I'll know more
> when I get there.  If someone has a better idea, let's hear it.

Any web references? I looked around some in Google but didn't find a
good page on this yet.

> A specific reccomendation would be to take your Pointrel system and see what is needed
> to support PIE or something very like PIE.  

Sounds like fun! Can you sketch out the core idea of what you need in a
paragraph or so?

> It looks like your code could do that.

The Pointrel Data Repository system is intended to be a flexible
solution (at a cost in other tradeoffs). It could do almost anything in
terms of representing a population of information which evolves over
time. Whether other solutions would be better or faster once an exact
solution was crystalized would be an issue down the road. (This is
related to the "overhead" you mentioned earlier.)

Actually, in my musings on a fork of Squeak for business use, I had
considered using the Pointrel approach instead of a change log.

> Could you do something where you devour all of the change logs from all the versions
> of Squeak and put them into a PIE-like Pointrel repository?  

Given that I don't understand all the requirements for PIE, I'd still
tend to say yes. 

Basically, I would just take each section of change log code and create
a string for it. Then parsing code could operate over that string and
create a set of more specific relationships defining timestamp, user,
class, and so on. Then those could be structured into some larger
hierarchy or web supporting multiple versions. 

The Pointrel approach allows one to endlessly annotate these strings and
relationships as needed (by creating new relations as needed). I already
do something like this to produce nested hierarchical versions of files
(more general than ENVY).

My biggest problem might be only having a few gig free HD space at the
moment.

> I've got code for parsing
> all of Squeak's change logs that will work in VisualWorks if you should need it, as well
> as all of the change and source files.

Does it run under Squeak? My VisualWorks system is still at 2.5.1+Envy,
is that good enough? I don't have the latest Squeak version of the
Pointrel software under VisualWorks, although don't think it would be
too much to port the core.

> I know you have some concerns about dealing with the forked version problem- my approach
> to that would be to build the tools that make dealing with that sort of thing trivial.
> I think there are solutions, possibly pre-existing.

Well, that at least is hopeful.

My major concern isn't forking Squeak so much as it is forking the
community.

A deeper issue is: can we determine a way that Squeak can evolve using
your sort of tool without the need for changes "blessed" by a central
organization? Or alternatively, can we have a distributed blessing
approach whether specific versions of things are more blessed as they
are more tested and used?
 
> Onward and upward,
> 
> - les

Sounds great. I suggest we keep as much of this discussion process on
the list as is prudent (or until people complain) to keep other
Squeakers informed and give them a chance to participate. Maybe we need
a subject line tag like [MOD] or [OASIS] or [REFACTOR].

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com





More information about the Squeak-dev mailing list