tmkk@uiuc.edu (K. Khan) (05/15/91)
In article <1991May7.235644.28744@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > > Well I recieved 5.01 yesterday, installed today, and almost >threw it out the window tonight. I know precisely what you mean! > Anybody know what the following error means: > > > (0) Unrecoverable error 668 : Eval Stack Fault > run-time error R6001 > - null pointer assignment Nope, I just came here to gripe! ;-) > Doesn't look good, I know a MSC error when I see one. You know >this is the 3rd revision of the Clipper product I have worked with >(S87, 5.0, 5.01) in the last 3 years, and as far as I am concerned this >thing is still in alpha test mode. That's for sure. > The error happens before getting into any of my code (the first line >of code is a DISPOUT("MADE IT") and that never gets executed). The >particular project is about 7000 lines of code (re)written from scratch >when 5.0 came out. The program has no warnings under the 5.0 compiler. It's pretty pathetic when code that compiles and runs fine under 5.0 breaks when compiled under 5.01, an alleged bug FIX. Here's my horror story (hit 'n' now if not interested): After installing the Clipper "upgrade," I recompiled my current project (not sure how big, but there are a couple dozen program files, maybe 20,000 lines of code). The first thing I noticed was that the size of the executable grew (it's now over 500K) as well as the amount of memory needed to run as indicated by .PLink. The worst part, however, is that a report routine that works fine under 5.0 locks up under 5.01. It opens two databases, steps through one while SEEKing associated records in the other. After each seek, I check to see if the record was found(). Somewhere during the call to found() the program disappears into the bit bucket (that found() is the location of the bug was verified both with debugging print statements as well as the Clipper debugger). Commenting out the line containing the call to found() avoids the lockup. The really bizarre part is that the problem ONLY occurs when I have output redirected to the printer using the SET PRINTER command! I can generate the report and send it to the screen, or to a disk file, with no problems whatsoever. It only locks up when output is going to the printer. This NEVER happened under 5.0. The workaround is to use recno() and reccount() instead of found(), thusly: replace if (!found())... with if (recno() > reccount())... Since I wasted quite some time figuring this one out, I haven't had a chance to run across any of the other new Clipper bugs yet... :-( Oh, the Norton Guides won't run on my PS/2 Model 70 with 2Mb of RAM and QEMM, either, and since cheapskate Nantucket isn't sending out any printed versions of the new Clipper documentation, I am forced to disable QEMM and reboot my machine whenever I need to look something up in the documentation. :-( :-( I suspect that we're about to see a large-scale exodus of former Clipper users to other products. Nantucket blew it once with the first release of 5.0, and now it appears that they have blown it again. I hear Fox is coming out with a new compiler for FoxPro...
tleylan@pegasus.com (Tom Leylan) (05/16/91)
In article <1991May14.170431.1509@ux1.cso.uiuc.edu> tmkk@uiuc.edu (K. Khan) writes: > >I suspect that we're about to see a large-scale exodus of former Clipper >users to other products. Nantucket blew it once with the first release >of 5.0, and now it appears that they have blown it again. > >I hear Fox is coming out with a new compiler for FoxPro... K., I suspect that you don't know what you're talking about. Send me one of your applications, I'll push all the wrong buttons and post a message about how terrible it is. Nantucket has far from blown it, Digital Research hasn't blown it, Whitewater Group hasn't blown it, Digitalk, Inc. hasn't blown it. If they are profitable and they move in the direction that they choose to move they are operating the business as they have right to do so. They can bet the bank on DR-DOS, Actor and Smalltalk if they want to and while I'm sure you know the best way to make money, they are entitled to try it their way. By all means purchase the FoxPro compiler... who suggested otherwise ? tom
tmkk@uiuc.edu (K. Khan) (05/16/91)
In article <1991May15.210031.23270@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: >In article <1991May14.170431.1509@ux1.cso.uiuc.edu> tmkk@uiuc.edu (K. Khan) writes: >> >>I suspect that we're about to see a large-scale exodus of former Clipper >>users to other products. Nantucket blew it once with the first release >>of 5.0, and now it appears that they have blown it again. >> >>I hear Fox is coming out with a new compiler for FoxPro... > >K., > >I suspect that you don't know what you're talking about. > >Send me one of your applications, I'll push all the wrong buttons and post >a message about how terrible it is. Ah, so according to you, Clipper is perfectly bug free and the only errors are the result of users "pushing the wrong buttons"? It seems clear that you are the one who doesn't know what he's talking about. The trade press took Nantucket to task for their initial release of 5.0. Their users took them to task. They felt it necessary to provide a BUG FIX release, 5.01. Clearly, 5.00 was too buggy for a "real" release. In my book, using your customers as your quality control department is BLOWING IT. 5.0 needed much more testing, but clearly Nantucket felt great pressure to release it because it was already MANY months late, so they shipped it before it was truly ready. As a result, users suffered. That is what I call BLOWING IT. As for 5.01 fixing all the bugs of 5.0 as you seem to believe, care to explain how a program, written from scratch in Clipper 5.0 and working perfectly, SUDDENLY BREAKS when compiled under 5.01? No external 3rd party libraries were used, it was all "native Clipper" code, and not one line of code was changed, merely the compiler version. Feel free to worship Nantucket as the best, most bug-free software development environment in the universe. Those of us with a grip on reality will probably be moving along to something better as soon as possible.
jgb@prism.gatech.EDU (James G. Baker) (05/17/91)
In article <1991May16.135821.5096@ux1.cso.uiuc.edu> tmkk@uiuc.edu (K. Khan) writes: > [ Various whining about Clipper... ] > It seems clear that you are the one who doesn't know what he's talking about. There is no such thing as a bug-free program, esp a compiler. Everyone knows of the "floating point libraries not linked" with TURBO C v2.0. I surely did not throw away TC for MSC. I've had some experience at crafting a compiler - I can not fathom the depth of Clipper. I have never seen a posting from Mr. Leylan bashing Foxpro, or dBaseIV to pieces -just explaining the merits of Clipper. Should I listen to his advice or the ranting on of someone who hits one snag and throws his arms up in the air? There will always be bugs. A bug-free Clipper would be on the order of a bug-free 80386 -which is nothing short of a miracle. I have never hit anything that there was not a work around for. And of course we all have the choice of going back to earlier versions which may be more stable but lack features. Are you saying that MS should have waited until v3.3 was ready rather than releasing 3.0, 3.1., 3.2? Wordperfect 5.0 was a bad move? Granted, DOS 4.0 was premature, but no one has a gun to your head. > Clearly, 5.00 was too buggy for a "real" release. In my >book, using your customers as your quality control department is BLOWING >IT. 5.0 needed much more testing, but clearly Nantucket felt great >pressure to release it because it was already MANY months late, so they >shipped it before it was truly ready. As a result, users suffered. That >is what I call BLOWING IT. Don't tell me you deleted Clipper '87 before trying v5.0? Multiply: (NUMBER OF PC's)*(POSSIBLE DISK SPACE)*(POSSIBLE MEMORY AVAIL)*(PROCESSOR TYPE)*(VIDEO TYPE)*(PERMUTATIONS OF SOUCE CODE)*(ASSUMPTION THAT DOS, TSRs, etc ARE WORKING RIGHT) That's a lot of things to test. -J Baker -- BAKER,JAMES G - Undergraduate Lab Instructor, School of Electrical Engineering ____ _ _ Georgia Institute of Technology, Atlanta Georgia, 30332 | | _ |_) uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jgb (_|. |_). |_). Internet: jgb@prism.gatech.edu, jgb@ee, jgb@eecom, jgb@cc
maurit@nrtc.nrtc.northrop.com (Mark Aurit <maurit>) (05/17/91)
In article <1991May15.210031.23270@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: >Nantucket has far from blown it, Digital Research hasn't blown it, Whitewater Agreed, Nantucket hasnt blown it in the sense that the company will probably remain solvent. However, from the standpoint that A-T was hemorraging and that the pickings were ripe for the other guys, they have certainly "blown" it in that many customers are not happy with 5.0 and I doubt if it will them many new ones. "Hey guys, lookit this slick new software, its harder to user and buggier than the old one." > >By all means purchase the FoxPro compiler... who suggested otherwise ? Actually, we've all blown it in that Fox continually states that they are NOT offering a compiler, just the ability to create .exe files. I say if it walks like a duck and sounds like a duck .... Mark
b39y@vax5.cit.cornell.edu (05/17/91)
tmkk- > As for 5.01 fixing all the bugs of 5.0 as you seem to believe, care to > explain how a program, written from scratch in Clipper 5.0 and working > perfectly, SUDDENLY BREAKS when compiled under 5.01? No external 3rd > party libraries were used, it was all "native Clipper" code, and not one > line of code was changed, merely the compiler version. > I'm not sure if you do this, but if you use PLLs you have to regenerate the BASE50.PLL file with 5.01 for some reason. (If this is obvious to you, then sorry for insulting your intelligence; but I'm aware of how often the obvious solutions are somewhat apparent until after the fact.) Dave Rodger b39y@vax5.cit.cornell.edu
tmkk@uiuc.edu (K. Khan) (05/18/91)
In article <29176@hydra.gatech.EDU> jgb@prism.gatech.EDU (James G. Baker) writes: > >Should I listen to >his advice or the ranting on of someone who hits one snag and throws his >arms up in the air? ONE snag? You don't know much about Clipper, do you? This snag is merely the latest one of many. :-( >There will always be bugs. True. The goal here is "reasonably bug free". The initial release of 5.0 clearly missed that goal. >Are you saying that MS should have waited until v3.3 was ready rather >than releasing 3.0, 3.1., 3.2? Wordperfect 5.0 was a bad move? Granted, >DOS 4.0 was premature, but no one has a gun to your head. dBase IV was premature, also. In fact, I'm sure we could come up with a long list of products which were released before they were really ready. Just because it's a common practice doesn't make it good or right. I'm saying that instead of rushing their (already late) product to market prematurely, Nantucket should have waited, gotten rid of more bugs, and THEN released a reasonably bug-free compiler. Of course, they felt additional pressures due to the behind-schedule status of 5.0, so they chose not to wait.
tleylan@pegasus.com (Tom Leylan) (05/18/91)
In article <24450@gremlin.nrtc.northrop.com> maurit@nrtc.nrtc.northrop.com (Mark Aurit) writes: >remain solvent. However, from the standpoint that A-T was hemorraging and that >the pickings were ripe for the other guys, they have certainly "blown" it >in that many customers are not happy with 5.0 and I doubt if it will them many >new ones. "Hey guys, lookit this slick new software, its harder to user and >buggier than the old one." >> Mark, Just to clarify things a bit, at no point did Nantucket entertain the idea that the typical dBASE user was a potential Clipper developer. There is no interactive front end to Clipper (as you know) and one would have to be blind to believe that a group that typically resists explicit declaration of variables as PUBLIC or PRIVATE is going to embrace the concepts behind LOCAL and STATIC declarations. Anybody who would issue a CLEAR ALL command in an application doesn't understand multi-programmer projects and the inherent problems that constructs like that introduce. Nantucket isn't blind, their development group aren't incapable of writing dBASE IV, the prefer not to. I sat in Larry Heimendinger's office and told him to expect to lose the low-end dBASE user who only used Clipper as a "packager" to compile their final dBASE III application. I believe that they will gain from the top end however, the programmers who could write the app in C or Pascal but for various reasons (usually productivity) they will choose to use Clipper now. Those people would not use dBASE because it is seriously flawed as a language (not necessarily flawed as a tool however). BTW, the sales figures for Clipper completely counter your hypothesis that sales are waining. Personally I don't care what product anybody uses but I don't like people to base their decisions on misleading information. tom
tleylan@pegasus.com (Tom Leylan) (05/18/91)
In article <1991May16.135821.5096@ux1.cso.uiuc.edu> tmkk@uiuc.edu (K. Khan) writes: > >Ah, so according to you, Clipper is perfectly bug free and the only errors >are the result of users "pushing the wrong buttons"? It seems clear that >you are the one who doesn't know what he's talking about. The trade >press took Nantucket to task for their initial release of 5.0. Their >users took them to task. They felt it necessary to provide a BUG FIX >release, 5.01. Clearly, 5.00 was too buggy for a "real" release. In my I don't believe I said that 5.01 is "perfectly bug-free" and would likely not use those words. Anyone who has spent any time in the computer industry would realize that such a statement is fundamentally unproveable. There is no software that is bug-free. You can quote the trade press anytime you want, PC Week is routinely called PC Weak by many, InfoWorld is not too much better. I was interviewed by one of InfoWorld's Bureau Chiefs, who didn't print my comments because they did not jive with the story he wanted to print. I guess I'll remain puzzled did you not want Nan to release a bug-fix ? > >Feel free to worship Nantucket as the best, most bug-free software >development environment in the universe. Those of us with a grip on >reality will probably be moving along to something better as soon as >possible. Thanks but I don't worship software, I use it. I use Clipper because it solves my problems. I don't understand your delay "you'll move along as soon as possible", move today, purchase Borland's C++ or grab a copy of Zortech C++ and pickup Microsoft's Windows SDK. If you're waiting for a language to be developed to suit your own personal beliefs I think you have a long wait. In fact, develop one of your own, I'll buy a copy, yours would be perfect your tech support staff would have CS degrees and upgrades would be free if they were necessary at all... let me know when it's finished. tom
tleylan@pegasus.com (Tom Leylan) (05/18/91)
In article <29176@hydra.gatech.EDU> jgb@prism.gatech.EDU (James G. Baker) writes: >Don't tell me you deleted Clipper '87 before trying v5.0 ? > Uh Oh... common sense, can't have that around here James <grin> tom
maurit@nrtc.nrtc.northrop.com (Mark Aurit <maurit>) (05/21/91)
In article <1991May17.211857.18269@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: >dBASE IV, the prefer not to. I sat in Larry Heimendinger's office and told >him to expect to lose the low-end dBASE user who only used Clipper as a >"packager" to compile their final dBASE III application. I believe that Ah well, it looks like Tom has seen my true colors. We actually write our code in dBASE III (not III+, too techie), just run clipper.exe against the main module (everthing else is referenced by a "do", none of them functions or external thingies), and link using PLINK. Right. A while back, you wrote of a Foxpro "attitude". Im sure this is a complete surprise to you, but there is a very real attitude associtated with Clipper programmers; your little statement above shows you to be a charter Clipperhead. Those people would not use dBASE because it is >seriously flawed as a language (not necessarily flawed as a tool however). I dont know how you define the dBASE language, but just because no one else has STATIC variables you find them all seriously flawed. I tend to define a language based on its ability to perform a task, not its perceived technical excellence. IMHO a good language makes the underlying architecture TOTALLY transparent to the developer - obviously Nantucket and I differ in this philosophy. >BTW, the sales figures for Clipper completely counter your hypothesis that >sales are waining. Personally I don't care what product anybody uses but >I don't like people to base their decisions on misleading information. Nor do I. I *very* seriously doubt these sales figures. Ive certainly read letters of people saying they were leaving the Clipper fold, and have difficulty conceiving what someone would buy a product that reference journals, magazines, and the internet said was buggy. Ill bet Nantucket was merely counting upgrades, not an uncommon practice in the industry. Mark
tmkk@uiuc.edu (K. Khan) (05/21/91)
In article <1991May17.211857.18269@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: > >Nantucket isn't blind, their development group aren't incapable of writing >dBASE IV, the prefer not to. I sat in Larry Heimendinger's office and told >him to expect to lose the low-end dBASE user who only used Clipper as a >"packager" to compile their final dBASE III application. I believe that >they will gain from the top end however, the programmers who could write the >app in C or Pascal but for various reasons (usually productivity) they will >choose to use Clipper now. I hate to tell you this, but Nantucket might just lose BOTH ends. I programmed in C many years before I ever wrote one line of Clipper code. I confess, I liked the C-like features of Clipper 5.0, and I use them extensively in my applications, but all that means nothing if the application which results is unstable. If I had my druthers, I would write everything in C and use the Paradox engine or some other database function library, perhaps along with some sort of CASE tool. This may be where the "high-end" programmers will end up.
tmkk@uiuc.edu (K. Khan) (05/21/91)
In article <1991May17.213946.18478@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: > >Thanks but I don't worship software, I use it. I use Clipper because it >solves my problems. I don't understand your delay "you'll move along as >soon as possible", move today, I would, if it were my decision. >purchase Borland's C++ Got it, thanks. Great package, BTW. I can take a program I wrote in Turbo C++ 1.0 (which runs fine), compile it under BC++ 2.0, and IT RUNS WITHOUT CRASHING. This is more than I can say for my Clipper program under the same circumstances. :-(
tleylan@pegasus.com (Tom Leylan) (05/22/91)
In article <24677@gremlin.nrtc.northrop.com> maurit@nrtc.nrtc.northrop.com (Mark Aurit) writes: > Ah well, it looks like Tom has seen my true colors. We actually write our >code in dBASE III (not III+, too techie), just run clipper.exe against the >main module (everthing else is referenced by a "do", none of them functions >or external thingies), and link using PLINK. Right. A while back, you wrote >of a Foxpro "attitude". Im sure this is a complete surprise to you, but there >is a very real attitude associtated with Clipper programmers; your little >statement above shows you to be a charter Clipperhead. > > I dont know how you define the dBASE language, but just because no >one else has STATIC variables you find them all seriously flawed. I tend >to define a language based on its ability to perform a task, not its >perceived technical excellence. IMHO a good language makes the underlying >architecture TOTALLY transparent to the developer - obviously Nantucket >and I differ in this philosophy. > > Nor do I. I *very* seriously doubt these sales figures. Ive certainly >read letters of people saying they were leaving the Clipper fold, and have >difficulty conceiving what someone would buy a product that reference >journals, magazines, and the internet said was buggy. Ill bet Nantucket >was merely counting upgrades, not an uncommon practice in the industry. > Mark, I'm at a loss why you think that people compiling dBASE code is an insult. The people who tell me that's basically what they do aren't insulted. I didn't know that you were qualified to judge what a "good language" is and before your kick your cubicle wall over, I thought I used the example of a jet that Northrop produces... if I said "IMHO a good jet should just let me fly it without looking at the gauges" would you just say "yeah" or would you question my understanding of jets ? Finally, the figures on sales are monitored independently, Softsel is a major distributor if you think they are in on the conspiracy then I cannot help you. You are quite simply, wrong. I also consider people like you as dangerous since you clearly have made up your mind and don't want facts to get in the way. It is of no benefit to anyone and most importantly not to you. If it's a game you want to play, you win. You get all the points and you're king of the hill. Yes you have the biggest male member. Oh... in case you're confused, I am not the Devil. Seeing as you can't distinguish reality from fiction. tom