FileReference should throw error when deleting unexisting files?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

FileReference should throw error when deleting unexisting files?

Mariano Martinez Peck
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

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Mariano Martinez Peck


On Mon, Jun 11, 2012 at 8:38 PM, Mariano Martinez Peck <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Nicolas Petton
Mariano Martinez Peck <[hidden email]> writes:

> On Mon, Jun 11, 2012 at 8:38 PM, Mariano Martinez Peck
> <[hidden email]> 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

cbc
Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

cbc
On Mon, Jun 11, 2012 at 2:32 PM,  <[hidden email]> wrote:
> Maybe #ensureDeleted would be better?
>
> Nico
I like #ensureDeleted (make sure it doesn't exist)

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Sean P. DeNigris
Administrator
Chris Cunningham wrote
I like #ensureDeleted (make sure it doesn't exist)
Makes sense... +1
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Schwab,Wilhelm K
In reply to this post by cbc
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: [hidden email] [[hidden email]] on behalf of Chris Cunningham [[hidden email]]
Sent: Monday, June 11, 2012 5:55 PM
To: [hidden email]
Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

On Mon, Jun 11, 2012 at 2:32 PM,  <[hidden email]> wrote:
> Maybe #ensureDeleted would be better?
>
> Nico
I like #ensureDeleted (make sure it doesn't exist)


Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

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: [hidden email] [[hidden email]] on behalf of Chris Cunningham [[hidden email]]
> Sent: Monday, June 11, 2012 5:55 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
>
> On Mon, Jun 11, 2012 at 2:32 PM,  <[hidden email]> wrote:
>> Maybe #ensureDeleted would be better?
>>
>> Nico
> I like #ensureDeleted (make sure it doesn't exist)
>
>


Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Chris Cunningham [[hidden email]]
> Sent: Monday, June 11, 2012 5:55 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
>
> On Mon, Jun 11, 2012 at 2:32 PM,  <[hidden email]> wrote:
>> Maybe #ensureDeleted would be better?
>>
>> Nico
> I like #ensureDeleted (make sure it doesn't exist)
>
>





--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

EstebanLM
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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Chris Cunningham [[hidden email]]
> Sent: Monday, June 11, 2012 5:55 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
>
> On Mon, Jun 11, 2012 at 2:32 PM,  <[hidden email]> wrote:
>> Maybe #ensureDeleted would be better?
>>
>> Nico
> I like #ensureDeleted (make sure it doesn't exist)
>
>





--
Mariano
http://marianopeck.wordpress.com


Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Mariano Martinez Peck


On Tue, Jun 12, 2012 at 9:54 AM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Chris Cunningham [[hidden email]]
> Sent: Monday, June 11, 2012 5:55 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
>
> On Mon, Jun 11, 2012 at 2:32 PM,  <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

EstebanLM
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Chris Cunningham [[hidden email]]
> Sent: Monday, June 11, 2012 5:55 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
>
> On Mon, Jun 11, 2012 at 2:32 PM,  <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Stéphane Ducasse
+ 1

> he... I'm ok with that. But I want #deleteIfAbsent: :)
>

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Henrik Sperre Johansen
In reply to this post by Mariano Martinez Peck
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

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Mariano Martinez Peck
In reply to this post by Stéphane Ducasse
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 <[hidden email]> wrote:
+ 1

> he... I'm ok with that. But I want #deleteIfAbsent: :)
>




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Sean P. DeNigris
Administrator
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/lastSuccessfulBuild/artifact/Cog-mac.zip
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Mariano Martinez Peck


On Tue, Jun 12, 2012 at 3:39 PM, Sean P. DeNigris <[hidden email]> 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/lastSuccessfulBuild/artifact/Cog-mac.zip


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-unexisting-files-tp4634357p4634473.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Sean P. DeNigris
Administrator
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 the vm on Nabble. Just to be clear, you're highlighting the whole block and doing "PrintIt", right?
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Mariano Martinez Peck


On Tue, Jun 12, 2012 at 6:07 PM, Sean P. DeNigris <[hidden email]> 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 <[hidden email]>'

maybe this is because I am in snow leopard and you are in lion?


--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Mariano Martinez Peck


On Tue, Jun 12, 2012 at 6:27 PM, Mariano Martinez Peck <[hidden email]> wrote:


On Tue, Jun 12, 2012 at 6:07 PM, Sean P. DeNigris <[hidden email]> 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 <a href="tel:30%2016" value="+333016" target="_blank">30 16:16:27 2012 +0200 By: Esteban Lorenzano <[hidden email]>'

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

Reply | Threaded
Open this post in threaded view
|

Re: FileReference should throw error when deleting unexisting files?

Mariano Martinez Peck
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 <[hidden email]> wrote:


On Tue, Jun 12, 2012 at 6:27 PM, Mariano Martinez Peck <[hidden email]> wrote:


On Tue, Jun 12, 2012 at 6:07 PM, Sean P. DeNigris <[hidden email]> 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 <a href="tel:30%2016" value="+333016" target="_blank">30 16:16:27 2012 +0200 By: Esteban Lorenzano <[hidden email]>'

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

12