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:

...

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

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

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:

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

Andreas Raab wrote:

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

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

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

Andreas Raab wrote:

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

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

Good to hear from you Eliot, thanks for your long and considered email.

For me this raises the need to step back from the conversation about the development process and talk about the artifacts the community produces and who the consumers of those artifacts are.

Consumers can fall into some broad categories

• experienced squeakers who want to have at the system in all its

glory and program as the system was intended to permit programming

• new aspiring experienced squeakers who want to use the system in the

same way

• educators who wish to use the system to teach
• students who wish to be taught programming in the context of squeak
• people who want to run some application developed in squeak without

delving into the system other than superficially

• commercial entities through to hobbyists who want to deploy

applications they're written in squeak for profit or not There are probably other meaningful categories, and some people occupy more tan one category concurrently. But you get my drift. Not everyone wants to wrestle with the full glory, but those that do are likely to contribute to the system's subsequent evolution, fix bugs, etc.

It makes sense to me that all but the first want to start with a known quantity, something that is identified, has people who will try and help with problems with it, something around which a community is focussed, something with a hoped-for future, something documented and perhaps even written about. In short a distro. If that distro isn't in some sense a "closed shop", if its anything like a fast-moving target then it'll satisfy only the experienced few, the gurus, who can roll up their sleeves and have at it.

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/Buil...

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