- User Since
- Feb 27 2013, 12:20 AM (353 w, 5 d)
Thu, Dec 5
i think that there is one occurence here : doc/elementary_examples_cxx.dox: * @ref location_cxx_example_01
Wed, Nov 27
Wed, Nov 20
@ProhtMeyhet if there is no such warning on linux, then we can close the task
gcc for Windows, version 9.2.0. I guess that it does not detect that it is defined there :
btw, in code there are also TODO and XXX comments...
Tue, Nov 19
"Lastly, you've suggested to use cos rather than cosf before at D10467, jsuya agreed this patch as you can see his comment above. and I agree also."
is this accuracy really needed ?
Sat, Nov 16
to mimic Shakespeare:
Fri, Nov 15
so, what is the status of this diff ?
Thu, Nov 14
Nov 5 2019
Oct 31 2019
Oct 28 2019
btw cosf returns a float, not a double
Oct 11 2019
Oct 10 2019
Oct 9 2019
we can also increase _XOPEN_SOURCE to 700 (http://man7.org/linux/man-pages/man7/feature_test_macros.7.html)
otoh : https://lists.gnu.org/archive/html/autoconf/2010-08/msg00045.html it seems that we should not use __USE_UNIX98
@raster btw, eina_inline_posix_lock.x does:
@raster i've asked the user to export it to CPPFLAGS and issue vanished of course. I will provide a diff
@bu5hm4n i would say in eina as a user should not do extra work. Eina is using some features, it should enable them, imho.
it is garded. adding -D_POSIX_C_SOURCE=200809L in eina.pc (in CFlags) should be sufficient
Oct 8 2019
strlcat does not exist on Windows
Oct 7 2019
Oct 5 2019
Oct 4 2019
option b) is fine for me
Oct 3 2019
Note that elementary makes ephoto unresponsive. Certainly a problem on Windows. I have plenty of this message:
we have plenty of dependencies, so if we can remove some, that would simplify everybody's life
Oct 2 2019
shouldn't this be abandoned and rewritten for meson build system ?
should we add @private to the doc of the functions ?
Sep 30 2019
Sep 23 2019
Sep 16 2019
no, EFL_BUILD is set in config.h, which is also used by binaries. see toplevel meson.build
maybe this should have been detected with a unit test too, no ?
Sep 13 2019
i can't try the test, but i tried the code on a file, and it works with the change mentioned above
Sep 12 2019
i should add a typedef in evil_private.h then. ssize_t does not exist on Windows but SSIZE_T does
why is there a diff for benchmark ?
unmark err as unused
Sep 11 2019
mprotect is in evil now. i have to define HAVE_MMAP in evil_mman.h to check if there is no problem. I'll do that today
Sep 5 2019
Sep 4 2019
@stefan_schmidt is this a blocker for 1.23 ?
Sep 3 2019
actually, i've just checked : eina_config.h is generated independantly of eina_config.h.in
I just want to mention that long is a 32 bits type on Windows 64 bits, so you must pay attention at what is done on this platform when using long
Aug 31 2019
after checking, eina_config.h has no EINA_HAS_BUILTIN macro (at least on Windows) with latest git of today(august 31st 2019) with gcc as compiler. Is it normal ?
Aug 26 2019
Aug 23 2019
Aug 21 2019
Aug 20 2019
Aug 19 2019
Aug 18 2019
diff to review : #9542
include mman.h in raw generic module
I don't understand. It's like the other EFL header inclusions which are not part of the lib. Look at all the Eina.h inclusions for examples
Aug 10 2019
Aug 8 2019
i plan to remove sys/mman.h from evil and just a private evil_mman.h (included by evil_private.h)
Aug 6 2019
there is no mman.h on Windows, only in Evil. It's currently exported. I want to make it private in Evil (creates an evil_mman.h, included in evil_private.h), then :
Aug 5 2019
also, there are a lot of files that include sys/mman.h without guarding it with HAVE_SYS_MMAN_H. They must be guarded, right ?
Aug 4 2019
@raster yes, they are functionnaly equivalent. i've already implemented it on my computer. I'll provide a diff soon for it
@bu5hm4n you added the definition of HAVE_MMAN_H : https://git.enlightenment.org/core/efl.git/commit/header_checks/meson.build?id=46d464e5bfc10398461a33a2256c1c58d509dd1a
@raster VirtualProtect can be used. Also, mprotect exists in FreeBSD since BSD 4.4 (quite old), and is in POSIX 2001  and solaris