[squeak-dev] Re: [Pharo-project] Just a little point

---

Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail

Hi,

Bravo Benoit!

I concur.

Every Smalltalk or Smalltalk variant is Smalltalk! Let's make them all the best they can be.

I currently use: Susie Smalltalk, Smalltalk MT,  Dolphin, Squeak, Pharo, VisualWorks, VisualAge, Gemstone, GNU Smalltalk, Smalltalk/X.  I have products in Digitalk V286 for PC and Mac, VisualSmalltalk Enterprise. I'm working on my own variant of Smalltalk, ZokuTalk. I like other smaltalk's too, heck, there is a list here: http://www.Smalltalk.org/versions that's almost complete (new smalltalk's keep appearing).

Unlike Java or the Microsoft communities, Smalltalk is very much like the Unix, Linux, *BSD communities, it's diverse.

If you can't get along with others fine, no one will force you... but please let those of us who can get along with each other regardless of which Smalltalk we use get on with making them better. Thanks.

One aspect of human nature is to form groups with "rules" about who is in the group and who isn't. Benoit is right that we are all using Smalltalk and that is the larger context, the larger group to keep in mind even if you only use one Smalltalk.

You can also think of it another way, the larger group may be able to bring more resources to bear on problems to solve them quicker. Much like farming communities that assist each other to build barns. This year Billy Bob needs a new barn. Next year it's Mary Sue.

“Three helping one another will do as much as six working singly." - Spanish proverb. By extension, all Smalltalkers working to improve Smalltalk will accomplish more than any of us can in fragmented groups.

All the best,

Peter William Lount
Editor Smalltalk.org



Benoit St-Jean wrote:

Chers amis, désolé pour l'anglais mais comme je voulais que tous les principaux intéressés comprennent mon point de vue, j'ai choisi l'anglais!

Okay guys, let's put things in perspective here...

Pharo isn't at war with Squeak and vice-versa...  Just like any kid, it just wants to "live it's own life" and somehow, somewhat, slowly progress and become a little bit different from its parents, here namely Squeak.

If find it weird that 2 Smalltalk implementations/communities, so close to each other like Squeak and Pharo, go to great lengths at flaming each other...  Don't you find it weird that such discussions don't happen between VisualWorks and Dolphin, between VisualAge and GNU Smalltalk, etc ?

We're from the same family.  Okay, we're all a bit different different but, deep inside, we're so the same.

I'm a happy Smalltalker who's daily job involves VisualWorks, Dolphin and VisualAge.  In my spare time, I'm happy "squeaking" and "pharoing".  Can't we just respect each other's goals/ambitions/dreams and try to find some communality and try to stay "not too far from each other and benefit from each other" instead of starting a "cold war" that will only leave us isolated, both in our own camps ?  I'm puzzled!  What do I do if I like both?  Choose my camp or abandon them both ?

 

-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
Blog: lamneth.wordpress.com
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

> If find it weird that 2 Smalltalk implementations/communities, so
> close to each other like Squeak and Pharo, go to great lengths at
> flaming each other...

No they don't, it's just me.

Please don't tar the mostly polite squeak-dev with my brush.

I spent a lot of time working on stuff that pharo could use,
particularly because a lot of it was Stephane's idea in the first place,
going back to August 2006.

My two main points of contention are Monticello and SUnit but as you can
see there are others.

Monticello:  I put a LOT, read LOTS of effort into joining the 3+
Monticello forks into one, and assuring that it loads in to all forks of
squeak, as a strategic approach for the whole community to have common
tools everywhere.
Pharo has made that effort a waste of time, simply because they wont use
or contribute to the merged uber-Monticello.

SUnit: I put a second lot of effort into improving SUnit so that it
could support multiple forks of squeak simultaneously. I also wrote a
non Gui test runner for automated testing. SUnit is a public resource
and is maintained in a public repository. Pharo have needlessly forked
SUnit.

Several things that wind me up, one is wasted effort, and another is
duplicated effort, and the third is making plans to duplicate effort on
purpose.
> that will only leave us isolated, both in our own camps ?  I'm
> puzzled!  What do I do if I like both?  Choose my camp or abandon them
> both ?
If you like both, then please encourage them to make parts that could be
common common. For example I maintain ProcessSpecific for Logging, Pharo
has integrated ProcessSpecific but has made no attempt to pick or offer
feedback to version that was maintained. This is one of numerous example
of subsystems that could easily be mutually maintained.

There are many initiatives in the pharo camp, that could be developed
and deployed into both camps. I spent all that time on Monticello in
order to ensure that this could happen, but pharo only develops
initiatives for itself, therefore Pharo is effectively planning for
duplicated effort.

One more example, Pharo could come up with an initiative to fix the
sources/changes file mess. This would be very benefitcial to me. However
its no good if I cant load it into squeak where a lot of my code runs.
So at some point someone would have to duplicate the effort for Squeak.
All it would take is a little thought and planning.

When I took the initiative to write Rio as a replacement for
FileDirectory, I did it in such a way as anyone could benefit.
When I took the initiative to write Logging as a potential core feature
for Kernel/Server images I did it so that anyone could benefit.
When I wrote the TestReporter as a text based tool for testing I did it
so that anyone could benefit.
When I wrote Bob for automated image building and testing I have done it
so that it can build any image.
When I wrote  Sake for rake like functionality it loads into any image.
When I wrote Sake/Packges for managing packges dependencies I did it so
that any image can benefit.

I dont know what initiatives pharo has completed, but, and please do
correct me if I am wrong. I havent seen a single initiative from pharo
that has been developed and deployed so that everyone could benefit.

best regards

Keith

Sorry Keith, but I must say this:

The obvious reason Pharoers reject your contributions are not
contributions as such but your attitude as the contributor. And I'd do
the same, reject them, because they are dangerous. Because they bring
you and your attitude with them.

Please think that way a bit. For the sake of Squeak community and our
progress. And for the sake of your work at the end. Changing your
attitude will change the acceptance of your work too, be sure!

Best regards
Janko

Keith Hodges pravi:

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Keith Hodges wrote:
> Several things that wind me up, one is wasted effort, and another is
> duplicated effort, and the third is making plans to duplicate effort on
> purpose.

But it's not wasted/duplicated effort. Making code cross-dialect is not
free - it's extra work that's being deferred. The deferred work can be
until: later (after the new creation has solidified), or never (because
the creation was not useful).

It can also be deferred for someone else to do. For example, newcomers
wanting to get a foothold could benefit from doing a "porting" task.
This ecosystem would free up inventors to invent new stuff, and provide
useful learning experiences for newcomers - to everyone's benefit.

Thinking about cross-dialect issues can stifle invention. I'd rather see
the invention happen. Maybe there is some wasted effort in the process,
but that concern would be mitigated if the new invention brought more
people to the community.

--
Yanni

Yanni Chiu wrote:
> Keith Hodges wrote:
>> Several things that wind me up, one is wasted effort, and another is
>> duplicated effort, and the third is making plans to duplicate effort on
>> purpose.
>
> But it's not wasted/duplicated effort. Making code cross-dialect is
> not free - it's extra work that's being deferred. The deferred work
> can be until: later (after the new creation has solidified), or never
> (because the creation was not useful).
I spend a fair bit of time extending SUnit with various features.

Measures
    - does a test use the net or not
    - how long does the test take

Categories
    - categorise tests on timings
    - categorise tests on use of network or not
    - categorise tests on platform, image, or vm

Suite Building
    - tidier code
    - Build suites using method prefixes test*
    - Build suites using category names (to support SSpec conventions)

Test Running
    - Select/reject tests based upon categorisation
    - Non-gui based test runner

It was so long ago that I cant remember what else.

So today I am browsing a few blogs, and I find...
> I submitted a simple extension of the SUnit Test Runner to the Pharo
> Inbox. It accurately determines the test coverage of a selected
> package. For the latest versions of Magritte and Pier I get the
> following results:
>
> Posted by Lukas Renggli at 30 March 2009, 8:57 pm
I thought, thats nice, I would like to use that... but I cant.

Why? Is there any thing that I can do more to enable this situation not
to occur.

The first I thought was obvious, was to put the SUnit package into a
public repository where improvements could be contributed and tested as
a shared endeavor.

Some people however, have no attitude of share and share alike.

This attitude is a philosophical choice which precedes any technical issues.

Why should I put effort into improving something for others, if others
are going to improve the same thing in a way that I cannot use, when
there is no technical reason for it.
> It can also be deferred for someone else to do.
I wrote the improvements I made to SUnit in 2006, how much more deferred
do you want?
>
> Thinking about cross-dialect issues can stifle invention. I'd rather
> see the invention happen.
Innovation is overrated if it isnt valued. If you dont value the
contribution of others, then those other might eventually learn not to
bother contributing.

After 4 years active in the squeak community, I am seriously considering
whether this was time well spent.
> Maybe there is some wasted effort in the process, but that concern
> would be mitigated if the new invention brought more people to the
> community.
(wondering where Tim is now)

Keith

Keith Hodges wrote:
> So today I am browsing a few blogs, and I find...
>> I submitted a simple extension of the SUnit Test Runner to the Pharo
>> Inbox. It accurately determines the test coverage of a selected
>> package. For the latest versions of Magritte and Pier I get the
>> following results:
>>
>> Posted by Lukas Renggli at 30 March 2009, 8:57 pm
> I thought, thats nice, I would like to use that... but I cant.

And why can't you use it? Open Monticello, point it at
http://squeaksource.com/Pharo merge it, done. I just did exactly that
and if you now update your image from http://source.squeak.org/trunk you
can use these extensions, too.

I'm not sure how to say that gently, perhaps there is no way. But
whining isn't going to help. There will always be people who write code
for whatever reason. It's called competition. Monticello and other tools
help us make it easy to synchronize between the different developments.
I just did that (in less than 20 minutes) and suddenly Pharo and Squeak
are in sync as far as SUnit and TestRunner are concerned. How's that for
some progress?

Cheers,
   - Andreas

Cool! I already updated my image and ran the tests with the new SUnit  
TestRunner. It's a shame though we are one failure away from green -  
at least on my Mac!

Is it the same bug this thread was about?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129372.html

I did not find anything in Mantis.

Cheers,
Bernhard

Am 10.07.2009 um 00:09 schrieb Andreas Raab:

Running the coverage hangs my image, though, after about 40% of all  
tests.

Cheers,
Bernhard

Am 10.07.2009 um 00:51 schrieb Bernhard Pieber:

Andreas Raab wrote: This was only an example,

I was answering a specific point, the point that had been made was that
apparently innovation happens first, and integration will inevitably
happen at a later time.

If the community is setting a course for multiple forks, then it becomes
inevitably more difficult for one person to even carry out this
integration even if they wanted to.

This counter example, code languishing in the Testing repository since
2006 had failed to be integrated, even though it has been loadable from
Universes for most of that time, and was positioned as the new head for
everyone to work from. If people were to use it as the new head then
there wouldn't be any integration needed at all.

If you take a closer look at the differences between Testing/SUnit and
Pharo you may find that I implemented ClassClonerTestResource to assist
in testing the class side of classes, and I think that someone in Pharo
duplicated the very same work. So it is not as easy as you say if the
two branches have both seen refactorings

My point is that by putting the philosophy first, that is what leads you
to have tools like MC for interchanging code in the first place, and it
is what led me to spend time working on MC1.5. SUnit falls in to the
same category of tools that essentially have to be common across forks.

But if no one else adopts even a similar philosophy what's the point.

I still believe that if we the squeak community, profess to value
people's contributions, encourage the use of shared externally managed
projects, we can leave Pharo in the dust.

However following your "progress" now we have 3 branches of SUnit,
whereas before Pharo, there was only one, are we going backwards here or
what?

Keith

At 3:09 PM -0700 7/9/09, Andreas Raab apparently wrote:
And now if you updated Squeak Source SUnit repository to match everything, we may have some progress.
Otherwise it appears to me you have just created a third version the Squeak community needs to keep up to date.

Ken G. Brown

Keith Hodges wrote:
> This counter example, code languishing in the Testing repository since
> 2006 had failed to be integrated, even though it has been loadable from
> Universes for most of that time, and was positioned as the new head for
> everyone to work from. If people were to use it as the new head then
> there wouldn't be any integration needed at all.

That's a strange sense of entitlement you have here. Why do you think
anyone would heed your "positioning as the new head for everyone to work
from"? This is but one of the many versions of SUnit and I'm not sure
what would make it so special. In fact, given that it's not used in
*any* fork today it seems especially peculiar that you seem to be
claiming it to be base of development for *all* of them.

> My point is that by putting the philosophy first, that is what leads you
> to have tools like MC for interchanging code in the first place, and it
> is what led me to spend time working on MC1.5. SUnit falls in to the
> same category of tools that essentially have to be common across forks.
>
> But if no one else adopts even a similar philosophy what's the point.

I'm not sure what your philosophy is. If it is "let's make sure we use
the same SUnit version across different forks" then you should rejoice:
As of today, Squeak uses the same SUnit and SUnitGUI as Pharo! We just
reduced the burden of integration for anyone who has dependencies on
either of the two.

Cheers,
   - Andreas

Keith Hodges wrote:
>> This counter example, code languishing in the Testing repository since
>> 2006 had failed to be integrated, even though it has been loadable from
>> Universes for most of that time, and was positioned as the new head for
>> everyone to work from. If people were to use it as the new head then
>> there wouldn't be any integration needed at all.
>
> That's a strange sense of entitlement you have here. Why do you think
> anyone would heed your "positioning as the new head for everyone to
> work from"?
1) Because it is the only one in a public repository where contributions
are invited, so by default it is the only one in the ownership of the
community.  If there was any other one, then I would have contributed to it.

2) It is the only one that has had significant work done on it in the
past 3 years, so it is therefore the only one that has moved forward,
and so by default it is the only head. If you pick the SUnit in 3.9 then
what you are picking is more of a shoulder or navel.

3) Because it is the only one that attempts to address the articulated
goals of the communities using SUnit. So really you need to rephrase the
question with the broader context in mind.
> This is but one of the many versions of SUnit and I'm not sure what
> would make it so special. In fact, given that it's not used in *any* fork
In this public form it post dates most recent developments except for pharo.
> today it seems especially peculiar that you seem to be claiming it to
> be base of development for *all* of them.
Precisely because it is the only one maintained as an external package,
makes it most likely to be the only one that is capable of fulfilling
the role.

Since a number of forks have the professed goal of automated testing,
then the TestReporter is only present in this version.
>> My point is that by putting the philosophy first, that is what leads you
>> to have tools like MC for interchanging code in the first place, and it
>> is what led me to spend time working on MC1.5. SUnit falls in to the
>> same category of tools that essentially have to be common across forks.
>>
>> But if no one else adopts even a similar philosophy what's the point.
> I'm not sure what your philosophy is.
To embrace the contributions of the community. To enable people to both
diversify and consolidate. Make it easy to fork (i.e. build an image to
your tastes) and easy to share fundamental common parts.
> If it is "let's make sure we use the same SUnit version across
> different forks" then you should rejoice: As of today, Squeak uses the
> same SUnit and SUnitGUI as Pharo!
Which is no use to me, since there is no TestReporter in that version.
> We just reduced the burden of integration for anyone who has
> dependencies on either of the two.
Ok some challenges for you.

1) now try and write a single test suite for both Pharo and Squeak that
reports all tests green for each image, even though there may be
significant differences.

2) I want to take an image and test it from the command line. The
outputs I want are a progress indicator, and files with failures and errors.

3) I want to run SSpec specifications in the same runner (not functional
yet, but much groundwork has been done).
etc etc.

This version is the only version that has been developeed with the
professed goals of Pharo and Squeak in mind. If you dont have those
goals then do what you like,  but we do have those goals (well we used to)

Keith

Hi Keith -

Let's cut this discussion short a little since I don't think either one
of us is going to convince the other. To summarize, my position is that
yes, you've done some interesting work with SUnit, but the reality is
that this doesn't entitle you to anything. If you want your code to be
used you've got to create trust into what you've done (i.e., have users)
and you've got to convince others to include it (i.e., work with the
distros). This goes for anything we do in open source but doubly so if
core packages are involved.

Cheers,
   - Andreas

Keith Hodges wrote:

Andreas Raab wrote: The distro's are effectively a closed shop.

That is the whole point of replacing the release process with something
that is distributed and allows many different images to be built.

Keith

Hi Keith,

Good to hear from you Eliot, thanks for your long and considered email. I agree with everything you have said.
> So I see a contradiction in, Keith, your promotion of an open
> development model and at the same time an assumption of greater
> community participation.  I suspect that for most new community
> participants the existence of a few well-differentiated and
> well-supported distros is a necessity.
This is how I expect it could work. If the "knowledge" (Sake/Packages)
that goes into making distro's is captured, and is published and is part
of automated builds (Bob-Releases). Then the "stable known quantity" can
be updated and the distro's regenerated on top of a prospective new
version of the core. Thus the core can actually be moved forward with
the use-cases (the distro's) in mind, since the core can be
automatically tested against the distro's. If a core change breaks a
distro, then patches to the distro can be added to the "knowledge".

Thus the core may move forward, and it may even take on board radical
changes, but it will not be able to move as fast as if it were the only
entity, and compatibility is not being considered (i.e. the Pharo approach).

Also anyone can try a new core innovation, and test against the
distro's, with the build system we are not restricted to building
distro's on top of a single core.
> So what would make sense to me is a development model which tries to
> gather maintennance contributions from those that are capable of and
> happy to fix problems with the system and harvest them to make stable
> distros, a clearing house that verifies or rejects potential bug
> fixes, filters potential candidates for inclusion, so that the
> maintainers of distros have an easier job in moving their
> slower-moving targets forward.
That is the current plan...

If we start with 3.10.2 then we have a batch of tested and approved
fixes that apply to the current release. The derived image (distro) with
all of these loaded is called 3.10.2-fixes.  At some point a maintenance
release of the most essential of these will be incorporated into 3.10.3.

The next release 3.11 is built upon 3.10-fixes + tasks which apply the
design of 3.11.
And next unstable release 3.11 is built upon 3.10-fixes + unstable fixes
+ tasks which apply the design of 3.11.
> I want to say more about the kinds of artifacts the community might
> produce but the weekend is advancing and I'm about to dive into the
> bosom of my family for the weekend and leave the internet behind.  So
> this is too brief.  But I think people want to provide functionality
> in different forms.
>
> One important form is the cross-dialect package, such as Seaside,
> which is a core package plus compatibility code to adapt it to various
> Smalltalks, not just various Squeak dialects.
Sake/Packages provides slots for tweaking the load (i.e. adding a
dependency upon a particular bug fix/package) for the different squeak
dialects, however supporting different smalltalks is a little bit more
tricky, however Sake/Packages purposely has fairly minimal dependencies,
so if you there is going to be any viable cross dialect package
management solution Sake/Packages could be a front runner.
> One form, of necessity, is the package imprisoned in an image, such as
> eToys and QwaqForums where on the one hand the lack of modularity
> means that its too difficult to extract a package and on the other
> hand where the necessities of making radical changes to move the
> artifact forward result in a fork.
This is where, for the purpose of applying fixes/patches at an
integration level, we treat the image as a whole, simply saving the
packages afterwards. The current technology for doing this is
changesets, but one hopes that deltastreams will be better.

You could even load every package that will load, apply a
patch/refactoring to the whole caboodle, and then save all the packages.
(e.g. _ to :=) External maintainers would then be able to merge in the
result to their externally maintained branch-head.

> Other forms are kitchen-sink images appealing to power developers,
Squeak dev can now be built with

Packages load: 'Squeak-dev image'.
> various forms of cut-down images attempting to get to a kernel as a
> suitable starting point for modular composition, and so on.
Sake/Packages supports unloading of packages. So as long as the package
is correctly defined and unloads, there is no real need to unload it in
core. However some may wish to make a distro which does unload
everything that can be unloaded.

We called this the -minimum distro.

As long as no one unloads the ability to run scripts from the command
line. Bob can run arbitrary scripts on an image, and then save the
result. Distro's dont have to be created with Sake/Packages. However
Sake/Packages is also designed to be easily unloadable, all of its data
is in code, so you just have to delete the class category, it shouldn't
leave unwanted artefacts behind.
> All of these would benefit from a more modular system, especially one
> that had a small bootstrappable kernel that would allow the execution
> technology to move forward without breaking them, and without having
> to repeat bootstraps in place (yes I have a perspective here, porting
> closures to numerous images is not my idea of fun).
It would have been nice for the pharo crew to capture their what they
learned while they were "boldy going....".
One would also hope that atomic loading could help here.

Is there anything else you can think of that would make it easier?
> So again I see issues with your development model.  I think it is
> well-suited to the maintennance task,
Thank you.
> and important in getting to the small kernel that we want.
Even better, since these have been the professed goals of the squeak
community for several years.

Some appear to be forgetting is that as far as the board were concerned,
3.10 was essentially the end of the line. I encouraged/harassed them to
continue 3.10 as essentially an ongoing maintenance release in which
those of us using current stuff could continue to consolidate and
improve our lot. i.e. I don't expect to see major innovations in the 3.x
line, above and beyond the obvious improvements we would like, some of
those (i.e. closures) are radical enough for now.
> But it needs to dove-tail with a package-based model
Definitely, this is the role that Sake/Packages is intended to fulfil,
and I would go so far as to say without a working package mechanism for
loading things back in reliably, it's best not to take things out. 3.10
tried using Universes, but I regard that as a failed experiment.

Some of those clamouring for a new release are so keen to have a new
image at any costs, they are not realsing that this new development
process depends more upon a working Packages infrastructure, and that is
one thing that we do now have which we didnt have a year ago.

If you look at how Damien produces the dev image...

http://damiencassou.seasidehosting.st/seaside/pier/Smalltalk/squeak-dev/Building

The fundamental line is...

Installer sake install: 'Squeak-dev image'.

And that is it - that is the only line that you have to give to Bob, to
build developer images, apart from telling him the starting image, and
the period.
> because that's the model that gives most power to the community going
> forward in that it results in packages that can be deployed in
> different contexts and maintained to some extent independently of a
> specific substrate, and is the one that allows the community to evolve
> at its maximum rate.  (It is still extraordinary the Squeak has had
> the same slow VM technology for 14 years).
Totally agree.
>
> Anyway, my 2¢.
>
> Summary, can we not merge, or if not, marry, your auto-integration
> testing framework with a package-based approach
Yes by sitting down and carefully carving up the image into packages
that are stand alone and have limited dependencies, so that a module is
genuinely a package in its own right. This is the primary difference
between 3.10 and 3.11 as planned.

> the weekend beckons..
>
enjoy

Keith