russ@wpg.UUCP (Russell Lawrence) (01/15/89)
In article <24897@sgi.SGI.COM>, scotth@harlie.SGI.COM (Scott Henry) writes: > > ... The manual entry for selsort() > is wrong. It shows the prototype as (I can't use italics): > > selsort(tnum,fldtbl,srtfunc) > int tnum, *fldtbl; > int (*functbl[])() = {selfunc,confunc,srtfunc,tagfunc}; > > the argument line should read: > > selsort(tnum,fldtbl,functbl) [In a followup posting, Scott explains that he's using 4.0 unify... not the 3.2 version that I'm using.] I checked my 3.2 manual and found that it's also incorrect! Interesting! I had completely failed to spot the error, but was nonetheless invoking the function with a pointer to functbl rather than selsort since the training examples in the reference manual do indicate the "proper" usuage. I say "proper usuage", although I'm not really convinced since my program continues to crash whenever it executes selsort(). To me, the proof of "proper usuage" is a program that works, and/or documentation that's clearcut and error-free. > I am still having problems with my application, but I _think_ they are now > not in selsort(). Good luck. I wouldn't be too sure of this. Since unify traps signals, I'm not getting a core file, but the stubs that I've buried in my program indicate that my culprit is definitely the selsort function and/or its arguments. If someone out there could send me a fragment of code that works, I'd really appreciate the good example. BTW, it's intriguing to me that unify progressed from 3.2 to 4.0 with the same wrong entry in the programmers reference manual. -- Russell Lawrence, WP Group, New Orleans (504) 456-0001 {uunet,killer}!wpg!russ
paik@ati.tis.llnl.gov (Yunki Paik) (01/16/89)
In article <1081@wpg.UUCP> russ@wpg.UUCP (Russell Lawrence) writes: > >I wouldn't be too sure of this. Since unify traps signals, I'm not getting >a core file, but the stubs that I've buried in my program indicate that >my culprit is definitely the selsort function and/or its arguments. > >If someone out there could send me a fragment of code that works, I'd >really appreciate the good example. > For many years I have used Unify's HLI, including selsort(), without problem. Selsort is one of the harder to understand calls, and requires careful reading of the manual and experimentation. Hope you give another try. As for example code, my clients would not like it. /yunki
ariel@lznh.UUCP (<10000>Ariel Aloni) (01/16/89)
In article <1081@wpg.UUCP> russ@wpg.UUCP (Russell Lawrence) writes: > >In article <24897@sgi.SGI.COM>, scotth@harlie.SGI.COM (Scott Henry) writes: >> >> ... The manual entry for selsort() >[ ... ] In my experience, the most stable library call is unisort(). You can do practically anything with it although it's sometimes a bit more expensive. Hope this helps, ariel -- Ariel A. Aloni att!lznh!ariel "Just because you are parnoid doesn't mean they are not after you"
jiii@visdc.UUCP (John E Van Deusen III) (01/18/89)
In article <1081@wpg.UUCP>, Russell Lawrence writes: > BTW, it's intriguing to me that unify progressed from 3.2 to 4.0 with > the same wrong entry in the programmers reference manual. Unify Corporation telephoned me a few years back and interviewed me for about forty-five minutes about my experience with their documentation. The interviewer kept saying, "Oh yes, that's been fixed in the 4.0 version of the documentation". I finally asked why I was being interviewed about the old documentation if the new version had already been written. He answered that they had fallen behind on that part of the project. == John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
ray@spca6.UUCP (ray) (01/18/89)
In article <1995@lznh.UUCP> ariel@lznh.UUCP (<10000>Ariel Aloni) writes: >In my experience, the most stable library call is unisort(). You can >do practically anything with it although it's sometimes a bit more >expensive. Just something every Unify HLI user should know, any call to unisort is will cause a fork() system call. This is implicit in the manual, but should really be brought to every one's attention. On most systems, the fork() will be a little more than just 'a bit more expensive' than a selsort(). In fact, one of our programmers had written a program that was spending 33% of it's time executing fork() for the unisort() calls he had coded. (I seriouly considered removing it from our copy of the library when his reply was "But, unisort is SOOOOOOOO easy to use!" AARRRRRGGGGGHHHH!) Learn to use selsort, it works!(at least in our copy of 3.2 and 4.0) = ray mit-eddie!uccba!spca6!ray
ariel@lznh.UUCP (<10000>Ariel Aloni) (01/19/89)
In article <300@spca6.UUCP> ray@spca6.UUCP (ray) writes: >Just something every Unify HLI user should know, any call to unisort is >will cause a fork() system call. This is implicit in the manual, but This is the first time i here this (shame :-). Can you clarify on the issue ? Is an exec* also involved ? (probably yes, and an exec is much more exepensive than a fork on most Unix sytems). The only thing that caught my eye in the manual is something about a "general sorting function ...". Do they mean sort(1) ? ariel -- Ariel A. Aloni att!lznh!ariel "Just because you are parnoid doesn't mean they are not after you"