June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Mariano Martinez Peck

Hi Stef. It looks we are minority. So today I will: - add #testExists (becuase it was broken but no test) - add #ensureDeleted - add #testEnsureDeleted - fix FileSystemHandleTest >> tearDown to #ensureDeleted the reference. cheers On Tue, Jun 12, 2012 at 7:25 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Yes to me ensureDelete or ensureDeleted is not explicit enough. I prefer > remove/delete[ifAbsent:] > On Jun 12, 2012, at 1:41 AM, Schwab,Wilhelm K wrote: > > > I generally default to saying "of course there should be an error." I > much prefer to get my bad news early rather than having to fish around or > it after the fact. Toward that end, I would recommend having > #deleteIfAbsent: and #delete that provides an error-raising block and > forwards to #deleteifAbsent:. That is consistent with collections, which > are not a bad model/source-of-inspiration for managing directory contents. > > > > Having #ensureDeleted in addition to above does no real harm. I would > prefer that the selector start with "delete" so it appears close to the > other methods in browsers, even w/o category filtering - makes it more > discoverable. > > > > Just my 2 asCents. > > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Chris > Cunningham [cunningham.cb(a)gmail.com] > > Sent: Monday, June 11, 2012 5:55 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FileReference should throw error when > deleting unexisting files? > > > > On Mon, Jun 11, 2012 at 2:32 PM, <petton.nicolas(a)gmail.com> wrote: > >> Maybe #ensureDeleted would be better? > >> > >> Nico > > I like #ensureDeleted (make sure it doesn't exist) > > > > > > > -- Mariano http://marianopeck.wordpress.com

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Mariano Martinez Peck

> ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') >> load. >> > > I use version 1.7, but because I don't want the other packages in the > image, what do you mean with that phrase? -- Mariano http://marianopeck.wordpress.com

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Mariano Martinez Peck

> Then Fuel was loaded using the specs on > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/… > . > I did the "Basic Demo": > - > > Gofer it > > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfFuel'; > load. > > ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') > load. > > And the "Basic Demo" from the above mentioned page was tried and failed. > Actually... wait, the debugger ... -- actually, I do not have time to > replicate it right now. But the above scripts, running Pier on a Mac > failed. I forget why. > Yes, it fails because of a small detail. Nothing important, believe me. Run tests and you should have all 248 tests in green. Cheers, -- Mariano http://marianopeck.wordpress.com

June 12, 2012

Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

by StÃ©phane Ducasse

On Jun 12, 2012, at 5:51 AM, Eliot Miranda wrote: > > > On Mon, Jun 11, 2012 at 7:15 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Do we all agree that standardizing on the Unix Epoch is the way to go? > > No :) Why? > > The > argument on the squeak list seemed to be: > - the squeak epoch has a certain beauty to it, being the turn of the century > vs > - why reinvent the wheel? Everybody already knows what the unix epoch is > (e.g. you can point them to Wikipedia) > > The full discussion is here: > http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581… > > The main thing is to make sure that whatever we use is based on UTC and not > local time. > > So - two options > - PharoOffset := 1 January, 1901 UTC > - Unix offset > > Also, whatever we change it to (and IMHO it really needs to be changed), I > think existing live objects from previous Pharos (e.g. that are materialized > with fuel) may be invalid (like the recent zip/mcz consequences) > > -- > View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > best, > Eliot >

June 12, 2012

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by StÃ©phane Ducasse

Yes to me ensureDelete or ensureDeleted is not explicit enough. I prefer remove/delete[ifAbsent:] On Jun 12, 2012, at 1:41 AM, Schwab,Wilhelm K wrote: > I generally default to saying "of course there should be an error." I much prefer to get my bad news early rather than having to fish around or it after the fact. Toward that end, I would recommend having #deleteIfAbsent: and #delete that provides an error-raising block and forwards to #deleteifAbsent:. That is consistent with collections, which are not a bad model/source-of-inspiration for managing directory contents. > > Having #ensureDeleted in addition to above does no real harm. I would prefer that the selector start with "delete" so it appears close to the other methods in browsers, even w/o category filtering - makes it more discoverable. > > Just my 2 asCents. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb(a)gmail.com] > Sent: Monday, June 11, 2012 5:55 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files? > > On Mon, Jun 11, 2012 at 2:32 PM, <petton.nicolas(a)gmail.com> wrote: >> Maybe #ensureDeleted would be better? >> >> Nico > I like #ensureDeleted (make sure it doesn't exist) > >

June 12, 2012

Re: [Pharo-project] recompiling class

by StÃ©phane Ducasse

>> Soon we will be able to remove FileDirectory :) > > Yippppppppppie!!!!! even more than that :)

June 12, 2012

Re: [Pharo-project] [PLP] News

by Santiago Bragagnolo

Here is a related release-post :) http://concretetypeinference.blogspot.com.ar/2012/06/metacello-paullepoulpe… 2012/6/12 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > > PaulLePoulpe Logger is now working and tested on Pharo 1.3 core; 1.4 > and 2.0, and working with two red tests at Pharo 1.2 core. The two red > tests are related with an announcement issue. But it dont interfere with > the work, so, it works. > > I'm using it actively in ConcreteTypeInference and KwisatzHaderach > projects swiching configurations depending on which project im working, and > work perfect. > > That's why i decided to make the first version. > > Gofer new > url: 'http://ss3.gemstone.com/ss/PaulLePoulpe'; > package: 'ConfigurationOfPaulLePoulpe'; > load. > > ( (Smalltalk at: #ConfigurationOfPaulLePoulpe) project version:'1.0' ) > load > > >

June 12, 2012

Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

by Eliot Miranda

On Mon, Jun 11, 2012 at 7:15 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Do we all agree that standardizing on the Unix Epoch is the way to go? No :) > The > argument on the squeak list seemed to be: > - the squeak epoch has a certain beauty to it, being the turn of the > century > vs > - why reinvent the wheel? Everybody already knows what the unix epoch is > (e.g. you can point them to Wikipedia) > > The full discussion is here: > > http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581… > > The main thing is to make sure that whatever we use is based on UTC and not > local time. > > So - two options > - PharoOffset := 1 January, 1901 UTC > - Unix offset > > Also, whatever we change it to (and IMHO it really needs to be changed), I > think existing live objects from previous Pharos (e.g. that are > materialized > with fuel) may be invalid (like the recent zip/mcz consequences) > > -- > View this message in context: > http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- best, Eliot

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Cameron Sanders

Great, Thanks for the feedback! Good points. I appreciate it. Ciao, Cam On Mon, Jun 11, 2012 at 11:27 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 11/06/12 10:35 PM, Cameron Sanders wrote: > >> Do you need 1.4, and why? -- if you do not mind sharing. >> > > I was building on 1.3, and had a second automated build which tracked > 1.4. Periodically, I would manually update the 1.4 base image of the > build to the then latest 1.4. Each of the builds would load the > framework packages I needed, then load my code base. > > This way I could see problems with the frameworks or my code, as 1.4 > progressed. At some point 1.4 was stable enough that I switched over > (about 6 months ago). > > ... I only recently abandoned my Pharo-1.2 one-click derived image >> when I had troubles connecting to a DB. I figured it was time to do a >> complete upgrade. But it has turned into a nightmare, and my project >> has hit a standstill, >> > > Yep, you don't want to be caught by surprise, when upgrading. > > Pending your answers to my query about why you chose 1.4 over 1.3, I >> will start fresh again. >> > > In your situation, I would choose 1.4, because Seaside, Magritte2/3, > DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not > hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached > to Omnibrowser, then there is no reason to use 1.3. > > >

June 12, 2012

[Pharo-project] [PLP] News

by Santiago Bragagnolo

PaulLePoulpe Logger is now working and tested on Pharo 1.3 core; 1.4 and 2.0, and working with two red tests at Pharo 1.2 core. The two red tests are related with an announcement issue. But it dont interfere with the work, so, it works. I'm using it actively in ConcreteTypeInference and KwisatzHaderach projects swiching configurations depending on which project im working, and work perfect. That's why i decided to make the first version. Gofer new url: 'http://ss3.gemstone.com/ss/PaulLePoulpe'; package: 'ConfigurationOfPaulLePoulpe'; load. ( (Smalltalk at: #ConfigurationOfPaulLePoulpe) project version:'1.0' ) load

June 12, 2012