Roadmap proposal for 3.10/4.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Roadmap proposal for 3.10/4.0

Stéphane Ducasse-3
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



       




Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Edgar J. De Cleene
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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Klaus D. Witzel
In reply to this post by Stéphane Ducasse-3
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Andreas.Raab
In reply to this post by Stéphane Ducasse-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

J J-6
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.


>From: Andreas Raab <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Roadmap proposal for 3.10/4.0
>Date: Sun, 15 Oct 2006 12:04:44 -0700
>
>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
>



Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Ramon Leon-4
In reply to this post by Andreas.Raab
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.
>
> 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
  +1


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Zulq Alam-2
In reply to this post by Andreas.Raab
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.


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Brad Fuller
In reply to this post by Stéphane Ducasse-3
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:

> 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
>
>
>
>    
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Michael van der Gulik
In reply to this post by Stéphane Ducasse-3
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:

> 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

I'm assuming this is just an option, and won't mean ugly things like
Object>>loadTweak.

>     - 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

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!

>     - 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

Please make this a loadable option.

Michael.


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Klaus D. Witzel
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


Reply | Threaded
Open this post in threaded view
|

RE: Roadmap proposal for 3.10/4.0

Ron Teitelbaum
In reply to this post by Andreas.Raab
+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

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Andreas Raab
> Sent: Sunday, October 15, 2006 3:05 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Roadmap proposal for 3.10/4.0
>
> 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
>



Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

stephane ducasse-2
In reply to this post by Andreas.Raab
sounds good idea. Why not in fact.

Stef

On 15 oct. 06, at 21:04, 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.
>
> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

KenDickey
In reply to this post by Stéphane Ducasse-3
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



-KenD
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

stephane ducasse-2
In reply to this post by Andreas.Raab
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.

> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

stephane ducasse-2
In reply to this post by J J-6
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.


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

stephane ducasse-2
In reply to this post by KenDickey
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:

> 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
>
>
>


Reply | Threaded
Open this post in threaded view
|

Complex numbers (was Re: Roadmap proposal for 3.10/4.0)

Bert Freudenberg
In reply to this post by KenDickey
Am 17.10.2006 um 03:45 schrieb Ken Dickey:

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

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 -


Reply | Threaded
Open this post in threaded view
|

open process issues (was: Roadmap proposal for 3.10/4.0)

Lex Spoon
In reply to this post by Ron Teitelbaum
"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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap proposal for 3.10/4.0

Alan Grimes-2
In reply to this post by KenDickey
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.

123