Hi, I have been trying to use FFI (the latest on SqueakMap) in 3.9-7067, on Windows 2000, to get a device context, and do stuff with it. It doesn't seem to work like it used to.
Some investigation reveals that everything worked ok up to 7052. For example,
In 7032 - "Win32Window getFocus getDC getHandle" answers an integer
In 7067 - "Win32Window getFocus getDC getHandle" answers a ByteArray()
Inspecting the Win32Window>>#apiGetDC: compiledMethod in 7032 and 7067 reveals this difference... In 7032, literal4 = #Win32Window In 7067, literal4 = #Win32Window->Win32Window
recompiling the method in both images makes no difference.
Also, in 7032 - "Win32Window win32Draw" works correctly, But in 7067 - "Win32Window win32Draw" crashes the VM (both the old, and the new VM)
Have I installed the wrong FFI packages for 3.9? Or is there a problem in FFI? Or maybe there is a problem in the Compiler?
Cheers, Andy
Andrew Tween wrote:
I have been trying to use FFI (the latest on SqueakMap) in 3.9-7067, on Windows 2000, to get a device context, and do stuff with it. It doesn't seem to work like it used to.
I'm seeing the same problems.
Some investigation reveals that everything worked ok up to 7052.
How interesting. Do you know what changed between 7052 and later versions?
Have I installed the wrong FFI packages for 3.9?
No, this is the right place.
Or is there a problem in FFI? Or maybe there is a problem in the Compiler?
That's a good question. I'm not sure right now; I'll have to check 7052 and later to see what the difference exactly is.
Cheers, - Andreas
Please tell us. I cannot check anything right now because I'm travelling.
Stef
On 13 mars 07, at 05:47, Andreas Raab wrote:
Andrew Tween wrote:
I have been trying to use FFI (the latest on SqueakMap) in 3.9-7067, on Windows 2000, to get a device context, and do stuff with it. It doesn't seem to work like it used to.
I'm seeing the same problems.
Some investigation reveals that everything worked ok up to 7052.
How interesting. Do you know what changed between 7052 and later versions?
Have I installed the wrong FFI packages for 3.9?
No, this is the right place.
Or is there a problem in FFI? Or maybe there is a problem in the Compiler?
That's a good question. I'm not sure right now; I'll have to check 7052 and later to see what the difference exactly is.
Cheers,
- Andreas
Hi, ----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, March 13, 2007 4:47 AM Subject: Re: Possible problem with FFI in 3.9-7067 ?
Andrew Tween wrote:
I have been trying to use FFI (the latest on SqueakMap) in 3.9-7067, on
Windows
2000, to get a device context, and do stuff with it. It doesn't seem to work like it used to.
I'm seeing the same problems.
Some investigation reveals that everything worked ok up to 7052.
How interesting. Do you know what changed between 7052 and later versions?
The main difference was that FFI was removed from the image. I have just tried removing FFI from a 7052 image, and then immediately re-loading FFI from SqueakMap into the same 7052 image. Having done so, "Win32Window win32Draw" crashes the VM. The removal code I used is from ScriptLoader-md.296, the same as used when transitioning from 7052 - 7053, and is shown below.... --------- | copies namesOfpackagesToUnload | namesOfpackagesToUnload := #('*FFI*'). copies := MCWorkingCopy allManagers asSortedCollection: [ :a :b | a package name <= b package name ]. (copies select: [:each | namesOfpackagesToUnload anySatisfy: [:ea | ea match: each package name ]]) do: [:z | z unload]. Smalltalk recreateSpecialObjectsArray -----------
So perhaps something isn't being initialised when FFI is installed?
It may be a red-herring but evaluating "Win32HDC compiledSpec" before and after unloading/reloading, gives diffferent results...
Before - Win32HDC compiledSpec a WordArray(100925444) After - Win32HDC compiledSpec a WordArray(65536)
Have I installed the wrong FFI packages for 3.9?
No, this is the right place.
Or is there a problem in FFI? Or maybe there is a problem in the Compiler?
That's a good question. I'm not sure right now; I'll have to check 7052 and later to see what the difference exactly is.
Thanks.
Cheers, Andy
Hi, I have managed to "cure" the problem by doing the following...
After installing FFI in 3.9-7067, file-in the attached method (ExternalType class-initializeStructureTypes.st). Then evaluate,
ExternalType initialize. ExternalStructure compileAllFields.
the "Win32Window win32Draw" example then performs correctly without crashing the VM. Cheers, Andy
----- Original Message ----- From: "Andrew Tween" amtween@hotmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Wednesday, March 14, 2007 8:38 AM Subject: Re: Possible problem with FFI in 3.9-7067 ?
Hi, ----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, March 13, 2007 4:47 AM Subject: Re: Possible problem with FFI in 3.9-7067 ?
Andrew Tween wrote:
I have been trying to use FFI (the latest on SqueakMap) in 3.9-7067, on
Windows
2000, to get a device context, and do stuff with it. It doesn't seem to
work
like it used to.
I'm seeing the same problems.
Some investigation reveals that everything worked ok up to 7052.
How interesting. Do you know what changed between 7052 and later versions?
The main difference was that FFI was removed from the image. I have just tried removing FFI from a 7052 image, and then immediately re-loading FFI from SqueakMap into the same 7052 image. Having done so, "Win32Window win32Draw" crashes the VM. The removal code I used is from ScriptLoader-md.296, the same as used when transitioning from 7052 - 7053, and is shown below....
| copies namesOfpackagesToUnload | namesOfpackagesToUnload := #('*FFI*'). copies := MCWorkingCopy allManagers asSortedCollection: [ :a :b | a package name <= b package name ]. (copies select: [:each | namesOfpackagesToUnload anySatisfy: [:ea | ea match: each package name ]]) do: [:z | z unload]. Smalltalk recreateSpecialObjectsArray
So perhaps something isn't being initialised when FFI is installed?
It may be a red-herring but evaluating "Win32HDC compiledSpec" before and
after
unloading/reloading, gives diffferent results...
Before - Win32HDC compiledSpec a WordArray(100925444) After - Win32HDC compiledSpec a WordArray(65536)
Have I installed the wrong FFI packages for 3.9?
No, this is the right place.
Or is there a problem in FFI? Or maybe there is a problem in the Compiler?
That's a good question. I'm not sure right now; I'll have to check 7052 and later to see what the difference exactly is.
Thanks.
Cheers, Andy
Hi Andy -
Thanks for finding this. I'm still at a loss why this happens (perhaps Monticello gets something wrong in its initialization?) but I have added those two lines to the SqueakMap installer script. This should prevent crashes like you were seeing.
Cheers, - Andreas
Andrew Tween wrote:
Hi, I have managed to "cure" the problem by doing the following...
After installing FFI in 3.9-7067, file-in the attached method (ExternalType class-initializeStructureTypes.st). Then evaluate,
ExternalType initialize. ExternalStructure compileAllFields.the "Win32Window win32Draw" example then performs correctly without crashing the VM. Cheers, Andy
----- Original Message ----- From: "Andrew Tween" amtween@hotmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Wednesday, March 14, 2007 8:38 AM Subject: Re: Possible problem with FFI in 3.9-7067 ?
Hi, ----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, March 13, 2007 4:47 AM Subject: Re: Possible problem with FFI in 3.9-7067 ?
Andrew Tween wrote:
I have been trying to use FFI (the latest on SqueakMap) in 3.9-7067, on
Windows
2000, to get a device context, and do stuff with it. It doesn't seem to
work
like it used to.
I'm seeing the same problems.
Some investigation reveals that everything worked ok up to 7052.
How interesting. Do you know what changed between 7052 and later versions?
The main difference was that FFI was removed from the image. I have just tried removing FFI from a 7052 image, and then immediately re-loading FFI from SqueakMap into the same 7052 image. Having done so, "Win32Window win32Draw" crashes the VM. The removal code I used is from ScriptLoader-md.296, the same as used when transitioning from 7052 - 7053, and is shown below....
| copies namesOfpackagesToUnload | namesOfpackagesToUnload := #('*FFI*'). copies := MCWorkingCopy allManagers asSortedCollection: [ :a :b | a package name <= b package name ]. (copies select: [:each | namesOfpackagesToUnload anySatisfy: [:ea | ea match: each package name ]]) do: [:z | z unload]. Smalltalk recreateSpecialObjectsArray
So perhaps something isn't being initialised when FFI is installed?
It may be a red-herring but evaluating "Win32HDC compiledSpec" before and
after
unloading/reloading, gives diffferent results...
Before - Win32HDC compiledSpec a WordArray(100925444) After - Win32HDC compiledSpec a WordArray(65536)
Have I installed the wrong FFI packages for 3.9?
No, this is the right place.
Or is there a problem in FFI? Or maybe there is a problem in the Compiler?
That's a good question. I'm not sure right now; I'll have to check 7052 and later to see what the difference exactly is.
Thanks.
Cheers, Andy
Hi Andreas, ----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, March 22, 2007 8:25 PM Subject: Re: Possible problem with FFI in 3.9-7067 ?
Hi Andy -
Thanks for finding this. I'm still at a loss why this happens (perhaps Monticello gets something wrong in its initialization?) but I have added those two lines to the SqueakMap installer script. This should prevent crashes like you were seeing.
In case I didn't make it clear in my original post, you will probably also need to include the modified ExternalType class>>#initializeStructureTypes method. The two lines, on their own, didn't fix it.
Cheers, Andy
Andrew Tween wrote:
Thanks for finding this. I'm still at a loss why this happens (perhaps Monticello gets something wrong in its initialization?) but I have added those two lines to the SqueakMap installer script. This should prevent crashes like you were seeing.
In case I didn't make it clear in my original post, you will probably also need to include the modified ExternalType class>>#initializeStructureTypes method. The two lines, on their own, didn't fix it.
Actually, it turned out that this fix was not entirely correct, but it pointed to the problem. It seems as if the initialization of external structures is indeed broken but in a subtly different way - and that calling #compileFields on all the external structures does the right thing once the load is complete. I have updated the installer in the mean time to include that fix, if you could give it a try and let me know if you find any other issues with it I'd appreciate it.
Cheers, - Andreas
Hi Andreas,
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, March 22, 2007 10:32 PM Subject: Re: Possible problem with FFI in 3.9-7067 ?
Andrew Tween wrote:
Thanks for finding this. I'm still at a loss why this happens (perhaps Monticello gets something wrong in its initialization?) but I have added those two lines to the SqueakMap installer script. This should prevent crashes like you were seeing.,
In case I didn't make it clear in my original post, you will probably also
need
to include the modified ExternalType class>>#initializeStructureTypes
method.
The two lines, on their own, didn't fix it.
Actually, it turned out that this fix was not entirely correct, but it pointed to the problem. It seems as if the initialization of external structures is indeed broken but in a subtly different way - and that calling #compileFields on all the external structures does the right thing once the load is complete. I have updated the installer in the mean time to include that fix, if you could give it a try and let me know if you find any other issues with it I'd appreciate it.
Sure. I've just tried installing from SqueakMap, but it is delivering the same install and packages as before. I've cleared my SqueakMap cache, but with the same result. When I browse SqueakMap in a web browser, I don't see any recent updates to FFI. Could you check that it is indeed updated on SqueakMap?
Cheers, Andy
Cheers,
- Andreas
Andrew Tween wrote:
I've just tried installing from SqueakMap, but it is delivering the same install and packages as before. I've cleared my SqueakMap cache, but with the same result. When I browse SqueakMap in a web browser, I don't see any recent updates to FFI. Could you check that it is indeed updated on SqueakMap?
Right. I noticed that too. It seems like SM is too smart for its own good - you cannot update a file on the server, you have to rename it. Ho Hum.
After fixing that, I found that my fix still didn't fix it and your actually looked better and better the longer I stared at it. What convinced me was when I was running through the debugger to see what happens when you don't bootstrap - the structure bit musn't be set or else both the pointer and the non-pointer type look like structs to the FFI (very, very bad).
Adding that fix and pushing an InstallFFI3 script to SqueakMap finally solved it. Thanks for your help tracking this down.
Cheers, - Andreas
Andreas Raab andreas.raab@gmx.de wrote:
Andrew Tween wrote:
I've just tried installing from SqueakMap, but it is delivering the same install and packages as before. I've cleared my SqueakMap cache, but with the same result. When I browse SqueakMap in a web browser, I don't see any recent updates to FFI. Could you check that it is indeed updated on SqueakMap?
Right. I noticed that too. It seems like SM is too smart for its own good - you cannot update a file on the server, you have to rename it. Ho Hum.
Mmmm, yip. Sorry, indeed in that case it should just recalculate the checksum.
regards, Göran
Hi Andreas, ----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, March 23, 2007 3:34 AM Subject: Re: Possible problem with FFI in 3.9-7067 ?
Andrew Tween wrote:
I've just tried installing from SqueakMap, but it is delivering the same
install
and packages as before. I've cleared my SqueakMap cache, but with the same result. When I browse SqueakMap in a web browser, I don't see any recent updates to
FFI.
Could you check that it is indeed updated on SqueakMap?
Right. I noticed that too. It seems like SM is too smart for its own good - you cannot update a file on the server, you have to rename it. Ho Hum.
After fixing that, I found that my fix still didn't fix it and your actually looked better and better the longer I stared at it. What convinced me was when I was running through the debugger to see what happens when you don't bootstrap - the structure bit musn't be set or else both the pointer and the non-pointer type look like structs to the FFI (very, very bad).
Yes. I noticed the same by comparing the contents of the ExternalType.StructTypes class var in 3.8 and 3.9 images.
Adding that fix and pushing an InstallFFI3 script to SqueakMap finally solved it. Thanks for your help tracking this down.
I've installed the new version from SqueakMap, and can confirm it is working. Thanks.
Andy
El 3/12/07 9:56 PM, "Andrew Tween" amtween@hotmail.com escribió:
Hi, I have been trying to use FFI (the latest on SqueakMap) in 3.9-7067, on Windows 2000, to get a device context, and do stuff with it. It doesn't seem to work like it used to.
Some investigation reveals that everything worked ok up to 7052. For example,
In 7032 - "Win32Window getFocus getDC getHandle" answers an integer
In 7067 - "Win32Window getFocus getDC getHandle" answers a ByteArray()
Inspecting the Win32Window>>#apiGetDC: compiledMethod in 7032 and 7067 reveals this difference... In 7032, literal4 = #Win32Window In 7067, literal4 = #Win32Window->Win32Window
recompiling the method in both images makes no difference.
Also, in 7032 - "Win32Window win32Draw" works correctly, But in 7067 - "Win32Window win32Draw" crashes the VM (both the old, and the new VM)
Have I installed the wrong FFI packages for 3.9? Or is there a problem in FFI? Or maybe there is a problem in the Compiler?
Cheers, Andy
3.9 final 7067 don't have FFI . You must load . The version what you should is what I attach and is from Andreas. What remember me need to test in 3.10....
Edgar
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Andrew Tween -
Edgar J. De Cleene -
goran＠krampe.se -
stephane ducasse