- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Script to download Pharo 4 vm for Mac os sierra

by stepharong

Nice to see on this list after all these years :) This is important for synectiquers to use the power of the open-source :) > Hello, > > We have a jenkins job, running on a linux machine, that is responsible > for building and outputing a Pharo 4 development image + vm ready to be > used on mac machines. > > We use this command line to download the VM and archived it as output > of the job: > > curl -O http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-latest.zip > > On my mac (10.12.1), when i open the pharo image with this vm , I am > facing what seem to be some known issues for Mac OS sierra: > > Pharo[13048:431565] *** -[NSPathStore2 stringByAppendingPathExtension:]: > cannot append extension 'bundle/Contents/MacOS/' to path ... > Now, when I try to download a Pharo 4 vm directly from my mac sierra > machine, > with a zeroconf script (get.pharo.org/vm40) > It works: I am able to open the pharo image with this vm. > > Is there a script that allows to download a pharo 4 vm working for mac > os sierra, from a linux machine ? > > --Cyrille Delaunay -- Using Opera's mail client: http://www.opera.com/mail/

March 17, 2017

xsd to pharo?

by stepharong

Hi we are looking for a xsd to pharo class generator? Stef -- Using Opera's mail client: http://www.opera.com/mail/

March 17, 2017

Re: [Pharo-dev] Fogbugz feedback - "Image Version"

by Ben Coman

On Fri, Mar 17, 2017 at 7:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I understand why it is useful to you, but it is a PIA for all the rest of > us. > > Consider: > > $ java -version > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > $ python --version > Python 2.7.10 > > $ ruby --version > ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16] > > At the image level Pharo has: > > $ pharo Pharo.image printVersion > [version] 4.0 #40620 > > Clean, simple, precise. > > And then when the rest of the world wants to communicate about the VM > version they are using, you get: > > $ ../bin/pharo --version > 3.9-7 #1 Thu Apr 2 00:51:45 CEST 2015 gcc 4.6.3 [Production ITHB VM] > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 > UTC 2012 i686 i686 i386 GNU/Linux > plugin path: /home/audio359/pharo/bin/pharo-vm/ [default: > /home/audio359/pharo/bin/pharo-vm/] > > This is way too technical. > This just needs to be --versionVerbose or --versionAll. cheers -ben > On the other hand, I understand that this is also a vetting problem: who > builds the VM, validates it, assigns it version/build numbers. > > BTW, is there no open source convention of using xx-config to return all > this detailed (build) info ? > > > On 17 Mar 2017, at 11:36, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Ben, > > > >> On Mar 16, 2017, at 8:32 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> A niggle I've had for a while is that the "Image Version" field seems > to me to be useless. > >> > >> It defaults to a particular major version. > >> (that even though only a small thing, is one more thing to maintain) > >> > >> It tends to be superseded by the Milestone field. > >> > >> The limited selection of major version is too broad to add any > >> useful info beyond Milestone to narrow down action. > >> > >> So I wonder Image Version if it might be replaced by a freeform field > >> "Image Version" to enter the value from System > About. > >> > >> ----- > >> As an extension, given the flux of the VMs with the move to 64 bit, > >> and ongoing support for both, it might also be good to have a "VM > Version" field. > >> > >> Now actually I often find it awkward to report VM version. > >> The text under System > System Reporter > VM General > >> is quite bulky and its not clear what is the really useful parts for > identification. > >> So I usually end up pasting the whole thing, but this is too much for > >> an issue tracker field. Also, there is no indication here of itimer > versus threaded heartbeats which is sometimes pertinent. > >> Could suitable minimal VM version info be added to System > About > >> so the info required for the issue tracker is all in one simple place? > > > > Perhaps we should start by enumerating use cares. I originally wrote > that bulky version info so that vm maintainers could identify the exact > version of a VM. The use case here is to locate or obtain the build date, > c compiler and exact C and VMMaker source for the vm in order to locate the > exact vm, attach a debugger, recompile a matching debug vm, etc. At the > time the version info was > > > > a) the commit to the subversion Cog repository of the vm sources > > > > b) the commit to the subversion squeakvm repository of the vm support > files shared between Cog and squeakvm > > > > c) the VMMaker version of the StackInterpreter or CoInterpreter in the > vm (including the "*" dirty mark if so) > > > > d) the VMMaker version of the Cogit in the vm (including the "*" dirty > mark if so) > > > > With opensmalltalk-vm we can collapse a) and b), or rather, b) is no > longer separate and hence obsolete, but the triad a), c) & d) are still > most relevant to me. Condensing these to a summary means having to index > (e.g. lookup the VMMaker info in opensmalltalk-vm by checking out a > particular commit) and that's time consuming. > > > > So for me, while the info is poorly formatted and hard to read it is > informative and saves me time. I'm happy to see it paired down by dropping > b), and doing whatever we can to make it more readable but I'd still like > to see people cite it in full when reporting a potential vm problem or > reporting their vm version. > > > > What other use cases are there for this version info? (and that's not a > rhetorical question). > > > >> > >> ----- > >> Finally, do we want these version fields to: > >> * remain static for the version initially reported on, or > >> * be refreshed as confirmed in a later version, or > >> * have separate fields "Confirmed in {Image/VM} Version" to track tests. > >> > >> cheers -ben > >> > >> cheers -ben > > >

March 17, 2017

Re: [Pharo-dev] 60445, empty version info stamps

by Pavel Krivanek

Not sure with the date but we will store a hash of the commit from which the image will be bootstrapped. -- Pavel 2017-03-17 12:43 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > btw, will same user/date for multiple revisions remain available in > a Versions window? > > cheers -ben > > > On Fri, Mar 17, 2017 at 7:02 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> Pharo 7 will be bootstrapped from the metadata-less filetree where >> timestamps are ignored completely. So the question is if we should put >> energy into this... >> >> -- Pavel >> >> 2017-03-17 11:57 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> >>> On Fri, Mar 17, 2017 at 5:30 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> >>>> >>>> On Fri, Mar 17, 2017 at 5:22 PM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>>> In 60445, browse the implementors of #cacheAt:for:ifAbsentPut: >>>>> and the view the Versions of each. >>>>> Curiously some of them have a blank user/date. >>>>> >>>>> There are others... >>>>> errors := OrderedCollection new. >>>>> versions := (CompiledMethod allInstances) flatCollect: [:cm| >>>>> [VersionBrowser new setRGMethodFrom: cm asRingDefinition; >>>>> buildChangeList] >>>>> on: Error do:[:ex| errors add: (cm -> ex). #()] ]. >>>>> versions size. >>>>> "112131" >>>>> emptyStamps := versions select: [:rgm| rgm stamp = '']. >>>>> emptyStamps size. >>>>> "9264" >>>>> or 8% >>>>> >>>>> Maybe some are historic, but I'd guess this one at least is not so >>>>> old... >>>>> GLMFastListDataSource>>cacheAt:for:ifAbsentPut: >>>>> >>>>> What reasonable action do we need to take? >>>>> >>>>> cheers -ben >>>>> >>>> >>>> P.S. >>>> the errors were all "UTF8InvalidText: Invalid utf8 input detected" for >>>> these methods... >>>> QuotedPrintableMimeConverter >> #decode: >>>> StringTest >> #UTF8InvalidText: >>>> EpEnabledIntegrationTest >> #setUp >>>> SingleCodeCriticResultList >> #diffTextForChange: >>>> >>>> >>>> >>> Further analysis... >>> 60000 versions=93482 emptyStamps=8964 >>> 60050 versions=95654 (+2172) emptyStamps=9214 (+250) >>> 60100 versions=96112 (+458) emptyStamps=9212 (-2) >>> 60150 versions=97335 (+1223) emptyStamps=9211 (-1) >>> 60200 versions=98030 (+695) emptyStamps=9169 (-42) >>> 60250 versions=99779 (+1749) emptyStamps=9282 (113) >>> 60300 versions=109440 (+9661) emptyStamps=9153 (-129) >>> 60350 versions=109586 (+146) emptyStamps=9173 (+20) >>> 60400 versions=110278 (+692) emptyStamps=9185 (+12) >>> 60455 versions=112131 (+1853) emptyStamps=9264 (+79) >>> >>> cheers -ben >>> >> >> >

March 17, 2017

Re: [Pharo-dev] Fogbugz feedback - "Image Version"

by Sven Van Caekenberghe

I understand why it is useful to you, but it is a PIA for all the rest of us. Consider: $ java -version java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) $ python --version Python 2.7.10 $ ruby --version ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16] At the image level Pharo has: $ pharo Pharo.image printVersion [version] 4.0 #40620 Clean, simple, precise. And then when the rest of the world wants to communicate about the VM version they are using, you get: $ ../bin/pharo --version 3.9-7 #1 Thu Apr 2 00:51:45 CEST 2015 gcc 4.6.3 [Production ITHB VM] NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux plugin path: /home/audio359/pharo/bin/pharo-vm/ [default: /home/audio359/pharo/bin/pharo-vm/] This is way too technical. On the other hand, I understand that this is also a vetting problem: who builds the VM, validates it, assigns it version/build numbers. BTW, is there no open source convention of using xx-config to return all this detailed (build) info ? > On 17 Mar 2017, at 11:36, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Ben, > >> On Mar 16, 2017, at 8:32 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> A niggle I've had for a while is that the "Image Version" field seems to me to be useless. >> >> It defaults to a particular major version. >> (that even though only a small thing, is one more thing to maintain) >> >> It tends to be superseded by the Milestone field. >> >> The limited selection of major version is too broad to add any >> useful info beyond Milestone to narrow down action. >> >> So I wonder Image Version if it might be replaced by a freeform field >> "Image Version" to enter the value from System > About. >> >> ----- >> As an extension, given the flux of the VMs with the move to 64 bit, >> and ongoing support for both, it might also be good to have a "VM Version" field. >> >> Now actually I often find it awkward to report VM version. >> The text under System > System Reporter > VM General >> is quite bulky and its not clear what is the really useful parts for identification. >> So I usually end up pasting the whole thing, but this is too much for >> an issue tracker field. Also, there is no indication here of itimer versus threaded heartbeats which is sometimes pertinent. >> Could suitable minimal VM version info be added to System > About >> so the info required for the issue tracker is all in one simple place? > > Perhaps we should start by enumerating use cares. I originally wrote that bulky version info so that vm maintainers could identify the exact version of a VM. The use case here is to locate or obtain the build date, c compiler and exact C and VMMaker source for the vm in order to locate the exact vm, attach a debugger, recompile a matching debug vm, etc. At the time the version info was > > a) the commit to the subversion Cog repository of the vm sources > > b) the commit to the subversion squeakvm repository of the vm support files shared between Cog and squeakvm > > c) the VMMaker version of the StackInterpreter or CoInterpreter in the vm (including the "*" dirty mark if so) > > d) the VMMaker version of the Cogit in the vm (including the "*" dirty mark if so) > > With opensmalltalk-vm we can collapse a) and b), or rather, b) is no longer separate and hence obsolete, but the triad a), c) & d) are still most relevant to me. Condensing these to a summary means having to index (e.g. lookup the VMMaker info in opensmalltalk-vm by checking out a particular commit) and that's time consuming. > > So for me, while the info is poorly formatted and hard to read it is informative and saves me time. I'm happy to see it paired down by dropping b), and doing whatever we can to make it more readable but I'd still like to see people cite it in full when reporting a potential vm problem or reporting their vm version. > > What other use cases are there for this version info? (and that's not a rhetorical question). > >> >> ----- >> Finally, do we want these version fields to: >> * remain static for the version initially reported on, or >> * be refreshed as confirmed in a later version, or >> * have separate fields "Confirmed in {Image/VM} Version" to track tests. >> >> cheers -ben >> >> cheers -ben

March 17, 2017

Re: [Pharo-dev] 60445, empty version info stamps

by Ben Coman

btw, will same user/date for multiple revisions remain available in a Versions window? cheers -ben On Fri, Mar 17, 2017 at 7:02 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Pharo 7 will be bootstrapped from the metadata-less filetree where > timestamps are ignored completely. So the question is if we should put > energy into this... > > -- Pavel > > 2017-03-17 11:57 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >> >> On Fri, Mar 17, 2017 at 5:30 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On Fri, Mar 17, 2017 at 5:22 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> In 60445, browse the implementors of #cacheAt:for:ifAbsentPut: >>>> and the view the Versions of each. >>>> Curiously some of them have a blank user/date. >>>> >>>> There are others... >>>> errors := OrderedCollection new. >>>> versions := (CompiledMethod allInstances) flatCollect: [:cm| >>>> [VersionBrowser new setRGMethodFrom: cm asRingDefinition; >>>> buildChangeList] >>>> on: Error do:[:ex| errors add: (cm -> ex). #()] ]. >>>> versions size. >>>> "112131" >>>> emptyStamps := versions select: [:rgm| rgm stamp = '']. >>>> emptyStamps size. >>>> "9264" >>>> or 8% >>>> >>>> Maybe some are historic, but I'd guess this one at least is not so >>>> old... >>>> GLMFastListDataSource>>cacheAt:for:ifAbsentPut: >>>> >>>> What reasonable action do we need to take? >>>> >>>> cheers -ben >>>> >>> >>> P.S. >>> the errors were all "UTF8InvalidText: Invalid utf8 input detected" for >>> these methods... >>> QuotedPrintableMimeConverter >> #decode: >>> StringTest >> #UTF8InvalidText: >>> EpEnabledIntegrationTest >> #setUp >>> SingleCodeCriticResultList >> #diffTextForChange: >>> >>> >>> >> Further analysis... >> 60000 versions=93482 emptyStamps=8964 >> 60050 versions=95654 (+2172) emptyStamps=9214 (+250) >> 60100 versions=96112 (+458) emptyStamps=9212 (-2) >> 60150 versions=97335 (+1223) emptyStamps=9211 (-1) >> 60200 versions=98030 (+695) emptyStamps=9169 (-42) >> 60250 versions=99779 (+1749) emptyStamps=9282 (113) >> 60300 versions=109440 (+9661) emptyStamps=9153 (-129) >> 60350 versions=109586 (+146) emptyStamps=9173 (+20) >> 60400 versions=110278 (+692) emptyStamps=9185 (+12) >> 60455 versions=112131 (+1853) emptyStamps=9264 (+79) >> >> cheers -ben >> > >

March 17, 2017

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

by Ben Coman

On Fri, Mar 17, 2017 at 5:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > That list is multi-selection. On Mac, you can press Cmd while clicking and > you get the collection to the right. > > > I now see that Shift-click multi-selects and works just like I imagined it would. However Ctrl-click doesn't do anything, which was the only thing I tested before. I presume that is a bug? Can anyone confirm this on Linux? I'm... 32-bit Debian 8 Jessie. Pharo 60447 & Unix VM built on Mar 3 2017 21:07:26 Compiler: 4.6.3 VMMaker versionString VM: 201703031554 https://github.com/pharo-project/pharo-vm.git $ Date: Fri Mar 3 16:54:16 2017 +0100 $ Plugins: 201703031554 https://github.com/pharo-project/pharo-vm.git $ CoInterpreter * VMMaker.oscog-eem.2143 uuid: fe064b6b-e530-4766-837d-799ffe1e8dcd Mar 3 2017 StackToRegisterMappingCogit * VMMaker.oscog-eem.2143 uuid: fe064b6b-e530-4766-837d-799ffe1e8dcd Mar 3 2017 cheers -ben > Cheers, > Doru > > > On Mar 17, 2017, at 8:14 AM, Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > Sometimes when exploring a large data set in inspector, > I'd like to cherry pick a few items to act on as a collection. > > This would need to be valdiated/tested, but It could be useful to be > able to multi-select items and have the next pane to the right be the > collection containing the list of picked items. > > For the moment I can get by with... "self first: 5". > > cheers -ben > . > > > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > >

March 17, 2017

Re: [Pharo-dev] changing pharo packaging in linux

by Ben Coman

On Fri, Mar 17, 2017 at 3:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 17 Mar 2017, at 04:46, Ben Coman <btc(a)openinworld.com> wrote: > > On Thu, Mar 16, 2017 at 6:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > Hi, > > Last weeks I was fighting with library dependency problems on linux > distributions and at the end I came to the conclusion that the only way to > guarantee that our own dependencies will be found first than OS versions > (which can have problems for us when we choose to distribute a library by > our own) is to add library directory to LD_LIBRARY_PATH before the > execution. > > Now, I added that to zeroconf and thatâs working fine, but now we have > the problem of the ânon zeroconfâ distributions. > > I checked how to add this and well, turns out that âold wayâ of > distributions, from the standard builds of os-vm (we changed it like 5 > years ago) already have something like that. The osvm for linux has this > structure: > > ./pharo > ./lib > ./lib/5.0-201703221605 > ./lib/5.0-201703221605/* //All binaries and libraries here > ./bin > ./bin/pharo > > thing is: here ./pharo is an script who mades all we need. > > So, instead reinventing the wheel I want to go back to this structureâ¦ I > do not think it will imply anything to anyone, but I wanted to let you know > :) > > cheers, > Esteban > > > > Can you consider this for our startup script... > Generalise determination of LD_LIBRARY_PATH in squeak run script > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/15 > > > this is already merged, isnât? > in osvm, yes. > then is already in âmy scriptâ (what I was proposing is to use the osvm > script) :) > cool, just checking. Not too long ago it was missing from the Squeak download. cheers -ben btw, I just checked Squeak again and actually its script is now completely different, not setting LD_LIBRARY_PATH at all. > > > Last time I downloaded Squeak this hadn't filtered through to their > packaging > and their startup script bombed on my 32-bit Debian 8 Jessie. > > cheers -ben > > > P.S if time permits, could you also action out this.. > Download PharoXXX.sources if its not found in the usual location. > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/79 > > >

March 17, 2017

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

by Tudor Girba

Yes, the order is given by the order in which I click on the items. Doru > On Mar 17, 2017, at 9:26 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-03-17 10:18 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > Is there a reason why the order is reversed? > > I think it related to FastTable. Selected indexes are in order from last selected to first selected. New selected row is always added as first. -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

March 17, 2017

Re: [Pharo-dev] 60445, empty version info stamps

by Pavel Krivanek

Pharo 7 will be bootstrapped from the metadata-less filetree where timestamps are ignored completely. So the question is if we should put energy into this... -- Pavel 2017-03-17 11:57 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > On Fri, Mar 17, 2017 at 5:30 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Fri, Mar 17, 2017 at 5:22 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> In 60445, browse the implementors of #cacheAt:for:ifAbsentPut: >>> and the view the Versions of each. >>> Curiously some of them have a blank user/date. >>> >>> There are others... >>> errors := OrderedCollection new. >>> versions := (CompiledMethod allInstances) flatCollect: [:cm| >>> [VersionBrowser new setRGMethodFrom: cm asRingDefinition; >>> buildChangeList] >>> on: Error do:[:ex| errors add: (cm -> ex). #()] ]. >>> versions size. >>> "112131" >>> emptyStamps := versions select: [:rgm| rgm stamp = '']. >>> emptyStamps size. >>> "9264" >>> or 8% >>> >>> Maybe some are historic, but I'd guess this one at least is not so >>> old... >>> GLMFastListDataSource>>cacheAt:for:ifAbsentPut: >>> >>> What reasonable action do we need to take? >>> >>> cheers -ben >>> >> >> P.S. >> the errors were all "UTF8InvalidText: Invalid utf8 input detected" for >> these methods... >> QuotedPrintableMimeConverter >> #decode: >> StringTest >> #UTF8InvalidText: >> EpEnabledIntegrationTest >> #setUp >> SingleCodeCriticResultList >> #diffTextForChange: >> >> >> > Further analysis... > 60000 versions=93482 emptyStamps=8964 > 60050 versions=95654 (+2172) emptyStamps=9214 (+250) > 60100 versions=96112 (+458) emptyStamps=9212 (-2) > 60150 versions=97335 (+1223) emptyStamps=9211 (-1) > 60200 versions=98030 (+695) emptyStamps=9169 (-42) > 60250 versions=99779 (+1749) emptyStamps=9282 (113) > 60300 versions=109440 (+9661) emptyStamps=9153 (-129) > 60350 versions=109586 (+146) emptyStamps=9173 (+20) > 60400 versions=110278 (+692) emptyStamps=9185 (+12) > 60455 versions=112131 (+1853) emptyStamps=9264 (+79) > > cheers -ben >

March 17, 2017