gcc2.95, sizes and optimizations

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I think this topic was already discussed but I’ve tested a little
the development environment of qnx rtos :slight_smile:, these are only
considerations.

The first thing: the gcc2.95.2 is a relatively “old” compiler and has
many known bugs. It has MANY optimization problems and many problems
with c++. It would be nice in the next rtos release to have at leat
the 2.95.3 or the 2.96 from redhat, since gcc3 is unusable at the
moment.

Some c++ problems are now fixed using the more compliant and very
nice dinkum c++ library, but the gcc produce however huge
executables (when using some stl templates, like strings and vectors
the code becomes ten times bigger).

Even using the -g for debugging the executables become 100 times
bigger then a normal c executable (!)

Using c++ for producing small executables is effectively a problem.

Also, when using OPTIMIZE_TYPE=something in the makefiles, switching
from SIZE to TIME will not change anything (the optimization flag
passed to the compiler seems to be always -O). When setting
OPTIMIZE_TYPE to NONE, instead, the size of the executable becomes
smaller than ever, and it’s the ONLY way to debug the code (why this?
on linux I can set -O3 -g and debug any c++ code without a problem,
in neutrino it’s pratically impossible, I get unknown lines and so on).

It’s planned to do something to fix these issues in the next release
of qnx rtos?

2

dolly@cloned.net wrote:
: I think this topic was already discussed but I’ve tested a little
: the development environment of qnx rtos :slight_smile:, these are only
: considerations.

: The first thing: the gcc2.95.2 is a relatively “old” compiler and has
: many known bugs. It has MANY optimization problems and many problems
: with c++. It would be nice in the next rtos release to have at leat
: the 2.95.3 or the 2.96 from redhat, since gcc3 is unusable at the
: moment.

I think, I’ve posted about this already. Search the gcc mailing list
to see the real reason behind 2.95.3, 2.95.4(I do not think it was ever
release) and 2.96, those addresses different issues.
The 2.9x branch is a dead end no need to go this path(unless your are
a GNU/Linux distribution, since 3.0.x could not compile the linux kernel
for some reason).
The effort should be rather focus on 3.0.x series. gcc 3.0.1 is out.


: Some c++ problems are now fixed using the more compliant and very
: nice dinkum c++ library, but the gcc produce however huge
: executables (when using some stl templates, like strings and vectors
: the code becomes ten times bigger).

: Even using the -g for debugging the executables become 100 times
: bigger then a normal c executable (!)

: Using c++ for producing small executables is effectively a problem.

Noted. This is gcc specifics or you’ve notice some pecularities
on Neutrino also?

: Also, when using OPTIMIZE_TYPE=something in the makefiles, switching
: from SIZE to TIME will not change anything (the optimization flag
: passed to the compiler seems to be always -O). When setting
: OPTIMIZE_TYPE to NONE, instead, the size of the executable becomes
: smaller than ever, and it’s the ONLY way to debug the code (why this?
: on linux I can set -O3 -g and debug any c++ code without a problem,
: in neutrino it’s pratically impossible, I get unknown lines and so on).

Maybe because on some/many GNU/Linux the default is stabs. Try to compile
with -gstabs it may however double/triple the size of the executable.
-O3 -g is counterproductive :sunglasses: But I see what you meant.

: It’s planned to do something to fix these issues in the next release
: of qnx rtos?

The tools group is waving the options, can not speak for them.

3

Alain Magloire <alain@qnx.com> wrote:

I think, I’ve posted about this already. Search the gcc mailing list
to see the real reason behind 2.95.3, 2.95.4(I do not think it was ever
release) and 2.96, those addresses different issues.
The 2.9x branch is a dead end no need to go this path(unless your are
a GNU/Linux distribution, since 3.0.x could not compile the linux kernel
for some reason).
The effort should be rather focus on 3.0.x series. gcc 3.0.1 is out.

gcc3 would be a nice choice, but compilation times are longer than
the 2.9x series (that’s another problems on gcc under neutrino,
compilation times for c++ code are actually 5-6 times slower than
linux. this is probably due to the dinkum library).

Noted. This is gcc specifics or you’ve notice some pecularities
on Neutrino also?

The size problem seems to be gcc-dinkum related (also gcc produces
large executables, but not THAT large in normal circumstances).
Usually under linux and solaris (using 2.95.3 and stlport) an
executable can become 10% bigger than a c one, but under neutrino the
“expansion” is near 30-50%. I think that’s also a gcc fault. The name
mangling and simbol tables that the gcc produces for c++ code are
ugly in the 2.95 series (millions of simbols for a single program).

Maybe because on some/many GNU/Linux the default is stabs. Try to compile
with -gstabs it may however double/triple the size of the executable.
-O3 -g is counterproductive > :sunglasses: > But I see what you meant.

This doen’t solve the problem when using gcc. Since when using -O the
code it’s effectively different can beheave in different ways. Some
code will fail to run without -O3 in some circumstances (STLPort have
experienced many problem with this).
debugging the final code using the optimization flags it’s safer (at
least using gcc).

However the OPTIMIZE_TYPE thing it’s probably a bug. SIZE and TIME
uses the same flags and produces the same huge code (using NONE
procuces smaller executables).

It would be nice to check if those things persist when using a
different c++ compiler

4

<dolly@cloned.net> writes:

Alain Magloire <> alain@qnx.com> > wrote:
gcc3 would be a nice choice, but compilation times are longer than
the 2.9x series (that’s another problems on gcc under neutrino,
compilation times for c++ code are actually 5-6 times slower than
linux. this is probably due to the dinkum library).

If it’s any consolation, GCC compile times for C code are much slower
in QNX6 as well. I haven’t run exact benchmarks, but it looks like
about a factor of two.

Cheers,
Andrew

Andrew Thomas, President, Cogent Real-Time Systems Inc.
2430 Meadowpine Boulevard, Suite 105, Mississauga, Ontario, Canada L5N 6S2
Email: andrew@cogent.ca WWW: http://www.cogent.ca

5

Andrew Thomas <andrew@cogent.ca> wrote:

dolly@cloned.net> > writes:

Alain Magloire <> alain@qnx.com> > wrote:
If it’s any consolation, GCC compile times for C code are much slower
in QNX6 as well. I haven’t run exact benchmarks, but it looks like
about a factor of two.

I’ve just a little bench comparing linux times and neutrino times
when compiling a c++ application using gcc2.95.2.
Linux resides on a 233mmx intel computer, neutrino on an athlon
1200mhz, but linux still FASTER the neutrino!! (this is really
ridicoulous). Both uses gcc2.95.2

Here time linux times:
$ time --portability make
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o sockets.o sockets.cpp
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o functions.o
functions.cpp
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o tproxy.o tproxy.cpp
g++ -o tproxy sockets.o functions.o tproxy.o
real 8.56
user 8.11
sys 0.44

Neutrino:
$ time make
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o sockets.o sockets.cpp
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o functions.o
functions.cpp
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o tproxy.o tproxy.cpp
g++ -o tproxy sockets.o functions.o tproxy.o -lsocket
23.97s real 21.96s user 0.06s system

tproxy is a very simple c++ proxy application. It compiles flawlessy
under many operating systems without touching nothing so the
effective compiled code is always the same!

Prease read the times: 8secs under linux, 24 secs under neutrino.
Remember that linux runs on a 233mmx, neutrino under an athlon1200.
Nothing running on both oss but make.

This make me think.
If we were using gcc3, probably we can lauch make, go sleeping and
maybe we’ll get the executable :slight_smile: (or get an out-of-memory error :wink:)

6

My two cents,

QNX6 is meant to be a development platform no? That there
is no email program is fine with me, no decent browser
that’s fine with me too. No paint program, I can deal with
that as well. No program to write CD-R(RW) I can manage.

But if the compiler (or it’s implementation) sucks I’m really,
really concerned!

<wavexx@broadcast.anarchy.net> wrote in message
news:9m7hng$sd7$1@inn.qnx.com…

Andrew Thomas <> andrew@cogent.ca> > wrote:
dolly@cloned.net> > writes:

Alain Magloire <> alain@qnx.com> > wrote:
If it’s any consolation, GCC compile times for C code are much slower
in QNX6 as well. I haven’t run exact benchmarks, but it looks like
about a factor of two.

I’ve just a little bench comparing linux times and neutrino times
when compiling a c++ application using gcc2.95.2.
Linux resides on a 233mmx intel computer, neutrino on an athlon
1200mhz, but linux still FASTER the neutrino!! (this is really
ridicoulous). Both uses gcc2.95.2

Here time linux times:
$ time --portability make
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o sockets.o sockets.cpp
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o functions.o
functions.cpp
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o tproxy.o tproxy.cpp
g++ -o tproxy sockets.o functions.o tproxy.o
real 8.56
user 8.11
sys 0.44

Neutrino:
$ time make
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o sockets.o sockets.cpp
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o functions.o
functions.cpp
g++ -Wall -O2 -fstrict-aliasing -O3 -I. -c -o tproxy.o tproxy.cpp
g++ -o tproxy sockets.o functions.o tproxy.o -lsocket
23.97s real 21.96s user 0.06s system

tproxy is a very simple c++ proxy application. It compiles flawlessy
under many operating systems without touching nothing so the
effective compiled code is always the same!

Prease read the times: 8secs under linux, 24 secs under neutrino.
Remember that linux runs on a 233mmx, neutrino under an athlon1200.
Nothing running on both oss but make.

This make me think.
If we were using gcc3, probably we can lauch make, go sleeping and
maybe we’ll get the executable > :slight_smile: > (or get an out-of-memory error > :wink:> )

7

Mario Charest <mcharest@remzinformatic.com> wrote:

My two cents,

QNX6 is meant to be a development platform no? That there
is no email program is fine with me, no decent browser
that’s fine with me too. No paint program, I can deal with
that as well. No program to write CD-R(RW) I can manage.

But if the compiler (or it’s implementation) sucks I’m really,

I think the future for qnx rtos will be embedded systems, and
critical systems. desktop users will always look for games and these
“cool” things. Personally I feel great with rtos. great api, great
design. For now I don’t look at the desktop part. Insted the whole
developent section MUST BE FUNCTIONAL. The documentation is great,
the help system work well (maybe more examples and code snippets…)

But gcc is very ugly. The dinkum c++ library is underused with
gcc. Cameau c99/c++ would be a great compiler. A great ansi/iso
compliant compiler with a great c/c++ ansi/iso comliant library.
I’m also disposed to pay for it if necessary

Prease read the times: 8secs under linux, 24 secs under neutrino.
Remember that linux runs on a 233mmx, neutrino under an athlon1200.
Nothing running on both oss but make.
(Under pure speed terms, the athlon should be 26times faster than

the 233mmx, so what? gcc under neutrino is 78 times slower?)

I’ve forgived the sizes of the executables:

Under neutrino:
(normal:)
-rwxr-xr-x 1 wavexx users 132122 Aug 25 08:38 tproxy
(stripped:)
-rwxr-xr-x 1 wavexx users 117396 Aug 26 09:20 tproxy

Under linux:
(normal:)
-rwxrwxr-x 1 wavexx wavexx 48141 Aug 25 08:48 tproxy
(stripped:)
-rwxrwxr-x 1 wavexx wavexx 32256 Aug 26 09:28 tproxy

This is real al problem where the size DOES matter.

8

Mario Charest <mcharest@remzinformatic.com> wrote:

: My two cents,

: QNX6 is meant to be a development platform no?

You mean RTP.

: That there is no email program is fine with me,

Working on it, it takes time to get it right. Eudora or Outlook
was not written in a day. An seriously this is not our main focus.

: no decent browser that’s fine with me too.

Do not like Mozilla ? :sunglasses:

: No paint program, I can deal with that as well.

Me too :sunglasses:

: No program to write CD-R(RW) I can manage.

Annoying, agreed.

: But if the compiler (or it’s implementation) sucks I’m really,
: really concerned!

hmm … I would not call GCC (GNU compiler Collection) that, it is a very
capable compiler, yes there are issues, but not as alarming as this thread
make it sound.

One recurring issue, is the compile time, by gcc on Neutrino, not that
gcc generate utterly bad code. It may be the intensive I/O going
through the package file system etc …

g++ has always been notorious for it’s voracity in term of compile time
and memory, somehow this seems to double(triple according to some).

I will have to agree, it is indeed, something that the tools group should look at.

P.S.: one thing that seems to make a difference is “-nopipe” it seems that
our pipe() is … heuu … a little slow :sunglasses:.

9

“Alain Magloire” <alain@qnx.com> wrote in message
news:9memi6$oub$1@nntp.qnx.com…

Mario Charest <> mcharest@remzinformatic.com> > wrote:

: My two cents,

: QNX6 is meant to be a development platform no?

You mean RTP.

Yes sorry I meant RTP.

: That there is no email program is fine with me,

Working on it, it takes time to get it right. Eudora or Outlook
was not written in a day.
An seriously this is not our main focus.

Agreed, I wasn’t complaining :wink:

: no decent browser that’s fine with me too.

Do not like Mozilla ? > :sunglasses:

: No paint program, I can deal with that as well.

Me too > :sunglasses:

: No program to write CD-R(RW) I can manage.

Annoying, agreed.

: But if the compiler (or it’s implementation) sucks I’m really,
: really concerned!

hmm … I would not call GCC (GNU compiler Collection) that, it is a very
capable compiler, yes there are issues, but not as alarming as this
thread
make it sound.

Well not alarming like in jump off the boat, but alarming in like
will the ride be as smooth as the captain says its suppose to be,
and will my vacation be really a vacation.

A compiler/linker that generates executable 2-3 times
bigger then i`s LINUX counterpart for a system targeted
at embedded and small foot print I find concerning.
Alain you did talk about “main focus”. I was under the
impression executable size was under the “main focus”
section :wink:


One recurring issue, is the compile time, by gcc on Neutrino, not that
gcc generate utterly bad code. It may be the intensive I/O going
through the package file system etc …

Although frustrating again I can deal with that. But executable
size are harder to swallow.


g++ has always been notorious for it’s voracity in term of compile time
and memory, somehow this seems to double(triple according to some).

I will have to agree, it is indeed, something that the tools group should
look at.


P.S.: one thing that seems to make a difference is “-nopipe” it seems
that
our pipe() is … heuu … a little slow > :sunglasses:> .

:wink:

10

A compiler/linker that generates executable 2-3 times
bigger then i`s LINUX counterpart for a system targeted
at embedded and small foot print I find concerning.
Alain you did talk about “main focus”. I was under the
impression executable size was under the “main focus”
section > :wink:

It’s not the compiler Mario, it’s the library. The Dinkum C++ lib doesn’t
seem to play nicely with gcc wrt compile time and size. We’re currently
looking at the Dinkum Abridged C++ lib, which is a much leaner version, and
it is showing promising results so far.

We will be making packages soon that will allow you to select between the
full Dinkum C++, the Abridged Dinkum C++, and the GNU C++ for development.

\

cburgess@qnx.com

11

“Mario Charest” <mcharest@remzinformatic.com> wrote in message
news:9meqke$9g4$1@inn.qnx.com…

“Alain Magloire” <> alain@qnx.com> > wrote in message
news:9memi6$oub$> 1@nntp.qnx.com> …
Mario Charest <> mcharest@remzinformatic.com> > wrote:

: But if the compiler (or it’s implementation) sucks I’m really,
: really concerned!

hmm … I would not call GCC (GNU compiler Collection) that, it is a very
capable compiler, yes there are issues, but not as alarming as this
thread
make it sound.


Well not alarming like in jump off the boat, but alarming in like
will the ride be as smooth as the captain says its suppose to be,
and will my vacation be really a vacation.

A compiler/linker that generates executable 2-3 times
bigger then i`s LINUX counterpart for a system targeted
at embedded and small foot print I find concerning.
Alain you did talk about “main focus”. I was under the
impression executable size was under the “main focus”
section > :wink:


One recurring issue, is the compile time, by gcc on Neutrino, not
that
gcc generate utterly bad code. It may be the intensive I/O going
through the package file system etc …


Although frustrating again I can deal with that. But executable
size are harder to swallow.

I do think that QSSL needs to seriously rethink the compiler issue. I’ll
admit, I am spoiled by Watcom. But I am using QNX because I want to be
spoiled!

I love Neutrino the OS. But I have to admit, developing under RTP I feel
like I am SPOILED! (obviously a dufferent definition of the word).

12

Previously, Bill Caroselli (Q-TPS) wrote in qdn.public.qnxrtp.os:

I do think that QSSL needs to seriously rethink the compiler issue. I’ll
admit, I am spoiled by Watcom. But I am using QNX because I want to be
spoiled!

I do want to be spoiled. Watcom was fantastic. Especially the debugger.



I love Neutrino the OS. But I have to admit, developing under RTP I feel
like I am SPOILED! (obviously a dufferent definition of the word).

Core OS great. But the Linux obsession is a nightmare. Especially administration; why can’t it be simple, as in QNX4 ?


13

“Ian Cannon” <ianc@tecom.com.au> wrote in message
news:Voyager.010903085757.26711B@aresnode2.tecom.com.au…

Previously, Bill Caroselli (Q-TPS) wrote in qdn.public.qnxrtp.os:


I do think that QSSL needs to seriously rethink the compiler issue.
I’ll
admit, I am spoiled by Watcom. But I am using QNX because I want to be
spoiled!

I do want to be spoiled. Watcom was fantastic. Especially the debugger.

OK. Touche’!

I love Neutrino the OS. But I have to admit, developing under RTP I
feel
like I am SPOILED! (obviously a dufferent definition of the word).

Core OS great. But the Linux obsession is a nightmare. Especially
administration; why can’t it be simple, as in QNX4 ?

Boy, I’m glad someone besides me finally put that one into words. I hate
Linux almost as much as i hate Microsoft. And yes, Neutrino has done some
things VERY, VERY right! But QNX4 is much easier to use.

14

“Bill Caroselli (Q-TPS)” <qtps@earthlink.net> wrote in message
news:9n5jf9$9ep$1@inn.qnx.com…

“Ian Cannon” <> ianc@tecom.com.au> > wrote in message
news:> Voyager.010903085757.26711B@aresnode2.tecom.com.au> …
Previously, Bill Caroselli (Q-TPS) wrote in qdn.public.qnxrtp.os:


I do think that QSSL needs to seriously rethink the compiler issue.
I’ll
admit, I am spoiled by Watcom. But I am using QNX because I want to
be
spoiled!

I do want to be spoiled. Watcom was fantastic. Especially the debugger.

OK. Touche’!


I love Neutrino the OS. But I have to admit, developing under RTP I
feel
like I am SPOILED! (obviously a dufferent definition of the word).

Core OS great. But the Linux obsession is a nightmare. Especially
administration; why can’t it be simple, as in QNX4 ?

Boy, I’m glad someone besides me finally put that one into words. I hate
Linux almost as much as i hate Microsoft. And yes, Neutrino has done some
things VERY, VERY right! But QNX4 is much easier to use.

An opinion I share, but I often asked myself: is my opinion bias by all
those
years working with QNX4. For someone starting from scratch is QNX4
really that easier?

15

Most important to me (at this time) is the full Dinkum lib, and a highly
ISO compliant compiler (mind you the embedded systems I currently work
on tend to be 1Ghz processors with at least 256MB RAM and 20GB hard
drives :slight_smile:. My philosophy is: compliance first; efficiency will come…
I really think QSSL has to start taking C++ seriously now, it is a
standard and it is rapidly replacing C as the development language of
choice (even in embedded systems).

I think this whole discussion speaks to how hard it is to be truly
scalable, not just at the O/S level but at the tools level also (nobody
said it was easy, but to date, nobody does it as well as QNX does).

The choice of 3 libs sounds very good.

-----Original Message-----
From: Colin Burgess [mailto:cburgess@qnx.com]
Posted At: Tuesday, August 28, 2001 7:51 AM
Posted To: os
Conversation: gcc2.95, sizes and optimizations
Subject: Re: gcc2.95, sizes and optimizations


A compiler/linker that generates executable 2-3 times
bigger then i`s LINUX counterpart for a system targeted
at embedded and small foot print I find concerning.
Alain you did talk about “main focus”. I was under the
impression executable size was under the “main focus”
section > :wink:

It’s not the compiler Mario, it’s the library. The Dinkum C++ lib
doesn’t
seem to play nicely with gcc wrt compile time and size. We’re currently
looking at the Dinkum Abridged C++ lib, which is a much leaner version,
and
it is showing promising results so far.

We will be making packages soon that will allow you to select between
the
full Dinkum C++, the Abridged Dinkum C++, and the GNU C++ for
development.

\

cburgess@qnx.com

16

I tend to agree with Mario. For someone coming from a “traditional” Unix
background, QNX6 is a much easier migration path than QNX4. It is just so
much closer to the “normal” Unix environment (both from an administrative
and development point-of-view).

Don’t get me wrong - I love some of the “simplifications” that are present
in QNX4 but it took me a long time to learn all the idiosyncrasies.

I’m even beginning to like ddd. The only thing I really miss is vedit…

Rob Rutherford


“Mario Charest” <mcharest@zinformatic.com> wrote in message
news:9n5qfk$dj6$1@inn.qnx.com…

“Bill Caroselli (Q-TPS)” <> qtps@earthlink.net> > wrote in message
news:9n5jf9$9ep$> 1@inn.qnx.com> …
“Ian Cannon” <> ianc@tecom.com.au> > wrote in message
news:> Voyager.010903085757.26711B@aresnode2.tecom.com.au> …
Previously, Bill Caroselli (Q-TPS) wrote in qdn.public.qnxrtp.os:


I do think that QSSL needs to seriously rethink the compiler issue.
I’ll
admit, I am spoiled by Watcom. But I am using QNX because I want to
be
spoiled!

I do want to be spoiled. Watcom was fantastic. Especially the
debugger.

OK. Touche’!


I love Neutrino the OS. But I have to admit, developing under RTP I
feel
like I am SPOILED! (obviously a dufferent definition of the word).

Core OS great. But the Linux obsession is a nightmare. Especially
administration; why can’t it be simple, as in QNX4 ?

Boy, I’m glad someone besides me finally put that one into words. I
hate
Linux almost as much as i hate Microsoft. And yes, Neutrino has done
some
things VERY, VERY right! But QNX4 is much easier to use.

An opinion I share, but I often asked myself: is my opinion bias by all
those
years working with QNX4. For someone starting from scratch is QNX4
really that easier?


\

17

Rennie Allen <RAllen@csical.com> wrote:

Most important to me (at this time) is the full Dinkum lib, and a highly
ISO compliant compiler (mind you the embedded systems I currently work
on tend to be 1Ghz processors with at least 256MB RAM and 20GB hard
drives > :slight_smile:> . My philosophy is: compliance first; efficiency will come…
I really think QSSL has to start taking C++ seriously now, it is a
standard and it is rapidly replacing C as the development language of
choice (even in embedded systems).

careful, you might start a war…

regards,
rick

18

I agree with Rennie here. Factoring the problem and distributing tasks is
much easier. C++ allows us to build higher level tools more easily and to put
them into use more effectively. For embedded systems, simply steer away from
some of the more time/space consuming aspects, nothing says you must use it
all.

Admittedly, I have done many of the same things in C with Abstract Data Types
but C++ handles the nitty-gritty in standard ways that are easier for users.

Rick Lake wrote:

Rennie Allen <> RAllen@csical.com> > wrote:
Most important to me (at this time) is the full Dinkum lib, and a highly
ISO compliant compiler (mind you the embedded systems I currently work
on tend to be 1Ghz processors with at least 256MB RAM and 20GB hard
drives > :slight_smile:> . My philosophy is: compliance first; efficiency will come…
I really think QSSL has to start taking C++ seriously now, it is a
standard and it is rapidly replacing C as the development language of
choice (even in embedded systems).

careful, you might start a war…

regards,
rick

19

I’m even beginning to like ddd. The only thing I really miss is
vedit…

There’s no accounting for taste :slight_smile: Have you tried nedit ? It seems if
one liked vedit (with the standard bindings) then one would probably
like nedit. I’d admit that I use nedit, if converting from Emacs were
not a sin punishable by death…

20

Rennie Allen wrote:

I’m even beginning to like ddd. The only thing I really miss is
vedit…

There’s no accounting for taste > :slight_smile: > Have you tried nedit ? It seems if
one liked vedit (with the standard bindings) then one would probably
like nedit. I’d admit that I use nedit, if converting from Emacs were
not a sin punishable by death…

Don’t worry, Rennie, that’s only in MA. :sunglasses: