Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official"
Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Yes, I know, and I already asked on the ML if we can take that change or if it is not possible because we have already other changes (pharos file plugin provides addition attributes (the file permissions)). But I got no response, so I tried to adopt Marcels change.
And I only found the change for sqWin32FilePrims.c, but missed the other change that is necessary in sqWin32Directory.c (and asked on the ML). In the meantime Marcel added this but I could not find the changed source, only an updated vm. Is this change already comitted?
I would love if someone else got this working.
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
-- _,,,^..^,,,_ best, Eliot
Hi Nicolai,
On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official"
Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Yes, I know, and I already asked on the ML if we can take that change or if it is not possible because we have already other changes (pharos file plugin provides addition attributes (the file permissions)).
Esteban and I just harmonized this. I'm (almost correctly) generating the plugin source such that one can define either PharoVM or not to chose between the different versions. I say "almost" because I'm currently spitting out
#define PharoVM 0 ... #if PharoVM
instead of
#if !defined(PharoVM) # define PharoVM 0 #endif ... #if PharoVM
but I'll fix it v soon.
But I got no response, so I tried to adopt Marcels change.
And I only found the change for sqWin32FilePrims.c, but missed the other change that is necessary in sqWin32Directory.c (and asked on the ML). In the meantime Marcel added this but I could not find the changed source, only an updated vm. Is this change already comitted?
Yes, see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32Di...
I'm sorry I didn't see your message. Did you ask on vm-dev?
I would love if someone else got this working.
:-) I hear you :-)
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
-- _,,,^..^,,,_ best, Eliot
2015-09-10 23:07 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official"
Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Yes, I know, and I already asked on the ML if we can take that change or if it is not possible because we have already other changes (pharos file plugin provides addition attributes (the file permissions)).
Esteban and I just harmonized this. I'm (almost correctly) generating the plugin source such that one can define either PharoVM or not to chose between the different versions. I say "almost" because I'm currently spitting out
#define PharoVM 0 ... #if PharoVM
instead of
#if !defined(PharoVM) # define PharoVM 0 #endif ... #if PharoVM
but I'll fix it v soon.
OK, I'll try to copy marcels solution
But I got no response, so I tried to adopt Marcels change.
And I only found the change for sqWin32FilePrims.c, but missed the other change that is necessary in sqWin32Directory.c (and asked on the ML). In the meantime Marcel added this but I could not find the changed source, only an updated vm. Is this change already comitted?
Yes, see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32Di...
Ah, good. Now (I must be blind, but) I can not see the other change, shouldn't there be a "plugins" folder in Cog/platforms/win32/? Where are the changes to sqWin32FilePrims.c now?
I'm sorry I didn't see your message. Did you ask on vm-dev?
I am not sure, maybe I only send it in the squeak-dev list
I would love if someone else got this working.
:-) I hear you :-)
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
2015-09-11 9:43 GMT+02:00 Nicolai Hess nicolaihess@web.de:
2015-09-10 23:07 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official"
Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Yes, I know, and I already asked on the ML if we can take that change or if it is not possible because we have already other changes (pharos file plugin provides addition attributes (the file permissions)).
Esteban and I just harmonized this. I'm (almost correctly) generating the plugin source such that one can define either PharoVM or not to chose between the different versions. I say "almost" because I'm currently spitting out
#define PharoVM 0 ... #if PharoVM
instead of
#if !defined(PharoVM) # define PharoVM 0 #endif ... #if PharoVM
but I'll fix it v soon.
OK, I'll try to copy marcels solution
But I got no response, so I tried to adopt Marcels change.
And I only found the change for sqWin32FilePrims.c, but missed the other change that is necessary in sqWin32Directory.c (and asked on the ML). In the meantime Marcel added this but I could not find the changed source, only an updated vm. Is this change already comitted?
Yes, see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32Di...
Ah, good. Now (I must be blind, but) I can not see the other change, shouldn't there be a "plugins" folder in Cog/platforms/win32/? Where are the changes to sqWin32FilePrims.c now?
Ok, found it. It is in the trunk branch :)
I'm sorry I didn't see your message. Did you ask on vm-dev?
I am not sure, maybe I only send it in the squeak-dev list
I would love if someone else got this working.
:-) I hear you :-)
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
2015-09-11 9:44 GMT+02:00 Nicolai Hess nicolaihess@web.de:
2015-09-11 9:43 GMT+02:00 Nicolai Hess nicolaihess@web.de:
2015-09-10 23:07 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the
"official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Yes, I know, and I already asked on the ML if we can take that change or if it is not possible because we have already other changes (pharos file plugin provides addition attributes (the file permissions)).
Esteban and I just harmonized this. I'm (almost correctly) generating the plugin source such that one can define either PharoVM or not to chose between the different versions. I say "almost" because I'm currently spitting out
#define PharoVM 0 ... #if PharoVM
instead of
#if !defined(PharoVM) # define PharoVM 0 #endif ... #if PharoVM
but I'll fix it v soon.
OK, I'll try to copy marcels solution
But I got no response, so I tried to adopt Marcels change.
And I only found the change for sqWin32FilePrims.c, but missed the other change that is necessary in sqWin32Directory.c (and asked on the ML). In the meantime Marcel added this but I could not find the changed source, only an updated vm. Is this change already comitted?
Yes, see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32Di...
Ah, good. Now (I must be blind, but) I can not see the other change, shouldn't there be a "plugins" folder in Cog/platforms/win32/? Where are the changes to sqWin32FilePrims.c now?
Ok, found it. It is in the trunk branch :)
No, wait, now I am confused. The change to sqWin32FilePrims.c is only in the trunk branch and the change to sqWin32Directory.c is only in the Cog branch. What branch includes the solution for both (sqWin32Directory.c and sqWin32FilePrims.c) and should be used for a merge into pharos vm repository?
I'm sorry I didn't see your message. Did you ask on vm-dev?
I am not sure, maybe I only send it in the squeak-dev list
I would love if someone else got this working.
:-) I hear you :-)
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Hi Nicolai,
On Fri, Sep 11, 2015 at 12:48 AM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-11 9:44 GMT+02:00 Nicolai Hess nicolaihess@web.de:
2015-09-11 9:43 GMT+02:00 Nicolai Hess nicolaihess@web.de:
2015-09-10 23:07 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the
"official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Yes, I know, and I already asked on the ML if we can take that change or if it is not possible because we have already other changes (pharos file plugin provides addition attributes (the file permissions)).
Esteban and I just harmonized this. I'm (almost correctly) generating the plugin source such that one can define either PharoVM or not to chose between the different versions. I say "almost" because I'm currently spitting out
#define PharoVM 0 ... #if PharoVM
instead of
#if !defined(PharoVM) # define PharoVM 0 #endif ... #if PharoVM
but I'll fix it v soon.
OK, I'll try to copy marcels solution
But I got no response, so I tried to adopt Marcels change.
And I only found the change for sqWin32FilePrims.c, but missed the other change that is necessary in sqWin32Directory.c (and asked on the ML). In the meantime Marcel added this but I could not find the changed source, only an updated vm. Is this change already comitted?
Yes, see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32Di...
Ah, good. Now (I must be blind, but) I can not see the other change, shouldn't there be a "plugins" folder in Cog/platforms/win32/? Where are the changes to sqWin32FilePrims.c now?
Ok, found it. It is in the trunk branch :)
No, wait, now I am confused. The change to sqWin32FilePrims.c is only in the trunk branch and the change to sqWin32Directory.c is only in the Cog branch. What branch includes the solution for both (sqWin32Directory.c and sqWin32FilePrims.c) and should be used for a merge into pharos vm repository?
There are two "externals" in the Cog branch:
X platforms/win32/plugins X platforms/Cross/plugins
So http://www.squeakvm.org/svn/squeak/branches/Cog is the Cog repository, but
http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/plugins is in fact http://squeakvm.org/svn/squeak/trunk/platforms/win32/plugins
and http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Cross/plugins is in fact http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
OK?
I'm sorry I didn't see your message. Did you ask on vm-dev?
I am not sure, maybe I only send it in the squeak-dev list
I would love if someone else got this working.
:-) I hear you :-)
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
> 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. > > > nicolai > > > >
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official"
Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
github branch: https://github.com/nicolaihess/pharo-vm/tree/harmonize_win_file_plugin I'll create a push request.
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
-- _,,,^..^,,,_ best, Eliot
Thanks Nicolai, that's great! I'll merge in your changes. Which files do I need to look at?
On Sat, Sep 12, 2015 at 8:00 AM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official"
Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
github branch: https://github.com/nicolaihess/pharo-vm/tree/harmonize_win_file_plugin I'll create a push request.
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
-- _,,,^..^,,,_ best, Eliot
2015-09-14 23:10 GMT+02:00 Eliot Miranda eliot.miranda@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.
On Sat, Sep 12, 2015 at 8:00 AM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official"
Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
github branch: https://github.com/nicolaihess/pharo-vm/tree/harmonize_win_file_plugin I'll create a push request.
nicolai
On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess nicolaihess@web.de wrote:
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.
nicolai
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
2015-09-15 9:19 GMT+02:00 Nicolai Hess nicolaihess@web.de:
2015-09-14 23:10 GMT+02:00 Eliot Miranda eliot.miranda@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
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@web.de wrote:
2015-09-15 9:19 GMT+02:00 Nicolai Hess nicolaihess@web.de:
2015-09-14 23:10 GMT+02:00 Eliot Miranda eliot.miranda@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
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
2015-09-15 4:11 GMT+02:00 Ben Coman btc@openinworld.com:
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official"
Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c
and sqWin32FilePrims.c from the official cog source.
I left only pharos additions for the fileattributes (posixpermissions)
this should make it easier to merge which the
squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
I don't know, I don't think we use it at all. And for the different platforms, the permission attributes doesn't really *are the same*. For example, the read/write permissions we are showing for win32 platform, don't have much to do with win32 access restrictions - Idon't know about macos.
Pharo uses them.
Posix permissions are useful for both linux and mac. Windows uses also the posix permissions that came with MinGW… I do not think they are useful but we provide them anyway :)
Esteban
ps: I do not know what are you doing there guys, but you broke my builds (I’m taking a look at them now) :P
On 15 Sep 2015, at 09:24, Nicolai Hess nicolaihess@web.de wrote:
2015-09-15 4:11 GMT+02:00 Ben Coman <btc@openinworld.com mailto:btc@openinworld.com>:
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess <nicolaihess@web.de mailto:nicolaihess@web.de> wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog <http://www.squeakvm.org/svn/squeak/branches/Cog>. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
I don't know, I don't think we use it at all. And for the different platforms, the permission attributes doesn't really *are the same*. For example, the read/write permissions we are showing for win32 platform, don't have much to do with win32 access restrictions - Idon't know about macos.
2015-09-15 11:40 GMT+02:00 Esteban Lorenzano estebanlm@gmail.com:
Pharo uses them.
Posix permissions are useful for both linux and mac. Windows uses also the posix permissions that came with MinGW… I do not think they are useful but we provide them anyway :)
I removed the mingw based permissions (mingws stat/lstat) because they are slow and don't work with longpath names (neither with real multibyte paths).
Esteban
ps: I do not know what are you doing there guys, but you broke my builds (I’m taking a look at them now) :P
improbable, I didn't push the latest code change :)
On 15 Sep 2015, at 09:24, Nicolai Hess nicolaihess@web.de wrote:
2015-09-15 4:11 GMT+02:00 Ben Coman btc@openinworld.com:
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess nicolaihess@web.de wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the
"official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c
and sqWin32FilePrims.c from the official cog source.
I left only pharos additions for the fileattributes (posixpermissions)
this should make it easier to merge which the
squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
I don't know, I don't think we use it at all. And for the different platforms, the permission attributes doesn't really *are the same*. For example, the read/write permissions we are showing for win32 platform, don't have much to do with win32 access restrictions - Idon't know about macos.
On 15 Sep 2015, at 11:44, Nicolai Hess nicolaihess@web.de wrote:
2015-09-15 11:40 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Pharo uses them.
Posix permissions are useful for both linux and mac. Windows uses also the posix permissions that came with MinGW… I do not think they are useful but we provide them anyway :)
I removed the mingw based permissions (mingws stat/lstat) because they are slow and don't work with longpath names (neither with real multibyte paths).
mmm… but something needs to be returned. AFAIK mingw posix at least were answering if ro or rw available… but I’m not sure.
Esteban
ps: I do not know what are you doing there guys, but you broke my builds (I’m taking a look at them now) :P
improbable, I didn't push the latest code change :)
:) some changes in fileplugin were made in the spur branch and that broke the spur builds… but just looking at them now so I don’t know what it is yet.
Esteban
On 15 Sep 2015, at 09:24, Nicolai Hess <nicolaihess@web.de mailto:nicolaihess@web.de> wrote:
2015-09-15 4:11 GMT+02:00 Ben Coman <btc@openinworld.com mailto:btc@openinworld.com>:
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess <nicolaihess@web.de mailto:nicolaihess@web.de> wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog <http://www.squeakvm.org/svn/squeak/branches/Cog>. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
I don't know, I don't think we use it at all. And for the different platforms, the permission attributes doesn't really *are the same*. For example, the read/write permissions we are showing for win32 platform, don't have much to do with win32 access restrictions - Idon't know about macos.
On 15 Sep 2015, at 11:47, Esteban Lorenzano estebanlm@gmail.com wrote:
On 15 Sep 2015, at 11:44, Nicolai Hess <nicolaihess@web.de mailto:nicolaihess@web.de> wrote:
2015-09-15 11:40 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com>:
Pharo uses them.
Posix permissions are useful for both linux and mac. Windows uses also the posix permissions that came with MinGW… I do not think they are useful but we provide them anyway :)
I removed the mingw based permissions (mingws stat/lstat) because they are slow and don't work with longpath names (neither with real multibyte paths).
mmm… but something needs to be returned. AFAIK mingw posix at least were answering if ro or rw available… but I’m not sure.
Esteban
ps: I do not know what are you doing there guys, but you broke my builds (I’m taking a look at them now) :P
improbable, I didn't push the latest code change :)
:) some changes in fileplugin were made in the spur branch and that broke the spur builds… but just looking at them now so I don’t know what it is yet.
just an undef of PharoVM… now I need to define it in compiler arguments.
Esteban
On 15 Sep 2015, at 09:24, Nicolai Hess <nicolaihess@web.de mailto:nicolaihess@web.de> wrote:
2015-09-15 4:11 GMT+02:00 Ben Coman <btc@openinworld.com mailto:btc@openinworld.com>:
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess <nicolaihess@web.de mailto:nicolaihess@web.de> wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog <http://www.squeakvm.org/svn/squeak/branches/Cog>. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
I don't know, I don't think we use it at all. And for the different platforms, the permission attributes doesn't really *are the same*. For example, the read/write permissions we are showing for win32 platform, don't have much to do with win32 access restrictions - Idon't know about macos.
On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote:
Pharo uses them.
Posix permissions are useful for both linux and mac. Windows uses also the posix permissions that came with MinGW??? I do not think they are useful but we provide them anyway :)
Posix permissions are based on Unix, and are very platform specific. The Windows equivalents are semantically different, and other operating systems may exist that are not Unix based at all.
IMO, platform specific functions should go into separate plugins, and not in FilePlugin.
Dave
Esteban
ps: I do not know what are you doing there guys, but you broke my builds (I???m taking a look at them now) :P
On 15 Sep 2015, at 09:24, Nicolai Hess nicolaihess@web.de wrote:
2015-09-15 4:11 GMT+02:00 Ben Coman <btc@openinworld.com mailto:btc@openinworld.com>:
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess <nicolaihess@web.de mailto:nicolaihess@web.de> wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog <http://www.squeakvm.org/svn/squeak/branches/Cog>. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
I don't know, I don't think we use it at all. And for the different platforms, the permission attributes doesn't really *are the same*. For example, the read/write permissions we are showing for win32 platform, don't have much to do with win32 access restrictions - Idon't know about macos.
On 15 Sep 2015, at 14:13, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote:
Pharo uses them.
Posix permissions are useful for both linux and mac. Windows uses also the posix permissions that came with MinGW??? I do not think they are useful but we provide them anyway :)
Posix permissions are based on Unix, and are very platform specific. The Windows equivalents are semantically different, and other operating systems may exist that are not Unix based at all.
IMO, platform specific functions should go into separate plugins, and not in FilePlugin.
well, I disagree :) I do not find this approach practical… because in general, there is no other systems that may exist using other permissions than POSIX. Except Windows, of course, but even for windows, there are compatibility layers that we can use. In the case of the FilePlugin extensions, we choose to stay POSIX because in general, as its been said before, the job of a virtual machine is been virtual: to provide an “abstract machine” common for everything in the image. I’m not saying that this is possible and even desirable in all cases, but it should be something to think about. In that case, we could design a common file permissions different to the one of Windows and different to POSIX, but I think POSIX does the job just fine.
Also, the choice was: POSIX or nothing (because we didn’t have anything before). I would be very happy if we agree in a better solution, and we implement it. But in the mean time, a not perfect solution is better than none.
Esteban
Dave
Esteban
ps: I do not know what are you doing there guys, but you broke my builds (I???m taking a look at them now) :P
On 15 Sep 2015, at 09:24, Nicolai Hess nicolaihess@web.de wrote:
2015-09-15 4:11 GMT+02:00 Ben Coman <btc@openinworld.com mailto:btc@openinworld.com>:
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess <nicolaihess@web.de mailto:nicolaihess@web.de> wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com>:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the "official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c and sqWin32FilePrims.c from the official cog source. I left only pharos additions for the fileattributes (posixpermissions) this should make it easier to merge which the squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
I don't know, I don't think we use it at all. And for the different platforms, the permission attributes doesn't really *are the same*. For example, the read/write permissions we are showing for win32 platform, don't have much to do with win32 access restrictions - Idon't know about macos.
Hi David,
On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 15 Sep 2015, at 14:13, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote:
Pharo uses them.
Posix permissions are useful for both linux and mac. Windows uses also the posix permissions that came with MinGW??? I do
not think they are useful but we provide them anyway :)
Posix permissions are based on Unix, and are very platform specific. The Windows equivalents are semantically different, and other operating
systems
may exist that are not Unix based at all.
IMO, platform specific functions should go into separate plugins, and not in FilePlugin.
well, I disagree :) I do not find this approach practical… because in general, there is no other systems that may exist using other permissions than POSIX. Except Windows, of course, but even for windows, there are compatibility layers that we can use. In the case of the FilePlugin extensions, we choose to stay POSIX because in general, as its been said before, the job of a virtual machine is been virtual: to provide an “abstract machine” common for everything in the image. I’m not saying that this is possible and even desirable in all cases, but it should be something to think about. In that case, we could design a common file permissions different to the one of Windows and different to POSIX, but I think POSIX does the job just fine.
Also, the choice was: POSIX or nothing (because we didn’t have anything before). I would be very happy if we agree in a better solution, and we implement it. But in the mean time, a not perfect solution is better than none.
I agree with Esteban. IMO, the model of files that the FilePlugin provides access to can and should be a superset of facilities. By not supporting facilities such as permissions or symbolic links or active mount-points we hobble our core file functionality and that makes us a very weak scripting platform. Putting these facilities in add-on packages makes configuration more difficult and means that an elegant implementation in the core file classes, with fallbacks for platforms that don't support the concepts, is very difficult.
If we want to support unix-style scripting in Pharo and Squeak (and I think we very much do; there are many areas out there where good scripting is essential) then we need a better File model, and that means not just getting rid of FileDirectory et al, it also means providing the right infrastructure in the FilePlugin, and that means extensions like the one the Pharo VM folks made. Indeed they haven't gone nearly far enough IMO.
Esteban
Dave
Esteban
ps: I do not know what are you doing there guys, but you broke my
builds (I???m taking a look at them now) :P
On 15 Sep 2015, at 09:24, Nicolai Hess nicolaihess@web.de wrote:
2015-09-15 4:11 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:
btc@openinworld.com>>:
On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess <nicolaihess@web.de
mailto:nicolaihess@web.de> wrote:
2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com
mailto:eliot.miranda@gmail.com>:
Hi Nicolai,
I'm a bit concerned that this is creating drift with the
"official" Cog source base at http://www.squeakvm.org/svn/squeak/branches/Cog < http://www.squeakvm.org/svn/squeak/branches/Cog%3E. Long filename support for win32 was recently added by Marcel Taumel in May of this year. Are you tracking that? How can we keep the sources harmonized?
Ok, I removed all of my code again and merged with sqWin32Directory.c
and sqWin32FilePrims.c from the official cog source.
I left only pharos additions for the fileattributes
(posixpermissions) this should make it easier to merge which the
squeak vm main branch (wrapped with pharo vm ifdefs).
What is the purpose of fileattributes? In the interests of further minimising drift, is this useful to Squeak? cheers -ben
I don't know, I don't think we use it at all. And for the different
platforms, the permission attributes
doesn't really *are the same*. For example, the read/write permissions
we are showing for
win32 platform, don't have much to do with win32 access restrictions -
Idon't know about macos.
On Tue, Sep 15, 2015 at 10:45:16AM -0700, Eliot Miranda wrote:
Hi David,
On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 15 Sep 2015, at 14:13, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote:
Pharo uses them.
Posix permissions are useful for both linux and mac. Windows uses also the posix permissions that came with MinGW??? I do
not think they are useful but we provide them anyway :)
Posix permissions are based on Unix, and are very platform specific. The Windows equivalents are semantically different, and other operating
systems
may exist that are not Unix based at all.
IMO, platform specific functions should go into separate plugins, and not in FilePlugin.
well, I disagree :) I do not find this approach practical??? because in general, there is no other systems that may exist using other permissions than POSIX. Except Windows, of course, but even for windows, there are compatibility layers that we can use. In the case of the FilePlugin extensions, we choose to stay POSIX because in general, as its been said before, the job of a virtual machine is been virtual: to provide an ???abstract machine??? common for everything in the image. I???m not saying that this is possible and even desirable in all cases, but it should be something to think about. In that case, we could design a common file permissions different to the one of Windows and different to POSIX, but I think POSIX does the job just fine.
Also, the choice was: POSIX or nothing (because we didn???t have anything before). I would be very happy if we agree in a better solution, and we implement it. But in the mean time, a not perfect solution is better than none.
I agree with Esteban. IMO, the model of files that the FilePlugin provides access to can and should be a superset of facilities. By not supporting facilities such as permissions or symbolic links or active mount-points we hobble our core file functionality and that makes us a very weak scripting platform. Putting these facilities in add-on packages makes configuration more difficult and means that an elegant implementation in the core file classes, with fallbacks for platforms that don't support the concepts, is very difficult.
I do not intend to suggest that these things are not wonderful and good and worthy of being done. What I said is that they should not be put into FilePlugin.
Yes it is more difficult to implement features like this in packages, but with all due respect it's not all *that* terribly hard. And I think the too much work argument does not hold up when we are talking about something like FilePlugin that effectively defines minimal core functionality required to bring up an image on a new platform.
If we want to support unix-style scripting in Pharo and Squeak (and I think we very much do; there are many areas out there where good scripting is essential) then we need a better File model, and that means not just getting rid of FileDirectory et al, it also means providing the right infrastructure in the FilePlugin, and that means extensions like the one the Pharo VM folks made. Indeed they haven't gone nearly far enough IMO.
Again, I am not saying that these things should not be done. Just that with respect to platform-specific features that can only ever work on a Unix based system, allowing these to creep into the feature set of base system does not seem like a very good idea to me. That's all I am saying.
Dave
vm-dev@lists.squeakfoundation.org