current mcview still considered buggy
Hi, i must admit that I have been overly confident with the quality of the rewritten internal viewer. I have found two bugs in the text wrap mode. The first occurs when moving up a line or moving down a line. If the length of the first line on the screen (excluding the newline character) is equal to the number of columns, the cursor is advanced to the end of line, not to the next line. The second is related to the coordinate cache, specifically the nroff calculation. When asked for the offset of a line/column pair, it does not return the first point in the file where the offset is reached, but the second one. I'm currently working on these bugs and hope they will be fixed today. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: current mcview still considered buggy
Morning Roland, On Tue, 2005-06-07 at 08:25, Roland Illig wrote: i must admit that I have been overly confident with the quality of the rewritten internal viewer. I have found two bugs in the text wrap mode. I'm currently working on these bugs and hope they will be fixed today. How about the bugs that you haven't spotted yet? The fact that you so frankly admit you've maken a mistake doesn't guarantee there won't be found other bugs in your new code. This is why I keep stressing that 4.6.1 should be released from the MC_4_6_1_PRE branch. I'll commit the X11 signal handling patch (SSH) to PRE in one or two days. Plus I'll add the match for '\t' to the prompt bugfix. So if you guys can make up your mind wrt the gcc-4 fixes we can roll forwards toward a release. O, and please commit that memory leak in mcedit/mcview(?) you told me about yesterday to PRE. TIA. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, On Mon, 6 Jun 2005, Leonard den Ottolander wrote: Hello Miguel, On Mon, 2005-06-06 at 22:58, Miguel de Icaza wrote: I have made a tarball of the current trunk release and fixing a few issues in make distcheck, the question that remains is: what version should we use? Please use MC_4_6_1_PRE for the release of 4.6.1. Then we can use HEAD for 4.6.2 and onwards. I second that. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, On Mon, 6 Jun 2005, Roland Illig wrote: We continue to use the 4.6.xx family name. I think it might be time to change one of those numbers to identify the changes done since the 4.6.0 release in a more significant way. I would prefer 4.7. (Just to leave the long past of 4.6.* pre-releases behind us. ;)) In fact the changes between 4.6.0 and 4.6.1 are not so significant in terms of functionality. I think of 4.6.1 as a bugfix release. Browsing through the NEWS files doesn't indicate the opposite. Having said that - I think we should stick to 4.6.1. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: current mcview still considered buggy
Hello, On Tue, 7 Jun 2005, Roland Illig wrote: i must admit that I have been overly confident with the quality of the rewritten internal viewer. I have found two bugs in the text wrap mode. You have always been overly confident with the quality of your code. Period. With your ideas and ways of doing things. Do I have to remind you that you even banned yourself from commiting in the not so distant past. I still wonder why you keep posting this kind of email... I can't see the point. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: current mcview still considered buggy
Pavel Tsekov wrote: I still wonder why you keep posting this kind of email... I can't see the point. The point is that until yesterday I thought the viewer contained really close to zero bugs. That's what I also told Miguel for considering which CVS branch to release. So now I revert that opinion. By the way, the two bugs have just been fixed. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: current mcview still considered buggy
Hello, On Tue, 7 Jun 2005, Roland Illig wrote: Pavel Tsekov wrote: I still wonder why you keep posting this kind of email... I can't see the point. The point is that until yesterday I thought the viewer contained really close to zero bugs. That's what I also told Miguel for considering which CVS branch to release. So now I revert that opinion. You should have stated your intentions more clear then. We are not some kind of psychics. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH]: exit_subshell(): Cleanup only if required.
Hello,
The patch fixes an issue with exit_subshell() cleaning up
internal variables even when it should not.
To reproduce:
1) Start MC with subshell support and bash as the subshell
2) Press `Ctrl + O'
3) Press `Tab'
4) Press `Ctrl + O'
5) Press `F10' and select `Yes'
6) MC will warn you that the subshell is active - select `No'
7) Press `Ctrl + O'
8) Type something in the subshell or just press `Ctrl + O'
Changelog:
2005-06-07 Pavel Tsekov [EMAIL PROTECTED]
* subshell.c (exit_subshell): Do not blindly perform cleanup.
P.S. Please, apply to both HEAD and 4.6.1.Index: src/subshell.c
===
RCS file: /cvsroot/mc/mc/src/subshell.c,v
retrieving revision 1.87
diff -u -p -r1.87 subshell.c
--- src/subshell.c 27 May 2005 03:35:15 - 1.87
+++ src/subshell.c 7 Jun 2005 08:19:32 -
@@ -650,16 +650,18 @@ exit_subshell (void)
_( The shell is still active. Quit anyway? ),
0, 2, _(Yes), _(No));
-if (quit subshell_type == TCSH) {
- if (unlink (tcsh_fifo) == -1)
- fprintf (stderr, Cannot remove named pipe %s: %s\r\n,
-tcsh_fifo, unix_error_string (errno));
-}
+if (quit) {
+ if (subshell_type == TCSH) {
+ if (unlink (tcsh_fifo) == -1)
+ fprintf (stderr, Cannot remove named pipe %s: %s\r\n,
+tcsh_fifo, unix_error_string (errno));
+ }
-g_free (subshell_prompt);
-g_free (pty_buffer);
-subshell_prompt = NULL;
-pty_buffer = NULL;
+ g_free (subshell_prompt);
+ g_free (pty_buffer);
+ subshell_prompt = NULL;
+ pty_buffer = NULL;
+}
return quit;
}
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project
Hello Terry! ... about offering to become the new Maintainer of the Midnight Commander Project. Well, Terry, I have some arguments against your offer, but after reading your letters here I just has to say I don't need such maintainer. It's better have no maintainer than such person. No, thanks! -- Regards, Andrew V. Samoilov GET INTERNET ACCESS FROM BCS! http://www.bcs.zp.ua Join BCS today! For your FREE webmail, visit: http://email.zp.ua/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH]: exit_subshell(): Cleanup only if required.
Hello Pavel, Tuesday, June 7, 2005, 2:30:48 PM, you wrote: PT Hello, PT The patch fixes an issue with exit_subshell() cleaning up PT internal variables even when it should not. PT To reproduce: PT 1) Start MC with subshell support and bash as the subshell PT 2) Press `Ctrl + O' PT 3) Press `Tab' PT 4) Press `Ctrl + O' PT 5) Press `F10' and select `Yes' PT 6) MC will warn you that the subshell is active - select `No' PT 7) Press `Ctrl + O' PT 8) Type something in the subshell or just press `Ctrl + O' PT Changelog: PT 2005-06-07 Pavel Tsekov [EMAIL PROTECTED] PT * subshell.c (exit_subshell): Do not blindly perform cleanup. PT P.S. Please, apply to both HEAD and 4.6.1. Commit. Thx a lot! -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, Please use MC_4_6_1_PRE for the release of 4.6.1. Then we can use HEAD for 4.6.2 and onwards. I second that. Sounds good. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, I have made a tarball of the current trunk release and fixing a few issues in make distcheck, the question that remains is: what version should we use? What did you fix? Make distcheck was broken, look at the dist-hook target, it would not build with VPATH/different prefixes. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Keybindings in mcedit
Hi, all! I've updated my keybindings patch to work with latest CVS. new stuff: label text command could be changed see cooledit.bindings for example -- Vitja Makarov mcedit-keys.tar.bz2 Description: BZip2 compressed data ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
hello, I have a tarball made from the branch: http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz I can rename this to 4.6.1 if people want. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, On Tue, 7 Jun 2005, Miguel de Icaza wrote: hello, I have a tarball made from the branch: http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz The right link is: http://primates.ximian.com/~miguel/mc/mc-4.6.1-pre5a.tar.gz ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re[2]: Release procedure
Hello Miguel, Tuesday, June 7, 2005, 5:10:03 PM, you wrote: MdI I have a tarball made from the branch: MdIhttp://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz MdI I can rename this to 4.6.1 if people want. Miguel, Why 4.6.1-pre5a, not pre4a? Please wait before renaming one day. -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
backport of X11 connection handling
I just backported the X11 connection handling from the HEAD branch to the MC_4_6_1_PRE branch. This fixes the so-called OpenSSH bug. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello Leonard, mc-devel,
On Mon, 2005-06-06 at 23:34 +0200, Leonard den Ottolander wrote:
Hello Miguel,
On Mon, 2005-06-06 at 22:58, Miguel de Icaza wrote:
I have made a tarball of the current trunk release and fixing a
few issues in make distcheck, the question that remains is: what version
should we use?
Please use MC_4_6_1_PRE for the release of 4.6.1. Then we can use HEAD
for 4.6.2 and onwards.
All we need for PRE is possibly the fixes that proski introduced for
gcc-4 warnings and some translations. That should suffice for 4.6.1. I
would say you can call that code very stable.
I can confirm that all the signedness gcc4 warnings are now gone in
the current CVS. The only warnings I found were not gcc4 related with
trivial fix, but it would be nice to see it fixed in the next mc
release.
I discussed this with Roland so maybe it's fixed now already. Attaching
the patch anyway.
Cheers,
Jindrich
--
Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/
The worst evil in the world is refusal to think.
--- mc-4.6.1a/src/widget.c.fixes 2005-06-06 15:08:52.202559824 +0200
+++ mc-4.6.1a/src/widget.c 2005-06-06 15:08:29.120068896 +0200
@@ -2363,7 +2363,7 @@ buttonbar_set_label_data (Dlg_head *h, i
void
buttonbar_set_label (Dlg_head *h, int idx, const char *text, void (*cback) (void))
{
-buttonbar_set_label_data (h, idx, text, cback, 0);
+buttonbar_set_label_data (h, idx, text, (buttonbarfn)cback, 0);
}
void
--- mc-4.6.1a/src/command.c.fixes 2005-05-27 05:35:15.0 +0200
+++ mc-4.6.1a/src/command.c 2005-06-06 15:07:38.228805544 +0200
@@ -280,7 +280,7 @@ command_callback (Widget *w, widget_msg_
/* fall through */
default:
- return input_callback (cmd, msg, parm);
+ return input_callback (w, msg, parm);
}
}
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Jindrich Novy wrote:
--- mc-4.6.1a/src/widget.c.fixes2005-06-06 15:08:52.202559824 +0200
+++ mc-4.6.1a/src/widget.c 2005-06-06 15:08:29.120068896 +0200
@@ -2363,7 +2363,7 @@ buttonbar_set_label_data (Dlg_head *h, i
void
buttonbar_set_label (Dlg_head *h, int idx, const char *text, void (*cback)
(void))
{
-buttonbar_set_label_data (h, idx, text, cback, 0);
+buttonbar_set_label_data (h, idx, text, (buttonbarfn)cback, 0);
I will fix this in a minute, but sadly the _correct_ fix is not as
trivial. Here we are converting completely unrelated function pointers,
which is quite dangerous in case the function prototypes change or in
case we use another compiler. The C standard states this as undefined
behavior.
--- mc-4.6.1a/src/command.c.fixes 2005-05-27 05:35:15.0 +0200
+++ mc-4.6.1a/src/command.c 2005-06-06 15:07:38.228805544 +0200
@@ -280,7 +280,7 @@ command_callback (Widget *w, widget_msg_
/* fall through */
default:
- return input_callback (cmd, msg, parm);
+ return input_callback (w, msg, parm);
Fixed. That was trivial.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Last TODO items before release [was Re: Release procedure]
On Tue, 2005-06-07 at 20:02, Leonard den Ottolander wrote: Before releasing 4.6.1 there are a few things to be done: - Backporting gcc-4 signedness fixes I understand many of the developers doubt the quality of the warnings from gcc-4, and hence the fixes proski created for them. We can look at them for the next release. - Add match for tab in promptfix patch (I'll do this) I'll commit this with 6 hours from now. Gotta go now ;) . Anything else? ? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
wget http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz --14:28:46-- http://primates.ximian.com/%7Emiguel/mc/tar.mc-4.6.1-pre5a.tar.gz = `tar.mc-4.6.1-pre5a.tar.gz' Resolving primates.ximian.com... 130.57.169.34 Connecting to primates.ximian.com[130.57.169.34]:80... connected. HTTP request sent, awaiting response... 404 Not Found 14:28:49 ERROR 404: Not Found. -- Regards, Scott --- [ Miguel de Icaza ] ===--- hello, I have a tarball made from the branch: http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz I can rename this to 4.6.1 if people want. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project
Hello! Sorry, I should have answered this long ago. On Sat, 2005-06-04 at 05:58 -0700, Fudoki wrote: Greetings All! My name is Terry Wilkinson and I am on the Docs Team and also am the Public Relations Coordinator for the Krusader File Manager Project (http://krusader.sourceforge.net/index.php). Our Team has been watching this list closely because most of us are regular MC users. I have also been talking to our leadership, and to Pavel Roskin, about offering to become the new Maintainer of the Midnight Commander Project, and Pavel has encouraged me to do so. This is not true. In fact, it tried to discourage you from attempts to take over the existing project. That's what I wrote you: Fresh start needs developers. If you have developers, you don't need to talk to me. Just start coding and show me your existing code if you want me in your team. From another message: By the way, I think the new project shouldn't be called Midnight Commander. Either you misunderstood me or you are misrepresenting my words. In either case, I don't think you should take over the existing project. If you want mc developers to join your project, show what you can offer them. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project?
Fudoki Wilkinson wrote: Roland must be Mr. Icaza's protege, just slinging abuse and saying no before the offer is even on the table; In my opinion the offer of taking over mc could not have been expressed more clearly. I had already been on the table when I said no. The latest statement from Pavel Roskin proves that my initial guess was right. but he had already been identified as a cry baby and had no future with the Krew; I don't care about that. I have looked at some of your source code and the bulletin board, which convinced me that the mc team is more suitable for me. mainly due to his private notes to our Marketing Manager blasting the MC Project and it's Maintainers. private notes? I only wrote mails to public mailing lists, mc-devel in particular. So this statement is clearly wrong. Making a change is one thing, betraying your own team and backbiting is another. But while I was backbiting, I maily adhered to the facts instead of insulting others directly. Roland and Mr. Icaza should work well together. Believe it or not, we do. :) Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project
From - Thu Jun 2 20:53:04 2005X-Account-Key: account1X-UIDL: [EMAIL PROTECTED]X-Mozilla-Status: 0013X-Mozilla-Status2: Return-Path: [EMAIL PROTECTED]Received: from ibm46aec.bellsouth.net ([64.105.159.118]) by imf12aec.mail.bellsouth.net with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Thu, 2 Jun 2005 19:07:32 -0400Received: from dv.roinet.com ([ 64.105.159.118]) by ibm46aec.bellsouth.net with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Thu, 2 Jun 2005 19:07:31 -0400Received: from dv.roinet.com (localhost.localdomain [ 127.0.0.1]) by dv.roinet.com (8.13.4/8.13.4) with ESMTP id j52N7VA5003842 for [EMAIL PROTECTED]; Thu, 2 Jun 2005 19:07:31 -0400 Received: (from [EMAIL PROTECTED]) by dv.roinet.com (8.13.4/8.13.4/Submit) id j52N7VmY003839 for [EMAIL PROTECTED]; Thu, 2 Jun 2005 19:07:31 -0400 X-Authentication-Warning: dv.roinet.com: proski set sender to [EMAIL PROTECTED] using -fSubject: Re: A new day for MC?From: Pavel Roskin [EMAIL PROTECTED]To: Fudoki [EMAIL PROTECTED]In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]Content-Type: text/plainContent-Transfer-Encoding: 7bit Date: Thu, 02 Jun 2005 19:07:31 -0400Message-Id: [EMAIL PROTECTED]Mime-Version: 1.0X-Mailer: Evolution 2.2.2 (2.2.2-7) Hi, Terry!On Thu, 2005-06-02 at 10:42 -0400, Fudoki wrote: Greetings Pavel! Thanks for the kind and prompt reply. Many of the technical issues you raise have been things we have discussed. As one would expect, you have some great ideas. I'm glad you have come to realize that great developers often have little patience for the trivia of Project Management. I have done both jobs, but *never* at the same time! ;) When I manage a project, I don't write code, beyond fixing an occasional typo, or commenting code. Rafi and Shie (our leaders, and Lead Developers at Zend, The PHP Company in their day jobs) were insistent that we wait until you gave your blessing before posting an open message on the MC Forums. As Maintainers themselves, they wanted everything we did to be 100% true to the Open Source way. Thanks for giving me the go ahead on this.You definitely have my go ahead. I have two concerns about how to proceed, and perhaps you can give me the benefit of your years of experience with the MC Project. They are: 1) The professional and family responsibilities you have being fully understood and appreciated, I want you to know that whatever happens your input and ideas are considered valuable. I understand the concerns you raise, and respect them, but want to be clear that just because you have had trouble dealing with the nuisance and time drain a Maintainer has thrown at him, that does not take away from your talent as a developer, in fact it just proves it. Programmers just don't deal with trivial nonsense very well - it's just a fact.Exactly. Thank you for your support.In fact, I stopped contributing much to the project after I was accusedin January 2003 that I ignore the discussion (which ended up as a flamewar), while I was actually doing my best to keep track of it whileon vacation in Russia.As soon as people expect me to participate in every flamewar nad have anopinion on everything, it just stops to be fun. I want you to know that I value your advice and ideas as a programmer, and time permitting, welcome these. My guess is that once freed of the misery of having to be a Maintainer, you might just have some really good ideas for new functionality, and if you do, I would like to know. OK?It's hard for me to promise, but I'll be glad to participate if I can. 2) You mentioned the developers from the old project who don't want to repeat old design flaws. Could you give me some insight, privately, on which developers in the current MC Project are forward thinking, innovative, and adaptable? (On the next item, I understand if you prefer to pass.) If there are developer(s) who are an overall impediment to the Project, it would be great to know this too. Sometimes programmers will become attached to old ways, or don't want to change because they don't want to give up being the expert. This is what I see between the lines here. If you could give me some guidance on who might be suffering from this problem it will help us greatly Those who are really annoying have a short attention span and leave oncethey see that they are ignored. Those are usually single-issuedevelopers with one patch they desperately want applied. I haven't seen them much in the last months, but they can resurface.As for helpers, they all are constrained by the fragility of theexisting code. They could act differently when working on the new code.Some are learning good manners now, but please judge them by their code and their ability to understand, not by their manners.I have a feeling that the best programmers will join
Re: New Maintainer for MC Project
Hello, Terry!Now I see you actually understand me better than many mc contributorsand better than I initially thought. Maybe I was too harsh in myinitial e-mail. There was a significant fallout in my inbox caused by the recent discussions, and I had to deal with it while being verypressed with work and family duties.I agree that the project needs a fresh start. I mean something likewhat Subversion is to CVS - a new codebase, new technology, new protocol, but similar interface for the end user. And most importantly,the developers from the old project who don't want to repeat old designflaws.Speaking of the design flaws, these are some key issues I'd like to see addressed:1) Unicode and wide chars everywhere. No more strlen().2) No more targeting obsolete platforms. Portability fixes are appliedonly if they are reasonably maintainable.3) Object oriented design from ground up. Using an object oriented language (e.g. C++) to enforce the design. This is highly debatable,but I don't think C would be good enough, with all my love to low-levelprogramming. Other languages are fine as long as they bind easily to libraries in C.4) Reduce the number of --with and --enable. One screen library (Isuggest ncurses), mandatory VFS (one could disable some methods but notthe whole VFS layer), dynamically load optional libraries. 5) Internal terminal and internal subshell from the beginning. Whinersare free to use the old mc. Maintaining 4 combinations ofshell/terminal capabilities (with/without subshell, with/without screensaving) should no longer be needed. I'm fine with sharing code with screen and bash.6) Reuse externally maintained libraries whenever possible. Immediateportability to ancient OSes should not be an issue. Quality of code and _potential_ portability should be considered instead. We need aportability layer (either glib2 or APR), a fullscreen graphic library(maybe ncurses forms) and a library for settings. 7) The viewer should be a special read-only mode of the editor. Itcould share a library with the file manager, but I would prefer it to bea separate project with a separate maintainer and maybe a separate mailing list.8) We need a modular configuration for file associations with amechanism to find the best application for the environment.I'm ready to post the above publicly, but right now I'd like to keep the communication channels open for 4.6.1 release.I have absolutely no problem with you writing to the mailing listdirectly.Unfortunately, I don't see myself the maintainer of the new project. Ihave realized over the years of work with free software that I'm much more effective as a contributor than as a maintainer.Once people start expecting me to deal with issues I'm not interested inor to write responses in timely manner, contributing to the projectstops being interesting for me. Once I even had to stop participating in a project after my activity in the mailing list caused a wave offree support requests over the private e-mail. At some point I waseven thinking of closing my e-mail addresses and assuming a new identity just to get rid of the expectations.I'm ready to help with my experience, but my experience with mc wasmostly fixing and reorganizing the code, not implementing newfunctionality. That's why I'm asking you to look for a better maintainer.By the way, I think the new project shouldn't be called MidnightCommander. Maybe something with Commander at the end and adistinctive two letter command name, e.g. Zivisus Commander - zc, where Zivisus is Zivisus Is VISUal Shell :-) -- Regards,Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project?
Fudoki Wilkinson wrote: On 6/7/05, Roland Illig [EMAIL PROTECTED] wrote: Fudoki Wilkinson wrote: mainly due to his private notes to our Marketing Manager blasting the MC Project and it's Maintainers. private notes? I only wrote mails to public mailing lists, mc-devel in particular. So this statement is clearly wrong. Shall I post those too.? Please do. I'm curious about what it is. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Last TODO items before release [was Re: Release procedure]
Leonard den Ottolander wrote: Roland fixed a memory leak in HEAD but he doesn't know where again g. I have thoroughly check the changes to mcedit, where I assumed the memory leak to have been. The only things I found were two instances where I had replaced use of the catstrs() function with explicit memory management. These places look highly suspicious, but are indeed ok and always have been. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
old bug in achown.c
This bug is perhaps the oldest one I could find. Well, to be honest, it wasn't me but the SunPro compiler: /tmp/mc-current-build/src/src/achown.c, line 517: warning: enum type mismatch: arg #2 It's not only gcc's job to emit warnings ... ;) Roland Index: achown.c === RCS file: /cvsroot/mc/mc/src/achown.c,v retrieving revision 1.47 diff -u -p -r1.47 achown.c --- achown.c27 May 2005 03:35:14 - 1.47 +++ achown.c8 Jun 2005 00:42:55 - @@ -514,7 +514,7 @@ advanced_chown_callback (Dlg_head *h, dl break; ch_flags[flag_pos] = parm; update_mode (h); - advanced_chown_callback (h, KEY_RIGHT, DLG_KEY); + advanced_chown_callback (h, DLG_KEY, KEY_RIGHT); if (flag_pos 8 || !(flag_pos % 3)) dlg_one_down (h); ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Fwd: New Maintainer for MC Project
Part 1 of 2-- Forwarded message --From: Fudoki Wilkinson [EMAIL PROTECTED] Date: Jun 7, 2005 9:50 PMSubject: Re: New Maintainer for MC ProjectTo: MC Devel List mc-devel@gnome.org, [EMAIL PROTECTED] Pavel, Below is your note posted today. Below that the full text of the letter, and response, to which you refer, with key sections highlighted and numbered. Programmers can read - I'll let them draw their own conclusions. A conversation is proposed regarding the project, the Midnight Commander project. The project your quoted comment was discussing. I clearly state that the Krew does not agree with some of the remarks on the Lists and elswhere that Midnight Commander be scrapped, and an entirely new program be written. The we feel Midnight Commander is just fine and can have a bright future with the right leadership. Again, the offer is reiterated, with the sole goal of keeping the MC Project viable. This is the only thing we ever proposed. My note of June 4, 2005, posted in full on this list, reiterated yet again this fact, and asked specifically if you understood that we were not interested in writing a new application, or a branch of the existing MC, but were offering help to the existing MC Team to continue to work on their project in a pleasant and stable environment. Why you now try and say we were, in essence, trying to scavange MC Developers away from the existing project to create a new one I cannot know - but the message traffic shows this in just not so. In my next note, I underscored this fact (note already posted in full below) saying: Regarding a fresh start, if it was our desire to compete with MC, we would have already released our product - this is not our wish. Our wish is to try and save a distressed project that we all regard highly and support. We are MC users, too. From what I see in your forums, you don't need new developers, your developers just need to see their work used by MC users. New developers are not the answer, new leadership is the answer. My note of June 1st also emphasizes that point, full message below. In the sentence marked 1), you acknowledge that you understand that we are talking about giving the current MC Project a home, and no other. No new project, No fork, THE MC Project. That was the offer from the start, and nothing else. Please stop mis-characterizing what I communicated in my messages. The notes speak for themselves. Terry Subject: Re: Awaiting your replyFrom: Pavel Roskin [EMAIL PROTECTED]To: Fudoki [EMAIL PROTECTED]In-Reply-To: [EMAIL PROTECTED]References: [EMAIL PROTECTED] Content-Type: text/plainContent-Transfer-Encoding: 7bitDate: Wed, 01 Jun 2005 20:38:34 -0400Message-Id: [EMAIL PROTECTED]Mime-Version: 1.0X-Mailer: Evolution 2.2.2 (2.2.2-5 ) Hello, Terry!On Wed, 2005-06-01 at 13:52 -0400, Fudoki wrote: Pavel, The leaders of the Krusader Krew have decided that we should wait a few days before directly posting our offer on the Midnight Commander Forums to give you an opportunity to respond to my last letter. I see the wisdom of this, and will not be posting to the MC Forums until you have had time to get back to us with your position on the MC Team becoming a part of the Krusader Project.1) *Sorry, I didn't realize that the question was about MC Team becoming apart of the Krusader Project. I cannot answer on behalf of anyone except myself. I may join if I have time, but I'm not very optimistic.*If you are going to create a mailing list, please feel free to subscribeme. I'll unsubscribe if I have to. Our leadership wants to be certain that your feelings on this matter receive the consideration they deserve. Please let me know when you get a chance. Thanks!My feeling is that it would be nice to have a file manager with a maintainable codebase. I don't think anyone would object (maybe exceptcompeting projects).-- Regards,Pavel Roskin From: Pavel Roskin proski gnu orgTo: Fudoki sekhmet_616 yahoo comCc: mc-devel gnome orgSubject: Re: New Maintainer for MC Project Date: Tue, 07 Jun 2005 17:57:53 -0400 Hello!Sorry, I should have answered this long ago.On Sat, 2005-06-04 at 05:58 -0700, Fudoki wrote: Greetings All! My name is Terry Wilkinson and I am on the Docs Team and also am the Public Relations Coordinator for the Krusader File Manager Project ( http://krusader.sourceforge.net/index.php). Our Team has been watching this list closely because most of us are regular MC users. I have also been talking to our leadership, and to Pavel Roskin, about offering to become the new Maintainer of the Midnight Commander Project, and Pavel has encouraged me to do so.This is not true. In fact, it tried to discourage you from attempts totake over the existing project. That's what I wrote you:Fresh start needs developers. If you have developers, you don't needto talk to me. Just start coding and show me your existing code if youwant me in your team. From another message:By
Re: old bug in achown.c
On Wed, Jun 08, 2005 at 02:45:32AM +0200, Roland Illig wrote: - advanced_chown_callback (h, KEY_RIGHT, DLG_KEY); + advanced_chown_callback (h, DLG_KEY, KEY_RIGHT); heh, wow ... another a good example of why #define is bad and enum is good - provided you have a sufficiently strict compiler. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
