Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!pyrdc!netsys!ames!amdahl!kim From: kim@amdahl.uts.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga Subject: Re: AmigaWorld: More ARexx compatible programs Message-ID: Date: 13 Oct 88 20:01:18 GMT Article-I.D.: amdahl.c1=Ln53awT1010e=46Y References: <8810121541.AA11344@cory.Berkeley.EDU> Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 64 In article <8810121541.AA11344@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > Frankly, I think 5K is too much space wasted to port ARexx, I am > doing much better with my own IPC mechanism. But then again, I'm the only > one using my own IPC mechanism so far (fan club of one) since it hasn't > been released yet. Welllll ... the current implementation of ARexx in DME adds only about 1.5K, not 5K. That could be slimmed down a bit if I removed some checking code that I really don't think is needed, now that I understand ARexx a little better. Also several hundred bytes could get cut if I didn't allow "recursive" macro calls. So it could be done in as little as 1K, or so, without too much loss of functionality. On the other hand, the current implementation is rather basic. For example, the interface is "one way" in that currently, DME must initiate the macro call. Having an ARexx program startup a copy of DME, and then tell it what to do isn't supported (yet). Not sure how much code that would take, as I just started thinking about possible implementations, but I would imagine it could be done in about 1K also. Less if I could share some of the existing interface code. We'll see ... A couple other things do need to be done to DME itself though to make the ARexx interface (or, I suspect, your own IPC mechanism, for that matter) more useful. First, better error/boundary-condition trapping and reporting of the internal DME commands needs to be done. The second thing, is to give ARexx macros the ability to interrogate DME "state" information (cursor position, insert/overstrike mode, tab settings, current char/word/line, beginning-of-file, end-of-file, etc.) These too would add some code. So, maybe 5K is a reasonable ballpark number for a "complete" interface, with full error checking, etc., but it *can* be done in considerably less. That was really the objective of this 1st attempt ... to see how easy it would be to add a basic ARexx interface to some existing code, that wasn't designed with ARexx in mind, and to do so with *minimal* changes to the original code. Was pretty simple, really ... BTW, I notice that the "moderator(s)" are finally posting v1.30 of DME, after many months. Too bad it's obsolete (and in a sense, a real waste of net.bandwidth), since Matt's added some exciting new features in v1.30c ... but I'll let him tell you about them! Sounds like he's added some more stuff beyond 1.30c ... I'll be interested to see what *your* IPC mechanism looks like, Matt! /kim P.S. For those that are interested, Bill Hawes has posted a package on BIX called "rvi" (REXX Variable Interface). It's supposed to allow an ARexx "host" program (such as DME) direct access to an ARexx program or macro's internal variables. I haven't looked at it yet, but it might be pretty useful for xfer of "state" info, etc. -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25