Re: [E-devel] curl 7.29.0 segfaults Enlightenment and Terminology

2013-02-11 Thread Doug Newgard 
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

2013-02-11 Thread Stefan Schmidt 
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

2013-02-11 Thread Stefan Schmidt 
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)

2013-02-11 Thread Daniel Willmann 
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/
-> (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 
$ git commit
$ git push
-> (svn ci )

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 "-"
  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
  v, 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//*). 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 ready.

That's it for no

[E-devel] SVN->Git migration guide

2013-02-11 Thread Daniel Willmann 
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/
-> (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 
$ git commit
$ git push
-> (svn ci )

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 "-"
  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
  v, 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//*). 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

Re: [E-devel] Sound themes is there a way?

2013-02-11 Thread oeai 
Just some more i've imagined

actually it is interesting to create a theme file as an ogg file with 
xml file
the xml scheme will describe exact time for this file so people could 
use any song they like and set markers manually for any event, then the 
scheme can be enlarged for more tweaks that can be interpreted by 
sound-event-engine.
and actually few files can be used this way too, so including few 
strings and describing behavior and different themes can be used for few 
events as well as separated sound files can be used too.

> Re: Sound themes is there a way?


-- 
OEAI


--
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] curl 7.29.0 segfaults Enlightenment and Terminology

2013-02-11 Thread Mats Bertil Tegner 
On 02/11/2013 01:33 PM, Doug Newgard wrote:
> Bug in libcurl, not in EFL. Has been fixed upstream
> https://github.com/bagder/curl/commit/da3fc1ee91de656a30f3a12de394bcba55119872

Thanks, rebuilt curl using the latest daily snapshot (7.29.1-20130211).

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

[E-devel] Edje color/text_class_list bugs

2013-02-11 Thread Davide Andreoli 
Hi guys,
I think I found 2 bugs in edje (trunk):

edje_color_class_list() and edje_text_class_list() always return nothing...

see a super simple example at:
http://pastebin.com/8dAiaFzR

looking at the code seems that the 2 functions implementation search in the
wrong hash,
but I'm not sure...

can someone give a look please ?

thanks

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

[E-devel] New python bindings in a merged tree

2013-02-11 Thread Davide Andreoli 
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)

2013-02-11 Thread Mark Dickie 
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  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/
> -> (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 
> $ git commit
> $ git push
> -> (svn ci )
>
> 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 "-"
>   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
>   v, 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//*). 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. Wh

Re: [E-devel] efl merge and win32

2013-02-11 Thread Cedric BAIL 
Hello,

On Mon, Feb 11, 2013 at 10:56 PM, Stefan Schmidt  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.

2013-02-11 Thread ChunEon Park 
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.

2013-02-11 Thread ChunEon Park 
um actually, 

elm_object_view_mode_set(obj, ELM_VIEW_MODE_PORTRAIT/ELM_VIEW_MODE_LANDSCAPE);
 

-Regards, Hermet- 
-Original Message-
From: "ChunEon Park" 
To: "EFL"; 
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.

2013-02-11 Thread David Seikel 
On Tue, 12 Feb 2013 13:12:42 +0900 (KST) ChunEon Park
 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

2013-02-11 Thread Daniel Juyung Seo 
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 wrote:

> 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/
> -> (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 
> $ git commit
> $ git push
> -> (svn ci )
>
> 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 "-"
>   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
>   v, 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//*). 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 l

Re: [E-devel] suggestion of landscape mode in elm.

2013-02-11 Thread ChunEon Park 
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 Seikel" 
To: ; 
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
@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.

--
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

2013-02-11 Thread The Rasterman 
On Tue, 12 Feb 2013 13:46:47 +0900 Daniel Juyung Seo 
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
> wrote:
> 
> > 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/
> > -> (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 
> > $ git commit
> > $ git push
> > -> (svn ci )
> >
> > 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 "-"
> >   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
> >   v, 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//*). 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.

Re: [E-devel] suggestion of landscape mode in elm.

2013-02-11 Thread The Rasterman 
On Tue, 12 Feb 2013 13:12:42 +0900 (KST) ChunEon Park  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