I could use some pointers on the status of McCLIM on the Mac. In particular, I am interested in how to run against the native graphics system rather than having to run the X11 server.
I have looked a bit on the beagle backend but I cannot get it to work. A few fixes is needed just to get it to compile. Once that is done, it does compile and load but once an application (such as the calculator demo) is started, the lisp process freezes with output to the effect of:
? 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failure in -[NSWindowGraphicsContext reenableDisplayPosting], GraphicsContext.subproj/NSWindowGraphicsContext.m:117 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failure in -[NSViewHierarchyLock unlockTopMostReader], AppKit.subproj/NSViewHierarchyLock.m:444 2007-04-22 20:07:30.710 dppccl[2492] Error in event loop: Objective-C runtime exception: Invalid parameter not satisfying: th
suggesting something going wrong deep down below the lisp level. This was with the latest mcclim CVS, OpenMCL 1.0 and PPC OSX 10.4.9.
Before diving in I would like to know if the beagle backend is considered dead beyond repair (or at least if others than myself has any interest in it). Are there alternatives, can the gtkairo or opengl backends be brought to fly without X11?
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
IIRC, the last updates on the beagle backend were running into some collisions between how McCLIM wanted to work and how the Mac works. http://common-lisp.net/pipermail/mcclim-devel/2005-November/004301.html
I would suggest the first place to look would be at the OpenMCL Objective-C bridge, to make sure that works - if you can, grab a copy of OpenMCL that was current when the original work on the Beagle backend was done and a tarball release from around then and see if those work. I don't know how much has changed in McCLIM since the last Beagle updates and whether it would cause breakage.
Beagle is the "right way" to do an McCLIM backend for MacOSX, as I understand it - it will give the best "native" appearance and behavior. Cario's website says it has an experimental Quartz backend but I don't know if it's ever been tried with McCLIM.
Cheers, CY
--- Christian Lynbech christian@defun.dk wrote:
I could use some pointers on the status of McCLIM on the Mac. In particular, I am interested in how to run against the native graphics system rather than having to run the X11 server.
I have looked a bit on the beagle backend but I cannot get it to work. A few fixes is needed just to get it to compile. Once that is done, it does compile and load but once an application (such as the calculator demo) is started, the lisp process freezes with output to the effect of:
? 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failurein -[NSWindowGraphicsContext reenableDisplayPosting], GraphicsContext.subproj/NSWindowGraphicsContext.m:117 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failure in -[NSViewHierarchyLock unlockTopMostReader], AppKit.subproj/NSViewHierarchyLock.m:444 2007-04-22 20:07:30.710 dppccl[2492] Error in event loop: Objective-C runtime exception: Invalid parameter not satisfying: th
suggesting something going wrong deep down below the lisp level. This was with the latest mcclim CVS, OpenMCL 1.0 and PPC OSX 10.4.9.
Before diving in I would like to know if the beagle backend is considered dead beyond repair (or at least if others than myself has any interest in it). Are there alternatives, can the gtkairo or opengl backends be brought to fly without X11?
------------------------+-----------------------------------------------------
Christian Lynbech | christian #@ defun #. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Monday, April 30, 2007, at 08:04 pm, C Y wrote:
IIRC, the last updates on the beagle backend were running into some collisions between how McCLIM wanted to work and how the Mac works. http://common-lisp.net/pipermail/mcclim-devel/2005-November/004301.html
I don't think these issues are insurmountable; I've not been keeping up with McCLIM development over the last 18 months (I dunno, start a little side-project and what happens...), but I did see that Tim made a couple of changes to Beagle's event processing (it was whilst investigating some event issues that I got sidetracked). Whether that's helped any I'm not sure.
I would suggest the first place to look would be at the OpenMCL Objective-C bridge, to make sure that works - if you can, grab a copy of OpenMCL that was current when the original work on the Beagle backend was done and a tarball release from around then and see if those work. I don't know how much has changed in McCLIM since the last Beagle updates and whether it would cause breakage.
IIRC I got a couple of reports that Beagle didn't compile out of the box on 10.4. I never had a box with 10.4 on it and as far as I know nobody made any great effort to resolve the issue. OS X and OpenMCL have moved on quite a lot since then so if anything the bitrot is probably worse than was reported back then (although I note you're not using a much newer version of OpenMCL than I was (0.14.3)).
Beagle is the "right way" to do an McCLIM backend for MacOSX, as I understand it - it will give the best "native" appearance and behavior.
I remember having quite a long discussion wrt whether Cocoa or Carbon was the way to go for a (foreign) native L&F on the Mac; I can't help feeling that the direction I ended up taking (Cocoa) wasn't necessarily the best (in terms of making life easier when hooking up to the native window system, I suspect the low-level nature of Carbon is probably a win).
Cario's website says it has an experimental Quartz backend but I don't know if it's ever been tried with McCLIM.
Cheers, CY
--- Christian Lynbech christian@defun.dk wrote:
I could use some pointers on the status of McCLIM on the Mac. In particular, I am interested in how to run against the native graphics system rather than having to run the X11 server.
I have looked a bit on the beagle backend but I cannot get it to work. A few fixes is needed just to get it to compile. Once that is done, it does compile and load but once an application (such as the calculator demo) is started, the lisp process freezes with output to the effect of:
The calculator demo never used to work very well with Beagle (irrespective of frame manager). Trying to run anything from demodemo just caused deadlock in the event processing, so if you're getting that it's possible you've done as well as the code currently allows :-)
I would say that if you bind CLIM:*DEFAULT-FRAME-MANAGER* to BEAGLE:BEAGLE-STANDARD-FRAME-MANAGER (see the README.txt file in the backends/Beagle directory) and you get further, you may be seeing some side-effects to the problems in the event handling code (although I don't recall them making themselves apparent via assertion failures, so I'm not hopeful).
Sorry not to be more helpful...
-Duncan
? 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failurein -[NSWindowGraphicsContext reenableDisplayPosting], GraphicsContext.subproj/NSWindowGraphicsContext.m:117 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failure in -[NSViewHierarchyLock unlockTopMostReader], AppKit.subproj/NSViewHierarchyLock.m:444 2007-04-22 20:07:30.710 dppccl[2492] Error in event loop: Objective-C runtime exception: Invalid parameter not satisfying: th
suggesting something going wrong deep down below the lisp level. This was with the latest mcclim CVS, OpenMCL 1.0 and PPC OSX 10.4.9.
Before diving in I would like to know if the beagle backend is considered dead beyond repair (or at least if others than myself has any interest in it). Are there alternatives, can the gtkairo or opengl backends be brought to fly without X11?
+-----------------------------------------------------
Christian Lynbech | christian #@ defun #. dk
+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
I tried some of your suggestions and it changed the behaviour a bit.
I first changed to the address-book demo with first exhibited the same behaviour as before. I then changed the default frame manager and now rather than a lowlevel error, I get the following lisp level error which could hint at the aforementioned input focus problem.
No applicable method for args: (#<BEAGLE-PORT :screen MAIN-SCREEN> #<CLIM-DEMO::ADDRESS-BOOK #x9348EBE>) to #<STANDARD-GENERIC-FUNCTION CLIM-BACKEND:PORT-FRAME-KEYBOARD-INPUT-FOCUS #x8A8156E> [Condition of type SIMPLE-ERROR]
Restarts: 0: [ABORT] Return to SLIME's top level. 1: [ABORT-BREAK] Reset this process 2: [ABORT] Kill this process
Backtrace: 0: (#<CCL::STANDARD-KERNEL-METHOD NO-APPLICABLE-METHOD (T)> #<STANDARD-GENERIC-FUNCTION CLIM-BACKEND:PORT-FRAME-KEYBOARD-INPUT-FOCUS #x8A8156E>) 1: (#<STANDARD-METHOD CLIM:STREAM-SET-INPUT-FOCUS (CLIM:CLIM-STREAM-PANE)> #<CLIM-DEMO::ADDRESS-BOOK #x9348EBE>) 2: (#<STANDARD-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)> #<CLIM-DEMO::ADDRESS-BOOK #x9348EBE>) 3: (CCL::%%STANDARD-COMBINED-METHOD-DCODE #<CONNECTION #x844548E> #<TWO-WAY-STREAM input #<SWANK-BACKEND::SLIME-INPUT-STREAM #x844339E>, output #<SWANK-BACKEND::SLIME-OUTPUT-STREAM #x8445416> #x8443286>) 4: (ADDRESS-BOOK) 5: (CCL::CALL-CHECK-REGS 'ADDRESS-BOOK) 6: (#<Anonymous Function #x840A1A6> "(address-book) ") 7: (SWANK::CALL-WITH-BUFFER-SYNTAX #<COMPILED-LEXICAL-CLOSURE #x9348F7E>) 8: (CCL::CALL-CHECK-REGS 'SWANK:INTERACTIVE-EVAL) 9: (#<Anonymous Function #x840AE26> '(SWANK:INTERACTIVE-EVAL "(address-book) ") 30 'NIL) 10: (#<Anonymous Function #x83A1D26> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x841AF46> #<COMPILED-LEXICAL-CLOSURE #x9348F9E>) 11: (FUNCALL 'SWANK::EVAL-FOR-EMACS) 12: (#<Anonymous Function #x83F0CE6>) 13: (#<Anonymous Function #x83A1D26> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x841AF46> #<Anonymous Function #x83F0CE6>) 14: (SWANK::CALL-WITH-REDIRECTED-IO #<COMPILED-LEXICAL-CLOSURE #x9348FBE> 'NIL) 15: (SWANK::CALL-WITH-CONNECTION #<CONNECTION #x844548E> #<Anonymous Function #x83F0CE6>) 16: (SWANK::HANDLE-REQUEST #<CONNECTION #x844548E>) 17: (SWANK::CALL-WITH-BINDINGS 'NIL #<COMPILED-LEXICAL-CLOSURE #x9348FD6>) 18: (CCL::RUN-PROCESS-INITIAL-FORM '(#<COMPILED-LEXICAL-CLOSURE #x9341CFE>) #<PROCESS worker(33) [Active] #x9341D36>) 19: (#<Anonymous Function #x80D0DFE> '(#<COMPILED-LEXICAL-CLOSURE #x9341CFE>) 0) 20: (#<Anonymous Function #x80C3956> 791992 #<LISP-THREAD worker [tcr @ #x3056E0] #x9341E2E>)
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
Quoting Christian Lynbech (christian@defun.dk):
I tried some of your suggestions and it changed the behaviour a bit.
I first changed to the address-book demo with first exhibited the same behaviour as before. I then changed the default frame manager and now rather than a lowlevel error, I get the following lisp level error which could hint at the aforementioned input focus problem.
No applicable method for args: (#<BEAGLE-PORT :screen MAIN-SCREEN> #<CLIM-DEMO::ADDRESS-BOOK #x9348EBE>) to #<STANDARD-GENERIC-FUNCTION CLIM-BACKEND:PORT-FRAME-KEYBOARD-INPUT-FOCUS #x8A8156E> [Condition of type SIMPLE-ERROR]
That would be recent bit rot, due to Christophe Rhodes's keyboard focus changes. %SET-PORT-KEYBOARD-FOCUS has been removed. Instead ports need to implement a method on PORT-FRAME-KEYBOARD-INPUT-FOCUS, which returns the sheet that has input focus according to cocoa, and a SETF method of the same name to change cocoa's focus.
BTW, the code involving event handling looks rather recent. Browsing through CVS history I noticed that Tim Moore committed some changes a little over a year ago, for McCLIM 0.9.2.
d.
I made another attempt, this time making sure the flow was routed around the bad climi reference. The resulting error in the inferior lisp buffer is as follows. Something is still bad but the error is different so it seems as if a proper fix for the foxus problem is needed to progress.
-- Christian
? 2007-05-07 20:51:01.701 dppccl[4675] Exception raised during posting of notification. Ignored. exception: Lisp exception: Unknown foreign type: SINGLE-FLOAT 2007-05-07 20:51:02.018 dppccl[4675] *** NSThread: ignoring exception 'Lisp exception: value NIL is not of the expected type SIMPLE-VECTOR.' that raised during delayed perform of target 0x1862600 and selector 'endEditing' 2007-05-07 20:51:02.027 dppccl[4675] *** NSThread: ignoring exception 'Lisp exception: value NIL is not of the expected type SIMPLE-VECTOR.' that raised during delayed perform of target 0x1862600 and selector 'updateHemlockSelection' 2007-05-07 20:51:29.346 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.356 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.366 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.386 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.396 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.406 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.417 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.436 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.467 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.479 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.487 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.507 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.527 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.547 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.557 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:51:29.567 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR. 2007-05-07 20:52:17.668 dppccl[4675] *** NSThread: ignoring exception 'Lisp exception: value NIL is not of the expected type SIMPLE-VECTOR.' that raised during delayed perform of target 0x1862600 and selector 'updateHemlockSelection' 2007-05-07 20:52:20.446 dppccl[4675] *** NSThread: ignoring exception 'Lisp exception: value NIL is not of the expected type SIMPLE-VECTOR.' that raised during delayed perform of target 0x1862600 and selector 'updateHemlockSelection' 2007-05-07 20:53:46.679 dppccl[4675] *** Assertion failure in -[NSWindowGraphicsContext reenableDisplayPosting], GraphicsContext.subproj/NSWindowGraphicsContext.m:117 2007-05-07 20:53:46.682 dppccl[4675] Error in event loop: Objective-C runtime exception: Invalid parameter not satisfying: _displayPostingDisableCount > 0 2007-05-07 20:53:46.688 dppccl[4675] *** Assertion failure in -[NSViewHierarchyLock unlockTopMostReader], AppKit.subproj/NSViewHierarchyLock.m:444
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
Hi,
Quoting Christian Lynbech (christian@defun.dk):
I have looked a bit on the beagle backend but I cannot get it to work. A few fixes is needed just to get it to compile. Once that is done, it does compile and load but once an application (such as the calculator demo) is started, the lisp process freezes with output to the effect of:
can you submit those fixes as a patch?
If Beagle works at all, even just to the extent that it compiles and loads, I think it would be worth getting it reintegrated into mcclim.asd, so that anyone who wants to give it a try can do so easily.
IIRC others have reported on IRC that Beagle works for them with a little hacking, so it must be possible somehow.
Before diving in I would like to know if the beagle backend is considered dead beyond repair (or at least if others than myself has
Well, I do not have a Mac, so my interest in Beagle is just from the "native backend implementor" point of view. But I hope nobody would throw Gtkairo away just because it is a little buggy, and the same should be true for Beagle.
any interest in it). Are there alternatives, can the gtkairo or opengl backends be brought to fly without X11?
Gtkairo works without X on MS Windows, but I am not aware of anyone having it tried on MacOS without X.
Starting with GTK+ 2.9 there appears to be a Quartz implementation of GDK though, so it should be possible: http://developer.imendio.com/projects/gtk-macosx
Of course, a full GDK/GTK+ implementation cannot actually offer a native look and feel on MacOS. But then, CLIM has its own look and feel issues anyway, so that might not make much of a difference...
d.
My patch is attached below.
It is really quite simple. First of all it enables the beagle backend provided you do not have clx and do have mcl|openmcl. That should be safe enough.
The fix itself goes into "Backends/beagle/beagle-backend.asd" and here things are more fishy. Well, the fix itself is innocent enough, it fixes the imports of two unknown symbols.
The first fix `%set-port-keyboard-focus' is just outcommented since this is not referenced anywhere other than in beagle-backend.asd.
The other fix relates to `keyboard-input-focus' which also is no longer known. The patch changes that into `port-keyboard-input-focus' but judging from a comment of its only usage in `beagle-notification-to-clim-event' in "Backends/beagle/input/events.lisp" there must have been a subtle difference between `keyboard-input-focus' and `port-keyboard-input-focus'.
Anyway, we never get to that point, the process breaks down long before, suggesting problems in the ObjC bridge.
I am using OpenMCL 1.0 rather than the latest snapshot because that gives me a weird compilation error, but that may improve matters.
I also attach the script I have used to start up McCLIM on openmcl, the instructions in "Backends/beagle/README.txt" does not seem to match reality all that well.
-- Christian
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
-
C Y -
Christian Lynbech -
David Lichteblau -
Duncan Rose