Azul doesn't work on macOS due to "not yet implemented" error (missing implementation of shared OpenGL contexts)

[andrew-ignatiev]

Description

Crash attempting to run the examples.

An unexpected panic ocurred, the program has to exit.
Please report this error and attach the log file found in the directory of the executable.

The error ocurred in: $HOME/.cargo/git/checkouts/azul-dependencies-70bb1f94316762f9/c154897/tomaka.glutin#23b3b10/src/platform/macos/mod.rs at line 61 in thread main

Error information:
not yet implemented

Backtrace:

azul::logging::set_up_panic_hooks::panic_fn @ logging.rs:86
core::ops::function::Fn::call @ function.rs:69
std::panicking::rust_panic_with_hook @ panicking.rs:478
std::panicking::begin_panic @ panicking.rs:408
glutin::platform::platform::Context::new @ mod.rs:61
glutin::combined::CombinedContext::new @ combined.rs:58
azul::window::create_gl_window @ window.rs:851
azul::window::Window<T>::new @ window.rs:539
azul::app::App<T>::create_window @ app.rs:287
calculator::main @ calculator.rs:403
std::rt::lang_start::{{closure}} @ rt.rs:64
std::panicking::try::do_call @ panicking.rs:293
 @ lib.rs:87
std::rt::lang_start_internal @ rt.rs:48
std::rt::lang_start @ rt.rs:64

Version / OS

• azul version: master
• Operating system: macOS Mojave version 10.14.4

Steps to Reproduce

git clone https://github.com/maps4print/azul.git
cargo build
cargo run --example calculator

Additional Information

Issue seems in statement below from $HOME/.cargo/git/checkouts/azul-dependencies-70bb1f94316762f9/c154897/tomaka.glutin#23b3b10/src/platform/macos/mod.rs at line 61, which runs panic on any example from list.

if gl_attr.sharing.is_some() {
    unimplemented!()
}

[fschutt]

It's because OpenGL context sharing isn't implemented on macOS yet: rust-windowing/glutin#899 - this needs to be fixed.

[fschutt]

There has been a fix for this problem in tene/azul-dependencies@ba909f4 - however, this has to be merged in the upstream glutin repository first. I don't want to monkey-patch downstream crates and not contribute the changes back to their original repositories.

[tene]

I've sent them a PR at rust-windowing/glutin#1132

[monomadic]

Any movement on this? Looks like the PR was merged into the glutin master a long time ago.

[jaspervdm]

Looks like this was included in glutin v0.21, but it also has some breaking changes which need to be implemented in glium. There is a WIP glium/glium#1739 started a month ago but I am not sure on its current status.

[est31]

TBH I kinda had other stuff to do so i didn't come back to it also there was no immediate need for me. But as you seem to have a need, I guess I should re-focus at working on it.

[est31]

glium 0.25 is released now on crates.io: https://crates.io/crates/glium/0.25.0

[monomadic]

It might be worth considering some kind of cross platform CI, as... this is supposed to be a cross platform gui framework and having it break on a major platform for months at a time probably defeats the purpose :P

Still keenly waiting for the changes, I could make a PR pointing to the new glium if you want? I took a look into the project though and it seems like a really super bizarre way of including dependencies, putting them into a pre-checked-out static repository on github, not sure if that's a great way of doing it nor intuitive for contributors, why not allow cargo to work the way it way intended?

[est31]

it seems like a really super bizarre way of including dependencies, putting them into a pre-checked-out static repository on github, not sure if that's a great way of doing it nor intuitive for contributors, why not allow cargo to work the way it way intended?

Indeed the path taken by azul is unusal. I recommend you read #95 for the reasoning.

[monomadic]

Thanks for clarifying. I know my opinion probably isn't needed or wanted, but I'll just state my experience here. When I see this kind of thing, I feel like the devs don't want to work with the rust and cargo ecosystem, and come up with rube-goldberg contraptions to get around a fairly non existent (or, perhaps, smaller) problem. If this is a flaw of cargo, petition and talk with the cargo devs, or use one of the many cargo workarounds... but... don't do /this/.

Communicable code is simple code.

This very thread is a great example of why the vendored git repo "solution" creates way way way more problems than it solves.

I actually contribbed to winnit and work on a few public rust projects relating to gui (among other things), and have been watching azul for a long time now considering helping out (have various reasons), but to be honest... I was scared off by this setup. It's way too complicated and awkward. Of course, it's your project and you have the right to run it any way you see fit - but I wonder how many other people came across this setup and turned away too.

Just my 2c. Good luck with azul :)

[est31]

This very thread is a great example of why the vendored git repo "solution" creates way way way more problems than it solves.

Could you outline why? In fact, the vendored solution allowed them to backport a fix into the vendored repo, as referenced in the comment above: tene/azul-dependencies@ba909f4

Now, it's definitely unusual. I only know of Deno and Firefox which vendor dependencies in their VCS, and those are applications and do this as a minor improvement over Cargo.lock based version pinning. I myself am not a fan of doing this vendoring for libraries. If every library would do it, your binaries would become extremely massive as there is no more duplication. But ultimately, @fschutt is the maintainer so it's their decision.

[monomadic]

Sure, this would be a one line addition in Cargo.toml as a new release fixes problems. If a crate starts breaking things without altering its minor version number, that's not a flaw in cargo, that's a flaw in both the library dev and your choice of packages to rely on.

Having vendored libs essentially bypasses cargo's package management, blows up the size of the install directory like crazy (every time the version changes, it will now fetch the entire package vendored directory again - have you checked your cargo cache?), increases install/compile time (no re-use across packages, downloading packages on first install + updates), and the time taken for the contrib dev to update a package and update the frozen directory is completely unnecessary. Why do we even have cargo if we do this? You're solving the wrong problem with a complex solution.

We aren't using golang or something with a bad package manager, so why do this?

Anyway, again, this is all just my opinion, obviously the package owner has every right to develop how he likes. But I think as a rust developer who actually likes the rust and cargo ecosystem, I probably wouldn't want to contrib to this even if I liked the project (which I do).

[fschutt]

I'm finished fixing the callbacks, now they don't segfault anymore, so fixing the dependencies is probably the next thing on my list. I still have my problems with cargos algorithm, but as azul now requires a fairly recent compiler (which was the main point about switching to vendored dependencies), it doesn't make sense to have them vendored, since it doesn't provide additional benefit (i.e. originally I did it to ensure compiler backwards compatibility, but that reason is gone now).

But I'm on vacation right now, not sure when I'll come back to fix it. I'll need to upstream all changes I made to azul-dependencies and then edit the Cargo.toml to unlock the dependencies again.

[billylindeman]

Thanks for clarifying. I know my opinion probably isn't needed or wanted, but I'll just state my experience here. When I see this kind of thing, I feel like the devs don't want to work with the rust and cargo ecosystem, and come up with rube-goldberg contraptions to get around a fairly non existent (or, perhaps, smaller) problem. If this is a flaw of cargo, petition and talk with the cargo devs, or use one of the many cargo workarounds... but... don't do /this/.

Communicable code is simple code.

This very thread is a great example of why the vendored git repo "solution" creates way way way more problems than it solves.

I actually contribbed to winnit and work on a few public rust projects relating to gui (among other things), and have been watching azul for a long time now considering helping out (have various reasons), but to be honest... I was scared off by this setup. It's way too complicated and awkward. Of course, it's your project and you have the right to run it any way you see fit - but I wonder how many other people came across this setup and turned away too.

Just my 2c. Good luck with azul :)

Not to beat a dead horse... but I definitely agree. I tried to run the examples and they didn't work, and I went in to fix it (since it's already fixed in glutin), and I couldn't figure out how to make it work - which then led me to this thread. Cargo may indeed have its issues, but the bigger problem here is that this project layout isn't ergonomic and it's hard to jump in and contribute. This situation makes me think of the golang proverb : Gofmt's style is no one's favorite, yet gofmt is everyone's favorite. I'd love to start contributing to azul because as of right now its the most exciting project that I've come across in years, and if you want to attract more contributors it'll help to reduce the barrier to entry.

[chanhsiaoyu]

is there some new workaroud ?

[chanhsiaoyu]

I tried to move glium0.25 from .cargo/registry to .cargo/git/checkout/azul-dependencies , and modified cargo.toml in azul-dependencies for the 0.25.0 thing. but still can't help for running the example in mac

[sassman]

glium = "0.25" depends on glutin = "0.21" and in there a couple of things like CombinedContext do not exist anymore. Especially on the migration guide there is nothing mentioned about this particular CombinedContext only that ContextTrait can be removed safely.

So after all I was also not able to cargo build

[lachlansneff]

So, does azul just not work on macos then? Is this going to get fixed?

[dignifiedquire]

It is still pretty broken, but I have a refactored version that uses latest glium, glutin and winit and makes a window on MacOS. You can find my fork here: https://github.com/dignifiedquire/azul

(It drops azul-dependencies, and the code is reorganized into standard rust project layout)

[dignifiedquire]

game of life is almost working

[sverro2]

Same problem here. @dignifiedquire 's fork does seem to be a few steps in the right direction (doesn't crash anymore and GUI at least seems to function). Will probably develop on another OS for now though...

[gsson]

Have a look at the https://github.com/maps4print/azul/tree/unvendor_dependencies branch. That branch is definitely where the party is at right now

[russoue]

I just experienced the same problem on Mac OS X 10.14.6:

An unexpected panic ocurred, the program has to exit.
Please report this error and attach the log file found in the directory of the executable.

The error ocurred in: /Users/me/.cargo/git/checkouts/azul-dependencies-70bb1f94316762f9/bf2933b/tomaka.glutin#23b3b10/src/platform/macos/mod.rs at line 61 in thread main

Error information:
not yet implemented

Backtrace:

azul::logging::set_up_panic_hooks::panic_fn @ logging.rs:86
core::ops::function::Fn::call @ function.rs:69
std::panicking::rust_panic_with_hook @ panicking.rs:481
std::panicking::begin_panic @ panicking.rs:411
glutin::platform::platform::Context::new @ mod.rs:61
glutin::combined::CombinedContext::new @ combined.rs:58
azul::window::create_gl_window @ window.rs:890
azul::window::Window<T>::new @ window.rs:483
azul::app::App<T>::create_window @ app.rs:211
my-azul-app::main @ main.rs:32
std::rt::lang_start::{{closure}} @ rt.rs:64
std::panicking::try::do_call @ panicking.rs:296
 @ lib.rs:80
std::rt::lang_start_internal @ rt.rs:48
std::rt::lang_start @ rt.rs:64

[monomadic]

game of life is almost working

amazing work! I actually switched to linux in the time that this bug has been open, I might give your fork a spin here and see how things go.

[allevo]

Any updates?
Can I help somehow?

[Spleeding1]

Having same issue with macOS 10.15.1.

[niklasbuesing]

Same issue on windows

[benjaminbours]

Same issue here on macOs Mojave 10.14.6. If the fork of @dignifiedquire seems good, can this be merged into the main Azul repo? Let's provide a good experience for new users from macOs! 😄

[tsal]

I'd also be willing to contribute to this, as I'm in need of a cross-platform UI, and this one fits the bill in every case except my development environment and one of my build targets. However, as stated by others, there's an entry barrier here and I think the fork being merged in would be a great step towards removing that barrier.

[mokeyish]

Same issue on windows macOs

[Spleeding1]

So this post says to refer to #241 and was closed. Post #241 is closed because it is a duplicate of #131, or this one. @fschutt, did you notice that? was this issue resolved?

[fschutt]

@Spleeding1 This issue is resolved, but not on the master branch. That's why it's still an open issue. The wip branch doesn't have this problem, but it doesn't compile (still working on it).

I am aware of rendering issues in multi-window apps and I'll probably have to revert the system to use one WrRenderer per window, because otherwise, webrender has flickering problems. Then, shared OpenGL contexts won't be needed anymore, but the app will consume a little bit more memory.

[fschutt]

This should be solved now on the master branch. I have reverted the original change to a shared GL context, since it obviously doesn't work on all drivers. The original idea was to share the WrRenderer instance to consume less memory, but reliability is more important.

Shared OpenGL contexts will come back once I get to working on off-main OpenGL rendering. For now, multi-window apps should be possible (see CallbackInfo.create_window) and the crash should not happen anymore (since a new, separate WrRenderer is created for each new window). Please reopen if this issue still exists.