Re: GCC-4.0 warnings
Pavel Roskin wrote: While the code is correct, it's not obvious for gcc. The knee-jerk reaction could be to initialize val in caller(), but sometimes it may be better to fix callee(), especially if it's used many times. Even more so if it's not documented that the pointer won't be initialized if callee() returns a failure code. Hmm, my opinion is that a function should not change any of their output parameters on failure, but I see the problem for the compiler. Probably I will initialize the output parameters even on failure. I have fixed all warnings in HEAD except one introduced by you. I guess you can fix it better (I tried and it's not trivial, so you may want to reverse some of your changes instead): help.c: In function 'help_handle_key': help.c:627: warning: passing argument 3 of 'check_movement_keys' discards qualifiers from pointer target type I have fixed this. The code had been really ugly. It was not necessary to pass currentpoint to the check_movement_function(), as it is a global variable. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hello mc-devel, Miguel, On Sun, 2005-05-22 at 17:46 -0400, Miguel de Icaza wrote: Hello, Thanks for raising this issue up, I think that we should proceed in various stages to address some of the problems that we have today in mc: * The website should move to a Wiki. I will have our sysadmins setup a Wiki for MC based on the success we have had with Hula, Mono and Beagle. The use of the Wiki means that users can effectively contribute to the well state of the project, documentation, tutorials and addressing problems that people face. Also using the forum feature and discussion is a good way of keeping archives easily accessible to everyone. * Release-often: MC has not been officially released for a long time. I propose that the current CVS gets released as MC 5.0 and if any issues are found with the release we release 5.0.1, 5.0.2 and so on to address these problems. Sounds good to me. What about releasing mc in a given time period to prevent a lingered release cycle? Releasing a new mc (with changing its middle release number for instance) two times per year, say 1st Jan and 1st June, would be good at least for the downstream maintainer's point of view. Furthermore awareness of incoming release motivates people contributing to mc development to send all important patches before the date if they want to see them committed in the next release. Cheers, Jindrich -- Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/ The worst evil in the world is refusal to think. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation - wiki example
Hi all. I own LRSE Hosting. If you need hosting, I'd be happy to setup a virtual server for MC to host a wiki/slash/scoop whatever site. Free of charge, of course. I'd just be happy to be able to give a little back for such a great program. -- Regards, Scott --- [ Peter Masiar ] ===--- Pavel Roskin wrote: For the Wiki, all we need is a domain name (or we can keep it under the obscure url we can put it on). I have midnightcommander.org registered on Gandi. I can set its IP address to anything. But I don't have any servers to host Wiki. I host CGI::Application 'Best Practices' wiki, http://twiki.med.yale.edu/twiki2/bin/view/CGIapp/WebHome just for kicks set up MC wiki here: http://twiki.med.yale.edu/twiki2/bin/view/MC/WebHome I do not claim this should be 'The MC wiki' - just to show how easy will be to others to contribute with info, links, docs, etc, if we use wiki. How even non-coders (like me) can contribute to most important tool (at least for me). I do not have a logo yet (image is broken) but I will look something up. I am open for suggestions. :-) -- Peter Masiar, [EMAIL PROTECTED], NEW PHONE: (203) 737-2989 Yale Center for Medical Informatics (YCMI), http://ycmi.med.yale.edu I am not a lawyer. My ideas are NOT binding for University. In doubt, Yale policy right: http://www.yale.edu/policy/itaup.html ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #7872] Suggested changes in Python syntax bindings
Follow-up Comment #6, bug #7872 (project mc): [...] We could just as well start matching all possible paths to the binaries. i can't claim i'd understand that paragraph. :} [...] If you could comment on the usefulness [...] i'm can't claim to be a python wiz, either. http://docs.python.org/ref/strings.html the misunderstanding wrt. comments stems from the fact, that a string right after the def: of a function is a doc string. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hi Pavel, On Mon, 2005-05-23 at 03:20, Pavel Roskin wrote: I would suggest if such a step would be made we use the MC_4_6_1_PRE for this. HEAD is somewhat experimental. I disagree. We would confuse everybody. The 4.6.1 branch should be released as 4.6.1 if at all (maybe as 4.6.2 if there we unofficial 4.6.1 releases). It's the experimental code that should become 5.0 or 4.7 or whatever we choose. If it's too unstable, we could make some prereleases. ?? Aren't you saying what I'm saying? MC_4_6_1_PRE should become mc-4.6.1 and HEAD should be used for the release of 4.7 (the viewer code is not well tested so I believe it shouldn't be used for 4.6.1). Where do we disagree? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Some questions
Hi Pavel, On Mon, 2005-05-23 at 03:13, Pavel Roskin wrote: Not doing a release for years even though there has been significant progress is what affects the credibility of the project. I agree. ... I agree except the fact that nobody has ever told me that all e-mail was read and acted upon in some way. I believe we (Pavel Shirshov, Roland Illig and me) thought this was quite obvious from all the activity on the mc-devel list. I wouldn't say that *every* mail has been acted upon, but yes, many have indeed been acted upon. I'm not sure I understand you here. I'm not against a release. Well, you've been giving a totally different impression for months. And from my contacts with other developers I can say that I am not the only one that has this impression. I'm just saying that I cannot do it properly at this time. If someone else can take the responsibility for the project and make a release, I'm fine with it (provided that the maintenance is transferred openly, and all interested parties have their say). I'm quite willing to take partial responsibility for a 4.6.1 release based on MC_4_6_1_PRE (presuming we first have a release candidate to stamp out the last small but serious issues - we could address the larger slang-2 and other issues (samba, gcc-4.0 signedness warnings etc.) for 4.7.0). So are Roland Illig and Pavel Shirshov I believe (although I haven't spoken the latter in quite some time). I see what you mean. You are saying that I could concentrate on maintenance rather that review and discuss every patch about Python keywords or something like that. If it's OK for everyone, I can do it. Yes, that's the point I'm trying to make. All issues on the TODO for 4.6.1 have been fixed, including the X11 SSH issue (although that patch should still be reviewed before it can be committed). It's very obvious your time is limited. If you could use this limited amount of time to cook up a (post 4.6.1) development roadmap with the developers it shouldn't be necessary for you to do any reviews (unless you want to of course). Is this an acceptable scenario for you, or do you feel you can't take responsibility for the code base in this manner? If you want me to make a release from the 4.6.1 branch, I can do it within a few days. I'll need to move some stuff from the HEAD branch though just to make it easier for everyone. In particulate, the Alt-O behavior should be consistent. I would vote for a release candidate from the MC_4_6_1_PRE branch. In december it was decided by the then active developers (pchel, rillig and I) that we'd freeze development on 4.6.1 in the PRE branch, so people could start doing experimental work for a post 4.6.1 release in the HEAD branch. This might not be the things were done in the past but it is the actual situation. If you insist on doing a release from HEAD (or am I misunderstanding you?) I'd suggest you'd not use the new viewer code. Note that this is *not* a remark about the quality of the code, it's just that that code has had hardly *any* testing apart from it's author, Roland Illig. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Addressing MC stagnation.
Hi Jindrich, Miguel, On Mon, 2005-05-23 at 12:28, Jindrich Novy wrote: On Sun, 2005-05-22 at 17:46 -0400, Miguel de Icaza wrote: * Release-often: MC has not been officially released for a long time. I propose that the current CVS gets released as MC 5.0 and if any issues are found with the release we release 5.0.1, 5.0.2 and so on to address these problems. I don't see the point of doing a major version jump. Although a lot has been fixed there hasn't been that much new code introduced to justify this. 4.6.1 is fine with me. 5.0 would be more of a release number for when we have full extended charset support and all libraries we depend upon are up to date. Sounds good to me. What about releasing mc in a given time period to prevent a lingered release cycle? Releasing a new mc (with changing its middle release number for instance) two times per year, say 1st Jan and 1st June, would be good at least for the downstream maintainer's point of view. I disagree with this as well ;) . I think the best way to go would be to work out a road map and work towards the milestones. Although I can understand why some projects use a periodic release schedule (like Fedora where it is impossible to synchronize the release of all included packages anyway) it feels very unnatural for a project like mc. We should just try to set up the TODO in such a way that we can have a release once or twice a year (or even more often, but based on a roadmap, *not* a timetable). Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: before committing translation files ...
On Mon, 2005-05-23 at 11:58 +0200, Roland Illig wrote: Pavel Roskin wrote: On Thu, 2005-05-19 at 13:24 +0200, Roland Illig wrote: please run the ./strip-location.sh script on all files you want to commit. The locations are only redundant information for the translator. To regenerate the locations, just run make po-update. Example: cd mc/po ./strip-location.sh de.po cvs commit ChangeLog de.po make update-po The effect is that cvs diff is more readable. I've added --no-location to all msgmerge invocations, so it should be automatic (the patch is in the HEAD branch for now). And how do the translators get their version with locations? ;) Command--Find File Or by doing this: msgmerge --update lang.po mc.pot -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [bug #7872] Suggested changes in Python syntax bindings
On Mon, 2005-05-23 at 20:08 +, Leonard den Ottolander wrote: Follow-up Comment #7, bug #7872 (project mc): My question is why do we need the extra code to match '/usr/bin/env' if all we need to match is 'perl'? It seems redundant. Like trying to match '/usr/bin/perl', '/usr/local/bin/perl' etc. instead of just 'perl'. Good idea, let's do it for all interpreters. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] space on prompt bugfix
Hi Oswald, On Sat, 2005-05-21 at 20:07, Oswald Buddenhagen wrote: On Wed, Apr 27, 2005 at 11:24:06PM +0200, Leonard den Ottolander wrote: Any objections against me committing this patch? The real command line argument seems bogus, as a real command line would accept a command existing of only spaces but mc does not. So can I commit this? I'll verify that it works first ;) , but the patch seems straight forward enough. there were no objections, so i suppose you forgot it. :) I should have asked for a verification ;-p . So you've tested this patch and agree it should be committed? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] space on prompt bugfix
On Mon, May 23, 2005 at 10:44:01PM +0200, Leonard den Ottolander wrote: On Sat, 2005-05-21 at 20:07, Oswald Buddenhagen wrote: On Wed, Apr 27, 2005 at 11:24:06PM +0200, Leonard den Ottolander wrote: So can I commit this? I'll verify that it works first ;) , but the patch seems straight forward enough. there were no objections, so i suppose you forgot it. :) I should have asked for a verification ;-p . hehe So you've tested this patch of course not. i had a look and have not found something fundamentally broken about it. if a real mc developer would do the same, it should be totally sufficient. this paranoid checking policy doesn't get us anywhere but to the current state of stagnation. head is there for being broken once in a while. and if you find yourself in the situation that you cannot break head because people are relying on it's stability, you should seriously reconsider your release policy ... and agree it should be committed? sure -- 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
Re: [bug #7872] Suggested changes in Python syntax bindings
Hi Pavel, On Mon, 2005-05-23 at 22:43, Pavel Roskin wrote: On Mon, 2005-05-23 at 20:08 +, Leonard den Ottolander wrote: Follow-up Comment #7, bug #7872 (project mc): My question is why do we need the extra code to match '/usr/bin/env' if all we need to match is 'perl'? It seems redundant. Like trying to match '/usr/bin/perl', '/usr/local/bin/perl' etc. instead of just 'perl'. Good idea, let's do it for all interpreters. Do what for all interpreters? Match all possible paths? Are you kidding? Or just misreading me? Or do you say that the extra match for '/usr/bin/env' serves a useful purpose? Which? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #7872] Suggested changes in Python syntax bindings
Follow-up Comment #8, bug #7872 (project mc): i'd prefer to have the exact match as a simple correctness check. oh, well. is just the same as , except that you can embed physical newlines in this type of string. actually reading the BNF in the page i linked to would have revealed that (as it did to me now). don't act more stupid than you are. ;) ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] space on prompt bugfix
Hi Oswald, On Mon, 2005-05-23 at 22:56, Oswald Buddenhagen wrote: of course not. i had a look and have not found something fundamentally broken about it. if a real mc developer would do the same, it should be totally sufficient. I'm not sure if I would qualify. this paranoid checking policy doesn't get us anywhere but to the current state of stagnation. Bollocks. If you hadn't noticed pchel and I have done quite a lot of work this way the last half year of 2004. It's just that there don't seem to be many people that want to be the second pair of eyes to check patches. I believe double verification is a good policy to avoid silly mistakes. This might be a rather trivial patch, so yes, I could have committed it. Maybe I'm a bit too cautious at times. Must be my lack of formal training that makes me a bit uncertain about these issues at times. Otoh in all these months nobody seems to have cared just to take a look for a second and reply that they thought the thing was ok. head is there for being broken once in a while. and if you find yourself in the situation that you cannot break head because people are relying on it's stability, you should seriously reconsider your release policy ... I was intending to commit this to PRE as well. and agree it should be committed? sure Right. Thanks. I'll commit it to PRE and HEAD then. Tomorrow. Or the day after. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[bug #7872] Suggested changes in Python syntax bindings
Follow-up Comment #9, bug #7872 (project mc): I just don't feel like actually verifying this. Duh. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] space on prompt bugfix
On Mon, May 23, 2005 at 11:12:21PM +0200, Leonard den Ottolander wrote: On Mon, 2005-05-23 at 22:56, Oswald Buddenhagen wrote: this paranoid checking policy doesn't get us anywhere but to the current state of stagnation. Bollocks. [how reviewing is good, etc.] i was talking about the testing aspect, in particular. it will be tested after commit (apart from that i expect the author to have tested most possible situations already), so why slow down your process by enforcing something that nobody will do anyway? head is there for being broken once in a while. [...] I was intending to commit this to PRE as well. and you have to do this in the same second, right? ;) -- 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
