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

Randal L. Schwartz wrote: Actually, wasn't NetBSD bitten by the USL v BSDI & University of
California lawsuit which was over licencing of the commercial Unix code
that the early BSD code was based on?
 I'm pretty sure I remember them not being able to make their CVS repo
public in the early days because it contained commercially licenced code
from the original Unix.

Casimiro de Almeida Barreto wrote:
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.

These problems will not happen again in Pharo or Cuis. At least not in
Cuis.

Cheers,
Juan Vuletich

2009/6/28 Hernán Morales Durand <[hidden email]>:
> To my view, Squeak doesn't fit very well with the production-line
> programmer-worker.
>
> Then, my vote is not positive for color uniformity in Squeak :)
>
> Hernán

Hello Hernán!

This is a very passionate text to unveil your opinion. Thank you. Do
not get me wrong on my ideas: they are not about striving for
conventionalism but rather suggesting an avenue of solution that might
eventually be suitable and feasible.

You might well convince me that an ergonomics based on any popular
professional tools is not the optimal solution for Squeak. However,
don't tell me that the current UI is suitable for grown-up programmers
and professionals. It is not. Childish, confusing, undocumented, ugly,
outdated and "eccentric". Have better ideas than mine? Be my guest. =)

The issue is important because the growth rate of the community is low
and a certain amount of existing members move to other forks. Hernàn,
you're using Squeak for some time already. You can customize Squeak UI
as you deem necessary. Others might not. Morphic has no viable
documentation. We need a standard image with something visually and
ergonomically appealing, something approachable.

I have tried to introduce Squeak to acquaintances but it failed in
general. One of the common reason is the "weird" interface. What can I
do about it? Kick them in the nuts and tell them they don't know what
they're talking about? =)

The colour scheme doesn't really matter, does it?

We could be rebel and eccentric on other things than colours. I think...

Then we don't want to change colours because it upsets some in the
community. "Everybody can get Squeak with the features he desires,
provided it is backward compatible." What will happen when the
community desires a feature that will inflect such changes that will
not be backward compatible? Well, we do have constraints. Heck, I've
been told that we are unlikely to have international keyboard input
because its implementation would certainly break the compatibility...
oh, gee...

It's not that I want to be controversial... simply, I think, we should
not toss away the idea to be appealing to a greater mass, especially
if it helps Squeak to survive and move forward. It's not like we need
less manpower...

Regards,
Ian

--
http://mecenia.blogspot.com/

At Sun, 28 Jun 2009 19:28:50 +0200,
Philippe Marschall wrote:
>
> For Seaside #leadingChar is a PITA because there is no way of knowing
> the language of the content the user entered. And it's a rampant
> layering violation. And it probably contributes to WideStrings being
> so slow. And it's not portable. And ....

  For Seaside you don't need to display the string so you can just
ignore it.

> And don't get me "but we need it for fonts". The only way to get nice
> fonts in Squeak is to avoid it and do it in C with char*.

  This is a very confused statement.  You better pass the font and
language information to the outside renderer to get the proper result.

-- Yoshiki

On Mon, Jun 29, 2009 at 3:07 AM, Douglas
Brebner<[hidden email]> wrote:
But what about being more practical and take the Linux approach: use
the code and,
when and if ever, threatened or suited, remove the affected code and
rewriting it in order
to not infringe copyrights/patents.

Miguel Cobá

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. I can help with Kannada
(U0C80) and Tamil (U0B80) fonts. How was the picture produced?

Subbu

Miguel Cobá wrote: That's pretty much what they did except...
Firstly, it was almost *all* of the code potentially at risk (it was the
code they got from the university that was at issue).
Secondly, removing the tainted files required manual surgery to their
CVS repository.

2009/6/28 Klaus D. Witzel <[hidden email]>:
> ....
> I asked for existing apps who need it.

I'll give you an example:
A Swiss person expects monetary amounts to be formatted like this: 1'234.56
A German person expects monetary amounts to be formatted like this: 1.234,56
For each of them, the other format is "wrong". Localization support
would enable you to tell the system: format this number for the locale
the user selected in his profile, without having you to know what the
formatting of this locale is. The same goes for dates.

So the user would be any web application that supports users from more
than one locale and has to display monetary amounts or dates.

> If there is no need, how can I test adding I18-23 support?
> I think you got me wrong.

I think so too.

Cheers
Philippe

2009/6/29 Yoshiki Ohshima <[hidden email]>:
Nope, because in Seaside sometimes we like to compare strings and
#leadingChar is taken into account for #=. And we have to write code
that runs on other systems. And we have to map characters to bytes and
bytes to characters.

>> And don't get me "but we need it for fonts". The only way to get nice
>> fonts in Squeak is to avoid it and do it in C with char*.
>
>  This is a very confused statement.  You better pass the font and
> language information to the outside renderer to get the proper result.

I agree but you don't know how often I have gotten this answer when I
suggested to simply drop #leadingChar.

Cheers
Philippe

2009/6/29 K. K. Subramaniam <[hidden email]>:
> 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. I can help with Kannada
> (U0C80) and Tamil (U0B80) fonts. How was the picture produced?
>

Simple: bring up the morph's halo (workspace) , then click red halo
button - menu,
and then export -> PNG file.

:)

> Subbu
>
>



--
Best regards,
Igor Stasenko AKA sig.

2009/6/28 Klaus D. Witzel <[hidden email]>:
> ...
> goals: render _every_ glyph that is in _any_ modern (Unicode) platform font;
> make fonts offline and online usable, especially on small devices if needed,
> on demand (by end user).

So you have to select the font and you don't select it using #leadingChar?

Cheers
Philippe

At Mon, 29 Jun 2009 07:18:11 +0200,
Philippe Marschall wrote:
  Yeah, but insisting to use #= to do it seems to be a wrong goal
Define seasideEqual: and use it elsewhere would be better.

> And we have to map characters to bytes and bytes to characters.

  Everybody does.  Not sure why it is relevant.

> >> And don't get me "but we need it for fonts". The only way to get nice
> >> fonts in Squeak is to avoid it and do it in C with char*.
> >
> >  This is a very confused statement.  You better pass the font and
> > language information to the outside renderer to get the proper result.
>
> 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.

-- Yoshiki

>>> - Not backward compatible
>
> because, unfortunately, it is a main obstacle for moving forward.
> Or maybe not? Maybe we should start making amazing stuff right now?

I am doing amazing stuff with Squeak right now. I have been doing so for
years.

Now that Pharo provides the non-backward compatible way, which is fine,
I don't understand why the question arises for Squeak once again. Pharo
is the solution, isn't it ? (and I mean it).

Stef

2009/6/29 Stéphane Rollandin <[hidden email]>:
>>>> - Not backward compatible
>>
>> because, unfortunately, it is a main obstacle for moving forward.
>> Or maybe not? Maybe we should start making amazing stuff right now?
>
> I am doing amazing stuff with Squeak right now. I have been doing so for
> years.
>

Then we're putting different meaning in an 'amazing' word.
I can do amazing stuff, but its often requires hacks, workarounds and
other different gotchas,
which i hate to put into my code. And after all of that, fairly, i
can't call it amazing anymore. Can you?

> Now that Pharo provides the non-backward compatible way, which is fine, I
> don't understand why the question arises for Squeak once again. Pharo is the
> solution, isn't it ? (and I mean it).
>

You may feel content about code, which rots there for years, and
no-one even cares rewriting/optimizing/making it better.
But i don't. I don't like sitting on the gas canister and hoping that
next spark will not blow it up.

> Stef
>


--
Best regards,
Igor Stasenko AKA sig.

2009/6/29 Philippe Marschall <[hidden email]>:
> 2009/6/28 Klaus D. Witzel <[hidden email]>:
>> ...
>> goals: render _every_ glyph that is in _any_ modern (Unicode) platform font;
>> make fonts offline and online usable, especially on small devices if needed,
>> on demand (by end user).
>
> So you have to select the font and you don't select it using #leadingChar?
>

Btw, can someone explain me, what is a #leadingChar in Character, and
how it affects the output/input & different encodings/text
representation?


> Cheers
> Philippe
>
>



--
Best regards,
Igor Stasenko AKA sig.

Am 28.06.2009 um 21:07 schrieb Bert Freudenberg:
+1

Markus

The point is that, to me, this question of backward compatibility is not
theoritical. I do have a big amount of code and objects that I will just
have to reimplement if backward compatibility is broken. I mean months
of work, just to keep in sync with this kind of development. And if I
have to do that for each release, well then it would be much easier for
me to stay in 3.8 and maintain my own fork.


Stef

2009/6/29 Stéphane Rollandin <[hidden email]>:
> The point is that, to me, this question of backward compatibility is not
> theoritical. I do have a big amount of code and objects that I will just
> have to reimplement if backward compatibility is broken. I mean months of
> work, just to keep in sync with this kind of development. And if I have to
> do that for each release, well then it would be much easier for me to stay
> in 3.8 and maintain my own fork.
>

So what? Some people keep using even older images.
But in case if you want to stay on the bleeding edge and harvest the
fruits of most cool & advanced stuff, this is always demands a
sacrifices.
So, should people push the brake, just because you can't run at same speed?

>
> Stef
>



--
Best regards,
Igor Stasenko AKA sig.

>> The point is that, to me, this question of backward compatibility is not
>> theoritical. I do have a big amount of code and objects that I will just
>> have to reimplement if backward compatibility is broken. I mean months of
>> work, just to keep in sync with this kind of development. And if I have to
>> do that for each release, well then it would be much easier for me to stay
>> in 3.8 and maintain my own fork.
>>
>
> So what? Some people keep using even older images.

well thank you for driving me out. I guesss I just have to shut up now.


Stef

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!

Janko


> These problems will not happen again in Pharo or Cuis. At least not in
> Cuis.


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si