bobb@elrond.CalComp.COM (Robert J. Boulanger) (08/20/88)
Hello: I'm looking for some information about ADA development systems from Verdix Corporation. Does anyone use or know anything about their products? I'm especially interested in their documentation. How good is it, and recommnedations do you make for improving it? How is Verdix's customer support and training? Thanks ahead of time for any information. -- Bob Boulanger bobb@elrond.calcomp.com (603)885-8072
baur@spp2.UUCP (Steven L. Baur) (08/23/88)
in article <2410@elrond.CalComp.COM>, bobb@elrond.CalComp.COM (Robert J. Boulanger) says: > I'm looking for some information about ADA development systems from > Verdix Corporation. > ... I'm especially interested in their documentation. How good > is it, and recommnedations do you make for improving it? The documentation on the whole is fair. I would like to see more details on how the implementation is done (because of so many potentially expensive features), and more details on available libraries would be nice too. All run time libraries are delivered in source code, and that is basically all the documentation you get. > How is > Verdix's customer support and training? Customer support is weak at best. They answer the phone rarely, and are not too terribly helpful. There is hope though. The last time I dealt with customer support, they spent a good deal of time looking at my problem, and responded formally with written up bug reports. What will happen next, I don't know. Customer training? If there exists such a beast I have never heard of it. Currently there exist many problems with verdix ada. First and foremost is the release of VADS 5.5 has been suspended because generics do not work, and the optimizer produces incorrect code. We bought 5.5 many months ago (at least January I believe), and still have not received the real 5.5. There exist many situations where use of NFS file systems completely confuses the compiler such that it thinks that nothing is up to date (this can be fixed by touch'ing the objects, but is ugly). A.make is easily confused into thinking there are circular dependencies when there aren't. (Since VADS does not produce .o's in any kind of simple fashion, the use of make(1) is largely precluded). A.pr crashes when it sees a form feed. Verdix ada prints an error message when it sees a 'pragma page'. Earlier versions are worse. Verdix 5.4.1 (the last major release before 5.5) handled generics better, but the run time system had no concept of critical regions of code. The interrupt handler could and did interrupt itself. The code generator sometimes produces bogus code for arrays that will generate an exception (bus error, segmentation violation ...) at run time. This has not occurred in any kind of a fashion that I can repeat, but the symptoms are such that the array name if treated as pointer, will result in correct code generated. The bug always occurs when compiling output from the Intermetrics ada-yacc which is used in all the Intermetrics tools. Summary: If you do not use optimization, and use generics in limited fashion, Verdix works fine. Steve -- ucbvax!trwrb!trwspp!spp2!baur
karl@grebyn.com (Karl A. Nyberg) (08/24/88)
(I would have thought the response to this question would have been more appropriate for mail, but I'll go with the flow...) In article <1395@spp2.UUCP> baur@spp2.UUCP (Steven L. Baur) writes: >in article <2410@elrond.CalComp.COM>, bobb@elrond.CalComp.COM (Robert J. Boulanger) says: >> I'm looking for some information about ADA development systems from >> Verdix Corporation. >> ... I'm especially interested in their documentation. How good >> is it, and recommendations do you make for improving it? ... >All run time libraries are delivered in source code, and that is basically all >the documentation you get. I'm running VADS 5.5c on VAX/ULTRIX 2.3, self-target. In the documentation that I received, Chapter 18, titled "Implementation Reference", includes such sections as Parameter Passing, Conversion and Deallocation, Process Stack Size, Interface Programming, File Formats, some fifteen pages on Run Time System, another fifteen on Memory Allocation Support in the VADS Runtime, Bit Manipulation Utilities, Semaphore Services, Task Control Services, and Exception Reporting. Maybe you didn't RTFM? :-) There's even a section titled "Configuring the VADS Run Time System" (17.4), which is very small for the self-target, but for the VAX/VMS -> 80386 and VAX/UNIX -> 68000 I recall that these sections run to literally dozens of pages (I don't have them with me at the moment, so I can't provide EXACT page counts). >> How is Verdix's customer support and training? >Customer support is weak at best. They answer the phone rarely, and are >not too terribly helpful. There is hope though. The last time I dealt with >customer support, they spent a good deal of time looking at my problem, and >responded formally with written up bug reports. What will happen next, I >don't know. My experience has been quite different. Every time I call I get through and generally get answers to my problems immediately. They have an extensive formal electronic support service for submitting and resolving bugs, a quarterly users newsletter, a PC running a bulletin board that contains the latest set of bugs and workarounds. There's even a users mailing list where some of us share our problems and solutions independent of their product support office. Compare that with the results I've gotten when trying to submit SPRs to DEC for their Ada under VMS - last time I tried that I was told the fix wouldn't make it in for two more releases - scheduled a year and a half out, and that there were no workarounds or any other solutions. >Customer training? If there exists such a beast I have never heard of it. Through an arrangement with Honeywell. Now you've heard about it. :-) :-) ... many listed "problems" deleted. I hope you've submitted formal bug reports on these. Complaining may be gratifying for the ego, but it's real hard for vendors to fix "Well, the compiler blew up, and I need a fix" without ACTUAL code. Generics are broken one way or another in just about every compiler I've ever used. Sure, maybe I get SPECIAL service, being as how I'm a Field Test & Beta Test Site, have a direct 19200 baud uucp connection to support reporting of bugs, etc., and used to work there. But "I pays my money and demands my service", and I'm pleased with the results. And yes, I STILL own stock in Verdix Corporation. -- Karl -- Karl A. Nyberg karl@grebyn.com, nyberg@ajpo.sei.cmu.edu Grebyn Corporation karl%grebyn.com@haven.umd.edu P. O. Box 1144 {decuac,haven}!grebyn!karl Vienna, VA 22180-1144 703-281-2194
dee@linus.UUCP (David E. Emery) (08/25/88)
Our experience with verdix and generics does not match that reported by baur. In particular, I personally think that Verdix has the best implementation of generics of any compiler I've used. It's not 100% perfect, but it's a lot better than most compilers. Verdix is 1 of only 2 compilers that that I know to implement code sharing of generic bodies. Furthermore, Verdix does NOT require that the body of a generic be compiled before its instantiation. It is possible to write mutually dependent generics (each generic instantiates the other) in Verdix, where most compilers will gag on such code. We're using Vads 5.5(j) on Sun-3. This release has its problems, but I don't consider generics an issue. Verdix customer support is spotty. They have some of the brightest customer people I've worked with, but these people are stretched fairly thin. The documentation has gotten much better with 5.5. A.make does have some problems, I avoid using it on very large projects. There has been a long delay between the time bugs get reported and isolated and the next release of the compiler that fixes the bug. On the other hand, the debugger is nice, although there are a few bugs and enhancements it could use, too. It's the easiest debugger I've used to debug tasks and generics (and tasks in generics, which is a very rough topic...) There have been some problems with the optimizer and particularly with floating point numbers, plus some particularly annoying bugs in static array initialization (mentioned by baur, but there's a fairly simple workaround) and variant records (which I think may have been fixed in 5.5j). I have no reservations about using Verdix for use on large projects in a Unix self-hosted environment. dave emery emery@mitre-bedford.arpa
sommar@enea.se (Erland Sommarskog) (08/27/88)
David E. Emery (dee@linus.UUCP) writes: >Verdix is 1 of only 2 compilers that that I know to implement code >sharing of generic bodies. Furthermore, Verdix does NOT require that >the body of a generic be compiled before its instantiation. It is >possible to write mutually dependent generics (each generic >instantiates the other) in Verdix, where most compilers will gag on >such code. We're having 5.41 of VADS here for VAX/4.3BSD, and I have written several error reports on VADS, and more than one of them was on generics. For instance, the debugger couldn't find the source for generic procudure within a generic package. Even more amazing was to find a generic package to be dependent of its instantiator! A good point is that if you change a generic body, instantiators doesn't get invalidated, like they do with DEC/Ada. But the recompilation takes a very long time. Another problem I have had with VADS are the DIANA files. They get BIG, and *eats* diskquota. (And a.rm doesn't clear away old instantiations.) To make things worse, units from other libraries are cached in a local directory. Tip if you plan to use VADS: Get your own disk, and don't have any quota. -- Erland Sommarskog ENEA Data, Stockholm - Why are Macintosh screens so small? sommar@enea.UUCP - Big Mac is registered by McDonald's.