denhaana@sol.uvic.ca (Albert Den Haan) (06/12/91)
Here are a couple of questions about (almost) related topics, one should be dear to almost all Amiga programmers and the other to users of GNU source on the amiga. First some background. When I program I try to make changes to my code in an incremental manner. That is, I try to get one module working before I work on the next in an attempt to keep the amount of information I HAVE to keep track of to a minimum. (there are other rationals for this sort of develop ment process but I wont get into that here :-) Of course this sort of process and the edit-test-debug cycle produces LOTS of different source code revisions and the problem I am worried about is keeping track of the revisions I make at each stage without maintaining archives of the full text of each revision. I know of two systems that automate this: SCCS and RCS. Both systems keep track of the revision history of a given set of files by storing the CHANGES in the files from revison to revision. This saves a great deal of disk space and allows more sophisticated analysis than 'It worked yesterday...'. These systems also help in multiprogrammer situations to avoid 'race' conditions where two (or more) programmers modify the same file in different ways at the same time. I am currently using RCS on UN*X and enjoying the facilities it has for determining the *actual* changes I make to a file that cause things to break. (This only happens to me right? :-) Also a look at the blunders you consistently make in developing applications can be very educational! Just make sure your boss doesent see them! Enough for the intro. I ftp'ed the RCS implementation from ab20 last week in hopes of getting the same facilities on my amiga. No such luck. I tried to run the binaries on my 2000HD (WB 1.3.2) and recieved various amusing crashes and gurus. Attempts to un-RCS the source provided in RCS format on a UN*X box to attempt a rebuild with SAS C 5.10 provided more interesting crashes. Are those binaries so broken that the later patch is *necessary* or is it me? Has anyone ported a later, working version of RCS (5.5 is the version I am using on UN*X) and would they mind posting it to comp.amiga.sources? Once I started using this system at school a lot of revision-related headaches 'went away' an I would LOVE to have the same system at home. My second question (how many is that so far, really?) is how does one go about porting a GNU program/system to the Amiga platform? The SAS C run-time library has quite a few UN*X 'compatible' functions but where does most of the effort appear? I wouldnt mind hearing from the people who have already ported stuff like GNUgrep, GNUawk, bison, flex and yes, GCC to hear what efforts are required for a good GNU port. Maybe a GNU.port.FAQ report/posting could be generated from the responses or a GNU.lib library built to save previous work for later porting efforts to prevent wheel re-inventing. Albert. P.S. how does one go about getting patch 5.10a (or whatever is latest) to SAS C anyway? e-mail me on this one. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Albert den Haan. (yes den Haan is my LAST name) denhaana@sanjuan.UVic.CA -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
shields@nexus.yorku.ca (Paul Shields) (06/12/91)
denhaana@sol.uvic.ca (Albert Den Haan) writes: > I ftp'ed the RCS implementation from ab20 >last week in hopes of getting the same facilities on my amiga. No such luck. I'd love a working RCS for Amiga. [...] >My second question (how many is that so far, really?) is how does one >go about porting a GNU program/system to the Amiga platform? The SAS C >run-time library has quite a few UN*X 'compatible' functions but where >does most of the effort appear? I haven't ported any Unixy/Gnuy stuff to Amiga. But I have tried porting such programs to MS-DOS. The issues are usually: - processor .. though 680x0-based Unix's are common, issues like 16/32 bit int's come into play. - compiler .. the choices seem to be SAS or Manx. Portable programs strictly conforming to ANSI C should not break the compiler, but they do anyway. Compiler bugs may break code in statements or macros that are fairly complex. This forces you to exercise all of the code to verify that it works the same under Amiga as Unix, so extensive testing is necessary. Good run-time debugging facilities are helpful, as is having a Unix machine around to compare behaviour. - operating system calls .. Amiga O/S calls are not very helpful. Semantics of the filesystem may differ enough to cause problems. Environment variables differ radically. Process creation mechanisms differ radically: fork(), exec(), system(), popen() may not be present and may be broken. Many programs (probably RCS, too) execute a fork() then exec() a Unix command in the child process. Managing something as simple in Unix as pipes can become a nightmare. - run-time libraries .. depend on what comes with the compiler and are by no means complete. this was the biggest factor porting to MS-DOS. standard functions and whole systems available in all Unix's were not present, like regexp, dbm, curses, and termcap. Several, like open(), ioctl(), had weirdly different semantics which didn't match Unix and broke instantly. - programming environment infrastructure.. the makefiles for the Unix programs often assume the existence of other programs which have not been ported, and assume the compiler has a standard set of switches. patch, unshar, uudecode, tar, compress, and ed often are necessary for applying patches. The software itself may require that "standard" commands (sh, ed, sed, grep, sort, awk, date, dc, wc, etc.) be present in order to work.. And it's vital that those must work exactly as expected. ...And now a complaint to the programming community, some of which doesn't seem to have this down yet: If you make an Amiga (or MS-DOS) port or workalike of a Gnu or Unix command which is a software building block, then you can't change its features. Otherwise the porting curve for other software is too steep. If you PD or sharware any such tool, PLEASE don't restrict its use, and PLEASE release source.. so that when somebody discovers that the program is broken, they don't have to come back to you to support it. thanks, Paul Shields shields@nexus.yorku.ca
mks@cbmvax.commodore.com (Michael Sinz) (06/12/91)
In article <1991Jun12.081252.11729@newshub.ccs.yorku.ca> shields@nexus.yorku.ca (Paul Shields) writes: >denhaana@sol.uvic.ca (Albert Den Haan) writes: >> I ftp'ed the RCS implementation from ab20 >>last week in hopes of getting the same facilities on my amiga. No such luck. > >I'd love a working RCS for Amiga. I am using RCS all of the time. (In fact, we all do at C=) Anyway, see Fish disk 451 for the updated files and Fish disks 281 and 282 for the original distribution. /----------------------------------------------------------------------\ | /// Michael Sinz - Amiga Software Engineer | | /// Operating System Development Group | | /// BIX: msinz UUNET: rutgers!cbmvax!mks | |\\\/// When people are free to do as they | | \XX/ please, they usually imitate each other. | \----------------------------------------------------------------------/
rsbx@cbmvax.commodore.com (Raymond S. Brand) (06/12/91)
In article <1991Jun11.224756.18225@sol.UVic.CA>, denhaana@sol.uvic.ca (Albert Den Haan) writes: > [lots-o-stuff deleted] > Enough for the intro. I ftp'ed the RCS implementation from ab20 > last week in hopes of getting the same facilities on my amiga. No such luck. > I tried to run the binaries on my 2000HD (WB 1.3.2) and recieved various > amusing crashes and gurus. Attempts to un-RCS the source provided in RCS format on a UN*X box to attempt a rebuild with SAS C 5.10 provided more interesting > crashes. Are those binaries so broken that the later patch is *necessary* or > is it me? Has anyone ported a later, working version of RCS (5.5 is the > version I am using on UN*X) and would they mind posting it to > comp.amiga.sources? Once I started using this system at school a lot of > revision-related headaches 'went away' an I would LOVE to have the same > system at home. Make sure that you have all the binaries for RCS (ci,co,diff,diff3,ident,ked, merge,rcs,rcsdiff,rcsmerge,rlog) in the RCS: directory; use the diff that comes with RCS. Make your stack at least 30000. If you still have problems, email or call me directly. > My second question (how many is that so far, really?) is how does one > go about porting a GNU program/system to the Amiga platform? The SAS C run-time By "becoming one with the code" that you want to port. Understand what it does and how it does it, then look at how to do it on an Amiga. > library has quite a few UN*X 'compatible' functions but where does most of the > effort appear? I wouldnt mind hearing from the people who have already ported > stuff like GNUgrep, GNUawk, bison, flex and yes, GCC to hear what efforts are > required for a good GNU port. Maybe a GNU.port.FAQ report/posting could be > generated from the responses or a GNU.lib library built to save previous work > for later porting efforts to prevent wheel re-inventing. > > Albert. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Albert den Haan. (yes den Haan is my LAST name) > denhaana@sanjuan.UVic.CA > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= rsbx ------------------------------------------------------------------------ Raymond S. Brand rsbx@cbmvax.commodore.com Commodore-Amiga Engineering ...!uunet!cbmvax!rsbx 1200 Wilson Drive (215)-431-9100 West Chester PA 19380 "Looking" ------------------------------------------------------------------------ What if Commodore held a DevCon and no Commodore engineers showed up? ------------------------------------------------------------------------
crash@ckctpa.UUCP (Frank J. Edwards) (06/15/91)
In article <1991Jun12.081252.11729@newshub.ccs.yorku.ca> shields@nexus.yorku.ca (Paul Shields) writes: >denhaana@sol.uvic.ca (Albert Den Haan) writes: >> I ftp'ed the RCS implementation from ab20 >>last week in hopes of getting the same facilities on my amiga. No such luck. > >I'd love a working RCS for Amiga. Hmmm. I have one which I use all the time under AmigaDOS -- both 1.3 and 2.0[24]. One thing though: make sure the stack is at least 25K and 40K would be better. It was posted to comp.binaries.amiga quite awhile ago; check archive sites for it. The binaries must have been posted during '89 or early '90 because there's an "unofficial rcs patch" in v90i134 of the c.sources.a archive. >[...] >I haven't ported any Unixy/Gnuy stuff to Amiga. But I have tried porting >such programs to MS-DOS. The issues are usually: Basically the same, with a couple of additions... > - compiler .. the choices seem to be SAS or Manx. Portable programs > strictly conforming to ANSI C should not break the compiler, but they > do anyway. Compiler bugs may break code in statements or macros that > are fairly complex. This forces you to exercise all of the code to > verify that it works the same under Amiga as Unix, so extensive testing > is necessary. Good run-time debugging facilities are helpful, as is > having a Unix machine around to compare behaviour. I have had to port a Un*x cpp program in order to run Un*x code through it to generate the ".i" (preprocessed) file and _THEN_ compile it with Lattice/Manx ("Lattice" because this was awhile ago :-) Definitely use the Commodore developer tools (it's worth becoming a developer _just_ to get some of the great tools those guys write), such as Enforcer (traps reads/writes to inviolate memory), MungWall (pads memory in front of and behind memory allocations/frees in an attempt to cause Enforcer hits if you use free'd memory), and others. > - operating system calls .. Amiga O/S calls are not very > helpful. Semantics of the filesystem may differ enough to cause > problems. Big point here: only one task can have a file open for write at a time. This was a big problem for the C News "expire" and "relaynews" programs, since they open a file then attempt to unlink (remove) it. Can't be done while the file is open... > Environment variables differ radically. Process > creation mechanisms differ radically: fork(), exec(), system(), popen() > may not be present and may be broken. Many programs (probably > RCS, too) execute a fork() then exec() a Unix command in the > child process. Managing something as simple in Unix as pipes can > become a nightmare. Yes and no. Most code does fork() immediately followed by exec(). This is easily arranged with a function call which has been #ifdef'd into place as a substitute for fork/exec. "system()" is the same way. And pipes are not all that tough using the 2.0-specific System() call. (In fact, I have some routines which emulate the popen/pclose functions under both 1.3 and 2.0, but 2.0 is the only one I understand! ;-) > - run-time libraries .. depend on what comes with the compiler and > are by no means complete. this was the biggest factor porting to > MS-DOS. standard functions and whole systems available in all Unix's > were not present, like regexp, dbm, curses, and termcap. This is a major problem. However, the C News "dbz" package can be used (almost) anywhere that dbm is used (big caveat regarding dbz "assumptions" so don't just presume plug'n'play). There are also regexp functions available in source form (I use the GNU package). Curses is another biggie -- I cheated on this one, but there are curses packages for the Amiga (all I've seen so far are SAS libraries) in beta test. If you need termcap instead, through out the code -- it's too old! The only portable cursor package is curses, and there are even some differences in implementations... > Several, > like open(), ioctl(), had weirdly different semantics which didn't > match Unix and broke instantly. See above. > - programming environment infrastructure.. the makefiles for the Unix > programs often assume the existence of other programs which have not > been ported, and assume the compiler has a standard set of switches. Yeah, this one's a real bummer. Especially the makefiles that call the shell with some fancy multi-line command sequence. Usually I comment out the original action(s) and hard code the equivalent steps, ie. ######################################################################## foo: bar cd ../include; for i in *.h; do mv $i `basename $i .H`.h; done ...becomes... foo: bar execute makefile.sh1 makefile.sh1 ---- cd /include list to t:xxx lformat "makefile.sh1b %s" execute t:xxx makefile.sh1b ---- ; Change the file given as first parameter to a different extension etc, etc. ######################################################################## > patch, unshar, uudecode, tar, compress, and ed often are necessary for > applying patches. No problem. There are implementations of patch, unshar, uu{en,de}code, tar, compress (mine does dynamic memory allocations ;-), and ed (called "ked" in the RCS package). > The software itself may require that "standard" > commands (sh, ed, sed, grep, sort, awk, date, dc, wc, etc.) be present > in order to work.. And it's vital that those must work exactly as > expected. Again, C News has these expectations because of all the shell scripts. I had to rewrite all the shell scripts into Execute scripts (and I'm still hearing about how they don't work!!). Most of these are available from various places: sed, grep (from SKsh), awk (GNU awk I ported myself), wc (from SKsh), and ed (from RCS). A couple of'em: "sort" and "dc" can be major problems. I don't port that code!! :-( Although sometimes I've found that the program uses sort or dc in only a very limited form. Actually, since there is a port of Perl for the Amiga, I was sorely tempted to use Perl for all of the C News scripts... But I didn't want to get into the position of having to provide such a large package just to get some simple control messages to work, etc. >...And now a complaint to the programming community, some of >which doesn't seem to have this down yet: > > If you make an Amiga (or MS-DOS) port or workalike of a Gnu or Unix > command which is a software building block, then you can't change > its features. Otherwise the porting curve for other software is > too steep. Ahhh, yes and no. If a feature is left out as being "too hard to implement", I don't mind -- if it's documented as such! But the statement above stands: don't change the way a feature works, or how it's invoked, without making it extremely plain that such-and-such has been done. > If you PD or sharware any such tool, PLEASE don't restrict its > use, and PLEASE release source... so that when somebody discovers > that the program is broken, they don't have to come back to you > to support it. I agree -- don't restrict its use. But concerning source... If it's going to be PD (or is GNU) then of course, but I think Shareware is another issue. When I released C News I did so as a service to the Amiga community. But my newsreader consisted of long hours spent (both by me and my beta testers -- thanks Larry! :-) trying to tune what the program did and how it functioned. I distributed the newsreader as shareware, without source, to secure the code. I didn't want someone complaining to me that his copy, which he got from Joe Schmoe, didn't work and would I please fix Joe's changes? The other constraint on source is the sheer bulk of it. Take the GNU C compiler, for instance. If someone ports it to the Amiga, then they have to make the source available under the terms of the GPL, but they don't have to provide it unless you ask for it and they can charge you for distribution/media/etc. C News wasn't covered by the GPL, and in fact the licensing _DID_NOT_ say that source had to be provided, but source was sent to Fred Fish anyway just to get the programming examples (and how to work around certain problems) out to the Amiga programming public. >thanks, >Paul Shields >shields@nexus.yorku.ca Your welcome. And I think a FAQ&A for porting code would be a good idea. Also, one site that kept track of the "ls-lR" listing of the Amiga archives would be great, ie. perhaps ab20 could keep on-line the volume listings for c.s.a, c.b.a, and perhaps the ones for c.s.{unix,misc,games} as well with a notation of which sites archive which newsgroups. Whew!! My ingers are tired (see ;-) so i'm going to sign off now. -- Frank J. Edwards | "I did make up my own mind -- there 2677 Arjay Court | simply WASN'T ANY OTHER choice!" Palm Harbor, FL 34684-4504 | -- Me Phone (813) 786-3675 (voice) | Only Amiga Makes It Possible...