- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

by Tobias Pape

Hi Eliot On 21.11.2014, at 19:56, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Tobias, > > On Fri, Nov 21, 2014 at 10:52 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hi Eliot > > On 21.11.2014, at 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Tobias, > > > > On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > > > Hi, > > > > > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > > > > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > > > juanlists(a)jvuletich.org> wrote: > > > > > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > > > >>> > > > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete > > > subclasses (*). Names do mean something. (**) > > > >>> > > > >>> You're right about the FloatArray confusion. However, note that the > > > IEEE standard calls it single and double. It's only C using "float" to mean > > > "single precision". > > > >>> > > > >>> I'd name the abstract superclass Float, for readability, and the > > > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I > > > don't see the need for having a deep LimitedPrecisionReal - Float - > > > BoxedDouble/ImmediateDouble deep hierarchy now. > > > >>> > > > >>> If we ever add single-precision floats, we should name them > > > BoxedSingle and ImmediateSingle. At that point we might want a Single > > > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > > > that bridge when we get there. > > > >>> > > > >>> - Bert - > > > >>> > > > >>> (*) Since we're not going to see the class names often, we could even > > > spell it out as BoxedDoublePrecisionFloat and > > > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation > > > to the abstract Float very clear. > > > >>> > > > >>> (**) We could also try to make the names googleable. I was surprised > > > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it. > > > Maybe there are two better words? > > > >> > > > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > > > ImmediateDouble for consistency with SmallInteger. > > > > > > > > Then it would have to be LargeDouble for consistency with LargeInteger, > > > too. Which I don't find compelling. > > > > > > > > Also, with the 64 bit format we get many more immediate objects. There > > > already are immediate integers and characters, floats will be the third, > > > there could be more, like immediate points. For those, the small/large > > > distinction does not make sense. > > > > > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead > > > of "small" use "immediate": > > > > > > > > Float - BoxedFloat - ImmediateFloat > > > > > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending on > > > the magnitude of its exponent. > > > > > > I don't like the idea of putting a VM/Storage detail into the Class name. > > > The running system itself does not care about whether Floats or Integers > > > are > > > boxed or immediate. > > > > > > > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as > > much out of the VM into the system, and hiding it from clients via > > encapsulation. So unlike many other VMs the compiler is in the system, the > > system explicitly separates SmallInteger, LargePositiveInteger and > > LargeNegativeInteger and implements large integer arithmetic with Smalltalk > > code that uses SmallIntegers. Note that the primitives are an optional > > extra optimization that the VM does not need to implement. So for me it is > > in keeping with the current system to use BoxedFloat and SmallFloat or > > BoxedDouble and SmallDouble. > > > > This lifting things up provides us with an extremely malleable system. > > Pushing things down into the VM does the opposite. > > >> >> I can understand. It is however a tradeoff between abstraction and malleability. >> I'd rather see everything done in Smalltalk. Yet primitives not exposing its >> innards. >> >> I think I just can't have the cake and have it, too. >> > yes, alas it is all about tradeoffs :-). But that's great. The more varieties the merrier. > > > > > > For example in RSqueakVM (aka SPy) there is no immediate > > > Integer whatsoever. Yes, tagged ints are read during image startup but they > > > aren't subsequently represented as immediates or tagged ints after that. > > > > > > > Well because it's implemented above RPython I guess it is using Python's > > bignum code directly. That's fine but its a bit of a cheat. >> >> I was talking of SmallInts here. There is no bignum code involved. >> On the RPython side, SmallIntegers are just objects that have a field >> that is not accessible from Smalltalk but keeps a machine-word integer. >> > Hmmm, somewhere there's got to be a discrimination between SmallIntegers and other objects, right? It is done. They are just objects but object identity is delegated to value identity [1]. All primitives know about this and they unwrap and rewrap the boxed machine int. It's just a straight-forward boxed implementation of integers. Where have I confused you? > > > > Just as input, in the Racket language and other Schemes, > > > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > > > and for floats they have flonums and "extflonums" (80bit). > > > > > > Best > > > -Tobias Best -Tobias [1]: https://bitbucket.org/pypy/lang-smalltalk/src/2a99a4827c84352bbd8344a327937…

Nov. 21, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

by Eliot Miranda

Hi Tobias, On Fri, Nov 21, 2014 at 10:52 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hi Eliot > > On 21.11.2014, at 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Tobias, > > > > On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > > > Hi, > > > > > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> > wrote: > > > > > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > > > juanlists(a)jvuletich.org> wrote: > > > > > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > > > >>> > > > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the > concrete > > > subclasses (*). Names do mean something. (**) > > > >>> > > > >>> You're right about the FloatArray confusion. However, note that the > > > IEEE standard calls it single and double. It's only C using "float" to > mean > > > "single precision". > > > >>> > > > >>> I'd name the abstract superclass Float, for readability, and the > > > isFloat test etc. Also: "Float pi" reads a lot nicer than anything > else. I > > > don't see the need for having a deep LimitedPrecisionReal - Float - > > > BoxedDouble/ImmediateDouble deep hierarchy now. > > > >>> > > > >>> If we ever add single-precision floats, we should name them > > > BoxedSingle and ImmediateSingle. At that point we might want a Single > > > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > > > that bridge when we get there. > > > >>> > > > >>> - Bert - > > > >>> > > > >>> (*) Since we're not going to see the class names often, we could > even > > > spell it out as BoxedDoublePrecisionFloat and > > > ImmediateDoublePrecisionFloat. Only half joking. It would make the > relation > > > to the abstract Float very clear. > > > >>> > > > >>> (**) We could also try to make the names googleable. I was > surprised > > > to not get a good hit for "boxed immediate". Only "boxed unboxed" > finds it. > > > Maybe there are two better words? > > > >> > > > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > > > ImmediateDouble for consistency with SmallInteger. > > > > > > > > Then it would have to be LargeDouble for consistency with > LargeInteger, > > > too. Which I don't find compelling. > > > > > > > > Also, with the 64 bit format we get many more immediate objects. > There > > > already are immediate integers and characters, floats will be the > third, > > > there could be more, like immediate points. For those, the small/large > > > distinction does not make sense. > > > > > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but > instead > > > of "small" use "immediate": > > > > > > > > Float - BoxedFloat - ImmediateFloat > > > > > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending > on > > > the magnitude of its exponent. > > > > > > I don't like the idea of putting a VM/Storage detail into the Class > name. > > > The running system itself does not care about whether Floats or > Integers > > > are > > > boxed or immediate. > > > > > > > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as > > much out of the VM into the system, and hiding it from clients via > > encapsulation. So unlike many other VMs the compiler is in the system, > the > > system explicitly separates SmallInteger, LargePositiveInteger and > > LargeNegativeInteger and implements large integer arithmetic with > Smalltalk > > code that uses SmallIntegers. Note that the primitives are an optional > > extra optimization that the VM does not need to implement. So for me it > is > > in keeping with the current system to use BoxedFloat and SmallFloat or > > BoxedDouble and SmallDouble. > > > > This lifting things up provides us with an extremely malleable system. > > Pushing things down into the VM does the opposite. > > > > I can understand. It is however a tradeoff between abstraction and > malleability. > I'd rather see everything done in Smalltalk. Yet primitives not exposing > its > innards. > > I think I just can't have the cake and have it, too. > yes, alas it is all about tradeoffs :-). But that's great. The more varieties the merrier. > > > > > For example in RSqueakVM (aka SPy) there is no immediate > > > Integer whatsoever. Yes, tagged ints are read during image startup but > they > > > aren't subsequently represented as immediates or tagged ints after > that. > > > > > > > Well because it's implemented above RPython I guess it is using Python's > > bignum code directly. That's fine but its a bit of a cheat. > > I was talking of SmallInts here. There is no bignum code involved. > On the RPython side, SmallIntegers are just objects that have a field > that is not accessible from Smalltalk but keeps a machine-word integer. > Hmmm, somewhere there's got to be a discrimination between SmallIntegers and other objects, right? > > Just as input, in the Racket language and other Schemes, > > > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > > > and for floats they have flonums and "extflonums" (80bit). > > > > > > Best > > > -Tobias > -- best, Eliot

Nov. 21, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

by Tobias Pape

Hi Eliot On 21.11.2014, at 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Tobias, > > On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > Hi, > > > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > > juanlists(a)jvuletich.org> wrote: > > > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > > >>> > > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete > > subclasses (*). Names do mean something. (**) > > >>> > > >>> You're right about the FloatArray confusion. However, note that the > > IEEE standard calls it single and double. It's only C using "float" to mean > > "single precision". > > >>> > > >>> I'd name the abstract superclass Float, for readability, and the > > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I > > don't see the need for having a deep LimitedPrecisionReal - Float - > > BoxedDouble/ImmediateDouble deep hierarchy now. > > >>> > > >>> If we ever add single-precision floats, we should name them > > BoxedSingle and ImmediateSingle. At that point we might want a Single > > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > > that bridge when we get there. > > >>> > > >>> - Bert - > > >>> > > >>> (*) Since we're not going to see the class names often, we could even > > spell it out as BoxedDoublePrecisionFloat and > > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation > > to the abstract Float very clear. > > >>> > > >>> (**) We could also try to make the names googleable. I was surprised > > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it. > > Maybe there are two better words? > > >> > > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > > ImmediateDouble for consistency with SmallInteger. > > > > > > Then it would have to be LargeDouble for consistency with LargeInteger, > > too. Which I don't find compelling. > > > > > > Also, with the 64 bit format we get many more immediate objects. There > > already are immediate integers and characters, floats will be the third, > > there could be more, like immediate points. For those, the small/large > > distinction does not make sense. > > > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead > > of "small" use "immediate": > > > > > > Float - BoxedFloat - ImmediateFloat > > > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending on > > the magnitude of its exponent. > > > > I don't like the idea of putting a VM/Storage detail into the Class name. > > The running system itself does not care about whether Floats or Integers > > are > > boxed or immediate. > > > > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as > much out of the VM into the system, and hiding it from clients via > encapsulation. So unlike many other VMs the compiler is in the system, the > system explicitly separates SmallInteger, LargePositiveInteger and > LargeNegativeInteger and implements large integer arithmetic with Smalltalk > code that uses SmallIntegers. Note that the primitives are an optional > extra optimization that the VM does not need to implement. So for me it is > in keeping with the current system to use BoxedFloat and SmallFloat or > BoxedDouble and SmallDouble. > > This lifting things up provides us with an extremely malleable system. > Pushing things down into the VM does the opposite. > I can understand. It is however a tradeoff between abstraction and malleability. I'd rather see everything done in Smalltalk. Yet primitives not exposing its innards. I think I just can't have the cake and have it, too. > > For example in RSqueakVM (aka SPy) there is no immediate > > Integer whatsoever. Yes, tagged ints are read during image startup but they > > aren't subsequently represented as immediates or tagged ints after that. > > > > Well because it's implemented above RPython I guess it is using Python's > bignum code directly. That's fine but its a bit of a cheat. I was talking of SmallInts here. There is no bignum code involved. On the RPython side, SmallIntegers are just objects that have a field that is not accessible from Smalltalk but keeps a machine-word integer. > > > > > > Just as input, in the Racket language and other Schemes, > > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > > and for floats they have flonums and "extflonums" (80bit). > > > > Best > > -Tobias > >

Nov. 21, 2014

Re: [Pharo-dev] [squeak-dev] Float hierarchy for 64-bit Spur

by Eliot Miranda

Hi Tobias, On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hi, > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > juanlists(a)jvuletich.org> wrote: > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > >>> > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete > subclasses (*). Names do mean something. (**) > >>> > >>> You're right about the FloatArray confusion. However, note that the > IEEE standard calls it single and double. It's only C using "float" to mean > "single precision". > >>> > >>> I'd name the abstract superclass Float, for readability, and the > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I > don't see the need for having a deep LimitedPrecisionReal - Float - > BoxedDouble/ImmediateDouble deep hierarchy now. > >>> > >>> If we ever add single-precision floats, we should name them > BoxedSingle and ImmediateSingle. At that point we might want a Single > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > that bridge when we get there. > >>> > >>> - Bert - > >>> > >>> (*) Since we're not going to see the class names often, we could even > spell it out as BoxedDoublePrecisionFloat and > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation > to the abstract Float very clear. > >>> > >>> (**) We could also try to make the names googleable. I was surprised > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it. > Maybe there are two better words? > >> > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > ImmediateDouble for consistency with SmallInteger. > > > > Then it would have to be LargeDouble for consistency with LargeInteger, > too. Which I don't find compelling. > > > > Also, with the 64 bit format we get many more immediate objects. There > already are immediate integers and characters, floats will be the third, > there could be more, like immediate points. For those, the small/large > distinction does not make sense. > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead > of "small" use "immediate": > > > > Float - BoxedFloat - ImmediateFloat > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending on > the magnitude of its exponent. > > I don't like the idea of putting a VM/Storage detail into the Class name. > The running system itself does not care about whether Floats or Integers > are > boxed or immediate. > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as much out of the VM into the system, and hiding it from clients via encapsulation. So unlike many other VMs the compiler is in the system, the system explicitly separates SmallInteger, LargePositiveInteger and LargeNegativeInteger and implements large integer arithmetic with Smalltalk code that uses SmallIntegers. Note that the primitives are an optional extra optimization that the VM does not need to implement. So for me it is in keeping with the current system to use BoxedFloat and SmallFloat or BoxedDouble and SmallDouble. This lifting things up provides us with an extremely malleable system. Pushing things down into the VM does the opposite. For example in RSqueakVM (aka SPy) there is no immediate > Integer whatsoever. Yes, tagged ints are read during image startup but they > aren't subsequently represented as immediates or tagged ints after that. > Well because it's implemented above RPython I guess it is using Python's bignum code directly. That's fine but its a bit of a cheat. > > Just as input, in the Racket language and other Schemes, > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > and for floats they have flonums and "extflonums" (80bit). > > Best > -Tobias thanks -- best, Eliot

Nov. 21, 2014

[pharo-project/pharo-core]

by GitHub

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

Nov. 21, 2014

[pharo-project/pharo-core] 898184: 40381

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 89818487a755292e8f477a5e855cdca5b578b619 https://github.com/pharo-project/pharo-core/commit/89818487a755292e8f477a5e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-21 (Fri, 21 Nov 2014) Changed paths: R Collections-Abstract.package/Collection.class/instance/enumerating/do_displayingProgress_.st R Collections-Abstract.package/Collection.class/instance/enumerating/do_displayingProgress_every_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script381.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40381.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Caching.package/extension/BlockClosure/instance/memoized.st A System-Caching.package/extension/BlockClosure/instance/memoizedUsing_.st A System-CachingTests.package/extension/BlockClosureTest/instance/testMemoizedDictionary.st A System-CachingTests.package/extension/BlockClosureTest/instance/testMemoizedLRUCache.st A System-CachingTests.package/extension/LRUCache/instance/testSupportGetCachedAssociations.st A UIManager.package/extension/Collection/instance/do_displayingProgress_.st A UIManager.package/extension/Collection/instance/do_displayingProgress_every_.st Log Message: ----------- 40381 14487 do:displayingProgress: in Collection should be part of the UIManager package https://pharo.fogbugz.com/f/cases/14487 14458 Add BlockClosure>>memoized https://pharo.fogbugz.com/f/cases/14458 http://files.pharo.org/image/40/40381.zip

Nov. 21, 2014

Re: [Pharo-dev] Listening for shift key pressed

by Aliaksei Syrel

Hi Ben, If at the end of InputEventFetcher>>waitForInput > you put "Transcript crShow: Time now" > and I think you'll be looking at as raw an event aas you can get. Now this exhibits some strange behaviour? Pushing <shift> on its own does > not produce an event, however pushing <shift> fast multiple times does > generate events. ??? It's maybe because you move mouse, or randomly touch touchpad. After some investigations and digging lower and lower till primitive methods, I realized that VM itself doesn't queue an event after user presses Shift. It's just a modifier bit, that is applied on a real events, such as mouse moves or normal keyboard events. Cheers, Alex

Nov. 21, 2014

Re: [Pharo-dev] Listening for shift key pressed

by Ben Coman

Aliaksei Syrel wrote: > Hi, > > Thanks for the fast answer. But keyDown or keyUp are triggered only for > not modifier keys (Tab, space, [0-9a-Z]). When I press Shift, keyDown is > not triggered. :( > > Cheers, > Alex > > On Fri, Nov 21, 2014 at 4:12 PM, Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > Hi, > > I've some hints! > > Try listening to the keyDown and keyUp events of a morph. And take a > look at the #key message of a keyboard event. > > Cheers, > Guille > > On Fri, Nov 21, 2014 at 4:06 PM, Aliaksei Syrel > <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: > > Hi, > > In our project we would like to trigger some actions when user > presses down/up Shift button. But we didn't find how to do it. > It seems that such keys as Shift, Capslock, Ctrl are event > modifiers in Pharo, that apply on already existing events (in > HandMorph>>generateKeyboardEvent: evtBuf). > > Do you have any ideas or maybe have experience concerning > described problem? > Thanks in advance. If at the end of InputEventFetcher>>waitForInput you put "Transcript crShow: Time now" and I think you'll be looking at as raw an event aas you can get. Now this exhibits some strange behaviour? Pushing <shift> on its own does not produce an event, however pushing <shift> fast multiple times does generate events. ??? There is a new event loop being implemented in OSWindow (search this list). Maybe that will help. cheers -ben

Nov. 21, 2014

Re: [Pharo-dev] Listening for shift key pressed

by Nicolai Hess

2014-11-21 16:22 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi, > > Thanks for the fast answer. But keyDown or keyUp are triggered only for > not modifier keys (Tab, space, [0-9a-Z]). When I press Shift, keyDown is > not triggered. :( > > Cheers, > Alex > > On Fri, Nov 21, 2014 at 4:12 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi, >> >> I've some hints! >> >> Try listening to the keyDown and keyUp events of a morph. And take a look >> at the #key message of a keyboard event. >> >> Cheers, >> Guille >> >> On Fri, Nov 21, 2014 at 4:06 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >> >>> Hi, >>> >>> In our project we would like to trigger some actions when user presses >>> down/up Shift button. But we didn't find how to do it. It seems that such >>> keys as Shift, Capslock, Ctrl are event modifiers in Pharo, that apply on >>> already existing events (in HandMorph>>generateKeyboardEvent: evtBuf). >>> >>> Do you have any ideas or maybe have experience concerning described >>> problem? >>> Thanks in advance. >>> >>> Cheers, >>> Alex >>> >> >> > >From KeyPrinterMorph: handlesKeyboard: evt ^ true keyDown: anEvent self inform: anEvent asString

Nov. 21, 2014

Re: [Pharo-dev] Glorp and DBXTalk

by Brad

http://dbxtalk.smallworks.eu Brad Selfridge 913-269-2385 > On Nov 21, 2014, at 9:04 AM, Hernan Wilkinson <hernan.wilkinson(a)gmail.com> wrote: > > Hi, > quick question, how can I get Glorp for Pharo? And DBXTalk? > If anyone can provide me with some links it will be much appreciated :-) > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Nov. 21, 2014