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

> 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?

> 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.

>> >> 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.
>
>  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 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).
>
>  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.

>
> 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 ?
>  

> 2009/6/29 Igor Stasenko <[hidden email]>:
>> 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?
>
> At some point when rendering text you need to know the language of it.
> You could put this information in a lot of different places like
> paragraph, document, whatever. However since an interned integer on
> Squeak currently has 30bits available and Unicode is a 22bit character
> set why not take that 8 spare bits put that information into each
> character? Yeah, there some minor limitations like there are way more
> than 255 languages in the world and for any latin-1 character you
> wouldn't be able to set the language and if you wanted to use unicode
> you're supposed to set the language of non-Latin1 characters to
> something different than the one of the Latin-1 characters. It could
> kinda work if there was only one image, sort of. These days you'd
> probably use FreeType to get nice text rendering which doesn't need or
> use the information at the character level but anyway.
>
> Now it starts to get funny when you're interacting with the outside
> world. They are not likely to use Squeak so they don't pass language
> information at the character level to you. So what language do you use
> for incoming characters? Well isn't really defined because it never
> really was designed to handle that.
>
> Seaside kinda tends to communicate with the outside world, you see the
> problem? And our code ideally should also run on GemStone, VAST, VW,
> ....
>
> Oh, and the language is of course taken into account for #=. That's
> funny because the strings you get could come from anywhere: database,
> ui, file, .... where you have no control whatsoever over what language
> is used. It could also have been done on a different computer with a
> different language setting.
>

> I've been asked to clarify that the Squeak Oversight Board is paying
> attention to the current discussions.  I had thought that would be
> obvious since several of the Board members have been participating to
> one extent or another (Igor, Andreas, Bert, and Randal for example).
> But it has been pointed out that not everyone is aware of the current
> board members.
>
> If you haven't already you might want to read our last meeting report
> and our upcoming agenda notes for Wednesday:
>
> http://squeakboard.wordpress.com/2009/06/18/meeting-report-for-6172009/
>
> http://squeakboard.wordpress.com/2009/06/19/meeting-agenda-for-712009/
>
> Feel free to propose agenda items.
>
> Ken
>
>
>
>

> But it has been pointed out that not everyone is aware of the current
> board members.
>
> If you haven't already you might want to read our last meeting report
> and our upcoming agenda notes for Wednesday:
>
> http://squeakboard.wordpress.com/2009/06/18/meeting-report-for-6172009/
>
> http://squeakboard.wordpress.com/2009/06/19/meeting-agenda-for-712009/
>
> Feel free to propose agenda items.
>
> Ken
>
>
> ------------------------------------------------------------------------
>
>

> When I look back on the early days, we had a cycle where we would use
> the old system for all it was worth (even with ugly hacks), exploring
> some current set of initiatives, and *then* we would fall back to clean
> things up and integrate what we learned in the latest push.
>
> Maybe that's what's happening now, but I feel the absence of some of
> those big challenges that motivate and reward real progress (not to make
> little of the current efforts).  These could include...
>
>     Take advantage of multicore processors and associated
>     multi-thread OS's in our VM design(s).

> Each of these has high potential impact, and it would be nice to have
> made some real progress in one or two areas before doing a major merge
> or rewrite.  What if you decide to eliminate shared globals; wouldn't
> this be a great time to include that rewrite?  What if shared variables
> turn out to be a great way to synchronize multiple threads in the VM;  
> wouldn't this be a good time to fold that in? Etc.
>
> So this may be the time to reorganize everything, but it also looks to
> me like there is nothing in the way of making some *bold* progress right
> now, and it's likely that the wider perspective achieved in the process
> might inform an even better next system.
>
> That said, don't forget there are good and committed people on both
> sides of this discussion, and your first priority should be how to
> maximize the community.  FWIW I recommend face-to-face discussion. And
> beer.

> Hi Dan!
>
> (Watch out - rambling ahead)
>
> Long time no hear. :)
>
> Dan Ingalls wrote:
>>
>> Good people -
>>
>> Whatever the impetus, it's good to see this recent spate of
>> self-examination.
>
> Yep, indeed.
>
>> When I look back on the early days, we had a cycle where we would use the
>> old system for all it was worth (even with ugly hacks), exploring some
>> current set of initiatives, and *then* we would fall back to clean things up
>> and integrate what we learned in the latest push.
>>
>> Maybe that's what's happening now, but I feel the absence of some of those
>> big challenges that motivate and reward real progress (not to make little of
>> the current efforts).  These could include...
>>
>>    Take advantage of multicore processors and associated
>>    multi-thread OS's in our VM design(s).
>
> Yeah, I am unsure if Cog has anything in this area. We do have the Hydra
> base, and personally I am quite impressed that Huemul actually has native
> POSIX thread == Process!
>
> I presume the "perfect" setup is green Processes running on a pool of native
> threads. Thus preserving the "light weight" of Process and still be able to
> utilize cores.
>
> I also would like to note that while it would be COOL to be able to scale on
> cores - the *reality* is that most apps we write in Squeak that *needs* to
> scale is typically web apps. And you scale web apps horisontally using
> multiple VMs and a load balancer, no big deal.
>
> So it doesn't really matter how cool it would be - it is not a "killer"
> feature IMHO.
>
> But the scalability of Erlang would open up new frontiers. :)
>
>>    Demonstrate real ease of use in tapping that new
>>    dimension of performance.  Linda and E are relevant.
>>
>>    Press at least one good JIT design through to completion
>>    document it, and keep it alive on every platform.
>
> I presume Cog is our hope? The latest "news" in this area is that Eliot
> mentioned he is looking closer at the JIT in Factor (factorcode.org) and
> even considers porting it! And lots of JIT libs around these days, Nanojit
> in Tracemonkey, libJIT etc etc.
>
> But one thing is true - performance *kicks ass*. We may go on and on about
> how "unimportant" performance is but darnit, it really is a killer feature
> if we had a REAL fast VM whupping the Pyhon/Rubys. ;)
>
>>    Make it easy to produce Squeak apps for the iPhone
>>    and similar platforms for which it seems so perfect.
>
> Mmmm, most such platforms have their "own" UI which you really need to
> adhere to. I think simple interpreters that very easily can play with
> external libs have the upper hand here. Think Python.
>
>>    Bring Squeak to life in browsers.
>>    OMeta + V8 + Canvas = Squeak everywhere, including
>>    behind firewalls and where installation is prohibited
>
> Cool yes. Killer feature? Nope, don't think so.
>
>>    Get serious about security.  Take another look at ESqueak
>>    and figure how to make it just a bit simpler
>
> Doesn't make me drool. :)
>
>>    Along the same lines, make it easy for Squeak to rule
>>    the cloud.
>
> Ah, *that* one is more like it. Not sure HOW, but i do agree that the Cloud
> (in whichever shape or form) is coming.
>
> One thing I have noted as a consultant is that almost EVERY customer now
> runs virtual hardware. In Sweden almost always VMWare. And this actually
> benefits us - the customer just wants an "appliance". They often don't care
> what it is written in.
>
> If Squeak could offer something unique in this arena... but I fail to see
> what that could be :)
>

>> Each of these has high potential impact, and it would be nice to have made
>> some real progress in one or two areas before doing a major merge or
>> rewrite.  What if you decide to eliminate shared globals; wouldn't this be a
>> great time to include that rewrite?  What if shared variables turn out to be
>> a great way to synchronize multiple threads in the VM;  wouldn't this be a
>> good time to fold that in? Etc.
>>
>> So this may be the time to reorganize everything, but it also looks to me
>> like there is nothing in the way of making some *bold* progress right now,
>> and it's likely that the wider perspective achieved in the process might
>> inform an even better next system.
>>
>> That said, don't forget there are good and committed people on both sides
>> of this discussion, and your first priority should be how to maximize the
>> community.  FWIW I recommend face-to-face discussion. And beer.
>
> Beer is good. Too bad we are so darn spread out.
>
>>    - Dan
>
> regards, Göran
>
>
>

> At Mon, 29 Jun 2009 22:30:31 +0300,
>
> Igor Stasenko wrote:
> > So, do i understood you right: this information (leadingChar) could be
> > useful sometimes.
> > But real world examples showing that its completely useless , at least
> > by now. And often only adds an unnecessary complexity & confusion in
> > handing a text & communicating with world outside the Squeak.
>
>   Well, but Squeak in Chinese/Japanese/Korean have been using it and
> depending on it, so this characterization is not correct.

> At Mon, 29 Jun 2009 11:13:24 +0200,
> Paolo Bonzini wrote:
>> 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.
>
>    As Eliot wrote, an interactive environment has different constraint.
> #at: is one of them, and $- notation for specifying a character
> etc. (say print-it for it should print something) should provide some
> workable solution.