[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

Yoshiki Ohshima wrote:
>   Yeah, but insisting to use #= to do it seems to be a wrong goal
> Define seasideEqual: and use it elsewhere would be better.

You'd have to change too many places for this to be feasible. For
example, consider Set and Dictionary operations which may have to be
changed in this process.

>> And we have to map characters to bytes and bytes to characters.
>
>   Everybody does.  Not sure why it is relevant.

Because a simple conversion like squeakToUtf8/utf8ToSqueak is not
lossless anymore. The problem is that Unicode is Unicode is Unicode ;-)
You can either use it and live with its shortcomings or you can write
something completely different. But as soon as one tries to redefine it
partially it leads to problems since there are too many surrounding
assumptions.

>> I agree but you don't know how often I have gotten this answer when I
>> suggested to simply drop #leadingChar.
>
>   Maybe you get the answer often because it makes sense?  I wrote this
> a few times in last some years but if the goal is to make a
> comprehensible personal computer environment, some information is
> needed more than Unicode code points provides.

Yes, but it is not clear whether that information belongs into the
string itself or in its surrounding context. The argument that a
language should be part of the string itself can certainly be made but
it neglects the necessity of interacting with the outside world. And in
the outside world (meaning Unicode) the language tag isn't part of the
string but rather part of the context. Consequently, I think that Squeak
should follow similar semantics (imperfect as that may be for some uses)
and have language information associated with class Text (i.e., a text
attribute) not with class Character (leadingChar).

Cheers,
   - Andreas

On Mon, 29 Jun 2009 06:41:58 +0200, K. K. Subramaniam wrote:

> On Monday 29 Jun 2009 1:20:50 am Klaus D. Witzel wrote:
>> working on: three parts 1) fonts/glyphs without new plugins/VM support;  
>> 2)
>>   glyphs "char" map visualization (for end user support); 3) glyph
>> composition (for complicated scripts which need more than one glyph per
>> "character" location).
> That is a laudable set of goals.

:)

> The third part is especially interesting for
> stroke-based characters in Indic/Arabic scripts.

And in "very" ancient scripts, which are the reason for our project,  
examples:

- http://users.teilar.gr/~g1951d/download.html

> I can help with Kannada
> (U0C80) and Tamil (U0B80) fonts.

Great :) I put you on the list of potential testers. At the moment we are  
busy with basic WYSIWYG applets (visualizing glyphs/fonts). Will come back  
to you in 1-2 weeks.

> How was the picture produced?

In the way that Igor wrote.

> Subbu
>


--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

On Monday 29 Jun 2009 10:54:29 am Igor Stasenko wrote: I meant how were glyphs rendered in Squeak? currently 3) is supported only
through rendering engine plugins. I thought Klaus had dvipng [1] equivalent
working natively in Squeak.

[1] http://savannah.nongnu.org/projects/dvipng

Subbu

On Mon, 29 Jun 2009 11:01:37 +0200, K. K. Subramaniam wrote:

Ah, no, as written earlier we just use existing libs/VM/plugins and some  
new Smalltalk code. The picture was taken from a Cuis workspace from  
inside the .image, as Igor wrote, no magic.

Sorry for being a bit vague at the moment ;)

/Klaus

> [1] http://savannah.nongnu.org/projects/dvipng
>
> Subbu
>
>



--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

You're free to have your opinion on Han unification.  Many people share
it, many people don't.  But the fact is, only Squeak does it this way
and it does have as many problems as it solves.

For another way to encode languages see
http://www.isi.edu/in-notes/rfc2482.txt.

Paolo

On 6/28/09 5:37 PM, "Bernhard Pieber" <[hidden email]> wrote:

I miss Connectors, MathMorphs, Alice, Games, ThingLab, Genie, Nebraska and all the other cool things that were once. But maybe it's just me. ;-)

You have into FunSqueak (3.10 souped up) and into SqueakLigntII (3.10 shrinked but with “intelligent load”) most of old good friends.



Edgar

On 6/28/09 8:24 PM, "Igor Stasenko" <[hidden email]> wrote:

> It is impossible to maintain such a big code base by a single
> person. We need to split responsibilities, establish a new
> development/communication model. Only then you can get the answers in
> a minutes, whether your package will work with X.Y.Z image/module or
> not, and what you need to make it working.


So Igor, why when years ago I fight every guy asking for a strict "people
don't should mess others people work" you disagree ?

Was the "Czar of packages" idea .

Edgar

On 6/28/09 10:31 PM, "Hernán Morales Durand" <[hidden email]>
wrote:

> my vote is not positive
>
> Hernán

Seems like one infamous public man here in Argentina.
Maybe the world don't know we was in the process of ending the lies of K
government

For Squeak , who don't know we could have any look we wish ?

Edgar

On 6/28/09 11:32 PM, "Igor Stasenko" <[hidden email]> wrote:

> where are
> those people who stop talking and start doing something?

Here in Argentina we have Cuis, SqueakLightII, SqueakNOS, and many more.
What you don't like don't means we don't work

Edgar

On 6/29/09 4:12 AM, "Stéphane Rollandin" <[hidden email]> wrote:

> well thank you for driving me out. I guesss I just have to shut up now.
>
>
> Stef
No you do not should shut down.
You have many admirers and I'm guilty to do not try to get your VeryAmazing
work on FunSqueak or SqueakLightII.

Any .image which don't let you run your code is worthless , no matter if was
Squeak, Pharo , Cuis or other fork.


Edgar

Comitees set to design horses end up implementing giraffes.

Forcing anything will be paid with momentum. I don't think you want to loose it.

Want to start your own movment? nobody will stop you. Go ahead fork and show results.

---

De: [hidden email] [mailto:[hidden email]] En nombre de Stephen Pair
Enviado el: Monday, June 29, 2009 09:04
Para: The general-purpose Squeak developers list
Asunto: Re: [squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

2009/6/29 Janko Mivšek <[hidden email]>

Juan Vuletich pravi:

> I don't agree with this at all. The biggest problems Cuis and Pharo are
> trying to fix are the endless discussions, the weak leadership and the
> impossibility to build consensus in fundamental decisions.

I agree completelly!

Me too.  The fact is that committee and consensus based process, while it can work, will always be much slower and often unsatisfactory to a large percentage of the community (until our intellects are all intimately coupled (like the Borg), I suspect this will remain the case).  I see no reason to merge squeak with pharo, cuis or eToys.  These forks of squeak are successful in large part because they forked from the main squeak.  They are driven by people that have a very specific vision of what they want and there happen to be other people that believe in that same vision and contribute.  They don't have to seek approval or build any sort of consensus from any committee.  They alone get to decide to what degree they listen to their own community.

- Stephen

Em 28-06-2009 23:32, Igor Stasenko escreveu:

(...)

This discussion resembles other inside Fedora community: what should be
in/out of a distro and how to maintain it. There are three proposals:
Squeak, Pharo, Cuis. I'll tell you what I don't like in Pharo/Cuis
proposals: they resemble me Brazilian way of solving things: you have
something that's just not working as you wish. Instead of correcting the
circumstances that lead to the problem, people start a new project saying:
"now everything will be all right". Later the so called solution is
suffering from the same problems and people launches a newer project to fix
what went wrong with the predecessors.
    

This is what is called development: learn on mistakes and move forward.
An opposite to this is stalling: do nothing, eveyone is happy. End of story.

  

No, it's just spinning around. Why? Just take a look at the statements of Pharo and Cuis. They clearly point out what people think is wrong with Squeak.org but doesn't have a single word about how to avoid the situations to repeat in future.

First, I am not reactionary. I think that if something is not working, them it is necessary to move ahead. I've seem Pharo and I particularly enjoy their proposal. But when you see the project roadmap... there's much to be done. What are the concrete, tangible schedules? What are the resources to achieve them? Will the same people involved in Squeak.org be contributing to Pharo? If they're splitting teams where they'll find people to care about real world issues like support & maintenance?

Second, much of the manifestations of the spin-off projects show non satisfaction with current Squeak.org leadership. But leadership was voted... Besides, we at LA know where "benevolent dictatures" lead to...

And there are 3 projects running in
parallel. Redundancy of effort, high costs (even in terms of dedication of
people struggling to keep pace in what is happening around) and futile
disputes are the only results.

    

How many companies in the world producing a cars in parallel?
Should they merge under a single banner & start producing a single,
good for everyone car?
Or should they stop producing a cars at all, because all of them would
break someday, or get obsolete?
Imagine, how many money & man hours could be saved! :)
  

In fact, there are really a number of manufactures producing vehicles in parallel. But whenever their business loose meaning they merge or even close (unless some government crazily injects billions of bucks in their broken businesses).

The key question is: "the meaning of the business". What is the size of the market? What are the available resources? What are the future scenarios? Where people want to be in the next five years?

Squeak and derivatives scenario: how many people/organizations are using it? What is the "potential market" for Squeak? What are the available resources? What are the chances of filling the market space and how to do that?

I think there's nothing fundamentally wrong with squeak. The question is how
to organize things. How to classify things as "core", "contributed" and "3rd
party". How to keep things up to date. How to obsolete things.

It may be boring, but I think that many things could be formalized.

First there are the leadership meetings on Wednesdays. The agenda of the
meetings as well as their minutes could be placed at the
www.squeak.org/Foundation. There should be a place where people could
suggest topics to be included in the agenda. I know that much has been done
via e-mail lists but for people (like me) who have to deal with large
amounts of email these lists may be unpractical. Besides, keeping things
public is a good way for letting people decide if they want or don't want to
use squeak.

    

You are free to post agenda items at any time. Either in blog comments
area, or here on the list.
We are in need for your proposals, and declaring this constantly.
  

Well... I think I've presented some administrative proposals in my e-mails. The next paragraphs have at least 3 proposals: responsibility delegation regarding maintenance, establishment of mechanisms for evaluating suitability of packages to be included in official distros and seek for $$$ support. As they appear they're out of order because I think that 1rst thing for a leadership is to ensure enough resources (so, $ and gathering people comes first), delegation follows.

As I don't believe in dictatorship, at first I present ideas. If the ideas are not welcome, no meaning in proceeding to implementation  suggestions.

As this discussion (about future of Squeak & Pharo) made clear, it is urgent
to define what is in and what is out of Squeak. Since there's a real concern
about back compatibility and as things are getting big and sometimes
non-maintained, I would suggest that documenting things is essential.

In my opinion, it would be interesting to create a mechanism for
responsibility delegation regarding to maintenance. Regarding to
distributions it would be interesting to create a mechanism for evaluating
the suitability of packages to be included (like looking that the packages
don't have dependencies outside the distribution and things that can lead to
a situation where it is impossible to assure their maintenance). I don't
think that a situation where a single person is responsible for a critical
part of a distribution is acceptable: whenever such situation is identified
the leadership should seek for additional people.

In my opinion, it would be good if some sort of financial/corporate support
could be granted. It would allow to have people involved in "non exciting"
tasks. Again: corporate support doesn't translate in any kind of servitude
and it can help to grow the universe of Squeak users. Besides, good
marketing is essential: if you get good media it is more likely you'll be
granted more and better projects... more people will pay attention to you.

Just a last thing about croquet. It was meant to rock but didn't... I tell:
(1) poor documentation (how in hell I use it???) (2) lack of marketing
(yeah... even inside university good marketing is essential). Many people
just didn't figured out what it was meant to (3) performance issues
(intensive use of GL, etc).

    

You know, all of this is good: Pointing at mistakes, drawing a new direction.
But for a success, there is one little thing is missing: where are
those people who stop talking and start doing something?
I can tell you, but i think you know it yourself.
  

Yes. I know it. That's why I'm spending time in order to discuss things and present suggestions. Perhaps suggestions are not clear enough.

IMHO, I think that Squeak.org should be seeking for objectives (medium/long term), support and popularization. I give you an example: about 26 years ago people at UvA (Amsterdam, NL) decided to invest in the study of knowledge modeling and related research. Their leadership at that time (Prof. Dr. Wielinga, Prof. Dr. Breuker and Prof. Dr. Schreiber) elaborated an action plan (formalized in a set of projects) and got support within EU (ESPRIT projects, a good number of them) and companies (IBM among them). The ESPRIT support lasted for more than 15 years (I currently don't know the state of things) and many really interesting things came to life. SWI-Prolog is one of them.

No offense.

  

Good night all,

CdAB




    

No offense taken.

CdAB

Dear Ian,
                  I really understand your position, because I hated
the Squeak UI for almost one year, until I started to read about Color
Theory and Cognitive Pshychology and understand some things about it.
However, each soul has to convince by himself or do something about
it.

  Let me put my feelings into the words of Schoenberg, he once said :
"Art is not for everyone; and if it is for everyone, it is not Art.".
And I believe pretty much the same here : "Smalltalk is not for
everyone; and if it is for everyone, then it is not Smalltalk".

Cheers,

Hernán

2009/6/29 Ian Trudel <[hidden email]>:

>>>>> "Casimiro" == Casimiro de Almeida Barreto <[hidden email]> writes:

Casimiro> IMHO, I think that Squeak.org should be seeking for objectives
Casimiro> (medium/long term), support and popularization.

Indeed... this is pretty much agreed amongst the current SOB.  However,
*before* we want to nudge resources in that direction, we *need* to get the
license clean.  And that's currently in process, although taking time.

It would be really bad to have a huge promotion campaign for squeak right now
only to have people come and find a code freeze and an uncertain license.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Casimiro de Almeida Barreto wrote:
> No, it's just spinning around. Why? Just take a look at the statements
> of Pharo and Cuis. They clearly point out what people think is wrong
> with Squeak.org but doesn't have a single word about how to avoid the
> situations to repeat in future.

The Cuis statement says (stuff in parenthesis added in this message):
- Close to the ideas in Smalltalk-80 and "Design Principles Behind
Smalltalk".
    (Do not load stuff whose complexity outweighs its usefullness. Do
not load too complex stuff)
- Include only kernel functionality.
    (Leave optional functionality out, to be included in optional packages)
- Included stuff should be in very good shape.
    (Do not load bad code)
- Include a greatly simplified version of Morphic as the main UI.
    (Do not include optional applications like Etoys. Do not include too
complex stuff)
- Stable. Smalltalk kernel should not change much.
    (If something is not stabilized, as Unicode in Squeak, leave it out,
to be included in optional packages)
All these are ways to avoid the problems with the software.

It also says:
- Lead by Juan Vuletich (jmv) after these principles.
This is the way to avoid the problems with the community.

Maybe all this is plain wrong for many. Maybe it will bring new
problems. But it will indeed avoid the situations to repeat in the future.

Cheers,
Juan Vuletich

someone wrote:


This very point has been on my mind since this whole thread  started.  
At some point, money needs to be flowing in to guarantee the future of  
the environment, or else corporations will never want to adopt it.

-cam

2009/6/29 Edgar J. De Cleene <[hidden email]>:
I agree. But squeak is very permissive on that. So, whatever you or me
will say - people just keep doing things what they think is good for
them.



--
Best regards,
Igor Stasenko AKA sig.

At Mon, 29 Jun 2009 00:38:16 -0700,
Andreas Raab wrote:
>
> Yoshiki Ohshima wrote:
> >   Yeah, but insisting to use #= to do it seems to be a wrong goal
> > Define seasideEqual: and use it elsewhere would be better.
>
> You'd have to change too many places for this to be feasible. For
> example, consider Set and Dictionary operations which may have to be
> changed in this process.

  Right.  And Phillippe can strip the leading char when he wants.

  From another POV, the communication with outside world was
secondary.  The .changes in in UTF-8 but has the additional
information always so it is lossless.

  I should say I've been agreeing with it for a while, but it also is
a huge unstabilier to the existing system.  Now Pharo people may be
able to leap the gap, if they like.

-- Yoshiki

On 6/29/09 12:21 PM, "Juan Vuletich" <[hidden email]> wrote:

> Maybe all this is plain wrong for many. Maybe it will bring new
> problems. But it will indeed avoid the situations to repeat in the future..

Not wrong as I understand the goal and send mails to some members private
saying Cuis should be the stone on which we could build a better Squeak.

Pero mi querido Juan, podrías ser un poquito mas abierto y dejar que
cooperemos sin "ensuciar" el Cuis ?


Edgra