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

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

by Sven Van Caekenberghe

Because there are many options, 10, 20, and at that time slots were not yet available. It also makes it easier/clearer to treat them consistently. > On 11 Dec 2015, at 15:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > Just looked on ZnServer code. And I was wondering when see that everything is stored inside "options" variable (which is dictionary). For example port number is option which is really strange. > > What the reason for that?

Dec. 11, 2015

Why Zinc servers implemented with options dictionary instead of normal instance variables?

by Denis Kudriashov

Hello. Just looked on ZnServer code. And I was wondering when see that everything is stored inside "options" variable (which is dictionary). For example port number is option which is really strange. What the reason for that?

Dec. 11, 2015

Re: [Pharo-dev] [squeak-dev] Re: Unicode Support

by Eliot Miranda

Hi Euan, > On Dec 10, 2015, at 6:43 PM, EuanM <euanmee(a)gmail.com> wrote: > > I agree with all of that, Ben. > > I'm currently fairly certain that fully-composed abstract characters > is a term that is 1:1 mapped with the term "grapheme cluster" (i.e. > one is an older Unicode description of a newer Unicode term). > > And once we create these, I think this sort of implementation is > straightforward. For particular values of "straightforward", of > course :-) > > i.e. the Swift approach is equivalent to the approach I originally > proposed and asked for critiques of. > > One thing I don't understand.... why does the fact the composed > abstract character (aka grapheme cluster) is a sequence mean that an > array cannot be used to hold the sequence? Of course an Array can be used, but one good reason to use bits organized as four-byte units is that the garbage collector spends no time scanning them, whereas as far as its concerned the Array representation is all objects and must be scanned. Another reason is that foreign code may find the bits representation compatible and so they can be passed through the FFI to other languages whereas the Array of tagged characters will always require conversion. Yet another reason is that in 64-bits the Array takes twice the space of the bits object. > If people then also want a compatibility-codepoints-only UTF-8 > representation, it is simple to provide comparable (i.e > equivalence-testable) versions of any UTF-8 string - because we are > creating them from composed forms by a *single* defined method. > > For my part, the reason I think we ought to implement it *in* > Smalltalk is ... this is the String class of the new age. I want > Smalltalk to be handle Strings as native objects. There's little if any difference in convenience of use between an Array of characters and a bits array with the string at:/at:put: primitives since both require at:/at:put: to access, but the latter is (efficiently) type checked (by the VM), whereas there's nothing to prevent storing other than characters in the Areay unless one introduces the overhead of skier explicit type checks in Smalltalk, and the Areay starts life as a sequence of nils (invalid until every element is set to a character) whereas the bits representation begins fully initialized with 0 asCharacter. So there's nothing more "natively objecty" about the Array. Smalltalk objects hide their representation from clients and externally they behave the same, except for space and time. Given that this is a dynamically-typed language there's nothing to prevent one providing both implementations beyond maintenance cost and complexity/confusion. So at least it's easy to do performance comparisons between the two. But I still think the bits representation is superior if what you want is a sequence of Characters. >> On 10 December 2015 at 23:41, Ben Coman <btc(a)openinworld.com> wrote: >> On Wed, Dec 9, 2015 at 5:35 PM, 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 seems to be what Swift is doing, where Strings are not composed >> not of codepoints but of graphemes. >> >>>>> "Every instance of Swiftâs Character type represents a single extended grapheme cluster. An extended grapheme cluster is a sequence** of one or more Unicode scalars that (when combined) produce a single human-readable character. [1] >> >> ** i.e. not an array >> >>>>> Hereâs an example. The letter Ã© can be represented as the single Unicode scalar Ã© (LATIN SMALL LETTER E WITH ACUTE, or U+00E9). However, the same letter can also be represented as a pair of scalarsâa standard letter e (LATIN SMALL LETTER E, or U+0065), followed by the COMBINING ACUTE ACCENT scalar (U+0301). TheCOMBINING ACUTE ACCENT scalar is graphically applied to the scalar that precedes it, turning an e into an Ã©when it is rendered by a Unicode-aware text-rendering system. [1] >> >>>>> In both cases, the letter Ã© is represented as a single Swift Character value that represents an extended grapheme cluster. In the first case, the cluster contains a single scalar; in the second case, it is a cluster of two scalars:" [1] >> >>>>> SwiftÊ¼s string implemenation makes working with Unicode easier and significantly less error-prone. As a programmer, you still have to be aware of possible edge cases, but this probably cannot be avoided completely considering the characteristics of Unicode. [2] >> >> Indeed I've tried searched for what problems it causes and get a null >> result. So I read *all*good* things about Swift's unicode >> implementation reducing common errors dealing with Unicode. Can >> anyone point to complaints about Swift's unicode implementation? >> Maybe this... >> >>>>> An argument could be made that the implementation of String as a sequence that requires iterating over characters from the beginning of the string for many operations poses a significant performance problem but I do not think so. My guess is that AppleÊ¼s engineers have considered the implications of their implementation and apps that do not deal with enormous amounts of text will be fine. Moreover, the idea that you could get away with an implementation that supports random access of characters is an illusion given the complexity of Unicode. [2] >> >> Considering our common pattern: Make it work, Make it right, Make it >> fast -- maybe Strings as arrays are a premature optimisation, that >> was the right choice in the past prior to Unicode, but considering >> Moore's Law versus programmer time, is not the best choice now. >> Should we at least start with a UnicodeString and UnicodeCharacter >> that operates like Swift, and over time *maybe* move the tools to use >> them. >> >> [1] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swif… >> [2] http://oleb.net/blog/2014/07/swift-strings/ >> >> cheers -ben >> >>> >>>> >>>> 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 _,,,^..^,,,_ (phone)

Dec. 11, 2015

a Mushroom architecture

by Robert Withers

Dec. 11, 2015

Re: [Pharo-dev] Unicode Support

by EuanM

I agree with all of that, Ben. I'm currently fairly certain that fully-composed abstract characters is a term that is 1:1 mapped with the term "grapheme cluster" (i.e. one is an older Unicode description of a newer Unicode term). And once we create these, I think this sort of implementation is straightforward. For particular values of "straightforward", of course :-) i.e. the Swift approach is equivalent to the approach I originally proposed and asked for critiques of. One thing I don't understand.... why does the fact the composed abstract character (aka grapheme cluster) is a sequence mean that an array cannot be used to hold the sequence? If people then also want a compatibility-codepoints-only UTF-8 representation, it is simple to provide comparable (i.e equivalence-testable) versions of any UTF-8 string - because we are creating them from composed forms by a *single* defined method. For my part, the reason I think we ought to implement it *in* Smalltalk is ... this is the String class of the new age. I want Smalltalk to be handle Strings as native objects. On 10 December 2015 at 23:41, Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Dec 9, 2015 at 5:35 PM, 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 seems to be what Swift is doing, where Strings are not composed > not of codepoints but of graphemes. > >>>> "Every instance of Swiftâs Character type represents a single extended grapheme cluster. An extended grapheme cluster is a sequence** of one or more Unicode scalars that (when combined) produce a single human-readable character. [1] > > ** i.e. not an array > >>>> Hereâs an example. The letter Ã© can be represented as the single Unicode scalar Ã© (LATIN SMALL LETTER E WITH ACUTE, or U+00E9). However, the same letter can also be represented as a pair of scalarsâa standard letter e (LATIN SMALL LETTER E, or U+0065), followed by the COMBINING ACUTE ACCENT scalar (U+0301). TheCOMBINING ACUTE ACCENT scalar is graphically applied to the scalar that precedes it, turning an e into an Ã©when it is rendered by a Unicode-aware text-rendering system. [1] > >>>> In both cases, the letter Ã© is represented as a single Swift Character value that represents an extended grapheme cluster. In the first case, the cluster contains a single scalar; in the second case, it is a cluster of two scalars:" [1] > >>>> SwiftÊ¼s string implemenation makes working with Unicode easier and significantly less error-prone. As a programmer, you still have to be aware of possible edge cases, but this probably cannot be avoided completely considering the characteristics of Unicode. [2] > > Indeed I've tried searched for what problems it causes and get a null > result. So I read *all*good* things about Swift's unicode > implementation reducing common errors dealing with Unicode. Can > anyone point to complaints about Swift's unicode implementation? > Maybe this... > >>>> An argument could be made that the implementation of String as a sequence that requires iterating over characters from the beginning of the string for many operations poses a significant performance problem but I do not think so. My guess is that AppleÊ¼s engineers have considered the implications of their implementation and apps that do not deal with enormous amounts of text will be fine. Moreover, the idea that you could get away with an implementation that supports random access of characters is an illusion given the complexity of Unicode. [2] > > Considering our common pattern: Make it work, Make it right, Make it > fast -- maybe Strings as arrays are a premature optimisation, that > was the right choice in the past prior to Unicode, but considering > Moore's Law versus programmer time, is not the best choice now. > Should we at least start with a UnicodeString and UnicodeCharacter > that operates like Swift, and over time *maybe* move the tools to use > them. > > [1] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swif… > [2] http://oleb.net/blog/2014/07/swift-strings/ > > cheers -ben > >> >>> >>> 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 >

Dec. 11, 2015

Re: [Pharo-dev] Ubuntu 14.04 with pharo-launcher

by Ben Coman

In the Launcher settings you can specify which VM to use. Just be careful with spaces in the path name. I can't remember if escaping with a backslash or quotes around the path was the solution. cheers -ben On Thu, Dec 10, 2015 at 2:47 AM, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: > Ciao, > > on Ubuntu system 14.04 i load the Pharo-launcher support. > > Now all the pharo.image on the system run with the same pharo VM, > > but i have a image ( Glass TODE environment ) to load with specific VM and > relative library. > > If i load it with the default pharo VM, when i do some Tode commands the > system report: Error: External module not found. > > I think to create a new launcher application. > > I copy the /usr/share/applications/pharo-vm-desktop into > pharoTode-vm.desktop > > [Desktop Entry] > Name=Pharo Tode VM > GenericName=Pharo Tode Virtual Machine > Exec=pharo-vm-x %F > Icon=pharo > Terminal=false > Type=Application > StartupNotify=false > Categories=Development; > MimeType=application/x-pharo-image; > NoDisplay=true > > but i don't understand how reference the specific Pharo VM. > > I have a gsDevKitHome/pharo directory with the todeClient.image, the > pharo bash > > and pharo-vm subdirectory with the relative pharo-vm and relative lib* > to connect with the glass environment. > > > Thanks for considerations, > > Dario >

Dec. 11, 2015

Re: [Pharo-dev] Unified Property API and persistent properties (Pharo 5)

by Ben Coman

On Wed, Dec 9, 2015 at 6:30 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hello, >> >> If we look at methods, properties are not persistent in the code. Pragmas >> are (which are >> âspecialâ kind of properties. >> >> We should do the same for all the other properties: the lower property >> level is not saved >> in source, so we can store *anything* there. >> But we can add a âhigher levelâ. E.g. some form of class Pragmas. >> >> And for packages, I would want to store what is now in the Manifest there >> and make *that* >> persistent (by storing it in the MCZ). >> >> This would a) make the whole Manifest mode much nicer, b) allow for true >> package comments >> and c) we would have a real place for Package meta-data. > > + 1 Would storing these as STON within comments in methods be a cross dialect compatible way of maintaining properties across dialects that don't support properties like Pharo does? Otherwise another dialect loading a Monticello package and the saving may eliminate the properties. Or would this be more trouble than its worth? Otherwise maybe a tool to know a mcz was't saved by Pharo and helps go back through the ancestry to recover them. cheers -ben > >> >> In general, we should move away from storing data just as arrays or >> strings in methods. >> Instead we should have a true model for the data and store that. >> >> In the same direction, we should find a way to store data like icons and >> other âfilesâ nicelyâ¦ >> >> Marcus >> >>> On 08 Dec 2015, at 19:26, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> In Pharo 5 the "properties" API is unified (means you can associate >>> properties >>> to classes, methods, packages, ...). Really cool and a good step toward a >>> unified >>> and more flexible system. >>> >>> Exampel: >>> >>> |pck| >>> pck := #'Foo-Kernel' asPackage. >>> pck propertyAt: #'lastModified' put: DateAndTime now asString. >>> pck propertyAt: #'generatedUsing' put: 'Pharo DynaCase'. >>> pck properties >>> >>> So far it looks like the package properties are still transient - that >>> means >>> when you save the package and load in another image they will be empty >>> again. >>> Havent tried for class properties, ... >>> >>> Will this change in the near future so they are persistent? I wonder what >>> the >>> plans an next steps are in this area. >>> >>> Thanks >>> T. >>> >> >> > >

Dec. 10, 2015

Re: [Pharo-dev] Unicode Support

by Ben Coman

On Wed, Dec 9, 2015 at 5:35 PM, 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 seems to be what Swift is doing, where Strings are not composed not of codepoints but of graphemes. >>> "Every instance of Swiftâs Character type represents a single extended grapheme cluster. An extended grapheme cluster is a sequence** of one or more Unicode scalars that (when combined) produce a single human-readable character. [1] ** i.e. not an array >>> Hereâs an example. The letter Ã© can be represented as the single Unicode scalar Ã© (LATIN SMALL LETTER E WITH ACUTE, or U+00E9). However, the same letter can also be represented as a pair of scalarsâa standard letter e (LATIN SMALL LETTER E, or U+0065), followed by the COMBINING ACUTE ACCENT scalar (U+0301). TheCOMBINING ACUTE ACCENT scalar is graphically applied to the scalar that precedes it, turning an e into an Ã©when it is rendered by a Unicode-aware text-rendering system. [1] >>> In both cases, the letter Ã© is represented as a single Swift Character value that represents an extended grapheme cluster. In the first case, the cluster contains a single scalar; in the second case, it is a cluster of two scalars:" [1] >>> SwiftÊ¼s string implemenation makes working with Unicode easier and significantly less error-prone. As a programmer, you still have to be aware of possible edge cases, but this probably cannot be avoided completely considering the characteristics of Unicode. [2] Indeed I've tried searched for what problems it causes and get a null result. So I read *all*good* things about Swift's unicode implementation reducing common errors dealing with Unicode. Can anyone point to complaints about Swift's unicode implementation? Maybe this... >>> An argument could be made that the implementation of String as a sequence that requires iterating over characters from the beginning of the string for many operations poses a significant performance problem but I do not think so. My guess is that AppleÊ¼s engineers have considered the implications of their implementation and apps that do not deal with enormous amounts of text will be fine. Moreover, the idea that you could get away with an implementation that supports random access of characters is an illusion given the complexity of Unicode. [2] Considering our common pattern: Make it work, Make it right, Make it fast -- maybe Strings as arrays are a premature optimisation, that was the right choice in the past prior to Unicode, but considering Moore's Law versus programmer time, is not the best choice now. Should we at least start with a UnicodeString and UnicodeCharacter that operates like Swift, and over time *maybe* move the tools to use them. [1] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swif… [2] http://oleb.net/blog/2014/07/swift-strings/ cheers -ben > >> >> 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

Dec. 10, 2015

Re: [Pharo-dev] Unicode Support // e acute example --> decomposition in Pharo?

by H. Hirzel

Hello Sven On 12/9/15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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 Thanks for this example. I have created a wiki page with it I wonder what the Pharo equivalent is of the following Squeak expression $Ã© asString asDecomposedUnicode Regards Hannes

Dec. 10, 2015

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

by Mariano Martinez Peck

On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> OK Max. In the last version you can find the "likely" final version. It's >> extremely simple, easy to use, and very very little code. Only one >> override. All WADynamicVariables subclasses handled automatically. All you >> need to do is to register the handler: >> >> app filter configuration at: #exceptionHandler put: >> WAPharoDebuggererErrorHandler. >> >> It works for exceptions and both Halt too. The only limit is only the >> "last opened debugger" will be correct and all previous will be wrong since >> they will be using another values for dynamic variables. >> >> I will see if people want to integrate this directly into Seaside. >> >> >> Very nice! And since you provide a separate error handler itâs easy to >> integrate into seaside too by simply adding it to the handler chain. >> >> > Exactly. The only issue to fix is the override in WADynamicVariable >> > defaultAction. > And that's not easy. Why? Because at that level, we know nothing about the > current seaside app or anything. We don't know which seaside app those > signal came from. Of course, I can still do the check to the handler to see > if that has that variable stored. But... What if now you have set another > error handler? Or what about OTHER possible registered apps which use a > different error handler. > Thoughts? I have some HACKS in mind, but they are hacks and none solves > all problems. And only for Pharo. > Any idea to solve this would be nice. > > Assuming you are using GTDebugger (should be very easy to adapt for normal debugger), we can do this: defaultAction " This is an override from SeasidePharoDebugging because before raising a signal we first check if we have the value stored. That way, everywhere we evaluate code in a debugger that end ups doing 'WACurrentRequestContext value' will simply get up to this place. Since in WAPharoDebuggererErrorHandler >> #open: we stored the dynamic variables, we should have the value " | openedSeasideErrorDebuggers | *openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) * * collect: [ :each | each model ]) * * select: [ :each2 | (each2 session interruptedProcess suspendedContext method selector = #openDebuggerOn:)* * and: (each2 session interruptedProcess suspendedContext sender receiver class = WADynamicVariablesErrorHandler) ].* ^ openedSeasideErrorDebuggers ifEmpty: [ self class defaultValue ] ifNotEmpty: [ (WADynamicVariablesErrorHandler storedDynamicVariable: self class) ifNil: [ self class defaultValue ] ] But that..the only thing it solves is that we would not be getting the value of dynamic variables from previous errors if there is none debugger opened from a seaside continuation. If you let a debugger opened debugging a seaside error, then there is no magic we can do I think. Imagine you were in a debugger and you evaluated: "WAComponent new session". The signal raised from there knows NOTHING about the debugger where that was evaluated... so at #defaultAction level you know nothing about what triggered that. The only thing to solve this would be to hook into the do-it, print it, inspect etc...too complicated. Thoughts? > > >> Two tiny things: >> - youâre not using the #reset method you wrote but instead manually >> assign nil to the variable >> > > yes, thanks. > > >> - I guess the dictionary in the handler could be a SmallDictionary. There >> wonât be many entries. >> >> > Well..since there will be likely.. less than 10 entries I don't care which > Dictionary to use. However, I would prefer to keep Dictionary. Or if not > GRSmallDictionary. > > >> Thanks a lot for this. Iâll probably port this back to Seaside 2.8 so I >> can use it too :) >> > > No problem. Thanks for reviewing and give feedback. > > > >> >> On Sat, Dec 5, 2015 at 11:36 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> Can you try with the latest version that does not use LPC if it works? >>> >>> >>> Works perfectly! >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Dec. 10, 2015