[Vm-dev] Fwd: Merging FilesAttributesPlugin

Eliot Miranda eliot.miranda at gmail.com
Sat Dec 23 18:00:45 UTC 2017


Hi Alistair,

On Sat, Dec 23, 2017 at 9:35 AM, Alistair Grant <akgrant0710 at gmail.com>
wrote:

>
> Hi Eliot,
>
> I've made progress:
>
> - Updated FileAttributesPlugin to use #primitiveFailForOSError:.
> - Loaded PrimitiveOSError
> - Updated SmalltalkImage>>newSpecialObjectsArray
> - Run SmalltalkImage current recreateSpecialObjectsArray.
> - And triggered an error which generated the appropriate
> PrimitiveOSError object.
>
> Given I've already made changes, and have a bit more tidying up to do,
> it is probably isn't worthwhile you reviewing the code again until I
> post an updated version.  I'll let you know when it is ready.
>

OK, that's great.  Thanks and have a great holiday!


>
> Merry Christmas!
> Alistair
>
>
>
>
> On 22 December 2017 at 21:08, Alistair Grant <akgrant0710 at gmail.com>
> wrote:
> > 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
> >>
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171223/d601a1e2/attachment-0001.html>


More information about the Vm-dev mailing list