SGI: Development

New version of Nedit seems to be out on sourceforge: 5.7

Downloaded git snapshot zipfile. Source does not not compile with CC, now needs c99. Modify in Makefile.sgi
Will also have to spend some time ripping out the new colour defines so IMD theming will work again.

As I recall I did this for 5.6 too and wanted to feedback to Scott Trigali who seems to be maintaining Nedit these days. However, never managed to get hold of him via sourceforge.

Anybody know how to contact him?

J.

Right, here's a tarball of the git zipfile that I've modified to give us back:

- IMD look-and-feel: menu fonts and SGI DYNAMIC colour theming
- Use of Sgm Open/Save filedialogs
- O2 optimisation and setup for MIPSpro c99 compiler

Just unpack the tarball and run `make sgi`.

J.

sounds great, thanks
i'm surprised tho that it needs c99. i contributed some stuff to the dev branch when it got resurrected and that worked all fine even on irix 5.3. imho compatibility is a major point for nedit, they shouldn't handle that lightly.

I completly agree with you on the compatibility thing. But when I ran `make sgi` out of the box the compile failed. I then checked Makefile.sgi and there were strange things. first of all only -O optimisation. then a -DSGI which doesn;t appear in the source anywhere. It should have been -DSGI_CUSTOM. When I looked into the error I was getting, it seemed some new code in the nedit malloc stuff from 2015 was the culprit. On a hunch I changed the cc to c99 and the compile completed flawlessly.

It makes sense. I imagine there's so few developers people actually running older workstations these days. You can see it a bit from the commit logs etc. there's a lot of talk about openmotif and XFT and what have you which means linux and PeeCee's.

Btw. if the UI stuff is anything to go by, the actual nedit codebase needs a refactor in my opinion. It's really ugly stuff

jimmer wrote: I completly agree with you on the compatibility thing. But when I ran `make sgi` out of the box the compile failed. I then checked Makefile.sgi and there were strange things. first of all only -O optimisation. then a -DSGI which doesn;t appear in the source anywhere. It should have been -DSGI_CUSTOM. When I looked into the error I was getting, it seemed some new code in the nedit malloc stuff from 2015 was the culprit. On a hunch I changed the cc to c99 and the compile completed flawlessly.

aha okay, i guess that needs a closer look.
anyway -O is fine because with most compilers that's just an "alias" for -O2 which many programs use as the conservative default if they wanna play it safe.


EDIT: just checked the SF page and 5.7 doesn't seem to be a release yet. maybe we should wait for the final 5.7 release before putting too much effort in a nightly

EDIT2: had a look at the code and there're only 2 things that require c99.
1. they now use intptr_t which in case of irix can be replaced with long.
2. the one malloc function you mentioned declares one variable in the middle hence not pre-c99 compatible. just move the declaration to the beginnnig of the function and it's fine.

yes. and that one malloc call also is cast to (char *) which as i recall isn;t needed given that malloc returns (void *) But hey, I'm just a fair-weather coder. What do I know from what really goes on in there

jimmer wrote: yes. and that one malloc call also is cast to (char *) which as i recall isn;t needed given that malloc returns (void *)

that doesn't hurt. some compilers want the cast, some don't.

jimmer wrote: Btw. if the UI stuff is anything to go by, the actual nedit codebase needs a refactor in my opinion. It's really ugly stuff

Really? Because in the Mark Edel Slashdot interview (admittedly a long time ago, but not that much has changed in nedit on the in between), he says "One noticeable difference between NEdit and other FS/OSS projects is that the code is neat and thoroughly documented. As I mention in a later question, enforcing this has not been fun, and has probably been counterproductive, as well. It's just something I've found hard to give up on, particularly where I'm going to be the one with the responsibility for maintaining a given section of code."

Interview here:

https://developers.slashdot.org/story/00/10/27/1516243/mark-edel-answers-project-leadership-questions

jimmer wrote: As I recall I did this for 5.6 too and wanted to feedback to Scott Tringali who seems to be maintaining Nedit these days. However, never managed to get hold of him via sourceforge.

Anybody know how to contact him?

His email is s c o t t at tringali dot org, as of yesterday he's still active on the nedit mailing list (to which I subscribe).

Thanks. Have emailed him will be sending my trivial patches in the next while.

I also stand corrected about the nedit code. On second reading the nedit code is nice and clean. No idea why I said the stupid things I did above. I guess some of my Real Life project stress bled through or some other moment of braindeadness was in play. Thanks for calling BS on my comments.

Well, I think Mark enforced as much code-cleanliness as possible but when you're using X, Xt, and Motif things always end up getting a bit thick...

vishnu wrote: His email is s c o t t at tringali dot org, as of yesterday he's still active on the nedit mailing list (to which I subscribe).

nedit also has a lot of problems on X11-pseudocolor-terminals(1)

• v5.7 crashes
• v5.6 crashes
• v5.5 crashes
• v5.4 doesn't crash but it's damn slow to start.

and why does it crash in the first place? Why doesn't show up anything useful instead?
Any dbg_out(stderr, ErrorMessage)? Never heard before? bah

None of them reports a clue.
Need to write to someone.

(1) tested on
HP Envizex
Tektronix XP200s

Are you sure you're compiling it with the all the debugging symbols compiled in? And then running it in the debugger until it crashes? Because, generally speaking that will tell you exactly where in the code it's failing...