Roadmap proposal for 3.10/4.0

Hi all

I have been thinking about the next steps. Here are a list of  
propositions for 3.10/4.0 that I would like
to work on and welcome company. Ideally I would like to build a group  
of people that have fun to work on these items.
We could even try to have some regular chats one day a week and FUN.

I think that Squeak 10/4 should not be compatible to free us but at  
the same time it should prepare the
coming of new assets (sophie/tweak).

Here are the main actions I would like to see happening:

        - be able to load Tweak

        - be able to load Sophie infrastructural elements (ressource  
location...)
        => even substitute current Squeak ones with sophie ones (Rome renderer)

        - curve/remove Etoy/projects (without having to reload them)

        - remove nebraska and others/ remove packages early in the process

        - new compile method format if available else klaus fix for source  
limits

        - may be newcompiler if ready

        - aggressive cleans in a lot of areas

        - look at Pavel overrides problems
        => ideally be able to use Pavel image as a basis for 10/4

        - Use tool builder (looking at the tool plus) and change the current  
tools
        (the ones that deserve migration)

        - more tests

        - may be using MC2 if ready

        - better integration of AST and refactoring support

So if you want to help there on a regular basis or on specific items  
please say it

Stef



       

Stéphane Ducasse puso en su mail :

Of the long list, I have deep wish to help in:

> - curve/remove Etoy/projects (without having to reload them)
>  - remove nebraska and others/ remove packages early in the process
> look at Pavel overrides problems
>   => ideally be able to use Pavel image as a basis for 10/4

So, if you think I could do something useful ....


Edgar



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

On Sun, 15 Oct 2006 10:40:42 +0200, Stéphane Ducasse wrote:
> Hi all
>
> I have been thinking about the next steps. Here are a list of  
> propositions for 3.10/4.0 that I would like
> to work on and welcome company. Ideally I would like to build a group of  
> people that have fun to work on these items.
...
> - new compile method format if available else klaus fix for source  
> limits

Tim, what are your plans with my "inspiration" on source files' limits.

>
> - may be newcompiler if ready

I'm contributing to decompiler as much as I can. But the way I understand  
Squeak community is, the new compiler will *not* make it into mainstream.  
So it can only be distributed as an optional package, and besides the  
package owner's own priorities IMO there is no 3.10/4.0 deadline for the  
new compiler.

> - look at Pavel overrides problems
> => ideally be able to use Pavel image as a basis for 10/4

After all the mistakes from the past, *not* accepting Pavel's overrides  
will only split the community further.

> So if you want to help there on a regular basis or on specific items  
> please say it

As said above, I'm working on the new decompiler.

/Klaus

> Stef
>

I don't know what other people think, but these long feature lists just
give me the shivers. What if instead of listing feature X, Y, and Z (on
many of which the implementation hasn't even started) we simply have a
schedule that says:

a) Open discussion: Two months of determining what's ready to go into
the next release. At the end of the that period there should be a list
of things that we'd like to have in the next release.

b) Alpha phase: Two months of "getting stuff in" for those things that
we agreed upon in the first phase. At the end of this phase, any new
feature that isn't in yet, won't get in.

c) Beta phase: Two months of testing, fixing bugs updating the docs and
packages at Squeakmap. At the end of which we have a new release.

Six months, and it should be done. With clear deadlines what is expected
to happen when. With proposals made by the people who have done the work
already. With work that is already finished and only needs inclusion
instead of stuff on which work hasn't even begun yet.

Cheers,
   - Andreas

Great idea.  We also need some kind of list (on a website) that shows what
things are out there that need work, so people looking for something to do
know where to look.  I know the bug reports provide this a little, but I
really see a bug list as something different then a "needed features" list.

Andreas Raab wrote:   +1

Isn't the list that Stef is starting the same list you propose be
produced after the first two months?

Don't get me wrong, a plan is a good thing to have I'm just trying to
understand how you wont end up with a big list that will give you the
shivers... :o)

Z.

Andreas Raab wrote:
> I don't know what other people think, but these long feature lists just
> give me the shivers. What if instead of listing feature X, Y, and Z (on
> many of which the implementation hasn't even started) we simply have a
> schedule that says:
>
> a) Open discussion: Two months of determining what's ready to go into
> the next release. At the end of the that period there should be a list
> of things that we'd like to have in the next release.

Zulq Alam wrote:
> Isn't the list that Stef is starting the same list you propose be
> produced after the first two months?

It could end up being similar, but the main difference is that I'm not
willing to consider anything that hasn't been done already. Out of that
list there were two items that I would consider "ready for inclusion"
(which really means: ready for discussion), namely Klaus' fix for the
source code management and some of the fixes that Pavel needs. None of
the other items on the list are even close to being considered ready for
inclusion; on many of the items work hasn't even started.

And *if* any items on that list get done in the first two months we can
decide to include them. But I don't want to start out with a long list
of features that nobody has the time and the energy to implement.

> Don't get me wrong, a plan is a good thing to have I'm just trying to
> understand how you wont end up with a big list that will give you the
> shivers... :o)

Simple: By strictly not doing anything "new" but rather only pick from
what's already there. The release process isn't the place to start new
projects, it's the place to select from the existing projects those that
should be part of the next release.

Cheers,
   - Andreas

Maybe high on the list are tests (maybe even an automatic test procedure
mentioned on this list) and (more important) fix current defects.

Stéphane Ducasse wrote:

Could we please just have a minimal image for v4.0? The current Squeak
images are huge and have lots of stuff I don't want.

I want an image that doesn't have Morphic but just a command line, like
Pavel's kernel image. Everything else should be a separately maintained
project that you can load in - if you want it.

For ease of use, you can also release developer's images with
combinations of packages, but I don't believe that these should be the
official "Squeak 3.10" image.

Stéphane Ducasse wrote:
I'm assuming this is just an option, and won't mean ugly things like
Object>>loadTweak.

Perhaps it is better to include these projects in the release that
happens *after* they are ready.

>     - aggressive cleans in a lot of areas

Yes please!

Please make this a loadable option.

Michael.

On Mon, 16 Oct 2006 10:59:00 +0200, Michael van der Gulik wrote:

...
>
> I want an image that doesn't have Morphic but just a command line, like  
> Pavel's kernel image. Everything else should be a separately maintained  
> project that you can load in - if you want it.
>

+ (1 big)

/Klaus

+1

I think it would be good to have a more formal process.  It would be nice if
we could have a single place to go to see what is going on, who is working
on what and if there is any progress.  I like the idea of organizing around
current contributions and providing a structure so that everyone can
understand the process of harvesting changes for adoption in the main image.


It would also, as Andreas suggested, be a good idea to voice support for
activities in process, so that those efforts can be encouraged and supported
by anyone with spare time before adoption is considered.  

Beyond that each team gains momentum and organization in its own way and it
seems to me that persuading the community in any direction is very
difficult.  I have seen really cool stuff evolve by itself.  

So my suggestion is push for organization but accept the chaos that is
Squeak.

Ron Teitelbaum

sounds good idea. Why not in fact.

Stef

On 15 oct. 06, at 21:04, Andreas Raab wrote:

Greetings,

I'd like to raise the idea of changing the complex number code in 3.10/4.0.

See change set at:
        http://bugs.impara.de/view.php?id=3311


Current (3.8/3.9):
  2i isNumber. "false"
  -4 ln. "NaN"
  -4 sqrt. "exception"

 Alternate Code:
  2i isNumber. "true"
  -4 ln. "(1.38629436111989 +3.141592653589793i)"
  -4 sqrt. "2.0i"


I consider this a "community issue".

Questions:
  - Are there users of complex numbers (does anyone care)?
  - Assuming yes, are there objective criteria for choosing between alternate
implementations?
   + behavior/completeness/test-cases
   + performance (I suspect that "the wrong answer fast" is not the Smalltalk
way as we can always augment the primOps)
   + complex number user community vote
   + other...?

I am actually agnostic as to which code base gets chosen, but we really should
get the answers right.

$0.02
-KenD

I disagree on that one. I think that we can have a vision and create  
a group that works on that vision.
I do not see a problem even if people want to do something and fail.  
This does not mean that we
should not reasonable goals.

Removing Etoy for example, (even if pavel already did it is  
something) that could and should be done.

Yes we should do that.

> Great idea.  We also need some kind of list (on a website) that  
> shows what things are out there that need work, so people looking  
> for something to do know where to look.  I know the bug reports  
> provide this a little, but I really see a bug list as something  
> different then a "needed features" list.

I like the idea of nicolas to remove it and that someone take care of  
it as a package.

Stef

On 17 oct. 06, at 03:45, Ken Dickey wrote:

Am 17.10.2006 um 03:45 schrieb Ken Dickey:

Well, in best Smalltalk tradition I would vote for the alternate  
code. It's similar to fractional arithmetic ( 3 / 4 ). Yes, fractions  
bite some newbies, but they learn to use #// or #asFloat fast enough.  
Same here - if you need an error when taking a negative's square  
root, send #asFloat.

It's also a bit similar to Smalltalk being one of the few systems  
with correct integers, where a bug like this is not possible:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about- 
it-nearly.html

I'd like to have no arbitrary limits, like forbidding to take the  
logarithm of negative numbers.

- Bert -

"Ron Teitelbaum" <[hidden email]> writes:
> +1
>
> I think it would be good to have a more formal process.  It would be nice if
> we could have a single place to go to see what is going on, who is working
> on what and if there is any progress.  I like the idea of organizing around
> current contributions and providing a structure so that everyone can
> understand the process of harvesting changes for adoption in the main image.

Me three.  In my mind, working out a good process is the most
important thing that the Squeak community needs.  I argued so back
when the Castaways bullied in and tried to fix our community against
our will [1], and in most ways we are in about the same position now
as then.

The one good process change I see is that we can elect board members
now.  That's an excellent and crucial step forward.

The next big thing to focus on, IMHO, is managing changes to the
shared image.  Part of that is surely to develop an idea of
membership.  Using computer-generated popularity rankings is a poor
way to go. [2,3]

For big changes to the shared image, Andreas's notes earlier in the
thread sound terrific to me.

For small changes, we still seem to be operating in a vacuum.  I am
unmotivated to fix bugs in core Squeak and in the Unix port, because
in both cases the fixes are often ignored.  SharedQueue, one of our
fundamental synchronization constructs, has been broken for over a
year now, despite a fix being available [4].  Should I ever again blow
away a Saturday like that?  Nobody likes being a sucker who fights
harder for something than its own management.

So here's a challenge for you, board: how do we get fixes processed?
All the really cool Squeak stuff happens at the periphery [3].  The
question for the board is thus: how do we handle the simple, prosaic
patches?

-Lex



[1] When I reread this old thread:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088316.html

I again wonder how things would have gone if the "Squeak Foundation
Formation" group had continued its work, instead of being de facto
shut down by the Castaways.


[2] "[Elections] reputation systems for membership"
http://lists.squeakfoundation.org/pipermail/elections/2005-December/000010.html


[3] "Squeak as Commons", my first sketch for a community organization:
http://people.squeakfoundation.org/article/44.html


[4] http://forums.squeakland.org/view.php?id=1375

Ken Dickey wrote:

> Current (3.8/3.9):
>   2i isNumber. "false"
>   -4 ln. "NaN"
>   -4 sqrt. "exception"
>
>  Alternate Code:
>   2i isNumber. "true"
>   -4 ln. "(1.38629436111989 +3.141592653589793i)"
>   -4 sqrt. "2.0i"

> I consider this a "community issue".
>
> Questions:
>   - Are there users of complex numbers (does anyone care)?

Apparently, complex numbers are the most common class of numbers in the
universe.

>   - Assuming yes, are there objective criteria for choosing between alternate
> implementations?

Similarity to what math books talk about?

> I am actually agnostic as to which code base gets chosen, but we really should
> get the answers right.

Squeak appears to be a superlative platform for doing number theory and
other maths, I think things will only get better if complex types are
implemented across the board. =)


--
If you tell a linux advocate that you saw Bigfoot, he'd believe you.
If you tell him that you saw linux crash, he won't.