toma@tekgvs.LABS.TEK.COM (Tom Almy) (09/28/90)
Well, I got the update and certificates in the mail, and I never sent them any bug reports. I would guess all customers get this package free. What with the next major upgrade free as well and the half price coupon for another TopSpeed language, JPI seems to really be going all out to make ammends. Unfortunately the two bugs I had discovered in 1.04 (but did not report) are present in 1.06. I guess I'll call these in. Its a real shame they decided to go for multilanguage support -- that really messed things up. The compiler has gotten very complex to use, and the documentation for all the various options stinks. And am I the only one annoyed by the use of directory "include" for the Definition Modules? Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
GRANGERG@VTVM1.BITNET (Greg Granger) (09/29/90)
On Fri, 28 Sep 90 14:36:11 GMT Tom Almy said: >Well, I got the update and certificates in the mail, and I never sent >... > >Unfortunately the two bugs I had discovered in 1.04 (but did not report) >are present in 1.06. I guess I'll call these in. Its a real shame they >decided to go for multilanguage support -- that really messed things up. >The compiler has gotten very complex to use, and the documentation for >all the various options stinks. And am I the only one annoyed by the use >of directory "include" for the Definition Modules? > >Tom Almy >toma@tekgvs.labs.tek.com >Standard Disclaimers Apply I wholeheartedly agree. Yes, the directory name bugs me, but not nearly as much as all the _XXX variables or the Eval() functions (which would more appropiately be called the IamReallyAVoidCFunction()) or tracing all the heap allocation calls down to calloc & malloc calls in the CLB ('C'ommon Lib, HA!). The problem isn't that they decided on multi-lang support, it that they decided to market a C compiler (very buggy from what I've heard) and as a sideline maybe some other langs in a half-a**ed fashion. Maybe the 'next major release' will address these problems, but judging from the way they (JPI) defends the 'quality' of there product ("yes, it has a few small bugs, and the docs aren't good enough, but I don't know what everyone is so upset about") I wouldn't hold my breath. Now it would be great if they would start over at version 1.xx (which was great), or sell it to someone that would update it correctly, or (no chance but I can dream can't I) give the source to the PD (now that would be GREAT, but...) WARNING SOAPBOX MODE ON ************************************* We have to face facts the market is C. My own view on this is that in 10-20 years people will think of C the way they think of COBOL today; anyone with the slighest technical knowledge will loth working with it, but all the admin. types will say "it must be good there are 800 millions lines of code written in it". (people may realize (one day) that this is the same argument as "Hitler must have been right because millions of people followed him") What we need is more people in management roles with real hard technical knowledge and less managers who 'think' they have hard technical knowledge cause they had a computer course once in school in 1968. OK I FEEL BETTER NOW **************************************** Greg
Frank.Warren@f42.n161.z1.fidonet.org (Frank Warren) (10/06/90)
WARNING SOAPBOX MODE ON **********************************
Alas, I agree with everything you say, Greg. And I have to live
with lousy old C myself on a day to day basis. I sometimes wonder what
the moral difference is between programming in C and selling drugs to
school children for a living. Look at this; it's an egg. It's like
your CPU. Now break it open and lay it in a smoking frying pan to
bubble, boil, change colors and burn. This is your CPU on C code.
Think about it .
--
uucp: uunet!m2xenix!puddle!161!42!Frank.Warren
Internet: Frank.Warren@f42.n161.z1.fidonet.orgPeter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (10/07/90)
Hello Tom:
What two bugs have you found in 1.06b that were present in 1.04?
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgtoma@tekgvs.LABS.TEK.COM (Tom Almy) (10/09/90)
In article <184.270F4253@puddle.fidonet.org> Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) writes: >Hello Tom: > > What two bugs have you found in 1.06b that were present in 1.04? > (These bugs haven't been submitted to JPI, but I intend to do it now). The first bug is related to JPI's decision to allow multiple memory models like most C compilers. In the following program segment, no error is given on the call to Str.Length even though (using small model) the type of the actual and formal parameters don't match nor is code generated to properly pass the argument by value (assuming it were possible). Even ANSI C compilers don't screw this up; it is very unacceptable for a language like Modula-2. FROM Lib IMPORT CommandLine; FROM Str IMPORT Length; ... slen := Str.Length(CommandLine^); ========================================== I had been generating a "library" of object files, using a "Make" program and the command line compiler interface. I do this because there are many files, and there is no clean way to use the environment (I suppose a dummy program that includes all the modules would do it, but I don't consider that very clean). At any rate, when I specify processor options (80386, 80387 in my case) these options get included in the .obj file. When I compile my applications with the same options, the environment compiler does not insert these options in the .obj. The built-in make notices the discrepancy and forces recompilation of all the library files. A needless operation, and one that generates duplicate files since the new .obj's are placed in the current directory rather than that of the library obj's. ================================================ I found a third bug, which probably existed in the 1.04 version as well. I wanted to be able to redirect standard input from the command line (using the "<" operator). Using the IO.Rdxxx procedures no indication is produced at end of file, therefor while redirection works, programs tend to hang if they intend to continue reading until end of file. I attempted to get around the problem by using FIO.Rdxxx(StandardInput,...) which works fine reading from the keyboard (even EOF is indicated correctly) but when input is redirected always returns an EOF state. A casual inspection of the library source yielded no clues. =============================================== One irritant, especially with the C compatibility. You can turn on or off the capture of Control-Break, but you can't handle the interrupt with your own routine. An inspection of the library sources shows code to handle C style signals, but the capability is not passed to Modula-2. I'd like to be able to capture all errors to recover myself, and then not generate that error file. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply