tp@ndmce.uucp (Terry Poot) (11/12/86)
In article <118@unirot.UUCP> mg@unirot.UUCP (Mike Gallaher) writes: > > [Re: unipress emacs] > Heaven help you if you need custom work or a port there's not much demand > for. This is one reason why many commercial users have abandoned Unipress. > >Anyone who has a complaint about Unipress Emacs or the support they get should >send mail about it to ...!rutgers!unipress!emacs. >If that doesn't get any response, post it to the net! No company in its >right mind would ignore publicity like that. I'll have to back Mike up on that. We bought Unipress emacs a little over a year ago, and it never fully worked. After a few recent complaints to the net they sent me the new version free (since the one I paid for didn't work). It looks good, and there are some very nice enhancements over the version we have been using (V2.01 is useable, but not real good on a Masscomp). V2.10 is supposedly fully ported (much easier with Masscomp's current OS than it used to be), so I expect I will be happy with it. For what it is worth, people tried and failed to port Gnu to the old Masscomp OS, so even then, Unipress was superior on the Masscomp. Disclaimer: I am a previously dissatisfied Unipress customer who is now reserving judgement. I've never run GNU emacs because it has not been available for my machine. There is supposedly a version available now, but only if you have ftp, as it is the current beta copy and not yet on the distribution tapes. -- Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741 8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp ARPA: ndmce!tp@seismo.css.gov CSNET: ndmce!tp@smu
aland@hpscda.UUCP (11/21/86)
I have to disagree with Mike on this one. I use an HP9000 series 500 machine. I know it has an unconventional (to be nice) architecture, but we still don't have a working 2.10 version of Unipress Emacs. I have both sent net mail to ..!unipress!mg and called Unipress's technical office to leave a message for Mr. Gallaher, but haven't received any reply. I have successfully run a version of 2.10 on a series 300 (68000) machine, but even that version is still being 'fixed'. I continue to use 2.01, but find it's habit of 'help'ing me by destroying my nice windows to be most annoying. Conclusion: Unipress works on VAX-like systems, but the source assumes things like decreasing stack (won't work on series 500 or pyramid). Alan Davis
earls@pyramid.UUCP (11/23/86)
In article <4120002@hpscda.HP.COM>, aland@hpscda.HP.COM (Alan Davis) writes: > > I continue to use 2.01, but find it's habit of 'help'ing me by > destroying my nice windows to be most annoying. Conclusion: > Unipress works on VAX-like systems, but the source assumes things > like decreasing stack (won't work on series 500 or pyramid). > > Alan Davis We got Unipress 2.10 and I compiled it right out of the box and it has been running fine ever since. This is more than 6 months. 2.10 looks like a fine product to me. I enthusiastically recommend it to anyone that can afford it. -- ----------------------------------------------------------------------------- -m------- Earl A. Stutes ---mmm----- Pyramid Technology Corp. -----mmmmm--- Phone: (415) 965 7200 x 6012 -------mmmmmmm- {hplabs,allegra,decwrl,sun}!pyramid!earls -----------------------------------------------------------------------------
rs@mirror.UUCP (11/23/86)
/* Written 5:04 pm Nov 20, 1986 by aland@hpscda.UUCP in mirror:comp.emacs */ >... Conclusion: >Unipress works on VAX-like systems, but the source assumes things >like decreasing stack (won't work on series 500 or pyramid). > Alan Davis /* End of text from mirror:comp.emacs */ Not quite. It's been working on Pyramid's for quite some time. In fact, Pyramid bundles Unipress into their system. (We get it direct from Unipress tho -- because we like to be running the latest bugs. ;-) The Pyramid is more like a 68000 than a Vax, I've found: can't do *NULL, can't do *(long *)1, and the byte-order is the same. (Same as what, you ask? :-) The only real requirement is that (a) your code be linted; and (b) you don't play games with varargs, you do it right. -- Rich $alz "Hi, mom!" Mirror Systems, Cambridge Massachusetts rs@mirror.TMC.COM {mit-eddie, ihnp4, wjh12, cca, cbosgd, seismo}!mirror!rs
ljp@trwrb.UUCP (Laura J. Pearlman) (11/25/86)
In article <209400001@mirror> rs@mirror.UUCP writes: > > [Alan Davis writes that Unipress Emacs won't run on Pyramids] > >Not quite. It's been working on Pyramid's for quite some time. I second that -- version 2.1 compiled and worked right away on our 98x. >In fact, Pyramid bundles Unipress into their system. (We get it >direct from Unipress tho -- because we like to be running the >latest bugs. ;-) Yes, but what Pyramid supplies is the old version 264 Emacs, which still has lots of bugs and is missing all the new features of the later Unipress versions. Also, the last time I checked, Pyramid was charging slightly more for a binary Emacs license than Unipress charges for source. -- Laura Pearlman ...{ucbvax,hplabs,decvax}!trwrb!ljp
mg@unirot.UUCP (Mike Gallaher) (11/27/86)
In article <4120002@hpscda.HP.COM>, aland@hpscda.HP.COM (Alan Davis) writes: > I have to disagree with Mike on this one. I use an HP9000 series 500 > machine. I know it has an unconventional (to be nice) architecture, > but we still don't have a working 2.10 version of Unipress Emacs. Actually, the flame level in my message was a bit too intense (especially since the person hadn't even mentioned HP machines!). In general, HPUX is one of the nicest Unix ports around -- the documentation is quite simply the best I've seen for such a system, and the 9000/300 (68000-based workstations) is one of the most complete, consistent, and likeable Unix systems I've worked on (and we get to see quite a few of them). However, I have spent many hours of my life compensating for the differences between HPUX on the 500 and on everything else that also claims to be Unix System V. (There are more "special case" conditionals in the Emacs code for the 500 than for any other machine...) When I wrote that flame I had just wrestled with the following differences: - the file system is neither berkeley or v7/SysV, so the bsd directory emulator didn't work until I taught it how. (HP does supply its own BSD directory emulation, but it wasn't documented for the 500, at least that I could find). - The tty driver does not support VMIN/VTIME. This *is* documented, but it depends on which hardware interface you have, which is not easy to detect (even by looking at the box!). - There are bugs in the linker which keep it from loading certain library modules. (I pointed these out to the HP support people.) - the linker does not support etext, so we had to use the HP-supplied malloc (no big deal; you just can't ask for memory usage statistics from inside Emacs). I'm still working on the following, though we have workarounds for them: - Signals (in particular SIGCHLD) don't seem to work quite the way they do on System V. - Named pipes (fifos) don't seem to work quite the way they do on System V. It wasn't simply a matter of moving code that worked perfectly on the 300 over to the 500 and typing 'make', but given the differences in architecture that's not surprising. I will say that those things that weren't outright bugs were indeed documented if you know where to look. Now that the 9000/500 peculiarities have been accounted for, we shouldn't have these problems in porting future versions (I hope!). > I continue to use 2.01, but find it's habit of 'help'ing me by > destroying my nice windows to be most annoying. Conclusion: > Unipress works on VAX-like systems, but the source assumes things > like decreasing stack (won't work on series 500 or pyramid). No, V2.10 (which doesn't eat windows) works on Goulds, Pyramids, IBM-PC/RTs, 3b{2,5,20}, Amdahls, 68k, NS32k, as well as Vaxen. It does work on the 500 now, too. (We did get fixes from HP, probably from Alan, in fact, for the stack-growth-direction dependency, but I thought they'd been in for at least a year.) The code does not depend on word size, pointer size, word alignment, byte order, direction of stack growth, being able to take *NULL, or on the presence of "p&p6" at location zero. The only machine we utterly failed to port to was the Perq, which has gained a number of other fans (are you out there, utzoo!henry?). That was quite a while ago; we might even be able to do the Perq these days. Mike Gallaher Emacs Hacker Boss Unipress Software