Re: [E-devel] Compile error on OS X El Capitan 10.11.x
Hi, I noticed the following which seems 100% related : https://github.com/rbenv/ruby-build/issues/999 -- Adrien On Fri, Jul 14, 2017, Andrew Williams wrote: > Hi, > > EFL is failing to compile on 1 version back OS X: > > --- > > CC lib/eina/lib_eina_libeina_la-eina_debug_bt.lo > > lib/eina/eina_debug_bt.c:139:4: error: unknown type name 'clockid_t'; did > you mean 'clock_id_t'? > >clockid_t cid; > >^ > >clock_id_t > > /usr/include/mach/clock_types.h:53:13: note: 'clock_id_t' declared here > > typedef int clock_id_t; /* clock identification > type */ > > ^ > > 1 error generated. > --- > > It seems that clock_gettime etc are not implemented... > > Andy > -- > http://andywilliams.me > http://ajwillia.ms > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] python-efl3 and i586 (Hitting the limits of memory)
Hi, On Tue, Jun 27, 2017, Simon Lees wrote: > Hi All, > > our i586 builds of python3-efl are hitting kernel memory limits is there > anything we can do to fix this or are we going to have to edrop support > > cc1: out of memory allocating 65536 bytes after a total of > 1923301376 bytes > [ 544s] error: command 'gcc' failed with exit status 1 If I read that right, that's almost 2GB of memory. At that point, I'm not sure it's an issue with the architecture you're building on but rather that whatever you're building is pathological for optimizing compilers. I mean. Even boost doesn't need that much memory to build. -- Adrien -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] build system
Hi, I'm busy with other things but overall I find the content in the discussion very disconcerting. Taking ffmpeg's so-called configure script as an example. It. Is. A. Pile. Of. Crap. How is *that* script any better than autoconf's chain? Has anyone here actually read it? An autoconf 'configure' script is much more, and I chose my words, friendly compared to that. And did I mention the bugs? Which ones? Honestly, I don't remember because I've never felt like using my memory to store others' stupid shell mistakes. Has anyone in this thread actually called autoconf an issue? You don't have to use automake and libtool simply because you use autoconf. Also note that gnu make is slower than other make implementations because it does more things (including going through rules twice). Obviously if you use automake which does everything to not depend on gnu make but still depend on gnu make elsewhere, you're not gaining much on any front. As for libtool, a couple side-notes again. First it lets you run executables without installing them first (somehow this is called "uninstalled" rather than "not-yet-installed"). Second, it definitely does a lot things wrong but good luck faring better. Obviously, trying to contribute upstream seems impossible just like getting involved with one of the several projects aiming at replacing it. -- Adrien Nader -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL cross compilation for Windows
On Wed, Oct 26, 2016, Andrii Kroitor wrote: > Hello, Adrien. > > It's nice to meet you here. > > On 26.10.16 08:50, Adrien Nader wrote: > > [...] > >>> Should these packages be updated and uploaded manually? > >> If the path with win builds does not work out we could host the windows > >> binaries next to our source tarballs. Only for releases thought. > > Writing and improving the package manager's GUI took time off the > > packaging itself and has delayed the current release a lot. > Could you share some estimation on release date, please? Have you changed > or updated something in cross builds part? > I have tried to setup win-builds cross compilation on few different > Linux systems, > but it was unsuccessful. Are your current scripts in public access > somewhere? > > But that actually doesn't matter much. It's supposed to be possible to > > base on win-builds and build other versions or other packages and I > > don't see why that couldn't apply to the EFLs. > > > > However I'm not sure I understand some of things done in that git > > repository. I've only taken a cursory look at it and can't comment much > > but I've been more than surprised to see a pthread.h file copied there > > and that it came from pthreads-win32 which, I think(*), is > > ABI-incompatible while winpthreasd doesn't have that issue (everyone and > > their mothers assume pthread_t is an int like on linux). > > > > (*) maybe I've fixed the only occurrence of it a couple years ago, or > > maybe not, I don't know anymore, but somehow I doubt it > That file came from winpthreads-v3.3.0-2-x86_64-w64-mingw32.txz package > from winbuilds. > I've only added one explicit cast to bypass compilation error of > upstream EFL. > Problem is with pthread_cleanup_pop macro: > > #define pthread_cleanup_pop(E)\ > (*pthread_getclean() = _pthread_cup.next, > (E?_pthread_cup.func((pthread_once_t *)_pthread_cup.arg):0));} > > It works fine in C code, but in case of C++ last 0 should be casted to > (void) My issue with that file is that I understood it came from pthreads-win32 and not winpthreads. If that's not the case, then forget about this. Also the issue you mention is definitely valid and ahs actually been fixed recently in mingw-w64 upstream. That said such changes are better handled with patches to the corresponding component directly, especially since it's a small component which builds quickly. However I cannot say that win-builds has made such patching easy so far so I understand that you took the easier route. > > That said, the priorities in win-builds now are to provide a better > > integration with fetching sources from git, iron out the bugs and > > current limitations, and release. > You're doing awesome job. Thank you :) Thanks, still a fair bit to do however. :) -- Adrien Nader -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL cross compilation for Windows
On Mon, Oct 24, 2016, Stefan Schmidt wrote: > Hello. > > On 21/10/16 16:44, Andrii Kroitor wrote: > > Yes, this allows to compile working binaries for Windows from Linux system. > > At least after this patch will be merged: > > https://phab.enlightenment.org/D4357 > > > > I have not tried to build python efl yet, but I can check it next week. > > > > It is possible to prepare precompiled packages, but I'm not familiar > > with package maintenance and distribution. > > So I have a few question about this: > > What should be included into package? > > - binaries (for sure) > > - includes and other installed files? > > - some meta info about package? > > - all dependencies or only their list? > > > I honestly have no clue at all how windows packaging is done. What I > would expect as a user or developer is thought that all binaries, > dll/libs and header files are installed so I can start developing with it. You're a developer. Not an end-user. It's not completely trivial to have the same "packaging" for both classes of people. ;-) > > Where can they be hosted? Win-builds are inactive for a long time, so I > > doubt that we can reach their maintainer. > > Vincent said he is in contact with him. Maybe reach out to him if the > are plans for a new release? I'm actually subscribed to this mailing-list, I'm on #e.fr and sometimes on #edevelop. I got quite a bit behind in my emails a few months ago and it took me some time to catch up with them. > > Should these packages be updated and uploaded manually? > > If the path with win builds does not work out we could host the windows > binaries next to our source tarballs. Only for releases thought. Writing and improving the package manager's GUI took time off the packaging itself and has delayed the current release a lot. But that actually doesn't matter much. It's supposed to be possible to base on win-builds and build other versions or other packages and I don't see why that couldn't apply to the EFLs. However I'm not sure I understand some of things done in that git repository. I've only taken a cursory look at it and can't comment much but I've been more than surprised to see a pthread.h file copied there and that it came from pthreads-win32 which, I think(*), is ABI-incompatible while winpthreasd doesn't have that issue (everyone and their mothers assume pthread_t is an int like on linux). (*) maybe I've fixed the only occurrence of it a couple years ago, or maybe not, I don't know anymore, but somehow I doubt it That said, the priorities in win-builds now are to provide a better integration with fetching sources from git, iron out the bugs and current limitations, and release. > > It would be perfect if someone has working build server able to build > > EFL on Linux so we could add Windows build to it. > > Before anyone screams Jenkins here. I will only consider new things it > handles when its current problems are sorted and we have a longer period > of stable usage. > > We had cross builds for efl with mingw for some time but the cross build > slave started crashing and after this dragged out for over a year I > disabled the mingw builds. Can you detail the setup a bit more? I don't know which cross-toolchain and dependencies it used. Somehow I seem to remember they came from gentoo but I'm not sure. -- Adrien Nader -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Another day (maybe) and the server is down again
Considering this now happens frequently enough to disrupt continuous integration, why not stop some services and CI builds in order to see if that avoids the issue? CI or other things, I don't have a complete view of what's running on the servers. -- Adrien Nader -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abandoning pointers within Eolian and strings - request for feedback
On Wed, May 25, 2016, Tom Hacohen wrote: > On 25/05/16 12:01, Daniel Kolesa wrote: > > Hello, > > > > I've started removal of support for pointers in Eolian in order to > > bring the language one level up and make it easier to do bindings. > > This has already been done for class handles and for complex types > > like array, hash, iterator etc. but currently one big obstacle in the > > way is strings. I have a pretty clear idea in my head but it's > > possible I might have missed something so I'm asking here if anyone > > has any feedback or ideas or whatever that I could have missed before > > implementing it. > > > > Basically my idea currently is to introduce a new "string" builtin, > > which ALWAYS represents const char *. Mutable char pointers will not > > be possible with this system - I believe we don't want these either, > > because they're low level and represent something that you can change > > but not resize, plus it doesn't map well to various languages, > > especially scripting ones. I did some analysis on our API and it seems > > we actually have very few uses for mutable char pointers - there is > > currently only a handful of cases across the EFL, as opposed to > > countless const ones. APIs that currently use mutable char pointers > > would be dealt with on per-case basis and redesigned, probably to use > > something like Eina_Strbuf (in most cases; strbuf will get another > > builtin eolian type) with wrappers for legacy. > > evas_image_pixels_get returns a const char * that's not a string iirc. > Or heck, maybe char *. It's a good idea to also have a buffer type for > just dumping of raw data. This is useful for image pixel manipulation > and etc. So... "opaque"? And that should apply to void* too. It just means that you get some chunk of data that you might need to pass to something else but you cannot make any assumption about it. -- Adrien Nader -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/02: tiff: disable by default as it is full of CVE with apparently no chance to get them fixed.
There are basically two categories of CVEs for libtiff. If you want to see a list of recent issues, you can quite simply go look at the changelog for the most recent release: http://www.remotesensing.org/libtiff/v4.0.6.html . There have been security issues every few weeks now. For instance, CVE-2015-8665, CVE-2015-8784 and a few issues pending CVEs, about which a maintainer (Bob Friesenhahn) is saying the following: > To my knowledge, none of the issues recently posted on this list have > been addressed yet in libtiff. > > It is always our priority to fix issues occuring in libtiff itself > before addressing issues in the libtiff utilities. Some of the > libtiff maintainers care about only a few of the utilities. We are > all volunteers and available time is limited. > > It is my intention to spend time addressing the libtiff utility issues > (some of which might be due to issues in core libtiff) once I have > addressed the remaining CVEs in GraphicsMagick. Issues appearing to > be due to problems in libtiff itself will get attention first. So, yeah, many issues and updates are a bit laggy. -- Adrien Nader -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 02/02: ecore: Create Promises
On Tue, Mar 08, 2016, Cedric BAIL wrote:
> On Tue, Mar 8, 2016 at 9:19 PM, David Seikel wrote:
> > On Wed, 9 Mar 2016 13:34:48 +0900 Jean-Philippe André
> > wrote:
> >> On 9 March 2016 at 12:37, David Seikel wrote:
> >>
> >> Promises are a concept mainly used in javascript:
> >> https://www.promisejs.org/
> >>
> >> Basically they allow JS to run asynchronous tasks (remember js
> >> doesn't have threads) and you can define a success or a failure
> >> callback. Promises can also be bundled together by waiting either for
> >> the first one or for all of them to finish.
> >
> > In that case, I echo Toms WTF. Sounds like something that would be
> > trivial to do in a language that actually supports threads, so can't
> > see much point in it for EFL. Might be useful for the Lua side of EFL
> > though, except it's easy enough to do things in C and call them from
> > Lua. I have already written a Lua wrapped in Ecore_Thread
> > implementation. Though I can't see any use for this promises concept
> > in what I'm using that for.
>
> So Promise are actually a very useful way to synchronize multiple
> asynchronous operation together. The idea is that every promise come
> always to an end with either a success or a failure and you can join
> multiple promise at a rendez vous point with a promise that take a
> list of other promise.
>
> So you get an animation, a download, some computation going on in a
> thread and want to synchronize all of that. You just need to get all
> those promise and hook them into one and just write one
> success/failure callback for when they are all done. That's the idea
> here. As we push people to do more and more things asynchronously and
> they have a hard time getting it, this is a neat way to solve race
> condition.
>
> It is a very useful and powerfull way to synchronize stuff in with no
> race condition. Still I do disagree on the current implementation that
> was proposed. I think it is doable to make an implementation of
> promise ala Eina_Iterator that doesn't require to be linked or dlsymed
> with ecore at any point. As the object that return a promise will
> choose depending on their need to hook them self with a main loop and
> thread if really necessary (but current implementation of Ecore_Thread
> or Eio doesn't require promise to have this capability as all the
> synchronisation is done back in the main loop anyway).
>
> Also I am not sure of the way it is done with eolian and how it should
> be done, but clearly we need something that enable the possibility to
> specify both the type of the data stored in the promise and the
> structure describing the progress of the operation if there is one.
>
Note that promises aren't about threads, or at least not about threads
running at the same time. Javascript is a great example here: it's
single-threaded and something like node.js uses promises afaik while
being basically a big event-loop.
The nice thing with having promises is that it enables you to do
operations on them and to write stuff like:
do_foo().next(function(foo_result) { do_bar(foo_result) };
Basically you get a promise that there will be the result of a
computation at some point in the future. You register something to run
when that promise is met and the system will automatically run that. Of
course you can already do that in other ways but promises are much nicer
to manipulate.
--
Adrien Nader
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: efl -break the "i really know what i'm doing" option to get attention
You're painful. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] How to align words horizontally across genlist items?
Hello, Sorry it took me a bit of time to react: I've progressed at the incredible rate of 3 lines of code per evening this week. :) On Mon, Nov 16, 2015, Carsten Haitzler wrote: > On Sun, 15 Nov 2015 22:30:39 +0100 Adrien Nader said: > > > Hi, > > > > Let's say I have a genlist with two items with only text: > > [ foo bar baz ] > > [ f baaar bzzz ] > > > > I would like to give some horizontal alignment to the text I put there: > > [ foo bar baz ] > > [ f baaar bzzz ] > > > > This shouldn't assume text widths in the theme because 1- that wouldn't > > be a real solution, 2- I would be asking if I were to be satisfied with > > that. > > > > I'm looking for a solution available now (1.16). > > 3 swallows, put 1 table in each swallow. put rect in each table and in same > cell put label. set min width of rectangle to width you want. :) allow label > to > wrap. :) Well, this has two issues. First wrapping is not wished. Second it requires a lot of widgets and that's really bad for performance (with genlist it might be ok-ish). I'm partly to blame on that because I think I still haven't opened a ticket about it. After some discussions with cedric on IRC, I finally wrote the following: http://pastebin.notk.org/pastebin.php?show=f4373cd46 . It's OCaml code but the binding is straight-forward and the approach can be reduced to: - create an elm_layout with the theme that will be used for the swallower - create the swallowee - for each possible content, set it in the swallowee, call elm_layout_sizing_eval(layout) and get the effective size with evas_object_size_hint_min_get() - get the max of each of the possible sizes - clean up the layout you've just created - when adding an actual element, use evas_object_size_hint_min_set() to give it a minimal size That ended up working well without being complicated (although it felt quite dirty). However due to usability concerns, I ended up dropping the column approach for now and I'll be putting everything back when there is a full support for spreadsheet-like widgets in elementary (or that I make one myself; wouldn't be bad to prototype). Right now I'm trying to disable a specific item of a segment control and can't get things to work at all. Screenshot is at http://i.imgur.com/WEKuQTT.png . That's pretty much the only remaining blocker. Is it even possible? Thanks, -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] How to align words horizontally across genlist items?
Forgot something: using a table is not acceptable because that requires one widget per cell and last time I checked, the performance for creating widgets is abysmal (grows linearly with the number of existing widgets). -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] How to align words horizontally across genlist items?
Hi, Let's say I have a genlist with two items with only text: [ foo bar baz ] [ f baaar bzzz ] I would like to give some horizontal alignment to the text I put there: [ foo bar baz ] [ f baaar bzzz ] This shouldn't assume text widths in the theme because 1- that wouldn't be a real solution, 2- I would be asking if I were to be satisfied with that. I'm looking for a solution available now (1.16). Thanks, Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elua compilation for Windows is broken
On Mon, Oct 19, 2015, Daniel Kolesa wrote: > On Sat, Oct 17, 2015 at 4:01 PM, Adrien Nader wrote: > > Hi, > > > > I've finally tackled my luajit Windows troubles for cross-compilation, > > meaning I've tried to remove --enable-lua-old from my build scripts for > > EFL. Unfortunately the compilation is broken. > > This should be fixed now. Please compile and let me know if it's still broken. Thanks ! I've backported it on top of 1.15.1 for ease of testing on my side. I still don't have a full build because I need to change my native build too in order to get an 'elua' executable that I can run during cross-compilation but I don't really fear there would be issues with that. -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] elua compilation for Windows is broken
Hi, I've finally tackled my luajit Windows troubles for cross-compilation, meaning I've tried to remove --enable-lua-old from my build scripts for EFL. Unfortunately the compilation is broken. From https://www.gnu.org/software/gnulib/manual/html_node/locale_002eh.html : > The struct lconv type does not contain the members int_p_cs_precedes, > int_p_sign_posn, int_p_sep_by_space, int_n_cs_precedes, > int_n_sign_posn, int_n_sep_by_space on some platforms: glibc, OpenBSD > 4.9, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin 1.5.x, > mingw, MSVC 9. There are macros accessing these struct fields in elua's codebase. I don't know elua at all so I have no idea what to do with them. Any input? Thanks. -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Elementary 1.15.1 release
OK, will be 2.7. (and I still stand by what I said: the patches on the bug tracker are really ugly) -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Elementary 1.15.1 release
On Fri, Sep 11, 2015, Davide Andreoli wrote: > 2015-09-11 8:22 GMT+02:00 Adrien Nader : > > > Hi, > > > > I've given that what was supposed to be a quick try. With the additional > > dependencies I had to take care about (with the help of OpenSuSe's > > packages), I've been able to build a 32 bits 2.6.9 Python. > > The 64 bits one is not built (yet) because of issues with dependencies > > which I haven't looked at yet. > > The version is getting a bit old. Updating it to 2.7 should be doable > > but I'm not sure I want to spend time on that now unless it's really > > needed. I went for 2.6 because that's what opensuse is using. > > > > I strongly suggest (at least) python 2.7 > We do not test python-efl on the 2.6 branch, it was working in the past > but we do not support it. The 2.6 branch is unmaintained so I'm not happy with using it either. It might be reasonably doable to use 2.7 but I can't tell yet. I'd rather push a test version earlier in order to get more feedback and also to make it possible for people interested in Python to work on that. There have been several changes in win-builds which will make contributions easier and this, I hope, would lead to people taking over this specific field. (yes, this new version is really way simpler to work with for external usage) -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Elementary 1.15.1 release
Hi, I've given that what was supposed to be a quick try. With the additional dependencies I had to take care about (with the help of OpenSuSe's packages), I've been able to build a 32 bits 2.6.9 Python. The 64 bits one is not built (yet) because of issues with dependencies which I haven't looked at yet. The version is getting a bit old. Updating it to 2.7 should be doable but I'm not sure I want to spend time on that now unless it's really needed. I went for 2.6 because that's what opensuse is using. As for the patches to python, this large patchset is probably a bit old but it is large and I can easily understand the lack of motivation from upstream to merge it. If I were a Python developer and had to review a 6000-lines patch that started with an unwarranted (and probably unwanted) indentation change from 8 spaces to tabs, even if in C code, and made the diff larger than needed purely because of such whitespace changes, I definitely wouldn't be motivated. I'll most probably be putting python in the packages for win-builds 1.6 but I won't do a lot of work nor checks for the current version in order to not delay it. -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Elementary 1.15.1 release
On Tue, Sep 08, 2015, Jeff Hoogland wrote: > Python 2.x is fine. > OK. I've been assuming that most modules would retain compatibility with 2.x. -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Elementary 1.15.1 release
I'm going to give it a try later this week. That will be Python 2.6 with no plan to do it for 3.x in sight (i.e. upstream Python will probably have to start moving its ass). -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Elementary 1.15.1 release
On Sun, Sep 06, 2015, Jeff Hoogland wrote: > Adrien, > > Is there any chance pyefl could be included in win-builds? I've tried a few > times now to get it to compile, but my lack of experience building on this > platform has left me without anything to show from it. > > Would really love my pyefl apps to be cross platform. So far the reason not to have python in win-builds is the lack of support by Python upstream for GCC-based toolchains on Windows. I've looked around a bit and opensuse has such a package, using more than *6000* lines of patches. I was aware of GCC builds of Python but I was a bit dubious of the quality of the corresponding patches. At least some of the ones in opensuse are from Fridrich Strba and I trust him a lot. I'll still need to get in touch with him and actually read the patches a bit before I can say whether this is doable for the current release or not. -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL and Elementary 1.15.1 release
Hi, Just a quick heads up: I've removed Qt from win-builds' main packages and this has freed a huge amount of time. This means the next version is coming and it will most probably be a 1.15. Hopefully stabilization shouldn't take too long (I only need to ensure I have the most up-to-date versions of all packages and after that it should basically be a version freeze for win-builds). I've just finished a build-only experiment to replace evil's regex with musl's fork of the now-unmaintained "tre" library. Built fine with only simple build-system changes. Will be testing that probably in a couple weeks. By the way, I (and some Linux distributions) have gotten an issue building eio: currently it doesn't depend on libefl. The following sed invocation fixes that: sed -i \ '/EFL_INTERNAL_DEPEND_PKG(\[EIO\], \[eina\])/ a EFL_INTERNAL_DEPEND_PKG([EIO], [efl])' \ configure.ac (it adds EFL_INTERNAL_DEPEND_PKG([EIO], [efl]) after EFL_INTERNAL_DEPEND_PKG([EIO], [eina]) in configure.ac) -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Pre-release tarballs for efl and elm 1.14.2
Just updated the website to point to these instead of 1.14.1. -- Adrien Nader -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Building on Windows
Hi, On Sun, Jun 07, 2015, Andrew Williams wrote: > Hi, > > Sorry I should have said that I'm following the docs on > https://phab.enlightenment.org/w/windows/ - they seem to be far more in > depth. > As far as I can tell the win-builds setup is good but I can't get the > elementary to install. Elementary specifically or other things too? Also, I've been working on the next version and even though I haven't pushed the new EFLs yet but they're already built and ready. Meaning I'll push them next on friday or saturday. -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [website/www-content] master 01/01: Wiki page start changed with summary [] by Philippe Caseiro
On Sun, May 03, 2015, Carsten Haitzler wrote: > On Sat, 02 May 2015 08:39:06 -0700 Philippe Caseiro > said: > > what are you trying to achieve other than just defacing a web page and pissing > me off in having to revert them? With these dark times upon us, we, French people, are getting panicked. It is getting clear that we will soon need to prove our frenchness and as such we are accumulating proofs that everyday we do what being French means: being a borker and complaining. I'm still only complaining but I hope to soon graduate as a world-class borker too. More seriously, it would be wise to use ACLs to limit at least who can edit the main page. Contact and download might make sense too. -- Adrien Nader -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Reusing the EFL Tizen documentation on e.org
On Wed, Apr 15, 2015, Carsten Haitzler wrote:
> On Wed, 15 Apr 2015 09:20:42 +0200 Adrien Nader said:
>
> > On Tue, Apr 14, 2015, Carsten Haitzler wrote:
> > > On Mon, 13 Apr 2015 21:27:49 +0200 Adrien Nader said:
> > >
> > > sorry - not addressing the below.. but i have now got a local dokuwiki
> > > patch
> > > that extends geshi (the code syntax hilighter) to teach it new keywords.
> > > the
> > > awesome bit - the keywords are just a text file in the wiki!
> > >
> > > http://www.enlightenment.org/ss/e-552cb0fa49e318.10726513.png
> > >
> > > see evas_object_del is hilighted. i have a file with:
> > >
> > > evas_object_del
> > > evas_object_show
> > > evas_object_hide
> > > eo_add
> > > eo_del
> > >
> > > and if any of these appear - they get linked... to the following url which
> > > is in an accompanying file:
> > >
> > > /docs/generated/c/keywords/{FNAMEL}
> > >
> > > so that means click on a link and it goes to:
> > >
> > > docs/generated/c/keywords/evas_object_del
> >
> > Do you plan on making "stable" ones? I don't think it's sane to link to
> > anything but the most recent stable release: lagging a bit for updates
> > is fine but linking to the devel stuff would be really bad imho.
>
> that would be the idea - these are all "latest stable release" - we rebuild
> link lists just around/before/after release (in the last week or so of freeze
> should be fine as no api should change). any new docs needed can be prepared
> FOR
> this period but not made live yet.
Sounds perfect to me. Must make sure to not lose previous ones so we can
show the previous versions too.
> > Also, what about an URI that is simpler to memorize? That's not
> > exclusive with the current one though. I'd really like to be able to
> > remember the URI to prepend to any function name in order to get its
> > doc: "docs/generated/c/keywords/" is a bit too long for that.
>
> google will end up finding stuff for you in the end. i would expect us to have
> an index page generated from that with just links or something. in fact just
> make the parent dir have key.txt and it can be the link list. bookmark that
> and
> go there when needed.
I don't know how different I am from the typical future visitors but I
like being to go hit the api references quickly.
People praise Qt's docs but for two slightly different search queries,
chances are you will get results from different versions of Qt, possibly
even from nokia days.
> > > on the site (www.e.org in front of course). this is the beginning of a
> > > namespace for docs. the above keywords markdown pages can be totally
> > > generated (and maybe even be master pages for these things) and it means
> > > code at least gets auto-linked. the symbol list is in the wiki so it can
> > > be
> > > extended by hand edits or auto-generation and commits to www-content git
> > > on
> > > the back-end without going through the wiki. something needs to
> > > collect/generate all these keywords (functions, enums, macros, typedef'ed
> > > types). in future for eo we can auto-generate them for classes, methods,
> > > events etc. etc. but it's a start.
> > >
> > > so to some extent by doing this dokuwiki mod, i'm answering the question
> > > partially to layout already a this mod relies on a flat layout of keywords
> > > (geshi relies on this for linking keywords - it doesnt understand context
> > > thus has to be flat). oh btw - geshi is the code syntax hilighter buried
> > > in
> > > dokuwiki (external project from dokuwiki though) and has hilighters for
> > > maybe 50+ languages (c, cpp, js, lua python are all there, even brainfuck
> > > and ruby!) :)
> >
> > That only applies to the API part, right?
>
> this is for generating links to keywords - ie reference. the same links will
> apply to any and ALL c code (you can have per language keyword lists).
Yes, ok.
> > > > Last year, Samsung contracted a company made of French borkers to
> > > > write its "native application" documentation, i.e. usage of EFLs on
> > > > Tizen. Last week, raster switched e.org to dokuwiki.
> > > > Well, I worked on that documentation and I really like dokuwiki so I
> > > > started porting the documentation.
> > > >
> > > > It was written as doxygen and we don't have any copyright on that;
> > &
Re: [E-devel] EAPI considered harmful
After discussing this a bit more on #e.fr, it occurred to me the simplest would be to #undef EAPI at the end of headers. Basically this turns EAPI into a header-specific define. The annotations (both ELF visibility and Windows dllimport/export) are only needed on the function declaration, not on the function definition. However we enjoy the "EAPI" in the implementation so instead it could be defined to nothing. This amounts to adding the following at the end of each public header: #undef EAPI #define EAPI This shouldn't be an issue for any situation and would make sense to add to 1.14 right now. Actually I'm joking about that: I thought it'd be good to have people cry a bit more about the feature freeze not being applied. :) So, that means it'd be for the beginning of the next cycle. Any thought? -- Adrien Nader -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EAPI considered harmful
On Wed, Apr 15, 2015, David Seikel wrote: > On Tue, 14 Apr 2015 21:50:01 +0200 Adrien Nader wrote: > > > "considered harmful" should never be used. > > "Considered harmful" is considered harmful? Definitely. :) But I didn't have any proper title for that mail so I went for the quickest. :P -- Adrien Nader -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EAPI considered harmful
On Wed, Apr 15, 2015, Carsten Haitzler wrote: > On Tue, 14 Apr 2015 21:50:01 +0200 Adrien Nader said: > > > Hi, > > > > Let's get this straight: the title of this mail was only to trick you > > into reading what's below and "considered harmful" should never be used. > > > > I'm updating win-builds.org with EFL git and ephysics failed building > > because too many things use the EAPI define. > > EAPI is useful because some platforms want that symbols exported from > > shared libraries are explicitly marked and, conversely, when using > > symbols from another shared library, they should be marked but > > differently. > > > > Basically that means: > > when eina_init() is compiled, it must be marked "dllexport" (for > > Windows but this is also useful for ELF) and when it is used from my > > application, its definition must be marked "dllimport". > > > > Simple enough. > > > > In the EFL world, this is achieved through EAPI. > > Below is code from EPhysics.h: > > > > #ifdef EAPI > > # undef EAPI > > #endif > > > > #ifdef _WIN32 > > # ifdef EFL_EPHYSICS_BUILD > > # ifdef DLL_EXPORT > > # define EAPI __declspec(dllexport) > > # else > > # define EAPI > > # endif /* ! DLL_EXPORT */ > > # else > > # define EAPI __declspec(dllimport) > > # endif /* ! EFL_EPHYSICS_BUILD */ > > > > > > Then ephysics_world.cpp gets built with -DEFL_EPHYSICS_BUILD=1 and EAPI > > gets "dllexport". That way, it will be possible to export the symbols > > defined in ephysics_world.cpp. > > Except that Eina.h is then included and since EFL_EINA_BUILD isn't > > defined and the code in Eina.h is similar, we get #undef EAPI and then > > #define again but for dllimport. Then the symbols are declared while > > getting a decoration that means they are to be imported from another > > shared library. That makes no sense and compilation aborts. > > > > There's the quick solution: include EPhysics.h after all others. > > > > There's the clean solution: stop abusing EAPI for 20 different > > libraries. Think about it: today it's 20 but the goal is to get that > > much higher; this will not happen if the order in which headers have to > > be included is tricky. > > Maybe that having EINA_API, EPHYSICS_API, ECORE_API, and so on looks a > > bit tedious but at least it's simple to get right. > > Another way to see it is that currently, a /single/ define (EAPI) is > > controlled by 20 other defines (each of the EFL_.*_BUILD). > > > > To everyone writing new libraries: do not ever write "EAPI" in your code > > but use a specific define for your library. > > i have to say.. a custom EAPI (EINA_API whatever) per library is just insane. > the solution is far simpler. every header file must first #include <> deps > (other libs) THEN #define it's own EAPI and continue delcaring its own (maybe > #include it's own headers if it has multiple ala eina). > > this is far far far more managable. > Then how come there are so many bugs? Enventor has the same problem. Actually I bet that anything making a library outside of efl/ and elm/ has it. There's already the per-lib #define EFL_EFOO_BUILD. Having EFOO_API is nothing more than consistency. And you don't have to manage anything: it's visible only in one library and it's internal. It's the usual namespacing of identifiers and nothing more. -- Adrien Nader -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Reusing the EFL Tizen documentation on e.org
On Tue, Apr 14, 2015, Carsten Haitzler wrote:
> On Mon, 13 Apr 2015 21:27:49 +0200 Adrien Nader said:
>
> sorry - not addressing the below.. but i have now got a local dokuwiki patch
> that extends geshi (the code syntax hilighter) to teach it new keywords. the
> awesome bit - the keywords are just a text file in the wiki!
>
> http://www.enlightenment.org/ss/e-552cb0fa49e318.10726513.png
>
> see evas_object_del is hilighted. i have a file with:
>
> evas_object_del
> evas_object_show
> evas_object_hide
> eo_add
> eo_del
>
> and if any of these appear - they get linked... to the following url which is
> in an accompanying file:
>
> /docs/generated/c/keywords/{FNAMEL}
>
> so that means click on a link and it goes to:
>
> docs/generated/c/keywords/evas_object_del
Do you plan on making "stable" ones? I don't think it's sane to link to
anything but the most recent stable release: lagging a bit for updates
is fine but linking to the devel stuff would be really bad imho.
Also, what about an URI that is simpler to memorize? That's not
exclusive with the current one though. I'd really like to be able to
remember the URI to prepend to any function name in order to get its
doc: "docs/generated/c/keywords/" is a bit too long for that.
> on the site (www.e.org in front of course). this is the beginning of a
> namespace for docs. the above keywords markdown pages can be totally generated
> (and maybe even be master pages for these things) and it means code at
> least gets auto-linked. the symbol list is in the wiki so it can be extended
> by
> hand edits or auto-generation and commits to www-content git on the back-end
> without going through the wiki. something needs to collect/generate all these
> keywords (functions, enums, macros, typedef'ed types). in future for eo we can
> auto-generate them for classes, methods, events etc. etc. but it's a start.
>
> so to some extent by doing this dokuwiki mod, i'm answering the question
> partially to layout already a this mod relies on a flat layout of keywords
> (geshi relies on this for linking keywords - it doesnt understand context thus
> has to be flat). oh btw - geshi is the code syntax hilighter buried in
> dokuwiki
> (external project from dokuwiki though) and has hilighters for maybe 50+
> languages (c, cpp, js, lua python are all there, even brainfuck and ruby!) :)
That only applies to the API part, right?
We can also mod_rewrite or something else to turn docs/ecore/foo/bar
into whatever we want if needed. I think that for a namespaced
organization, a trailing /api component would only be a redirect or a
simple page with a list of entries but not much content by itself.
> now adding auto-linking outside of code blocks is harder. problem:
>
> 1. we don't know language context (link in c, cpp, js, python, lua? which?)
> 2. a lot more work (likely write plugin to do it ... if we knew context).
>
> so q is - do i bother? or do we just leave it to links outside code sections
> not being automatic (have to manually [[]] things) ... which as i think about
> it i think is fine. we can FORCE every function to have a code section - an
> example at least. a "see also" section can be done in a code block as well so
> it links nicely. imho these solve the problem enough from a docs point of
> view.
> of course this consideration goes right to the heart of what our docs will
> look
> like formatting-wise as a standard. thus positing it here.
I don't think it's worth spending time on it for now. It can always be
done later on without costing more time if really needed. Let's wait and
see.
> > Last year, Samsung contracted a company made of French borkers to
> > write its "native application" documentation, i.e. usage of EFLs on
> > Tizen. Last week, raster switched e.org to dokuwiki.
> > Well, I worked on that documentation and I really like dokuwiki so I
> > started porting the documentation.
> >
> > It was written as doxygen and we don't have any copyright on that;
> > however, the HTML output has been published as a mix of CC-BY 3.0, BSD
> > 3-clauses and LGPL v2.1 and Apache. It's not entirely consistent but in
> > any case, it's definitely usable (and probably with a better track of
> > licenses than what has existed until now).
>
> at the bottom of each page we can put a licence link and put a copy of the
> above licenses in our docs tree - we will comply happily then.
Page per page or globally for the wiki?
> > The documentation in Tizen is really good. I'm totally unbiased on
> > that. No, really.
>
> sure... :)
Who cares about typos and the like anyway? Being rushed is like a
Re: [E-devel] EAPI considered harmful
FWIW, I'm getting a similar problem with Emotion. Not exactly the same and probably more annoying to fix but still a variation on the same theme. -- Adrien Nader -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] EAPI considered harmful
Hi, Let's get this straight: the title of this mail was only to trick you into reading what's below and "considered harmful" should never be used. I'm updating win-builds.org with EFL git and ephysics failed building because too many things use the EAPI define. EAPI is useful because some platforms want that symbols exported from shared libraries are explicitly marked and, conversely, when using symbols from another shared library, they should be marked but differently. Basically that means: when eina_init() is compiled, it must be marked "dllexport" (for Windows but this is also useful for ELF) and when it is used from my application, its definition must be marked "dllimport". Simple enough. In the EFL world, this is achieved through EAPI. Below is code from EPhysics.h: #ifdef EAPI # undef EAPI #endif #ifdef _WIN32 # ifdef EFL_EPHYSICS_BUILD # ifdef DLL_EXPORT # define EAPI __declspec(dllexport) # else # define EAPI # endif /* ! DLL_EXPORT */ # else # define EAPI __declspec(dllimport) # endif /* ! EFL_EPHYSICS_BUILD */ Then ephysics_world.cpp gets built with -DEFL_EPHYSICS_BUILD=1 and EAPI gets "dllexport". That way, it will be possible to export the symbols defined in ephysics_world.cpp. Except that Eina.h is then included and since EFL_EINA_BUILD isn't defined and the code in Eina.h is similar, we get #undef EAPI and then #define again but for dllimport. Then the symbols are declared while getting a decoration that means they are to be imported from another shared library. That makes no sense and compilation aborts. There's the quick solution: include EPhysics.h after all others. There's the clean solution: stop abusing EAPI for 20 different libraries. Think about it: today it's 20 but the goal is to get that much higher; this will not happen if the order in which headers have to be included is tricky. Maybe that having EINA_API, EPHYSICS_API, ECORE_API, and so on looks a bit tedious but at least it's simple to get right. Another way to see it is that currently, a /single/ define (EAPI) is controlled by 20 other defines (each of the EFL_.*_BUILD). To everyone writing new libraries: do not ever write "EAPI" in your code but use a specific define for your library. -- Adrien Nader -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Reusing the EFL Tizen documentation on e.org
On Mon, Apr 13, 2015, Jeff Grimshaw wrote:
> On Mon, Apr 13, 2015 at 12:27 PM, Adrien Nader wrote:
>
> > Hi,
> >
> > Last year, Samsung contracted a company made of French borkers to
> > write its "native application" documentation, i.e. usage of EFLs on
> > Tizen. Last week, raster switched e.org to dokuwiki.
> > Well, I worked on that documentation and I really like dokuwiki so I
> > started porting the documentation.
> >
> > Yay! Win! Vive les borkers!
>
>
> > It was written as doxygen and we don't have any copyright on that;
> > however, the HTML output has been published as a mix of CC-BY 3.0, BSD
> > 3-clauses and LGPL v2.1 and Apache. It's not entirely consistent but in
> > any case, it's definitely usable (and probably with a better track of
> > licenses than what has existed until now).
> >
> >
> Looks like docs are CC-BY 3 and examples are BSD 3-clause. No worries
> there.
It depends on parts of the website. It's organized in a complex fashion
so it's difficult to keep track of it but I've seen some pages as with
other license text.
In any case it's something we can re-use. My only worry is that it'll be
complex to keep track of and we'll need to say "this tiny is that
license, this other, that other license" and so on. Maybe we can limit
ourselves to the CC-BY-3/BSD-3 pages for now and make a list of others
and when we have a good overview we'll decide how to continue.
> > The documentation in Tizen is really good. I'm totally unbiased on
> > that. No, really.
> > More seriously, it's fairly comprehensive and covers some topics which
> > are large enough for no-one to deal with them on their free time.
> >
> > It's made of "tutorials" and "programming guides". Programming guides
> > sit between tutorials and the API reference. Think of the tutorial as
> > "hold-my-hand-and-make-me-use-that-widget-for-the-first-time" while the
> > programming guide explains the common APIs and usage. Most widgets are
> > covered.
> >
> > For reference, my first try is a page with no incoming link at:
> > https://www.enlightenment.org/docs-non-api-wip
> >
>
> This page "does not exist yet" for me on the wiki :-(
Hmmm. I did the edit with another computer which is currently sleeping
in a backpack so I can't guarantee the address but I'm fairly sure it
was working. Maybe someone deleted it. Anyway it wasn't very valuable
(some kind of experimentation).
> > The very first question I got was: how do we organize that
> > documentation?
> > Dokuwiki supports namespaces and we probably want to take advantage of
> > that; namespaces can appear in the URI either as "foo:bar" or "foo/bar"
> > and it's also possible to put a page directly at "foo".
> >
> > I think we could have namespaces and pages like:
> > doc/
> > doc/efl # lists and explains libraries
> > doc/efl/ecore/
> > doc/efl/ecore/events # covers events, their handling, the mainloop...
> > doc/efl/elementary/
> > doc/efl/elementary/concepts
> > doc/efl/elementary/widgets # nice, sorted, widget gallery
> > doc/efl/elementary/widgets/button # page-name is guessable from the API
> > doc/e17/
> > doc/e19/
> >
> > Any thought? This really seems like the most blocking aspect to me.
> >
>
> This sounds sane. I don't have any experience with dokuwiki (yet) but
> namespaces
> sounds like a good way to organize the content. Is it easy to move if the
> organization
> does not work out? Any problems linking between namespaces?
Dokuwiki uses a simple file-and-directory storage for data. This means
that the above will be on disk as:
doc.txt
doc/ (a directory)
doc/efl.txt
doc/efl/
doc/efl/ecore.txt
doc/efl/ecore/
doc/efl/ecore/events.txt
...
There's no namespace containerization. Linking happens in the same
namespace by default but it's easily overriden: from doc/efl/ecore,
write [[:doc:efl]] and you get a link to doc/efl.txt.
It's possible to move files by hand if needed. The only annoyance is
that the tree structure is duplicated in two other places: the cache and
another one ("meta" iirc) but moving is also possible there and there
are scripts for that. It also doesn't seem too difficult to fix links
afterwards.
> > A few more things (most are for the wiki admins).
> >
> > What's missing or could be improved:
> > - the dokuwiki "syntax" page cannot be found on the wiki; it's a problem
> > because some dokuwiki plugins extend the syntax and it's dif
[E-devel] Reusing the EFL Tizen documentation on e.org
Hi, Last year, Samsung contracted a company made of French borkers to write its "native application" documentation, i.e. usage of EFLs on Tizen. Last week, raster switched e.org to dokuwiki. Well, I worked on that documentation and I really like dokuwiki so I started porting the documentation. It was written as doxygen and we don't have any copyright on that; however, the HTML output has been published as a mix of CC-BY 3.0, BSD 3-clauses and LGPL v2.1 and Apache. It's not entirely consistent but in any case, it's definitely usable (and probably with a better track of licenses than what has existed until now). The documentation in Tizen is really good. I'm totally unbiased on that. No, really. More seriously, it's fairly comprehensive and covers some topics which are large enough for no-one to deal with them on their free time. It's made of "tutorials" and "programming guides". Programming guides sit between tutorials and the API reference. Think of the tutorial as "hold-my-hand-and-make-me-use-that-widget-for-the-first-time" while the programming guide explains the common APIs and usage. Most widgets are covered. For reference, my first try is a page with no incoming link at: https://www.enlightenment.org/docs-non-api-wip The very first question I got was: how do we organize that documentation? Dokuwiki supports namespaces and we probably want to take advantage of that; namespaces can appear in the URI either as "foo:bar" or "foo/bar" and it's also possible to put a page directly at "foo". I think we could have namespaces and pages like: doc/ doc/efl # lists and explains libraries doc/efl/ecore/ doc/efl/ecore/events # covers events, their handling, the mainloop... doc/efl/elementary/ doc/efl/elementary/concepts doc/efl/elementary/widgets # nice, sorted, widget gallery doc/efl/elementary/widgets/button # page-name is guessable from the API doc/e17/ doc/e19/ Any thought? This really seems like the most blocking aspect to me. A few more things (most are for the wiki admins). What's missing or could be improved: - the dokuwiki "syntax" page cannot be found on the wiki; it's a problem because some dokuwiki plugins extend the syntax and it's difficult to know which ones are enabled without that page - there should be a plugin which provides mediawiki's table/list syntax (there are several of them available, not sure which one to chose) - locating the words "tizen" and "appcore"/"app_core" is fairly difficult and it'd be nice to have highlighting for that - when I want to upload an image, I need to download it locally then re-upload it (something for which I don't have the rights it seems) - we need to think about the license a bit in order to have something compatible with the mix from tizen.org. What's annoying and probably won't change: - copy-paste from tizen.org is a bit difficult because of tizen.org's layout - copy-paste loses some markup, in particular headers/titles, lists, tables, figures - some filtering needs to be done: Tizen-specific stuff needs to be stripped (there isn't much of it but you need to locate it) - dokuwiki's table syntax is nice and simple but also too simple -- Adrien Nader -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Terminology does not get focus in some window managers
Hi, On Fri, Mar 20, 2015, José Romildo Malaquias wrote: > Hello. > > I have been using terminology as my default terminal for some time, but > recently it has stopped working with some window managers. > > After starting terminology, its window is drawn without decoration, but > it does not receive focus and I cannot type anything in it. It is still > sensitive to mouse actions, allowing access to its menu. > > The attached file is a screenshot showing a terminology window and a > gnome-terminal window. The window manager is openbox. > > This is happening with several window managers I have tried: openbox, > fluxbox, window maker. So it probably is a problem with terminology > itself, and not with the window manager. > > It works with enlightenment and xfce, though. > > Is anybody else seing this behaviour or has any clues on how to fix it? This reminds me a *lot* of an issue I had too in openbox. It wasn't limited to Terminology. I think it started with EFL 1.12 and I think it has since been fixed: which exact version of EFL are you using? -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Python-EFL on Windows?
Hi, On Sat, Feb 21, 2015, Jeff Hoogland wrote: > Has any work been done to get Python-EFLs running on Windows? There are > nice pre-compiled Windows binaries for EFL/Elementary here -> > http://win-builds.org/index.html > > Would be nice if we had something similar for py-efl (ideally getting pip > to work with those windows build) to promote py-efl apps as being cross > platform. Complain to upstream python: the windows port of python only supports building with MSVC. Let upstream know that GCC support for the Windows port means everything can be cross-compiled. I haven't tried and maybe that the current state is actually sufficient for cross-compilation and only native compilation would be unsupported. I doubt it's the case though. Some people patch it to make it work with GCC but upstream is not merging them and it's a lrge pile of patches which is way too large for me to feel comfortable with. I've not looked at the details of such patches but some complain that they are not merged due to political issues (with the maintainer of the windows port being a bit too much in favor of Microsoft and Visual Studio). That's what I've been reading but I'm a bit dubious because fairly often such patches are not mergeable: they work for the usecase they're meant to support (or at least with minimal steps to do by hand) but also break other usecases. An alternative that just sprang to my mind would be to build python packages as part of win-builds but not python itself. This depends heavily on the amount of platform-specific defines at play but that's always a possible issue with cross-compilation so it probably doesn't make building worse anyway. -- Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Deprecating evas_object_event_callback_del() and the likes
On Tue, Feb 10, 2015, Tom Hacohen wrote: > On Tue, Feb 10, 2015 at 8:00 PM, Brett Nash wrote: > > > Please don't kill _del. > > > > A documentation fix or guarantee on what it deletes would be nice[1] (I > > recall it used to delete the most recently added item that matched). > > > > Del allows you to remove a callback without having to keep track of the > > data pointer, which is useful, if you know the lifecycle of the datapointer > > is safe. In particular since the name of the callback is a global name it > > is easy to discover/keep track of, but the data pointer would require extra > > access. > > > > The problem with this is that even if you guarantee the deletion order in > the docs (that is, most recently added would be deleted first) and make it > 100% obvious in that regard, it's still not safe. You can never be sure > someone else hasn't added a similar callback with different data after > you've added yours. As I said, this is an uncommon occurrence, but it'll > become even more relevant once we start using the callback mechanism with > more "global helpers" like we plan on doing on entry with string validation. > Even without the global case, it's a recipe for trouble in people's code > when they mismanage the order of callbacks added. > > We are becoming more and more protective of our developers, for example > with eo pointer indirection, we wouldn't like to make sure they don't shoot > themselves in the foot, and I think having this function available is a > threat to that notion. > > Sure, it's easier not to manage that, but it's sloppy. And it's what people use more than 99% of the time (well, 99% is probably too high but I'm confident in 95%). Maybe ERR() when _del() is used while there are several callbacks set up? Or give it a stack behaviour where the last installed callback is removed (I think I might actually have relied on that but I don't have access to the codebase anymore). There's a saying about making the complicated tasks possible but keep the simple tasks easy to achieve. I think it really applies here. -- Adrien Nader http://win-builds.org -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/27: eina: remove Windows specific thread implementation and rely on posix compliant library instead.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=2cb0c1cadc46e1d89fea4e27399b36ce9f1526ff
commit 2cb0c1cadc46e1d89fea4e27399b36ce9f1526ff
Author: Adrien Nader
Date: Wed Feb 11 12:15:43 2015 +0100
eina: remove Windows specific thread implementation and rely on posix
compliant library instead.
---
m4/efl_threads.m4 | 12 +-
src/lib/eina/eina_cpu.c | 4 +-
src/lib/eina/eina_inline_lock_win32.x | 610 --
src/lib/eina/eina_lock.h | 4 -
src/lib/eina/eina_main.c | 31 +-
src/lib/eina/eina_sched.c | 22 +-
src/lib/eina/eina_thread.c| 231 -
7 files changed, 9 insertions(+), 905 deletions(-)
diff --git a/m4/efl_threads.m4 b/m4/efl_threads.m4
index 9596908..88317af 100644
--- a/m4/efl_threads.m4
+++ b/m4/efl_threads.m4
@@ -25,17 +25,7 @@ gl_LOCK
AC_DEFINE([EFL_HAVE_THREADS], [1], [Define to mention that POSIX or Win32
threads are supported])
-case "$host_os" in
- mingw*)
- _efl_have_win32_threads="yes"
- efl_have_setaffinity="yes"
- AC_DEFINE([EFL_HAVE_WIN32_THREADS], [1], [Define to mention that Win32
threads are supported])
- ;;
- *)
- _efl_have_posix_threads="${gl_use_threads}"
- AC_DEFINE([EFL_HAVE_POSIX_THREADS], [1], [Define to mention that POSIX
threads are supported])
- ;;
-esac
+_efl_have_posix_threads="${gl_use_threads}"
dnl System specific CFLAGS
if test "x${_efl_have_posix_threads}" = "xyes"; then
diff --git a/src/lib/eina/eina_cpu.c b/src/lib/eina/eina_cpu.c
index 82c0f04..08b0860 100644
--- a/src/lib/eina/eina_cpu.c
+++ b/src/lib/eina/eina_cpu.c
@@ -35,9 +35,7 @@
# elif defined (__linux__) || defined(__GLIBC__)
# include
# endif
-# ifdef EFL_HAVE_POSIX_THREADS
-# include
-# endif
+# include
# define TH_MAX 8
#endif
diff --git a/src/lib/eina/eina_inline_lock_win32.x
b/src/lib/eina/eina_inline_lock_win32.x
index b3e8fbc..e69de29 100644
--- a/src/lib/eina/eina_inline_lock_win32.x
+++ b/src/lib/eina/eina_inline_lock_win32.x
@@ -1,610 +0,0 @@
-/* EINA - EFL data type library
- * Copyright (C) 2011 Vincent Torri
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library;
- * if not, see <http://www.gnu.org/licenses/>.
- */
-
-#ifndef EINA_INLINE_LOCK_WIN32_X_
-#define EINA_INLINE_LOCK_WIN32_X_
-
-#ifndef WIN32_LEAN_AND_MEAN
-# define WIN32_LEAN_AND_MEAN
-#endif
-#include
-#undef WIN32_LEAN_AND_MEAN
-
-/** @privatesection @{ */
-typedef CRITICAL_SECTION Eina_Lock;
-typedef struct _Eina_Condition Eina_Condition;
-typedef struct _Eina_RWLockEina_RWLock;
-typedef DWORD Eina_TLS;
-typedef HANDLE Eina_Semaphore;
-typedef Eina_Lock Eina_Spinlock;
-
-#if _WIN32_WINNT >= 0x0600
-struct _Eina_Condition
-{
- CRITICAL_SECTION *mutex; /**< The locking mechanism for this
condition variable */
- CONDITION_VARIABLE condition; /**< The condition variable */
-};
-
-struct _Eina_RWLock
-{
- SRWLOCK mutex; /**< The locking mechanism */
-
- Eina_Bool is_read_mode : 1; /**< Indicates if the lock is a read lock */
-};
-#else
-struct _Eina_Condition
-{
- int waiters_count; /**< The count of threads that are
waiting on this condition */
- CRITICAL_SECTION waiters_count_lock; /**< The locking mechanism for the
waiters_count member */
- CRITICAL_SECTION *mutex; /**< The locking mechanism for the
condition */
- HANDLEsemaphore; /**< Semaphore used to coordinate
waiters */
- HANDLEwaiters_done;/**< Event to trigger when all the
waiters are done */
- Eina_Bool was_broadcast; /**< Indicates whether this
condition has signalled its waiters */
-};
-
-struct _Eina_RWLock
-{
- LONG readers_count; /**< The number of readers waiting for locks
*/
- LONG writers_count; /**< The number of writers waiting for locks
*/
- intreaders;/**< The number of readers that have locks */
- intwriters;/**< The number of writers that have locks */
-
- Eina_Lock mutex; /**< The locking mechanism */
- Eina_Condition cond_r
[EGIT] [core/efl] master 02/27: eina: remove Eina_Counter and use provided Windows posix compatible implementation.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=9d1504dba11ed3d7c7f6c82fb1d1b5a7acbe4474
commit 9d1504dba11ed3d7c7f6c82fb1d1b5a7acbe4474
Author: Adrien Nader
Date: Wed Feb 11 12:09:59 2015 +0100
eina: remove Eina_Counter and use provided Windows posix compatible
implementation.
---
src/lib/eina/eina_counter.c| 49 --
src/lib/eina/eina_inline_private.h | 27 -
src/lib/eina/eina_main.c | 3 ---
3 files changed, 79 deletions(-)
diff --git a/src/lib/eina/eina_counter.c b/src/lib/eina/eina_counter.c
index 084788e..533d215 100644
--- a/src/lib/eina/eina_counter.c
+++ b/src/lib/eina/eina_counter.c
@@ -68,9 +68,6 @@ struct _Eina_Clock
Eina_Bool valid;
};
-#ifdef _WIN32
-LARGE_INTEGER _eina_counter_frequency;
-#endif
static char *
_eina_counter_asiprintf(char *base, int *position, const char *format, ...)
@@ -117,52 +114,6 @@ _eina_counter_asiprintf(char *base, int *position, const
char *format, ...)
*/
/**
- * Global *
-
**/
-
-/**
- * @internal
- * @brief Initialize the eina counter internal structure.
- *
- * @return #EINA_TRUE on success, #EINA_FALSE on failure.
- *
- * This function shuts down the counter module set up by
- * eina_counter_init(). It is called by eina_init().
- *
- * This function sets up the error module of Eina and only on Windows,
- * it initializes the high precision timer. It is also called
- * by eina_init(). It returns 0 on failure, otherwise it returns the
- * number of times it has already been called.
- *
- * @see eina_init()
- */
-Eina_Bool
-eina_counter_init(void)
-{
-#ifdef _WIN32
- if (!QueryPerformanceFrequency(&_eina_counter_frequency)) return EINA_FALSE;
-#endif /* _WIN2 */
- return EINA_TRUE;
-}
-
-/**
- * @internal
- * @brief Shut down the counter module.
- *
- * @return #EINA_TRUE on success, #EINA_FALSE on failure.
- *
- * This function shuts down the counter module set up by
- * eina_counter_init(). It is called by eina_shutdown().
- *
- * @see eina_shutdown()
- */
-Eina_Bool
-eina_counter_shutdown(void)
-{
- return EINA_TRUE;
-}
-
-/**
* API *
**/
diff --git a/src/lib/eina/eina_inline_private.h
b/src/lib/eina/eina_inline_private.h
index 752baa0..846081d 100644
--- a/src/lib/eina/eina_inline_private.h
+++ b/src/lib/eina/eina_inline_private.h
@@ -19,27 +19,14 @@
#ifndef EINA_INLINE_PRIVATE_H_
# define EINA_INLINE_PRIVATE_H_
-#ifndef _WIN32
# include
# include
-#else
-# define WIN32_LEAN_AND_MEAN
-# include
-# undef WIN32_LEAN_AND_MEAN
-#endif /* _WIN2 */
-#ifndef _WIN32
typedef struct timespec Eina_Nano_Time;
-#else
-typedef LARGE_INTEGER Eina_Nano_Time;
-
-extern LARGE_INTEGER _eina_counter_frequency;
-#endif
static inline int
_eina_time_get(Eina_Nano_Time *tp)
{
-#ifndef _WIN32
# if defined(CLOCK_PROCESS_CPUTIME_ID)
if (!clock_gettime(CLOCK_PROCESS_CPUTIME_ID, tp))
return 0;
@@ -64,9 +51,6 @@ _eina_time_get(Eina_Nano_Time *tp)
tp->tv_nsec = tv.tv_usec * 1000L;
return 0;
-#else
- return QueryPerformanceCounter(tp);
-#endif /* _WIN2 */
}
static inline long int
@@ -74,12 +58,7 @@ _eina_time_convert(Eina_Nano_Time *tp)
{
long int r;
-#ifndef _WIN32
r = tp->tv_sec * 10 + tp->tv_nsec;
-#else
- r = (long int)(((long long int)tp->QuadPart * 10ll) /
-(long long int)_eina_counter_frequency.QuadPart);
-#endif
return r;
}
@@ -89,14 +68,8 @@ _eina_time_delta(Eina_Nano_Time *start, Eina_Nano_Time *end)
{
long int r;
-#ifndef _WIN32
r = (end->tv_sec - start->tv_sec) * 10 +
end->tv_nsec - start->tv_nsec;
-#else
- r = (long int)(((long long int)(end->QuadPart - start->QuadPart)
- * 10LL)
-/ (long long int)_eina_counter_frequency.QuadPart);
-#endif
return r;
}
diff --git a/src/lib/eina/eina_main.c b/src/lib/eina/eina_main.c
index 7a9ec9f..aa39d27 100644
--- a/src/lib/eina/eina_main.c
+++ b/src/lib/eina/eina_main.c
@@ -60,7 +60,6 @@
#include "eina_list.h"
#include "eina_matrixsparse.h"
#include "eina_array.h"
-#include "eina_counter.h"
#include "eina_benchmark.h"
#include "eina_magic.h"
#include "eina_rectangle.h"
@@ -138,7 +137,6 @@ EAPI Eina_Inlist *_eina_tracking = NULL;
S(ustringshare);
S(matrixsparse);
S(convert);
- S(counter);
S(benchmark);
S(rectangle);
S(strbuf);
@@ -183,7 +181,6 @@ static con
[EGIT] [core/efl] master 03/27: eina: correctly handle and report Eina_File error on Windows.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=f71a78edcb2fbb2a6156abce3ab8f523eed09c66
commit f71a78edcb2fbb2a6156abce3ab8f523eed09c66
Author: Adrien Nader
Date: Wed Feb 11 11:58:28 2015 +0100
eina: correctly handle and report Eina_File error on Windows.
@fix
---
src/lib/eina/eina_file_win32.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/lib/eina/eina_file_win32.c b/src/lib/eina/eina_file_win32.c
index 01d0c9f..4398e0b 100644
--- a/src/lib/eina/eina_file_win32.c
+++ b/src/lib/eina/eina_file_win32.c
@@ -372,7 +372,7 @@ eina_file_real_close(Eina_File *file)
free(map);
}
- if (file->global_map != MAP_FAILED)
+ if (file->global_map != MAP_FAILED && file->handle != NULL)
UnmapViewOfFile(file->global_map);
if (file->fm) CloseHandle(file->fm);
@@ -728,6 +728,17 @@ eina_file_open(const char *path, Eina_Bool shared)
if (handle == INVALID_HANDLE_VALUE)
{
+LPVOID lpMsgBuf;
+
+FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER |
+ FORMAT_MESSAGE_FROM_SYSTEM |
+ FORMAT_MESSAGE_IGNORE_INSERTS,
+ NULL,
+ GetLastError(),
+ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+ (LPTSTR) &lpMsgBuf,
+ 0, NULL);
+
switch (GetLastError())
{
case ERROR_FILE_NOT_FOUND:
--
Re: [E-devel] Eolian, nullability and the gcc attribute "nonnull"
Hi, It's late for me so I won't try to think on your first question. As soon as I saw the "nonnull" attribute, I was interested. I think I haven't gotten anything from it however. Maybe I did something wrong but it seemed to only catch obvious mistakes, ones which you get in gdb in a few seconds anyway (spawn, wait for crash, see it's dereferencing NULL, check backtrace, see there's a NULL in parameters 3 calls earlier, done). I really wish it was better but I'm under the impression it's not bringing much currently. -- Adrien Nader http://win-builds.org -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] On tmpstr, death and performance
Hi, As a user of the EFLs, I've found tmpstr to be quite painful. I was jointly supervising other people and I'm quite certain that dropping a few tmpstr instances and going for something plain and simple solved at least a couple bugs. That was a couple years ago so I don't remember the specific but I do remember that it wasn't one of the APIs I've loved the most. When it comes to locks for thread-safety, it's good to remember that the libc's malloc is quite likely going to take a lock too so it's not an argument in favor of one or the other (jemalloc tries to avoid the need for them but I think glibc doesn't). In any case, if you look at Tom's example of getenv(), I'd say the call to getenv() is probably to be what's slower by quite a large margin. You gave the example of genlists but when would performance for this matter? Scrolling. So you'd have to malloc() space for a string and at the same time you're also free()'ing space for a string for a widget that became invisible. If your libc's malloc() is not completely crap then it's likely going to be fast. And if it is crap, fix it (or you're going to be like the openssl devs that went for a broken custom mempool and you know how this ended). >From my perspective: save bugs, save kittens, avoid unneeded optimizations. And since I'm siding with Tom on this one, I'll also side with him on saying that the benchmark that's needed is the one that would be in favor of tmpstr and would therefore be work from not I. :) -- Adrien Nader http://win-builds.org - package manager for windows: cute EFL GUI -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 06/11: eolian: fix to pass make check on windows
On Tue, Feb 03, 2015, Stefan Schmidt wrote:
> Hello.
>
> On 01/02/15 19:02, Sebastian Dransfeld wrote:
> > $(EXEEXT)?
>
> Fair point as this would avoid the ifdef alltogether. Is normally only
> used in Makefile, right? Is is really available at this stage?
I'd say it probably isn't. Now, would it be worth adding it? Dunno. I
think it's not used elsewhere.
A way to reduce the duplication would probably be something like adding
a trailing "%s" in the format and
#ifdef _WIN32
, ".exe"
#else
, ""
#endif
in the arguments. With compiler optimizations the output code will
probably be equivalent.
(and it's not like it'd be dwarfed by the folllowing process spawning
anyway).
--
Adrien Nader
> > michelle legrand skrev
> >
> >> cedric pushed a commit to branch master.
> >>
> >> http://git.enlightenment.org/core/efl.git/commit/?id=9431cde70e25ba40e7408ca11016e58977d09b2b
> >>
> >> commit 9431cde70e25ba40e7408ca11016e58977d09b2b
> >> Author: michelle legrand
> >> Date: Fri Jan 30 10:49:53 2015 +0100
> >>
> >>eolian: fix to pass make check on windows
> >>
> >>@fix
> >>
> >>Signed-off-by: Cedric BAIL
> >> ---
> >> src/tests/eolian/eolian_generation.c | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/src/tests/eolian/eolian_generation.c
> >> b/src/tests/eolian/eolian_generation.c
> >> index 25fcddf..f3ccc71 100644
> >> --- a/src/tests/eolian/eolian_generation.c
> >> +++ b/src/tests/eolian/eolian_generation.c
> >> @@ -72,9 +72,15 @@ _eolian_gen_execute(const char *eo_filename, const char
> >> *options, const char *ou
> >>
> >>if (getenv("EFL_RUN_IN_TREE"))
> >> {
> >> +#ifdef _WIN32
> >> +snprintf(eolian_gen_path, sizeof(eolian_gen_path),
> >> + "%s/src/bin/eolian/eolian_gen.exe",
> >> + PACKAGE_BUILD_DIR);
> >> +#else
> >> snprintf(eolian_gen_path, sizeof(eolian_gen_path),
> >> "%s/src/bin/eolian/eolian_gen",
> >> PACKAGE_BUILD_DIR);
> >> +#endif
> >> }
> >>if (eolian_gen_path[0] == '\0')
> >> return -1;
> >>
> >> --
> >>
> >>
> > --
> > Dive into the World of Parallel Programming. The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take a
> > look and join the conversation now. http://goparallel.sourceforge.net/
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [ANN] Win-builds 1.5.0 - fully-bootstrapped free software distribution for Windows, with GUI using EFLs
e set of such packages has only one inhabitant: Qt. I'll be frank: maintaining a Qt that is cross-compiled from Linux for Windows is probably close to a full-time part-time job, i.e. something that will take all the time for someone doing part-time on it. My perception is probably flawed since I've made the initial packaging and it includes things that have probably never been done before and definitely deviate from what upstream had in mind (i.e. cross-compile qmake itself). It is also unfortunately to be expected that each new version of Qt breaks something for this packaging (cross-compile to Windows). As such, additional maintainers are looked for. There is no reason to be afraid and this is not about abandoning the package unless someone steps up. This is entirely in order to be able to better track upstream releases. Security Updates This part has mostly been a failure. The work involved was larger than expected and was let slip by without bound. Basically, the work (reading, updating the source, rebuilding, testing, uploading, announcing) is sometimes too much to do immediately after the availability of a security fix. With no strict bound and with the need to spend time on large changes in the build architecture, the updates have slipped by one day at a time. As usual, Frederick P. Brooks got it right: Q: How does a large software project get to be one year late? A: One day at a time. The larger architecture have been done. There will be others but they should be less pervasive and shouldn't block working on other tasks for as much time. More importantly, at least for this release, the official goal is to handle most security updates in 3 days at most and let none slip by more than 8 days. This should be at least as good as most large Linux distributions. Any security update lagging behind for more than that should be considered "unnoticed" and a poke warranted. PS [1] It obviously takes some time to extract the 25MB or so (8MB compressed) but it is fast enough and can most probably be made faster. The main advantage however is that this solves the issue of replacing files which are in-use: the package manager depends on .dll files and therefore would have been unable to ever replace these without resorting to complex tricks. [2] Perhaps the best proof is the following top-level code: let init_count = ref 0 let init () = if !init_count = 0 then ( do_the_actual_init (); incr init_count; ) else () let () = init () On Windows I had to add an explicit call to the "init" function from somewhere else in the code. -- Adrien Nader http://win-builds.org -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: autotools: remove some Windows CE bits.
Hi, On Sat, Jan 24, 2015, Stefan Schmidt wrote: > Hello. > > On 24/01/15 12:41, Vincent Torri wrote: > > cedric pushed a commit to branch master. > > > > http://git.enlightenment.org/core/efl.git/commit/?id=546d87c8b5de547a6ecbe579a08910981deac8a0 > > > > commit 546d87c8b5de547a6ecbe579a08910981deac8a0 > > Author: Vincent Torri > > Date: Fri Jan 23 17:18:23 2015 +0100 > > > > autotools: remove some Windows CE bits. > > > > We actually do not support Windows CE and don't plan to. Let's remove > > that > > from our configure. > > Would have been good if the commit message also mentioned that it > switched the default for windows version from XP to Win7. Not sure how > much this really changes but seeing this inside was unexpected. > Basically it's like switching from targeting libc5 to targeting glibc 2: the executables won't be able to run on XP because it lacks some newer APIs (it's a bit more complicated than that but considering how computer-literate Windows are it's probably very close). So, less compatibility. Bad! Except that it means more code is needed inside evil and it's code that doesn't get many reviews. Also, XP has been EOL'ed for real by MS for almost a year and no dev around the EFLs cares about it (or at least to the point of spending time to maintain compatibility). By the way, on win-builds.org's apache logs, I don't see browsers from XP anymore in the top ones while I was seeing some less than a year ago though. I've also seen people ask for XP compatibility in win-builds 1.5 as recently as last week so there's a demand (that one was for Xonotic). (still, that part should have gone in a separate commit) -- Adrien Nader http://win-builds.org -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Windows issue with Eina_Thread type
On Wed, Dec 24, 2014, Carsten Haitzler wrote: > On Tue, 23 Dec 2014 18:35:20 +0100 (CET) Michelle Legrand > said: > > > So if I understood correctly, I should replace in > > src/lib/eina/eina_thread.h: > > typedef unsigned long int Eina_Thread; > > by : > > typedef uintptr_t Eina_Thread; > > > > like Nash suggested ? > > or just unsigned long long - which in any sane world will always be 64bit. It's still completely wrong. It might work, including on Windows with winpthreads (but not pthreads-win32) but it's wrong. As I've mentioned, pthread_t can be anything and the whole issue is about assuming a specific ABI for pthread_t. The proper approach would be to remove this typedef and avoid casts between types which aren't guaranteed to be compatible (i.e. Eina_Thread and pthread_t). It's obviously more work however and the platforms with a non-integer pthread_t are quite uncommon. I've given the example of pthreads-win32 on Windows but it's not that much used nowadays and winpthreads which usually comes with GCC on/for Windows has been created specifically for the applications which violate the specification by assuming an ABI for pthread_t. Realistically I don't see this fixed properly anytime soon and would definitely rather go for the half-fix rather than keeping the win32-based implentation since it probably has many more bugs that are yet to be found and solved. I'd like a check to be added however. Not very long ago I had another ABI issue with libarchive and wrote the following to make compilation fail if the ABIs wouldn't match. It uses C11/C++11's static assert (or that sufficient GCC and LLVM handle it no matter the standard). Code can be seen outside of mail at http://cgit.notk.org/adrien/yypkg/slackware64-current.git/tree/l/libarchive/use-static-asserts-to-guarantee-abi-compatibility.patch /* Take advantage of static_assert/_Static_assert to make sure libarchive is * not built and is not used with a "struct stat" that isn't 64bits. * On Windows I had "stat" #define'd to "stat64" but libarchive #undef'ed it in * its private headers; I then built a program that used libarchive and didn't * have that #undef and got ABI issues: libarchive was storing a 32bit offset * in a "struct stat" but the caller was expecting a 64bit one. * This is a best effort check but which should cover most uses. */ #ifdef __cplusplus #if (__cplusplus >= 201103L) static_assert(sizeof(struct stat) == sizeof(struct stat64), "Not using largefile support"); #endif #else #if ((defined(__STDC_VERSION) && __STDC_VERSION >= 201112L) \ || (defined(__GNUC__) && (__GNUC__ >= 4) && (__GNUC_MINOR__ >= 6)) \ || (defined(__clang__) && (__clang_major__ >= 3) && (__clang_minor__ >= 4))) _Static_assert(sizeof(struct stat) == sizeof(struct stat64), "Not using largefile support"); #endif #endif -- Adrien Nader -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PROPOSAL] [Evas] Optimizing smooth scaling of Evas in software backend
Hi, On Thu, Dec 18, 2014, Krishnaraj Raghavendra Bhat wrote: > Yes, probably it won't be packaged by any distro because it's used only in > chromium browser & lollipop as of now. > The current cmakefile compiles it to a static library. If we statically link > libyuv to evas, > runtime dependencies can be avoided. The size of libevas.so(after stripping) > increased by 0.3 MB in this case Please, don't go that way. Absolutely everything that comes from google for use in chrom* is packaging crap. It's not even meant to be packaged: it's code dumps without a build system usable for anything besides chrom*. We are already seeing this with Angle (OpenGL API implemented on top of DirectX to work-around drivers with crappy OpenGL implementations on Windows). The result is that it's not usable at all. The right way is to have it packaged separately and to pressure upstream to accept build system improvements. The threshold to get packages into distributions is usually not very high; the main trouble is with crappy build systems and these must be solved or they'll come back to bite hard rather sooner than later. Note that the only problem here is Google. I'm not sure what is the use in pushing code with a BSD license and make is to annoying to use. It almost feels like it's meant to not displease their employees who want to work on free software, while not making free software in practice. Regards, Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Windows issue with Eina_Thread type
doable to review the pthread-specific code for casts to longs and that being able to smithe the win32-specific code will very quickly reduce the maintenance burden. Thinking about it now, first step would probably be to remove the cast to pthread_t* and let the compiler complain if it feels like French today. Another issue is that eina_thread.h exposes the bad line: typedef unsigned long int Eina_Thread; This is wrong because pthread_t can be anything and the fact that it is an int is only the "common" case. The issue has been introduced by the following commit: commit 09748cfb154a314b3f98add4e0b98b30f9839df2 Author: Gustavo Sverzut Barbieri Date: Mon Dec 31 17:26:33 2012 + efl: beef thread documentation and error reporting. eina_thread_join() is nasty and didn't report errors :-( I'm using Eina_Error here, but it's global to the application and not thread-local. Maybe we should make eina_error_get() and eina_error_set() thread-local storage? SVN revision: 81936 The net effect for eina_thread.h is: -typedef pthread_t Eina_Thread; +typedef unsigned long int Eina_Thread; IOW, this commit (which was supposed to be documentation) has made the implementation of Eina_Thread public and possibly incorrect. Also, considering the timestamp, I believe this awards k-s a shiny first-class-borker medal. Therefore, one way to go would be to hide again the implementation of Eina_Thread by making it a typedef of pthread_t again. I don't think it is currently known whether this will require additional work. This is probably the more correct change but might be riskier than simply #ifdef'ing a typedef to the right size for windows x86_64. As Michelle said: what do you think should be done? Regards, Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EO for non-EFL/Enlightenment use
Hi, On Tue, Nov 25, 2014, Chris Marshall wrote: > I'm in the process of trying to build the current EFL release to get > at the EO and Eolian for that work but not having much luck on this > cygwin/win7 platform. Given that the EO framework is the foundation > of the new Enlightenment implementation it would be nice if it were > possible to build EO without requiring window/graphics/multimedia/... > configuration and libraries. "cygwin/win7" or "windows"? In other words: a cygwin application which is built with the cygwin headers which are posix, which is linked against and depends upon cygwin1.dll and which is therefore bound to the GPL, or an application built from cygwin but not tied to it otherwise? If it's a cygwin application, I have no idea what the overall status is. If it's merely an application built for Windows from Cygwin (i.e. cross-compilation), then EO works and I'm using it daily as part of an EFL application and in which case it would be good to try to have more logs. -- Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] discussion - documentation
On Thu, Nov 06, 2014, Carsten Haitzler wrote: > i thought i'd start this here for a wide audience. > > documentation for efl. it's rather horrible. and yesterday it dawned on me... > it has license problems too. > > 1. license problems: > > the documentation in many parts is lgpl - and that means copying any code from > code snippets or examples in the docs makes the app you copy it into lgpl. > that > is BAD. enforcing the license even though with lgpl we intend the library > boundary to be the library itself. we can add exceptions, but splitting docs > out might actually be best. reality is that no one is ever going to sue over > this and it's safe as it's not intended to be a problem, but strictly/legally > it is. if someone has a legal department that really dots their i's and > crosses > their t's... they would spot this. A related discussion: https://lists.debian.org/debian-legal/2008/06/msg00012.html Fortunately, examples are most often separate files with short modification histories and only a few authors total. Relicensing shouldn't be a huge pain of tracking down everyone. Also, since they're separate files and works, they might not even be LGPL or anything but full-copyright. > 2. our docs are a mess. a lot are not linked to and undiscoverable. they have > typos, missing docs - often are sparse and with little or nothing in the way > of > binding things together. they are at best a very slim reference set for apis > with little besides that. some references are good, but most are also very > thin. keeping docs totally in the hands of core devs (always in the source > tree - src commit access needed) simply is *NOT WORKING*. devs work on code. > we > just are not doing docs. we should do them, but reality is we are not and have > little incentive to do it. core devs are busy enough as-is. Definitely agreed. Making the glue with doxygen between the various API pages is fine once you've done enough doxygen but wiki or something similar might be better for glue (and intros and tutorials and ...). For the tutorials and the likes, better to wait a bit before starting to work on these. > 3. eo brings the added problem of needing docs to cover multiple languages > from a single source. C, C++, Lua, JS, Python... it's a unique problem that > using doxygen is never going to solve. we need a solution. i haven't found > another solution and to be honest ours will be custom due to eo/eolian anwyay. It's not terribly pretty but having no documentation in the bindings is acceptable imho. Put a link at the top of each of their API ref to the documentation for the C code, and stop there. The bindings are so close to 1:1 that they're easy to understand. > 4. people ask questions on efl all the time and we answer in email, irc etc. > .. > and this information is not captured. it's lost. that's because there is no > "forum" for asking such q's. we should closely tie such forums and q&a to > documentation. this would massively improve the value of docs. > > 5. the theory of keeping docs with the code is just not working. it doesn't > encourage them to be good. it just isn't working - plain and simple. it's time > to re-evaluate that. Again, agreed. > [...] And the rest sounds good but that's a large proposal so needs time to check and think about it. -- Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: elua: load .dylib on OSX
Hi, On Tue, Nov 04, 2014, Daniel Kolesa wrote: > 2014-11-04 14:17 GMT+00:00 Tom Hacohen : > > > That's why autofoo has a variable for lib extension. Use it... > > > > I was thinking about doing that, but decided it was counter-intuitive. It'd > actually be more code to use that variable as well as make editing things > more painful (as I'd have to generate util.lua, which would have a need for > util.lua.in, which editors wouldn't recognize as lua... I'm not even > talking about that it's not only an extension thing, Windows uses foo.dll > pattern while other OSes typically use libfoo.ext). We don't currently > support any OSes that don't follow this pattern - and if we ever do, it'll > be very easy to detect and port, as that code path is triggered when you > build the EFL - as such, I'd opt for keeping the current code as it is, and > only use the variable if ever necessary (which I don't think will happen). Everything built through libtool, no matter if for Windows or not, will use the libfoo-X.bar pattern. In my builds for Windows, everything uses that except SDL and, of course, Qt. Regards, Adrien Nader -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: ecore_exe_win32: CreateProcess was called with random flags.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=e9e61718d1dc7d8f012ca4ee4958156ae47aea4f
commit e9e61718d1dc7d8f012ca4ee4958156ae47aea4f
Author: Adrien Nader
Date: Sat Oct 25 16:35:06 2014 +0200
ecore_exe_win32: CreateProcess was called with random flags.
CreateProcess() has a flags parameter which is being passed
"run_pri | CREATE_SUSPENDED".
The issue lies in the value of run_pri. It is best explained by the
following code somewhere else in the file:
switch (run_pri)
{
case IDLE_PRIORITY_CLASS:
return ECORE_EXE_WIN32_PRIORITY_IDLE;
The run_pri variable is supposed to store a value from the win32 API while
it was used to store one from the ecore API.
If I recall correctly, the windows one is equal to 32 and the ecore one to
. Meaning ended up used as flags so let's have a look at what that
actually enabled; the reference is "Process Creation Flags" from MSDN
http://msdn.microsoft.com/en-us/library/ms684863%28v=vs.85%29.aspx .
gives 0x270F and this matches
DEBUG_PROCESS | DETACHED_PROCESS | DEBUG_ONLY_THIS_PROCESS
| CREATE_SUSPENDED | CREATE_NEW_PROCESS_GROUP | CREATE_SEPARATE_WOW_VDM
| CREATE_UNICODE_ENVIRONMENT | <0x2000 matches nothing>
Matches nothing? Weird. Well, maybe. Except that I stumbled upon this define
in the mingw-w64 headers:
#define CREATE_FORCEDOS 0x2000
Mingw-w64 only has a #define, Wine has nothing (they don't do DOS anyway),
but ReactOS has some code about it:
https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/kernel32/client/proc.c;hb=f60941f8dc775427af04eb0a3c3e4d38160c7641#l3007
Overall the actual set of flags probably made very little sense and wasn't
working very well. :)
I also noticed the following in the mingw-w64 headers:
#define INHERIT_CALLER_PRIORITY 0x2
This should be a better match for what seemed to be the original intent of
inheriting the priority. I haven't tested it and it's only documented on
MSDN for Windows CE and similar so I'm really not sure about what it does.
MSDN however mentions that the child processes will have at most the
"normal" priority by default (same as its parent if the parent has less
than the default one) but I'm under the impression a process can raise its
own priority level... Anyway, "NORMAL_PRIORITY_CLASS" will do for now.
With this change and a couple others, elementary's theme builds properly
on Windows (_on_ Windows). I'll assess the usefulness of the other changes
in my tree over the next few days.
Signed-off-by: Cedric BAIL
---
src/lib/ecore/ecore_exe_win32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/ecore/ecore_exe_win32.c b/src/lib/ecore/ecore_exe_win32.c
index 5b725c6..2a4db49 100644
--- a/src/lib/ecore/ecore_exe_win32.c
+++ b/src/lib/ecore/ecore_exe_win32.c
@@ -34,7 +34,7 @@
#define ECORE_EXE_WIN32_TIMEOUT 3000
-static int run_pri = ECORE_EXE_PRIORITY_INHERIT;
+static int run_pri = NORMAL_PRIORITY_CLASS;
static Eina_Bool
_ecore_exe_close_cb(void *data,
--
[EGIT] [core/elementary] master 02/04: doc: add API docs in button, container, image, store, general.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=c8dd871c1d38d6dd196578c0d2560dc09b336cc5
commit c8dd871c1d38d6dd196578c0d2560dc09b336cc5
Author: Adrien Nader
Date: Mon Oct 13 15:59:28 2014 +0200
doc: add API docs in button, container, image, store, general.
This adds API docs for:
- elm_button_admits_autorepeat_get
- elm_container_content_swallow_list_get
- content_get
- content_set
- content_unset
- elm_image_resize_down_set
- resize_down_get
- resize_up_set
- resize_up_get
- scale_set
- scale_get
- fill_inside_set
- fill_inside_get
- sizing_eval
Light documentation for enum Elm_Object_Select_Mode, enum
Elm_Object_Multi_Select_Mode and Elm_Store_Item_Mapping_Type.
---
src/lib/elm_button.eo| 2 +-
src/lib/elm_container.eo | 14
src/lib/elm_general.h| 12 +--
src/lib/elm_image.eo | 88 +---
src/lib/elm_store.h | 6 +++-
5 files changed, 98 insertions(+), 24 deletions(-)
diff --git a/src/lib/elm_button.eo b/src/lib/elm_button.eo
index d0651f4..5d3027f 100644
--- a/src/lib/elm_button.eo
+++ b/src/lib/elm_button.eo
@@ -88,7 +88,7 @@ class Elm_Button (Elm_Layout, Evas.Clickable_Interface,
}
admits_autorepeat {
get {
-/*@ No description supplied by the EAPI. */
+/*@ Get whether the button supports autorepeat. */
legacy: null;
}
values {
diff --git a/src/lib/elm_container.eo b/src/lib/elm_container.eo
index b306f7e..899068c 100644
--- a/src/lib/elm_container.eo
+++ b/src/lib/elm_container.eo
@@ -6,7 +6,7 @@ class Elm_Container (Elm_Widget)
properties {
content_swallow_list {
get {
-/*@ No description supplied by the EAPI. */
+/*@ Get the list of swallow parts in the object. */
}
values {
list *ret; /*@ list */
@@ -15,22 +15,22 @@ class Elm_Container (Elm_Widget)
}
methods {
content_set {
- /*@ No description supplied by the EAPI. */
+ /*@ Swallow the given object into the given part of the container. */
params {
-@in const(char)* name;
-@in Evas_Object *content;
+@in const(char)* name; /*@ the part in which to swallow the object
*/
+@in Evas_Object *content; /*@ the object to swallow */
}
return: bool;
}
content_get {
- /*@ No description supplied by the EAPI. */
+ /*@ Get the object swallowed in the given part of the container. */
params {
-@in const(char)* name;
+@in const(char)* name; /*@ the part in which the object is
swallowed */
}
return: Evas_Object *;
}
content_unset {
- /*@ No description supplied by the EAPI. */
+ /*@ Unswallow the object in the given part of the container and
return it. */
params {
@in const(char)* name;
}
diff --git a/src/lib/elm_general.h b/src/lib/elm_general.h
index 88d9ff1..a800f24 100644
--- a/src/lib/elm_general.h
+++ b/src/lib/elm_general.h
@@ -134,20 +134,28 @@ typedef enum
ELM_POLICY_THROTTLE_NEVER /**< never throttle when windows are all hidden,
regardless of config settings */
} Elm_Policy_Throttle;
+/**
+ * Possible values for the #ELM_OBJECT_SELECT_MODE policy.
+ * @since 1.7
+ */
typedef enum
{
ELM_OBJECT_SELECT_MODE_DEFAULT = 0, /**< default select mode. Once an item
is selected, it would stay highlighted and not going to call selected callback
again even it was clicked. Items can get focus. */
ELM_OBJECT_SELECT_MODE_ALWAYS, /**< always select mode. Item selected
callbacks will be called every time for click events, even after the item was
already selected. Items can get focus. */
ELM_OBJECT_SELECT_MODE_NONE, /**< no select mode. Items will never be
highlighted and selected but the size will be adjusted by the finger size
configuration. Items can't get focus. */
ELM_OBJECT_SELECT_MODE_DISPLAY_ONLY, /**< no select mode with no finger
size rule. Items will never be highlighted and selected and ignore the finger
size. So the item size can be reduced below than the finger size configuration.
Items can't get focus. */
- ELM_OBJECT_SELECT_MODE_MAX
+ ELM_OBJECT_SELECT_MODE_MAX /**< canary value: any value greater or equal to
ELM_OBJECT_SELECT_MODE_MAX is forbidden. */
} Elm_Object_Select_Mode;
+/**
+ * Possible values for the #ELM_OBJECT_MULTI_SELECT_MODE policy.
+ * @since 1.8
+ */
typedef enum
{
ELM_OBJECT_MULTI_SELECT_MODE_DEFAULT = 0, /**< default multiple select mode
*/
ELM_OBJECT_MULTI_SELECT_MODE_WITH_CONTROL, /**< disall
[EGIT] [core/elementary] master 03/04: doc: add API docs in elm_interface_scrollable.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=6309e212fb928228483e4d12e3a088af8bc9ffa6
commit 6309e212fb928228483e4d12e3a088af8bc9ffa6
Author: Adrien Nader
Date: Mon Oct 13 16:07:24 2014 +0200
doc: add API docs in elm_interface_scrollable.
This adds
- gravity_set
- gravity_get
- bounce_allow_set
- bounce_allow_get
- movement_block_set
- movement_block_get
- policy_get
- policy_set
- content_region_get
- content_region_set
- page_size_set
- page_size_get
- page_snap_allow_set
- page_snap_allow_get
- single_direction_get
- single_direction_set
- last_page_get
- current_page_get
- content_size_get
- scroll_up_cb
- hbar_drag_cb
- drag_start_cb
- scroll_left_cb
- vbar_press_cb
- hbar_press_cb
- hbar_unpress_cb
- drag_stop_cb
- page_change_cb
- animate_start_cb
- scroll_down_cb
- scroll_cb
- animate_stop_cb
- scroll_right_cb
- edge_left_cb
- vbar_drag_cb
- vbar_unpress_cb
- edge_bottom_cb
- edge_top_cb
- page_show
- region_bring_in
- page_bring_in
- content_region_show
- content_min_limit
---
src/lib/elm_interface_scrollable.eo | 470
1 file changed, 369 insertions(+), 101 deletions(-)
diff --git a/src/lib/elm_interface_scrollable.eo
b/src/lib/elm_interface_scrollable.eo
index 16d3981..320651c 100644
--- a/src/lib/elm_interface_scrollable.eo
+++ b/src/lib/elm_interface_scrollable.eo
@@ -2,30 +2,67 @@ mixin Elm_Interface_Scrollable(Evas.Scrollable_Interface,
Evas.Object_Smart)
{
legacy_prefix: null;
eo_prefix: elm_interface_scrollable;
- data: Elm_Scrollable_Smart_Interface_Data;
+ data: Elm_Scrollable_Smart_Interface_Data;
properties {
gravity {
set {
-/*@ No description supplied by the EAPI. */
+/*@ Set scrolling gravity on the scrollable
+
+ The gravity defines how the scroller will adjust its view
+ when the size of the scroller contents increases.
+
+ The scroller will adjust the view to glue itself as follows.
+
+ x=0.0, for staying where it is relative to the left edge of the
content
+ x=1.0, for staying where it is relative to the rigth edge of the
content
+ y=0.0, for staying where it is relative to the top edge of the
content
+ y=1.0, for staying where it is relative to the bottom edge of
the content
+
+ Default values for x and y are 0.0
+
+ @ingroup Widget
+ */
}
get {
-/*@ No description supplied by the EAPI. */
+/*@ Get scrolling gravity on the scrollable
+
+ The gravity defines how the scroller will adjust its view
+ when the size of the scroller contents increases.
+
+ The scroller will adjust the view to glue itself as follows.
+
+ x=0.0, for staying where it is relative to the left edge of the
content
+ x=1.0, for staying where it is relative to the rigth edge of the
content
+ y=0.0, for staying where it is relative to the top edge of the
content
+ y=1.0, for staying where it is relative to the bottom edge of
the content
+
+ Default values for x and y are 0.0
+
+ @ingroup Widget
+ */
}
values {
-double x;
-double y;
+double x; /*@ Horizontal scrolling gravity */
+double y; /*@ Vertical scrolling gravity */
}
}
bounce_allow {
+ /* @brief Bouncing behavior
+ *
+ * When scrolling, the scroller may "bounce" when reaching an edge of
the
+ * content object. This is a visual way to indicate the end has been
reached.
+ * This is enabled by default for both axis. This API will set if it
is enabled
+ * for the given axis with the boolean parameters for each axis.
+ *
+ * @ingroup Widget
+ */
set {
-/*@ No description supplied by the EAPI. */
}
get {
-/*@ No description supplied by the EAPI. */
}
values {
-bool horiz;
-bool vert;
+bool horiz; /*@ Horizontal bounce policy. */
+bool vert; /*@ Vertical bounce policy. */
}
}
wheel_disabled {
@@ -40,14 +77,30 @@ mixin Elm_Interface_Scrollable(Evas.Scrollable_Interface,
Evas.Object_Smart)
}
}
movement_block {
+ /*@
+ * @brief Blocking of scrolling (per axis)
+ *
+ * This function will block scrolling movement (by input of a user) in
+ * a given direction. One can disable movements in the X axis, the Y
+ * axis or
[EGIT] [core/elementary] master 01/04: doc: fix mismatched variable names between prototypes and doxygen comments.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=5bbf974060a09e15237eb9521a345adad922ea61
commit 5bbf974060a09e15237eb9521a345adad922ea61
Author: Adrien Nader
Date: Mon Oct 13 14:50:22 2014 +0200
doc: fix mismatched variable names between prototypes and doxygen comments.
Several APIs are marked as not documented simply because the doxygen
documentation mentions a parameter named "foo" while the spelling in the
prototype is something like "fooh". An example correction is
- * @param fsize Finger size
+ * @param sz Finger size
Nothing very complicated and there are also a couple typo fixes I noticed
while going over the files.
---
src/lib/elc_fileselector_legacy.h | 2 +-
src/lib/elc_naviframe_common.h | 1 +
src/lib/elm_actionslider.eo| 2 +-
src/lib/elm_app_client.eo | 4 ++--
src/lib/elm_config.h | 16
src/lib/elm_gesture_layer_common.h | 2 +-
src/lib/elm_map_common.h | 4 ++--
src/lib/elm_prefs_data.h | 6 +++---
src/lib/elm_toolbar_common.h | 6 --
src/lib/elm_transit.h | 6 +++---
src/lib/elm_win.eo | 2 +-
11 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/src/lib/elc_fileselector_legacy.h
b/src/lib/elc_fileselector_legacy.h
index 2c7fcd6..0aa5b79 100644
--- a/src/lib/elc_fileselector_legacy.h
+++ b/src/lib/elc_fileselector_legacy.h
@@ -408,6 +408,6 @@ EAPI Elm_Fileselector_Sort
elm_fileselector_sort_method_get(const Evas_Object *o
* @since 1.9
* @ingroup Fileselector
*/
-EAPI void elm_fileselector_sort_method_set(Evas_Object *obj,
Elm_Fileselector_Sort method);
+EAPI void elm_fileselector_sort_method_set(Evas_Object *obj,
Elm_Fileselector_Sort sort);
#include "elm_fileselector.eo.legacy.h"
diff --git a/src/lib/elc_naviframe_common.h b/src/lib/elc_naviframe_common.h
index 757bdb5..39d3a79 100644
--- a/src/lib/elc_naviframe_common.h
+++ b/src/lib/elc_naviframe_common.h
@@ -109,6 +109,7 @@ EAPI Eina_Bool
elm_naviframe_item_title_enabled_get(const Elm_Object_Item
*
* @param it The item to set the callback on
* @param func the callback function.
+ * @param data The data to be passed to this @p func call.
*
* @warning Don't set "clicked" callback to the prev button additionally if the
* function does an exact same logic with this @c func. When hardware back key
diff --git a/src/lib/elm_actionslider.eo b/src/lib/elm_actionslider.eo
index 27d74ea..84f42d7 100644
--- a/src/lib/elm_actionslider.eo
+++ b/src/lib/elm_actionslider.eo
@@ -25,7 +25,7 @@ class Elm_Actionslider (Elm_Layout)
set {
/*@
Set actionslider magnet position. To make multiple positions
magnets @c or
-them together(e.g.: #ELM_ACTIONSLIDER_LEFT |
#ELM_ACTIONSLIDER_RIGHT)
+them together (e.g. #ELM_ACTIONSLIDER_LEFT |
#ELM_ACTIONSLIDER_RIGHT)
@ingroup Actionslider */
}
diff --git a/src/lib/elm_app_client.eo b/src/lib/elm_app_client.eo
index c2b4bdd..6566158 100644
--- a/src/lib/elm_app_client.eo
+++ b/src/lib/elm_app_client.eo
@@ -8,7 +8,7 @@ class Elm_App_Client (Eo.Base)
/*@ Return a iterator with all views of application. */
}
values {
-iterator *ret; /*@ the iterator with all views, must be freed
after use */
+iterator *ret; /*@ The iterator with all views, must be freed
after use */
}
}
package {
@@ -35,7 +35,7 @@ class Elm_App_Client (Eo.Base)
/*@ Terminate application. */
}
view_open {
- /*@ Open a application view. */
+ /*@ Open an application view. */
params {
@in Eina_Value *args; /*@ an array of */
@in Elm_App_Client_Open_View_Cb view_open_cb; /*@ callback to be
called when view open */
diff --git a/src/lib/elm_config.h b/src/lib/elm_config.h
index aa8a7cb..58d23df 100644
--- a/src/lib/elm_config.h
+++ b/src/lib/elm_config.h
@@ -430,7 +430,7 @@ EAPI double
elm_config_scroll_thumbscroll_friction_standard_get(void);
* same with thumbscroll friction, if the velocity is same with standard
* velocity.
*
- * @param friction the thumb scroll friction standard
+ * @param standard the thumb scroll friction standard
*
* @see elm_config_thumbscroll_friction_standard_get()
* @ingroup Scrolling
@@ -524,7 +524,7 @@ EAPI double
elm_config_scroll_thumbscroll_acceleration_time_limit_get(void
/**
* Set the time limit for accelerating velocity.
*
- * @param threshold the thumb scroll acceleration time limit
+ * @param time_limit the thumb scroll acceleration time limit
*
* @see elm_config_thumbscroll_acceleration_time_limit_get()
* @ingroup Scrolling
@@ -543,7 +543,7 @@ EAPI double
elm_config_scroll_thumbscroll_ac
[EGIT] [core/efl] master 51/56: eina document eina mempools' API.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=020bd415058497a48fc4afa0ae814f2ebe5fa583
commit 020bd415058497a48fc4afa0ae814f2ebe5fa583
Author: Adrien Nader
Date: Mon Oct 20 14:51:37 2014 +0200
eina document eina mempools' API.
Except for the weird _Eina_Mempool_Backend_ABI1/ABI2 work-around which is
completely internal and probably is of interest to noone (the only person
on Earth who will be interested in it in a decade will hate me for skipping
it).
---
src/lib/eina/eina_inline_mempool.x | 16 +
src/lib/eina/eina_mempool.h| 48 ++
2 files changed, 44 insertions(+), 20 deletions(-)
diff --git a/src/lib/eina/eina_inline_mempool.x
b/src/lib/eina/eina_inline_mempool.x
index c33af06..59bf523 100644
--- a/src/lib/eina/eina_inline_mempool.x
+++ b/src/lib/eina/eina_inline_mempool.x
@@ -27,14 +27,30 @@ typedef struct _Eina_Mempool_Backend_ABI2
Eina_Mempool_Backend_ABI2;
struct _Eina_Mempool_Backend
{
+ /** Name of the mempool backend */
const char *name;
+ /** Function to initialize the backend. */
void *(*init)(const char *context, const char *options, va_list args);
+ /** Function to free memory back to the mempool. */
void (*free)(void *data, void *element);
+ /** Function to allocate memory from the mempool. */
void *(*alloc)(void *data, unsigned int size);
+ /** Function to change the size of a block of memory that is currently
+* allocated. */
void *(*realloc)(void *data, void *element, unsigned int size);
+ /** Function to trigger a garbage collection; can be NULL if the feature
+* isn't available in the backend. */
void (*garbage_collect)(void *data);
+ /** Report statistics on the content of the mempool; can be NULL if the
+* feature isn't available in the backend. */
void (*statistics)(void *data);
+ /** Function to destroy the backend, freeing memory back to the operating
+* system. */
void (*shutdown)(void *data);
+ /** Function to optimize the placement of objects in the mempool (it's
+* different from garbage_collect); can be NULL if the feature isn't
+* available in the backend.
+* @see Eina_Mempool_Repack_Cb */
void (*repack)(void *data, Eina_Mempool_Repack_Cb cb, void *cb_data);
};
diff --git a/src/lib/eina/eina_mempool.h b/src/lib/eina/eina_mempool.h
index 9e1d97f..7aaffc2 100644
--- a/src/lib/eina/eina_mempool.h
+++ b/src/lib/eina/eina_mempool.h
@@ -71,8 +71,14 @@ typedef struct _Eina_Mempool_Backend Eina_Mempool_Backend;
/**
* @typedef Eina_Mempool_Repack_Cb
- * Type for a callback who need to unreference an old object from a mempool
- * and reference the new one instead. Memcpy is taken care by the mempool.
+ *
+ * Type for a callback which is called when the mempool "repacks" its data,
+ * i.e. moves it around to optimize the way it is stored in memory. This is
+ * useful to improve data locality and to free internal pools back to the OS.
+ *
+ * The callback needs to update users of the data to stop accessing the object
+ * from the old location and access it using the new location instead. The copy
+ * of memory is taken care of by the mempool.
*/
typedef void (*Eina_Mempool_Repack_Cb)(void *dst, void *src, void *data);
@@ -80,21 +86,22 @@ EAPI extern Eina_Error EINA_ERROR_NOT_MEMPOOL_MODULE;
/**
*
- * @brief TODO
+ * @brief Create a new mempool of the given type
*
- * @param module
- * @param context
- * @param options
+ * @param name Name of the mempool kind to use.
+ * @param context Identifier of the mempool created (for debug purposes).
+ * @param options Unused. Use the variable arguments list instead to pass
options to the mempool.
+ * @param ... Additional options to pass to the allocator; depends entirely on
the type of mempool ("int pool size" for chained and "int item_size" for
one_big.
* @return Newly allocated mempool instance, NULL otherwise.
*
*/
-EAPI Eina_Mempool *eina_mempool_add(const char *module, const char *context,
const char *options, ...) EINA_MALLOC EINA_WARN_UNUSED_RESULT
EINA_ARG_NONNULL(1);
+EAPI Eina_Mempool *eina_mempool_add(const char *name, const char *context,
const char *options, ...) EINA_MALLOC EINA_WARN_UNUSED_RESULT
EINA_ARG_NONNULL(1);
/**
*
- * @brief TODO
+ * @brief Delete the given mempool.
*
- * @param mp The mempools
+ * @param mp The mempool to delete
*
*/
EAPI void eina_mempool_del(Eina_Mempool *mp) EINA_ARG_NONNULL(1);
@@ -154,19 +161,21 @@ static inline void *eina_mempool_calloc(Eina_Mempool *mp,
unsigned int size) EIN
static inline void eina_mempool_free(Eina_Mempool *mp, void *element)
EINA_ARG_NONNULL(1);
/**
- *
- * @brief TODO
+ * @brief Repack the objects in the mempool.
*
* @param mp The mempool
- * @param cb The after repack callback
- * @param data The data
+ * @param cb A callback to u
[EGIT] [core/efl] master 38/56: ecore_audio: add @brief doc for struct Ecore_Audio_Vio.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=d22917626c29249727844fd5eb98d81d164e450b
commit d22917626c29249727844fd5eb98d81d164e450b
Author: Adrien Nader
Date: Mon Oct 13 17:24:27 2014 +0200
ecore_audio: add @brief doc for struct Ecore_Audio_Vio.
It's simply a copy of the one given in the following typedef:
typedef struct _Ecore_Audio_Vio Ecore_Audio_Vio;
---
src/lib/ecore_audio/Ecore_Audio.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/lib/ecore_audio/Ecore_Audio.h
b/src/lib/ecore_audio/Ecore_Audio.h
index e977060..dda0c1b 100644
--- a/src/lib/ecore_audio/Ecore_Audio.h
+++ b/src/lib/ecore_audio/Ecore_Audio.h
@@ -82,6 +82,7 @@ typedef struct _Ecore_Audio_Module Ecore_Audio_Module;
typedef struct _Ecore_Audio_Object Ecore_Audio_Object; /**< The audio object
*/
/*
+ * @brief Structure to hold the callbacks needed to implement virtual file IO
* @since 1.8
*/
struct _Ecore_Audio_Vio {
--
[EGIT] [core/efl] master 40/56: eio: add doc for returns of eio_file_{mkdir, move, copy}, eio_dir_{move, copy}.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=73d58b94465dab056ca727941ecb0eebd822d550
commit 73d58b94465dab056ca727941ecb0eebd822d550
Author: Adrien Nader
Date: Mon Oct 13 17:10:05 2014 +0200
eio: add doc for returns of eio_file_{mkdir,move,copy}, eio_dir_{move,copy}.
---
src/lib/eio/Eio.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/lib/eio/Eio.h b/src/lib/eio/Eio.h
index e120fd6..0eb38c8 100644
--- a/src/lib/eio/Eio.h
+++ b/src/lib/eio/Eio.h
@@ -446,6 +446,7 @@ EAPI Eio_File *eio_file_mkdir(const char *path,
* @param done_cb Callback called when the move is done.
* @param error_cb Callback called when something goes wrong.
* @param data Unmodified user data passed to callbacks
+ * @return A reference to the I/O operation.
*
* @return an Eio_File pointer, handler to the move operation, can be used to
cancel the operation
*
@@ -491,6 +492,7 @@ EAPI Eio_File *eio_file_copy(const char *source,
* @param done_cb Callback called when the copy is done.
* @param error_cb Callback called when something goes wrong.
* @param data Unmodified user data passed to callbacks
+ * @return A reference to the I/O operation.
*
* @return an Eio_File pointer, handler to the move operation, can be used to
cancel the operation
*
@@ -521,6 +523,7 @@ EAPI Eio_File *eio_dir_move(const char *source,
* @param done_cb Callback called when the copy is done.
* @param error_cb Callback called when something goes wrong.
* @param data Unmodified user data passed to callbacks
+ * @return A reference to the I/O operation.
*
* @return an Eio_File pointer, handler to the copy operation, can be used to
cancel the operation
*
@@ -547,6 +550,7 @@ EAPI Eio_File *eio_dir_copy(const char *source,
* @param done_cb Callback called when the copy is done.
* @param error_cb Callback called when something goes wrong.
* @param data Unmodified user data passed to callbacks
+ * @return A reference to the I/O operation.
*
* @return an Eio_File pointer, handler to the unlink operation, can be used
to cancel the operation
*
--
[EGIT] [core/efl] master 50/56: eina: remove @addtogroup in eina_inline_mempool.x: the .h already has it.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=10c4309fa7f366a3a95688c41e1b4d9778c01939
commit 10c4309fa7f366a3a95688c41e1b4d9778c01939
Author: Adrien Nader
Date: Mon Oct 20 13:40:00 2014 +0200
eina: remove @addtogroup in eina_inline_mempool.x: the .h already has it.
It looks like doxygen doesn't appreciate having a group inside a group of
the same name and simply ignores any documentation coming from the parent
one.
Since the .x is included from the .h, it is always already inside the
group so simply remove the directive from the .x.
This fixes the documentation for all the functions which are declared and
documented in the .h and implemented in the .x.
---
src/lib/eina/eina_inline_mempool.x | 10 --
1 file changed, 10 deletions(-)
diff --git a/src/lib/eina/eina_inline_mempool.x
b/src/lib/eina/eina_inline_mempool.x
index 032ce06..c33af06 100644
--- a/src/lib/eina/eina_inline_mempool.x
+++ b/src/lib/eina/eina_inline_mempool.x
@@ -21,12 +21,6 @@
#include
-/**
- * @addtogroup Eina_Memory_Pool_Group Memory Pool
- *
- * @{
- */
-
/* Memory Pool */
typedef struct _Eina_Mempool_Backend_ABI1 Eina_Mempool_Backend_ABI1;
typedef struct _Eina_Mempool_Backend_ABI2 Eina_Mempool_Backend_ABI2;
@@ -128,8 +122,4 @@ eina_mempool_alignof(unsigned int size)
return ((size / align) + (size % align ? 1 : 0)) * align;
}
-/**
- * @}
- */
-
#endif
--
[EGIT] [core/efl] master 39/56: ethumb: document most functions from ethumb.
cedric pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=19a35949dab9b3dfd44a1e063e59132b7ab4f424 commit 19a35949dab9b3dfd44a1e063e59132b7ab4f424 Author: Adrien Nader Date: Fri Oct 17 16:53:40 2014 +0200 ethumb: document most functions from ethumb. --- src/lib/ethumb/Ethumb.h | 140 +++- 1 file changed, 138 insertions(+), 2 deletions(-) diff --git a/src/lib/ethumb/Ethumb.h b/src/lib/ethumb/Ethumb.h index 6a1bd40..46ab759 100644 --- a/src/lib/ethumb/Ethumb.h +++ b/src/lib/ethumb/Ethumb.h @@ -144,10 +144,26 @@ typedef struct _Ethumb Ethumb; */ typedef void (*Ethumb_Generate_Cb)(void *data, Ethumb *e, Eina_Bool success); +/** + * @brief Initialize ethumb. + * @return 1 or greater on success, 0 otherwise. + */ EAPI int ethumb_init(void); +/** + * @brief Shutdown ethumb, unloading all currently-loaded modules. + * @return 0 if ethumb shuts down, an integer greater than 0 otherwise. + */ EAPI int ethumb_shutdown(void); +/** + * @brief Create a new ethumb object. + * return The newly-created ethumb object + */ EAPI Ethumb * ethumb_new(void) EINA_MALLOC EINA_WARN_UNUSED_RESULT; + +/** + * @brief Free an ethumb object. + */ EAPI void ethumb_free(Ethumb *e); /** @@ -212,22 +228,91 @@ typedef enum _Ethumb_Thumb_Orientation EAPI void ethumb_thumb_fdo_set(Ethumb *e, Ethumb_Thumb_FDO_Size s) EINA_ARG_NONNULL(1); +/** + * @brief Set the size of thumbnails. + * + * @param e A pointer to an Ethumb object. + * @param tw Thumbnail width. + * @param th Thumbnail height. + */ EAPI void ethumb_thumb_size_set(Ethumb *e, int tw, int th) EINA_ARG_NONNULL(1); +/** + * @brief Get the size of thumbnails. + * + * @param e A pointer to an Ethumb object. + * @param[out] tw Pointer to an int to store the thumbnail width. + * @param[out] th Pointer to an int to store the thumbnail height. + */ EAPI void ethumb_thumb_size_get(const Ethumb *e, int *tw, int *th) EINA_ARG_NONNULL(1); +/** + * @brief Set the fileformat of the thumbnails + * + * Thumbnails are sent compressed; possible formats are PNG, JPEG and EET. + * + * @param e A pointer to an Ethumb object. + */ EAPI void ethumb_thumb_format_set(Ethumb *e, Ethumb_Thumb_Format f) EINA_ARG_NONNULL(1); +/** + * @brief Get the fileformat of the thumbnails + * + * @param e A pointer to an Ethumb object. + * @return The thumbnail fileformat + * + * @see ethumb_thumb_format_set + */ EAPI Ethumb_Thumb_Format ethumb_thumb_format_get(const Ethumb *e) EINA_WARN_UNUSED_RESULT EINA_ARG_NONNULL(1) EINA_PURE; -EAPI void ethumb_thumb_aspect_set(Ethumb *e, Ethumb_Thumb_Aspect a) EINA_ARG_NONNULL(1); +/** + * @brief Set the aspect ratio policy. + * + * When the source and thumbnail aspect ratios don't match, this policy sets + * how to adapt from the former to the latter: resize keeping source aspect + * ratio, resize ignoring it or crop. + * + * @param e A pointer to an Ethumb object. + * @param aspect The new aspect ratio policy. + */ +EAPI void ethumb_thumb_aspect_set(Ethumb *e, Ethumb_Thumb_Aspect aspect) EINA_ARG_NONNULL(1); +/** + * @brief Get the aspect ratio policy. + * + * @param e A pointer to an Ethumb object. + * @return The aspect ratio policy. + */ EAPI Ethumb_Thumb_Aspect ethumb_thumb_aspect_get(const Ethumb *e) EINA_WARN_UNUSED_RESULT EINA_ARG_NONNULL(1) EINA_PURE; -EAPI void ethumb_thumb_orientation_set(Ethumb *e, Ethumb_Thumb_Orientation o) EINA_ARG_NONNULL(1); +/** + * @brief Set the thumbnail rotation or flip. + * + * @param e A pointer to an Ethumb object. + * @param orientation The new orientation. + */ +EAPI void ethumb_thumb_orientation_set(Ethumb *e, Ethumb_Thumb_Orientation orientation) EINA_ARG_NONNULL(1); +/** + * @brief Get the thumbnail rotation. + * + * @param e A pointer to an Ethumb object. + * @return The current rotation. + */ EAPI Ethumb_Thumb_Orientation ethumb_thumb_orientation_get(const Ethumb *e) EINA_WARN_UNUSED_RESULT EINA_ARG_NONNULL(1) EINA_PURE; EAPI void ethumb_thumb_crop_align_set(Ethumb *e, float x, float y) EINA_ARG_NONNULL(1); EAPI void ethumb_thumb_crop_align_get(const Ethumb *e, float *x, float *y) EINA_ARG_NONNULL(1); +/** + * @brief Set the thumbnail compression quality. + * + * @param e A pointer to an Ethumb object. + * @param quality Compression quality (from 0 to 100, 100 being the best; default is 80) + */ EAPI void ethumb_thumb_quality_set(Ethumb *e, int quality) EINA_ARG_NONNULL(1); +/** + * @brief Get the thumbnail compression quality. + * + * @param e A pointer to an Ethumb object. + * @return The current compression quality (from 0 to 100, 100 being the best) + */ EAPI int ethumb_thumb_quality_get(const Ethumb *e) EINA_ARG_NONNULL(1) EINA_WARN_UNUSED_RESULT EINA_PURE; EAPI void ethumb_thumb_compress_set(Ethumb *e, int compress) EINA_ARG_NO
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, Sep 29, 2014, Doug Newgard wrote: > > > > > Date: Mon, 29 Sep 2014 15:54:44 +0100 > > From: tom.haco...@samsung.com > > To: enlightenment-devel@lists.sourceforge.net > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > `udev_device_set_sysattr_value' [...] snip > > Again, an horrible precedence and a passive aggressive way of saying "we > > no longer support all of you guys who haven't jumped on the systemd > > band-wagon". > > udev works fine without systemd. Those distros that are refusing to update > past 184 are either ones that use ancient software anyway or they are just > taking a very childish stance and refusing to even build it now. Distros tend to not move past 184 (or 182 here) precisely because it's annoying to get building and working. It's not simply because they're being childish. But anyway, the point is moot. Have a look at http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html Quoting: > Also note that at that point we intend to move udev onto kdbus as > transport, and get rid of the userspace-to-userspace netlink-based > tranport udev used so far. Unless the systemd-haters prepare another > kdbus userspace until then this will effectively also mean that we will > not support non-systemd systems with udev anymore starting at that > point. Gentoo folks, this is your wakeup call. IOW, even if it were all working nicely right now, that won't last. For future versions this raises the issue of chosing what is being depended upon. As far as I'm concerned, I don't really care but thought that you should remember that even in the best case for compatibility, this won't last long. Regards, Adrien Nader -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The state of EFL/Elementary's Cross Platform Support
Spent a bit more time on that, had to fight windows dumbness and a bug in libarchive which only appeared when having forbidden chars in paths on windows. Anyway, here is the end result after installing all packages (and not crashing when doing so): http://i.imgur.com//8pIl5uG.png (font will soon be dejavu sans) -- Adrien Nader -- Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] The state of EFL/Elementary's Cross Platform Support
Hi, Currently I have this application running on Windows well enough: http://win-builds.org/screenshot.png THat's the package manager Cedric talked about and it's almost good for release, with only a few bugs to iron out and a release within a month. Overall, things work well. The issues I'm seeing: - elm_init() fails 60% of the time _except_ when run from gdb (handy) - threads are flaky and I think this can be solved by adding winpthreads as a dependency to EFL and then making the code common between usual pthreads-platforms and windows - "backspace" doesn't work in entries (will likely be fixed soon) Apart from that I get the same behaviour on Linux and Windows. One thing I haven't been able to spend time on is the initial packaging: put the .exe and .dll files and data files and everything in an auto-extractible archive. This should work but might require some fiddling with paths in which the various components search for their data. A bit of work but I'm not worried. (static linking is not really usable however because of plugins: dlopen() of .a file won't work...) -- Adrien Nader -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 03/04: efreet: replace 4096 with sizeof(buf) in snprintf(buf, 4096, ...).
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=a2d8c1651ba14a97d2accb2b78fef1b7f5d1202f
commit a2d8c1651ba14a97d2accb2b78fef1b7f5d1202f
Author: Adrien Nader
Date: Sat Aug 9 12:18:31 2014 +0200
efreet: replace 4096 with sizeof(buf) in snprintf(buf, 4096, ...).
buf is a local variable defined as:
char buf[4096];
The current code is correct; this change only makes sure the value won't
get out-of-sync later on.
---
src/lib/efreet/efreet_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/efreet/efreet_base.c b/src/lib/efreet/efreet_base.c
index 7a20a9c..f43b1dd 100644
--- a/src/lib/efreet/efreet_base.c
+++ b/src/lib/efreet/efreet_base.c
@@ -305,7 +305,7 @@ efreet_dirs_init(void)
/* xdg_data_dirs */
#ifdef _WIN32
-snprintf(buf, 4096, "%s\\Efl;" DATA_DIR ";/usr/share;/usr/local/share",
getenv("APPDATA"));
+snprintf(buf, sizeof(buf), "%s\\Efl;" DATA_DIR
";/usr/share;/usr/local/share", getenv("APPDATA"));
xdg_data_dirs = efreet_dirs_get("XDG_DATA_DIRS", buf);
#else
xdg_data_dirs = efreet_dirs_get("XDG_DATA_DIRS",
--
[EGIT] [core/efl] master 01/04: efreet: remove #ifdef GETUID inside #ifdef _WIN32 (it's always false).
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=0fb9f5d5163fbeb5304684714f7e9aa41f1485a5
commit 0fb9f5d5163fbeb5304684714f7e9aa41f1485a5
Author: Adrien Nader
Date: Sat Aug 9 12:00:32 2014 +0200
efreet: remove #ifdef GETUID inside #ifdef _WIN32 (it's always false).
---
src/lib/efreet/efreet_base.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/lib/efreet/efreet_base.c b/src/lib/efreet/efreet_base.c
index 20c248b..dfc5a3a 100644
--- a/src/lib/efreet/efreet_base.c
+++ b/src/lib/efreet/efreet_base.c
@@ -291,9 +291,6 @@ efreet_dirs_init(void)
#ifdef _WIN32
if (!efreet_home_dir || efreet_home_dir[0] == '\0')
{
-#if defined(HAVE_GETUID) && defined(HAVE_GETEUID)
- if (getuid() == geteuid())
-#endif
efreet_home_dir = getenv("USERPROFILE");
}
#endif
--
[EGIT] [core/efl] master 02/04: efreet: reverse if's condition and swap then/else blocks for readability
raster pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=37780369266db89e968bf646ca76aa7605f00c78
commit 37780369266db89e968bf646ca76aa7605f00c78
Author: Adrien Nader
Date: Sat Aug 9 12:09:44 2014 +0200
efreet: reverse if's condition and swap then/else blocks for readability
The reversal makes it possible to merge two #if and unspaghetti the code
a bit.
Since the diff is not very readable, here is the before/after to show
the spirit:
before:
#if cond
if (...)
#endif
do_foo();
#if cond
else
do_bar();
#endif
after:
#if cond
if ( ! ...)
do_bar();
else
#endif
do_foo();
---
src/lib/efreet/efreet_base.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/lib/efreet/efreet_base.c b/src/lib/efreet/efreet_base.c
index dfc5a3a..7a20a9c 100644
--- a/src/lib/efreet/efreet_base.c
+++ b/src/lib/efreet/efreet_base.c
@@ -277,17 +277,16 @@ efreet_dirs_init(void)
/* efreet_home_dir */
#if defined(HAVE_GETUID) && defined(HAVE_GETEUID)
- if (getuid() == geteuid())
-#endif
- efreet_home_dir = getenv("HOME");
-#if defined(HAVE_GETUID) && defined(HAVE_GETEUID)
- else
+ if (getuid() != geteuid())
{
struct passwd *pw = getpwent();
if ((pw) && (pw->pw_dir)) efreet_home_dir = pw->pw_dir;
}
+ else
#endif
+ efreet_home_dir = getenv("HOME");
+
#ifdef _WIN32
if (!efreet_home_dir || efreet_home_dir[0] == '\0')
{
--
Re: [E-devel] Upcoming efl and elm 1.9.2
On Mon, Mar 24, 2014, Stefan Schmidt wrote: > Hello. > > On Mon, 2014-03-24 at 11:25, Stefan Schmidt wrote: > > Hello. > > > > On Mon, 2014-03-24 at 11:19, Adrien Nader wrote: > > > Hi, > > > > > > On Thu, Mar 20, 2014, Stefan Schmidt wrote: > > > > Hello. > > > > > > > > I plan a new stable update for beginning of next week. > > > > > > > > Please bring in all fixes at the weekend so I can cut the tarballs on > > > > Monday and hopefully release after some testing on Tuesday. > > > > > > I'm piggy-backing on this thread for a simple fix in elementary when > > > regex.h isn't available (windows typically). > > > > > > In src/modules/prefs/Makefile.am, @EVIL_LIBDS@ must be appended to the > > > definition of module_la_LIBADD. > > > Simple enough to not make and send a patch imho but if it's wanted, I > > > can do that too. > > > > I will fix this up. Thanks for letting us know! > > Done in master and backported to the 1.9 branch. Will be in the 1.92. > release I'm going to prepare right now. Perfect, thanks a lot. -- Adrien Nader -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Upcoming efl and elm 1.9.2
Hi, On Thu, Mar 20, 2014, Stefan Schmidt wrote: > Hello. > > I plan a new stable update for beginning of next week. > > Please bring in all fixes at the weekend so I can cut the tarballs on > Monday and hopefully release after some testing on Tuesday. I'm piggy-backing on this thread for a simple fix in elementary when regex.h isn't available (windows typically). In src/modules/prefs/Makefile.am, @EVIL_LIBDS@ must be appended to the definition of module_la_LIBADD. Simple enough to not make and send a patch imho but if it's wanted, I can do that too. Regards, Adrien Nader -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prposed release schedule for 1.10
On Wed, Feb 26, 2014, Stefan Schmidt wrote:
> Hello.
>
> On Tue, 2014-02-25 at 23:10, Adrien Nader wrote:
> > I am the main dev behind http://win-builds.org which makes builds for,
> > well, Windows. Everything is cross-compiled from linux64. Windows is one
> > of the platforms that gets built and tested less often
>
> It should get build for every push to efl master. Jenkins takes care
> of that. It is correct though that it is broken more often than the
> other builds.
>
> > and we found
> > several issues in beta1 (you can see windows and cross-compilation fixes
> > in git soon after beta1).
>
> Thanks!
Most changes required were fairly simple and half the work was to throw
any issue at cedric and jpeg. :)
I'm a bit surprised the bot could build successfully though. I guess
that either some issues were not noticed, that there timing issues
and/or that some things would succeed if the system already had a
previous cross-build installed. Difficult to say but again, there
weren't that many things to change in the end.
> > While I am a developer, I do not intend to take a more active role in
> > the development of the EFLs. Using them, yes; working on them, there's
> > simply no time for that. This is one of the reasons I don't build and
> > test intermediate versions. Another reason is that for platforms that
> > get tested less, this would mean getting way too many errors.
>
>
> And here we have the problem. Nobody is willing to invest in having
> efl working well on mingw/windows. You did some patches which is more
> than other people do so thanks for that.
>
> Still, what I mostly hear is like "EFL needs to support windows
> because the app I write should work there". But the reality is that
> none of the active developers is using it or working on it behind the
> causual bug fix if jenkins complains about broken builds. The mingw
> automated build on jenkins is as what Cedric and I did to have at
> leats an idea if we break stuff for mingw on the compilation side. Its
> as far as I personally will go.
>
> I siad it before and I will say it it again to everyone who wants efl
> top support mingw/windows as a first class citizen:
>
> If you don't do the work nobody else does.
>
> It may sound harsh but I have done my share on keeping the mingw port
> build even if I have _zero_ interest in it.
It's already much better than some libraries. The rules could be as
simple as:
1- don't break the build
2- try not to rely on _approaches_ that are specific to either Linux or
GNU; functions specific to one of them should be mostly fine but
approaches (think "cgroups"), not
Is there a place which centralizes the expected features by platform?
Like if someone adds an #ifdef around some feature, is it mentioned
somewhere which isn't the code?
> > I tried 1.9 beta1 because Cedric asked me to do it and I had some free
> > time that day. With only one week between beta and the release, it is
> > difficult to test and it is highly likely that my time will already be
> > allocated for something else. This is without even accounting for other
> > changes like evolving packaging, dependency on luajit (mostly to
> > evaluate it), ...
>
> I would suggest startring with the alpha that would give you one more
> week. To late now for 1.9 anyway just saying.
I know Cedric had kept the mingw port at least working. Unfortunately,
earlier testing was hampered by lack of time and new dependencies mostly
(which were not showstoppers but required mind time for packaging).
I will try to track stuff more closely, I'm finally getting close to the
end of my backlog^W^Wone of my backlogs.
> > >From my packager perspective, more time between beta and final release
> > is better. From my developer perspective, I actually like it when other
> > devs get bored with the feeling they have nothing to do near the end of
> > a stabilization period.
>
> If they would get bored it would be good. What I see though is that
> people loose interest if the stabilization phase is to long and just
> start working on new developments. In the end these people are not
> working on bug fixes and thus a longer time brings nothing.
True, that can happen as well.
> > The main need is to be able to iterate several times with {build, test,
> > report issue/send patch, have it commited} and for that the 1.9 setup
> > has been quite short. I believe the two weeks will be much better.
>
> You really should start with the alpha which gives you three weeks
> during 1.10 if the schedule I proposed holds.
I hope I can do builds earlier. That requires me getting 1.4 (at least
beta) of win-builds out but I'
Re: [E-devel] Prposed release schedule for 1.10
Hi again,
I mentionned in the "1.9 release should happen within the next 24h"
thread that I found the last step too short and I'm answering here since
I find it more appropriate.
I am the main dev behind http://win-builds.org which makes builds for,
well, Windows. Everything is cross-compiled from linux64. Windows is one
of the platforms that gets built and tested less often and we found
several issues in beta1 (you can see windows and cross-compilation fixes
in git soon after beta1).
(it's Windows but it could as well be Linux on MIPS; it's not Linux
x86/x86_64 nor Linux ARM and it's not tested often)
While I am a developer, I do not intend to take a more active role in
the development of the EFLs. Using them, yes; working on them, there's
simply no time for that. This is one of the reasons I don't build and
test intermediate versions. Another reason is that for platforms that
get tested less, this would mean getting way too many errors.
I tried 1.9 beta1 because Cedric asked me to do it and I had some free
time that day. With only one week between beta and the release, it is
difficult to test and it is highly likely that my time will already be
allocated for something else. This is without even accounting for other
changes like evolving packaging, dependency on luajit (mostly to
evaluate it), ...
The 1.8 release is actually broken for Windows and we only noticed too
late; as far as I remember, the changes required were not trivial and we
decided to call 1.8 a version that could never work on Windows and
instead spend time to get 1.9 working again.
>From my packager perspective, more time between beta and final release
is better. From my developer perspective, I actually like it when other
devs get bored with the feeling they have nothing to do near the end of
a stabilization period. Of course that might not match your needs.
The main need is to be able to iterate several times with {build, test,
report issue/send patch, have it commited} and for that the 1.9 setup
has been quite short. I believe the two weeks will be much better.
PS: I also hope that before 1.10 alpha, I will have finished a few
changes to win-builds to harass most of you into testing for Windows.
PS2: Wine works well enough.
--
Adrien Nader
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.9 release should happen within the next 24h
Hi, I don't expect, nor intend, to delay the release of 1.9. I only want to record my belief as a packager that the release cycles are too short and that the stabilization phases are _way_ too short (let's face it, no packager does continuous integration/packaging). -- Adrien Nader -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
Hi, On Wed, Oct 02, 2013, Gustavo Sverzut Barbieri wrote: > -0 I'm not convinced but I don't have any evidence that it's bad, just > a personal feeling. All it does is add a commit that says "branch X was merged in branch Y". There are two possible drawbacks: - commit message should be checked to contain meaningful branch names (you can end up with bad names if you use bad names in your local branches and expect these names to never be seen by the public) - one useless commit (some people actually don't like it) -- Adrien Nader -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [GIT] HTTP cloning
Older versions of git had a dumb protocol over HTTP. It's been improved
for more than a year.
On Sun, Feb 24, 2013, Bertrand Jacquin wrote:
> Not really, it does not use stock HTTP (GET every objects, pack etc), it
> use git-http-backend that is CGI code that use git-upload-pack and git
> pack-objects as git daemon does. You only have HTTP headers as an overhead.
>
> To compar time between both I did clone core/efl.git with HTTP and git
> protocol from a server in france :
>
> git: 1m35.757s
> http: 1m31.452s
>
> You are free to repeat at your home. In any case git:// should be
> prefered.
>
> D'ar sul 24 a viz C'hwevrer 2013 e 15 eur 26, « Daniel Juyung Seo » he deus
> skrivet :
> > Yes it's cool to have. Thanks Bertrand Jacquin.
> > But as Tom mentioned git is way faster.
> > So try git first and setup git proxy if one uses proxy. If it fails,
> > use this http stuff.
> >
> > Anyway great!
> > Thanks.
> >
> > Daniel Juyung Seo (SeoZ)
> >
> >
> > On Sun, Feb 24, 2013 at 11:16 PM, Tom Hacohen wrote:
> > > Cool to have, but guys, if you can use the git protocol, you should. It
> > > should be way faster, and less hard on the server.
> > >
> > > --
> > > Tom.
> > >
> > >
> > > On Sun, Feb 24, 2013 at 1:17 PM, Bertrand Jacquin
> > > wrote:
> > >
> > >> D'ar sul 24 a viz C'hwevrer 2013 e 14 eur 12, « Carsten Haitzler » he
> > >> deus
> > >> skrivet :
> > >> > On Sun, 24 Feb 2013 13:50:07 +0100 Bertrand Jacquin
> > >> >
> > >> said:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > Pretty sure nobody will care about, but now all git repositories have
> > >> > > read only access via HTTP for thoses behind firewall.
> > >> > >
> > >> > > The clone URL in cgit have been updated to report the cloning URL.
> > >> > > This
> > >> > > URL is the same shown in your browser URL bar, don't panic, this is
> > >> > > handled by filtering the requested file that never conflict with
> > >> > > cgit.
> > >> > > Some htaccess magic does help.
> > >> > >
> > >> > > So for official git repositoried, it now give the following :
> > >> > >
> > >> > > http://git.enlightenment.org/core/efl.git
> > >> > > http://git.enlightenment.org/core/elementary.git
> > >> > > http://git.enlightenment.org/core/enlightenment.git
> > >> >
> > >> > this is actually rather cool. :) it was one of those benefits "out of
> > >> the box"
> > >> > for svn originally. :)
> > >>
> > >> For thoses who are interested in a such configuration :
> > >>
> > >> # Force no Indexes in all cases
> > >> # Force ExecCGI
> > >> # FollowSymlinks for RewriteEngine
> > >> Options -Indexes ExecCGI FollowSymlinks
> > >>
> > >> AddHandler cgi-script .cgi
> > >> # No index.html or other things
> > >> DirectoryIndex cgit.cgi
> > >>
> > >> # Config is locally hosted, not depending on root filesystem
> > >> SetEnv CGIT_CONFIG ./cgitrc
> > >>
> > >> # git-html-backend config
> > >> # GIT_HTTP_EXPORT_ALL is not setted, gitolite is creating
> > >> git-daemon-export-ok
> > >> SetEnv GIT_PROJECT_ROOT /srv/gitolite/repositories
> > >>
> > >> RewriteEngine On
> > >>
> > >> # Disable HTTPS
> > >> RewriteCond %{ENV:HTTPS} On
> > >> RewriteRule ^(.*)http://%{SERVER_NAME}/$1 [R=301,L]
> > >>
> > >> # Stop here if cgit is handling the request
> > >> RewriteCond %{REQUEST_URI} ^/cgit.cgi
> > >> RewriteRule (.*) - [L]
> > >>
> > >> # Stop here if git-http-backend is handling the request
> > >> RewriteCond %{REQUEST_URI} ^/git-http-backend.cgi
> > >> RewriteRule (.*) - [L]
> > >>
> > >> # Refuse to serve to users the config file
> > >> RewriteCond %{REQUEST_URI} ^/cgitrc
> > >> RewriteRule (.*) - [F,L]
> > >>
> > >> # Disable git-http-backend write access
> > >> RewriteCond %{REQUEST_URI} ^(.*)\.git/git-receive-pack
> > >> RewriteRule (.*) - [F,L]
> > >>
> > >> # Access to git files is a the same URL than cgit, filter them
> > >> RewriteCond %{REQUEST_URI} ^(.*)\.git/HEAD$
> > >> [OR]
> > >> RewriteCond %{REQUEST_URI} ^(.*)\.git/info/refs$
> > >> [OR]
> > >> RewriteCond %{REQUEST_URI} ^(.*)\.git/objects/info/[^/]+
> > >> [OR]
> > >> RewriteCond %{REQUEST_URI} ^(.*)\.git/objects/[0-9a-f]{2}/[0-9a-f]{38}$
> > >> [OR]
> > >> RewriteCond %{REQUEST_URI} ^(.*)\.git/pack/pack-[0-9a-f]{40}\.(pack|idx)$
> > >> [OR]
> > >> RewriteCond %{REQUEST_URI} ^(.*)\.git/git-upload-pack$
> > >> RewriteRule (.*) /git-http-backend.cgi/$1 [L,QSA]
> > >>
> > >> # Access cgit from /
> > >> RewriteRule ^([^/]+)(/(.*)) /cgit.cgi/$1$2 [L,QSA,NS]
> > >>
> > >> --
> > >> Beber
> > >>
> > >>
> > >> --
> > >> Everyone hates slow websites. So do we.
> > >> Make your web apps faster with AppDynamics
> > >> Download AppDynamics Lite for free today:
> > >> http://p.sf.net/sfu/appdyn_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
On Fri, Jan 11, 2013, Carsten Haitzler wrote: > On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel said: > > > On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL > > wrote: > > > > > On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler > > > wrote: > > > > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL > > > > said: > > > >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > > > >> wrote: > > > >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL > > > >> > said: > > > >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > > > >> >> wrote: > > > >> >> > After lucas commit, i tried to build EFL merge for win32. > > > >> >> > > > > >> >> > i configure with : ./configure --prefix=$MINGW_PREFIX > > > >> >> > --host=$TARGET --disable-static --with-tests=none > > > >> >> > --with-crypto=gnutls --disable-gstreamer > > > >> >> > --disable-pulseaudio --disable-audio --disable-physics > > > >> >> > > > > >> >> > --disable-gstreamer option does't work at all, it's ignored, > > > >> >> > attached a patch which fix this issue. > > > >> >> > > > > >> >> > The next issue is that the configure try to check for eeze, > > > >> >> > but eeze is a linux only package, it's a non sense for > > > >> >> > windows or macos. So how to remove eeze from the build ? > > > >> >> > It could be a good option to add a --disable-eeze option in > > > >> >> > the configure ? what you think about it ? > > > >> >> > > > >> >> Obviously, yes. > > > >> >> > > > >> >> I think we really need to setup a buildbot for mingw as the > > > >> >> last serie of patch prove that nobody did test it at all and > > > >> >> made change that are likely to break it. > > > >> > > > > >> > first... need to make a qemu vm for windows... and that means a > > > >> > windows licence/copy at a minimum. we should test a real build > > > >> > ON windows ... as opposed to a cross-compile. here's the > > > >> > question. windows xp, vista, 7 or 8? sure - in theory we should > > > >> > have all. in theory if we use xp... then what we build > > > >> > binary-wise AND the build itself should work on later versions > > > >> > too... > > > >> > > > >> At this point, just automated building will be a huge step > > > >> forward... > > > > > > > > but we can't build on windows.. without a windows... install ... to > > > > build on. :P > > > > > > Cross compilation is faster as far as I know for windows :-) > > > > Vincent's Windows stuff was made to cross compile with mingw under > > Linux. That's the main delivery method he used. So no need for a > > Windows license to compile it. And as Cedric said, at least that means > > we can make sure compiling is not broken. Leave the result easily > > downloaded, and I'm sure people will download it to test it on their > > expensive Windows installs. > > but we can't make sure that compiling *ON* windows is not broken. we also > can't > verify if it runs properly or not (missing symbols, modules simply not loading > at all etc.). Don't worry about missing symbols, there can be no undefined symbols in DLLs (that's in the design of the PE loader). Anyway, I get your point and I agree that's a goal but it's much more work. However it is *cross*-compilation which is way cleaner and nicer than compiling from something on windows. Various thoughts as bullet points: - building from cygwin to windows (not to cygwin) is cross-compilation - building from msys to windows (not to msys) is cross-compilation - msys is a big ugly hack (a fork of cygwin and a never-upstreamed fork of gcc 2.95 or 2.96 to add a specific target) - msys is a bastard in the first meaning of the name: it's a tentative mix of windows and posix, a guess of what comes from which, goes where and how it should be translated - buildbots on msys and cygwin will probably never be able to handle the load because of how slow they will be (iirc it took Vincent 10 times longer to build elementary from msys) and a ccache would probably make t
Re: [E-devel] [e] OpenBSD & shm_open()
On Sun, Dec 16, 2012, Vincent Torri wrote: > On Sun, Dec 16, 2012 at 11:33 AM, Carsten Haitzler > wrote: > > On Sun, 16 Dec 2012 10:54:24 +0100 Maxime Villard said: > > > >> Hi, > >> == efl/src/modules/ecore_evas/engines/buffer/ecore_evas_extn.c == > >> OpenBSD doesn't have shm_open(), just shmget(). As ecore_evas_extn.c > >> doesn't seem to be used, I commented all the file and it works, but > >> it would be better if someone adds #elif HAVE_SHMGET or replaces > >> shm_open() by shmget(), which is standardized. I don't know these > >> things. > >> > >> Thanks > > > > i'ts used by elementary. we will be doing more of this shm_open... because > > it's > > frankly immensely more useful than sysv shm. > > > > 1. you have a NAME to share things by... easy to have a common known name > > 2. evas cserve2 is built on it and cserve2 will becomes required - no > > choice. > > 3. shm_open etc. uses fd's and mmap. unlike sysvshm.. u can resize a shm > > segment by just munmap+mmap or mremap(). sysvshm in linxu has some > > EXTENSIONS > > to do this, but its non-standard... > > > > so you won't be able to avoid shm_open for a lot longer... so i suggest, > > instead of "just disable it for bsd", you find an acceptable solution... > > maybe > > pressure open/free/whatever bsd kernel devs to support it. we probably need > > to > > move this api/abstraction into eina - BUT... at some point those os's that > > dont > > provide something as feasible/usable/nice as above are going to have a bad > > day. :) > > then annonce *clearly* that you support only POSIX systems, that is, > you don't suport anymore Windows, BSD (and Mac) and Solaris, hence it > remains only linux. I see things a bit differently: we know that windows mac and solaris won't change easily. The BSDs (I've never considered Mac OS X as a BSD system btw) can change. That function is POSIX.1-2001 and most of the BSDs boast themselves as sticking to standards. This is something they should _want_ to have and I don't understand why they don't. Are there bug tracker entries for that issue or any explanation why this function is not available? With that said, considering that it will take a new OS release for such functions to become available and that it'll take time for people to upgrade, it's clear there will be an issue when this code is released. The portability issue with cserve2 has already been mentionned a few months ago and there was no solution that fit everyone's needs. The EFLs are working rather well nowadays overall and such things are comfort compared to platform support (yes, I'm thinking of Windows here). Does the lack of cserve2 (or others) prevents making applications? And if it does, maybe that most people are willing to trade that functionality bit for better platform support. I agree SysV IPC is really annoying but at some point, adding all the time more stuff that works on linux but not elsewhere gives way too much work for the few people who do the porting. It makes the porting effort a continuous unrewarding sprint. GTK has issues with Windows, Qt's support in the future doesn't seem terribly good to me. It's always the same story and it'd be a shame for the EFLs to take the same path instead of taking advantage of a better support when the other toolkits are getting worse. -- Adrien Nader -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Annotations for binding generation
Hi, I'm interested in bindings to several libraries but I don't want to do it by hand. I definitely prefer to automate their generation. Unfortunately, some type information is missing. The best example is probably with lists and other data structures: eina_module_list_get() returns an Eina_List but what is the type of the elements inside it? In this case, it's an Eina_Module list: quite understandable to humans but unusable for automated tasks. For some languages, lacking this kind of information prevents building an API with a native feel and is even dangerous sometimes. C++ would call them "std::vector" or so, Go would have "list of Eina_Module", OCaml would name them "Eina_Module list". The Glib people did it (almost) right and have annotations in their code. There are two interesting documentation pages about it: https://live.gnome.org/GObjectIntrospection/Annotations https://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs I definitely don't agree with everything there but it's worth a quick read to see ideas and examples. This leaves a couple questions: - can doxygen be used to extract annotations; if not, I can write something reliable to do it - which format to use (glib uses S-expressions which are simple to parse) I'll also mention a few more benefits of more annotations and more bindings: - makes some bad APIs more obvious - finds irregular function names - better developer documentation (thinking about the exact return type of eina_module_list_get() late in the day after a very stressful day didn't prove very successful for me) - exercises more parts of the code - can bring some interesting concepts (and I already have a secret experiment planned :-) ) Any comment? Overall I find Glib's annotations to be pretty well-done so I'd be tempted to do it similarly. Also, without such bindings, I'd be forced to do more GTK+ and less EFL (plus I pay beers). ='( -- Adrien Nader -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eyesight and mupdf : build a shared lib of mupdf or link mupdf statically against eyesight ?
Hi, On Mon, Jul 30, 2012, Vincent Torri wrote: > Hey > > I plan to update mupdf from 0.9 to 1.0. So i'm writing the build > system for that version. As mupdf is not necessarly included in the > distros, I integrate the mupdf source in eyesight and I build it. I'm > now wondering if I should build a shared lib of mupdf and install it, > or if i should statically link mupdf against the pdf module of > eyesight. Basically: > > 1) integrate mupdf and its thirdparty package (which includes : > libjpeg, freetype, openjpeg, jbig2dec and zlib), i build them and I > statically link all that against the pdf module of eyesight That reminds me of firefox and everything in the mozilla family, chrome/chromium, qt and a couple others too. Slower builds, bigger downloads (firefox' source is currently 80MB, qt's is 150MB or so), and typically, done like crap. I'm sure you'd do a good job but then something remains: security updates. It's more work for you, and probably for everyone. Not worth the drawbacks. > 2) or I ask the user to have libjpeg, freetype, openjpeg, jbig2dec and > zlib already installed, I build mupdf and I link mupdf statically > against the pdf module of eyesight Libjpeg, zlib, freetype, are absolutely everywhere. Openjpeg is available everywhere too (fedora, slackware, debian, opensuse) and I think jbig2dec will be too (it's in slackware at least, I think it's a dep of something else which is widely used). > 3) or I ask the user to have libjpeg, freetype, openjpeg, jbig2dec and > zlib already installed, I build mupdf as a shared lib and the pdf > module will use the shared lib of mupdf. I don't have a preference for shared over static as long as your shared library of mupdf doesn't end up in the system libdir where it could create conflicts. > What is the best solution ? C! Like in any multiple-chose questionnaire. -- Adrien Nader -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
Hi, Someone from #tukaani on freenode has just made some benchmarks which can be relevant here: http://pokecraft.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO Speed will probably be impacted quite a lot by the data but I expect memory usage to not change. Anyway, not my benchmark, I can't say anything about how good it is (and anyway, you shouldn't believe me :-)). -- Adrien Nader -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn trunk/PROTO/eobj/lib
On Tue, May 08, 2012, Vincent Torri wrote: > On Tue, May 8, 2012 at 9:27 AM, Tom Hacohen wrote: > > On 08/05/12 10:25, Vincent Torri wrote: > >> > >> I also don't know such lib, but i also don't know the libraries that > >> will be written in the future as well. > > > > > > That's their job not to steal the namespace, the same way we hope they won't > > steal azy, evas, eina and etc... > > http://eodev.sourceforge.net/eo/doc/html/index.html > > it's a C++ library that has eo as namespace. That means that if > someone writes a C++ binding of our Eo, its namespace will conflict > withthe above library if they are used together. Hi, >From an external point-of-view, "eo" is not very explicit while "eobj" is clear. -- Adrien Nader -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
Hi, On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri said: > hey > > just found that while reading the gnutls ML : > > http://code.google.com/p/lz4/ > > it seems that it allows the same ratio for compression than zlib but > seems to be by far faster than zlib > > the memory consumption should be tested too. > > What do you think ? New compression formats and libraries regularly get released and my biggest concern is always that they introduce incompatible changes every few months. As far as I can tell, this isn't the case for lz4, which should be a good point (even though there seems to be some changes coming; but as long as they don't happen every few months...). > Other than that, would it really be worth it? Even if in the best case > the compression is only a little worse than zlib and compression time > would be a lot faster - would it really be worth it? > Eet usually is used WORM-style (Write Once / Read Many), so > compression time is hardly an issue - but if decompression is not > significantly faster (or even slower?), and file size is larger (thus > I/O, which more often than not is a bottle-neck nowadays, being lower) > you'd actually not gain anything but lose run-time performance > instead. > On the lz4hc page I only spotted compression benchmarks, nothing about > decompression - if basic information is missing, there usually is a > reason. > > If anything, what would make sense for Eet would be the XZ format, using LZMA. > Compared to zlib, compression is a lot slower, but decompression is > not much slower - and compression ratio and through that I/O > throughput a lot higher. > XZs liblzma is LGPLv2.1 though. XZ(lzma2)/lzma have variable memory requirements. The xz manpage explains pretty much everything (and #tukaani on freenode is a nice place if you have questions). Here is the summary: The following table summarises the features of the presets: Preset DictSize CompCPU CompMem DecMem -0 256 KiB 03 MiB1 MiB -1 1 MiB 19 MiB2 MiB -2 2 MiB 2 17 MiB3 MiB -3 4 MiB 3 32 MiB5 MiB -4 4 MiB 4 48 MiB5 MiB -5 8 MiB 5 94 MiB9 MiB -6 8 MiB 6 94 MiB9 MiB -7 16 MiB 6 186 MiB 17 MiB -8 32 MiB 6 370 MiB 33 MiB -9 64 MiB 6 674 MiB 65 MiB This shows the big picture, but reading the manpage is quite important (it's detailled and informative). That reminds me of one very nice feature of lzma: the decompression speed is roughly constant in terms of compressed data, i.e. it is independant of the uncompressed size. In other words, if 10MB of data gets compressed down to 1MB, it'll get decompressed five times faster than 10MB of data that got compressed down to 5MB. However, iirc, lzma can use quite a lot of memory bandwidth. -- Adrien Nader -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Internship request - bindings creation and package management on windows
Hello, I am a student who will graduate soon with an MSc in electronics and computer science (French "ingénieur" degree). I have created a package manager for use with Microsoft Windows and embedded systems and have also acquired experience in the automated generation of language bindings. My final year ends with a 6-months internship during which I'd like to improve and promote the EFLs by making them easier to install and use. While laying out my own internship topics may seem presumptuous, I know these problems are currently open and many people are expecting a solution. I believe I will be able to solve them thanks to the time alloted for the internship. === Package manager === The EFLs are currently relatively easy to install with the usual configure, make, make install steps and a good Windows port is even available. However, getting a full development environment on Windows or for a mobile phone is tedious and updates are painful. Simplifying the installation of the EFLs will make discovery and maintenance easier for all kind of platforms. I have been developing yypkg[1], a fast and stable package manager meant for environments that have been difficult to target so far: embedded systems and Windows. It is not perfect yet, but it can already be used for daily work and is a good base for further development. Moreover, it will likely become the official package manager for the mingw-w64 project. == Proposal == The core of yypkg works well but EFL and mingw-w64 people have asked for features which should be implemented. The packages themselves will then have to be created in order to create a "click-and-play" development environment. === Language Bindings === With GTK, the libraries are written in C and are intended to be also used from other languages. This gives the best of both languages: rapid prototyping and simpler code logic, while maintaining the performance level. == Proposal == With the size of current libraries, only automatic generation of language bindings is realistic. However, a common issue is the ambiguity of some C constructs: "int*" in a function argument could be an array of integers or a value the callee will change. The task would therefore be to augment the EFLs with disambiguating information and write a complete binding generator. If you are interested in my proposal for solving these two issues and are able to hire an intern in or around Paris for 6 months, starting in March, or know someone who would be please contact me. I have made this message short on purpose but I will gladly answer any question in much more details, possibly at the FOSDEM which I will be attending. [1] http://yypkg.forge.ocamlcore.org/ and screenshots: http://yypkg.forge.ocamlcore.org/screenshots/index.html Regards, Adrien Nader -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
