I've git cloned a new copy and this seems to be gone. Only guess I have is that ninja didn't clean everything or maybe some meson bug.... Only thing remains now are some unused warnings in generated .eo.c code and a format error :D :

hum, eina_config.h has a #pragma once in its head. I know that is not a standard way.

In D11368#221836, @stefan_schmidt wrote:

@bu5hm4n, @ProhtMeyhet are you happy with the rebased version now?

Overall I like this idea :-)

In T8624#151063, @netstar wrote:

No, that's the index value within the parts. parts_count - 1.

In T7133#151049, @yasarciv67 wrote:

The subject was pretty late. Can you give me a clear answer about this problem? Is it just a problem for me or a general problem?

another post

In T8622#151024, @Peter2121 wrote:

I am not sure that it is really FreBSD specific, but I cannot test on Linux now.

@seeker could you write us a patch? Either upload it here or create a diff here. Any other textform (email, paste) would probably also helpful, but less desirable.

also why is the ERR substracting -1 from pc->parts_count, while in the if it is not? Either the the if is wrong or the ERR debug output will not give you the actual information.

This error was introduced in e8e637a79a6 . @netstar, could you please have a look?

Is this on BSD? And on X11?

In D11471#218594, @ali.alzyod wrote:

I think there are alot of similar cases in the source code

The parameter for git diff that shows you more lines to see if obj is used is -U

In D11368#216816, @akanad wrote:

in the github link, a patch looks like below.

In D11377#216819, @bu5hm4n wrote:

Please keep in mind that this is legacy API. If we change something like this. Then we have a quite big chance that we will cause hard trouble for people that wrote apps with efl. Why not just leave it as it is, and *not* cause any trouble? The performance impact here cannot be that bad, yet i am still missing a single prove that this lines causes any performance issues... On the other side, if someone complained about this using too much time if you pass NULL, NULL simply DO NOT CALL IT THEN.

In D11377#216690, @segfaultxavi wrote:

The if(w) and if(h) are rather standard ways to say "If the caller provided a place to store this data, then store it, otherwise do nothing". It is convenient for those cases were the caller is only interested in some of the return values, because it does not need to provide storage space for data it is not interested in.

In D11377#216669, @segfaultxavi wrote:

Calling these methods with w == h == NULL looks like an error. Shouldn't we print something? Maybe with an EINA_SAFETY macro?

In D11297#214885, @segfaultxavi wrote:

But if you want to do it beautiful, this could be a meson configure option ?

... and I should be be giving more details. The difference I see between those two is just the following

In T8217#150357, @mbert wrote:

Sorry, I noticed this comment a bit late. Here's the output you were asking for.

Before:

before.txt1 KBDownload

After:

after.txt1 KBDownload

In D11297#214845, @bu5hm4n wrote:

Correct :)

general question: without this

Could you please in the future add tags on your own? A priority would be helpful as well.

*cough* *cough* please, Simon, you are capable of adding tags on your own. Please do in the future.

ahhhrg, just running it in gdb gives me a bus error:

In D11171#213982, @bu5hm4n wrote:

Oh, now that is interesting - can you create a ticket, and share the backtrace there ?

I compiled with ggc-9.2

In D11171#213897, @bu5hm4n wrote:

elementary_test fails because errors are now printed.

this is really turning into a hunt.

Follow up on D11237. Please see T8591 for details.

In D11171#213004, @bu5hm4n wrote:

Sounds like a good idea, however, now the tests dont pass anymore :/

meh [insert profanity]

In T8593#150205, @raster wrote:

have you thought of providing the openjpeg devel pkgs like all other devel pkgs for deps... or disabling the jp2k loader? :)

In T8592#150196, @cedric wrote:

Yes, it is resolved. Twitter bug report is the future :-)

For edje resolved: D11237 .

I didn't want to put this in the commit comment. Please see T8591 for details.

In T8591#150176, @devilhorns wrote:

From a compiler stand point, I do not think that it actually makes a difference ... tho that Could depend on the compiler. It's been EFL preference that they come After so if you would like to make some patches to fix those, that would be great.

In T8591#150172, @devilhorns wrote:

Normally, we use it After the variable

yeah! my first commit!

the do { } while(0) there doesn't help either, but my uploaded file was one without this adjustment.

In D11189#213028, @bu5hm4n wrote:

@ProhtMeyhet what is the problem with the macro ?

Also - can you ensure that the tests do pass ?

In T8581#150127, @stefan_schmidt wrote:

I can't comment on all of it but here are my thoughts on this.
We should try to configure phab to have like a template bug report users can use to fill in details we would need for debugging. Adding a default efl or enlightenment tag (unknown maybe) could be a good idea. A template should also tell them what to put in the tag (if they build from git, use a distro package,e tc)

In T8581#150128, @zmike wrote:

The numbered tags are milestones. Phabricator automatically closes the previous milestone when a new one is created, and there's no way (that I'm aware of) to change this behavior without modifying the underlying code.

updated the same "fix" to the other functions in eina_legacy.c. Does not change functionality.

only thing I'm not sure about is if I should use EINA_SAFETY_ON_NULL_RETURN as part is an argument to those functions and the macro EINA_SAFETY_ON_NULL_RETURN would at least log that there has been a NULL given.

Isn't the EINA_UNUSED wrong on the function argument Eo *obj ? Because the macro GET_REAL_PART_ON_FAIL_RETURN looks like this and it includes obj

I think you should better use the macro EINA_SAFETY_ON_NULL_RETURN here, and probably before GET_REAL_PART_ON_FAIL_RETURN().

I am become death, the destroyer of worlds.

Cowards die many times before their deaths,
The valiant never taste of death but once.

In T8316#149901, @Thanatermesis wrote:

It doesn't change, same issue

It seems to be related to the default theme

Is this still an issue?

I can't reproduce this.

Is this still an issue? I seem to remember raster changed something with multiple keyboard layouts... can't find it atm, though.

can you please post the output of the following terminal commands before and after this happens?

In D11144#211109, @zmike wrote:

I went full stupid and only needed like 70% stupid

This assignment/declaration itself is not a problem

Don't forget there is already ecrire which could serve as a quick start.

@jayji could you have a look? It's from your commit c03876d611fca41d02513fb07d3d275f64bcf0cd and also has a FIXME there:

Could you please post the compiler warnings? Because just casting a return value like the following will solve compiler warnings, but sadly may just solve those, but - worse - may not resolve any bugs, but even hide them in the future. Especially this strlen call doesn't seem right:

Yep, I don't think this is fixable as EFM is tightly integrated for various reasons into the enlightenment display manager itself.

Also, please state again here so those who could solve it will know:

Could you please tell us which version of enlightenment you are using and on which OS/Distribution? Or are you on Git and build yourself?

testing a bit more, this script is very effective for stopping e for up to 5 seconds for me. First send a via notify-send which returns immediately, start date and then shellementary. Needs a bit higher load and a hardware accelerated video playing. Browsers like Firefox and Chromium are helpful as well. Restarts after 900 seconds which seems enough to purge the kernel cache of shellementary and its librarys.

For me I've found a relatively reliable testcase for this: shellementary. When I play a video, have a browser open and a system load roughly equal to the number of cpu cores, e hangs for up to 5 seconds when opening it the first time. So it seems either e or Xorg is waiting for the creation of this window, but shellementary sometimes takes too long (maybe on memory init?)

In D10890#205001, @segfaultxavi wrote:

This table complicates things for users that know both APIs (C and C#). Imagine somebody debugging a C# method and trying to set breakpoints in C functions.
What is worse, this includes us, the maintainers! We will need to memorize this table to know if progressbar translates to Progressbar or ProgressBar, and this will make development slower.

Also, we are trying to create a new, clean API, free from the problems from Legacy. Creating this table means that we start having "legacy unified names" which we don't like but we cannot change.