[Vm-dev] Fwd: Merging FilesAttributesPlugin

[Eliot Miranda]

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 ;-)


> 
> 
>> 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 ;-)

> 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