[graton]

Not when I read the replies to that reply.

  @Carsten_Haitzler said:

  as for the "you bitch" comment. that does not appear anywhere inside efl at asll. i can only assume you are full of bullshit here as with a lot of the prior "facts" you have disclosed, as a grep through our codebase for efl and elementary shows no such string:

  core/efl.git - EFL core libraries
  evas - change error out from bitch to complain - cosmetic changeHEADmaster
  committer Carsten Haitzler (Rasterman) [e-mail]	2015-03-11 12:59:01 (GMT)

  F#*k off.

[int_19h]

Reading through some of these replies further down the thread, they seem to confirm the basic notion that EFL docs are really poor. Examples:

> key names - no - we didn't document it, but it'll be the same set as you get in x11. we emulate it elsewhere. yes- maybe we should explicitly document that but to date no one has actually complained

> if its a const char * of course you don't free - if it's a char * return (example) it'll be documented as to how to free it. if its' objects - objects stay alive until you delete them ... or the canvas they live in is deleted, or an object that has taken ownership is deleted (and objects that take ownership are in charge of deletion). it's the same throughout efl - its similar to gtk in that sense. it hasn't been explicitly documented i guess because it's a convention that is common enough.

On dynamic typing, and checking object types - and why it's a warning rather than hard error when a type doesn't match what's expected:

> default is to march on and recover with a complaint - the complaint is your signal to enable this next time you run and hunt down the detail. ... mostly the errors are harmless. the majority of code marches on fine - thus prefer staying alive over suddenly falling over.

[coldtea]

>Not when I read the replies to that reply.

Even more so after one reads the replies.

Perhaps we didn't read the same reply?

Because the response you've posted:

1) only addresses one of the tens of points in the reply -- the others still being valid.

2) while true, it is still irrelevant from a technical standpoint (not to mention softened in the subsequent version anyway).

3) At worst, the Evas author failed to grep the right version for it. Whereas the ranter, at best, fails to understand C coding, failed to consult documentation that was right there, complaints for valid behavior, cites several wrong facts about the behavior of the code (like the supposed "512" object limit), and closes with the BS "it will take man-years" to build a sample simplistic media player with the lib (using a ready made codecs/media player widget component).

Evas/Eve etc have some questionable design decisions, and not the best documentation. But the original post is full of crap in almost every aspect, and with unwarranted language to boot.

[tigershark]

Are you an EFL developer or the author? I have read the whole 19 pages of comments, plus the sister thread on os news, and you are the only one that can't understand all the problems in that ball of sh*t apart from the EFL author and his coworker. In any case I would prefer to lose an hand than to work with someone like you for which writing non type-safe C code, with 40 vulnerabilities discovered by a single researcher, is perfectly fine.

[lfowles]

A little bit more context I had to go look up: the response is also dated 11 Mar 2015

[coldtea]

And as the author of the code writes 2-4 times, he looked for the literally mentioned quote and didn't find it -- he even posted the grep results.

He only found that it was "bitch" (single word) later from a later corrected comment and fixed it (out in the open, in the the public code repository in any way).

In any case, again, not technical, not a WTF, and not pertaining to the actual code/implementation.

[int_19h]

The author of the code is the one who added that word to the code in the first place. You'd think he might remember that, even if the wording of the complaint was off.

https://git.enlightenment.org/legacy/evas.git/commit/src/lib...

https://git.enlightenment.org/legacy/evas.git/commit/src/lib...

If he does not, that invites the question of how many similar error messages are there in the code. Note that this is something that actually gets printed to stdout - in other words, if there's a bug in your app (or EFL, for that matter), your end user might see that message. I would dare say that's a pretty big WTF.