- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Some GT tool for this?

by Eliot Miranda

Hi Mariano, for this in Squeak I added a simple menu pick to the Monticello Browser's package list menu called "search history" which opens up a workspace containing the entire history as a flat string. I then just search using ctrl-f. You can find it in a current squeak trunk image. _,,,^..^,,,_ (phone) > On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > How many times have you tried to search a string as a comment of a commit in all the history? Myself: many many times. I know we need much better tools for that, store the history in a another way, provide a nicer API, etc etc. And I know there were topics about that. > > However, I would deeply appreciate a very short term solution for ease that. The model side is as simple as this: > > | packageName ancestry anscestors substring | > packageName := 'MyPackageXX'. > substring := 'whatever I want to search'. > ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName = packageName] ) ancestry. > anscestors := ancestry withBreadthFirstAncestors select: [:each | each isKindOf: MCVersionInfo]. > anscestors select: [ :each | each message includesSubstring: substring ] > > Do you think it's worth a simple UI tool? Custom inspector of MCAncestry? > > Cheers, > > > -- > Mariano > http://marianopeck.wordpress.com

Dec. 11, 2015

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

by Max Leske

> On 11 Dec 2015, at 16:39, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Fri, Dec 11, 2015 at 12:25 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> >> >> On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> >> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >>> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@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? > > I think youâre solution is already pretty good. I wouldnât really care if multiple debuggers are a problem. Evaluating a piece of code in context of the dynamic variables is already a lot of help. Although, if you donât know that youâre seeing a different session / request, thatâs bad... > > I do have one idea but it might be a bit more complicated and is not Seaside specific: if we could attach the context of the evaluation to the suspended context, the handler search should automatically yield the correct handlers for the dynamic variables (although I donât know exactly how the VM resolves the handlers). Alternatively, instead of attaching the whole stack, it would suffice to copy the handler contexts and attach them to the evaluation context. Both approaches would also solve the problem of multiple debuggers. > > Yes, I have thought about doing something similar. In GemStone for example, there is another possibility since it allows global static handler for exceptions. So for example you can say install a block to be executed when nobody handled exception XXX. And that closure execution is BEFORE the #defaultAction. So for example in this case I would be able to do that without the override in WADynamicVariable >> defaultAction. > mmmmm I am not 100% sure about what I said about GemStone hahahaha. Intersting. But wouldnât you have the same problem with multiple debuggers? Theyâd all use the same global handler, wouldnât they? > > > For this to work the debugger would need highjack the evaluation of code e.g. by using a custom code editor. > > Exactly. We would need to hook on everything: print it, do it, debug it, inspect etc. Maybe at the first level is not that hard (say at debugger level). But imagine you do a "self session inspect". But then, once inside the inspector, you can inspect other objects and open other inspectors, evaluate another piece of code etc... and so the scope would end up in the first level. Yes, right. Thatâs a problem, although what I usually do is inspect the session and then use the session in a new handler context to run my code: WASession use: self during: [ â¦ ] Thus I donât care too much about what happens outside of the debugger. Of course, not everyone understands the session handling mechanism, so itâs probably not the solution for everyone. Still, having access to dynamic variables *at least* in the debugger, is already a big improvement in itself. We donât need to rethink everything. > > With current approach we simply propagate the values to everybody , everywhere. But it's also nice to be able to inspect, explore etc from anywhere and you know you will be dealing with the context of the last debugger :) I mean, you can do anything in the image and you will be dealing with the last debug error context :) > So I think that even both approaches have advantages and disadvantages, right? > > The cool thing about this would be that every evaluation would run in the same exception handling contexts as the original process. > The bad thing is of course that in some situations you actually donât care (or want to care) about those handlers (e.g. when you want to trigger an exception explicitly during evaluation and donât want it to be swallowed by the exception handlers). > > Iâve CCâed Andrei because he knows more about UI <-> Debugger interaction. Maybe he has an idea how to do this. > > > OK, Thanks. >> >> >> >> >> 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 <mailto:maxleske@gmail.com>> wrote: >>> >>>> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@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 <http://marianopeck.wordpress.com/> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 11, 2015

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

by Mariano Martinez Peck

On Fri, Dec 11, 2015 at 12:25 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > 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? > > > I think youâre solution is already pretty good. I wouldnât really care if > multiple debuggers are a problem. Evaluating a piece of code in context of > the dynamic variables is already a lot of help. Although, if you donât know > that youâre seeing a different session / request, thatâs bad... > > I do have one idea but it might be a bit more complicated and is not > Seaside specific: if we could attach the context of the evaluation to the > suspended context, the handler search should automatically yield the > correct handlers for the dynamic variables (although I donât know exactly > how the VM resolves the handlers). Alternatively, instead of attaching the > whole stack, it would suffice to copy the handler contexts and attach them > to the evaluation context. Both approaches would also solve the problem of > multiple debuggers. > Yes, I have thought about doing something similar. In GemStone for example, there is another possibility since it allows global static handler for exceptions. So for example you can say install a block to be executed when nobody handled exception XXX. And that closure execution is BEFORE the #defaultAction. So for example in this case I would be able to do that without the override in WADynamicVariable >> defaultAction. mmmmm I am not 100% sure about what I said about GemStone hahahaha. > For this to work the debugger would need highjack the evaluation of code > e.g. by using a custom code editor. > Exactly. We would need to hook on everything: print it, do it, debug it, inspect etc. Maybe at the first level is not that hard (say at debugger level). But imagine you do a "self session inspect". But then, once inside the inspector, you can inspect other objects and open other inspectors, evaluate another piece of code etc... and so the scope would end up in the first level. With current approach we simply propagate the values to everybody , everywhere. But it's also nice to be able to inspect, explore etc from anywhere and you know you will be dealing with the context of the last debugger :) I mean, you can do anything in the image and you will be dealing with the last debug error context :) So I think that even both approaches have advantages and disadvantages, right? > The cool thing about this would be that every evaluation would run in the > same exception handling contexts as the original process. > The bad thing is of course that in some situations you actually donât care > (or want to care) about those handlers (e.g. when you want to trigger an > exception explicitly during evaluation and donât want it to be swallowed by > the exception handlers). > > Iâve CCâed Andrei because he knows more about UI <-> Debugger interaction. > Maybe he has an idea how to do this. > > OK, Thanks. > > > > >> >> >>> 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 > > > -- Mariano http://marianopeck.wordpress.com

Dec. 11, 2015

Re: [Pharo-dev] Unicode Support

by Richard Sargent

EuanM wrote > ... > all ISO-8859-1 maps 1:1 to Unicode UTF-8 > ... I am late coming in to this conversation. If it hasn't already been said, please do not conflate Unicode and UTF-8. I think that would be a recipe for a high P.I.T.A. factor. Unicode defines the meaning of the code points. UTF-8 (and -16) define an interchange mechanism. In other words, when you write the code points to an external medium (socket, file, whatever), encode them via UTF-whatever. Read UTF-whatever from an external medium and re-instantiate the code points. (Personally, I see no use for UTF-16 as an interchange mechanism. Others may have justification for it. I don't.) Having characters be a consistent size in their object representation makes everything easier. #at:, #indexOf:, #includes: ... no one wants to be scanning through bytes representing variable sized characters. Model Unicode strings using classes such as e.g. Unicode7, Unicode16, and Unicode32, with automatic coercion to the larger character width. -- View this message in context: http://forum.world.st/Unicode-Support-tp4865139p4866610.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 11, 2015

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

by Denis Kudriashov

2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Because there are many options, 10, 20, and at that time slots were not > yet available. > Is not it is same case as class with 20 variables which always smell bad?

Dec. 11, 2015

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

by Max Leske

> On 10 Dec 2015, at 21:21, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > > On Thu, Dec 10, 2015 at 7:27 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 07 Dec 2015, at 17:17, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@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? I think youâre solution is already pretty good. I wouldnât really care if multiple debuggers are a problem. Evaluating a piece of code in context of the dynamic variables is already a lot of help. Although, if you donât know that youâre seeing a different session / request, thatâs bad... I do have one idea but it might be a bit more complicated and is not Seaside specific: if we could attach the context of the evaluation to the suspended context, the handler search should automatically yield the correct handlers for the dynamic variables (although I donât know exactly how the VM resolves the handlers). Alternatively, instead of attaching the whole stack, it would suffice to copy the handler contexts and attach them to the evaluation context. Both approaches would also solve the problem of multiple debuggers. For this to work the debugger would need highjack the evaluation of code e.g. by using a custom code editor. The cool thing about this would be that every evaluation would run in the same exception handling contexts as the original process. The bad thing is of course that in some situations you actually donât care (or want to care) about those handlers (e.g. when you want to trigger an exception explicitly during evaluation and donât want it to be swallowed by the exception handlers). Iâve CCâed Andrei because he knows more about UI <-> Debugger interaction. Maybe he has an idea how to do this. > > > > > 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 <mailto:maxleske@gmail.com>> wrote: >> >>> On 05 Dec 2015, at 12:58, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@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 <http://marianopeck.wordpress.com/> > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 11, 2015

a little poll on the importance of architecture

by Tudor Girba

Hi, I created another little poll about the importance of architecture. If you have a Twitter account, feel free to participate: https://twitter.com/girba/status/675330047608299521 Cheers, Doru -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

Dec. 11, 2015

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