jimc@iscuva.ISCS.COM (Jim Cathey) (08/22/89)
In article <34184@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <8352@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>Want to display a bitmap or picture with more than 32,767 pixels in a >>scrolling window? Better write your own scroll bar CDEF then, and set >>up your own versions of the value etc. routines, because the Control >>Manager can't imagine you would ever want a 32-bit control. Same goes >>for text -- want to display more than 32,767 lines in a scrolling text >>document? Don't look to the OS for help, except for drawing the >>characters! >Sounds like a job for MacApp! MacApp allows views to have 32-bit coords... Oops, something just slid over my reasonableness threshhold, so watch out! (Not picking on anybody in particular, it's just that I keep hearing things like this and I can't let them slide forever.) FLAME ON **** It's not just the CM that can't imagine anyone needing (not wanting) a long, I can't either. Why not just scale the control? Do you really _need_ more than 32767 discrete settings for a control? Why? Usually when scrolling through bitmaps a chunk size of 8 bits is more reasonable than 1 bit anyway, so using each increment of 1 of the scrollbar to move 8 pixels yields a document size of about 300 feet! (262,000 pixels.) In MacPaint terms this represents an in-memory bitmap of 18MB in size (for _monochrome_)! Isn't that big enough yet? Make the chunk 9 or 10 pixels if it isn't. Consider that >32767 settings of a scroll bar mean that the operator will find it very difficult to use the thing to find a position anyway. Each pixel of the control (say about 400 to be generous) represents 82 different settings of the control. Controls live in the human interface space, not the program convenience space. If you find you're wanting more range than is available it's because you haven't decomposed the problem correctly. The complaint about TE has been dealt with already. By the time you get that many lines TE has bogged down to the point that you don't want to use it anyway. Hell, if all I wanted to do was scroll through a huge number of lines of text I'd probably not even blink about doing it myself -- especially since I'd probably 'chunk' the document in from disk piecemeal so's not to waste memory having my mongo document in memory all at once. Those putative 40,000 80-column lines take up 3.2MB all by themselves. C'mon guys, MoveTo and DrawText are _easy_! Lord help us when the Mac has VM -- hardly anyone one will ever even try to appease the effeciency gods. The Vax weenies [Paging Will Fix It (tm)] will dance upon our graves yet (chanting "More megabytes, more megabytes..."). I _like_ the 16-bit integers and all that entails. They serve as a constant reminder to _think_ about what ranges I need, and why. The long is there for when they won't serve. I suppose spending a few minutes thinking about things _is_ too much for some, but let's let them continue to bang their shins on real-life systems and piss-n-moan about it. _We_ know better don't we? Sooner or later they'll learn, and we'll all be better off. We won't appease the uninformed by breaking our tools so they're less efficient. (You know, 32-bit ints, >32K globals for huge static arrays, VM, things like... oh-oh!) FLAME OFF **** +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
d88-jwa@nada.kth.se (Reply via mail or intl. +46 8 258 268...) (08/23/89)
In article <2601@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >Oops, something just slid over my reasonableness threshhold, so watch out! >(Not picking on anybody in particular, it's just that I keep hearing things > like this and I can't let them slide forever.) >FLAME ON **** #include <asbestos_suit.h> >The complaint about TE has been dealt with already. By the time you >get that many lines TE has bogged down to the point that you don't want >to use it anyway. But MY complaint about TE is the fact that it DOES bog down... >80-column lines take up 3.2MB all by themselves. C'mon guys, MoveTo and >DrawText are _easy_! But flickers in anything else but monochrome on a SEx, yes... >Lord help us when the Mac has VM -- hardly anyone one will ever even >try to appease the effeciency gods. The Vax weenies [Paging Will Fix >It (tm)] will dance upon our graves yet (chanting "More megabytes, more >megabytes..."). Post it to rec.humour.funny. Much better than the things that come from there presently. >FLAME OFF **** >+----------------+ >! II CCCCCC ! Jim Cathey >! II SSSSCC ! ISC-Bunker Ramo >! II CC ! TAF-C8; Spokane, WA 99220 >! IISSSS CC ! UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com) >! II CCCCCC ! (509) 927-5757 >+----------------+ > "With excitement like this, who is needing enemas?" #include <flame.h> #define _FLAME_ If you're concerned about efficiency, why do you have a >3 row .sig ? And why can't we spoiled Mac programers have a wishing-list for christmas just like the other kids ? Here's mine: 1) Protected Memory 2) Protected Memory 3) Larger Jump Tables (So I can debug OOP on large projects) this may be solved through 4) 32 bit resource sizes 5) TE that doesn't bog down. A simple, neat editor/word processor with the ability to easily add functionality. and from Father Christmas, who's not gonna give me anything anyway since I've flamed so many people this year, I want 6) Preemptive Multitasking So there! -- This is your fortune from h+@nada.kth.se: TRAPEZOID - A device for catching zoids.
mce@tc.fluke.COM (Brian McElhinney) (08/24/89)
In article <2601@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >I _like_ the 16-bit integers and all that entails. They serve as a constant >reminder to _think_ about what ranges I need, and why. The long is there for >when they won't serve. > >I suppose spending a few minutes thinking about things _is_ too much >for some, but let's let them continue to bang their shins on real-life >systems and piss-n-moan about it. _We_ know better don't we? Sooner >or later they'll learn, and we'll all be better off. We won't appease >the uninformed by breaking our tools so they're less efficient. (You know, >32-bit ints, >32K globals for huge static arrays, VM, things like... oh-oh!) I *hate* 16-bit integers and all of the stupidity it shows: the assumption that you can predict the future ("oh, no one could possibly need something that large"). Programming is hard. Arbitrary limits are bad and make programming even harder, especially in system software! Efficiency is only *one* issue (I don't care how fast a program does the wrong thing). I've always been amazed that Intel and IBM are publicly castrated for the segmented, 16-bit, 8086 family, but Apple turning a 32-bit 68000 into a segmented 15-bit architecture is Just Fine. [And, yes, I am quite aware of the (very good) reasons why. I just hope, in vain, that the same mistake is not repeated in System 7.0] Brian McElhinney mce@tc.fluke.com
miller@CS.ROCHESTER.EDU (Brad Miller) (08/24/89)
I *hate* 16-bit integers and all of the stupidity it shows: the assumption
that you can predict the future ("oh, no one could possibly need something
that large"). Programming is hard. Arbitrary limits are bad and make
programming even harder, especially in system software! Efficiency is only
*one* issue (I don't care how fast a program does the wrong thing).
Gee, you're right! Well, Apple, I certainly hope you will support only
BIGNUM arithmetic for ints, so you can support future infinite address space
machines. After all, why have any fixed precision when there is still
available memory? And that will make all our current programs work just as
inefficiently when you change processors. ;-)
Sarcastically yours,jimc@iscuva.ISCS.COM (Jim Cathey) (08/24/89)
In article <1456@draken.nada.kth.se> h+@nada.kth.se (Jon W{tte) writes: >>80-column lines take up 3.2MB all by themselves. C'mon guys, MoveTo and >>DrawText are _easy_! >But flickers in anything else but monochrome on a SEx, yes... Que? That sequence is how TE (and most everything else) draws its text, so I don't understand the comment. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
tim@hoptoad.uucp (Tim Maroney) (08/24/89)
In article <2601@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >FLAME ON **** Save it for when you're right.... >It's not just the CM that can't imagine anyone needing (not wanting) a >long, I can't either. Why not just scale the control? Do you really >_need_ more than 32767 discrete settings for a control? Why? Usually >when scrolling through bitmaps a chunk size of 8 bits is more >reasonable than 1 bit anyway, so using each increment of 1 of the >scrollbar to move 8 pixels yields a document size of about 300 feet! Gosh, I must have forgotten it's a law of nature that there are 72 pixels to an inch. I guess the TIFF development team did as well. You hit this limit in about eight pages there. I know, it really stretches the imagination that anyone might want to fax a whole eight pages, doesn't it? >Controls live in the human interface space, not the program convenience >space. If you find you're wanting more range than is available it's >because you haven't decomposed the problem correctly. Yeah, we should just let it decompose to the point that no one wants to use multi-page high-density bitmaps. That's a sure winner. >The complaint about TE has been dealt with already. By the time you >get that many lines TE has bogged down to the point that you don't want >to use it anyway. Another stunning rejoinder. TextEdit has so many limitations already that one more doesn't make a difference. It's this kind of crystal clarity of thought that has led to TextEdit being the support layer of choice for word processing applications.... >Hell, if all I wanted to do was scroll through a huge number of lines of text >I'd probably not even blink about doing it myself -- especially since I'd >probably 'chunk' the document in from disk piecemeal so's not to waste memory >having my mongo document in memory all at once. Those putative 40,000 >80-column lines take up 3.2MB all by themselves. C'mon guys, MoveTo and >DrawText are _easy_! Yeah! Yeah! And selection is a breeze! And double and triple clicking are easy! And shift-double-clicking is practically trivial! And style changes are a snap! And word wrapping algorithms -- no problem! And size changes are very easy to handle! And compatibility with Script Manager, right-to-left font families, context-sensitive letters, and two-character symbols isn't all that hard! And so on, and so on. Tens of easy problems generally add up to a hard problem. But let's back off and see what you're saying here. TextEdit is fine because it's so limited you don't use it anyway. The 16-bit limitations of QuickDraw and the Control Manager are fine because you can hack your way around them by using counter-intuitive approaches. Anyway, you can always write your own managers. Are you making any sense at all, or did you just get up on the wrong side of the bed this morning? >Lord help us when the Mac has VM -- hardly anyone one will ever even >try to appease the effeciency gods. The Vax weenies [Paging Will Fix >It (tm)] will dance upon our graves yet (chanting "More megabytes, more >megabytes..."). Well, I'm glad you got that off your chest. It has nothing to do with this message, but then, flames are supposed to be incoherent and shrill, right? Right. >I _like_ the 16-bit integers and all that entails. They serve as a constant >reminder to _think_ about what ranges I need, and why. The long is there for >when they won't serve. Not in the operating system it isn't, you blithering cretin. There is no capability to use longs when you run into the OS limitations on shorts. (There's a joke in that last clause, but it's not worth the trouble.) Is this point so hard for you to understand -- that 16 bits is a low limit which very many real programs will hit in the real world, while 32 bits is a high limit which most real programs can treat as an effective infinity? >I suppose spending a few minutes thinking about things _is_ too much >for some, but let's let them continue to bang their shins on real-life >systems and piss-n-moan about it. It's considered strange to talk about yourself this way. >_We_ know better don't we? Sooner >or later they'll learn, and we'll all be better off. We won't appease >the uninformed by breaking our tools so they're less efficient. (You know, >32-bit ints, >32K globals for huge static arrays, VM, things like... oh-oh!) Oh come on! Not only 16-bit control values and bit planes, but virtual memory, 32-bit integers, more than 32K of global space, and for all I know, a 32-bit data bus drive you up the wall now? Why don't you go back to CP/M and have fun with your little 64K address space and trying to fit real programs into it? The rest of us have work to do. I can just see it now. "4-MEGABYTE SIMMS -- JUST SAY NO." "A deranged individual identifying himself as a computer programmer was arrested outside Apple Computer in Cupertino today after threatening to, quote, wake those idiots up to the threat to our precious bodily fluids. His demands to reduce the Macintosh to 64K of RAM and, quote, no more bits in QuickDraw than will fit on a screen, were dismissed by industry observers as the ravings of a madman." >FLAME OFF **** I think "pilot light out" is more accurate.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Every year, thousands of new Randoids join the ranks. Most tend to be either too-rich self-made tycoons or picked-on computer nerds (the romantic, heroic individualism of Rand's novels flatters the former and fuels the latter's revenge fantasies)." -- Bob Mack, SPY, July 1989
amanda@intercon.uu.net (Amanda Walker) (08/24/89)
Yow. Everybody seems to be in a bad mood about scroll bars this week :-). I think that Jim and Tim both have good points. Arbitrary limits (especially low ones) are guaranteed to be run into. Whether or not there are workarounds is beside the point. However, in the specific case of scroll bars for big views (like 60 page TIFF files), I'm not sure what the problem is. The value range of the control is only relevant when you are moving or positioning the thumb directly. a 16 bit value *doesn't lose you anything*! Now personally, I agree that using shorts for everything is really annoying (esp. in the List Manager and TextEdit), but in this particular case it's not a very hard limit. Let's take a concrete example. I have a window that provides a scrolling view on a 2550 by 198000 bit bitmap (60 pages at 300 dpi). For the moment, pretend I have enough memory in which to store it :-). Among the things I keep as part of the state of the window are the coordinates of the upper left hand corner of the currently visible area, as two 32 bit integers. I also have a scroll bar whose value can range from 0-32767. The only "special" thing I have to do when the user scrolls is to update the offsets and then set the scroll bar appropriately, rather than the other way around. If I were feeling unusually clever, I might even write a couple of small routines that used the refCon field as an extended value, so that I wouldn't even have to change my old code except to do a global replace of "SetCtlValue" and "GetCtlValue" to, say, "XSetCtlValue" and "XGetCtlValue". If I wanted to be even more general, I could make the refCon point at a handle containing 32-bit min, max, and value fields... Much less icky than making the List Manager handle >32K of data or rewriting TextEdit... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
mce@tc.fluke.COM (Brian McElhinney) (08/25/89)
In article <1989Aug23.181850.22509@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: >Gee, you're right! Well, Apple, I certainly hope you will support only >BIGNUM arithmetic for ints, so you can support future infinite address space >machines. After all, why have any fixed precision when there is still >available memory? And that will make all our current programs work just as >inefficiently when you change processors. ;-) We're talking system software here. System software using 16-bit integers on a 32-bit CPU is an arbitrary limit. It's the same meme that gave us the 8086 the same year as the 68000. "No one could possibly need a single variable larger than 64K." You don't agree with that, I hope. Why are QuickDraw, Control Manager, etc, any different? [For the 128K Mac might have been wise because it saved RAM at a time when there was hardly *any* RAM for applications. I doubt it would have much impact now] Brian McElhinney mce@tc.fluke.com
jimc@iscuva.ISCS.COM (Jim Cathey) (08/25/89)
In article <8380@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Gosh, I must have forgotten it's a law of nature that there are 72 >pixels to an inch. I guess the TIFF development team did as well. You >hit this limit in about eight pages there. I know, it really stretches >the imagination that anyone might want to fax a whole eight pages, >doesn't it? Never said it was a law, but it _is_ a characteristic of the Macintosh display space, which is where the numerical value of a control has its ultimate expression. Regardless of the bit density of a TIFF image, once displayed on the Mac screen it is 72 bpi (more or less), if you're working with a 'life-size' representation. My original point is that a control already has a much greater range of values than an operator can comfortably deal with. Scaling will easily (even trivially) handle shifting to whatever space your application needs. You have not addressed the issue. Bumping into that 16-bit limit is more a case of "Oh, nasty... wait a minute, I can't use that simple-minded approach anyway because then the program would be hard to use. Let's think about this for awhile..." >>... >Another stunning rejoinder. TextEdit has so many limitations already >that one more doesn't make a difference. It's this kind of crystal >clarity of thought that has led to TextEdit being the support layer >of choice for word processing applications.... Which it was _never_ intended to be! >Yeah! Yeah! And selection is a breeze! And double and triple >clicking are easy! And shift-double-clicking is practically trivial! >And style changes are a snap! And word wrapping algorithms -- no >problem! And size changes are very easy to handle! And compatibility >with Script Manager, right-to-left font families, context-sensitive >letters, and two-character symbols isn't all that hard! And so on, >and so on. Tens of easy problems generally add up to a hard problem. > >But let's back off and see what you're saying here. TextEdit is fine >because it's so limited you don't use it anyway. Having Word in ROM might be nice, but that's not a real expectation is it. The original posting was (as I interpreted it) about displaying text out of a (large) file, not about interactive editing. Anything that requires a huge file to be entirely in memory before displaying a little piece of it sucks, so far as that is concerned. Eventually TE will probably be extended to start swapping pieces on and off of disk. I don't expect it to, and I don't really even want it to (given what it will surely do to the overhead [per usage] required to run TE), and I surely don't expect the manner in which it will do it to please everybody. >The 16-bit >limitations of QuickDraw and the Control Manager are fine because you >can hack your way around them by using counter-intuitive approaches. >Anyway, you can always write your own managers. Are you making any >sense at all, or did you just get up on the wrong side of the bed this >morning? Intuition is not always correct, and you _can_ always write your own managers, especially if the ones that already exist are designed to solve different problems than the one you have at hand. >>I _like_ the 16-bit integers and all that entails. They serve as a constant >>reminder to _think_ about what ranges I need, and why. The long is there >>for when they won't serve. >Not in the operating system it isn't, you blithering cretin. There is >no capability to use longs when you run into the OS limitations on shorts. Such politeness!! I've never advocated the use of a short where a long is called for. My point has always been to use the appropriate size for the job. Certain things have no need for more range than 16 bits implies. Certain architectures penalize you for the larger sizes (the 68000 is one such). What's wrong with recognizing this situation and allowing for it? It certainly doesn't hurt you where this isn't the case. >Is this point so hard for you to understand -- that 16 bits is a low >limit which very many real programs will hit in the real world, while >32 bits is a high limit which most real programs can treat as an >effective infinity? Just as they treat memory, disk space, and CPU horsepower as effectively infinite? Sorry, I work only on _real_ machines. Ones that reward me with fast execution speeds for thinking first before coding. (Oh, you mean they _all_ do that? Well, how about that!) >Oh come on! Not only 16-bit control values and bit planes, but virtual >memory, 32-bit integers, more than 32K of global space, and for all I >know, a 32-bit data bus drive you up the wall now? Larger than 32K global space encourages such laziness as declaring huge arrays as global, rather than allocating them. I am not against large global spaces, but I am against this laziness. It is unfortunate that the environment is such that you can't have the best of both (a system that lets you have a large aggregate of globals [for the rare times when you really need such], but doesn't let you have huge working arrays without using NewPtr/NewHandle.) I like 32-bit data busses, but not when I'm trying to design a low-cost something. These things all have their place, and it'll be very sad when I can no longer design a low-cost something because all the programmers were too lazy to make programs that would run on lesser machines. My worry is that we'll end up like the damned IBM's, where programs that don't do very much require 386's in order to run acceptably fast. Out of programmers' laziness. If you want to see another sorry sight, try one of those DEC Vaxstations. 800KB-1.2MB window applications. 6MB of RAM and the thing's still sluggish, it feels worse than the 512K VM graphics workstation I'm typing this on. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ Member: Society for the Preservation of Thought in Programming. P.S. I never did like CP/M, though the Z-80's inherent limitations aren't what bugged me about it.
wetter@cup.portal.com (Pierce T Wetter) (08/25/89)
In article <2601@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >>FLAME ON **** >Save it for when you're right.... Save the snide remarks for when you're right... >>It's not just the CM that can't imagine anyone needing (not wanting) a >>long, I can't either. Why not just scale the control? Do you really >>_need_ more than 32767 discrete settings for a control? Why? Usually >>when scrolling through bitmaps a chunk size of 8 bits is more >>reasonable than 1 bit anyway, so using each increment of 1 of the >>scrollbar to move 8 pixels yields a document size of about 300 feet! >Gosh, I must have forgotten it's a law of nature that there are 72 >pixels to an inch. I guess the TIFF development team did as well. You >hit this limit in about eight pages there. I know, it really stretches >the imagination that anyone might want to fax a whole eight pages, >doesn't it? Gee, I must have forgotten it's a law of nature that the value you pass to the CM must have a one to one correspondance to your data. God Forbid that the scroll bar value should be the y coordinate of your document in INCHES instead of 300dpi pixels. (Or even quarter inches!) Or even the size of your document over 65535! Wow! 65535 distinct positions in a say, 50 page document. Gee, thats every .008" inches. Of course 50 300dpi pages would need 50megabytes of storage, but who's counting. >>Controls live in the human interface space, not the program convenience >>space. If you find you're wanting more range than is available it's >>because you haven't decomposed the problem correctly. >Yeah, we should just let it decompose to the point that no one wants >to use multi-page high-density bitmaps. That's a sure winner. Different uses of decompose here. Decompose as in simplify, and decompose as in brain rot. Pay attention! :-) >>The complaint about TE has been dealt with already. By the time you >>get that many lines TE has bogged down to the point that you don't want >>to use it anyway. >Another stunning rejoinder. TextEdit has so many limitations already >that one more doesn't make a difference. It's this kind of crystal >clarity of thought that has led to TextEdit being the support layer >of choice for word processing applications.... What do you want from something that was originally designed to fit in 2k of ROM? TextEdit does fine for what it is: A system utility for editing, and displaying small bits of text so that programmers don't have do spend hours writing code every time they want input from the user. Styled TextEdit simply allows for fancier display boxes. TextEdit was never designed to be a word processor, which is why it doesn't handle: footnotes, paragraphs, full-justification etc. That was the point to his response: bitching about TextEdit has been dealt with. >>Hell, if all I wanted to do was scroll through a huge number of lines of text >>I'd probably not even blink about doing it myself -- especially since I'd >>probably 'chunk' the document in from disk piecemeal so's not to waste memory >>having my mongo document in memory all at once. Those putative 40,000 >>80-column lines take up 3.2MB all by themselves. C'mon guys, MoveTo and >>DrawText are _easy_! >Yeah! Yeah! And selection is a breeze! And double and triple >clicking are easy! And shift-double-clicking is practically trivial! >And style changes are a snap! And word wrapping algorithms -- no >problem! And size changes are very easy to handle! And compatibility >with Script Manager, right-to-left font families, context-sensitive >letters, and two-character symbols isn't all that hard! And so on, >and so on. Tens of easy problems generally add up to a hard problem. Why do you need all this unless you are writing a Word processor? Besides, the structures that TE uses are OPTIMUM for SMALL amounts of text. They would be rediculous for LARGE amounts. (Would you really like to search through a 1 meg array of char to change line breaks every time a char was inserted? Or would you rather search through the structure for that paragraph?) What you are really bitching about is that there is no library of text handling routines for big files or word processors. I have news for you. There never will be unless they provide them in source, simply because everyone will need just a few more fields in the records. If you want this, buy CAPS from Think. >>I _like_ the 16-bit integers and all that entails. They serve as a constant >>reminder to _think_ about what ranges I need, and why. The long is there for >>when they won't serve. >Not in the operating system it isn't, you blithering cretin. There is >no capability to use longs when you run into the OS limitations on shorts. >(There's a joke in that last clause, but it's not worth the trouble.) Actually, the OS is the file manager and the like which use longs, and the toolbox is what uses shorts, but thats quibbling. Just because you disagree with his opinion, don't call him a cretin. He said that HE liked 16 bits, he didn't say that you had to. Since you don't really understand what he said, let me explain it. Programmers are lazy. If apple had put long offsets into TextEdit, MicroSoft Word would use it even if it was deadly slow above 10K. Database programmers would use the Resource Manager for their databases, even though it was totally inappropriate. And the mac would be a toy. >Is this point so hard for you to understand -- that 16 bits is a low >limit which very many real programs will hit in the real world, while >32 bits is a high limit which most real programs can treat as an >effective infinity? Is this point so hard for you to understand -- that 32 bits is too big for most tasks and that lamely written programs would treat it as effective infinity even when inappropriate? (Personally, I would prefer 17 bits) >>_We_ know better don't we? Sooner >>or later they'll learn, and we'll all be better off. We won't appease >>the uninformed by breaking our tools so they're less efficient. (You know, >>32-bit ints, >32K globals for huge static arrays, VM, things like... oh-oh!) >Oh come on! Not only 16-bit control values and bit planes, but virtual >memory, 32-bit integers, more than 32K of global space, and for all I >know, a 32-bit data bus drive you up the wall now? Why don't you go >back to CP/M and have fun with your little 64K address space and trying >to fit real programs into it? The rest of us have work to do. Virtual memory is only bad because lazy programmers put big static arrays in their codes instead of calling malloc. Ever try to port a ray tracer to the Mac? The fact that they never simultaneously use those 15 four meg arrays never seems to enter into programmers minds. "Its just swap space." 16 bit integers are faster then 32 bit integers. > 32K of global space would be nice but is only possible on 020 machines which can have 32bit offsets from address registers. (Unless you want global data to have absolute addressing which would only be possible by relocating the code (ala CP/M-68K) or using a PMMU). Did he mention a 32bit data bus? No, you did. Of course, if you really want something to bitch about, how come the Mac II motherboard doesn't do block transfer? I mean, god forbit you would ever want to shove bytes at the video memory! >>FLAME OFF **** >I think "pilot light out" is more accurate.... I think _reasonable response_ IS accurate. Pierce
pepke@loligo (Eric Pepke) (08/25/89)
In article <1397@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >However, in the specific case of scroll bars for big views (like 60 page >TIFF files), I'm not sure what the problem is. The value range of the control >is only relevant when you are moving or positioning the thumb directly. >a 16 bit value *doesn't lose you anything*! Now personally, I agree that >using shorts for everything is really annoying (esp. in the List Manager >and TextEdit), but in this particular case it's not a very hard limit. > [and describes one good clean way of doing high-precision scrolling.] I agree. Only a very naive programmer would have any difficulty making 16-bit scroll bars do what was required. I've used the SetOrigin by the scrollbars technique a few times, but only when the job I had to do was very simple. When you want to work with very large structures, you will want to do better and faster clipping than QuickDraw does automatically, anyway, so is a half dozen extra lines of code to convert really that big a deal? You will run into any arbitrary limitation sooner or later, and what the arbitrary limitation is is of secondary importance. I implemented scrolling for a dataset of objects with real coordinates and arbitrary zoom. The fact that scroll bars don't return real numbers didn't cause me to lose any sleep. As for TextEdit, I wish that it could do more than 32K characters and do so lickety-split, but then again, I am more interested in seeing it do tabs and super- and subscripts. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
amanda@intercon.uu.net (Amanda Walker) (08/26/89)
In article <118@vsserv.scri.fsu.edu>, pepke@loligo (Eric Pepke) writes: > As for TextEdit, I wish that it could do more than 32K characters and do > so lickety-split, but then again, I am more interested in seeing it do > tabs and super- and subscripts. I have found that Capps' is a real nice TextEdit replacement (even if THINK doesn't want to sell it any more :-(). The only thing I occasionally wish it would do is word wrap, but. For those who aren't familar with it, it's a package of editing routines that seem to be pretty similar to TextEdit except (a) it uses longs for offsets and sizes, thus allowing >32K of text, (b) it uses a gapped text buffer to avoid moving potentially huge amounts of data around every time you insert a character, and (c) it supports tabs and "escape hooks" (which let you do magic things with control characters, like chage the text style). With some blue smoke and mirrors, I even made an MPW library out of it, so that I can use it with MPW C instead of THINK C. Too bad THINK decided to stop selling it just as people were starting to use it... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
bayes@hpislx.HP.COM (Scott Bayes) (08/26/89)
> Is this point so hard for you to understand -- that 16 bits is a low > limit which very many real programs will hit in the real world, while > 32 bits is a high limit which most real programs can treat as an > effective infinity? Except for file systems. It's only 2GB (4 GB unsigned), and bytes are a reasonable file system resolution level. My own OS will run up against the 32 bit boundary soon, what with big discs, magneto-optical discs, etc. Tim is right: once the long boundary is hit, an application can't do diddly with a quad, unless we support it in the OS routines. Scott Bayes
tim@hoptoad.uucp (Tim Maroney) (08/27/89)
In article <10910003@hpislx.HP.COM> bayes@hpislx.HP.COM (Scott Bayes) writes: >> Is this point so hard for you to understand -- that 16 bits is a low >> limit which very many real programs will hit in the real world, while >> 32 bits is a high limit which most real programs can treat as an >> effective infinity? > >Except for file systems. It's only 2GB (4 GB unsigned), and bytes are >a reasonable file system resolution level. My own OS will run up against >the 32 bit boundary soon, what with big discs, magneto-optical discs, etc. Yes, pretty soon we're going to be needing 64-bit file systems. That should last another decade or three. (Then someone will figure out how to do three dimensional optical storage crystals and even 64 bits may not be enough.) Current optical disks are already starting to push against the 32-bit limit -- fortunately, a lot of it can be kept internal to the OS. A 4 gig limit on individual file sizes is livable, it's only the overall file system that will need larger numbers. (And even then, with most real systems, blocks are represented not by a single number, but by a pair of numbers in polar coordinates, so it may be possible to live with pairs of 32 bit numbers for quite a while.) >Tim is right: once the long boundary is hit, an application can't do >diddly with a quad, unless we support it in the OS routines. Yes, and I'm surprised that so many people have missed another of my main points -- you *can* hack around 16-bit limitations, but you shouldn't *have* to. The more such hacks there are in a program, the less elegant and so the less maintainable the program becomes. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Our newest idol, the Superman, celebrating the death of godhead, may be younger than the hills; but he is as old as the shepherds." - Shaw, "On Diabolonian Ethics"