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-long-filename

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=sharing

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