On 01/26/2011 09:33 AM, Bruno Haible wrote:
> I agree with Eli that a bit of hand-written renaming in the script
> is feasible and maintainable.
A bit is, yes. However, we should strive to put the burden of
renaming-for-DOS into the DOS-related source files, and so this bit
shouldn't be preceden
> Date: Wed, 26 Jan 2011 16:39:43 -0800
> From: Paul Eggert
> CC: Eric Blake , Eli Zaretskii ,
> bug-gnulib ,
> c...@stupidchicken.com, emacs-de...@gnu.org, monn...@iro.umontreal.ca,
> Bruno Haible
>
> The *.in.h problem is more serious, though, as it limits
> include file names to 7 letter
Stefan Monnier 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
[trimming down the CCs, as this is no longer related to emacs]
Paul Eggert wrote:
> Currently we build
> lib/c++defs.h from build-aux/c++defs.h as part of ordinary
> 'make'. But lib/c++defs.h is the same on all platforms.
> It would save work for ordinary 'make' if we distributed
> lib/c++defs.h,
On 01/26/11 08:36, Jim Meyering wrote:
> Renaming files like those to avoid the 8.3 collisions does not seem
> like the right move, especially since we (at least I) have no idea of
> the size of the user base we would be accommodating.
I agree that wholesale renaming is not a realistic option.
It
Eli Zaretskii wrote:
>> From: Jim Meyering
>> Cc: ebl...@redhat.com, egg...@cs.ucla.edu, bug-gnulib@gnu.org,
>> c...@stupidchicken.com, emacs-de...@gnu.org,
>> monn...@iro.umontreal.ca, br...@clisp.org
>> Date: Wed, 26 Jan 2011 19:59:18 +0100
>>
>> Requiring doslfn solely for those *building* emac
> From: Bruno Haible
> Date: Wed, 26 Jan 2011 20:01:30 +0100
> Cc: ebl...@redhat.com,
> c...@stupidchicken.com,
> egg...@cs.ucla.edu,
> bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca,
> emacs-de...@gnu.org
>
> > > 1. runs "gnulib-tool"
> > > 2. looks at list of lib/*.in.h files,
> > >
> From: Jim Meyering
> Cc: ebl...@redhat.com, egg...@cs.ucla.edu, bug-gnulib@gnu.org,
> c...@stupidchicken.com, emacs-de...@gnu.org, monn...@iro.umontreal.ca,
> br...@clisp.org
> Date: Wed, 26 Jan 2011 19:59:18 +0100
>
> Requiring doslfn solely for those *building* emacs on DOS would
> al
Hi Eli,
> > 1) About c++defs.h:
> >
> > I have proposed in [2] a modification to the Emacs sources that will ensure
> > that
> > - No c++defs.h is contained in the build.
> > - A gnulib-local/modules/c++defs.diff file is contained in the tarball but
> > not used in the build. According to
On 01/26/2011 11:40 AM, Eli Zaretskii wrote:
>> I have proposed in [2] a modification to the Emacs sources that will ensure
>> that
>> - No c++defs.h is contained in the build.
>> - A gnulib-local/modules/c++defs.orig file is contained in the tarball but
>> not used in the build. According
Eli Zaretskii wrote:
>> From: Jim Meyering
>> Cc: Eli Zaretskii , Paul Eggert ,
>> bug-gnulib , c...@stupidchicken.com,
>> emacs-de...@gnu.org, monn...@iro.umontreal.ca, Bruno Haible
>>
>> Date: Wed, 26 Jan 2011 17:36:42 +0100
>>
>> Here are some of the reasons to try hard to avoid 8.3 constraint
> From: Bastien ROUCARIES
> Date: Wed, 26 Jan 2011 16:31:04 +0100
> Cc: Andy Moreton , emacs-de...@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
> From: Bastien ROUCARIES
> Date: Wed, 26 Jan 2011 16:57:10 +0100
> Cc: j...@meyering.net,
> emacs-de...@gnu.org,
> egg...@cs.ucla.edu,
> bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca
>
> why not supply a doslfn module (fixed) in djgpp ?
Because DJGPP has seen its last release 8.5 years ag
> From: Jim Meyering
> Cc: Eli Zaretskii , Paul Eggert ,
> bug-gnulib , c...@stupidchicken.com,
> emacs-de...@gnu.org, monn...@iro.umontreal.ca, Bruno Haible
>
> Date: Wed, 26 Jan 2011 17:36:42 +0100
>
> Here are some of the reasons to try hard to avoid 8.3 constraints
> altogether. Th
> From: Bruno Haible
> Date: Wed, 26 Jan 2011 18:33:20 +0100
> Cc: c...@stupidchicken.com,
> egg...@cs.ucla.edu,
> bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca,
> emacs-de...@gnu.org
>
> Remember that Eli said that the entire discussion is about renaming files
> in the Emacs repository, not
Bastien ROUCARIES 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
Hi Eric, Eli,
Remember that Eli said that the entire discussion is about renaming files
in the Emacs repository, not in gnulib [1]. I also pointed out that MSDOS
support is outside of gnulib's scope [2].
On this background, for me the goal is not to do any renamings in gnulib,
but rather to help
Eric Blake wrote:
> [intentionally breaking threading and retitling this, to try and make it
> easier to see replies to just this aspect of the thread]
>
> [well, my first attempt at breaking threading failed; apologies for the
> duplicate, but here's a resend with identical contents to make good o
> 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 surpri
On 01/26/2011 08:58 AM, Eli Zaretskii wrote:
>> Paul already suggested renaming c++defs.h to cxxdefs.h in gnulib, which
>> makes sense to me in light of POSIX restrictions on portable filenames;
>> however, this module belongs to Bruno, so it is his call.
>
> And Bruno already voiced his objections
> 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
> From: Bastien ROUCARIES
> Date: Wed, 26 Jan 2011 16:26:05 +0100
> Cc: j...@meyering.net,
> emacs-de...@gnu.org,
> egg...@cs.ucla.edu,
> bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca
>
> And do not talk about bare metal. DPMI is not bare metal dos*.
Yes, it is, because DJGPP includes a DPM
> Date: Wed, 26 Jan 2011 08:19:13 -0700
> From: Eric Blake
> CC: c...@stupidchicken.com, egg...@cs.ucla.edu, bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca, emacs-de...@gnu.org,
> Bruno Haible
>
> > 1) For c++defs.h and the lib/*.in.h files: rely on the automatic
> > renamin
Le mercredi 26 janvier 2011 16:46:29, Eli Zaretskii a écrit :
> > From: Bastien ROUCARIES
> > Date: Wed, 26 Jan 2011 16:26:05 +0100
> > Cc: j...@meyering.net,
> >
> > emacs-de...@gnu.org,
> > egg...@cs.ucla.edu,
> > bug-gnulib@gnu.org,
> > monn...@iro.umontreal.ca
> >
> > And do not talk abo
[intentionally breaking threading and retitling this, to try and make it
easier to see replies to just this aspect of the thread]
[well, my first attempt at breaking threading failed; apologies for the
duplicate, but here's a resend with identical contents to make good on
the promise of a new thre
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-o
* m4/fcntl.m4 (gl_FUNC_FCNTL): Also catch Haiku errno bug.
* lib/fcntl.c (rpl_fcntl) [F_DUPFD]: Work around Haiku losing
cloexec bit on duplication.
* doc/posix-functions/fcntl.texi (fcntl): Document the bug.
Signed-off-by: Eric Blake
---
This fixes the fcntl side of things; I'm still working on
> Date: Mon, 24 Jan 2011 15:48:30 -0800
> From: Paul Eggert
> CC: emacs-de...@gnu.org, bug-gnulib@gnu.org
>
> You do need to worry about HAVE_DECL_*, yes. Some
> of these symbols has been in config.in for quite
> some time, but gnulib added some more.
>
> I also suggest looking at HAVE_ATTRIBUT
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
[intentionally breaking threading and retitling this, to try and make it
easier to see replies to just this aspect of the thread]
On 01/25/2011 11:01 PM, Eli Zaretskii wrote:
> 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 file
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 fig
I just tried to build on w32 (with the tools I used before) and got
the error below. Is that expected at the moment?
gcc -I. -c -gdwarf-2 -g3 -DEMACSDEBUG -Ic:/g/include
-fno-crossjumping -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_N
TGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=500 -o oo/i386/print.o
Miles Bader writes:
> Leo 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 evidence
On Wed, Jan 26, 2011 at 2:23 PM, Jim Meyering 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 a
> From: Andreas Schwab
> Date: Wed, 26 Jan 2011 14:24:03 +0100
> Cc: c...@stupidchicken.com, egg...@cs.ucla.edu, bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca, emacs-de...@gnu.org
>
> Since when does Emacs run on bare metal?
On plain DOS? since 1994.
Anyway, the DJGPP project supports al
> From: Bastien ROUCARIES
> Date: Wed, 26 Jan 2011 14:33:54 +0100
> Cc: Jim Meyering ,
> emacs-de...@gnu.org,
> egg...@cs.ucla.edu,
> bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca
>
> according to http://www.delorie.com/djgpp/doc/kb/kb_10.html
> "The DJGPP library features transparent and au
Eli Zaretskii wrote:
>> From: Jim Meyering
>> Cc: egg...@cs.ucla.edu, c...@stupidchicken.com, bug-gnulib@gnu.org,
>> monn...@iro.umontreal.ca, emacs-de...@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.b
Lennart Borgman wrote:
> I just tried to build on w32 (with the tools I used before) and got
> the error below. Is that expected at the moment?
>
> gcc -I. -c -gdwarf-2 -g3 -DEMACSDEBUG -Ic:/g/include
> -fno-crossjumping -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_N
> TGUI=1 -DUSE_CRT_DLL=1 -DP
On Wed 26 Jan 2011, Lennart Borgman wrote:
> I just tried to build on w32 (with the tools I used before) and got
> the error below. Is that expected at the moment?
>
> gcc -I. -c -gdwarf-2 -g3 -DEMACSDEBUG -Ic:/g/include
> -fno-crossjumping -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_N
> TGUI=
> From: Jim Meyering
> Cc: egg...@cs.ucla.edu, c...@stupidchicken.com, bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca, emacs-de...@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 conceiv
> > 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-u
> From: Lennart Borgman
> Date: Wed, 26 Jan 2011 14:29:31 +0100
> Cc: Eli Zaretskii , c...@stupidchicken.com, egg...@cs.ucla.edu,
> bug-gnulib@gnu.org, monn...@iro.umontreal.ca, emacs-de...@gnu.org
>
> At the moment it is not even possible to build on w32. Could we please
> fix this first?
> From: Jim Meyering
> Cc: sdl@gmail.com, roucaries.bast...@gmail.com, egg...@cs.ucla.edu,
> bug-gnulib@gnu.org, monn...@iro.umontreal.ca, emacs-de...@gnu.org
> Date: Wed, 26 Jan 2011 14:09:39 +0100
>
> Taking well-intended technical suggestions as a personal attack
It cannot be anythi
Eli Zaretskii writes:
>> From: Andreas Schwab
>> Cc: Paul Eggert , c...@stupidchicken.com,
>> bug-gnulib@gnu.org, monn...@iro.umontreal.ca, emacs-de...@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
Eli Zaretskii wrote:
>> From: Jim Meyering
>> >> 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, t
> From: Lennart Borgman
> Date: Wed, 26 Jan 2011 13:35:41 +0100
> Cc: Eli Zaretskii , c...@stupidchicken.com, jan@swipnet.se,
> bug-gnulib@gnu.org, j...@meyering.net, emacs-de...@gnu.org
>
> I just tried to build on w32 (with the tools I used before) and got
> the error below. Is that
> From: Andreas Schwab
> Cc: Paul Eggert , c...@stupidchicken.com,
> bug-gnulib@gnu.org, monn...@iro.umontreal.ca, emacs-de...@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
> From: Bastien ROUCARIES
> Date: Wed, 26 Jan 2011 12:52:33 +0100
> Cc: Eli Zaretskii ,
> emacs-de...@gnu.org,
> egg...@cs.ucla.edu,
> bug-gnulib@gnu.org,
> monn...@iro.umontreal.ca
>
> Moreover freedos seems to use routinly doslfn. So it is a least a
> little bit tested.
FreeDOS has known i
> From: Jim Meyering
> Cc: Paul Eggert , c...@stupidchicken.com,
> bug-gnulib@gnu.org, monn...@iro.umontreal.ca, emacs-de...@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 confi
Eli Zaretskii wrote:
>> From: Jim Meyering
...
>> Eli Zaretskii wrote:
>> >> From: Leo
>> ...
>> >> 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.
>> Pr
> From: Jim Meyering
> Cc: Bastien ROUCARIES , emacs-de...@gnu.org,
> egg...@cs.ucla.edu, bug-gnulib@gnu.org, monn...@iro.umontreal.ca
> Date: Wed, 26 Jan 2011 12:02:47 +0100
>
> Eli Zaretskii wrote:
> >> From: Bastien ROUCARIES
> >> Date: Tue, 25 Jan 2011 23:37:08 +0100
> >>
> >> (if and o
On 2011-01-18 I wrote:
> When I reintroduce the memory leak fixed on 2009-12-15, the output on
> MacOS X and Cygwin thus changes from
>
> Skipping test: getrlimit and setrlimit don't work
> SKIP: test-dprintf-posix2.sh
> Skipping test: getrlimit and setrlimit don't work
> SKIP: test-fprint
> From: Jim Meyering
> Cc: Leo , roucaries.bast...@gmail.com,
> egg...@cs.ucla.edu, bug-gnulib@gnu.org, monn...@iro.umontreal.ca,
> emacs-de...@gnu.org
> Date: Wed, 26 Jan 2011 11:52:12 +0100
>
> Eli Zaretskii wrote:
> >> From: Leo
> ...
> >> Please don't take that personally.
> >
> > Eve
Eli Zaretskii 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 DOS
setrlimit of RLIMIT_DATA limits the size of the data segment, but POSIX
does not define an accessor function for the size of the data segment.
I'm adding the module 'get-rusage-data' which defines such an accessor.
I need it so that the unit tests against memory leaks will also work
on AIX (note t
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
> > >> Date: Tue, 25 Jan 2011 23:37:08 +0100
> > >>
> > >> (if and only if doslfn is buggy, and it does not seem
Eli Zaretskii wrote:
>> From: Paul Eggert
...
>> 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
Le mercredi 26 janvier 2011 12:02:47, Jim Meyering a écrit :
> Eli Zaretskii wrote:
> >> From: Bastien ROUCARIES
> >> 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.
>
>
Eli Zaretskii wrote:
>> From: Leo
...
>> 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 pe
Eli Zaretskii wrote:
>> From: Bastien ROUCARIES
>> 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
60 matches
Mail list logo
