headers
Yoshiki Ohshima | 1 Jul 01:06
Gravatar

Re: Re: Sq font rendering [was: The future of Squeak & Pharo ... etc]

At Tue, 30 Jun 2009 13:16:54 +0530,
K. K. Subramaniam wrote:
> 
> On Tuesday 30 Jun 2009 3:09:15 am Yoshiki Ohshima wrote:
> > 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.
> The essential problem is the encoding of characters (graphemes) which have 
> regional or lingual variations. Devanagari also has such examples. The 
> grapheme 'a' is rendered differently in Bombay and in Calcutta. Should the 
> variations be encoded in the context or in every grapheme codepoint?

  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".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paolo Bonzini | 1 Jul 01:11
Picon
Gravatar

Re: #leadingChar (Re: The future of Squeak & Pharo))

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
Permalink | Reply | 2 comments |
headers
Yoshiki Ohshima | 1 Jul 01:34
Gravatar

Re: Re: #leadingChar (Re: The future of Squeak & Pharo))

At Wed, 01 Jul 2009 01:11:33 +0200,
Paolo Bonzini wrote:
> 
> 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.

  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.^^;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eliot Miranda | 1 Jul 02:48
Picon

Re: Re: Future of Squeak, and outsider's view



On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <stephen <at> pairhome.net> wrote:
On Tue, Jun 30, 2009 at 3:00 PM, Eliot Miranda <eliot.miranda <at> gmail.com> wrote:

 But as I've said earlier in the thread the extensional approach has problems when it comes to managing multiple packages that can overlap (as I think s inevitable in imperfect complex systems).  

I realize this thread is more concerned with the here and the now, but doesn't this problem go away entirely in a system like Newspeak?  When you can have modules of code co-resident and active at the same time, wouldn't you just create a new version of some package on which you depend rather than patch it with extension methods you define in your own package?  Your code would happily use your version of the package while others happily use the unmodified version.

In theory yes.  But as soon as one had a living system which contained objects already active then I don't see how the Newspeak module system solves the problem.  It neatly allows one to reuse modules and extend them locally.  But as far as I can see once you want to interact in new ways with already live objects then one may still need to patch.

Gilad is virulently against monkey-patching and so there is no support for extensions in Newspeak modules; all very well.  But at the same time one of the models of use for Newspeak is where clients implemented in Newspeak are orthogonally synchronised (both data and code are updated) at suitable points in an applications' use (e.g. when a server interaction is initiated).  Here the author of a module is allowed to modify it and the next time any client containing an instance of that module would have the client's instance of the module updated transparently.  So in a situation where some rich application on the client is composed of two modules, and the author of one of them wants an extension method added to the other so that his modifications can function one would have to request the author of the other module to add it and (presumably) wait for changes to propagate.  There are lots of issues here (what if the author of the second module goes bust) but if the picture can be realised its actually much better than the Smalltalk package status quo because every instance is continuously integrated.  One of the issues that gives rise to the need for patches is that one can't ask the author to update their package and so one has to do it oneself.  Gilad's scheme is a great idea, but I'm not entirely sure it is that different from the current situation with automatically updated software (OSs etc).  As the software gets more complex so organizations are less able to change it frequently.  Newspeak may have some new means with which to attack the problem but the problem still remains.

 I can see a potential need in cases where a body of code is designed to interface with some already present service (for example, a phone dialer application designed to use an AddressBook service).  But, in such a system, you wouldn't want to allow monkey patching anyway out of security concerns (if you could override the AddressBook interface, your code could potentially access information that the owner didn't want your code to access).

But how do you override your own AddressBook?  Bringing a new one into existence is one thing, but modifying your fully-populated one implemented by someone else is another thing altogether.  If the system is so architected then it is presumably trivial to create a new instance, move the data across and replace the old with the new.  But if the system isn't (e.g. for security or ip concerns) then you can't.  But these issues operate at a higher level than the language/module/update level right?  The issues with monkey patching are to do with keeping software maintainable and comprehensible to software authors.  The issues of mutable extensible systems also involve their users, and that's more than I can think about right now :)

 

- Stephen 
Permalink | Reply | 5 comments |
headers
Stephen Pair | 1 Jul 03:15
Gravatar

Re: Re: Future of Squeak, and outsider's view



On Tue, Jun 30, 2009 at 8:48 PM, Eliot Miranda <eliot.miranda <at> gmail.com> wrote:
On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <stephen <at> pairhome.net> wrote:

 I can see a potential need in cases where a body of code is designed to interface with some already present service (for example, a phone dialer application designed to use an AddressBook service).  But, in such a system, you wouldn't want to allow monkey patching anyway out of security concerns (if you could override the AddressBook interface, your code could potentially access information that the owner didn't want your code to access).

But how do you override your own AddressBook?  Bringing a new one into existence is one thing, but modifying your fully-populated one implemented by someone else is another thing altogether.  If the system is so architected then it is presumably trivial to create a new instance, move the data across and replace the old with the new.  But if the system isn't (e.g. for security or ip concerns) then you can't.  But these issues operate at a higher level than the language/module/update level right?  The issues with monkey patching are to do with keeping software maintainable and comprehensible to software authors.  The issues of mutable extensible systems also involve their users, and that's more than I can think about right now :)

Overriding your own AddressBook would be a problem of loading in new code and migrating the instances (pretty much like software works today where you load a new version of an application and it has to update your existing database(s)).  So, the new code would have whatever fancy new stuff you wanted to do in your AddressBook, but for external applications like the phone dialer to be able to interact with it, it would still need support some defined (and ideally versioned) interface.  To the degree that new versions of the phone dialer and the address book are backward compatible with the versions of the interface they support, you are free to upgrade each independently.  And, the AddressBook is free to use some highly customized collections framework while the phone dialer uses an entirely different implementation of collections.  Such a system would offer very significant benefits to a community like squeak.  Imagine being able to able to run squeak 2.0 and squeak 3.10 concurrently (with them able to communicate with each other) and imagine all the old, abandoned, but still useful projects that could be readily used without the need to migrate them to all the latest version of your favorite fork.  I don't see these issues as being at some higher level, I see the language and platform as lacking a much needed capability.

(btw, none of this necessarily implies everything must be in a single process, I imagine much of this could be accomplished using hydra for instance)

- Stephen
Permalink | Reply | 4 comments |
headers
Keith Hodges | 1 Jul 04:37
Picon
Favicon
Gravatar

[Ann] Packages updated

Hello All,  (subject to squeaksource returning to life sometime today)

I have just updated Sake/Packages in order to simplify it while
retaining the same functionality.

In addition we enable projects which define their own package
definitions to be included. For example my seaside "Beach" project
maintains its own set of definitions, dependencies and documentation in
the package "Beach-Packages"

The goal is for Sake/Packages in Packages-Library (and similar packages)
to be able to maintain a list of every package, and what works where, in
a form that is easily browsable and editable. The same mechanism is
designed to be able to work for squeak, pharo, cuis, etoys, cobalt.
Sake/Packages simply uses existing code browsing tools, and is not
reliant upon a GUI.

There is one thing that I agree with Edgar on, and that is that I think
we do need Package Czar's, to maintain and test these package
definitions for the common good.

Any volunteers?

Keith
Permalink | Reply | 1 comment |
headers
rkrock | 1 Jul 05:27

Re: [Ann] Packages updated

Out of curiosity, any idea how this compares with the work Dale Hendrichs
is doing with 'metacello' for Gemstone?

> Hello All,  (subject to squeaksource returning to life sometime today)
>
> I have just updated Sake/Packages in order to simplify it while
> retaining the same functionality.
>
> In addition we enable projects which define their own package
> definitions to be included. For example my seaside "Beach" project
> maintains its own set of definitions, dependencies and documentation in
> the package "Beach-Packages"
>
> The goal is for Sake/Packages in Packages-Library (and similar packages)
> to be able to maintain a list of every package, and what works where, in
> a form that is easily browsable and editable. The same mechanism is
> designed to be able to work for squeak, pharo, cuis, etoys, cobalt.
> Sake/Packages simply uses existing code browsing tools, and is not
> reliant upon a GUI.
>
> There is one thing that I agree with Edgar on, and that is that I think
> we do need Package Czar's, to maintain and test these package
> definitions for the common good.
>
> Any volunteers?
>
> Keith
>
>
>
>
Permalink | Reply | 0 comments |
headers
Ramon Leon | 1 Jul 06:19

Re: Usability and look-and-feel (was Re: The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean))

> Bert, are you serious?
>
> Enough with the children! It's been done and redone and overdone. The
> past and the future confounded. Why can't we live the present living?
> You're talking about something that might (or might not) produce
> engineers in the next, say, 20 years? Smalltalk will be around 50
> years by then. I find it painful that our community wouldn't be a
> little bit more practical, for a change..
>
> Right here, right now.
>
> Ian.
>
> PS: I am so sorry... I don't even have spare children to furiously
> train on Squeak...
>
> --
> http://mecenia.blogspot.com/

+10

Seriously, stop talking about kids, who cares, I'll be retired by the
time they're useful.  Programming languages are tools that are
primarily used by and useful for adults, they should be aimed at
adults.  I want Smalltalk to be usable now, not at some unspecified
time in some imaginary future where it takes over the world by getting
kids before they've been introduced to other environments.  It's pure
fantasy to think this'll happen, it won't.  This is the attitude that
holds Squeak back and prevents anyone from taking it too seriously.
This is why Pharo will continue to steal mind-share and Squeak will
die.

Ramon Leon
http://onsmalltalk.com
Permalink | Reply | 41 comments |
headers
Igor Stasenko | 1 Jul 06:28
Picon

Re: Usability and look-and-feel (was Re: The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean))

2009/7/1 Ramon Leon <ramon.leon <at> allresnet.com>:
>> Bert, are you serious?
>>
>> Enough with the children! It's been done and redone and overdone. The
>> past and the future confounded. Why can't we live the present living?
>> You're talking about something that might (or might not) produce
>> engineers in the next, say, 20 years? Smalltalk will be around 50
>> years by then. I find it painful that our community wouldn't be a
>> little bit more practical, for a change..
>>
>> Right here, right now.
>>
>> Ian.
>>
>> PS: I am so sorry... I don't even have spare children to furiously
>> train on Squeak...
>>
>> --
>> http://mecenia.blogspot.com/
>
> +10
>
> Seriously, stop talking about kids, who cares, I'll be retired by the
> time they're useful.  Programming languages are tools that are
> primarily used by and useful for adults, they should be aimed at
> adults.  I want Smalltalk to be usable now, not at some unspecified
> time in some imaginary future where it takes over the world by getting
> kids before they've been introduced to other environments.  It's pure
> fantasy to think this'll happen, it won't.  This is the attitude that
> holds Squeak back and prevents anyone from taking it too seriously.
> This is why Pharo will continue to steal mind-share and Squeak will
> die.
>

+10.
Let us separate the domains:
1. Squeak for developers who need a modern & sound smalltalk
environment which fullfills their needs and
2. Squeak for teachers/children/endusers who will use a wonderfull
environment produced by software engineers.

If you don't have 1st, you can't progress in 2nd, because obviously
developers do not like sitting in child room and pretend that they are
sitting in the lab.

> Ramon Leon
> http://onsmalltalk.com
>
>

--

-- 
Best regards,
Igor Stasenko AKA sig.
Permalink | Reply | 0 comments |
headers
Andreas Raab | 1 Jul 09:10
Picon
Picon

MCM update script

Folks -

I've set up a little test for the suggested MCM update script via 
Monticello. In order to try it out, do the following:
* Get a copy of http://ftp.squeak.org/3.10/Squeak3.10-7159-basic.zip
* Fire up Monticello and point it at http://squeaksource.com/MCUpdateTest
* Load the latest MonticelloConfigurations package from there and ONLY 
that package (the fixes included are a strict prerequisite for this to work)

Now run the following code:

	MCMcmUpdater updateFromRepositories: #(
		'http://squeaksource.com/MCUpdateTest'
	).

This will go to the repository and discover that there is 
update-ar.1.mcm and update-ar.2.mcm. It will load the first, find that 
there is nothing to do, move on to the second. The second has actually 
re-ordered the Exceptions and the Morphic package to allow for loading 
of a modification enabling SystemProgressMorph to change its label. It 
then uses the configuration to update all the remaining listed packages 
(and you can see the effect of the updated label right away).

If we'd find that at some point the order needs to be changed to be able 
to load a particular modification, we would just issue an update.mcm 
with the new order.

Hope this illustrates what I am imagining for an update mechanism using 
Monticello.

Cheers,
   - Andreas
Permalink | Reply | 7 comments |

Gmane