On 7/24/16 4:47 PM, Ben Coman wrote:
On Mon, Jul 25, 2016 at 4:23 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On 7/24/16 11:29 AM, Cyril Ferlicot D. wrote:
Le 18/07/2016 à 20:33, Dale Henrichs a écrit :
Hello Cyril,
This appears to be related to the fact that the class comment file (README.md) is unexpectedly missing from your download ... Since the file is present on GitHub[1] ... perhaps the download from failed in an odd way without triggering an error leading to this problem ... I would have expected an incomplete download error along the way --- if you still have a copy of the Transcript a download error message should be present ...
Retrying the git get/load might get a good result ...
Dale
[1]
https://github.com/dalehenrich/metacello-work/tree/master/repository/Baselin...
https://github.com/dalehenrich/filetree/blob/pharo6.0_dev/repository/Montice...
Hi Dale,
I got some time to retry a little.
I tried to load in Pharo 6 a project of mine that is on GitHub and it worked.
I tried in the same image to load Metacello but it failed.
When I go in the github-cache/ folder, I see that the Metacello folder contains all the folder of each packages BUT they do not contains any files[1]. The only file in the folder is the .filetree file in the repository/ folder.
I get the problem into Pharo 5 and 6 on Windows 7. I do not have this problem on OSX.
Also, I tried to download the zip of the repository and when I try to extract it on Windows I get an error message saying that the zip file is not valid[2].
When I try to clone the repository I get an error because some names are too long[3].
-- [1] http://puu.sh/qcVoG/60e481ec1b.png [2] http://puu.sh/qcVqE/f8a4dbd36d.png [3] http://puu.sh/qcVkh/fbd16ba541.png Cyril,
Thanks for providing a stack trace ... I recognize the issue --- windows has a 256 char (I think) path length limit and a handful of the Metacello methods exceed this limit ... I've created a dev_win-hack branch on Metacello where I renamed the files that were exceeding the limit[1] --- in my particular use case, git was not able to access the files which is why I didn't recognize the issue initially --- there are a garden basket of problems when trying to use windows, but the stack provided the necessary detail to figure out which piece of fruit was going bad :)
Or could paths be specified in this format... \\?\D:\very long path".
https://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#maxpath
If I'm not mistaken, this kind of monkey business would have to be done within the FileSystem code or maybe the vm ... I'm pretty sure that FileTree is using FileReferences to access the files with long file paths in a platform independent manner ... Dale