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

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

by Norbert Hartl

> Am 04.12.2015 um 16:05 schrieb Max Leske <maxleske(a)gmail.com>: > > >> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which are completely different. WADynamicVariable uses exception mechanism while DynamicVariable uses the ProcessSpecificVariable. >> But thanks anyway! > > Oh manâ¦. Sorry :) > > I wonder, why WADynamicVariable *isnât* a DynamicVariable. The semantics are the same if Iâm not mistaken (e.g. only available in the current process) and I think access to a dynamic variable may even be faster because it *doesnât* use the exception mechanism (i.e. no need to walk down the stack). > If someone knows the answer, Iâd be happy to hear it. > > Iâve played around with Process>>signalException: and Context>>handleSignal: (which looked quite promising) but didnât get any results. Iâm out of ideas. > There was no DynamicVariable in pharo when seaside was created. It has been introduced in pharo3?? There are not fully equivalent so it is hard to say better or not. We had a problem that you cannot access a process specific variable because the debugger forks off. But we introduced a fix from Eliot where the effective process is taken into account. A resumable exception should be available as long as you have access to the whole stack up to the closure for that exception. So should be independent of the process you are in. I cannot recall why this makes problems at all. my 2 cents, Norbert > Cheers, > Max > >> >> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> Hereâs a snippet to play with: >> >> p := Processor activeProcess. >> x := 2. >> v := TestDynamicVariable value: x during: [ >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> ]. >> >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> >> Cheers, >> Max >> >>> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>> >>> I feel you :) >>> >>> Without having thought this through completely: if you look at the implementation of DynamicVariable>>value:during: youâll see that the way it works is that the variable is bound to the active process. In the debugger you have access to the process that is being debugged and thus you should have access to the variables bound to it. You could try accessing all such variables by iterating over them (which I think will require an extension on Process because youâd need to access at least the PSKeys class variable). >>> >>> Cheers, >>> Max >>> >>>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>> >>>> Hi guys, >>>> >>>> This thing I will ask in this email it's in my mind since YEARS. But I have always thought it was like that and that there was nothing we could do. However, I think it's time I ask again :) >>>> >>>> For those that have used Seaside, and you try to debug, you know that upon request processing seaside uses Exceptions mechanisim to always have access to the request, session, etc. They way that is done is very smart :) >>>> >>>> WACurrentRequestContext use: self during: aBlock >>>> >>>> In that case, "self" is the request instance and aBlock the closure that takes care of the request processing. So, inside that closure, everywhere you do "WACurrentRequestContext value" you get the correct request instance. >>>> >>>> So..that's great for Seaside, but debugging gets complicated. While you can restart, proceed, etc, once inside debugger, you cannot evaluate any piece of code that will use the session or request because you get a WARequestContextNotFound. Of course, because I guess the evaluation you do from cmd+d on a piece of text or via the debugger inspector, creates another closure/context which does not receive the WACurrentRequestContext instance. >>>> >>>> Now....besides WACurrentRequestContext I have my own class UserContextInformation where I basically have a bunch of stuff associated to the logged user. And I do exactly the same as the WACurrentRequestContext. And I have the same problem. I really want to be able to fix this. >>>> >>>> Anyone have an idea on how can I do it? I guess I can change the debugger, in the place where I evaluate code so that I wrap that evaluation with my request context instance??? >>>> >>>> Thoughts? >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >>> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >

Dec. 4, 2015

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

by Max Leske

> On 04 Dec 2015, at 17:11, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > I found a way!!!! Much cleaner and easier. Awesome! > I will clean it, test it a bit more and try to package it for public usage :) Give me a snippet! I want to play with it! :D > > On Fri, Dec 4, 2015 at 12:31 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > > On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which are completely different. WADynamicVariable uses exception mechanism while DynamicVariable uses the ProcessSpecificVariable. >> But thanks anyway! > > Oh manâ¦. Sorry :) > > I wonder, why WADynamicVariable *isnât* a DynamicVariable. The semantics are the same if Iâm not mistaken (e.g. only available in the current process) and I think access to a dynamic variable may even be faster because it *doesnât* use the exception mechanism (i.e. no need to walk down the stack). > If someone knows the answer, Iâd be happy to hear it. > > > I bet it's because of portability. For example, i remember in GemStone the ProcessorLocalVariable did not behave the same as in Pharo. And it was actually an experiment. I think you cannot expect all this stuff to be ansi (or easily portable), while exceptions do. > > Iâve played around with Process>>signalException: and Context>>handleSignal: (which looked quite promising) but didnât get any results. Iâm out of ideas. > > > I have played all morning with an idea of using local variables. I arrive to the point where I DO HAVE the request context at hand, but I don't find an easy way to hook into do-its, print-it etc so that the closure evaluated gets the request context plugged. In other ways... let's say I have the context stored somewhere. I am at the SmalltalkEditor >> evaluateSelectionAndDo: aBlock > > and so..somewhere I need to do something like: > > WACurrentRequestContext use: self storedContextSomewhere during: [ self theSelectionToBeEvaluated ] > > and that's where I am now :) > > > > Cheers, > Max > >> >> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> Hereâs a snippet to play with: >> >> p := Processor activeProcess. >> x := 2. >> v := TestDynamicVariable value: x during: [ >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> ]. >> >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> >> Cheers, >> Max >> >>> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>> >>> I feel you :) >>> >>> Without having thought this through completely: if you look at the implementation of DynamicVariable>>value:during: youâll see that the way it works is that the variable is bound to the active process. In the debugger you have access to the process that is being debugged and thus you should have access to the variables bound to it. You could try accessing all such variables by iterating over them (which I think will require an extension on Process because youâd need to access at least the PSKeys class variable). >>> >>> Cheers, >>> Max >>> >>>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>>> >>>> Hi guys, >>>> >>>> This thing I will ask in this email it's in my mind since YEARS. But I have always thought it was like that and that there was nothing we could do. However, I think it's time I ask again :) >>>> >>>> For those that have used Seaside, and you try to debug, you know that upon request processing seaside uses Exceptions mechanisim to always have access to the request, session, etc. They way that is done is very smart :) >>>> >>>> WACurrentRequestContext use: self during: aBlock >>>> >>>> In that case, "self" is the request instance and aBlock the closure that takes care of the request processing. So, inside that closure, everywhere you do "WACurrentRequestContext value" you get the correct request instance. >>>> >>>> So..that's great for Seaside, but debugging gets complicated. While you can restart, proceed, etc, once inside debugger, you cannot evaluate any piece of code that will use the session or request because you get a WARequestContextNotFound. Of course, because I guess the evaluation you do from cmd+d on a piece of text or via the debugger inspector, creates another closure/context which does not receive the WACurrentRequestContext instance. >>>> >>>> Now....besides WACurrentRequestContext I have my own class UserContextInformation where I basically have a bunch of stuff associated to the logged user. And I do exactly the same as the WACurrentRequestContext. And I have the same problem. I really want to be able to fix this. >>>> >>>> Anyone have an idea on how can I do it? I guess I can change the debugger, in the place where I evaluate code so that I wrap that evaluation with my request context instance??? >>>> >>>> Thoughts? >>>> >>>> >>>> -- >>>> 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. 4, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Max Leske

> On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > > On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> >> 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>>> >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>>> >>>>>>> @Doru >>>>>>> Youâre missing the point: #anyOne *fails* for empty collections. >>>>>> >>>>>> I am not missing the point at all. I am saying that if you want sum: >>>>>> to be generic, it cannot assume a specific Zero object. >>>>>> >>>>>> And sum: should be generic because of its name. >>>>> >>>>> I am missing understanding the other use cases. Can you describe >>>>> further the generic nature of #sum & #sum: ? I would have thought by >>>>> default they only applied to numbers. >>>>> >>>>> sum can be applied to anything that supports #+, not only numbers >>>>> sum: can be applied to any collection with a block that return some >>>>> object that supports #+ >>> >>> To me this is a mis-application of polymorphism, that just because >>> something responds to #+ it should be summable. We have overloaded the >>> semantics of #+ to mean both numeric addition and >>> concatenation/membership, but technically "summation" relates only to >>> numeric addition. I agree. If I want to sum something other than a collection of numbers Iâll happily provide the block for that summation (I wouldnât even expect strings to be summable to be honest. Why would you have a collection of numbers that are stringsâ¦? And if you really have one, you should convert it explicitly so that another person reading your code knows whatâs going on.) >> >> >> I didn't wanted to argue for or against any change. I just wanted to clarify >> that there are situations in which a generic sum/sum: that throws an error >> on empty collections and don't assume a null value makes sense. >> >> >>> >>> >>> https://www.google.com.au/search?q=define+sum&oq=define+sum >>> >>> https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate >>> >>> For example... >>> >>> * KMModifier implements #+ so what is the expected semantic of " { >>> KMModifier shift . KMModifier meta} sum " ? >>> To me this is more of a concatenation/join/union facility rather than >>> numeric addition. (btw, that expression actually fails since >>> KMModifier does not understand minus #- ) . >>> >>> * String implements #+ and " { '1' . '2' } sum " --> '3', so >>> actually its doing numeric addition. However " { 'a' . 'b' } sum " >>> produces an error. >>> >>> So actually there seem some existing problems with summing >>> non-numerics. What examples work? >>> >>> * Trait classes implement both #+ and #- , but the semantic seems >>> more to do with membership than numeric addition. I don't how how to >>> produce an example of using #sum against traits. >>> >>> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >>> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >>> cause any error in this case. >>> >>> >>> cheers -ben >>> >>> >>>>> >>>>> therefore you can not assume 0 (<- a number) is a proper initial value >>>>> therefore you *need* to work with #anyOne >>>>> and as you can not assume a proper initial value, you can not assume a >>>>> default value for empty collections >>>>> -> it should throw an error. If you (the caller of the function) knows >>>>> what to do with an empty collection you have >>>>> to check, or call inject:into: directly, with a proper initial value. >>>> >>>> I am sorry but I am getting really tired of this, you should read what >>>> is being said. >> >> >> do that change, I am not against it. Ben just asked for an example and I >> thought it would be helpful. > > It was helpful :) It evolved my thinking. Now thinking further, I > wonder how returning 0 will work with applications using units like > Aconcagua, and if it would over-complicate things to do something > like... > > Collection>>sum > | sum sample | > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > sample := self anyOne. > sum := self inject: sample into: [ :accum :each | accum + each ]. > ^ sum - sample > > ArithmeticZero class >> + anObject > ^anObject While I think you might be on to something, I think we should take small steps. Iâd be happy already if we can just get rid of one superfluous method and provide a better API without starting to think about the deeper semantics. Also, I think thereâs a reason why Aconcagua is an external package: developers usually are happy to work with numbers (which are already objects in Smalltalk anyway) and theyâre fast. > > cheers -ben > >> >> >>> >>>> >>>> I am not suggesting to stop using #anyOne because I like why it is there >>>> and what it can do. >>>> >>>> The change I want is what happens with an empty collection when using >>>> the simplest selector, #sum. >>>> >>>> I do not want to say to some collection of numbers #sumIfEmpty: [0], >>>> because summing numbers starting from zero is the most common case and >>>> everybody expects that, hence the unary selector fits. >>>> >>>> I want the less common cases to use the more complicated API, as in some >>>> collection of colors #sumIfEmpty: [ Color black ] >>>> >>>> In my book that is common sense API design. >>>> >>>> Doing that I do no take anything away, because today you already have to >>>> make sure the collection is not empty. >>>> >>>> The only change would be in the error behaviour. I think that is a >>>> reasonable price to pay. Instead of having #anyOne fail, it will say that #+ >>>> cannot add 0 to some object, and in a comment we can point to the >>>> alternative API. >> >> >> >> >>> >>>> >>>> http://izquotes.com/quote/242740 right ? >>>> >>>>> cheers -ben >>>>> >>>>>> >>>>>>>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo >>>>>>>> <emaringolo(a)gmail.com> wrote: >>>>>>>> >>>>>>>> I don't want to be heretic (or too orthodox), but why not to >>>>>>>> delegate >>>>>>>> this behavior to other class (an iterator maybe?). >>>>>>>> >>>>>>>> It's too tempting adding these convenience methods to Collection >>>>>>>> and/or subclasses, but anything that requires an explicit protocol >>>>>>>> of >>>>>>>> its elements is wrong, IMO. >>>>>>>> >>>>>>>> something like aCollection arithmetic sum: [...] or.... aCollection >>>>>>>> arithmetic avg. > > > On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham > <cunningham.cb(a)gmail.com <mailto:cunningham.cb@gmail.com>> wrote: >> <uncontrolled snipping> >> >> On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >>> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >>> cause any error in this case. >> >> but points aren't commutative: >> >> 2@2 + 1 " = 3@3" >> 1 + 2@2 " = 3@2" >> >> Of course, 0 wouldn't be an issue, unless you wanted to access x or y!

Dec. 4, 2015

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

by Mariano Martinez Peck

I found a way!!!! Much cleaner and easier. Awesome! I will clean it, test it a bit more and try to package it for public usage :) On Fri, Dec 4, 2015 at 12:31 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which >> are completely different. WADynamicVariable uses exception mechanism >> while DynamicVariable uses the ProcessSpecificVariable. >> But thanks anyway! >> >> >> Oh manâ¦. Sorry :) >> >> I wonder, why WADynamicVariable *isnât* a DynamicVariable. The semantics >> are the same if Iâm not mistaken (e.g. only available in the current >> process) and I think access to a dynamic variable may even be faster >> because it *doesnât* use the exception mechanism (i.e. no need to walk down >> the stack). >> If someone knows the answer, Iâd be happy to hear it. >> >> > I bet it's because of portability. For example, i remember in GemStone the > ProcessorLocalVariable did not behave the same as in Pharo. And it was > actually an experiment. I think you cannot expect all this stuff to be ansi > (or easily portable), while exceptions do. > > >> Iâve played around with Process>>signalException: and >> Context>>handleSignal: (which looked quite promising) but didnât get any >> results. Iâm out of ideas. >> >> > I have played all morning with an idea of using local variables. I arrive > to the point where I DO HAVE the request context at hand, but I don't find > an easy way to hook into do-its, print-it etc so that the closure evaluated > gets the request context plugged. In other ways... let's say I have the > context stored somewhere. I am at the SmalltalkEditor >> > evaluateSelectionAndDo: aBlock > > and so..somewhere I need to do something like: > > WACurrentRequestContext use: self storedContextSomewhere during: [ self > theSelectionToBeEvaluated ] > > and that's where I am now :) > > > > >> Cheers, >> Max >> >> >> On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Hereâs a snippet to play with: >>> >>> p := Processor activeProcess. >>> x := 2. >>> v := TestDynamicVariable value: x during: [ >>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>> env copyWithout: nil ]) inspect >>> ]. >>> >>> ((p instVarNamed: 'env') ifNotNil: [ :env| >>> env copyWithout: nil ]) inspect >>> >>> Cheers, >>> Max >>> >>> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> I feel you :) >>> >>> Without having thought this through completely: if you look at the >>> implementation of DynamicVariable>>value:during: youâll see that the way it >>> works is that the variable is bound to the active process. In the debugger >>> you have access to the process that is being debugged and thus you should >>> have access to the variables bound to it. You could try accessing all such >>> variables by iterating over them (which I think will require an extension >>> on Process because youâd need to access at least the PSKeys class variable). >>> >>> Cheers, >>> Max >>> >>> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> Hi guys, >>> >>> This thing I will ask in this email it's in my mind since YEARS. But I >>> have always thought it was like that and that there was nothing we could >>> do. However, I think it's time I ask again :) >>> >>> For those that have used Seaside, and you try to debug, you know that >>> upon request processing seaside uses Exceptions mechanisim to always have >>> access to the request, session, etc. They way that is done is very smart :) >>> >>> WACurrentRequestContext use: self during: aBlock >>> >>> In that case, "self" is the request instance and aBlock the closure that >>> takes care of the request processing. So, inside that closure, everywhere >>> you do "WACurrentRequestContext value" you get the correct request instance. >>> >>> So..that's great for Seaside, but debugging gets complicated. While you >>> can restart, proceed, etc, once inside debugger, you cannot evaluate any >>> piece of code that will use the session or request because you get >>> a WARequestContextNotFound. Of course, because I guess the evaluation you >>> do from cmd+d on a piece of text or via the debugger inspector, creates >>> another closure/context which does not receive the WACurrentRequestContext >>> instance. >>> >>> Now....besides WACurrentRequestContext I have my own class >>> UserContextInformation where I basically have a bunch of stuff associated >>> to the logged user. And I do exactly the same as the >>> WACurrentRequestContext. And I have the same problem. I really want to be >>> able to fix this. >>> >>> Anyone have an idea on how can I do it? I guess I can change the >>> debugger, in the place where I evaluate code so that I wrap that evaluation >>> with my request context instance??? >>> >>> Thoughts? >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Dec. 4, 2015

[pharo-project/pharo-core]

by GitHub

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

Dec. 4, 2015

[pharo-project/pharo-core] 7a8e6d: 50485

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7a8e6d1b8907aa8fa9d5b71564122941517413f6 https://github.com/pharo-project/pharo-core/commit/7a8e6d1b8907aa8fa9d5b715… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-04 (Fri, 04 Dec 2015) Changed paths: M Monticello.package/MCVersion.class/instance/accessing/loadCompleteSnapshot.st M Nautilus.package/NautilusUI.class/instance/package filter/buildPackageSearch.st A OpalTools.package/extension/SymbolicBytecode/instance/gtSpotterCodePreviewIn_.st A OpalTools.package/extension/SymbolicBytecode/instance/spotterActDefault.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50484.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50485.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50484.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50485.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50485 16964 Nautilus package search field cursor goes back to start when space is inserted at the end of the field https://pharo.fogbugz.com/f/cases/16964 17185 Broken changes view https://pharo.fogbugz.com/f/cases/17185 17172 SymbolicBytecode should be embeddable in Spotter https://pharo.fogbugz.com/f/cases/17172 http://files.pharo.org/image/50/50485.zip

Dec. 4, 2015

Re: [Pharo-dev] Unicode Support

by Max Leske

Hi Euan I think itâs great that youâre trying this. I hope you know what youâre getting yourself into :) Iâm no Unicode expert but I want to add two points to your list (although youâve probably already thought of them): - Normalisation and conversion (http://unicode.org/faq/normalization.html) Unicode / ICU provide libraries (libuconv / libiconv) that handle this stuff. Specifically normalisation conversions arenât trivial and I think it wouldnât make much sense to reimplement those algorithms. I do think however, that having them available is important (where I work weâre currently writing a VM plugin for access to libiconv through primitives so that we can clean out combining characters through normalisation. And weâll obviously get nice sorting properties and speeds for free) - Sorting and comparison. Basically the same point as above. libuconv / libiconv provide algorithms for this. Do we need our own implementation? Cheers, Max > On 04 Dec 2015, at 12:42, EuanM <euanmee(a)gmail.com> wrote: > > I'm currently groping my way to seeing how feature-complete our > Unicode support is. I am doing this to establish what still needs to > be done to provide full Unicode support. > > This seems to me to be an area where it would be best to write it > once, and then have the same codebase incorporated into the Smalltalks > that most share a common ancestry. > > I am keen to get: equality-testing for strings; sortability for > strings which have ligatures and diacritic characters; and correct > round-tripping of data. > > Call to action: > ========== > > If you have comments on these proposals - such as "but we already have > that facility" or "the reason we do not have these facilities is > because they are dog-slow" - please let me know them. > > If you would like to help out, please let me know. > > If you have Unicode experience and expertise, and would like to be, or > would be willing to be, in the 'council of experts' for this project, > please let me know. > > If you have comments or ideas on anything mentioned in this email > > In the first instance, the initiative's website will be: > http://smalltalk.uk.to/unicode.html > > I have created a SqueakSource.com project called UnicodeSupport > > I want to avoid re-inventing any facilities which already exist. > Except where they prevent us reaching the goals of: > - sortable UTF8 strings > - sortable UTF16 strings > - equivalence testing of 2 UTF8 strings > - equivalence testing of 2 UTF16 strings > - round-tripping UTF8 strings through Smalltalk > - roundtripping UTF16 strings through Smalltalk. > As I understand it, we have limited Unicode support atm. > > Current state of play > =============== > ByteString gets converted to WideString when need is automagically detected. > > Is there anything else that currently exists? > > Definition of Terms > ============== > A quick definition of terms before I go any further: > > Standard terms from the Unicode standard > =============================== > a compatibility character : an additional encoding of a *normal* > character, for compatibility and round-trip conversion purposes. For > instance, a 1-byte encoding of a Latin character with a diacritic. > > Made-up terms > ============ > a convenience codepoint : a single codepoint which represents an item > that is also encoded as a string of codepoints. > > (I tend to use the terms compatibility character and compatibility > codepoint interchangably. The standard only refers to them as > compatibility characters. However, the standard is determined to > emphasise that characters are abstract and that codepoints are > concrete. So I think it is often more useful and productive to think > of compatibility or convenience codepoints). > > a composed character : a character made up of several codepoints > > Unicode encoding explained > ===================== > A convenience codepoint can therefore be thought of as a code point > used for a character which also has a composed form. > > The way Unicode works is that sometimes you can encode a character in > one byte, sometimes not. Sometimes you can encode it in two bytes, > sometimes not. > > You can therefore have a long stream of ASCII which is single-byte > Unicode. If there is an occasional Cyrillic or Greek character in the > stream, it would be represented either by a compatibility character or > by a multi-byte combination. > > Using compatibility characters can prevent proper sorting and > equivalence testing. > > Using "pure" Unicode, ie. "normal encodings", can cause compatibility > and round-tripping probelms. Although avoiding them can *also* cause > compatibility issues and round-tripping problems. > > Currently my thinking is: > > a Utf8String class > an Ordered collection, with 1 byte characters as the modal element, > but short arrays of wider strings where necessary > a Utf16String class > an Ordered collection, with 2 byte characters as the modal element, > but short arrays of wider strings > beginning with a 2-byte endianness indicator. > > Utf8Strings sometimes need to be sortable, and sometimes need to be compatible. > > So my thinking is that Utf8String will contain convenience codepoints, > for round-tripping. And where there are multiple convenience > codepoints for a character, that it standardises on one. > > And that there is a Utf8SortableString which uses *only* normal characters. > > We then need methods to convert between the two. > > aUtf8String asUtf8SortableString > > and > > aUtf8SortableString asUtf8String > > > Sort orders are culture and context dependent - Sweden and Germany > have different sort orders for the same diacritic-ed characters. Some > countries have one order in general usage, and another for specific > usages, such as phone directories (e.g. UK and France) > > Similarly for Utf16 : Utf16String and Utf16SortableString and > conversion methods > > A list of sorted words would be a SortedCollection, and there could be > pre-prepared sortBlocks for them, e.g. frPhoneBookOrder, deOrder, > seOrder, ukOrder, etc > > along the lines of > aListOfWords := SortedCollection sortBlock: deOrder > > If a word is either a Utf8SortableString, or a well-formed Utf8String, > then we can perform equivalence testing on them trivially. > > To make sure a Utf8String is well formed, we would need to have a way > of cleaning up any convenience codepoints which were valid, but which > were for a character which has multiple equally-valid alternative > convenience codepoints, and for which the string currently had the > "wrong" convenience codepoint. (i.e for any character with valid > alternative convenience codepoints, we would choose one to be in the > well-formed Utf8String, and we would need a method for cleaning the > alternative convenience codepoints out of the string, and replacing > them with the chosen approved convenience codepoint. > > aUtf8String cleanUtf8String > > With WideString, a lot of the issues disappear - except > round-tripping(although I'm sure I have seen something recently about > 4-byte strings that also have an additional bit. Which would make > some Unicode characters 5-bytes long.) > > > (I'm starting to zone out now - if I've overlooked anything - obvious, > subtle, or somewhere in between, please let me know) > > Cheers, > Euan >

Dec. 4, 2015

Re: [Pharo-dev] Java Future

by stepharo

> We do need more ease of integration with other software. > I agree Normally we should have spur by next wednesday > > * 64 bit > > * OS Process made easier. > Mariano did you started to work on that? > * FFI not requiring a PhD > Yes. > * Being able to use Pharo with normal text based tools (like mount an > image like a filesystem). > * Full integration with trendy tools. e.g. MongoTalk missing GridFS, > sharding, HA. > > These things are moving forward. > > I am pissed that Julia got $600 000 and we are struggling due to cash > issues. > Well I do not know how to do that. > We do not miss brainpower. We miss being able to focus on progress > because we can't fund it well enough. > > Phil > > > > On Nov 30, 2015 12:21 PM, "Tudor Girba" <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > > > Hi, > > > > Increasing the community is certainly important, and we welcome any > action that anyone would want to undertake in this direction. > > > > However, talking about the future of Java does not fall in this > category. > > > > Cheers, > > Doru > > > > > > > On Nov 30, 2015, at 4:44 AM, EuanM <euanmee(a)gmail.com > <mailto:euanmee@gmail.com>> wrote: > > > > > > We also need to concentrate on building our community. > > > > > > We build a better platform faster if we have more people. > > > > > > We build a more valuable platform if we have a wider range of valuable > > > use cases to target. > > > > > > Unless and until we hit a critical mass of people joining our > > > community, we *need* to spend some of our focus on community-building. > > > > > > Part of great is being able to build things to sufficient completeness > > > *and* keep them in working order over the long haul. This is easier > > > with more contributors. > > > > > > On 27 November 2015 at 21:27, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > >> Hello everyone, > > >> > > >> Please stop this thread on this mailing list. We need to focus on > building a great platform. > > >> > > >> Cheers, > > >> Doru > > >> > > >> > > >>> On Nov 27, 2015, at 10:05 PM, EuanM <euanmee(a)gmail.com > <mailto:euanmee@gmail.com>> wrote: > > >>> > > >>> First of all - is this true? Where can we read about it? > > >>> > > >>> I cannot find anything about this at > > >>> https://www.oracle.com/search/press > > >>> > > >>> ======================================= > > >>> > > >>> If Oracle did make this statement, then what people have said so far > > >>> is true. BUT... > > >>> > > >>> Java got about 40% of its initial momentum from IBM dumping > VisualAge > > >>> and putting all their resources into Java. > > >>> > > >>> Oracle are targetting this move at IBM more than anyone else. > > >>> > > >>> IBM will start to think about how to migrate from Java - as > Oracle are > > >>> telling them they will have to. (It's OUR bat and its OUR ball, and > > >>> no-one else can play with it. Not even the Java Community). And > > >>> IBM's coders do not pay for Java, Eclipse users do not pay for > Java. I > > >>> expect the licence-fee income for JREs is small. > > >>> > > >>> Oracle are doing one of two things - announcing that Java is for > sale > > >>> to device providers - phones (Google is the obvious buyer) or the > > >>> impending Internet of Things (which was what Java was designed for > > >>> originally) or announcing that no-one making an internet of things > > >>> offering should consider Java. > > >>> > > >>> Yes, things live on and on in a kind of zombie state. So yes, > things > > >>> live on as long as their ecosystem does. And they gently wither and > > >>> their ecosystem withers is a long slow drawn out spiral. Which > is why > > >>> we still have Cobol. > > >>> > > >>> People and organisations tend to move from one technology to another > > >>> in an incremental fashion. Swapping a little bit here, and a little > > >>> bit there. > > >>> > > >>> The new target platforms are ones which > > >>> 1) look like they have longevity, and > > >>> 2) have a migration pathway that provides incremental steps. > > >>> > > >>> Offering a compelling advantage is good - but only if the steps 1) > > >>> and 2) are catered to. > > >>> > > >>> IBM VisualAge Smalltalk is still robust, commercially available > > >>> software, and VisualStudio and Gemstone continue to represent > > >>> Smalltalk out to the big world of corporate development. > > >>> > > >>> So that's a start. > > >>> > > >>> Say only 5% of the Java world moves away from Java each year, as a > > >>> result of this announcement. > > >>> > > >>> We *should* wish to take advantage of this announcement. > > >>> > > >>> After all, think what difference having even 0.01% of the > world's Java > > >>> coders moving to Smalltalk would make. How could we help that > > >>> happen? > > >>> > > >>> Think what it would be like to have thought-leaders like Kent > Beck and > > >>> Ward Cunningham back in the Smalltalk fold. How could we help that > > >>> happen? > > >>> > > >>> Think what it would be like to get back all the universities who > moved > > >>> from teaching OO concepts using Smalltalk into teaching them via > Java. > > >>> We now know almost all the ones using Smalltalk as a teaching > language > > >>> by name. Does anyone know even how many universities teach OO via > > >>> Java? What would it be like if 5% of those universities moved to > > >>> Smalltalk each year. How could we help that happen? > > >>> > > >>> Next - do we have any big brained thinkers who can see specific ways > > >>> we can improve interoperation between Java facilities and libraries > > >>> and the Smalltalks? For the next 12 months, we should work on Java > > >>> integration, rather than C++ integration. We should identify the > > >>> three best things for us to do in this regard, and make them > polished > > >>> and compelling. Who is in a position to help that happen? > > >>> > > >>> The final way we can take advantage help the maximum number of > people > > >>> find their way to us is to present a united community front to the > > >>> outside world. In the same way I am both a European and a Scot, we > > >>> need to be Smalltalkers *and*members of our individual > > >>> Smalltalk-platform communities. > > >>> > > >>> How can we help make that happen? > > >>> > > >>> This is not a silver bullet. It's going to cause a long-term > trend in > > >>> events, not a sudden abrupt change. But it will have a real, if > > >>> gradual effect. (assuming that > > >>> > > >>> Equally, it is not something we should ignore. It is something we > > >>> should make use of. We need to put effort into raising our profile > > >>> over the next 6 months. > > >>> > > >>> On 25 November 2015 at 19:51, Casimiro - GMAIL > > >>> <casimiro.barreto(a)gmail.com <mailto:casimiro.barreto@gmail.com>> > wrote: > > >>>> Em 25-11-2015 17:21, Nicolas Anquetil escreveu: > > >>>> > > >>>> > > >>>> > > >>>> On 25/11/2015 19:55, Jimmie Houchin wrote: > > >>>> > > >>>> Much truth in what you say. However, what Oracle choose to > invest its money, > > >>>> time, personnel resource into Java does affect its present and > future. It > > >>>> has a great affect. But it isn't the whole story. Java has > enough momentum > > >>>> in what already exists in the language and vm and what has been > release > > >>>> under its license, for businesses to keep going for some time > with only what > > >>>> currently exists. > > >>>> > > >>>> Cobol is still alive (and well) after > 50 years. > > >>>> You can expect Java programmers to find jobs for many years yet > to come > > >>>> :-) > > >>>> > > >>>> nicolas > > >>>> > > >>>> -- > > >>>> Nicolas Anquetil > > >>>> RMod team -- Inria Lille > > >>>> > > >>>> 1st: Java is extremely profitable. Each android phone, each > android TV, each > > >>>> android embedded system pays copyrights to Oracle. > > >>>> 2nd: Much of current cloud infrastructure depends on java. > > >>>> 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It > will continue > > >>>> to be used by same reasons these languages are used. > > >>>> > > >>>> IMHO, discussing java is not profitable. Better to discuss > things to be than > > >>>> talk about things that already happened. > > >>>> > > >>>> casimiro > > >>>> > > >>>> -- > > >>>> The information contained in this message is confidential and > intended to > > >>>> the recipients specified in the headers. If you received this > message by > > >>>> error, notify the sender immediately. The unauthorized use, > disclosure, copy > > >>>> or alteration of this message are strictly forbidden and > subjected to civil > > >>>> and criminal sanctions. > > >>>> > > >>>> == > > >>>> > > >>>> This email may be signed using PGP key ID: 0x4134A417 > > >>> > > >> > > >> -- > > >> www.tudorgirba.com <http://www.tudorgirba.com> > > >> > > >> "Reasonable is what we are accustomed with." > > >> > > >> > > > > > > > -- > > www.tudorgirba.com <http://www.tudorgirba.com> > > > > "Presenting is storytelling." > > > > >

Dec. 4, 2015

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

by Mariano Martinez Peck

On Fri, Dec 4, 2015 at 12:05 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 04 Dec 2015, at 14:29, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Max...Seaside uses WADynamicVariable (NOT DynamicVariable) which > are completely different. WADynamicVariable uses exception mechanism > while DynamicVariable uses the ProcessSpecificVariable. > But thanks anyway! > > > Oh manâ¦. Sorry :) > > I wonder, why WADynamicVariable *isnât* a DynamicVariable. The semantics > are the same if Iâm not mistaken (e.g. only available in the current > process) and I think access to a dynamic variable may even be faster > because it *doesnât* use the exception mechanism (i.e. no need to walk down > the stack). > If someone knows the answer, Iâd be happy to hear it. > > I bet it's because of portability. For example, i remember in GemStone the ProcessorLocalVariable did not behave the same as in Pharo. And it was actually an experiment. I think you cannot expect all this stuff to be ansi (or easily portable), while exceptions do. > Iâve played around with Process>>signalException: and > Context>>handleSignal: (which looked quite promising) but didnât get any > results. Iâm out of ideas. > > I have played all morning with an idea of using local variables. I arrive to the point where I DO HAVE the request context at hand, but I don't find an easy way to hook into do-its, print-it etc so that the closure evaluated gets the request context plugged. In other ways... let's say I have the context stored somewhere. I am at the SmalltalkEditor >> evaluateSelectionAndDo: aBlock and so..somewhere I need to do something like: WACurrentRequestContext use: self storedContextSomewhere during: [ self theSelectionToBeEvaluated ] and that's where I am now :) > Cheers, > Max > > > On Fri, Dec 4, 2015 at 7:32 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> Hereâs a snippet to play with: >> >> p := Processor activeProcess. >> x := 2. >> v := TestDynamicVariable value: x during: [ >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> ]. >> >> ((p instVarNamed: 'env') ifNotNil: [ :env| >> env copyWithout: nil ]) inspect >> >> Cheers, >> Max >> >> On 04 Dec 2015, at 10:47, Max Leske <maxleske(a)gmail.com> wrote: >> >> I feel you :) >> >> Without having thought this through completely: if you look at the >> implementation of DynamicVariable>>value:during: youâll see that the way it >> works is that the variable is bound to the active process. In the debugger >> you have access to the process that is being debugged and thus you should >> have access to the variables bound to it. You could try accessing all such >> variables by iterating over them (which I think will require an extension >> on Process because youâd need to access at least the PSKeys class variable). >> >> Cheers, >> Max >> >> On 04 Dec 2015, at 00:34, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> Hi guys, >> >> This thing I will ask in this email it's in my mind since YEARS. But I >> have always thought it was like that and that there was nothing we could >> do. However, I think it's time I ask again :) >> >> For those that have used Seaside, and you try to debug, you know that >> upon request processing seaside uses Exceptions mechanisim to always have >> access to the request, session, etc. They way that is done is very smart :) >> >> WACurrentRequestContext use: self during: aBlock >> >> In that case, "self" is the request instance and aBlock the closure that >> takes care of the request processing. So, inside that closure, everywhere >> you do "WACurrentRequestContext value" you get the correct request instance. >> >> So..that's great for Seaside, but debugging gets complicated. While you >> can restart, proceed, etc, once inside debugger, you cannot evaluate any >> piece of code that will use the session or request because you get >> a WARequestContextNotFound. Of course, because I guess the evaluation you >> do from cmd+d on a piece of text or via the debugger inspector, creates >> another closure/context which does not receive the WACurrentRequestContext >> instance. >> >> Now....besides WACurrentRequestContext I have my own class >> UserContextInformation where I basically have a bunch of stuff associated >> to the logged user. And I do exactly the same as the >> WACurrentRequestContext. And I have the same problem. I really want to be >> able to fix this. >> >> Anyone have an idea on how can I do it? I guess I can change the >> debugger, in the place where I evaluate code so that I wrap that evaluation >> with my request context instance??? >> >> Thoughts? >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Dec. 4, 2015

Re: [Pharo-dev] GTDebugger not draggable with latest VM

by Andrei Chis

Seems to happen due to the fix in issue 17178 <https://pharo.fogbugz.com/f/cases/17178> On Fri, Dec 4, 2015 at 4:21 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Seems that starting with Pharo 50483 one cannot drag the > inspector/playground/debugger. > > No idea what happened. > > On Fri, Dec 4, 2015 at 3:19 PM, Blondeau Vincent < > vincent.blondeau(a)worldline.com> wrote: > >> Hi, >> >> >> >> I have a problem on the latest Moose6.0 image. >> >> I was not able to open a Roassal view, I had a NativeBoost Generic >> failureâ¦ >> >> So I updated the VM to last stable, and, now, the GTdebugger and the >> Moose panel are not draggable anymoreâ¦ >> >> Can somebody is able to reproduce the problem? >> >> >> >> Thanks >> >> >> >> Cheers, >> >> Vincent >> >> ------------------------------ >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its integrity cannot be secured on the Internet, the Worldline liability >> cannot be triggered for the message content. Although the sender endeavours >> to maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> > >

Dec. 4, 2015