Mac Issues

[codescrawl]

Hi, I'm having a problem getting up and running on the mac with your library and I'd love to get to the bottom of this if possible as I'm keen to port the superbible 7 examples over as a learning exercise. I'm not a l33t lisper as I'm coming back to the language after a 20 year hiatus.

In sbcl I see the following floating-point-overflow error which looks pretty much the same as I've encountered running some glut examples.

• (ql:quickload "cl-glfw3-examples")
  To load "cl-glfw3-examples":
  Load 1 ASDF system:
  cl-glfw3-examples
  ; Loading "cl-glfw3-examples"
  ............
  ("cl-glfw3-examples")
• (cl-glfw3-examples:basic-window-example)

debugger invoked on a FLOATING-POINT-OVERFLOW in thread

<THREAD "main thread" RUNNING {1002C74733}>:

arithmetic error FLOATING-POINT-OVERFLOW signalled

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.

("bogus stack frame")
0]

At this point I have to exit sbcl to close the exec icon that appears in the dock. I can we the window rendered correctly however.

In ccl64 I get a different issue:

? (ql:quickload "cl-glfw3-examples")
To load "cl-glfw3-examples":
Load 1 ASDF system:
cl-glfw3-examples
; Loading "cl-glfw3-examples"

("cl-glfw3-examples")
? (cl-glfw3-examples:basic-window-example)
2015-10-08 13:14:05.733 dx86cl64[15465:315830] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-1154/Misc.subproj/NSUndoManager.m:340
2015-10-08 13:14:05.734 dx86cl64[15465:315830] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.
2015-10-08 13:14:05.735 dx86cl64[15465:315830](0 CoreFoundation 0x00007fff916dd03c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff9726076e objc_exception_throw + 43
2 CoreFoundation 0x00007fff916dce1a +[NSException raise:format:arguments:] + 106
3 Foundation 0x00007fff9759299b -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 195
4 Foundation 0x00007fff9751464f +[NSUndoManager%28NSPrivate%29 _endTopLevelGroupings] + 156
5 AppKit 0x00007fff8ba6cb95 -[NSApplication run] + 756
6 libglfw3.dylib 0x00000000000dc85c _glfwPlatformCreateWindow + 1410
7 libglfw3.dylib 0x00000000000d920f glfwCreateWindow + 582
8 dx86cl64 0x000000000001b693 ffcall_return + 0)
2015-10-08 13:14:05.735 dx86cl64[15465:315830] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-1154/Misc.subproj/NSUndoManager.m:340
Unhandled exception 10 at 0x0, context->regs at #xb0299bd0
Exception occurred while executing foreign code
received signal 10; faulting address: 0x0
? for help
[15465] Clozure CL kernel debugger:

I'm stumped as to what I need to do to progress - do you have any ideas? I see that you have some darwin conditional statements in the code so assume you've managed to get something up and running in the past, is that correct?

Thanks in advance for help,

Colin

[AlexCharlton]

Without having looked into it further, I'm as stumped as you. I didn't add the initial Mac support, but I assume it worked at some point. I do have a Mac now, so I'll be able to test it, but until I do, I'm totally in the dark!

[alexander-us85]

I got the same error in Clozure CL on Os X (el Capitan) but on sbcl everything seems to be OK. At least
(cl-glfw3-examples:basic-window-example)
works as expected.

[codescrawl]

I'm using sbcl 1.2.16 installed from homebrew:

This is SBCL 1.2.16, an implementation of ANSI Common Lisp.
More information about SBCL is available at http://www.sbcl.org/.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.

Is that the same as you @alexzlov? Also, it does work for me up until I close the window and then I see that particular error.

[alexander-us85]

@codescrawl Here's a screenshot of mine: http://joxi.ru/krDlRV5Spdn3rp
SBCL 1.2.16.143-1e1da23, Clozure CL Version 1.12-dev-r16611M-trunk (DarwinX8664),
OS X El Capitan.
There is a place in cl-glfw3 sources, which handles floating point traps:
https://github.com/AlexCharlton/cl-glfw3/blob/master/glfw-bindings.lisp#L89,
so I think it's not cl-glfw3 issue.
Before OS X update (yosemite) I had the same issue with glfw3 library and Clozure CL. Steel Bank worked good.
In general, I suspect that the cause of the Clozure CL error lies in the Os X threading and window management. Here's the working example with CCL and GLUT framework:
http://trac.clozure.com/ccl/browser/trunk/source/examples/opengl-ffi.lisp#L111
May be these hacks can help.

[AlexCharlton]

I just tried it out with SBCL 1.2.14 on Yosemite and curiously I ended up with the same error you got on CCL, @codescrawl, before the window even opens. The errors do suggest that both SBCL and CCL are trying to do something overly clever with threads. I haven't run into anything like this with GLFW in a single-threaded environment.

Unfortunately, I don't have much time to look into this at the moment. Any fixes for this would be appreciated!

[codescrawl]

Thanks for the information. I'm running Yosemite right now so it sounds like there is some mileage in upgrading to El Capitan. I'll be honest though my lisp skills are not good enough yet to help with a fix although I'd love to help. I'll tinker for a bit and see if I can find a way around though and report back if I discover anything useful.

[alexander-us85]

Ok, finally I've got some information.
In sbcl, FLOATING-POINT-OVERFLOW occurs in a build without threading support. I installed sbcl from homebrew (which was with sb-threads) and got the same error, as in ClozureCL:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.'

@codescrawl : you can use a hack like this:
(sb-thread:interrupt-thread
(sb-thread:main-thread)
(lambda () (cl-glfw3-examples:basic-window-example)))

and the window example should run and work correctly

[AlexCharlton]

Looks like there are two issues at we're seeing. The floating point error, and an error when glfw is initialized outside of the main thread. I'm running SBCL with threading support, and can reproduce both issues easily.

When I run an example with Slime (which starts it a non-main thread) I get the latter error before any window is initialized. This is clearly an issue others have run into ( lispgames/cl-sdl2#29 ) and it seems difficult to work around in an elegant way, at least at the level of this library, as it would require implementation specific support like @alexzlov's example. Any suggestions in this direction are most welcome.

I see the floating point error when running the basic-window-example out of the main thread. I've isolated it to the key-callback. Still unsure why it's happening, but I'll continue investigating.

[alexander-us85]

@AlexCharlton May be it's possible to add a library such as https://github.com/Shinmera/trivial-main-thread as a dependency? I've tried it with the following code:

    (ql:quickload '(cl-glfw3 cl-glfw3-examples trivial-main-thread))
    (trivial-main-thread:call-in-main-thread (lambda ()
                                                    (cl-glfw3-examples:basic-window-example))

and everything worked fine.

[AlexCharlton]

@alexzlov That's a good library to know about! Unfortunately, I don't feel like adding it straight to cl-glfw3 is the right move, as it's the kind of thing that needs to be applied to all graphics calls. Because of this, setting the thread is something that I feel should be done at a higher level, or things will just be confusing. I did just update the examples to take advantage of trivial-main-threads so that they can now run easily.

@alexzlov @codescrawl I just pushed a branch https://github.com/AlexCharlton/cl-glfw3/tree/no-float-trap-restore that fixes the floating point issues that I've seen. Do you mind testing it and letting me know if it makes anything better or worse for you?

Thanks!

[codescrawl]

Hi Alex, I've tried this version from local projects and for some reason it now appears to be looking for libglfw.so rather than .dylib

Error: Unable to load any of the alternatives:
("libglfw.so.3.0" "libglfw.so.3")

I've compiled glfw3 from scratch as a dylib and it's now loading (with a change to glfw-bindings.lisp). I'll try and give it a test in a short while.

[codescrawl]

OK, that definitely works for me in clozure 1.10 - thanks very much for that.

The only change I had to make is show below in glfw-bindings.lisp

(define-foreign-library (glfw)
(:unix (:or "libglfw.3.1.dylib" "libglfw.so.3.0" "libglfw.so.3"))
(t (:or (:default "libglfw3") (:default "libglfw"))))

[alexander-us85]

@codescrawl OK, that's great! Have you tried glfw3 installation with homebrew? I don't remember exactly, but it seems that I've made homebrew glfw installation and everything was ok.
There is a Russian machine - the truck "Kamaz". Kamaz drivers can be found very easily - they're all dirty because of the fact that they always need to get under the hood and fix something. It seems that implementations of Common Lisp and KAMAZ have something in common - if something does not work, you have to get "under the hood" and try to fix it yourself.

[alexander-us85]

@codescrawl One small PS. If you don't consider using sbcl or other implementations, maybe you'll find more useful to make direct calls to libglfw3.dylib via native clozure's ffi generator? Although building ffigen4 is a little tricky I've had a success with it.
Just in case I give you a couple of links:
https://lispwannabe.wordpress.com/2010/01/25/clozure-common-lisp-ffi-mini-tutorial/
http://trac.clozure.com/ccl/wiki/BuildFFIGEN

[tavurth]

OSX Sierra, SBCL, working fine with glfw from homebrew.

brew install glfw libffi