I suggest a new fork or possibly a new orientation for the next Squeak release: Adopt Cuis as the core image and focus on killer applications to attract new Smalltalk users. Thousands of downloads are recorded on CNet for simple apps like a voice recorder. They could all be using and learning Smalltalk. Same for many other applications. That would help make Smalltalk popular again.
Recently I found Squeak / Cuis contains many Sound classes. So I wrote up an email suggesting it to a community college teacher friend who had asked for a sound recorder. Imagine my embarrassment when I found the files Squeak supports doesn't include .mp3.
Squeak has so much unfinished half starts at programs, why not adopt Juan's work to flush the unnecessary, then get started on building a serious applications team to build truly useful free code.
Another example, Roxio is a million dollar software company making a video recorder app. which is not as good as an ordinary VCR and not supported (they have a staff but try getting any real help). Squeak could be capturing a slice of that market and enticing users to learn Smalltalk! And source code can substitute for most support.
Another example, Solid Works is a 3D object drafting program that is simple and gets many thousands of users away from AutoDesk. Can Smalltalk deliver most or all of that function with a FFI to openGL and some programming? Certianly!
Finally, the one complaint I've heard on the job about Smalltalk is it's slow. I recently added several thousand classes and find simply clicking on the class in a browser is now slow to respond. When end-users, not programmers, can type at 80 words a minute and more in a C app. or they can be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM was a good improvement, now try to solve the speed issues in the image.
Thanks, Kirk Fraser
Cuis is a good partial solution. So is Craig Latta's Spoon.
Better will be developing a GOOD IPC strategy so that we can spawn dedicated images from Cuis that contain only the code necessary to run a task in its own process, using Spoon to cull the unneeded classes.
L.
On 9/7/11 9:52 AM, Overcomer Man wrote:
I suggest a new fork or possibly a new orientation for the next Squeak release: Adopt Cuis as the core image and focus on killer applications to attract new Smalltalk users. Thousands of downloads are recorded on CNet for simple apps like a voice recorder. They could all be using and learning Smalltalk. Same for many other applications. That would help make Smalltalk popular again. Recently I found Squeak / Cuis contains many Sound classes. So I wrote up an email suggesting it to a community college teacher friend who had asked for a sound recorder. Imagine my embarrassment when I found the files Squeak supports doesn't include .mp3. Squeak has so much unfinished half starts at programs, why not adopt Juan's work to flush the unnecessary, then get started on building a serious applications team to build truly useful free code. Another example, Roxio is a million dollar software company making a video recorder app. which is not as good as an ordinary VCR and not supported (they have a staff but try getting any real help). Squeak could be capturing a slice of that market and enticing users to learn Smalltalk! And source code can substitute for most support. Another example, Solid Works is a 3D object drafting program that is simple and gets many thousands of users away from AutoDesk. Can Smalltalk deliver most or all of that function with a FFI to openGL and some programming? Certianly! Finally, the one complaint I've heard on the job about Smalltalk is it's slow. I recently added several thousand classes and find simply clicking on the class in a browser is now slow to respond. When end-users, not programmers, can type at 80 words a minute and more in a C app. or they can be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM was a good improvement, now try to solve the speed issues in the image. Thanks, Kirk Fraser
Inline below.
On Wed, Sep 7, 2011 at 9:52 AM, Overcomer Man overcomer.man@gmail.comwrote:
I suggest a new fork
-1
or possibly a new orientation for the next Squeak release: Adopt Cuis as the core image and focus on killer applications to attract new Smalltalk users.
+1. If I was allowed to do +100, you'd have that in a heartbeat:)
Thousands of downloads are recorded on CNet for simple apps like a voice recorder. They could all be using and learning Smalltalk. Same for many other applications. That would help make Smalltalk popular again.
:D I like the way you think!
Recently I found Squeak / Cuis contains many Sound classes. So I wrote up an email suggesting it to a community college teacher friend who had asked for a sound recorder. Imagine my embarrassment when I found the files Squeak supports doesn't include .mp3.
Juan, I think it's time to bring out your synth, my friend! So .mp3 isn't necessarily a deal breaker. MPEG should be convertible to WAV, but FWIW, you're right. Squeak needs a Winamp/XMMS killer. Between this, and a standards-complient web browser (read: nightmarish rabbit-hole) I can practically ditch my operating system and live in Squeakland all the time. Wouldn't that be *radical?*
Squeak has so much unfinished half starts at programs, why not adopt Juan's work to flush the unnecessary, then get started on building a serious applications team to build truly useful free code.
Worth pointing out: applications which use Morphic will take real work to make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, lean, beautiful, and completely different from the tangle which many applications expect to find down there.
Another example, Roxio is a million dollar software company making a video recorder app. which is not as good as an ordinary VCR and not supported (they have a staff but try getting any real help). Squeak could be capturing a slice of that market and enticing users to learn Smalltalk! And source code can substitute for most support.
Yes! Redhat sells an open source operating system. We have an operating system that's actually pretty! Why not Mousehat or something (obviously I'm not from marketing)? I dig the entrepreneurial angle, Overcomer Man. I've been thinking about this stuff for years. I dream of a BSD kernel and nothing else but drivers and Squeak. Web browser is still an issue, but it's no problem money can't solve.
Another example, Solid Works is a 3D object drafting program that is simple and gets many thousands of users away from AutoDesk. Can Smalltalk deliver most or all of that function with a FFI to openGL and some programming? Certianly!
Have you played with OpenQwaq? It has tools that do some of this stuff in a very natural way. If we can make these parts loadable packages, the whole GPL thing becomes a non-issue for end users. Can't go into the core system, but as a loadable package, everybody wins. I want to see what we can do with a Cintiq graphics tablet, build ourselves a Robot Draftsman. Long live Sketchpad!
Finally, the one complaint I've heard on the job about Smalltalk is it's slow.
Eh... Smalltalk invented fast. Smalltalk's little sister, Self, invented *very fast*. JIT and polymorphic inline caches make this a virtual non-issue. And you can optimize for whatever you want because you control the vertical, you control the horizontal. See also, L Peter Deutsch, David Ungar, Eliot Miranda.
We have a fast VM now. This is a non-issue.
I recently added several thousand classes and find simply clicking on the
class in a browser is now slow to respond.
Hmm. Have you tried using the performance spy to figure out where the bottleneck is? Generally, most programs spend 80% of their time in 20% of their code. A Pareto relationship. There is likely something running which is sending more messages than it needs to be.
How big is that image file, out of curiosity?
When end-users, not programmers, can type at 80 words a minute and more in a C app. or they can be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM was a good improvement, now try to solve the speed issues in the image.
Sure, I mean. Cuis?
Thanks, Kirk Fraser
Kirk, I really enjoyed your spirited comments. While I *do* think you have some great ideas for new apps, I personally think the best plan is to throw in on making the apps that Smalltalk programmers presently care a great deal for (e.g., Seaside) run atop Cuis. This will take a concerted effort.
Cuis is a lovely little system. I find it the most broadly usable Smalltalk -- certainly better looking than any other (antialiasing goes a long way with rounded window corners, thanks again Juan) -- and I would love so see someone experiment with the combination of Spoon and Cuis (to address Lawson's point.)
Craig, if I wanted to try to Spoon-out Cuis, where would I start?
On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Inline below.
On Wed, Sep 7, 2011 at 9:52 AM, Overcomer Man overcomer.man@gmail.com wrote:
I suggest a new fork
[snip]
:D I like the way you think!
Recently I found Squeak / Cuis contains many Sound classes. So I wrote up an email suggesting it to a community college teacher friend who had asked for a sound recorder. Imagine my embarrassment when I found the files Squeak supports doesn't include .mp3.
Juan, I think it's time to bring out your synth, my friend! So .mp3 isn't necessarily a deal breaker. MPEG should be convertible to WAV, but FWIW, you're right. Squeak needs a Winamp/XMMS killer. Between this, and a standards-complient web browser (read: nightmarish rabbit-hole) I can practically ditch my operating system and live in Squeakland all the time. Wouldn't that be *radical?*
That is exactly what I want for OSP, the Squeak desktop *IS* the desktop.
Squeak has so much unfinished half starts at programs, why not adopt Juan's work to flush the unnecessary, then get started on building a serious applications team to build truly useful free code.
Worth pointing out: applications which use Morphic will take real work to make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, lean, beautiful, and completely different from the tangle which many applications expect to find down there.
Not sure how to interpret this. Morphic is key to OSP, as it is to OLPC. Are you saying that Morphic will not run on Cuis without modification, but should it be ported the underlying system is fast and lean?
Another example, Roxio is a million dollar software company making a video recorder app. which is not as good as an ordinary VCR and not supported (they have a staff but try getting any real help). Squeak could be capturing a slice of that market and enticing users to learn Smalltalk! And source code can substitute for most support.
Yes! Redhat sells an open source operating system. We have an operating system that's actually pretty! Why not Mousehat or something (obviously I'm not from marketing)? I dig the entrepreneurial angle, Overcomer Man. I've been thinking about this stuff for years. I dream of a BSD kernel and nothing else but drivers and Squeak. Web browser is still an issue, but it's no problem money can't solve.
Maybe implementing a window frame class that allows apps to run in a squeak window is all we need. Rather than build a web browser in Squeak, open Mozilla it in a Squeak window. Think X tunneling on the same host.
Gary Dunn wrote:
On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger casey.obrien.r@gmail.com wrote:
...
Worth pointing out: applications which use Morphic will take real work to make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, lean, beautiful, and completely different from the tangle which many applications expect to find down there.
Not sure how to interpret this. Morphic is key to OSP, as it is to OLPC. Are you saying that Morphic will not run on Cuis without modification, but should it be ported the underlying system is fast and lean?
Cuis uses Morphic. Only cleaner, simpler and faster. Why don't you try it for 15 minutes?
Cheers, Juan Vuletich
Seriously, people. TRY IT. Test it out. The differences between Morphic in Squeak/Pharo, and Cuis, are *absolutely* improvements. Juan has sloughed thousands of lines of code. I don't have to work as hard to get a thing done in Cuis, because almost *all* of the bull____ has been cleared away.
Proof of this is that I was able to do the Pareto 20% of what Polymorph did _in ONE class_. And I'm not really that clever.
It's undoubtedly the more elegant system I've ever encountered. It might even change the way you think, if you gave it a shot.
I dare you: try it.
All the love,
C:)
On Sep 7, 2011, at 5:59 PM, Juan Vuletich juan@jvuletich.org wrote:
Gary Dunn wrote:
On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger casey.obrien.r@gmail.com wrote: ...
Worth pointing out: applications which use Morphic will take real work to make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, lean, beautiful, and completely different from the tangle which many applications expect to find down there.
Not sure how to interpret this. Morphic is key to OSP, as it is to OLPC. Are you saying that Morphic will not run on Cuis without modification, but should it be ported the underlying system is fast and lean?
Cuis uses Morphic. Only cleaner, simpler and faster. Why don't you try it for 15 minutes?
Cheers, Juan Vuletich
On Wed, Sep 7, 2011 at 2:59 PM, Juan Vuletich juan@jvuletich.org wrote:
Gary Dunn wrote:
On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger casey.obrien.r@gmail.com wrote: ...
Worth pointing out: applications which use Morphic will take real work to make run over Cuis. Morphic in Cuis is a whole new breed of animal; fast, lean, beautiful, and completely different from the tangle which many applications expect to find down there.
Not sure how to interpret this. Morphic is key to OSP, as it is to OLPC. Are you saying that Morphic will not run on Cuis without modification, but should it be ported the underlying system is fast and lean?
Cuis uses Morphic. Only cleaner, simpler and faster. Why don't you try it for 15 minutes?
Cheers, Juan Vuletich
Just did. Works fine on FreeBSD 8.2, at least it starts and runs, no exhaustive testing. Right off the bat I checked to see if it would load my Morphic book project. I could not find a way to do that. Then I checked the browser to see if there is a bookmorph. I don't see one, or many of the other Morphic building blocks I use.
You can find out more about my book concept here:
http://wiki.openslate.net/mediawiki/index.php?title=Chalk_Dust_Applications:...
I agree that there is much that needs fixing in Squeak. I have made several entries in Mantis, for example how the yellow-click pop-up mouse window text formatting commands are broken. And I did try to fix that, and found a dark, confusing swamp filled with tangled code, different code for doing the same task depending on how it is initiated. I knew I was in over my head. Perhaps starting over with Cuis is a good plan. My question is, who is going to do all the work required to port all this good stuff into the new image?
When I was in college I lived for awhile in a small, run-down house with two other students. A real Animal House. One day, after a few beers, we decided the place would look a lot better if we painted it. We started in the bathroom, where the paint was really peeling. We stripped the old paint, and stopped. Nobody had the time to devote to finishing the project.
Likely your troubles are in fact with Morphic. It's the spot where the most stuff has changed. Have you tried loading up any of your missing dependencies? I've been able on occasion to get things written for Squeak working without a lot of effort Cuis, but it did take some learning about Cuis' (lovely) flavor of Morphic in order to make things work. Often times, it's just a matter of using a more idiomatic selector where the Squeak code is using (redundant) convenience methods. In other cases, it's really just that Cuis is quite different. It's almost always something to do with Morphic.
If I was you, I'd pick my way through, try to load the stuff that's missing (I often minimize the debugger when I'm loading something and I hit a missing class, that way I don't forget to go back and test it once I've loaded it up.)
If you do this and get stuck, you should post a stack trace or a description of the problem to the list. I'll be glad to help you any way that I can as time allows (though my time is currently up in the air.)
Cheers,
Casey
On Thu, Sep 8, 2011 at 3:50 PM, Gary Dunn garydunnhi@gmail.com wrote:
On Wed, Sep 7, 2011 at 2:59 PM, Juan Vuletich juan@jvuletich.org wrote:
Gary Dunn wrote:
On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger casey.obrien.r@gmail.com wrote: ...
Worth pointing out: applications which use Morphic will take real work
to
make run over Cuis. Morphic in Cuis is a whole new breed of animal;
fast,
lean, beautiful, and completely different from the tangle which many applications expect to find down there.
Not sure how to interpret this. Morphic is key to OSP, as it is to OLPC. Are you saying that Morphic will not run on Cuis without modification, but should it be ported the underlying system is fast and lean?
Cuis uses Morphic. Only cleaner, simpler and faster. Why don't you try it for 15 minutes?
Cheers, Juan Vuletich
Just did. Works fine on FreeBSD 8.2, at least it starts and runs, no exhaustive testing. Right off the bat I checked to see if it would load my Morphic book project. I could not find a way to do that. Then I checked the browser to see if there is a bookmorph. I don't see one, or many of the other Morphic building blocks I use.
You can find out more about my book concept here:
http://wiki.openslate.net/mediawiki/index.php?title=Chalk_Dust_Applications:...
I agree that there is much that needs fixing in Squeak. I have made several entries in Mantis, for example how the yellow-click pop-up mouse window text formatting commands are broken. And I did try to fix that, and found a dark, confusing swamp filled with tangled code, different code for doing the same task depending on how it is initiated. I knew I was in over my head. Perhaps starting over with Cuis is a good plan. My question is, who is going to do all the work required to port all this good stuff into the new image?
When I was in college I lived for awhile in a small, run-down house with two other students. A real Animal House. One day, after a few beers, we decided the place would look a lot better if we painted it. We started in the bathroom, where the paint was really peeling. We stripped the old paint, and stopped. Nobody had the time to devote to finishing the project.
-- Gary Dunn Honolulu
Hi Casey--
Craig, if I wanted to try to Spoon-out Cuis, where would I start?
Hm, I included the VM changes for Spoon's "dissolve" feature in Spoon 3a3, but not the object-level part. Are you still interested? I could put it somewhere for you.
thanks,
-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
On 2/18/12 5:10 PM, "Craig Latta" craig@netjam.org wrote:
Hi Casey--
Craig, if I wanted to try to Spoon-out Cuis, where would I start?
Hm, I included the VM changes for Spoon's "dissolve" feature inSpoon 3a3, but not the object-level part. Are you still interested? I could put it somewhere for you.
thanks,-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177
- 1 415 287 3547
In http://ftp.squeak.org/various_images/SqueakLight/Cuis3.1r.4.zip Is the reduced Cuis plus updates of Juan plus Network kernel of Pharo. It's 2.5 mb , clean with no Undeclared and no obsoletes. All which works is Juan Vuletich an all which not sure is mine.
Enjoy and ready to Spoon it
Edgar
In http://ftp.squeak.org/various_images/SqueakLight/Cuis3.1r.4.zip Is the reduced Cuis plus updates of Juan plus Network kernel of Pharo. It's 2.5 mb , clean with no Undeclared and no obsoletes. All which works is Juan Vuletich an all which not sure is mine.
Enjoy and ready to Spoon it
Okay, I'll give it a whirl!
thanks again,
-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
On Wed, 7 Sep 2011, Overcomer Man wrote:
I suggest a new fork or possibly a new orientation for the next Squeak release:
I guess we have too many forks already (compared to the number of active developers).
Adopt Cuis as the core image and focus on killer applications to attract new Smalltalk users.
Cuis is nice, but lacks features that are important for those killer apps (e.g. internationalization). Also throwing aways years of work (3.8, 3.9, 4.1, 4.2 and 4.3) sounds like a bad idea. We should pick good stuff from Cuis (and Pharo) instead. To make the image smaller we should do two things (in parallel): - craving (make packages unloadable, remove dependencies, split packages) - building (use Spoon to rebuild the current image)
To make this happen we have to start with writing tests, which "document" the expected behavior of the system. So when we change it, we can be sure that we didn't lose anything important.
Thousands of downloads are recorded on CNet for simple apps like a voice recorder. They could all be using and learning Smalltalk. Same for many other applications. That would help make Smalltalk popular again.
If popularity is the goal, then this is a possible path, though most users won't care about the language their software is written in.
Recently I found Squeak / Cuis contains many Sound classes. So I wrote up an email suggesting it to a community college teacher friend who had asked for a sound recorder. Imagine my embarrassment when I found the files Squeak supports doesn't include .mp3.
I guess it does (there's Mpeg3Plugin). Btw I think using PortAudio or LibVLC may have advantages over the current platform specific implementations of audio and video support.
Squeak has so much unfinished half starts at programs, why not adopt Juan's work to flush the unnecessary, then get started on building a serious applications team to build truly useful free code.
See above.
Another example, Roxio is a million dollar software company making a video recorder app. which is not as good as an ordinary VCR and not supported (they have a staff but try getting any real help). Squeak could be capturing a slice of that market and enticing users to learn Smalltalk! And source code can substitute for most support.
Another example, Solid Works is a 3D object drafting program that is simple and gets many thousands of users away from AutoDesk. Can Smalltalk deliver most or all of that function with a FFI to openGL and some programming? Certianly!
Finally, the one complaint I've heard on the job about Smalltalk is it's slow. I recently added several thousand classes and find simply clicking on the class in a browser is now slow to respond. When end-users, not
Interesting. Did you add all classes to the same class category? In that case it will be slow, but this is a unrealistic case. I'm not saying we shouldn't fix it, but it's something that has a pretty low priority.
programmers, can type at 80 words a minute and more in a C app. or they can be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM was a good improvement, now try to solve the speed issues in the image.
Are there other speed issues?
Levente
Thanks, Kirk Fraser
On 9/7/11 6:24 PM, "Levente Uzonyi" leves@elte.hu wrote:
building (use Spoon to rebuild the current image)
I think Spoon is the future, but we should take PharoKernel as next step.
Edgar
Inline.
On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 7 Sep 2011, Overcomer Man wrote:
I suggest a new fork or possibly a new orientation for the next Squeak
release:
I guess we have too many forks already (compared to the number of active developers).
+1
Adopt Cuis as the core image and focus on killer applications to attract
new Smalltalk users.
Cuis is nice, but lacks features that are important for those killer apps (e.g. internationalization). Also throwing aways years of work (3.8, 3.9, 4.1, 4.2 and 4.3) sounds like a bad idea. We should pick good stuff from Cuis (and Pharo) instead. To make the image smaller we should do two things (in parallel):
- craving (make packages unloadable, remove dependencies, split packages)
- building (use Spoon to rebuild the current image)
Yes, we should merge the best things from Squeak into Cuis, We should merge the best things from Cuis into Squeak. Until all are one.
WRT internationalization, though, I do feel that most end users don't need 20 languages they don't speak in the core system. Most users will want to use the system in a primary language. This stuff should all be available as rock-solid external packages. Not saying it isn't important, not saying that at all. If we hope to rebase Etoys on Squeak, internationalization is essential.
To make this happen we have to start with writing tests, which "document" the expected behavior of the system. So when we change it, we can be sure that we didn't lose anything important.
+1!
A living system needs a living specification, and the closest thing I know how to do to a living specification is a great suite of tests.
Let's start by merging the tests.
Thousands of downloads are recorded on CNet for simple apps like a voice
recorder. They could all be using and learning Smalltalk. Same for many other applications. That would help make Smalltalk popular again.
If popularity is the goal, then this is a possible path, though most users won't care about the language their software is written in.
Popularity, along with usability, *is* _massively_ important. Picture three clocks in your mind. For every second, Ruby gains a second. For every second, Squeak and Pharo lose two.
If we lose badly, we've wasted our time.
Recently I found Squeak / Cuis contains many Sound classes. So I wrote up
an email suggesting it to a community college teacher friend who had asked for a sound recorder. Imagine my embarrassment when I found the files Squeak supports doesn't include .mp3.
I guess it does (there's Mpeg3Plugin). Btw I think using PortAudio or LibVLC may have advantages over the current platform specific implementations of audio and video support.
Good news.
Squeak has so much unfinished half starts at programs, why not adopt Juan's
work to flush the unnecessary, then get started on building a serious applications team to build truly useful free code.
See above.
See below.
Another example, Roxio is a million dollar software company making a video
recorder app. which is not as good as an ordinary VCR and not supported (they have a staff but try getting any real help). Squeak could be capturing a slice of that market and enticing users to learn Smalltalk! And source code can substitute for most support.
Another example, Solid Works is a 3D object drafting program that is simple and gets many thousands of users away from AutoDesk. Can Smalltalk deliver most or all of that function with a FFI to openGL and some programming? Certianly!
Finally, the one complaint I've heard on the job about Smalltalk is it's slow. I recently added several thousand classes and find simply clicking on the class in a browser is now slow to respond. When end-users, not
Interesting. Did you add all classes to the same class category? In that case it will be slow, but this is a unrealistic case. I'm not saying we shouldn't fix it, but it's something that has a pretty low priority.
I have a feeling there's an obvious fix for this. He might have ended up with a dictionary larger than was optimized for. Not going to worry about it until we see a performance profile.
programmers, can type at 80 words a minute and more in a C app. or they can
be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM was a good improvement, now try to solve the speed issues in the image.
Are there other speed issues?
'Cause Levente will probably be all over that:) straight up wrecking the bad numbers with new optimized code. 'Cause he's pretty much awesome that way.
Levente
Thanks, Kirk Fraser
On Mon, Sep 12, 2011 at 9:27 AM, Ben Coman btc@openinworld.com wrote:
** Casey Ransberger wrote:
Inline.
On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi leves@elte.hu wrote:
On Wed, 7 Sep 2011, Overcomer Man wrote:
I suggest a new fork or possibly a new orientation for the next Squeak
release:
I guess we have too many forks already (compared to the number of active developers).
+1
Adopt Cuis as the core image and focus on killer applications to attract
new Smalltalk users.
Cuis is nice, but lacks features that are important for those killer apps (e.g. internationalization). Also throwing aways years of work (3.8, 3.9, 4.1, 4.2 and 4.3) sounds like a bad idea. We should pick good stuff from Cuis (and Pharo) instead. To make the image smaller we should do two things (in parallel):
- craving (make packages unloadable, remove dependencies, split packages)
- building (use Spoon to rebuild the current image)
Yes, we should merge the best things from Squeak into Cuis, We should merge the best things from Cuis into Squeak. Until all are one.
WRT internationalization, though, I do feel that most end users don't need 20 languages they don't speak in the core system. Most users will want to use the system in a primary language. This stuff should all be available as rock-solid external packages. Not saying it isn't important, not saying that at all. If we hope to rebase Etoys on Squeak, internationalization is essential.
To make this happen we have to start with writing tests, which "document" the expected behavior of the system. So when we change it, we can be sure that we didn't lose anything important.
+1!
A living system needs a living specification, and the closest thing I know how to do to a living specification is a great suite of tests.
Let's start by merging the tests.
An interesting future scenario would be a shared test repository between the various forks of Squeak, with their respective continuous integration servers outputting results to a common database. Differences in "good results " between forks should be catered for, but would highlight differences in the "specification" of each fork, which might help it to converge over time while allowing the implementations to differ.
An excellent idea!
Levente Uzonyi wrote:
On Wed, 7 Sep 2011, Overcomer Man wrote:
... Cuis is nice, but lacks features that are important for those killer apps (e.g. internationalization).
That is not needed in a kernel image. It should be in an optional package.
Also throwing aways years of work (3.8, 3.9, 4.1, 4.2 and 4.3) sounds like a bad idea.
Cuis is not Squeak 3.7. Nearly all the changes done in these years in Squeak, that belong in a kernel image, have been integrated in Cuis. For instance, I am the only guy who studied the migration of the image to Closures format in enough detail to be able to update an image without any help from Eliot. That's how seriously I take being updated to latest Squeak. I have already integrated Squeak changes up to end of August (i.e. a week ago). These will be in the next release of Cuis, and are available for anyone who asks.
Besides, as you know, quite a bit of the changes done in Squeak in the last couple of years actually came from Cuis.
We should pick good stuff from Cuis (and Pharo) instead. To make the image smaller we should do two things (in parallel):
- craving (make packages unloadable, remove dependencies, split packages)
- building (use Spoon to rebuild the current image)
Growing back the image with Spoon is much easier if you already start with a clean image, like Cuis. Same for loading packages back: half of the work is already done.
...
Cheers, Juan Vuletich
On 9/7/11 5:56 PM, Juan Vuletich wrote:
Levente Uzonyi wrote: We should pick good stuff from Cuis (and Pharo) instead.
[...]
To make the image smaller we should do two things (in parallel):
- craving (make packages unloadable, remove dependencies, split
packages)
- building (use Spoon to rebuild the current image)
Growing back the image with Spoon is much easier if you already start with a clean image, like Cuis. Same for loading packages back: half of the work is already done.
For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It would be interesting to see if Craig can use Spoon to make it even more lean.
At the other extreme, when Craig brags that he's gotten a minimalist Squeak image to run with only 1337 bytes, he's not joking. I loaded it into a programming text editor (BBEdit) and sure enough, it is exactly 1337 bytes. Very LEET indeed. :-)
As far as what makes a "killer app" goes, the answer is obvious. Squeak/Pharo/Cuis/Spoon/Seaside are programming *tools*. This community doesn't have the resources to make a new killer app out of the existing tools (if they did, they'd be multi-millionaires already), BUT, Squeak running on Cog/MTCog is sufficiently fast to compete with other programming environments in order to create THE killer app: tools to create games for others to use to create games.
Squeak could easily become the next Flash environment if the APIs existed to manipulate sprites and 3D objects properly. We already have Teatime, which distributes processing in ways that no other platform can even dream of (or even understand without some hours of explanation). Matt Fulmer has managed to get Open Cobalt running in a 4.2 image and play nice with the Morphic GUI (at the cost of some speed, you can overlap windows on top of the OpenGL layer seamlessly http://www.opencobalt.org/downloads).
I've been looking at a simple, but fun, 2D game called NAEV. It uses C for the skeleton framework and calls external libraries (most of which Squeak also calls, or has bypassed to some extent) for speed, and uses Lua scripting to bind the game logic together. It uses SDL for its graphics needs -there was a Squeak project to interface with SDL 1.2, but that apparently died when the main programmer did, but I don't think we need SDL interfacing, because we have direct access to the entire OpenGL 1.4 API. Naev is the work of 7 programmers and my impression is that those same programmers using Squeak + OpenGL would have finished their project many months ago, instead of being only halfway through it.
What we lack is a wrapper around the various libraries that Squeak already calls that would be attractive to game makers, both 2D and 3D. Combine that with squeak's ease of programming, Teatime, and a way of minimizing the footprint of the image using Cuis & Spoon, and you have something that could attract literally thousands of wannabe game writers to the platform.
We have OpenCobalt and OpenQWAK. We need a similar 2D library for sprite-based games as well.
Just a thought...
L.
Lawson English wrote:
... For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It would be interesting to see if Craig can use Spoon to make it even more lean.
If you care about image size, http://www.jvuletich.org/Cuis/Cuis3.1r3.zip is about 2Mb.
Cheers, Juan Vuletich
On Thu, Sep 8, 2011 at 9:29 PM, Lawson English lenglish5@cox.net wrote:
On 9/7/11 5:56 PM, Juan Vuletich wrote:
Levente Uzonyi wrote: We should pick good stuff from Cuis (and Pharo) instead.
[...]
To make the image smaller we should do two things (in parallel):
- craving (make packages unloadable, remove dependencies, split packages)
- building (use Spoon to rebuild the current image)
Growing back the image with Spoon is much easier if you already start with a clean image, like Cuis. Same for loading packages back: half of the work is already done.
For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It would be interesting to see if Craig can use Spoon to make it even more lean.
At the other extreme, when Craig brags that he's gotten a minimalist Squeak image to run with only 1337 bytes, he's not joking. I loaded it into a programming text editor (BBEdit) and sure enough, it is exactly 1337 bytes. Very LEET indeed. :-)
As far as what makes a "killer app" goes, the answer is obvious. Squeak/Pharo/Cuis/Spoon/Seaside are programming *tools*. This community doesn't have the resources to make a new killer app out of the existing tools (if they did, they'd be multi-millionaires already), BUT, Squeak running on Cog/MTCog is sufficiently fast to compete with other programming environments in order to create THE killer app: tools to create games for others to use to create games.
Squeak could easily become the next Flash environment if the APIs existed to manipulate sprites and 3D objects properly. We already have Teatime, which distributes processing in ways that no other platform can even dream of (or even understand without some hours of explanation). Matt Fulmer has managed to get Open Cobalt running in a 4.2 image and play nice with the Morphic GUI (at the cost of some speed, you can overlap windows on top of the OpenGL layer seamlessly http://www.opencobalt.org/downloads).
There are lots of "low hanging fruit" that could enhance Squeak for of game development. Tools for managing internal and external resources/ media for example.
I would really like to see a lot of game development happening in Squeak :-) Here are a few for fun:
http://www.hpi.uni-potsdam.de/hirschfeld/projects/olpc/index.html
Karl
I've been looking at a simple, but fun, 2D game called NAEV. It uses C for the skeleton framework and calls external libraries (most of which Squeak also calls, or has bypassed to some extent) for speed, and uses Lua scripting to bind the game logic together. It uses SDL for its graphics needs -there was a Squeak project to interface with SDL 1.2, but that apparently died when the main programmer did, but I don't think we need SDL interfacing, because we have direct access to the entire OpenGL 1.4 API. Naev is the work of 7 programmers and my impression is that those same programmers using Squeak + OpenGL would have finished their project many months ago, instead of being only halfway through it.
What we lack is a wrapper around the various libraries that Squeak already calls that would be attractive to game makers, both 2D and 3D. Combine that with squeak's ease of programming, Teatime, and a way of minimizing the footprint of the image using Cuis & Spoon, and you have something that could attract literally thousands of wannabe game writers to the platform.
We have OpenCobalt and OpenQWAK. We need a similar 2D library for sprite-based games as well.
Just a thought...
L.
Hi--
Lawson writes:
For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It would be interesting to see if Craig can use Spoon to make it even more lean.
No doubt. We could run it through Spoon's "dissolve" feature. It uses an alternate version of the garbage collector to treat as garbage methods which haven't been run since a chosen point in time. It's the most effective way of stripping a system, and it happens in an instant.
-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
On 2/18/12 5:08 PM, "Craig Latta" craig@netjam.org wrote:
Hi--
Lawson writes:For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It would be interesting to see if Craig can use Spoon to make it even more lean.
No doubt. We could run it through Spoon's "dissolve" feature. Ituses an alternate version of the garbage collector to treat as garbage methods which haven't been run since a chosen point in time. It's the most effective way of stripping a system, and it happens in an instant.
-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177
- 1 415 287 3547
Cuis have a reduced version of 2 mb
I have a CuisWiki with Kom + Hv + my Wiki own version which behaves like real Squeak swiki.
It's 5 mb and can see running today at http://201.212.74.182:8086
User: 'visita' pass: must be blank
Presents encrypted, via HVCaptcha could see Spanish assorted notes.
I hope some day we could build some like this (better) with Spoon I want a .image which could do Morphic and also could do web. I want to take Squeak or Pharo and with some Spoon magic tell what to do for build some arbitrary thing.
Cheers
Edgar
Hi Edgar--
I hope some day we could build some like this (better) with Spoon I want a .image which could do Morphic and also could do web. I want to take Squeak or Pharo and with some Spoon magic tell what to do for build some arbitrary thing.
Yes, that would go like this:
- Start up a blank Spoon history memory.
- Start up an arbitrary Smalltalk memory (Squeak, Pharo, VisualWorks, VAST, GNU, Dolphin, whatever). Let's call it the "control memory".
- Load minimal support for Naiad (Spoon's module system) into the control memory, using the dialect's packaging system (e.g., Monticello, Store, Envy).
- From the control memory, make a Naiad connection to the history memory and request an installation of the rest of the Naiad support.
- Checkpoint the activation state of all the methods in the control memory.
- Run the unit tests for the arbitrary thing in the control memory that you want to keep.
- Dissolve everything else and snapshot.
thanks again,
-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
Hi Craig,
Craig Latta wrote:
Hi--
Lawson writes:For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It would be interesting to see if Craig can use Spoon to make it even more lean.
No doubt. We could run it through Spoon's "dissolve" feature. Ituses an alternate version of the garbage collector to treat as garbage methods which haven't been run since a chosen point in time. It's the most effective way of stripping a system, and it happens in an instant.
-C
I'm very much interested on this. If anybody tries it, please share the experience and results.
Cheers, Juan Vuletich
Me too! In fact, I'm hoping Craig himself will demonstrate Spoon in action as part of his on-line presentation.
On Thu, Feb 23, 2012 at 8:05 AM, Juan Vuletich juan@jvuletich.org wrote:
Hi Craig,
Craig Latta wrote:
Hi--
Lawson writes:
For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It would be interesting to see if Craig can use Spoon to make it even more lean.
No doubt. We could run it through Spoon's "dissolve" feature. It uses an alternate version of the garbage collector to treat as garbage methods which haven't been run since a chosen point in time. It's the most effective way of stripping a system, and it happens in an instant.
-C
I'm very much interested on this. If anybody tries it, please share the experience and results.
Cheers, Juan Vuletich
Hi Chris--
In fact, I'm hoping Craig himself will demonstrate Spoon in action as part of his on-line presentation.
Yup. I just got the virtual machine simulator in Squeak 4.3 to simulate the Cuis memory properly, so it's close.
-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
On Sun, Mar 04, 2012 at 12:02:13AM +0100, Craig Latta wrote:
Hi Chris--
In fact, I'm hoping Craig himself will demonstrate Spoon in action as part of his on-line presentation.
Yup. I just got the virtual machine simulator in Squeak 4.3 tosimulate the Cuis memory properly, so it's close.
Cool. Any simulator patches, please post to vm-dev (or just update VMMaker directly if you prefer).
Dave
Craig Latta wrote:
Hi Chris--
In fact, I'm hoping Craig himself will demonstrate Spoon in action as part of his on-line presentation.
Yup. I just got the virtual machine simulator in Squeak 4.3 tosimulate the Cuis memory properly, so it's close.
That's great! If you have any suggestion for Cuis to ease this, please tell.
And please publish the steps so we can follow you easily.
Thanks, Juan Vuletich
Levente Uzonyi-2 wrote:
I suggest... a new orientation for the next Squeak release:
I guess we have too many forks already (compared to the number of active developers).
Adopt Cuis as the core image and focus on killer applications to attract new Smalltalk users.
This is pure gold. It would be great to put the personality differences aside (I think the only real obstacle/difference at this point) and unify as much as possible.
For sure, another fork would only dilute everyone's great efforts further. But a stack of existing technologies could be very intriguing, if only wishful thinking right now. The seeming current policy of Squeak/Pharo/Cuis/etc to cherry pick changes from the other guys seems to leave little time for killer app development. Imagine something like:
cuis - rock-solid, clean, stable, small kernel + pharo - professional-grade Smalltalk with the expected bells and whistles of a modern IDE + squeak - dynabook software (which b.t.w. was the whole point of Squeak - and Smalltalk - in the first place); a medium that unites all other media of human expression, with the required support of PDF reading/writing/viewing, HTML browsing, cross-platform mp3 support... _______________________________________________________________________ = the closest we've ever been to the holy grail of computing (until VPRI releases and makes us all obsolete, lol)
-- View this message in context: http://forum.world.st/Fork-Proposal-Cuis-Killer-Apps-tp3796633p3798801.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org
-
Ben Coman -
Casey Ransberger -
Chris Muller -
Craig Latta -
David T. Lewis -
Edgar J. De Cleene -
Eliot Miranda -
Gary Dunn -
Juan Vuletich -
karl ramberg -
Lawson English -
Levente Uzonyi -
Overcomer Man -
Sean P. DeNigris