Issue 4647 in pharo: Update Filesystem Dialogs to use the new FS implementation

Comment #20 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

Camillo I merged the two others but when I open a file list it is really  
slow
and clicking on a tree node is also really slow.
can you have a look?

I will remove the slice from ss3 for now.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #21 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

cant you just leave the slice? doesn't really make sense to remove it...

I can attach the missing sources later on.

PS: use the monkey ;)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #22 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

What the monkey does when there is merge conflict btw?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #23 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

the problem lies in how FSFilesystem checks whether an FSReference is a  
file or a directory leading to O(n^2) complexity.

Basically it iterates over all files in a directory to get back the  
primitive's entry giving low-level information such as filetype / creation  
date...

There would be a primitive primitiveDirectoryEntry which would allow for  
direct indexing with the filename avoiding a second loop over everything  
again.

The primitive implementations under OSX are incomplete (Cocoa /  
Objective-C) or not working properly (Carbon / C).


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #24 on issue 4647 by [hidden email]: Update Filesystem Dialogs to  
use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

It's a bit hackish, but FileDirectory >> fileExists: was changed a while  
back to avoid iterating directory contents by trying to open the file,  
which has seemed to work ok ever since...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #25 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

right, I thought of the same solution opening a fileStream to test if a  
file exists.
So for now this should suffice to address the performance issues.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #26 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

ok that was still not the proper solution, since it only tells you whether  
there is a file at the given path but not the type (e.g. File vs  
Directory). So this solution drops out as well...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #27 on issue 4647 by [hidden email]: Update Filesystem Dialogs to  
use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

well, you could change isDirectory: to be O(1), say:
FSStore >> isDirectory: aPath
        aPath isRoot ifTrue: [ ^ true ].
        self
                directoryAt: aPath
                ifAbsent: [^false]
                nodesDo: [^true]

(or nodesDo: [:each | ^true] if not changing the method to use culling)
       


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #28 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

thats again the same as the current implementation nodesDo: will loop over  
all entries in a directory, hence

(FSFilesystem disk referenceTo: '/foo/bar') files

is going to be O(n^2) instead of O(n)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #29 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

I fixed the primitive under OSX so you can do now

p := FSFilePluginPrims new.
p lookupDirectory: (p encode: '/') filename: (p encode: 'Applications').

without the need of looping over all the entries.
on to fixing the *nix implementation


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #30 on issue 4647 by [hidden email]: Update Filesystem Dialogs to  
use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

@26, you can't open a stream a Directory, so it does tell you the type if  
successful.
It's basically an O(1) isFile:.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #31 on issue 4647 by [hidden email]: Update Filesystem Dialogs to  
use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

@28: It won't loop for all the nodes when you use a non-local return like  
posted.



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #32 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

maybe I get this wrong :) but I think that still doesn't work:


take the following file as an example (readable by everyone, writeable only  
by root):

> ll /System/Library/BridgeSupport/libSystem.bridgesupport
-rw-r--r--  1 root  wheel  224205 15 Nov 17:08  
/System/Library/BridgeSupport/libSystem.bridgesupport

then I cannot safely distinguish on OSX whether this is a file or a  
directory:

this one is wrong...
FileStream  
fileNamed: '/System/Library/BridgeSupport/libSystem.bridgesupport ' => nil

this one is correct
FileStream fileNamed: '/System/Library/BridgeSupport/' => nil

this one is correct
FileStream  
readOnlyFileNamed: '/System/Library/BridgeSupport/libSystem.bridgesupport'  
=> MultiByteFileStream:...

this one is wrong
FileStream readOnlyFileNamed: '/System/Library/BridgeSupport'. =>  
MultiByteFileStream: ..


What I could do is try to read form the file, but what do I get for empty  
files?

so FileStreams are not a safe way to distinguish files / directories on  
unix systems...



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #33 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

@31 that's what the default implementation did of course, which might not  
lead to a full O(n^2) behavior but in the example use case it was something  
like O(5n) to O(10n) which is not nice at all :/


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixReviewNeeded

Comment #34 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

- added explicit browse methods for directories and files
- see the latest FSConfiguration for the changes


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Workneeded

Comment #35 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

So where do I find the code?

We really need to automatize the harvesting... a machine can not follow  
this report.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixToInclude

Comment #36 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

updated the old slice (filesystem has already been updated in the main  
image):

SLICE-Issue-4647-Update-Filesystem-Dialogs-to-use-the-new-FS-implementation-CamilloBruni.4


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Integrated

Comment #37 on issue 4647 by [hidden email]: Update Filesystem  
Dialogs to use the new FS implementation
http://code.google.com/p/pharo/issues/detail?id=4647

in 14325


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker