Re: [E-devel] curl 7.29.0 segfaults Enlightenment and Terminology
Bug in libcurl, not in EFL. Has been fixed upstream https://github.com/bagder/curl/commit/da3fc1ee91de656a30f3a12de394bcba55119872 Date: Fri, 8 Feb 2013 17:10:54 +0100 From: mats.bertil.teg...@gmail.com To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] curl 7.29.0 segfaults Enlightenment and Terminology On 02/08/2013 04:49 PM, enlightenment-devel-requ...@lists.sourceforge.net wrote: Send enlightenment-devel mailing list submissions to enlightenment-devel@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/enlightenment-devel or, via email, send a message with subject or body 'help' to enlightenment-devel-requ...@lists.sourceforge.net You can reach the person managing the list at enlightenment-devel-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of enlightenment-devel digest... Today's Topics: 1. Re: curl 7.29.0 segfaults Enlightenment and Terminology (e-crashdump) (Andrey Ponomarenko) May be this report can help: http://upstream-tracker.org/pkgdiff_reports/libcurl/7.28.1_to_7.29.0/changes_report.html The curl_multi_cleanup function is defined in lib/multi.c and its implementation has been seriously changed: http://upstream-tracker.org/pkgdiff_reports/libcurl/7.28.1_to_7.29.0/diffs/lib/multi.c-diff.html See also: http://upstream-tracker.org/versions/libcurl.html Thanks for the links. I will check them out. Mats -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
Hello. On 11/01/13 07:21, Nicolas Aguirre wrote: I don't think so, cross compilation is better in any case, it's faster, it's easy, and it's already present in almost all recent distributions. It's also easy to build for 32 and 64 architecture with no extra cost. About the windows version i don't know exatcly but i think you're right with xp you should target all later versions. if you want to set up your machine for a build, Vincent did a build of all dependencies http://dev.enlightenment.fr/~doursse/efl_dep.zip it's for 32bits only architecture. Then you need to install mingw-w64 and gcc-mingw-w64-i686 Once unzip you only need to export few env vars : base=`pwd` export TARGET=i686-w64-mingw32 export MINGW_PREFIX=$base/package/ I had to remove the packgae here as the zip unpacks without any package subdir for me. Only change I did to this. export CPPFLAGS=-I$MINGW_PREFIX/include -I$MINGW_PREFIX/include/evil-1 -I$MINGW_PREFIX/include/freetype2 export CXXFLAGS=$CFLAGS export LDFLAGS=$LDFLAGS -L$MINGW_PREFIX/lib export PATH=$HOME/local/opt/mingw-w64-x86_32/bin:$MINGW_PREFIX/bin:$PATH export LD_LIBRARY_PATH=$MINGW_PREFIX/lib export PKG_CONFIG_PATH=$MINGW_PREFIX/lib/pkgconfig export PKG_CONFIG_LIBDIR=$MINGW_PREFIX/lib/pkgconfig and then you can compile as usual efl : ./autogen.sh --prefix=$MINGW_PREFIX --host=$TARGET --disable-static Thanks for posting this. And major thanks to Vtorri to prepare all this. That's all, it's really easy, and we don't need a real windows machine for that. Of course if you want automated it's better, but i don't think we have man power for this. I did take a stab and integrating this into my local jenkins here today. I made some good progress but run out of motivation for more work. My configure line looks like this now: ./autogen.sh --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-crypto=none --disable-physics --disable-gstreamer --with-tests=none --disable-fribidi --disable-image-loader-gif --disable-audio This is mainly due to workaround not having pre-compiled stuff for things like giflib, check, etc. After that I had to discover that someone was happy to do changes to the ecore_evas w32 engine without bothering to test or even simply check a variable is declared before assigning to it. :/ I fixed up the most bogus things and that part builds now. Next was eina_mmap failing due to stuff no available on Windows. Here I lost motivation. So yes, setting it up is easy and not that much trouble. If someone takes up on thsi I might even consider leaving this automated build for mingw in once I move our jenkins stuff out to e5. But it only makes sense if people want the build to work for w32. Personally I don't have any use of it. regards Stefan Schmidt -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
Hello. On 11/02/13 13:53, Stefan Schmidt wrote: I fixed up the most bogus things and that part builds now. Next was eina_mmap failing due to stuff no available on Windows. Here I lost motivation. If anybody has interest in this: CC lib/eina/lib_eina_libeina_la-eina_accessor.lo CC lib/eina/lib_eina_libeina_la-eina_array.lo CC lib/eina/lib_eina_libeina_la-eina_benchmark.lo CC lib/eina/lib_eina_libeina_la-eina_binbuf.lo CC lib/eina/lib_eina_libeina_la-eina_binshare.lo CC lib/eina/lib_eina_libeina_la-eina_convert.lo CC lib/eina/lib_eina_libeina_la-eina_counter.lo CC lib/eina/lib_eina_libeina_la-eina_cpu.lo CC lib/eina/lib_eina_libeina_la-eina_error.lo CC lib/eina/lib_eina_libeina_la-eina_fp.lo CC lib/eina/lib_eina_libeina_la-eina_hamster.lo CC lib/eina/lib_eina_libeina_la-eina_hash.lo CC lib/eina/lib_eina_libeina_la-eina_inarray.lo CC lib/eina/lib_eina_libeina_la-eina_inlist.lo CC lib/eina/lib_eina_libeina_la-eina_iterator.lo CC lib/eina/lib_eina_libeina_la-eina_lalloc.lo CC lib/eina/lib_eina_libeina_la-eina_list.lo CC lib/eina/lib_eina_libeina_la-eina_log.lo CC lib/eina/lib_eina_libeina_la-eina_magic.lo CC lib/eina/lib_eina_libeina_la-eina_main.lo lib/eina/eina_main.c: In function 'eina_init': lib/eina/eina_main.c:253:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] CC lib/eina/lib_eina_libeina_la-eina_matrixsparse.lo CC lib/eina/lib_eina_libeina_la-eina_mempool.lo CC lib/eina/lib_eina_libeina_la-eina_mmap.lo lib/eina/eina_mmap.c:71:24: error: unknown type name 'siginfo_t' lib/eina/eina_mmap.c: In function 'eina_mmap_safety_enabled_set': lib/eina/eina_mmap.c:133:27: error: storage size of 'sa' isn't known lib/eina/eina_mmap.c:154:14: warning: implicit declaration of function 'fcntl' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:154:48: error: 'F_GETFD' undeclared (first use in this function) lib/eina/eina_mmap.c:154:48: note: each undeclared identifier is reported only once for each function it appears in lib/eina/eina_mmap.c:155:23: error: 'FD_CLOEXEC' undeclared (first use in this function) lib/eina/eina_mmap.c:156:40: error: 'F_SETFD' undeclared (first use in this function) lib/eina/eina_mmap.c:161:27: error: '_eina_mmap_safe_sigbus' undeclared (first use in this function) lib/eina/eina_mmap.c:162:23: error: 'SA_RESTART' undeclared (first use in this function) lib/eina/eina_mmap.c:162:36: error: 'SA_SIGINFO' undeclared (first use in this function) lib/eina/eina_mmap.c:163:9: warning: implicit declaration of function 'sigemptyset' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:164:9: warning: implicit declaration of function 'sigaction' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:164:23: error: 'SIGBUS' undeclared (first use in this function) lib/eina/eina_mmap.c:133:27: warning: unused variable 'sa' [-Wunused-variable] make[4]: *** [lib/eina/lib_eina_libeina_la-eina_mmap.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 regards Stefan Schmidt -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'. You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: Fix memory leak in function xyz If the allocation of foo fails the error path doesn't clean up correctly which leads to variable bla being leaked. Clean up correctly and exit. Similarly, the individual commits shouldn't be too large. I don't want you to commit every line change separately, but git allows you to commit a bunch of stuff locally before pushing it upstream. What was one large commit in SVN can be broken up into several smaller ones in Git. This makes commits much easier to review (as does a proper commit message, hint, hint). If you do have a larger feature that requires tens of commits please don't just dump them into upstream Git at once, but develop them publicly in a topic branch (see topic branches) and merge them when they are
[E-devel] SVN-Git migration guide
Apologies for the double send, but someone forgot to set the subject correctly (at all)... Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'. You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: Fix memory leak in function xyz If the allocation of foo fails the error path doesn't clean up correctly which leads to variable bla being leaked. Clean up correctly and exit. Similarly, the individual commits shouldn't be too large. I don't want you to commit every line change separately, but git allows you to commit a bunch of stuff locally before pushing it upstream. What was one large commit in SVN can be broken up into several smaller ones in Git. This makes commits much easier to review (as does a proper commit message, hint, hint). If you do have a larger feature that requires tens of commits please don't just dump them into upstream Git at once, but
[E-devel] New python bindings in a merged tree
I forward to this ml for who dont follow the commit-ml: Put in a first, still wip, version of the python bindings in a merged tree. This is meant to be the 1.8 version of the wrappers and will include everything that now is in the python folder. Atm this include evas, ecore, edje, elementary and emotion (emotion still commented in the build couse it need some more testing). Eo is used as a base for all the objects that inherit from it in C, but in real nothing is used from Eo, it is used more like a container to share code between the libs. All the docs has been stripped out because we want to use the new sphinx style docs that Kay has done in his git repo. (Kay: please wait a little bit to include it, as working on the libs without docs is much more easy) The new wrappers include a new container module called efl and thus you can live with both the old and the new installation. This also means that you need to import the new modules as: from efl import evas (instead of the old import evas) The idea here is that you can make your code works with both version doing something like: try: import evas except: from efl import evas ...like is done in the gtk bindings Some stuff has been leaved out on purpose, because was old stuff (like the hacked evas rotation stuff) or because was not working as expected (like all the ecore.evas.XXX modules). See the TODO.txt file for more info. Probably some stuff is out just because I missed them, let me know if you miss something. Improvements from the old version: - Py3 compatible (still some work to be done, but really only TODO, no problems to resolv) - Should also works on other platforms, like windoz (but not tested) - Unittests greatly improved, you can also run ALL tests at once - much more simpler :) I will contine the works in the next weeks and hope someone will help too. NOTE: I switched back to setup.py instead of autotools, because that is the right way to compile python stuff. So to build just use: python setup.py install or python3 setup.py install Enjoy davemds -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
As a humble e tester many thanks for the info. Tarball -cvs -svn - git. still enjoying the ride and the result! Cheers M On 11 February 2013 17:07, Daniel Willmann d.willm...@samsung.com wrote: Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'. You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: Fix memory leak in function xyz If the allocation of foo fails the error path doesn't clean up correctly which leads to variable bla being leaked. Clean up correctly and exit. Similarly, the individual commits shouldn't be too large. I don't want you to commit every line change separately, but git allows you to commit a bunch of stuff locally before pushing it upstream. What was one large commit in SVN can be broken up into several smaller ones in Git.
Re: [E-devel] efl merge and win32
Hello, On Mon, Feb 11, 2013 at 10:56 PM, Stefan Schmidt s.schm...@samsung.com wrote: Hello. On 11/02/13 13:53, Stefan Schmidt wrote: I fixed up the most bogus things and that part builds now. Next was eina_mmap failing due to stuff no available on Windows. Here I lost motivation. If anybody has interest in this: CC lib/eina/lib_eina_libeina_la-eina_accessor.lo CC lib/eina/lib_eina_libeina_la-eina_array.lo CC lib/eina/lib_eina_libeina_la-eina_benchmark.lo CC lib/eina/lib_eina_libeina_la-eina_binbuf.lo CC lib/eina/lib_eina_libeina_la-eina_binshare.lo CC lib/eina/lib_eina_libeina_la-eina_convert.lo CC lib/eina/lib_eina_libeina_la-eina_counter.lo CC lib/eina/lib_eina_libeina_la-eina_cpu.lo CC lib/eina/lib_eina_libeina_la-eina_error.lo CC lib/eina/lib_eina_libeina_la-eina_fp.lo CC lib/eina/lib_eina_libeina_la-eina_hamster.lo CC lib/eina/lib_eina_libeina_la-eina_hash.lo CC lib/eina/lib_eina_libeina_la-eina_inarray.lo CC lib/eina/lib_eina_libeina_la-eina_inlist.lo CC lib/eina/lib_eina_libeina_la-eina_iterator.lo CC lib/eina/lib_eina_libeina_la-eina_lalloc.lo CC lib/eina/lib_eina_libeina_la-eina_list.lo CC lib/eina/lib_eina_libeina_la-eina_log.lo CC lib/eina/lib_eina_libeina_la-eina_magic.lo CC lib/eina/lib_eina_libeina_la-eina_main.lo lib/eina/eina_main.c: In function 'eina_init': lib/eina/eina_main.c:253:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] CC lib/eina/lib_eina_libeina_la-eina_matrixsparse.lo CC lib/eina/lib_eina_libeina_la-eina_mempool.lo CC lib/eina/lib_eina_libeina_la-eina_mmap.lo lib/eina/eina_mmap.c:71:24: error: unknown type name 'siginfo_t' lib/eina/eina_mmap.c: In function 'eina_mmap_safety_enabled_set': lib/eina/eina_mmap.c:133:27: error: storage size of 'sa' isn't known lib/eina/eina_mmap.c:154:14: warning: implicit declaration of function 'fcntl' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:154:48: error: 'F_GETFD' undeclared (first use in this function) lib/eina/eina_mmap.c:154:48: note: each undeclared identifier is reported only once for each function it appears in lib/eina/eina_mmap.c:155:23: error: 'FD_CLOEXEC' undeclared (first use in this function) lib/eina/eina_mmap.c:156:40: error: 'F_SETFD' undeclared (first use in this function) lib/eina/eina_mmap.c:161:27: error: '_eina_mmap_safe_sigbus' undeclared (first use in this function) lib/eina/eina_mmap.c:162:23: error: 'SA_RESTART' undeclared (first use in this function) lib/eina/eina_mmap.c:162:36: error: 'SA_SIGINFO' undeclared (first use in this function) lib/eina/eina_mmap.c:163:9: warning: implicit declaration of function 'sigemptyset' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:164:9: warning: implicit declaration of function 'sigaction' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:164:23: error: 'SIGBUS' undeclared (first use in this function) lib/eina/eina_mmap.c:133:27: warning: unused variable 'sa' [-Wunused-variable] make[4]: *** [lib/eina/lib_eina_libeina_la-eina_mmap.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 There is apparently no windows implementation of eina_mmap_safety_enabled_set (signal don't exist on windows). The idea of this function is to setup a sigbus handler to detect access to corrupted file with Eina_File. I have no idea how to detect that in Windows land. For the moment I would say we should properly disable the code. -- Cedric BAIL -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] suggestion of landscape mode in elm.
Dear friends, this is Hermet. I suggest a feature - portrait/landscape view mode set for the elm widgets. Although this could be proper only for the mobile envrironment, some widgets may have totally different UX between landscape/portrait. So, It will be better if the widget base styles are changed automatically for user convience if the widgets supports this mode. For example, in point of the usage view, when target view mode is changed, user calls an api. elm_object_view_mode_set(win, ELM_WIN_VIEW_MODE_PORTRAIT/ELM_WIN_VIEW_MODE_LANDSCAPE); Then by traversing the widget tree, it calls the view mode change callback for it's sub objects(if sub objects implemented it and they have the landscape style.) What do you think about this? or any other idea to support this kind of feature for user convience? -Regards, Hermet- -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] suggestion of landscape mode in elm.
um actually, elm_object_view_mode_set(obj, ELM_VIEW_MODE_PORTRAIT/ELM_VIEW_MODE_LANDSCAPE); -Regards, Hermet- -Original Message- From: ChunEon Parkher...@naver.com To: EFLenlightenment-devel@lists.sourceforge.net; Cc: Sent: 2013-02-12 (화) 13:12:42 Subject: [E-devel]suggestion of landscape mode in elm. Dear friends, this is Hermet. I suggest a feature - portrait/landscape view mode set for the elm widgets. Although this could be proper only for the mobile envrironment, some widgets may have totally different UX between landscape/portrait. So, It will be better if the widget base styles are changed automatically for user convience if the widgets supports this mode. For example, in point of the usage view, when target view mode is changed, user calls an api. elm_object_view_mode_set(win, ELM_WIN_VIEW_MODE_PORTRAIT/ELM_WIN_VIEW_MODE_LANDSCAPE); Then by traversing the widget tree, it calls the view mode change callback for it's sub objects(if sub objects implemented it and they have the landscape style.) What do you think about this? or any other idea to support this kind of feature for user convience? -Regards, Hermet- -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] suggestion of landscape mode in elm.
On Tue, 12 Feb 2013 13:12:42 +0900 (KST) ChunEon Park her...@naver.com wrote: Dear friends, this is Hermet. I suggest a feature - portrait/landscape view mode set for the elm widgets. Although this could be proper only for the mobile envrironment, some widgets may have totally different UX between landscape/portrait. Desktops can be landscape/portrait as well. I saw one last week that had dual monitors, one set to each. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN-Git migration guide
Great! Thanks a lot for your effort. Btw, non-committers can clone git in the same way? How they clone git? Daniel Juyung Seo (SeoZ) On Tue, Feb 12, 2013 at 1:12 AM, Daniel Willmann d.willm...@samsung.comwrote: Apologies for the double send, but someone forgot to set the subject correctly (at all)... Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'. You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: Fix memory leak in function xyz If the allocation of foo fails the error path doesn't clean up correctly which leads to variable bla being leaked. Clean up correctly and exit. Similarly, the individual commits shouldn't be too large. I don't want you to commit every line change separately, but git allows you to commit a bunch of stuff locally before
Re: [E-devel] suggestion of landscape mode in elm.
But in desktop mode, It' doesnt need to affect each window. The layouts just tend to be resizable with window in desktop mode. and keep the ux. -Regards, Hermet- -Original Message- From: David Seikellt;onef...@gmail.comgt; To: lt;enlightenment-devel@lists.sourceforge.netgt;; Cc: Sent: 2013-02-12 (화) 13:40:11 Subject: Re: [E-devel] suggestion of landscape mode in elm. On Tue, 12 Feb 2013 13:12:42 +0900 (KST) ChunEon Park lt;hermetgt;@naver.comgt; wrote: gt; Dear friends, this is Hermet. gt; gt; I suggest a feature - portrait/landscape view mode set for the elm gt; widgets. gt; gt; Although this could be proper only for the mobile envrironment, some gt; widgets may have totally different UX between landscape/portrait. Desktops can be landscape/portrait as well. I saw one last week that had dual monitors, one set to each. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN-Git migration guide
On Tue, 12 Feb 2013 13:46:47 +0900 Daniel Juyung Seo seojuyu...@gmail.com said: Great! Thanks a lot for your effort. Btw, non-committers can clone git in the same way? How they clone git? obviously they can't clone the same way... ssh transport will not work for them. :) they probably can git clone as normal tho via git proto. Daniel Juyung Seo (SeoZ) On Tue, Feb 12, 2013 at 1:12 AM, Daniel Willmann d.willm...@samsung.comwrote: Apologies for the double send, but someone forgot to set the subject correctly (at all)... Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'. You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: Fix
Re: [E-devel] suggestion of landscape mode in elm.
On Tue, 12 Feb 2013 13:12:42 +0900 (KST) ChunEon Park her...@naver.com said: if its just portrait/landscape.. then sizing should be enough to adjust a widget. if youw ant to actually hint orientation like 0, 90, 180, 270 degrēes - tats more useful.. Dear friends, this is Hermet. I suggest a feature - portrait/landscape view mode set for the elm widgets. Although this could be proper only for the mobile envrironment, some widgets may have totally different UX between landscape/portrait. So, It will be better if the widget base styles are changed automatically for user convience if the widgets supports this mode. For example, in point of the usage view, when target view mode is changed, user calls an api. elm_object_view_mode_set(win, ELM_WIN_VIEW_MODE_PORTRAIT/ELM_WIN_VIEW_MODE_LANDSCAPE); Then by traversing the widget tree, it calls the view mode change callback for it's sub objects(if sub objects implemented it and they have the landscape style.) What do you think about this? or any other idea to support this kind of feature for user convience? -Regards, Hermet- -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
