[Vm-dev] Fwd: Merging FilesAttributesPlugin

Fri Dec 22 20:08:09 UTC 2017

Hi Eliot,

Thanks!  I'd figured out the slang changes, I'll start work on the
Smalltalk code changes after I've fixed my vm build system.

Cheers,
Alistair

On 22 December 2017 at 20:59, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Alistair,  Hi Clément,
>
>   here are the code and an example of the new operating system error primitive fail facility.
>
> Here's the extract from recreateSpecialObjectsArray that adds the prototype to the table:
>
> newArray at: 52 put: #(nil "nil => generic error" #'bad receiver'
> #'bad argument' #'bad index'
> #'bad number of arguments'
> #'inappropriate operation'  #'unsupported operation'
> #'no modification' #'insufficient object memory'
> #'insufficient C memory' #'not found' #'bad method'
> #'internal error in named primitive machinery'
> #'object may move' #'resource limit exceeded'
> #'object is pinned' #'primitive write beyond end of object'
> #'object moved' #'object not pinned' #'callback error'),
> {PrimitiveOSError new errorName: #'operating system error'; yourself}.
>
> Here's the class definition (also attached) for PrimitiveOSError:
>
> !Object methodsFor: '*System-Support-error handling' stamp: 'eem 12/12/2017 09:16'!
> isPrimitiveOSError
> ^false! !
>
> Object subclass: #PrimitiveOSError
> instanceVariableNames: 'errorName errorCode'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'System-Support'!
> !PrimitiveOSError commentStamp: 'eem 12/7/2017 19:31' prior: 0!
> A PrimitiveOSError is used to answer a primitive failure code that has an associated operating system/library error.
>
> Instance Variables
> errorName: <Symbol>
> errorValue: <Integer>
>
> errorName
> - typically #'operating system error'
>
> errorValue
> - the value of the error, a signed 64-bit value, a representation imposed by the VM; specific clients must map this error value into an unsigned value as appropriate if required!
>
>
> !PrimitiveOSError methodsFor: 'accessing' stamp: 'eem 12/7/2017 19:32'!
> errorCode
> ^errorCode! !
>
> !PrimitiveOSError methodsFor: 'accessing' stamp: 'eem 12/7/2017 19:32'!
> errorCode: anObject
> errorCode := anObject! !
>
> !PrimitiveOSError methodsFor: 'accessing' stamp: 'eem 12/7/2017 18:16'!
> errorName
> ^errorName! !
>
> !PrimitiveOSError methodsFor: 'accessing' stamp: 'eem 12/7/2017 18:16'!
> errorName: anObject
> errorName := anObject! !
>
>
> !PrimitiveOSError methodsFor: 'testing' stamp: 'eem 12/12/2017 09:15'!
> isPrimitiveOSError
> ^true! !
>
>
> The signature of primitiveFailForOSError: is:
> sqInt primitiveFailForOSError(sqLong)
>
> So in your Slang code use
>
>     interpreterProxy primitiveFailForOSError: osErrorCode
>
> or in your platform C code use
>
>
>     interpreterProxy->primitiveFailForOSError(osErrorCode)
>
> In your Smalltalk code write things like
>
>      <primitive: 'foo' module: '' error: ec>
>      ec isOSErrorCode ifTrue:
>          [self processError: ec errorCode]
>
>
>
>
> On Fri, Dec 22, 2017 at 9:11 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
>>
>>
>> Hi Eliot,
>>
>> On 22 December 2017 at 18:00, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >
>> > Hi Alistair,
>> >
>> >
>> >> On Dec 22, 2017, at 8:33 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
>> >>
>> >>
>> >> Hi Eliot,
>> >>
>> >>> On 22 December 2017 at 17:09, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >>>
>> >>> Hi Clément, Hi Alistair,
>> >>>
>> >>>    FileAttrbutesPlugin is not yet ready for use.  The main problem is that it neither fails properly nor communicates error codes back properly.  Basically FileAttrbutesPlugin confuses failing because it gets invalid arguments with reporting error codes due to operating system level errors.  For the FileAttrbutesPlugin's primitives to work in Spur they must fail in the traditional way when given invalid arguments.  This is because the Spur VM will check when a primitive fails if there are any forwarders in the primitive's parameters, and if so, follow (fix up) the forwarders and retry the primitive.
>> >>
>> >> Is this the feedback you gave me on 2 September, or something different?
>> >
>> > One and the same.
>> >
>> >>
>> >> Back then, you wrote:
>> >>> The change that is required to error handling:
>> >>> If a primitive fails due to argument marshaling it must use the primitiveFailedWith: mechanism and report the error using one of the error codes.  This is because Spur uses lazy forwarding to implement become:, pin, et al.  The lazy forwarding mechanism follows forwarders in the VM when they are encountered.  For sends this is trivial; any send to a forwarder fails and so the failure side of message lookup follows forwarders and retries the send.  Similarly for the arguments of primitives, when a primitive fails the VM searches for forwarders in the receiver and arguments to a specific pre-computed depth, following any forwarders it finds.  If any forwarders are found the primitive is retried after following all the forwarders found.
>> >>
>> >>
>> >> My understanding is that this has already been done.  If I've
>> >> misunderstood, my apologies.
>> >
>> > I should apologize.  One side effect of answering email in my phone is that I don't look things up as often as I should (blush).  But answering email in bed in the early morning while the kids are still asleep is irresistible.  Anyway, good.  I shall try and review the code this weekend or early next week.  Feel free to nag me.  Feel free to use harsh language ;-)
>>
>> No problem.    The email subject where I run over the mods is "Re:
>> 20294 Add FileAttributesPlugin to the linux 32 bit VM", sent 6 Sep
>> 2017.
>>
>>
>>
>> >>> Next, communication no os errors back through the primitives results is acceptable, but a better way would be to use the new #'operating system error' primitive failure code mechanism.  Here, provided a suitable two slot prototype is installed in the primitiveErrorTable (see Squeak trunk) then a plugin can do
>> >>>        interpreterProxy primitiveFailForOSError(signedSixtyFourBitErrorCode)
>> >>> and the VM will clone the error object whose first slot should be #'operating system error' and whose second slot will be the code.
>> >>>
>> >>> This gives us a clean way of communicating errors back to a primitive's method body in the traditional way.
>> >>
>> >> At the moment I'm passing back an error number generated by the
>> >> plugin, not an OS error number returned by a system call, but I assume
>> >> that the VM doesn't really care.
>> >>
>> >> Do you have an example where this is being used in a plugin?
>> >
>> > Not yet.  This is new.  Monty wanted if god the FilePlugin and we really needed it.  I'll prepare a proper email with examples of usage and a class def for the error prototype soon.  Again, harsh language may be effective ;-)
>>
>> OK.  I'll have a look, but the examples will be good.
>>
>> Thanks,
>> Alistair
>>
>>
>>
>> >> Cheers,
>> >> Alistair
>> >
>> > Cheers!
>> >
>> >>
>> >>
>> >>> I do apologize if I hadn't made this clear earlier.  But AFAIA there is significant work to do before the plugin is ready for integration.
>> >>>
>> >>> _,,,^..^,,,_ (phone)
>> >>>
>> >>>> On Dec 22, 2017, at 2:48 AM, Alistair Grant <akgrant0710 at gmail.com> wrote:
>> >>>>
>> >>>>
>> >>>> Hi Clément,
>> >>>>
>> >>>>> On 22 December 2017 at 11:29, Clément Bera <bera.clement at gmail.com> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> What is the status of the FilesAttributesPlugin ?
>> >>>>
>> >>>> I'm hoping that it will be integrated soon.
>> >>>>
>> >>>>
>> >>>>> I would like to make it available by default on pharo VMs.
>> >>>>
>> >>>> Yes, please. :-)
>> >>>>
>> >>>>
>> >>>>> Questions:
>> >>>>>
>> >>>>> 1) Is it already merged with another plugin ?
>> >>>>
>> >>>> I'm not sure that I understand the question.  FileAttributesPlugin
>> >>>> works along side FilePlugin (which is obviously already part of the
>> >>>> pharo VM).
>> >>>>
>> >>>>
>> >>>>> 2) If not, for integration, should I move the FilesAttributesPlugin from its external smalltalkhub repository to VMMaker-Plugins package ?
>> >>>>
>> >>>> That's my guess, but someone knowledgable needs to answer this.
>> >>>>
>> >>>>
>> >>>>> 3) What is the right way to generate a plugin ? I use this:
>> >>>>>
>> >>>>> (VMMaker
>> >>>>> makerFor: StackInterpreter
>> >>>>> and: nil
>> >>>>> with: #()
>> >>>>> to: (FileDirectory default pathFromURI: '../src')
>> >>>>> platformDir: (FileDirectory default pathFromURI: '../platforms')
>> >>>>> including: #(FileAttributesPlugin)
>> >>>>> ) generateExternalPlugin: FileAttributesPlugin
>> >>>>>
>> >>>>> Is that correct ?
>> >>>>> It seems it generates only the C file but no header file.
>> >>>>
>> >>>> There isn't a FileAttributesPlugin.h.  It does need the platform support file:
>> >>>>
>> >>>> platforms/win32/plugins/FileAttributesPlugin/Makefile.plugin
>> >>>>
>> >>>> which is already part of opensmalltalk-vm.
>> >>>>
>> >>>> I've always used VMMakerTool to make the plugin, but if it's
>> >>>> generating the .c file it's probably correct.
>> >>>>
>> >>>>
>> >>>> My plan was that once the plugin was added to VMMaker-Plugins that I
>> >>>> would test it again on linux and windows, and then ask for the
>> >>>> appropriate plugins.int to be updated.
>> >>>>
>> >>>>
>> >>>> Thanks!
>> >>>> Alistair
>> >>>>
>> >>>>
>> >>>>> Thanks,
>> >>>>>
>> >>>>> --
>> >>>>> Clément Béra
>> >>>>> https://clementbera.wordpress.com/
>> >>>>> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>