<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Nicolai,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"> 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.<br><br><span style="background-color: rgba(255, 255, 255, 0);">_,,,^..^,,,_ (phone)</span></div><div><br>On Oct 12, 2015, at 3:04 PM, Nicolai Hess <<a href="mailto:nicolaihess@web.de">nicolaihess@web.de</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-09-15 9:19 GMT+02:00 Nicolai Hess <span dir="ltr"><<a href="mailto:nicolaihess@web.de" target="_blank">nicolaihess@web.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div class="gmail_extra"><br><div class="gmail_quote">2015-09-14 23:10 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div>Thanks Nicolai, that's great! I'll merge in your changes. Which files do I need to look at?</div></blockquote><div><br></div><div>I changed (removed my code, added Marcels)<br>
<span title="platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c">
platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c
</span>
<br><span title="platforms/win32/vm/sqWin32.h">platforms/win32/vm/sqWin32.h
</span>
<br>
<span title="platforms/win32/vm/sqWin32Directory.c">
platforms/win32/vm/sqWin32Directory.c
</span>
<br><br>I added (should be the same as in squeak vm repository)<br>
<span title="platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c">
platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c
</span>
<br></div><div><br><br></div><div>But my changes only about that code that already is in squeaks repository.<br><br></div><div>If we want to merge some of the pharo-vm code into squeaks branch, we<br></div><div>first need to wrap that code with some #ifdefs<br></div><div><br>(For the win32 file/directory stuff, this would be code in<br><span title="platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c">platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c
</span>
<br><span title="platforms/win32/vm/sqWin32.h">platforms/win32/vm/sqWin32.h
</span>
<br>
<span title="platforms/win32/vm/sqWin32Directory.c">
platforms/win32/vm/sqWin32Directory.c
</span>
<br></div><div>and <br></div><div><span title="platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c">platforms/Cross/plugins/FilePlugin/FilePlugin.h)<br><br></span></div><div><span title="platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c">Maybe Estaban should look at this, and tell which path he would follow to<br></span></div><div><span title="platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c">merge those changes.<br><br></span></div></div></div></div></blockquote><div><br></div><div>OK, these changes are now in pharos vm repository, ....<br><br><br>but I just found another issue with long paths, squeak and pharo:<br><br></div><div>This is a path from one github repository based package<br><br>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<br><br></div><div>Yes, pathlength is 282! But I think the problem is not the overall path name, but the length of the filename.<br></div><div><br></div><div>On squeak, you can open and browse the parent directory in a FileList and even show the contents of the contained files.<br></div><div>On Pharo, this does not work, because Pharos FileList uses a different method for accessing the file attributes.<br></div><div>(the difference is, we call dir_EntryLookup, whereas (most) of Squeaks FileList methods just call dir_Lookup).<br><br></div><div>But there are some methods in Squeak that call dir_EntryLookup and those are failing too. <br></div><div><br>For example:<br></div><div><br></div><div>"Creating a Stream and reading the contents works"<br></div>(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.<br><br>"Creating a Stream and accessing the directory entry does not work"<br>(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<br>" -> Error: file not in directory: initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st"<br><br><br></div><div class="gmail_quote">nicolai<br></div><br><br></div></div>
</div></blockquote></body></html>