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

On Tue, 30 Jun 2009 09:56:38 +0200, Paolo Bonzini wrote:

> On 06/30/2009 12:02 AM, Yoshiki Ohshima wrote:
...
>>    I think a future version basically shouldn't try to "print" a
>> Chararacter, but print out the code point and to display a character,
>> you do have to supply the extra infomation.  (Character object is
>> convenient, but you can go with all String objects, if you like.)
>
> Exactly my point.  When you know a language you can go with String  
> objects and then you can avoid #leadingChar.

Sorry for disturbing your circles, guys. But replacing a leading char by  
another sequence of chars ? what would be the purpose (other than the fun  
of it) ?

Paolo, since 1999 RFC 2482 awaits formal acceptance, so it does not really  
address any urgent need nor really solves a critical problem ?

Also, RFC 2428 was specifically designed for _transfer_ protocols which  
want in-bound language tag information.

Besides of that, RFC2428 cannot do without Unicode (but Unicode encodes  
scripts, not languages, so apps cannot be compatible without costly  
changes).

So why would I want to have a transfer encoding in my storage encoded  
image, a transfer encoding that eats up space in stored strings, and does  
not work with 8bit strings but requires wide strings ?

Perhaps I'm missing something ?

/Klaus

> Paolo
>



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

> Paolo, since 1999 RFC 2482 awaits formal acceptance, so it does not
> really address any urgent need nor really solves a critical problem ?

Not really.  I cited RFC2482 because it was the first link I found, but
plane 14 language tags are part of Unicode 3.1 and later.  Regarding the
importance of the problem, Unicode experts are split 50-50 (though with
significant variations according to their nationality).  I'm not
disputing that anyway, just that the leadingChar is not an appropriate
solution.

Paolo

On Tue, 30 Jun 2009 12:20:42 +0200, Paolo Bonzini wrote:

>
>> Paolo, since 1999 RFC 2482 awaits formal acceptance, so it does not
>> really address any urgent need nor really solves a critical problem ?
>
> Not really.  I cited RFC2482 because it was the first link I found, but  
> plane 14 language tags are part of Unicode 3.1 and later.  Regarding the  
> importance of the problem, Unicode experts are split 50-50 (though with  
> significant variations according to their nationality).  I'm not  
> disputing that anyway,

Ah, thanks, understand.

/Klaus

> just that the leadingChar is not an appropriate solution.
>
> Paolo
>

Dan Ingalls wrote:
>
> 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.

Great idea! We can have lots of face time (and beer) at Squeakfest in
L.A. (August 10-12). There will be a technical track (Eliot is giving a
talk) and you're all invited to come by :)

Rita
>
>     - Dan
>


--
Rita Freudenberg
Squeakland Foundation
http://www.squeakland.org

At Tue, 30 Jun 2009 09:56:38 +0200,
Paolo Bonzini wrote:
>
> #at: is not one of them, language tags should not be skipped just like
> soft hyphens (U+00AD, also known as hyphenation hint) should not.

  If #at: should return a printable character, then the resulting
character (really a String) with proper language tag(s) externally
associated should be returned from #at:.  And you need to look for the
tag, right?  And #at:put:, (or replaceFrom:to:...), putting a String
with language tag externally associated would modify somewhere other
than specified in the string, too (and may change the length).  That
would be really tricky.

> >    I think a future version basically shouldn't try to "print" a
> > Chararacter, but print out the code point and to display a character,
> > you do have to supply the extra infomation.  (Character object is
> > convenient, but you can go with all String objects, if you like.)
>
> Exactly my point.  When you know a language you can go with String
> objects and then you can avoid #leadingChar.

  You can, but it is a real major change and good luck.

-- Yoshiki

At Tue, 30 Jun 2009 09:56:38 +0200,
Paolo Bonzini wrote:
>
> #at: is not one of them, language tags should not be skipped just like
> soft hyphens (U+00AD, also known as hyphenation hint) should not.

  If #at: should return a printable character, then the resulting
character (really a String) with proper language tag(s) externally
associated should be returned from #at:.  And you need to look for the
tag, right?  And #at:put:, (or replaceFrom:to:...), putting a String
with language tag externally associated would modify somewhere other
than specified in the string, too (and may change the length).  That
would be really tricky.

> >    I think a future version basically shouldn't try to "print" a
> > Chararacter, but print out the code point and to display a character,
> > you do have to supply the extra infomation.  (Character object is
> > convenient, but you can go with all String objects, if you like.)
>
> Exactly my point.  When you know a language you can go with String
> objects and then you can avoid #leadingChar.

  You can, but it is a real major change and good luck.

-- Yoshiki

On Tue, 2009-06-30 at 00:59 +0200, Göran Krampe wrote:
Exupery development is still continuing though the rest of this year is
likely to be slow but speeding up as the months go by. The current task
is dynamically inlining methods.

Bryce

At Tue, 30 Jun 2009 13:16:54 +0530,
K. K. Subramaniam wrote:
  Well, don't you rather say Mumbai and Kolkata?

> leadingChar is just one way to resolve such variations. Personally, I prefer
> handling such variations as part of the context. A grapheme is a notional
> element. We need to encode it so that we can input, calculate, combine,
> compare and sort notional elements. Visual appearance becomes important only
> for manual edit and print operations.

  I guess I understand your point, but not sure what you would do to
implement "encode in the context".

-- Yoshiki

On 06/30/2009 07:33 PM, Yoshiki Ohshima wrote:
> At Tue, 30 Jun 2009 09:56:38 +0200,
> Paolo Bonzini wrote:
>> #at: is not one of them, language tags should not be skipped just like
>> soft hyphens (U+00AD, also known as hyphenation hint) should not.
>
>    If #at: should return a printable character, then the resulting
> character (really a String) with proper language tag(s) externally
> associated should be returned from #at:.

No, characters are characters are characters.  They should not have any
language tag.  The language tag, if of anything, could be returned as
part of the style if you're working on a Text.  The default language tag
could be extrapolated from the current user's locale.

>    You can, but it is a real major change and good luck.

I'm not planning to do this of course.  I'm just saying that there are
other possibilities that (as Philippe pointed out) collaborate better
with the rest of the Unicode world.  Maybe starting from a clean slate
without #leadingChar, and working things out from there, would be better
than forcing Han-disunification down the throat.

Paolo

At Wed, 01 Jul 2009 01:11:33 +0200,
Paolo Bonzini wrote:
  Yeah, so that is why I would say, printing a character would display
just a number is even sensible.

  But what about my question in regards to #at:put: and
#replaceFrom:to?  Do you think it is feasible, if the tag is in the
string as well?

> >    You can, but it is a real major change and good luck.
>
> I'm not planning to do this of course.

  I'm not mistaken about it.^^;

> I'm just saying that there are
> other possibilities that (as Philippe pointed out) collaborate better
> with the rest of the Unicode world.

  Yes.

> Maybe starting from a clean slate
> without #leadingChar, and working things out from there, would be better
> than forcing Han-disunification down the throat.

  Maybe.  That would be an approach, but that wouldn't have been
considered Squeak.

-- Yoshiki

On 07/01/2009 01:34 AM, Yoshiki Ohshima wrote:
>    But what about my question in regards to #at:put: and
> #replaceFrom:to?  Do you think it is feasible, if the tag is in the
> string as well?

I would just hope that the user knows what he's doing (I do think the
spec would be improved by having a PUSH/POP mechanism for language tags,
which would fix this problem in another way).  It's not different from
inserting a character after a decomposed accent.

The language tag would be just a detail in converting to Unicode for the
outside world, I would keep language information in styles internally so
that Text's handling would just work.

The last famous words.

Paolo

Hi Bryce!

Bryce Kampjes wrote:
I deliberately didn't mention your work because I didn't want to put
pressure and since Cog was slated for this summer (I think) I guess Cog
may deliver before Exupery starts to deliver in earnest.

But inlining of methods sounds like it could be a booster, right?

regards, Göran

Dan Ingalls wrote:
> 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.
>
I admit to being bemused that even the most radical people are
essentially proposing something that's essentially a "modern system but
a bit nicer". Is anyone working on something as advanced over current
systems as the original Smalltalk was over its contemporaries?

> 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.
>
I feel the Pharo people deserve a beer for lighting a fire under the
Squeak community and getting people motivated :)

Douglas Brebner wrote:
>
> I feel the Pharo people deserve a beer for lighting a fire under the
> Squeak community and getting people motivated :)
>  
The Squeak community was motivated before Pharo, and lots of work has
been done in the past couple of years outside of Pharo to improve squeak
for use in a commercial environment. My own contribution to this includes:

Installer - DSL for building images
SUnit-improved
SSpec
TestReporter - Text based SUnit runner
MC1.5 - merge of all forks of MC
MC1.5 Orphanage - out of order loading
MC1.5 - extensions and overrides actually work.
MC1.6 - initial coding for Atomic Loading
Sake - aka. make/rake for squeak
Sake/Packages - replace universes
Bob1 (in ruby)
Sake/Bob - automatic build/test server
Logging
LevelPlayingField

If that lot don't constitute motivation, I don't know what does.

What pharo managed to do was demotivate several people who had
contributed, and their contributions were summarily ignored.

For example, I regard the fact that Pharo started with 3.9 when there
was no reason why they could not have started with 3.10, as a
significant insult to Edgar and the rest of us that put lots of effort
into 3.10.

As a second example I consider the fact that Pharo refuses to adopt or
contribute to MC1.5 with a view to adoption. MC1.5 included a merge of
several MC forks, and common tools are essential for cross fertilisation
within the community. I take their actions as a demonstration that they
are not interested in being community players or working with any
broader community vision that I we or anyone might propose.

We had a golden opportunity for the community to work together on the
important tools, and the Pharo guys will not play ball, they will not
join with any vision other than their own. This has the effect of
DEMOTIVATING folks like myself who would like to see all of the
community work together, and have been working towards that end for over
3 years.

They will not contribute to any of the above projects that are
maintained in public repositories as a community resource. Instead they
retain their own forks of SUnit and MC, etc.

This has driven me to the point of not being motivated to continue to
contribute to MC, because the Pharo team are effectively vetoing the
adoption of any future enhancements.  I cannot take pharo seriously as a
commercial development tool, when it uses MC1 which doesn't cope with
method extensions or overrides. (fine if you are in you ivory tower and
writing your own code from scratch, but a nightmare if you try to patch
up and maintain code that is not your own)

In summary, I have regrettably discovered and continue to maintain that
the attitude of the Pharo team is very rude indeed. I have pondered
whether this is a cultural thing (i.e. traditionally the French and
English don't get along). I have discussed it with my non coding friends
and others and I have not managed to come to any other constructive
conclusion.

So in conclusion, I personally regard pharo as a small academic research
project being carried out on behalf of the smalltalk community. It's
only valuable output will be the MIT licenced code that they produce.
The lack of social skills in the pharo team is only surpassed by my own.
As such this renders the pharo vision useless to any bigger concept of
shared objective or values, and that's what I think squeak is really all
about.

Keith

Keith Hodges wrote: I'm well aware that there are motivated individuals. I was referring to
the community as a whole.
> What pharo managed to do was demotivate several people who had
> contributed, and their contributions were summarily ignored.
>
>  
It has motivated some people who were not contributing to do so too.
> As a second example I consider the fact that Pharo refuses to adopt or
> contribute to MC1.5 with a view to adoption. MC1.5 included a merge of
> several MC forks, and common tools are essential for cross fertilisation
> within the community. I take their actions as a demonstration that they
> are not interested in being community players or working with any
> broader community vision that I we or anyone might propose.
>
>  
Didn't Matthew Fulmer say he was going to be working on this?

Hi Keith,
I understand some of your bitterness, but I think that's the destiny
of who involves in this community:
doing the hard work is hardly ever encouraged, and you get promptly
bashed for what does not work.

2009/7/1 Keith Hodges <[hidden email]>:
You make a point here.
Pharo did have to redo most of (all ?) 3.10 anyway, that's a lost of time.

> As a second example I consider the fact that Pharo refuses to adopt or
> contribute to MC1.5 with a view to adoption. MC1.5 included a merge of
> several MC forks, and common tools are essential for cross fertilisation
> within the community. I take their actions as a demonstration that they
> are not interested in being community players or working with any
> broader community vision that I we or anyone might propose.
>

Things are not definitive. They can still adopt MC1.5.
On the other hand, there is also MC1.6 without Trait support and
MC2.0... So it might still be urgent to wait. Even if Pharo resources
are growing, there are still sparse wrt their own goals.

Also don't forget Pharo team wanted a solid base for starting rapidly,
and I perfectly understand that they preferred a less powerfull well
known solution from which they already knew the limitations to an
advanturous new one not completely stabilized, or at least unknown.

> We had a golden opportunity for the community to work together on the
> important tools, and the Pharo guys will not play ball, they will not
> join with any vision other than their own. This has the effect of
> DEMOTIVATING folks like myself who would like to see all of the
> community work together, and have been working towards that end for over
> 3 years.
>

Your work is valuable and is not lost. Things are not changing as fast
as we want it...

> They will not contribute to any of the above projects that are
> maintained in public repositories as a community resource. Instead they
> retain their own forks of SUnit and MC, etc.
>

That's a temporary pragmatic choice. They want to have control over
the process and cannot depend on too many thrid party hypothetic
achivements.

> This has driven me to the point of not being motivated to continue to
> contribute to MC, because the Pharo team are effectively vetoing the
> adoption of any future enhancements.  I cannot take pharo seriously as a
> commercial development tool, when it uses MC1 which doesn't cope with
> method extensions or overrides. (fine if you are in you ivory tower and
> writing your own code from scratch, but a nightmare if you try to patch
> up and maintain code that is not your own)
>

Hmm. IMO Maintaining code you don't own is a dead end anyway.
If that code evolves out of your control, then you get unwanted work
flowing and being downstream is not comfortable...
I experienced this with st-80/Objectworks because I deeply modified
the system...
(keyboard short cut, alternate fonts/emphasis, localization, bubble
help, code formatting etc...)

> In summary, I have regrettably discovered and continue to maintain that
> the attitude of the Pharo team is very rude indeed. I have pondered
> whether this is a cultural thing (i.e. traditionally the French and
> English don't get along). I have discussed it with my non coding friends
> and others and I have not managed to come to any other constructive
> conclusion.
>

Yes, you can take it as selfish, but I don't see anything cultural
here, and I doubt Pharo is only a french thing.

That's already something.
Or isn't the greatest output to shake this community?

Nicolas

On Wed, 2009-07-01 at 13:57 +0200, Göran Krampe wrote:
It should be a major gain but more urgently it'll allow me to decide
whether Eliot's stack VMs make sense with Exupery. Dynamic inlining may
remove enough sends so that the extra complexity of the stack VM isn't
justified. Dynamic inlining may also create de-optimisation problems
that are well solved by using the stack VM's context caching.

Implementing dynamic inlining will allow that decision to be informed by
running code.

Also the last bug fixes have improved reliability enough that starting
work on dynamic inlining is sensible.

Bryce

> In summary, I have regrettably discovered and continue to maintain that
> the attitude of the Pharo team is very rude indeed. I have pondered
> whether this is a cultural thing (i.e. traditionally the French and
> English don't get along). I have discussed it with my non coding friends
> and others and I have not managed to come to any other constructive
> conclusion.

Hey, I'm french :)

All frogs don't live in the same pond...

Stef

2009/7/1 Stéphane Rollandin <[hidden email]>:
> All frogs don't live in the same pond...

...but they all blow up with a cigarette!

Just kidding! =)

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