[Vm-dev] Re: [Pharo-dev] issue with large file path on windows

[Eliot Miranda]

Hi Nicolai,

    I have to say that the problem lies with the git integration.  The length of Smalltalk selectors is effectively unlimited and the language encourages Kong descriptive names.  Many (most?) unixes have a limitation of 256 characters in any path element and a PATH_MAX that may be as little as 1024.  So the current architecture is, for me, way too close to implementation limits.  IMO a far better design would be to use protocol names, all methods per protocol, eg Object.accessing or two files per class (instance & class side) with methods ordered by selector.  Either of those, but especially the last, should give good diff results in git but be well away from the implementation limit.  The one method per file, selector as file name approach is asking for trouble.

_,,,^..^,,,_ (phone)

> On Oct 12, 2015, at 3:04 PM, Nicolai Hess <nicolaihess at web.de> wrote:
> 
> 
> 
> 2015-09-15 9:19 GMT+02:00 Nicolai Hess <nicolaihess at web.de>:
>> 
>> 
>> 2015-09-14 23:10 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>>  
>>> Thanks Nicolai, that's great!  I'll merge in your changes.  Which files do I need to look at?
>> 
>> I changed (removed my code, added Marcels)
>> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c 
>> platforms/win32/vm/sqWin32.h 
>> platforms/win32/vm/sqWin32Directory.c 
>> 
>> I added (should be the same as in squeak vm repository)
>> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c 
>> 
>> 
>> But my changes only about that code that already is in squeaks repository.
>> 
>> If we want to merge some of the pharo-vm code into squeaks branch, we
>> first need to wrap that code with some #ifdefs
>> 
>> (For the win32 file/directory stuff, this would be code in
>> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c 
>> platforms/win32/vm/sqWin32.h 
>> platforms/win32/vm/sqWin32Directory.c 
>> and 
>> platforms/Cross/plugins/FilePlugin/FilePlugin.h)
>> 
>> Maybe Estaban should look at this, and tell which path he would follow  to
>> merge those changes.
> 
> OK, these changes are now in pharos vm repository, ....
> 
> 
> but I just found another issue with long paths, squeak and pharo:
> 
> This is a path from one github repository based package
> 
> u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st
> 
> Yes, pathlength is 282! But I think the problem is not the overall path name, but the length of the filename.
> 
> On squeak, you can open and browse the parent directory in a FileList and even show the contents of the contained files.
> On Pharo, this does not work, because Pharos FileList uses a different method for accessing the file attributes.
> (the difference is, we call dir_EntryLookup, whereas (most) of Squeaks FileList methods just call dir_Lookup).
> 
> But there are some methods in Squeak that call dir_EntryLookup and those are failing too. 
> 
> For example:
> 
> "Creating a Stream and reading the contents works"
> (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') contents.
> 
> "Creating a Stream and accessing the directory entry does not work"
> (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') directoryEntry
> " -> Error: file not in directory: initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st"
> 
> 
> nicolai
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151012/bed44553/attachment.htm