For now fixed in the meson ( devs/bu5hm4n/meson) fixed with D6865. works.
Jan 22 2019
Jan 14 2019
Aug 25 2018
Aug 18 2018
@jayji that is very good news. :)
Aug 17 2018
I don't know if this will help, but ecore_cocoa_clipboard_set() (that calls evas_textblock_text_markup_to_utf8) is beta API (the whole cocoa clipboard API is). It was (badly) designed to be used by Elementary only. Maybe the caller of this function can run the evas_textblock_text_markup_to_utf8() first, and pass its output as the data parameter?
Aug 16 2018
Then feel free to refactor the textblock apis into a static lib,
No, that's definitely not a viable solution for us.
Or just quick and dirty dlsym'ing evas_textblock_text_markup_to_utf8 ?
I agree that it probably should not, but this is how the code is written.
Jul 25 2018
This is probably a symptom of T6940.
Jul 4 2018
Ah I misunderstood sorry.
I had thought it was something else from the description.
If it's not visible then I agree it's not a 1.21 problem.
Jul 3 2018
It's a race condition based on a timing issue. It's entirely possible that there is no visible sign of this, which is why I removed it from the 1.21 milestone.
I actually can't replicate this here - is there a small code snippet that I can use?
Jun 29 2018
The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.
I don't see a crash?
Hey @ajwillia.ms that sounds good :)
Jun 28 2018
Hi @netstar if you're not succeeding I will look - this should really get fixed for 1.21
It seems like this was resolved.
I think probably there are more important issues for the 1.21 release, let's table it for now.
Jun 22 2018
I'll take a look at it. No promises! I've some free time though.
Here you go mike: https://phab.enlightenment.org/D6366
Is this still an issue?
If someone in this ticket isn't interested in resolving this soon then the 1.21 milestone tag should be dropped...
Yes, but what about when it is just setting ->key to the event member? Is this memory guaranteed to persist too?
Jun 21 2018
Should be okay and point to valid address in data segment I reckon?
@netstar and what about the key string allocation?
This was causing issue in Fyne.io using EFL.
I can have a little look.
Jun 20 2018
I'm not an expert on mac system programming or whatever language the .m files are written in.
Jun 14 2018
Reopen if this recurs.
Jun 12 2018
Jun 11 2018
Jun 10 2018
I think this works here...
@jayji still relevant for you?
May 15 2018
The window rendering seems fine on resize here?
@zmike sd->deferred_resize_job=1 fixes the issue
May 14 2018
Dec 29 2017
@netstar this time it is not thanks to me, someone made a fancy patch that happened to fix the build :)
yeh it worked, built last night ! thanks @jayji
Dec 28 2017
hhahaha. yay christmas! :) unfortunately i have no macs to test on... for windows i have now set up a cross-compile env for building windows targets. i actually have a windows laptop that i transferred into a vm image (trust me. that took over a day of dumping disk images and so on and it wasn't pretty). i have a freebsd vm. but nothing for osx. so i have to rely on you osx users to pick up those pieces. :(
Fixed by some Christmas magic :)
Dec 20 2017
yargh... ok. hmmm then why... :/ :\ :|
Sorry, still the same :(
aaah but it expands WHEN EWAPI is #defined... not later on. so it has to be re #defined again. i just tried that now. remember cpp is dumb. it expands WHEN the token/macro is seen... not later on when "used". :)
Yes, when I wrote EAPI, it is because EWAPI expands to EAPI and something else I don't remember.
yargh! i think EWAPI has something to do with it though... as
If EAPI is not defined when those symbols are encountered, we are doomed.
In elc_ctxpopup.c for example (which includes elm_ctxpopup.eo.h, and therefore has the first DECLARATION of _ELM_CTXPOPUP_EVENT_DISMISSED) we already are outside of Elementary.h, so that's dead.
Nope, still not working.
odd. it works on linux and i use -fvisibility=hidden ... but #including elm_ctxpopup.eo.h in Elementary.h (the public header) is wrong as long as it is not installed:
Dec 19 2017
@jayji thanks very much!
And there are cyclic includes as well:
What was done in evas_font.h in D5419: Remove evas internal dependency from the evas_font module seems pretty weird to me. Why do we re-define EAPI there?
I'll have a look at this, haven't built efl on mac for a while.
It would be much nicer if we had a meson build to speed up build time :/
This is a mystery... I tried using dlsym and only got more errors.
See travis build 900: https://travis-ci.org/Enlightenment/efl/jobs/318462374
Undefined symbols for architecture x86_64: "_evas_common_font_cache_get", referenced from: _eng_font_cache_flush in modules_evas_engines_gl_generic_module_la-evas_engine.o _eng_font_cache_get in modules_evas_engines_gl_generic_module_la-evas_engine.o "_evas_common_font_cache_set", referenced from: _eng_font_cache_flush in modules_evas_engines_gl_generic_module_la-evas_engine.o _eng_font_cache_set in modules_evas_engines_gl_generic_module_la-evas_engine.o "_evas_common_font_draw", referenced from: _eng_font_draw in modules_evas_engines_gl_generic_module_la-evas_engine.o "_evas_common_font_draw_prepare", referenced from: _eng_font_draw in modules_evas_engines_gl_generic_module_la-evas_engine.o "_evas_common_font_flush", referenced from: _eng_font_cache_flush in modules_evas_engines_gl_generic_module_la-evas_engine.o "_evas_common_font_glyph_uncompress", referenced from: _evas_gl_font_texture_new in libevas_engine_gl_common.a(modules_evas_engines_gl_common_libevas_engine_gl_common_la-evas_gl_font.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [modules/evas/engines/gl_generic/module.la] Error 1
Without my own build environment I don't know what to do.
But I suspect that somehow evas_engines_gl_generic_module is just not linked to libevas. I tried adjusting configure.ac and
Dec 14 2017
Just a note. When we get to a stage where the build works, I'm quite happy to build daily so that hopefully this sort of thing can be caught as and when it happens.
Dec 8 2017
@smohanty can you please have at least a look at this? It broke the compilation on OSX which was working fine before.
Dec 1 2017
It is indeed. Esepcially if you have your own branches and what to see that some basic build testing works on osx for example. I just need to find more time to extend it further.
Nov 30 2017
Full build log: https://travis-ci.org/Enlightenment/efl/jobs/309383396