Fork Proposal: Cuis & Killer Apps.

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

Fork Proposal: Cuis & Killer Apps.

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



Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

LawsonEnglish
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




    



Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Casey Ransberger-2
In reply to this post by Kirk Fraser
Inline below.

On Wed, Sep 7, 2011 at 9:52 AM, Overcomer Man <[hidden email]> wrote:
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?
 
--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Levente Uzonyi-2
In reply to this post by Kirk Fraser
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Gary Dunn-2
In reply to this post by Casey Ransberger-2
On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger
<[hidden email]> wrote:
> Inline below.
>
> On Wed, Sep 7, 2011 at 9:52 AM, Overcomer Man <[hidden email]>
> 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
Open Slate Project
http://openslate.org/
Honolulu

Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Edgar De Cleene
In reply to this post by Levente Uzonyi-2



On 9/7/11 6:24 PM, "Levente Uzonyi" <[hidden email]> wrote:

>  building (use Spoon to rebuild the current image)

I think Spoon is the future, but we should take PharoKernel as next step.

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Casey Ransberger-2
In reply to this post by Levente Uzonyi-2
Inline.

On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi <[hidden email]> 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





--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Juan Vuletich-4
In reply to this post by Levente Uzonyi-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Juan Vuletich-4
In reply to this post by Gary Dunn-2
Gary Dunn wrote:

> On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger
> <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Try it. (was Re: [squeak-dev] Fork Proposal: Cuis & Killer Apps.)

Casey Ransberger-2
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 <[hidden email]> wrote:

> Gary Dunn wrote:
>> On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger
>> <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Sean P. DeNigris
Administrator
In reply to this post by Levente Uzonyi-2
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)



Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

LawsonEnglish
In reply to this post by Juan Vuletich-4
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.





Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Juan Vuletich-4
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

Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Gary Dunn-2
In reply to this post by Juan Vuletich-4
On Wed, Sep 7, 2011 at 2:59 PM, Juan Vuletich <[hidden email]> wrote:

> Gary Dunn wrote:
>>
>> On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger
>> <[hidden email]> 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:Squeak_Projects

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

Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Casey Ransberger-2
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 <[hidden email]> wrote:
On Wed, Sep 7, 2011 at 2:59 PM, Juan Vuletich <[hidden email]> wrote:
> Gary Dunn wrote:
>>
>> On Wed, Sep 7, 2011 at 9:27 AM, Casey Ransberger
>> <[hidden email]> 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:Squeak_Projects

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




--
Casey Ransberger


Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Ben Coman
In reply to this post by Casey Ransberger-2
Casey Ransberger wrote:
Inline.

On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi <[hidden email]> 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. 


Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Eliot Miranda-2


On Mon, Sep 12, 2011 at 9:27 AM, Ben Coman <[hidden email]> wrote:
Casey Ransberger wrote:
Inline.

On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi <[hidden email]> 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! 

--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

Karl Ramberg
In reply to this post by LawsonEnglish
On Thu, Sep 8, 2011 at 9:29 PM, Lawson English <[hidden email]> 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.
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

ccrraaiigg
In reply to this post by LawsonEnglish

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



Reply | Threaded
Open this post in threaded view
|

Re: Fork Proposal: Cuis & Killer Apps.

ccrraaiigg
In reply to this post by Casey Ransberger-2

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



12