7:06 a.m.
(The following is NOT an official statement, it's my personal
opinion!)
>>>> "IH" == Isaac Hollander
<ysh(a)mindspring.com> writes:
IH> Sun^WForte still ships XEmacs 20.4 with their Workshop IDE suite, since
I've asked this question here many times:-( But it looks like there is
movement at the end of the tunnel;-) I'm not in charge of the workshop
but I know some people;-)
IH> the lisp files in the Sun directory of xemacs-packages only work
IH> properly if they're dumped into the xemacs binary.
IH> I've opened up a bug report with Sun from my ork address, but I don't
IH> expect any quick progress.
Did you get a bug number or anything?
IH> While you can hack the lisp yourself to get workshop to semi-work, I
IH> would argue that until Sun or someone associated with them provides
IH> 21.x compatible lisp code, the Sun directory should be removed from
IH> xemacs-packages.
I think I got a fairly working (at least) 21.1 together. I did not try
the workshop part with the 21.2.* yet. What are the problems you're
seeing?
IH> My $.02.
IH> Should this discussion take place on the xemacs-beta mailing list?
I don't know how many are interested in this topic?
Thanks,
-- Marco
IH> Thanks
IH> Isaac
--
9:59 a.m.
New subject: Sun package is deadwood?
[ I have cc'd Tor Norbye who is responsible for the Workshop-XEmacs
integration
Tor: this is about Sun/Forte still shipping 20.4 and IH claims the
lisp files shipped with Workshop don't work with 21.1 ]
Marco Walther <marcow(a)jena.eng.sun.com> writes:
>>>>> "IH" == Isaac Hollander
<ysh(a)mindspring.com> writes:
IH> the lisp files in the Sun directory of xemacs-packages only work
IH> properly if they're dumped into the xemacs binary.
really? Have you followed the instructions in the XEmacs FAQ? It works
fine here. Alas I still use the _Sun_ Workshop (5?) and not _Forte_
(6?), yet.
IH> I've opened up a bug report with Sun from my ork address,
but I don't
IH> expect any quick progress.
Did you get a bug number or anything?
IH> While you can hack the lisp yourself to get workshop to semi-work, I
IH> would argue that until Sun or someone associated with them provides
IH> 21.x compatible lisp code, the Sun directory should be removed from
IH> xemacs-packages.
I think I got a fairly working (at least) 21.1 together. I did not try
the workshop part with the 21.2.* yet. What are the problems you're
seeing?
IH> My $.02.
IH> Should this discussion take place on the xemacs-beta mailing list?
I don't know how many are interested in this topic?
I am. xemacs-beta is certainly the right place.
Gunnar
2:12 p.m.
New subject: Sun package is deadwood?
Gunnar> really? Have you followed the instructions in the XEmacs FAQ? It works
Gunnar> fine here. Alas I still use the _Sun_ Workshop (5?) and not _Forte_
Gunnar> (6?), yet.
IH> I've opened up a bug report with Sun from my ork address, but I don't
IH> expect any quick progress.
>
> Did you get a bug number or anything?
>
I'll double check.
IH> While you can hack the lisp yourself to get workshop to semi-work, I
IH> would argue that until Sun or someone associated with them provides
IH> 21.x compatible lisp code, the Sun directory should be removed from
IH> xemacs-packages.
>
> I think I got a fairly working (at least) 21.1 together. I did not try
> the workshop part with the 21.2.* yet. What are the problems you're
> seeing?
I looked at the xemacs-beta archives for information, but did not check
the FAQ. I am duly chastened. I found information on the correct
libraries to load, but not the eserve.el patch; I'll try that out.
But in any case, IMHO it's time for Workshop/Forte to work without extra
user-level lisp hacks. Whether the fix is in $xemacs-packages/Sun or in
/opt/SUNWspro/lib/*.el, the hacks noted in the FAQ should _not_ be
necessary if Sun wants to take XEmacs development seriously.
Isaac
2:38 p.m.
New subject: Sun package is deadwood?
>>>> "Isaac" == Isaac Hollander
<ysh(a)mindspring.com> writes:
Isaac> I looked at the xemacs-beta archives for information, but did not check
Isaac> the FAQ. I am duly chastened. I found information on the correct
Isaac> libraries to load, but not the eserve.el patch; I'll try that out.
If you don't want to hack the elisp, you can do something like this:
;; now, to fake out the "bad" workshop 4.x eserve.el XEmacs
;; version checking:
(let ((saved-emacs-version emacs-version))
(setq emacs-version (concat "20.x or higher " emacs-version))
(load "workshop")
(setq emacs-version saved-emacs-version))
and if I remember correctly that isn't a problem in the Forte version.
In case this info will help anyone, I had to set up our install here to deal
with both the 4.x WorkShop and the 6.x Forte WorkShop (not that I use either
of them myself but rather just use dbx, but others here that use my XEmacs
install do) and I did it with the following elisp in our site-start.el:
======================================================================
;; To get SunPro SPARCWorks WorkShop stuff to load and start properly for the
;; various flavors of WorkShop we have to use on different machines: find
;; where eserve/workshop exec is, so we know where to find the elisp for it!
(require 'executable)
(let ((wspath (file-truename (executable-find "workshop")))
(wslibdir))
(if wspath
(progn
(setq wslibdir (replace-in-string (file-name-directory wspath) "/bin/?$"
"/lib"))
(if (file-exists-p wslibdir)
(progn
(message "adding workshop lib dir (%s) to load path" wslibdir)
(setq load-path (cons wslibdir load-path))
;; then load all the required gunk for it too:
(when (featurep 'tooltalk)
(load "tooltalk-macros")
(load "tooltalk-util")
(load "tooltalk-init"))
(when (featurep 'sparcworks)
(load "sunpro-init")
(load "ring")
(load "comint")
(load "annotations")
;; now, to fake out the "bad" workshop 4.x eserve.el XEmacs
;; version checking:
(let ((saved-emacs-version emacs-version))
(setq emacs-version (concat "20.x or higher " emacs-version))
(load "workshop")
(setq emacs-version saved-emacs-version))
))
(message "workshop lib dir (%s) missing?" wslibdir)))
(message "workshop not found in exec-path?")))
======================================================================
There may be a more elegant way to do this, but it seems to work ok here.
Chuck
--
Charles K. Hines <ckh(a)requesttech.com> <hines(a)gderome.com>
Principal Scientist at ReQuest Technologies Inc (http://www.ReQuestTech.com/)
Martial Arts Instructor [Modern Arnis and Balintawak Escrima]
"Go back to sleep, Chuck. You're just havin' a nightmare
-- of course, we ARE still in Hell." (Gary Larson)
7:40 a.m.
New subject: Sun package is deadwood?
I used to work on XEmacs/Workshop integration at Sun 5 years ago.
>>>> "Marco" == Marco Walther
<marcow(a)jena.eng.sun.com> writes:
Marco> (The following is NOT an official statement, it's my personal
Marco> opinion!)
>>>> "IH" == Isaac Hollander
<ysh(a)mindspring.com> writes:
IH> Sun^WForte still ships XEmacs 20.4 with their Workshop IDE suite, since
I was expecting Forte to ship with 21.1.
Marco> I've asked this question here many times:-( But it looks like there is
Marco> movement at the end of the tunnel;-) I'm not in charge of the workshop
Marco> but I know some people;-)
Much of the Sun elisp stuff, like eos, was unmaintained even then.
The Sun directory should not be in the Sumo, but keeping the packages
in CVS should do no harm.
I also know some folks at Sun who at least were recently in charge of
XEmacs/Workshop. Unfortunately, XEmacs/Workshop integration is not a
high-priority activity at Sun.
2:29 p.m.
New subject: Sun package is deadwood?
Martin> The Sun directory should not be in the Sumo, but keeping the packages
Martin> in CVS should do no harm.
Or even provide a separate package file a la jde for people to grab if
they want.
Martin> I also know some folks at Sun who at least were recently in charge of
Martin> XEmacs/Workshop. Unfortunately, XEmacs/Workshop integration is not a
Martin> high-priority activity at Sun.
That's what I've heard as well from my Sun sources.
Isaac
6:13 a.m.
New subject: Sun package is deadwood?
|--==> "MB" == Martin Buchholz <martin(a)xemacs.org> writes:
MB> The Sun directory should not be in the Sumo, but keeping the packages
MB> in CVS should do no harm.
Okay, the next SUMO won't have Sun. But I'll still keep the package
available so people can grab it if the want to.
Perhaps a 'README' at the top of the SUMO is in order, now that we
have a few packages that aren't included in the SUMO.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
5:30 p.m.
New subject: Sun package is deadwood?
>>>> "MB" == Martin Buchholz
<martin(a)xemacs.org>:
MB> I also know some folks at Sun who at least were recently in charge of
MB> XEmacs/Workshop. Unfortunately, XEmacs/Workshop integration is not a
MB> high-priority activity at Sun.
truly unfortunate - some of my most pleasant debugging experiences were
when I was using a Sun and their debugger with XEmacs as the frontend - I
just loved being able to set breakpoints, etc. in XEmacs while seeing the
code formatted and colored exactly as it was meant to be
oh well...
--
John A. Turner, Ph.D. Senior Research Associate
Blue Sky Studios, 44 S. Broadway, White Plains, NY 10601
http://www.blueskystudios.com/ (914) 259-6319
8646
days inactive
8655
days old
8 comments
8 participants
participants (8)
-
Charles Hines -
Gunnar Evermann -
Isaac Hollander -
John A. Turner -
Marco Walther -
Martin Buchholz -
Mats Larsson -
Steve Youngs