> 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 > <mailto: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). Esteban > > > Esteban > >> On 3 Mar 2019, at 23:03, Eliot Miranda <eliot.mira...@gmail.com >> <mailto: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
