Hi Esteban, On Mon, Mar 4, 2019 at 9:09 AM Esteban Lorenzano <esteba...@gmail.com> wrote:
> On 4 Mar 2019, at 16:02, Eliot Miranda <eliot.mira...@gmail.com> wrote: > > Hi Esteban, > > On Mon, Mar 4, 2019 at 4:31 AM Esteban Lorenzano <esteba...@gmail.com> > wrote: > >> Hi, >> >> Mmm… FFIMethodRegistry is reseting the method value to its old value >> because you modified the method but you did not executed it (you simulated >> it, I guess), and FFICalloutAPI updates the registry on method execution. >> Then on image shutdown the methods are reseted to their original value. >> This is usually not an issue, but running with the simulator can cause >> that problem. >> > > It happens with or without the simulator. If I redefine the method and > save, expecting that on startup the new version will be executed, and > startup with the normal VM, the method is reset. Surely this is a bug and > the method should be removed from the FFI registry when it is redefined > with no FFI usage in it. Right? > > > Then indeed, that may be a bug… still, I need to check the best way to fix > it (we need to introduce a check when compiling to reset the ffi method… I > guess with a compiler plugin). > That seems right to me. Only methods containing FFI calls should be in the register. If one redefines such na method to remove its FFI call then it should be removed from the registry. The alternative would be for the reset code to check that it is resetting a method containing an FFI call, and if there is none, not resetting. This might be simpler in the end. > > Esteban > > > >> >> Esteban >> >> On 3 Mar 2019, at 23:03, Eliot Miranda <eliot.mira...@gmail.com> wrote: >> >> Hi All, >> >> I'm trying to debug remaining limitations in Image Segment support >> in Spur using a case provided by Max Leske. This is a pair of Pharo 6 >> images, one of which saves an image segment the other which loads it. Both >> use OSEnvironment>>getEnv: to access environment variables. >> >> The base definition of OSEnvironment>>getEnv: is >> >> !OSEnvironment methodsFor: 'accessing' stamp: 'auto 5/3/2016 10:31'! >> getEnv: arg1 >> "This method calls the Standard C Library getenv() function. The >> name of the argument (arg1) should fit decompiled version." >> ^ self ffiCall: #( String getenv (String arg1) ) module: LibC! ! >> >> but as I'm using the VM Simulator to debug the image segment issues I >> need to avoid the FFI, which isn't yet simulateable. So I redefine >> OSEnvironment>>getEnv: as follows, and then save and exit. >> >> !OSEnvironment methodsFor: 'accessing' stamp: 'EliotMiranda 02/27/2019 >> 17:09'! >> getEnv: aByteStringOrByteArray >> "This method calls the Standard C Library getenv() function. The >> name of the argument (arg1) should fit decompiled version." >> <primitive: 'primitiveGetenv' module: '' error: ec> >> ec == #'bad argument' ifTrue: >> [aByteStringOrByteArray isString ifFalse: >> [^self getEnv: aByteStringOrByteArray asString]]. >> self primitiveFail! ! >> >> But, and here's the weird bit, when I start up the image, the new >> definition has been discarded and replaced by the original. WTF?!?! Why >> is this happening? How can I disable this? >> >> The only way that I've found I am able to save with a new version is by >> doing a Save As... to a new name. This is fine, but I find the current >> behavior extremely unhelpful. Is it a bug? If it is intended, whats the >> rationale? >> _,,,^..^,,,_ >> best, Eliot >> >> >> > > -- > _,,,^..^,,,_ > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot
