From: rustyBSD <rus...@gm...> - 2012-09-28 15:41:48
Attachments:
e_fm_op.c.diff
|
Le 28/09/2012 12:39, Carsten Haitzler (The Rasterman) a écrit : > you're waiting for vincent to commit patches? what patches? where? by who? > doing what? you planned to do something ... but never mention you did it. > planning and doing are very different things. you didn't say that the patches > you sent fix this. sorry but your mails are incredibly far from being clear on > the topic. your first reply to me definitely is not. and then its "revert > changes" which of course i refused as it'd make the code worse. > > could you please actually be clear before resorting to swearing and asking for > reverts? You're not doing (overwrite_count) passes, but (overwrite_count*NB_PASS). You cannot cancel operation and see progression. Here is a patch. $ svn update -r77020 e_fm_op.c And then patch. So we are doing the same thing (I mean, in a loop), but correctly. (and ...random_buf() never returns -1, so -> void). Discomfitor asked me to improve e_fm_op.c, and I started by adding this little feature. It's just that it make me angry when I'm in charge of something which is modified by others without asking anything. Then I loose my time to write mails, as if I had only that to do. |
From: Carsten H. (T. R. <ra...@ra...> - 2012-09-29 02:24:18
|
On Fri, 28 Sep 2012 17:41:37 +0200 rustyBSD <rus...@gm...> said: > Le 28/09/2012 12:39, Carsten Haitzler (The Rasterman) a écrit : > > you're waiting for vincent to commit patches? what patches? where? by who? > > doing what? you planned to do something ... but never mention you did it. > > planning and doing are very different things. you didn't say that the > > patches you sent fix this. sorry but your mails are incredibly far from > > being clear on the topic. your first reply to me definitely is not. and > > then its "revert changes" which of course i refused as it'd make the code > > worse. > > > > could you please actually be clear before resorting to swearing and asking > > for reverts? > > You're not doing (overwrite_count) passes, > but (overwrite_count*NB_PASS). You cannot > cancel operation and see progression. > > Here is a patch. > > $ svn update -r77020 e_fm_op.c > And then patch. > > So we are doing the same thing (I mean, in > a loop), but correctly. (and ...random_buf() > never returns -1, so -> void). yes. in fact i was wondering why this func could/should fail. you could always just use rand() anyway and it will never fail. :) > Discomfitor asked me to improve e_fm_op.c, > and I started by adding this little feature. > > It's just that it make me angry when I'm in > charge of something which is modified by others > without asking anything. Then I loose my time to > write mails, as if I had only that to do. here's a ground rule. no one is officially "in charge" in that they are the only one who can o should commit to something. it is a general guideline that you don't stomp around on code you don't know or understand, but anyone is free to fix or improve anything they want. there are no monopolies. if you do things in private (be it a private git repo + branchs you keep privately or patches you kep pricate) then those will get stomped on as no one knows what you are doing. send your patches to the list in public and... we then all know! if you had sent the patch with your reply i would not have changed the code - i likely may have committed it. :) in fact tht is just what i did. :) your patch is now in. thanks! just keep in mind. 1. be clear. 2. if you want others to know what you are doing - share it with them. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Lucas De M. <luc...@pr...> - 2012-09-28 17:21:57
|
On Fri, Sep 28, 2012 at 12:41 PM, rustyBSD <rus...@gm...> wrote: > Le 28/09/2012 12:39, Carsten Haitzler (The Rasterman) a écrit : >> you're waiting for vincent to commit patches? what patches? where? by who? >> doing what? you planned to do something ... but never mention you did it. >> planning and doing are very different things. you didn't say that the patches >> you sent fix this. sorry but your mails are incredibly far from being clear on >> the topic. your first reply to me definitely is not. and then its "revert >> changes" which of course i refused as it'd make the code worse. >> >> could you please actually be clear before resorting to swearing and asking for >> reverts? > > You're not doing (overwrite_count) passes, > but (overwrite_count*NB_PASS). You cannot > cancel operation and see progression. > > Here is a patch. > > $ svn update -r77020 e_fm_op.c > And then patch. > > So we are doing the same thing (I mean, in > a loop), but correctly. (and ...random_buf() > never returns -1, so -> void). > > Discomfitor asked me to improve e_fm_op.c, > and I started by adding this little feature. > > It's just that it make me angry when I'm in > charge of something which is modified by others You should improve you tooling then. There's no need for a revert here. Code now is better than it was before. If yours is indeed better yet (didn't look your patch), just re-diff it and *send* as an improvement. You didn't submit it before and raster committed a much more sane code. There's no such "lock" waiting for people to do their planning and submit their patches. > without asking anything. Then I loose my time to > write mails, as if I had only that to do. And you wasted the time of at least 4 other developers responding to your email insulting people. Lucas De Marchi |
From: rustyBSD <rus...@gm...> - 2012-09-28 18:53:34
Attachments:
e_fm_op.c.diff2
|
Le 28/09/2012 19:21, Lucas De Marchi a écrit : > There's no need for a revert here. Code now is better than it was > before. If yours is indeed better yet (didn't look your patch), just > re-diff it and *send* as an improvement. You didn't submit it before > and raster committed a much more sane code. . |
From: Vincent T. <vt...@un...> - 2010-04-18 06:51:26
|
On Sun, 18 Apr 2010, han...@gm... wrote: > On Sun, Apr 18, 2010 at 7:29 AM, Enlightenment SVN > <no-...@en...> wrote: >> Log: >> Replace the description "Everything" by "All" as there >> is a conflict with the Everything module wrt translations. >> > 'Everything' shouldnt be translated, just like 'enlightenment' so > there is no conflict, or was there any? do a grep in src/modules/everything on "Everything". It is translaterd sometimes. Vincent > >> Author: caro >> Date: 2010-04-17 23:29:31 -0700 (Sat, 17 Apr 2010) >> New Revision: 48098 >> >> Modified: >> trunk/e/src/bin/e_int_border_remember.c >> >> Modified: trunk/e/src/bin/e_int_border_remember.c >> =================================================================== >> --- trunk/e/src/bin/e_int_border_remember.c 2010-04-18 06:26:50 UTC (rev 48097) >> +++ trunk/e/src/bin/e_int_border_remember.c 2010-04-18 06:29:31 UTC (rev 48098) >> @@ -619,7 +619,7 @@ >> e_widget_list_object_append(o, ob, 1, 1, 0.5); >> ob = e_widget_radio_add(evas, _("Size, Position and Locks"), MODE_GEOMETRY_LOCKS, rg); >> e_widget_list_object_append(o, ob, 1, 1, 0.5); >> - ob = e_widget_radio_add(evas, _("Everything"), MODE_ALL, rg); >> + ob = e_widget_radio_add(evas, _("All"), MODE_ALL, rg); >> e_widget_list_object_append(o, ob, 1, 1, 0.5); >> return o; >> } >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> enlightenment-svn mailing list >> enl...@li... >> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > |