[Pharo-project] No GUI on MacOSX 10.5.8 using Cocoa VM
I use Pharo-1.4 using the VM's from http://www.mirandabanda.org/files/Cog/VM/ Now I want to use Zodiac, so I need the SSL plugin. The SSL plugin is pre-built in the VM's from https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/ But, when I run with this CogVM, I get only a blank window (on MacOSX 10.5.8). When I compared the two executables using "otool -L" it looks like, from the shared library list, that Eliot's VM is Carbon based, and the "Pharo" VM is Cocoa based. Even though I could only see a blank window, the CPU usage seemed to be normal (3-5%), so I decided to try accessing the Seaside app that was already running in the image, and found that it was working fine. Since I had RFB/VNC loaded, I could enable it, and connect to the image via a VNC viewer. It seems that the image is running in "headless" mode. I tried older Pharo images, as well as newer/older Pharo CogVM's, and got the same blank window. I added some code the the VNCController app to get the remote UI to work. The code was: self uiProcess isNil ifTrue: [ UIManager default: MorphicUIManager new ] Even though there's now a MorphicUIManager set, the window is still blank. So any ideas? Does the VM fall back to headless mode when it cannot init the graphics on my older MacOS? Does the MorphicUIManager need to be set in the startup code, else it's too late? -- Yanni
On 25 September 2012 17:33, Yanni Chiu <yanni@rogers.com> wrote:
I use Pharo-1.4 using the VM's from http://www.mirandabanda.org/files/Cog/VM/
Now I want to use Zodiac, so I need the SSL plugin. The SSL plugin is pre-built in the VM's from
https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/
But, when I run with this CogVM, I get only a blank window (on MacOSX 10.5.8). When I compared the two executables using "otool -L" it looks like, from the shared library list, that Eliot's VM is Carbon based, and the "Pharo" VM is Cocoa based.
I'm not sure what happen. Could be that two VMs have some incompatibility. Usually copying plugins should work. Except that yes, Carbon/Coocan mix and match.. this can have some side effects.
Even though I could only see a blank window, the CPU usage seemed to be normal (3-5%), so I decided to try accessing the Seaside app that was already running in the image, and found that it was working fine. Since I had RFB/VNC loaded, I could enable it, and connect to the image via a VNC viewer.
It seems that the image is running in "headless" mode. I tried older Pharo images, as well as newer/older Pharo CogVM's, and got the same blank window.
I added some code the the VNCController app to get the remote UI to work. The code was: self uiProcess isNil ifTrue: [ UIManager default: MorphicUIManager new ]
Even though there's now a MorphicUIManager set, the window is still blank.
So any ideas?
Does the VM fall back to headless mode when it cannot init the graphics on my older MacOS?
Does the MorphicUIManager need to be set in the startup code, else it's too late?
I don't understand, is this happen only if you "copy" plugin from one VM to another?
-- Yanni
-- Best regards, Igor Stasenko.
On 25/09/12 5:49 PM, Igor Stasenko wrote:
I don't understand, is this happen only if you "copy" plugin from one VM to another?
I use the VM's as built. A long time ago I tried to "copy" plugins from one place to another, but I could never get it to work (on MacOSX) - so, in my mind that has never been an approach to try anymore. I'll try copying the Inria-built SSL plugin to the Eliot-built VM, and see what happens.
[re-sending since gmane may have swallowed it] On 25/09/12 5:49 PM, Igor Stasenko wrote:
I don't understand, is this happen only if you "copy" plugin from one VM to another?
I use the VM's as built. A long time ago I tried to "copy" plugins from one place to another, but I could never get it to work (on MacOSX) - so, in my mind that has never been an approach to try anymore. I'll try copying the Inria-built SSL plugin to the Eliot-built VM, and see what happens. [Update - I looked at the directory structure of the Cocoa vs Carbon apps, and decided to try to build the VM instead of trying to splice in a plugin. It doesn't seem to be just a simple .so file to be copied.]
On 25/09/12 11:33 AM, Yanni Chiu wrote:
So any ideas?
I tried to build the CogVM. - search for build instructions, blog post, etc. - almost give up in frustration before discovering the process noted below :) - download the tar ball from: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/ - find and install cmake - already had a C compiler installed - the HOWTOBUILD file said: cd build cmake . make - the build path is hard coded so: % mkdir -p Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/ % mv ~/src Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog # where ~/src is the un-tar'ed tar ball from above - run cmake and make again (sometimes had to remove CMakeCache.txt file) - build fails at: ==== [ 77%] Building CXX object CMakeFiles/CogVM.dir/Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m.o In file included from /Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m:44: /Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/OSX/SqueakOSXAppDelegate.h:46: error: cannot find protocol declaration for âNSApplicationDelegateâ make[2]: *** [CMakeFiles/CogVM.dir/Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m.o] Error 1 make[1]: *** [CMakeFiles/CogVM.dir/all] Error 2 make: *** [all] Error 2 ==== - the culprit is the line: @interface SqueakOSXAppDelegate : sqSqueakAppDelegate <NSApplicationDelegate> - web search for NSApplicationDelegate - find Apple dev page that says: NSApplicationDelegate - Available in OS X v10.6 and later. So, is there an important reason to use NSApplicationDelegate? IIUC, it results in the VM requiring OSX 10.6 or higher, which means my 10.5.8 will never work with CogVM's built this way.
On 26 September 2012 05:13, Yanni Chiu <yanni@rogers.com> wrote:
On 25/09/12 11:33 AM, Yanni Chiu wrote:
So any ideas?
I tried to build the CogVM. - search for build instructions, blog post, etc. - almost give up in frustration before discovering the process noted below :) - download the tar ball from:
https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/ - find and install cmake - already had a C compiler installed - the HOWTOBUILD file said: cd build cmake . make - the build path is hard coded so:
yes, this is an unavoidable outcome of being able to specify custom paths by developer for sources/build directories.. they are written into directories.cmake file. Initially all paths there was relative, but since user can specify own (absolute) custom paths, there is no way how it can keep working using relative paths. You can edit this file, or you can just run an image placed in ./image subdirectory and rerun cmake files generation on you machine, so paths will be fixed automagically.
% mkdir -p Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/ % mv ~/src Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog # where ~/src is the un-tar'ed tar ball from above - run cmake and make again (sometimes had to remove CMakeCache.txt file) - build fails at: ==== [ 77%] Building CXX object CMakeFiles/CogVM.dir/Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m.o In file included from /Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m:44: /Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/OSX/SqueakOSXAppDelegate.h:46: error: cannot find protocol declaration for âNSApplicationDelegateâ make[2]: *** [CMakeFiles/CogVM.dir/Users/hudson/jenkins/workspace/Cog-VM/Architecture/32/OS/mac/cog/platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m.o] Error 1 make[1]: *** [CMakeFiles/CogVM.dir/all] Error 2 make: *** [all] Error 2 ==== - the culprit is the line: @interface SqueakOSXAppDelegate : sqSqueakAppDelegate <NSApplicationDelegate> - web search for NSApplicationDelegate - find Apple dev page that says: NSApplicationDelegate - Available in OS X v10.6 and later.
So, is there an important reason to use NSApplicationDelegate? IIUC, it results in the VM requiring OSX 10.6 or higher, which means my 10.5.8 will never work with CogVM's built this way.
is there a reason why you cannot upgrade your OS? -- Best regards, Igor Stasenko.
On 26/09/12 6:03 AM, Igor Stasenko wrote:
- the culprit is the line: @interface SqueakOSXAppDelegate : sqSqueakAppDelegate <NSApplicationDelegate> - web search for NSApplicationDelegate - find Apple dev page that says: NSApplicationDelegate - Available in OS X v10.6 and later.
is there a reason why you cannot upgrade your OS?
No reason other than it used to happen automatically when I got a new machine. That hasn't happened yet. I'll try a bit more to get it to work on 10.5.8, now that I can build a VM.
On 26/09/12 11:07 AM, Yanni Chiu wrote:
I'll try a bit more to get it to work on 10.5.8, now that I can build a VM.
Okay, got it to work! Three changes: 1. SqueakOSXAppDelegate.h - use NSObject instead ofNSApplicationDelegate 2. sqSqueakOSXScreenAndWindow.h - use NSObject instead of NSWindowDelegate 3. SqueakOSXAppDelegate.m - use CoreGraphics instead of OpenGL //#ifndef USE_CORE_GRAPHICS //# import "sqSqueakOSXOpenGLView.h" //# define ContentViewClass sqSqueakOSXOpenGLView //#else # import "sqSqueakOSXCGView.h" # define ContentViewClass sqSqueakOSXCGView //#endif ==== Along the way, I found: Issue 5650: OneClick 1.4 can't be launched on MacOSX Mac Air 10.5.8 http://code.google.com/p/pharo/issues/detail?id=5650 While I agree that support for old OS releases should have a reasonable limit, I don't buy 10.5 dropped when 10.8 is around the corner is the right limit. My machine is circa 2009, just three years or so. Apple may have good reason to want to move the user/developer base off of 10.5, because of hardware (pad/phone) and UI native widget changes. In the Squeak/Pharo case, we just need a single window to draw in - that should hardly obsolete a three year old computer. I'll add this thread to the issue report (5650).
Hi yanni it may be worth to create a config and publish it on the github repository. Esteban is on vacation right now but may be we read the mailing-list. Now I do not know how specific version are managed. I can simply tell you that esteban is often losing days fighting with flags. Stef
I'll try a bit more to get it to work on 10.5.8, now that I can build a VM.
Okay, got it to work!
Three changes:
1. SqueakOSXAppDelegate.h - use NSObject instead ofNSApplicationDelegate
2. sqSqueakOSXScreenAndWindow.h - use NSObject instead of NSWindowDelegate
3. SqueakOSXAppDelegate.m - use CoreGraphics instead of OpenGL
//#ifndef USE_CORE_GRAPHICS //# import "sqSqueakOSXOpenGLView.h" //# define ContentViewClass sqSqueakOSXOpenGLView //#else # import "sqSqueakOSXCGView.h" # define ContentViewClass sqSqueakOSXCGView //#endif
====
Along the way, I found:
Issue 5650: OneClick 1.4 can't be launched on MacOSX Mac Air 10.5.8 http://code.google.com/p/pharo/issues/detail?id=5650
While I agree that support for old OS releases should have a reasonable limit, I don't buy 10.5 dropped when 10.8 is around the corner is the right limit. My machine is circa 2009, just three years or so. Apple may have good reason to want to move the user/developer base off of 10.5, because of hardware (pad/phone) and UI native widget changes. In the Squeak/Pharo case, we just need a single window to draw in - that should hardly obsolete a three year old computer.
I'll add this thread to the issue report (5650).
participants (3)
-
Igor Stasenko -
Stéphane Ducasse -
Yanni Chiu