simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) (12/14/90)
Well, I've just go 2.0 up and running on two of my cubes. Here are some initial reactions: * 2.0 is *much* faster than 1.0a. One of the reasons for this is that a lot of attention has been paid to the layout of objects in memory. * Although 2.0 is binary compatiable with 1.0a, it is not source-code compatiable. You will need to change your applications in order to get it to recompile. * In particular, the Bitmap object nolonger exists. Instead, there is a new object called NXImage that does everything that Bitmap did and more --- it will load EPS or TIFF, load from files, &c. For example, it can automatically the bitmap from your file to the memory-space of the window manager, without having to send the bits through your app! But it is not as easy to use. * This seems to be the case with a lot of the new things. Much more powerful. Much less easy to use. Well, at least the book I'm writing about Programming the NeXT is going to have an audience. (Now all I need is a publisher!) * Stuart 2.0 doesn't work properly. It leaves turds at the bottom of each line on redisplay. This is odd, and kind of flies in the face of binary compatiability. Well, at least it works. * I'm still using Stuart 2.0, however, because the insert-line/delete-line functions in Terminal are a little broken. You probably won't notice the problem unless you use EMACS. If you use EMACS (most of the people at NeXT don't, by the way), you'll get screwed alot --- especially if you scroll one-line-up or one-line-down a lot. (I have lisp functions that do this, bound to ^Z and meta-control-Z). * Speaking about META, the people at NeXT who made Terminal work don't seem to understand that META-F is not the same as <ESC> <F>. The problem, again, is EMACS. If ALT-F transmits ESC-F instead of META-F (that is, an F with bit-8 set, or ASCII 0xb6), you can't use ALT-F to terminate an incremental search. Instead, the first ESC gets gobbled by the incremental search and it goes into regular-search (and who uses that?) That's just one example. * Lisp doesn't work. At all. You can't rebuild Lisp for some obscure /bin/ld problem. I've been able to run words that I dumped with (dumplisp file:), but I can't really run them because the throw to the TOP-LEVEL::MAIN-LOOP (not its real name but close) doesn't work anymore. Apparently, the top-level loop isn't there. * Icon is *gone*. I don't know how to make an icon now. Make a backup of your program before doing the upgrade. * The spinning cursor is a real pain, and there is no way to turn it off (that I can figure). * Sound Effects (a la Apple's Sonic Finder) would be nice. Or has that idea been patented too? (Has anybody seen the article I wrote with Richard about why software patents are bad?) More good things: * The objective-C +new has been superseeded with an +alloc function, which allows you to specify which Mach Zone to allocate the object in. You set up your application so that objects used in the same part of the program are allocated in the same zone. As a result, applications have to swap a lot less. * Interface builder has more options/classes/other stuff. And the ability to dynamically load in a class, which means that you don't have to build "custom IB" anymore. * Edit is now in Retained mode, not Buffered mode. As a result, it flashes, but it draws faster. Be nice if you could set this. You probably won't see the flashing on an 040. * Application debugger lets you look into a bundled application (kind of like ResEdit on the mac). * Process debugger lets you open a running process and mess with its mind, or at least look at it. * Much better sound demos. * If you print to a LaserWriter, the NeXT now puts the pages in the right order. Thank you! * several very impotant security holes have been plugged. * WriteNow blazes. And it finally seems to use DPS to do its kerning, so things really look the same way on the screen that they do on the printer. * gdb now works with Edit. (Oh joy!) ================ A question to the net: how many people use Emacs and how many use Edit? *don't post what you use, and please don't start a flame war!* Just send me e-mail and let me know. I have a suspicion that emacs is far more popular. ================ In other news, I've gotten my News reader to the same level of completion that Will Shipley's is. Oh, I've got posting almost working too, Rich Text and all! The idea that I like best about dealing with the Rich Text / non-rich-text problem was suggested by Will: do a writeRichText: and a writeText:. Post the normal text, a ^l, and then a uuencoded, compressed, binary diff of the two. The only problem is that, well, I've done testing, and the overhead of doing a uudecode, an uncompress, and a binary ed is just, well, too high. So I think that well just post both the rich text. It's not *that* unreadable. If you can't read RichText on your Sun, buy a NeXT. Or I'll give you a copy of my Rich Text spec, and *you* can implement all of the tools from scratch that come as part of the package on the NeXT platform. Hopefully I'll have something that can be FTP'ed by January.
declan@traffic.rutgers.edu (Declan McCullagh/LZ) (12/14/90)
In article <4490@media-lab.MEDIA.MIT.EDU>, simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: > * Although 2.0 is binary compatiable with 1.0a, it is not source-code > compatiable. You will need to change your applications in order to > get it to recompile. Yes... Keep that copy of 1.0 around for compiling programs that you find in the /pub/next/sources directories of archive sites. > * Stuart 2.0 doesn't work properly. It leaves turds at the bottom of > each line on redisplay. This is odd, and kind of flies in the face of > binary compatiability. Well, at least it works. That's strange. I used Stuart 2.0 with NeXTstep 2.0 for a day or two, then switched back to Terminal (because of the lack of the Services menu in Stuart). While I used it (with Emacs), I only saw garbage text on the last line once. > * Icon is *gone*. I don't know how to make an icon now. Make a > backup of your program before doing the upgrade. Huh? Do you have the extended version of 2.0? Icon's still there, and much improved, though not as stable as the 1.0 version. > In other news, I've gotten my News reader to the same level of > completion that Will Shipley's is. Oh, I've got posting almost > working too, Rich Text and all! The idea that I like best about > dealing with the Rich Text / non-rich-text problem was suggested by > Will: do a writeRichText: and a writeText:. Post the normal text, a > ^l, and then a uuencoded, compressed, binary diff of the two. That seems the most straightforward way to do things. If (that's a big IF, in terms of space) you're going to support NeXTmail-like attachments, you'll probably have to tar/compress/uuencode anyway. Also, as the person following a thread is reading messages, perhaps you could be checking the articles ahead in the thread and uudecoding/uncompressing/untaring those. The performance might get a bit less than optimal if the person is jumping around a thread, but if he/she's consistently reading messages sequentially, it might be worthwhile. > Hopefully I'll have something that can be FTP'ed by January. Great! Good luck. Declan McCullagh Independent NeXT Developer
garth@cs.swarthmore.edu (Garth Snyder) (12/15/90)
In <4490@media-lab.MEDIA.MIT.EDU> (Simson L. Garfinkel) writes: > Well, I've just go 2.0 up and running on two of my cubes. Here are > some initial reactions: > > I'm still using Stuart 2.0, however, because the insert-line / > delete-line functions in Terminal are a little broken. You probably > won't notice the problem unless you use EMACS. If you use EMACS (most > of the people at NeXT don't, by the way), you'll get screwed alot --- > especially if you scroll one-line-up or one-line-down a lot. You might try running with strict vt100 compliance on, though this will cause you other headaches if your terminal window isn't the size of a vt100. > Speaking about META, the people at NeXT who made Terminal work don't > seem to understand that META-F is not the same as <ESC> <F>... > If ALT-F transmits ESC-F instead of META-F (that is, an F with bit-8 > set, or ASCII 0xb6), you can't use ALT-F to terminate an incremental > search. You can use the Preferences panel to choose whether the Alternate key generates Escape sequences or characters with bit-8 set. Or use dwrite to specify an arbitrary prefix character. -- Garth Snyder | UUCP: {bpa,liberty}!swatsun!garth Swarthmore College | NET: garth@cs.swarthmore.edu 500 College Avenue | DOD#: 0085 Swarthmore, PA 19081 | QUOTE: "Quidquid latine dictum sit, altum viditur"
glenn@heaven.woodside.ca.us (Glenn Reid) (12/17/90)
In article <4490@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: >* Icon is *gone*. I don't know how to make an icon now. Make a >backup of your program before doing the upgrade. No it's not. /NextDeveloper/Demos/Icon.app Maybe your dock just has /NextDeveloper/Demos/Icon (I think the .app is a recent development) and it just "seems" to be gone when you try to launch it from the dock. In fact, not only is Icon still there, it has become quite an amazing program, capable of all sorts of things (if you can only figure out the interface). You should see it in color. It never really was just an "Icon" program, but now it's even further from that. Image processing program is more like it. >A question to the net: how many people use Emacs and how many use >Edit? *don't post what you use, and please don't start a flame war!* >Just send me e-mail and let me know. I have a suspicion that emacs is >far more popular. I use Edit unless I'm hacking around in the shell and need to quickly edit a file without taking my hands off the keyboard, in which case I launch emacs. >In other news, I've gotten my News reader to the same level of >completion that Will Shipley's is. Oh, I've got posting almost >working too, Rich Text and all! The idea that I like best about >dealing with the Rich Text / non-rich-text problem was suggested by >Will: do a writeRichText: and a writeText:. Post the normal text, a >^l, and then a uuencoded, compressed, binary diff of the two. > >The only problem is that, well, I've done testing, and the overhead of >doing a uudecode, an uncompress, and a binary ed is just, well, too >high. So I think that well just post both the rich text. It's not >*that* unreadable. If you can't read RichText on your Sun, buy a >NeXT. Or I'll give you a copy of my Rich Text spec, and *you* can >implement all of the tools from scratch that come as part of the >package on the NeXT platform. I think that the best idea about Rich Text got lost in the shuffle. I think it was from Mike Dixon at PARCplace. The idea was to put the plain text first, then have a trailer with the RTF commands and some byte offsets into the plain text where they should be applied. This enables a single post of length equivalent to an RTF file that can be read as plain text by normal people, but software could pick up and apply the RTF commands from the end of the file before the file is viewed. Give that some thought; I think it's an excellent idea. There is one glitch I can think of, though, which is what you do when you want to include somebody else's post in yours, and you add > characters and all the offsets change. I guess you just generate a completely new RTF file with only a single trailer at the bottom. Anyway, I think that is the perfect solution for the RTF newsreader, and it will hardly add any bandwidth. Anybody else remember that posting? Could its original author amplify the volume and perhaps give us another example? I think it would work perfectly, with a little software thrown at it. /Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
cfw@aplpy.jhuapl.edu (Chuck Waltrip) (12/18/90)
In article <371@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: >In article <4490@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: >>* Icon is *gone*. I don't know how to make an icon now. Make a >>backup of your program before doing the upgrade. > >No it's not. /NextDeveloper/Demos/Icon.app > >Maybe your dock just has /NextDeveloper/Demos/Icon (I think the .app is >a recent development) and it just "seems" to be gone when you try to >launch it from the dock. In fact, not only is Icon still there, it has >become quite an amazing program, capable of all sorts of things (if you >can only figure out the interface). You should see it in color. It >never really was just an "Icon" program, but now it's even further from >that. Image processing program is more like it. > >>A question to the net: how many people use Emacs and how many use >>Edit? *don't post what you use, and please don't start a flame war!* >>Just send me e-mail and let me know. I have a suspicion that emacs is >>far more popular. > >I use Edit unless I'm hacking around in the shell and need to quickly >edit a file without taking my hands off the keyboard, in which case I >launch emacs. > >>In other news, I've gotten my News reader to the same level of >>completion that Will Shipley's is. Oh, I've got posting almost >>working too, Rich Text and all! The idea that I like best about >>dealing with the Rich Text / non-rich-text problem was suggested by >>Will: do a writeRichText: and a writeText:. Post the normal text, a >>^l, and then a uuencoded, compressed, binary diff of the two. >> >>The only problem is that, well, I've done testing, and the overhead of >>doing a uudecode, an uncompress, and a binary ed is just, well, too >>high. So I think that well just post both the rich text. It's not >>*that* unreadable. If you can't read RichText on your Sun, buy a >>NeXT. Or I'll give you a copy of my Rich Text spec, and *you* can >>implement all of the tools from scratch that come as part of the >>package on the NeXT platform. > >I think that the best idea about Rich Text got lost in the shuffle. >I think it was from Mike Dixon at PARCplace. The idea was to put the >plain text first, then have a trailer with the RTF commands and some >byte offsets into the plain text where they should be applied. This >enables a single post of length equivalent to an RTF file that can be >read as plain text by normal people, but software could pick up and >apply the RTF commands from the end of the file before the file is >viewed. Give that some thought; I think it's an excellent idea. There >is one glitch I can think of, though, which is what you do when you >want to include somebody else's post in yours, and you add > characters >and all the offsets change. I guess you just generate a completely >new RTF file with only a single trailer at the bottom. > >Anyway, I think that is the perfect solution for the RTF newsreader, >and it will hardly add any bandwidth. Anybody else remember that posting? >Could its original author amplify the volume and perhaps give us another >example? I think it would work perfectly, with a little software thrown >at it. > >/Glenn > >-- > Glenn Reid RightBrain Software > glenn@heaven.woodside.ca.us PostScript/NeXT developers > ..{adobe,next}!heaven!glenn 415-851-1785
rca@cs.brown.edu (Ronald C.F. Antony) (12/18/90)
In article <371@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: >I think that the best idea about Rich Text got lost in the shuffle. >I think it was from Mike Dixon at PARCplace. The idea was to put the >plain text first, then have a trailer with the RTF commands and some >byte offsets into the plain text where they should be applied. >[...] There >is one glitch I can think of, though, which is what you do when you >want to include somebody else's post in yours, and you add > characters >and all the offsets change. The way to handle that is that the whole editor and all routines work with RTF. Only for postings or for reading in posting there should be a conversion in one or the other direction. Then the rest should work transparently. >Anyway, I think that is the perfect solution for the RTF newsreader, >and it will hardly add any bandwidth. Anybody else remember that posting? I remember and fully agree. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet
scott@mcs-server.gac.edu (Scott Hess) (12/18/90)
In article <4490@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes:
* Stuart 2.0 doesn't work properly. It leaves turds at the bottom of
each line on redisplay. This is odd, and kind of flies in the face of
binary compatiability. Well, at least it works.
There are some weirdisms in the layout of the Courier font. I think
Ohlfs shoudl still work. I'll release a 2.0 specific Stuart in January
(in fact, Stuart2.0 is the last 1.0 Stuart . . .)
* I'm still using Stuart 2.0, however, because the
insert-line/delete-line functions in Terminal are a little broken.
You probably won't notice the problem unless you use EMACS. If you
use EMACS (most of the people at NeXT don't, by the way), you'll get
screwed alot --- especially if you scroll one-line-up or one-line-down
a lot. (I have lisp functions that do this, bound to ^Z and
meta-control-Z).
Hmm. That shouldn't happen, because Terminal and Stuart2.0 are mostly
the same. I wonder what I did right :-).
* Speaking about META, the people at NeXT who made Terminal work don't
seem to understand that META-F is not the same as <ESC> <F>. The
problem, again, is EMACS. If ALT-F transmits ESC-F instead of META-F
(that is, an F with bit-8 set, or ASCII 0xb6), you can't use ALT-F to
terminate an incremental search. Instead, the first ESC gets gobbled
by the incremental search and it goes into regular-search (and who
uses that?) That's just one example.
You should be able to set the hi-bit for Meta from Preferences. If not,
then they changed the app since I last saw it.
* Edit is now in Retained mode, not Buffered mode. As a result, it
flashes, but it draws faster. Be nice if you could set this. You
probably won't see the flashing on an 040.
Actually, I think this is a feature of the Text object. If the windows
were really in Retained mode all the time, the scrollbar would look
terrible (seriously, put a scrollbar in a Retained window.)
This brings up another feature: apparently, you can change the backing
of a window on the fly. So, the Text object can change the backing to
Retained for scrolls . . . don't ask me how (I've not seen the docs,
yet.)
--
scott hess scott@gac.edu
Independent NeXT Developer GAC Undergrad
<I still speak for nobody>
"Tried anarchy, once. Found it had too many constraints . . ."
"Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by
Richard Simmons . . ."cfw@aplpy.jhuapl.edu (Chuck Waltrip) (12/19/90)
In article <371@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: >In article <4490@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: [.... some discussion deleted ....] >>In other news, I've gotten my News reader to the same level of >>completion that Will Shipley's is. Oh, I've got posting almost >>working too, Rich Text and all! The idea that I like best about >>dealing with the Rich Text / non-rich-text problem was suggested by >>Will: do a writeRichText: and a writeText:. Post the normal text, a >>^l, and then a uuencoded, compressed, binary diff of the two. >> >>The only problem is that, well, I've done testing, and the overhead of >>doing a uudecode, an uncompress, and a binary ed is just, well, too >>high. So I think that well just post both the rich text. It's not >>*that* unreadable. If you can't read RichText on your Sun, buy a >>NeXT. Or I'll give you a copy of my Rich Text spec, and *you* can >>implement all of the tools from scratch that come as part of the >>package on the NeXT platform. > >I think that the best idea about Rich Text got lost in the shuffle. >I think it was from Mike Dixon at PARCplace. The idea was to put the >plain text first, then have a trailer with the RTF commands and some >byte offsets into the plain text where they should be applied. This >enables a single post of length equivalent to an RTF file that can be >read as plain text by normal people, but software could pick up and >apply the RTF commands from the end of the file before the file is >viewed. Give that some thought; I think it's an excellent idea. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I agree. >There >is one glitch I can think of, though, which is what you do when you >want to include somebody else's post in yours, and you add > characters >and all the offsets change. I guess you just generate a completely >new RTF file with only a single trailer at the bottom. Hmmmm. Will Usenet let you insert some unprintable character in the text to be replaced by a corresponding RTF command in the trailer? By corresponding, I mean the first instance of the unprintable character would be replaced by the first RTF command in the trailer, the second instance of the unprintable character would be replaced by the second RTF command in the trailer, etc. I don't know if there are any unprintable characters (e.g., <ESC>) which have special signifi- cance to any Usenet mailers and therefore have to be avoided. My guess is that you probably can't get away with using any unprintable characters since translation tables on the various Usenet nodes aren't even all that consistent about the full set of printable characters. In which case it may be that some printable character sequence may have to be used which may not be much less obtrusive than just inserting the RTF commands themselves. If it turns out that you can insert an unprintable character, then, to avoid the translation table problem, you will have to place that character in a known place in the RTF trailer so that the RTF mail reader can find it and know what the unprintable character was received as. This is the same principle used in uuencoded files which contain a header with the list of those characters which get translated differently by different nodes. I hope some workable solution for posting RTF can be found as I believe it would be a nice touch. And I agree with Glenn that the scheme for keeping the RTF commands confined to a trailer is a good approach. > >Anyway, I think that is the perfect solution for the RTF newsreader, >and it will hardly add any bandwidth. Anybody else remember that posting? >Could its original author amplify the volume and perhaps give us another >example? I think it would work perfectly, with a little software thrown >at it. > >/Glenn > >-- > Glenn Reid RightBrain Software > glenn@heaven.woodside.ca.us PostScript/NeXT developers > ..{adobe,next}!heaven!glenn 415-851-1785 c.f.waltrip <cfw@aplpy.jhuapl.edu> Opinions expressed are strictly my own.
mdixon@parc.xerox.com (Mike Dixon) (12/19/90)
I think that the best idea about Rich Text got lost in the shuffle.
I think it was from Mike Dixon at PARCplace.
for the record,
it wasn't my idea,
PARC (a Xerox research lab) is not the same as PARCPlace (a PARC
spinoff to commercialize the Smalltalk work), and
i have yet to read a news posting that would have been improved by RTF...
--
.mike.glenn@heaven.woodside.ca.us (Glenn Reid) (12/22/90)
In article <MDIXON.90Dec18213147@thelonius.parc.xerox.com> mdixon@parc.xerox.com (Mike Dixon) writes: >for the record, > it wasn't my idea, > PARC (a Xerox research lab) is not the same as PARCPlace (a PARC > spinoff to commercialize the Smalltalk work), and > i have yet to read a news posting that would have been improved by RTF... Sorry, Mike. I should know better than to half-remember things, rather than going back and getting it right. I do know the difference between PARC and PARCplace, and I apologize for that error, too. And, now that you mention it, I have to agree that news articles in general would not be improved by using RTF, although the FLAMES would improve dramatically when people could use italics and large sizes of type to tell each other that they are idiots. Thanks for your clarification; sorry to use your name in vain. Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785