- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

> On 11 Nov 2017, at 08:53, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Esteban > there is not hook to be able to avoid such bugs. I do not understand :) the problem is that this issue do not happen in P7â¦ I wonder why? but well, we need to add a step to P6 64bits building. Esteban > > Stef > > On Sat, Nov 11, 2017 at 12:46 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> got it. >> I was able to reproduce it. >> >> turns out there is a problem in the 32-64 bits conversion and libgit2 >> bindings. >> >> you need to execute this: >> >> LGitExternalStructure allSubclassesDo: #compileFields. >> >> before execute this: >> >> Metacello new >> repository: 'github://estebanlm/libclang-pharo-bindings/src'; >> baseline: 'LibClang'; >> load. >> >> Esteban >> >> >> On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> Any help? >> >> On Nov 10, 2017, at 8:49 AM, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> Yes, trying to install your libclang. >> >> Pharo is brand new download of whatever is on the website - 6.1-64 bit >> version (yes I know its not tested - I was going to test it). >> OSX Sierra. >> I have Xcode and all that goes with it installed (my day job is IoT projects >> with accompanying iPhone apps and occasionally web services development). >> >> Homebrew packages installed include... >> >> appledoc gmp nettle >> autoconf gnutls nmap >> aws-elasticbeanstalk gobject-introspection node >> awscli graphite2 openssl >> basset_ios harfbuzz openssl@1.1 >> bazel icu4c p11-kit >> boot2docker imagemagick pango >> c-ares jpeg pcre >> cairo libcroco pixman >> cmake libffi pkg-config >> coreutils libgcrypt python >> cvs libgpg-error python3 >> dfu-util libpng rbenv >> docker librsvg readline >> fontconfig libssh2 redis >> freetype libtasn1 ruby-build >> gdbm libtiff sqlite >> gdk-pixbuf libtool unar >> geoip libunistring wget >> gettext libusb wireshark >> ghostscript little-cms2 xz >> glib lua >> >> >> >> On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> I would need a way to reproduce this. >> >> pharo version? (6.1?) >> vm version? >> operating system? >> project you try to install? (I guess is libclang) >> >> anything I should know about your environment? (image is clean/new? are you >> behind a proxy? whatever that can help) >> >> Esteban >> >> On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> #(0 25 1) >> >> On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> (LGitLibrary uniqueInstance version) >> >> >> >> >> >> >

Nov. 11, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Stephane Ducasse

Tx esteban I agree :) On Fri, Nov 10, 2017 at 7:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > none of them, Iâm sorry :) > I think we can do a lot better with just a bit of effort. > > Esteban > >> On 10 Nov 2017, at 15:26, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> I would prefer the last one. >> Regularity over exception. >> Now the parser should just be good :) >> >> Stef >> >> On Fri, Nov 10, 2017 at 7:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 10 Nov 2017, at 19:12, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi sven >>>> >>>> Do you have an example because I do not understand your doubling. >>> >>> Sure, >>> >>> Bla { bla:bla } [ >>> self isFoo ifTrue: [ #foo >>> ] >>> ifFalse: [ [ "block" #bar >>> ]] >>> ] >>> >>> would have to become >>> >>> Bla { bla:bla } [ >>> self isFoo ifTrue: [ #foo >>> ]] >>> ifFalse: [ [ "block" #bar >>> ]]] >>> ] >>> >>> but this very rare (because usually code is intended). >>> >>> Nicolas' latest idea is cool too (use as much ['s as needed to avoid conflict). So the example would then become >>> >>> Bla { bla:bla } [[[ >>> self isFoo ifTrue: [ #foo >>> ] >>> ifFalse: [ [ "block" #bar >>> ]] >>> ]]] >>> >>>> stef >>>> >>>> >>>> On Fri, Nov 10, 2017 at 11:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> Hi, >>>>> >>>>> Right now, TonelParser>>#methodBody looks a bit dangerous (too complex), and Nicolas already found some breaking cases as well a one possible solution. I was thinking a bit along the same lines, so here is a proposal. >>>>> >>>>> Overall I think we should keep the current readability of Tonel as much as possible (it is very important for diffs), while still being correct - i.e. no method source, even convoluted ones, possibly in different languages should break the encoding. >>>>> >>>>> The problem is how to quickly scan a stream for the closing $] (which occurs as a single character on a line by its own). Especially in Pharo source code, that situation (a conflict between the proper marker and actual source) is very rare, since code is usually intended. But is can occur and must be dealt with. >>>>> >>>>> The proposal is to just double the $] but only on lines that could conflict (which are lines consisting of only $]'s). The code itself becomes quite simple and remains fast enough. >>>>> >>>>> Here is some code to play with (EOL fixed to #cr for demo purposes): >>>>> >>>>> writer := [ :stream :methodSourceString | >>>>> stream nextPut: $[; cr. >>>>> methodSourceString linesDo: [ :line | >>>>> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >>>>> ifTrue: [ stream << $] ]. >>>>> stream << line; cr ]. >>>>> stream nextPut: $]; cr ]. >>>>> >>>>> reader := [ :stream | | line | >>>>> (stream peekFor: $[) ifTrue: [ stream nextLine ] ifFalse: [ self error ]. >>>>> String streamContents: [ :out | >>>>> [ (line := stream nextLine) = ']' ] whileFalse: [ >>>>> (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) >>>>> ifTrue: [ out << line allButFirst ] >>>>> ifFalse: [ out << line ]. >>>>> out cr ] ] ]. >>>>> >>>>> encoded := String streamContents: [ :out | writer value: out value: (Collection>>#inject:into:) sourceCode ]. >>>>> >>>>> (reader value: encoded readStream) = ((Collection>>#inject:into:) sourceCode, String cr). >>>>> >>>>> escapedEncoded := String streamContents: [ :out | writer value: out value: 'test >>>>> "Make sure there is no whitespace at line start to force an escape" >>>>> self isFoo ifTrue: [ #foo >>>>> ] >>>>> ifFalse: [ [ "block" #bar >>>>> ]] >>>>> ' ]. >>>>> >>>>> (reader value: escapedEncoded readStream). >>>>> >>>>> What do you think ? >>>>> Did I miss any special cases ? >>>>> Is the price (very occasional insertion of an extra #] in the source code) worth the advantage (a simple, safe scheme). >>>>> >>>>> Sven >>>>> >>>>> PS: Note that several tools line syntax highlighting and double-click next to brackets have problems with weird delimiters such as in the above code ;-) >>>>> >>>>> >>>> >>> >>> >> > >

Nov. 11, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Stephane Ducasse

Esteban there is not hook to be able to avoid such bugs. Stef On Sat, Nov 11, 2017 at 12:46 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > got it. > I was able to reproduce it. > > turns out there is a problem in the 32-64 bits conversion and libgit2 > bindings. > > you need to execute this: > > LGitExternalStructure allSubclassesDo: #compileFields. > > before execute this: > > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src'; > baseline: 'LibClang'; > load. > > Esteban > > > On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Any help? > > On Nov 10, 2017, at 8:49 AM, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Yes, trying to install your libclang. > > Pharo is brand new download of whatever is on the website - 6.1-64 bit > version (yes I know its not tested - I was going to test it). > OSX Sierra. > I have Xcode and all that goes with it installed (my day job is IoT projects > with accompanying iPhone apps and occasionally web services development). > > Homebrew packages installed include... > > appledoc gmp nettle > autoconf gnutls nmap > aws-elasticbeanstalk gobject-introspection node > awscli graphite2 openssl > basset_ios harfbuzz openssl@1.1 > bazel icu4c p11-kit > boot2docker imagemagick pango > c-ares jpeg pcre > cairo libcroco pixman > cmake libffi pkg-config > coreutils libgcrypt python > cvs libgpg-error python3 > dfu-util libpng rbenv > docker librsvg readline > fontconfig libssh2 redis > freetype libtasn1 ruby-build > gdbm libtiff sqlite > gdk-pixbuf libtool unar > geoip libunistring wget > gettext libusb wireshark > ghostscript little-cms2 xz > glib lua > > > > On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > I would need a way to reproduce this. > > pharo version? (6.1?) > vm version? > operating system? > project you try to install? (I guess is libclang) > > anything I should know about your environment? (image is clean/new? are you > behind a proxy? whatever that can help) > > Esteban > > On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com> wrote: > > #(0 25 1) > > On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > (LGitLibrary uniqueInstance version) > > > > > >

Nov. 11, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

got it. I was able to reproduce it. turns out there is a problem in the 32-64 bits conversion and libgit2 bindings. you need to execute this: LGitExternalStructure allSubclassesDo: #compileFields. before execute this: Metacello new repository: 'github://estebanlm/libclang-pharo-bindings/src'; baseline: 'LibClang'; load. Esteban > On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Any help? > >> On Nov 10, 2017, at 8:49 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >> >> Yes, trying to install your libclang. >> >> Pharo is brand new download of whatever is on the website - 6.1-64 bit version (yes I know its not tested - I was going to test it). >> OSX Sierra. >> I have Xcode and all that goes with it installed (my day job is IoT projects with accompanying iPhone apps and occasionally web services development). >> >> Homebrew packages installed include... >> >> appledoc gmp nettle >> autoconf gnutls nmap >> aws-elasticbeanstalk gobject-introspection node >> awscli graphite2 openssl >> basset_ios harfbuzz openssl@1.1 >> bazel icu4c p11-kit >> boot2docker imagemagick pango >> c-ares jpeg pcre >> cairo libcroco pixman >> cmake libffi pkg-config >> coreutils libgcrypt python >> cvs libgpg-error python3 >> dfu-util libpng rbenv >> docker librsvg readline >> fontconfig libssh2 redis >> freetype libtasn1 ruby-build >> gdbm libtiff sqlite >> gdk-pixbuf libtool unar >> geoip libunistring wget >> gettext libusb wireshark >> ghostscript little-cms2 xz >> glib lua >> >> >> >>> On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> I would need a way to reproduce this. >>> >>> pharo version? (6.1?) >>> vm version? >>> operating system? >>> project you try to install? (I guess is libclang) >>> >>> anything I should know about your environment? (image is clean/new? are you behind a proxy? whatever that can help) >>> >>> Esteban >>> >>>> On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>> >>>> #(0 25 1) >>>> >>>>> On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>> >>>>> (LGitLibrary uniqueInstance version) >>>> >>> >> >

Nov. 11, 2017

Re: [Pharo-dev] Tonel and class definition changes

by Esteban Lorenzano

> On 11 Nov 2017, at 07:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > I extracted my question from previous thread about encoding issue in Tonel. > > 2017-11-10 18:08 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > On 10 Nov 2017, at 13:05, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> 2017-11-10 16:30 GMT+01:00 Martin McClure <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>>: >> Tonel is intended to be, I believe: >> * For Smalltalk primarily (although there are other languages) >> * Be for any Smalltalk dialect (although the first implementation is for Pharo, it is being ported to GemStone, and we intend to port it to VW and VA) >> >> Interesting how it will be handled when Pharo will use slots abstraction exclusively. And more simple, when there will be only package and tags instead of class categories. >> >> To be more clear. Imaging that instead of #instanceVariables field Pharo will use #slots. And instead of #category it will be #package and #tags > > what does it has to do with this thread? > > My question was related to the sentence that Tonel is intended to be for any Smalltalk dialect. If Pharo will use #slots, #package and #tags names in class definition format it will be not compatible to other smalltalks. we will use #slots and other implementations will use #instVars platforms will need to translate themâ¦ for example, we will be able to interpret instVars as simple slots and categories as packages, they can do the same (it can be more complicated for slots, but at the end, is also doable) tonel is a portable cross dialect format, but that does not means that what is saved for pharo is immediately loadable in other platforms and viceversa. When working for compatibility, framework designers takes the differences into account: they do not use traits and sometimes they need a compatibility layer (Seaside, Iâm watching you). With slots they will need to do the same, and most probably they will not use them, sadly. > > handling that is trivial: once we actually have slots (bah, we have them, but once we *use* them) and once we move to package+tags, we just adapt the descriptions. Thatâs the advantage of using STON to keep them. > > And what will happen then? We will again regenerate all sources/history? > When we will switch to new names every class will be modified in following commit. or incremental (while working). I still do not decide how to proceed since is a problem we still do not have. I have plenty of things I need to decide right now, I can wait a bit for this one :) Esteban >

Nov. 11, 2017

Re: [Pharo-dev] Thanks for he TDD improvement!

by Stephane Ducasse

Yes we should fix what get on our way. The next item is the bad widget for selecting a package taht we all hate. On Sat, Nov 11, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-11-11 11:47 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi >> >> this is super cool to get tests refreshed in nautilus when we define >> the method in the debugger. I was always bored when I do demo to have >> the rerun the tests. >> >> TX because this is super cool >> We should continue to improve the user experience in Pharo. > > > Yes, every little thing leads to big improvement. We should repeat it every > day :). I was annoyed by this issue all the time but not force myself to fix > it. > >> >> >> Stef >> >

Nov. 11, 2017

Re: [Pharo-dev] summary of "float & fraction equality bug"

by raffaello.giulietti＠lifeware.ch

On 2017-11-10 22:18, Nicolas Cellier wrote: > > > 2017-11-10 20:58 GMT+01:00 Martin McClure <martin(a)hand2mouse.com > <mailto:martin@hand2mouse.com>>: > > On 11/10/2017 11:33 AM, raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> wrote: > > Doing only Fraction->Float conversions in mixed mode won't > preserve = as > an equivalence relation and won't enable a consistent ordering > with <=, > which probably most Smalltalkers consider important and enjoyable > properties. > > Good point. I agree that Float -> Fraction is the more desirable > mode for implicit conversion, since it can always be done without > changing the value. > > Nicolas gave some convincing examples on why most > programmers might want to rely on them. > > > Also, as I mentioned, most Smalltalkers might prefer keeping > away from > the complex properties of Floats. Doing automatic, implicit > Fraction->Float conversions behind the scenes only exacerbates the > probability of encountering Floats and of having to deal with their > weird and unfamiliar arithmetic. > > One problem is that we make it easy to create Floats in source code > (0.1), and we print Floats in a nice decimal format but by default > print Fractions in their reduced fractional form. If we didn't do > this, Smalltalkers might not be working with Floats in the first > place, and if they did not have any Floats in their computation they > would never run into an implicit conversion to *or* from Float. > > As it is, if we were to uniformly do Float -> Fraction conversion on > mixed-mode operations, we would get things like > > (0.1 * (1/1)) printStringÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â --> > '3602879701896397/36028797018963968' > > Not incredibly friendly. > > > For those not practicing the litote: definitely a no go. > > > Regards, > -Martin > > > At the risk of repeating myself, unique choice for all operations is a > nice to have but not a goal per se. > > I mostly agree with Florin: having 0.1 representing a decimal rather > than a Float might be a better path meeting more expectations. > > But thinking that it will magically eradicate the problems is a myth. > > Shall precision be limited or shall we use ScaledDecimals ? > > With limited precision, we'll be back to having several Fraction > converting to same LimitedDecimal, so it won't solve anything wrt > original problem. > With illimted precision we'll have the bad property that what we print > does not re-interpret to the same ScaledDecimal (0.1s / 0.3s), but > that's a detail. > The worse thing is that long chain of operations will tend to produce > monster numerators denominators. > And we will all have long chain when resizing a morph with proportional > layout in scalable graphics. > We will then have to insert rounding operations manually for mitigating > the problem, and somehow reinvent a more inconvenient Float... > It's boring to allways play the role of Cassandra, but why do you think > that Scheme and Lisp did not choose that path? > I don't know why Lisper got this way. They justify the conversion choice for comparison (equivalence of = and total ordering of <=) but for the arithmetic operations there does not seem to be a clearly stated rationale. Are they happy with their choice? I haven't the foggiest idea. Don't get me wrong: I understand the Fraction->Float choice for the sake of more speed. But this increase in speed is not functionally transparent: it is not like an increase in the clock rate of a CPU, it's not like a better performing division algorithm, a faster implementation of sorting or a JIT compiler. This increase in speed, rather, comes at the cost of a shift in functionality and cognitive load, because even + or 0.1 have not their conventional semantics. It's not that Floats are wrong by themselves, it's that their operations seem weird at first and at odd with the familiar behavior. Again, I'm not addressing the experts in floating point computation here: they know how to deal with it. Thus, I expect that the developers of numerically intensive libraries or packages, like 2D or 3D graphics, are fully aware of the trade-offs and are in a position to make an explicit choice: either monster denominators in fractions or more care with floats, but always in control. Here, I'm targeting the John Doe Smalltalker which usually uses well-crafted, well-performing libraries and probably only performs a few thousand mixed Fraction/Float computations on his own, and then speed trade-offs do not matter. He is better served with implicit, automatic Float->Fraction conversions in both comparisons and operations. For him, less cognitive load and less surprises are probably an added value.

Nov. 11, 2017

Re: [Pharo-dev] Thanks for he TDD improvement!

by Denis Kudriashov

2017-11-11 11:47 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi > > this is super cool to get tests refreshed in nautilus when we define > the method in the debugger. I was always bored when I do demo to have > the rerun the tests. > > TX because this is super cool > We should continue to improve the user experience in Pharo. > Yes, every little thing leads to big improvement. We should repeat it every day :). I was annoyed by this issue all the time but not force myself to fix it. > > Stef > >

Nov. 11, 2017

Re: [Pharo-dev] feenk log

by Stephane Ducasse

Nice explanation. Aliaksei do you add it to the BLSpace class comment? Stef On Fri, Nov 10, 2017 at 10:36 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Sean, > >> Why not `anElement simulateClick`? > > > Good question :) > We indeed evaluated a possibility to have (BlElement >> #simulateClick) but > then decided to make BlSpace class to be responsible for that. > > First we should realise that when we simulate a click we do literally > simulate user's action which is: mouseDown at some global coordinate in > space and then mouseUp. A process of handing mouse down/up events involves > some complex event processing in order to detect what should happen, for > example, with currently focused element or if we need to send double-click > event. It is a mouse processor who is responsible for all these actions and > it belongs to Space (inst. var in space). Not to mention some weird cases of > overlapped elements, elements with custom elevation (zIndex), custom > mouseDown/up event listeners that do some work too... > That is why it is definitely not enough just to send a plain BlClickEvent > directly to the element. Instead, we should involve a space in the process > and actually simulate it by pushing mouseDown and mouseUp events to the > event queue. > > Next what we realised it the fact that it is not nice to always create a > temporary space and add our element to it in order to simulate a click. What > if an element is already added to the space, what if not? > To wrap up, we decided that it should be a responsibility of the Space class > to create a new temporary instance of itself, add an element to it, simulate > click event and then delete itself. In order to show the intent and a > process behind we decided that it would be a good idea to actually write a > code like this: > > BlSpace simulateClickOn: element. > > In english it is quite nice: > > "dear space class, could you, please, simulate a click event on a given > element?" It is a space who simulates event, not an element. > > P.S. Users can still send a BlClickEvent directly (informs 'click'): > > element := BlElement new. > element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. > element fireEvent: BlClickEvent new > > Cheers, > Alex > > On 10 November 2017 at 21:22, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: >> >> Tudor Girba-2 wrote >> > - support for programatic testing of bloc mouse events: >> > https://twitter.com/feenkcom/status/925672206763511808 >> >> Why not `anElement simulateClick`? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >

Nov. 11, 2017

Re: [Pharo-dev] feenk log

by Stephane Ducasse

Thanks Doru this is cool to see this happening. Stef On Fri, Nov 10, 2017 at 7:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Over the past couple of weeks Alex worked on stabilizing a first beta01 version for Pharo 6.1: > https://twitter.com/feenkcom/status/929031849879461889 > > This is available as a beta01 tag in the pharo61 branch here: > https://github.com/pharo-graphics/Bloc/tree/beta01 > > The main readme was updated with instructions and links: > https://github.com/pharo-graphics/Bloc > > An overview of the improvements: > - improved animations support that also works for scaling > https://twitter.com/feenkcom/status/927617393194610693 > - improved debugging support for transformations > https://twitter.com/feenkcom/status/926040946130612224 > - support for programatic testing of bloc mouse events: > https://twitter.com/feenkcom/status/925672206763511808 > - updated MemoryGame tutorial: > http://files.pharo.org/books-pdfs/booklet-Bloc/2017-11-09-memorygame.pdf > https://github.com/pharo-graphics/Tutorials > - extended examples that offer a 52% coverage > - new Bloc world menu for easily accessing Bloc examples and reseting the Universe > > Cheers, > The feenk team > > -- > www.tudorgirba.com > www.feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > >

Nov. 11, 2017