[Pharo-project] FileReference should throw error when deleting unexisting files?
So if we now do: 'afileThatDoesntExist' asFileReference delete I get a PrimitiveFailed. If this is what we want, can I add: FileReference >> deleteIfExists self exists ifTrue: [ self delete] or something like that? because lots of places (tearDown of tests) I want to remove crao which may or may not exist... thanks -- Mariano http://marianopeck.wordpress.com
On Mon, Jun 11, 2012 at 8:38 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
So if we now do:
'afileThatDoesntExist' asFileReference delete
I get a PrimitiveFailed. If this is what we want, can I add:
FileReference >> deleteIfExists
self exists ifTrue: [ self delete]
So I discussed in IRC and Camillo and Sean recommended to use #ensureDelete because it is concistent to ensureFile and ensureDirecotry etc... for me #ensureDelete sounds the opposite to what this method does because I am not ensuring anything, if fact, I won't remove anything if the file does not exist. Camilo also suggested to do FileReference >> deleteIfExists self deleteIfAbsent: [ ] FileReference >> deleteIfAbsent: aBlock self exists ifTrue: [self delete] ifFalse: [aBock value] What do you think? which one do you like more? #ensureDelete or #deleteIfExists? do you also agree to add the intermediate #deleteIfAbsent: ? Cheers
or something like that? because lots of places (tearDown of tests) I want to remove crao which may or may not exist...
thanks
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Mariano Martinez Peck <marianopeck@gmail.com> writes:
On Mon, Jun 11, 2012 at 8:38 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
So if we now do:
 'afileThatDoesntExist' asFileReference delete
I get a PrimitiveFailed. If this is what we want, can I add:
FileReference >> deleteIfExists
self exists ifTrue: [ self delete]
So I discussed in IRC and Camillo and Sean recommended to use #ensureDelete because it is concistent to ensureFile and ensureDirecotry etc... for me #ensureDelete sounds the opposite to what this method does because I am not ensuring anything, if fact, I won't remove anything if the file does not exist.
I like #ensureDelete, because yes, it is consistent. I see it as "make sure the file is deleted", so it makes sense to me. Maybe #ensureDeleted would be better? Nico
Camilo also suggested to do
FileReference >> deleteIfExists
self deleteIfAbsent: [ ]
FileReference >> deleteIfAbsent: aBlock
self exists      ifTrue: [self delete]      ifFalse: [aBock value]
What do you think? which one do you like more? #ensureDelete or #deleteIfExists? do you also agree to add the intermediate #deleteIfAbsent: ?
Cheers
Â
or something like that?  because lots of places (tearDown of tests) I want to remove crao which may or may not exist...
thanks
-- Mariano http://marianopeck.wordpress.com
-- Nicolas Petton http://nicolas-petton.fr
Chris Cunningham wrote
I like #ensureDeleted (make sure it doesn't exist)
Makes sense... +1 -- View this message in context: http://forum.world.st/FileReference-should-throw-error-when-deleting-unexist... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@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@gmail.com> wrote:
Maybe #ensureDeleted would be better?
Nico I like #ensureDeleted (make sure it doesn't exist)
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@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@gmail.com> wrote:
Maybe #ensureDeleted would be better?
Nico I like #ensureDeleted (make sure it doesn't exist)
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@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@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@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@gmail.com> wrote:
Maybe #ensureDeleted would be better?
Nico I like #ensureDeleted (make sure it doesn't exist)
-- Mariano http://marianopeck.wordpress.com
no, I vote for #deleteIfAbsent: too On Jun 12, 2012, at 9:49 AM, Mariano Martinez Peck wrote:
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@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@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@gmail.com> wrote:
Maybe #ensureDeleted would be better?
Nico I like #ensureDeleted (make sure it doesn't exist)
-- Mariano http://marianopeck.wordpress.com
On Tue, Jun 12, 2012 at 9:54 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
no, I vote for #deleteIfAbsent: too
fuc...I hate discussing in IRC. I won't do it again... In IRC we said that even if I have #deleteIfAbsent: it is NOT enough. I don't want to have to do aReference deleteIfAbsent: [] all the time...I don't like it. So I want #ensureDeleted or #deleteIfExists, and yes, it can rely on #deleteIfAbsent: if desired, I don't care. cheers
On Jun 12, 2012, at 9:49 AM, Mariano Martinez Peck wrote:
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@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@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@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@gmail.com> wrote:
Maybe #ensureDeleted would be better?
Nico I like #ensureDeleted (make sure it doesn't exist)
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
he... I'm ok with that. But I want #deleteIfAbsent: :) On Jun 12, 2012, at 9:57 AM, Mariano Martinez Peck wrote:
On Tue, Jun 12, 2012 at 9:54 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote: no, I vote for #deleteIfAbsent: too
fuc...I hate discussing in IRC. I won't do it again... In IRC we said that even if I have #deleteIfAbsent: it is NOT enough. I don't want to have to do aReference deleteIfAbsent: [] all the time...I don't like it. So I want #ensureDeleted or #deleteIfExists, and yes, it can rely on #deleteIfAbsent: if desired, I don't care.
cheers
On Jun 12, 2012, at 9:49 AM, Mariano Martinez Peck wrote:
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@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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@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@gmail.com> wrote:
Maybe #ensureDeleted would be better?
Nico I like #ensureDeleted (make sure it doesn't exist)
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Now I found another problem.... | filesystem reference | filesystem := FileSystem store: DiskStore activeClass createDefault. reference := filesystem * 'plonk'. reference openWritable: true. reference exists -> answers false, but | filesystem reference | filesystem := FileSystem memory. reference := filesystem * 'plonk'. reference openWritable: true. reference exists -> answers true. So...first, they should be polimorphic, right? second, which one is the correct? I guess in memory? thanks On Tue, Jun 12, 2012 at 11:45 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
+ 1
he... I'm ok with that. But I want #deleteIfAbsent: :)
-- Mariano http://marianopeck.wordpress.com
Mariano Martinez Peck wrote
Now I found another problem....
| filesystem reference | filesystem := FileSystem store: DiskStore activeClass createDefault. reference := filesystem * 'plonk'. reference openWritable: true. reference exists
-> answers false
Answers true for me on Mac with this vm: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/l... -- View this message in context: http://forum.world.st/FileReference-should-throw-error-when-deleting-unexist... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Jun 12, 2012 at 3:39 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Mariano Martinez Peck wrote
Now I found another problem....
| filesystem reference | filesystem := FileSystem store: DiskStore activeClass createDefault. reference := filesystem * 'plonk'. reference openWritable: true. reference exists
-> answers false
Answers true for me on Mac with this vm:
https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/l...
really??? i have just tried with that VM and I still get a false. Can you try with a different name instead of 'plonk' ??? like 'dasdasdasdasdasd' ? :)
-- View this message in context: http://forum.world.st/FileReference-should-throw-error-when-deleting-unexist... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
Mariano Martinez Peck wrote
really??? i have just tried with that VM and I still get a false. Can you try with a different name instead of 'plonk' ??? like 'dasdasdasdasdasd' ? :)
that worked too... I'm attaching http://forum.world.st/file/n4634490/CogVM.zip the vm on Nabble . Just to be clear, you're highlighting the whole block and doing "PrintIt", right? -- View this message in context: http://forum.world.st/FileReference-should-throw-error-when-deleting-unexist... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Jun 12, 2012 at 6:07 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Mariano Martinez Peck wrote
really??? i have just tried with that VM and I still get a false. Can you try with a different name instead of 'plonk' ??? like 'dasdasdasdasdasd'
?
:)
that worked too... I'm attaching http://forum.world.st/file/n4634490/CogVM.zip the vm on Nabble . Just to be clear, you're highlighting the whole block and doing "PrintIt", right?
yes, I do that. Tried with that VM, same result. Just to clarify, the output of Smalltalk vm version is Smalltalk vm version 'CoInterpreter VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 2b16c2cfc16ef2e08dbc93113ce9552e810e3e78 Date: Wed May 30 16:16:27 2012 +0200 By: Esteban Lorenzano <estebanlm@gmail.com>' maybe this is because I am in snow leopard and you are in lion? -- Mariano http://marianopeck.wordpress.com
On Tue, Jun 12, 2012 at 6:27 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Jun 12, 2012 at 6:07 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Mariano Martinez Peck wrote
really??? i have just tried with that VM and I still get a false. Can
you
try with a different name instead of 'plonk' ??? like 'dasdasdasdasdasd' ? :)
that worked too... I'm attaching http://forum.world.st/file/n4634490/CogVM.zip the vm on Nabble . Just to be clear, you're highlighting the whole block and doing "PrintIt", right?
yes, I do that. Tried with that VM, same result. Just to clarify, the output of Smalltalk vm version is
Smalltalk vm version 'CoInterpreter VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 2b16c2cfc16ef2e08dbc93113ce9552e810e3e78 Date: Wed May 30 16:16:27 2012 +0200 By: Esteban Lorenzano <estebanlm@gmail.com>'
maybe this is because I am in snow leopard and you are in lion?
let's see something else. If you run all FileSystem tests, how many yellow do you have? I have 4, one looking suspicious ;) 312 run, 308 passes, 0 expected failures, 4 failures, 0 errors, 0 unexpected passes Failures: DiskFileSystemTest>>#testCopyDestExists DiskFileSystemTest>>#testFile DiskFileSystemTest>>#testRootIsNotAFile FileHandleTest>>#testCreatedOpen Errors: #testCreatedOpen is failing...maybe this is related....
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Hi sean. It's time you update your image ;) the tests in latest images: works with Pharo2.0a Latest update: #20119 does not work with Pharo2.0a Latest update: #20129 problem is that (in the broken one) "reference openWritable: true" answers a handler with a NIL id.... will try to debug later. but if someone already have a hint... cheers On Tue, Jun 12, 2012 at 7:04 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Jun 12, 2012 at 6:27 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Jun 12, 2012 at 6:07 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Mariano Martinez Peck wrote
really??? i have just tried with that VM and I still get a false. Can
you
try with a different name instead of 'plonk' ??? like 'dasdasdasdasdasd' ? :)
that worked too... I'm attaching http://forum.world.st/file/n4634490/CogVM.zip the vm on Nabble . Just to be clear, you're highlighting the whole block and doing "PrintIt", right?
yes, I do that. Tried with that VM, same result. Just to clarify, the output of Smalltalk vm version is
Smalltalk vm version 'CoInterpreter VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 2b16c2cfc16ef2e08dbc93113ce9552e810e3e78 Date: Wed May 30 16:16:27 2012 +0200 By: Esteban Lorenzano <estebanlm@gmail.com>'
maybe this is because I am in snow leopard and you are in lion?
let's see something else. If you run all FileSystem tests, how many yellow do you have? I have 4, one looking suspicious ;)
312 run, 308 passes, 0 expected failures, 4 failures, 0 errors, 0 unexpected passes Failures: DiskFileSystemTest>>#testCopyDestExists DiskFileSystemTest>>#testFile DiskFileSystemTest>>#testRootIsNotAFile FileHandleTest>>#testCreatedOpen
Errors:
#testCreatedOpen is failing...maybe this is related....
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Mariano Martinez Peck wrote
Hi sean. It's time you update your image ;) ...does not work with Pharo2.0a Latest update: #20129
Ah yes. Now it's broken... I feel much better :) -- View this message in context: http://forum.world.st/FileReference-should-throw-error-when-deleting-unexist... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
- Added #deleteIfAbsent: , #ensureDeleted and #ensureClosed. - Added #testDeleteIfAbsent, #testEnsureClosed, #testEnsureDeleted and #testExists. - Make FileSystemHandleTest >> tearDown more robust by using ensure* methods. I have know much about FileSystem so if someone can check please. I don't know if the classes where I place the unit tests are the correct place. http://code.google.com/p/pharo/issues/detail?id=6060 thanks On Tue, Jun 12, 2012 at 10:57 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Mariano Martinez Peck wrote
Hi sean. It's time you update your image ;) ...does not work with Pharo2.0a Latest update: #20129
Ah yes. Now it's broken... I feel much better :)
-- View this message in context: http://forum.world.st/FileReference-should-throw-error-when-deleting-unexist... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
On 11.06.2012 20:38, Mariano Martinez Peck wrote:
So if we now do:
'afileThatDoesntExist' asFileReference delete
I get a PrimitiveFailed. If this is what we want, can I add:
FileReference >> deleteIfExists
self exists ifTrue: [ self delete]
or something like that? because lots of places (tearDown of tests) I want to remove crao which may or may not exist...
thanks
-- Mariano http://marianopeck.wordpress.com
Is there any specific reason why you need to use setUp/tearDown instead of a more restricted scope? For scoped operations like tests, I always liked the XFileNamed: do: api, when you have references, how about: aFileReference tempFileDo: [:fileStream :canonicalPath (culled) |] Could be useful for command line interaction as well, I guess. Cheers, Henry
participants (8)
-
Chris Cunningham -
Esteban Lorenzano -
Henrik Sperre Johansen -
Mariano Martinez Peck -
petton.nicolas＠gmail.com -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse