I get this while trying to load FractalMorph 1.2 from the Package Universe browser:
PluggableTextMorph(Object)>>doesNotUnderstand: #hideScrollBarIndefinitely FractalMorph>>initButtons FractalMorph>>initialize FractalMorph class(Behavior)>>new UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing: {[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk l...]} BlockContext>>on:do: [] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing: {[:bar | [self atEnd] whileFalse: [bar value: self position. self skipS...]} [] in ProgressInitiationException>>defaultMorphicAction {[result := workBlock value: progress]} BlockContext>>ensure: ProgressInitiationException>>defaultMorphicAction ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during:
On 04/12/2008, at 23:42, Greg A. Woods; Planix, Inc. wrote:
I get this while trying to load FractalMorph 1.2 from the Package Universe browser:
PluggableTextMorph(Object)>>doesNotUnderstand: #hideScrollBarIndefinitely FractalMorph>>initButtons FractalMorph>>initialize FractalMorph class(Behavior)>>new UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing: {[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk l...]} BlockContext>>on:do: [] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing: {[:bar | [self atEnd] whileFalse: [bar value: self position. self skipS...]} [] in ProgressInitiationException>>defaultMorphicAction {[result := workBlock value: progress]} BlockContext>>ensure: ProgressInitiationException>>defaultMorphicAction ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during:
-- Greg A. Woods; Planix, Inc. woods@planix.ca
http://map.squeak.org/package/5728e8ea-6a53-4a67-ae1c-07f17defca22
Shows is originated in 3.4 , so no surprise not porper work in 3.10.
As I said in previous mail, we need a Packages Czar now, with power to rule the Universes :=)
I could do this , if all agree.
For credentials, I made SqueakLight , SqueakLightII, FunSqueak, was in past Release Team and help to port many old friends to recent images.
Edgar
On 05/12/2008, at 06:01, Andreas Raab wrote:
I think this would be great. You have my support.
Cheers,
- Andreas
Very thanks.
My Plan , as we discusss with Ralph (hope he read and correct me) A review of "state of affairs" for all packages now in Squeakmap.
Tentative list to check.
This "MyGreatThing" is on Universes ? Loads in fresh 3.10 current ? Who owns / mantain it ? Have .mcz version in SqueakSource ? Have tutorial for newbies ?
We discuss in doing a Lint for each, we could do swiki page for this. In the past, many improve his packages when I email they. In Ralph Monticello version in 3,10, when you have a Undeclared you got a halt.
I once talk about some more , like a Custom Office checking you don't bring bombs or dangeorous things to OurKingdom. Ideas to check this ?
All packages should have a owner. No foreing people should take other packages. Packages without owner for two years become free for any wishing take they, Packages without any wishing take they go to OrphansHouse,
Feedback ?
Edgar
Andreas Raab wrote:
Edgar J. De Cleene wrote:
As I said in previous mail, we need a Packages Czar now, with power to rule the Universes :=)
I could do this , if all agree.
I think this would be great. You have my support.
Cheers,
- Andreas
I suggested this months and months ago, the packages@list.squeakfoundation.org was seconded for this very purpose, and is used for that very thing.
Since the keeper of Universes resisted any sensible suggestions to make things open enough to fix problems effectively, I developed Sake/Packages instead. I spent less time developing Sake/Packages than I did wrestling with Universes trying to build my production image.
The best way forward is for the community to manage all of the package definitions for all of the images in Sake/Packages. Then to have an automated build script which is able to update the universe(s) server from the Sake/Packages definitions.
At present this is done the other way around, Universes is synced to Sake/Packages, but S/P reserves the right to override the universes definition. Inability to fix a broken universe entry is still the biggest problem in keeping things in sync.
My personally favoured option would be to forget about universes entirely because it is a pain to keep current. But the "keeping them bothin sync" option would certainly be worthwhile.
Keith
p.s. Andreas, Sake/Packages is data driven now.
I'm glad I'm keeping this topic alive with my bug reports! :-)
I must say though that the underlying complexity that shows up here mystifies me somewhat. I'm guessing there's some kind of politics under the hood that I'm not fully aware of.
The basic problem for me is that I need the default package management tool, however it might work under the hood, to actually work reliably, 110%, all the time for everyone.
I.e. there's a button for the user to press in the default 3.10.2-7179- basic package which starts the process and I think it's essential that everything from there work 110%, even if it means that what's available lags somewhat behind the latest and greatest of what's available.
Also essential is a clean and safe way of upgrading installed packages. Default error handlers need to be in place to cleanly and safely back out any attempted upgrades which encounter any errors or conflicts. It would also be nice to have a de-installer and cleanup tools in the package manager too. Sure one can always start with a fresh image and load everything still wanted from scratch, including one's own local change sets, etc., and doing so has some of its own advantages, but for beginners and _end_ users an uninstaller is pretty much a necessary feature of any package management subsystem.
The consequences of not having 110% perfection in the initial user experience of loading new packages into the now stripped down basic Squeak image means skeptical users will be driven away in droves.
Perhaps it would be better to return to a form of the old pre-loaded bloated image, but this time adorn it with tools that would facilitate _unloading_ of unwanted packages by those who want to reduce the bloat. The last time I forayed with any dedication into the world of Squeak I was actually very happy to have a complete stable distribution image that came with all the available tools and toys already installed and tested. It meant I could jump right in and play or work with anything and everything. Now with 3.10 it's almost three weeks since I tried to "upgrade" and I'm still struggling. I hate to think what any more naive user than I would feel about this experience.
There are problems with the pre-loaded image though -- looking at what's in the dev image now makes me want to avoid it because it contains some stuff I don't want, stuff which so far as I understand actually changes too much about the environment over and above the default "basic" configuration which want to work with.
Squeak definitely needs a good strong leader, or at least a cohesive leadership, with a good and hopefully popular vision of where the core is going and how it's going to get there, and I think now with the "basic" default image being one without everything pre-loaded this vision has to stretch out over the basic package management issues too.
Hear, hear. This has the makings of a manifesto. Thus I have quoted it in its entirety :)
- TimJ
On Dec 5, 2008, at 1:32 PM, Greg A. Woods; Planix, Inc. wrote:
I'm glad I'm keeping this topic alive with my bug reports! :-)
I must say though that the underlying complexity that shows up here mystifies me somewhat. I'm guessing there's some kind of politics under the hood that I'm not fully aware of.
The basic problem for me is that I need the default package management tool, however it might work under the hood, to actually work reliably, 110%, all the time for everyone.
I.e. there's a button for the user to press in the default 3.10.2-7179-basic package which starts the process and I think it's essential that everything from there work 110%, even if it means that what's available lags somewhat behind the latest and greatest of what's available.
Also essential is a clean and safe way of upgrading installed packages. Default error handlers need to be in place to cleanly and safely back out any attempted upgrades which encounter any errors or conflicts. It would also be nice to have a de-installer and cleanup tools in the package manager too. Sure one can always start with a fresh image and load everything still wanted from scratch, including one's own local change sets, etc., and doing so has some of its own advantages, but for beginners and _end_ users an uninstaller is pretty much a necessary feature of any package management subsystem.
The consequences of not having 110% perfection in the initial user experience of loading new packages into the now stripped down basic Squeak image means skeptical users will be driven away in droves.
Perhaps it would be better to return to a form of the old pre-loaded bloated image, but this time adorn it with tools that would facilitate _unloading_ of unwanted packages by those who want to reduce the bloat. The last time I forayed with any dedication into the world of Squeak I was actually very happy to have a complete stable distribution image that came with all the available tools and toys already installed and tested. It meant I could jump right in and play or work with anything and everything. Now with 3.10 it's almost three weeks since I tried to "upgrade" and I'm still struggling. I hate to think what any more naive user than I would feel about this experience.
There are problems with the pre-loaded image though -- looking at what's in the dev image now makes me want to avoid it because it contains some stuff I don't want, stuff which so far as I understand actually changes too much about the environment over and above the default "basic" configuration which want to work with.
Squeak definitely needs a good strong leader, or at least a cohesive leadership, with a good and hopefully popular vision of where the core is going and how it's going to get there, and I think now with the "basic" default image being one without everything pre-loaded this vision has to stretch out over the basic package management issues too.
+ 1
Stef
On 05/12/2008, at 16:32, Greg A. Woods; Planix, Inc. wrote:
Squeak definitely needs a good strong leader, or at least a cohesive leadership, with a good and hopefully popular vision of where the core is going and how it's going to get there, and I think now with the "basic" default image being one without everything pre-loaded this vision has to stretch out over the basic package management issues too.
But we don't have a good strong leader.
Hopes of many was when Dan say he wish be on Board.
Now I sit on his chair (because maybe nobody with better qualification is at hand ?).
You should be new, so don't know about Pirates or Failed Unification of all Forks (Open meeting regarding the Squeak Release Team, look for this)
This days all have his own image and some go Pharo, some go Damien dev, no idea who is going Squeakland or EToys or Sophie or Scratch or...
Maybe we becoming Linux ? With thousands of distributions on some similar core ?
Ketih and Matthew said they made 3.11 .
Craig said he made Spoon.
Where are they ? Could you use ?
I have my pet , SqueakLightIi, based on years of work, RUNNING.
http://wiki.squeak.org/squeak/6056 http://wiki.squeak.org/squeak/6098
I have FunSqueak RUNNING
Edgar
P.S. I don't said running at 110% as you wish, For this I ask zillions gold coins , like the other Board member who leaves we in the dark and crying :-)
Pharo is active and producing the Smalltalk that I always wanted.
On Fri, Dec 5, 2008 at 3:12 PM, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
On 05/12/2008, at 16:32, Greg A. Woods; Planix, Inc. wrote:
Squeak definitely needs a good strong leader, or at least a cohesive leadership, with a good and hopefully popular vision of where the core is going and how it's going to get there, and I think now with the "basic" default image being one without everything pre-loaded this vision has to stretch out over the basic package management issues too.
But we don't have a good strong leader. Hopes of many was when Dan say he wish be on Board. Now I sit on his chair (because maybe nobody with better qualification is at hand ?). You should be new, so don't know about Pirates or Failed Unification of all Forks (Open meeting regarding the Squeak Release Team, look for this) This days all have his own image and some go Pharo, some go Damien dev, no idea who is going Squeakland or EToys or Sophie or Scratch or... Maybe we becoming Linux ? With thousands of distributions on some similar core ? Ketih and Matthew said they made 3.11 . Craig said he made Spoon. Where are they ? Could you use ? I have my pet , SqueakLightIi, based on years of work, RUNNING. http://wiki.squeak.org/squeak/6056 http://wiki.squeak.org/squeak/6098 I have FunSqueak RUNNING Edgar P.S. I don't said running at 110% as you wish, For this I ask zillions gold coins , like the other Board member who leaves we in the dark and crying :-)
2008/12/5 David Mitchell david.mitchell@gmail.com:
Pharo is active and producing the Smalltalk that I always wanted.
- there is no human resources to support bloated image(s) by single team, and i hope that Pharo guys understand this clearly and never turn back to strategy of maintaining big-fat bloated images. It should be clear, where ends Pharo and where starts package(s) developed and maintained by independent developers/teams.
- i think that somewhere in crosshatching Pharo and Spoon lies a golden spot: - having well integrated old-style image (Pharo) - but also be very agile/modular (Spoon).
- IMO, first and ultimately , squeak needs better modularity to move on. - only when we solve the first problem, it would be much easier to come up with better integration solutions (packaging tools)
Igor Stasenko wrote:
2008/12/5 David Mitchell david.mitchell@gmail.com:
Pharo is active and producing the Smalltalk that I always wanted.
- there is no human resources to support bloated image(s) by single
team, and i hope that Pharo guys understand this clearly and never turn back to strategy of maintaining big-fat bloated images. It should be clear, where ends Pharo and where starts package(s) developed and maintained by independent developers/teams.
Well said that man!
+10
Keith
i think that somewhere in crosshatching Pharo and Spoon lies a golden spot:
- having well integrated old-style image (Pharo)
- but also be very agile/modular (Spoon).
IMO, first and ultimately , squeak needs better modularity to move on.
only when we solve the first problem, it would be much easier to
come up with better integration solutions (packaging tools)
My point exactly - watch this space
On 05/12/2008, at 17:27, David Mitchell wrote:
Pharo is active and producing the Smalltalk that I always wanted.
So go to Pharo, I don't wish unhappy people.
Or go Ruby, Perl, COBOL or any you feel at home with.
But I want Squeak as once was.
For kids, for teachers, for researchers and for web developers, and for all who found some different in it.
And I do my best for going smaller and modular for you only load what you want and others load different things like MathMorphs, MorphicWrappers, Etoys, or maybe Morphic 3.0 one day.
This list lost FUN.
Edgar
Edgar J. De Cleene wrote:
On 05/12/2008, at 16:32, Greg A. Woods; Planix, Inc. wrote:
Squeak definitely needs a good strong leader, or at least a cohesive leadership, with a good and hopefully popular vision of where the core is going and how it's going to get there, and I think now with the "basic" default image being one without everything pre-loaded this vision has to stretch out over the basic package management issues too.
But we don't have a good strong leader.
No we dont need a strong leader. We tried that one before and what we got was an uncommunicative invisible ne disappearing leader.
What we need is people who are willing to contribute positively to the positive forward thinking vision that we already have got. There is a vision for 3.11, and there is a vision for 4, and 5. For 3 and 4 we have a fairly bold and strong philosophical line, of making as many things work for as many people as possible. And providing the tools required in order to move forward.
Previous release teams identified the need for tools, for atomic loading for example, then focussed primarily on the image once more, plugging away with the old tools, and complaining all the way about the tools.
While the pharo faction is hammering away on the core image, its roughly the same team who years ago complained that their work was hard because the tools (i.e. Monticello) werent good enough for the job. They also announce... "we are going for a more modular image"... and they have no coherent strategy or effective tools for explaining how once I have a more modular image I can (un)load things back in again and be sure that they will work.
For years and years and years the difficulty of doing things particularly.
1) loading stuff getting dependencies right so things work 2) writing stuff that works and is loadable in many images 3) Providing feedback to the community about what works where and what doesnt. 4) unloading (forget it)
These have been the biggest NEEDS in the community for those of us who are using squeak for real work. They have ALL been addressed in the ongoing 3.11/3.x tools effort.
Another thing that has been difficult has been migrating large codebases from one image to another because the tools were different in each squeak version. At one time I was working on projects in 3 different squeak versions simultaneously, while maintaining 6 further images because of the bugs in monticello1.
I dont need a better kernel I would like one, but I dont need it (YET). Its a complete red herring until I can build production images that work in less than 2 weeks. (thats what it took me using universes) Without having to email every package owner, and twist their arm to fix things or add my fixes to their code because I am using a more recent image than they are.
Our goals are to make things better for everyone. The pharo team have no such goals to ensure that their wonderful improvements to the image are as widely useful to the community as possible. Any tools they produce are in the first instance for their image only.
Did you know that someone in the Pharo camp recently merged FileList and FileList2. Is it just me or could that improvement be useful to everyone, whether in etoys or croquet. There is nothing in the Pharo mindset or toolset that enables this to happen by default.
In contrast, for us, that is our number one goal. With the work that we have been doing for 3.11, all the tools work for all the people in theory. With the help of Installer, Sake/Packages and LevelPlayingField, that FileList-improved could be made available to everyone, croquet, etoys, sophie, not only that it can be loaded atomically too. We have and are building the TOOLS to achieve this now.
Does that example help you see the difference of what we are trying to achieve. We can and will catch up with these "exclusive visionaries", we can pick the best of SqueakLight/FunSqueak/Pharo, but we can do it in a coherent, considered "for as many as possible" manner.
The 3.x era is drawing to a close, what we need is more coherence, and stability, and better tools.
The 3.11 team has a philosophy of improving the tools for everyone. And if you look carefully a lot has happened on the tools front in the past 18 months.
There is a coherent strategy in place, and a vision, even if that vision is a long time in coming, it is coming
volunteers are welcome to join us on squeak irc
Keith
Hello Keith,
2008/12/5 Keith Hodges keith_hodges@yahoo.co.uk
Did you know that someone in the Pharo camp recently merged FileList and FileList2. Is it just me or could that improvement be useful to everyone, whether in etoys or croquet. There is nothing in the Pharo mindset or toolset that enables this to happen by default.
I merged FileList two weeks before I saw the open issue in the Pharo issues list, as an excercise in a new automatic merging tool I'm writing. But anyone feel free to take that fix and merge it into any Squeak image.
Cheers.
Hernán
On 05/12/2008, at 22:20, Hernán Morales Durand wrote:
I merged FileList two weeks before I saw the open issue in the Pharo issues list, as an excercise in a new automatic merging tool I'm writing. But anyone feel free to take that fix and merge it into any Squeak image.
Cheers.
Hernán
Where is the code ? So I put into SqueakLighthII , the only thing working now . 3.11 ? Vaporware....
Edgar
Hello Edgar,
EJDC> 3.11 ? Vaporware....
unnecessary destructive comment.
Cheers,
Herbert
El 12/6/08 8:20 AM, "Herbert König" herbertkoenig@gmx.net escribió:
Hello Edgar,
EJDC> 3.11 ? Vaporware....
unnecessary destructive comment.
Cheers,
Herbert
Seems this point is still without a minimal consensus.
For me, Squeak is a descendant of original Smalltalk.
Any disagree ?
Because the way of Smalltalk is a image in chicken and egg cycle and any image comes from previous one, mutating in the process.
And Smalltalk is about objects and not about scripting.
Any not sharing this should be on another list.
Also Squeak once was a wonderful fun world for all.
Children's, teachers, researchers and web developers.
I have deep respect for Pharo people, but fellows, Pharo is not Squeak and I don't lost my time with it.
I know my SqueakLightII is not a silver bullet . I name it SqueakLightII , because 3.11 name was taked at the time and I have a SqueakLight before, but is really a logic step from 3.10. Smaller and more modular.
Yesterday I have another fight on IRC with no minimal consensus.
Some say I can't made image and others could do.
Others say I should join they and I saw 3.11 folder empty, like when I create it a long , long time ago.
We don't have more with us to Dan , Ralph , Ned, Diego , Steph , Tim , Pavel, etc.
If I don't put some , is by lack of memory.
So Herbert , you should know me better. I don't wish be destructive.
I wish AWAKE Squeakers.
Edgar
2008/12/6 Edgar J. De Cleene edgardec2001@yahoo.com.ar:
El 12/6/08 8:20 AM, "Herbert König" herbertkoenig@gmx.net escribió:
Hello Edgar,
EJDC> 3.11 ? Vaporware....
unnecessary destructive comment.
Cheers,
Herbert
Seems this point is still without a minimal consensus.
For me, Squeak is a descendant of original Smalltalk.
Any disagree ?
Because the way of Smalltalk is a image in chicken and egg cycle and any image comes from previous one, mutating in the process.
And Smalltalk is about objects and not about scripting.
Any not sharing this should be on another list.
Also Squeak once was a wonderful fun world for all.
Children's, teachers, researchers and web developers.
I have deep respect for Pharo people, but fellows, Pharo is not Squeak and I don't lost my time with it.
Hmm, i see nothing fun when i loading random package from squeak map have a 50% chance (or less) of successfull load. And even if it loads, it could be half-working and may lead to DNU/crash each time i using this package. Maybe i too dumb , because i can't see how such situation can be called wonderfull world for "children's, teachers, researchers and web developers".
I know my SqueakLightII is not a silver bullet . I name it SqueakLightII , because 3.11 name was taked at the time and I have a SqueakLight before, but is really a logic step from 3.10. Smaller and more modular.
Being smaller doesn't makes it any more modular.
Yesterday I have another fight on IRC with no minimal consensus.
Some say I can't made image and others could do.
Others say I should join they and I saw 3.11 folder empty, like when I create it a long , long time ago.
We don't have more with us to Dan , Ralph , Ned, Diego , Steph , Tim , Pavel, etc.
If I don't put some , is by lack of memory.
So Herbert , you should know me better. I don't wish be destructive.
I wish AWAKE Squeakers.
To awake Squeakers, you should think about developers. Not childrens, nor teachers, because they are end users. First we should make squeak a nice living places for devs, then developers will turn it out to nice place for the rest in the world. Make no toys, make things for professionals, so they can easily make own toys. And 3.11 "vaporware" is the step towards developers, as well as Pharo.
Edgar
Igor,
On Sat, Dec 6, 2008 at 3:12 PM, Igor Stasenko siguctua@gmail.com wrote:
To awake Squeakers, you should think about developers. Not childrens, nor teachers, because they are end users.
First we should make squeak a nice living places for devs, then developers will turn it out to nice place for the rest in the world.
Make no toys, make things for professionals, so they can easily make own
toys. And 3.11 "vaporware" is the step towards developers, as well as Pharo.
To be true, thinking, that you have forgotten, that:
Software developer or programmer is just like a translator, and nothing more... Their work is to interpret the "real world problems" of "end users" into "virtual world problems". But they NOTHING know really about these "real world problems" and how to solve them in "virtual world" also. They could only translate "word by word or letter by letter" according to the "sentences", constructed by the "end user" (like "from English to French etc.") using different models.
SQUEAK is one of the attempts to develop the self-exploratory environment, where "developers" could not be needed for the "end users" at all, because "end users" are NOT "end users=impotent mans=dead users etc..", but they are the CREATORS of their own real and virtual worlds and life. So, Etoys is not a "toy", but the real "anti-developer-programmer" software solution attempt, that allows "end users" to be the real CREATORS.
"To awake Squeakers", you should think about children, teachers, etc.. and about developers, who accept the Etoy's philosophic concept at list.
Regards, Nikolay Suslov
2008/12/7 Nikolay Suslov nsuslovi@gmail.com:
Igor,
On Sat, Dec 6, 2008 at 3:12 PM, Igor Stasenko siguctua@gmail.com wrote:
To awake Squeakers, you should think about developers. Not childrens, nor teachers, because they are end users.
First we should make squeak a nice living places for devs, then developers will turn it out to nice place for the rest in the world.
Make no toys, make things for professionals, so they can easily make own toys. And 3.11 "vaporware" is the step towards developers, as well as Pharo.
To be true, thinking, that you have forgotten, that:
Software developer or programmer is just like a translator, and nothing more... Their work is to interpret the "real world problems" of "end users" into "virtual world problems". But they NOTHING know really about these "real world problems" and how to solve them in "virtual world" also. They could only translate "word by word or letter by letter" according to the "sentences", constructed by the "end user" (like "from English to French etc.") using different models.
SQUEAK is one of the attempts to develop the self-exploratory environment, where "developers" could not be needed for the "end users" at all, because "end users" are NOT "end users=impotent mans=dead users etc..", but they are the CREATORS of their own real and virtual worlds and life. So, Etoys is not a "toy", but the real "anti-developer-programmer" software solution attempt, that allows "end users" to be the real CREATORS.
Well, if you find a kid, who can write a web server, search engine, 3D-modeling environment just using etoys , then we don't need to distinguish developers/non-developers anymore. Until that moment, we obviously should do.
"To awake Squeakers", you should think about children, teachers, etc.. and about developers, who accept the Etoy's philosophic concept at list.
A have nothing against Etoys. But i don't think that squeak , as language, as environment , best and ultimately its goal was Etoys. Etoys is done & shipped. So, lets hug each other, say bye and each go its own road? Or maybe there is still a lot of fun things which can be done, apart from etoys?
Regards, Nikolay Suslov
On Dec 6, 2008, at 8:12 AM, Igor Stasenko wrote:
Hmm, i see nothing fun when i loading random package from squeak map have a 50% chance (or less) of successfull load. And even if it loads, it could be half-working and may lead to DNU/crash each time i using this package. Maybe i too dumb , because i can't see how such situation can be called wonderfull world for "children's, teachers, researchers and web developers".
There was a professor at the University here who had the two Mark Guzdial Squeak books on her shelf when I went to work on her computer, roughly two years ago. I struck up a conversation about Squeak. I knew already that she didn't teach Squeak in any courses here. She said Squeak was very neat, but "very buggy." She found it hard to get anything done because she "kept running into bugs." She sounded as if she considered it something of a shame.
- TimJ
Hello Edgar,
EJDC> 3.11 ? Vaporware....
unnecessary destructive comment.
...snip..
EJDC> Any not sharing this should be on another list. hm, that is decided by who subscribes to this list.
EJDC> Also Squeak once was a wonderful fun world for all. EJDC> Children's, teachers, researchers and web developers. I came to Squeak 3.6 and yes that was the fascinating thing about Squeak then. Seen (solely) from that perspective Squeak went downhill from then to now.
But 3.7 and 3.8 brought things with them that made Squeak more practical for me, so now I'm on 3.8.2. I saw the loss but was not willing to do the work, so what? 3.9 and 3.10 didn't and didn't appeal to me.
EJDC> I know my SqueakLightII is not a silver bullet . EJDC> I name it SqueakLightII , because 3.11 name was taked at the time and I have EJDC> a SqueakLight before, but is really a logic step from 3.10. EJDC> Smaller and more modular.
And more of the old great projects running on it, at least your reports say.
EJDC> We don't have more with us to EJDC> Dan , Ralph , Ned, Diego , Steph , Tim , Pavel, etc.
Actually two things are needed: Work getting done and gathering of followers. For SqueakLight I can only be the consumer. Consumers don't report bugs, they turn away and take a fresh look later.
On the positive side I feel that more people have come here than have left here. And I feel that both 3.11 and 4.0 efforts may bring us closer to Squeak being a better base when somebody again will build the big image with everything.
But maybe Squeak will change to being the great developer tool envisioned by some here and the fun and play squeak will stay in a less universal incarnation with Squeakland.
The world changes.
EJDC> So Herbert , you should know me better. EJDC> I don't wish be destructive.
Yes I know you better but this is a public list. Calling some peoples efforts "vaporware" is diminishing (a lot of) work that is done with good intention and not awaking anybody.
Btw I had a lot of fun using Squeak the development tool to let a program play Asteroids on a simulator running the original ROM of the ca. 1980 Atari arcade game. Real great useless fun!
http://www.heise.de/ct/creativ/08/02/ergebnisse/ click on any of the
triangles, you find me on position 69, most impressive is position
17.
Cheers,
Herbert
Herbert König wrote:
Btw I had a lot of fun using Squeak the development tool to let a program play Asteroids on a simulator running the original ROM of the ca. 1980 Atari arcade game. Real great useless fun!
http://www.heise.de/ct/creativ/08/02/ergebnisse/ click on any of the
triangles, you find me on position 69, most impressive is position
Hi Herbert.. that is pretty fun indeed. Yours plays like me except with good aim. 17 is indeed impressive, but it's so unhuman that it's stressful to watch! :)
It would be fun to read your code.
Hello Simon,
SM> Hi Herbert.. that is pretty fun indeed. Yours plays like me except with SM> good aim. 17 is indeed impressive, but it's so unhuman that it's SM> stressful to watch! :)
same link, scroll deeper, there is another table (search Squeak). If you click on the down arrow there, you can download the image. I guess I provided a batch (Win) and a .st to autostart.
If it contains separate sources, to not have the sources in files discussion I filed out everything, as they required sources. Programming language is English so you should have a chance in reading code.
Feel free to mail me in private for more information.
To all...
Can we, for once, take a deep breath and step back for a minute. No, we can't ALL be on the same page with the same goals, motivations and preferences. Personally, I don't care about EToys, Traits and some other-cool-things-that-I-do-not-use but I can understand some people have interests different than mine.
"This is a Pharo list now". No, Pharo has its own mailing list. But the Pharo guys are kind enough and do care about Smalltalk/Squeak enough that when they find/fix bugs that they suspect could be present in "other flavors/forks" of Squeak, they simply post it here too. Just to be nice. Just to help the "Squeak" community. "Squeak" not just as in "Squeak-dev" but more in the "larger sense", WhateverSqueak fork out there.
Personally, the more forks we have, the more chances we have to "convert" someone into Squeak, Smalltalk. The more Smalltalk (or Squeak) flavors out there, the better. Even though I never use ObjectStudio nor GNU Smalltalk, I'd never criticize or "bash" those guys because, in a sense, I feel we are in the same "community", the Smalltalkers one. The more Smalltalk grows (in directions we like or not), the more people we'll reach.
Let's not try to self-implode like a dying star here...
Diversity is cool and necessary to evolve. Besides, wasn't experimentation one of the initial goals of Squeak?!
Gentlemen, at your browsers. Let's not waste our time on details and let's flood the world with Smalltalk...
My 2 cents
----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
Because the way of Smalltalk is a image in chicken and egg cycle and any image comes from previous one, mutating in the process.
Dear Edgar,
That is precisely the problem.
How many chickens lay their eggs while crossing the road. Chickens normally sit down to lay their eggs.
How many eggs hatch while rolling down the hill? Normally they are stationary, if not the new chick is going to get dizzy with confusion.
And Smalltalk is about objects and not about scripting.
One person (a bottleneck) incrementally adding things to an image is easy, and inevitably the image grows.
Modularizing and refactoring an image made up of interdependent parts is harder it takes foresight and planning.
We want to empower everyone to contribute to parts of the core image in parallel. When I work on a task (like refactoring SourceFiles for example) I don't know how long it is going to take. What are the chances of my efforts being ready at precisely the time that the release team is ready to use my effort? Basically virtually zero.
So... if I can continuously integrate my work into a public (or private to me) "unstable" release, I get to receive potential feedback as early as possible ("fail fast = learn fast").
One other thing, when one person is incrementally tweaking the image that everyone is relying upon there is a lot of pressure to be perfect. This is really "not fun", it is usually quite painful (don't you know that feeling?) This alone is perhaps responsible for the painfully slow release cycle that squeak has had over the past few years.
In the past a new module like Rio would have to be perfect before getting into an image, and even then it might take 2 or more years to gain acceptance. Dare I mention Namespaces?
With this scripting approach we have a platform in which non perfect contributions can be included in the unstable releases. You dont have to wait for the release team to buy into your idea, you can throw it into the unstable release, and get it seen. Then when the release team decides not to include it you can still load your "task" if you want to, and make it available to others. The basic release can be shipped including "the unstable tasks" that you can apply if you want to. This releases unstable tasks are the next releases potential stable ones.
We then have scope for planning the movement of unstable contributions to stable ones. For some of us, we really produce our best work when we are working in a team. But for most of us we are coding in squeak on our own. The tools can facilitate the not yet perfect packages reaching others who might form a team effort to knock them into shape. Matthew and I have been doing this with Monticello15 for the past year, and it works really well, with a well defined module. This can be extended to the core with help from scripting and tools.
If we improve the tools with atomic loading where things can be loaded and unloaded (more) easily we can tackle the core image where it was harder to do before and free everyone from the tyrany of perfectionism.
Did your hero Pavel not achieve the kernel image through Scripting? I think so!
regards
Keith
On 07/12/2008, at 03:41, Keith Hodges wrote:
Did your hero Pavel not achieve the kernel image through Scripting? I think so!
Pavel magic was made a modern mammal from a dinosaur. The point is. I have one of this egss , no matter if he made thousands or how he do this egss. I go away, as now this is de-facto Pharo list. Stay on Board as some should elected me thinking was for Squeak good.
Long life and prosper, Pharo people!
Edgar
Edgar J. De Cleene wrote:
I go away, as now this is de-facto Pharo list.
It is not. As a matter of fact I think that since the Etoy-Haters have now found a place they can call home there just may be a chance to get Squeak back to where it always belonged.
Cheers, - Andreas
El 12/7/08 7:09 AM, "Andreas Raab" andreas.raab@gmx.de escribió:
It is not. As a matter of fact I think that since the Etoy-Haters have now found a place they can call home there just may be a chance to get Squeak back to where it always belonged.
Cheers,
- Andreas
Andreas, you should take the challenge now. Nobody could say you don't know Squeak in deep as they could say to me.
I tired of no progress, only read about ideas but no evidence of going in the good direction.
The last good Squeak release with wide consensus was 3.8
Then come people who for his own (maybe good) purposes introduce Traits. You always said and I support still no evidence Traits give us some we don't could made with good Smalltalk. And introduce the troubles. Almost all major forks is no Traits (3.8) based.
They have a good point in start to "packaging" the image and introduce Monticello as way of start to made downloadable packages.
3.9 was a pain for all, but give a way to start to download packages and load again.
That's was 3.10, and we don't move more out because we wish play safe.
The goal for me is going to MorphicCore Pavel made.
But as MorphicCore exist today, don't run and is only for study (sorry Pavel)
I always said the most long shot is Spoon or whatever we call it.
But if nobody take the trouble to see how to go from existent Monticello and current image to smaller and modular, never we could reach any of it.
I do my best, sometimes good and sometimes bad.
Try to help newbies and try to keep as fun as possible.
Who think Web 2.0 is incompatible with "old Squeak" was wrong.
I put SLWeb on ftp as soon I test and prove any could load Etoys , mp3 and all web we have now (Aida - Seaside - HV2) on top of SqueakLightII.
Scripting people always could script it if they wish.
Edgar
Hi Edgar,
On Sun, Dec 7, 2008 at 12:57 PM, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
The last good Squeak release with wide consensus was 3.8
what's "good"? (Rhetoric question. *Please* don't answer. I *think* I get your point.)
About consensus: oh please, that's frankly not possible. Once a certain critical mass in community participation has been reached, it is almost inevitably the case that there are digressions, branches, and so on.
Then come people who for his own (maybe good) purposes introduce Traits. You always said and I support still no evidence Traits give us some we don't could made with good Smalltalk. And introduce the troubles.
I agree that traits should have been optional. That said, I recently made ContextS work in Squeak 3.10, and yon traits weren't painful. Then again, maybe I just didn't have to touch the "right" places...
Best,
Michael
Edgar,
The whole ethos behind 3.11 is to provide a framework for people to contribute.
If we get that right progress is assured. I admit I myself have had some hiccups, I have had domestic problems, and lots of deadlines in my day job. BUT, in a framework where people are encouraged and enabled to contribute that shouldn't matter.
PROGRESS HAS CONTINUALLY BEEN MADE by someone somewhere, its just a matter of harnessing it.
I am left with a huge sense of irony, given that the whole ethos behind 3.11 is to provide a framework for people to contribute:
Irony no. 1, the entire Pharo team create a fork. Benefit, Pharo guys get to do R&D for us to "acquire" later, iff we can persuade them to be co-operative (i.e. use similar tools and apis)
Irony no. 2 -
I have tried and tried and tried, to encourage you, ask you persuade you, to bring your expertise and contribute, but you will not. You absolutely refuse.
You have expertise in unloading bits of squeak into separate packages. I hate grovelling around looking for obsolete references. You have already done the work. All that needs to happen is to package your work into discrete #unload tasks, and Sake/Packages &/ Universes load tasks
If a project whose goal is to encourage people to contribute cannot get people to contribute then it is doomed from the start.
Andreas, you should take the challenge now. Nobody could say you don't know Squeak in deep as they could say to me.
I tired of no progress,
I am fed up with you saying there is no progress. I do paid work in squeak, and from that perspective there has been LOTS of progress. In some ways Squeak was painful to use for commercial work. I used to dread building up an image from scratch for a new client project, and it was impossible to code several client projects simultaneously in one image (due to MC bugs). I am approaching the point where I can code all of my client projects in one image, and automatically deploy to separate images for each client.
Things are getting much better than they were a year ago and as soon as "Bob the Builder" is ready there will be a whole lot more progress.
LevelPlayingField - is a huge bonus Monticello - 100's of fixes, huge speed improvements, Files support (I announced yesterday) Sake/Packages - Actually does work Sake - Simple but ultimately very powerful. Tasks - Framework for organising 3.11 Pharo - R&D for Squeak 3.1x FunSqueak - R&D for Sake/Packages SqueakLightII - R&D for Squeak3.1x
only read about ideas but no evidence of going in the good direction.
But Edgar you have decided in advance not to be interested. You take one look at the fact I embed small scripts in Mantis bug reports and you refuse to contribute even there. You have never contributed one script. Have you ever loaded a fix using Installer mantis ensureFix: 474 ? It is actually very useful.
You tell me that all these guru people should be listened to, at the same time you tell me I am not worth listening to. I have been coding for 32 years, you never know I might know something after all, you might learn something. Sorry I am not a professor in an academic ivory tower, I am a pragmatic programmer, and for me perfectionism gives way to pragmatism.
This means that I appreciate the need for TEAM, I cannot do it on my own. Matthew has been a huge help to me, dotting i's and crossing t's. I wrote the code for atomic loading in Monticello 1.6 in December 2007. Colin wrote the code for SystemEditor long before that. It is Matthew who has had the patience to get SystemEditor to work as required through painstakingly careful testing. So the irony no.1 is that many potential team members have gone off to pharo, the irony number 2 is that other potential team members are hankering after the same old way of doing things and have dug their heals in.
Sure I might be wrong, and if I am, I would be happy to be shown a better way. For 3 years the community has talked about a better way would be led by improved tools, and greater modularity. Meanwhile release teams have soldiered on declaring that "We are not going to develop anything, just integrate what the community gives us". The community has lacked the tools to give the release teams what they were asking for. The lead time for a new bit of code to get into the image is probably on average 3 years in a good year.
3.11 might look a bit slow of the mark, and I have my fair share of excuses. BUT we are actually coding stuff, and coding stuff takes a bit more time than cherry picking code that is already out there.
To be honest, all of my code works in 3.7, so from the pragmatic perspective, the huge efforts put in by 3.8 3.9 and 3.10 teams to give us incremental changes has not really been that radical, or even useful. So from a pragmatic sense if 3.11 follows the same... "One person load a few fixes and release an image" ethos, it is valueless to me.
At one point the Board/Oversight Team/Leaders(?) recognized this, and felt that the effort was better spent on something radically new (i.e. Spoon). I campaigned for 3.11 to go ahead because I knew we had a lot to harness that would be really useful, and would be potentially be lost if we didn't do it, not because I wanted 50 more random fixes in my image.
In contrast the ... "harness lots of creativity from lots of people, and enable as much stuff to work as possible for everyone" ethos behind 3.11 will give me benefits, it will, and already has given me lots more things to play with.
It is well known that technical projects never fail due to technical reasons. Politics is always the make or break of any software, and I dont do politics, I cant see much point in tact or diplomacy. If we fail to make progress, I will blame the politicians.
Now you are on the board Edgar, that makes you a politician.
The last good Squeak release with wide consensus was 3.8
Which is a fact of life
Then come people who for his own (maybe good) purposes introduce Traits. You always said and I support still no evidence Traits give us some we don't could made with good Smalltalk. And introduce the troubles. Almost all major forks is no Traits (3.8) based.
And Matthew has done the work to make this a non-issue.
But if nobody take the trouble to see how to go from existent Monticello and current image to smaller and modular, never we could reach any of it.
Perhaps I should change my name to "Nobody"
I do my best, sometimes good and sometimes bad. Scripting people always could script it if they wish.
and Image tweaking people can always Image tweak if they wish. But their work is more difficult to harness and cross fertilize between forks and different sectors of the community. They have no ethos of desiring it to be possible, and no means to transact it.
In contrast the scripting side of arguement goes like this:
3.11 is generated by a series of scripted tasks, but that script is modular in such a way as to be useful to another fork, say Sophie. i.e. we actively view other forks as part of the same moving forward process. We support them, we don't leave them out on their own.
They can take a copy or a specialised subclass of the 3.11 set of tasks, and apply them to their next release.
If all the forks, apply their core improvements via a common set of tasks, and packages. And if all the forks use a common set of tools to organise their work. Then they will naturally converge where it is most important, where there is the most overlap.
There is a vision for the politicians to think about
best regards
Keith
On 07/12/2008, at 10:29, Keith Hodges wrote:
Now you are on the board Edgar, that makes you a politician.
Ja ! Am I wrong think you don't have fun !
Me politics ? Saying yes to nonsense ?
It's the best joke of this year.
I was reluctant to be on Board, remember ?
But as bad soap opera film say, until some better guy come, I do my best.
No more mails, I read The Weekly Squeak from now
Edgar
On Sun, Dec 07, 2008 at 12:18:11PM -0300, Edgar J. De Cleene wrote:
On 07/12/2008, at 10:29, Keith Hodges wrote:
Now you are on the board Edgar, that makes you a politician.
Ja ! Am I wrong think you don't have fun !
Me politics ? Saying yes to nonsense ?
It's the best joke of this year.
I was reluctant to be on Board, remember ?
But as bad soap opera film say, until some better guy come, I do my best.
If you don't want to be on the board, then resign and let me. I think I'm the next candidate by votes
On 07.12.2008, at 14:29, Keith Hodges wrote:
Edgar,
The whole ethos behind 3.11 is to provide a framework for people to contribute.
If we get that right progress is assured. I admit I myself have had some hiccups, I have had domestic problems, and lots of deadlines in my day job. BUT, in a framework where people are encouraged and enabled to contribute that shouldn't matter.
PROGRESS HAS CONTINUALLY BEEN MADE by someone somewhere, its just a matter of harnessing it.
I am left with a huge sense of irony, given that the whole ethos behind 3.11 is to provide a framework for people to contribute:
Irony no. 1, the entire Pharo team create a fork. Benefit, Pharo guys get to do R&D for us to "acquire" later, iff we can persuade them to be co-operative (i.e. use similar tools and apis)
Irony no. 2 -
I have tried and tried and tried, to encourage you, ask you persuade you, to bring your expertise and contribute, but you will not. You absolutely refuse.
You have expertise in unloading bits of squeak into separate packages. I hate grovelling around looking for obsolete references. You have already done the work. All that needs to happen is to package your work into discrete #unload tasks, and Sake/Packages &/ Universes load tasks
If a project whose goal is to encourage people to contribute cannot get people to contribute then it is doomed from the start.
Andreas, you should take the challenge now. Nobody could say you don't know Squeak in deep as they could say to me.
I tired of no progress,
I am fed up with you saying there is no progress. I do paid work in squeak, and from that perspective there has been LOTS of progress. In some ways Squeak was painful to use for commercial work. I used to dread building up an image from scratch for a new client project, and it was impossible to code several client projects simultaneously in one image (due to MC bugs). I am approaching the point where I can code all of my client projects in one image, and automatically deploy to separate images for each client.
Things are getting much better than they were a year ago and as soon as "Bob the Builder" is ready there will be a whole lot more progress.
LevelPlayingField - is a huge bonus Monticello - 100's of fixes, huge speed improvements, Files support (I announced yesterday) Sake/Packages - Actually does work Sake - Simple but ultimately very powerful. Tasks - Framework for organising 3.11 Pharo - R&D for Squeak 3.1x FunSqueak - R&D for Sake/Packages SqueakLightII - R&D for Squeak3.1x
only read about ideas but no evidence of going in the good direction.
But Edgar you have decided in advance not to be interested. You take one look at the fact I embed small scripts in Mantis bug reports and you refuse to contribute even there. You have never contributed one script. Have you ever loaded a fix using Installer mantis ensureFix: 474 ? It is actually very useful.
You tell me that all these guru people should be listened to, at the same time you tell me I am not worth listening to. I have been coding for 32 years, you never know I might know something after all, you might learn something. Sorry I am not a professor in an academic ivory tower, I am a pragmatic programmer, and for me perfectionism gives way to pragmatism.
This means that I appreciate the need for TEAM, I cannot do it on my own. Matthew has been a huge help to me, dotting i's and crossing t's. I wrote the code for atomic loading in Monticello 1.6 in December 2007. Colin wrote the code for SystemEditor long before that. It is Matthew who has had the patience to get SystemEditor to work as required through painstakingly careful testing. So the irony no.1 is that many potential team members have gone off to pharo, the irony number 2 is that other potential team members are hankering after the same old way of doing things and have dug their heals in.
Sure I might be wrong, and if I am, I would be happy to be shown a better way. For 3 years the community has talked about a better way would be led by improved tools, and greater modularity. Meanwhile release teams have soldiered on declaring that "We are not going to develop anything, just integrate what the community gives us". The community has lacked the tools to give the release teams what they were asking for. The lead time for a new bit of code to get into the image is probably on average 3 years in a good year.
3.11 might look a bit slow of the mark, and I have my fair share of excuses. BUT we are actually coding stuff, and coding stuff takes a bit more time than cherry picking code that is already out there.
To be honest, all of my code works in 3.7, so from the pragmatic perspective, the huge efforts put in by 3.8 3.9 and 3.10 teams to give us incremental changes has not really been that radical, or even useful. So from a pragmatic sense if 3.11 follows the same... "One person load a few fixes and release an image" ethos, it is valueless to me.
At one point the Board/Oversight Team/Leaders(?) recognized this, and felt that the effort was better spent on something radically new (i.e. Spoon). I campaigned for 3.11 to go ahead because I knew we had a lot to harness that would be really useful, and would be potentially be lost if we didn't do it, not because I wanted 50 more random fixes in my image.
In contrast the ... "harness lots of creativity from lots of people, and enable as much stuff to work as possible for everyone" ethos behind 3.11 will give me benefits, it will, and already has given me lots more things to play with.
It is well known that technical projects never fail due to technical reasons. Politics is always the make or break of any software, and I dont do politics, I cant see much point in tact or diplomacy. If we fail to make progress, I will blame the politicians.
Now you are on the board Edgar, that makes you a politician.
The last good Squeak release with wide consensus was 3.8
Which is a fact of life
Then come people who for his own (maybe good) purposes introduce Traits. You always said and I support still no evidence Traits give us some we don't could made with good Smalltalk. And introduce the troubles. Almost all major forks is no Traits (3.8) based.
And Matthew has done the work to make this a non-issue.
But if nobody take the trouble to see how to go from existent Monticello and current image to smaller and modular, never we could reach any of it.
Perhaps I should change my name to "Nobody"
I do my best, sometimes good and sometimes bad. Scripting people always could script it if they wish.
and Image tweaking people can always Image tweak if they wish. But their work is more difficult to harness and cross fertilize between forks and different sectors of the community. They have no ethos of desiring it to be possible, and no means to transact it.
If you mean the Etoys image with that comment - we simply chose the most efficient way for us to deliver. We were 5 people, most of them not even working full-time on Etoys. We have an installed user base of at least 500,000. We have to be careful about backwards compatibility. Doing this while trying to keep in sync through 3.9, 3.10, etc., would frankly have put the whole project in jeopardy. OTOH we tried to break out the separable functionality so it can be used in other projects - e.g., the DBus support, GStreamer support, which are maintained as Monticello packages.
I for one would love to see Etoys being maintained in sync with (or even inside) the squeak.org version, and now that the pace of development has slowed down on the Etoys side this might even be feasible. However, since Etoys never was a community-driven scratch- your-own-itch project, somebody would have to come forward declaring it his own itch (like Marcus and Michael did in 3.8). Recently I've only seen Edgar express interest in that direction.
In contrast the scripting side of arguement goes like this:
3.11 is generated by a series of scripted tasks, but that script is modular in such a way as to be useful to another fork, say Sophie. i.e. we actively view other forks as part of the same moving forward process. We support them, we don't leave them out on their own.
They can take a copy or a specialised subclass of the 3.11 set of tasks, and apply them to their next release.
If all the forks, apply their core improvements via a common set of tasks, and packages. And if all the forks use a common set of tools to organise their work. Then they will naturally converge where it is most important, where there is the most overlap.
There is a vision for the politicians to think about
best regards
Keith
I like your vision, and the progress you are making :)
- Bert -
Scripting people always could script it if they wish.
and Image tweaking people can always Image tweak if they wish. But their work is more difficult to harness and cross fertilize between forks and different sectors of the community. They have no ethos of desiring it to be possible, and no means to transact it.
If you mean the Etoys image with that comment - we simply chose the most efficient way for
Not at all, "image tweaking" is the standard way of doing things, and it is the most efficient way of developing an end product. No pesky scm, packaging and module distribution issues.
All release teams, pharo, edgar etoys, croquet, etc have been moving forward by imcrementally changing the image. (Sophie had a build process, as does Gjallar)
All 3.11 aims to do differently is to increment the image in larger discrete (but not two big) crafted steps, that forks can potentially share.
us to deliver. We were 5 people, most of them not even working full-time on Etoys. We have an installed user base of at least 500,000. We have to be careful about backwards compatibility. Doing this while trying to keep in sync through 3.9, 3.10, etc., would frankly have put the whole project in jeopardy.
Quite right. That illustrates my point, working with a moving target is not easy, and not desirable.
OTOH we tried to break out the separable functionality so it can be used in other projects - e.g., the DBus support, GStreamer support, which are maintained as Monticello packages.
I for one would love to see Etoys being maintained in sync with (or even inside) the squeak.org version, and now that the pace of development has slowed down on the Etoys side this might even be feasible. However, since Etoys never was a community-driven scratch-your-own-itch project, somebody would have to come forward declaring it his own itch (like Marcus and Michael did in 3.8). Recently I've only seen Edgar express interest in that direction.
That's why it is such a shame that Edgar will not come out and play today, and believe me I have tried.
I like your vision, and the progress you are making :)
Thanks... I trust we can pull this off.
Keith
p.s. Rob - I do seaside mostly, and interfacing to business accounts.
On Sun, Dec 7, 2008 at 1:05 PM, Keith Hodges keith_hodges@yahoo.co.ukwrote:
p.s. Rob - I do seaside mostly, and interfacing to business accounts.
Thanks...good to know people are out there having success with Squeak!
Take care,
Rob
Keith Hodges wrote:
Sorry to interfere with this, but this statement is puzzling me:
Not at all, "image tweaking" is the standard way of doing things, and it is the most efficient way of developing an end product. No pesky scm, packaging and module distribution issues.
How do you deliver the end product then? I hope not a stripped developer image? :)
Claus Kick wrote:
Keith Hodges wrote:
Sorry to interfere with this, but this statement is puzzling me:
Not at all, "image tweaking" is the standard way of doing things, and it is the most efficient way of developing an end product. No pesky scm, packaging and module distribution issues.
How do you deliver the end product then? I hope not a stripped developer image? :)
For details - http://installer.pbwiki.com/Squeak311Proposal
The build process produces a "test-candidate" image.
The "test-candidate" is processed into a "release-candidate" image via:
1) All packages are saved to the monticello repository 2) some tools used in building may be removed 3) version is updated.
The release, the basic image will be fairly functional, elements that are optional will be easily unloaded. i.e. rather than produce a minimal image that can be built into a basic image, we will produce a basic image that can be reduced to a minimal image using Sake/Packages unload tasks, after which Sake/Packages itself can be unloaded. Rather than produce an image in which traits are loadable (this would prevent the core from using traits), we will have an image in which traits are removable/flattenable.
Derivative images, automatically built from release-basic
1. -test - basic with tests loaded 2. -minimal - basic with all removable packages removed, including LPF, Sake, Installer etc. 3. -kernel - Pavel's shrink script applied perhaps? 4. -full/fun - (fun squeak? Edgar?) 5. -dev - Squeak-dev (Damien is moving over to use Sake/Packages to build) 6. -web - Squeak-web 7. -dev-beta - Squeak-dev beta 8. -web-beta - Squeak-web beta 9. -seaside - The seaside one-click-experience 10. -seaside-magma-pier-magritte-scriptaculous - The basis of my own work 11. -morphic3 experimental platform
ambitious do you think?
Keith
2008/12/7 Andreas Raab andreas.raab@gmx.de:
Edgar J. De Cleene wrote:
I go away, as now this is de-facto Pharo list.
It is not. As a matter of fact I think that since the Etoy-Haters have now found a place they can call home there just may be a chance to get Squeak back to where it always belonged.
One people hate Etoys, others hate Traits. :)
Then lets declare 3.8 a best software ever made and leave things as they is. Since 3.8 is perfect, then any contribution made past 3.8 and any will be made in future should be rejected because you can't improve what is already perfect, right? :) Let's then stop discussing how to improve things - because it is pointless.
There's only one thing which makes me uncomfortable: any organism which can't evolve and can't react to ever-changing environment adequately is doomed to become extinct.
Cheers,
- Andreas
Igor Stasenko wrote:
One people hate Etoys, others hate Traits. :)
Then lets declare 3.8 a best software ever made and leave things as they is.
How exactly are these two statements related? Why does a dislike for traits imply that 3.8 is perfect?
Since 3.8 is perfect, then any contribution made past 3.8 and any will be made in future should be rejected because you can't improve what is already perfect, right? :) Let's then stop discussing how to improve things - because it is pointless.
Is there any point to this rhetoric? If so I fail to see it.
There's only one thing which makes me uncomfortable: any organism which can't evolve and can't react to ever-changing environment adequately is doomed to become extinct.
And your point is...? You are the first person to propose stopping to improve Squeak. Since I know this isn't your goal I can only guess that you were trying to make some other point which I'm not getting.
Cheers, - Andreas
2008/12/7 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
One people hate Etoys, others hate Traits. :)
Then lets declare 3.8 a best software ever made and leave things as they is.
How exactly are these two statements related? Why does a dislike for traits imply that 3.8 is perfect?
i refer to Edgar's comment about 3.8 and what is gone 'wrong' after it.
Since 3.8 is perfect, then any contribution made past 3.8 and any will be made in future should be rejected because you can't improve what is already perfect, right? :) Let's then stop discussing how to improve things - because it is pointless.
Is there any point to this rhetoric? If so I fail to see it.
There's only one thing which makes me uncomfortable: any organism which can't evolve and can't react to ever-changing environment adequately is doomed to become extinct.
And your point is...? You are the first person to propose stopping to improve Squeak. Since I know this isn't your goal I can only guess that you were trying to make some other point which I'm not getting.
My point :
Is it RIGHT to not do anything , because there is always someone who will be discontented with it?
Cheers,
- Andreas
Igor Stasenko wrote:
2008/12/7 Andreas Raab andreas.raab@gmx.de:
How exactly are these two statements related? Why does a dislike for traits imply that 3.8 is perfect?
i refer to Edgar's comment about 3.8 and what is gone 'wrong' after it.
I re-read Edgar's comments again but I still don't see anything in them that could be construed as framing 3.8 as perfect or denying progress. Edgar points out (correctly) that 3.8 was the last release that had wide consensus, he points out (again correctly) that many of the major forks are 3.8 based. He then goes on saying that 3.9 was "pain for all" and concludes by pointing out that 3.10 release team was trying to play it safe. All of it seems to be quite accurate from what I can tell.
My point :
Is it RIGHT to not do anything , because there is always someone who will be discontented with it?
Of course not. That is so obvious it doesn't even bear mentioning. But then again, has that ever happened? Or is that likely to happen? We have seen constant improvements in Squeak, mostly non-controversial and in my experience, the situations where you find great resistance are almost exclusively those where one side is absolutely unwilling to adopt to concerns and push things with pseudo justifications like "this is for your own benefit". If it were, you wouldn't have to force people to use it - you would make it accessible so that people have the option and then, when its value is established, you can come back and make a real case why it should be included by default. This is how the process should have gone with traits.
Cheers, - Andreas
We have seen constant improvements in Squeak, mostly non-controversial and in my experience, the situations where you find great resistance are almost exclusively those where one side is absolutely unwilling to adopt to concerns and push things with pseudo justifications like "this is for your own benefit". If it were, you wouldn't have to force people to use it - you would make it accessible so that people have the option and then, when its value is established, you can come back and make a real case why it should be included by default. This is how the process should have gone with traits.
yes.
would it have happened this way, the people implementing traits may have noticed that a lot of people did not use them simply because the tools were not there. IMO the job has been left unfinished, and with the traits team moving to Pharo we seem to be left with yet another leftover mostly useless cruft in Squeak, which is the kind of thing these same people have been creating Pharo to get rid of. how sadly ironic. it seems to me that a lot of time, energy and good-willingness from all sides has just been wasted.
Stef
On 07.12.2008, at 16:33, Igor Stasenko wrote:
2008/12/7 Andreas Raab andreas.raab@gmx.de:
Edgar J. De Cleene wrote:
I go away, as now this is de-facto Pharo list.
It is not. As a matter of fact I think that since the Etoy-Haters have now found a place they can call home there just may be a chance to get Squeak back to where it always belonged.
One people hate Etoys, others hate Traits. :)
Traits are actually quite cool. I think people do not hate Traits but just object to the way they were added to the system. A similar objection applies to how Etoys is intertwined with Morphic, so I'd think people don't actually hate Etoys but just that it cannot cleanly be removed without severe breakage.
- Bert -
On 7-Dec-2008, at 5:16 PM, Bert Freudenberg wrote:
Traits are actually quite cool.
Traits may be cool, and/or they may just be a fad like I think Aspect Oriented Programming is.
However from what I can tell so far Traits are not really Smalltalk-80 at all.
I Squeak still supposed to be Smalltalk-80? Is it supposed to be Smalltalk + Traits? Is it supposed to be a standards-compatible Smalltalk? What is Squeak? Who definitively can answer that these days?
I think people do not hate Traits but just object to the way they were added to the system.
From what I know at this moment I personally think trying to include Traits in the core basic image, and especially any attempt to make use of them in the basic core image, is fine just so long as you call the result something other than Smalltalk-80.
I do not yet know how Traits have been introduced into Smalltalk, but it is my very strong impression that the result is not compatible with strict Smalltalk-80.
At this point I (naively) think Smalltalk with Traits _must_ be a fork and it _must_ be called something else. I may be very wrong, and I may be starting from the wrong impressions, but that's where my understanding takes me to right now.
So, in that sense, I think I would object to the fact they were added to the system, not just the way they were added to the system.
I personally would really like Squeak to be a strong, viable, Smalltalk-80 implementation with full standards compatibility and with a good strong community which provides add-ons, extensions, and such as additional packages. Perhaps for a poor analogy, Squeak should be the equivalent of the Linux kernel in GNU/Linux systems, thus allowing for variant distributions which might ship ready-to-run images which contain specific sets of pre-loaded packages and modifications, but which hopefully all derive from the same core image and VM. A slightly better analogy might be the full NetBSD (or FreeBSD) core OS. It's a full base operating system (not just a kernel), but there are thousands of additional add-on packages available to any user. Even X11 is often considered to be just an add-on package.
Traits are actually quite cool.
Traits may be cool, and/or they may just be a fad like I think Aspect Oriented Programming is.
However from what I can tell so far Traits are not really Smalltalk-80 at all.
I Squeak still supposed to be Smalltalk-80? Is it supposed to be Smalltalk + Traits? Is it supposed to be a standards-compatible Smalltalk? What is Squeak? Who definitively can answer that these days?
As far as I am aware Traits are just an implementation detail as far as Smalltalk-80 compatability is concerned. They may effect the users ability to understand existing code structure, and provide additional options for structuring code. Essentially though Traits are transparent to 99% of client code.
Keith
I personally would really like Squeak to be a strong, viable, Smalltalk-80 implementation with full standards compatibility and with a good strong community which provides add-ons, extensions, and such as additional packages.
Of course, *that* would itself be a fork. Squeak has always been about experimentation and Smalltalk-80 compatibility was more of a historical artifact than a design goal.
I'd rather have a great Smalltalk-08 (and soon -09) than something that matches up with the Blue Book description of Smalltalk-80. The reason I'm using Pharo now is that it looks like the best near term 'core' Smalltalk.
Hi Edgar,
On Sun, Dec 7, 2008 at 10:59 AM, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
I go away, as now this is de-facto Pharo list.
I absolutely don't share that impression. There are many many threads that don't deal with Pharo.
Best,
Michael
http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20081129/58... To install:
-Remove the Morphic-FileList category. -Evaluate:
FileStream fileIn: 'Morphic-FileList.st'. FileStream fileIn: 'FileListNewReferences.st'
2008/12/6 Edgar J. De Cleene edgardec2001@yahoo.com.ar
On 05/12/2008, at 22:20, Hernán Morales Durand wrote:
I merged FileList two weeks before I saw the open issue in the Pharo
issues list, as an excercise in a new automatic merging tool I'm writing. But anyone feel free to take that fix and merge it into any Squeak image.
Cheers.
Hernán
Where is the code ? So I put into SqueakLighthII , the only thing working now . 3.11 ? Vaporware....
Edgar
On 06/12/2008, at 12:10, Hernán Morales Durand wrote:
http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/ 20081129/58d8a9b3/FileList-0001.zip
To install:
-Remove the Morphic-FileList category. -Evaluate:
FileStream fileIn: 'Morphic-FileList.st'. FileStream fileIn: 'FileListNewReferences.st'
Very thanks, I add you to helpers.
Edgar
Hernán Morales Durand wrote:
Hello Keith,
2008/12/5 Keith Hodges <keith_hodges@yahoo.co.uk mailto:keith_hodges@yahoo.co.uk>
Did you know that someone in the Pharo camp recently merged FileList and FileList2. Is it just me or could that improvement be useful to everyone, whether in etoys or croquet. There is nothing in the Pharo mindset or toolset that enables this to happen by default.I merged FileList two weeks before I saw the open issue in the Pharo issues list, as an excercise in a new automatic merging tool I'm writing. But anyone feel free to take that fix and merge it into any Squeak image.
Cheers.
Hernán
Dear Hernán,
first of all I must make clear that my comment re: FileList was intended to be entirely illustrative of the attitude, not concrete to any one fix, or person.
Again using FileList as an easy example, of how to think about positioning this tool for the future.
Firstly if someone were to take FileList and make it a standalone loadable package, this would potentially contribute to every squeak varient out there.
Secondly it would need to be refactored so that its interface to FileDirectory is a separate package. So that in the future an alternative to FileDirectory could be slotted in, or images that nolonger have FileDirectory might supply their own Interface package. Perhaps the UI could be a separate package for when the OB version, or Morphic3 version is required.
As I said this is only an illustrative example.
Keith
Hi Edgar--
Hopes of many was when Dan say he wish be on Board.
Now I sit on his chair (because maybe nobody with better qualification is at hand ?).
Dan left the board because he was too busy with work and his other commitments to participate. You're on the board now because we had two open slots (Tim had also left), and you were one of the two next highest vote-getters in the last election.
-C
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
On 16/12/2008, at 04:10, Craig Latta wrote:
Hi Edgar--
Hopes of many was when Dan say he wish be on Board.
Now I sit on his chair (because maybe nobody with better
qualification
is at hand ?).
Dan left the board because he was too busy with work and hisother commitments to participate.
Too bad for us.
As I said, many have the wish Dan could bring wisdom to Squeakers again
You're on the board now because we had two open slots (Tim had also left), and you were one of the two next highest vote-getters in the last election.
So , Tim and Dan go , Giovanni and me was the next on the line :=)
Next January I hope many apply for the Board and have the energy and the charisma Squeak needs.
Edgar
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Benoit St-Jean -
Bert Freudenberg -
Claus Kick -
Craig Latta -
David Mitchell -
Edgar J. De Cleene -
Greg A. Woods; Planix, Inc. -
Herbert König -
Hernán Morales Durand -
Igor Stasenko -
Keith Hodges -
Matthew Fulmer -
Michael Haupt -
Nikolay Suslov -
Rob Rothwell -
Simon Michael -
Stéphane Rollandin -
Tim Johnson