From makovick at kmlinux.fjfi.cvut.cz Sun Nov 2 12:51:08 2003 From: makovick at kmlinux.fjfi.cvut.cz (Jindrich Makovicka) Date: Sun, 02 Nov 2003 13:51:08 +0100 Subject: [patch] ftpfs specifying password for "ftp" & "anonymous" accounts Message-ID: <3FA4FDBC.7080108@kmlinux.fjfi.cvut.cz> Hi, this patch makes ftp:mypassword at server work as expected (logs as "ftp" with password "mypassword"). Currently mc uses always the default mail address as a password for ftp or anonymous, regardless of the password specified after a colon. -- Jindrich Makovicka -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ftpfs.c.diff URL: From biro_arpad at yahoo.com Tue Nov 4 22:06:26 2003 From: biro_arpad at yahoo.com (Arpad Biro) Date: Tue, 4 Nov 2003 14:06:26 -0800 (PST) Subject: Textual corrections Message-ID: <20031104220626.91466.qmail@web13702.mail.yahoo.com> Hi, Just in case you forgot about it... I reported a few small things in the following post last year: http://mail.gnome.org/archives/mc-devel/2002-December/msg00273.html They seem to be present in the current snapshot as well. Arpad Biro __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From proski at gnu.org Wed Nov 5 00:38:04 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 4 Nov 2003 19:38:04 -0500 (EST) Subject: Textual corrections In-Reply-To: <20031104220626.91466.qmail@web13702.mail.yahoo.com> References: <20031104220626.91466.qmail@web13702.mail.yahoo.com> Message-ID: On Tue, 4 Nov 2003, Arpad Biro wrote: > Just in case you forgot about it... > I reported a few small things in the following post last year: > > http://mail.gnome.org/archives/mc-devel/2002-December/msg00273.html > > They seem to be present in the current snapshot as well. Yes, unfortunately. "%s opening remote file" "%s removing remote file" "%s renaming files" This comes from smbfs.c and should not be displayed often. I don't see how to fix it without invalidating the existing translations. "In this cases" "~/.netrc file has not correct mode" I have fixed these. -- Regards, Pavel Roskin From proski at gnu.org Sun Nov 9 08:53:53 2003 From: proski at gnu.org (Pavel Roskin) Date: Sun, 09 Nov 2003 03:53:53 -0500 (EST) Subject: Your mc efforts is a great job !!! [Warning]: Long In-Reply-To: <3FA0757D.5030303@optonline.net> References: <3F9C904F.3000601@optonline.net> <3F9DC7A1.7010206@optonline.net> <3FA0757D.5030303@optonline.net> Message-ID: On Wed, 29 Oct 2003, Nikolai Bezroukov wrote: > [Warning] Long, as I reiterated some points from the prev discussion. Sorry, I could not reply earlier. Valgrind shows that mc has serious problems with garbage collection in VFS if extfs in involved. I must give priority to coding because it's something that nobody else will fix. This discussion is something that others are more likely to participate in. > Pavel Roskin wrote: > > [snip] > > I'm not sure you are talking about mcfs. mcfs doesn't allow you to > > execute any remote commands other than whatever is already > > supported by mcserver. That's the standard file operations supported > by FTP > > plus a few goodies like chmod. > > I do not know the details of the actual implementation, but IMHO the > idea itself is very elegant although slightly ahead of the codebase with > its hardwired hotkeys. It's better to be preserved and extended it to > the full functionality. We should not throw out the child with a water. I think we are completely misunderstanding each other. Hotkeys have noting to do with it. Either mcserv remains are a file server, or it becomes a file server plus shell server (like sshd). I believe we don't need another shell server. If you have a different opinion, please show your code. But if you don't document every function, I'm not going to look at your patch. There are enough good patches in the queue that I don't have time to apply. > Your concerns about security might be slightly overstated, as IPsec, SSL > or similar secure or semi-secure channel can be used. Moreover on > switched networks that now prevail, the session is not that easy to > sniff, if switches are configured correctly and hardened against ARP > poisoning. For example in the 3COM switches (SuperStack II) enabling > "Port Security" on a port makes the switch remember the first MAC > address it receives and locks that MAC address to that port until > overridden by manual intervention. After that any hacker can hit the > wall with his head as long as he wish. Also any attempt to use ARP > poisoning in corp. environment usually trigger IDS. It's irresponsible to represent insecure servers as secure ones. I know that some distributions made mcserv a separate package, which is run by default. That was the main reason for disabling mcserv and mcfs by default if installed. We failed to explain distributors that mcserv is insecure on public networks. Disabling the code by default was the way to get the message across. I'm not going to compromise on security. If you want insecure mcserv, make it a separate project. Port it to DOS, VxWorks, whatever. I'm sure embedded developers will like it. GNU Midnight Commander will not enable by default any inherently insecure code as long as I maintain it. > Here I am discussing the general ("theoretical") value of client-server > mode for this type of managers. And it is in this lights I stated in > http://www.softpanorama.org/OFM/Ofm_04.shtml and I am still convinced > that mc client-server capabilities provides an important, pioneering > step in the right direction. If keystrokes are parameterized into a > "command language", not hardwired like in the current implementation, > then this client server model is very natural with the server > interpreting internal "command language" and client converting > keystrokes to the command stream and updating panels. mcfs is part of VFS. This code is only enabled if VFS is enabled. VFS is "virtual filesystem". It has nothing to do with keystrokes. It presents remote files, archives and other objects as files. What you are describing cannot be based on the existing mcfs code. > The key advantage is the unique powerful and very attractive blend of > FTP and telnet functionality in one interface. IMHO such a functionality > might constitute a new protocol, "a command line VNC", if you wish. I'd rather have a blend of ssh and scp/sftp. Currently we have problems with ssh passwords. They can be entered more by accident than by design. > Probably equally important is the possibility of avoiding those horrible > "Alice in Wonderland" key binding problems that litter this list. The > server is immune to the host key bindings and you can use just one > client on, say, the most "mc-friendly" Linux flavor (RH8 with the > gnome-terminal 2.0.1-5 ;-) to administer all your servers. That > instantly makes mc much more appealing tool to the system administrators > who need to work with a lot of servers and might help to increase the > development resources by attracting new talented developers. I'm afraid you'll have to write that tool yourself. And if it's insecure, you will fix it or see it abandoned by "new talented developers". Sane people use ssh for that purpose. By the way, you don't need to start remote terminals, you can run ssh in a local terminal. Support for file transfers over the existing connection could be implemented in ssh itself if it's not implemented already. I believe there are serious security implications if the remove system is allowed to upload or download files without specific approval from the user. It seems to me that making the local approval secure is the core of the issue. Nobody should be able to fake that prompt on any terminal. > > I was confused by "VFS" meaning two different things on adjacent > > lines. I still don't know what NC5 XTree VFS is. I have never used NC5. > > That's how I call "flat file VFS". As a PhD I have the responsibility to > obscure things by inventing new terms ;-). See also > http://www.softpanorama.org/OFM/Ofm_00.shtml. The book discuses several > implementations including NC5. Actually, this should be implemented separately from VFS, as a higher level. It's representations of the tree on the panels, not representations of something as a tree. > > > The idea is to have access to top and bottom directory in the > > > current panel (which of course depends of your sorting mode) via > > > hotkeys. > > As I said, I'm not aware of such key in mc. > > It's actually not defined either in OFM1999 standard or in OFM2004 > standard (see http://www.softpanorama.org/OFM/Ofm_08.shtml and > http://www.softpanorama.org/OFM/Ofm_09.shtml ). Here is what OFM1999 is > saying (sorry, it's slightly Windows-biased ;-) : > > The hotkey assignment for sorting is optional. If the hotkey is > defined its action should correspond to the F9-(LR)-S sequence for > the current panel and display the same menu so that the proper order > can be selected with the second key from the menu. Alternatively, > Ctrl-F3, Ctrl-F4, Ctrl-F5, Ctrl-F6 and Ctrl-F7 can be used for > sorting by name, extension, modification time, size and unsorted, > correspondingly ("NETSU" order). > > For Unix you need to add the ability to sort by sort by permissions, > owner and group. So the menu selection string became "NETSUPOG". > > As for the hotkey, actually, how about Ctrl-A ? A very convenient > hotkey for a frequently used operation (and resorting of columns is > definitely very frequently used, at least by advanced users). Actually > you are in a better position to suggest a suitable hotkey as I do not > really understand all the tradeoffs of the Unix environment especially > the potential conflicts with Emacs/XEmacs (I use Vim/Gvim). Please reread this. I think you are misunderstanding me. As I understand, you wanted a hotkey to place the cursor on the first or last directory by one keystroke. I wrote you that we don't have such keys Actually, for the first directory, Home is pretty close in most cases. But suppose we have 1000 directories and 2000 files in some directory. Then going to the last _directory_ can be a boring task. Now you are quoting text about sorting and asking me what I think about using Ctrl-A for _sorting_, not for going to the last directory. > I consider your efforts to be really outstanding because you not only > managed to revitalize the development, but also stop the feature creep. > Without your efforts mc probably would scale down to version 4.35. IMHO > two of your recent decisions (1) to clean the code of GUI-related staff > and (2) Windows-port related staff were very timely. Thank you for your support. I wish you were around when those features were being added. > Two things are now more or less clear: > > - mc is in the stabilization phase and it's level of maturity is > reasonably high, This doesn't apply to VFS, although I hope to fix it. Support for background operations is a worse problem - it's useful, but I cannot be implemented correctly without major changes. I would say the code is in the "active stabilization" mode. Sometimes the only way to fix the code is to change it until it's clear what it does. I'm not kidding, unfortunately. > - the development resources are very scarce and just keeping up > with the usual flow of bugs strains the resources. Yes. Actually, there is some interest to "easy" parts of the code, but it's often blocked by lower-level changes required for complete implementation. The code remains too complicated for many contributors to understand, which leads to lower quality of patches. Most functions are undocumented or documented insufficiently. What do you think can do a function called vfs_add_noncurrent_stamps? Function mc_def_ungetlocalcopy had just one comment in version 4.6.0: /* Dijkstra probably hates me... But he should teach me how to do this nicely. */ Too bad, Dijkstra is not with us anymore. > That's why I think it make sense to bite the bullet and move this > "cleaning" strategy on a new level by using the capabilities of S-lang. > Adding S-lang and exposing relevant internal functions might took the > same amount of efforts as a regular cleaning of code that is needed > anyway, but with much better return on the investment. Iit gives you an > opportunity to concentrate on simplifying and refactoring the core > codebase by removing several ad hoc mini-languages invented in usual > hacker-style traditions. For example, the code implementing "user > extension predicates" and "user menu visibility predicates" are two > examples of mini-languages, implementations of which can instantly be > replaced with S-lang with no or very little effort. I want to release a version that doesn't complain about "Invalid read of size 4" in extfs_free(). Then I want to release a version that doesn't have buffers of fixed sizes for paths. I want to release a version that has all contributed patches incorporated. Please note that we don't currently include S-Lang interpreter, only S-Lang screen library. Also, it's possible to compile mc with ncurses without S-Lang. I believe ncurses support is worth keeping for now. I'd like to see how you would handle something like the Open action for HTML (search for "html" in mc.ext.in) - that action indeed has grown too large. > Also the pool of people who can develop/polish scriptable parts is > bigger/deeper. That's a natural separation of labor that the current > development environment is lacking: you need to be a jack of all trades > and react to each and every hotkey problem (actually even in todays > situation several things from the discussions can probably be added to > FAQ to cut the number of such issues). Assuming the core and scripting > part are separated you have a core team and the extension development > community like in Emacs. that's a more powerful combination and I > suspect that more people might be willing to help with the scripting, > but few would dig into the current C codebase. I agree with your idea of separation of labor, but I don't see how it can work with the current codebase. Besides, all changes need to be reviewed, and I don't see how switching to S-Lang would help. I don't know any S-Lang programmers. Also I'm afraid you are overestimating the number of problems with keys that can be fixed by making them scriptable. Many problems are inherent to terminals. > Moreover S-lang usage in mc may provide stimulus for further improvement > of both the S-lang and its interpreter and thus lift some or all of the > current limitations/reservations. There also may be some kind of > cross-pollination / integration with jed, which is a much better editor > then cooledit , so this is actually not a one time tradeoff when you can > lose of win, but a dynamic situation, a potentially mutually beneficial > two-way process. My experience shows that "cross-pollination" doesn't work. We had Cooledit code in mc. There were patches sent to the mc lists with fixes for the editor. Some were specific to the text mode, some were not. Nobody cared to forward those patches to the Cooledit maintainer. It takes time. When people contribute code for free, it's hard to ask them to do extra efforts, especially with software they don't use (i.e. graphical Cooledit). Neither did "cross-pollination" work for Samba. Changes in vfs/samba are not contributed to the Samba project. In fact, the code we are including has become a library of its own, based on old Samba code. > It is true that S-lang has its own warts and limitations, but please > understand that is such situation there is no best choice, only the > worst choice and this might be inaction. The truth is that even the > worst choice (let's say adopting bash ;-) is better than none: scripting > language is one of the few available avenues of addressing the feature > creep problem . I really don't care that much about the programming language for the scripts as long as it works. I suggested using bash for mc.ext, but others in this list didn't like the idea. I don't remember the reasons, but it should be archived. The real question is whether you want to make mc.ext and mc.menu single programs or not. If they are single programs, then the choice of the language doesn't matter - mc will be communicating with a program. If you want mc.ext and mc.menu to be sets of scripts that are parsed by mc, then I can say that they are already written in bash. > The other solution might be exposing API and introducing a FAR-style > plug-ins mechanism, although they have their own problems and having a > two dozens or more of them installed lead to "overcrowding of the > kitchen". But technically this is as simple as introducing plug-in menu > in addition to the user menu or option to call a plug-in in the user menu. This would lock the API at the time when significant reorganization of code is underway. > If the recent crisis, that you resolved by stepping in, is any > indication about the future, a large pure-C open-source implementation > like mc might not be sustainable due to the level of complexity and > those of them, which cannot not attract enough resources need either to > scale down of face the possibility of extinction. Just because the pool > of really knowledgeable C developers is shrinking and they are in fact > pretty close to becoming an endangered specie. We all like free lunch > but somebody needs to heat it even if the food is free ;-) There are so many issues here, let me comment on them separately. Pure C. Yes, I appreciate your insight. Even slightly "impure" C, like C with gcc extensions, could be helpful. Linux kernel is an example. It's well structured thanks to macros, initializers of structures, constructors and explicit exports. But in fact, the code is screaming for a language with OOP support. A lot of incorrect interdependencies would have been avoided in the compiler was enforcing some rules. It's especially important for collaborative projects. But on the other hand we have Gtk, which is pure C and sustainable. Maybe it's because Gtk developers avoided feature bloat from the beginning and cared about code quality. But it's a library - you are guaranteed to have many programmers using it. GNU Midnight Commander is for end users, even if they happen to be e.g. Perl programmers. Besides, Gtk is used in GUI. I know programmers that only work in GUI. There was the punchcard generation, the command line generation, the text UI generation (TUI), and now we have the GUI generation of programmers. GNU Midnight Commander serves only the text UI generation of users, and so it's not appealing to the young users and programmers. It's a niche project. There are 3 large free office suites in development, so the programmers resources are not scarce. Those who started with Microsoft Word are young and have enough time. Those who started with Norton Commander have serious jobs and in many cases families. We are endangered species - the text UI programmers with enough time for free software that one won't put on resume like Linux kernel, Apache or cryptography. But let's not generalize. > That's why making this decision and taking some steps now, when the mc > development is clearly revitalized because of your efforts is, in my > opinion, so important. OK, I'm afraid I cannot spend any more time on the discussion unless you show me something more specific. -- Regards, Pavel Roskin From speditor at optonline.net Tue Nov 11 04:11:50 2003 From: speditor at optonline.net (Nikolai Bezroukov) Date: Mon, 10 Nov 2003 23:11:50 -0500 Subject: Your mc efforts is a great job !!! [Warning]: Long In-Reply-To: References: <3F9C904F.3000601@optonline.net> <3F9DC7A1.7010206@optonline.net> <3FA0757D.5030303@optonline.net> Message-ID: <3FB06186.2090600@optonline.net> Hi Pavel, Pavel Roskin wrote: >On Wed, 29 Oct 2003, Nikolai Bezroukov wrote: > > [snip] >This discussion is something that others are more likely to participate >in. > > True. Still no takers... [snip] >I think we are completely misunderstanding each other. Hotkeys have >noting to do with it. Either mcserv remains are a file server, or it >becomes a file server plus shell server (like sshd). I believe we don't >need another shell server. If you have a different opinion, please show >your code. But if you don't document every function, I'm not going to >look at your patch. There are enough good patches in the queue that I >don't have time to apply. > > We actually don't, unless you want us to ;-). We just have different positions on the issue. I expressed algitimate (I suppose) opinion that mcserv can be a perfect "fileserver+shell server" conbination. You already vioced your opinion before that msserv is redundant and now reiterated your points again. I disagree, but I suppose that understood you correctly. And please do not overuse this hammer "show me the code" ;-). [snip] >I'm not going to compromise on security. If you want insecure mcserv, >make it a separate project. Port it to DOS, VxWorks, whatever. I'm sure >embedded developers will like it. GNU Midnight Commander will not enable >by default any inherently insecure code as long as I maintain it. > > Security is the matter of IQ. Rephazing a Russian proverb, it's better to lose some with a clever admin, than to gain some with a foollish one. Idiot admin with ssh will always have a less secure system that a competent admin with telnet and ftp and my point is that mc is for intelligent admins ;-) In no way encryption on the application level like in ssh is panacea. On the transport level its another story (Ipsec). FYI Open SSH 1 was one of the major sources of "real" break-ins for ISPs. Do not know stats for 'real' breakins for SSH2 but the latest CERT advisories (CA-2002-36. etc) does not encorage blind trust and suggest that there still risks due to the complexity of the codebase. [snip] > I'd rather have a blend of ssh and scp/sftp. Here I have other opinion, but I respect yours. [snip] >> > I was confused by "VFS" meaning two different things on adjacent >> > lines. I still don't know what NC5 XTree VFS is. I have never used NC5. >> >>That's how I call "flat file VFS". As a PhD I have the responsibility to >>obscure things by inventing new terms ;-). See also >>http://www.softpanorama.org/OFM/Ofm_00.shtml. The book discuses several >>implementations including NC5. >> >> > >Actually, this should be implemented separately from VFS, as a higher >level. It's representations of the tree on the panels, not >representations of something as a tree. > You might be wrong, as semantically this is yet another VFS, not that different from tar VFS or gzip VFS. >> > > The idea is to have access to top and bottom directory in the >> > > current panel (which of course depends of your sorting mode) via >> > > hotkeys. >> > As I said, I'm not aware of such key in mc. >> >>It's actually not defined either in OFM1999 standard or in OFM2004 >>standard (see http://www.softpanorama.org/OFM/Ofm_08.shtml and >>http://www.softpanorama.org/OFM/Ofm_09.shtml ). Here is what OFM1999 is >>saying (sorry, it's slightly Windows-biased ;-) : >> >> The hotkey assignment for sorting is optional. If the hotkey is >> defined its action should correspond to the F9-(LR)-S sequence for >> the current panel and display the same menu so that the proper order >> can be selected with the second key from the menu. Alternatively, >> Ctrl-F3, Ctrl-F4, Ctrl-F5, Ctrl-F6 and Ctrl-F7 can be used for >> sorting by name, extension, modification time, size and unsorted, >> correspondingly ("NETSU" order). >> >>For Unix you need to add the ability to sort by sort by permissions, >>owner and group. So the menu selection string became "NETSUPOG". >> >>As for the hotkey, actually, how about Ctrl-A ? A very convenient >>hotkey for a frequently used operation (and resorting of columns is >>definitely very frequently used, at least by advanced users). Actually >>you are in a better position to suggest a suitable hotkey as I do not >>really understand all the tradeoffs of the Unix environment especially >>the potential conflicts with Emacs/XEmacs (I use Vim/Gvim). >> >> > >Please reread this. I think you are misunderstanding me. As I understand, >you wanted a hotkey to place the cursor on the first or last directory by >one keystroke. > No, that was a wrong idea. Forget about it. I realized that this should be better addressed by F10 (already in the TODO list), if the tree is positioned on the current directory. >I wrote you that we don't have such keys Actually, for the first >directory, Home is pretty close in most cases. But suppose we have 1000 >directories and 2000 files in some directory. Then going to the last >_directory_ can be a boring task. > >Now you are quoting text about sorting and asking me what I think about >using Ctrl-A for _sorting_, not for going to the last directory. > > Here I was probably wrong. I learned that FAR is using Ctrl-F12. >>I consider your efforts to be really outstanding because you not only >>managed to revitalize the development, but also stop the feature creep. >>Without your efforts mc probably would scale down to version 4.35. IMHO >>two of your recent decisions (1) to clean the code of GUI-related staff >>and (2) Windows-port related staff were very timely. >> >> > >Thank you for your support. I wish you were around when those features >were being added. > > You are quite welcomed. Thank you very much for your efforts !!! >>Two things are now more or less clear: >> >> - mc is in the stabilization phase and it's level of maturity is >> reasonably high, >> >> > >This doesn't apply to VFS, although I hope to fix it. Support for >background operations is a worse problem - it's useful, but I cannot be >implemented correctly without major changes. > >I would say the code is in the "active stabilization" mode. Sometimes the >only way to fix the code is to change it until it's clear what it does. >I'm not kidding, unfortunately. > > That's a common situation not limited ot mc. You might benefit from Doxygen [snip] >>That's why I think it make sense to bite the bullet and move this >>"cleaning" strategy on a new level by using the capabilities of S-lang. >>Adding S-lang and exposing relevant internal functions might took the >>same amount of efforts as a regular cleaning of code that is needed >>anyway, but with much better return on the investment. Iit gives you an >>opportunity to concentrate on simplifying and refactoring the core >>codebase by removing several ad hoc mini-languages invented in usual >>hacker-style traditions. For example, the code implementing "user >>extension predicates" and "user menu visibility predicates" are two >>examples of mini-languages, implementations of which can instantly be >>replaced with S-lang with no or very little effort. >> >> > >I want to release a version that doesn't complain about "Invalid read of >size 4" in extfs_free(). Then I want to release a version that doesn't >have buffers of fixed sizes for paths. I want to release a version that >has all contributed patches incorporated. > >Please note that we don't currently include S-Lang interpreter, only >S-Lang screen library. Also, it's possible to compile mc with ncurses >without S-Lang. I believe ncurses support is worth keeping for now. > > That complicates things. If the current goal is simplicity, that should be wieghted against the amount of code that need to be maintaned when you support both, and the amount when you need to support just S-lang. >I'd like to see how you would handle something like the Open action for >HTML (search for "html" in mc.ext.in) - that action indeed has grown too >large. > That's a drawback of any scripting approach -- it can be too slow. So be it. Nothing is perfect and scripting is not a panacea for all situations. >>Also the pool of people who can develop/polish scriptable parts is >>bigger/deeper. That's a natural separation of labor that the current >>development environment is lacking: you need to be a jack of all trades >>and react to each and every hotkey problem (actually even in todays >>situation several things from the discussions can probably be added to >>FAQ to cut the number of such issues). Assuming the core and scripting >>part are separated you have a core team and the extension development >>community like in Emacs. that's a more powerful combination and I >>suspect that more people might be willing to help with the scripting, >>but few would dig into the current C codebase. >> >> > >I agree with your idea of separation of labor, but I don't see how it can >work with the current codebase. Besides, all changes need to be reviewed, >and I don't see how switching to S-Lang would help. I don't know any >S-Lang programmers. > > Niether do I. But IMHO anybody with scripting language experience can do useful things in S-lang. Still I agree with you that this is currently "bird in the sky" thing. >Also I'm afraid you are overestimating the number of problems with >keys that can be fixed by making them scriptable. Many problems are >inherent to terminals. > > True. It does not make them to go away, thouth. I would like to stress it again: in case one meed to administer many different OSes, mcserver might help as it is not dependent on the terminal on the target machine. >>Moreover S-lang usage in mc may provide stimulus for further improvement >>of both the S-lang and its interpreter and thus lift some or all of the >>current limitations/reservations. There also may be some kind of >>cross-pollination / integration with jed, which is a much better editor >>then cooledit , so this is actually not a one time tradeoff when you can >>lose of win, but a dynamic situation, a potentially mutually beneficial >>two-way process. >> >> > >My experience shows that "cross-pollination" doesn't work. We had >Cooledit code in mc. There were patches sent to the mc lists with fixes >for the editor. Some were specific to the text mode, some were not. >Nobody cared to forward those patches to the Cooledit maintainer. It >takes time. When people contribute code for free, it's hard to ask them >to do extra efforts, especially with software they don't use (i.e. >graphical Cooledit). > >Neither did "cross-pollination" work for Samba. Changes in vfs/samba are >not contributed to the Samba project. In fact, the code we are including >has become a library of its own, based on old Samba code. > > You might be right. . >>It is true that S-lang has its own warts and limitations, but please >>understand that is such situation there is no best choice, only the >>worst choice and this might be inaction. The truth is that even the >>worst choice (let's say adopting bash ;-) is better than none: scripting >>language is one of the few available avenues of addressing the feature >>creep problem . >> >> > >I really don't care that much about the programming language for the >scripts as long as it works. > >I suggested using bash for mc.ext, but others in this list didn't like the >idea. I don't remember the reasons, but it should be archived. > > Actually I was wrong. You idea with bash for mc.ext might actually be not a bad idea and can be used in mc.menu too. >The real question is whether you want to make mc.ext and mc.menu single >programs or not. If they are single programs, then the choice of the >language doesn't matter - mc will be communicating with a program. > > IMHO they are not monolitic scripts. I suspect that they are closer to script libraries, similar to startup scripts, but this does not invalidate your idea. For example you can represent shortcuts as soft link names for the script. Variables exposed by mc can be just be converted into environment variables like MC_ALTPATH for %D, or MC_FILE for %f, etc. That might help to solve problem with non-working substitution in quick cd command. The question is what is the return on the investment in the simplification of code, as better is the enemy of good. >If you want mc.ext and mc.menu to be sets of scripts that are parsed by >mc, then I can say that they are already written in bash. > > I agree about bash. Both looks like a sets of scripts and as I mentioned above it might make sense to store them in a way similar to starup scripts. To achive the effect of generation of the menu that is used in mc you need to have a special option for each script (like status) and when invoked with this option the script needs to produces a menu entry if conditions are met, nothing if not. >>The other solution might be exposing API and introducing a FAR-style >>plug-ins mechanism, although they have their own problems and having a >>two dozens or more of them installed lead to "overcrowding of the >>kitchen". But technically this is as simple as introducing plug-in menu >>in addition to the user menu or option to call a plug-in in the user menu. >> >> > >This would lock the API at the time when significant reorganization of >code is underway. > > True, but my point is that it's easier then adding scripting language because you can partially reuse ideas that FAR and Total Commander APIs. And that might suggest some directions of reorganization of the codebase. >>If the recent crisis, that you resolved by stepping in, is any >>indication about the future, a large pure-C open-source implementation >>like mc might not be sustainable due to the level of complexity and >>those of them, which cannot not attract enough resources need either to >>scale down of face the possibility of extinction. Just because the pool >>of really knowledgeable C developers is shrinking and they are in fact >>pretty close to becoming an endangered specie. We all like free lunch >>but somebody needs to heat it even if the food is free ;-) >> >> > >There are so many issues here, let me comment on them separately. > >Pure C. Yes, I appreciate your insight. Even slightly "impure" C, like C >with gcc extensions, could be helpful. Linux kernel is an example. It's >well structured thanks to macros, initializers of structures, constructors >and explicit exports. > > Least common denominator prevails in application. Kernel is quite another story and different animal altogether. And the only realistic way to implement this you idea of "better-C" (which is right by itself) is to separate mc into a core and peripheral parts. Which again returns us to a scripting language issue and/or plug-in issue. >But in fact, the code is screaming for a language with OOP support. A lot >of incorrect interdependencies would have been avoided in the compiler was >enforcing some rules. It's especially important for collaborative >projects. > C++ would probably harm as much as it might help. This is like in a quote from 12 chairs "all the money were eaten by the 'apparatus' (bureaucracy)" (Note for non-Russian readers: "12 chairs" is a famous Russian satirical novel about building socialism in the USSR; not connected in any way with open source/free software movement. The quote belongs to the leading character of the novel Ostap Bender, who wants to became millionaire by expropriating money from other millionairies, who in his opinion got thier money in a wrong, criminal way; again no connection to open source) . >But on the other hand we have Gtk, which is pure C and sustainable. >Maybe it's because Gtk developers avoided feature bloat from the beginning >and cared about code quality. But it's a library - you are guaranteed to >have many programmers using it. GNU Midnight Commander is for end users, >even if they happen to be e.g. Perl programmers. Besides, Gtk is used in >GUI. > >I know programmers that only work in GUI. There was the punchcard >generation, the command line generation, the text UI generation (TUI), and >now we have the GUI generation of programmers. GNU Midnight Commander >serves only the text UI generation of users, and so it's not appealing to >the young users and programmers. It's a niche project. > IMHO not true. Good young programmers know and use command line, sometimes even better then the "old guard". For example the productivity of using mc by skilled admin is such that people with pure GUI skills cannot compete. And as sysadmins is a mass speciality, in no way mc is a niche project and it's *very* appeling to young sysadmins and programmers. Some of my students became expert users of mc or FAR in year or so. The second consideration is that it might represent a new generation of command line interface for bash (or other unix shell) and one can think about mc as a bash extention. Bash is not going away any time soon no matter what interface you prefer. That's why I consider your idea of convering mc.ext and user.menu into a libraries of bash scripts to be a very good idea. >There are 3 large free office suites in development, so the programmers >resources are not scarce. Those who started with Microsoft Word are young >and have enough time. Those who started with Norton Commander have >serious jobs and in many cases families. We are endangered species - the >text UI programmers with enough time for free software that one won't put >on resume like Linux kernel, Apache or cryptography. But let's not >generalize. > > You might be overestimating Open Office stuff. It's all Sun's money. I think that open source has more chances on the command line level were things are simpler and programs can be smaller. IMHO the best chances to compete on GUI level is to adopt a scripting language with the TK or QT or similar library, and that's not an easy game from the point of view of speed. But for problems with low-level compiled language approach in GUI applications just look at Gnome. All this "attempt to catch and then leave behind Microsoft" is IMHO partially a temporary aberration of the overenthusiastic crowd (or if you are in IPO game, a new "make money fast" game) that volunteer developers might pay with their health, family life, etc. As the complexity grows, the advantage of proprietary development grows too and IMHO Microsoft or IBM or Sun or other big software company will always have an upper hand in Office-style applications just because they can mobilize far bigger resources and to impose stricter discipline, that is absolutely necessary in such a tremendous task. I am convinced that simplicity is the only advantage of open source and thus the command line applications deserve a prominent place among open source tools. This advantage will never go away. >>That's why making this decision and taking some steps now, when the mc >>development is clearly revitalized because of your efforts is, in my >>opinion, so important. >> >> >OK, I'm afraid I cannot spend any more time on the discussion unless you show me something more specific. > > Agreed. Thank you for the discussing those issues with me. Good luck ! -- Regards, Dr. Nikolai Bezroukov From proski at gnu.org Tue Nov 11 08:44:01 2003 From: proski at gnu.org (Pavel Roskin) Date: Tue, 11 Nov 2003 03:44:01 -0500 (EST) Subject: Your mc efforts is a great job !!! [Warning]: Long In-Reply-To: <3FB06186.2090600@optonline.net> References: <3F9C904F.3000601@optonline.net> <3F9DC7A1.7010206@optonline.net> <3FA0757D.5030303@optonline.net> <3FB06186.2090600@optonline.net> Message-ID: On Mon, 10 Nov 2003, Nikolai Bezroukov wrote: > I expressed algitimate (I suppose) opinion that mcserv can be a perfect > "fileserver+shell server" conbination. You already voiced your opinion > before that mcserv is redundant and now reiterated your points again. > I disagree, but I suppose that understood you correctly. And please do > not overuse this hammer "show me the code" ;-). [snip] OK, I just was tired of all this discussion. I know that it won't happen because I've seen the code and I know that sftp support would be much more welcome than making mcfs effective. > Idiot admin with ssh will always have a less secure system that a > competent admin with telnet and ftp and my point is that mc is for > intelligent admins ;-) > > In no way encryption on the application level like in ssh is panacea. > On the transport level its another story (Ipsec). FYI Open SSH 1 was one > of the major sources of "real" break-ins for ISPs. Do not know stats > for 'real' breakins for SSH2 but the latest CERT advisories (CA-2002-36. > etc) does not encorage blind trust and suggest that there still risks > due to the complexity of the codebase. I fully agree with this. I just wanted to say that systems that provide security (or let's say do their part) are more likely to be popular in the real world, where IPsec is not used universally. There is no way a non-secure protocol can replace a secure one in the current climate. If ssh and sftp lack something, it will be easier to change them than to create an alternative without security. > >> > I was confused by "VFS" meaning two different things on adjacent > >> > lines. I still don't know what NC5 XTree VFS is. I have never used NC5. > >> > >>That's how I call "flat file VFS". As a PhD I have the responsibility to > >>obscure things by inventing new terms ;-). See also > >>http://www.softpanorama.org/OFM/Ofm_00.shtml. The book discuses several > >>implementations including NC5. > > > >Actually, this should be implemented separately from VFS, as a higher > >level. It's representations of the tree on the panels, not > >representations of something as a tree. > > > You might be wrong, as semantically this is yet another VFS, not that > different from tar VFS or gzip VFS. Only if VFS classes (such as tarfs) were allowed to choose whether to report full filenames in one directory or not. I prefer to have separate layers. There is no reason for the user (i.e. somebody without knowledge of the tar format) to expect different behavior from the normal filesystem, where the files are shown in a tree. Conversely, if the user prefers the flat representation, it should be used regardless of the origin of the file entries. There is nothing virtual in a different representation of the same tree. Anyway, it's an academic question and I don't really care. > >>Two things are now more or less clear: > >> > >> - mc is in the stabilization phase and it's level of maturity is > >> reasonably high, > >> > >> > > > >This doesn't apply to VFS, although I hope to fix it. Support for > >background operations is a worse problem - it's useful, but I cannot be > >implemented correctly without major changes. > > > >I would say the code is in the "active stabilization" mode. Sometimes the > >only way to fix the code is to change it until it's clear what it does. > >I'm not kidding, unfortunately. > > > > > That's a common situation not limited to mc. You might benefit from > Doxygen I actually tried it already. I believe doesn't address problems with the current code, but it may be useful in the future. The problems with the existing code are different. I'm not concerned where functions are called. I can always find it. Most often the problems are of different kind: 1) Code duplication. Examples - two parallel dialog stacks in dlg.c and dialog.c (killed recently). Similar but slightly different sequences for Ctrl-O and Enter on the command line (still needs work). A lot of duplicate code in getid() methods in VFS classes. 2) Unused or useless code. That's very mc specific because of its history. Mostly removed. Example - file caching for tarfs and cpiofs. 3) Code that has never been finished, without documentation what it should do. Sometimes the code is very elaborate, but there is no one to understand an finish it. Sometimes it's OK to remove (PC port), sometimes not (directory tree). Sometimes the code mostly works, but fails in complex situations (VFS garbage collection). 4) Saving on little details while losing on the average. Example - retrieving 8k of each file on VFS when the user clicks on it. That's the minimum required to find the type of the file. In fact, the whole file wad retrieved anyway, in some situations twice. In most cases, the user would still need the whole file and not the first 8k. 5) Misplaced features. Example - hex edit in the viewer. Very hard to do anything about it. 6) Simple hacks covered by layers of code to work around the defects. Example - functions to capture stderr so that popen() can be used and the child's error messages could be shown. 7) Unneeded complexity as a result of initial bad design. Example - background-safe message stub functions with fixed number of arguments. Nobody thought that the arguments could be combined into one string in the child process, rather than passed individually and combined in the parent. 8) Support for weird and obsolete software that is even hard to set up for testing. Example - BSD curses, termnet, SCO console. Mostly removed. > >Please note that we don't currently include S-Lang interpreter, only > >S-Lang screen library. Also, it's possible to compile mc with ncurses > >without S-Lang. I believe ncurses support is worth keeping for now. > > > That complicates things. If the current goal is simplicity, that should > be weighted against the amount of code that need to be maintained when > you support both, and the amount when you need to support just S-lang. I don't think keeping ncurses is very important, although it may be useful for rare OSes and terminals. It's not hard to maintain ncurses support. It may be harder to fix or work around S-Lang limitations if the mc users are forced to use it and start complaining. One reason why ncurses support is important is UTF-8 support. S-Lang is patched for UTF-8 by distributors, ncurses supports it natively. We need UTF-8 support. It may happen that it will be easier to start with ncurses. > >I'd like to see how you would handle something like the Open action for > >HTML (search for "html" in mc.ext.in) - that action indeed has grown > >too large. > > > That's a drawback of any scripting approach -- it can be too slow. So be > it. Nothing is perfect and scripting is not a panacea for all > situations. I just wanted to see the code. If it searches for ten browsers in PATH every time, I don't care. If it's slow, we can fix it. But if it's ugly and cannot be easily extended of factorized, then I'd rather use another language. > >>It is true that S-lang has its own warts and limitations, but please > >>understand that is such situation there is no best choice, only the > >>worst choice and this might be inaction. The truth is that even the > >>worst choice (let's say adopting bash ;-) is better than none: > >>scripting language is one of the few available avenues of addressing > >>the feature creep problem . > > > >I really don't care that much about the programming language for the > >scripts as long as it works. > > > >I suggested using bash for mc.ext, but others in this list didn't like > >the idea. I don't remember the reasons, but it should be archived. > > > Actually I was wrong. You idea with bash for mc.ext might actually be > not a bad idea and can be used in mc.menu too. bash is used right now in both files. Each action is a little script. > >The real question is whether you want to make mc.ext and mc.menu single > >programs or not. If they are single programs, then the choice of the > >language doesn't matter - mc will be communicating with a program. > > > IMHO they are not monolitic scripts. I suspect that they are closer to > script libraries, similar to startup scripts, but this does not > invalidate your idea. For example you can represent shortcuts as soft > link names for the script. Variables exposed by mc can be just be > converted into environment variables like MC_ALTPATH for %D, or MC_FILE > for %f, etc. That might help to solve problem with non-working > substitution in quick cd command. The question is what is the return on > the investment in the simplification of code, as better is the enemy of > good. Substitution of variables is done by mc. That alone doesn't make it a separate language. We could use environment variables and pipes codes to communicate with the script, but I don't see any strong reason for that. Besides, we could lose some features, such as prompts. It's inherently unsafe to use dialog code from more than one process running on the same terminal, so we'll need something similar to the background code to pass messages to the foreground process. Substitution has it's limitations, but they should be easier to overcome. We don't have PATH search and alternate actions in mc (like "use catdoc if present in PATH, else use word2x, else use strings"). Also, we don't have string continuation, so the script is sometimes hard to read, let alone change for a casual user. If we are going to reuse code in the scripts, there should be a "common" section that gets copied to every script. It's also missing. PATH search could go there instead on the C code. My biggest concern is that we allow users to modify the script locally, but we change the default script as well. There is no mechanism for merging user's changes when mc is upgraded. Ideally, only changed parts should survive. But since mc.ext is used as a template, it's saved as ~/.mc/bindings in it's entirety. All there problems are mostly irrelevant to the language. Maybe Perl scripts could be shorter, offer code reuse and simplify PATH search. Maybe S-Lang scripts could be parsed in the parent process. But we still need a protocol for talking to the script and we need a mechanism to separate local customizations from the distributed default settings. > >If you want mc.ext and mc.menu to be sets of scripts that are parsed by > >mc, then I can say that they are already written in bash. > > > I agree about bash. Both looks like a sets of scripts and as I mentioned > above it might make sense to store them in a way similar to startup > scripts. To achive the effect of generation of the menu that is used in > mc you need to have a special option for each script (like status) and > when invoked with this option the script needs to produces a menu entry > if conditions are met, nothing if not. Then you'll have to fork mc.menu into two scripts - one that decides what menu items to show, and the other that does the work when the menu item is selected. Separation conditions from the code won't make it easier to edit the menu. That's why I want to see the code. Maybe you see how to do it nicely, but I don't. > >>The other solution might be exposing API and introducing a FAR-style > >>plug-ins mechanism, although they have their own problems and having a > >>two dozens or more of them installed lead to "overcrowding of the > >>kitchen". But technically this is as simple as introducing plug-in > >>menu in addition to the user menu or option to call a plug-in in the > >>user menu. > > > >This would lock the API at the time when significant reorganization of > >code is underway. > > > True, but my point is that it's easier then adding scripting language > because you can partially reuse ideas that FAR and Total Commander APIs. > And that might suggest some directions of reorganization of the > codebase. I'm not looking for new ideas at this point. I want to fix what is already present. > >There are so many issues here, let me comment on them separately. > > > >Pure C. Yes, I appreciate your insight. Even slightly "impure" C, > >like C with gcc extensions, could be helpful. Linux kernel is an > >example. It's well structured thanks to macros, initializers of > >structures, constructors and explicit exports. > > > Least common denominator prevails in application. Kernel is quite > another story and different animal altogether. And the only realistic > way to implement this you idea of "better-C" (which is right by itself) > is to separate mc into a core and peripheral parts. Which again returns > us to a scripting language issue and/or plug-in issue. Compiler specific tricks are out of question for now. Code separation and improvement is going on. We have less interdependencies with VFS now than in 4.6.0. glib also helps with things like lists. VFS file handles are in a list now. > >But in fact, the code is screaming for a language with OOP support. A > >lot of incorrect interdependencies would have been avoided in the > >compiler was enforcing some rules. It's especially important for > >collaborative projects. > > > C++ would probably harm as much as it might help. This is like in a > quote from 12 chairs "all the money were eaten by the 'apparatus' I don't know. I believe many bad hacks we have in the code now would not have appeared if the project was using C++. Our init_* and done_* functions would become constructors, and it would be harder to put irrelevant code there when it belongs elsewhere. The scary vfs_add_noncurrent_stamps() would become VfsGcList::Add with the timeout argument, as opposed to vfs_add_current_stamps(), which would also be VfsGcList::Add, but without the timeout argument. Event if the only comment in that function were "Dijkstra hates me" it would still be easier to understand what that function does. We are modeling C++ in many places. We have classes and limited inheritance in VFS. We have 4 types of panels with come common treats that could have been subclasses of a single parent, that would be a subclass of Widget. The only free software project using C++ in which I participated was IceWM. It's not bug-free, but it's easier to understand. The code I wanted to fix could be found in minutes. That bug turned out a feature that couldn't be turned off. Not the worst kind of bugs. I'm not aware of any project that suffered because it was using C++ instead of C. I don't think C++ could be an obstacle with modern GCC and fast computers. Situation could have been different in 1995, when mc started. Of course, if I was rewriting mc from scratch, I would go with something more radical, like Ruby or Lisp. But it's completely unrealistic to convert the existing code to something so radically different. > >I know programmers that only work in GUI. There was the punchcard > >generation, the command line generation, the text UI generation (TUI), and > >now we have the GUI generation of programmers. GNU Midnight Commander > >serves only the text UI generation of users, and so it's not appealing to > >the young users and programmers. It's a niche project. > > > IMHO not true. Good young programmers know and use command line, > sometimes even better then the "old guard". For example the productivity > of using mc by skilled admin is such that people with pure GUI skills > cannot compete. And as sysadmins is a mass speciality, in no way mc is a > niche project and it's *very* appealing to young sysadmins and > programmers. Some of my students became expert users of mc or FAR in > year or so. Good to know. That's very different from my experience. > The second consideration is that it might represent a new generation of > command line interface for bash (or other unix shell) and one can think > about mc as a bash extention. Bash is not going away any time soon no > matter what interface you prefer. That's why I consider your idea of > convering mc.ext and user.menu into a libraries of bash scripts to be a > very good idea. It's your idea. I didn't say that. I actually need to think about it. If we keep separate scripts, it would partly solve the upgrade problem I mentioned before. > >There are 3 large free office suites in development, so the programmers > >resources are not scarce. Those who started with Microsoft Word are > >young and have enough time. Those who started with Norton Commander > >have serious jobs and in many cases families. We are endangered > >species - the text UI programmers with enough time for free software > >that one won't put on resume like Linux kernel, Apache or cryptography. > >But let's not generalize. > > > You might be overestimating Open Office stuff. It's all Sun's money. Maybe, I'm judging by the opinions of people who don't participate in its development. > I think that open source has more chances on the command line level were > things are simpler and programs can be smaller. IMHO the best chances > to compete on GUI level is to adopt a scripting language with the TK or > QT or similar library, and that's not an easy game from the point of > view of speed. I think it's better to have a choice. Sometimes speed is essential. > But for problems with low-level compiled language approach in GUI > applications just look at Gnome. > > All this "attempt to catch and then leave behind Microsoft" is IMHO > partially a temporary aberration of the overenthusiastic crowd (or if > you are in IPO game, a new "make money fast" game) that volunteer > developers might pay with their health, family life, etc. I cannot judge the code of GNOME. Maybe some code is of low quality. I don't know. What was left in the mc codebase was pretty bad, but it were the first steps, I cannot judge the project by them. I know that gtk is quite good inside, even if it's hard to bootstrap. GIMP 1.3.x is excellent, but I'm just a user, and not a very demanding one. > As the complexity grows, the advantage of proprietary development grows > too and IMHO Microsoft or IBM or Sun or other big software company will > always have an upper hand in Office-style applications just because they > can mobilize far bigger resources and to impose stricter discipline, > that is absolutely necessary in such a tremendous task. > > I am convinced that simplicity is the only advantage of open source and > thus the command line applications deserve a prominent place among open > source tools. This advantage will never go away. I disagree. Simplicity is a plus, but not a single one. There are other advantages strongly correlated with openness of the development process and motivation of the developers. It's possible to beat big guys by making sound design choices and by not being bound by backward compatibility, third-party code and employees with low skills and motivations that are hard to replace. Although this is not about free software, "Beating the Averages" by Paul Graham demonstrates all my points: http://www.paulgraham.com/avg.html > >OK, I'm afraid I cannot spend any more time on the discussion unless > >you show me something more specific. > > > Agreed. Thank you for the discussing those issues with me. Good luck ! I hope my answers have been useful for you. -- Regards, Pavel Roskin From dave at jikos.cz Thu Nov 13 17:32:23 2003 From: dave at jikos.cz (David Sterba) Date: Thu, 13 Nov 2003 18:32:23 +0100 (CET) Subject: BUG: entering vfs archives broken (.tar..gz) Message-ID: Hi, [todyays CVS version] Press enter on an archive (eg. file.tar.gz). Files from the archive are not listed. In the list of active virtual FS is correctly shown the entry e.g. "/home/dave/file.tar.gz#utar/". Dave From proski at gnu.org Thu Nov 13 17:47:32 2003 From: proski at gnu.org (Pavel Roskin) Date: Thu, 13 Nov 2003 12:47:32 -0500 (EST) Subject: BUG: entering vfs archives broken (.tar..gz) In-Reply-To: References: Message-ID: On Thu, 13 Nov 2003, David Sterba wrote: > Hi, > > [todays CVS version] > > Press enter on an archive (eg. file.tar.gz). Files from the archive are > not listed. In the list of active virtual FS is correctly shown the > entry e.g. "/home/dave/file.tar.gz#utar/". Confirmed. Actually, VFS seems to be completely broken, but it worked yesterday. I'll try to fix it as soon as possible. -- Regards, Pavel Roskin From aliakc at web.de Thu Nov 13 18:50:08 2003 From: aliakc at web.de (Ali Akcaagac) Date: Thu, 13 Nov 2003 19:50:08 +0100 Subject: A proposal for Midnight Commander Message-ID: <1068749408.7535.20.camel@localhost> Hi, I know this may be a delicate point to discuss but I would like to propose that MC becomes independant to glib again. Reasons for this: Some years ago where Midnight Commander became some sort of Console and Desktop Filemanager (for GNOME) it made sense using libraries that came with the Desktop in this case it was glib. A lot of wrappers for simple types and a bunch of new functions like linked lists, hash tables and stuff usually not found inside glibc or other standard c libraries used on other plattforms. A few weeks/months we saw some people announcing MC forks such as Arpi did with his Midnight Commander fork and someone else who continued with 4.1.40 (which is glib free). I have been thinking about this for quite some time and indeed it does make sense. Look MC is an all purpose filemanager (if not the best around for all sorts of open source architectures). People load it up, do their job and quit it again. But have we ever thought about rescue systems ? such like bootable rescue CD's or other situations ?. Let's look at rescue CD's for a moment. The aim for such a CD is to keep things tiny (small sized, less library dependencies if possible statically linked). Midnight Commander in it's current state is maturing and using a lot of libraries these days (libglib and libgmodule) for example, this means we need to provide these libraries as well. Not to mention what we all need to get MC compiled. Say if we create a rescue system and want to use uClibc we then try to depend on as less stuff as possible. Currently we need pkg-config installed to compile glib and if we build a new system in a chroot then we need to compile quite some stuff before being able to use Midnight Commander, specially in critical situations when we really urgently need a filemanager. Say on my system (only to give a practical example). I have my GTK/GNOME installation kept in /usr/local this also means my 'mc' which I checkout once a week or something. When I compile GNOME from scratch (this then also includes all the other stuff, pkgconfig, startup-notification, libxml, libxslt, audiofile etc. before it comes to glib it needs to compile a few other things first. During that time I have no mc available or can't use it due the fact that my /usr/local dir is moved to /usr/local.bak a new /usr/local is being created where all the new GNOME stuff is being installed ****(well let's not get deeper into why it's backup'ed, simply take the situation where it's not able to access mc anymore which happens for many people quite often - assuming even you). **** I think there are quite some people here who simply trapped themselves into such a situation every now and then and wished that mc would not depend on glib for example and only depend on the core libraries such as glibc for example. I think we should talk about this for a while and imo it does make a lot of sense. If we simply go and accept glib as some defacto standard library met on every system then we soon gonna accept every library to be standard and make mc become more complicated (maybe not now but maybe one day). http://mc.linuxinside.com/ http://www1.mplayerhq.hu/~arpi/amc/ provided two links of recent mc forks. From miguel at ximian.com Thu Nov 13 19:58:46 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 13 Nov 2003 14:58:46 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <1068749408.7535.20.camel@localhost> References: <1068749408.7535.20.camel@localhost> Message-ID: <1068753526.4926.188.camel@erandi.boston.ximian.com> Hello, > Say on my system (only to give a practical example). I have my GTK/GNOME > installation kept in /usr/local this also means my 'mc' which I checkout > once a week or something. When I compile GNOME from scratch (this then > also includes all the other stuff, pkgconfig, startup-notification, > libxml, libxslt, audiofile etc. before it comes to glib it needs to > compile a few other things first. During that time I have no mc > available or can't use it due the fact that my /usr/local dir is moved > to /usr/local.bak a new /usr/local is being created where all the new > GNOME stuff is being installed Maybe you should consider building mc with glib statically linked. Not rocket science dude. Miguel From mikey at wirelabs.lublin.pl Thu Nov 13 19:02:03 2003 From: mikey at wirelabs.lublin.pl (Michal Szwaczko) Date: Thu, 13 Nov 2003 20:02:03 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068749408.7535.20.camel@localhost> References: <1068749408.7535.20.camel@localhost> Message-ID: <20031113190203.GA31760@matrix> On Thu, Nov 13, 2003 at 07:50:08PM +0100, Ali Akcaagac wrote: > I think there are quite some people here who simply trapped themselves > into such a situation every now and then and wished that mc would not > depend on glib for example and only depend on the core libraries such as > glibc for example. I think we should talk about this for a while and imo > it does make a lot of sense. If we simply go and accept glib as some > defacto standard library met on every system then we soon gonna accept > every library to be standard and make mc become more complicated (maybe > not now but maybe one day). Glib is very usable and it would be a pain in the ass to clean up the code now of all 'glibisms', I reckon. Your point of scarce resource systems does not appeal to me since the rescue system's idea is not full-blown linux system with all the goodies you can have. Besides - glib is quite small, it's not the glib use that makes mc quite resource-demanding. It's a bunch of old, unused code that does. That's my 2c Cheers -- [ Micha? 'Mikey' Szwaczko | GPG Key#:0x653CBD53 ] [ Developer/Troubleshooter | GNU Generation Now! ] [ Generating signature .... Segmentation fault ] From proski at gnu.org Thu Nov 13 19:02:10 2003 From: proski at gnu.org (Pavel Roskin) Date: Thu, 13 Nov 2003 14:02:10 -0500 (EST) Subject: BUG: entering vfs archives broken (.tar..gz) In-Reply-To: References: Message-ID: On Thu, 13 Nov 2003, Pavel Roskin wrote: > On Thu, 13 Nov 2003, David Sterba wrote: > > > Hi, > > > > [todays CVS version] > > > > Press enter on an archive (eg. file.tar.gz). Files from the archive are > > not listed. In the list of active virtual FS is correctly shown the > > entry e.g. "/home/dave/file.tar.gz#utar/". > > Confirmed. Actually, VFS seems to be completely broken, but it worked > yesterday. I'll try to fix it as soon as possible. The reason is that I was removed protection in mc_chdir() against chdir() functions that modify the argument. They still do it despite having const in the declaration. My reliance exclusively on gcc warnings was wrong. In particular, vfs_split modifies the first argument. I'm working on it now and I hope to commit fix within the next 12 hours. -- Regards, Pavel Roskin From aliakc at web.de Thu Nov 13 19:09:06 2003 From: aliakc at web.de (Ali Akcaagac) Date: Thu, 13 Nov 2003 20:09:06 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068749408.7535.20.camel@localhost> References: <1068749408.7535.20.camel@localhost> Message-ID: <1068750546.7607.3.camel@localhost> On Thu, 2003-11-13 at 19:50, Ali Akcaagac wrote: > I know this may be a delicate point to discuss but I would like to > propose that MC becomes independant to glib again. I have peeked quickly into the source and the majority of calls are concentrated to ~5 functions only, g_malloc, g_free (basically wrappers), g_strdup and some GTree stufff. Once the g_malloc and g_free stuff is replaced with their standard C library equivalents then aprox ~80% (if not more) of the work is done. From aliakc at web.de Thu Nov 13 19:16:02 2003 From: aliakc at web.de (Ali Akcaagac) Date: Thu, 13 Nov 2003 20:16:02 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068753526.4926.188.camel@erandi.boston.ximian.com> References: <1068749408.7535.20.camel@localhost> <1068753526.4926.188.camel@erandi.boston.ximian.com> Message-ID: <1068750961.7607.9.camel@localhost> On Thu, 2003-11-13 at 20:58, Miguel de Icaza wrote: > Maybe you should consider building mc with glib statically linked. Well thats not the point. Compiling something statically does indeed work but reducing dependency is the better way imo. Look there are quite some functions marked DEPRECATED in glib already this includes functions such as g_tree_traverse for the upcoming glib2.4 (only one example). This means on the long run you need to replace these functions inside MC with suitable new functioncalls. Instead going this way, it would be better to make MC independant to glib again and have it kept as standalone app. I would really consider working on the core MC rather than going for yet another fork of it due to disagreement. Which is quite commonly the reason for forks to show up. I mean we are only changing a bunch of g_malloc's, g_free's here and kill some deprecated tree functions with alternative calls. It's no visible change or drastic change that influences the normal workflow here. From proski at gnu.org Thu Nov 13 20:19:13 2003 From: proski at gnu.org (Pavel Roskin) Date: Thu, 13 Nov 2003 15:19:13 -0500 (EST) Subject: A proposal for Midnight Commander In-Reply-To: <1068749408.7535.20.camel@localhost> References: <1068749408.7535.20.camel@localhost> Message-ID: On Thu, 13 Nov 2003, Ali Akcaagac wrote: > I know this may be a delicate point to discuss but I would like to > propose that MC becomes independent to glib again. In fact, the more I work on mc the more I think that we should be using high level constructs rather than plain C. Fixed buffers are a problem for security and correctness, so we should use dynamic memory allocation. If we allocate data, we should deallocate it. Many functions return in more than one place. C lacks anything like "finalize" or garbage collection, so we have growing code in the branches that are executed very rarely, so that code doesn't get tested. glib offers some relief. In particular, g_free() includes a test if the pointer is NULL - very useful to avoid extra code. g_malloc() aborts the program if the memory cannot be allocated. Again, it eliminates a lot of code. It also makes sure that mc fails early and in a predictable way if the memory is indeed very low. Lists are also useful, once you know how to use them. Unfortunately, they make it easy to do something wrong. For example, it's easy to write g_slist_delete_link (vfs_openfiles, l); instead of vfs_openfiles = g_slist_delete_link (vfs_openfiles, l); Both would work, but the former would break when the first element is removed. That's an error that doesn't happen often, so chances are that is will be overlooked in simple tests. Still, the lists are convenient to avoid code duplication and some common errors. But it you have a better alternative, I'll switch gladly. I'm seriously considering C++ with its standard libraries, but it's too intrusive and may not happen soon. > Reasons for this: > > Some years ago where Midnight Commander became some sort of Console and > Desktop Filemanager (for GNOME) it made sense using libraries that came > with the Desktop in this case it was glib. A lot of wrappers for simple > types and a bunch of new functions like linked lists, hash tables and > stuff usually not found inside glibc or other standard c libraries used > on other platforms. We actually use a small part of it. But there is more code that could be converted. Lists are used almost everywhere. > A few weeks/months we saw some people announcing MC forks such as Arpi > did with his Midnight Commander fork and someone else who continued with > 4.1.40 (which is glib free). It's more like years, not months. All that happened before 4.6.0 release, as a reaction to the code bloat from the GNOME frontend. > I have been thinking about this for quite some time and indeed it does > make sense. Look MC is an all purpose filemanager (if not the best > around for all sorts of open source architectures). People load it up, > do their job and quit it again. > > But have we ever thought about rescue systems ? such like bootable > rescue CD's or other situations ?. Let's look at rescue CD's for a > moment. The aim for such a CD is to keep things tiny (small sized, less > library dependencies if possible statically linked). Midnight Commander > in it's current state is maturing and using a lot of libraries these > days (libglib and libgmodule) for example, this means we need to provide > these libraries as well. Or listen to Miguel and link them statically. > Not to mention what we all need to get MC compiled. Say if we create a > rescue system and want to use uClibc we then try to depend on as less > stuff as possible. Currently we need pkg-config installed to compile > glib and if we build a new system in a chroot then we need to compile > quite some stuff before being able to use Midnight Commander, specially > in critical situations when we really urgently need a filemanager. No, pkg-config is not required if glib 1.2.x is used. In fact, glib 1.2.x support is primarily kept to make it easier to compile mc in such minimal environment. > Say on my system (only to give a practical example). I have my GTK/GNOME > installation kept in /usr/local this also means my 'mc' which I checkout > once a week or something. When I compile GNOME from scratch (this then > also includes all the other stuff, pkgconfig, startup-notification, > libxml, libxslt, audiofile etc. before it comes to glib it needs to > compile a few other things first. During that time I have no mc > available or can't use it due the fact that my /usr/local dir is moved > to /usr/local.bak a new /usr/local is being created where all the new > GNOME stuff is being installed If you really want to use glib2, there is a script mc_glib2_compile in the CVS repository. I'm not sure whether to distribute it in the tarball. However, this script doesn't try to install glib2, it merely compiles mc against it. Actually, it were you who insisted on adding glib2 support, so I'm surprised that you are complaining now! > I think there are quite some people here who simply trapped themselves > into such a situation every now and then and wished that mc would not > depend on glib for example and only depend on the core libraries such as > glibc for example. I think we should talk about this for a while and imo > it does make a lot of sense. If we simply go and accept glib as some > defacto standard library met on every system then we soon gonna accept > every library to be standard and make mc become more complicated (maybe > not now but maybe one day). OK, maybe I'll move mc_glib1_compile and mc_glib2_compile to the root directory so that users can use it. I don't share your pessimism about other libraries. Actually, gmodule makes it possible to load other libraries dynamically, so they become optional at the run time. And what do you suggests to use instead of glib? In particular what do you suggest to use for lists and dynamic loading of modules? > http://mc.linuxinside.com/ > http://www1.mplayerhq.hu/~arpi/amc/ > > provided two links of recent mc forks. Neither is recent. -- Regards, Pavel Roskin From aliakc at web.de Thu Nov 13 20:55:24 2003 From: aliakc at web.de (Ali Akcaagac) Date: Thu, 13 Nov 2003 21:55:24 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068749408.7535.20.camel@localhost> Message-ID: <1068756924.8126.30.camel@localhost> On Thu, 2003-11-13 at 21:19, Pavel Roskin wrote: > Actually, it were you who insisted on adding glib2 support, > so I'm surprised that you are complaining now ! Exactly I was the guy who provided the glib2 stuff to you. Well no, you are misunderstanding me here I think. I have no negative intentions about using glib1 or glib2 or something. I use GNOME for quite some years myself now and glib is kinda part of my system. I was only proposing to have it removed in general. > And what do you suggests to use instead of glib ? I suggest going back to plain standard C library. I like you to do this test. Compile MC against the latest glib 2.3.x you get from ftp.gnome.org and add the -DG_DISABLE_DEPRECATED to it and see what happens. Glib1 is a no option on my system and on many other people's system either because the majority for now seem to have switched to GNOME2 or GTK2 already and do not intend to use glib1 anymore - regardless of the fact that it co-exists. The idea itself is wrong. Glib2 as in the new version 2.3.x has some DEPRECATED functions inside that MC makes usage of which pretty soon may be removed. This requires someone to work around and use other functioncalls to make it work again. Standard C library is the solution here. Well I know this makes allocating memory and free'ing memory not become easier but it works. It works in thousands of open source console applications. MC is the only app so far that uses glib for this. It's a mixture of using glib calls and glibc calls and soon you hit on DEPRECATED functions anyways. I can't exactly speak for other architectures such as SUN, AIX, Darwin, BSD etc. but I somehow do have the feeling that using glib for this is kinda wrong. Removing GNOME dependency from MC was a major big and very cool idea from you and I fullheartly supported this decision the time back when you removed that junk. It would now be a good sign to remove the last bits of it too. Thus I propose to make it glib free. The first steps would be to slowly replace the g_malloc, g_free, g_new0, g_strdup, g_strconcat Calls with native C ones. Once this has been done half of the entire work is done. I have been playing with the code for some mins and replaced (only as a test) the g_malloc calls with native C ones and the g_free with free (without any function test, only the grep). I wanted to check how much of the easier things can be done and what remains afterwards. It may look a lot at the first moment but it's not that much. Once this has been done we can look whether some 'really important functions' can be simply cut and pasted from glib into MC itself and then replaced one day. Then the general cleanups here and there. I know some of the users here are not thrilled by the idea, others may definately be (and the MP fork isn't that old either its started in April this year and based on MC 4.1.40 which probably was the last glibfree version existing) e.g. he started with an older version because he belived it was the better thing to do. This itself was based on ARPI's fork which he made earlier. I think that these people and I share similar ideas here and I do belive that a lot of people outside (not subscirbed here) may belive the same here. A console filemanager should be usable in even the worst ever scenarios and not depend on so much libs. Statically compiling - ok is an argument, but requires that glib exists on the system. Some people would argument that this may be a stupid thing but on the otherhand it does make sense, we don't want to stagnate here because we throw our pro's and con's at each of us. If we go that way then we make no real progress, while I do belive that it should be clear to everyone that having it not depend on many libs result in an application that may run in even worst case scenarios. Many people are trapped with prebuild distributions and installations, how many of the people using open source these days really know howto deal with the system. They all live in the best scenario e.g. when my system crashes I then go and re-install it from debian or red hat, but what about critical situations, e.g. your harddisk crashed, or some other thing happened which made your system inaccessible and you urgently need to rescue some stuff, you boot some rescue CD-Rom, you enter MC and it throws out libglib-2.0.so libgobject-2.0.so required.. Where to get these libraries quickly.. in the strange situation you may be trapped in ? You can't access the internet, you can't call up a friend, you have no other CD laying around infront of you and you didn't made recent backups. You then need to figure out another way to do the stuff. Doesn't this ring a bell or something ? I can't imagine that there isn't one on here that wasn't in such a situation.. and I can bet that there is the one or other who may have said 'Shit. I wished it wouldn't depend on glib.' I would really like to go with the flow here. I know you are doing a great work on Midnight Commander and the majority of people are usually 'I go with the real thing' person and I do see the benefits that we work together to figure a good solution for this and I am not a friend of forks myself. 20 forks, all halfassed, half supported, left unmaintained after a while. There is no benefits. I mean we are not going to change visible stuff to the user, or workflow relevant parts. We are only changing something in the bottom framework. It makes you happy, it makes me happy, it makes others happy and finally an MC with less dependencies. I even think that the uClibc people gonna thank you here because I do not belive that glib compiles against uClibc here. The embedded guys would probably be thankful using a most recent, active and alive project such as mc 4.6.0 on their embedded plattforms or rescue systems. I hope you see my point here. greetings. From proski at gnu.org Thu Nov 13 22:56:50 2003 From: proski at gnu.org (Pavel Roskin) Date: Thu, 13 Nov 2003 17:56:50 -0500 (EST) Subject: A proposal for Midnight Commander In-Reply-To: <1068756924.8126.30.camel@localhost> References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> Message-ID: On Thu, 13 Nov 2003, Ali Akcaagac wrote: > On Thu, 2003-11-13 at 21:19, Pavel Roskin wrote: > > Actually, it were you who insisted on adding glib2 support, > > so I'm surprised that you are complaining now ! > > Exactly I was the guy who provided the glib2 stuff to you. Well no, you > are misunderstanding me here I think. I have no negative intentions > about using glib1 or glib2 or something. I use GNOME for quite some > years myself now and glib is kinda part of my system. I was only > proposing to have it removed in general. Fair enough. > > And what do you suggests to use instead of glib ? > > I suggest going back to plain standard C library. I like you to do this > test. Compile MC against the latest glib 2.3.x you get from > ftp.gnome.org and add the -DG_DISABLE_DEPRECATED to it and see what > happens. I cannot do it right now, but I'm well aware that some functions may become obsolete. The approach I intend to use is to track the latest released version. Once a function is removed (not just deprecated), we should upgrade to the new equivalent. If the new function is missing in older versions of glib, it should be added to src/glibcompat.c (see CVS). > Glib1 is a no option on my system and on many other people's system > either because the majority for now seem to have switched to GNOME2 or > GTK2 already and do not intend to use glib1 anymore - regardless of the > fact that it co-exists. The idea itself is wrong. I also prefer to use current versions of all software. On the other hand, Glib doesn't promise stability of API in the long term. I realize that it's a problem, but I don't consider it a major problem, based on my experience so far. > Glib2 as in the new version 2.3.x has some DEPRECATED functions inside > that MC makes usage of which pretty soon may be removed. This requires > someone to work around and use other function calls to make it work > again. Well, I think it can be done. > Standard C library is the solution here. Well I know this makes > allocating memory and free'ing memory not become easier but it works. It > works in thousands of open source console applications. MC is the only > app so far that uses glib for this. It's a mixture of using glib calls > and glibc calls and soon you hit on DEPRECATED functions anyways. Many large projects written in C use their own utility libraries. Samba uses ubiqx. Apache uses APR (Apache Portable Runtime). gcc uses libiberty. Other large projects use higher-level languages and their libraries. Still, Mozilla uses NSPR. > I can't exactly speak for other architectures such as SUN, AIX, Darwin, > BSD etc. but I somehow do have the feeling that using glib for this is > kinda wrong. Removing GNOME dependency from MC was a major big and very > cool idea from you and I fullheartly supported this decision the time > back when you removed that junk. It would now be a good sign to remove > the last bits of it too. Thus I propose to make it glib free. I understand your feelings, but I'd rather go with a utility library maintained by someone else, ideally with standard stable API. > The first steps would be to slowly replace the > > g_malloc, g_free, g_new0, g_strdup, g_strconcat > > Calls with native C ones. Once this has been done half of the entire > work is done. I have been playing with the code for some mins and > replaced (only as a test) the g_malloc calls with native C ones and the > g_free with free (without any function test, only the grep). I wanted to > check how much of the easier things can be done and what remains > afterwards. > > It may look a lot at the first moment but it's not that much. Once this > has been done we can look whether some 'really important functions' can > be simply cut and pasted from glib into MC itself and then replaced one > day. Then the general cleanups here and there. I understand that it can be done. We should retain wrappers because the libc functions may not be as good as the ones from glib on some platforms. > I know some of the users here are not thrilled by the idea, others may > definitely be (and the MP fork isn't that old either its started in > April this year and based on MC 4.1.40 which probably was the last > glibfree version existing) e.g. he started with an older version because > he belived it was the better thing to do. This itself was based on > ARPI's fork which he made earlier. I think that these people and I share > similar ideas here and I do belive that a lot of people outside (not > subscirbed here) may belive the same here. A console filemanager should > be usable in even the worst ever scenarios and not depend on so much > libs. glib is a single hard compile time dependency. There are some hard runtime dependencies (gpm, ext2fs), but their number will be reduced if gmodule (or perhaps libltdl if we get rid of glib) is used to load them. > Statically compiling - ok is an argument, but requires that glib exists > on the system. Some people would argument that this may be a stupid > thing but on the otherhand it does make sense, we don't want to stagnate > here because we throw our pro's and con's at each of us. If we go that > way then we make no real progress, while I do belive that it should be > clear to everyone that having it not depend on many libs result in an > application that may run in even worst case scenarios. Many people are > trapped with prebuild distributions and installations, how many of the > people using open source these days really know howto deal with the > system. They all live in the best scenario e.g. when my system crashes I > then go and re-install it from debian or red hat, but what about > critical situations, e.g. your harddisk crashed, or some other thing > happened which made your system inaccessible and you urgently need to > rescue some stuff, you boot some rescue CD-Rom, you enter MC and it > throws out libglib-2.0.so libgobject-2.0.so required.. Where to get > these libraries quickly.. in the strange situation you may be trapped in > ? You can't access the internet, you can't call up a friend, you have no > other CD laying around infront of you and you didn't made recent > backups. You then need to figure out another way to do the stuff. > Doesn't this ring a bell or something ? I can't imagine that there isn't > one on here that wasn't in such a situation.. and I can bet that there > is the one or other who may have said 'Shit. I wished it wouldn't depend > on glib.' I'm not trying to convince you that the glib dependency is good. I'm just trying to find the best solution, just like you. Note that I'm only challenging bad or weak arguments of yours. If you have a bad crash, you are as likely to lose libc as glib. You must have knoppix around anyway. It's perfectly OK for programs to depend on many libraries. There is nothing inherently wrong with it. Libraries allow code reuse. They allow separating of efforts between developers. They don't make the software less stable if certain versioning rules are followed. I accept your argument that specifically GNU Midnight Commander should not have too many dependencies because it can be used as a recovery tool. It's just that the weight of this argument is not as significant as it used to be. The most widespread media for recovery tools is now a CD, not a floppy disk. On the other hand of the equation we have security, usability and maintainability of GNU Midnight Commander under normal (i.e. not emergency) conditions. And they do profit from having a portable layer between the code and libc. Actually, I would be just as much concerned about gpm because it depends on ncurses. That's two libraries. Remove any of them, and mc won't work. > I would really like to go with the flow here. I know you are doing a > great work on Midnight Commander and the majority of people are usually > 'I go with the real thing' person and I do see the benefits that we work > together to figure a good solution for this and I am not a friend of > forks myself. 20 forks, all halfassed, half supported, left unmaintained > after a while. There is no benefits. As I said, I don't think the reason is glib. The reason was GNOME. If the forks still exist, the reason is quality. It's easy to fix many problems, but it's not easy to fix the underlying problem, and that's what I'm trying to do. People who care about clock in the upper left corner more than about use of uninitialized variables will keep their forks until the hard stuff is fixed. I'm not saying I'm doing enough. Maybe I'm doing 20% of what should be done. But I know that if we reduce requirements on the quality, the code will become mess once again. Neither am I saying that my handling of the situation is correct. I'm just trying to do what I can. Also, there was a misconception that glib depends on X11. We cannot cater to misconceptions - we are not politicians. > I mean we are not going to change visible stuff to the user, or workflow > relevant parts. We are only changing something in the bottom framework. > It makes you happy, it makes me happy, it makes others happy and finally > an MC with less dependencies. I even think that the uClibc people gonna > thank you here because I do not belive that glib compiles against uClibc > here. I remember I did it in the past. If you have any problems, please report them to glib and uClibc developers. > The embedded guys would probably be thankful using a most recent, active > and alive project such as mc 4.6.0 on their embedded platforms or > rescue systems. I agree. > I hope you see my point here. Absolutely. -- Regards, Pavel Roskin From w.geuens at pandora.be Thu Nov 13 07:20:01 2003 From: w.geuens at pandora.be (Werner Geuens) Date: Thu, 13 Nov 2003 08:20:01 +0100 Subject: FTP question Message-ID: <200311130820.01275.w.geuens@pandora.be> This might turn out not to be a bug report, but rather a configuration/feature question: When using MC to uploading files to my webspace on the provider's server, I get an error after each file. The bottom line is that MC wants to match the rights on the provider-side to those on my machine. The error goes like this: "Cannot chmod target file ....... operation not permitted (1). And I ask for "skip", to continue. Not nice when uploading lots of small files, I have to stay at the keyboard. I obviously can't change the rights on the provider's side, and will probably never be allowed to do so. Can MC be told not to try and set the rights, for ftp at least ? My details: Running SuSE 8.2 Pro distro, and "mc -V" reports the following: GNU Midnight Commander 4.6.0 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 -- Werner Geuens mailto:w.geuens at pandora.be I don't suffer from insanity. I enjoy every moment of it. From proski at gnu.org Fri Nov 14 09:03:52 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 14 Nov 2003 04:03:52 -0500 (EST) Subject: BUG: entering vfs archives broken (.tar..gz) In-Reply-To: References: Message-ID: On Thu, 13 Nov 2003, Pavel Roskin wrote: > On Thu, 13 Nov 2003, David Sterba wrote: > > > Hi, > > > > [todays CVS version] > > > > Press enter on an archive (eg. file.tar.gz). Files from the archive are > > not listed. In the list of active virtual FS is correctly shown the > > entry e.g. "/home/dave/file.tar.gz#utar/". > > Confirmed. Actually, VFS seems to be completely broken, but it worked > yesterday. I'll try to fix it as soon as possible. Fixed in CVS and the current snapshot. -- Regards, Pavel Roskin From zlatko at gmx.at Fri Nov 14 13:34:23 2003 From: zlatko at gmx.at (Thomas Zajic) Date: Fri, 14 Nov 2003 14:34:23 +0100 Subject: FTP question In-Reply-To: <200311130820.01275.w.geuens@pandora.be> References: <200311130820.01275.w.geuens@pandora.be> Message-ID: <20031114133423.GB25095@sphere.fdns.net> * Werner Geuens , 13/11/2003, 08:20 > This might turn out not to be a bug report, > but rather a configuration/feature question: > > When using MC to uploading files to my webspace on the provider's server, I > get an error after each file. The bottom line is that MC wants to match the > rights on the provider-side to those on my machine. > > The error goes like this: > "Cannot chmod target file ....... operation not permitted (1). > [...] Try switching off "[ ] preserve Attributes" before copying (in the dialog that pops up right after you hit F5). Works fine here to prevent the same problem when copying files to SMB shares. HTH, Thomas -- =-------------------------------------------------------------------------= - Thomas "ZlatkO" Zajic Linux-2.4.19 & Mutt-1.4i - - "It is not easy to cut through a human head with a hacksaw." (M. C.) - =-------------------------------------------------------------------------= From andrew at email.zp.ua Fri Nov 14 14:12:41 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 14 Nov 2003 16:12:41 +0200 (EET) Subject: undelfs warnings fix In-Reply-To: Message-ID: <200311141412.hAEECfRI043666@email.zp.ua> > On Thu, 13 Nov 2003, Andrew V. Samoilov wrote: > > > Hello, Pavel! > > > > Small fix for last changes. > > The warnings have been fixed already. I'm not sure about com_err(). See > "man com_err". Maybe it's used to override com_err() from the library. It seems you are right about com_err(). Well, this patch cleans up argument names for com_err() and also fixes program termination if where is no enough memory while scanning deleted entries. As far as I remember there was some problems with g_malloc() & free() mixing, at least on FreeBSD, so I propose to define free as g_free() for glib2+, and use free() to release memory, allocated by malloc()/realloc() for glib 1.2.x. I fix this for undelfs, but view->data case in view.c is more complicated. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: undelfs.c.patch URL: From andrew at email.zp.ua Fri Nov 14 15:37:50 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Fri, 14 Nov 2003 17:37:50 +0200 (EET) Subject: undelfs warnings fix In-Reply-To: <200311141412.hAEECfRI043666@email.zp.ua> Message-ID: <200311141537.hAEFboDf046078@email.zp.ua> > > On Thu, 13 Nov 2003, Andrew V. Samoilov wrote: > > > > > Hello, Pavel! > > > > > > Small fix for last changes. > > > > The warnings have been fixed already. I'm not sure about com_err(). See > > "man com_err". Maybe it's used to override com_err() from the library. > > It seems you are right about com_err(). Well, this patch cleans up argument > names for com_err() and also fixes program termination if where is no enough > memory while scanning deleted entries. > > As far as I remember there was some problems with g_malloc() & free() mixing, > at least on FreeBSD, so I propose to define free as g_free() for glib2+, > and use free() to release memory, allocated by malloc()/realloc() for > glib 1.2.x. I fix this for undelfs, but view->data case in view.c is more > complicated. Previous patch implementation breaks mcfs compilation, and as I understood recently current implementaion of com_err() is wrong and have format string vulnerability. New implementation fixes com_err() and does not define free, sorry about glib and libc memory allocation function mix, but we have it for glib 1.2x. already. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: undelfs.c.patch URL: From aliakc at web.de Fri Nov 14 16:29:36 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 14 Nov 2003 17:29:36 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: Message-ID: <1068827376.12105.28.camel@localhost> On Fri, 2003-11-14 at 15:30, Koblinger Egmont wrote: > If you care about dependencies so much, then please let me > share my experiences. I'm not really familiar in glib{,2} > programming, I rather use plain glibc calls. In the mean time, > working on a linux distribution we thought about putting some > nice tools in the initrd that performs the installation. We > have strace and other nice debug tools there. MC would be > nice, too. But we didn't put mc there, and the reason was not > glib. (Actually, glib2 is already there since our installer > uses gtk2, but we'd simply put there glib2 if it wasn't there, > no problem.) > > I think glib2 is now a quite stanadrd piece of software, with > plenty of useful functions. Even if it changes faster than glibc, > I'm sure that there's always a big timeframe when obsoleted > functions are still available, and I'm quite sure that porting mc > to a newer glib2 requires less work than reimplementing all these > nice features of glib2 in pure glibc. Well I think I need to reply a bit more precise here. I'm programming GNOME applications myself for quite some time now. This includes fixing bugs, co-authoring of some stuff and my own projects. http://www.akcaagac.com/index_atlantis.html I for my own have no problems with 'glib'. glib is indeed a nice addon with a lot of powerful functions usually not found in 'glibc' and it guarantees that it works on all plattforms. So far for this. I also share the opinion that re-using code is a wonderful thing. But it only makes sense in large projects such as re-using a framework of standard libraries under GNOME for example. Standard libraries are librsvg, libbonobo, libbonoboui, libgnome, libgnomeui, gnome-vfs and so on. This makes a lot of sense and is the right way to go. You can count on my vote for this whenever someone shows up infront of me and asks whether this is a good thing or not. Depending of making glib a standard library is also something that needs to be viewed by the individual. There are people who belive it to be standard, others think of it as a graphical helper library for GTK+ and GNOME. Last one is valid for me. I only belive that this is not a good thing for midnight commander. it's by far the only console application that I've met in all the years (that I personally use) which has this requirement. I'm also into making rescue systems. I must admit that I recently started with it but it was something I always wanted to do and understand correctly. But I don't belive that such stuff should depend in the initrd image rather than one step later in the root image after you pivot_root'ed into it - But I'm not to judge here how people are doing their stuff. For the interested ones, you can get a dead simply rescue/boot/backup bash script from my webpage which generates such a cd for you, e.g. creating an initrd, copying busybox onto it, then creating a syslinux disk out of it and then later on creates a root image with some files on it. http://www.akcaagac.com/tools/files/shell/cdimage.sh > If you think in dependencies: there's an uglier dependency of mc, > namely slang. My experiences show that mc compiled without slang > (only ncurses) has lot ot problems. IIRC even the developers say > that compiling against only ncurses is not recommended. > > Ncurses ships a big terminfo database, but it's possible to > compile some terminfo entries hardwired into ncurses. We have > the most common terminals (linux, xterm, vt100 and screen) > compiled into ncurses, this makes its size bigger about 2kB > or so, which is nothing. And then ncurses applications > perfectly work on these kinds of terminals without any > terminfo database. Slang, however, isn't able to hardcode > some terminal entries. So for a slang-mc to work properly, > you must have the terminfo entries installed. Yes I fully understand this problem, that could then be seen as step 2 of the process to move midnight commander forward. I am already peeking to the MP fork of 4.1.35 -> which now became 4.1.40. http://mc.linuxinside.com It's based on a pre glib/gnome version of midnight commander, which was heavily bugfixed and some nice little features got added even backported from 4.6.0. The entire size is less than half of what midnight commander became now. I only had some problems with the colors when started up but got told a workaround for this with the -Y classic color option that I haven't paid attention for. I do share some of the sights from olegarch here and I'm already in contact with him, whether we can create a mailinglist and continue working on that one. I have raised my opinion on the current situation of midnight commander from a users perspective and I'm not forcing my opinion on others. There are quite a lot of nice stuff in 4.6.0 no doubt but some things have also changed for the bad. I primarily want is a console filemanager that I can use to delete some junk, move some dirs and rename some stuff - which not depends on glib. greetings. From nerijus at users.sourceforge.net Fri Nov 14 18:09:05 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Fri, 14 Nov 2003 19:09:05 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068827376.12105.28.camel@localhost> References: <1068827376.12105.28.camel@localhost> Message-ID: <3FB51A41.5050906@users.sourceforge.net> Ali Akcaagac wrote: > There are quite a lot of nice > stuff in 4.6.0 no doubt but some things have also changed for the bad. I > primarily want is a console filemanager that I can use to delete some > junk, move some dirs and rename some stuff - which not depends on glib. And I need console filemanager not for rescue disks, but for normal work (file manager plus editing files), as I have usually up to 10 terminals with mc opened. And I don't care about its size or whether it depends on glib... BTW, I don't see any new bad things in 4.6.0, can you elaborate on this? Regards, Nerijus From aliakc at web.de Fri Nov 14 18:20:23 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 14 Nov 2003 19:20:23 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <3FB51A41.5050906@users.sourceforge.net> References: <1068827376.12105.28.camel@localhost> <3FB51A41.5050906@users.sourceforge.net> Message-ID: <1068834023.12912.10.camel@localhost> On Fri, 2003-11-14 at 19:09, Nerijus Baliunas wrote: > And I need console filemanager not for rescue disks, but for > normal work (file manager plus editing files), as I have usually > up to 10 terminals with mc opened. And I don't care about its size > or whether it depends on glib... BTW, I don't see any new bad > things in 4.6.0, can you elaborate on this? Listen, I'm not going to make some sort of flamewar out of this. I just raised a proposal which I for my own belive in. If you and others are going to see it differently then it's ok. No further harms no bad feelings nothing. After all it's open source which you can go and fork as you wish. The rescue disk idea was just one of many possible combinations that one person could raise - I only wonder why people are more up to discuss the concerns of a rescue system rather than talking about the real problem. Do you know the problem I was raising - do you understand the technical problem raised here ? Now you said you don't care whether it depends on glib or not so why did you replied then ? You do not see any difference from operation only that the handful glib calls gonna be replaced with native glibc ones which imo is a good sign to go in the right direction again. Your benefit is that you can edit, rename, copy, move the files even under worst system circumstances because of less dependencies of the core. The functions you have now in mc460 stays the same. By the way you can do the same stuff with mc4140MP, edit, copy, move, rename etc. Please people - only reply if you understand the technical problem I describe here and not just because you feel you need to reply but do not understand the problems. It only raises a wrong light and creates the wrong impressions that there are people who do not like to see mc improving in that area. A few comments already raised are made by people who do not understand the bottom problems here. From rgr at sdf.lonestar.org Fri Nov 14 19:18:18 2003 From: rgr at sdf.lonestar.org (Rob Ristroph) Date: 14 Nov 2003 13:18:18 -0600 Subject: A proposal for Midnight Commander In-Reply-To: <1068827376.12105.28.camel@localhost> References: <1068827376.12105.28.camel@localhost> Message-ID: <87k7627o91.fsf@rgristroph-austin.ath.cx> >>>>> "Ali" == Ali Akcaagac writes: Ali> Ali> http://www.akcaagac.com/index_atlantis.html Your site is giving a connection refused error. Ali> I also share the opinion that re-using code is a wonderful Ali> thing. But it only makes sense in large projects such as re-using Ali> a framework of standard libraries under GNOME for Ali> example. Standard libraries are librsvg, libbonobo, libbonoboui, Ali> libgnome, libgnomeui, gnome-vfs and so on. This makes a lot of Ali> sense and is the right way to go. You can count on my vote for Ali> this whenever someone shows up infront of me and asks whether Ali> this is a good thing or not. Depending of making glib a standard Ali> library is also something that needs to be viewed by the Ali> individual. There are people who belive it to be standard, Ali> others think of it as a graphical helper library for GTK+ and Ali> GNOME. Last one is valid for me. Ali> Ali> I only belive that this is not a good thing for midnight Ali> commander. it's by far the only console application that I've met Ali> in all the years (that I personally use) which has this Ali> requirement. I agree with you. I won't even bother to download and try it out an mc that has libbonobo in it. Or anything else, for that matter -- I'm slowly extracting myself out of gnucase and a couple of other tools that use it. As the guy in in Pulp Fiction said, "sewer rat may taste like pumpkin pie, but I'll never know, because I won't eat the filthy" thing. I've already had too large a portion of my life wasted by the gnome people. Maybe in fifteen years when a generation of programmers have passed through, and I can be reasonably sure none of the original people are still writing parts of it, I'll look at it. It's important to consider that kind of mindshare that a project can lose by releasing successive worse and worse releases. Especially when there is a hype associated with it that is so clearly at odds with what you see on your screen. Ali> I'm also into making rescue systems. I must admit that I recently Ali> started with it but it was something I always wanted to do and Ali> understand correctly. But I don't belive that such stuff should Ali> depend in the initrd image rather than one step later in the root Ali> image after you pivot_root'ed into it - But I'm not to judge here Ali> how people are doing their stuff. For the interested ones, you Ali> can get a dead simply rescue/boot/backup bash script from my Ali> webpage which generates such a cd for you, e.g. creating an Ali> initrd, copying busybox onto it, then creating a syslinux disk Ali> out of it and then later on creates a root image with some files Ali> on it. Ali> Ali> http://www.akcaagac.com/tools/files/shell/cdimage.sh I made a single floppy linux that has mc on it: http://rgr.freeshell.org/flinux/mc-link/ It was more pain that it needed to be. At one point I dug up out of the Slackware archives the slackware package from mc 3.5, and attempted to use that, and it lacked some feature which I have forgotten. Then I went back to a more recent version and commented out whole swaths of troublesome code. It seemed that I could pick any source file and randomly delete stuff and mc would get better. At around that time the 4.6 version was released, which was a large improvement, and the only thing I needed to delete was some stuff in mcserv. I like the current mc, and I think it is going in the right direction in general. >> If you think in dependencies: there's an uglier dependency of mc, >> namely slang. My experiences show that mc compiled without slang >> (only ncurses) has lot ot problems. IIRC even the developers say >> that compiling against only ncurses is not recommended. I compiled mine with ncurses. >> Ncurses ships a big terminfo database, but it's possible to compile >> some terminfo entries hardwired into ncurses. We have the most >> common terminals (linux, xterm, vt100 and screen) compiled into >> ncurses, this makes its size bigger about 2kB or so, which is >> nothing. And then ncurses applications perfectly work on these >> kinds of terminals without any terminfo database. Slang, however, >> isn't able to hardcode some terminal entries. So for a slang-mc to >> work properly, you must have the terminfo entries installed. I did not know about compiling the terminfo's into ncurses. I put a single terminfo entry (linux) on my floppy. Ali> I am already peeking to the MP fork of 4.1.35 -> which now became Ali> 4.1.40. Ali> Ali> http://mc.linuxinside.com Ali> Ali> It's based on a pre glib/gnome version of midnight commander, Ali> which was heavily bugfixed and some nice little features got Ali> added even backported from 4.6.0. The entire size is less than Ali> half of what midnight commander became now. I only had some Ali> problems with the colors when started up but got told a Ali> workaround for this with the -Y classic color option that I Ali> haven't paid attention for. I do share some of the sights from Ali> olegarch here and I'm already in contact with him, whether we can Ali> create a mailinglist and continue working on that one. I have Ali> raised my opinion on the current situation of midnight commander Ali> from a users perspective and I'm not forcing my opinion on Ali> others. There are quite a lot of nice stuff in 4.6.0 no doubt but Ali> some things have also changed for the bad. I primarily want is a Ali> console filemanager that I can use to delete some junk, move some Ali> dirs and rename some stuff - which not depends on glib. It looks interesting. In the cursory inspection I just gave it, I was only able to compile it in the --with-included-slang configuration. Compiling with -Os and stripping, with options as close to what I used in mc 4.6 as possible, I get an executable of 4.51 MB, while my mc 4.6 executable is 3.98 MB. I fiddled with the config options and recompiled it three times. Basically, it reminds me of mc 4.1 which would not allow me to turn off enough options to fit it on a floppy system. However, I think it is good that multiple groups are maintaining different versions of mc. However, it is important to note that mc 4.6 is smaller, or can be configured to be smaller, than it's predecessor. The difference in size is larger than the additional 171k of glib. That's why I think mc is on the right path. I agree with Pavel's view on the various issues. I would tend towards avoiding glib myself if I were coding, but then I haven't contributed any code lately, and glib is small enough that it has not stopped me from doing anything I want to do with mc. --Rob From egmont at cs.bme.hu Fri Nov 14 14:30:31 2003 From: egmont at cs.bme.hu (Koblinger Egmont) Date: Fri, 14 Nov 2003 15:30:31 +0100 (CET) Subject: A proposal for Midnight Commander In-Reply-To: <1068750961.7607.9.camel@localhost> Message-ID: On Thu, 13 Nov 2003, Ali Akcaagac wrote: > Well thats not the point. Compiling something statically does indeed > work but reducing dependency is the better way imo. If you care about dependencies so much, then please let me share my experiences. I'm not really familiar in glib{,2} programming, I rather use plain glibc calls. In the mean time, working on a linux distribution we thought about putting some nice tools in the initrd that performs the installation. We have strace and other nice debug tools there. MC would be nice, too. But we didn't put mc there, and the reason was not glib. (Actually, glib2 is already there since our installer uses gtk2, but we'd simply put there glib2 if it wasn't there, no problem.) I think glib2 is now a quite stanadrd piece of software, with plenty of useful functions. Even if it changes faster than glibc, I'm sure that there's always a big timeframe when obsoleted functions are still available, and I'm quite sure that porting mc to a newer glib2 requires less work than reimplementing all these nice features of glib2 in pure glibc. If you think in dependencies: there's an uglier dependency of mc, namely slang. My experiences show that mc compiled without slang (only ncurses) has lot ot problems. IIRC even the developers say that compiling against only ncurses is not recommended. Ncurses ships a big terminfo database, but it's possible to compile some terminfo entries hardwired into ncurses. We have the most common terminals (linux, xterm, vt100 and screen) compiled into ncurses, this makes its size bigger about 2kB or so, which is nothing. And then ncurses applications perfectly work on these kinds of terminals without any terminfo database. Slang, however, isn't able to hardcode some terminal entries. So for a slang-mc to work properly, you must have the terminfo entries installed. The whole terminfo database is nearly 6MB (uncompressed). Either you split the terminfo package to terminfo-common and terminfo-not-so-common and only install the first one on your minimal system, or install the whole terminfo package and then remove files... It's not the disk space required by the few really important entries of terminfo that matters, but the fact that it's hard to manage it. So IMHO there's absolutely nothing wrong with mc using glib. If there's something else someone should work on, then IMHO it's either make mc perfect without slang, or implement hardwired fallback terminfo entries in slang. -- Egmont From aliakc at web.de Fri Nov 14 20:01:44 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 14 Nov 2003 21:01:44 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <87k7627o91.fsf@rgristroph-austin.ath.cx> References: <1068827376.12105.28.camel@localhost> <87k7627o91.fsf@rgristroph-austin.ath.cx> Message-ID: <1068840104.13036.31.camel@localhost> On Fri, 2003-11-14 at 20:18, Rob Ristroph wrote: > Ali> http://www.akcaagac.com/index_atlantis.html > > Your site is giving a connection refused error. Yes figured that out myself. It looks like my buddy who hosts me on his server is going to have some maintainance on it. I bet it will be back online in a couple of hours. > I like the current mc, and I think it is going in the right > direction in general. Yes if you speak about cleaning it up, removing dead code, replace broken parts with new ones. Then I fullheartly agree here. But what benefits do we have if we can't really pariticpate to this project ? There is a bugreporting system, a mailinglist, but basically proposals we raise are going to /dev/null. > It looks interesting. In the cursory inspection I just gave it, > I was only able to compile it in the --with-included-slang > configuration. Compiling with -Os and stripping, with options as > close to what I used in mc 4.6 as possible, I get an executable of > 4.51 MB, while my mc 4.6 executable is 3.98 MB. I fiddled with the > config options and recompiled it three times. Basically, it > reminds me of mc 4.1 which would not allow me to turn off enough > options to fit it on a floppy system. ;------------ w/o gpm, undelext2 + stripped galaxy at ulixys:~ > ls -l /tmp/s/mc-4.1.40-pre8/src/mc 651856 Nov 14 20:39 /tmp/s/mc-4.1.40-pre8/src/mc ;------------ whereas my 4.6.0 version ;------------ normal configure && make && make install galaxy at ulixys:~ > ls -l /usr/local/bin/mc 670013 Nov 12 01:15 /usr/local/bin/mc ;------------ I must admit the differences aren't that big for a more improved version like the 4.6.0. That's definately not my worries either. I am only stuck with the problematic of the glib dependency. > However, I think it is good that multiple groups are maintaining > different versions of mc. Maybe it's possible to hook on at the 4.1.40 development of mcMP after all the maintainer made some cleanups by removing stuff no one really wants in mc, as written the GNOME stuff, TK, X. There is a lot of room to improve (even in size). I don't really know. On the one hand I like to follow mainstream, I do like mc460 but the glib issue gave me many more times problems than just one time. I will continue keeping an eye on both projects. From rgr at sdf.lonestar.org Fri Nov 14 20:24:04 2003 From: rgr at sdf.lonestar.org (Rob Ristroph) Date: 14 Nov 2003 14:24:04 -0600 Subject: A proposal for Midnight Commander In-Reply-To: <1068840104.13036.31.camel@localhost> References: <1068827376.12105.28.camel@localhost> <87k7627o91.fsf@rgristroph-austin.ath.cx> <1068840104.13036.31.camel@localhost> Message-ID: <87vfpm1yxn.fsf@rgristroph-austin.ath.cx> >>>>> "Ali" == Ali Akcaagac writes: Ali> >> I like the current mc, and I think it is going in the right >> direction in general. Ali> Ali> Yes if you speak about cleaning it up, removing dead code, Ali> replace broken parts with new ones. Then I fullheartly agree Ali> here. But what benefits do we have if we can't really pariticpate Ali> to this project ? There is a bugreporting system, a mailinglist, Ali> but basically proposals we raise are going to /dev/null. Are patches being rejected ? One way to get a new feature accepted would be to post the patch or whole source on the web, even if the maintainer didn't like it at first, widespread use of the changes might change minds. >> It looks interesting. In the cursory inspection I just gave it, I >> was only able to compile it in the --with-included-slang >> configuration. Compiling with -Os and stripping, with options as >> close to what I used in mc 4.6 as possible, I get an executable of >> 4.51 MB, while my mc 4.6 executable is 3.98 MB. I fiddled with the >> config options and recompiled it three times. Basically, it >> reminds me of mc 4.1 which would not allow me to turn off enough >> options to fit it on a floppy system. Ali> Ali> ;------------ w/o gpm, undelext2 + stripped Ali> galaxy at ulixys:~ > ls -l /tmp/s/mc-4.1.40-pre8/src/mc Ali> 651856 Nov 14 20:39 /tmp/s/mc-4.1.40-pre8/src/mc Ali> ;------------ Ali> Ali> whereas my 4.6.0 version Ali> Ali> ;------------ normal configure && make && make install Ali> galaxy at ulixys:~ > ls -l /usr/local/bin/mc Ali> 670013 Nov 12 01:15 /usr/local/bin/mc Ali> ;------------ Ali> Ali> I must admit the differences aren't that big for a more improved Ali> version like the 4.6.0. That's definately not my worries Ali> either. I am only stuck with the problematic of the glib Ali> dependency. Your 4.1.40 is likely unstripped, because it doesn't strip the copy in the source tree (in fact make install doesn't strip it either). It is likely stripping will save you more space than glib. Also look at "ldd /tmp/s/mc-4.1.40-pre8/src/mc" and "ldd /usr/local/bin/mc". It is likely that you link in one or two unneeded libraries. Here's what I am getting from ldd: libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40024000) libncurses.so.5 => /lib/libncurses.so.5 (0x40048000) libext2fs.so.2 => /lib/libext2fs.so.2 (0x40088000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x4009c000) libc.so.6 => /lib/libc.so.6 (0x4009e000) libgpm.so.1 => /lib/libgpm.so.1 (0x401c1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) And even then I can remove libgpm if I need to. Ali> Maybe it's possible to hook on at the 4.1.40 development of mcMP Ali> after all the maintainer made some cleanups by removing stuff no Ali> one really wants in mc, as written the GNOME stuff, TK, X. There Ali> is a lot of room to improve (even in size). I don't really Ali> know. On the one hand I like to follow mainstream, I do like Ali> mc460 but the glib issue gave me many more times problems than Ali> just one time. Ali> Ali> I will continue keeping an eye on both projects. Ok, but consider which is easier -- dealing with the separate 4.1.40 tree, or just adding --without-x to your configure flags ? --Rob From nerijus at users.sourceforge.net Fri Nov 14 20:48:42 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Fri, 14 Nov 2003 21:48:42 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068834023.12912.10.camel@localhost> References: <1068827376.12105.28.camel@localhost> <3FB51A41.5050906@users.sourceforge.net> <1068834023.12912.10.camel@localhost> Message-ID: <3FB53FAA.2090304@users.sourceforge.net> Ali Akcaagac wrote: >>And I need console filemanager not for rescue disks, but for >>normal work (file manager plus editing files), as I have usually >>up to 10 terminals with mc opened. And I don't care about its size >>or whether it depends on glib... BTW, I don't see any new bad >>things in 4.6.0, can you elaborate on this? > > Listen, I'm not going to make some sort of flamewar out of this. I just I am not going too, sorry if it sounded like that. I just said what *I* need from the console filemanager, that's it. > raised a proposal which I for my own belive in. If you and others are > going to see it differently then it's ok. No further harms no bad > feelings nothing. Exactly. I just wanted to say that I see it differently, but I do not think that everybody has to think the same way. > about the real problem. Do you know the problem I was raising - do you > understand the technical problem raised here ? Yes. > Now you said you don't > care whether it depends on glib or not so why did you replied then ? Oh well, this is a flame already, I will not answer in order not to become a troll... > do not see any difference from operation only that the handful glib > calls gonna be replaced with native glibc ones which imo is a good sign > to go in the right direction again. Pavel said he will do that when these calls disappear from glib. Regards, Nerijus P.S. My comment was about that these issues are not the most important ones for the moment, and probably because of that Pavel will not address them now, but if you want to do that, you are welcome. From aliakc at web.de Fri Nov 14 20:49:31 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 14 Nov 2003 21:49:31 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <87vfpm1yxn.fsf@rgristroph-austin.ath.cx> References: <1068827376.12105.28.camel@localhost> <87k7627o91.fsf@rgristroph-austin.ath.cx> <1068840104.13036.31.camel@localhost> <87vfpm1yxn.fsf@rgristroph-austin.ath.cx> Message-ID: <1068842971.3355.15.camel@localhost> On Fri, 2003-11-14 at 21:24, Rob Ristroph wrote: > Are patches being rejected ? One way to get a new feature > accepted would be to post the patch or whole source on the > web, even if the maintainer didn't like it at first, > widespread use of the changes might change minds. I'm not the person writing patches which are supposed to be rejected afterwards. I first make a proposal and if it's being agreed on then we can talk about making patches. I am willing to write a couple of parts to remove glib dependency. > Your 4.1.40 is likely unstripped, because it doesn't strip the > copy in the source tree (in fact make install doesn't strip it > either). It is likely stripping will save you more space than > glib. Also look at "ldd /tmp/s/mc-4.1.40-pre8/src/mc" and "ldd > /usr/local/bin/mc". It is likely that you link in one or two > unneeded libraries. I don't know what you are using here but it's most likely NOT the mc-4.1.40MP that I was refering to but to answer at least one question it was stripped by me afterwards before I mentioned the values. > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40024000) > libncurses.so.5 => /lib/libncurses.so.5 (0x40048000) > libext2fs.so.2 => /lib/libext2fs.so.2 (0x40088000) > libcom_err.so.2 => /lib/libcom_err.so.2 (0x4009c000) > libc.so.6 => /lib/libc.so.6 (0x4009e000) > libgpm.so.1 => /lib/libgpm.so.1 (0x401c1000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Yeah only strange thing is, where did you get the glib dependency from ? Midnight Commander 4.1.40 MP doesn't have any glib dependencies in it. It doesn't link to it, it doesn't search for it and it doesn't require it. So the only conclusion is you are ldd'ing a totally wrong binary here. http://mc.linuxinside.com/ > Ok, but consider which is easier -- dealing with the separate > 4.1.40 tree, or just adding --without-x to your configure flags ? I think you don't exactly know what you are writing here (no offense but I don't know how else I can explain it). --without-x has nothing to do with glib not staying a dependency inside mc. Again, I'm not worried about the size (well not entirely true). It doesn't really matter whether there are a few bytes difference (as long as it's a few bytes). To say the truth mc-4.6.0 can be stripped down to a 360376 bytes binary without any options enabled, compiled with -Os and stripped, whereas the mc-4.1.40MP is around 536524 bytes binary without any options, compiled with -Os and stripped. But the glib library is around 500kb which makes the nice stripped 360376 bytes binary of mc-4.6.0 look like a worthless value. From aliakc at web.de Fri Nov 14 20:56:38 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 14 Nov 2003 21:56:38 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <3FB53FAA.2090304@users.sourceforge.net> References: <1068827376.12105.28.camel@localhost> <3FB51A41.5050906@users.sourceforge.net> <1068834023.12912.10.camel@localhost> <3FB53FAA.2090304@users.sourceforge.net> Message-ID: <1068843398.3355.21.camel@localhost> On Fri, 2003-11-14 at 21:48, Nerijus Baliunas wrote: > > do not see any difference from operation only that the handful > > glib calls gonna be replaced with native glibc ones which imo > > is a good sign to go in the right direction again. > > Pavel said he will do that when these calls disappear from glib. He actually said that he is going to replace DEPRECATED glib functioncalls with NEW functioncalls inside glib. Not replacing them with glibc alternatives. Which is quite a big difference. > but if you want to do that, you are welcome. Are you the new maintainer of Midnight Commander ? From what I understood is that Pavel doesn't plan to have that one changed. If so then I can write a bunch of parts to have glib dependency removed. Yes I am willing to do this - with help of others this could be done in a couple of hours. From proski at gnu.org Fri Nov 14 21:04:49 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 14 Nov 2003 16:04:49 -0500 (EST) Subject: undelfs warnings fix In-Reply-To: <200311141537.hAEFboDf046078@email.zp.ua> References: <200311141537.hAEFboDf046078@email.zp.ua> Message-ID: On Fri, 14 Nov 2003, Andrew V. Samoilov wrote: > Previous patch implementation breaks mcfs compilation, and as I understood > recently current implementation of com_err() is wrong and have format string > vulnerability. > > New implementation fixes com_err() and does not define free, sorry about > glib and libc memory allocation function mix, but we have it for glib 1.2x. > already. Applied. Thank you! The mix is unavoidable, but glib 1.2.x always uses libc memory allocation. -- Regards, Pavel Roskin From nerijus at users.sourceforge.net Fri Nov 14 21:20:56 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Fri, 14 Nov 2003 22:20:56 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068843398.3355.21.camel@localhost> References: <1068827376.12105.28.camel@localhost> <3FB51A41.5050906@users.sourceforge.net> <1068834023.12912.10.camel@localhost> <3FB53FAA.2090304@users.sourceforge.net> <1068843398.3355.21.camel@localhost> Message-ID: <3FB54738.1090009@users.sourceforge.net> Ali Akcaagac wrote: >>Pavel said he will do that when these calls disappear from glib. > > He actually said that he is going to replace DEPRECATED glib > functioncalls with NEW functioncalls inside glib. Not replacing them > with glibc alternatives. Which is quite a big difference. Ah, ok, sorry. >>but if you want to do that, you are welcome. > > Are you the new maintainer of Midnight Commander ? From what I > understood is that Pavel doesn't plan to have that one changed. If so OK then, if you can't persuade him, you can only use some other fork or fork yourself... > then I can write a bunch of parts to have glib dependency removed. Yes I > am willing to do this - with help of others this could be done in a > couple of hours. Really? And to make it work with a lot of unices and their compilers? And don't have any potential problems with buffers et all? Nerijus From rgr at sdf.lonestar.org Fri Nov 14 21:33:47 2003 From: rgr at sdf.lonestar.org (Rob Ristroph) Date: 14 Nov 2003 15:33:47 -0600 Subject: A proposal for Midnight Commander In-Reply-To: <1068842971.3355.15.camel@localhost> References: <1068827376.12105.28.camel@localhost> <87k7627o91.fsf@rgristroph-austin.ath.cx> <1068840104.13036.31.camel@localhost> <87vfpm1yxn.fsf@rgristroph-austin.ath.cx> <1068842971.3355.15.camel@localhost> Message-ID: <87oeve1vpg.fsf@rgristroph-austin.ath.cx> >>>>> "Ali" == Ali Akcaagac writes: Ali> Ali> I'm not the person writing patches which are supposed to be Ali> rejected afterwards. I first make a proposal and if it's being Ali> agreed on then we can talk about making patches. Come on, have you ever seen a project that worked like that ? Seriously, "show me the code" is the motto of any project with more than a handful of people, unless you are paying money. Ali> I am willing to write a couple of parts to remove glib Ali> dependency. I would be interested in trying out any patches you made that removed the glib dependency. If two people where using it regularly and merging in the other continuing changes, Pavel might be more interested. Even if you only remove some of the dependencies, maybe I can see about the remaining ones. I like the idea of writing very simple, but safe and bug-free, code that depends on as few libraries as reasonably possible. Ali> I don't know what you are using here but it's most likely NOT the Ali> mc-4.1.40MP that I was refering to but to answer at least one Ali> question it was stripped by me afterwards before I mentioned the Ali> values. Ali> >> libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40024000) >> libncurses.so.5 => /lib/libncurses.so.5 (0x40048000) >> libext2fs.so.2 => /lib/libext2fs.so.2 (0x40088000) >> libcom_err.so.2 => /lib/libcom_err.so.2 (0x4009c000) >> libc.so.6 => /lib/libc.so.6 (0x4009e000) >> libgpm.so.1 => /lib/libgpm.so.1 (0x401c1000) >> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Ali> Ali> Yeah only strange thing is, where did you get the glib dependency Ali> from ? Midnight Commander 4.1.40 MP doesn't have any glib Ali> dependencies in it. It doesn't link to it, it doesn't search for Ali> it and it doesn't require it. So the only conclusion is you are Ali> ldd'ing a totally wrong binary here. I'm ldd'ing mc 4.6, to show you that the total number of library dependancies in my version. Perhaps you might check your version and see if there are library dependancies other than glib that can be removed by changing the parameters to ./configure. >> Ok, but consider which is easier -- dealing with the separate >> 4.1.40 tree, or just adding --without-x to your configure flags ? Ali> Ali> I think you don't exactly know what you are writing here (no Ali> offense but I don't know how else I can explain it). --without-x Ali> has nothing to do with glib not staying a dependency inside mc. No, and I wasn't implying that it did. However, it is likely that you can do far more shrinking of your mc by applying a few configure flags (even if glib is still there) than you would get by removing glib, which would require writing code. Ali> Again, I'm not worried about the size (well not entirely Ali> true). It doesn't really matter whether there are a few bytes Ali> difference (as long as it's a few bytes). To say the truth Ali> mc-4.6.0 can be stripped down to a 360376 bytes binary without Ali> any options enabled, compiled with -Os and stripped, whereas the Ali> mc-4.1.40MP is around 536524 bytes binary without any options, Ali> compiled with -Os and stripped. But the glib library is around Ali> 500kb which makes the nice stripped 360376 bytes binary of Ali> mc-4.6.0 look like a worthless value. On slackware 8.1 glib is 171k. On Debian 3.0 it is 138k. On Debian testing it is 400k -- that's because it glib 2.0. To get rid of a dependency on a 400k binary (glib 2.0) I would start writing code, so I begin to see your point. I probably would not do it for the glib1.2, simply because I know of other trickery I can employ to save me that much space, mainly removing stuff from the linux kernel. Why don't you see if you can use glib 1.2 ? Then you can save a lot of space without much work. I have been able to compile mc 4.6 on linuxes that had only the 1.2 version of glib, so I suppose the configure scripts pick that up automatically. --Rob From aliakc at web.de Fri Nov 14 21:37:47 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 14 Nov 2003 22:37:47 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <3FB54738.1090009@users.sourceforge.net> References: <1068827376.12105.28.camel@localhost> <3FB51A41.5050906@users.sourceforge.net> <1068834023.12912.10.camel@localhost> <3FB53FAA.2090304@users.sourceforge.net> <1068843398.3355.21.camel@localhost> <3FB54738.1090009@users.sourceforge.net> Message-ID: <1068845867.10799.10.camel@localhost> On Fri, 2003-11-14 at 22:20, Nerijus Baliunas wrote: > > then I can write a bunch of parts to have glib dependency > > removed. Yes I am willing to do this - with help of others > > this could be done in a couple of hours. > > Really ? And to make it work with a lot of unices and their > compilers ? And don't have any potential problems with buffers > et all ? This is no problem with compilers or something. But yes, the majority of g_* calls used are g_malloc, g_free, g_strdup and a few soon to be DEPRECATED calls. The majority can be replaced with libc alternatives. I would be a liar and not serious if I promise that there won't be the one or other problem that needs to be investigated a bit more but I can promise that after it's done that it works. Your system is full of console programs that do not require glib and they magically work - don't you agree ? And that's my whole point. I don't want to change the appearance of Midnight Commander, nor do I want to take away flexibility or something. Midnight Commander besides a few things I don't really like (because of personal preferences) is so far a great program. It's used worldwide by many people. I only want to increase it's flexibility by removing a shitty dependency. After this has been done we can seamless concentrate solving the other issues around it like VFS that pavel said to be broken and things like this. Another thing that may be not clear right now is the simple datatypes. Look if we gonna talk about 'does it work on other systems' and if we talk about 'glib is cool' then I need to raise the question why doesn't Midnight Commander use all of glib then ? Even the simple Datatypes ? The majority of Datatypes are wrappers anyways but glib here guarantees that a 32bit integer is 32bit and not 16bit or 64bit (just a weak example). The majority of Datatypes used in Midnight Commander are standard C Datatypes. So basically the glib usage is halfbacked in Midnight Commander anyways. From nerijus at users.sourceforge.net Fri Nov 14 21:41:41 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Fri, 14 Nov 2003 22:41:41 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <87oeve1vpg.fsf@rgristroph-austin.ath.cx> References: <1068827376.12105.28.camel@localhost> <87k7627o91.fsf@rgristroph-austin.ath.cx> <1068840104.13036.31.camel@localhost> <87vfpm1yxn.fsf@rgristroph-austin.ath.cx> <1068842971.3355.15.camel@localhost> <87oeve1vpg.fsf@rgristroph-austin.ath.cx> Message-ID: <3FB54C15.7090106@users.sourceforge.net> Rob Ristroph wrote: > Ali> I'm not the person writing patches which are supposed to be > Ali> rejected afterwards. I first make a proposal and if it's being > Ali> agreed on then we can talk about making patches. > > Come on, have you ever seen a project that worked like that ? > Seriously, "show me the code" is the motto of any project with more > than a handful of people, unless you are paying money. Well, Ali is right. I remember one of mplayer developers posted a few patches, but got no reply from Pavel... Regards, Nerijus From aliakc at web.de Fri Nov 14 21:47:59 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 14 Nov 2003 22:47:59 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <87oeve1vpg.fsf@rgristroph-austin.ath.cx> References: <1068827376.12105.28.camel@localhost> <87k7627o91.fsf@rgristroph-austin.ath.cx> <1068840104.13036.31.camel@localhost> <87vfpm1yxn.fsf@rgristroph-austin.ath.cx> <1068842971.3355.15.camel@localhost> <87oeve1vpg.fsf@rgristroph-austin.ath.cx> Message-ID: <1068846479.10820.7.camel@localhost> On Fri, 2003-11-14 at 22:33, Rob Ristroph wrote: > Come on, have you ever seen a project that worked like > that ? Seriously, "show me the code" is the motto of any > project with more than a handful of people, unless you > are paying money. Good, this can be the case for other projects but not with my time. I am not sitting here writing 1 week of code only to hear afterwards that the maintainer isn't interested. If it works for you ok, not for me. I say it how it is. I spent various days writing some shit only to see them being rejected afterwards. So asking first makes more sense. If no one is interested then I can spent my time for other things. > I'm ldd'ing mc 4.6, to show you that the total number of > library dependancies in my version. Perhaps you might > check your version and see if there are library dependancies > other than glib that can be removed by changing the parameters > to ./configure. Seriously Your 4.1.40 is likely unstripped, ... ... Here's what I am getting from ldd: One time you write mc-4.1.40 and then later you meant 4.6.0. Now what ? Once you agree which version you meant to show me you can reply on it again. > Why don't you see if you can use glib 1.2 ? Because I explained this point already in the initials of this Thread. I recommend you read it entirely and not half. It's not difficult and my english (besides that it's bad) isn't difficult either. Ok I think we leave it on that. From miguel at ximian.com Fri Nov 14 23:00:34 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 14 Nov 2003 18:00:34 -0500 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> Message-ID: <1068850834.24775.54.camel@erandi.boston.ximian.com> Hello, > > Glib1 is a no option on my system and on many other people's system > > either because the majority for now seem to have switched to GNOME2 or > > GTK2 already and do not intend to use glib1 anymore - regardless of the > > fact that it co-exists. The idea itself is wrong. > > I also prefer to use current versions of all software. On the other hand, > Glib doesn't promise stability of API in the long term. I realize that > it's a problem, but I don't consider it a major problem, based on my > experience so far. There is a promise that we will never break the compatibility. A function in say glib 75 might become deprecated, but if you stick to the stable version, there is a community contract to keep the stability from the Gnome folks > I understand your feelings, but I'd rather go with a utility library > maintained by someone else, ideally with standard stable API. I agree completely with Pavel: the more code you reuse from someone else, the more you cross-benefit that community, and they benefit you. Less lines of code to maintain, more time to work on fun things. > I accept your argument that specifically GNU Midnight Commander should not > have too many dependencies because it can be used as a recovery tool. > It's just that the weight of this argument is not as significant as it > used to be. The most widespread media for recovery tools is now a CD, not > a floppy disk. Also, static glib is a requirement at *build time*, not a requirement at runtime. > I'm not saying I'm doing enough. Maybe I'm doing 20% of what should be > done. But I know that if we reduce requirements on the quality, the code > will become mess once again. Neither am I saying that my handling of the > situation is correct. I'm just trying to do what I can. Btw, I really appreciate your work here Pavel. Miguel From aliakc at web.de Fri Nov 14 22:18:17 2003 From: aliakc at web.de (Ali Akcaagac) Date: Fri, 14 Nov 2003 23:18:17 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068850834.24775.54.camel@erandi.boston.ximian.com> References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> Message-ID: <1068848297.10846.11.camel@localhost> On Sat, 2003-11-15 at 00:00, Miguel de Icaza wrote: > > I understand your feelings, but I'd rather go with a utility > > library maintained by someone else, ideally with standard > > stable API. > > I agree completely with Pavel: the more code you reuse from > someone else, the more you cross-benefit that community, and > they benefit you. Less lines of code to maintain, more time > to work on fun things. I think you should know it better than what you replied here. You are only making a despite reply here imo. Reusing code definately a good thing in large projects such as GNOME but not good in a console application which can run easily without glib here. Your reply regarding community stability is wrong if you looked at the g_tree_traverse call. It's marked deprecated in glib 2.3.x. So much for API compatibility. Your reply regarding 'working on fun stuff' deserve a closer view as well. Look what happens once the DEPRECATION of such glib calls come reality ? You then sit there thinking of yet another 20 ways howto solve the problem - which should not have been a problem after all if there was a proper solution for it. Look at GNOME for example how much stuff recently got marked DEPRECATED (of course I am all for the deprecation itself because we finally move away from wrong code and move towards a nice codebase for the GNOME framework) but for the fun thing... How much time do we need to change our code to fit the new functioncalls. All the libgnomeui deprecated functions we now need to YET AGAIN work out a new solution... where is the 'use the time to hack on fun stuff' ? Same for the new Toolbarcode and Menucode, replacement of GTKCombo with GTKCombobox. Even your ppl at Ximian need to hack GAL to change the GTKCombo used inside there... So much for the 'fun stuff'. This is no rant or insult, only a true statement that even you know. And you know it's true. As I said, I am not against Glib and I do see the benefits of it in a large project such as GNOME but not in a console application. What re-use of code is there in Midnight Commander ? There are basically no code-reuse, no deep large library call that does some significant task here. The majority of stuff used are memory allocation calls and free'ing calls beside some string calls. Everything and all replaceable with glibc ones. greetings. From aliakc at web.de Sat Nov 15 00:54:07 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 01:54:07 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <3FB54C15.7090106@users.sourceforge.net> References: <1068827376.12105.28.camel@localhost> <87k7627o91.fsf@rgristroph-austin.ath.cx> <1068840104.13036.31.camel@localhost> <87vfpm1yxn.fsf@rgristroph-austin.ath.cx> <1068842971.3355.15.camel@localhost> <87oeve1vpg.fsf@rgristroph-austin.ath.cx> <3FB54C15.7090106@users.sourceforge.net> Message-ID: <1068857647.17540.11.camel@localhost> On Fri, 2003-11-14 at 22:41, Nerijus Baliunas wrote: > Well, Ali is right. I remember one of mplayer developers > posted a few patches, but got no reply from Pavel... Actually it was not one of the MPlayer developers. It was the lead developer of MPlayer himself - Arpi. The guy who has bigger balls in his pants than others (refering to his skills here). Ok it was always criticised that the MPlayer code looked awfull but this is hopefully being dealth with in MPlayerG2. But more interesting is that he and his team of developers were those who finally brought one of the best mediaplayers around to open source. This makes him a qualified person as soon as it comes to innovate and bringing projects futher. I only didn't caught his signal where he wanted to create a new mainstream Midnight Commander early Spring this year. Anyways have you people paid attention that during this entire conversation that Pavel didn't replied to it anymore ? This is a development Mailinglist so raising Proposals and ideas what can be changed is a common practice. I am not talking out of my back here - I do know what I am talking here and raising some good points that others may not have seen so far is definately a good point but I take his silence as - not wanting to cooperate in any ways. Accpeting patches from others and the normal smaltalk is welcome but major changes or raised opinions somehow not. After all we are just talking about software here and I am happy that we kept it that way. Anyways I would wish that people are more cooperative and more open about innovation and going a good way rather than keeping their tunnelview and stay stuck in road they are going. Midnight Commander is a nice tool, the source code layout in the Midnight Commander dir looks quite promising. After all we are not pushing Mountains here. Anyways Pavel, my offer to help removing the glib dependency still stays. I would accept it, it's a general benefit for all. From avarakin00 at hotmail.com Sat Nov 15 01:10:56 2003 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Fri, 14 Nov 2003 20:10:56 -0500 Subject: A proposal for Midnight Commander References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> Message-ID: I am sorry if the suggestion below has been alredy made : Can't we just include glib (or part of it) as part of mc sources? It seems that we are using only few functions from glib, so we can create a file (or few files) which contain the subset of glib which is used by mc, and include it as part of mc, and part of mc build. Advantages are: 1. no hassle with installing , building glib aymore 2. no changes in mc sources 3. we will have stable version of glib 4. no hassle with glib1 vs glib2 5. maybe smaller size of mc binaries 6. this subset of glib may become a foundation for new mc framework From aliakc at web.de Sat Nov 15 01:39:30 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 02:39:30 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> Message-ID: <1068860370.17742.8.camel@localhost> On Sat, 2003-11-15 at 02:10, Alexander Varakin wrote: > 1. no hassle with installing , building glib aymore > 2. no changes in mc sources > 3. we will have stable version of glib > 4. no hassle with glib1 vs glib2 > 5. maybe smaller size of mc binaries > 6. this subset of glib may become a foundation for new mc framework This would be a good idea and for the moment not bad either. But here is something more easy: :%s/g_malloc/malloc/g :%s/g_free/free/g And you are quite a lot closer to porting from glib to glibc. After this do that: :%s/g_strdup/strdup/g :%s/g_strconcat//g And you ported Midnight Commander for over 60-70% to glibc again. This was only a quick peek I did. A few things need a bit more investigation but it's not that big as people may assuming here. From avarakin00 at hotmail.com Sat Nov 15 02:30:46 2003 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Fri, 14 Nov 2003 21:30:46 -0500 Subject: A proposal for Midnight Commander References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> Message-ID: > :%s/g_malloc/malloc/g > :%s/g_free/free/g > > And you are quite a lot closer to porting from glib to glibc. After this > do that: > > :%s/g_strdup/strdup/g > :%s/g_strconcat//g Even easier: #define g_malloc malloc The advantage of this approach is that there will be no change in many files and, if desired, we can change implementation of these simple functions, e.g. we can make g_malloc to bail out if we run out of memory. But this is just a matter of taste which approach to chose for these simple functions. > And you ported Midnight Commander for over 60-70% to glibc again. This > was only a quick peek I did. A few things need a bit more investigation The remaining 30% of mc's glib code usage must be the list code, and I think the best way to handle it is just to use glib's implementation. From miguel at ximian.com Sat Nov 15 03:40:11 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 14 Nov 2003 22:40:11 -0500 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> Message-ID: <1068867611.24775.62.camel@erandi.boston.ximian.com> Hello, > The advantage of this approach is that there will be no change in many files > and, if desired, we can change implementation of these simple functions, > e.g. we can make g_malloc to bail out if we run out of memory. > But this is just a matter of taste which approach to chose for these simple > functions. > > > And you ported Midnight Commander for over 60-70% to glibc again. This > > was only a quick peek I did. A few things need a bit more investigation > > The remaining 30% of mc's glib code usage must be the list code, and I think > the best way to handle it is just to use glib's implementation. The problem is wasting the time doing this. See, one of the worst parts in the code of MC is the input handling: keyboard, idles and timeouts. It only handles a few, and has a number of workarounds and ugly chunks which are no longer required. A worthwhile exercise would be to replace those with the GLib mainloop, which would give us timeouts, and would cleanup a lot of messy code in the viewer, the editor and the shell. The focus should be on cleaning up *that* code base, taking advantage of what glib has to offer, rather than introducing more regressions in the code. Miguel. From aliakc at web.de Sat Nov 15 03:00:03 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 04:00:03 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> Message-ID: <1068865203.17998.16.camel@localhost> On Sat, 2003-11-15 at 03:30, Alexander Varakin wrote: > Even easier: > #define g_malloc malloc Indeed, this sounds even better. > The remaining 30% of mc's glib code usage must be the list code, > and I think the best way to handle it is just to use glib's > implementation. The rest are still depending on some soon to be DEPRECATED functions which you can verify on your own inside glib 2.3.x. I think we should have a separate location for this stuff. Arpi already offered me some space on mplayer.hu (also good for PR). I only like to convince a few more people for this, so we can finally start doing the work. Let's see how this looks like. I am not going to promise anything because MC as is now satisfies me on my normal Workstation. It's just the idea I have now. Maybe I can convince Arpi (shouldn't be a big prob imo) and that Olegarch guy (who is working on 4.1.40) to merge together in one project. I do like Midnight Commander 4.6.0 (as I often repeated here) it's nothing wrong only the dependency of glib which shouldn't be there imo. I saw what Miguel replied to you and usually I have the tendency to agree that re-using code is a nice thing. But Midnight Commander is not big enough that it would justify it to depend on glib. For GUI material e.g. a full Desktop Environment I would fullheartly agree anyday but not for a console application. What benefits do you have when you are able to shrink the size of Midnight Commander to around ~350kb but then on the otherhand need a full blown Glib2 library with ~500kb only to use the 5-6 functions required by Midnight Commander. I think that everybody is going to agree here. Let me know whether you have interest in this (this is valid for everyone else as well), I then gonna forward this request to Arpi and have a new ML set up for this. greetings. From miguel at ximian.com Sat Nov 15 04:12:22 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 14 Nov 2003 23:12:22 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <1068865203.17998.16.camel@localhost> References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068865203.17998.16.camel@localhost> Message-ID: <1068869542.24775.67.camel@erandi.boston.ximian.com> > Let me know whether you have interest in this (this is valid for > everyone else as well), I then gonna forward this request to Arpi and > have a new ML set up for this. The beauty of open source is that you can do this, and am glad, because not everyone has the same needs. Some people need smaller applications, or we have differences. Good luck with the project Ali. Now, lets go back to our regularly scheduled programming. Miguel From aliakc at web.de Sat Nov 15 03:19:39 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 04:19:39 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068869542.24775.67.camel@erandi.boston.ximian.com> References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068865203.17998.16.camel@localhost> <1068869542.24775.67.camel@erandi.boston.ximian.com> Message-ID: <1068866379.18043.5.camel@localhost> On Sat, 2003-11-15 at 05:12, Miguel de Icaza wrote: > The beauty of open source is that you can do this, and am glad, > because not everyone has the same needs. Some people need smaller > applications, or we have differences. Good luck with the project > Ali. Now, lets go back to our regularly scheduled programming. Indeed, open source is so what nice. You can take it, change it, re-release it. Do whatever you think is right. No seriously. Ever asked yourself why there are forks ? Because people can't get along doing such changes in the core. Anyways I am far from forking anything. I first need to find a bunch of people who may be interested. Then it makes sense not earlier. I can also get along with Midnight Commander as is in CVS - also no problem, regardless of the fact that I dislike the fact of it using Glib. The good things about development mailinglists are you can raise some proposals and if people (dis)agree then you can search for those who may agree, who are interested in changes etc. On the otherhand we also had a good refreshing discussion - after all we are talking about software here and not personal feelings of people. greetings. From miguel at ximian.com Sat Nov 15 04:32:25 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 14 Nov 2003 23:32:25 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <1068866379.18043.5.camel@localhost> References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068865203.17998.16.camel@localhost> <1068869542.24775.67.camel@erandi.boston.ximian.com> <1068866379.18043.5.camel@localhost> Message-ID: <1068870745.24775.72.camel@erandi.boston.ximian.com> > > The beauty of open source is that you can do this, and am glad, > > because not everyone has the same needs. Some people need smaller > > applications, or we have differences. Good luck with the project > > Ali. Now, lets go back to our regularly scheduled programming. > > Indeed, open source is so what nice. You can take it, change it, > re-release it. Do whatever you think is right. > > No seriously. Ever asked yourself why there are forks ? Because people > can't get along doing such changes in the core. Anyways I am far from > forking anything. I first need to find a bunch of people who may be > interested. Then it makes sense not earlier. I can also get along with > Midnight Commander as is in CVS - also no problem, regardless of the > fact that I dislike the fact of it using Glib. The good things about > development mailinglists are you can raise some proposals and if people > (dis)agree then you can search for those who may agree, who are > interested in changes etc. On the otherhand we also had a good > refreshing discussion - after all we are talking about software here and > not personal feelings of people. Well, I think that forks have gotten a bad reputation, but it does not really deserve it. Many times the needs of one community are different than others. For example, you dont use even the same source code for the Linux kernel on a PalmPilot as the one you use on a 64-way NUMA system. It is just not practical to satisfy every need, and to maintain every need on the same code base. It is still possible to merge improvements back and forth, but I think that we should be talking about "customizations" of the software more than forks. Like it happens with cars. Not everyone wants to ride the same car: people might want to add a stereo, better wheels, different engine, crazy paintings, dark glasses, etc. Is this something the dealership should offer? 40 different variables for every possible combination and have to support them all? Probably not. So all the more power to forks. Miguel From avarakin00 at hotmail.com Sat Nov 15 03:47:05 2003 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Fri, 14 Nov 2003 22:47:05 -0500 Subject: A proposal for Midnight Commander References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> Message-ID: > > > > The remaining 30% of mc's glib code usage must be the list code, and I think > > the best way to handle it is just to use glib's implementation. > > The problem is wasting the time doing this. > You should not worry about this. If this effort will be supported by maintainers of mc , I and Ali will make the changes. It does not look like a huge effort, couple of days max. The real problem is that many potential users try to install or build mc and suddenly they realize that this small program requires a third party library, maybe many of them. When something like this happens to me, I just nuke such program and try to forget about it.... > > The focus should be on cleaning up *that* code base, taking advantage > of what glib has to offer, rather than introducing more regressions in > the code. For this we have another option, the simplest of all: just include the whole glib as part of mc. BTW, we already have one 3rd party library (slang) included, and nobody complains about it. Alex From proski at gnu.org Sat Nov 15 04:36:21 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 14 Nov 2003 23:36:21 -0500 (EST) Subject: A proposal for Midnight Commander In-Reply-To: References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> Message-ID: Hello! I'm afraid I'll not be able to participate in this discussion until Monday, but let me reply to the last message in the thread. On Fri, 14 Nov 2003, Alexander Varakin wrote: > > > The remaining 30% of mc's glib code usage must be the list code, and I > think > > > the best way to handle it is just to use glib's implementation. > > > > The problem is wasting the time doing this. > > You should not worry about this. If this effort will be supported by > maintainers of mc , I and Ali will make the changes. It does not look like a > huge effort, couple of days max. > > The real problem is that many potential users try to install or build mc and > suddenly they realize that this small program requires a third party > library, maybe many of them. When something like this happens to me, I just > nuke such program and try to forget about it.... Maybe you should try a distribution with proper package management there installing a package is just a matter of running apt-get or yum. I believe we should not consider generic arguments against libraries. Even if such arguments exist, advantages are known to outweigh the inconvenience. Libraries exist, hence they are needed. There is a specific problem with glib 2.x, which is the fact that it relies on non-common infrastructure, such as pkg-config. I have voiced my concerns about it already. I believe that pkg-config should have been a script, not a C program. I do agree that glib 2.x is unnecessarily hard to compile on OSes without GNU tools preinstalled. But since glib 1.2.x is not going away, we can support it. Thanks to Miguel's clarification, I believe that glib is a good choice. > > The focus should be on cleaning up *that* code base, taking advantage > > of what glib has to offer, rather than introducing more regressions in > > the code. > > For this we have another option, the simplest of all: just include the > whole glib as part of mc. BTW, we already have one 3rd party library > (slang) included, and nobody complains about it. That's certainly an option worth considering. pkg-config itself includes glib 1.2.x to make it possible to bootstrap it. glib 1.2.x is not going to be developed, so we won't need any mergers or maintenance of the code. If everybody is happy with it, I think that's the direction we should follow. By the way (maybe this should be a separate thread), due to known security problems in VFS (not that we ever promised that VFS is secure) and data loss bug in the editor (Ctrl-g) fixed in CVS, I had to move most of the TODO list to "after 4.6.1". I'm really disappointed that many "must have" things have been shifted, but it's the best I can do. My definite plans before 4.6.1 are to fix the only known crash is the code (freeing extfs under extfs) and the regression caused by the removal of tilde expansion from VFS. The next step will be going trough the submitted patches and applying those that look safe. During that period, I'm ready to make large changes if they are unlikely to destabilize the code. That includes incorporating glib. Then there will be a testing period followed by the 4.6.1 release. -- Regards, Pavel Roskin From gabucino at mplayerhq.hu Sat Nov 15 07:43:20 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 08:43:20 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068750961.7607.9.camel@localhost> Message-ID: <20031115074320.GA1385@woodstock.localdomain> Koblinger Egmont wrote: > So IMHO there's absolutely nothing wrong with mc using glib. If there's Well I do have glib installed, but not glib2, nor do I plan to do so in the next 5 years, so don't make it mandatory. I don't like glib dependency at all, if I may add. How is mc gonna be ported to Minix, after all? :) -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gabucino at mplayerhq.hu Sat Nov 15 08:23:58 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 09:23:58 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <3FB54738.1090009@users.sourceforge.net> References: <1068827376.12105.28.camel@localhost> <3FB51A41.5050906@users.sourceforge.net> <1068834023.12912.10.camel@localhost> <3FB53FAA.2090304@users.sourceforge.net> <1068843398.3355.21.camel@localhost> <3FB54738.1090009@users.sourceforge.net> Message-ID: <20031115082358.GA10648@woodstock.localdomain> Nerijus Baliunas wrote: > Really? And to make it work with a lot of unices and their compilers? ;) I've installed mc (A'rpi's old 4.1 fork) on my QNX NTO 6 with no problems whatsoever. Then I tried to install glib (because irssi - which is a neat console IRC client - depends on it). glib didn't compile, and I couldn't get it to do so. -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gabucino at mplayerhq.hu Sat Nov 15 08:46:39 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 09:46:39 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <20031115082358.GA10648@woodstock.localdomain> References: <1068827376.12105.28.camel@localhost> <3FB51A41.5050906@users.sourceforge.net> <1068834023.12912.10.camel@localhost> <3FB53FAA.2090304@users.sourceforge.net> <1068843398.3355.21.camel@localhost> <3FB54738.1090009@users.sourceforge.net> <20031115082358.GA10648@woodstock.localdomain> Message-ID: <20031115084639.GB10648@woodstock.localdomain> Gabucino wrote: > I've installed mc (A'rpi's old 4.1 fork) on my QNX NTO 6 with no problems > whatsoever. FYI, I've just installed mc-4.1.40-pre8 on a Redhat 4.1 libc5 system, without gpm code: [root at woodstock /home]# ldd /usr/bin/mc libc.so.5 => /lib/libc.so.5.3.12 Why should I install glib..? :) -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gabucino at mplayerhq.hu Sat Nov 15 08:59:02 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 09:59:02 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> Message-ID: <20031115085902.GC10648@woodstock.localdomain> Alexander Varakin wrote: > Can't we just include glib (or part of it) as part of mc sources? Hey I'm having a breakfast right now, don't you ever scare me like that again!! -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From egmont at uhulinux.hu Sat Nov 15 12:31:38 2003 From: egmont at uhulinux.hu (Koblinger Egmont) Date: Sat, 15 Nov 2003 13:31:38 +0100 (CET) Subject: A proposal for Midnight Commander In-Reply-To: <1068865203.17998.16.camel@localhost> Message-ID: On Sat, 15 Nov 2003, Ali Akcaagac wrote: > I saw what Miguel replied to you and usually I have the tendency to > agree that re-using code is a nice thing. But Midnight Commander is not > big enough that it would justify it to depend on glib. For GUI material > e.g. a full Desktop Environment I would fullheartly agree anyday but not > for a console application. What benefits do you have when you are able > to shrink the size of Midnight Commander to around ~350kb but then on > the otherhand need a full blown Glib2 library with ~500kb only to use > the 5-6 functions required by Midnight Commander. I think that everybody > is going to agree here. No, not really :-))) IMHO code reusage isn't for saving some kilobytes of disk space, it's mainly for saving programmers' time and for having less bugs in the software. I agree with you that it wouldn't take so much time to kill all the glib stuff from mc _now_, but I even more agree with Miguel that a more intensive usage of glib functions might make mc cleaner and more bug-free, and IMHO this is the way to go. I'm nearly always using a normal system. I use rescue and similar minimal systems only several times a year. Yes, it'd nice to have mc there, but if it isn't, then I can cope with cp, mv..., no problem. So it's IMHO not worth to investigate too many work on making mc run on minimal systems. Which glib to use is a harder question, Gabucino votes for glib1, while I want to kill all the glib1 and gtk1 stuff from my system as soon as I can, and I'd rather use a new, actively maintained (and changing, doh!) code than an old, non maintained one. -- Egmont From aliakc at web.de Sat Nov 15 12:49:45 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 13:49:45 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: Message-ID: <1068900585.18353.14.camel@localhost> On Sat, 2003-11-15 at 13:31, Koblinger Egmont wrote: > more intensive usage of glib functions might make mc cleaner > and more bug-free, and IMHO this is the way to go. Assuming that glib itself is free of bugs - which you can't depend on. > Which glib to use is a harder question, Gabucino votes for glib1, > while I want to kill all the glib1 and gtk1 stuff from my system > as soon as I can, and I'd rather use a new, actively maintained Excuse me, in case I may repeat myself half a dozen times now. There are no large significant parts inside Midnight Commander that justifies it to use Glib2. It's not like you are removing 2000 lines of code within Midnight Commander and have it replaced with 1 line Glib2 code. The memory allocation/free calls are a good example. While they may check whether they could allocate the memory or could even free NULL they have no significant benefits over the calls made by glibc or the g_strdup vs. strdup calls. About Maintainance. If it wasn't possible to reduce all bugs until now after X years then something must have significant wrong. Maintainance of Glib2 on the otherhand makes you depend on other people. Say you detect a serious bug in Glib2 in an important function you use. You file a bugreport and then can start having painful discussions with the maintainers of Glib2. You first will get X times 'NOT A BUG' replies where your bug will be closed because they are trying to shift this problem back to you. After you got them convinced that this really is a bug, you then can continue having long conversations if the bugfix may break API or not and things like this, while on the otherhand you could have easily fixed your code within seconds in case something happened and commit it to your Midnight Commander CVS. I will give you a good example here http://bugzilla.gnome.org enter bugnumber #112806 and see yourself how many months it took until they fixed 2 lines within a Makefile to have the modules generated correctly in GTK+. Ok I don't want to blame anyone here but you were basically crying for good practical examples why to not use Glib2 (or Glib in general). I want to be more precise it's not about Glib2 vs. Glib1 it's about Glib in general here. From aliakc at web.de Sat Nov 15 13:12:22 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 14:12:22 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: Message-ID: <1068901942.18376.6.camel@localhost> On Sat, 2003-11-15 at 13:31, Koblinger Egmont wrote: > ... harder question, Gabucino votes for glib1 ... I doubt that he was 'voting' for glib1 here. From what I was able to read out of his replies was that he didn't liked the glib dependency at all and thus seeked for the less evil solution to get it operational. But my primarily intention was to add a note to my previous reply. About coding and maintainance. Today we are living in a world of powerful tools to do development. We have a good compiler collection we have that thing called 'debugger' we have nice time measuring tools like 'profiler' and some nice memoryleak checking tools such as 'valgrind'. From egmont at uhulinux.hu Sat Nov 15 13:25:01 2003 From: egmont at uhulinux.hu (Koblinger Egmont) Date: Sat, 15 Nov 2003 14:25:01 +0100 (CET) Subject: A proposal for Midnight Commander In-Reply-To: <1068900585.18353.14.camel@localhost> Message-ID: On Sat, 15 Nov 2003, Ali Akcaagac wrote: > Assuming that glib itself is free of bugs - which you can't depend on. Neither is glibc. > Excuse me, in case I may repeat myself half a dozen times now. There are > no large significant parts inside Midnight Commander that justifies it > to use Glib2. It's not like you are removing 2000 lines of code within > Midnight Commander and have it replaced with 1 line Glib2 code. The > memory allocation/free calls are a good example. While they may check > whether they could allocate the memory or could even free NULL they have > no significant benefits over the calls made by glibc or the g_strdup vs. > strdup calls. I exactly understand what you say, didn't say you're wrong in it. I agree that _currently_ mc doesn't use glib too much, it would be easy to remove glib stuff. I only disagree in the direction we should move to, I guess mc should move intensively take advantage of glib, instead of manually re-implementing everything in pure glibc. > About Maintainance. If it wasn't possible to reduce all bugs until now > after X years then something must have significant wrong. Maintainance > of Glib2 on the otherhand makes you depend on other people. Say you > detect a serious bug in Glib2 in an important function you use. You file > [...] Yes, there are bugs in glib1 and glib2. You may have bad experiences about glib development. But, on the other hand, glib is a layer that hides OS specific stuff, is able to workaround libc bugs, and provides a less OS dependant interface. There might be bugs in glib. You may report them. It's possible that it's fixed within a few hours. It's also possible that it's not touch for many months. But what do you do if you find a bug in glibc? Have you seen their bug tracking system? If you have, you wouldn't say any nasty words about gnome people. Glibc maintenance is terrible. I do have some bug reports pending both in the Gnome bugzilla and at the glibc folks, so I do have experiences... glibc's bugtracker system (gnats) has been down for many months when I reported my latest bug (I don't know if it's back alive), so I sent it to their bug mailing list. I keep on checking their archives. No reply, only 10 spam and 2 normal messages every day in the archive. It's impossible to work with such a system. Also see how often a new release of glib2 and glibc are out there, and how much compatibility issue they bring in. (Do you remember all the errno stuff with glibc 2.3.2 which broke many utilities building, and even broke wine runtime? Compared to this, marking some glib2 function as deprecated and removing them in one or two years is a fair thing.) What if you find a bug in glib2 that makes mc misbehave? You document that it's a glib bug, create a patch, put it into their bugzilla, and write in the documentation that glib2 needs to be patches. What if you find such a bug in libc? Do you tell the people to patch and recompile libc of this-and-that-particular-unix-like-system? So glib is IMHO no way worse than pure libc. Every software has bugs. If mc uses glib, it increases the probability that a glib bug will be caught, it'll be fixed and improve the quality of other software as well. -- Egmont From nerijus at users.sourceforge.net Sat Nov 15 13:26:30 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Sat, 15 Nov 2003 14:26:30 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068900585.18353.14.camel@localhost> References: <1068900585.18353.14.camel@localhost> Message-ID: <3FB62986.50108@users.sourceforge.net> (Pavel, please read my suggestion in the middle of the message) Ali Akcaagac wrote: > Assuming that glib itself is free of bugs - which you can't depend on. glib is used by probably thousands of projects, so logically it shouldn't contain lots of bugs, and bugs should be found quite fast. > Excuse me, in case I may repeat myself half a dozen times now. There are > no large significant parts inside Midnight Commander that justifies it > to use Glib2. Yes, but Pavel and Miguel want to increase these parts instead of removing them...;-) > After you got them convinced that this really is a > bug, you then can continue having long conversations if the bugfix may > break API or not and things like this, while on the otherhand you could > have easily fixed your code within seconds in case something happened > and commit it to your Midnight Commander CVS. Including glib in mc cvs tree should help in this case. OK, I have a suggestion: 1. Include glib in mc cvs. 2. Make it so that it should be possible to use either glib or libc functions (at configure time by ifdeffing etc). 3. Then there would be 3 choices - a) use system glib, b) use builtin glib, c) don't use glib at all (i.e. use libc or own functions). Maybe some features should be disabled in c) case. > I will give you a good example here http://bugzilla.gnome.org enter > bugnumber #112806 and see yourself how many months it took until they > fixed 2 lines within a Makefile to have the modules generated correctly > in GTK+. Well, I see Owen suggested you to try something, but you didn't - so why complain? See this: --Additional Comments From Owen Taylor 2003-06-08 I believe changing install-data-local to install-data-hook in gtk+/gdk-pixbuf/Makefile.am and gtk+/modules/input/Makefile.am will fix. Testing would be appreciated. install-data-hook is, of course, not right since the modules don't get installed in install-data. install-exec-hook should work. --Additional Comments From Ali Akcaagac 2003-06-30 Any future progress with this ? The problem still exists in current HEAD. You didn't even tell if you tried the suggestion, so why do you expect the problem to magically disappear? > Ok I don't want to blame anyone here but you were basically > crying for good practical examples why to not use Glib2 (or Glib in > general). It was bad example. Regards, Nerijus From gabucino at mplayerhq.hu Sat Nov 15 14:00:23 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 15:00:23 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068865203.17998.16.camel@localhost> Message-ID: <20031115140023.GA12536@woodstock.localdomain> Koblinger Egmont wrote: > Gabucino votes for glib1 No, I vote to no glib at all! A two panel filemanager doesn't need all these sophisticated stuff! Check Volkov Commander, it's a 64kb DOS COM executable (and imho it's much faster/stabler/better than mc, pity it's on DOS). But this argument is getting very very pointless, it seems Pavel apparently listens to noone, likes reinventing the wheel, dropping simple support for many OS'es, and his dictatoric means of maintaining resulted in the appearing of many mc forks... -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From aliakc at web.de Sat Nov 15 14:07:00 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 15:07:00 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <3FB62986.50108@users.sourceforge.net> References: <1068900585.18353.14.camel@localhost> <3FB62986.50108@users.sourceforge.net> Message-ID: <1068905219.18857.20.camel@localhost> On Sat, 2003-11-15 at 14:26, Nerijus Baliunas wrote: > You didn't even tell if you tried the suggestion, so why > do you expect the problem to magically disappear? Because, if I really need to investigate on my own fixing all the problems found in hundrets of apps then I probably require a fulltime job for doing so. Unfortunately I have also private life, own business and other things to care about. If the Maintainers of GTK+ for example not properly test their patches that they committ then it's far from my fault. All I can do is file a bug about it and hope that the experts on their area gonna fix the problem quickly. I explicitly say 'experts' here because they seem to understand their stuff from top to bottom. What do you expect next ? Should I investigate 2 weeks into Open Office and fix a bug ? First of all I don't even know how the heck Open Office code looks, like. Secondly I do not intend to fix such a bug on my own because I may be breaking stuff elsewhere. Last I do belive that the experts are more suited for this kind of task. > It was bad example. No, I think it was one example. The bug got marked 'NOT A BUG' within a couple of seconds after I filed it. I then opened it again and waited until someone else besides me could confirm it to be a bug, now that more GNOMER's jump on GTK HEAD this was the case. I think we should seriously concentrate on Midnight Commander again. All I can do is having normal conversation and try to convince people. I do not intend to get offensive, nor do I plan to be unfair. I brought up a lot of really good arguments. From gabucino at mplayerhq.hu Sat Nov 15 14:09:34 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 15:09:34 +0100 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068900585.18353.14.camel@localhost> Message-ID: <20031115140934.GB12536@woodstock.localdomain> Koblinger Egmont wrote: > So glib is IMHO no way worse than pure libc. Sorry Egmont, but this argument is pretty much braindead. Next time you'll be proposing encapsulating IPv4 data into an IPv4 tunnel... -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From nerijus at users.sourceforge.net Sat Nov 15 14:12:04 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Sat, 15 Nov 2003 15:12:04 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <20031115140023.GA12536@woodstock.localdomain> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> Message-ID: <3FB63434.3080508@users.sourceforge.net> Gabucino wrote: > No, I vote to no glib at all! A two panel filemanager doesn't need all these > sophisticated stuff! Check Volkov Commander, it's a 64kb DOS COM executable > (and imho it's much faster/stabler/better than mc, pity it's on DOS). Don't you think DOS is much simpler OS than UNIX (with all its flavours...) and mc has more features (only think about vfs...). > But this argument is getting very very pointless, it seems Pavel apparently > listens to noone, likes reinventing the wheel, dropping simple support for > many OS'es, and his dictatoric means of maintaining resulted in the > appearing of many mc forks... Please don't insult here. IIRC all forks started to appear before 4.5x, i.e. when gmc was started, quite a long time ago. Nerijus From aliakc at web.de Sat Nov 15 14:13:38 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 15:13:38 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <20031115140023.GA12536@woodstock.localdomain> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> Message-ID: <1068905618.18857.28.camel@localhost> On Sat, 2003-11-15 at 15:00, Gabucino wrote: > But this argument is getting very very pointless, it seems Pavel > apparently listens to noone, likes reinventing the wheel, dropping > simple support for many OS'es, and his dictatoric means of main- > taining resulted in the appearing of many mc forks... Sadly but true. I can tell you that within the past 2 days a bunch of private emails showed up in my mailbox from people who fullheartly agree with my raised points and with my proposal in general. I have been trying to do my best to convince the authority of this list to have a fruitable change within Midnight Commander. I was kinda polite and raised good examples. I do see that this Mailinglist has no special purpose at all because 'no one cares a shit' for the opinion of other people. It's just another USERS Mailinglist where unwanted people participate for one persons entertainment. I dislike doing another fork and I do belive that this can easy be done in the core of Midnight Commander but doing this requires people to participate and a maintainer who is open to other people. Arpi, Oleg, you, me and I bet my pants that there are others as well see this differently. We see a big problem here - not software technically but more - people technically, thus I now need to raise a proposal to fork from the current MC CVS branch and create a new mainstream. From nerijus at users.sourceforge.net Sat Nov 15 14:32:07 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Sat, 15 Nov 2003 15:32:07 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068905219.18857.20.camel@localhost> References: <1068900585.18353.14.camel@localhost> <3FB62986.50108@users.sourceforge.net> <1068905219.18857.20.camel@localhost> Message-ID: <3FB638E7.1030909@users.sourceforge.net> It is my last message as it's offtopic here. Ali Akcaagac wrote: >>You didn't even tell if you tried the suggestion, so why >>do you expect the problem to magically disappear? > > Because, if I really need to investigate on my own fixing all the > problems found in hundrets of apps then I probably require a fulltime > job for doing so. Trying one thing was really *so* hard for you? Owen didn't have that problem on his system, and suggested to try simple fix, still you didn't. And you are the author of CVSGnome Build Script, so you are presumably very good at gnome building. Do you really expect everyone to fix bugs (even their own bugs) fast when you are not even trying to help? I did expect very long time ago, but not anymore. It is not an ideal world. Owen also has private life, and he runs a lot of projects besides gnome-build. > Unfortunately I have also private life, own business > and other things to care about. If the Maintainers of GTK+ for example > not properly test their patches that they committ then it's far from my > fault. All I can do is file a bug about it and hope that the experts on > their area gonna fix the problem quickly. I explicitly say 'experts' I don't see why your reported bugs should be fixed quickly. Look at all of the big projects bugzillas, they have unfixed bugs from a few years ago. Such is life... > here because they seem to understand their stuff from top to bottom. > What do you expect next ? Should I investigate 2 weeks into Open Office > and fix a bug ? First of all I don't even know how the heck Open Office > code looks, like. Sorry, you wrote nonsense. Noone speaks about openoffice or mozilla. You were asked to try simple one line fix, as presumably Owen didn't have that problem on his system, he could only verify that fix, if it works for you, also doesn't break anything on his system. I understand you were insulted by that NOTABUG thing, but I still think it was a bad example (you even knew a workaround, so this was really a non critical bug). To decide from such a bug that glib is not suitable for mc is nonsense IMHO. Sorry again for this offtopic, Nerijus From aliakc at web.de Sat Nov 15 14:38:45 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 15:38:45 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <3FB638E7.1030909@users.sourceforge.net> References: <1068900585.18353.14.camel@localhost> <3FB62986.50108@users.sourceforge.net> <1068905219.18857.20.camel@localhost> <3FB638E7.1030909@users.sourceforge.net> Message-ID: <1068907125.18857.36.camel@localhost> On Sat, 2003-11-15 at 15:32, Nerijus Baliunas wrote: > Sorry again for this offtopic, The first valuable sentence from you - congratulations. I was already up to ask what crackpipe you were sniffing at. But I'm not the guy slandering people on their back. Listen - I was trying to raise a proposal which I do belive in. I think you are not the person suitable for such a technically conversation and I seriously wonder why you are subscribed to a development mailinglist. The purpose and aim of such a list is to raise proposals or talk about technical stuff in general and not driving a campaign on other people to find weaknesses on their personality rather than on the point of topic, which is Midnight Commander and the dependency of Glib. If you have nothing productive to add then please do not reply. If you plan to make me look like a fool then I need to suggest that you gonna search someone else for this. greetings. From arpi at mplayerhq.hu Sat Nov 15 16:07:08 2003 From: arpi at mplayerhq.hu (Arpi) Date: Sat, 15 Nov 2003 17:07:08 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <20031115140023.GA12536@woodstock.localdomain> Message-ID: <200311151607.hAFG78HJ014630@mail.mplayerhq.hu> Hi, > Koblinger Egmont wrote: > > Gabucino votes for glib1 > No, I vote to no glib at all! A two panel filemanager doesn't need all these > sophisticated stuff! Check Volkov Commander, it's a 64kb DOS COM executable > (and imho it's much faster/stabler/better than mc, pity it's on DOS). > > But this argument is getting very very pointless, it seems Pavel apparently > listens to noone, likes reinventing the wheel, dropping simple support for > many OS'es, and his dictatoric means of maintaining resulted in the > appearing of many mc forks... Ok, I think it's time to comment on this thread. I've just ran through this thread, read the most, but not all mails, sorry it's way too much offtopic and flame and PR text. As I already told in private to Ali, my opinion on these: glib issue: i don't care of glib, at all. first when i noticed it in 4.6, i didnt liked it, but i can understand and accept that it simplifies mc code, and moves some bugfixing and maintaince and porting work to the glib team. i will like if glib is removed, but i don't mind if it remains there. anyway i'm against including glib as-is in mc source,it's total nonsence. i'm not against code sharing, it's a good thing, if it's well done. (and no, i won't work on glib removal of 4.6, i simply has no time for something i don't care.) forks: since i'm "owning" 2 of them (4.1.35-Axx series and amc-4.6 cvs), i can't simply say here that i don't like them :) but the reason of forking wa snot glib at all. it was gnome (!=glib) in case of 4.1.35-Axx, and other buggy broken bloat in 4.5.xx series. when i did that fork, there was no 4.6 (at least i wasn't aware of it), and the 4.5.x series was so broken to be totaly unusable, and does not worth to fix it. i've worked a lot on the -Axx fork, to fix known bugs, add most-wanted features and fix VFS/extfs drivers, especially the oh-so-broken FTPfs. then i stopped that work, due to MPlayer project and other works. the next fork, amc-4.6 was done after 4.6.0 release, due to my patch sets for 4.6.0 being rejected by maintainer with no (or not acceptable) reasons. but i want to note, that i have nothing bad with current 4.6.x maintainer(s), i see and can accept that he tries to keep the baseline mc code as clean as possible, and fix all issues and remove obsolete code before starting (re-)adding funcy features. i should have done the same with mplayer years ago, keep it clean, and refuse all feature patches until the code is cleaned up and bugfree. (so i could avoid restarting from scratch nowdays, with mplayer-g2...) but it isn't so simple, there is a big demand from users for new features, so we must either accept these patches for the mainstream code, or make a fork which focuses on features instead of cleaness and bugfixes. such fork can be the testbed for such patches, before they gets accepted for the mainstream code. this is teh reason, why i made amc-4.6, to accept and test verious patches being refused from mainstream code. unfortunatelly i was too busy to work on this fork, or even maintain it, so it died as fast as it born. i was recently told about a new fork, the mc-mp (aka 4.1.40-preXX). it is said to be based on my 4.1.35-A12 code, but i miss many of the featuers and fixes i made in -A12 from it, so maybe it isn't true. (anyway it should be true, as some of my code is there in mc-mp, even if it doesnt work due to other changes...) also, it has a strong DN (dos navigator, some of you maybe remember that old thing, ran by people on dos who didnt like (the imho much better, and less bloated) volkov commander) feeling, especially in colors and some fancy features (like clock in the corner etc). even with -Y option it still has unusual look-and-feel compared to mc or vc or nc. besides of that, it's a nice try, i like it. it is based on 4.1.x series, but has the good parts of 4.6 backported, like the builtin df and find-file code, and the editor. the vfs code is based on teh old API, which works better (imho) for non-local filesystems than the 4.6 one. (remember, i failed to port my ftpfs fixes to 4.6, due to new api lacking some basic features) also, the mc-mp maintainer guy said something (i dont know that code, so i cant decide) about the new dialog boxes code being much worse in 4.6. btw, could someone list the features and advantages of 4.6.x over the 4.1.x series (release or the forks: 4.1.35-Axx or 4.1.40/mc-mp) ? i'm interested in both code-level (internals) and user-level (features). i think it's a very important information for the decision, so we can see if it does worth to work on mc-mp (and backport interesting things from 4.6) or it's better to port -Axx and mc-mp features to 4.6-based fork (be it amc-4.6 or make another). some time ago (2003 spring) i thought the second is better, but after checking the mc-mp, and talking with his author i'm unsure now. what i saw in 4.6 was some API changed, heavy usage of linked lists, internal types and other OOP things make it less readable. it wouldnt be a problem alone, if i see same amount (or more) advantages of 4.6, to balance it. but it seems the interesting features of 4.6 (over 4.1) were easy to backport to 4.1, so why bother with 4.6 any more?? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu From miguel at ximian.com Sat Nov 15 17:19:05 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 15 Nov 2003 12:19:05 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <20031115140934.GB12536@woodstock.localdomain> References: <1068900585.18353.14.camel@localhost> <20031115140934.GB12536@woodstock.localdomain> Message-ID: <1068916745.24775.97.camel@erandi.boston.ximian.com> Hello, > > So glib is IMHO no way worse than pure libc. > Sorry Egmont, but this argument is pretty much braindead. > Next time you'll be proposing encapsulating IPv4 data into an IPv4 tunnel... There is no need to be insulting on the mailing list. I agree with him. If you do not agree with either of us, present your case, but mocking someone up is not a way of gaining your peer's respect. Miguel. From miguel at ximian.com Sat Nov 15 17:24:22 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 15 Nov 2003 12:24:22 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <20031115140023.GA12536@woodstock.localdomain> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> Message-ID: <1068917062.24775.103.camel@erandi.boston.ximian.com> Hello, > > Gabucino votes for glib1 > No, I vote to no glib at all! A two panel filemanager doesn't need all these > sophisticated stuff! Check Volkov Commander, it's a 64kb DOS COM executable > (and imho it's much faster/stabler/better than mc, pity it's on DOS). > > But this argument is getting very very pointless, it seems Pavel apparently > listens to noone, likes reinventing the wheel, dropping simple support for > many OS'es, and his dictatoric means of maintaining resulted in the > appearing of many mc forks... MC is a 550k file manager, with tons of external features from libc, libgpm and libncurses. If you want a 64k file manager, feel free to rewrite it from scratch in assembly. C is just not the language to get those savings. And if you dont like Pavel's position, you can fork the code base, and have your e733T file manager, we in the free software world enable everyone to do this. Miguel. From miguel at ximian.com Sat Nov 15 17:29:17 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 15 Nov 2003 12:29:17 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <20031115140023.GA12536@woodstock.localdomain> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> Message-ID: <1068917356.24775.109.camel@erandi.boston.ximian.com> Hello, > But this argument is getting very very pointless, it seems Pavel apparently > listens to noone, likes reinventing the wheel, dropping simple support for > many OS'es, and his dictatoric means of maintaining resulted in the > appearing of many mc forks... And please stop the name calling, you have been treated with respect here, we expect at least that from you. Maintainers do not do everything contributors want for a variety of reasons: Yes, your idea might be great, and might save us 40k of code, and might enable a floppy-installation of mc. But the maintainer has to carry-on, fixing bugs, improving the code, understanding the code. Not everyone has the same goals, some people want features, some people want to fit things in a 64k segment. I already pointed out to Linux. Few people run "stock" Linux, most people run a distro-fork-Linux. There is nothing wrong with that. Try to get Linus to add ifdefs support for the PalmPilot on the main kernel. Miguel From gabucino at mplayerhq.hu Sat Nov 15 16:30:44 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 17:30:44 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068917062.24775.103.camel@erandi.boston.ximian.com> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> <1068917062.24775.103.camel@erandi.boston.ximian.com> Message-ID: <20031115163044.GA30077@woodstock.localdomain> Miguel de Icaza wrote: > MC is a 550k file manager, with tons of external features from libc, > libgpm and libncurses. Exactly, and there is absolutely no need, nor reason to increase dependency list with glib/gnome/whatever, you name it. > have your e733T file manager, we in the free software world enable Simple != elite, you know. And don't Cc: me, I'm subscribed (what a surprise). -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From aliakc at web.de Sat Nov 15 16:55:08 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 17:55:08 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068917356.24775.109.camel@erandi.boston.ximian.com> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> <1068917356.24775.109.camel@erandi.boston.ximian.com> Message-ID: <1068915308.19238.6.camel@localhost> On Sat, 2003-11-15 at 18:29, Miguel de Icaza wrote: > Not everyone has the same goals, some people want features, > some people want to fit things in a 64k segment. I think this is getting worse now. We shouldn't move in a gray corner here by itching people. Regardless who started it, we are only talking about software here. > I already pointed out to Linux. Few people run "stock" Linux, most > people run a distro-fork-Linux. There is nothing wrong with that. - And again some are trying to manifest Microsoft innovations on Linux, but most people already mentioned how much they dislike it. - Some people are using blog entries to write 20 pages about their business product + code examples to manifest Microsoft innovations, but most people use blogs to describe their daily feelings. - Some companies are trying to sell GNOME as their product, but most individuals are working on it as individuals in their spare time. What an illusion... isn't it ? No bad feelings but I think we should play fair again and concentrate on what's important. After all we are pro Midnight Commander users, we do like it, thus we do like to improve it. That people have different opinions is nothing new. From miguel at ximian.com Sat Nov 15 18:11:15 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 15 Nov 2003 13:11:15 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <1068915308.19238.6.camel@localhost> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> <1068917356.24775.109.camel@erandi.boston.ximian.com> <1068915308.19238.6.camel@localhost> Message-ID: <1068919874.24775.119.camel@erandi.boston.ximian.com> Hello, > > I already pointed out to Linux. Few people run "stock" Linux, most > > people run a distro-fork-Linux. There is nothing wrong with that. > > - And again some are trying to manifest Microsoft innovations on Linux, > but most people already mentioned how much they dislike it. > > - Some people are using blog entries to write 20 pages about their > business product + code examples to manifest Microsoft innovations, but > most people use blogs to describe their daily feelings. > > - Some companies are trying to sell GNOME as their product, but most > individuals are working on it as individuals in their spare time. I see you could not resist the urge of bringing your flames from another forum here. If you do not like my blog Ali, do not read it. It is as simple as that. If you disagree with my vision for making Linux more ubiquitous, feel free to build and construct your own vision, be constructive, do something about it. Miguel. From aliakc at web.de Sat Nov 15 17:21:32 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 18:21:32 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068919874.24775.119.camel@erandi.boston.ximian.com> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> <1068917356.24775.109.camel@erandi.boston.ximian.com> <1068915308.19238.6.camel@localhost> <1068919874.24775.119.camel@erandi.boston.ximian.com> Message-ID: <1068916892.19279.7.camel@localhost> On Sat, 2003-11-15 at 19:11, Miguel de Icaza wrote: > I see you could not resist the urge of bringing your flames from > another forum here. Excuse me, this wasn't about flames. I wanted only to show you the irony in your own previous writing. You are not the only one being able to juggle with the tongue. My main message is, the same way you are trying to manifest your opinion and your vision in the public the same way I and others are trying to manifest our opinion in the public. Only difference is that we are causing less harassment. We are not trying to manifest drastical changes, we are just talking about using 5 alternative functioncalls from glibc rather than glib, the dimensions are quite different. greetings. From miguel at ximian.com Sat Nov 15 18:44:22 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 15 Nov 2003 13:44:22 -0500 Subject: A proposal for Midnight Commander In-Reply-To: References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> Message-ID: <1068921862.24775.141.camel@erandi.boston.ximian.com> Hello Pavel, > There is a specific problem with glib 2.x, which is the fact that it > relies on non-common infrastructure, such as pkg-config. I have voiced my > concerns about it already. I believe that pkg-config should have been a > script, not a C program. I do agree that glib 2.x is unnecessarily hard > to compile on OSes without GNU tools preinstalled. > > But since glib 1.2.x is not going away, we can support it. Thanks to > Miguel's clarification, I believe that glib is a good choice. My personal vote would go for Glib 2.x. Even if it is slightly harder to build on old systems, it is becoming more and more ubiquitous everywhere: * Solaris ship with this, and MacOS will have to ship it as part of their X distro to support fontconfig. * Every Linux system that uses Freedesktop.org or Gnome will have it (Cairo, Fontconfig, depend on it anyways). * Every installation where Mozilla runs will have it too. I know it is very desktop-centric, but pkg-config fixes a long standing problem in the Unix world: how to detect, use and consume libraries easily. And glib 2 provides a lot nicer IO support (the kind that would be nice to replace the stuff in key.c). Miguel From gabucino at mplayerhq.hu Sat Nov 15 18:40:24 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 19:40:24 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068921862.24775.141.camel@erandi.boston.ximian.com> References: <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> <1068921862.24775.141.camel@erandi.boston.ximian.com> Message-ID: <20031115184024.GB30400@woodstock.localdomain> Miguel de Icaza wrote: > My personal vote would go for Glib 2.x. Even if it is slightly harder > to build on old systems, it is becoming more and more ubiquitous > everywhere: Sure, let's depend on XFree86 4.3 too, it's getting more and more ubiquitous everywhere. > * Solaris ship with this, and MacOS will have to ship it as > part of their X distro to support fontconfig. I don't have solaris, nor macos. > * Every Linux system that uses Freedesktop.org or Gnome will > have it (Cairo, Fontconfig, depend on it anyways). I don't use either of these. > * Every installation where Mozilla runs will have it too. I use Opera. Anyway afair mozilla is distributed in a static binary. > I know it is very desktop-centric Do you really suppose this desktop-centric user will mess with a console filemanager with keyboard controls? > but pkg-config fixes a long standing problem in the Unix world: how to > detect, use and consume libraries easily. Sure. Ever tried to compile some pkgconfig-user program in "userspace", eg both with --prefix=/home/anywhere ? It won't work. Only as root, and /usr. So much for fixing long standing problems. (try sidplay2-lib and sidplay2 packages for example) -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From miguel at ximian.com Sat Nov 15 19:53:50 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 15 Nov 2003 14:53:50 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <20031115184024.GB30400@woodstock.localdomain> References: <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> <1068921862.24775.141.camel@erandi.boston.ximian.com> <20031115184024.GB30400@woodstock.localdomain> Message-ID: <1068926030.13814.11.camel@erandi.boston.ximian.com> Hello, > > My personal vote would go for Glib 2.x. Even if it is slightly harder > > to build on old systems, it is becoming more and more ubiquitous > > everywhere: > Sure, let's depend on XFree86 4.3 too, it's getting more and more > ubiquitous everywhere. Glib is a core dependency for many projects. X is a large windowing system. I am trying to have a technical discussion and respectful to you. > > * Solaris ship with this, and MacOS will have to ship it as > > part of their X distro to support fontconfig. > I don't have solaris, nor macos. Those were examples of systems outside of the open source world that *might* be considered non GNU-toolchain compliant, and where the major objection to use pkg-config might come from. If you are using Linux, you probably already have glib installed. If you do any kind of development in any of the new projects, you probably also have pkg-config. > > but pkg-config fixes a long standing problem in the Unix world: how to > > detect, use and consume libraries easily. > Sure. Ever tried to compile some pkgconfig-user program in "userspace", eg > both with --prefix=/home/anywhere ? It won't work. Only as root, and /usr. > So much for fixing long standing problems. (try sidplay2-lib and sidplay2 > packages for example) I use software in /usr/local, /mono, /install, /miguel, /toys and /usr, and they all work fine. Hint: man pkg-config Reading the man page instead of flaming will not hurt you. Miguel. From miguel at ximian.com Sat Nov 15 19:54:34 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 15 Nov 2003 14:54:34 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <20031115163044.GA30077@woodstock.localdomain> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> <1068917062.24775.103.camel@erandi.boston.ximian.com> <20031115163044.GA30077@woodstock.localdomain> Message-ID: <1068926073.13814.13.camel@erandi.boston.ximian.com> Hello, > > MC is a 550k file manager, with tons of external features from libc, > > libgpm and libncurses. > Exactly, and there is absolutely no need, nor reason to increase > dependency list with glib/gnome/whatever, you name it. I was very clear: glib. not gnome. Avoid using FUD-y arguments to make your point. Miguel From aliakc at web.de Sat Nov 15 19:05:15 2003 From: aliakc at web.de (Ali Akcaagac) Date: Sat, 15 Nov 2003 20:05:15 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <20031115184024.GB30400@woodstock.localdomain> References: <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> <1068921862.24775.141.camel@erandi.boston.ximian.com> <20031115184024.GB30400@woodstock.localdomain> Message-ID: <1068923114.19471.16.camel@localhost> On Sat, 2003-11-15 at 19:40, Gabucino wrote: > > but pkg-config fixes a long standing problem in the Unix > > world: how to detect, use and consume libraries easily. > Sure. Ever tried to compile some pkgconfig-user program in > "userspace", eg both with --prefix=/home/anywhere ? It won't > work. Only as root, and /usr. So much for fixing long standing > problems. (try sidplay2-lib and sidplay2 packages for example) Actually it works in the --prefix=/home/ directory. You can take my word on this because I'm dealing with GNOME installations defacto every day due to CVSGnome which I wrote. But you are partially right a coin usually has 2 sides so does pkgconfig. While it does solve some things about easier configuration it also increases complexity. a) it's another program, which embedds an old glib 1.2.x inside it. b) you are not dealing with *-config files anymore but you are now dealing with all types of spread 'pkgconfig' directory paths. Example: Say you compile some stuff in /opt/ and you see that it adds .pc files into /opt//lib/pkgconfig then you need to take care of this directory because pkgconfig doesn't know of this directory unless it's compiled in the same prefix. Let's assume here that pkgconfig has it's prefix in /usr/local. Now you need to make pkgconfig know about the new /opt//lib/pkgconfig dir so you need to add this path to the PKG_CONFIG_PATH export PKG_CONFIG_PATH="/opt//lib/pkgconfig:$PKG_CONFIG_PATH" Now you see in more recent installations of XFree that it also created a directory in /usr/X11R6/lib/pkgconfig. Thus you need to add this prefix to the PKG_CONFIG_PATH searchpath as well so pkgconfig realizes that there are .pc files as well thus you line looks like this. export PKG_CONFIG_PATH="/opt//lib/pkgconfig:/usr/X11R6/lib/pkgconfig:$PKG_CONFIG_PATH" Now many core system libraries are moving to /usr these days and you guessed it, some of these things create a /usr/lib/pkgconfig directory so your line looks like this. export PKG_CONFIG_PATH="/opt//lib/pkgconfig:/usr/X11R6/lib/pkgconfig:/usr/lib/pkgconfig:$PKG_CONFIG_PATH" This was not required with the old *-config files because they were always found in the suitable binary PATHS. I do see benefits of using pkgconfig - as I'm using it in my own stuff, but it would be a big lie denying other problems that have shown up with it. And yes, I think that spreading the word 'freedesktop.org' and making a defacto standard out of it is plain wrong. I am not against new technology. I do like the people participating in their IRC channel and we have a good harmony of conversations there. But showing up on all places and say 'freedesktop.org' is a standard is not the right thing and people doing this are taking out (?) a lot by doing so. I also belive, with respect to open source and the capabilities of their developers. That expecting glib to be found on every plattform is - like taking away individuality of these plattforms. The individuality of MacOSX, QNX, MorphOS etc. should be kept as is. There has been a reason for these developers to make exactly such an Operating System. Because they plan to be different. If there is no individuality anymore in computer business then where will we find ourselves pretty soon ? Say people who do not like GNOME or KDE, they are forced to use their libraries. They plan to escape to QNX because they think they can benefit from PROTON and Neutrino and what do they find. All these lame ports. They then escape to the quite expensive Machintosh architecture and find them caught in the same situation using the libraries they wanted to escape from. Again I'm not criticising these technologies. I do use many of these libraries myself. They should be used where they belong to and nowhere else. I am heavily critcising people who repeat these things more and more until the last one belives it. I for my own think this is encforcing wrong facts on peoples mind. greetings. From gabucino at mplayerhq.hu Sat Nov 15 22:19:58 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 23:19:58 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068926073.13814.13.camel@erandi.boston.ximian.com> References: <1068865203.17998.16.camel@localhost> <20031115140023.GA12536@woodstock.localdomain> <1068917062.24775.103.camel@erandi.boston.ximian.com> <20031115163044.GA30077@woodstock.localdomain> <1068926073.13814.13.camel@erandi.boston.ximian.com> Message-ID: <20031115221958.GA31142@woodstock.localdomain> Miguel de Icaza wrote: > > > MC is a 550k file manager, with tons of external features from libc, > > > libgpm and libncurses. > > Exactly, and there is absolutely no need, nor reason to increase > > dependency list with glib/gnome/whatever, you name it. > I was very clear: glib. not gnome. I know what glib and gnome are. One thing is common: both are unneeded here. > Avoid using FUD-y arguments to make your point. Please understand: don't Cc me ;) -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gabucino at mplayerhq.hu Sat Nov 15 22:37:19 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sat, 15 Nov 2003 23:37:19 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068926030.13814.11.camel@erandi.boston.ximian.com> References: <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> <1068921862.24775.141.camel@erandi.boston.ximian.com> <20031115184024.GB30400@woodstock.localdomain> <1068926030.13814.11.camel@erandi.boston.ximian.com> Message-ID: <20031115223719.GB31142@woodstock.localdomain> Miguel de Icaza wrote: > Glib is a core dependency for many projects. X is a large windowing > system. > I am trying to have a technical discussion and respectful to you. Thanks. However, I've been using mc (except >=4.5) for about 7 years without glib dependency, and I see not a single reason to just let that dependancy occur. or evolve to a higher degree. > If you are using Linux, you probably already have glib installed. If > you do any kind of development in any of the new projects, you probably > also have pkg-config. I do have glib. I do have pkgconfig. I don't have anything against glib _in general_, but pkgconfig is a braindead idea. Especially in its current, binary form. > I use software in /usr/local, /mono, /install, /miguel, /toys and /usr, > and they all work fine. Hint: man pkg-config Yes, I have to compile and install pkgconfig too. Idiocry. And it's also offtopic here. -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From egmont at uhulinux.hu Sat Nov 15 22:42:11 2003 From: egmont at uhulinux.hu (Koblinger Egmont) Date: Sat, 15 Nov 2003 23:42:11 +0100 (CET) Subject: A proposal for Midnight Commander In-Reply-To: <1068923114.19471.16.camel@localhost> Message-ID: On Sat, 15 Nov 2003, Ali Akcaagac wrote: > export PKG_CONFIG_PATH="/opt//lib/pkgconfig:$PKG_CONFIG_PATH" > > Now you see in more recent installations of XFree that it also created a > directory in /usr/X11R6/lib/pkgconfig. Thus you need to add this prefix > to the PKG_CONFIG_PATH searchpath as well so pkgconfig realizes that > there are .pc files as well thus you line looks like this. > > export > PKG_CONFIG_PATH="/opt//lib/pkgconfig:/usr/X11R6/lib/pkgconfig:$PKG_CONFIG_PATH" > > Now many core system libraries are moving to /usr these days and you > guessed it, some of these things create a /usr/lib/pkgconfig directory > so your line looks like this. > > export > PKG_CONFIG_PATH="/opt//lib/pkgconfig:/usr/X11R6/lib/pkgconfig:/usr/lib/pkgconfig:$PKG_CONFIG_PATH" > > This was not required with the old *-config files because they were > always found in the suitable binary PATHS. I do see benefits of using > pkgconfig - as I'm using it in my own stuff, but it would be a big lie > denying other problems that have shown up with it. What do you mean by suitable binary PATH? Every time a new directory needs to be put into PKG_CONFIG_PATH, most likely a counterpart of that directory needs to be put into LD_LIBRARY_PATH or /etc/ld.so.conf, and often PATH needs to be adjusted, too. As a result, so far you had to maintain a directory listing at two different places, now you have to do at three. I see absolutely no problem here. Most likely the very same engine that is managing your PATH or /etc/ld.so.conf can also be used to manage PKG_CONFIG_PATH. -- Egmont From miguel at ximian.com Sun Nov 16 02:16:30 2003 From: miguel at ximian.com (Miguel de Icaza) Date: 15 Nov 2003 21:16:30 -0500 Subject: A proposal for Midnight Commander In-Reply-To: <20031115223719.GB31142@woodstock.localdomain> References: <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> <1068921862.24775.141.camel@erandi.boston.ximian.com> <20031115184024.GB30400@woodstock.localdomain> <1068926030.13814.11.camel@erandi.boston.ximian.com> <20031115223719.GB31142@woodstock.localdomain> Message-ID: <1068948989.13814.16.camel@erandi.boston.ximian.com> Hello, > > Glib is a core dependency for many projects. X is a large windowing > > system. > > I am trying to have a technical discussion and respectful to you. > Thanks. However, I've been using mc (except >=4.5) for about 7 years without > glib dependency, and I see not a single reason to just let that dependancy > occur. or evolve to a higher degree. > > > > If you are using Linux, you probably already have glib installed. If > > you do any kind of development in any of the new projects, you probably > > also have pkg-config. > I do have glib. I do have pkgconfig. I don't have anything against glib > _in general_, but pkgconfig is a braindead idea. Especially in its current, > binary form. > > > > I use software in /usr/local, /mono, /install, /miguel, /toys and /usr, > > and they all work fine. Hint: man pkg-config > Yes, I have to compile and install pkgconfig too. Idiocry. And it's also > offtopic here. Well, now I know why people think you are an imbecile. Miguel. From gabucino at mplayerhq.hu Sun Nov 16 08:00:47 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sun, 16 Nov 2003 09:00:47 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068948989.13814.16.camel@erandi.boston.ximian.com> References: <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> <1068921862.24775.141.camel@erandi.boston.ximian.com> <20031115184024.GB30400@woodstock.localdomain> <1068926030.13814.11.camel@erandi.boston.ximian.com> <20031115223719.GB31142@woodstock.localdomain> <1068948989.13814.16.camel@erandi.boston.ximian.com> Message-ID: <20031116080047.GA1229@woodstock.localdomain> Miguel de Icaza wrote: > Well, now I know why people think you are an imbecile. Good for you. However, you're still fuckin' Cc:-ing me, do you even know what it is? -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gabucino at mplayerhq.hu Sun Nov 16 08:05:58 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sun, 16 Nov 2003 09:05:58 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <1068948989.13814.16.camel@erandi.boston.ximian.com> References: <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> <1068921862.24775.141.camel@erandi.boston.ximian.com> <20031115184024.GB30400@woodstock.localdomain> <1068926030.13814.11.camel@erandi.boston.ximian.com> <20031115223719.GB31142@woodstock.localdomain> <1068948989.13814.16.camel@erandi.boston.ximian.com> Message-ID: <20031116080558.GB1229@woodstock.localdomain> Miguel de Icaza wrote: > Well, now I know why people think you are an imbecile. Anyway, instead of calling me an imbecile, you should prove my being wrong, and you being right, just like civilized dudes do. Your lack of behaviour is not my failure, no matter how hard you try belittling me. So stop the flame and act like a normal guy. If you can't do that, please do not reply to this thread... -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gabucino at mplayerhq.hu Sun Nov 16 16:27:39 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sun, 16 Nov 2003 17:27:39 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <016d01c3ac5a$cd78b560$0200a8c0@wsl3> References: <20031116080047.GA1229@woodstock.localdomain> <016d01c3ac5a$cd78b560$0200a8c0@wsl3> Message-ID: <20031116162739.GA14574@woodstock.localdomain> William Scott Lockwood III wrote: > Jesus, you're an asshole. I think everyone should CC you until you go away. That was a valuable comment. -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gabucino at mplayerhq.hu Sun Nov 16 17:55:25 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sun, 16 Nov 2003 18:55:25 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <017c01c3ac60$a24848f0$0200a8c0@wsl3> References: <20031116162739.GA14574@woodstock.localdomain> <017c01c3ac60$a24848f0$0200a8c0@wsl3> Message-ID: <20031116175525.GA26750@woodstock.localdomain> William Scott Lockwood III wrote: > Here's an idea - you go to your room, and take a nap. When you come out, you > play nice with the other boys, or I'll tell Mommy on you, and she'll take > your computer away again. I can't expect more from someone who has 6 lines of unusable signature, and attaches the whole mail which he has just replied - and at the same time he's against HTML mails. -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gabucino at mplayerhq.hu Sun Nov 16 18:53:47 2003 From: gabucino at mplayerhq.hu (Gabucino) Date: Sun, 16 Nov 2003 19:53:47 +0100 Subject: A proposal for Midnight Commander In-Reply-To: <002101c3ac6c$385b2a50$0200a8c0@wsl3> References: <20031116175525.GA26750@woodstock.localdomain> <002101c3ac6c$385b2a50$0200a8c0@wsl3> Message-ID: <20031116185347.GA29499@woodstock.localdomain> William Scott Lockwood III wrote: > I think if there is anyone we can't expect much from, it's you - and with > that, I'm done. Welcome to my mail filter. At least he seems to be stopped quoting whole mails :P -- Gabucino MPlayer Core Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From andrew at email.zp.ua Mon Nov 17 15:51:28 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 17 Nov 2003 17:51:28 +0200 (EET) Subject: undelfs warnings fix In-Reply-To: Message-ID: <200311171551.hAHFpSxO056833@email.zp.ua> > On Fri, 14 Nov 2003, Andrew V. Samoilov wrote: > > > Previous patch implementation breaks mcfs compilation, and as I understood > > recently current implementation of com_err() is wrong and have format string > > vulnerability. > > > > New implementation fixes com_err() and does not define free, sorry about > > glib and libc memory allocation function mix, but we have it for glib 1.2x. > > already. > > Applied. Thank you! The mix is unavoidable, but glib 1.2.x always uses > libc memory allocation. Thanks! I hope this is last iteration for com_err() - va_list must be first local variable in function, now call to com_err() hangs mc. Sorry for lack of testing. -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: undelfs.c.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ChangeLog.patch URL: From biro_arpad at yahoo.com Sun Nov 16 17:52:44 2003 From: biro_arpad at yahoo.com (Arpad Biro) Date: Sun, 16 Nov 2003 09:52:44 -0800 (PST) Subject: Fast horizontal scrolling in viewer Message-ID: <20031116175244.58452.qmail@web13701.mail.yahoo.com> Hi, There is a feature that IMHO is missing from MC: fast horizontal scrolling in the internal viewer (by which I mean: scrolling by, say, 10 chars horizontally). It seemed to be easy to hack this in, so I made a patch that does just that. With the patch, Ctrl+Left scrolls left by 10 chars and Ctrl+Right scrolls right by the same amount. I have not thoroughly investigated MC code, so the patch may not be up to MC standards. If it is not, then take this as a feature request. The patch was tested on Linux and seems to work. The patch was made against the mc-2003-11-14-08 snapshot. Arpad Biro __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree -------------- next part -------------- A non-text attachment was scrubbed... Name: view.c.diff.bz2 Type: application/x-bzip2 Size: 969 bytes Desc: view.c.diff.bz2 URL: From nerijus at users.sourceforge.net Mon Nov 17 19:27:42 2003 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 17 Nov 2003 20:27:42 +0100 Subject: Fast horizontal scrolling in viewer In-Reply-To: <20031116175244.58452.qmail@web13701.mail.yahoo.com> References: <20031116175244.58452.qmail@web13701.mail.yahoo.com> Message-ID: <3FB9212E.2040604@users.sourceforge.net> Arpad Biro wrote: > There is a feature that IMHO is missing from MC: fast horizontal > scrolling in the internal viewer (by which I mean: scrolling by, say, > 10 chars horizontally). It seemed to be easy to hack this in, so I > made a patch that does just that. With the patch, Ctrl+Left scrolls > left by 10 chars and Ctrl+Right scrolls right by the same amount. Great, it was painful to scroll with arrows when viewing kernel log files for example. I hope it is ok and will be applied. Regards, Nerijus From dooligan at intergate.ca Wed Nov 19 20:51:10 2003 From: dooligan at intergate.ca (Miven Dooligan) Date: Wed, 19 Nov 2003 12:51:10 -0800 Subject: Press any key to continue... bug? References: <20031116175244.58452.qmail@web13701.mail.yahoo.com> <3FB9212E.2040604@users.sourceforge.net> Message-ID: <3FBBD7BE.7070301@intergate.ca> A little thing that's been bugging me for quite a long time: Using mc I get the habit of F10 to cancel things, so when I run something from the F2 user menu and it asks me to "Press any key to continue..." I seem to tap F10 by habit, which leaves a bunch of junk on the command line when the panels return, which I have to backspace though. This little hack uses read() to suck the keyboard dry so that I'm not left with chars in the buffer, and I have a nice clean commandline. Does this seem like a reasonable approach? -- Peace and Cheers. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: main_c_PressAnyKey.patch URL: From andrew at email.zp.ua Thu Nov 20 16:35:09 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Thu, 20 Nov 2003 18:35:09 +0200 (EET) Subject: * util.c (load_mc_home_file): Eliminate g_strdup_printf(). Message-ID: <200311201635.hAKGZ9xr002574@email.zp.ua> Hello, Pavel! -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: util.c.patch URL: From proski at gnu.org Thu Nov 20 19:09:54 2003 From: proski at gnu.org (Pavel Roskin) Date: Thu, 20 Nov 2003 14:09:54 -0500 (EST) Subject: undelfs warnings fix In-Reply-To: <200311171551.hAHFpSxO056833@email.zp.ua> References: <200311171551.hAHFpSxO056833@email.zp.ua> Message-ID: On Mon, 17 Nov 2003, Andrew V. Samoilov wrote: > > On Fri, 14 Nov 2003, Andrew V. Samoilov wrote: > > > > > Previous patch implementation breaks mcfs compilation, and as I understood > > > recently current implementation of com_err() is wrong and have format string > > > vulnerability. > > > > > > New implementation fixes com_err() and does not define free, sorry about > > > glib and libc memory allocation function mix, but we have it for glib 1.2x. > > > already. > > > > Applied. Thank you! The mix is unavoidable, but glib 1.2.x always uses > > libc memory allocation. > > Thanks! I hope this is last iteration for com_err() - va_list > must be first local variable in function, now call to com_err() hangs mc. > Sorry for lack of testing. I cannot find any document that says so. However, everybody puts va_list first, so maybe there is a reason for that. Strange that nobody complained about message() in CVS. I'm applying your patch, but I'll appreciate if you post a document saying that va_list should be first. -- Regards, Pavel Roskin From proski at gnu.org Thu Nov 20 19:34:42 2003 From: proski at gnu.org (Pavel Roskin) Date: Thu, 20 Nov 2003 14:34:42 -0500 (EST) Subject: A proposal for Midnight Commander In-Reply-To: <1068921862.24775.141.camel@erandi.boston.ximian.com> References: <1068749408.7535.20.camel@localhost> <1068756924.8126.30.camel@localhost> <1068850834.24775.54.camel@erandi.boston.ximian.com> <1068848297.10846.11.camel@localhost> <1068860370.17742.8.camel@localhost> <1068867611.24775.62.camel@erandi.boston.ximian.com> <1068921862.24775.141.camel@erandi.boston.ximian.com> Message-ID: On Sat, 15 Nov 2003, Miguel de Icaza wrote: > Hello Pavel, > > > There is a specific problem with glib 2.x, which is the fact that it > > relies on non-common infrastructure, such as pkg-config. I have voiced my > > concerns about it already. I believe that pkg-config should have been a > > script, not a C program. I do agree that glib 2.x is unnecessarily hard > > to compile on OSes without GNU tools preinstalled. > > > > But since glib 1.2.x is not going away, we can support it. Thanks to > > Miguel's clarification, I believe that glib is a good choice. > > My personal vote would go for Glib 2.x. Even if it is slightly harder > to build on old systems, it is becoming more and more ubiquitous > everywhere: > > * Solaris ship with this, and MacOS will have to ship it as > part of their X distro to support fontconfig. > > * Every Linux system that uses Freedesktop.org or Gnome will > have it (Cairo, Fontconfig, depend on it anyways). > > * Every installation where Mozilla runs will have it too. > > I know it is very desktop-centric, but pkg-config fixes a long standing > problem in the Unix world: how to detect, use and consume libraries > easily. > > And glib 2 provides a lot nicer IO support (the kind that would be nice > to replace the stuff in key.c). OK, then I won't rush with integrating glib 1.2.x into the mc sources. The only change that will be implemented now is moving the build scripts to the root directory. Sorry for all the flames that this thread has provoked. I was away and could not stop it immediately, but the measures will be taken. -- Regards, Pavel Roskin From irdyb at o2.pl Fri Nov 7 15:14:15 2003 From: irdyb at o2.pl (Ireneusz =?iso-8859-2?q?Dybczy=F1ski?=) Date: Fri, 7 Nov 2003 16:14:15 +0100 Subject: bug in mc Message-ID: <20031120172421.CA0782EEB3E@kogut.o2.pl> I have found something, which I thing is a bug in the midnight commander. If I set chmod of a file to 222, and later try to open it with the internal editor (F4), there is a message that reading was not successful and contents of a file is wiped. I use mc-4.5.55-7mdk on mandrake linux 8.2. It is rather rare case, but can cause losing data. with regards Ireneusz Dybczy?ski From dooligan at intergate.ca Fri Nov 21 04:07:17 2003 From: dooligan at intergate.ca (Miven Dooligan) Date: Thu, 20 Nov 2003 20:07:17 -0800 Subject: Press any key to continue... bug? References: <20031116175244.58452.qmail@web13701.mail.yahoo.com> <3FB9212E.2040604@users.sourceforge.net> <3FBBD7BE.7070301@intergate.ca> <20031119205341.GA18945@matrix> Message-ID: <3FBD8F75.30003@intergate.ca> Michal Szwaczko wrote: > On Wed, Nov 19, 2003 at 12:51:10PM -0800, Miven Dooligan wrote: > >>Does this seem like a reasonable approach? >> > > I don't think so, you are killing legal terminal Fxx sequences. > > Exactly the purpose of what I'm trying to do. The getch() only uses the first byte of the escape code, and leaves the rest to show up on the commandline. Obviously this read() approach would not be used anywhere else but a situation like this. AFAIK these lines are only run through after a subshell command and the continue prompt. At the point when asked to "Press any key to continue..." there isn't going to be any use for Fxx sequences, therefore just treat it all like one getch(); BTW Any function/arrow/etc key leaves junk on my commandline at this point. Of course it's possible other read() calls don't behave like mine. Perhaps some demand 15 bytes and will sit around waiting for them if they don't show up. Mine just takes what it can get and returns. Does anyone have a read() that'll wait for 15 bytes even if it only gets 5? -- Peace and Cheers. From proski at gnu.org Fri Nov 21 05:55:38 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 21 Nov 2003 00:55:38 -0500 (EST) Subject: Press any key to continue... bug? In-Reply-To: <3FBBD7BE.7070301@intergate.ca> References: <20031116175244.58452.qmail@web13701.mail.yahoo.com> <3FB9212E.2040604@users.sourceforge.net> <3FBBD7BE.7070301@intergate.ca> Message-ID: On Wed, 19 Nov 2003, Miven Dooligan wrote: > A little thing that's been bugging me for quite a long time: Using mc I > get the habit of F10 to cancel things, so when I run something from the > F2 user menu and it asks me to "Press any key to continue..." I seem to > tap F10 by habit, which leaves a bunch of junk on the command line when > the panels return, which I have to backspace though. This little hack > uses read() to suck the keyboard dry so that I'm not left with chars in > the buffer, and I have a nice clean commandline. > > Does this seem like a reasonable approach? I don't think it's a reasonable approach because it doesn't use the code already present in mc specifically for this purpose - to get a complete key sequence. The function is called get_key_code(), and it's already used to return from Ctrl-O if the subshell is not used. I've just applied a patch that uses get_key_code() for the "pause after run". Another reason your patch is incorrect is because it relies on the behavior of read(). It's not safe to rely on it, especially for remote terminals. There is no guarantee that it will flush the input. Again, there is a standard function specifically for flushing the input on terminals. You can find it used in synchronize() (src/subshell.c): /* Discard all remaining data from stdin to the subshell */ tcflush (subshell_pty, TCOFLUSH); I don't think we need to flush the input in this particular case because there may be legitimate uses for typing ahead. You can press "any key" and start typing another command. It's different from the situation where tcflush() is currently used, where the output would be fed to the subshell (not the command line) after the panels are restored. It's important to keep the code consistent and to reuse the existing code. Less code usually means less bugs, and if there are bugs, they are easier to detect and fix. -- Regards, Pavel Roskin From proski at gnu.org Fri Nov 21 05:59:53 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 21 Nov 2003 00:59:53 -0500 (EST) Subject: bug in mc In-Reply-To: <20031120172421.CA0782EEB3E@kogut.o2.pl> References: <20031120172421.CA0782EEB3E@kogut.o2.pl> Message-ID: On Fri, 7 Nov 2003, Ireneusz [iso-8859-2] Dybczy?ski wrote: > I have found something, which I thing is a bug in the midnight > commander. If I set chmod of a file to 222, and later try to open it > with the internal editor (F4), there is a message that reading was not > successful and contents of a file is wiped. I use mc-4.5.55-7mdk on > mandrake linux 8.2. It is rather rare case, but can cause losing data. I believe this bug was fixed. I cannot reproduce it with the CVS version or 4.6.0. There were significant changes in the file loading code before version 4.6.0. -- Regards, Pavel Roskin From proski at gnu.org Fri Nov 21 06:34:05 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 21 Nov 2003 01:34:05 -0500 (EST) Subject: Fast horizontal scrolling in viewer In-Reply-To: <20031116175244.58452.qmail@web13701.mail.yahoo.com> References: <20031116175244.58452.qmail@web13701.mail.yahoo.com> Message-ID: On Sun, 16 Nov 2003, Arpad Biro wrote: > Hi, > > There is a feature that IMHO is missing from MC: fast horizontal > scrolling in the internal viewer (by which I mean: scrolling by, say, 10 > chars horizontally). It seemed to be easy to hack this in, so I made a > patch that does just that. With the patch, Ctrl+Left scrolls left by 10 > chars and Ctrl+Right scrolls right by the same amount. I have not > thoroughly investigated MC code, so the patch may not be up to MC > standards. If it is not, then take this as a feature request. The patch > was tested on Linux and seems to work. > > The patch was made against the mc-2003-11-14-08 snapshot. I like the idea, but not the implementation. You added a parameter to functions that is only used in the text mode. This parameter is ignored in the hex mode. However, the comments for the functions were not updated to reflect this inconsistency. I've applied a similar patch that affects only one function check_left_right_keys() It will be easier to apply your patches if you include ChangeLog entries with them. -- Regards, Pavel Roskin From proski at gnu.org Fri Nov 21 07:04:49 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 21 Nov 2003 02:04:49 -0500 (EST) Subject: [patch] ftpfs specifying password for "ftp" & "anonymous" accounts In-Reply-To: <3FA4FDBC.7080108@kmlinux.fjfi.cvut.cz> References: <3FA4FDBC.7080108@kmlinux.fjfi.cvut.cz> Message-ID: On Sun, 2 Nov 2003, Jindrich Makovicka wrote: > Hi, > > this patch makes ftp:mypassword at server work as expected (logs as "ftp" > with password "mypassword"). Currently mc uses always the default mail > address as a password for ftp or anonymous, regardless of the password > specified after a colon. I've applied a similar patch that also gives the explicit password priority over the password from .netrc file. Thank you for report. -- Regards, Pavel Roskin From proski at gnu.org Fri Nov 21 09:38:40 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 21 Nov 2003 04:38:40 -0500 (EST) Subject: A proposal for Midnight Commander In-Reply-To: <1068857647.17540.11.camel@localhost> References: <1068827376.12105.28.camel@localhost> <87k7627o91.fsf@rgristroph-austin.ath.cx> <1068840104.13036.31.camel@localhost> <87vfpm1yxn.fsf@rgristroph-austin.ath.cx> <1068842971.3355.15.camel@localhost> <87oeve1vpg.fsf@rgristroph-austin.ath.cx> <3FB54C15.7090106@users.sourceforge.net> <1068857647.17540.11.camel@localhost> Message-ID: Hi, Ali! Sorry for late reply. I was away when this thread was active, and later I didn't have time to read such a long thread. It took me 2 hours just to read all messages, and yours is perhaps the only one that needs my reply. On Sat, 15 Nov 2003, Ali Akcaagac wrote: > On Fri, 2003-11-14 at 22:41, Nerijus Baliunas wrote: > > Well, Ali is right. I remember one of mplayer developers > > posted a few patches, but got no reply from Pavel... > > Actually it was not one of the MPlayer developers. It was the lead > developer of MPlayer himself - Arpi. The guy who has bigger balls in his > pants than others (refering to his skills here). Ok it was always > criticised that the MPlayer code looked awfull but this is hopefully > being dealth with in MPlayerG2. But more interesting is that he and his > team of developers were those who finally brought one of the best > mediaplayers around to open source. The patches were not suitable for 4.6.1 release. Fortunately, we have the patch repository on savannah.gnu.org, so the patches can be put there and applied later. I know, some of those patches could have been applied after some work. That's what I do with simple patches. I simply cannot afford to spend time applying large patches if I know that the underlying code needs cleanup and I'll spend more time on more complicated code. I'm just trying to maximize the return for the time I can spend on the project. It's painful for me not to be able to take every contribution immediately, but I have to choose. There are more factors than whether the patch works and who wrote it. If the code becomes harder to understand or to change, we may be losing in the long term, including the end users who won't get some features because maintainers are trying to understand what the code does and why it breaks instead of adding new features and making releases. The 4.6.1 release is primarily held by the undocumented timestamping code, that also "mostly works", but crashes in some situations (extfs inside extfs). There is nobody actively working on the project who has the complete understanding of that code. 4.6.0 has a buffer overflow in VFS and the editor will close by Ctrl-g without asking. If not that crash in VFS, 4.6.1 would have been released already. Arpi may be a great programmer, and his code may be ideal, but if it makes it hard to understand the existing code, it's also important. If if takes a day to understand a patch (and that always involves understanding the existing code) I must consider if I want to spend that day on something else and maybe understand the existing code better, add some comments, understand the limitations. I'm sure some other person could have performed better in my place, but I don't know such person who would take my place, and my choice is between doing what I can and not doing it. > This makes him a qualified person as soon as it comes to innovate and > bringing projects futher. I only didn't caught his signal where he > wanted to create a new mainstream Midnight Commander early Spring this > year. Anyways have you people paid attention that during this entire > conversation that Pavel didn't replied to it anymore ? This is a > development Mailinglist so raising Proposals and ideas what can be > changed is a common practice. I am not talking out of my back here - I > do know what I am talking here and raising some good points that others > may not have seen so far is definately a good point but I take his > silence as - not wanting to cooperate in any ways. Accpeting patches > from others and the normal smaltalk is welcome but major changes or > raised opinions somehow not. I was away and could not participate. It took me 2 hours to read the whole thread, and I didn't have time for that before now. Again, I'm just trying to spend my time effectively. Participation in active discussions could drain my time resources while there were important patches in the message queue. I don't consider the glib dependency a major issue. It will be a bigger issue if we start using it for real. > After all we are just talking about software here and I am happy that we > kept it that way. Anyways I would wish that people are more cooperative > and more open about innovation and going a good way rather than keeping > their tunnelview and stay stuck in road they are going. Midnight > Commander is a nice tool, the source code layout in the Midnight > Commander dir looks quite promising. After all we are not pushing > Mountains here. Anyways Pavel, my offer to help removing the glib > dependency still stays. I would accept it, it's a general benefit for > all. I appreciate your readiness to work on free software. But I'm still not convinced that it's the right thing to do. Let me sum up the arguments as I see them. It should be easier than to reply individual messages. 1) glib is easy to remove I don't care if it's easy or not. Just because it can be done, it doesn't mean it should be done. 2) glib adds code size at the runtime Many other things do. Those who design embedded systems should consider what can be removed or disabled. I believe that glib 1 should be used and linked statically to eliminate unused code. Maybe glib 2 should have better support for embedded systems, e.g. it should be possible to eliminate some unneeded features, like selection of the malloc implementation. Also, some sources could be split to make smaller object files and this make linking more fine-grained. 3) glib adds (or will add) dependency on GNOME, XFree86 etc That's an invalid argument. Maybe there is a problem with perception of glib as part of GNOME, but I cannot fix perception by technical means. 4) glib may have its own bugs Yes, but I'd rather trust the list code written by somebody specifically writing the list code rather than the code by somebody implementing e.g. directory list in mc. There are some little details that are hard to get right if you are thinking of something else. I must admit that glib makes it easy to make certain errors with lists. I don't know if alternative implementations were considered. But I don't know of any replacement for the list functions in glib. 5) glib has an unstable API Unless you specifically disable deprecated functions, it should be backward compatible. 6) glib is hard to compile That's true for glib2 because of its dependency on libiconv, gettext and pkgconfig. I still cannot get the build script build-glib2.sh to work on FreeBSD 5.1. This needs to be fixed. In particular, recent versions of gettext hardcodes the ".so" suffix in some places. Also, glib doesn't detect libiconv properly in some situations (it uses headers not matching the library). On the other hand, we have glib1 now, and it's easy o compile. 7) glib brings additional dependencies glib2 doesn't bring any additional dependencies for full-featured mc. We are using gettext already, and libiconv is used if the charset conversion is enabled. If you are building an embedded system, use glib1 for now, but help glib2 developers to make glib2 leaner (optionally). 8) glib brings no real benefits to mc Not true. A lot of string operations are simplified by functions like g_strdup_printf(). It may seem easy to replace each function with an equivalent not using glib, but it may not be so easy to understand and modify the code using standard string functions. 9) we don't need glib2, let's just integrate parts from glib1 glib2 has potentially useful code, such as Unicode support and the event loop. If we were using the event loop, porting mc to BeOS with its braindamaged socket-only select() would have been trivial. We cannot rely on Unicode support in libc if we want to stay portable. 10) glib is not portable glib1 is portable. There are minor issues with some OSes, but they are trivial to fix. glib2 has issues with one of its dependencies, namely gettext. I'm not aware of portability issues in glib2 itself. These problems can and should be fixed before we drop glib1 support. 11) the alternative to glib is glibc We cannot rely on GNU extensions if we want to stay portable. There are many libc implementations that crash on free(NULL). 12) shared libraries are inconvenient, fault prone etc Shared libraries are good enough for OpenBSD. Modular design is good enough for spacecrafts. 13) users won't find glib, especially the glib-devel package If you are compiling code, you are supposed to understand something. Otherwise, use precompiled packages, including mc. -- Regards, Pavel Roskin From ossi at kde.org Fri Nov 21 13:28:41 2003 From: ossi at kde.org (Oswald Buddenhagen) Date: Fri, 21 Nov 2003 14:28:41 +0100 Subject: Press any key to continue... bug? In-Reply-To: References: <20031116175244.58452.qmail@web13701.mail.yahoo.com> <3FB9212E.2040604@users.sourceforge.net> <3FBBD7BE.7070301@intergate.ca> Message-ID: <20031121132841.GA1600@ugly.local> On Fri, Nov 21, 2003 at 12:55:38AM -0500, Pavel Roskin wrote: > I don't think we need to flush the input in this particular case > because there may be legitimate uses for typing ahead. You can press > "any key" and start typing another command. > It's different from the situation where tcflush() is currently used, > where the output would be fed to the subshell (not the command line) > after the panels are restored. > btw, something is highly b0rked in this area; my type-ahead is cleared always, even if i'm in the subshell view. this sucks major ass, to say the least ... :} actually i don't remember ever having problems with keys going to the panel instead of the shell before, so i guess it was just a matter of getting used to doing it right. greetings -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From blackspy2002 at mail.ru Sun Nov 23 16:34:56 2003 From: blackspy2002 at mail.ru (BlackCat Hack Palace Admin) Date: Sun, 23 Nov 2003 18:34:56 +0200 Subject: Compilation Problem Message-ID: <000c01c3b1df$bc69a790$b91a05c3@blackcat> Hello, I tried to compile Midnight Commander under FreeBSD from ports, but then it compiling it writes me that gsize was previviosly declared and compilation stops, so what can I do to fix the problem ? thx. -------------- next part -------------- An HTML attachment was scrubbed... URL: From proski at gnu.org Mon Nov 24 14:24:29 2003 From: proski at gnu.org (Pavel Roskin) Date: Mon, 24 Nov 2003 09:24:29 -0500 (EST) Subject: Compilation Problem In-Reply-To: <000c01c3b1df$bc69a790$b91a05c3@blackcat> References: <000c01c3b1df$bc69a790$b91a05c3@blackcat> Message-ID: On Sun, 23 Nov 2003, BlackCat Hack Palace Admin wrote: > Hello, I tried to compile Midnight Commander under FreeBSD from ports, > but then it compiling it writes me that gsize was previviosly declared > and compilation stops, so what can I do to fix the problem ? thx. You are asking in a wrong place. Compile problems with any packages or ports should be reported to the packagers. Perhaps you should check if there are any guidelines for reporting problems with FreeBSD ports. I think the exact version of the packages and your OS might be helpful, as well as the exact error message. -- Regards, Pavel Roskin From andrew at email.zp.ua Mon Nov 24 16:12:17 2003 From: andrew at email.zp.ua (Andrew V. Samoilov) Date: Mon, 24 Nov 2003 18:12:17 +0200 (EET) Subject: Some more g_strdup_printf() eliminated Message-ID: <200311241612.hAOGCHYO030470@email.zp.ua> Hello, Pavel! P.S. g_strcompress() cannot be used to interpret C literals in regular expressions entered by the user, e.g. \r and \0x0D. It replace '\.' with '.' ;-( -- Regards, Andrew V. Samoilov. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: g_strdup_printf.patch URL: From eolkhovick at kazna.rv.ua Tue Nov 25 12:31:59 2003 From: eolkhovick at kazna.rv.ua (Eugene Olkhovick) Date: Tue, 25 Nov 2003 14:31:59 +0200 Subject: mc error Message-ID: <1327455911.20031125143159@kazna.rv.ua> Hello mc-devel, Now I add package mc-4.6.0_6 in my FreeBSD 4.2 system/ When I try to start mc the following error occured: /usr/libexec/ld-elf.so.1: Undefined symbol "__stdoutp" referenced from COPY relocation in mc How can I fix this trouble ? -- The State Treasury of Ukraine, Rivne branch, chief of the Department of Information Technologies and Telecomunications, Eugene Olkhovick mailto:eolkhovick at kazna.rv.ua From proski at gnu.org Wed Nov 26 19:45:44 2003 From: proski at gnu.org (Pavel Roskin) Date: Wed, 26 Nov 2003 14:45:44 -0500 (EST) Subject: mc error In-Reply-To: <1327455911.20031125143159@kazna.rv.ua> References: <1327455911.20031125143159@kazna.rv.ua> Message-ID: On Tue, 25 Nov 2003, Eugene Olkhovick wrote: > Hello mc-devel, > > Now I add package mc-4.6.0_6 in my FreeBSD 4.2 system/ When I try to > start mc the following error occured: > /usr/libexec/ld-elf.so.1: Undefined symbol "__stdoutp" referenced > from COPY relocation in mc Generally, such questions should be addressed to the packagers. GNU Midnight Commander doesn't use internal symbols of the FreeBSD C library. Search for "__stdoutp" on Google gives this: http://lists.freebsd.org/pipermail/freebsd-questions/2003-August/014595.html Perhaps the package was built for another version of FreeBSD. -- Regards, Pavel Roskin From dave at jikos.cz Fri Nov 28 10:49:54 2003 From: dave at jikos.cz (David Sterba) Date: Fri, 28 Nov 2003 11:49:54 +0100 (CET) Subject: Tilde expansion in mkdir dialog Message-ID: Hi, the new tilde expansion behaviour seems a bit ambiguous in make dir dialog (F7). I would like to create directory named '~', but this gets expanded to my home directory, which exist. Now, I would like to create /home/mylogin/dir and input '~/dir' and here i want the expansion. Creation of '~' should be treated differently. (Well, I don't create directories '~' every day.) There is a bug in tilde expansion function: 1. try to create directory '~nonexistent' 2. shis should stay as-is, so I expect creation of directory' ~nonexistent' 3. but only the directory 'nonexistent' is created Variable holding the directory name skips initial '~' but does not restore it back when returning nonexistent entry in passwd. patch: --- utilunix.c.orig Fri Nov 28 11:45:57 2003 +++ utilunix.c Fri Nov 28 11:46:03 2003 @@ -290,7 +290,7 @@ /* If we can't figure the user name, leave tilde unexpanded */ if (!passwd) - return g_strdup (directory); + return g_strdup (directory-1); return g_strconcat (passwd->pw_dir, PATH_SEP_STR, p, NULL); } bye Dave From proski at gnu.org Fri Nov 28 15:27:31 2003 From: proski at gnu.org (Pavel Roskin) Date: Fri, 28 Nov 2003 10:27:31 -0500 (EST) Subject: Tilde expansion in mkdir dialog In-Reply-To: References: Message-ID: On Fri, 28 Nov 2003, David Sterba wrote: > Hi, > > the new tilde expansion behaviour seems a bit ambiguous in make dir > dialog (F7). > > I would like to create directory named '~', but this gets expanded to my > home directory, which exist. This command has always been using input_expand_dialog(). The same behavior exists in version 4.6.0. I believe there is no regression here. > Now, I would like to create /home/mylogin/dir and input '~/dir' and here > i want the expansion. > > Creation of '~' should be treated differently. > > (Well, I don't create directories '~' every day.) Then we would need some way to quote the tilde. > There is a bug in tilde expansion function: > 1. try to create directory '~nonexistent' > 2. shis should stay as-is, so I expect creation > of directory' ~nonexistent' > 3. but only the directory 'nonexistent' is created > Variable holding the directory name skips initial '~' > but does not restore it back when returning nonexistent > entry in passwd. > > patch: > --- utilunix.c.orig Fri Nov 28 11:45:57 2003 > +++ utilunix.c Fri Nov 28 11:46:03 2003 > @@ -290,7 +290,7 @@ > > /* If we can't figure the user name, leave tilde unexpanded */ > if (!passwd) > - return g_strdup (directory); > + return g_strdup (directory-1); > > return g_strconcat (passwd->pw_dir, PATH_SEP_STR, p, NULL); > } Yes, that's a new bug. I have fixed it slightly differently. The variable "directory" should not have been used as a temporary string pointer. Nice example of code that is dangerous to change. -- Regards, Pavel Roskin From Bernd.Bartmann at sohanet.de Sat Nov 29 11:44:56 2003 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Sat, 29 Nov 2003 12:44:56 +0100 Subject: Where is the mc CVS module? Message-ID: <3FC886B8.1020307@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I wanted to checkout the mc CVS module following the instructions found at http://www.ibiblio.org/mc/ and http://savannah.gnu.org/cvs/?group=mc but both fail with "/cvsroot/mc: no such repository" [bart at riker new]$ cvs -d :pserver:anoncvs at subversions.gnu.org:/cvsroot/mc checkout mc /cvsroot/mc: no such repository [bart at riker new]$ cvs -d:pserver:anoncvs at savannah.gnu.org:/cvsroot/mc login Logging in to :pserver:anoncvs at savannah.gnu.org:2401/cvsroot/mc CVS password: /cvsroot/mc: no such repository Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/yIa4kQuIaHu84cIRAqsHAJ0TKp9kLT1yZvbT4Mt0RcFku3NHjACfUecs KeWZJZZxicUKhlCNcMtenls= =ikaQ -----END PGP SIGNATURE----- From proski at gnu.org Sat Nov 29 23:45:16 2003 From: proski at gnu.org (Pavel Roskin) Date: Sat, 29 Nov 2003 18:45:16 -0500 Subject: Where is the mc CVS module? In-Reply-To: <3FC886B8.1020307@sohanet.de> References: <3FC886B8.1020307@sohanet.de> Message-ID: <1070149516.3yc837ma2z0@webmail.spamcop.net> Quoting Bernd Bartmann : > I wanted to checkout the mc CVS module following the instructions found > at http://www.ibiblio.org/mc/ and http://savannah.gnu.org/cvs/?group=mc > but both fail with "/cvsroot/mc: no such repository" > > [bart at riker new]$ cvs -d > :pserver:anoncvs at subversions.gnu.org:/cvsroot/mc checkout mc > /cvsroot/mc: no such repository Thank you for your report. The anonymous repository was working just a few days earlier. I know that because snapshots are made by a script that uses anonymous read-only access. I confirm the problem. I also see that other projects like autoconf and grub can be accessed. I'll forward this message to the Savannah sysadmins. I hope this issue will be resolved shortly. -- Regards, Pavel Roskin From proski at gnu.org Sun Nov 30 01:08:35 2003 From: proski at gnu.org (Pavel Roskin) Date: Sat, 29 Nov 2003 20:08:35 -0500 Subject: Where is the mc CVS module? In-Reply-To: <3FC886B8.1020307@sohanet.de> References: <3FC886B8.1020307@sohanet.de> Message-ID: <1070154515.6cq779waow74@webmail.spamcop.net> Quoting Bernd Bartmann : > I wanted to checkout the mc CVS module following the instructions found > at http://www.ibiblio.org/mc/ and http://savannah.gnu.org/cvs/?group=mc > but both fail with "/cvsroot/mc: no such repository" Fixed now. Please try again. -- Regards, Pavel Roskin From lists1 at pervalidus.net Sun Nov 30 05:05:05 2003 From: lists1 at pervalidus.net (=?ISO-8859-1?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Sun, 30 Nov 2003 03:05:05 -0200 (BRST) Subject: Segmentation fault using Ctrl+o: libgpm related ? Message-ID: Hope it helps. Latest CVS on Linux. Compiled with --enable-charset --with-screen=ncurses --without-ext2undel How to reproduce it. Start it on a console. It crashes as soon as you use Ctrl+o. Is it a libgpm bug ? It works fine under screen, but applications running under it don't have mouse support through libgpm. I had used --without-gpm-mouse for a very long time, but enabled it. #0 0x40163bf3 in strlen () at strlen:-1 #1 0x400911c9 in Gpm_Open () from /usr/lib/libgpm.so.1 #2 0x0807755c in enable_mouse () at /usr/local/src/CVS/GNU/mc/src/mouse.c:80 #3 0x08061bab in toggle_panels () at /usr/local/src/CVS/GNU/mc/src/execute.c:255 #4 0x08075141 in midnight_callback (h=0x8101630, msg=DLG_KEY, parm=1074344200) at /usr/local/src/CVS/GNU/mc/src/main.c:1573 #5 0x0805fb56 in dlg_key_event (h=0x40093108, d_key=135242600) at /usr/local/src/CVS/GNU/mc/src/dialog.c:655 #6 0x0805fca9 in dlg_process_event (h=0x80f3640, key=0, event=0xbffff630) at /usr/local/src/CVS/GNU/mc/src/dialog.c:745 #7 0x0805fe4a in run_dlg (h=0x80f3640) at /usr/local/src/CVS/GNU/mc/src/dialog.c:777 #8 0x080753e2 in setup_panels_and_run_mc () at /usr/local/src/CVS/GNU/mc/src/main.c:1669 #9 0x080755ed in do_nc () at /usr/local/src/CVS/GNU/mc/src/main.c:1742 #10 0x08076066 in main (argc=0, argv=0x0) at /usr/local/src/CVS/GNU/mc/src/main.c:2234 #11 0x400fdbf6 in __libc_start_main (main=0x8075d80
, argc=1, ubp_av=0xbffff734, init=0x80b3880 <__libc_csu_init>, fini=0x80b38b0 <__libc_csu_fini>, rtld_fini=0x1, stack_end=0x8101630) at ../sysdeps/generic/libc-start.c:152 -- http://www.pervalidus.net/contact.html From Bernd.Bartmann at sohanet.de Sun Nov 30 10:08:29 2003 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Sun, 30 Nov 2003 11:08:29 +0100 Subject: Where is the mc CVS module? In-Reply-To: <1070154515.6cq779waow74@webmail.spamcop.net> References: <3FC886B8.1020307@sohanet.de> <1070154515.6cq779waow74@webmail.spamcop.net> Message-ID: <3FC9C19D.9010806@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pavel Roskin schrieb: | Quoting Bernd Bartmann : |>I wanted to checkout the mc CVS module following the instructions found |>at http://www.ibiblio.org/mc/ and http://savannah.gnu.org/cvs/?group=mc |>but both fail with "/cvsroot/mc: no such repository" | | Fixed now. Please try again. Thanks Pavel, works now for me too. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/ycGdkQuIaHu84cIRAtrZAJ4p90vhnxaMjRncl3PjS/7zwNdzCwCfUXLP y1HzxtsT6YGGp4d0Fb4t/vo= =eeaw -----END PGP SIGNATURE----- From egmont at uhulinux.hu Sun Nov 30 11:37:49 2003 From: egmont at uhulinux.hu (Koblinger Egmont) Date: Sun, 30 Nov 2003 12:37:49 +0100 (CET) Subject: Segmentation fault using Ctrl+o: libgpm related ? In-Reply-To: Message-ID: On Sun, 30 Nov 2003, [ISO-8859-1] Fr?d?ric L. W. Meunier wrote: Hi! Try to apply the attached patch to gpm. Some time ago this patch solved me a gpm-related segfault, I can't remember if it was related to Ctrl+o... -- Egmont -------------- next part -------------- diff -urN gpm-1.20.1.orig/src/lib/liblow.c gpm-1.20.1/src/lib/liblow.c --- gpm-1.20.1.orig/src/lib/liblow.c 2002-12-30 23:13:37.000000000 +0100 +++ gpm-1.20.1/src/lib/liblow.c 2002-12-30 23:56:54.000000000 +0100 @@ -199,7 +199,7 @@ Gpm_Stst *new = NULL; char* sock_name = 0; - option.consolename = NULL; + option.consolename; /*....................................... First of all, check xterm */ From lists1 at pervalidus.net Sun Nov 30 15:21:15 2003 From: lists1 at pervalidus.net (=?ISO-8859-1?Q?Fr=E9d=E9ric_L=2E_W=2E_Meunier?=) Date: Sun, 30 Nov 2003 13:21:15 -0200 (BRST) Subject: Segmentation fault using Ctrl+o: libgpm related ? In-Reply-To: References: Message-ID: On Sun, 30 Nov 2003, Koblinger Egmont wrote: > On Sun, 30 Nov 2003, [ISO-8859-1] Fr?d?ric L. W. Meunier wrote: > > Try to apply the attached patch to gpm. > > Some time ago this patch solved me a gpm-related segfault, I can't > remember if it was related to Ctrl+o... Yes, it works. Thanks. But there's a different patch at http://lists.linux.it/pipermail/gpm/2003-September/000691.html Unfortunately CVS hasn't been updated. Nico ? -- http://www.pervalidus.net/contact.html