[squeak-dev] Object >> future
nicolas.cellier.aka.nice at gmail.com
Wed Mar 10 20:32:41 UTC 2010
2010/3/10 keith <keith_hodges at yahoo.co.uk>:
> Why do you feel that you are entitled to have me make this available in
> whichever image you've decided to use? I have not heard users of Cuis,
> Pharo, or Cobalt ask for this functionality. Why should I spend my limited
> spare time creating and maintaining loadable packages for these?
> Because if you had thought about the problem first, in the light of the fact
> that we are living in a multi-fork world, then your innovation could have
> been designed to be potentially loadable in all forks from the start, and
> derived images (with tool support to help you with building and testing it
> in all targets) , and you could have used 3.10.2 as one example use case of
> the integration of that innovation, for others to copy.
This is absurd. We can not develop trunk patches in 3.10.2.
If it would be true, that would mean that you can take all the
"patches" applied from 3.10.2 up to latest trunk and reload them in
I really want you to try before speaking.
I wonder what other squeakers think about closures/faster sets/new
trailers/SmalltalkImage etc... :
- shall we revert them and wait for a better engineered universal
loading procedure ?
- or are we happy with a better than nothing trunk-only version ?
In fact, these are not even trunk-only, because Juan, you and pharoers
can take a part of the burden and port important things to fork.
I don't say that the statu quo is ideal, nor that we should not
improve inter-fork exchange, but Keith, not this model please !
> This is what us package developers have been doing for years. If I can do it
> for Rio, and Logging, you can do it for your stuff too.
> The crime is that the process you are using, "trunk" causes you by default
> to think and act as if you are in a one fork moving target world, and to
> think in a "I will just throw this in for good measure" manner.
> The end result being that your efforts integrating it into trunk will
> inevitably have to be repeated by others. However those others do not have
> your knowledge and will all have to reverse engineer everything you did and
> guess at all of your design decisions and the fixes you had to add to trunk
> to accommodate.
> This means that the net result for the community is that you, in your
> attempt to provide a simple new feature just for your own pleasure, have
> actually generated work for other people, and this is what i think can be
> improved. What is needed is some form of knowledge capture on the way.
> I am not saying you have to package it as loadable for everyone, but it
> would be helped by a process which identifies your work as a discrete
> separate lump, rather than mixing it in with everything else.
> If you had simply developed it for 3.10.2 rather than trunk, that would have
> done the trick.
> In the "grow" scheme I have 4 or 5 kernel innovations on the go. But they
> are all being developed relative to the base-dev image. This keeps things
> uncluttered. If these innovations interfere unduely with one another then
> this is a clue that I need to improve their modularity.
> It is then trivial to generate a build with all 5 innovations loaded, even
> though it may not work immediately.
> If one of the five innovations loads in cuis-base-dev, then the knowledge I
> need to make that happen is captured in the fixes that go into the
> cuis-base-dev package. When I load it into pharo, I port just that
> knowledge, into the pharo-base-dev package. As the base-dev images get more
> api commonality. Then when it comes to porting the other 4 innovations, to
> the other forks it gets easier.
More information about the Squeak-dev