Re: [E-devel] E CVS: libs/etk barbieri (about recent Etk changes)
On 10/16/07, Simon TRENY [EMAIL PROTECTED] wrote: 2nd - Don't forget to CC me when you add a patch to bugzilla (there has been a couple of patches that I missed because I wasn't CCed on these) Just guessing here, but it may be possible to add your email automatically in every bug report with 'Etk' selected as product (CodeWarrior is automatically assigned to Etk bugs if I recall correctly). Anyone maintaining the bugzilla, is this possible? Cheers, Caio Marcelo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri (about recent Etk changes)
On 10/16/07, Simon TRENY [EMAIL PROTECTED] wrote: On Sat, 13 Oct 2007 15:27:06 -0300, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote : On 10/13/07, Simon TRENY [EMAIL PROTECTED] wrote: On Wed, 26 Sep 2007 00:58:05 -0400 (EDT), Enlightenment CVS [EMAIL PROTECTED] wrote : Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/lib Log Message: Structures fields reorder to avoid holes and save memory. Have all Etk_Bool inside structures to be a bitfield, reorder fields to provide better packing. Packaging was aided by pahole 1.0 on x86 (http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git) Tested with etk_test and edje_viewer, both still work. PS: bugs may appear due Etk_Bool size change, values like 2 (10b) will now be evaluated as false. That was already a bug, just being exposed now, the fix is easy: use !! (double negative) before the value, example: visible = obj_ptr; becomes visible = !!obj_ptr;. Can I ask you how many bytes per widget do you gain with such a change? I don't really expect it to be more than 300b per widget. Since in an Etk app, you'll most probably never have more than 300 widgets, you'll gain 100kb max, and I'm being **VERY** generous here! :) And I don't think 100kb is really important nowadays, even on embedded devices (whose apps will never have 300 widgets anyway...). So, if you don't mind, I'm going to revert this change, as it introduces code changes that I personally find really ugly (such as visible = !!obj_ptr;...) And, it would have been great if this change had been discussed on the dev ML before being committed. I know I haven't been really active these last weeks, I've been quite busy with school and other projects, but I'd still like to have the opportunity to give my opinion before such a change happens. More generally, there has been a lot of important changes recently in Etk internals, some of them are great, but there also have been changes that I really don't like. I would have appreciated if you (i.e. developers who made these changes) had discussed them publicly and *waited* for my response before committing them. Ok, I feel a bit guilt here since I did most of the changes you disliked, sorry about that, but they all have a good reason. Avoiding holes in structs is not just about saving space, is fitting things better into cache lines, is using memory better and believe me or not, it makes difference. Ok, I can't test so I trust you on that. Using unsigned int bool : 1 for booleans is not a bad idea, I just don't like some of the consequences it has brought (especially the !! thing) Also, forcing boolean fields to be 1 or 0 (ETK_TRUE or ETK_FALSE) makes sense or we still have bugs depending on how software is developed. Today it fails if you use 2 (10b) as true, but it would also fail if you compared with ETK_TRUE, so that _IS_ a bug. If you dislike !!var, then use something else, but make sure it's 1 (ETK_TRUE) or 0 (ETK_FALSE) if you tagged them as Etk_Bool. Yes, you made a good point here. Maybe we could then just have a macro called TO_BOOL() that does the integer-to-boolean cast. So there will be no !! in the code anymore. This specific change was not discussed in open, but others, like Etk_Signal, were and at least CodeWarrior said: go for it. Before we were keeping those changes in GIT branches at http://staff.get-e.org and CodeWarrior wisely requested us to keep these changes in CVS to avoid fragmentation. We (INdT) choose ETK over EWL because it was easier to get our requests done and accepted, but we said (at least to CodeWarrior) that we wanted some things changed. We really want to cooperate and build a better platform together, but if you don't want these things in, we'd have to keep a separate branch/fork with changes you still haven't accepted... this will be painful for everybody. :-( So, when will you be back online? and which development approach would you like (separate code bases or development in CVS)? Yes, having several branches is not a good idea imho. Especially since you (devs at INdT and other Etk devs) did an amazing work recently and since I think we share the same common goals in Etk, and it would be a shame to spread our efforts. In order to avoid having this kind of situation again, I think we could set 2 rules that should be applied for *important* changes: 1st - Always discuss major changes publicly (i.e. on the Dev ML, not only on IRC). If I don't give my opinion 7 days after the beginning of the conversation, you can commit the changes, it would be entirely my fault if I'm not happy with them :) I know I didn't participate to the Etk_Signal dicussion thread, so you were right to commit it. And actually, I even
Re: [E-devel] E CVS: libs/etk barbieri (about recent Etk changes)
On Wed, 26 Sep 2007 00:58:05 -0400 (EDT), Enlightenment CVS [EMAIL PROTECTED] wrote : Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/lib Log Message: Structures fields reorder to avoid holes and save memory. Have all Etk_Bool inside structures to be a bitfield, reorder fields to provide better packing. Packaging was aided by pahole 1.0 on x86 (http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git) Tested with etk_test and edje_viewer, both still work. PS: bugs may appear due Etk_Bool size change, values like 2 (10b) will now be evaluated as false. That was already a bug, just being exposed now, the fix is easy: use !! (double negative) before the value, example: visible = obj_ptr; becomes visible = !!obj_ptr;. Can I ask you how many bytes per widget do you gain with such a change? I don't really expect it to be more than 300b per widget. Since in an Etk app, you'll most probably never have more than 300 widgets, you'll gain 100kb max, and I'm being **VERY** generous here! :) And I don't think 100kb is really important nowadays, even on embedded devices (whose apps will never have 300 widgets anyway...). So, if you don't mind, I'm going to revert this change, as it introduces code changes that I personally find really ugly (such as visible = !!obj_ptr;...) And, it would have been great if this change had been discussed on the dev ML before being committed. I know I haven't been really active these last weeks, I've been quite busy with school and other projects, but I'd still like to have the opportunity to give my opinion before such a change happens. More generally, there has been a lot of important changes recently in Etk internals, some of them are great, but there also have been changes that I really don't like. I would have appreciated if you (i.e. developers who made these changes) had discussed them publicly and *waited* for my response before committing them. Regards, Simon TRENY MoOm - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri (about recent Etk changes)
On Sat, 13 Oct 2007, Simon TRENY wrote: PS: bugs may appear due Etk_Bool size change, values like 2 (10b) will now be evaluated as false. That was already a bug, just being exposed now, the fix is easy: use !! (double negative) before the value, example: visible = obj_ptr; becomes visible = !!obj_ptr;. Can I ask you how many bytes per widget do you gain with such a change? I don't really expect it to be more than 300b per widget. Since in an Etk app, you'll most probably never have more than 300 widgets, you'll gain 100kb max, and I'm being **VERY** generous here! :) And I don't think 100kb is really important nowadays, even on embedded devices (whose apps will never have 300 widgets anyway...). So, if you don't mind, I'm going to revert this change, as it introduces code changes that I personally find really ugly (such as visible = !!obj_ptr;...) And, it would have been great if this change had been discussed on the dev ML before being committed. I know I haven't been really active these last weeks, I've been quite busy with school and other projects, but I'd still like to have the opportunity to give my opinion before such a change happens. More generally, there has been a lot of important changes recently in Etk internals, some of them are great, but there also have been changes that I really don't like. I would have appreciated if you (i.e. developers who made these changes) had discussed them publicly and *waited* for my response before committing them. And bugzilla is a good tool to put patches so that we can discuss them. Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri (about recent Etk changes)
On 10/13/07, Simon TRENY [EMAIL PROTECTED] wrote: On Wed, 26 Sep 2007 00:58:05 -0400 (EDT), Enlightenment CVS [EMAIL PROTECTED] wrote : Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/lib Log Message: Structures fields reorder to avoid holes and save memory. Have all Etk_Bool inside structures to be a bitfield, reorder fields to provide better packing. Packaging was aided by pahole 1.0 on x86 (http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git) Tested with etk_test and edje_viewer, both still work. PS: bugs may appear due Etk_Bool size change, values like 2 (10b) will now be evaluated as false. That was already a bug, just being exposed now, the fix is easy: use !! (double negative) before the value, example: visible = obj_ptr; becomes visible = !!obj_ptr;. Can I ask you how many bytes per widget do you gain with such a change? I don't really expect it to be more than 300b per widget. Since in an Etk app, you'll most probably never have more than 300 widgets, you'll gain 100kb max, and I'm being **VERY** generous here! :) And I don't think 100kb is really important nowadays, even on embedded devices (whose apps will never have 300 widgets anyway...). So, if you don't mind, I'm going to revert this change, as it introduces code changes that I personally find really ugly (such as visible = !!obj_ptr;...) And, it would have been great if this change had been discussed on the dev ML before being committed. I know I haven't been really active these last weeks, I've been quite busy with school and other projects, but I'd still like to have the opportunity to give my opinion before such a change happens. More generally, there has been a lot of important changes recently in Etk internals, some of them are great, but there also have been changes that I really don't like. I would have appreciated if you (i.e. developers who made these changes) had discussed them publicly and *waited* for my response before committing them. Ok, I feel a bit guilt here since I did most of the changes you disliked, sorry about that, but they all have a good reason. Avoiding holes in structs is not just about saving space, is fitting things better into cache lines, is using memory better and believe me or not, it makes difference. Also, forcing boolean fields to be 1 or 0 (ETK_TRUE or ETK_FALSE) makes sense or we still have bugs depending on how software is developed. Today it fails if you use 2 (10b) as true, but it would also fail if you compared with ETK_TRUE, so that _IS_ a bug. If you dislike !!var, then use something else, but make sure it's 1 (ETK_TRUE) or 0 (ETK_FALSE) if you tagged them as Etk_Bool. This specific change was not discussed in open, but others, like Etk_Signal, were and at least CodeWarrior said: go for it. Before we were keeping those changes in GIT branches at http://staff.get-e.org and CodeWarrior wisely requested us to keep these changes in CVS to avoid fragmentation. We (INdT) choose ETK over EWL because it was easier to get our requests done and accepted, but we said (at least to CodeWarrior) that we wanted some things changed. We really want to cooperate and build a better platform together, but if you don't want these things in, we'd have to keep a separate branch/fork with changes you still haven't accepted... this will be painful for everybody. :-( So, when will you be back online? and which development approach would you like (separate code bases or development in CVS)? -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri (about recent Etk changes)
On 10/13/07, Simon TRENY [EMAIL PROTECTED] wrote: And, it would have been great if this change had been discussed on the dev ML before being committed. I know I haven't been really active these last weeks, I've been quite busy with school and other projects, but I'd still like to have the opportunity to give my opinion before such a change happens. More generally, there has been a lot of important changes recently in Etk internals, some of them are great, but there also have been changes that I really don't like. I would have appreciated if you (i.e. developers who made these changes) had discussed them publicly and *waited* for my response before committing them. I agree that changes need to be discussed if they are considered to be major changes or ones that affect the core of Etk. My response will be continued after Gustavo's reply as it also responds to his email. On 10/13/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: This specific change was not discussed in open, but others, like Etk_Signal, were and at least CodeWarrior said: go for it. Before we were keeping those changes in GIT branches at http://staff.get-e.org and CodeWarrior wisely requested us to keep these changes in CVS to avoid fragmentation. I can see where Simon is coming from regarding major changes being submitted to Etk without him getting the chance to be a part of the discussion. I can also see where Gustavo is coming from regarding discussing these changes both online and on the mailing list. I personally believe that all major changes should be discussed and reviewed by those who work on Etk. We have to keep a few points in mind though when deciding how to do things, and when it is OK to submit a so called major change to CVS. 1) Simon, although you want to be part of the discussion and review process prior to the inclusion of major patches to Etk, remember that you have not been online very often lately. I am not saying that developers wishing to submit major changes to Etk should not wait for you at all, they should, but they can not wait too long. Since the INdT is using Etk for something more than just a fun hobby application like most of the other code using Etk, they can not spend a lot of time waiting for their code to be reviewed and discussed. This does not mean that they have to check their code into CVS the next day after sending a public announcement to the list about it. This does mean however that they can not wait 2 or 3 weeks every time they have a patch pending review. They can keep their own tree only for so long, at which point they should merge it into CVS to avoid all sorts of conflicts and incompatibilities that might arise. So to summarize this point (which was brought on earlier when we were discussing the whole EFL delays that occur with raster's patch reviews due to his tremendous email backlog), a fair period should be given after a patch is submitted to the ML or Bugzilla. What is this period? A week? 2 Weeks? We should agree on that as one of the outcomes of this discussion. We (INdT) choose ETK over EWL because it was easier to get our requests done and accepted, but we said (at least to CodeWarrior) that we wanted some things changed. We really want to cooperate and build a better platform together, but if you don't want these things in, we'd have to keep a separate branch/fork with changes you still haven't accepted... this will be painful for everybody. :-( 2) Maintaining a fork or completely separate development branch should not be something we even consider. Again, patches need not be submitted to Etk directly, nor should they have to wait a month before going into CVS. Remember that CVS does not mean stable, nor does it mean release. So if something does make it in there that is later determined to be a bad idea then we can always roll it back. That's one of the major advantages of version control. So, when will you be back online? and which development approach would you like (separate code bases or development in CVS)? Although this question is directed to Simon, my opinion on this would be that we should continue to work on our current CVS, but we should set some rules as to how major changes are added. It should not be difficult to abide by the rules we set. If for some reason something has to go into CVS and is deemed a rush commit because it added something needed right now or fixes something (but is not entirely the best approach) we can always choose to fix it later, or revert it and find a better approach to do it. Etk is Simon's baby so to speak, so I can see and understand his point of view regarding having a say in what happens. Etk is also being used by a team that is developing industry grade heavy duty software, which means they will want certain changes and additions made, and they can not wait for a long time for their code to be part of Etk. Finding a middle ground on which we all agree according to a small set of fair
Re: [E-devel] E CVS: libs/etk barbieri (about recent Etk changes)
Hello Simon, :-) On 10/13/07, Simon TRENY [EMAIL PROTECTED] wrote: More generally, there has been a lot of important changes recently in Etk internals, some of them are great, but there also have been changes that I really don't like. I would have appreciated if you (i.e. developers who made these changes) had discussed them publicly and *waited* for my response before committing them. I did a bunch of big internal changes to Etk these last weeks. I've tried as much as I could to hold them before comitting, since I knew they could benefit from other devels opinions. Even maintaned for a little while a branch in GIT to track my changes without changing CVS, so people could review. Most changes have been proposed in the ML: the thread 'Etk signals improvements' from Sep 13 (and then bug #215, about identificators returned by signal connections and related), the thread 'Removing etk_signal_stop' from Sep 19 (which was a public continuation of a previous email between some devels). In this second thread I've proposed removing Etk_Accumulator later, because even the existent implementation had problems (which I pointed out in the thread). Obviously I'm open to discuss the changes, and of course even revert them if we concluded it's a bad thing (version control exists for that). My major changes were (if I forgot one that you dislike, please point out): - Make connect return identificators, that can be used for disconnection/block. - Make disconnect/block/unblock take the data pointer, so instead of removing ALL the connections of a certain callback function it removes only the one with the data associated. - Remove etk_signal_stop(), replaced by using the return value of the callback. - Related change: remove accumulators to accomplish the previous change. Accumulators were being used only to simulate a behaviour like the previous change proposed, and it usage in most cases can be replaced by passing more arguments to the marshaller. Other thing to notice: accumulator implementation was wrong in the sense that it assumed that callbacks always returned Etk_Bools - Related change: make all callbacks return Etk_Bool. To provide means for stopping signals. - This pack of changes simplified the implementation a lot, and I don't think we lost much. - Change internally how we hold the callbacks. Instead of a list, have an array of lists. I sent an email about this change. - Related to the change before, start to use internally numeric codes instead of strings for signal emission. So emitting any signal is just looking up in the array and calling all callbacks in the list, insted of looking in a Hash, filtering the callbacks from the big list. - A few changes in how we create types. New ways of creating types/signals that make code cleaner. Please, when you have time, try to comment on these changes. As Gustavo said, we want build this *together*, and avoid fork in Etk. PS: if you sense any rudeness I'm my mail, please ignore, I don't know English very well, so may choice of words may be wrong sometimes :-) Cheers, Caio Marcelo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri
On 9/30/07, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/lib Modified Files: etk_signal.c etk_signal.h etk_type.c etk_type.h etk_types.h Log Message: Refinements to new ETK signal system. [...snip...] * etk_signal_lookup() and etk_signal_lookup_code() are now internal (static). Why did this happen? now, unless I set them up all manually, if I have a signal's string name or code I have no way of knowing which marshaller to use for it... what's the proposed way for that? -- Chady 'Leviathan' Kassouf http://chady.net/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri
On 9/30/07, Chady Kassouf [EMAIL PROTECTED] wrote: On 9/30/07, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/lib Modified Files: etk_signal.c etk_signal.h etk_type.c etk_type.h etk_types.h Log Message: Refinements to new ETK signal system. [...snip...] * etk_signal_lookup() and etk_signal_lookup_code() are now internal (static). Why did this happen? now, unless I set them up all manually, if I have a signal's string name or code I have no way of knowing which marshaller to use for it... what's the proposed way for that? etk_type_signal_get() etk_type_signal_get_by_name() I really think exposing these through etk_type makes more sense... I hope in the end most calls of etk_signal except by members getters and setters will be made private. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri
On 9/30/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On 9/30/07, Chady Kassouf [EMAIL PROTECTED] wrote: On 9/30/07, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/lib Modified Files: etk_signal.c etk_signal.h etk_type.c etk_type.h etk_types.h Log Message: Refinements to new ETK signal system. [...snip...] * etk_signal_lookup() and etk_signal_lookup_code() are now internal (static). Why did this happen? now, unless I set them up all manually, if I have a signal's string name or code I have no way of knowing which marshaller to use for it... what's the proposed way for that? etk_type_signal_get() etk_type_signal_get_by_name() I really think exposing these through etk_type makes more sense... I hope in the end most calls of etk_signal except by members getters and setters will be made private. Last but not least, Caio will restart his work on python-etk on Monday, so maybe he'll notice some things are incomplete and then he'll fix. If you miss some bit, some feature that could help etk-perl, then say now so we can implement as soon as possible. So far what we really miss is the reverse lookup of basic structs, like to know if a pointer is an Etk_Object, Etk_Position, Etk_Size, ... for these we hope to have Etk_Base_Type (parent of Etk_Type) and Etk_Base (parent of Etk_Object and these basic structs). -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri
Enlightenment CVS schrieb: Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/bin Modified Files: etk_combobox_test.c etk_tree_test.c Log Message: Fix compiler warnings === RCS file: /cvs/e/e17/libs/etk/src/bin/etk_combobox_test.c,v retrieving revision 1.16 retrieving revision 1.17 diff -u -3 -r1.16 -r1.17 --- etk_combobox_test.c 29 Jun 2007 09:14:01 - 1.16 +++ etk_combobox_test.c 24 Jul 2007 21:40:16 - 1.17 @@ -1,3 +1,4 @@ +#define _GNU_SOURCE #include etk_test.h #include stdlib.h #include unistd.h @@ -202,7 +203,7 @@ cur_dir = strdup(dir_stripped); files = ecore_file_ls(dir_stripped); - ecore_list_sort(files, strcasecmp, 'a'); + ecore_list_sort(files, (Ecore_Compare_Cb)strcasecmp, 'a'); I'm not sure what your intention is behind the 'a', but the third argument of ecore_list_sort() should be ECORE_SORT_MIN or ECORE_SORT_MAX. I updated the doxy to be more precise about the possible values. Besides that, the return list of ecore_file_ls() should already be sorted. Peter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri
On 7/25/07, Peter Wehrfritz [EMAIL PROTECTED] wrote: I'm not sure what your intention is behind the 'a', but the third argument of ecore_list_sort() should be ECORE_SORT_MIN or ECORE_SORT_MAX. I updated the doxy to be more precise about the possible values. Besides that, the return list of ecore_file_ls() should already be sorted. Fixed, thanks. ecore_file_ls seems to use strcol l() which is case sensitive. -- Hisham Mardam Bey http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/etk barbieri
Hisham Mardam Bey schrieb: On 7/25/07, Peter Wehrfritz [EMAIL PROTECTED] wrote: I'm not sure what your intention is behind the 'a', but the third argument of ecore_list_sort() should be ECORE_SORT_MIN or ECORE_SORT_MAX. I updated the doxy to be more precise about the possible values. Besides that, the return list of ecore_file_ls() should already be sorted. Fixed, thanks. ecore_file_ls seems to use strcol l() which is case sensitive. strcoll is in general case insensitive , only if you haven't set the user's locale (via setlocale(LC_COLLATE, ); or setlocale(LC_ALL, );) and hence the locale is set to C, it will fallback, for whatever reasons, to use strcmp. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
