December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] layoutChanged call too much ?

by Nicolai Hess

2015-12-09 15:13 GMT+01:00 Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com>: > Hi, > > I wanted to execute an action each time we resize some window and I > wanted to see easily if the method layoutChanged is call each time we > resize it. > > To test that I added Â«Transcript crShow: DateAndTime now asStringÂ» > inside the method TransforMorph>>#layoutChanged. I wanted to resize a > TransformMorph and check the transcript. But went I opened the > Transcriptâ¦ Surprise ! I had a lot of lines. > > I did the same in a new image of Pharo 5 and even with only 2 > TransformMorph in the image there is A LOT of call to the method all the > time. > > Is that normal ? > I thnk the Transcript scroller uses a TransformMorph as well. > > Here an example: http://s11.postimg.org/n4rtz6xm9/Pharo_Screenshot.png > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

Dec. 9, 2015

layoutChanged call too much ?

by Ferlicot D. Cyril

Hi, I wanted to execute an action each time we resize some window and I wanted to see easily if the method layoutChanged is call each time we resize it. To test that I added Â«Transcript crShow: DateAndTime now asStringÂ» inside the method TransforMorph>>#layoutChanged. I wanted to resize a TransformMorph and check the transcript. But went I opened the Transcriptâ¦ Surprise ! I had a lot of lines. I did the same in a new image of Pharo 5 and even with only 2 TransformMorph in the image there is A LOT of call to the method all the time. Is that normal ? Here an example: http://s11.postimg.org/n4rtz6xm9/Pharo_Screenshot.png -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 9, 2015

Re: [Pharo-dev] [squeak-dev] Re: [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: Unicode Support))

by H. Hirzel

Hi Stephan What you mention is an edge case. A regular case which is not implemented yet is language insensitive sorting http://www.unicode.org/versions/Unicode8.0.0/UnicodeStandard-8.0.pdf <citation> In some circumstances, an application may need to do language-insensitive sortingâthat is, sorting of textual data without consideration of language-specific cultural expectations about how strings should be ordered. </citation> This is currently not the case as there is no normalization. As the Unicode Character Database [1] is already available in Squeak / Pharo (and could easily be loaded into Cuis) the implementation effort for language-insensitive sorting seems to be in reach without a big effort. [1] http://wiki.squeak.org/squeak/6244 Hannes On 12/9/15, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 08-12-15 22:35, Dale Henrichs wrote: >> What I meant is that you can't _always_ use the code point for >> collation, i.e., sorting based on the value of code points is not always >> correct[1]. > > I have given up on universal sorting when I learned that dutch libraries > sorting of author names depends on the country of origin of the author. > So if Jan van Beek is dutch he will be sorted under B, while if he's > belgian under V. I haven't checked what happens if the author emigrates, > or changes nationality... > > Stephan > > > >

Dec. 9, 2015

Re: [Pharo-dev] How does Nautilus change highlighting for class definitions

by Damien Cassou

Nicolai Hess <nicolaihess(a)gmail.com> writes: > 2015-12-09 14:45 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr>: > > But beware, there are multiple parts involved if you use nautilus code > pane. > - parser for syntax highlighting > - the styler itself > - completion ( you may or may not want to have NEC to popup the completion > menu) > - class / method selection dependent menu entries (Suggestions for example) > - the acceptor (on accept, a class definition is execute, a method > definition is compiled) thanks to both. > what are ini-modules? it's a tentative replacement for class-side instance creation methods that suffer from a lot of problems. It's a new concept, just like traits and slots, except that it solves the instance creation problems listed at the end of http://smalltalkhub.com/#!/~MarcoNaddeo/IniModules Thanks again -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Dec. 9, 2015

Re: [Pharo-dev] How does Nautilus change highlighting for class definitions

by Skip Lentz

> On Dec 9, 2015, at 2:55 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-12-09 14:45 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr <mailto:skip.lentz@inria.fr>>: > Browse class references to the âNautilusClassSelectedâ Announcement, I see a mention of a method called #showScriptCode: when it subscribes to that announcement, perhaps thatâs the one you need? > This is in contrast with #showSourceCode:, which is used in the subscription of the NautilusProtocolSelected and NautilusMethodSelected announcements. I think the difference lies between those methods. > > the distinction between method and class definition highlighting is done by > AbstractNautilusUI>>setStylerClass: > if it is nil, it treats all code as "smalltalk expressions" > if it is not-nil it treats all code as "method definitionsâ. Ah ok. > But beware, there are multiple parts involved if you use nautilus code pane. > - parser for syntax highlighting > - the styler itself > - completion ( you may or may not want to have NEC to popup the completion menu) > - class / method selection dependent menu entries (Suggestions for example) > - the acceptor (on accept, a class definition is execute, a method definition is compiled) Yes but if he just adds his own announcement such as âNautilusIniModuleSelectedâ and subscribes to it in addition to "NautilusClassSelected" it should be fine no? > what are ini-modules? Link: http://smalltalkhub.com/#!/~MarcoNaddeo/IniModules <http://smalltalkhub.com/#!/~MarcoNaddeo/IniModules>. But probably Marco and/or Damien can answer that better. > > > > On Dec 9, 2015, at 2:16 PM, Damien Cassou <damien.cassou(a)inria.fr <mailto:damien.cassou@inria.fr>> wrote: > > > > Hi, > > > > in short: in which method is Nautilus adapting source-code highlighting > > based on the selection (class or method)? > > > > slightly longer: With Marco Naddeo we wanted to add ini-modules to > > Nautilus. Because an ini-module definition is a Smalltalk expression > > (just like a class definition), we want Nautilus to do source-code > > highlighting of an ini-module the same way it does for class > > definitions. How is Nautilus changing the source-code highlighting > > process depending on the selection (class or method)? > > > > > > Thank you > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/> > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." --Winston Churchill > > > > >

Dec. 9, 2015

Re: [Pharo-dev] How does Nautilus change highlighting for class definitions

by Nicolai Hess

2015-12-09 14:45 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr>: > Browse class references to the âNautilusClassSelectedâ Announcement, I see > a mention of a method called #showScriptCode: when it subscribes to that > announcement, perhaps thatâs the one you need? > This is in contrast with #showSourceCode:, which is used in the > subscription of the NautilusProtocolSelected and NautilusMethodSelected > announcements. I think the difference lies between those methods. > the distinction between method and class definition highlighting is done by AbstractNautilusUI>>setStylerClass: if it is nil, it treats all code as "smalltalk expressions" if it is not-nil it treats all code as "method definitions". But beware, there are multiple parts involved if you use nautilus code pane. - parser for syntax highlighting - the styler itself - completion ( you may or may not want to have NEC to popup the completion menu) - class / method selection dependent menu entries (Suggestions for example) - the acceptor (on accept, a class definition is execute, a method definition is compiled) what are ini-modules? > > > On Dec 9, 2015, at 2:16 PM, Damien Cassou <damien.cassou(a)inria.fr> > wrote: > > > > Hi, > > > > in short: in which method is Nautilus adapting source-code highlighting > > based on the selection (class or method)? > > > > slightly longer: With Marco Naddeo we wanted to add ini-modules to > > Nautilus. Because an ini-module definition is a Smalltalk expression > > (just like a class definition), we want Nautilus to do source-code > > highlighting of an ini-module the same way it does for class > > definitions. How is Nautilus changing the source-code highlighting > > process depending on the selection (class or method)? > > > > > > Thank you > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." --Winston Churchill > > > > >

Dec. 9, 2015

Re: [Pharo-dev] How does Nautilus change highlighting for class definitions

by Skip Lentz

Browse class references to the âNautilusClassSelectedâ Announcement, I see a mention of a method called #showScriptCode: when it subscribes to that announcement, perhaps thatâs the one you need? This is in contrast with #showSourceCode:, which is used in the subscription of the NautilusProtocolSelected and NautilusMethodSelected announcements. I think the difference lies between those methods. > On Dec 9, 2015, at 2:16 PM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > Hi, > > in short: in which method is Nautilus adapting source-code highlighting > based on the selection (class or method)? > > slightly longer: With Marco Naddeo we wanted to add ini-modules to > Nautilus. Because an ini-module definition is a Smalltalk expression > (just like a class definition), we want Nautilus to do source-code > highlighting of an ini-module the same way it does for class > definitions. How is Nautilus changing the source-code highlighting > process depending on the selection (class or method)? > > > Thank you > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

Dec. 9, 2015

Re: [Pharo-dev] Unicode Support

by Sven Van Caekenberghe

> On 09 Dec 2015, at 14:16, EuanM <euanmee(a)gmail.com> wrote: > > "To encode Unicode for external representation as bytes, we use UTF-8 > like the rest of the modern world. > > So far, so good. > > Why all the confusion ?" That was a rhetorical question. I know that we lack normalization, we don't need another encoding or representation. Sorting/collation can also be done regardless of encoding or representation. These are orthogonal concerns to the working situation that we have today. > The confusion arises because simply providing *a* valid UTF-8 encoding > of does not ensure sortability, nor equivalence testability. > > It might provide sortable strings. It might not. > > It might provide a string that can be compared to another string > successfully. It might not. > > So being able to perform valid UTF-8 encoding is *necessary*, but *not > sufficient*. > > i.e. the confusion arises because UTF-8 can provide for several > competing, non-sortable encodings of even a single character. This > means that *valid* UTF-8 cannot be relied upon to provide these > facilities *unless* all the UTF-8 strings can be relied upon to have > been encoded to UTF-8 by the same specification of process. i.e. > *unless* it has gone through a process of being converted by *a > specific* valid method of encoding to UTF-8. > > Understanding the concept of abstract character is, imo key to > understanding the differences between the various valid UTF-8 forms of > a given abstract character. > > > Cheers, > Euan > > On 9 December 2015 at 10:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> On 09 Dec 2015, at 10:35, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> >>>> On 8 dic 2015, at 10:07 p.m., EuanM <euanmee(a)gmail.com> wrote: >>>> >>>> "No. a codepoint is the numerical value assigned to a character. An >>>> "encoded character" is the way a codepoint is represented in bytes >>>> using a given encoding." >>>> >>>> No. >>>> >>>> A codepoint may represent a component part of an abstract character, >>>> or may represent an abstract character, or it may do both (but not >>>> always at the same time). >>>> >>>> Codepoints represent a single encoding of a single concept. >>>> >>>> Sometimes that concept represents a whole abstract character. >>>> Sometimes it represent part of an abstract character. >>> >>> Well. I do not agree with this. I agree with the quote. >>> >>> Can you explain a bit more about what you mean by abstract character and concept? >> >> I am pretty sure that this whole discussion does more harm than good for most people's understanding of Unicode. >> >> It is best and (mostly) correct to think of a Unicode string as a sequence of Unicode characters, each defined/identified by a code point (out of 10.000s covering all languages). That is what we have today in Pharo (with the distinction between ByteString and WideString as mostly invisible implementation details). >> >> To encode Unicode for external representation as bytes, we use UTF-8 like the rest of the modern world. >> >> So far, so good. >> >> Why all the confusion ? Because the world is a complex place and the Unicode standard tries to cover all possible things. Citing all these exceptions and special cases will make people crazy and give up. I am sure that most stopped reading this thread. >> >> Why then is there confusion about the seemingly simple concept of a character ? Because Unicode allows different ways to say the same thing. The simplest example in a common language is (the French letter Ã©) is >> >> LATIN SMALL LETTER E WITH ACUTE [U+00E9] >> >> which can also be written as >> >> LATIN SMALL LETTER E [U+0065] followed by COMBINING ACUTE ACCENT [U+0301] >> >> The former being a composed normal form, the latter a decomposed normal form. (And yes, it is even much more complicated than that, it goes on for 1000s of pages). >> >> In the above example, the concept of character/string is indeed fuzzy. >> >> HTH, >> >> Sven >> >> >

Dec. 9, 2015

How does Nautilus change highlighting for class definitions

by Damien Cassou

Hi, in short: in which method is Nautilus adapting source-code highlighting based on the selection (class or method)? slightly longer: With Marco Naddeo we wanted to add ini-modules to Nautilus. Because an ini-module definition is a Smalltalk expression (just like a class definition), we want Nautilus to do source-code highlighting of an ini-module the same way it does for class definitions. How is Nautilus changing the source-code highlighting process depending on the selection (class or method)? Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Dec. 9, 2015

Re: [Pharo-dev] Unicode Support

by EuanM

"To encode Unicode for external representation as bytes, we use UTF-8 like the rest of the modern world. So far, so good. Why all the confusion ?" The confusion arises because simply providing *a* valid UTF-8 encoding of does not ensure sortability, nor equivalence testability. It might provide sortable strings. It might not. It might provide a string that can be compared to another string successfully. It might not. So being able to perform valid UTF-8 encoding is *necessary*, but *not sufficient*. i.e. the confusion arises because UTF-8 can provide for several competing, non-sortable encodings of even a single character. This means that *valid* UTF-8 cannot be relied upon to provide these facilities *unless* all the UTF-8 strings can be relied upon to have been encoded to UTF-8 by the same specification of process. i.e. *unless* it has gone through a process of being converted by *a specific* valid method of encoding to UTF-8. Understanding the concept of abstract character is, imo key to understanding the differences between the various valid UTF-8 forms of a given abstract character. Cheers, Euan On 9 December 2015 at 10:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 09 Dec 2015, at 10:35, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> >>> On 8 dic 2015, at 10:07 p.m., EuanM <euanmee(a)gmail.com> wrote: >>> >>> "No. a codepoint is the numerical value assigned to a character. An >>> "encoded character" is the way a codepoint is represented in bytes >>> using a given encoding." >>> >>> No. >>> >>> A codepoint may represent a component part of an abstract character, >>> or may represent an abstract character, or it may do both (but not >>> always at the same time). >>> >>> Codepoints represent a single encoding of a single concept. >>> >>> Sometimes that concept represents a whole abstract character. >>> Sometimes it represent part of an abstract character. >> >> Well. I do not agree with this. I agree with the quote. >> >> Can you explain a bit more about what you mean by abstract character and concept? > > I am pretty sure that this whole discussion does more harm than good for most people's understanding of Unicode. > > It is best and (mostly) correct to think of a Unicode string as a sequence of Unicode characters, each defined/identified by a code point (out of 10.000s covering all languages). That is what we have today in Pharo (with the distinction between ByteString and WideString as mostly invisible implementation details). > > To encode Unicode for external representation as bytes, we use UTF-8 like the rest of the modern world. > > So far, so good. > > Why all the confusion ? Because the world is a complex place and the Unicode standard tries to cover all possible things. Citing all these exceptions and special cases will make people crazy and give up. I am sure that most stopped reading this thread. > > Why then is there confusion about the seemingly simple concept of a character ? Because Unicode allows different ways to say the same thing. The simplest example in a common language is (the French letter Ã©) is > > LATIN SMALL LETTER E WITH ACUTE [U+00E9] > > which can also be written as > > LATIN SMALL LETTER E [U+0065] followed by COMBINING ACUTE ACCENT [U+0301] > > The former being a composed normal form, the latter a decomposed normal form. (And yes, it is even much more complicated than that, it goes on for 1000s of pages). > > In the above example, the concept of character/string is indeed fuzzy. > > HTH, > > Sven > >

Dec. 9, 2015