pharo 2.0 FileDirectory

[camillobruni]

http://code.google.com/p/pharo/issues/detail?id=5772 completely removed FileDirectory from the image hence a rewrite of FileTree on top of FileSystem is needed in Pharo 2.0

[dalehenrich]

Not a good time for me to take that on right now ... probably not until after ESUG ... I would certainly accept contributions from someone else though

[camillobruni]

I will take care of it, since I want to keep on exporting pharo versions to github

[dalehenrich]

Much appreciated!

Provide a pull request ...I've already got a pharo2.0 branch, so just do a topic branch off of that for the update ... pull requests are branch based now, so we'll want to isolate your changes in a separate branch off of pharo2.0 branch so that I can review changes ...

also the pharo2.0 branch is a commit behind (just some tests), but if you're on a topic branch it won't matter that much...

[camillobruni]

the old bootstrap code in the gemstone repos relies still FileDirectory, so I guess we will have to publish a new version there for Pharo 2.0

[dalehenrich]

Yes once you get things working we'll need to update the .pharo20 branch ... I can do that part after I've integrated the pull request onto the pharo2.0 branch...

Thanks a ton for helping!

[dalehenrich]

clean build against Pharo-1.4 ... code base is ready, but haven't done manual load from scratch yet and will also need to ensure the Metacello Preview runs in Pharo-2.0 before travis ci builds enabled

[dalehenrich]

builderci is ready for Pharo-2.0

[dalehenrich]

need to refresh the bootstrap configuration and mcz files to include Pharo-2.0 as that is the root cause of the current build failure for builderCI and Pharo-2.0

[camillobruni]

Any news on that? I think you only accidentally committed FileDirectoryEntry which is nowhere referenced in the rest of the code.

[dalehenrich]

I'm waiting for the stability work with RPackage to finish up before I start dev on Pharo 2.0 ... I need to make a sweep through builderCI, FileTree, and Metacello Preview, so I want a fairly stable environment before I get going ...

[camillobruni]

I still see an extension method for DirectoryEntryFile in the 2.0 branch. A class that has been eliminated together with FileDirectory.

[camillobruni]

Couldn't we port the whole 1.4 and 2.0 branch to a clean FileSystem implementation once 1.4 will have the complete changes from 2.0 FileSystem https://code.google.com/p/pharo/issues/detail?id=6553?

[dalehenrich]

GemStone and Squeak will still be using FileDirectory (AFAIK) so I'm less inclined to do a complete rewrite based on FileSystem ... OTOH if someone else were to maintain the FileSystem-based implementation (for Pharo1.4/2.0) I wouldn't complain:)

Dale

----- Original Message -----	From: "Camillo Bruni" notifications@github.com	To: "dalehenrich/filetree" filetree@noreply.github.com	Cc: "Dale Henrichs" dhenrich@vmware.com	Sent: Wednesday, September 12, 2012 4:32:33 AM	Subject: Re: [filetree] pharo 2.0 FileDirectory (#52)
Couldn't we port the whole 1.4 and 2.0 branch to a clean FileSystem
implementation once 1.4 will have the complete changes from 2.0
FileSystem https://code.google.com/p/pharo/issues/detail?id=6553 ?
—
Reply to this email directly or view it on GitHub .

[dalehenrich]

I haven't touched the FileTree code for quite a while (before ESUG) and I'm waiting for Pharo2.0 to stabilize before touching it again...

I'm also trying to get a Metacello release out with Seaisde3.1 support ....

Dale

----- Original Message -----	From: "Camillo Bruni" notifications@github.com	To: "dalehenrich/filetree" filetree@noreply.github.com	Cc: "Dale Henrichs" dhenrich@vmware.com	Sent: Wednesday, September 12, 2012 4:28:25 AM	Subject: Re: [filetree] pharo 2.0 FileDirectory (#52)
I still see an extension method for DirectoryEntryFile in the 2.0
branch. A class that has been eliminated together with
FileDirectory.
—
Reply to this email directly or view it on GitHub .

[camillobruni]

• for my git integration plan code with FileDirectory semantics won't do, since that decouples paths from fileystems
• I have no problem maintaining the port (I guess max would help as well) besides I think if it's important enough it will make it into the main pharo package

[dalehenrich]

I thought you were talking about a complete rewrite?

If all you are suggesting to do is to use the existing FileSystem code for FileTree in Pharo1.4, then I don't have a problem ... I don't want to maintain two completely different implementations, but variant using FileDirectory-Utilities will work for me, if it works for you ... and I will even maintain it ...

I think I can arrange to conditionally load the FileDirectory-Utilities (for FileSystem or FileDirectory) in Pharo1.4 under control of a configuration ... I'm a little concerned about folks running on a slightly older version of Pharo1.4 (like Summer) and not having the correct FileSystem code installed ...

Dale

----- Original Message -----	From: "Camillo Bruni" notifications@github.com	To: "dalehenrich/filetree" filetree@noreply.github.com	Cc: "Dale Henrichs" dhenrich@vmware.com	Sent: Wednesday, September 12, 2012 3:23:41 PM	Subject: Re: [filetree] pharo 2.0 FileDirectory (#52)
* for my git integration plan code with FileDirectory semantics
won't do, since that decouples paths from fileystems
* I have no problem maintaining the port (I guess max would help
as well) besides I think if it's important enough it will make
it into the main pharo package
—
Reply to this email directly or view it on GitHub .

[camillobruni]

On 2012-09-13, at 01:01, Dale Henrichs notifications@github.com wrote:

I thought you were talking about a complete rewrite?

ah no no, it'was only about using the existing FS.

If all you are suggesting to do is to use the existing FileSystem code for FileTree in Pharo1.4, then I don't have a problem ... I don't want to maintain two completely different implementations, but variant using FileDirectory-Utilities will work for me, if it works for you ... and I will even maintain it ...

I think I can arrange to conditionally load the FileDirectory-Utilities (for FileSystem or FileDirectory) in Pharo1.4 under control of a configuration ... I'm a little concerned about folks running on a slightly older version of Pharo1.4 (like Summer) and not having the correct FileSystem code installed ...

for now I'll develop a version and store it on gemstone, since the bootstrap won't work directly... once I can export all my git code again I am happy :).

well, I wouldn't see any reason why a developer would chose the older 1.4 release. since for deployment you most probably won't use filetree...

but indeed, that is a point of discussion...

[dalehenrich]

regarding the older Pharo1.4 ... the configurations don't distinguish the the update level of Pharo .... that's why OB caused such a hullabaloo a while back .. .older versions of Pharo1.3(?) needed the old version of OB and when the #stable version was updated to reference a later version of pharo1.3 all hell broke loose for the guys with older versions ... I'd rather avoid that kind of mess if at all possible ... especially for a supposedly stable pharo1.4 release:)

Dale

----- Original Message -----	From: "Camillo Bruni" notifications@github.com	To: "dalehenrich/filetree" filetree@noreply.github.com	Cc: "Dale Henrichs" dhenrich@vmware.com	Sent: Wednesday, September 12, 2012 4:08:53 PM	Subject: Re: [filetree] pharo 2.0 FileDirectory (#52)
On 2012-09-13, at 01:01, Dale Henrichs notifications@github.com
wrote:
> I thought you were talking about a complete rewrite?
ah no no, it'was only about using the existing FS.
> If all you are suggesting to do is to use the existing
> FileSystem code for FileTree in Pharo1.4, then I don't have a
> problem ... I don't want to maintain two completely different
> implementations, but variant using FileDirectory-Utilities will
> work for me, if it works for you ... and I will even maintain it
> ...
>
> I think I can arrange to conditionally load the
> FileDirectory-Utilities (for FileSystem or FileDirectory) in
> Pharo1.4 under control of a configuration ... I'm a little
> concerned about folks running on a slightly older version of
> Pharo1.4 (like Summer) and not having the correct FileSystem code
> installed ...
for now I'll develop a version and store it on gemstone, since the
bootstrap
won't work directly... once I can export all my git code again I am
happy :).
well, I wouldn't see any reason why a developer would chose the older
1.4 release.
since for deployment you most probably won't use filetree...
but indeed, that is a point of discussion...
—
Reply to this email directly or view it on GitHub .

[seandenigris]

Why not use customProjectAttributes to conditionally load based on which version is present?

[dalehenrich]

The only sticky wicket is that FileSystem being present isn't diagnostic ... we need to make sure that the correct version of FileSystem is present ... my preference would be to make it an option to choose to load the FileSystem support into Pharo1.4 ... then the FsGit code could require that the FileSystem support be loaded in FileTree as a pre-requisite and then FsGit could also require the correct version of FileSystem as a pre-requisite ....

The simple naive load of FileTree would still use FileDirectory in Pharo1.4...

[seandenigris]

I don't have an opinion... if we go the conditional loading route, it would just have to be slightly more specific e.g. "is #selectorOnlyPresentInTheUpdatedVersion present in aClass?"

[dalehenrich]

with these changes let's call this one closed ... green builds in Pharo-2.0-20305...

builderCI has not been updated to handle Pharo2.0 ... yet ...