From xemacs-m  Mon Sep 22 15:55:27 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id PAA08148
	for <xemacs-beta@xemacs.org>; Mon, 22 Sep 1997 15:55:22 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA21976; Mon, 22 Sep 1997 13:54:53 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id NAA15909; Mon, 22 Sep 1997 13:54:50 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA14160; Mon, 22 Sep 1997 13:54:47 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA08697; Mon, 22 Sep 1997 13:54:46 -0700
Date: Mon, 22 Sep 1997 13:54:46 -0700
Message-Id: <199709222054.NAA08697@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Rick Campbell <rickc@lehman.com>
Cc: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Sun does it again...
In-Reply-To: <9709191549.AA23828@cfdevx1.lehman.com>
References: <9709191549.AA23828@cfdevx1.lehman.com>
X-Mailer: VM 6.33 under 20.3 "Vienna" XEmacs  Lucid (beta14)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "Rick" == Rick Campbell <rickc@lehman.com> writes:

Rick> So, it looks like Sun has found yet another way to mess with the only
Rick> debugging environment that's even come close to being usable for me.
Rick> Man, if they could ever come even a little bit close to what I get
Rick> with gdb and emacs gdb-mode, I would be so happy.

Rick> Anyway, I've been messing with the SC4.2 (ten points to whoever can
Rick> figure out why all of their compiler products have at least 2 or three

The same reason the version number of Gnus is not correlated with the
version number of XEmacs?

Rick> different version numbers associated with them) because SC4.0 is
Rick> hopeless flawed when it comes to generating optimized code using
Rick> templates.  I fired up eos::start-dbx and got:

Rick>   dbx: Option '-editor' has been removed in this dbx release
Rick>   dbx: Emacs integration is available through `workshop'
Rick>   dbx: option usage error

Being a believer in editor-centric computing, I would not have made
this decision.

But you can understand Sun's decision from this perspective: EOS was
an editor-specific solution, and Sun wanted a solution that would
allow users to use their Editor Of Choice (in the real world, this
means vi, FSF Emacs, or XEmacs).  Therefore a solution was devised
that would work with vi as well.  On the way to implementing that, the
-editor option disappeared, and EOS stopped working as a result.  EOS
was a personal effort by Eduardo Pelligri-LLopart (`Eduardo's Own
version of Sparcworks'), but he left the developer products group at
Sun around the time these decisions were being made, and EOS was
orphaned.  The engineer most responsible for the new WorkShop design
recently left Sun for Microsoft.

Rick>   Process Eos Dbx exited abnormally with code 2

Rick> Naturally, apropos for `workshop' turns up zilch.  I'm guessing that

man workshop

Rick> this must be the new environment that their reps told us that they
Rick> were going to put effort into instead of trying to get the compiler up
Rick> to spec.  The only thing that comes to mind is to back out to
Rick> progessively older versions of dbx until I find one that they didn't
Rick> already cripple.

You are asking for trouble if the dbx and the compiler you use don't
match.

Remember that every company is just a bunch of diverse folks who all
have different perspectives and design visions and time constraints.
There is no conspiracy to deprive customers of functionality.  But
sometimes things happen so that it looks that way.  I'm sure the
following comment in lib-src/Makefile.in can be explained the same
way:

## Why oh why does HP not include half of the standard X distribution?

Rick> So . . . two questions for anyone out there:

Rick>  - is there any way to get SC4.2 dbx working with XEmacs 19.15 with
Rick>    SparcWorks support?

There will be changes to allow 20.3 M-x dbx to work with SC4.2 dbx.

Rick>  - now that Cygnus has a template database for g++ is there any reason
Rick>    to prefer it to Sun's attempts at C++ support?

Every C++ compiler has its advantages and disadvantages.  I think
you'll find that Sun's compilers have better performance on your
real-world apps.

Martin

