Giter VIP home page Giter VIP logo

glfw.jl's People

Contributors

asinghvi17 avatar cmcaine avatar ffreyer avatar giordano avatar gnimuc avatar iblislin avatar jaakkor2 avatar jayschwa avatar juliatagbot avatar louisponet avatar musm avatar scottpjones avatar simondanisch avatar sjkelly avatar ssfrr avatar timholy avatar tkelman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

glfw.jl's Issues

Use @enum for GLFW constants

ErrorCode is already an enum. It can be rolled out to more of the constants.

Candidates:

  • Key
  • Button actions (e.g. press, release)
  • Modifier keys
  • Cursors
  • Window hints
  • etc

The only downside is that exceptions might occur if Julia gets a value that isn't defined in the enum. This probably won't occur under normal circumstances since this package also controls which version of the GLFW library gets used. However, it might be good to write a little script that compares our enums to what is in glfw3.h.

Pkg.build blows up if library is already loaded in Windows

import GLFW
GLFW.GetVersion()
Pkg.build("GLFW")

In Windows, this blows up every time because the existing file is opened by the Julia process and can't be overwritten.

I happened to stumble upon this while doing some Windows testing. It's probably not something that will happen very often to normal users, but it'd be nice if it can be remedied. For some reason I feel like there are tools (at least on Linux) that can safely install new copies of files even if the existing ones are opened by a process.

Segfault after 'using GLFW'

Segfault after using GLFW on 2.0 alpha on Arch linux

signal (11): Segmentation fault
while loading no file, in expression starting on line 0
unknown function (ip: 0x7fded5f75ecf)
unknown function (ip: 0x7fded83e658e)
unknown function (ip: 0x7fded83e6981)
unknown function (ip: 0x7fded83f3685)
unknown function (ip: 0x7fded83f7623)
unknown function (ip: 0x7fded83e658e)
unknown function (ip: 0x7fded83fad42)
unknown function (ip: 0x7fded83e6694)
unknown function (ip: 0x7fded83f3685)
unknown function (ip: 0x7fded83f7623)
unknown function (ip: 0x7fded83dfd52)
unknown function (ip: 0x7fded83e31c3)
unknown function (ip: 0x7fded83e5668)
unknown function (ip: 0x7fded83e6419)
unknown function (ip: 0x7fded83e6981)
unknown function (ip: 0x7fded83f3685)
unknown function (ip: 0x7fded83f7623)
unknown function (ip: 0x7fded8353698)
jl_apply_generic at /usr/lib/libjulia.so.0.6 (unknown line)
unknown function (ip: 0x7fded837eb0a)
unknown function (ip: 0x7fded8379990)
jl_restore_incremental at /usr/lib/libjulia.so.0.6 (unknown line)
unknown function (ip: 0x7fded24e9096)
_require_from_serialized at ./loading.jl:200
unknown function (ip: 0x7fdea992a848)
jl_apply_generic at /usr/lib/libjulia.so.0.6 (unknown line)
_require_search_from_serialized at ./loading.jl:236
unknown function (ip: 0x7fdea99362a8)
jl_apply_generic at /usr/lib/libjulia.so.0.6 (unknown line)
_require at ./loading.jl:441
require at ./loading.jl:405
unknown function (ip: 0x7fdea9928152)
jl_apply_generic at /usr/lib/libjulia.so.0.6 (unknown line)
unknown function (ip: 0x7fded837e85b)
unknown function (ip: 0x7fded837f3b2)
jl_toplevel_eval_in at /usr/lib/libjulia.so.0.6 (unknown line)
macro expansion at /home/raf/.julia/v0.6/Atom/src/repl.jl:118 [inlined]
anonymous at ./<missing> (unknown line)
unknown function (ip: 0x7fded837f8f9)
jl_toplevel_eval_in at /usr/lib/libjulia.so.0.6 (unknown line)
unknown function (ip: 0x7fded23c6c09)
unknown function (ip: 0x7fded23c6c1f)
jl_apply_generic at /usr/lib/libjulia.so.0.6 (unknown line)
unknown function (ip: 0x7fded2447981)
unknown function (ip: 0x7fded2447b9f)
jl_apply_generic at /usr/lib/libjulia.so.0.6 (unknown line)
macro expansion at ./REPL.jl:97 [inlined]
#1 at ./event.jl:73
unknown function (ip: 0x7fdeb606089f)
jl_apply_generic at /usr/lib/libjulia.so.0.6 (unknown line)
unknown function (ip: 0x7fded836d9fd)
unknown function (ip: 0xffffffffffffffff)
Allocations: 141327038 (Pool: 141315638; Big: 11400); GC: 332
Julia Version 0.6.3
Commit d55cadc (2018-05-28 20:20 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libm
  LLVM: libLLVM-3.9.1 (ORCJIT, sandybridge)

don't use Pkg.dir

In several places (for example, here), you use Pkg.dir("GLVisualize", ...) to find the package directory. This is wrong, because it breaks for packages that are stored in a system-wide location—see JuliaLang/julia#12120

The right thing to do is one of:

  • Use relative paths. e.g. just include("types.jl") rather than include(joinpath( sourcedir, "types.jl")) ... this works, because include is always relative to the directory of the current file.
  • If an absolute path is needed, use dirname(@__FILE__).

Sweet!

I was considering putting together the beginnings of a GLFW.jl package this weekend. Glad to see that you got a nice amount of functions working! I like your wrappers for callbacks; think I'll incorporate that into the GLUT.jl package.

--Rob

Should this work with OpenGL.jl?

I'm old-fashioned (read: short of time for learning new tricks), and would like to use deprecated OpenGL functions like glMatrixMode.

Since these functions aren't included in ModernGL.jl, I thought I'd try using GLFW with OpenGL 1.0 from OpenGL.jl. However, the following code displays a black window and turns my Macbook Pro into treacle until I manage to force-quit it. Am I doing something wrong, or is this impossible?

using OpenGL
@OpenGL.version "1.0"
@OpenGL.load
import GLFW

GLFW.Init()

window = GLFW.CreateWindow(640, 480, "GLFW.jl")

GLFW.MakeContextCurrent(window)

w = 640
h = 480

glViewport(0,0,w,h)
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
gluPerspective(45.0,w/h,0.1,100.0)
glMatrixMode(GL_MODELVIEW)

while !GLFW.WindowShouldClose(window)

    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

    glLoadIdentity()

    glColor(1.0,1.0,1.0)

    glTranslate(-1.5,0.0,-6.0)

    glBegin(GL_POLYGON)
      glVertex(0.0,rand(),0.0)
      glVertex(1.0,-1.0,0.0)
      glVertex(-1.0,-1.0,0.0)
    glEnd()

    glTranslate(3.0,0.0,0.0)

    glBegin(GL_QUADS)
        glVertex(-1.0,1.0,0.0)
        glVertex(1.0,1.0,0.0)
        glVertex(1.0,-1.0,0.0)
        glVertex(-1.0,-1.0,0.0)
    glEnd()
    end

    GLFW.SwapBuffers(window)

    GLFW.PollEvents()
end

GLFW.Terminate()

GLFWError (PLATFORM_ERROR): Wayland: Failed to connect to display

Wayland: Failed to connect to display

> import GLFW
ERROR: InitError: GLFWError (PLATFORM_ERROR): Wayland: Failed to connect to display
Stacktrace:
 [1] handle_error(::Int32, ::String) at /home/zorn/.julia/v0.6/GLFW/src/GLFW.jl:34
 [2] ##ErrorCallbackWrapper#657(::Int32, ::Cstring) at /home/zorn/.julia/v0.6/GLFW/src/callback.jl:50
 [3] Init() at /home/zorn/.julia/v0.6/GLFW/src/glfw3.jl:306
 [4] __init__() at /home/zorn/.julia/v0.6/GLFW/src/GLFW.jl:40
 [5] macro expansion at ./REPL.jl:97 [inlined]
 [6] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:73
during initialization of module GLFW

I am using Arch Linux
Is there something I have to install?

> echo $XDG_RUNTIME_DIR                                                                             
/run/user/1000

Throw more specific error types

The default error callback simply calls error. However, the different errors that GLFW can raise are quite different. Some indicate programmer error, some indicate (possibly) recoverable runtime errors, and some are irrecoverable runtime errors.

GLFW.jl should be updated to throw an appropriately typed error. Existing Julia error types can be used where possible, and new ones can be created for the remainder that don't have good matches.

precompilation safety

If you ever precompile this package, e.g. as a side-effect of precompiling GLVisualize (JuliaGL/GLVisualize.jl#15), it should be revised to separate runtime and compile-time more cleanly.

In particular, it currently detects the glfwGetVersion at runtime and initializes appropriately. If you precompile this module, however, it will "freeze in" the glfwGetVersion that was detected at compile time and probably crash if the version loaded at runtime is different.

Since the version can no longer change at runtime anyway once it is precompiled (which is probably desirable), my suggestion is:

  • Detect the glfw version and library location in deps/build.jl, i.e. at Pkg.build time, and write it to a file deps/deps.jl that is included by GLFW.jl
  • At runtime (in an __init__ function), call glfwGetVersion and throw an exception if the major version does not match the one in deps.jl (i.e. if it doesn't match the version the package was built with) — tell the caller to re-run Pkg.build("GLFW").

Build Error on Linux/Ubuntu: No such file or directory

I get an error when I try to build GLFW.jl. I got this when I tried using Pkg.add and then when I tried running the build file myself. Do you know what's going on?

leah@sandy-4:~/.julia/v0.3/GLFW$ julia deps/build.jl 
ERROR: could not spawn `cmake -DBUILD_SHARED_LIBS=ON -DGLFW_BUILD_EXAMPLES=OFF -DGLFW_BUILD_DOCS=OFF -DCMAKE_INSTALL_PREFIX=../../usr -DGLFW_BUILD_TESTS=OFF ../../src/glfw-3.0.4`: no such file or directory (ENOENT)
 in _jl_spawn at process.jl:217
 in spawn at process.jl:348
 in spawn at process.jl:389
 in run at process.jl:478
 in anonymous at /home/leah/.julia/v0.3/GLFW/deps/build.jl:25
 in cd at file.jl:20
 in include at ./boot.jl:244
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
while loading /home/leah/.julia/v0.3/GLFW/deps/build.jl, in expression starting on line 17

Build fails on Windows / Julia v0.4

Feel free to close this if GLFW isn't meant to be compatible with the current master branch of Julia (I looked, but didn't see it specified anywhere).

Currently, Pkg.build("GLFW") on Windows fails with the following error:

"LoadError: could not spawn cp -R builds/glfw-3.0.4.bin.WIN32/lib-mingw usr32/lib: no such file or directory (ENOENT)
while loading C:\Users\admin.julia\v0.4\GLFW\deps\build.jl, in expression starting on line 38"

Is there an additional dependency I should install?

Add sane gamma ramp interface

The GammaRamp structure is currently just a collection of uint pointers, which isn't terribly useful. The gamma ramp functions should probably take and emit arrays or tuples or something.

Build failure (can't find Xrandr.h)

From a Pkg.update() this morning:

INFO: Building GLFW
-- The C compiler identification is GNU 4.8.2
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so  
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Using X11 for window creation
-- Using GLX for context creation
-- Configuring done
CMake Warning (dev) in src/CMakeLists.txt:
  Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
  interface.  Run "cmake --help-policy CMP0022" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  Target "glfw" has an INTERFACE_LINK_LIBRARIES property which differs from
  its LINK_INTERFACE_LIBRARIES properties.

  INTERFACE_LINK_LIBRARIES:

    /usr/lib/x86_64-linux-gnu/libX11.so;-lpthread;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libXrandr.so;/usr/lib/x86_64-linux-gnu/libXi.so;/usr/lib/x86_64-linux-gnu/libXxf86vm.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/libGL.so

  LINK_INTERFACE_LIBRARIES:



This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /home/tim/.julia/v0.3/GLFW/deps/builds/glfw-3.0.4
Scanning dependencies of target glfw
[  5%] Building C object src/CMakeFiles/glfw.dir/clipboard.c.o
In file included from /home/tim/.julia/v0.3/GLFW/deps/src/glfw-3.0.4/src/internal.h:73:0,
                 from /home/tim/.julia/v0.3/GLFW/deps/src/glfw-3.0.4/src/clipboard.c:27:
/home/tim/.julia/v0.3/GLFW/deps/src/glfw-3.0.4/src/x11_platform.h:42:35: fatal error: X11/extensions/Xrandr.h: No such file or directory
 #include <X11/extensions/Xrandr.h>
                                   ^
compilation terminated.
make[2]: *** [src/CMakeFiles/glfw.dir/clipboard.c.o] Error 1
make[1]: *** [src/CMakeFiles/glfw.dir/all] Error 2
make: *** [all] Error 2
=====================================================================[ ERROR: GLFW ]=====================================================================

failed process: Process(`make install`, ProcessExited(2)) [2]
while loading /home/tim/.julia/v0.3/GLFW/deps/build.jl, in expression starting on line 16

=========================================================================================================================================================

====================================================================[ BUILD ERRORS ]=====================================================================

WARNING: GLFW had build errors.

 - packages with build errors remain installed in /home/tim/.julia/v0.3
 - build a package and all its dependencies with `Pkg.build(pkg)`
 - build a single package by running its `deps/build.jl` script

=========================================================================================================================================================

For me, locate Xrandr.h turns up nothing. I'm on Kubuntu 14.04.

Also note the Target "glfw" has an INTERFACE_LINK_LIBRARIES property which differs from its LINK_INTERFACE_LIBRARIES properties warning.

[PackageEvaluator.jl] Your package GLFW may have a testing issue.

This issue is being filed by a script, but if you reply, I will see it.

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their test (if available) on both the stable version of Julia (0.2) and the nightly build of the unstable version (0.3).

The results of this script are used to generate a package listing enhanced with testing results.

The status of this package, GLFW, on...

  • Julia 0.2 is 'Tests fail, but package loads.' PackageEvaluator.jl
  • Julia 0.3 is 'Tests fail, but package loads.' PackageEvaluator.jl

'No tests, but package loads.' can be due to their being no tests (you should write some if you can!) but can also be due to PackageEvaluator not being able to find your tests. Consider adding a test/runtests.jl file.

'Package doesn't load.' is the worst-case scenario. Sometimes this arises because your package doesn't have BinDeps support, or needs something that can't be installed with BinDeps. If this is the case for your package, please file an issue and an exception can be made so your package will not be tested.

This automatically filed issue is a one-off message. Starting soon, issues will only be filed when the testing status of your package changes in a negative direction (gets worse). If you'd like to opt-out of these status-change messages, reply to this message.

Need cmake on OS X

build failed on OS X (Mavericks), until after I ran

brew install cmake

Windows support?

Has this been tested on Windows systems yet? I tried the minimal example program from the readme.md, but got the results below. Do I need to specify a dll location?

I have the contents of glfw-3.0.4.bin.WIN64.zip stored in C:\Program Files\GLFW.

# OpenGLTest.jl
import GLFW

GLFW.Init()
GLFW.OpenWindow(0, 0, 0, 0, 0, 0, 0, 0, GLFW.WINDOW)
while GLFW.GetWindowParam(GLFW.OPENED) && !GLFW.GetKey(GLFW.KEY_ESC)
  GLFW.SwapBuffers()
end
GLFW.CloseWindow()
GLFW.Terminate()
julia> OpenGLTest
LoadError("C:/Users/[username]/Documents/JuliaStudio/OpenGLTest.jl",3,ErrorException("error compiling Init: could not load module libglfw: The specified module could not be found.\r\n"))

folder not found when building

On OSX, GLFW doesn't build successfully after homebrew fails.
Is this an issue with Bindeps? For linux it seems to work fine.

LoadError: could not spawn `cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/Applications/JuliaPro-0.5.0.2.app/Contents/Resources/pkgs-0.5.0.2/v0.5/GLFW/deps/usr -DGLFW_BUILD_DOCS=OFF -DGLFW_BUILD_EXAMPLES=OFF -DGLFW_BUILD_TESTS=OFF .`: no such file or directory (ENOENT)
while loading /Applications/JuliaPro-0.5.0.2.app/Contents/Resources/pkgs-0.5.0.2/v0.5/GLFW/deps/build.jl, in expression starting on line 52

Or is the error message confusing and it's just that cmake is missing?

Best,
Simon

GLFW.OpenWindow() error on OS X

I just installed GLFW.jl. Running the example in Readme gives this error:

ERROR: ccall: could not find function glfwOpenWindow in library libglfw
 in OpenWindow at /Users/jkickliter/.julia/v0.3/GLFW/src/GLFW.jl:28

Please let me know any system specific information you need.

Fetching package fails on Ubunty - "error setting certificate"

This is probably a trivial problem, but I don't quite understand what's going on:

INFO: Downloading GLFW 3.1.2 source tarball
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (77) error setting certificate verify locations:
  CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
================================[ ERROR: GLFW ]=================================

LoadError: failed process: Process(`curl -o downloads/glfw-3.1.2.tar.gz -L https://github.com/glfw/glfw/archive/3.1.2.tar.gz`, ProcessExited(77)) [77]
while loading /home/job/.julia/v0.4/GLFW/deps/build.jl, in expression starting on line 13

================================================================================

=================================================================[ BUILD ERRORS ]=================================================================

WARNING: GLFW had build errors.

 - packages with build errors remain installed in /home/job/.julia/v0.4
 - build the package(s) and all dependencies with `Pkg.build("GLFW")`
 - build a single package by running its `deps/build.jl` script

==================================================================================================================================================

Throw more informative errors on version mismatch

If someone tries to use OpenWindow with GLFW 3 or CreateWindow with GLFW 2, they'll get a generic error that the function is not defined. Attempt to alleviate user headaches by at least giving them a clear description of the version mismatch problem.

build dependencies not working on osx

The build process for GLFW is not working on the new macOS Sierra. I have spent some time tracking down the reason, and I believe I have found it:

The GLFW.jl/deps/build.jl file runs and downloads the prebuilt glfw3 homebrew package, but the package cannot find the correct opengl32 dynamic library when running. With every new OS release, the default framework path changes. For example, the new framework path for opengl on sierra has moved to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/OpenGL.framework (note the 10.12).

The problem is that the prebuilt bottles referenced in deps/build.jl link to their own specific framework folder. This mechanism falls behind with each new OS release. The regular command line homebrew manager knows this and will build glfw3 from source rather than download a bottle. The mechanism used in GLFW.jl bypasses homebrew and cannot handle the change properly. Since all of the JuliaGL packages at their root appear to rely on GLFW for the binary dependencies to opengl, fixing it here should fix it everywhere else.

I propose that the deps/build.jl process be reworked to use BinDeps.jl and Homebrew.jl rather than relying on its own mechanism of downloading prebuilt bottles to GLFW/deps/builds. Perhaps something more along the lines of the deps found in Cairo.jl/deps/build.jl. Unfortunately, that likely means moving the libglfw3 binary files out of their GLFW/deps/builds subfolder and into the regular BinDeps.jl and Homebrew.jl target paths.

Fix for FreeBSD

In ModernGL/src/ModernGL.jl, line 29: change is_linux() to is_unix(). Then Pkg.test("GLFW") passes.

Automatic donwload fai

I got this error when running Pkg.build("GLFW")

automatic download failed (error: 2148270085): https://github.com/glfw/glfw/releases/download/3.1.1/glfw-3.1.1.bin.WIN32.zip
while loading C:\Users\user.julia\v0.3\GLFW\deps\build.jl, in expression starting on line 68

I managed to bypass it by downloading "glfw-3.1.1.bin.WIN32.zip", and manually and putting it into .julia\v0.3\GLWF\deps\downloads.
I also had to remove:
download("https://github.com/glfw/glfw/releases/download/$version/$build.zip", archive)
from line 68 from the build.jl file.

It might have been just a problem on my end, but I thought I would post it here in case it needs fixing.

Add @doc strings

Thoughts:

  • Compat.jl does not support @doc, so this might have to wait until Julia 0.3 support is dropped.
  • It might be worth writing a tool to scape the majority of documentation from glfw.h. It doesn't have to be perfect, but it will save a lot of manual copy-pasting.

Remove gamma ramp calls

Until a sane interface for them is devised (see #8), I don't want to have to take them into account once semantic versioning kicks in with v1.0.0.

Got error with GLFW.SetKeyCallback()

I'm a beginner to GLFW and followed the official guide to learn how to receive input events:

Receiving input events
Each window has a large number of callbacks that can be set to receive all the various kinds of events. To receive key press and release events, create a key callback function.

static void key_callback(GLFWwindow* window, int key, int scancode, int action, int mods)
{
    if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
        glfwSetWindowShouldClose(window, GL_TRUE);
}

The key callback, like other window related callbacks, are set per-window.

glfwSetKeyCallback(window, key_callback);

In order for event callbacks to be called when events occur, you need to process events as described below.
...
...

Then, I tryed to use GLFW.SetKeyCallback() to test a callback:

...some initializations...
window = GLFW.Createwindow(600,800,"mywindow",GLFW.NullMonitor,GLFW.NullWindow)

function key_callback(window::GLFW.Window, key::Cint , scancode::Cint, action::Cint, mods::Cint)
    if (key == GLFW.KEY_ESCAPE && action == GLFW.PRESS)
        GLFW.SetWindowShouldClose(window, 1);
    end
end

GLFW.SetKeyCallback(window,key_callback)  # error when exec this line

But I got these errors described below:

Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x6bf58a94 -- jl_f_get_field at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)

jl_f_get_field at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
SetKeyCallback at C:\Users\Administrator\.julia\v0.3\GLFW\src\util.jl:44
jlcall_SetKeyCallback_2404 at  (unknown line)
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_interpret_toplevel_expr at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_interpret_toplevel_thunk_with at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_eval_with_compiler_p at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_parse_eval_all at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_load_file_string at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
include_string at C:\Users\Administrator\.julia\v0.3\Jewel\src\eval.jl:32
jlcall_include_string_2084 at  (unknown line)
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_interpret_toplevel_expr at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_interpret_toplevel_thunk_with at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_eval_with_compiler_p at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_f_top_eval at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
include_string at C:\Users\Administrator\.julia\v0.3\Jewel\src\eval.jl:36
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
eval at C:\Users\Administrator\.julia\v0.3\Jewel\src\LightTable\eval.jl:11
evaldisplay at C:\Users\Administrator\.julia\v0.3\Jewel\src\LightTable\eval.jl:22
jlcall___evaldisplay#23___2070 at  (unknown line)
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
julia_evaldisplay_2068 at  (unknown line)
jlcall_evaldisplay_2068 at  (unknown line)
anonymous at C:\Users\Administrator\.julia\v0.3\Jewel\src\LightTable\eval.jl:53
handlecmd at C:\Users\Administrator\.julia\v0.3\Jewel\src\LightTable/LightTable.jl:65
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
handlenext at C:\Users\Administrator\.julia\v0.3\Jewel\src\LightTable/LightTable.jl:81
server at C:\Users\Administrator\.julia\v0.3\Jewel\src\LightTable/LightTable.jl:22
jlcall_server_1341 at  (unknown line)
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_f_apply at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
server at C:\Users\Administrator\.julia\v0.3\Jewel\src\Jewel.jl:15
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_f_apply at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_interpret_toplevel_expr at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_interpret_toplevel_thunk_with at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_eval_with_compiler_p at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_parse_eval_all at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
jl_load_ at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
include at boot.jl:245
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
include_from_node1 at loading.jl:128
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
process_options at client.jl:285
_start at client.jl:354
jlcall__start_358 at  (unknown line)
jl_apply_generic at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
unknown function (ip: 4200610)
julia_trampoline at C:\Julia-0.3.4\bin\libjulia.dll (unknown line)
unknown function (ip: 4202784)
unknown function (ip: 4199370)
unknown function (ip: 4199672)
BaseThreadInitThunk at C:\Windows\system32\kernel32.dll (unknown line)
RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line)
RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line)

I'm confused about the code written in util.jl and don't know whether I used a correct calling form of the function GLFW.SetKeyCallback(). Or something wrong with the glfwlib?

Remove GLFW 2 support

GLFW 3 has been out for close to 2 years and the package seamlessly installs it on 2 of 3 platforms (only Linux is lacking right now). It's probably not worth the effort of keeping GLFW 2 API support.

Version 2.0.0-alpha breaks interactive demo from GLVisualize

Hi,

with the newest version I am not able anymore to use drag and drop in GLVisualize. (Example: https://github.com/JuliaGL/GLVisualize.jl/blob/master/examples/interactive/graph_editing.jl)

This results in the following error:

ERROR: LoadError: MethodError: no method matching (::GLWindow.##23#24{Reactive.Signal{Tuple{Int64,In
t64,Int64}}})(::GLFW.Window, ::Int32, ::GLFW.Action, ::Int32)
Closest candidates are:
  #23(::Any, ::Int32, ::Int32, ::Int32) at C:\Users\thiem\.julia\v0.6\GLWindow\src\callbacks.jl:65
Stacktrace:
 [1] _MouseButtonCallbackWrapper(::GLFW.Window, ::Int32, ::GLFW.Action, ::Int32) at C:\Users\thiem\.
julia\v0.6\GLFW\src\callback.jl:60
 [2] #renderloop#39(::Float64, ::GLWindow.##40#42, ::Function, ::GLWindow.Screen) at C:\Users\thiem\
.julia\v0.6\GLWindow\src\render.jl:45
 [3] renderloop(::GLWindow.Screen) at C:\Users\thiem\.julia\v0.6\GLWindow\src\render.jl:40

The error occurs when I start to Drag a circle in the demo. Pinning to v1.5.0 fixes the problem.

glfwGetKeyName not exposed

julia> convert(Char, GLFW.KEY_5)
'5': ASCII/Unicode U+0035 (category Nd: Number, decimal digit)
julia> convert(Char, GLFW.KEY_KP_5)
'Ņ': Unicode U+0145 (category Lu: Letter, uppercase)

To get '5' from GLFW.KEY_KP_5, glfwGetKeyName would be useful. It was introduced in GLFW 3.2 released in June 2016.

Unix Build is missing when Pkg.add("GLFW")

If you do Pkg.add("GLFW") it should download the master which should include the unix_only lines in build.jl, which it doesn't ...
Is that, because the newest version is not included in METADATA?
Best,
Simon

GLFW error on Julia 0.5 on Linux with Mesa

I'm getting a seg fault on my Linux machines using GLFW.jl with the current Julia release whenever I try to create a window. I get this error on both of my Linux machines with Mesa (Ubuntu 16.04 and Debian 9). Both of these machines can, however, run GLFW with Julia 0.4, and can use GLFW without Julia. I am having no problems with Julia 0.5 and GLFW on Windows.

The error message on the Ubuntu 16.04 machine is the following after trying to create a window:

Cannot find target for triple amdgcn-- No available targets are compatible with this triple, see -version for the available targets.

signal (11): Segmentation fault
while loading no file, in expression starting on line 0
LLVMCreateTargetMachine at /home/nicolelislab/julia/usr/bin/../lib/libLLVM-3.7.1.so (unknown line)
unknown function (ip: 0x7fb7fe24fd6e)
unknown function (ip: 0x7fb7fe25005b)
amdgpu_winsys_create at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (unknown line)
unknown function (ip: 0x7fb7fdcce79e)
unknown function (ip: 0x7fb7fdf5ab93)
unknown function (ip: 0x7fb7fdf570ce)
unknown function (ip: 0x7fb7ffe4e502)
unknown function (ip: 0x7fb7ffe268a3)
glXQueryVersion at /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (unknown line)
unknown function (ip: 0x7fb801a39286)
unknown function (ip: 0x7fb801a35171)
glfwCreateWindow at /home/nicolelislab/.julia/v0.5/GLFW/deps/usr/lib/libglfw.so (unknown line)
CreateWindow at /home/nicolelislab/.julia/v0.5/GLFW/src/glfw3.jl:342
#create_glcontext#46 at /home/nicolelislab/.julia/v0.5/GLWindow/src/screen.jl:198
unknown function (ip: 0x7fb805e646d6)
jl_call_method_internal at /home/nicolelislab/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/nicolelislab/julia/src/gf.c:1945
create_glcontext at /home/nicolelislab/.julia/v0.5/GLWindow/src/screen.jl:181
create_glcontext at /home/nicolelislab/.julia/v0.5/GLWindow/src/screen.jl:181
unknown function (ip: 0x7fb805e62bdf)
jl_call_method_internal at /home/nicolelislab/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/nicolelislab/julia/src/gf.c:1945
do_call at /home/nicolelislab/julia/src/interpreter.c:66
eval at /home/nicolelislab/julia/src/interpreter.c:190
jl_toplevel_eval_flex at /home/nicolelislab/julia/src/toplevel.c:558 [inlined]
jl_toplevel_eval at /home/nicolelislab/julia/src/toplevel.c:580
jl_toplevel_eval_in_warn at /home/nicolelislab/julia/src/builtins.c:590
eval at ./boot.jl:234
unknown function (ip: 0x7fba2150bf8f)
jl_call_method_internal at /home/nicolelislab/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/nicolelislab/julia/src/gf.c:1945
eval_user_input at ./REPL.jl:64
unknown function (ip: 0x7fb805e2ea86)
jl_call_method_internal at /home/nicolelislab/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/nicolelislab/julia/src/gf.c:1945
macro expansion at ./REPL.jl:95 [inlined]
#3 at ./event.jl:68
unknown function (ip: 0x7fb805e2becf)
jl_call_method_internal at /home/nicolelislab/julia/src/julia_internal.h:189 [inlined]
jl_apply_generic at /home/nicolelislab/julia/src/gf.c:1945
jl_apply at /home/nicolelislab/julia/src/julia.h:1392 [inlined]
start_task at /home/nicolelislab/julia/src/task.c:253
unknown function (ip: 0xffffffffffffffff)
Allocations: 8345220 (Pool: 8341152; Big: 4068); GC: 15
Segmentation fault (core dumped)

The Debian 9 error message is similar, but does not include the first line because it uses a slightly different Mesa driver. I can post when I'm at that desk.

I suspect that Mesa and Julia 0.5 are using different LLVM versions, and something is getting confused during one of the calls. Anyone have any other ideas or possible solutions?

Thanks!

Improve build step on Linux

I've wanted to improve the build of GLFW, but I never got around to it and I still am not too motivated.
I open at least an issue, and describe what needs to be done for now.
On Unix, you need to have at least cmake installed. Is there an easy way to do this automatically?
On Ubuntu, I additionally need xorg-dev and libglu1-mesa-dev. We should be able to get them via BinDeps?!
Windows seems to be fine the way it is.
I don't know about any other operating systems.

Best,
Simon

ReadOnlyMemoryError

Hi, when I try to create a window using

window = GLFW.CreateWindow(800, 600, "test")

I get the following error:

ERROR: LoadError: ReadOnlyMemoryError() in CreateWindow(::Int64, ::Int64, ::String, ::GLFW.Monitor, ::GLFW.Window) at /home/andreas/.julia/v0.5/GLFW/src/glfw3.jl:351

Can you help me fix it? Thanks, Andreas

GLX API_UNAVAILABLE

Hi, I'm on:+

    julia 0.5
    system: NixOS (linux)

I import the module, but when I call:
window = GLFW.CreateWindow(640, 480, "GLFW.jl")
I get the following error:
ERROR: GLFWError (API_UNAVAILABLE): GLX: Failed to load GLX

Am I missing a Library? Don't know how to figure out how to fix it
Thanks, Nicolò

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.