Hi Everyone,
FilePlugin>>primitiveFileStdioHandles is responsible for opening stdio in the VM. The basic behaviour is to call sqFileStdioHandlesInto() which does the actual work and returns a mask indicating which streams were successfully opened (stdin, stdout, stderr).
However primitiveFileStdioHandles regards a mask of 0, i.e. no files available, as a primitive failure:
sHFAfn ~= 0 ifTrue: [(self cCode: ' ((sqInt (*)(void))sHFAfn)()' inSmalltalk: [true]) ifFalse: [^interpreterProxy primitiveFailFor: PrimErrUnsupported]]. self cCode: '' inSmalltalk: [fileRecords := Array new: 3]. validMask := self sqFileStdioHandlesInto: fileRecords. validMask = 0 ifTrue: [^interpreterProxy primitiveFailFor: PrimErrUnsupported].
This doesn't cause a problem in squeak since all primitive errors are handled by simply assuming that the stdio files can't be opened and ignoring any other errors.
Pharo currently raises an unhandled exception.
On Windows not having stdio available is a normal condition, so I think the correct behaviour is for the primitive to succeed, but return an array of 3 nils, i.e. successfully determined that none of the stdio files are available (this is effectively what happens in the Squeak image anyway).
It would then mean that a primitive failure can be treated as something going wrong, rather than the normal (on Windows) situation of no stdio files being available.
The other (minor) benefit is that at the moment there are two situations in which the primitive fails with PrimErrUnsupported: sHFAfn ~= 0 and validMask = 0. This change would make it easier to interpret the failure.
Any objections?
Thanks, Alistair
Hi Alistair,
On Sun, Aug 5, 2018 at 1:02 PM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Everyone,
FilePlugin>>primitiveFileStdioHandles is responsible for opening stdio in the VM. The basic behaviour is to call sqFileStdioHandlesInto() which does the actual work and returns a mask indicating which streams were successfully opened (stdin, stdout, stderr).
However primitiveFileStdioHandles regards a mask of 0, i.e. no files available, as a primitive failure:
sHFAfn ~= 0 ifTrue: [(self cCode: ' ((sqInt (*)(void))sHFAfn)()' inSmalltalk: [true]) ifFalse: [^interpreterProxy primitiveFailFor: PrimErrUnsupported]]. self cCode: '' inSmalltalk: [fileRecords := Array new: 3]. validMask := self sqFileStdioHandlesInto: fileRecords. validMask = 0 ifTrue: [^interpreterProxy primitiveFailFor: PrimErrUnsupported].
This doesn't cause a problem in squeak since all primitive errors are handled by simply assuming that the stdio files can't be opened and ignoring any other errors.
Pharo currently raises an unhandled exception.
On Windows not having stdio available is a normal condition, so I think the correct behaviour is for the primitive to succeed, but return an array of 3 nils, i.e. successfully determined that none of the stdio files are available (this is effectively what happens in the Squeak image anyway).
It would then mean that a primitive failure can be treated as something going wrong, rather than the normal (on Windows) situation of no stdio files being available.
The other (minor) benefit is that at the moment there are two situations in which the primitive fails with PrimErrUnsupported: sHFAfn ~= 0 and validMask = 0. This change would make it easier to interpret the failure.
Any objections?
No, but I think the right thing to do is to fail if sqFileStdioHandlesInto answers a value less than zero. That would;d still allow the subsystem to communicate some serious error, while allowing the system also to report that no streams are available (e.g. when not attached to a console).
BTW, is there any image level source code available for accessing the FileAttributesPlugin's primitives? This is lazy of me, but if there is could you email me a pointer to the code or the code itself asap? TIA
P.S> I'm specifically looking for code to implement testing directory writability in Squeak.
Thanks, Alistair
Hi Eliot,
On Wed, 8 Aug 2018 at 21:31, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair,
On Sun, Aug 5, 2018 at 1:02 PM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Everyone,
FilePlugin>>primitiveFileStdioHandles is responsible for opening stdio in the VM. The basic behaviour is to call sqFileStdioHandlesInto() which does the actual work and returns a mask indicating which streams were successfully opened (stdin, stdout, stderr).
However primitiveFileStdioHandles regards a mask of 0, i.e. no files available, as a primitive failure:
sHFAfn ~= 0 ifTrue: [(self cCode: ' ((sqInt (*)(void))sHFAfn)()' inSmalltalk: [true]) ifFalse: [^interpreterProxy primitiveFailFor: PrimErrUnsupported]]. self cCode: '' inSmalltalk: [fileRecords := Array new: 3]. validMask := self sqFileStdioHandlesInto: fileRecords. validMask = 0 ifTrue: [^interpreterProxy primitiveFailFor: PrimErrUnsupported].
This doesn't cause a problem in squeak since all primitive errors are handled by simply assuming that the stdio files can't be opened and ignoring any other errors.
Pharo currently raises an unhandled exception.
On Windows not having stdio available is a normal condition, so I think the correct behaviour is for the primitive to succeed, but return an array of 3 nils, i.e. successfully determined that none of the stdio files are available (this is effectively what happens in the Squeak image anyway).
It would then mean that a primitive failure can be treated as something going wrong, rather than the normal (on Windows) situation of no stdio files being available.
The other (minor) benefit is that at the moment there are two situations in which the primitive fails with PrimErrUnsupported: sHFAfn ~= 0 and validMask = 0. This change would make it easier to interpret the failure.
Any objections?
No, but I think the right thing to do is to fail if sqFileStdioHandlesInto answers a value less than zero. That would;d still allow the subsystem to communicate some serious error, while allowing the system also to report that no streams are available (e.g. when not attached to a console).
Wouldn't it be better for sqFileStdioHandlesInto to flag the primitive as failing itself as it could then provide a reason, e.g. primitiveFailFor or primitiveFailForOSError? (the platform support file is already doing this in other support routines).
BTW, is there any image level source code available for accessing the FileAttributesPlugin's primitives? This is lazy of me, but if there is could you email me a pointer to the code or the code itself asap? TIA
P.S> I'm specifically looking for code to implement testing directory writability in Squeak.
OK, just a warning in advance: The code (VM and image) works fine on Linux and Windows. I didn't know about the Mac file encoding quirks until recently, so need to change the plugin to work properly on Mac OS. But I haven't got the VM to compile on my Mac virtualbox machine, so the changes are still local to my PC. This won't affect you unless you've got non-ascii characters in your file names. I should have fixed this by now, but the problems compiling on Mac have frustrated me, and I've had very little time (personal reasons).
The main repository for the image side file attributes code is at: https://github.com/akgrant43/pharo/tree/21368-Integrate-FileAttributesPlugin.
If you're not comfortable with git I think figuring out the changes will be difficult. I've got a .cs from a slightly earlier revision which I can email you - probably directly, it's 93Kb.
I'll try and put together a change set which just includes enough code to get file attributes.
Any other questions, of course please let me know.
Cheers, Alistair
Hi Eliot,
On Thu, 9 Aug 2018 at 10:37, Alistair Grant akgrant0710@gmail.com wrote:
BTW, is there any image level source code available for accessing the FileAttributesPlugin's primitives? This is lazy of me, but if there is could you email me a pointer to the code or the code itself asap? TIA
P.S> I'm specifically looking for code to implement testing directory writability in Squeak.
OK, just a warning in advance: The code (VM and image) works fine on Linux and Windows. I didn't know about the Mac file encoding quirks until recently, so need to change the plugin to work properly on Mac OS. But I haven't got the VM to compile on my Mac virtualbox machine, so the changes are still local to my PC. This won't affect you unless you've got non-ascii characters in your file names. I should have fixed this by now, but the problems compiling on Mac have frustrated me, and I've had very little time (personal reasons).
The main repository for the image side file attributes code is at: https://github.com/akgrant43/pharo/tree/21368-Integrate-FileAttributesPlugin.
If you're not comfortable with git I think figuring out the changes will be difficult. I've got a .cs from a slightly earlier revision which I can email you - probably directly, it's 93Kb.
I'll try and put together a change set which just includes enough code to get file attributes.
Any other questions, of course please let me know.
I'll reply to this with a change set that should get you started.
Disclaimer: I've thrown this together in about half an hour and checked that I can get directory permissions. Anything (and probably everything :-)) else could fail.
The squeak VM I have doesn't include the FileAttributesPlugin. To get going I simply copied FileAttributesPlugin.so from my Pharo VM (this is on Ubuntu 16.04 (I know, bad practice, but no time to build a new VM right now)).
Once you've filed in the change set you should be able to:
1. FileAttributesPrimitives fileAttributesVersionString "'1.3.2'"
2. (DiskDirectoryEntry reference: '/bin') isWritable "false"
3. (DiskDirectoryEntry reference: '/home/myhomedir') isWritable "true"
DiskDirectoryEntry normally expects to hold a FileReference in Pharo. I've hacked it enough to accept a string instead.
Sorry for the lack of testing, but wanted to try and get at least something to you. I hope to have some more time tonight to tidy this up if you want, or answer any other questions.
Cheers, Alistair
Hi Eliot,
On Thu, 9 Aug 2018 at 16:15, Alistair Grant akgrant0710@gmail.com wrote:
...
I'll reply to this with a change set that should get you started.
Disclaimer: I've thrown this together in about half an hour and checked that I can get directory permissions. Anything (and probably everything :-)) else could fail.
...
Change set attached (I hope).
Cheers, Alistair
Hi Alistair,
On Thu, Aug 9, 2018 at 1:37 AM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Eliot,
On Wed, 8 Aug 2018 at 21:31, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair,
On Sun, Aug 5, 2018 at 1:02 PM, Alistair Grant akgrant0710@gmail.com
wrote:
Hi Everyone,
FilePlugin>>primitiveFileStdioHandles is responsible for opening stdio in the VM. The basic behaviour is to call sqFileStdioHandlesInto() which does the actual work and returns a mask indicating which streams were successfully opened (stdin, stdout, stderr).
However primitiveFileStdioHandles regards a mask of 0, i.e. no files available, as a primitive failure:
sHFAfn ~= 0 ifTrue: [(self cCode: ' ((sqInt (*)(void))sHFAfn)()' inSmalltalk: [true])
ifFalse:
[^interpreterProxy primitiveFailFor: PrimErrUnsupported]].self cCode: '' inSmalltalk: [fileRecords := Array new: 3]. validMask := self sqFileStdioHandlesInto: fileRecords. validMask = 0 ifTrue: [^interpreterProxy primitiveFailFor: PrimErrUnsupported].
This doesn't cause a problem in squeak since all primitive errors are handled by simply assuming that the stdio files can't be opened and ignoring any other errors.
Pharo currently raises an unhandled exception.
On Windows not having stdio available is a normal condition, so I think the correct behaviour is for the primitive to succeed, but return an array of 3 nils, i.e. successfully determined that none of the stdio files are available (this is effectively what happens in the Squeak image anyway).
It would then mean that a primitive failure can be treated as something going wrong, rather than the normal (on Windows) situation of no stdio files being available.
The other (minor) benefit is that at the moment there are two situations in which the primitive fails with PrimErrUnsupported: sHFAfn ~= 0 and validMask = 0. This change would make it easier to interpret the failure.
Any objections?
No, but I think the right thing to do is to fail if
sqFileStdioHandlesInto answers a value less than zero. That would;d still allow the subsystem to communicate some serious error, while allowing the system also to report that no streams are available (e.g. when not attached to a console).
Wouldn't it be better for sqFileStdioHandlesInto to flag the primitive as failing itself as it could then provide a reason, e.g. primitiveFailFor or primitiveFailForOSError? (the platform support file is already doing this in other support routines).
BTW, is there any image level source code available for accessing the
FileAttributesPlugin's primitives? This is lazy of me, but if there is could you email me a pointer to the code or the code itself asap? TIA
P.S> I'm specifically looking for code to implement testing directory
writability in Squeak.
OK, just a warning in advance: The code (VM and image) works fine on Linux and Windows. I didn't know about the Mac file encoding quirks until recently, so need to change the plugin to work properly on Mac OS. But I haven't got the VM to compile on my Mac virtualbox machine, so the changes are still local to my PC. This won't affect you unless you've got non-ascii characters in your file names. I should have fixed this by now, but the problems compiling on Mac have frustrated me, and I've had very little time (personal reasons).
I develop on the Mac so feel free to email me a change set and tests (e.g. just doit in a workspace) and IO can test for you.
The main repository for the image side file attributes code is at: https://github.com/akgrant43/pharo/tree/21368-Integrate- FileAttributesPlugin.
OK, I'll see if I can grab this wen I have time. Today is taken :-)
If you're not comfortable with git I think figuring out the changes will be difficult. I've got a .cs from a slightly earlier revision which I can email you - probably directly, it's 93Kb.
I'll try and put together a change set which just includes enough code to get file attributes.
I've got myself going. I have the R_OK, W_OK, E_OK accessors in place so don't need source code. I do suggest however that primitiveFileAttribute would be nicer to use if it took its arguments in reverse order. i.e.
attribute: attributeNumber forPath: path
is less clumsy than
attributeForPath: path numbered: attributeNumber
Any other questions, of course please let me know.
Cheers, Alistair
_,,,^..^,,,_ best, Eliot
2018-08-09 17:34 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Alistair,
On Thu, Aug 9, 2018 at 1:37 AM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Eliot,
On Wed, 8 Aug 2018 at 21:31, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair,
On Sun, Aug 5, 2018 at 1:02 PM, Alistair Grant akgrant0710@gmail.com
wrote:
Hi Everyone,
FilePlugin>>primitiveFileStdioHandles is responsible for opening stdio in the VM. The basic behaviour is to call sqFileStdioHandlesInto() which does the actual work and returns a mask indicating which streams were successfully opened (stdin, stdout, stderr).
However primitiveFileStdioHandles regards a mask of 0, i.e. no files available, as a primitive failure:
sHFAfn ~= 0 ifTrue: [(self cCode: ' ((sqInt (*)(void))sHFAfn)()' inSmalltalk: [true])
ifFalse:
[^interpreterProxy primitiveFailFor: PrimErrUnsupported]].self cCode: '' inSmalltalk: [fileRecords := Array new: 3]. validMask := self sqFileStdioHandlesInto: fileRecords. validMask = 0 ifTrue: [^interpreterProxy primitiveFailFor: PrimErrUnsupported].
This doesn't cause a problem in squeak since all primitive errors are handled by simply assuming that the stdio files can't be opened and ignoring any other errors.
Pharo currently raises an unhandled exception.
On Windows not having stdio available is a normal condition, so I think the correct behaviour is for the primitive to succeed, but return an array of 3 nils, i.e. successfully determined that none of
the
stdio files are available (this is effectively what happens in the Squeak image anyway).
It would then mean that a primitive failure can be treated as something going wrong, rather than the normal (on Windows) situation of no stdio files being available.
The other (minor) benefit is that at the moment there are two
situations
in which the primitive fails with PrimErrUnsupported: sHFAfn ~= 0 and validMask = 0. This change would make it easier to interpret the failure.
Any objections?
No, but I think the right thing to do is to fail if
sqFileStdioHandlesInto answers a value less than zero. That would;d still allow the subsystem to communicate some serious error, while allowing the system also to report that no streams are available (e.g. when not attached to a console).
Wouldn't it be better for sqFileStdioHandlesInto to flag the primitive as failing itself as it could then provide a reason, e.g. primitiveFailFor or primitiveFailForOSError? (the platform support file is already doing this in other support routines).
BTW, is there any image level source code available for accessing the
FileAttributesPlugin's primitives? This is lazy of me, but if there is could you email me a pointer to the code or the code itself asap? TIA
P.S> I'm specifically looking for code to implement testing directory
writability in Squeak.
OK, just a warning in advance: The code (VM and image) works fine on Linux and Windows. I didn't know about the Mac file encoding quirks until recently, so need to change the plugin to work properly on Mac OS. But I haven't got the VM to compile on my Mac virtualbox machine, so the changes are still local to my PC. This won't affect you unless you've got non-ascii characters in your file names. I should have fixed this by now, but the problems compiling on Mac have frustrated me, and I've had very little time (personal reasons).
I develop on the Mac so feel free to email me a change set and tests (e.g. just doit in a workspace) and IO can test for you.
The main repository for the image side file attributes code is at: https://github.com/akgrant43/pharo/tree/21368-Integrate-File AttributesPlugin.
OK, I'll see if I can grab this wen I have time. Today is taken :-)
If you're not comfortable with git I think figuring out the changes will be difficult. I've got a .cs from a slightly earlier revision which I can email you - probably directly, it's 93Kb.
I'll try and put together a change set which just includes enough code to get file attributes.
I've got myself going. I have the R_OK, W_OK, E_OK accessors in place so don't need source code. I do suggest however that primitiveFileAttribute would be nicer to use if it took its arguments in reverse order. i.e.
attribute: attributeNumber forPath: pathis less clumsy than
attributeForPath: path numbered: attributeNumber
It can be with more traditional #at:
attributeForPath: path at: attributeNumber
Any other questions, of course please let me know.
Cheers, Alistair
_,,,^..^,,,_ best, Eliot
Hi Denis,
On Aug 9, 2018, at 1:18 PM, Denis Kudriashov dionisiydk@gmail.com wrote:
2018-08-09 17:34 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Alistair,
On Thu, Aug 9, 2018 at 1:37 AM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Eliot,
On Wed, 8 Aug 2018 at 21:31, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair,
On Sun, Aug 5, 2018 at 1:02 PM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Everyone,
FilePlugin>>primitiveFileStdioHandles is responsible for opening stdio in the VM. The basic behaviour is to call sqFileStdioHandlesInto() which does the actual work and returns a mask indicating which streams were successfully opened (stdin, stdout, stderr).
However primitiveFileStdioHandles regards a mask of 0, i.e. no files available, as a primitive failure:
sHFAfn ~= 0 ifTrue: [(self cCode: ' ((sqInt (*)(void))sHFAfn)()' inSmalltalk: [true]) ifFalse: [^interpreterProxy primitiveFailFor: PrimErrUnsupported]]. self cCode: '' inSmalltalk: [fileRecords := Array new: 3]. validMask := self sqFileStdioHandlesInto: fileRecords. validMask = 0 ifTrue: [^interpreterProxy primitiveFailFor: PrimErrUnsupported].
This doesn't cause a problem in squeak since all primitive errors are handled by simply assuming that the stdio files can't be opened and ignoring any other errors.
Pharo currently raises an unhandled exception.
On Windows not having stdio available is a normal condition, so I think the correct behaviour is for the primitive to succeed, but return an array of 3 nils, i.e. successfully determined that none of the stdio files are available (this is effectively what happens in the Squeak image anyway).
It would then mean that a primitive failure can be treated as something going wrong, rather than the normal (on Windows) situation of no stdio files being available.
The other (minor) benefit is that at the moment there are two situations in which the primitive fails with PrimErrUnsupported: sHFAfn ~= 0 and validMask = 0. This change would make it easier to interpret the failure.
Any objections?
No, but I think the right thing to do is to fail if sqFileStdioHandlesInto answers a value less than zero. That would;d still allow the subsystem to communicate some serious error, while allowing the system also to report that no streams are available (e.g. when not attached to a console).
Wouldn't it be better for sqFileStdioHandlesInto to flag the primitive as failing itself as it could then provide a reason, e.g. primitiveFailFor or primitiveFailForOSError? (the platform support file is already doing this in other support routines).
BTW, is there any image level source code available for accessing the FileAttributesPlugin's primitives? This is lazy of me, but if there is could you email me a pointer to the code or the code itself asap? TIA
P.S> I'm specifically looking for code to implement testing directory writability in Squeak.
OK, just a warning in advance: The code (VM and image) works fine on Linux and Windows. I didn't know about the Mac file encoding quirks until recently, so need to change the plugin to work properly on Mac OS. But I haven't got the VM to compile on my Mac virtualbox machine, so the changes are still local to my PC. This won't affect you unless you've got non-ascii characters in your file names. I should have fixed this by now, but the problems compiling on Mac have frustrated me, and I've had very little time (personal reasons).
I develop on the Mac so feel free to email me a change set and tests (e.g. just doit in a workspace) and IO can test for you.
The main repository for the image side file attributes code is at: https://github.com/akgrant43/pharo/tree/21368-Integrate-FileAttributesPlugin.
OK, I'll see if I can grab this wen I have time. Today is taken :-)
If you're not comfortable with git I think figuring out the changes will be difficult. I've got a .cs from a slightly earlier revision which I can email you - probably directly, it's 93Kb.
I'll try and put together a change set which just includes enough code to get file attributes.
I've got myself going. I have the R_OK, W_OK, E_OK accessors in place so don't need source code. I do suggest however that primitiveFileAttribute would be nicer to use if it took its arguments in reverse order. i.e.
attribute: attributeNumber forPath: pathis less clumsy than
attributeForPath: path numbered: attributeNumberIt can be with more traditional #at:
attributeForPath: path at: attributeNumber
Let’s analyze:
attribute: attributeNumber forPath: path has three words in the selector: attribute for Path six words in the message pattern attribute attribute Number for Path path which could be five and read just as well: attribute n for Path path
attributeForPath: path at: attributeNumber has four words in the selector: attribute For Path at seven words in the message pattern attribute For Path path at attribute Number which could be six and read just as well attribute For path at attribute Number
So putting the path first forces the selector and the message pattern to be longer. It is clumsy.
Any other questions, of course please let me know.
Cheers, Alistair
_,,,^..^,,,_ best, Eliot
Hi Eliot,
On Thu, Aug 09, 2018 at 09:34:21AM -0700, Eliot Miranda wrote:
Hi Alistair,
I've got myself going. I have the R_OK, W_OK, E_OK accessors in place so don't need source code. I do suggest however that primitiveFileAttribute would be nicer to use if it took its arguments in reverse order. i.e.
attribute: attributeNumber forPath: pathis less clumsy than
attributeForPath: path numbered: attributeNumber
I've written this as:
fileAttribute: aString number: attributeNumber
I tend to put the main object first in the parameter list as it helps me mentally by setting the context, in this case it is the file that we are operating on.
It could be:
file: path attributeNumber: anInteger
Which matches the complexity from your reply to Denis (three words in the selector, six words in the message pattern (although one is "an").
I would actually prefer:
file: pathString attributeNumber: anInteger
because Pharo has a Path object, which isn't allowed here, it must be a string.
Do you still feel strongly about swapping the argument order?
Cheers, Alistair
vm-dev@lists.squeakfoundation.org
-
Alistair Grant -
Denis Kudriashov -
Eliot Miranda