* RE : Re: Files from gnulib @ 2011-01-25 8:20 Bastien ROUCARIES 2011-01-25 14:05 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-25 8:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Paul Eggert, bug-gnulib, monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 805 bytes --] Btw does doslfn not available these days? Bastien Le 25 janv. 2011 05:00, "Eli Zaretskii" <eliz@gnu.org> a écrit : > Date: Mon, 24 Jan 2011 15:26:06 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: Stefan Monnier <monnier@iro.umontreal.ca>, bug-gnulib@gnu.org, > emacs-devel@gnu.org > > On 01/23/11 20:01, Eli Zaretskii wrote: > > The program used to unpack the .tar.gz archives automa... There are no special tarballs for MSDOS. People use the tarball from the GNU FTP site. So this solution will not work. > * The conflicting names in m4/* don't matter, for the same > reason that conflicts in admin/* a... The files in m4/ still matter because you need to unpack the tarball, and the utility that does that won't silently overwrite files due to file-name clashes. [-- Attachment #2: Type: text/html, Size: 1284 bytes --] ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 8:20 RE : Re: Files from gnulib Bastien ROUCARIES @ 2011-01-25 14:05 ` Eli Zaretskii 2011-01-25 14:51 ` Jim Meyering 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 14:05 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: eggert, bug-gnulib, monnier, emacs-devel > Date: Tue, 25 Jan 2011 09:20:48 +0100 > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, bug-gnulib@gnu.org, > Paul Eggert <eggert@cs.ucla.edu> > > Btw does doslfn not available these days? It can be downloaded (although unmaintained since 2006), but I don't know whether it can be a viable solution. It was never widely used with DJGPP, so its compatibility with the Long File Name (LFN) functions used by DJGPP is unknown. DJGPP implementation of the Standard C library assumes that any LFN support implements the full range of LFN functions that Windows 9X provided. There isn't a single LFN function that is not used by some library function in DJGPP. If someone wants LFN support nowadays, they can easily enough install Windows (where DJGPP programs can run and support long file names). Which may explain why doslfn is not used too much. So I'd rather not request users to install doslfn. None of the other DJGPP ports requires LFN as a prerequisite for building it, so doing so for Emacs sounds like a bad idea to me, when the alternative is to rename a few files. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 14:05 ` Eli Zaretskii @ 2011-01-25 14:51 ` Jim Meyering 2011-01-25 15:33 ` Eli Zaretskii 2011-01-25 16:03 ` RE : " Leo 0 siblings, 2 replies; 99+ messages in thread From: Jim Meyering @ 2011-01-25 14:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Bastien ROUCARIES, eggert, bug-gnulib, monnier, emacs-devel Eli Zaretskii wrote: >> Date: Tue, 25 Jan 2011 09:20:48 +0100 >> From: Bastien ROUCARIES <roucaries.bastien@gmail.com> >> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, bug-gnulib@gnu.org, >> Paul Eggert <eggert@cs.ucla.edu> >> >> Btw does doslfn not available these days? > > It can be downloaded (although unmaintained since 2006), but I don't > know whether it can be a viable solution. It was never widely used > with DJGPP, so its compatibility with the Long File Name (LFN) > functions used by DJGPP is unknown. DJGPP implementation of the > Standard C library assumes that any LFN support implements the full > range of LFN functions that Windows 9X provided. There isn't a single > LFN function that is not used by some library function in DJGPP. > > If someone wants LFN support nowadays, they can easily enough install > Windows (where DJGPP programs can run and support long file names). > Which may explain why doslfn is not used too much. > > So I'd rather not request users to install doslfn. None of the other > DJGPP ports requires LFN as a prerequisite for building it, so doing > so for Emacs sounds like a bad idea to me, when the alternative is to > rename a few files. Forcing current and future emacs development into the archaic 8.3 mold has a significant cost (just look at how long this thread is), yet provides relatively little benefit. If something like doslfn is reliable enough and not hard to install, then requiring it makes sense: then all emacs developers will be freed of this onerous file-naming constraint. This is like various shims we've used over the years. (remember ansi2knr?) Imposing small relatively transparent requirements on users of less common systems is actually a good practice, when doing so permits improvements in the development process. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 14:51 ` Jim Meyering @ 2011-01-25 15:33 ` Eli Zaretskii 2011-01-25 16:32 ` Jim Meyering ` (2 more replies) 2011-01-25 16:03 ` RE : " Leo 1 sibling, 3 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 15:33 UTC (permalink / raw) To: Jim Meyering; +Cc: roucaries.bastien, eggert, bug-gnulib, monnier, emacs-devel > From: Jim Meyering <jim@meyering.net> > Cc: Bastien ROUCARIES <roucaries.bastien@gmail.com>, eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Tue, 25 Jan 2011 15:51:00 +0100 > > Forcing current and future emacs development into the archaic 8.3 mold has > a significant cost The costs are generally mine, and mine alone. I offered to do the renaming job myself, provided some guidance from people who know their way through gnulib. > (just look at how long this thread is) It could be much shorter if my original request was granted. It is long because people ask me questions and I respect them enough to answer those questions in detail. I don't mind keeping answering them, but please don't hold that against me, or present that as incurring significant costs on Emacs development. If we want to cut our losses, why not accept my suggestion, and be done with that? For that matter, how about presenting some technical reasons for objecting the renaming I suggested, or any alternative renaming? I explained why proposed alternatives were problematic, but didn't yet see any explanation of the reasons behind the apparent objection. > yet provides relatively little benefit. See, you are wrong here. The number of times I found bugs in Emacs that are of importance to Posix platforms, just by building the DOS port, is not negligible. The reasons are that the DOS build is very similar to the Unix build --without-x (which evidently not many people who track the development try these days), and its use of menus is exactly identical to the no-toolkit X build. These are evidently rare configurations, but they are still supported. I think that the occasional hour or two I invest once in a few weeks when the DOS build becomes broken and I need to fix it is well payed by the benefits that brings to Emacs development in general, by uncovering bugs in those rare configurations. And if it does some service to a niche user community while at that, what's wrong with that? > If something like doslfn is reliable enough > and not hard to install, then requiring it makes sense: then all emacs > developers will be freed of this onerous file-naming constraint. It's impossible for me to say if doslfn is reliable. I never used it myself, nor was it ever used widely enough by DJGPP users. As for the onerous file-naming constraint, we have more than 3000 files in the Emacs tree, and the problem is limited to just 7 or so, all of them recent additions. > Imposing small relatively transparent requirements on users of less common > systems is actually a good practice, when doing so permits improvements > in the development process. I'm not aware of any improvements in the development process that the DOS port imposes. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 15:33 ` Eli Zaretskii @ 2011-01-25 16:32 ` Jim Meyering 2011-01-25 18:48 ` Eli Zaretskii 2011-01-25 16:50 ` Ulrich Mueller 2011-01-25 22:37 ` Bastien ROUCARIES 2 siblings, 1 reply; 99+ messages in thread From: Jim Meyering @ 2011-01-25 16:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: roucaries.bastien, eggert, bug-gnulib, monnier, emacs-devel Eli Zaretskii wrote: >> From: Jim Meyering <jim@meyering.net> >> Cc: Bastien ROUCARIES <roucaries.bastien@gmail.com>, >> eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, >> emacs-devel@gnu.org >> Date: Tue, 25 Jan 2011 15:51:00 +0100 >> >> Forcing current and future emacs development into the archaic 8.3 mold has >> a significant cost > > The costs are generally mine, and mine alone. I offered to do the Not being able to use a preferred file name due to the archaic 8.3 naming limitations is onerous, even if someone else handles the renaming task. Just because it's a cost incurred mostly by you doesn't diminish the fact that it's a cost. > renaming job myself, provided some guidance from people who know their > way through gnulib. > >> (just look at how long this thread is) > > It could be much shorter if my original request was granted. It is > long because people ask me questions and I respect them enough to > answer those questions in detail. I don't mind keeping answering > them, but please don't hold that against me, or present that as > incurring significant costs on Emacs development. If we want to cut > our losses, why not accept my suggestion, and be done with that? For > that matter, how about presenting some technical reasons for objecting > the renaming I suggested, or any alternative renaming? I explained > why proposed alternatives were problematic, but didn't yet see any > explanation of the reasons behind the apparent objection. If what I said implied I'm holding anything against you personally, it was not intended. Why did I speak up? I'm in the habit of avoiding problems with "old code" and old processes, and I place great value on "code cleanliness". When I see effort being expended in an attempt to work around DOS 8.3 name collisions, my "oh, no, not that again" reflex kicks in and I can't resist the urge to hype an approach that may relieve you and others of the trouble of worrying about 8.3 ever again. Isn't it almost always better to do a little more work now, when that will save lots of tedious, manual work later? >> yet provides relatively little benefit. > > See, you are wrong here. The number of times I found bugs in Emacs > that are of importance to Posix platforms, just by building the DOS > port, is not negligible. The reasons are that the DOS build is very Obviously building for DOS is worthwhile. There's no need to stop that. However, if you can continue doing that, but with one small shim (assuming it's easy/effective) and without naming constraints, then everyone would win. > similar to the Unix build --without-x (which evidently not many people > who track the development try these days), and its use of menus is > exactly identical to the no-toolkit X build. These are evidently rare > configurations, but they are still supported. > > I think that the occasional hour or two I invest once in a few weeks > when the DOS build becomes broken and I need to fix it is well payed > by the benefits that brings to Emacs development in general, by > uncovering bugs in those rare configurations. And if it does some > service to a niche user community while at that, what's wrong with > that? Portability is great. For all I know, there may be many DOS-only emacs users and developers. But portability is even better when archaic constraints do not impede (not even slightly) development for more modern systems. >> If something like doslfn is reliable enough >> and not hard to install, then requiring it makes sense: then all emacs >> developers will be freed of this onerous file-naming constraint. > > It's impossible for me to say if doslfn is reliable. I never used it > myself, nor was it ever used widely enough by DJGPP users. > > As for the onerous file-naming constraint, we have more than 3000 > files in the Emacs tree, and the problem is limited to just 7 or so, > all of them recent additions. 7 may not seem like a lot to you, but it does imply an ongoing tension. A small burden... One of those constraints that we'd like to define-away. >> Imposing small relatively transparent requirements on users of less common >> systems is actually a good practice, when doing so permits improvements >> in the development process. > > I'm not aware of any improvements in the development process that the > DOS port imposes. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 16:32 ` Jim Meyering @ 2011-01-25 18:48 ` Eli Zaretskii 2011-01-26 0:45 ` Miles Bader 2011-01-26 2:42 ` Leo 0 siblings, 2 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 18:48 UTC (permalink / raw) To: Jim Meyering; +Cc: roucaries.bastien, eggert, bug-gnulib, monnier, emacs-devel > From: Jim Meyering <jim@meyering.net> > Cc: roucaries.bastien@gmail.com, eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Tue, 25 Jan 2011 17:32:27 +0100 > > Not being able to use a preferred file name due to the archaic 8.3 > naming limitations is onerous, even if someone else handles the > renaming task. Just because it's a cost incurred mostly by you > doesn't diminish the fact that it's a cost. "What's in a name?" How is unistd.in.h substantially different from unistd-in.h or some such, that preferring one over the other is a "cost"? > I'm in the habit of avoiding problems with "old code" > and old processes, and I place great value on "code cleanliness". What is not "clean" in unistd-in.h? > When I see effort being expended in an attempt to work around DOS 8.3 > name collisions, my "oh, no, not that again" reflex kicks in and I can't > resist the urge to hype an approach that may relieve you and others of > the trouble of worrying about 8.3 ever again. How about honoring a small request of a veteran Emacs hacker? Does that have any weight in this discussion? It's certainly not less important than the knee-jerk reaction on behalf of 8.3. You are talking about costs? How about _my_ costs -- the need to endure these endless "why-don't-you-go-away-with-your-stupid-DOS" discussions? Here's Miles again, asking his perennial "how many users are there", here's Leo inventing "loads of weird files" that somehow are the fault of supporting the DOS port, here's Ulrich Mueller reminding me that I asked for eliminating file-name clashes in CEDET (in Oct 2009!)... How do you think I feel after all this hazing I need to go through, because of a simple request? What do you think this does to my motivation to continue development of the bidirectional editing support for a community that treats me like that? So I have a weak spot, so what? who doesn't? Why everybody and their dog here feel a need to probe that spot with a pique? > Isn't it almost always better to do a little more work now, when > that will save lots of tedious, manual work later? It is, but no one yet suggested such a magic way of solving this. All of the alternatives proposed until now mean more work, which is more tedious and more manual than a simple one-time rename. > Obviously building for DOS is worthwhile. > There's no need to stop that. If others cannot build it reliably and seamlessly, then there's no incentive for me to continue maintaining this port. Is that the intent here -- to make this progressively harder and harder for me, until I give up and go away? > Portability is great. For all I know, there may be many DOS-only emacs > users and developers. But portability is even better when archaic > constraints do not impede (not even slightly) development for more > modern systems. There's no impediment. File names can continue being long and descriptive, they just should be different either in the first 8 characters before the dot or the first 3 characters after the dot. That's it. All that's needed is a few seconds of thought when selecting a file name. It's not like this is the only restriction we need to cope with when naming files. The only "impediment" here is that knee-jerk irrational reaction. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 18:48 ` Eli Zaretskii @ 2011-01-26 0:45 ` Miles Bader 2011-01-26 6:08 ` Eli Zaretskii 2011-01-26 2:42 ` Leo 1 sibling, 1 reply; 99+ messages in thread From: Miles Bader @ 2011-01-26 0:45 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, bug-gnulib, Jim Meyering, emacs-devel, monnier, roucaries.bastien Eli Zaretskii <eliz@gnu.org> writes: > Here's Miles again, asking his perennial "how many users are there" Do you think that's an irrelevant question? -miles -- Liberty, n. One of imagination's most precious possessions. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 0:45 ` Miles Bader @ 2011-01-26 6:08 ` Eli Zaretskii 2011-01-26 6:41 ` Miles Bader 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 6:08 UTC (permalink / raw) To: Miles Bader Cc: eggert, bug-gnulib, jim, emacs-devel, monnier, roucaries.bastien > From: Miles Bader <miles@gnu.org> > Cc: Jim Meyering <jim@meyering.net>, roucaries.bastien@gmail.com, eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > System-Type: x86_64-unknown-linux-gnu > Date: Wed, 26 Jan 2011 09:45:15 +0900 > > Eli Zaretskii <eliz@gnu.org> writes: > > Here's Miles again, asking his perennial "how many users are there" > > Do you think that's an irrelevant question? It wasn't irrelevant when it was asked (and answered) the first time. When asked for the umpteenth time, it sounds like you are actually asking something else. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 6:08 ` Eli Zaretskii @ 2011-01-26 6:41 ` Miles Bader 0 siblings, 0 replies; 99+ messages in thread From: Miles Bader @ 2011-01-26 6:41 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, bug-gnulib, jim, emacs-devel, monnier, roucaries.bastien Eli Zaretskii <eliz@gnu.org> writes: >> Do you think that's an irrelevant question? > > It wasn't irrelevant when it was asked (and answered) the first time. > When asked for the umpteenth time, it sounds like you are actually > asking something else. The answer most likely does not remain the same over time, though, so it's appropriate to re-ask such questions periodically. -Miles -- My spirit felt washed. With blood. [Eli Shin, on "The Passion of the Christ"] ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 18:48 ` Eli Zaretskii 2011-01-26 0:45 ` Miles Bader @ 2011-01-26 2:42 ` Leo 2011-01-26 4:14 ` Eli Zaretskii 1 sibling, 1 reply; 99+ messages in thread From: Leo @ 2011-01-26 2:42 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, bug-gnulib, Jim Meyering, emacs-devel, monnier, roucaries.bastien On 2011-01-26 02:48 +0800, Eli Zaretskii wrote: > You are talking about costs? How about _my_ costs -- the need to > endure these endless "why-don't-you-go-away-with-your-stupid-DOS" > discussions? Here's Miles again, asking his perennial "how many users > are there", here's Leo inventing "loads of weird files" that somehow > are the fault of supporting the DOS port, here's Ulrich Mueller > reminding me that I asked for eliminating file-name clashes in > CEDET (in Oct 2009!)... Please don't take that personally. People are annoyed by 8+3 not by you and we users value very much your tireless and long-term contribution to Emacs. The thing though is 8+3 is on everybody's mind so they will unconsciously name files that way even in cases difficult to do so. BTW, what I meant by weirdly-named files are, for example, those c.el, dired.el etc in cedet. One has to look at its enclosing directory to guess what it does. Leo -- Oracle is the new evil ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 2:42 ` Leo @ 2011-01-26 4:14 ` Eli Zaretskii 2011-01-26 10:52 ` Jim Meyering 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 4:14 UTC (permalink / raw) To: Leo; +Cc: eggert, bug-gnulib, jim, emacs-devel, monnier, roucaries.bastien > From: Leo <sdl.web@gmail.com> > Cc: Jim Meyering <jim@meyering.net>, roucaries.bastien@gmail.com, eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Wed, 26 Jan 2011 10:42:13 +0800 > > On 2011-01-26 02:48 +0800, Eli Zaretskii wrote: > > You are talking about costs? How about _my_ costs -- the need to > > endure these endless "why-don't-you-go-away-with-your-stupid-DOS" > > discussions? Here's Miles again, asking his perennial "how many users > > are there", here's Leo inventing "loads of weird files" that somehow > > are the fault of supporting the DOS port, here's Ulrich Mueller > > reminding me that I asked for eliminating file-name clashes in > > CEDET (in Oct 2009!)... > > Please don't take that personally. Everything is personal in this world. People who don't take things personal are people you should stay away of. > People are annoyed by 8+3 not by you > and we users value very much your tireless and long-term contribution to > Emacs. The thing though is 8+3 is on everybody's mind so they will > unconsciously name files that way even in cases difficult to do so. Well, let your consciousness kick in. > BTW, what I meant by weirdly-named files are, for example, those c.el, > dired.el etc in cedet. One has to look at its enclosing directory to > guess what it does. And cedet-dired.el is more helpful how? ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 4:14 ` Eli Zaretskii @ 2011-01-26 10:52 ` Jim Meyering 2011-01-26 12:42 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Jim Meyering @ 2011-01-26 10:52 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, bug-gnulib, emacs-devel, monnier, roucaries.bastien, Leo Eli Zaretskii wrote: >> From: Leo <sdl.web@gmail.com> ... >> Please don't take that personally. > > Everything is personal in this world. People who don't take things > personal are people you should stay away of. ?? On the contrary. Projects can improve/evolve more rapidly when egos don't interfere. I find that people get a lot more real work done when they do not interpret constructive criticism of their code as a personal attack. It can be challenging, esp. when problem reports and "suggestions" are worded undiplomatically, but dissociating ego from code is well worth the effort. "Assume the best" is almost always a better policy than assuming the worst, both for you and for the people you deal with. And for "the code". Imagine that you didn't have to worry about 8.3 and Paul did not have to jump through its hoops... How many bugs would you two have fixed with the saved time? How much new code would you have been able to write without contributing to this email thread. >> People are annoyed by 8+3 not by you >> and we users value very much your tireless and long-term contribution to ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 10:52 ` Jim Meyering @ 2011-01-26 12:42 ` Eli Zaretskii 2011-01-26 13:09 ` Jim Meyering 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 12:42 UTC (permalink / raw) To: Jim Meyering Cc: eggert, bug-gnulib, emacs-devel, monnier, roucaries.bastien, sdl.web > From: Jim Meyering <jim@meyering.net> > Cc: Leo <sdl.web@gmail.com>, roucaries.bastien@gmail.com, eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Wed, 26 Jan 2011 11:52:12 +0100 > > Eli Zaretskii wrote: > >> From: Leo <sdl.web@gmail.com> > ... > >> Please don't take that personally. > > > > Everything is personal in this world. People who don't take things > > personal are people you should stay away of. > > ?? > On the contrary. > Projects can improve/evolve more rapidly when egos don't interfere. "Personally" != "ego". People who take their jobs personally are the best ones I ever met. Being emotional about your job is not a vice; on the contrary. But I _really_, REALLY don't want to start a sub-thread on this. > I find that people get a lot more real work done when they do not > interpret constructive criticism of their code as a personal attack. We are not talking about any criticism of my code. The analogy is inappropriate. There were no technical reasons for rejecting my simple original suggestion. Only dogmatic arguments, whose intent is very clear: to resist any effort, even an infinitesimal one, on the Posix side, even if it imposes an unduly heavy burden on me and on the end users. There's nothing between this and constructive criticism on the one hand, and "ego" on the other. > Imagine that you didn't have to worry about 8.3 and Paul did not have > to jump through its hoops... How many bugs would you two have fixed with > the saved time? How much new code would you have been able to write > without contributing to this email thread. Imagine that instead of arguing, the files would be simply renamed. But we are repeating ourselves. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 12:42 ` Eli Zaretskii @ 2011-01-26 13:09 ` Jim Meyering 2011-01-26 13:29 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Jim Meyering @ 2011-01-26 13:09 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, bug-gnulib, emacs-devel, monnier, roucaries.bastien, sdl.web Eli Zaretskii wrote: >> From: Jim Meyering <jim@meyering.net> ... >> Eli Zaretskii wrote: >> >> From: Leo <sdl.web@gmail.com> >> ... >> >> Please don't take that personally. >> > >> > Everything is personal in this world. People who don't take things >> > personal are people you should stay away of. >> >> ?? >> On the contrary. >> Projects can improve/evolve more rapidly when egos don't interfere. > > "Personally" != "ego". People who take their jobs personally are the > best ones I ever met. Being emotional about your job is not a vice; > on the contrary. Taking well-intended technical suggestions as a personal attack (and responding in kind) is counterproductive, no matter what you call it. > But I _really_, REALLY don't want to start a sub-thread on this. > >> I find that people get a lot more real work done when they do not >> interpret constructive criticism of their code as a personal attack. > > We are not talking about any criticism of my code. The analogy is We are talking about process restrictions that you want to continue to impose on the code of all developers, solely for the sake of the DOS port. Paul has been patient and professional, constantly proposing alternatives intended to ease the maintenance of the DOS port. Yet, you seem to reject each of those without giving him a chance. > inappropriate. There were no technical reasons for rejecting my > simple original suggestion. Only dogmatic arguments, whose intent is > very clear: to resist any effort, even an infinitesimal one, on the > Posix side, even if it imposes an unduly heavy burden on me and on the > end users. There's nothing between this and constructive criticism on > the one hand, and "ego" on the other. We're trying to minimize or eliminate your burden, but you seem unwilling to consider the slightest change. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 13:09 ` Jim Meyering @ 2011-01-26 13:29 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:29 UTC (permalink / raw) To: Jim Meyering Cc: eggert, bug-gnulib, emacs-devel, monnier, roucaries.bastien, sdl.web > From: Jim Meyering <jim@meyering.net> > Cc: sdl.web@gmail.com, roucaries.bastien@gmail.com, eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Wed, 26 Jan 2011 14:09:39 +0100 > > Taking well-intended technical suggestions as a personal attack It cannot be anything else, when "technical suggestions" boil down to making the job of a fellow developer 1000 times harder for no good technical reasons, just because of "oh no, not that again" kind of irrationalities. The attack could be unintended, but any reasonable grown-up will realize that this is the result. > We are talking about process restrictions that you want to continue > to impose on the code of all developers The restrictions are minuscule. In my latest suggestion, rename only 3 *.m4 files, in a way that still keeps descriptive names. I wonder how much time will be wasted on bykeshedding that one. > We're trying to minimize or eliminate your burden, but you seem > unwilling to consider the slightest change. I suggested a compromise solution a few hours ago, which does, I hope, constitute a change, but have yet to see any response. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 15:33 ` Eli Zaretskii 2011-01-25 16:32 ` Jim Meyering @ 2011-01-25 16:50 ` Ulrich Mueller 2011-01-25 18:50 ` Eli Zaretskii 2011-01-25 19:04 ` Stefan Monnier 2011-01-25 22:37 ` Bastien ROUCARIES 2 siblings, 2 replies; 99+ messages in thread From: Ulrich Mueller @ 2011-01-25 16:50 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, bug-gnulib, Jim Meyering, emacs-devel, monnier, roucaries.bastien >>>>> On Tue, 25 Jan 2011, Eli Zaretskii wrote: >> Forcing current and future emacs development into the archaic 8.3 >> mold has a significant cost > The costs are generally mine, and mine alone. Unfortunately, that is not entirely true. For example, most files of CEDET were renamed to 8+3 some time ago, breaking other elisp packages (e.g. company-mode, ecb, jde, matlab, speechd-el) depending on them. Ulrich ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 16:50 ` Ulrich Mueller @ 2011-01-25 18:50 ` Eli Zaretskii 2011-01-25 19:31 ` Ulrich Mueller 2011-01-25 19:52 ` Óscar Fuentes 2011-01-25 19:04 ` Stefan Monnier 1 sibling, 2 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 18:50 UTC (permalink / raw) To: Ulrich Mueller Cc: eggert, bug-gnulib, jim, emacs-devel, monnier, roucaries.bastien > Date: Tue, 25 Jan 2011 17:50:59 +0100 > From: Ulrich Mueller <ulm@gentoo.org> > Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, Jim Meyering <jim@meyering.net>, > emacs-devel@gnu.org, monnier@iro.umontreal.ca, roucaries.bastien@gmail.com > > For example, most files of CEDET were renamed to 8+3 some time ago, > breaking other elisp packages (e.g. company-mode, ecb, jde, matlab, > speechd-el) depending on them. Reality check: there were many changes made in CEDET due to admission into the Emacs distribution. File-name changes were only a small part of them, and the changes just moved some files into subdirectories, such that foo-bar.el became foo/bar.el. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 18:50 ` Eli Zaretskii @ 2011-01-25 19:31 ` Ulrich Mueller 2011-01-25 19:38 ` Eli Zaretskii 2011-01-25 19:52 ` Óscar Fuentes 1 sibling, 1 reply; 99+ messages in thread From: Ulrich Mueller @ 2011-01-25 19:31 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, bug-gnulib, jim, emacs-devel, monnier, roucaries.bastien >>>>> On Tue, 25 Jan 2011, Eli Zaretskii wrote: >> For example, most files of CEDET were renamed to 8+3 some time ago, >> breaking other elisp packages (e.g. company-mode, ecb, jde, matlab, >> speechd-el) depending on them. > Reality check: there were many changes made in CEDET due to admission > into the Emacs distribution. File-name changes were only a small part > of them, and the changes just moved some files into subdirectories, > such that foo-bar.el became foo/bar.el. Which still breaks compatibility, because (require 'foo-bar) in any elisp package will fail now. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 19:31 ` Ulrich Mueller @ 2011-01-25 19:38 ` Eli Zaretskii 2011-01-25 20:00 ` Ulrich Mueller 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 19:38 UTC (permalink / raw) To: Ulrich Mueller Cc: eggert, bug-gnulib, jim, emacs-devel, monnier, roucaries.bastien > Date: Tue, 25 Jan 2011 20:31:30 +0100 > From: Ulrich Mueller <ulm@gentoo.org> > Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, jim@meyering.net, > emacs-devel@gnu.org, monnier@iro.umontreal.ca, roucaries.bastien@gmail.com > > > Reality check: there were many changes made in CEDET due to admission > > into the Emacs distribution. File-name changes were only a small part > > of them, and the changes just moved some files into subdirectories, > > such that foo-bar.el became foo/bar.el. > > Which still breaks compatibility, because (require 'foo-bar) in any > elisp package will fail now. And that was the single backward-incompatible change in CEDET? ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 19:38 ` Eli Zaretskii @ 2011-01-25 20:00 ` Ulrich Mueller 2011-01-25 20:09 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Ulrich Mueller @ 2011-01-25 20:00 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, bug-gnulib, jim, emacs-devel, monnier, roucaries.bastien >>>>> On Tue, 25 Jan 2011, Eli Zaretskii wrote: >> > Reality check: there were many changes made in CEDET due to admission >> > into the Emacs distribution. File-name changes were only a small part >> > of them, and the changes just moved some files into subdirectories, >> > such that foo-bar.el became foo/bar.el. >> >> Which still breaks compatibility, because (require 'foo-bar) in any >> elisp package will fail now. > And that was the single backward-incompatible change in CEDET? No, but your original statement was: "The costs are generally mine, and mine alone." These renamed files have to be taken account for in all packages using CEDET, and that means additional work for the upstreams of these packages and for distro builders. Therefore, at least in the case of CEDET, the costs are not yours alone. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 20:00 ` Ulrich Mueller @ 2011-01-25 20:09 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 20:09 UTC (permalink / raw) To: Ulrich Mueller Cc: eggert, bug-gnulib, jim, emacs-devel, monnier, roucaries.bastien > Date: Tue, 25 Jan 2011 21:00:16 +0100 > Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, jim@meyering.net, > emacs-devel@gnu.org, monnier@iro.umontreal.ca, > roucaries.bastien@gmail.com > From: Ulrich Mueller <ulm@gentoo.org> > > >>>>> On Tue, 25 Jan 2011, Eli Zaretskii wrote: > > >> > Reality check: there were many changes made in CEDET due to admission > >> > into the Emacs distribution. File-name changes were only a small part > >> > of them, and the changes just moved some files into subdirectories, > >> > such that foo-bar.el became foo/bar.el. > >> > >> Which still breaks compatibility, because (require 'foo-bar) in any > >> elisp package will fail now. > > > And that was the single backward-incompatible change in CEDET? > > No, but your original statement was: "The costs are generally mine, > and mine alone." The word "generally" is there for a reason. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 18:50 ` Eli Zaretskii 2011-01-25 19:31 ` Ulrich Mueller @ 2011-01-25 19:52 ` Óscar Fuentes 2011-01-25 20:19 ` Eli Zaretskii 1 sibling, 1 reply; 99+ messages in thread From: Óscar Fuentes @ 2011-01-25 19:52 UTC (permalink / raw) To: Eli Zaretskii Cc: eggert, Ulrich Mueller, jim, emacs-devel, monnier, roucaries.bastien Eli Zaretskii <eliz@gnu.org> writes: >> For example, most files of CEDET were renamed to 8+3 some time ago, >> breaking other elisp packages (e.g. company-mode, ecb, jde, matlab, >> speechd-el) depending on them. > > Reality check: there were many changes made in CEDET due to admission > into the Emacs distribution. File-name changes were only a small part > of them, and the changes just moved some files into subdirectories, > such that foo-bar.el became foo/bar.el. Those changes were a burden the day I tried to use an external package which adds CEDET-based C# code completion to Emacs. I thought that as the supposedly difficult part of installing CEDET was already done thanks to its integration into the Emacs distribution, applying the simple instructions for adding the C# package would be a piece of cake. But soon discovered that the instructions and the .el file referenced several files that apparently were missing from Emacs. After some investigation I learned that those files were moved. It was not fun to locate each file and patch the external package. Moving the files will cause extra work to those who maintain external CEDET packages, so they must introduce changes for supporting the new places while keeping compatibility with the old ones. This is just to demonstrate that the 8+3 issue is not as irrelevant as you say. That said, I'm glad that the DOS port provides motivation for keeping you as an Emacs maintainer, some renaming from time to time is a little price to pay for that. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 19:52 ` Óscar Fuentes @ 2011-01-25 20:19 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 20:19 UTC (permalink / raw) To: Óscar Fuentes Cc: eggert, ulm, jim, emacs-devel, monnier, roucaries.bastien > From: Óscar Fuentes <ofv@wanadoo.es> > Cc: Ulrich Mueller <ulm@gentoo.org>, eggert@cs.ucla.edu, jim@meyering.net, emacs-devel@gnu.org, monnier@iro.umontreal.ca, roucaries.bastien@gmail.com > Date: Tue, 25 Jan 2011 20:52:22 +0100 > > This is just to demonstrate that the 8+3 issue is not as irrelevant as > you say. Well, I didn't really mean to say they were irrelevant, just that they are not as significant as this thread seems to indicate. > That said, I'm glad that the DOS port provides motivation for > keeping you as an Emacs maintainer, some renaming from time to time is a > little price to pay for that. Thank you for your kind words. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 16:50 ` Ulrich Mueller 2011-01-25 18:50 ` Eli Zaretskii @ 2011-01-25 19:04 ` Stefan Monnier 2011-01-25 19:36 ` Eli Zaretskii 1 sibling, 1 reply; 99+ messages in thread From: Stefan Monnier @ 2011-01-25 19:04 UTC (permalink / raw) To: Ulrich Mueller Cc: eggert, bug-gnulib, Jim Meyering, emacs-devel, roucaries.bastien, Eli Zaretskii > For example, most files of CEDET were renamed to 8+3 some time ago, > breaking other elisp packages (e.g. company-mode, ecb, jde, matlab, > speechd-el) depending on them. Indeed the CEDET renaming was (and still is) a source of problems because there is still an "upstream" that hasn't done the same renaming yet (or has been done, finally?). But in this particular case, I'd argue that the restructuring was for the better. This said, I'd be happy if we could solve the 8+3 issue differently. Eli, what do you think of Paul's suggestion to use "djtar -n emacs-25.chg emacs-25.tgz" -- Stefan ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 19:04 ` Stefan Monnier @ 2011-01-25 19:36 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 19:36 UTC (permalink / raw) To: Stefan Monnier Cc: eggert, bug-gnulib, ulm, jim, emacs-devel, roucaries.bastien > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu, bug-gnulib@gnu.org, > Jim Meyering <jim@meyering.net>, emacs-devel@gnu.org, > roucaries.bastien@gmail.com > Date: Tue, 25 Jan 2011 14:04:44 -0500 > > This said, I'd be happy if we could solve the 8+3 issue differently. I will go with any solution that does not unduly increases the burden and does not involve tedious manual work down the line. For now, the only alternatives I heard more or less told me to go screw myself. > Eli, what do you think of Paul's suggestion to use > > "djtar -n emacs-25.chg emacs-25.tgz" I already replied: this kind of scheme is used by GDB, and it works very badly. I don't want to go that way in Emacs. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 15:33 ` Eli Zaretskii 2011-01-25 16:32 ` Jim Meyering 2011-01-25 16:50 ` Ulrich Mueller @ 2011-01-25 22:37 ` Bastien ROUCARIES 2011-01-26 3:49 ` Eli Zaretskii 2 siblings, 1 reply; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-25 22:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, eggert, bug-gnulib, Jim Meyering, monnier Le mardi 25 janvier 2011 16:33:40, Eli Zaretskii a écrit : > I think that the occasional hour or two I invest once in a few weeks > when the DOS build becomes broken and I need to fix it is well payed > by the benefits that brings to Emacs development in general, by > uncovering bugs in those rare configurations. And if it does some > service to a niche user community while at that, what's wrong with > that? > > > If something like doslfn is reliable enough > > and not hard to install, then requiring it makes sense: then all emacs > > developers will be freed of this onerous file-naming constraint. > > It's impossible for me to say if doslfn is reliable. I never used it > myself, nor was it ever used widely enough by DJGPP users. > > As for the onerous file-naming constraint, we have more than 3000 > files in the Emacs tree, and the problem is limited to just 7 or so, > all of them recent additions. > > > Imposing small relatively transparent requirements on users of less > > common systems is actually a good practice, when doing so permits > > improvements in the development process. > > I'm not aware of any improvements in the development process that the > DOS port imposes. A quick search on google show that doslfn is used by DJGPP user. Moreover, instead of fixing bugs in source package, it will allow a final fix for dos. And instead of renaming and thus using your time doing every time the same stuff, you could fix the doslfn package is buggy. If fixed once, it will definitvly fix the 8.3 problem (if and only if doslfn is buggy, and it does not seems according to a quick search). Bastien ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 22:37 ` Bastien ROUCARIES @ 2011-01-26 3:49 ` Eli Zaretskii 2011-01-26 11:02 ` Jim Meyering 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 3:49 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: emacs-devel, eggert, bug-gnulib, jim, monnier > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Date: Tue, 25 Jan 2011 23:37:08 +0100 > Cc: Jim Meyering <jim@meyering.net>, > eggert@cs.ucla.edu, > bug-gnulib@gnu.org, > monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > (if and only if doslfn is buggy, and it does not seems according to a quick search). Your search was too quick. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 3:49 ` Eli Zaretskii @ 2011-01-26 11:02 ` Jim Meyering 2011-01-26 11:52 ` Bastien ROUCARIES ` (2 more replies) 0 siblings, 3 replies; 99+ messages in thread From: Jim Meyering @ 2011-01-26 11:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Bastien ROUCARIES, eggert, bug-gnulib, monnier, emacs-devel Eli Zaretskii wrote: >> From: Bastien ROUCARIES <roucaries.bastien@gmail.com> >> Date: Tue, 25 Jan 2011 23:37:08 +0100 >> >> (if and only if doslfn is buggy, and it does not seems according to >> a quick search). > > Your search was too quick. Considering your wish to continue supporting emacs on DOS, I would have thought you would jump at a possible solution like this. If it works (and indications are that it does), then it defines away the whole problem. Wouldn't you welcome the idea of a DOS port with no risk of 8.3 collisions? What if the solution really is as easy as it appears? Here is a recently-updated FAQ: http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en Please give it an honest try before dismissing it. Just because someone wrote about a problem does not mean using it to build Emacs will trigger the same one. And even if it does, report it nicely and someone might even fix it right away. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 11:02 ` Jim Meyering @ 2011-01-26 11:52 ` Bastien ROUCARIES 2011-01-26 11:58 ` Bastien ROUCARIES 2011-01-26 13:12 ` Eli Zaretskii 2011-01-26 12:52 ` Eli Zaretskii 2012-08-23 11:36 ` Bastien ROUCARIES 2 siblings, 2 replies; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-26 11:52 UTC (permalink / raw) To: Jim Meyering; +Cc: Eli Zaretskii, eggert, bug-gnulib, monnier, emacs-devel Le mercredi 26 janvier 2011 12:02:47, Jim Meyering a écrit : > Eli Zaretskii wrote: > >> From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > >> Date: Tue, 25 Jan 2011 23:37:08 +0100 > >> > >> (if and only if doslfn is buggy, and it does not seems according to > >> a quick search). > > > > Your search was too quick. > > Considering your wish to continue supporting emacs on DOS, > I would have thought you would jump at a possible solution like this. > If it works (and indications are that it does), then it defines > away the whole problem. Know bug list is pretty short note > Wouldn't you welcome the idea of a DOS > port with no risk of 8.3 collisions? > > What if the solution really is as easy as it appears? Here is a > recently-updated FAQ: > > http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en > > Please give it an honest try before dismissing it. > > Just because someone wrote about a problem does not > mean using it to build Emacs will trigger the same one. > And even if it does, report it nicely and someone might > even fix it right away. Moreover freedos seems to use routinly doslfn. So it is a least a little bit tested. Bastien ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 11:52 ` Bastien ROUCARIES @ 2011-01-26 11:58 ` Bastien ROUCARIES 2011-01-26 13:12 ` Eli Zaretskii 1 sibling, 0 replies; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-26 11:58 UTC (permalink / raw) To: Jim Meyering; +Cc: Eli Zaretskii, eggert, bug-gnulib, monnier, emacs-devel Le mercredi 26 janvier 2011 12:52:33, Bastien ROUCARIES a écrit : > Le mercredi 26 janvier 2011 12:02:47, Jim Meyering a écrit : > > Eli Zaretskii wrote: > > >> From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > > >> Date: Tue, 25 Jan 2011 23:37:08 +0100 > > >> > > >> (if and only if doslfn is buggy, and it does not seems according to > > >> a quick search). > > > > > > Your search was too quick. > > > > Considering your wish to continue supporting emacs on DOS, > > I would have thought you would jump at a possible solution like this. > > If it works (and indications are that it does), then it defines > > away the whole problem. > > Know bug list is pretty short note > > > Wouldn't you welcome the idea of a DOS > > port with no risk of 8.3 collisions? > > > > What if the solution really is as easy as it appears? Here is a > > > > recently-updated FAQ: > > http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en > > > > Please give it an honest try before dismissing it. > > > > Just because someone wrote about a problem does not > > mean using it to build Emacs will trigger the same one. > > And even if it does, report it nicely and someone might > > even fix it right away. > > Moreover freedos seems to use routinly doslfn. So it is a least a little > bit tested. and used by 4dos one of the most usuable dos file manager http://4dos.isgreat.org Bastien ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 11:52 ` Bastien ROUCARIES 2011-01-26 11:58 ` Bastien ROUCARIES @ 2011-01-26 13:12 ` Eli Zaretskii 1 sibling, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:12 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: eggert, bug-gnulib, jim, monnier, emacs-devel > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Date: Wed, 26 Jan 2011 12:52:33 +0100 > Cc: Eli Zaretskii <eliz@gnu.org>, > emacs-devel@gnu.org, > eggert@cs.ucla.edu, > bug-gnulib@gnu.org, > monnier@iro.umontreal.ca > > Moreover freedos seems to use routinly doslfn. So it is a least a > little bit tested. FreeDOS has known issues with DJGPP. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 11:02 ` Jim Meyering 2011-01-26 11:52 ` Bastien ROUCARIES @ 2011-01-26 12:52 ` Eli Zaretskii 2011-01-26 13:33 ` Bastien ROUCARIES 2012-08-23 11:36 ` Bastien ROUCARIES 2 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 12:52 UTC (permalink / raw) To: Jim Meyering; +Cc: roucaries.bastien, eggert, bug-gnulib, monnier, emacs-devel > From: Jim Meyering <jim@meyering.net> > Cc: Bastien ROUCARIES <roucaries.bastien@gmail.com>, emacs-devel@gnu.org, eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca > Date: Wed, 26 Jan 2011 12:02:47 +0100 > > Eli Zaretskii wrote: > >> From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > >> Date: Tue, 25 Jan 2011 23:37:08 +0100 > >> > >> (if and only if doslfn is buggy, and it does not seems according to > >> a quick search). > > > > Your search was too quick. > > Considering your wish to continue supporting emacs on DOS, > I would have thought you would jump at a possible solution like this. The solution would need to be rock solid, for me to jump at it. DJGPP is very stable on plain DOS, and its users expect stability. > http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en > > Please give it an honest try before dismissing it. It obviously has problems with protected-mode programs and environments, and with DOS extenders. DJGPP programs switch the machine to 32-bit protected mode, so any programs that have difficulties with that environment are not promising. And the fact that DJGPP is not mentioned as a solution for DOS programs that support LFN does not help to remove the cloud. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 12:52 ` Eli Zaretskii @ 2011-01-26 13:33 ` Bastien ROUCARIES 2011-01-26 13:48 ` Eli Zaretskii 2011-01-26 14:35 ` Andy Moreton 0 siblings, 2 replies; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-26 13:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, bug-gnulib, Jim Meyering, monnier, emacs-devel > > Considering your wish to continue supporting emacs on DOS, > > I would have thought you would jump at a possible solution like this. > > The solution would need to be rock solid, for me to jump at it. DJGPP > is very stable on plain DOS, and its users expect stability. > > > http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en > > > > Please give it an honest try before dismissing it. > > It obviously has problems with protected-mode programs and > environments, and with DOS extenders. DJGPP programs switch the > machine to 32-bit protected mode, so any programs that have > difficulties with that environment are not promising. And the fact > that DJGPP is not mentioned as a solution for DOS programs that > support LFN does not help to remove the cloud. according to http://www.delorie.com/djgpp/doc/kb/kb_10.html "The DJGPP library features transparent and automatic support for long file names on Windows 9X(1) The DJGPP startup code queries the system for the availability of the LFN API, and if it's available, all low-level file-oriented primitives are automatically switched to using the special LFN-aware functions. This run-time detection of the LFN support means that the same executable will run on DOS and on Windows, and will automatically support long file names when it runs on Windows 9X" They are a faq entry on lfn: http://www.delorie.com/djgpp/v2faq/faq22_16.html And it seems that lfn is supported since djgpp 2.01 so since October 19, 1996. according to http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.DevelCppBeginners It could be used under drdos and with djgpp I agree with you about bug but they seems minor like this http://permalink.gmane.org/gmane.comp.emulators.freedos.kernel/1372 and could be fixed doslfn is moreover well supported due to adoption of win95 even on fat12. Therefore since 2001 (creation of doslfn), 8.3 name problem should not exist. Instead of tackling the main problem lack of 8.3 support and use the new api, you are stick in the 90's. Thanks Bastien ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:33 ` Bastien ROUCARIES @ 2011-01-26 13:48 ` Eli Zaretskii 2011-01-26 15:26 ` Bastien ROUCARIES 2011-01-26 14:35 ` Andy Moreton 1 sibling, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:48 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: eggert, bug-gnulib, jim, monnier, emacs-devel > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Date: Wed, 26 Jan 2011 14:33:54 +0100 > Cc: Jim Meyering <jim@meyering.net>, > emacs-devel@gnu.org, > eggert@cs.ucla.edu, > bug-gnulib@gnu.org, > monnier@iro.umontreal.ca > > according to http://www.delorie.com/djgpp/doc/kb/kb_10.html > "The DJGPP library features transparent and automatic support for long file names on Windows 9X(1) The DJGPP startup code queries > the system for the availability of the LFN API, and if it's available, all low-level file-oriented primitives are automatically > switched to using the special LFN-aware functions. This run-time detection of the LFN support means that the same executable will > run on DOS and on Windows, and will automatically support long file names when it runs on Windows 9X" Yes, I know. I wrote some of those "low-level file-oriented primitives". > They are a faq entry on lfn: > http://www.delorie.com/djgpp/v2faq/faq22_16.html Did you see who wrote that FAQ? > And it seems that lfn is supported since djgpp 2.01 so since October 19, 1996. That's not the issue, you misunderstood my comment. The issue is that DJGPP programs switch the CPU to 32-bit protected mode, and use a DPMI server to issue real-mode DOS and BIOS system calls from protected mode. doslfn seems to have problems with such programs (which is not surprising, since any TSR that hooks interrupts might have problems in protected mode). ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:48 ` Eli Zaretskii @ 2011-01-26 15:26 ` Bastien ROUCARIES 2011-01-26 15:46 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-26 15:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, bug-gnulib, jim, monnier, emacs-devel Le mercredi 26 janvier 2011 14:48:18, Eli Zaretskii a écrit : > > "The DJGPP library features transparent and automatic support for long > > file names on Windows 9X(1) The DJGPP startup code queries the system > > for the availability of the LFN API, and if it's available, all > > low-level file-oriented primitives are automatically switched to using > > the special LFN-aware functions. This run-time detection of the LFN > > support means that the same executable will run on DOS and on Windows, > > and will automatically support long file names when it runs on Windows > > 9X" > > Yes, I know. I wrote some of those "low-level file-oriented primitives". > > > They are a faq entry on lfn: > > http://www.delorie.com/djgpp/v2faq/faq22_16.html > > Did you see who wrote that FAQ? Yes you :) > > And it seems that lfn is supported since djgpp 2.01 so since October 19, > > 1996. > > That's not the issue, you misunderstood my comment. The issue is that > DJGPP programs switch the CPU to 32-bit protected mode, and use a DPMI > server to issue real-mode DOS and BIOS system calls from protected > mode. doslfn seems to have problems with such programs (which is not > surprising, since any TSR that hooks interrupts might have problems in > protected mode). This is the real bug, and I suppose "might have problems" means this bug could be fixed. And do not talk about bare metal. DPMI is not bare metal dos*. So we could add another layer, that is doslfn in order to compile emacs... Bastien * at least in my sense ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 15:26 ` Bastien ROUCARIES @ 2011-01-26 15:46 ` Eli Zaretskii 2011-01-26 15:57 ` Bastien ROUCARIES 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 15:46 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: eggert, bug-gnulib, jim, monnier, emacs-devel > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Date: Wed, 26 Jan 2011 16:26:05 +0100 > Cc: jim@meyering.net, > emacs-devel@gnu.org, > eggert@cs.ucla.edu, > bug-gnulib@gnu.org, > monnier@iro.umontreal.ca > > And do not talk about bare metal. DPMI is not bare metal dos*. Yes, it is, because DJGPP includes a DPMI host in its development kit, and each DJGPP program (including Emacs) loads that DPMI host into memory if it is not already there at startup time. So you only need a plain stock DOS system to run DJGPP. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 15:46 ` Eli Zaretskii @ 2011-01-26 15:57 ` Bastien ROUCARIES 2011-01-26 18:56 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-26 15:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, bug-gnulib, jim, monnier, emacs-devel Le mercredi 26 janvier 2011 16:46:29, Eli Zaretskii a écrit : > > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > > Date: Wed, 26 Jan 2011 16:26:05 +0100 > > Cc: jim@meyering.net, > > > > emacs-devel@gnu.org, > > eggert@cs.ucla.edu, > > bug-gnulib@gnu.org, > > monnier@iro.umontreal.ca > > > > And do not talk about bare metal. DPMI is not bare metal dos*. > > Yes, it is, because DJGPP includes a DPMI host in its development kit, > and each DJGPP program (including Emacs) loads that DPMI host into > memory if it is not already there at startup time. So you only need a > plain stock DOS system to run DJGPP. For sure and why not supply a doslfn module (fixed) in djgpp ? And you do not answer about: >This is the real bug, and I suppose "might have problems" means this bug could be fixed. I suppose the problem could be fixed because some scsi disk/network disk of this era use tsr and could be browsed from dpmi mode. Bastien ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 15:57 ` Bastien ROUCARIES @ 2011-01-26 18:56 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 18:56 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: eggert, bug-gnulib, jim, monnier, emacs-devel > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Date: Wed, 26 Jan 2011 16:57:10 +0100 > Cc: jim@meyering.net, > emacs-devel@gnu.org, > eggert@cs.ucla.edu, > bug-gnulib@gnu.org, > monnier@iro.umontreal.ca > > why not supply a doslfn module (fixed) in djgpp ? Because DJGPP has seen its last release 8.5 years ago, and will not see another one. Its development is finished. (There are a couple of enthusiasts who still work on development, but the development code will never leave the alpha status, for lack of heavy users to test it well enough for it to get to release quality.) > And you do not answer about: > >This is the real bug, and I suppose "might have problems" means this bug could be fixed. > I suppose the problem could be fixed because some scsi disk/network disk of this era use tsr and could be browsed from dpmi mode. I doubt we will find someone to fix that. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:33 ` Bastien ROUCARIES 2011-01-26 13:48 ` Eli Zaretskii @ 2011-01-26 14:35 ` Andy Moreton 2011-01-26 15:31 ` Bastien ROUCARIES 2011-01-27 10:54 ` Simon Josefsson 1 sibling, 2 replies; 99+ messages in thread From: Andy Moreton @ 2011-01-26 14:35 UTC (permalink / raw) To: bug-gnulib; +Cc: emacs-devel On Wed 26 Jan 2011, Bastien ROUCARIES wrote: > Therefore since 2001 (creation of doslfn), 8.3 name problem should not > exist. > > Instead of tackling the main problem lack of 8.3 support and use the > new api, you are stick in the 90's. It seems odd to me that the developers of a GNU library fight so hard to avoid their code being portable. The gnulib manual [1] says: Gnulib is useful to enhance various aspects of a package: * Portability: With Gnulib, a package maintainer can program against the POSIX and GNU libc APIs and nevertheless expect good portability to platforms that don't implement POSIX. * Maintainability: When a package uses modules from Gnulib instead of code written specifically for that package, the maintainer has less code to maintain. It seems that manual promotes exactly the features that Eli needs. AndyM [1] http://www.gnu.org/software/gnulib/manual/html_node/Benefits.html#Benefits ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 14:35 ` Andy Moreton @ 2011-01-26 15:31 ` Bastien ROUCARIES 2011-01-26 18:28 ` Miles Bader 2011-01-26 18:59 ` Eli Zaretskii 2011-01-27 10:54 ` Simon Josefsson 1 sibling, 2 replies; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-26 15:31 UTC (permalink / raw) To: bug-gnulib; +Cc: Andy Moreton, emacs-devel Le mercredi 26 janvier 2011 15:35:52, Andy Moreton a écrit : > On Wed 26 Jan 2011, Bastien ROUCARIES wrote: > > Therefore since 2001 (creation of doslfn), 8.3 name problem should not > > exist. > > > > Instead of tackling the main problem lack of 8.3 support and use the > > new api, you are stick in the 90's. > > It seems odd to me that the developers of a GNU library fight so > hard to avoid their code being portable. The gnulib manual [1] says: > > Gnulib is useful to enhance various aspects of a package: > > * Portability: With Gnulib, a package maintainer can program > against the POSIX and GNU libc APIs and nevertheless expect good > portability to platforms that don't implement POSIX. > > * Maintainability: When a package uses modules from Gnulib instead > of code written specifically for that package, the maintainer has > less code to maintain. > > It seems that manual promotes exactly the features that Eli needs. > > AndyM 8.3 limitation is really of another age, and could be lifted on dos is doslfn is fixed. DJGPP need dpmi adding a prerequist of doslfn is not so hard in order to compile (not run) emacs. Bastien ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 15:31 ` Bastien ROUCARIES @ 2011-01-26 18:28 ` Miles Bader 2011-01-26 18:59 ` Eli Zaretskii 1 sibling, 0 replies; 99+ messages in thread From: Miles Bader @ 2011-01-26 18:28 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: Andy Moreton, bug-gnulib, emacs-devel Bastien ROUCARIES <roucaries.bastien@gmail.com> writes: >> It seems odd to me that the developers of a GNU library fight so >> hard to avoid their code being portable. The gnulib manual [1] says: > > 8.3 limitation is really of another age, and could be lifted on dos is > doslfn is fixed. DJGPP need dpmi adding a prerequist of > doslfn is not so hard in order to compile (not run) emacs. Indeed: "portability" is a good goal in general, but it's a vague word. There are obviously points at which it can be taken too far, where the benefit isn't enough to justify the effort required and resulting obfuscation of the code base. Where these points are, of course, shifts over time. [E.g., the once fairly widespread goal of supporting pre-ANSI C compilers seems to have been largely abandoned these days.] I'm not saying MSDOS has reached that point yet, just that a goal of "portability" needs to be judged in the appropriate context. -miles -- Joy, n. An emotion variously excited, but in its highest degree arising from the contemplation of grief in another. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 15:31 ` Bastien ROUCARIES 2011-01-26 18:28 ` Miles Bader @ 2011-01-26 18:59 ` Eli Zaretskii 1 sibling, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 18:59 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: andrewjmoreton, bug-gnulib, emacs-devel > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Date: Wed, 26 Jan 2011 16:31:04 +0100 > Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org > > DJGPP need dpmi adding a prerequist of doslfn is not so hard in > order to compile (not run) emacs. Not true. Once we allow any clashes of file names anywhere in Emacs, soon enough we will have them in the Lisp files, and then LFNs will be a necessity for Emacs to run as well, not just to be built. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 14:35 ` Andy Moreton 2011-01-26 15:31 ` Bastien ROUCARIES @ 2011-01-27 10:54 ` Simon Josefsson 2011-01-28 2:27 ` Paul Eggert 1 sibling, 1 reply; 99+ messages in thread From: Simon Josefsson @ 2011-01-27 10:54 UTC (permalink / raw) To: Andy Moreton; +Cc: bug-gnulib, emacs-devel Andy Moreton <andrewjmoreton@gmail.com> writes: > On Wed 26 Jan 2011, Bastien ROUCARIES wrote: > >> Therefore since 2001 (creation of doslfn), 8.3 name problem should not >> exist. >> >> Instead of tackling the main problem lack of 8.3 support and use the >> new api, you are stick in the 90's. > > It seems odd to me that the developers of a GNU library fight so > hard to avoid their code being portable. The gnulib manual [1] says: > > Gnulib is useful to enhance various aspects of a package: > > * Portability: With Gnulib, a package maintainer can program > against the POSIX and GNU libc APIs and nevertheless expect good > portability to platforms that don't implement POSIX. > > * Maintainability: When a package uses modules from Gnulib instead > of code written specifically for that package, the maintainer has > less code to maintain. > > It seems that manual promotes exactly the features that Eli needs. This could probably be clarified in the gnulib manual, but my impression is that gnulib has always been agreesive about abandoning support for platforms that are not commercially supported and that we can't access and test patches on. For example, I believe SunOS 4 falls into this category. /Simon ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-27 10:54 ` Simon Josefsson @ 2011-01-28 2:27 ` Paul Eggert 0 siblings, 0 replies; 99+ messages in thread From: Paul Eggert @ 2011-01-28 2:27 UTC (permalink / raw) To: bug-gnulib; +Cc: emacs-devel On 01/27/2011 02:54 AM, Simon Josefsson wrote: > my impression is that gnulib has always been agreesive about > abandoning support for platforms that are not commercially supported > and that we can't access and test patches on. I'm not sure what "aggressive" means, but the general rule is that we try not to waste resources maintaining code that cannot easily be tested and that increases the maintenance burden for ordinary development. Another way of putting it is, if the original platform distributor no longer supports something, that's a good indication that we shouldn't bother either, as it indicates that the audience is too small to be worth committing our scarce resources to. > For example, I believe SunOS 4 falls into this category. SunOS 4 is still documented as being a target, though this may change as per the above. I personally haven't used SunOS 4 in years; has anyone else? > This could probably be clarified in the gnulib manual Here's what it currently says. Can you suggest which clarifications would be helpful? Originally much of the Gnulib code was portable to ancient hosts like 4.2BSD, but it is a maintenance hassle to maintain compatibility with unused hosts, so currently we assume at least a freestanding C89 compiler, possibly operating with a C library that predates C89. The oldest environment currently ported to is probably SunOS 4 + GCC 1.x, though we haven't tested this exact combination. SunOS 4 last shipped on 1998-09-30, and Sun dropped support for it on 2003-10-01, so at some point we may start assuming a C89 library as well. ... Even if the include files conform to C89, the library itself may not. For example, SunOS 4's (free (NULL)) can dump core, so Gnulib code must avoid freeing a null pointer, even though C89 allows it. You can work around some of these problems by requiring the relevant modules, e.g., the Gnulib 'free' module supplies a conforming 'free'. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 11:02 ` Jim Meyering 2011-01-26 11:52 ` Bastien ROUCARIES 2011-01-26 12:52 ` Eli Zaretskii @ 2012-08-23 11:36 ` Bastien ROUCARIES 2012-08-23 16:23 ` Eli Zaretskii 2 siblings, 1 reply; 99+ messages in thread From: Bastien ROUCARIES @ 2012-08-23 11:36 UTC (permalink / raw) To: Jim Meyering; +Cc: Eli Zaretskii, eggert, bug-gnulib, monnier, emacs-devel [sorry for retrieving this old thread] On Wed, Jan 26, 2011 at 1:02 PM, Jim Meyering <jim@meyering.net> wrote: > Eli Zaretskii wrote: >>> From: Bastien ROUCARIES <roucaries.bastien@gmail.com> >>> Date: Tue, 25 Jan 2011 23:37:08 +0100 >>> >>> (if and only if doslfn is buggy, and it does not seems according to >>> a quick search). >> >> Your search was too quick. > > Considering your wish to continue supporting emacs on DOS, > I would have thought you would jump at a possible solution like this. > If it works (and indications are that it does), then it defines > away the whole problem. Wouldn't you welcome the idea of a DOS > port with no risk of 8.3 collisions? > > What if the solution really is as easy as it appears? Here is a > recently-updated FAQ: > > http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en > > Please give it an honest try before dismissing it Moreover doslfn is activelly maintened. The upsteam release a new version in february. (http://adoxa.3eeweb.com/doslfn/), so time to drop 8.3 limitation in emacs build ? Bastien ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2012-08-23 11:36 ` Bastien ROUCARIES @ 2012-08-23 16:23 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2012-08-23 16:23 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: eggert, bug-gnulib, jim, monnier, emacs-devel > Date: Thu, 23 Aug 2012 13:36:16 +0200 > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, eggert@cs.ucla.edu, > bug-gnulib@gnu.org, monnier@iro.umontreal.ca > > [sorry for retrieving this old thread] I suggest to let the sleeping dogs lie. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 14:51 ` Jim Meyering 2011-01-25 15:33 ` Eli Zaretskii @ 2011-01-25 16:03 ` Leo 2011-01-25 17:16 ` Miles Bader 2011-01-25 18:05 ` Eli Zaretskii 1 sibling, 2 replies; 99+ messages in thread From: Leo @ 2011-01-25 16:03 UTC (permalink / raw) To: emacs-devel; +Cc: bug-gnulib On 2011-01-25 22:51 +0800, Jim Meyering wrote: > Forcing current and future emacs development into the archaic 8.3 mold has > a significant cost (just look at how long this thread is), yet provides > relatively little benefit. I also think it is insane, the 8+3 thing. It is a huge burden evidenced by loads of weirdly-named files in the repo. Leo -- Oracle is the new evil ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 16:03 ` RE : " Leo @ 2011-01-25 17:16 ` Miles Bader 2011-01-26 2:33 ` Stephen J. Turnbull 2011-01-26 7:18 ` Dan Nicolaescu 2011-01-25 18:05 ` Eli Zaretskii 1 sibling, 2 replies; 99+ messages in thread From: Miles Bader @ 2011-01-25 17:16 UTC (permalink / raw) To: Leo; +Cc: bug-gnulib, emacs-devel Leo <sdl.web@gmail.com> writes: >> Forcing current and future emacs development into the archaic 8.3 mold has >> a significant cost (just look at how long this thread is), yet provides >> relatively little benefit. > > I also think it is insane, the 8+3 thing. It is a huge burden evidenced > by loads of weirdly-named files in the repo. I don't know whether to call it a "huge" burden, but it is clearly a burden. I wonder if there are actually any users... -Miles -- Egotist, n. A person of low taste, more interested in himself than in me. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 17:16 ` Miles Bader @ 2011-01-26 2:33 ` Stephen J. Turnbull 2011-01-26 7:18 ` Dan Nicolaescu 1 sibling, 0 replies; 99+ messages in thread From: Stephen J. Turnbull @ 2011-01-26 2:33 UTC (permalink / raw) To: Miles Bader; +Cc: bug-gnulib, Leo, emacs-devel Miles Bader writes: > I wonder if there are actually any users [of DJGPP Emacs] ... Yes, there are; Eli gets at least one or two messages of thanks for every release. If you want a count, I'd suggest asking on the DJGPP list. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 17:16 ` Miles Bader 2011-01-26 2:33 ` Stephen J. Turnbull @ 2011-01-26 7:18 ` Dan Nicolaescu 2011-01-26 16:15 ` Stefan Monnier 1 sibling, 1 reply; 99+ messages in thread From: Dan Nicolaescu @ 2011-01-26 7:18 UTC (permalink / raw) To: Miles Bader; +Cc: bug-gnulib, Leo, emacs-devel Miles Bader <miles@gnu.org> writes: > Leo <sdl.web@gmail.com> writes: >>> Forcing current and future emacs development into the archaic 8.3 mold has >>> a significant cost (just look at how long this thread is), yet provides >>> relatively little benefit. >> >> I also think it is insane, the 8+3 thing. It is a huge burden evidenced >> by loads of weirdly-named files in the repo. > > I don't know whether to call it a "huge" burden, but it is clearly a burden. > > I wonder if there are actually any users... When we removed support for a lot of old systems 3 years ago MSDOS was on the list of systems to be removed, nobody claimed to still use Emacs on that platform. Since then, there was a single user that said that he still used it. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 7:18 ` Dan Nicolaescu @ 2011-01-26 16:15 ` Stefan Monnier 2011-01-27 3:08 ` Dan Nicolaescu 0 siblings, 1 reply; 99+ messages in thread From: Stefan Monnier @ 2011-01-26 16:15 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel, bug-gnulib, Leo, Miles Bader > When we removed support for a lot of old systems 3 years ago MSDOS was > on the list of systems to be removed, nobody claimed to still use > Emacs on that platform. > Since then, there was a single user that said that he still used it. MS-DOS nowadays is a pretty special niche, so I'm not surprised we don't hear from them much here. Stefan ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-26 16:15 ` Stefan Monnier @ 2011-01-27 3:08 ` Dan Nicolaescu 0 siblings, 0 replies; 99+ messages in thread From: Dan Nicolaescu @ 2011-01-27 3:08 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel, bug-gnulib, Leo, Miles Bader Stefan Monnier <monnier@iro.umontreal.ca> writes: >> When we removed support for a lot of old systems 3 years ago MSDOS was >> on the list of systems to be removed, nobody claimed to still use >> Emacs on that platform. >> Since then, there was a single user that said that he still used it. > > MS-DOS nowadays is a pretty special niche, so I'm not surprised we don't > hear from them much here. At what point can we say that this pretty special niche is served well enough by emacs-2X.Y, so that we don't need to support it in new releases? ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: RE : Re: Files from gnulib 2011-01-25 16:03 ` RE : " Leo 2011-01-25 17:16 ` Miles Bader @ 2011-01-25 18:05 ` Eli Zaretskii 1 sibling, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 18:05 UTC (permalink / raw) To: Leo; +Cc: bug-gnulib, emacs-devel > From: Leo <sdl.web@gmail.com> > Date: Wed, 26 Jan 2011 00:03:18 +0800 > Cc: bug-gnulib@gnu.org > > I also think it is insane, the 8+3 thing. It is a huge burden evidenced > by loads of weirdly-named files in the repo. What on Earth are you talking about? what "loads" of which "weirdly-named" files do you mean? And how is that related to this discussion? The number of times I asked for renaming files was quite small, so if there are "loads" of files that annoy you, MSDOS compatibility is not the reason. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Files from gnulib @ 2011-01-23 12:15 Eli Zaretskii 2011-01-23 12:40 ` Eli Zaretskii 2011-01-23 19:29 ` Paul Eggert 0 siblings, 2 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-23 12:15 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel Some of the new files added from gnulib use file names that are invalid on 8+3 (aka MSDOS) filesystems. These files are: c++defs.h -- the `+' character is not allowed in file names lib/stddef.in.h lib/time.in.h lib/unistd.in.h -- 2 dots are not allowed In addition, several file names in the m4/ subdirectory clash after 8+3 truncation: gnulib-cache.m4 gnulib-common.m4 gnulib-comp.m4 This will cause problems when unpacking the emacs tarball on those filesystems, something we managed to avoid until now. Can these files be renamed, please? I suggest cxxdefs.h for the first and FOO.in for the FOO.in.h files. For the files in m4/, how about transposing the "gnulib" part with the rest, i.e. cache-gnulib.m4 etc.? (I would remove the files myself, but I don't know what changes in the gnulib imports will that require.) TIA ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-23 12:15 Eli Zaretskii @ 2011-01-23 12:40 ` Eli Zaretskii 2011-01-23 19:29 ` Paul Eggert 1 sibling, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-23 12:40 UTC (permalink / raw) To: eggert, emacs-devel > Date: Sun, 23 Jan 2011 14:15:43 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > lib/stddef.in.h lib/time.in.h lib/unistd.in.h -- 2 dots are not allowed Forgot getopt.in.h. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-23 12:15 Eli Zaretskii 2011-01-23 12:40 ` Eli Zaretskii @ 2011-01-23 19:29 ` Paul Eggert 2011-01-23 22:16 ` Bruno Haible ` (2 more replies) 1 sibling, 3 replies; 99+ messages in thread From: Paul Eggert @ 2011-01-23 19:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnulib, emacs-devel [Adding bug-gnulib to the thread that started in <http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00761.html>]: On 01/23/2011 04:15 AM, Eli Zaretskii wrote: > Some of the new files added from gnulib use file names that are > invalid on 8+3 (aka MSDOS) filesystems. These files are: > > c++defs.h -- the `+' character is not allowed in file names I am sympathetic to the proposal to rename c++defs.h to cxxdefs.h, as "+" is not in the POSIX portable file name character set; see <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_276>. > lib/stddef.in.h lib/time.in.h lib/unistd.in.h -- 2 dots are not allowed The Emacs trunk already has seventeen other files with 2 dots in their file names, with names like lisp/gnus/.dir-locals.el and admin/charsets/mapfiles/symbol.txt.gz. Since these haven't been a problem, why would file names like getopt.in.h be a problem? > In addition, several file names in the m4/ subdirectory clash after > 8+3 truncation: > > gnulib-cache.m4 gnulib-common.m4 gnulib-comp.m4 Again, the Emacs trunk already has several instances of truncation after 8+3 limits, such as lisp/org/org-compat.el versus lisp/org/org-complete.el, and test/cedet/semantic-ia-utest.el versus test/cedet/semantic-tests.el, and I don't see why files imported from gnulib would be different. > This will cause problems when unpacking the emacs tarball on those > filesystems, something we managed to avoid until now. > > Can these files be renamed, please? I suggest cxxdefs.h for the first > and FOO.in for the FOO.in.h files. For the files in m4/, how about > transposing the "gnulib" part with the rest, i.e. cache-gnulib.m4 > etc.? > > (I would remove the files myself, but I don't know what changes in the > gnulib imports will that require.) Developers on Microsoft Windows platforms all have access to better file systems these days, surely. And as shown above Emacs does not respect those limitations in other parts of its source tree. So, other than c++defs.h, I don't see the need for renaming these files. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-23 19:29 ` Paul Eggert @ 2011-01-23 22:16 ` Bruno Haible 2011-01-24 3:26 ` Stefan Monnier 2011-01-24 4:07 ` Eli Zaretskii 2 siblings, 0 replies; 99+ messages in thread From: Bruno Haible @ 2011-01-23 22:16 UTC (permalink / raw) To: bug-gnulib; +Cc: Eli Zaretskii, Paul Eggert, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1049 bytes --] Paul Eggert replied to Eli Zaretskii: > > Some of the new files added from gnulib use file names that are > > invalid on 8+3 (aka MSDOS) filesystems. These files are: > > > > c++defs.h -- the `+' character is not allowed in file names > > I am sympathetic to the proposal to rename c++defs.h to cxxdefs.h, > as "+" is not in the POSIX portable file name character set; see > <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_276>. I'm not sympathetic to this proposal. gnulib supports POSIX platforms and mingw, and all known POSIX platforms and mingw support '+' in file names. Eli's point is that he wants support for MSDOS file system. This is outside the scope of gnulib, and therefore is best solved within Emacs. It can be done by adding 2 files to the Emacs tree (see attached .tar.gz file) and by adding the option --local-dir=gnulib-local to the gnulib-tool invocation. See the gnulib documentation [1] for details. Bruno [1] <http://www.gnu.org/software/gnulib/manual/html_node/Extending-Gnulib.html> [-- Attachment #2: new-files.tar.gz --] [-- Type: application/x-tgz, Size: 1301 bytes --] ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-23 19:29 ` Paul Eggert 2011-01-23 22:16 ` Bruno Haible @ 2011-01-24 3:26 ` Stefan Monnier 2011-01-24 4:01 ` Eli Zaretskii 2011-01-24 7:57 ` Glenn Morris 2011-01-24 4:07 ` Eli Zaretskii 2 siblings, 2 replies; 99+ messages in thread From: Stefan Monnier @ 2011-01-24 3:26 UTC (permalink / raw) To: Paul Eggert; +Cc: Eli Zaretskii, bug-gnulib, emacs-devel > The Emacs trunk already has seventeen other files > with 2 dots in their file names, with names like > lisp/gnus/.dir-locals.el I don't know how MSDOS handles names that start with dot, so either this is a special case that's OK, or it's indeed a problem which we hadn't noticed yet. > and admin/charsets/mapfiles/symbol.txt.gz. This one, OTOH is OK because the `admin' subdir is not included in the tarball, so its name is irrelevant. >> In addition, several file names in the m4/ subdirectory clash after >> 8+3 truncation: >> gnulib-cache.m4 gnulib-common.m4 gnulib-comp.m4 > Again, the Emacs trunk already has several instances of truncation > after 8+3 limits, such as lisp/org/org-compat.el versus > lisp/org/org-complete.el, Good point. I guess Eli hadn't noticed it yet. > and test/cedet/semantic-ia-utest.el > versus test/cedet/semantic-tests.el, and I don't see why > files imported from gnulib would be different. Here, again, the `test' subdir is not included in the tarball, so it's not an issue. Stefan ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-24 3:26 ` Stefan Monnier @ 2011-01-24 4:01 ` Eli Zaretskii 2011-01-24 23:26 ` Paul Eggert 2011-01-24 7:57 ` Glenn Morris 1 sibling, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-24 4:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: eggert, bug-gnulib, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Eli Zaretskii <eliz@gnu.org>, bug-gnulib <bug-gnulib@gnu.org>, emacs-devel@gnu.org > Date: Sun, 23 Jan 2011 22:26:52 -0500 > > > The Emacs trunk already has seventeen other files > > with 2 dots in their file names, with names like > > lisp/gnus/.dir-locals.el > > I don't know how MSDOS handles names that start with dot, so either this > is a special case that's OK, or it's indeed a problem which we hadn't > noticed yet. The program used to unpack the .tar.gz archives automatically renames ant .FOO files to _FOO while unpacking, so that's not a problem. (This program, called djtar.exe, is part of the DJGPP package which is used to build Emacs on MSDOS.) > > and admin/charsets/mapfiles/symbol.txt.gz. > > This one, OTOH is OK because the `admin' subdir is not included in the > tarball, so its name is irrelevant. Right. > > Again, the Emacs trunk already has several instances of truncation > > after 8+3 limits, such as lisp/org/org-compat.el versus > > lisp/org/org-complete.el, > > Good point. I guess Eli hadn't noticed it yet. I did notice that. These files appeared very recently, and I didn't yet have time to talk to Org mode maintainers about renaming them. In the past a couple of other Org files were renamed for this reason, at my request. > > and test/cedet/semantic-ia-utest.el > > versus test/cedet/semantic-tests.el, and I don't see why > > files imported from gnulib would be different. > > Here, again, the `test' subdir is not included in the tarball, so it's > not an issue. Right. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-24 4:01 ` Eli Zaretskii @ 2011-01-24 23:26 ` Paul Eggert 2011-01-25 4:00 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Paul Eggert @ 2011-01-24 23:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnulib, Stefan Monnier, emacs-devel On 01/23/11 20:01, Eli Zaretskii wrote: > The program used to unpack the .tar.gz archives automatically renames > ant .FOO files to _FOO while unpacking, so that's not a problem. OK, so it sounds like there's already part of a solution here, in that files are automatically renamed to avoid the MS-DOS restrictions. How about if we expand on that solution, as follows: * Just before creating a tarball for MS-DOS, apply the following substitutions to the contents of all files that go into the tarball: s/c++defs\.h/cxxdefs\.h/g s/\([a-zA-Z0-9_]*\)\.in\.h/_\1.h/g The latter substitution, for example, replaces all instances of unistd.in.h with _unistd.h. * Similarly, just before creating the tarball, rename all the source files according to the above patterns. * The above can be done in the make-dist implementation for MS-DOS. * The conflicting names in m4/* don't matter, for the same reason that conflicts in admin/* and tests/* don't matter: these files are not used in an MS-DOS build. With this approach, the problem of MS-DOS names is handled entirely in the MS-DOS port. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-24 23:26 ` Paul Eggert @ 2011-01-25 4:00 ` Eli Zaretskii 2011-01-25 8:48 ` Paul Eggert 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 4:00 UTC (permalink / raw) To: Paul Eggert; +Cc: bug-gnulib, monnier, emacs-devel > Date: Mon, 24 Jan 2011 15:26:06 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: Stefan Monnier <monnier@iro.umontreal.ca>, bug-gnulib@gnu.org, > emacs-devel@gnu.org > > On 01/23/11 20:01, Eli Zaretskii wrote: > > The program used to unpack the .tar.gz archives automatically renames > > ant .FOO files to _FOO while unpacking, so that's not a problem. > > OK, so it sounds like there's already part of a solution here, > in that files are automatically renamed to avoid the MS-DOS > restrictions. > > How about if we expand on that solution, as follows: > > * Just before creating a tarball for MS-DOS, apply > the following substitutions to the contents of all > files that go into the tarball: There are no special tarballs for MSDOS. People use the tarball from the GNU FTP site. So this solution will not work. > * The conflicting names in m4/* don't matter, for the same > reason that conflicts in admin/* and tests/* don't matter: > these files are not used in an MS-DOS build. The files in m4/ still matter because you need to unpack the tarball, and the utility that does that won't silently overwrite files due to file-name clashes. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 4:00 ` Eli Zaretskii @ 2011-01-25 8:48 ` Paul Eggert 2011-01-25 11:24 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Paul Eggert @ 2011-01-25 8:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnulib, monnier, emacs-devel On 01/24/2011 08:00 PM, Eli Zaretskii wrote: > There are no special tarballs for MSDOS. Ah, sorry, then I misunderstood. Well, then, instead of doing the stuff I mentioned before the tarball is created, we can add a shell script to be run after the tarball is extracted. For example, on MS-DOS the c++defs.h file is automatically renamed to cxxdefs.h by the extractor, so the script can uniformly substitute "cxxdefs.h" for "c++defs.h" in all the text files. Hopefully a similar idea works for all the other files with non-MS-DOS names. I assume that the "configure" procedure for MS-DOS is already different, so this new script can be folded into that procedure. > The files in m4/ still matter because you need to unpack the tarball, > and the utility that does that won't silently overwrite files due to > file-name clashes. That's OK. People can ignore those diagnostics, just as I assume they already ignore the diagnostics for the files whose names start with ".". It doesn't matter whether those files are extracted correctly, as the MS-DOS build doesn't use them. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 8:48 ` Paul Eggert @ 2011-01-25 11:24 ` Eli Zaretskii 2011-01-25 11:32 ` Bastien ROUCARIES 2011-01-25 18:07 ` Paul Eggert 0 siblings, 2 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 11:24 UTC (permalink / raw) To: Paul Eggert; +Cc: bug-gnulib, monnier, emacs-devel > Date: Tue, 25 Jan 2011 00:48:12 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: monnier@iro.umontreal.ca, bug-gnulib@gnu.org, emacs-devel@gnu.org > > instead of doing the stuff I mentioned before the tarball is > created, we can add a shell script to be run after the tarball is > extracted. For example, on MS-DOS the c++defs.h file is > automatically renamed to cxxdefs.h by the extractor, so the script > can uniformly substitute "cxxdefs.h" for "c++defs.h" in all the text > files. Hopefully a similar idea works for all the other files with > non-MS-DOS names. The magic coded into the extractor utility is limited. It indeed handles file names with `+' in them, but does not handle arbitrary file names with multiple dots as a human would. It uses some convoluted algorithm to replace the extra dot with a `_' or a `-'; sometimes it replaces the first dot, sometimes the second. The results are often unpredictable or surprising, especially if, as it often happens, the modified names also clash in the 8+3 namespace (see below). So going this way means a much more complex and error-prone arrangement than a one-time rename of a small number of files. > I assume that the "configure" procedure for MS-DOS is already > different Yes, see config.bat in the top-level directory. But that's not the issue here. > > The files in m4/ still matter because you need to unpack the tarball, > > and the utility that does that won't silently overwrite files due to > > file-name clashes. > > That's OK. People can ignore those diagnostics The result is not ignorable diagnostics, but a prompt for the user to provide an alternate name. Since the user does not generally know whether these files are needed by the build, she will not be able to deal with the prompt. > just as I assume they already ignore the diagnostics for the files > whose names start with ".". No, there are no diagnostics for these conversions, they are done silently. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 11:24 ` Eli Zaretskii @ 2011-01-25 11:32 ` Bastien ROUCARIES 2011-01-25 14:07 ` Eli Zaretskii 2011-01-25 18:07 ` Paul Eggert 1 sibling, 1 reply; 99+ messages in thread From: Bastien ROUCARIES @ 2011-01-25 11:32 UTC (permalink / raw) To: bug-gnulib, Eli Zaretskii; +Cc: Paul Eggert, monnier, emacs-devel Le mardi 25 janvier 2011 12:24:56, Eli Zaretskii a écrit : > > Date: Tue, 25 Jan 2011 00:48:12 -0800 > > From: Paul Eggert <eggert@cs.ucla.edu> > > CC: monnier@iro.umontreal.ca, bug-gnulib@gnu.org, emacs-devel@gnu.org > > > > instead of doing the stuff I mentioned before the tarball is > > created, we can add a shell script to be run after the tarball is > > extracted. For example, on MS-DOS the c++defs.h file is > > automatically renamed to cxxdefs.h by the extractor, so the script > > can uniformly substitute "cxxdefs.h" for "c++defs.h" in all the text > > files. Hopefully a similar idea works for all the other files with > > non-MS-DOS names. > > The magic coded into the extractor utility is limited. It indeed > handles file names with `+' in them, but does not handle arbitrary > file names with multiple dots as a human would. It uses some > convoluted algorithm to replace the extra dot with a `_' or a `-'; > sometimes it replaces the first dot, sometimes the second. The > results are often unpredictable or surprising, especially if, as it > often happens, the modified names also clash in the 8+3 namespace (see > below). As I have mentionned previously, does doslfn is an option ? Bastien ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 11:32 ` Bastien ROUCARIES @ 2011-01-25 14:07 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 14:07 UTC (permalink / raw) To: Bastien ROUCARIES; +Cc: emacs-devel > From: Bastien ROUCARIES <roucaries.bastien@gmail.com> > Date: Tue, 25 Jan 2011 12:32:41 +0100 > Cc: Paul Eggert <eggert@cs.ucla.edu>, > monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > As I have mentionned previously, does doslfn is an option ? Yeah, only 3 hours ago. Don't you think you are a bit impatient? The question wasn't exactly a trivial one. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 11:24 ` Eli Zaretskii 2011-01-25 11:32 ` Bastien ROUCARIES @ 2011-01-25 18:07 ` Paul Eggert 2011-01-25 19:02 ` Eli Zaretskii 1 sibling, 1 reply; 99+ messages in thread From: Paul Eggert @ 2011-01-25 18:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnulib, monnier, emacs-devel On 01/25/11 03:24, Eli Zaretskii wrote: > It uses some > convoluted algorithm to replace the extra dot with a `_' or a `-'; > sometimes it replaces the first dot, sometimes the second. The > results are often unpredictable or surprising, especially if, as it > often happens, the modified names also clash in the 8+3 namespace (see > below). The results may seem convoluted, but I doubt whether they are actually unpredictable. I suspect we can accommodate whatever programmatic scheme djtar defaults to. Or we can tell djtar to use our own scheme, as discussed below. >> That's OK. People can ignore those diagnostics > > The result is not ignorable diagnostics, but a prompt for the user to > provide an alternate name. Since the user does not generally know > whether these files are needed by the build, she will not be able to > deal with the prompt. We already provide instructions for people who want to build Emacs on MS-DOS platforms. Our instructions can be expanded slightly to tell them how to extract the files in the first place, and how to deal with such prompts. They can be asked to just type RETURN, for example. Or, if that's too much trouble, the MS-DOS build instructions could instead tell people to fetch a small file "emacs-25.chg", and then execute djtar -n emacs-25.chg emacs-25.tgz where emacs-25.chg is a list of desired file name conversions. That is not much trouble, and it also addresses the extraction name-change issues that have been raised so far. If we don't want to distribute this small file separately, we can bundle it as part of the Emacs tarball, and give instructions on how to extract it separately first. > So going this way means a much more complex and error-prone > arrangement than a one-time rename of a small number of files. It is a bit more complex and error-prone for MS-DOS, yes. But it has the advantage of compartmentalizing the MS-DOS restrictions into the MS-DOS build instructions, rather than having these restrictions spread to Emacs more generally, where they complicate software integration efforts there. There is a significant advantage to modularization and separation of concerns, one that outweighs minor increases in complexity for individual components. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 18:07 ` Paul Eggert @ 2011-01-25 19:02 ` Eli Zaretskii 2011-01-25 21:03 ` Stefan Monnier 2011-01-25 21:24 ` Paul Eggert 0 siblings, 2 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 19:02 UTC (permalink / raw) To: Paul Eggert; +Cc: cyd, bug-gnulib, monnier, emacs-devel > Date: Tue, 25 Jan 2011 10:07:45 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: monnier@iro.umontreal.ca, bug-gnulib@gnu.org, emacs-devel@gnu.org > > We already provide instructions for people who want to build Emacs > on MS-DOS platforms. Our instructions can be expanded slightly > to tell them how to extract the files in the first place, and how > to deal with such prompts. They can be asked to just type RETURN, > for example. To read the instructions, you need to unpack the archive first. > djtar -n emacs-25.chg emacs-25.tgz > ... > It is a bit more complex and error-prone for MS-DOS, yes. But > it has the advantage of compartmentalizing the MS-DOS restrictions > into the MS-DOS build instructions Sorry, but these complications are unacceptable for me. We use something like that in GDB, and the result is extremely fragile and error-prone, I find problems with missing renames every time I build GDB. I'm not going to make the same kind or mistake again in Emacs. Stefan and Chong, please make a decision regarding this issue. If the decision is not to rename these few files in the Emacs distribution, and instead ask me to cope with these complications, I will understand that the knee-jerk reaction of too many members of this community when they hear "MS-DOS" is more important that any voice of reason, and I will therefore resign from everything I do for Emacs development. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 19:02 ` Eli Zaretskii @ 2011-01-25 21:03 ` Stefan Monnier 2011-01-25 21:54 ` Eli Zaretskii 2011-01-26 0:32 ` Jason Rumney 2011-01-25 21:24 ` Paul Eggert 1 sibling, 2 replies; 99+ messages in thread From: Stefan Monnier @ 2011-01-25 21:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, Paul Eggert, bug-gnulib, emacs-devel >> djtar -n emacs-25.chg emacs-25.tgz >> ... >> It is a bit more complex and error-prone for MS-DOS, yes. But >> it has the advantage of compartmentalizing the MS-DOS restrictions >> into the MS-DOS build instructions > Sorry, but these complications are unacceptable for me. We use > something like that in GDB, and the result is extremely fragile and > error-prone, I find problems with missing renames every time I build > GDB. I'm not going to make the same kind or mistake again in Emacs. Here's a compromise: - let's do the renames that need to be done (they're really not problematic, AFAICT). - let's try and get this "djtar -n emacs-25.chg emacs-25.tgz" to work reliably, e.g. by auto-building the emacs-25.chg file as part of make-dist, so there's no way for that file to be "missing renames". Stefan ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 21:03 ` Stefan Monnier @ 2011-01-25 21:54 ` Eli Zaretskii 2011-01-25 22:15 ` Stefan Monnier 2011-01-26 0:32 ` Jason Rumney 1 sibling, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 21:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, eggert, bug-gnulib, emacs-devel > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: Paul Eggert <eggert@cs.ucla.edu>, cyd@stupidchicken.com, > bug-gnulib@gnu.org, emacs-devel@gnu.org > Date: Tue, 25 Jan 2011 16:03:16 -0500 > > - let's try and get this "djtar -n emacs-25.chg emacs-25.tgz" to work > reliably, e.g. by auto-building the emacs-25.chg file as part of > make-dist, so there's no way for that file to be "missing renames". Based on the experience from GDB, here are the problems with this approach: . The remapping of file names cannot be fully automated. Once all limits on file names are removed ("we don't want even the slightest impediment", says Jim), sooner or later you get to the point where the number of files to be renamed becomes large and a human needs to define how files will be renamed, because you want names that at least remotely resemble the original ones, but still don't clash in the 8+3 namespace. (I hope no one is seriously entertaining the idea of producing meaningless names like foo~123.c or ABC123EF.c, from some hash or whatever). . Once the remapping is maintained by humans, it becomes unreliable. . The unpacking instructions are part of the tarball, and need to be extracted separately before the "main" extraction begins. More importantly, the remapping file needs to be extracted before that as well. This makes the entire unpacking procedure extremely complicated and thus error-prone, except if the person who does that is the one who designed it and wrote the instructions in the first place. In addition, there will be a need to deal with something that the GDB distribution doesn't. In GDB, the files that are renamed during unpacking are only those that are not used for the DOS build. By contrast, here we want to rename files that are used during the build. So there will be a need to edit all the files that reference the renamed ones, before the build can begin. This can be done with Sed, but the DOS shell doesn't have any way of recursively descending through a directory tree. So, if we want to make this editing as part of config.bat, the subdirectories of the Emacs tree will have to be hard-coded in config.bat, which is yet another source of errors, when a subdirectory is added or removed. (The alternative, of using a port of GNU Find, would mean addition of another tool that is not required today for building Emacs.) Perhaps it's possible to solve all this in a satisfactory manner, but doing so would require a lot of work, much more than I am willing to invest. (I still want to finish development of bidirectional editing, remember?) Given the small (yes, small!) fraction of files that ever need to be renamed, the significant effort needed for getting this particular alternative right is not justified. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 21:54 ` Eli Zaretskii @ 2011-01-25 22:15 ` Stefan Monnier 2011-01-26 1:05 ` Paul Eggert 2011-01-26 4:02 ` Eli Zaretskii 0 siblings, 2 replies; 99+ messages in thread From: Stefan Monnier @ 2011-01-25 22:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, bug-gnulib, emacs-devel > Based on the experience from GDB, here are the problems with this > approach: > . The remapping of file names cannot be fully automated. Once all > limits on file names are removed ("we don't want even the > slightest impediment", says Jim), sooner or later you get to the > point where the number of files to be renamed becomes large and a > human needs to define how files will be renamed, because you want > names that at least remotely resemble the original ones, but still > don't clash in the 8+3 namespace. (I hope no one is seriously > entertaining the idea of producing meaningless names like > foo~123.c or ABC123EF.c, from some hash or whatever). Yes, I was assuming that there would still be few files, and that the renaming would be human-controlled (but the make-dist script signals an error if the human-provided rules don't cover all cases). So it wouldn't help for cases like CEDET. > . Once the remapping is maintained by humans, it becomes unreliable. Why is that? > . The unpacking instructions are part of the tarball, and need to be > extracted separately before the "main" extraction begins. More > importantly, the remapping file needs to be extracted before that > as well. This makes the entire unpacking procedure extremely > complicated and thus error-prone, except if the person who does > that is the one who designed it and wrote the instructions in the > first place. Rather than distribute a file that needs to be passed to djtar, I was thinking of distributing a script tailored to MS-DOS, run instead of djtar, and which would run djtar insternally. So this script can provide the instructions. > In addition, there will be a need to deal with something that the GDB > distribution doesn't. In GDB, the files that are renamed during > unpacking are only those that are not used for the DOS build. By > contrast, here we want to rename files that are used during the build. Yes, that's a much bigger problem. In the mean time, please rename the files, thank you, Stefan ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 22:15 ` Stefan Monnier @ 2011-01-26 1:05 ` Paul Eggert 2011-01-26 4:12 ` Eli Zaretskii 2011-01-26 4:02 ` Eli Zaretskii 1 sibling, 1 reply; 99+ messages in thread From: Paul Eggert @ 2011-01-26 1:05 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, bug-gnulib, cyd, emacs-devel On 01/25/11 14:15, Stefan Monnier wrote: > In the mean time, please rename the files, thank you, I'm afraid it's not as simple as merely renaming the files. One must also change the contents of all files referring to the renamed files, and change Makefile.in so that when fresh copies are imported from gnulib, the files' names and contents are consistently renamed. And in the end, one will end up with files that differ from gnulib, which will make it a bit harder to port patches from Emacs back to gnulib. I'd like to pursue the idea of renaming the files only on the MS-DOS platform. This approach shouldn't take that much work now, and it should save time in the future (including lessening the need to discuss 8+3 issues on this mailing list :-). ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 1:05 ` Paul Eggert @ 2011-01-26 4:12 ` Eli Zaretskii 2011-01-26 6:01 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 4:12 UTC (permalink / raw) To: Paul Eggert; +Cc: cyd, bug-gnulib, monnier, emacs-devel > Date: Tue, 25 Jan 2011 17:05:28 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, > bug-gnulib@gnu.org, emacs-devel@gnu.org > > I'm afraid it's not as simple as merely renaming the files. > One must also change the contents of all files referring to > the renamed files, and change Makefile.in so that when > fresh copies are imported from gnulib, the files' names > and contents are consistently renamed. These are all parts of the job that needs to be done under your suggestion as well--to rename and edit when Emacs is built on MSDOS. > I'd like to pursue the idea of renaming the files only > on the MS-DOS platform. This approach shouldn't take > that much work now, and it should save time in the future That approach as suggested (modeled on what GDB does) is unacceptable, sorry. I already said what it means for me personally if it will be accepted here. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 4:12 ` Eli Zaretskii @ 2011-01-26 6:01 ` Eli Zaretskii 2011-01-26 16:11 ` Stefan Monnier 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 6:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, bug-gnulib, monnier, emacs-devel > Date: Wed, 26 Jan 2011 06:12:55 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@IRO.UMontreal.CA, > emacs-devel@gnu.org > > > I'd like to pursue the idea of renaming the files only > > on the MS-DOS platform. This approach shouldn't take > > that much work now, and it should save time in the future > > That approach as suggested (modeled on what GDB does) is unacceptable, > sorry. Here's a compromise that at least I can live with; hope others can, too: 1) For c++defs.h and the lib/*.in.h files: rely on the automatic renaming by djtar. Files that reference those will be edited by config.bat as part of configuring Emacs for the MS-DOS build. 2) For the 3 m4/gnulib-*.m4 files: rename them. I suggested one way of renaming, but there's nothing sacred about that; any renaming that will get rid of the name clash is fine with me. As long as the list of files that get handled by 1) is relatively small and kept under control, this is manageable. This means no "open season" for disregarding the issue altogether, as in "we already have such problems elsewhere, why not add a few more". I hope that as long as the list of files that are handled by 2) is short (3 for now), that would be regarded as manageable and acceptable by gnulib people. [Make no mistake: supporting 1) is still a complication. There's more there than meets the eye. For example, when djtar runs on Windows, it doesn't perform any automatic renames, because it knows that long file names are available (DJGPP has built-in support for them in the Standard C library). So, to support the Emacs build on both plain DOS and Windows, config.bat will need to do slightly different things in each case, which means more scripting and more testing. But these complications are relatively minor, don't affect the end users, and I have good experience with solving such problems, in Emacs and elsewhere.] ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 6:01 ` Eli Zaretskii @ 2011-01-26 16:11 ` Stefan Monnier 0 siblings, 0 replies; 99+ messages in thread From: Stefan Monnier @ 2011-01-26 16:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, bug-gnulib, emacs-devel > Here's a compromise that at least I can live with; hope others can, too: > 1) For c++defs.h and the lib/*.in.h files: rely on the automatic > renaming by djtar. Files that reference those will be edited by > config.bat as part of configuring Emacs for the MS-DOS build. > 2) For the 3 m4/gnulib-*.m4 files: rename them. I suggested one way > of renaming, but there's nothing sacred about that; any renaming > that will get rid of the name clash is fine with me. Sounds good to me. Stefan ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 22:15 ` Stefan Monnier 2011-01-26 1:05 ` Paul Eggert @ 2011-01-26 4:02 ` Eli Zaretskii 1 sibling, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 4:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, eggert, bug-gnulib, emacs-devel > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: eggert@cs.ucla.edu, cyd@stupidchicken.com, bug-gnulib@gnu.org, > emacs-devel@gnu.org > Date: Tue, 25 Jan 2011 17:15:37 -0500 > > > . Once the remapping is maintained by humans, it becomes unreliable. > > Why is that? Because people err and don't always pay attention to all changes that affect this issue. > > . The unpacking instructions are part of the tarball, and need to be > > extracted separately before the "main" extraction begins. More > > importantly, the remapping file needs to be extracted before that > > as well. This makes the entire unpacking procedure extremely > > complicated and thus error-prone, except if the person who does > > that is the one who designed it and wrote the instructions in the > > first place. > > Rather than distribute a file that needs to be passed to djtar, I was > thinking of distributing a script tailored to MS-DOS, run instead of > djtar, and which would run djtar insternally. So this script can > provide the instructions. How will that script be distributed? > > In addition, there will be a need to deal with something that the GDB > > distribution doesn't. In GDB, the files that are renamed during > > unpacking are only those that are not used for the DOS build. By > > contrast, here we want to rename files that are used during the build. > > Yes, that's a much bigger problem. There's more to it. If the affected files are mentioned in some Lisp files, then those Lisp files will need to be recompiled after being edited. That means the Emacs build process on MSDOS will have to run Make in the lips/ subdirectory, which until now it didn't. lisp/Makefile requires a Unixy shell (and associated utilities, like Coreutils), which would be now another prerequisite for building Emacs. I'm sure we will discover more difficulties, because even GDB didn't rename files used in building on DOS. > In the mean time, please rename the files, thank you, Thank you. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 21:03 ` Stefan Monnier 2011-01-25 21:54 ` Eli Zaretskii @ 2011-01-26 0:32 ` Jason Rumney 2011-01-26 3:12 ` Stefan Monnier 1 sibling, 1 reply; 99+ messages in thread From: Jason Rumney @ 2011-01-26 0:32 UTC (permalink / raw) To: emacs-devel On 26/01/2011 05:03, Stefan Monnier wrote: > Here's a compromise: > - let's do the renames that need to be done (they're really not > problematic, AFAICT). > - let's try and get this "djtar -n emacs-25.chg emacs-25.tgz" to work > reliably, e.g. by auto-building the emacs-25.chg file as part of > make-dist, so there's no way for that file to be "missing renames". > It might also be a good idea to add an alternate-load-library-alist variable which require and load could consult when attempts to load a file fail. That would also be useful on other platforms for the CEDET rename and similar cases. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 0:32 ` Jason Rumney @ 2011-01-26 3:12 ` Stefan Monnier 0 siblings, 0 replies; 99+ messages in thread From: Stefan Monnier @ 2011-01-26 3:12 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel >> Here's a compromise: >> - let's do the renames that need to be done (they're really not >> problematic, AFAICT). >> - let's try and get this "djtar -n emacs-25.chg emacs-25.tgz" to work >> reliably, e.g. by auto-building the emacs-25.chg file as part of >> make-dist, so there's no way for that file to be "missing renames". > It might also be a good idea to add an alternate-load-library-alist variable > which require and load could consult when attempts to load a file fail. > That would also be useful on other platforms for the CEDET rename and > similar cases. Indeed. This could even be auto-filled by autoload.el if we add support in it for entries like: ;;;###autoload (provide 'foo) -- Stefan ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 19:02 ` Eli Zaretskii 2011-01-25 21:03 ` Stefan Monnier @ 2011-01-25 21:24 ` Paul Eggert 2011-01-25 22:06 ` Eli Zaretskii 1 sibling, 1 reply; 99+ messages in thread From: Paul Eggert @ 2011-01-25 21:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, bug-gnulib, monnier, emacs-devel On 01/25/11 11:02, Eli Zaretskii wrote: > To read the instructions, you need to unpack the archive first. That may have been true years ago, when the tarballs themselves were the main way that one could find out how to do maintenance. But that long ago stopped being true for Emacs. If I wanted to come up to speed on how to build Emacs for MS-DOS, the first thing I'd do would be a Google search, which would point me at places like <http://www.emacswiki.org/emacs-fr/EmacsForDOS> and <http://www.gnu.org/software/emacs/manual/html_node/emacs/MS_002dDOS.html>. If these places contain extraction instructions, that's good enough. >> djtar -n emacs-25.chg emacs-25.tgz > We use something like that in GDB, and the result is extremely > fragile and error-prone, Even if -n is currently error-prone in GDB, that does not mean that the approach is inherently error-prone, or that it must be error-prone in Emacs. For example, it should be pretty easy to check emacs-25.chg automatically; is that done with GDB? If not, and if checking is done by hand, I can understand why it might be error-prone; but an automated check should substantially reduce the number of errors. > If the decision is not to rename these few files in the Emacs > distribution, and instead ask me to cope with these complications, I > will understand that the knee-jerk reaction of too many members of > this community when they hear "MS-DOS" is more important that any > voice of reason I hope that you don't include me in members whose knees are jerking. Personally I would just rename the files in gnulib and be done with it, as none of the name changes seem to be onerous. However, we don't seem to have consensus for that now; I seem to be the only gnulib developer who would go that route. Also, the problem of non-8+3 file names does not seem to be limited to gnulib-derived files. All in all it sounds like automating the renaming on the MS-DOS side would be a reasonable thing to do. This is a bit of work but doesn't seem that hard. And if we get the automation working well with Emacs we could then apply similar ideas to GDB as well, and make GDB development less error-prone on MS-DOS. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 21:24 ` Paul Eggert @ 2011-01-25 22:06 ` Eli Zaretskii 2011-01-26 0:54 ` Paul Eggert 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-25 22:06 UTC (permalink / raw) To: Paul Eggert; +Cc: cyd, bug-gnulib, monnier, emacs-devel > Date: Tue, 25 Jan 2011 13:24:11 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > On 01/25/11 11:02, Eli Zaretskii wrote: > > > To read the instructions, you need to unpack the archive first. > > That may have been true years ago, when the tarballs themselves were > the main way that one could find out how to do maintenance. But that > long ago stopped being true for Emacs. If I wanted to come up to > speed on how to build Emacs for MS-DOS, the first thing I'd do would > be a Google search, which would point me at places like > <http://www.emacswiki.org/emacs-fr/EmacsForDOS> and > <http://www.gnu.org/software/emacs/manual/html_node/emacs/MS_002dDOS.html>. > If these places contain extraction instructions, that's good enough. And what about the emacs-25.chg file? Would you expect users to google for it as well, and copy-paste it into their shell window? I hope you will agree that it's a very bad idea. So the file will have to be extracted first, and you are back at the same problem as with the instructions again. > For example, it should be pretty easy to check emacs-25.chg > automatically; is that done with GDB? Yes, it is done. But it doesn't catch all the errors. More importantly, the remapping file is maintained manually. See my response to Stefan. > > If the decision is not to rename these few files in the Emacs > > distribution, and instead ask me to cope with these complications, I > > will understand that the knee-jerk reaction of too many members of > > this community when they hear "MS-DOS" is more important that any > > voice of reason > > I hope that you don't include me in members whose knees are jerking. I no longer know who is and who isn't. Oscar's was the only message that sounded like a glimpse of light in the darkness. > Personally I would just rename the files in gnulib and be done with > it, as none of the name changes seem to be onerous. However, we don't > seem to have consensus for that now; I seem to be the only gnulib > developer who would go that route. We are talking about renaming files in the Emacs repo. Why would gnulib developers have any say in that? > Also, the problem of non-8+3 file names does not seem to be limited > to gnulib-derived files. Yes, they are limited to gnulib-derived files. If you mean Org, I'm sure those files will be renamed. > All in all it sounds like automating the renaming on the MS-DOS side > would be a reasonable thing to do. Theoretically, yes. It sounded like that years ago, when it was introduced into GDB. I feel much better now, thank you. > This is a bit of work but doesn't seem that hard. And if we get the > automation working well with Emacs we could then apply similar ideas > to GDB as well, and make GDB development less error-prone on MS-DOS. Who is "we" here, I wonder. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-25 22:06 ` Eli Zaretskii @ 2011-01-26 0:54 ` Paul Eggert 2011-01-26 4:10 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Paul Eggert @ 2011-01-26 0:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, bug-gnulib, monnier, emacs-devel On 01/25/11 13:54, Eli Zaretskii wrote: > This makes the entire unpacking procedure extremely > complicated and thus error-prone I don't see why. With GDB it's two commands: djtar -x -p -o gdb-7.2/djunpack.bat gdb-7.2.tar.gz > djunpack.bat djunpack gdb-7.2.tar.gz Why would it be more complicated than that for Emacs? > . Once the remapping is maintained by humans, it becomes unreliable. No, not if it's checked. Surely the check can be automated reliably. > the subdirectories of the Emacs tree will have to be hard-coded in > config.bat, which is yet another source of errors, when a > subdirectory is added or removed. (The alternative, of using a port > of GNU Find, would mean addition of another tool that is not > required today for building Emacs.) That should not be a problem. 'find' is already required to build Emacs; for example, Makefile.in uses it. It is easy to run 'find' as part of the process that makes a distribution, and to put its output into config.bat or the equivalent, so there is no need to run 'find' under MS-DOS. > Perhaps it's possible to solve all this in a satisfactory manner, but > doing so would require a lot of work, I don't think it'd take much work to do the above. I can write scripts to do the check and to do the find, since they can all be done on a standard GNU platform. What else is needed? On 01/25/11 14:06, Eli Zaretskii wrote: > And what about the emacs-25.chg file? Would you expect users to > google for it as well, and copy-paste it into their shell window? No, I would expect users to extract it from the tarball much as is already done with GDB and djunpack.bat. That's simple, and it would work. >> For example, it should be pretty easy to check emacs-25.chg >> automatically; is that done with GDB? > > Yes, it is done. But it doesn't catch all the errors. How is that checking done, and what errors doesn't it catch? I don't see the checking in the GDB 7.2 distribution. > We are talking about renaming files in the Emacs repo. Why would > gnulib developers have any say in that? Because we automatically sync files from gnulib into Emacs. What I think you are suggesting, is that we rename gnulib files, and edit their contents, after copying them from gnulib into Emacs. But this will break the existing "make sync-from-gnulib", or require "make sync-from-gnulib" to be considerably more complicated. The renaming and copying is needed only on MS-DOS; it's not needed for any other platform. It makes sense to do it only on MS-DOS. This will simplify maintenance on non-MS-DOS platforms; for example, it will make it easier to propagate fixes from Emacs back to gnulib. >> Also, the problem of non-8+3 file names does not seem to be limited >> to gnulib-derived files. > > Yes, they are limited to gnulib-derived files. If you mean Org, I'm > sure those files will be renamed. I meant all the other files that have 8+3 issues. These are all problems, even if the solutions differ for different cases. > Who is "we" here, I wonder. I can write the above scripts for Emacs. The ideas can be propagated into GDB later, as needed. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 0:54 ` Paul Eggert @ 2011-01-26 4:10 ` Eli Zaretskii 2011-01-26 11:13 ` Jim Meyering ` (2 more replies) 0 siblings, 3 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 4:10 UTC (permalink / raw) To: Paul Eggert; +Cc: cyd, bug-gnulib, monnier, emacs-devel > Date: Tue, 25 Jan 2011 16:54:16 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > On 01/25/11 13:54, Eli Zaretskii wrote: > > > This makes the entire unpacking procedure extremely > > complicated and thus error-prone > > I don't see why. With GDB it's two commands: > > djtar -x -p -o gdb-7.2/djunpack.bat gdb-7.2.tar.gz > djunpack.bat > djunpack gdb-7.2.tar.gz > > Why would it be more complicated than that for Emacs? This is the complexity I want to avoid. Don't you think it's complicated enough? And how about the issue with using slashes in the argument to djunpack? does that kind of subtlety mean something to you? > > . Once the remapping is maintained by humans, it becomes unreliable. > > No, not if it's checked. Surely the check can be automated reliably. The reliability of this is determined by the scripts that do it. Scripts are written by people, who tend to err or miss something. > > the subdirectories of the Emacs tree will have to be hard-coded in > > config.bat, which is yet another source of errors, when a > > subdirectory is added or removed. (The alternative, of using a port > > of GNU Find, would mean addition of another tool that is not > > required today for building Emacs.) > > That should not be a problem. 'find' is already required to build > Emacs; for example, Makefile.in uses it. Only lisp/Makefile.in, which is not used when a release is built on DOS (all the files are already compiled). > It is easy to run 'find' as part of the process that makes a > distribution, and to put its output into config.bat or the > equivalent, so there is no need to run 'find' under MS-DOS. More complications. This means, for example, that to test an arbitrary revision of the development tree, I will need to run make-dist on Unix, create a tarball, copy it to a DOS machine, then build, find problems, go back to the Unix machine, etc. > > Perhaps it's possible to solve all this in a satisfactory manner, but > > doing so would require a lot of work, > > I don't think it'd take much work to do the above. I can write > scripts to do the check and to do the find, since they can all be done > on a standard GNU platform. What else is needed? Maintenance. > > And what about the emacs-25.chg file? Would you expect users to > > google for it as well, and copy-paste it into their shell window? > > No, I would expect users to extract it from the tarball much as > is already done with GDB and djunpack.bat. That's simple, and it > would work. How can instructions that need to be googled for be simple and reliable? > >> For example, it should be pretty easy to check emacs-25.chg > >> automatically; is that done with GDB? > > > > Yes, it is done. But it doesn't catch all the errors. > > How is that checking done, and what errors doesn't it catch? It's done by the ARI script. All I know about the errors is that some files still clash. > The renaming and copying is needed only on MS-DOS; it's not needed > for any other platform. It makes sense to do it only on MS-DOS. > This will simplify maintenance on non-MS-DOS platforms But the price will be unacceptable complications for MS-DOS. No, thanks, not unless we find a simpler way. > >> Also, the problem of non-8+3 file names does not seem to be limited > >> to gnulib-derived files. > > > > Yes, they are limited to gnulib-derived files. If you mean Org, I'm > > sure those files will be renamed. > > I meant all the other files that have 8+3 issues. Which ones? ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 4:10 ` Eli Zaretskii @ 2011-01-26 11:13 ` Jim Meyering 2011-01-26 13:09 ` Eli Zaretskii 2011-01-26 12:27 ` Andreas Schwab 2011-01-27 8:32 ` Paul Eggert 2 siblings, 1 reply; 99+ messages in thread From: Jim Meyering @ 2011-01-26 11:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, Paul Eggert, bug-gnulib, monnier, emacs-devel Eli Zaretskii wrote: >> From: Paul Eggert <eggert@cs.ucla.edu> ... >> It is easy to run 'find' as part of the process that makes a >> distribution, and to put its output into config.bat or the >> equivalent, so there is no need to run 'find' under MS-DOS. > > More complications. This means, for example, that to test an > arbitrary revision of the development tree, I will need to run > make-dist on Unix, create a tarball, copy it to a DOS machine, then > build, find problems, go back to the Unix machine, etc. Nah. You wouldn't have to test at all, because it could be automated. See below. >> > Perhaps it's possible to solve all this in a satisfactory manner, but >> > doing so would require a lot of work, >> >> I don't think it'd take much work to do the above. I can write >> scripts to do the check and to do the find, since they can all be done >> on a standard GNU platform. What else is needed? > > Maintenance. [assuming something like doslfn is too buggy -- have you tried it? ] We could write an 8.3 conflict-checking Makefile rule and add it as a dependent of "check". Then any new file that conflicts would be detected immediately, and whoever added it would deal with the failed "make check" by renaming their file or by adding a DOS-renaming rule. >> > And what about the emacs-25.chg file? Would you expect users to >> > google for it as well, and copy-paste it into their shell window? >> >> No, I would expect users to extract it from the tarball much as >> is already done with GDB and djunpack.bat. That's simple, and it >> would work. > > How can instructions that need to be googled for be simple and > reliable? > >> >> For example, it should be pretty easy to check emacs-25.chg >> >> automatically; is that done with GDB? >> > >> > Yes, it is done. But it doesn't catch all the errors. >> >> How is that checking done, and what errors doesn't it catch? > > It's done by the ARI script. I didn't find any script in GDB named ARI, but do see many references to ARI in ChangeLogs. > All I know about the errors is that some files still clash. All that means is that there's room for improvement. No need to reject that solution because it's not yet perfect. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 11:13 ` Jim Meyering @ 2011-01-26 13:09 ` Eli Zaretskii 2011-01-26 13:23 ` Jim Meyering 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:09 UTC (permalink / raw) To: Jim Meyering; +Cc: cyd, eggert, bug-gnulib, monnier, emacs-devel > From: Jim Meyering <jim@meyering.net> > Cc: Paul Eggert <eggert@cs.ucla.edu>, cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Wed, 26 Jan 2011 12:13:28 +0100 > > >> It is easy to run 'find' as part of the process that makes a > >> distribution, and to put its output into config.bat or the > >> equivalent, so there is no need to run 'find' under MS-DOS. > > > > More complications. This means, for example, that to test an > > arbitrary revision of the development tree, I will need to run > > make-dist on Unix, create a tarball, copy it to a DOS machine, then > > build, find problems, go back to the Unix machine, etc. > > Nah. You wouldn't have to test at all, > because it could be automated. See below. We are miscommunicating. Paul suggested that config.bat, the script used instead of the Posix `configure' when building the MS-DOS port, will have the list of files/directories to rename/edit hardcoded into it by make-dist. Which means that to update config.bat, I will need to run make-dist on a Unix host, then copy the results to the machine where I build the DOS port, and only then build it. Just testing doesn't solve the issue, because if testing detects a problem, the way to correct it is very complicated (compared to what I do today -- just edit and try again). > >> I don't think it'd take much work to do the above. I can write > >> scripts to do the check and to do the find, since they can all be done > >> on a standard GNU platform. What else is needed? > > > > Maintenance. > > [assuming something like doslfn is too buggy -- have you tried it? ] > > We could write an 8.3 conflict-checking Makefile rule and add > it as a dependent of "check". Then any new file that conflicts > would be detected immediately, and whoever added it would > deal with the failed "make check" by renaming their file or > by adding a DOS-renaming rule. "make check" is jut the part that detects problems. They also need to be fixed, and that's where most of the maintenance effort goes. And what about the need to remember to say "make check"? Emacs does not yet have a test suite that can be run as a single large test in batch mode, so "make check" is not a routine part of building it. > >> How is that checking done, and what errors doesn't it catch? > > > > It's done by the ARI script. > > I didn't find any script in GDB named ARI, but do see > many references to ARI in ChangeLogs. I think you will find it on the GDB Web site. If not, ask on the gdb-patches mailing list. I once asked for it and the core maintainers sent it to me. > > All I know about the errors is that some files still clash. > > All that means is that there's room for improvement. > No need to reject that solution because it's not yet perfect. Either you underestimate the complexity of the task, or you somehow believe that any complexity can be dealt with reliably. In both cases, I really have no practical way of convincing you (and Paul), because this is no longer about facts, it's about experience and gray hair. After so many years of bad experience, I concluded that this kind of solution will never work reliably, unless someone works full time on maintaining it. You are welcome to learn the same lesson the hard way, but I've learned mine. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:09 ` Eli Zaretskii @ 2011-01-26 13:23 ` Jim Meyering 2011-01-26 13:29 ` Lennart Borgman 2011-01-26 13:37 ` Eli Zaretskii 0 siblings, 2 replies; 99+ messages in thread From: Jim Meyering @ 2011-01-26 13:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, bug-gnulib, monnier, emacs-devel Eli Zaretskii wrote: >> From: Jim Meyering <jim@meyering.net> >> >> It is easy to run 'find' as part of the process that makes a >> >> distribution, and to put its output into config.bat or the >> >> equivalent, so there is no need to run 'find' under MS-DOS. >> > >> > More complications. This means, for example, that to test an >> > arbitrary revision of the development tree, I will need to run >> > make-dist on Unix, create a tarball, copy it to a DOS machine, then >> > build, find problems, go back to the Unix machine, etc. >> >> Nah. You wouldn't have to test at all, >> because it could be automated. See below. > > We are miscommunicating. Paul suggested that config.bat, the script > used instead of the Posix `configure' when building the MS-DOS port, > will have the list of files/directories to rename/edit hardcoded into > it by make-dist. Which means that to update config.bat, I will need There would be a rule (always run at least by "make dist") that would update config.bat. You could conceivably just run that rule, which would surely be very quick. You would not have to run the full "make dist". However, you might not have to do even that. You're presuming that people will be adding new files with conflicting name, but without updating the renaming rules required for DOS. That's where the automation comes in. If some rename-shim is required for DOS, then any build target (even "all") can require it, if it is deemed important enough. Then, if someone adds a conflicting file and does not also update the list of rename pairs, a regular "make" could fail with a diagnostic telling them what's required. That would make it the responsibility of each person adding a new conflicting file to tend to this small infrequent task, not you. > to run make-dist on a Unix host, then copy the results to the machine > where I build the DOS port, and only then build it. Just testing > doesn't solve the issue, because if testing detects a problem, the way > to correct it is very complicated (compared to what I do today -- just > edit and try again). ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:23 ` Jim Meyering @ 2011-01-26 13:29 ` Lennart Borgman 2011-01-26 13:33 ` Eli Zaretskii 2011-01-26 13:37 ` Eli Zaretskii 1 sibling, 1 reply; 99+ messages in thread From: Lennart Borgman @ 2011-01-26 13:29 UTC (permalink / raw) To: Jim Meyering; +Cc: eggert, bug-gnulib, cyd, emacs-devel, monnier, Eli Zaretskii On Wed, Jan 26, 2011 at 2:23 PM, Jim Meyering <jim@meyering.net> wrote: > > However, you might not have to do even that. At the moment it is not even possible to build on w32. Could we please fix this first? I do not know very much about the topic discussed here, but from my experience things often does not work as well as those who have not really tried assume. Maybe it would be could if those proposing a change actually tried it themselves - in the environment where they suggest it? ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:29 ` Lennart Borgman @ 2011-01-26 13:33 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:33 UTC (permalink / raw) To: Lennart Borgman; +Cc: eggert, bug-gnulib, cyd, jim, emacs-devel, monnier > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Wed, 26 Jan 2011 14:29:31 +0100 > Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, eggert@cs.ucla.edu, > bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > At the moment it is not even possible to build on w32. Could we please > fix this first? That's a separate issue. I will fix the w32 build when I have time; volunteers are welcome to beat me to it. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:23 ` Jim Meyering 2011-01-26 13:29 ` Lennart Borgman @ 2011-01-26 13:37 ` Eli Zaretskii 2011-01-26 13:50 ` Jim Meyering 1 sibling, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:37 UTC (permalink / raw) To: Jim Meyering; +Cc: cyd, eggert, bug-gnulib, monnier, emacs-devel > From: Jim Meyering <jim@meyering.net> > Cc: eggert@cs.ucla.edu, cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Wed, 26 Jan 2011 14:23:51 +0100 > > There would be a rule (always run at least by "make dist") that would > update config.bat. You could conceivably just run that rule, which > would surely be very quick. You would not have to run the full "make dist". You cannot run "make ANYTHING" before config.bat, because the latter edits Makefile.in files into Makefile files. > You're presuming that people will be adding new files with conflicting > name, but without updating the renaming rules required for DOS. > That's where the automation comes in. You cannot maintain the DB or renaming automatically, unless you are willing to settle for meaningless file names. > That would make it the responsibility of each person adding a new > conflicting file to tend to this small infrequent task, not you. People don't care about this now (and I cannot and don't blame them). Why would they care more under this new scheme? ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:37 ` Eli Zaretskii @ 2011-01-26 13:50 ` Jim Meyering 0 siblings, 0 replies; 99+ messages in thread From: Jim Meyering @ 2011-01-26 13:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, bug-gnulib, monnier, emacs-devel Eli Zaretskii wrote: >> From: Jim Meyering <jim@meyering.net> >> Cc: eggert@cs.ucla.edu, cyd@stupidchicken.com, bug-gnulib@gnu.org, >> monnier@iro.umontreal.ca, emacs-devel@gnu.org >> Date: Wed, 26 Jan 2011 14:23:51 +0100 >> >> There would be a rule (always run at least by "make dist") that would >> update config.bat. You could conceivably just run that rule, which >> would surely be very quick. You would not have to run the full "make dist". > > You cannot run "make ANYTHING" before config.bat, because the latter > edits Makefile.in files into Makefile files. You would run it on a gnu/linux system. >> You're presuming that people will be adding new files with conflicting >> name, but without updating the renaming rules required for DOS. >> That's where the automation comes in. > > You cannot maintain the DB or renaming automatically, unless you are > willing to settle for meaningless file names. Adding rename pairs would have to be done manually, and as I said, infrequently, typically by the person who has added the offending name into the repository. >> That would make it the responsibility of each person adding a new >> conflicting file to tend to this small infrequent task, not you. > > People don't care about this now (and I cannot and don't blame them). > Why would they care more under this new scheme? If the build rules (and policy) make it their concern, and it is well enough documented, they will do it. We're talking about only a few minutes of added work, here, and then only infrequently. How often do people add new files to emacs? Of those, how many fail the 8.3 uniqueness test? Very few. No big deal. If this is the price people must pay to be rid of the 8.3 name restrictions, few will complain. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 4:10 ` Eli Zaretskii 2011-01-26 11:13 ` Jim Meyering @ 2011-01-26 12:27 ` Andreas Schwab 2011-01-26 13:17 ` Eli Zaretskii 2011-01-27 8:32 ` Paul Eggert 2 siblings, 1 reply; 99+ messages in thread From: Andreas Schwab @ 2011-01-26 12:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, Paul Eggert, bug-gnulib, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > More complications. This means, for example, that to test an > arbitrary revision of the development tree, I will need to run > make-dist on Unix, create a tarball, copy it to a DOS machine, then > build, find problems, go back to the Unix machine, etc. There is also DOSBox which should obviate the need to use a separate DOS machine. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 12:27 ` Andreas Schwab @ 2011-01-26 13:17 ` Eli Zaretskii 2011-01-26 13:24 ` Andreas Schwab 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:17 UTC (permalink / raw) To: Andreas Schwab; +Cc: cyd, eggert, bug-gnulib, monnier, emacs-devel > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: Paul Eggert <eggert@cs.ucla.edu>, cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Wed, 26 Jan 2011 13:27:09 +0100 > > There is also DOSBox which should obviate the need to use a separate DOS > machine. Not if you develop software that needs to run on bare metal. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:17 ` Eli Zaretskii @ 2011-01-26 13:24 ` Andreas Schwab 2011-01-26 13:41 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Andreas Schwab @ 2011-01-26 13:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, eggert, bug-gnulib, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Andreas Schwab <schwab@linux-m68k.org> >> Cc: Paul Eggert <eggert@cs.ucla.edu>, cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org >> Date: Wed, 26 Jan 2011 13:27:09 +0100 >> >> There is also DOSBox which should obviate the need to use a separate DOS >> machine. > > Not if you develop software that needs to run on bare metal. Since when does Emacs run on bare metal? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 13:24 ` Andreas Schwab @ 2011-01-26 13:41 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-26 13:41 UTC (permalink / raw) To: Andreas Schwab; +Cc: cyd, eggert, bug-gnulib, monnier, emacs-devel > From: Andreas Schwab <schwab@linux-m68k.org> > Date: Wed, 26 Jan 2011 14:24:03 +0100 > Cc: cyd@stupidchicken.com, eggert@cs.ucla.edu, bug-gnulib@gnu.org, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > > Since when does Emacs run on bare metal? On plain DOS? since 1994. Anyway, the DJGPP project supports all environments that include a reasonable implementation of the DOS system calls. Asking that one of the most important packages in the DJGPP suite will only run on 1 or two select environments, not even on the original DOS, is ridiculous. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-26 4:10 ` Eli Zaretskii 2011-01-26 11:13 ` Jim Meyering 2011-01-26 12:27 ` Andreas Schwab @ 2011-01-27 8:32 ` Paul Eggert 2011-01-27 11:08 ` Eli Zaretskii 2 siblings, 1 reply; 99+ messages in thread From: Paul Eggert @ 2011-01-27 8:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, bug-gnulib, monnier, emacs-devel On 01/25/2011 08:10 PM, Eli Zaretskii wrote: > It's done by the ARI script. All I know about the errors is that some > files still clash. I looked into that, and the ARI script itself <http://sourceware.org/gdb/current/ari/gdb_ari.sh> doesn't know anything about 8+3 file names, so some other program must be doing it. My guess is that they're using GNU doschk <http://www.gnu.org/software/doschk/> and filtering the output. If I run "make dist" on the Emacs trunk, and then ask GNU doschk to report all 8+3 file name clashes in the resulting distribution, it reports the following: ORG-COMP.EL : ./lisp/org/org-compat.el ./lisp/org/org-complete.el ORG-COMP.ELC : ./lisp/org/org-compat.elc ./lisp/org/org-complete.elc SEMANTIC.EL : ./test/cedet/semantic-ia-utest.el ./test/cedet/semantic-tests.el ./test/cedet/semantic-utest-c.el ./test/cedet/semantic-utest.el TESTSPPR.C : ./test/cedet/tests/testsppreplace.c ./test/cedet/tests/testsppreplaced.c Do you see any errors in this report? If so, we should fix GNU doschk. If not, that suggests that doschk is good enough for us to use with Emacs, as part of a maintainer-mode check for problems in this area. >> From: Paul Eggert <eggert@cs.ucla.edu> >> With GDB it's two commands: >> >> djtar -x -p -o gdb-7.2/djunpack.bat gdb-7.2.tar.gz > djunpack.bat >> djunpack gdb-7.2.tar.gz >> >> Why would it be more complicated than that for Emacs? > > This is the complexity I want to avoid. Don't you think it's > complicated enough? Having MS-DOS builders type two commands to extract, rather than one, is not complicated. It would be a tiny price to pay, compared to the hassles for all developers who have to shoehorn file names into the 8+3 straitjacket. People who build for MS-DOS can be expected to understand minor workarounds like this. > And how about the issue with using slashes in the > argument to djunpack? What issue is that? In the above instructions, djunpack's argument does not contain any slashes. > Scripts are written by people, who tend to err or miss something. Sure, but a reasonable script will greatly lower the error rate to something that is manageable. That's all that one can ask of any build system. >> 'find' is already required to build Emacs; for example, Makefile.in >> uses it. > > Only lisp/Makefile.in, which is not used when a release is built on > DOS (all the files are already compiled). No, 'find' is used in other places too; for example it is used the top level Makefile.in, and in leim/Makefile.in. But my point, which I think you're agreeing with, is that it's OK to use 'find' in maintainer 'make' rules, since maintainers are expected to have hosts with a decent toolset. > This means, for example, that to test an > arbitrary revision of the development tree, I will need to run > make-dist on Unix, create a tarball, copy it to a DOS machine, then > build, find problems, go back to the Unix machine, etc. That's OK. It's normal, even on Unix-like hosts to do that. I do it all the time. I've caught multiple bugs recently in Emacs by doing that. The goal is not to make _maintenance_ practical on MS-DOS; that would be far too ambitious. The goal is only to make _building_ practical on MS-DOS. >> What else is needed? > > Maintenance. No matter what solution we adopt, some maintenance will be required. However, if we can automate most of it, we will lessen the overall maintenance burden. > How can instructions that need to be googled for be simple and > reliable? Instructions don't *need* to be Googled for. One can visit the Emacs web page, and navigate to the installation instructions, which will be one of the web pages that I mentioned. However, it is quite common to use Google nowadays, more common than traditional navigation, and there's nothing wrong with that. >>>> Also, the problem of non-8+3 file names does not seem to be limited >>>> to gnulib-derived files. >>> >>> Yes, they are limited to gnulib-derived files. If you mean Org, I'm >>> sure those files will be renamed. >> >> I meant all the other files that have 8+3 issues. > > Which ones? CEDET as well (see the above). This is a continuing issue, with files coming from multiple sources, and the problem is likely to keep cropping up. We need a better solution than what we've got now. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-27 8:32 ` Paul Eggert @ 2011-01-27 11:08 ` Eli Zaretskii 2011-01-28 7:30 ` Paul Eggert 0 siblings, 1 reply; 99+ messages in thread From: Eli Zaretskii @ 2011-01-27 11:08 UTC (permalink / raw) To: Paul Eggert; +Cc: cyd, monnier, emacs-devel Note: I removed gnulib from the list of addressees, as this is no longer a gnulib issue. > Date: Thu, 27 Jan 2011 00:32:03 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: cyd@stupidchicken.com, bug-gnulib@gnu.org, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > On 01/25/2011 08:10 PM, Eli Zaretskii wrote: > > > It's done by the ARI script. All I know about the errors is that some > > files still clash. > > I looked into that, and the ARI script itself > <http://sourceware.org/gdb/current/ari/gdb_ari.sh> doesn't know > anything about 8+3 file names, so some other program must be doing it. > My guess is that they're using GNU doschk > <http://www.gnu.org/software/doschk/> and filtering the output. AFAIR, ARI calls doschk, or maybe there was some wrapper script that did that. But doschk is definitely used for this. > If I run "make dist" on the Emacs trunk, and then ask GNU doschk > to report all 8+3 file name clashes in the resulting distribution, it > reports the following: > > ORG-COMP.EL : ./lisp/org/org-compat.el > ./lisp/org/org-complete.el > ORG-COMP.ELC : ./lisp/org/org-compat.elc > ./lisp/org/org-complete.elc I emailed the Org mode maintainers yesterday (off-list), and they agreed to rename org-complete.el to org-pcomplete.el (which is a more correct name anyway, IMO). The Emacs trunk will get that change when it is sync'ed with Org next time. > SEMANTIC.EL : ./test/cedet/semantic-ia-utest.el > ./test/cedet/semantic-tests.el > ./test/cedet/semantic-utest-c.el > ./test/cedet/semantic-utest.el > TESTSPPR.C : ./test/cedet/tests/testsppreplace.c > ./test/cedet/tests/testsppreplaced.c These clashes are not important, because the test suite should not be part of the release tarball. (I know that currently it is, but Stefan said that this is a bug that should be fixed.) > Do you see any errors in this report? If so, we should fix GNU > doschk. If not, that suggests that doschk is good enough for us > to use with Emacs, as part of a maintainer-mode check for problems > in this area. doschk is definitely good enough. I do run doschk from time to time, and it seemed to be frequently enough. The issue is only important when a release is close. In any case, the problem is not with having a Make target (the command is trivial), but to arrange for someone or something to run it and report the results. Frankly, I never pushed that issue because people tend to get annoyed by 8+3, so having something automatic that would print messages about that didn't seem like a good idea... > >> djtar -x -p -o gdb-7.2/djunpack.bat gdb-7.2.tar.gz > djunpack.bat > >> djunpack gdb-7.2.tar.gz > >> > >> Why would it be more complicated than that for Emacs? > > > > This is the complexity I want to avoid. Don't you think it's > > complicated enough? > > Having MS-DOS builders type two commands to extract, rather than one, > is not complicated. I'm not talking about the number of commands, I'm talking about the complexity of the first one and the potential to make mistakes in it. Few DJGPP users even know about the -p and -o switches to djtar. (djtar is generally used with only -x.) If you use the command-line arguments in a different order, chances are the command will not work as intended. I myself need to consult the README when I unpack the GDB tarball, for fear of mistakes (which did happen), and I wrote that stuff! > > And how about the issue with using slashes in the > > argument to djunpack? > > What issue is that? In the above instructions, djunpack's argument > does not contain any slashes. The argument could include slashes if the tarball is in a different directory. See the comments near the beginning of djunpack.bat. > >> 'find' is already required to build Emacs; for example, Makefile.in > >> uses it. > > > > Only lisp/Makefile.in, which is not used when a release is built on > > DOS (all the files are already compiled). > > No, 'find' is used in other places too; for example it is used > the top level Makefile.in Not relevant, as the DOS build doesn't use the top-level Makefile.in. See config.bat and msdos/mainmake.v2. > and in leim/Makefile.in Not relevant, since this use in the `install' target which isn't run on DOS (because "make install" in mainmake.v2 installs the binary in-place, under the source tree, and thus doesn't recurse into leim/). > But my point, > which I think you're agreeing with, is that it's OK to use 'find' > in maintainer 'make' rules, since maintainers are expected to have hosts > with a decent toolset. Yes, I agree. However, those comments of mine were to your suggestion to rename the files as part of running config.bat, which is run at configure time on the end-user machines. If you now have something else in mind, those comments are probably not pertinent anymore. > > This means, for example, that to test an > > arbitrary revision of the development tree, I will need to run > > make-dist on Unix, create a tarball, copy it to a DOS machine, then > > build, find problems, go back to the Unix machine, etc. > > That's OK. It's normal, even on Unix-like hosts to do that. > I do it all the time. You don't realize how little time I have to work on Emacs in general and on the MS-DOS port in particular. Each such complication steals precious time that I don't have. The Unix machine I use is fencepost, so copying files involves moving them through the Internet. Which means I cannot do this offline (yes, connectivity problems do happen in my corner of the world) or when fencepost is down, and also slows down things quite a lot even if the connection is in good shape. > > How can instructions that need to be googled for be simple and > > reliable? > > Instructions don't *need* to be Googled for. One can visit the Emacs > web page, and navigate to the installation instructions, which will be > one of the web pages that I mentioned. So now I'm supposed to lobby Emacs maintainers to have MS-DOS build instructions on the Web site? We've just heard several people ask when it will be possible to drop the MS-DOS support entirely; how would they react, you think, if I made such a request? I generally tend to avoid unnecessary friction wrt the MS-DOS port; I'm sure you will understand after the experience of this thread. msdos/INSTALL is all I need, thank you. It lies low and out of sight, and doesn't bother anyone. > However, it is quite common to use Google nowadays, more common than > traditional navigation, and there's nothing wrong with that. If you are looking for precise and correct instructions, googling is your enemy, because it brings hits that cannot be guaranteed to be correct. Someone said something a year ago, and it's there forever, even if in the meantime things happened that made it false. Look, it's pointless to try to push further the possibility that Emacs will adopt the same way of unpacking as GDB. I invented that stuff in the first place, but after all these years my experience with it is so bad that I will never agree to have it in Emacs. If the issue of file-name clashes becomes so unbearable for the Emacs developers that they will request that all limitations on file names are unconditionally lifted, it will be easier for me to declare that the MS-DOS port is dead, as soon as the conflicts hit the point where it cannot be handled by simple tricks. > >> I meant all the other files that have 8+3 issues. > > > > Which ones? > > CEDET as well (see the above). Not an issue (see above). > This is a continuing issue, with files coming from multiple sources, > and the problem is likely to keep cropping up. We need a better > solution than what we've got now. Experience shows that these issues crop up very rarely, although the nervous reactions and the futile prolonged debates make it sound like a grave problem. I'm willing to consider any reasonable solutions to that nonetheless, just not this one, because unlike any others, this one is tested in practice, and it failed that test. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-27 11:08 ` Eli Zaretskii @ 2011-01-28 7:30 ` Paul Eggert 2011-01-28 14:20 ` Eli Zaretskii 0 siblings, 1 reply; 99+ messages in thread From: Paul Eggert @ 2011-01-28 7:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, monnier, emacs-devel `On 01/27/2011 03:08 AM, Eli Zaretskii wrote: > I do run doschk from time to time, and it seemed to be frequently > enough. The issue is only important when a release is close. If file renaming code needs to be checked only when a release is close, that's fine. We can run the checks then. > In any case, the problem is not with having a Make target (the command > is trivial), but to arrange for someone or something to run it and > report the results. This can be done when a release is close. It's better if it's automated. >> Having MS-DOS builders type two commands to extract, rather than one, >> is not complicated. > > I'm not talking about the number of commands, I'm talking about the > complexity of the first one and the potential to make mistakes in it. Cutting and pasting two lines is pretty reliable. Anyone who wants to build Emacs for MS-DOS already should be referring to the instructions, to learn other things. For example, they need to know that they should use djtar and not some other extractor. These instructions, which are needed anyway, can tell them to cut and paste two lines. There is no fundamental problem with this approach. > The argument could include slashes if the tarball is in a different > directory. If people cute and paste two lines, as suggested, this won't be a problem, because the two lines won't include slashes in the wrong spot. > So now I'm supposed to lobby Emacs maintainers to have MS-DOS build > instructions on the Web site? That's easy. All we have to do is to put the two lines into the Emacs manual (enough to extract the files), and then point people at the extracted readme file. That will not be a problem. > You don't realize how little time I have to work on Emacs in general > and on the MS-DOS port in particular. Everybody who contributes to Emacs has limited time. We are trying to lessen the total amount of developer time being consumed by this problem. It's possible that this may require spending a bit more of your time, so that we collectively save time. Even so, this can be a tradeoff that is well worth making. > If the issue of file-name clashes becomes so unbearable for the > Emacs developers that they will request that all limitations on file > names are unconditionally lifted, it will be easier for me to > declare that the MS-DOS port is dead, as soon as the conflicts hit > the point where it cannot be handled by simple tricks. If that is the best alternative available, then we should do that. However, it doesn't sound that hard to do something that is similar to what GDB does, but is considerably more reliable because it is checked systematically. > Look, it's pointless to try to push further the possibility that Emacs > will adopt the same way of unpacking as GDB. I am not suggesting that. I'm suggesting something better. ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-28 7:30 ` Paul Eggert @ 2011-01-28 14:20 ` Eli Zaretskii 0 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-28 14:20 UTC (permalink / raw) To: Paul Eggert; +Cc: cyd, monnier, emacs-devel > Date: Thu, 27 Jan 2011 23:30:12 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > Cc: cyd@stupidchicken.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > Look, it's pointless to try to push further the possibility that Emacs > > will adopt the same way of unpacking as GDB. > > I am not suggesting that. I'm suggesting something better. Then perhaps I don't understand your suggestion. Could you describe it in its entirety, starting with how file-name clashes would be detected, how their alternative names would be determined, and how all this would work with make-dist and configuring and building the MS-DOS port? ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-24 3:26 ` Stefan Monnier 2011-01-24 4:01 ` Eli Zaretskii @ 2011-01-24 7:57 ` Glenn Morris 2011-01-24 16:37 ` Stefan Monnier 1 sibling, 1 reply; 99+ messages in thread From: Glenn Morris @ 2011-01-24 7:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, Paul Eggert, emacs-devel Stefan Monnier wrote: > Here, again, the `test' subdir is not included in the tarball, so it's > not an issue. Except of course, now it is included: http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00445.html ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-24 7:57 ` Glenn Morris @ 2011-01-24 16:37 ` Stefan Monnier 0 siblings, 0 replies; 99+ messages in thread From: Stefan Monnier @ 2011-01-24 16:37 UTC (permalink / raw) To: Glenn Morris; +Cc: Eli Zaretskii, Paul Eggert, emacs-devel >> Here, again, the `test' subdir is not included in the tarball, so it's >> not an issue. > Except of course, now it is included: > http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00445.html But it's an error, so it's not really relevant. Stefan ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: Files from gnulib 2011-01-23 19:29 ` Paul Eggert 2011-01-23 22:16 ` Bruno Haible 2011-01-24 3:26 ` Stefan Monnier @ 2011-01-24 4:07 ` Eli Zaretskii 2 siblings, 0 replies; 99+ messages in thread From: Eli Zaretskii @ 2011-01-24 4:07 UTC (permalink / raw) To: Paul Eggert; +Cc: bug-gnulib, emacs-devel > Date: Sun, 23 Jan 2011 11:29:37 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: emacs-devel@gnu.org, bug-gnulib <bug-gnulib@gnu.org> > > Developers on Microsoft Windows platforms all have access to > better file systems these days, surely. I'm talking only about the MSDOS port. The Windows port has no problems with these file names. It must be possible to build the MSDOS port on plain DOS, because Emacs is one of a couple of GNU programs (another one is Make) that are built first, because without them you have no usable development environment. That is why Emacs on MSDOS is built using a minimal set of tools, although DJGPP has an excellent port of Bash, which could be used to run the configure script. > So, other than c++defs.h, I don't see the need for renaming these > files. Given the responses from Stefan and myself, please reconsider. Again, I'm willing to do the job myself if needed, if you could guide me through the gnulib maze. TIA ^ permalink raw reply [flat|nested] 99+ messages in thread
end of thread, other threads:[~2012-08-23 16:23 UTC | newest] Thread overview: 99+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-25 8:20 RE : Re: Files from gnulib Bastien ROUCARIES 2011-01-25 14:05 ` Eli Zaretskii 2011-01-25 14:51 ` Jim Meyering 2011-01-25 15:33 ` Eli Zaretskii 2011-01-25 16:32 ` Jim Meyering 2011-01-25 18:48 ` Eli Zaretskii 2011-01-26 0:45 ` Miles Bader 2011-01-26 6:08 ` Eli Zaretskii 2011-01-26 6:41 ` Miles Bader 2011-01-26 2:42 ` Leo 2011-01-26 4:14 ` Eli Zaretskii 2011-01-26 10:52 ` Jim Meyering 2011-01-26 12:42 ` Eli Zaretskii 2011-01-26 13:09 ` Jim Meyering 2011-01-26 13:29 ` Eli Zaretskii 2011-01-25 16:50 ` Ulrich Mueller 2011-01-25 18:50 ` Eli Zaretskii 2011-01-25 19:31 ` Ulrich Mueller 2011-01-25 19:38 ` Eli Zaretskii 2011-01-25 20:00 ` Ulrich Mueller 2011-01-25 20:09 ` Eli Zaretskii 2011-01-25 19:52 ` Óscar Fuentes 2011-01-25 20:19 ` Eli Zaretskii 2011-01-25 19:04 ` Stefan Monnier 2011-01-25 19:36 ` Eli Zaretskii 2011-01-25 22:37 ` Bastien ROUCARIES 2011-01-26 3:49 ` Eli Zaretskii 2011-01-26 11:02 ` Jim Meyering 2011-01-26 11:52 ` Bastien ROUCARIES 2011-01-26 11:58 ` Bastien ROUCARIES 2011-01-26 13:12 ` Eli Zaretskii 2011-01-26 12:52 ` Eli Zaretskii 2011-01-26 13:33 ` Bastien ROUCARIES 2011-01-26 13:48 ` Eli Zaretskii 2011-01-26 15:26 ` Bastien ROUCARIES 2011-01-26 15:46 ` Eli Zaretskii 2011-01-26 15:57 ` Bastien ROUCARIES 2011-01-26 18:56 ` Eli Zaretskii 2011-01-26 14:35 ` Andy Moreton 2011-01-26 15:31 ` Bastien ROUCARIES 2011-01-26 18:28 ` Miles Bader 2011-01-26 18:59 ` Eli Zaretskii 2011-01-27 10:54 ` Simon Josefsson 2011-01-28 2:27 ` Paul Eggert 2012-08-23 11:36 ` Bastien ROUCARIES 2012-08-23 16:23 ` Eli Zaretskii 2011-01-25 16:03 ` RE : " Leo 2011-01-25 17:16 ` Miles Bader 2011-01-26 2:33 ` Stephen J. Turnbull 2011-01-26 7:18 ` Dan Nicolaescu 2011-01-26 16:15 ` Stefan Monnier 2011-01-27 3:08 ` Dan Nicolaescu 2011-01-25 18:05 ` Eli Zaretskii -- strict thread matches above, loose matches on Subject: below -- 2011-01-23 12:15 Eli Zaretskii 2011-01-23 12:40 ` Eli Zaretskii 2011-01-23 19:29 ` Paul Eggert 2011-01-23 22:16 ` Bruno Haible 2011-01-24 3:26 ` Stefan Monnier 2011-01-24 4:01 ` Eli Zaretskii 2011-01-24 23:26 ` Paul Eggert 2011-01-25 4:00 ` Eli Zaretskii 2011-01-25 8:48 ` Paul Eggert 2011-01-25 11:24 ` Eli Zaretskii 2011-01-25 11:32 ` Bastien ROUCARIES 2011-01-25 14:07 ` Eli Zaretskii 2011-01-25 18:07 ` Paul Eggert 2011-01-25 19:02 ` Eli Zaretskii 2011-01-25 21:03 ` Stefan Monnier 2011-01-25 21:54 ` Eli Zaretskii 2011-01-25 22:15 ` Stefan Monnier 2011-01-26 1:05 ` Paul Eggert 2011-01-26 4:12 ` Eli Zaretskii 2011-01-26 6:01 ` Eli Zaretskii 2011-01-26 16:11 ` Stefan Monnier 2011-01-26 4:02 ` Eli Zaretskii 2011-01-26 0:32 ` Jason Rumney 2011-01-26 3:12 ` Stefan Monnier 2011-01-25 21:24 ` Paul Eggert 2011-01-25 22:06 ` Eli Zaretskii 2011-01-26 0:54 ` Paul Eggert 2011-01-26 4:10 ` Eli Zaretskii 2011-01-26 11:13 ` Jim Meyering 2011-01-26 13:09 ` Eli Zaretskii 2011-01-26 13:23 ` Jim Meyering 2011-01-26 13:29 ` Lennart Borgman 2011-01-26 13:33 ` Eli Zaretskii 2011-01-26 13:37 ` Eli Zaretskii 2011-01-26 13:50 ` Jim Meyering 2011-01-26 12:27 ` Andreas Schwab 2011-01-26 13:17 ` Eli Zaretskii 2011-01-26 13:24 ` Andreas Schwab 2011-01-26 13:41 ` Eli Zaretskii 2011-01-27 8:32 ` Paul Eggert 2011-01-27 11:08 ` Eli Zaretskii 2011-01-28 7:30 ` Paul Eggert 2011-01-28 14:20 ` Eli Zaretskii 2011-01-24 7:57 ` Glenn Morris 2011-01-24 16:37 ` Stefan Monnier 2011-01-24 4:07 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.