- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Unicode Support

by EuanM

"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?" Guillermo The problem with the quote is, that *while true*, it *does not disambiguate* between: either compatibility character and abstract character; or character as composable component of an abstract character and character as the entire embodiment of an abstract character; Abstract character is the key concept of Unicode. Differentiation between abstract character and codepoints is the key differentiator of the Unicode approach and most previous approaches to character encoding, e,g, ASCII, EBCDIC, ISO Latin 1, etc Please see my previous posts which use the example of Angstrom, Capital A with circle (or whatever the canonical name is) and the composed sequence of "Capital A" and "circle above a letter" for a fuller explanation of the concept of "abstract character". On 9 December 2015 at 09: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? > >> >> This is the key difference between Unicode and most character encodings. >> >> A codepoint does not always represent a whole character. >> >> On 7 December 2015 at 13:06, Henrik Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 07 Dec 2015, at 1:05 , EuanM <euanmee(a)gmail.com> wrote: >>> >>> Hi Henry, >>> >>> To be honest, at some point I'm going to long for the for the much >>> more succinct semantics of healthcare systems and sports scoring and >>> administration systems again. :-) >>> >>> codepoints are any of *either* >>> - the representation of a component of an abstract character, *or* >>> eg. "A" #(0041) as a component of >>> - the sole representation of the whole of an abstract character *or* of >>> - a representation of an abstract character provided for backwards >>> compatibility which is more properly represented by a series of >>> codepoints representing a composed character >>> >>> e.g. >>> >>> The "A" #(0041) as a codepoint can be: >>> the sole representation of the whole of an abstract character "A" #(0041) >>> >>> The representation of a component of the composed (i.e. preferred) >>> version of the abstract character â« #(0041 030a) >>> >>> â« (#00C5) represents one valid compatibility form of the abstract >>> character â« which is most properly represented by #(0041 030a). >>> >>> â« (#212b) also represents one valid compatibility form of the abstract >>> character â« which is most properly represented by #(0041 030a). >>> >>> With any luck, this satisfies both our semantic understandings of the >>> concept of "codepoint" >>> >>> Would you agree with that? >>> >>> In Unicode, codepoints are *NOT* an abstract numerical representation >>> of a text character. >>> >>> At least not as we generally understand the term "text character" from >>> our experience of non-Unicode character mappings. >>> >>> >>> I agree, they are numerical representations of what Unicode refers to as >>> characters. >>> >>> >>> codepoints represent "*encoded characters*" >>> >>> >>> 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. >>> >>> and "a *text element* ... >>> is represented by a sequence of one or more codepoints". (And the >>> term "text element" is deliberately left undefined in the Unicode >>> standard) >>> >>> Individual codepoints are very often *not* the encoded form of an >>> abstract character that we are interested in. Unless we are >>> communicating to or from another system (Which in some cases is the >>> Smalltalk ByteString class) >>> >>> >>> >>> >>> i.e. in other words >>> >>> *Some* individual codepoints *may* be a representation of a specific >>> *abstract character*, but only in special cases. >>> >>> The general case in Unicode is that Unicode defines (a) >>> representation(s) of a Unicode *abstract character*. >>> >>> The Unicode standard representation of an abstract character is a >>> composed sequence of codepoints, where in some cases that sequence is >>> as short as 1 codepoint. >>> >>> In other cases, Unicode has a compatibility alias of a single >>> codepoint which is *also* a representation of an abstract character >>> >>> There are some cases where an abstract character can be represented by >>> more than one single-codepoint compatibility codepoint. >>> >>> Cheers, >>> Euan >>> >>> >>> I agree you have a good grasp of the distinction between an abstract >>> character (characters and character sequences which should be treated >>> equivalent wrt, equality / sorting / display, etc.) and a character (which >>> each have a code point assigned). >>> That is besides the point both Sven and I tried to get through, which is the >>> difference between a code point and the encoded form(s) of said code point. >>> When you write: >>> "and therefore encodable in UTF-8 as compatibility codepoint e9 hex >>> and as the composed character #(0065 00b4) (all in hex) and as the >>> same composed character as both >>> #(feff 0065 00b4) and #(ffef 0065 00b4) when endianness markers are >>> included" >>> >>> I's quite clear you confuse the two. 0xFEFF is the codepoint of the >>> character used as bom. >>> When you state that it can be written ffef (I assume you meant FFFE), you >>> are again confusing the code point and its encoded value (an encoded value >>> which only occurs in UTF16/32, no less). >>> >>> When this distinction is clear, it might be easier to see that value in that >>> Strings are kept as Unicode code points arrays, and converted to encoded >>> forms when entering/exiting the system. >>> >>> Cheers, >>> Henry >>> >> > >

Dec. 9, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50492 Home: https://github.com/pharo-project/pharo-core

Dec. 9, 2015

[pharo-project/pharo-core] e3f6b3: 50492

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e3f6b3f61fc8f36d306bbd3d8e0f125a369528ba https://github.com/pharo-project/pharo-core/commit/e3f6b3f61fc8f36d306bbd3d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-09 (Wed, 09 Dec 2015) Changed paths: R Morphic-Core.package/Morph.class/instance/stepping and presenter/startSteppingIn_.st R Morphic-Core.package/PasteUpMorph.class/instance/world state/addMorphs_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50491.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50492.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50491.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50492.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50492 17221 clean dirty packages after metacello update https://pharo.fogbugz.com/f/cases/17221 17219 Class Definitions not in Changes... again again https://pharo.fogbugz.com/f/cases/17219 17217 Remove PasteUpMorph>>#addMorphs: https://pharo.fogbugz.com/f/cases/17217 http://files.pharo.org/image/50/50492.zip

Dec. 9, 2015