Dear all,
my impression is that we've got a gorgeous release with lots of good things under and above the hood. So far, I'm happy. :-)
But there's going to be a Squeak 4.2, right? Now what's going to happen to make it happen? What things are intended? Is there even a consistent overall idea of what should be achieved for 4.2? Is there any idea? A "vision", so to speak?
I can sense some things, I'd like to have some things. If you ask me, personally, I'd love to see Squeak 4.2 as the best documented Smalltalk out there. I'd also like to see more native GUI support, a JIT compiler, and transparent multicore exploitation. Anyway, I'd like to see more tests, and a green bar.
Eventually, I'd really really love to have a nice and high-level VM implementation (both like and unlike PyPy). But that's probably for 6.0 or so.
Now is the time.
Best,
Michael
I'd be delighted to have a 4.2 roadmap as well and I believe it would be beneficial to the entire community.
Ian.
2010/4/25 Michael Haupt mhaupt@gmail.com:
Dear all,
my impression is that we've got a gorgeous release with lots of good things under and above the hood. So far, I'm happy. :-)
But there's going to be a Squeak 4.2, right? Now what's going to happen to make it happen? What things are intended? Is there even a consistent overall idea of what should be achieved for 4.2? Is there any idea? A "vision", so to speak?
I can sense some things, I'd like to have some things. If you ask me, personally, I'd love to see Squeak 4.2 as the best documented Smalltalk out there. I'd also like to see more native GUI support, a JIT compiler, and transparent multicore exploitation. Anyway, I'd like to see more tests, and a green bar.
Eventually, I'd really really love to have a nice and high-level VM implementation (both like and unlike PyPy). But that's probably for 6.0 or so.
Now is the time.
Best,
Michael
I checked out the meeting minutes from http://squeakboard.wordpress.com/.
Meeting Report for 4/7/2010 April 9, 2010 by andreasraab
.... We spent a good amount of time discussing the situation of external packages in Squeak. We agree that the current situation is undesirable and that hopefully something can be done about this in the 4.2 time frame but what exactly that means is unclear at this point. Some ideas have been voiced that need to be discussed more widely (i.e., on Squeak-dev).
Bert mentioned in a mail on this list that 'Package Management'
could be the grand theme for 4.2
We now have a nice base system. How do I get things into it reliably.
In addition some minor things like - a registry for the world menu and docking bar / people are working on it right now - a better worked out way for loading and unloading GUI elements / people are working on it right now - ... - ....
I think for the discussion it is helpful to mention 4.3 and maybe 4.4 as well. This will help that for this discussion we can bring up basically anything which seems to be useful. Then we can find out what is doable for 4.2
--Hannes
On 4/26/10, Ian Trudel ian.trudel@gmail.com wrote:
I'd be delighted to have a 4.2 roadmap as well and I believe it would be beneficial to the entire community.
Ian.
2010/4/25 Michael Haupt mhaupt@gmail.com:
Dear all,
my impression is that we've got a gorgeous release with lots of good things under and above the hood. So far, I'm happy. :-)
But there's going to be a Squeak 4.2, right? Now what's going to happen to make it happen? What things are intended? Is there even a consistent overall idea of what should be achieved for 4.2? Is there any idea? A "vision", so to speak?
I can sense some things, I'd like to have some things. If you ask me, personally, I'd love to see Squeak 4.2 as the best documented Smalltalk out there. I'd also like to see more native GUI support, a JIT compiler, and transparent multicore exploitation. Anyway, I'd like to see more tests, and a green bar.
Eventually, I'd really really love to have a nice and high-level VM implementation (both like and unlike PyPy). But that's probably for 6.0 or so.
Now is the time.
Best,
Michael
I have thought about it again:
Themes: - Documentation - Package management - More Tests
Plus Open issues which did not make it into 4.1, more GUI enhancements (this includes a one-stop place for importing and exporting resources) and bug fixes.
However realistically speaking - the process should be driven by the people who want to contribute code in the areas.
The other approach is just to set a time frame - and then include what is available at that time.
--Hannes
On 4/26/10, Hannes Hirzel hannes.hirzel@gmail.com wrote:
I checked out the meeting minutes from http://squeakboard.wordpress.com/.
Meeting Report for 4/7/2010 April 9, 2010 by andreasraab
.... We spent a good amount of time discussing the situation of external packages in Squeak. We agree that the current situation is undesirable and that hopefully something can be done about this in the 4.2 time frame but what exactly that means is unclear at this point. Some ideas have been voiced that need to be discussed more widely (i.e., on Squeak-dev).
Bert mentioned in a mail on this list that 'Package Management'
could be the grand theme for 4.2
We now have a nice base system. How do I get things into it reliably.
In addition some minor things like
- a registry for the world menu and docking bar / people are working
on it right now
- a better worked out way for loading and unloading GUI elements /
people are working on it right now
- ...
- ....
I think for the discussion it is helpful to mention 4.3 and maybe 4.4 as well. This will help that for this discussion we can bring up basically anything which seems to be useful. Then we can find out what is doable for 4.2
--Hannes
On 4/26/10, Ian Trudel ian.trudel@gmail.com wrote:
I'd be delighted to have a 4.2 roadmap as well and I believe it would be beneficial to the entire community.
Ian.
2010/4/25 Michael Haupt mhaupt@gmail.com:
Dear all,
my impression is that we've got a gorgeous release with lots of good things under and above the hood. So far, I'm happy. :-)
But there's going to be a Squeak 4.2, right? Now what's going to happen to make it happen? What things are intended? Is there even a consistent overall idea of what should be achieved for 4.2? Is there any idea? A "vision", so to speak?
I can sense some things, I'd like to have some things. If you ask me, personally, I'd love to see Squeak 4.2 as the best documented Smalltalk out there. I'd also like to see more native GUI support, a JIT compiler, and transparent multicore exploitation. Anyway, I'd like to see more tests, and a green bar.
Eventually, I'd really really love to have a nice and high-level VM implementation (both like and unlike PyPy). But that's probably for 6.0 or so.
Now is the time.
Best,
Michael
Hi,
thanks, Hannes, for pointing to the board meeting post.
On Mon, Apr 26, 2010 at 8:02 AM, Hannes Hirzel hannes.hirzel@gmail.com wrote:
I have thought about it again:
Themes:
- Documentation
- Package management
- More Tests
Plus Open issues which did not make it into 4.1, more GUI enhancements (this includes a one-stop place for importing and exporting resources) and bug fixes.
That quite nails it, and is much more sensible than my extensive wish list. :-)
I'll keep those things in mind, though ...
However realistically speaking - the process should be driven by the people who want to contribute code in the areas.
The other approach is just to set a time frame - and then include what is available at that time.
Hm, er, no. Not exactly a vision, right? Is there one? What is Squeak supposed to be in 1 or 2 years? Is there anyone formulating and conveying a roadmap? Anyone?
Best,
Michael
Michael, thank you for your answer.
I started another thread which is even less visionary, going for a 4.1.1 maintenance release ASAP. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149629.htm...
However for the vision part you brought up the idea of
"Squeak as the best documented Smalltalk system"
I like this idea. A friend of mine is a 70 year old mathematician who used to work for IBM 40 years ago. She says that she was taught at that documentation is 50% of the product. I think this still applies. Of course people always say one should browse the code in the image and it is true, it reveals a lot. But if I want a drink out of a soda-wending machine I'd like to know where to put in the coin and which buttons to press. Most of the time I do not want to know how the machine is constructed.
API documentation is fine but process oriented documentation is needed in addition.
Maybe we could have a goal of motivating 30 people contributing to documentation. Everyone writing a little tutorial and with a small sample application.
A calculator, a game, puzzles, a scrapbook, a world clock, ToolBuilder examples, a small parser, some simulations, a little spreadsheet for doing a simple budget, a flash card came, a sound library browser, an outliner, the HelpSystem (with tags), a browser for flickr, a curl plugin example, example accessing this NON-relational databases (JSON based), a website done with Http view, links to Seaside more examples,.... you name it.
Video sessions where people demonstrate how they actually work in Squeak would be beneficial as well.
--Hannes
On 4/26/10, Michael Haupt mhaupt@gmail.com wrote:
Hi,
thanks, Hannes, for pointing to the board meeting post.
On Mon, Apr 26, 2010 at 8:02 AM, Hannes Hirzel hannes.hirzel@gmail.com wrote:
I have thought about it again:
Themes:
- Documentation
- Package management
- More Tests
Plus Open issues which did not make it into 4.1, more GUI enhancements (this includes a one-stop place for importing and exporting resources) and bug fixes.
That quite nails it, and is much more sensible than my extensive wish list. :-)
I'll keep those things in mind, though ...
However realistically speaking - the process should be driven by the people who want to contribute code in the areas.
The other approach is just to set a time frame - and then include what is available at that time.
Hm, er, no. Not exactly a vision, right? Is there one? What is Squeak supposed to be in 1 or 2 years? Is there anyone formulating and conveying a roadmap? Anyone?
Best,
Michael
Hi Hannes,
On Mon, Apr 26, 2010 at 9:52 PM, Hannes Hirzel hannes.hirzel@gmail.com wrote:
However for the vision part you brought up the idea of
"Squeak as the best documented Smalltalk system"
I like this idea.
cool, thanks. :-)
A friend of mine is a 70 year old mathematician who used to work for IBM 40 years ago. She says that she was taught at that documentation is 50% of the product. I think this still applies. ...
It certainly does!
API documentation is fine but process oriented documentation is needed in addition.
Absolutely. I don't really know about others, but I usually learn much better from tutorials, extrapolating usage patterns, than from sheer API documentation. Recently, I learned how to use Java 7's INVOKEDYNAMIC by reading the API documentation from alpha to omega. That was interesting, but not much fun, I can tell you.
A much different but very interesting approach is the one Bruce Tate takes in his upcoming book "Seven Languages in Seven Weeks" (Pragmatic Programmers), in which he introduces (in the given order) Ruby, Io, Prolog, Scala, Erlang, Clojure, and Haskell. Each language is briefly introduced at a high level, and then there are examples. Lots of them, and they very very quickly leave "Hello, world" style things behind, introducing the really interesting bits of those languages without getting overly complicated. (The Haskell chapter has not yet been written, but the Clojure one has just been released in beta stage.)
Another great text is "Real World Haskell" by Bryan O'Sullivan, Don Stewart, and John Goerzen. A wonderfully practical book on a supposedly academic language. During the first few chapters, the authors walk you through accessing the file system already, and some chapters on, there is a complete bar code reader, from parsing the input file (GIF, I think) over adjusting the layout of the code to scanning the bars and emitting the code. *Cool*.
What I want to say is that such things are needed for Squeak. Not at the same order of magnitude (I'm talking about books with several hundreds of pages each), but in the same vein. I'm also not talking about SBE - it's wonderful and important, but concentrates on the tools more than on building mid-scale or larger-scale applications.
Maybe we could have a goal of motivating 30 people contributing to documentation. Everyone writing a little tutorial and with a small sample application.
Or 15 people with 2 tutorials each, or 10 with 3, or whatever.
A calculator, a game, puzzles, a scrapbook, a world clock, ToolBuilder examples, a small parser, some simulations, a little spreadsheet for doing a simple budget, a flash card came, a sound library browser, an outliner, the HelpSystem (with tags), a browser for flickr, a curl plugin example, example accessing this NON-relational databases (JSON based), a website done with Http view, links to Seaside more examples,.... you name it.
I could contribute a Z80 emulator. And probably a Smalltalk VM. ;-)
Best,
Michael
Thank you Michael for your detailed and interesting answer. I put in some comments below
--Hannes
On 4/26/10, Michael Haupt mhaupt@gmail.com wrote:
Hi Hannes,
On Mon, Apr 26, 2010 at 9:52 PM, Hannes Hirzel hannes.hirzel@gmail.com wrote:
However for the vision part you brought up the idea of
"Squeak as the best documented Smalltalk system"
I like this idea.
cool, thanks. :-)
A friend of mine is a 70 year old mathematician who used to work for IBM 40 years ago. She says that she was taught at that documentation is 50% of the product. I think this still applies. ...
It certainly does!
API documentation is fine but process oriented documentation is needed in addition.
Absolutely. I don't really know about others, but I usually learn much better from tutorials, extrapolating usage patterns, than from sheer API documentation. Recently, I learned how to use Java 7's INVOKEDYNAMIC by reading the API documentation from alpha to omega. That was interesting, but not much fun, I can tell you.
A much different but very interesting approach is the one Bruce Tate takes in his upcoming book "Seven Languages in Seven Weeks" (Pragmatic Programmers), in which he introduces (in the given order) Ruby, Io, Prolog, Scala, Erlang, Clojure, and Haskell. Each language is briefly introduced at a high level, and then there are examples. Lots of them, and they very very quickly leave "Hello, world" style things behind, introducing the really interesting bits of those languages without getting overly complicated. (The Haskell chapter has not yet been written, but the Clojure one has just been released in beta stage.)
Another great text is "Real World Haskell" by Bryan O'Sullivan, Don Stewart, and John Goerzen. A wonderfully practical book on a supposedly academic language. During the first few chapters, the authors walk you through accessing the file system already, and some chapters on, there is a complete bar code reader, from parsing the input file (GIF, I think) over adjusting the layout of the code to scanning the bars and emitting the code. *Cool*.
What I want to say is that such things are needed for Squeak. Not at the same order of magnitude (I'm talking about books with several hundreds of pages each), but in the same vein. I'm also not talking about SBE - it's wonderful and important, but concentrates on the tools more than on building mid-scale or larger-scale applications.
Maybe we could have a goal of motivating 30 people contributing to documentation. Everyone writing a little tutorial and with a small sample application.
Or 15 people with 2 tutorials each, or 10 with 3, or whatever.
YES, One or two people probably will provide 5 tutorials, maybe three people 3 tutorials and the rest two or one tutorials.
30 tutorials is a reasonable goal I think. There are people in the documentation thread who have shown interest. Here http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149074.htm... and more here
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149174.htm...
Some of them might have tutorials where just some dusting off is needed and a check if it still works in 4.1.
For writing the tutorials my recommendation is to use Torsten Bergmann's HelpSystem. As it is now it is good enough I think. And it can by loaded through the help menu entry 'Extending the system' as of now.
A calculator, a game, puzzles, a scrapbook, a world clock, ToolBuilder examples, a small parser, some simulations, a little spreadsheet for doing a simple budget, a flash card came, a sound library browser, an outliner, the HelpSystem (with tags), a browser for flickr, a curl plugin example, example accessing this NON-relational databases (JSON based), a website done with Http view, links to Seaside more examples,.... you name it.
I could contribute a Z80 emulator. And probably a Smalltalk VM. ;-)
Best,
Michael
You mention the upcoming book of Bruce Tate "Seven Languages in Seven Weeks" (Pragmatic Programmers), in which he introduces (in the given order) Ruby, Io, Prolog, Scala, Erlang, Clojure, and Haskell.
You mention that it will contain 'lots of examples'.
That is what we need.
Regarding the Z80 emulator. Yes I think that is a good idea. I assume it runs old Z80 games at a reasonable speed these days?
And maybe that example could be used for an implementation of the MMIX RISC computer http://www-cs-faculty.stanford.edu/~uno/mmix.html
And this would lead to a generic set of classes for implementing these kinds of emulators.....
Anyhow it need not be. The Z80 emulator as such is fine. Other people on the list might provide other interpreters.
As the heading of this thread is 'What is the plan for 4.2?' we should try to come up with a list
- title - summary - main responsible, - other contact persons - status
(it's OK for the time being if this list stays within this email thread)
Going through the wiki could be helpful as well. A suggestion, please, for all people who start doing this, may I kindly ask you to "earmark" pages on that wiki you think are useful with the tag 'RelevantForSqueak41"
--Hannes
"Squeak as the best documented Smalltalk system" +1
30 tutorials is a great idea, but don't forget video. A video walkthrough of each tutorial would be excellent and would serve for teaching tool usage as well.
I love the smell of progress in the morning!
Regards, Sam
Sam S. Adams, IBM Distinguished Engineer, IBM Research Mobile: 919-696-6064, email: ssadams@us.ibm.com Asst: Kenndra K. Quiles. (732) 926-2292 Fax: (732) 926-2455, email: Kenndra@us.ibm.com <<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>
squeak-dev-bounces@lists.squeakfoundation.org wrote on 04/28/2010 08:15:35 AM:
Hannes Hirzel hannes.hirzel@gmail.com Sent by: squeak-dev-bounces@lists.squeakfoundation.org
04/28/2010 08:15 AM
Please respond to The general-purpose Squeak developers list <squeak- dev@lists.squeakfoundation.org>
To
The general-purpose Squeak developers list <squeak- dev@lists.squeakfoundation.org>
cc
Subject
Re: [squeak-dev] What is the plan for 4.2?
Thank you Michael for your detailed and interesting answer. I put in some comments below
--Hannes
On 4/26/10, Michael Haupt mhaupt@gmail.com wrote:
Hi Hannes,
On Mon, Apr 26, 2010 at 9:52 PM, Hannes Hirzel
wrote:
However for the vision part you brought up the idea of
"Squeak as the best documented Smalltalk system"
I like this idea.
cool, thanks. :-)
A friend of mine is a 70 year old mathematician who used to work for IBM 40 years ago. She says that she was taught at that documentation is 50% of the product. I think this still applies. ...
It certainly does!
API documentation is fine but process oriented documentation is needed in addition.
Absolutely. I don't really know about others, but I usually learn much better from tutorials, extrapolating usage patterns, than from sheer API documentation. Recently, I learned how to use Java 7's INVOKEDYNAMIC by reading the API documentation from alpha to omega. That was interesting, but not much fun, I can tell you.
A much different but very interesting approach is the one Bruce Tate takes in his upcoming book "Seven Languages in Seven Weeks" (Pragmatic Programmers), in which he introduces (in the given order) Ruby, Io, Prolog, Scala, Erlang, Clojure, and Haskell. Each language is briefly introduced at a high level, and then there are examples. Lots of them, and they very very quickly leave "Hello, world" style things behind, introducing the really interesting bits of those languages without getting overly complicated. (The Haskell chapter has not yet been written, but the Clojure one has just been released in beta stage.)
Another great text is "Real World Haskell" by Bryan O'Sullivan, Don Stewart, and John Goerzen. A wonderfully practical book on a supposedly academic language. During the first few chapters, the authors walk you through accessing the file system already, and some chapters on, there is a complete bar code reader, from parsing the input file (GIF, I think) over adjusting the layout of the code to scanning the bars and emitting the code. *Cool*.
What I want to say is that such things are needed for Squeak. Not at the same order of magnitude (I'm talking about books with several hundreds of pages each), but in the same vein. I'm also not talking about SBE - it's wonderful and important, but concentrates on the tools more than on building mid-scale or larger-scale applications.
Maybe we could have a goal of motivating 30 people contributing to documentation. Everyone writing a little tutorial and with a small sample application.
Or 15 people with 2 tutorials each, or 10 with 3, or whatever.
YES, One or two people probably will provide 5 tutorials, maybe three people 3 tutorials and the rest two or one tutorials.
30 tutorials is a reasonable goal I think. There are people in the documentation thread who have shown interest. Here
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149074.htm...
and more here
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149174.htm...
Some of them might have tutorials where just some dusting off is needed and a check if it still works in 4.1.
For writing the tutorials my recommendation is to use Torsten Bergmann's HelpSystem. As it is now it is good enough I think. And it can by loaded through the help menu entry 'Extending the system' as of now.
A calculator, a game, puzzles, a scrapbook, a world clock, ToolBuilder examples, a small parser, some simulations, a little spreadsheet for doing a simple budget, a flash card came, a sound library browser, an outliner, the HelpSystem (with tags), a browser for flickr, a curl plugin example, example accessing this NON-relational databases (JSON based), a website done with Http view, links to Seaside more examples,.... you name it.
I could contribute a Z80 emulator. And probably a Smalltalk VM. ;-)
Best,
Michael
You mention the upcoming book of Bruce Tate "Seven Languages in Seven Weeks" (Pragmatic Programmers), in which he introduces (in the given order) Ruby, Io, Prolog, Scala, Erlang, Clojure, and Haskell.
You mention that it will contain 'lots of examples'.
That is what we need.
Regarding the Z80 emulator. Yes I think that is a good idea. I assume it runs old Z80 games at a reasonable speed these days?
And maybe that example could be used for an implementation of the MMIX RISC computer http://www-cs-faculty.stanford.edu/~uno/mmix.html
And this would lead to a generic set of classes for implementing these kinds of emulators.....
Anyhow it need not be. The Z80 emulator as such is fine. Other people on the list might provide other interpreters.
As the heading of this thread is 'What is the plan for 4.2?' we should try to come up with a list
- title
- summary
- main responsible,
- other contact persons
- status
(it's OK for the time being if this list stays within this email thread)
Going through the wiki could be helpful as well. A suggestion, please, for all people who start doing this, may I kindly ask you to "earmark" pages on that wiki you think are useful with the tag 'RelevantForSqueak41"
--Hannes
Hi Hannes,
On Wed, Apr 28, 2010 at 2:15 PM, Hannes Hirzel hannes.hirzel@gmail.com wrote:
For writing the tutorials my recommendation is to use Torsten Bergmann's HelpSystem. As it is now it is good enough I think. And it can by loaded through the help menu entry 'Extending the system' as of now.
this help system is one gorgeous and useful piece of code. Heck. :-)
Regarding the Z80 emulator. Yes I think that is a good idea. I assume it runs old Z80 games at a reasonable speed these days?
Nopes. As of now, it is really just a Z80 emulator (read: it emulates the processor, not any of the machines built using it), and some things like interrupts are still not complete. Once those things exist, I want to build a ZX81 on top of it.
As the heading of this thread is 'What is the plan for 4.2?' we should try to come up with a list ...
I think we should harvest what's there first, and then see what's missing - to fill in holes.
Going through the wiki could be helpful as well. ...
Precisely what I mean. :-)
Best,
Michael
squeak-dev@lists.squeakfoundation.org
-
Hannes Hirzel -
Ian Trudel -
Michael Haupt -
Sam Adams