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

Re: [Pharo-dev] AsmJit

by Eliot Miranda

Hi Jan, On Tue, Dec 15, 2015 at 11:22 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi Esteban, Eliot, Clemont > > thanks very much for elaborate answer. I'm aware of all what you said > (well, most :-), but my actual needs are very low and primitive. > > All I need now is something that allows me to turn x86_64 assembly > into a machine code using a sane Smalltalk API, which I can later copy > to VM code space. Nothing more, nothing less :-) I do not fancy > spending time writing yet-another-x86-assembler hence my interest in > asmjit. > What's the use case? What do you mean "copy to VM code space"? I want to know because I want to give you a viable direction, but I need to know more about your intended use first. > > Thanks! Jan > > > > On Tue, 2015-12-15 at 18:34 +0100, ClÃ©ment Bera wrote: > > We're getting away from Jan initial question here ... > > > > I think the point here is that Cog has: > > - 2 stable back ends: ARMv5 and x86 > > - 2 backends stable in the simulator with production planned for ~ > > April: x64 and MIPS > > and Tim is willing to do the ARMv8 backend. > > > > All the 4, and soon 5, cog back ends are maintained: > > - x86 and x64 maintained by Eliot > > - MIPS maintained by Ryan > > - ARMv5 and soon ARMv8 maintained by Tim > > > > Each backend requires months of work. > > > > Do you want to maintain 10 backends instead of 5 ? Do want to spend > > time to implement 5 backends or 10 ? > > > > I don't. Only the x86 backend is duplicated right now in AsmJIT. > > > > So one idea is to reuse Cog's backends from the image instead of > > AsmJIT. To do so, we can use encodings available in the sista > > extended instruction set to tell Cog what machine code to generate. A > > project named uFFI aims, among other things, at doing this, by > > providing a unified interface between the Cog backends and AsmJIT. > > > > > > 2015-12-15 16:43 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > Hi Jan, > > > > > > > On Dec 15, 2015, at 3:06 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > > > wrote: > > > > > > > > Hi guys, > > > > > > > > two queations: > > > > > > > > (i) Is AsmJit going to be developed any more or it's abandoned > > > > as well as native boost? > > > > > > AsmJIT is effectively being abandoned but NativeBoost is not. > > > > > > The key limitation of AsmJIT is that it was not designed to be > > > cross platform; it is effectively an x86 assembler. As such it's > > > use gets in the way of ARM and x86_64 (I am currently getting the C > > > version of 64-bit Cog Spur working on x86_64, given that it is > > > working in the simulator). > > > > > > Another limitation is that it doesn't play that well with the VM's > > > JIT. Igor and I never managed to work on integrating it better. > > > The VM's job is managing code and Igor's approach was to hack; > > > eliminating execution protection in the entire heap, instead of > > > extending the support that either the Alien plugin's callback > > > support or the JIT's executable method zone provides. Making the > > > entire heap executable is /not/ a sensible approach. > > > > > > But there is a better way! A key component of the Sista adaptive > > > optimizer/speculative inlined that ClÃ©ment is currently stabilizing > > > (!!) is a set of bytecodes that encode unsafe operations like > > > at:put: without bounds, type or store checks. For example, the > > > normal at:put: is about a hundred instructions, checks for > > > smallinteger indices, differentiates between byte, 32-but long and > > > pointer objects and does a store check. But one of the Sista codes > > > for at:put: generates about two instructions, one to adjust the > > > index, the other to do the store. Distaste job is to analyze code > > > and inline methods using these unsafe bytecodes where they are > > > proven to be safe, hence increasing performance. > > > > > > Unlike AsmJIT, Sista's unsafe bytecodes are cross platform, and, > > > being executed by the VM, can work on an interpreter VM or be > > > converted to machine code by the JIT. > > > > > > So our plan is to extend these bytecodes with ones that support > > > marshaling arguments for NativeBoost calls. Ronie Salgado has > > > already extended his lowcode scheme to define these instructions > > > and sometime soon (hopefully 2016) we shall rewrite NativeBoost to > > > target these bytecodes. > > > > > > HTH > > > > > > > (ii)Where can I find latest AsmJit? I'm properly confused: > > > > > > > > * Is is the one in latest Pharo 4.0 (5.0) image? > > > > * Is it the one here: http://smalltalkhub.com/#!/~Pharo/AsmJi > > > t ? > > > > (the one in the image seem to be based on completely > > > disjunct > > > > set of .mcz than those in the repo above). > > > > > > > > Best, Jan > > > > > > _,,,^..^,,,_ (phone) > > > > > -- _,,,^..^,,,_ best, Eliot

Dec. 15, 2015

Re: [Pharo-dev] AsmJit

by Jan Vrany

Hi Esteban, Eliot, Clemont thanks very much for elaborate answer. I'm aware of all what you said (well, most :-), but my actual needs are very low and primitive.Â All I need now is something that allows me to turn x86_64 assemblyÂ into a machine code using a sane Smalltalk API, which I can later copy to VM code space. Nothing more, nothing less :-) I do not fancy spending time writing yet-another-x86-assembler hence my interest inÂ asmjit.Â Thanks! Jan On Tue, 2015-12-15 at 18:34 +0100, ClÃ©ment Bera wrote: > We're getting away from Jan initial question here ... > > I think the point here is that Cog has: > - 2 stable back ends: ARMv5 and x86Â > - 2 backends stable in the simulator with production planned for ~ > April: x64 and MIPS > and Tim is willing to do the ARMv8 backend. > > All the 4, and soon 5, cog back ends are maintained: > - x86 and x64 maintained by Eliot > - MIPS maintained by Ryan > - ARMv5 and soon ARMv8 maintained by Tim > > Each backend requires months of work. > > Do you want to maintain 10 backends instead of 5 ? Do want to spend > time to implement 5 backends or 10 ? > > I don't. Only the x86 backend is duplicated right now in AsmJIT. > > So one idea is to reuse Cog's backends from the image instead of > AsmJIT. To do so, we can use encodings available in the sista > extended instruction set to tell Cog what machine code to generate. A > project named uFFI aims, among other things, at doing this, by > providing a unified interface between the Cog backends and AsmJIT. > > > 2015-12-15 16:43 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Jan, > > > > > On Dec 15, 2015, at 3:06 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > > wrote: > > > > > > Hi guys, > > > > > > two queations: > > > > > > (i) Is AsmJit going to be developed any more or it's abandoned > > >Â Â Â as well as native boost? > > > > AsmJIT is effectively being abandoned but NativeBoost is not. > > > > The key limitation of AsmJIT is that it was not designed to be > > cross platform; it is effectively an x86 assembler.Â As such it's > > use gets in the way of ARM and x86_64 (I am currently getting the C > > version of 64-bit Cog Spur working on x86_64, given that it is > > working in the simulator). > > > > Another limitation is that it doesn't play that well with the VM's > > JIT.Â Igor and I never managed to work on integrating it better.Â > > The VM's job is managing code and Igor's approach was to hack; > > eliminating execution protection in the entire heap, instead of > > extending the support that either the Alien plugin's callback > > support or the JIT's executable method zone provides.Â Making the > > entire heap executable is /not/ a sensible approach. > > > > But there is a better way!Â A key component of the Sista adaptive > > optimizer/speculative inlined that ClÃ©ment is currently stabilizing > > (!!) is a set of bytecodes that encode unsafe operations like > > at:put: without bounds, type or store checks.Â For example, the > > normal at:put: is about a hundred instructions, checks for > > smallinteger indices, differentiates between byte, 32-but long and > > pointer objects and does a store check. But one of the Sista codes > > for at:put: generates about two instructions, one to adjust the > > index, the other to do the store.Â Distaste job is to analyze code > > and inline methods using these unsafe bytecodes where they are > > proven to be safe, hence increasing performance. > > > > Unlike AsmJIT, Sista's unsafe bytecodes are cross platform, and, > > being executed by the VM, can work on an interpreter VM or be > > converted to machine code by the JIT. > > > > So our plan is to extend these bytecodes with ones that support > > marshaling arguments for NativeBoost calls.Â Ronie Salgado has > > already extended his lowcode scheme to define these instructions > > and sometime soon (hopefully 2016) we shall rewrite NativeBoost to > > target these bytecodes. > > > > HTH > > > > > (ii)Where can I find latest AsmJit? I'm properly confused: > > > > > >Â Â Â * Is is the one in latest Pharo 4.0 (5.0) image? > > >Â Â Â * Is it the one here: http://smalltalkhub.com/#!/~Pharo/AsmJi > > t ? > > >Â Â Â Â (the one in the image seem to be based on completely > > disjunct > > >Â Â Â Â set of .mcz than those in the repo above). > > > > > > Best, Jan > > > > _,,,^..^,,,_ (phone) > >

Dec. 15, 2015

Re: [Pharo-dev] potential to include cryptography in base image

by Ben Coman

On Wed, Dec 16, 2015 at 1:36 AM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > > On 12/15/2015 05:20 AM, Sven Van Caekenberghe wrote: >> >> Robert, >> >> I think that the Pharo community, part of which is more business oriented, >> is absolutely interested in more and better Crypto code. In any case, I am. >> >> What we absolutely want, if it is not already the case (I did not check), >> is that the Crypto code can be loaded using 1 single action (through our >> validated Monticello configurations and Catalog mechanism) - I am sure you >> will find help to achieve and maintain (through a CI process) that goal. > > > Alright, please let me know. If someone shows me how to get this into > configurations and the Catalog, we'll get it done. Versionneer... http://forum.world.st/Versioneer-nice-mmMmmm-td4779483.html Catalog... http://catalog.pharo.org/catalog/note-for-developers?_k=1Ur7YrxY2p1TaD4k Repository for Configuration... http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo50 cheers -ben > > robert > >> >> Whether it should be a base part of the image is another question. >> Modularity is a huge goal for Pharo. This is a much harder discussion (as >> the same can be said of or asked for for many packages that are generally >> useful: XML, CSV, JSON, SQL, ...). In any the case, the first step is the >> one described in the previous paragraph. Then you need traction, usage, and >> maybe demand for full inclusion. >> >> Regards, >> >> Sven >> >>> On 15 Dec 2015, at 11:00, Robert Withers <robert.w.withers(a)gmail.com> >>> wrote: >>> >>> It was suggested to me that I write to the list and raise the question >>> about cryptography being included in the base image. Really I have 3 >>> questions I would ask you all: >>> >>> â¢ is it desirable to include cryptography? >>> â¢ is it feasible to include cryptography? >>> â¢ what is the time frame for including cryptography? >>> Given the thread on password hashing (and salting and so on), there are >>> good, solid implementations in the cryptography package. Looking in the >>> Cryptography repository, there is a Pharo 5.0 compatible Cryptography >>> package. >>> >>> In light of another recent thread discussing random number generation, >>> discussion about the best approach to random algorithms in cryptography >>> ought be engaged. For instance, the SecureRandom algorithm evidently >>> provides some level of guarantee. >>> >>> To underline the solidity I am attaching a profile of all 102 >>> cryptography tests passing green. This profile demonstrates that there are >>> no areas of particular inefficiency - nothing stands out to be improved - >>> means that the entire library is maximally efficient. >>> >>> And so I please ask that we have these discussions, for there is a lot of >>> value in this package for general and basic use. >>> >>> >>> -- >>> . .. ... ^,^ best, robert >>> <Cryptography Spy Results.text.gz> > > > -- > . .. .. ^,^ best, robert >

Dec. 15, 2015

Re: [Pharo-dev] potential to include cryptography in base image

by Peter UhnÃ¡k

> Alright, please let me know. If someone shows me how to get this into > configurations and the Catalog, we'll get it done. You just need to commit your configuration to MetaRepoForPharo50 (this should be public repo; if you can't commit ask on the mailing list and someone will add you). But before you do that, open Versionner (World > Tools > Versionner), right click your configuration and select "add catalog methods". This will add class-side methods to the Configuration class which you can modify to write things like description, website, tags, etc. You can also use the Veresionner to create your ConfigurationOf if you don't have one already, more info on Configurations can be found in DeepIntoPharo (Metacello chapter) https://ci.inria.fr/pharo-contribution/view/Books/job/DeepIntoPharo/lastSuc… or look through other configurations in the image or search through mailing list archives, there should be plenty of information. Peter

Dec. 15, 2015

Re: [Pharo-dev] potential to include cryptography in base image

by Robert Withers

On 12/15/2015 05:20 AM, Sven Van Caekenberghe wrote: > Robert, > > I think that the Pharo community, part of which is more business oriented, is absolutely interested in more and better Crypto code. In any case, I am. > > What we absolutely want, if it is not already the case (I did not check), is that the Crypto code can be loaded using 1 single action (through our validated Monticello configurations and Catalog mechanism) - I am sure you will find help to achieve and maintain (through a CI process) that goal. Alright, please let me know. If someone shows me how to get this into configurations and the Catalog, we'll get it done. robert > > Whether it should be a base part of the image is another question. Modularity is a huge goal for Pharo. This is a much harder discussion (as the same can be said of or asked for for many packages that are generally useful: XML, CSV, JSON, SQL, ...). In any the case, the first step is the one described in the previous paragraph. Then you need traction, usage, and maybe demand for full inclusion. > > Regards, > > Sven > >> On 15 Dec 2015, at 11:00, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> It was suggested to me that I write to the list and raise the question about cryptography being included in the base image. Really I have 3 questions I would ask you all: >> >> â¢ is it desirable to include cryptography? >> â¢ is it feasible to include cryptography? >> â¢ what is the time frame for including cryptography? >> Given the thread on password hashing (and salting and so on), there are good, solid implementations in the cryptography package. Looking in the Cryptography repository, there is a Pharo 5.0 compatible Cryptography package. >> >> In light of another recent thread discussing random number generation, discussion about the best approach to random algorithms in cryptography ought be engaged. For instance, the SecureRandom algorithm evidently provides some level of guarantee. >> >> To underline the solidity I am attaching a profile of all 102 cryptography tests passing green. This profile demonstrates that there are no areas of particular inefficiency - nothing stands out to be improved - means that the entire library is maximally efficient. >> >> And so I please ask that we have these discussions, for there is a lot of value in this package for general and basic use. >> >> >> -- >> . .. ... ^,^ best, robert >> <Cryptography Spy Results.text.gz> -- . .. .. ^,^ best, robert

Dec. 15, 2015

Re: [Pharo-dev] AsmJit

by ClÃ©ment Bera

We're getting away from Jan initial question here ... I think the point here is that Cog has: - 2 stable back ends: ARMv5 and x86 - 2 backends stable in the simulator with production planned for ~ April: x64 and MIPS and Tim is willing to do the ARMv8 backend. All the 4, and soon 5, cog back ends are maintained: - x86 and x64 maintained by Eliot - MIPS maintained by Ryan - ARMv5 and soon ARMv8 maintained by Tim Each backend requires months of work. Do you want to maintain 10 backends instead of 5 ? Do want to spend time to implement 5 backends or 10 ? I don't. Only the x86 backend is duplicated right now in AsmJIT. So one idea is to reuse Cog's backends from the image instead of AsmJIT. To do so, we can use encodings available in the sista extended instruction set to tell Cog what machine code to generate. A project named uFFI aims, among other things, at doing this, by providing a unified interface between the Cog backends and AsmJIT. 2015-12-15 16:43 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Jan, > > > On Dec 15, 2015, at 3:06 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > > > Hi guys, > > > > two queations: > > > > (i) Is AsmJit going to be developed any more or it's abandoned > > as well as native boost? > > AsmJIT is effectively being abandoned but NativeBoost is not. > > The key limitation of AsmJIT is that it was not designed to be cross > platform; it is effectively an x86 assembler. As such it's use gets in the > way of ARM and x86_64 (I am currently getting the C version of 64-bit Cog > Spur working on x86_64, given that it is working in the simulator). > > Another limitation is that it doesn't play that well with the VM's JIT. > Igor and I never managed to work on integrating it better. The VM's job is > managing code and Igor's approach was to hack; eliminating execution > protection in the entire heap, instead of extending the support that either > the Alien plugin's callback support or the JIT's executable method zone > provides. Making the entire heap executable is /not/ a sensible approach. > > But there is a better way! A key component of the Sista adaptive > optimizer/speculative inlined that ClÃ©ment is currently stabilizing (!!) is > a set of bytecodes that encode unsafe operations like at:put: without > bounds, type or store checks. For example, the normal at:put: is about a > hundred instructions, checks for smallinteger indices, differentiates > between byte, 32-but long and pointer objects and does a store check. But > one of the Sista codes for at:put: generates about two instructions, one to > adjust the index, the other to do the store. Distaste job is to analyze > code and inline methods using these unsafe bytecodes where they are proven > to be safe, hence increasing performance. > > Unlike AsmJIT, Sista's unsafe bytecodes are cross platform, and, being > executed by the VM, can work on an interpreter VM or be converted to > machine code by the JIT. > > So our plan is to extend these bytecodes with ones that support marshaling > arguments for NativeBoost calls. Ronie Salgado has already extended his > lowcode scheme to define these instructions and sometime soon (hopefully > 2016) we shall rewrite NativeBoost to target these bytecodes. > > HTH > > > (ii)Where can I find latest AsmJit? I'm properly confused: > > > > * Is is the one in latest Pharo 4.0 (5.0) image? > > * Is it the one here: http://smalltalkhub.com/#!/~Pharo/AsmJit ? > > (the one in the image seem to be based on completely disjunct > > set of .mcz than those in the repo above). > > > > Best, Jan > > _,,,^..^,,,_ (phone) >

Dec. 15, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: Unicode Support))

by Mark Bestley

On 15/12/2015 16:05, H. Hirzel wrote: > On 12/15/15, Ben Coman <btc(a)openinworld.com> wrote: >> On Thu, Dec 10, 2015 at 12:37 AM, Todd Blanchard <tblanchard(a)mac.com> >> wrote: >>> They are practically the same thing. >>> >>> ICU was developed by Taligent which was a joint venture between Apple and >>> IBM. Makes sense that NSString and ICU's UnicodeString are pretty close >>> in implementation. ICU was also ported to Java for Sun by IBM. The point >>> is - this is a very elaborate chunk of code with far reach. If ICU is >>> wrong on some point - it is universally wrong and thus likely to be taken >>> as "right" as it is at least consistent. I think re-implementing it is >>> folly TBH. Just use it. >> I suspect the history is wrong as NSString was first written at NeXT when they were not Apple and was not unicode aware at first, but the end result does seem to be NSString now uses ICU >> Apple seem to have moved on from NSString to support Unicode in a >> different way in Switft... > > Could you please give some more details? > > I have read > https://www.objc.io/issues/9-strings/unicode/#nsstring-and-unicode > so far. > > It says that an NSString object actually represents an array of > UTF-16-encoded code units. > > This in contrast to Squeak / Pharo where a String is an > ArrayedCollection of 21 bit Unicode code points (transparently > optimizing to a ByteArray if the string only contains values of the > first code page). > > The Swift code (well for the next version) is open source see https://github.com/apple/swift-corelibs-foundation for the Foundation lib which includes Strings. Foundation is being rewritten in Swift rather than Objective C so should be Swift->C but I wonder if it is really clean yet, i.e. do they need all the current code. A quick scan gives the low level as Stringing (same as current OSX_. The encodings and conversions seem to use ICU to do the work (which is UTF-16 based) Also in NSString.swift is the line public typealias unichar = UInt16 >>> >>>> On Dec 8, 2015, at 15:52, EuanM <euanmee(a)gmail.com> wrote: >>>> >>>> Equally old are the NextStep Object C functions which are now embodied >>>> within MacOS X. >>>> -- Mark

Dec. 15, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by H. Hirzel

On 12/15/15, Ben Coman <btc(a)openinworld.com> wrote: > On Thu, Dec 10, 2015 at 12:37 AM, Todd Blanchard <tblanchard(a)mac.com> > wrote: >> They are practically the same thing. >> >> ICU was developed by Taligent which was a joint venture between Apple and >> IBM. Makes sense that NSString and ICU's UnicodeString are pretty close >> in implementation. ICU was also ported to Java for Sun by IBM. The point >> is - this is a very elaborate chunk of code with far reach. If ICU is >> wrong on some point - it is universally wrong and thus likely to be taken >> as "right" as it is at least consistent. I think re-implementing it is >> folly TBH. Just use it. > > Apple seem to have moved on from NSString to support Unicode in a > different way in Switft... Could you please give some more details? I have read https://www.objc.io/issues/9-strings/unicode/#nsstring-and-unicode so far. It says that an NSString object actually represents an array of UTF-16-encoded code units. This in contrast to Squeak / Pharo where a String is an ArrayedCollection of 21 bit Unicode code points (transparently optimizing to a ByteArray if the string only contains values of the first code page). >> >>> On Dec 8, 2015, at 15:52, EuanM <euanmee(a)gmail.com> wrote: >>> >>> Equally old are the NextStep Object C functions which are now embodied >>> within MacOS X. >>> >> >> > >

Dec. 15, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by Todd Blanchard

I wouldn't say that necessarily. There's a whole lot of API that is dependent on objective c - I suspect they have a toll free bridging in there where swift/objective c strings share enough common protocol to be fully substitutable like with CFString. Anyhow swifts step away from smalltalk ideals and the added complexity of language bridging has me avoiding it. Sent from the road > On Dec 15, 2015, at 00:49, Ben Coman <btc(a)openinworld.com> wrote: > > Apple seem to have moved on from NSString to support Unicode in a > different way in Switft...

Dec. 15, 2015

Re: [Pharo-dev] AsmJit

by Eliot Miranda

Hi Jan, > On Dec 15, 2015, at 3:06 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > Hi guys, > > two queations: > > (i) Is AsmJit going to be developed any more or it's abandoned > as well as native boost? AsmJIT is effectively being abandoned but NativeBoost is not. The key limitation of AsmJIT is that it was not designed to be cross platform; it is effectively an x86 assembler. As such it's use gets in the way of ARM and x86_64 (I am currently getting the C version of 64-bit Cog Spur working on x86_64, given that it is working in the simulator). Another limitation is that it doesn't play that well with the VM's JIT. Igor and I never managed to work on integrating it better. The VM's job is managing code and Igor's approach was to hack; eliminating execution protection in the entire heap, instead of extending the support that either the Alien plugin's callback support or the JIT's executable method zone provides. Making the entire heap executable is /not/ a sensible approach. But there is a better way! A key component of the Sista adaptive optimizer/speculative inlined that ClÃ©ment is currently stabilizing (!!) is a set of bytecodes that encode unsafe operations like at:put: without bounds, type or store checks. For example, the normal at:put: is about a hundred instructions, checks for smallinteger indices, differentiates between byte, 32-but long and pointer objects and does a store check. But one of the Sista codes for at:put: generates about two instructions, one to adjust the index, the other to do the store. Distaste job is to analyze code and inline methods using these unsafe bytecodes where they are proven to be safe, hence increasing performance. Unlike AsmJIT, Sista's unsafe bytecodes are cross platform, and, being executed by the VM, can work on an interpreter VM or be converted to machine code by the JIT. So our plan is to extend these bytecodes with ones that support marshaling arguments for NativeBoost calls. Ronie Salgado has already extended his lowcode scheme to define these instructions and sometime soon (hopefully 2016) we shall rewrite NativeBoost to target these bytecodes. HTH > (ii)Where can I find latest AsmJit? I'm properly confused: > > * Is is the one in latest Pharo 4.0 (5.0) image? > * Is it the one here: http://smalltalkhub.com/#!/~Pharo/AsmJit ? > (the one in the image seem to be based on completely disjunct > set of .mcz than those in the repo above). > > Best, Jan _,,,^..^,,,_ (phone)

Dec. 15, 2015