Tim Mackinnon wrote > Hi Ben - while I understand the description below - why would it work the > first time (no errors) and then fail the second time in a fresh image? Are > we really sure its just down to non-determinism of the load process > (possibly - but it seems very suspicious to me). There is something more > fishy about windows going on I suspect…
The Iceberg cache path is relative to the image folder, so it's at least possible to have success in one image, located in C:\Pharo\testImage\, while another image, reciding in something like C:\Users\sam\Documents\Pharo\images\exercism-test-run-7.0-32\ , fails to load the exact same filetree package... Tim Mackinnon wrote > I will track down the Exercism dependencies to see if any of them are > FileTree - having said that, on OSX (where it loads cleanly - I would > expect to be able to find one of those methods in my image - but again I > can’t? They look like valid methods - but why aren’t they in my image? Its > like the load process is downloading other stuff on its own and then not > loading that into the image? Yeaaah, that sounds fishy. But at least the first method sounds like a test, which may be part of the packages in the git repo that gets cloned without being loaded by Metacello, if the Metacello dependency specifies a *Core group which does not include tests. Tim Mackinnon wrote > I’m just worried that we keep blaming windows (and yes its dumb having a > file length restriction I this day and age) - but maybe we are missing > another problem too? > > Tim To be pendantic, (and not of much actual help, sorry :/ ) the problem isn't really with Windows, which provides API's for getting file info that handle long paths just fine, but with libgit, which is probably compiled against some POSIX stat implementation provided by Cygwin/mingw, which does not. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
