The Future of Squeak or Squeaking at the Future?

> I'm a 'Squeak Newbie' for more than a year now, and i really love the
> language and environment. Now with full closures, traits, Seaside,
> Magritte, Exupery... (Tweak?, pragmas?) the language is truly limitless
> and still clean-and-simple (I'm one of the people who really like the
> Smalltalk syntax ^_^ ).
>
> What's really bugging me is the lack of possibility to use Squeak for
> 'everyday tasks', like linux scripting, small apps and so on... i don't
> say it's "impossible", but totally discouraged, unsupported and
> "forsaken" by most employers.
>
> As it stands now, Squeak *is* a language for long-time Squeakers, OOP
> learning and language-hacker, maybe mid-sized web apps, but *nothing more*.
>
> I'm forced to learn Ruby (and probably Python) to be able to do my work
> now, and i do really hate the utterly ugly and evil perl-like syntax,
> lack of dev environment (Browser? Shout? ...impossible) and the
> complexity (perplexity?) of this languages.
>
>
> I've read enough of the discussions and articles regarding
> Squeaks/Smalltalks future, and this is a sum of the main issues with
> some personal remarks:
>
> -> *GUI DESIGN* of Squeak is kind-of weird/childish: we don't really
> need look like window$, but the UI is the first thing man gets to see,
> so adding a bit of sanity would be nice (anyone using the Skylark theme?
> @ http://www.comtalk.net/Squeak/87 ...imo this should replace the
> default one, but porting in 3.9 involves kind of black magic; an
> alternative theme mimicking the 'redmont' look wold be /though ugly/
> nice too ^^; )
>
> -> *no native apps* - kind-of part of GUI, but shouldn't be too hard to
> get right: we have wxSqueak, maybe we will get Ffenestri... make the
> first-time users see them ^_^
>         -->complex graphical apps use the host system only to get a plain
> window and draw their content by themself (Winamp, most of Miranda,
> almost all games...) - we should be able to mimick this behavior: make
> the native windows 'wrap around' SystemWindows and other morphs/Tweak
> costumes and let BitBlt do it's work.
>         -->i don't really see a reason for the main window being controlled by
> the VM: it should be possible to show/hide it on-demand and so everybody
> could choose: Squeak UI like it's now, or loose apps in native windows
> and let the main window act like the 'java console', but
> not-even-comparable better.
> -> *threading* - good to use soft-threads, bad to not-be-able to use
> host threads, most in the times of multi-core CPUs
>         -->I've read an *really* interesting blog concerning the use of
> realtime delays (another pain-in-ass) >>
> http://www.cdegroot.com/blog/2006/02/02/delay-after-delay/, and it
> really shouldn't be hard to implement Transactional Memory
> (http://www.cambridge.intel-research.net/~rennals/faststm.html) without
> breaking image format (breaking delay-using code is no argument, even
> between minor versions of Squeak, half of the packages get regularly
> unusable)
>                 --->if we had transactional memory *and* externalized VM state, we
> could fork the interpret for every transaction... or use a predictive
> scheduler to assign the transactions to a fixed number of host threads
> ... or there are sure other ways (only guessing, I'm not very proficient
> in this field).
>
> -> *foreign languages* are another long-time problem: english is good
> enough for the dev environment, but not for end-user apps, and until the
> whole image works in Unicode (utf-8), using any language with
> non-standard charset involves very deep hacking of the image and fonts,
> much of the free distributed TTF files have complete-enough utf-8
> charset, but loading them, the national characters are still unusable
> (not talking about input conversions).
>
> -> *packages/namespaces* - I've tried VW, and it's packaging system is
> evil, taking away the simplicity and so the usability; Monticello is
> good, but not good enough, and without namespaces
> (http://swiki.krampe.se/gohu/32 is really enough), the image gets very
> bloated in no time... waiting for M2, waiting for namespace support in
> newCompiler (could hack it into by myself, but for a compiler generated
> by SmaCC, it'd be a more-than-dirty solution).
>
> -> *host integration* - no callbacks, insufficient FFI (limited
> parameters) - it's true anyone can write an own wrapper plugin, but it's
> very discouraging and complicating the work (a language should aid the
> developer, not adding tasks).
>
>
> I thing there is a way Squeak can stay a small, simple and fast
> environment for embedded dev on one hand and a robust dev
> language/environment/framework/engine/call-it-as-you-like for system
> scripting, web/desktop apps, and with Exupery maybe system apps and
> games too ^__^ (just dreaming..?)
>
> Of course i could do a lot of these 'tasks' myself, and/or aid in
> others, but by now, there is really no motivation to do it without the
> community support - it's a lot of changes, depending on each other and
> sometimes breaking compatibility, and i really don't want to end up with
> my own branch of VM and image, unsupported and so unusable in the real
> world out there...
>
> Is there a real possibility to do this kind of 'step in the dark', and
> evolve Squeak for the use in real word, in our everyday jobs... without
> losing the community?
>
> Viktor Svub
>
>
>

> -->complex graphical apps use the host system only to get a plain  
> window and draw their content by themself (Winamp, most of Miranda,  
> almost all games...) - we should be able to mimick this behavior:  
> make the native windows 'wrap around' SystemWindows and other  
> morphs/Tweak costumes and let BitBlt do it's work.
> -->i don't really see a reason for the main window being  
> controlled by the VM: it should be possible to show/hide it on-
> demand and so everybody could choose: Squeak UI like it's now, or  
> loose apps in native windows and let the main window act like the  
> 'java console', but not-even-comparable better.
> -> *threading* - good to use soft-threads, bad to not-be-able to  
> use host threads, most in the times of multi-core CPUs
>

> -->I've read an *really* interesting blog concerning the use of  
> realtime delays (another pain-in-ass) >> http://www.cdegroot.com/ 
> blog/2006/02/02/delay-after-delay/, and it really shouldn't be hard  
> to implement Transactional Memory (http://www.cambridge.intel- 
> research.net/~rennals/faststm.html) without breaking image format  
> (breaking delay-using code is no argument, even between minor  
> versions of Squeak, half of the packages get regularly unusable)
> --->if we had transactional memory *and* externalized VM state,  
> we could fork the interpret for every transaction... or use a  
> predictive scheduler to assign the transactions to a fixed number  
> of host threads ... or there are sure other ways (only guessing,  
> I'm not very proficient in this field).
>
> -> *foreign languages* are another long-time problem: english is  
> good enough for the dev environment, but not for end-user apps, and  
> until the whole image works in Unicode (utf-8), using any language  
> with non-standard charset involves very deep hacking of the image  
> and fonts, much of the free distributed TTF files have complete-
> enough utf-8 charset, but loading them, the national characters are  
> still unusable (not talking about input conversions).
>
> -> *packages/namespaces* - I've tried VW, and it's packaging system  
> is evil, taking away the simplicity and so the usability;  
> Monticello is good, but not good enough, and without namespaces  
> (http://swiki.krampe.se/gohu/32 is really enough), the image gets  
> very bloated in no time... waiting for M2, waiting for namespace  
> support in newCompiler (could hack it into by myself, but for a  
> compiler generated by SmaCC, it'd be a more-than-dirty solution).

> -> *host integration* - no callbacks, insufficient FFI (limited  
> parameters) - it's true anyone can write an own wrapper plugin, but  
> it's very discouraging and complicating the work (a language should  
> aid the developer, not adding tasks).
>
> I thing there is a way Squeak can stay a small, simple and fast  
> environment for embedded dev on one hand and a robust dev language/
> environment/framework/engine/call-it-as-you-like for system  
> scripting, web/desktop apps, and with Exupery maybe system apps and  
> games too ^__^ (just dreaming..?)

> Viktor Svub puso en su mail :
>
>> -> *host integration* - no callbacks, insufficient FFI (limited
>> parameters) - it's true anyone can write an own wrapper plugin, but it's
>> very discouraging and complicating the work (a language should aid the
>> developer, not adding tasks).
>
> Viktor :
>
> All your post is very clear.
>
> To this point, in Mac you could do a lot via AppleScript and Services.
>
> John do a great job in VM construction for support this,
>
> I do not know if you have Mac, but just in case how about a mini MacSqueak
> task force for doing examples, etc ?
>
> Could you have time / interest in this ?
>
> Edgar
>
>
>
>
> _________________________________________________________
> Horóscopos, Salud y belleza, Chistes, Consejos de amor:
> el contenido más divertido para tu celular está en Yahoo! Móvil.
> Obtenelo en http://movil.yahoo.com.ar
>
>

> ...
>> Is there a real possibility to do this kind of 'step in the dark',
>> and evolve Squeak for the use in real word, in our everyday jobs...
>> without losing the community?
>
> I really hope but we need to have more people working for squeak and
> not simply using it (which is already perfect)
>
> Stef
>>
>> Viktor Svub

>> I'm a 'Squeak Newbie' for more than a year now, and i really love the
>> language and environment. Now with full closures, traits, Seaside,
>> Magritte, Exupery... (Tweak?, pragmas?) the language is truly
>> limitless and still clean-and-simple (I'm one of the people who really
>> like the Smalltalk syntax ^_^ ).
>
> :)
>
>> What's really bugging me is the lack of possibility to use Squeak for
>> 'everyday tasks', like linux scripting, small apps and so on... i
>> don't say it's "impossible", but totally discouraged, unsupported and
>> "forsaken" by most employers.
>
> We started to work on a scripting syntax but we stop. This would be easy
> to get one.

>
>> As it stands now, Squeak *is* a language for long-time Squeakers, OOP
>> learning and language-hacker, maybe mid-sized web apps, but *nothing
>> more*.
>
>
>
>> I'm forced to learn Ruby (and probably Python) to be able to do my
>> work now, and i do really hate the utterly ugly and evil perl-like
>> syntax, lack of dev environment (Browser? Shout? ...impossible) and
>> the complexity (perplexity?) of this languages.
>
> The fact that companies want to use Ruby or python is not really related
> to the language but the trends around it.
> If I would have couple of Million dollars to spend I would have some ideas.

>
>
>> -> *GUI DESIGN* of Squeak is kind-of weird/childish: we don't really
>> need look like window$, but the UI is the first thing man gets to see,
>> so adding a bit of sanity would be nice (anyone using the Skylark
>> theme? @ http://www.comtalk.net/Squeak/87 ...imo this should replace
>> the default one, but porting in 3.9 involves kind of black magic; an
>> alternative theme mimicking the 'redmont' look wold be /though ugly/
>> nice too ^^; )
>
> Yes. We started to change the web site. Andrew Tween is working on true
> type fonts support and we should certainly
> pay someone to design a look for squeak.

>
>
>> -> *no native apps* - kind-of part of GUI, but shouldn't be too hard
>> to get right: we have wxSqueak, maybe we will get Ffenestri... make
>> the first-time users see them ^_^
>
> Exact!
>
>>     -->complex graphical apps use the host system only to get a plain
>> window and draw their content by themself (Winamp, most of Miranda,
>> almost all games...) - we should be able to mimick this behavior: make
>> the native windows 'wrap around' SystemWindows and other morphs/Tweak
>> costumes and let BitBlt do it's work.
>>     -->i don't really see a reason for the main window being
>> controlled by the VM: it should be possible to show/hide it on-demand
>> and so everybody could choose: Squeak UI like it's now, or loose apps
>> in native windows and let the main window act like the 'java console',
>> but not-even-comparable better.
>> -> *threading* - good to use soft-threads, bad to not-be-able to use
>> host threads, most in the times of multi-core CPUs
>>
>
>>     -->I've read an *really* interesting blog concerning the use of
>> realtime delays (another pain-in-ass) >>
>> http://www.cdegroot.com/blog/2006/02/02/delay-after-delay/, and it
>> really shouldn't be hard to implement Transactional Memory
>> (http://www.cambridge.intel-research.net/~rennals/faststm.html)
>> without breaking image format (breaking delay-using code is no
>> argument, even between minor versions of Squeak, half of the packages
>> get regularly unusable)
>>         --->if we had transactional memory *and* externalized VM
>> state, we could fork the interpret for every transaction... or use a
>> predictive scheduler to assign the transactions to a fixed number of
>> host threads ... or there are sure other ways (only guessing, I'm not
>> very proficient in this field).
>>
>> -> *foreign languages* are another long-time problem: english is good
>> enough for the dev environment, but not for end-user apps, and until
>> the whole image works in Unicode (utf-8), using any language with
>> non-standard charset involves very deep hacking of the image and
>> fonts, much of the free distributed TTF files have complete-enough
>> utf-8 charset, but loading them, the national characters are still
>> unusable (not talking about input conversions).
>>
>> -> *packages/namespaces* - I've tried VW, and it's packaging system is
>> evil, taking away the simplicity and so the usability; Monticello is
>> good, but not good enough, and without namespaces
>> (http://swiki.krampe.se/gohu/32 is really enough), the image gets very
>> bloated in no time... waiting for M2, waiting for namespace support in
>> newCompiler (could hack it into by myself, but for a compiler
>> generated by SmaCC, it'd be a more-than-dirty solution).
>
> Namespaces are not the solution.
> Manpower is! If you want the new compiler, contact marcus and help
> improving it.

>
>> -> *host integration* - no callbacks, insufficient FFI (limited
>> parameters) - it's true anyone can write an own wrapper plugin, but
>> it's very discouraging and complicating the work (a language should
>> aid the developer, not adding tasks).
>>
>> I thing there is a way Squeak can stay a small, simple and fast
>> environment for embedded dev on one hand and a robust dev
>> language/environment/framework/engine/call-it-as-you-like for system
>> scripting, web/desktop apps, and with Exupery maybe system apps and
>> games too ^__^ (just dreaming..?)
>
> No I think that this is possible but just help!
> Everybody can help.

>
>> Of course i could do a lot of these 'tasks' myself, and/or aid in
>> others, but by now, there is really no motivation to do it without the
>> community support - it's a lot of changes, depending on each other and
>> sometimes breaking compatibility, and i really don't want to end up
>> with my own branch of VM and image, unsupported and so unusable in the
>> real world out there...
>
>
> Just start with some simples changes, get confidence and trust.
> Help in harvesting for example, writing tests, helping people, trying
> other codes. I think that stepwise we can slowly get there.
>
>> Is there a real possibility to do this kind of 'step in the dark', and
>> evolve Squeak for the use in real word, in our everyday jobs...
>> without losing the community?
>
> I really hope but we need to have more people working for squeak and not
> simply using it (which is already perfect)

> Viktor Svub wrote:
>> -> *host integration* - no callbacks, insufficient FFI (limited
>> parameters) - it's true anyone can write an own wrapper plugin, but
>> it's very discouraging and complicating the work (a language should
>> aid the developer, not adding tasks).
>
> Can you explain what you mean by "limited parameters" for FFI? Limited how?
>
>
> Cheers,
>   - Andreas
>
>

> KernelPackage
> import: Point.
>
> Package declare: 'ColoredPointPackage'.
>
> Point < ColoredPoint
> variables: 'x y' ;
> classvar: 'Foo'
>
> ColoredPoint>>foo: zork
> [
>          <category: 'foobar'>
> <author: 'sd' date: '24/06/2006'>
>
> ^ self foo
>         ]
>

> stéphane ducasse wrote:
>> ...
>>> Is there a real possibility to do this kind of 'step in the dark',
>>> and evolve Squeak for the use in real word, in our everyday jobs...
>>> without losing the community?
>>
>> I really hope but we need to have more people working for squeak and
>> not simply using it (which is already perfect)
>>
>> Stef
>>>
>>> Viktor Svub
> OK.  How experienced does one need to be, and where/how should one
> volunteer?

> Basically *anyone* that has a computer capable of running Squeak  
> and a little time and web access can do something helpful.  We use  
> Mantis to record bugs/problems/feature requests, so one route would  
> be to look through the lists (http://bugs.impara.de/main_page.php)  
> and look at anything that might pique your interest.
>
> Read the problem description and any notes and see if they make  
> sense; can you actually understand what the problem is supposed to  
> be? Can you replicate the problem at all? If not, email the  
> original reporter to ask if they can help work it out and improve  
> the description, or establish that it got fixed in a more recent  
> release. A non-problem can be closed, removing clutter. A better  
> problem description will help a more experienced user fix it - and  
> you get to learn as you help.
>
> If the problem happens to be something you already understand but  
> can't see a solution, try to write some test to demonstrate it  -  
> just a code snippet helps - and some cases that explain what ought  
> to happen if it were fixed. Some bugs are things that people like  
> me could fix quickly if only we knew what the correct response was.
>
> If you do know a solution but can't work out how to program it,  
> explain the solution. If you think you know who might be able to  
> implement your solution ask if they can help you. If you don't know  
> who, ask on the list.
>
> I'd bet that pretty much anyone on this list could progress from  
> total know-nothing-yet beginner to getting-the-idea apprentice with  
> a reputation for being a good contributor in a short time by doing  
> nothing more than the above for a couple of reports a week.
>
> It's our system. It only gets better if we put some work into it.

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Quality assurance: A way to ensure you never deliver shoddy goods  
> accidentally.
>
>
>
>

> Viktor Svub wrote:
> > Isn't the number of parameters of the called function limited to some
> > fixed count?
>
> No. That's a limitation of Squeak not the FFI. The FFI can deal with
> arbitrary number of arguments but Squeak can't deal with more than 15
> right now. If you really need more you can still construct and invoke
> your FFI call manually; you just can't use the "inline" declaration.
>
> Cheers,
>    - Andreas

>
> On 12 mai 06, at 17:52, Lord ZealoN wrote:
>
> > But Dolphin doesn't run in Unix Like and not is opensource.
> >
> > I'm the most newbie in squeak. I have only been able to dedicate to
> > (this was traduced by google sorry) squeak a few hours, but i hate the
> > logo and the default child interface (sorry), but i'm accustoming
>
> seriously, me too... and we are working on it.
> I prefer the squeakfoundation logo :)
>
> >
> >
> >
> > --
> >
> > ::Mi blog::
> > http://blog.lordzealon.com
> >
> >
>
>
>

>
> On 12-May-06, at 9:39 AM, Charles D Hixson wrote:
>
>> stéphane ducasse wrote:
>>> ...
>>>> Is there a real possibility to do this kind of 'step in the dark',
>>>> and evolve Squeak for the use in real word, in our everyday jobs...
>>>> without losing the community?
>>>
>>> I really hope but we need to have more people working for squeak and
>>> not simply using it (which is already perfect)
>>>
>>> Stef
>>>>
>>>> Viktor Svub
>> OK.  How experienced does one need to be, and where/how should one
>> volunteer?
>
> I wrote a message quite a while ago about how even the newest of new
> newcomers could join in and help.
>
> Basically *anyone* that has a computer capable of running Squeak and a
> little time and web access can do something helpful.  We use Mantis to
> record bugs/problems/feature requests, so one route would be to look
> through the lists (http://bugs.impara.de/main_page.php) and look at
> anything that might pique your interest.
>
> Read the problem description and any notes and see if they make sense;
> can you actually understand what the problem is supposed to be? Can
> you replicate the problem at all? If not, email the original reporter
> to ask if they can help work it out and improve the description, or
> establish that it got fixed in a more recent release. A non-problem
> can be closed, removing clutter. A better problem description will
> help a more experienced user fix it - and you get to learn as you help.
>
> If the problem happens to be something you already understand but
> can't see a solution, try to write some test to demonstrate it  - just
> a code snippet helps - and some cases that explain what ought to
> happen if it were fixed. Some bugs are things that people like me
> could fix quickly if only we knew what the correct response was.
>
> If you do know a solution but can't work out how to program it,
> explain the solution. If you think you know who might be able to
> implement your solution ask if they can help you. If you don't know
> who, ask on the list.
>
> I'd bet that pretty much anyone on this list could progress from total
> know-nothing-yet beginner to getting-the-idea apprentice with a
> reputation for being a good contributor in a short time by doing
> nothing more than the above for a couple of reports a week.
>
> It's our system. It only gets better if we put some work into it.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Quality assurance: A way to ensure you never deliver shoddy goods
> accidentally.
>
>
>
>