Mac Issues about cl-glfw3 HOT 16 OPEN

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!

from cl-glfw3.

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.

from cl-glfw3.

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.

from cl-glfw3.

@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.

from cl-glfw3.

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!

from cl-glfw3.

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.

from cl-glfw3.

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

from cl-glfw3.

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.

from cl-glfw3.

@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.

from cl-glfw3.

@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!

from cl-glfw3.

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.

from cl-glfw3.

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"))))

from cl-glfw3.

@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.

from cl-glfw3.

@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

from cl-glfw3.

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

brew install glfw libffi

from cl-glfw3.

Hi - I came to cl-glfw3 by recommendation. Running sbcl 1.4.6 on macOS High Sierra 10.13.4. I don't see any window appearing when running the examples, just:
#<SIMPLE-TASKS:CALL-TASK :FUNC #<FUNCTION (LAMBDA ()
:IN CL-GLFW3-EXAMPLES:BASIC-WINDOW-EXAMPLE) {22B2F99B}> :STATUS :SCHEDULED {1004845AB3}>
Do I need to run the task as a separate step?

TIA for any hints.
Regards
Frank

from cl-glfw3.