paz@mimir.dmt.oz (Paul Zemancheff) (03/07/88)
There are a couple of bugs in this package of programs.
The first one is in the make file for ` rf.c '. The make file should include
termcap for the libraries to be used. Eg, LIBS = -lcurses -ltermcap. The
second problem seems to be two functions which are not part of our curses
library ( BSD 4.3 ). Namely, idlok() & setscrreg(), thus rf.c won't compile.
Finally, there are a couple of undefined variables in ` rolo.c '. If
any one has fix for these last two items please let know what they are.
paul.......
================================================================================
Paul Zemancheff PHONE: +61 3 487 9263
CSIRO Division of ACSNET or CSNET: paz@mimir.dmt.oz
Manufacturing Technology, ARPA: paz%mimir.dmt.oz@uunet.uu.net
Melbourne, Australia. UUCP: {uunet,ukc,mcvax}!munnari!mimir.dmt.oz!paz
================================================================================fmr@cwi.nl (Frank Rahmani) (03/08/88)
> > > There are a couple of bugs in this package of programs. > The first one is in the make file for ` rf.c '. The make file should include > termcap for the libraries to be used. Eg, LIBS = -lcurses -ltermcap. The > second problem seems to be two functions which are not part of our curses > library ( BSD 4.3 ). Namely, idlok() & setscrreg(), thus rf.c won't compile. Replace idlok by newwin and setscreg by subwin. Furthermore replace the lines reading X attron(A_REVERSE); by X standout(); and the lines reading X attroff(A_REVERSE); by X standend(); This works fine for me under BSD4.3. A pity there isn't yet an option to add entries to rf_data (or did I miss something??) > Finally, there are a couple of undefined variables in ` rolo.c '. If > any one has fix for these last two items please let know what they are. You're referring to quite another program here. There were so many different programs under this name that you should be specific as to which one you refer (they ALL compiled o.k. here). By the way does anybody know about a version of rolo ( or another adressbase) that lets you add a substantial amount of text under COMMENTS ? > > paul....... > ================================================================================ > Paul Zemancheff PHONE: +61 3 487 9263 > CSIRO Division of ACSNET or CSNET: paz@mimir.dmt.oz > Manufacturing Technology, ARPA: paz%mimir.dmt.oz@uunet.uu.net > Melbourne, Australia. UUCP: {uunet,ukc,mcvax}!munnari!mimir.dmt.oz!paz > ================================================================================ fmr@cwi.nl -- It is better never to have been born. But who among us has such luck?
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/08/88)
In article <1081@mimir.dmt.oz> paz@mimir.dmt.oz (Paul Zemancheff) writes: > > There are a couple of bugs in this package of programs. >The first one is in the make file for ` rf.c '. The make file should include >termcap for the libraries to be used. Eg, LIBS = -lcurses -ltermcap. The >second problem seems to be two functions which are not part of our curses >library ( BSD 4.3 ). Namely, idlok() & setscrreg(), thus rf.c won't compile. It sounds as though the options you are using are not correct for your system, as I have done it on SysV, Xenix and BSD without problems. I sure hope VMS works, too, because it's a useful program. For Xenix, V7 and BSD, I used option TERMCAP, and both curses and termcap libraries. On SysV the termlib is usually bundled with curses, so I used TERMLIB and just the curses library. Hope this helps. PS: our mailer won't have your address, so I'm posting this. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
dcon@ihlpe.ATT.COM (452is-Connet) (03/09/88)
In article <443@sering.cwi.nl> fmr@cwi.nl (Frank Rahmani) writes: >> library ( BSD 4.3 ). Namely, idlok() & setscrreg(), thus rf.c won't compile. >Replace idlok by newwin and setscreg by subwin. Furthermore replace the lines idlok != newwin and setscreg != subwin idlok(win,flag) If flag is enabled, curses will concider using hardware "insert/delete line" terminal features. If disabled, it will seldom use it. This option is always concidered. It needs to be enabled only if your application needs it, such as a screen editor. It tends to be annoying when used in applications where it isn't really needed. If it cannot be used, curses will redraw the changed lines. setscrreg(top,bot) wsetscrreg(win,top,bot) These allow a user to set a software scrolling region in a window. top and bot are line numbers of the top and bottom margin of the scrolling region. This has nothing to do with the terminals physical scrolling capability. Hope this helps. This is from the SVR3 curses documentation. David Connet ihnp4!ihlpe!dcon
larry@kitty.UUCP (Larry Lippman) (03/10/88)
In article <443@sering.cwi.nl>, fmr@cwi.nl (Frank Rahmani) writes: > ... > This works fine for me under BSD4.3. I'm glad someone made it BSD-compatible, insofar as the curses implementation is concerned. Unfortunately, neither myself nor anyone else in my organization had enough BSD experience to offer the correct BSD options. > A pity there isn't yet an option to > add entries to rf_data (or did I miss something??) Actually, most users prefer to simply edit the database file using vi or emacs. I do have a shell/awk script which inserts new entries in the database file (after verifying that no duplication exists), but since it was a quick hack and was not "idiot-proof", I elected not to include it with the comp.sources submission. It's quite simple to write a script using sed or awk for this purpose, and a script is indeed appropriate here since execution speed is not important for adding new entries. Modifying existing entries using a script is a little trickier, but not that big a deal (I find the entry to be modified and write it to a temp file, then I write the database less the modified entry to a second temp file; the temp file containing the single entry is modified using an invocation of vi, followed by appending it to the other temp file, which in turn overwrites the original database file. Since I wanted to keep rf(1L) "simple", I never felt like writing the C code necessary to write/edit/update the database file; this would probably require more code that the original rf.c module. Incidently, when I wrote rf(1L) in 1985, it was my first use of curses(3X) under SVR2. The program was an exercise which paid off well; properly using curses was all downhill after I understood what was necessary to write the program. <> Larry Lippman @ Recognition Research Corp., Clarence, New York <> UUCP: {allegra|ames|boulder|decvax|rutgers|watmath}!sunybcs!kitty!larry <> VOICE: 716/688-1231 {hplabs|ihnp4|mtune|utzoo|uunet}!/ <> FAX: 716/741-9635 {G1,G2,G3 modes} "Have you hugged your cat today?"
paz@mimir.dmt.oz (Paul Zemancheff) (03/18/88)
Has anyone out there managed to successfully compile `rolo' ?
I have not managed to do so. Compiling the program using Makefile.bsd produces
an error when combining all the modules near the end. I have one undefined
variable called " strchr " which occurs in a number of the source programs
including rolo.c, update.c & operatns.c. We are using BSD 4.3. Any suggestions
for a possible cure would be most welcome.
....paul
Paul Zemancheff PHONE: +61 3 487 9263
CSIRO Division of ACSNET or CSNET: paz@mimir.dmt.oz
Manufacturing Technology, ARPA: paz%mimir.dmt.oz@uunet.uu.net
Melbourne, Australia. UUCP: {uunet,ukc,mcvax}!munnari!mimir.dmt.oz!pazpaz@mimir.dmt.oz (Paul Zemancheff) (03/18/88)
Re: My previous news item. " strchr() " is a function, not a variable.
The code for this function does not appear ( at least I can't find it.) in any
of the sources for Rolodex. The question is, whether it should be in one of
the source files, or if it is expected be in one of the function libraries.
Anybody got any clues ?.
paul.....
Paul Zemancheff PHONE: +61 3 487 9263
CSIRO Division of ACSNET or CSNET: paz@mimir.dmt.oz
Manufacturing Technology, ARPA: paz%mimir.dmt.oz@uunet.uu.net
Melbourne, Australia. UUCP: {uunet,ukc,mcvax}!munnari!mimir.dmt.oz!pazkjk@pbhyf.UUCP (Ken Keirnan) (03/19/88)
In article <1094@mimir.dmt.oz> paz@mimir.dmt.oz (Paul Zemancheff) writes: > > Re: My previous news item. " strchr() " is a function, not a variable. >The code for this function does not appear ( at least I can't find it.) in any [ text deleted ] > paul..... Paul, the rolodex package was shipped with makefiles for several different systems. On your system, you should have moved (or copied) "Makefile.bsd" to "Makefile" before calling make. It sounds like you are using the system V makefile. I hope this helps. Ken Keirnan +----------------------------------------------------------------+ | Ken Keirnan Pacific Bell - Minicomputer Support Staff | +----------------------------------------------------------------+ | old {ames,ihnp4,lll-crg,dual,pyramid}!ptsfa!pbhyf!kjk | | new {ames,ihnp4,lll-crg,dual,pyramid}!pacbell!pbhyf!kjk | +----------------------------------------------------------------+
jsc@cblpn.ATT.COM (Jonathan Cassell) (03/19/88)
In article <1094@mimir.dmt.oz> paz@mimir.dmt.oz (Paul Zemancheff) writes: > > Re: My previous news item. " strchr() " is a function, not a variable. >The code for this function does not appear ( at least I can't find it.) in any >of the sources ... > >Paul Zemancheff PHONE: +61 3 487 9263 If you add "-Dstrchr=index" to your compile line, you will probably eliminate the problem. strchr() is functionally equivalent to index(), as is strrchr() to rindex(). Your libraries probably contain index() and rindex(). An irritating, but minor, BSD/ATT-BL inconsistency. jonathon cassell cblpn!jsc
stark@sbcs.sunysb.edu (Eugene Stark) (03/19/88)
In article <1093@mimir.dmt.oz> paz@mimir.dmt.oz (Paul Zemancheff) writes:
Has anyone out there managed to successfully compile `rolo' ?
Yes, I compiled it on BSD 4.3, but I had to make a slight hack to
the Makefile. In particular, I replaced the line
CFLAGS = -DBSD -DUNIX -DROLOLIB=$(ROLOLIB) $(TERMSTUFF) -I$(TOOLDIR) -g
by the line
CFLAGS = -DBSD -DUNIX -DROLOLIB=\"$(ROLOLIB)\" $(TERMSTUFF) -I$(TOOLDIR) -O -s
otherwise errors from the C compiler are reported during compilation.
Hope this helps.
Gene Stark
SUNY at Stony Brookgwyn@brl-smoke.ARPA (Doug Gwyn ) (03/20/88)
In article <1094@mimir.dmt.oz> paz@mimir.dmt.oz (Paul Zemancheff) writes: > Re: My previous news item. " strchr() " is a function, not a variable. >The code for this function does not appear ( at least I can't find it.) in any >of the sources for Rolodex. The question is, whether it should be in one of >the source files, or if it is expected be in one of the function libraries. strchr() is a standard C library function. If your implementation doesn't have it, perhaps it has index(), which is the same except for the function name. Also note that strrchr()'s obsolete equivalent is rindex().
paz@mimir.dmt.oz (Paul Zemancheff) (03/24/88)
I now have a working copy of Rolodex. The last question I posted about
this program produced numerous replies, so I guess we can consider the matter
closed for the time being.
paul.......
Paul Zemancheff PHONE: +61 3 487 9263
CSIRO Division of ACSNET or CSNET: paz@mimir.dmt.oz
Manufacturing Technology, ARPA: paz%mimir.dmt.oz@uunet.uu.net
Melbourne, Australia. UUCP: {uunet,ukc,mcvax}!munnari!mimir.dmt.oz!pazgautier@ai.cs.wisc.edu (Jorge Gautier) (03/25/88)
In article <557@cblpn.ATT.COM> jsc@cblpn.ATT.COM (Jonathan Cassell) writes: >If you add "-Dstrchr=index" to your compile line, you will probably >eliminate the problem... Nope: watch out for an "index()" function defined in the sources! --- Jorge Gautier @ Wisconsin, gautier@cs.wisc.edu "The fact that my internal arrangement differs from yours, doctor, pleases me without end."