From onlyjob at member.fsf.org Sat Nov 3 00:34:58 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Sat, 3 Nov 2012 11:34:58 +1100 Subject: optimising "change CWD" algorithm in subshell mode Message-ID: <201211031134.59141.onlyjob@member.fsf.org> Dear MC team, This is just an idea of improvement. At the moment MC is quite ineffectively changing current working directory (CWD) in subshell mode. What's happening is MC sends full path of a directory we're we want to change to the (bash) shell. For example if current working directory is /1/2/3/4/5 and we want to change to /1/2/3/4/5/6 MC sends "cd /1/2/3/4/5/6" to bash when in reality one would likely to use "cd ./6" as long as it is just one hop away from current directory. Changing directories in deeply nested trees becomes increasingly slower as we travel deeper and deeper until MC is crashing when trying to change to a very long path or hangs on hide panels operation, see https://www.midnight-commander.org/ticket/2072#comment:11 Worth noticing that major factor contributing to speed of changing directories is not a depth but a length of a full path: if directory names are long the slowdown becomes noticeable much sooner which also contributes to probability of crash. So the idea is to optimise CWD algorithm a little by sending only relative "cd" from CWD when possible. Is it feasible? How easy this can be implemented? Cheers, Dmitry. From ossi at kde.org Sun Nov 4 10:26:04 2012 From: ossi at kde.org (Oswald Buddenhagen) Date: Sun, 4 Nov 2012 11:26:04 +0100 Subject: optimising "change CWD" algorithm in subshell mode In-Reply-To: <201211031134.59141.onlyjob@member.fsf.org> References: <201211031134.59141.onlyjob@member.fsf.org> Message-ID: <20121104102604.GB31635@ugly.local> On Sat, Nov 03, 2012 at 11:34:58AM +1100, Dmitry Smirnov wrote: > For example if current working directory is /1/2/3/4/5 and we want to > change to /1/2/3/4/5/6 MC sends "cd /1/2/3/4/5/6" to bash when in > reality one would likely to use "cd ./6" as long as it is just one hop > away from current directory. > > Is it feasible? > i don't like it for two reasons: - using an absolute path is an easy error recovery. mc gets confused often enough by errors while changing cwd (especially since shell activity detection was so utterly screwed up). not being able to just hit twice to recover would be a major PITA. - this is fixing the problem at the wrong place, aka a workaround. there is no way in hell that simple processing of a string with a few tens of utf8 characters could legitimately require billions of cpu cycles. my suspicion is that some utterly inefficient shell functions are being invoked via $PS1 or so - that would also explain why there are problems reproducing it. From onlyjob at member.fsf.org Sun Nov 4 12:43:35 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Sun, 4 Nov 2012 23:43:35 +1100 Subject: optimising "change CWD" algorithm in subshell mode In-Reply-To: <20121104102604.GB31635@ugly.local> References: <201211031134.59141.onlyjob@member.fsf.org> <20121104102604.GB31635@ugly.local> Message-ID: <201211042343.36151.onlyjob@member.fsf.org> Dear Oswald, On Sun, 4 Nov 2012 21:26:04 Oswald Buddenhagen wrote: > On Sat, Nov 03, 2012 at 11:34:58AM +1100, Dmitry Smirnov wrote: > > For example if current working directory is /1/2/3/4/5 and we want to > > change to /1/2/3/4/5/6 MC sends "cd /1/2/3/4/5/6" to bash when in > > reality one would likely to use "cd ./6" as long as it is just one hop > > away from current directory. > > > > Is it feasible? > > i don't like it for two reasons: > - using an absolute path is an easy error recovery. mc gets confused > often enough by errors while changing cwd (especially since shell > activity detection was so utterly screwed up). not being able to just > hit twice to recover would be a major PITA. Even if we have to ask bash for CWD (pwd) when possible it still could be done isn't it? Are you sure it can't be implemented reliably? > - this is fixing the problem at the wrong place, aka a workaround. there > is no way in hell that simple processing of a string with a few tens > of utf8 characters could legitimately require billions of cpu cycles. > my suspicion is that some utterly inefficient shell functions are > being invoked via $PS1 or so - that would also explain why there are > problems reproducing it. First of all there is no problem reproducing it with bash subshell. I clearly described how. It's not "few tens" but rather a several hundred utf8 characters we're pushing to bash every time we change directory. Even though travelling through deep long trees may become very uncomfortable comparing to "-u" mode it wouldn't be so bad if it were merely an inconvenience of slowness. To me much bigger problem is that MC hangs or crashes in this situation. If the problem is due to bash limitation for max path length then we have either legitimate case for workaround or a bug to file against bash. What do you think would be the best to do about it? Regards, Dmitry. From ossi at kde.org Mon Nov 5 17:09:45 2012 From: ossi at kde.org (Oswald Buddenhagen) Date: Mon, 5 Nov 2012 18:09:45 +0100 Subject: optimising "change CWD" algorithm in subshell mode In-Reply-To: <201211042343.36151.onlyjob@member.fsf.org> References: <201211031134.59141.onlyjob@member.fsf.org> <20121104102604.GB31635@ugly.local> <201211042343.36151.onlyjob@member.fsf.org> Message-ID: <20121105170945.GA4115@troll08.it.local> On Sun, Nov 04, 2012 at 11:43:35PM +1100, Dmitry Smirnov wrote: > What do you think would be the best to do about it? > find out where the slowness *actually* comes from. oprofile, or maybe callgrind (once you isolated the process). From onlyjob at member.fsf.org Mon Nov 5 20:44:13 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 6 Nov 2012 07:44:13 +1100 Subject: optimising "change CWD" algorithm in subshell mode In-Reply-To: <20121105170945.GA4115@troll08.it.local> References: <201211031134.59141.onlyjob@member.fsf.org> <201211042343.36151.onlyjob@member.fsf.org> <20121105170945.GA4115@troll08.it.local> Message-ID: <201211060744.14190.onlyjob@member.fsf.org> On Tue, 6 Nov 2012 04:09:45 Oswald Buddenhagen wrote: > On Sun, Nov 04, 2012 at 11:43:35PM +1100, Dmitry Smirnov wrote: > > What do you think would be the best to do about it? > > find out where the slowness *actually* comes from. oprofile, or maybe > callgrind (once you isolated the process). I don't know where slowness comes from (self-evidently it becomes slower with the growing length of full path) but *crash* comes from long string (>1024 characters) passed to bash hence it make sense to limit that if possible. From bircoph at gmail.com Mon Nov 5 21:25:59 2012 From: bircoph at gmail.com (Andrew Savchenko) Date: Tue, 6 Nov 2012 01:25:59 +0400 Subject: optimising "change CWD" algorithm in subshell mode In-Reply-To: <201211060744.14190.onlyjob@member.fsf.org> References: <201211031134.59141.onlyjob@member.fsf.org> <201211042343.36151.onlyjob@member.fsf.org> <20121105170945.GA4115@troll08.it.local> <201211060744.14190.onlyjob@member.fsf.org> Message-ID: <20121106012559.80e1efb7.bircoph@gmail.com> Hello, On Tue, 6 Nov 2012 07:44:13 +1100 Dmitry Smirnov wrote: > On Tue, 6 Nov 2012 04:09:45 Oswald Buddenhagen wrote: > > On Sun, Nov 04, 2012 at 11:43:35PM +1100, Dmitry Smirnov wrote: > > > What do you think would be the best to do about it? > > > > find out where the slowness *actually* comes from. oprofile, or maybe > > callgrind (once you isolated the process). > > I don't know where slowness comes from (self-evidently it becomes slower with > the growing length of full path) That's why you are asked to use oprofile to find out. You may use systemtap as well. My readings shows that bash is slow here, not MC; your mileage may vary, of course. But problems must be fixed where they occur, not where it is convenient to put a hack for you. > but *crash* comes from long string (>1024 > characters) passed to bash hence it make sense to limit that if possible. I set up your locale, generated dirs via: for n in $(seq 100); do DN="${DN}/notsolongdirnametotestnested_$n"; done; mkdir -p "./${DN}" and I can move throught the end of this tree without a crash and with some small slowdown (about 1-2 seconds in the end). I use mc-4.8.3-36-gf1075b8 and bash-4.2_p37. Best regards, Andrew Savchenko -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From egmont at gmail.com Mon Nov 5 21:37:56 2012 From: egmont at gmail.com (Egmont Koblinger) Date: Mon, 5 Nov 2012 22:37:56 +0100 Subject: optimising "change CWD" algorithm in subshell mode In-Reply-To: <20121106012559.80e1efb7.bircoph@gmail.com> References: <201211031134.59141.onlyjob@member.fsf.org> <201211042343.36151.onlyjob@member.fsf.org> <20121105170945.GA4115@troll08.it.local> <201211060744.14190.onlyjob@member.fsf.org> <20121106012559.80e1efb7.bircoph@gmail.com> Message-ID: Hi guys, I looked at the problem a while ago, and figured out that bash's speed improved quite a lot during versions, even though the latest is still not as fast as it should be, but much better than previous versions. I figured out that with bash-4.2 the slowness it bearable and wasn't worth it for me to investigate any further. Dmitry, please make sure that you also use the newest bash. If you're not, upgrading will perhaps significantly improve your experience. I'm really not sure about the crash, though. cheers, egmont On Mon, Nov 5, 2012 at 10:25 PM, Andrew Savchenko wrote: > Hello, > > On Tue, 6 Nov 2012 07:44:13 +1100 Dmitry Smirnov wrote: > > On Tue, 6 Nov 2012 04:09:45 Oswald Buddenhagen wrote: > > > On Sun, Nov 04, 2012 at 11:43:35PM +1100, Dmitry Smirnov wrote: > > > > What do you think would be the best to do about it? > > > > > > find out where the slowness *actually* comes from. oprofile, or maybe > > > callgrind (once you isolated the process). > > > > I don't know where slowness comes from (self-evidently it becomes slower > with > > the growing length of full path) > > That's why you are asked to use oprofile to find out. You may use > systemtap as well. > > My readings shows that bash is slow here, not MC; your mileage may vary, > of course. But problems must be fixed where they occur, not where it is > convenient to put a hack for you. > > > but *crash* comes from long string (>1024 > > characters) passed to bash hence it make sense to limit that if possible. > > I set up your locale, generated dirs via: > for n in $(seq 100); do DN="${DN}/notsolongdirnametotestnested_$n"; done; > mkdir -p "./${DN}" > and I can move throught the end of this tree without a crash and with > some small slowdown (about 1-2 seconds in the end). > > I use mc-4.8.3-36-gf1075b8 and bash-4.2_p37. > > Best regards, > Andrew Savchenko > > _______________________________________________ > mc-devel mailing list > https://mail.gnome.org/mailman/listinfo/mc-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From onlyjob at member.fsf.org Mon Nov 5 23:00:41 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 6 Nov 2012 10:00:41 +1100 Subject: optimising "change CWD" algorithm in subshell mode In-Reply-To: <20121106012559.80e1efb7.bircoph@gmail.com> References: <201211031134.59141.onlyjob@member.fsf.org> <201211060744.14190.onlyjob@member.fsf.org> <20121106012559.80e1efb7.bircoph@gmail.com> Message-ID: <201211061000.41473.onlyjob@member.fsf.org> On Tue, 6 Nov 2012 08:25:59 Andrew Savchenko wrote: > On Tue, 6 Nov 2012 07:44:13 +1100 Dmitry Smirnov wrote: > > On Tue, 6 Nov 2012 04:09:45 Oswald Buddenhagen wrote: > > > On Sun, Nov 04, 2012 at 11:43:35PM +1100, Dmitry Smirnov wrote: > > > > What do you think would be the best to do about it? > > > > > > find out where the slowness *actually* comes from. oprofile, or maybe > > > callgrind (once you isolated the process). > > > > I don't know where slowness comes from (self-evidently it becomes slower > > with the growing length of full path) > > That's why you are asked to use oprofile to find out. You may use > systemtap as well. Andrew, I have to clarify that Oswald merely replied what's in his opinion should be done. He did not ask me to use those tools. I don't know how to use them. If you posses this knowledge please feel free to share what you have found. Regards, Dmitry. From onlyjob at member.fsf.org Mon Nov 5 23:20:31 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 6 Nov 2012 10:20:31 +1100 Subject: optimising "change CWD" algorithm in subshell mode In-Reply-To: References: <201211031134.59141.onlyjob@member.fsf.org> <20121106012559.80e1efb7.bircoph@gmail.com> Message-ID: <201211061020.31721.onlyjob@member.fsf.org> On Tue, 6 Nov 2012 08:37:56 Egmont Koblinger wrote: > I looked at the problem a while ago, and figured out that bash's speed > improved quite a lot during versions, even though the latest is still not > as fast as it should be, but much better than previous versions. I figured > out that with bash-4.2 the slowness it bearable and wasn't worth it for me > to investigate any further. > > Dmitry, please make sure that you also use the newest bash. If you're not, > upgrading will perhaps significantly improve your experience. > I'm not sure how much performance has increased comparing to older bash versions. At the moment I have bash_4.2.36 but I'm not too sensitive to this problem as I rarely explore deeply nested trees. However I think even with up-to-date bash slowdown can be quite noticeable on older computers. Here is an example of feedback that I had difficulties to confirm until I went much deeper: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652883#30 > I'm really not sure about the crash, though. > Crash is there, to reproduce just navigate deep enough and hide panels (Ctrl+O). I think we're all pretty much agree that fixing hangs/crashes are of much greater priority than optimising slowdown. Cheers, Dmitry. From netuse at lavabit.com Mon Nov 19 16:11:44 2012 From: netuse at lavabit.com (Marco) Date: Mon, 19 Nov 2012 17:11:44 +0100 Subject: Defining custom actions Message-ID: <20121119171144.798e43de@homerow> Hi! Is there a way to add more actions to some file types additionally to the predefined View, Open and Edit? I found the following snippet on the web, but I have no idea how to access the custom defined actions. regex/\.([Tt]ex|TEX|TeX)$ Open=%var{EDITOR:vi} %f TeX this file=tex %f LaTeX this file=latex %f Marco From aborodin at vmail.ru Tue Nov 20 04:23:04 2012 From: aborodin at vmail.ru (Andrew Borodin) Date: Tue, 20 Nov 2012 08:23:04 +0400 Subject: Defining custom actions In-Reply-To: <20121119171144.798e43de@homerow> References: <20121119171144.798e43de@homerow> Message-ID: On Mon, 19 Nov 2012 17:11:44 +0100 Marco wrote: > Is there a way to add more actions to some file types additionally > to the predefined View, Open and Edit? No. There is no code to handle any other actions. -- Andrew From netuse at lavabit.com Sun Nov 18 18:15:33 2012 From: netuse at lavabit.com (Marco) Date: Sun, 18 Nov 2012 19:15:33 +0100 Subject: Defining custom actions Message-ID: <20121118191533.7e26d2df@homerow> Hi! Is there a way to add more actions to some file types additionally to the predefined View, Open and Edit? I found the following snippet on the web, but I have no idea how to access the custom defined actions. regex/\.([Tt]ex|TEX|TeX)$ Open=%var{EDITOR:vi} %f TeX this file=tex %f LaTeX this file=latex %f Marco From pascal.longuepee at ucm.be Thu Nov 22 10:42:19 2012 From: pascal.longuepee at ucm.be (LONGUEPEE Pascal) Date: Thu, 22 Nov 2012 10:42:19 -0000 Subject: MC behaviour change between linux and AIX Message-ID: <0E1D732517DB6B44A9653CF5A8D2D12F058E6230AB@100SVW010.intra.pme-net.net> Hi, we are using for a long time mc on linux , now we just install it on AIX . On Aix , mc quit when we press F10 without changing the current dir to the last displayed dir within mc. We don't find any obvouis solution on web ( ini parameter ?) ..... Can you tell use if it's possible on aix. ? Thanks . On aix : # mc -V GNU Midnight Commander 4.7.0.4 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm With internationalization support With multiple codepages support Data types: char 8 int 32 long 32 void * 32 off_t 64 ecs_char 8 On Linux : $ mc -V GNU Midnight Commander 4.6.1-pre1a Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, undelfs With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support Regards. Pascal longuepee Administrateur Syst?mes UCM DIGIT Chauss?e de Marche 637 - 5100 Wierde T?l : 081/32 55 57 Gsm : 0478/84 09 61 [cid:image001.jpg at 01CDC8A3.C2D7CF00] website : www.ucm.be -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2065 bytes Desc: image001.jpg URL: