Stef's Squeak Grand Vision

Hi Hilaire

Here is my **personal** vision for the future:

Making Squeak a software platform (for web dev, education dev,  
dreaming....)

        - Small kernel (We should help Spoon)
        - Good package (may be MC2)
        - Good library (Stream, file, network)
        - Good set of tools
                - OB, Refactoring Engine, coverage browser, new code browser, shout,
                - ecompletion, new compiler,
        - Connection with the outer world (GTK, vwxWidgets)
        - removing broken stuff
        - Cleaning internal (Set, Dictionary....)

Possibly with clear OS license.

Doing that with good software engineering practices
        - Tests
        - Test Server
        - Building scripts

I will slowly work on that. Note that this is still the vision behind  
3.9.
If you are interested I can point to work to be done to arrive to  
that point.

Stef

Yes, yes, yes.

I'm working on a high level programming discipline for a stored program
object computer. (Java and ST code is really microcode - defining the
opertions of the stored program object computer) I hope to be in time for
the "next Morphic" to be clean, high level code from the bottom up. No
hidden, dirty details, buildt on a clean Squeak software platform.

All the best
--Trygve

At 10:12 08.07.2006, Stef wrote:

--

Trygve Reenskaug      mailto: [hidden email]
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

At least!

stéphane ducasse a écrit :
Which mean the mainstream VM will be patched so it is immediately
workable with such widgets, right?

>     - removing broken stuff
>     - Cleaning internal (Set, Dictionary....)
>
> Possibly with clear OS license.

Do you think we can afford to get this as only an option?
Should we not make clear in our roadmap we want to move *toward* a clean
 OS license? (hudge difference impact)


>
> Doing that with good software engineering practices
>     - Tests
>     - Test Server
>     - Building scripts
>
> I will slowly work on that. Note that this is still the vision behind  3.9.
> If you are interested I can point to work to be done to arrive to  that
> point.

Let's take a few more time to discuss on that.


Hilaire

I do not know. VM are not my areas.
The problem with the VM is that some new people should invest there
to avoid some bottlenecks in the future. :)

>>     - removing broken stuff
>>     - Cleaning internal (Set, Dictionary....)
>>
>> Possibly with clear OS license.
>
> Do you think we can afford to get this as only an option?
> Should we not make clear in our roadmap we want to move *toward* a  
> clean
>  OS license? (hudge difference impact)

OK for me.

stéphane ducasse a écrit :
Both Bruno (gtk) and Rob (wxWidget) already provided the necessary patch...

I think from a visibility point of view it is important if the Wx or GTK
can be used directly from standard VM. Yes again politician point of view.

Hilaire

> Both Bruno (gtk) and Rob (wxWidget) already provided the necessary  
> patch...
>
> I think from a visibility point of view it is important if the Wx  
> or GTK
> can be used directly from standard VM. Yes again politician point  
> of view.

For which VM is it?
The linux and window ones?
May be you should post in the vm mailing-list.

Stef

stéphane ducasse a écrit :
Not yet there, we are just chatting now of the available option.
And do not forget whatever the decision, it depends on the commitment of
the respective SqueakGTK+ and SqueakWX developer to this road map.

Hilaire

On 7/8/06, Hilaire Fernandes <[hidden email]> wrote:
> > For which VM is it?
> > The linux and window ones?
> > May be you should post in the vm mailing-list.
>
> Not yet there, we are just chatting now of the available option.
> And do not forget whatever the decision, it depends on the commitment of
> the respective SqueakGTK+ and SqueakWX developer to this road map.
>

It's probably best if someone who knows a lot about the VM looks at
the GTK and Wx patches for the various platforms, and tries to come up
with a way to shove these patches into modules - maybe breaking out
some ugly event loop stuff from the common code into modules as well.

Now, I'm not qualified in either area (VM, GTK, Wx), and I am usually
hesitant to make suggestions on mailing lists I couldn't at least
theoretically execute myself :-), but in this case I think it's
important that whatever becomes the common code, it becomes as
agnostic as possible about things like the UI.

BTW - I smell another interesting student project here :-). Evaluating
event handling across the matrix of {SqueakUI, GTK, Wx} x {Unix,
Windows, Mac} and coming up with a plugin design that can handle them
all...

On Sat, 08 Jul 2006 10:12:48 +0200, stéphane ducasse  
<[hidden email]> wrote:

I always can't understand what these discussion mean, my English is not  
good enough for :)
However, i think Andreas Raab' callbacks-related patch are a really nice  
start point to avoid a VM for Gtk and Wx plugins. The Gtk plugin doesn't  
modify the internals of the VM, it's a simple external plugin.

New coming users shouldn't recompile the VM with the plugin, the plugin  
must be installed as a binary package into the plugins directory, so a  
generic installation script for these must exist.

Also i've seen on squeakvm.org that the Windows VM is not much developed,  
latest version is 3.7.1.
What about a 3.9 version with an updated toolchain for porting plugins on  
Windows?

--
www.lethalman.net - Thoughts about internet technologies

+1

stéphane ducasse wrote:
> Doing that with good software engineering practices
>     - Tests
>     - Test Server
>     - Building scripts
>

Does this include 'management' practices? Having a backlog of features,
force ranked in terms of priority, with estimates and people only
working on features slated for the current iteration, is a very good way
of breaking out of paralysis in commercial software development. Is
there anything analogous you can do in a community driven development?

Cheers

Daniel

On 7/8/06, Daniel Poon <[hidden email]> wrote:
> Is
> there anything analogous you can do in a community driven
> development?
>
<puts on his Scrum master hat...>

Certainly. Even though people usually just scratch their itches (which
makes it hard to predict which features will be built :-)), usually
one or more people sign up for, say, a release and they are usually
committed to do some grunt work, stick with what is agreed, etcetera -
just as in a regular project. The biggest difference is probably that
you don't know how much time people will be able to give.

I think the most important thing we're not doing is timeboxing.
Releases should be time-based, not feature-based. This keeps things
cooking so to say - regular releases will put some pressure on working
towards "we can release at any moment" systems: daily builds,
automated testing, etcetera. Releasing twice a year or even quarterly
also makes the feedback loop shorter (and thus better), so the
community can better steer the course of development. Finally, short
release sprints will make it easier for people to sign up and even
commit time - I can predict in advance how much time I can spend the
next quarter. I cannot predict in advance how much time I can spend
until, say, the original 3.9 feature list is complete. In fact, I
changed jobs in the meantime and I've switched from full-time Squeaker
to something very different :-).

I'd suggest a major release per year (so you can break backwards
compatibility once a year :-)), and a point release per quarter.

Cees De Groot wrote:
> Certainly. Even though people usually just scratch their itches (which
> makes it hard to predict which features will be built :-)), usually
> one or more people sign up for, say, a release and they are usually
> committed to do some grunt work, stick with what is agreed, etcetera -
> just as in a regular project. The biggest difference is probably that
> you don't know how much time people will be able to give.

Sure, you don't want people to not be able to 'play', at least in this
kind of community. If you defined the backlog of stories as being things
that would be fully integrated and potentially releasable, then at least
you would know where you stood with respects to how fast you are burning
stories that have been agreed to by the community.

The main difficulty is going to be maintaining a backlog where everybody
in the community is a stakeholder, and everybody in the community will
be estimating stories.

Can't fault your conclusion there.

Cheers

Daniel

On 7/8/06, Daniel Poon <[hidden email]> wrote:
> The main difficulty is going to be maintaining a backlog where everybody
> in the community is a stakeholder, and everybody in the community will
> be estimating stories.
>
I think that whoever signs up for a release, should be able to
prioritize the backlog. Without any intervention from the community,
rooted in the Roman dictator model: you say you're going to step in
and fix things, then if the community ok's that you get to be the boss
for that release. With quarterly releases, I can't think of anyone
having a problem with that :-)

I can't help thinking that today's Sluggy Freelance (http://
www.sluggy.com/images/comics/060708f.jpg) is relevant to the problem  
of vision, commitment, work and.... stuff.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DSO: Do Something or Other

Cees De Groot wrote:
> I think that whoever signs up for a release, should be able to
> prioritize the backlog. Without any intervention from the community,
> rooted in the Roman dictator model: you say you're going to step in
> and fix things, then if the community ok's that you get to be the boss
> for that release. With quarterly releases, I can't think of anyone
> having a problem with that :-)

What if we created a backlog by nominating stories, and then got
everyone to prioritize it by voting for stories?

Il giorno sab, 08/07/2006 alle 14.50 +0200, Cees De Groot ha scritto:
> On 7/8/06, Daniel Poon <[hidden email]> wrote:
> I think the most important thing we're not doing is timeboxing.

> I'd suggest a major release per year (so you can break backwards
> compatibility once a year :-)), and a point release per quarter.

+1

I'd add an automated build system which takes care of creating the zip
files for releases, composing the changelog and sending it to
squeak-dev.

        Giovanni

Be my guest.
I have something that is starting to automatize certain aspects but  
not everything.
Have a look at the public helper methods of scriptloader.
After I need a ssh connection so may be I could do that using  
OSProcess but I did not got the time to investigate that

Stef


On 10 juil. 06, at 10:18, Giovanni Corriga wrote:

Can you elaborate? And provide a small example? Maybe what I'm doing
turns out to be the "next Morphic"...
Cheers,
Juan Vuletich

Trygve Reenskaug wrote: