On Mon, Aug 24, 2015 at 8:44 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-08-24 13:34 GMT+02:00 Henrik Johansen henrik.s.johansen@veloxit.no:
On 23 Aug 2015, at 6:09 , Nicolai Hess nicolaihess@web.de wrote:
And If you want to review the changes:
https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lon...
2015-08-23 13:44 GMT+02:00 Nicolai Hess nicolaihess@web.de:
For those who had problems with pharo on windows and github based repositories, I built a windows vm with support for long paths:
https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=sharin...
For browsing directories with large paths (FileList or Inspect), you may need one additional change in the image (But I am not really sure about that) :
DiskStore>>initialize super initialize. maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ].
please test and give feedback.
This wasn't as easy as I thought, and I had to make some more changes for the file permissions (the stat-functions don't work for files with long paths). Please test other file/folder operations.
- Is an alloca version really worth it for the potential problems?
It is what Marcel used for the long path support in the squeak vm (I would have copy and paste the whole change, but I couldn't find the appropriate change for directory functions).
"Potential problems" sounded like something interesting I could learn. Here is a summary...
http://stackoverflow.com/questions/5807612/on-the-use-and-abuse-of-alloca On the use and abuse of alloca * alloca five times faster than malloc (but is that necessary given file operations likely take longer anyway?) * most concerns with alloca no problem here e.g. its a very short lifespan; the pointer is not returned from the function.
http://www.strchr.com/alloca The Perils of alloca() * remaining concern is potential stack exhaustion... * is MAX_LONG_FILE_PATH=32kB significant today (but also consider embedded application) ? * counter argument, primitive functions are not likely to entered recursively ?
Microsoft advises alloca [1] deprecated in favour of malloca [2] which allocates either stack or heap depending on requested size [1] https://msdn.microsoft.com/en-us/library/wb1s57t5(v=vs.80).aspx [2] https://msdn.microsoft.com/en-us/library/5471dc8s(VS.80).aspx
https://sourceware.org/ml/libc-alpha/2012-06/msg00246.html An example of a DIY malloca... * might have the advantage of tuning MAX_ALLOCA_CUTOFF post-compilation * minGW gcc might not have malloca * if large allocations go on the heap, maybe MAX_LONG_FILE_PATH test not required, just MAX_ALLOCA_CUTOFF
---------- btw, perhaps rename CONVERT_MULTIBYTE_TO_WIDECHAR_PATH to ALLOC_WIDECHAR_PATH_FROM_MULTIBYTE or similar so its more obviously symmetrical with FREE_WIDECHAR_PATH.
cheers -ben