rminnich@udel.EDU (Ron Minnich) (03/16/88)
One of the things that bothers me about the Amiga (and the guy who dumped his amiga for a Mac II) is that we tend to spend a lot of time on basic mechanisms while apple folks get to build stuff like Hypercard. Hypercard, like it or not (and i don't, really) is a significant innovation. Don't believe me? Read comp.sys.mac.hypercard and see what they're doing, and then think about doing the same things, *in the same amount of time*, on the amiga. I still feel that the amiga is potentially much better, and is much better in certain areas (like in all the things i'm interested in) but we have got to get off the ground in certain areas, and IPC is one. I really admire Bill Hawe's willingness to release the headers for AREXX. From what i have seen AREXX has been used to build real things involving real programs (ask Tom Rokicki). Some real nice sketches of IPC systems have been outlined here, but AREXX is real ... and i think we should concentrate on building systems using something that works, not trying to create another thing that works too, but that some of us might like better than AREXX. In other words we need people working on SYSTEMS using what we have, not continuing to build foundations. Just a thought. Now i gotta find some money to buy AREXX ... -- ron (rminnich@udel.edu)
sean@ms.uky.edu (Sean Casey) (03/18/88)
In article <1571@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes: >One of the things that bothers me about the Amiga (and the >guy who dumped his amiga for a Mac II) is that we tend to spend >a lot of time on basic mechanisms while apple folks get to build >stuff like Hypercard. Hypercard, like it or not (and i don't, really) is >a significant innovation. Don't believe me? Read comp.sys.mac.hypercard >and see what they're doing, and then think about doing the same things, >*in the same amount of time*, on the amiga. First of all, hypercard is no innovation. The ideas for hypercard have been around for forty (40) years. There are a number of precedents. I've been told that programming an amy for graphics and sound is much easier than programming a mac. So what gives? Why does Apple have hypercard and not Amiga? reason: Sales. Apple made a huge sales push and got a huge number of Macs into people's hands. It was a business machine that was easy to use. Point and click. The demand for software was phenomenal. Everyone knew it was going to be big. Commodore, on the other hand... why even discuss it? We all know what happened, or rather, what didn't. reason: Standardization. Apple has a thoroughly documented interface. No vendor has to make their software use the "MacIntosh Interface", but if they do people can easily adapt what they already know to using the program. Over time, since these interfaces are so similar, software writers have built libraries of routines for doing things in standard ways. This makes developing things like hypercard much much faster. Amiga is just barely catching up in this area, but it's not due to an effort by Commodore, but to an effort by the users. The users want a way to turn a running program into a small icon. Does commodore help? No, so instead two or three ways to do it are publically released by authors. Does anyone really know when the next version of dos is coming out, or what improvements will be made? reason: Market There are a huge number of Mac programmers out there, and a relatively small number of Amiga programmers. Money talks. I've played with hypercard, and I love it. What it represents is a lot of sweat by the author, and a successful computer by Apple. The funny thing is, the Mac started out as an inferior machine, but because of a wonderful effort by Apple, it made it into a lot of people's hands. The Amiga was just the opposite. Now, of course, the Amiga has been leapfrogged by the MacII. This doesn't bother me. But what happens when someone comes out with a cheap '020 Graphics workstation with Unix and far better graphics for about the price of an Amiga 2000? Looks like I'll be selling out, that's what. -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** The Empire Maniac {rutgers,uunet,cbosgd}!ukma!sean *** University of Kentucky / Lexington Kentucky / USA *** "Ludo... FRIEND!"
morgan@brambo.UUCP (Morgan W. Jones) (03/20/88)
In article <1571@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes: }we should concentrate on building systems using something that works, }not trying to create another thing that works too, but that some of }us might like better than AREXX. In other words we need people }working on SYSTEMS using what we have, not continuing to build foundations. And if everyone thought this way we'd all still be using CP/M, wouldn't we? }ron (rminnich@udel.edu) -- Morgan Jones - Bramalea Software Inc. morgan@brambo.UUCP ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan "These might not even be my opinions, let alone anyone else's."
rminnich@udel.EDU (Ron Minnich) (03/22/88)
In article <353@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes: >In article <1571@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes: >}In other words we need people >}working on SYSTEMS using what we have, not continuing to build foundations. >And if everyone thought this way we'd all still be using CP/M, >wouldn't we? You miss my point, or you have not been reading the discussions. I have seen (my count) five different IPC proposals roll by, and arguments about which is better for what reason, and so on. The amiga is to the point where we should not continue arguing about fundamentals, which a good working IPC is. We ought to be building systems that use an IPC that works, a la AmigaTeX and its use of ARexx. I have been messing with these machines since late '85 and it seems incredible that we still do not have an IPC standard! We need some stability in this area, and we don't need five different IPC standards, and it is probably too late to build a full-blown object-oriented system, even if we were sure we wanted it, which no one is. What do you recommend? I want to build some fun toys that use an existing IPC; I'm not interested in creating Yet Another IPC Standard. And there are a fair number of people in the same boat. Do you have something useful to say, or are you just going to complain? If the former, we can use your help! -- ron (rminnich@udel.edu)
peter@nuchat.UUCP (Peter da Silva) (03/25/88)
In article <1661@louie.udel.EDU>, rminnich@udel.EDU (Ron Minnich) writes: > The amiga > is to the point where we should not continue arguing about fundamentals, > which a good working IPC is. Gee, I brought this up back when AREXX came out: pointing out that the existing mechanisms for IPC (clipboards, devices, pipes, and plain message ports) were quite adequate. For the sort of thing you can use REXX for, I still can't see that they need work. > What do you recommend? I want to build some fun toys that > use an existing IPC; I'm not interested in creating Yet Another IPC > Standard. And there are a fair number of people in the same boat. So how about: (1) A library for clipboards that makes them as easy to use as files, or (2) A CLIP: device, that allows you to read and write clipboards from current programs. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (03/26/88)
In article <853@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes: > In article <1661@louie.udel.EDU>, rminnich@udel.EDU (Ron Minnich) writes: > > The amiga > > is to the point where we should not continue arguing about fundamentals, > > which a good working IPC is. > > Gee, I brought this up back when AREXX came out: pointing out that the > existing mechanisms for IPC (clipboards, devices, pipes, and plain message > ports) were quite adequate. For the sort of thing you can use REXX for, I > still can't see that they need work. Now wait a minute. ARexx is, first of all, an interpretive language processor, that just happens to understand the REXX language. Which means you can write standalone programs (like a calculator, or a grep-like thingie, etc.), and it will dutifully execute them for you, just like any other language processor. It's I/O *is* restricted to command-line-like input, and console-like output, or files (i.e., no builtin window support, etc), which is one of the things that keeps it small. You can, of course, develop your own shared libraries of any functions you want, as it's also extensible (via the library route). So if you want it to be able to "speak" windows, gadgets, etc., that *can* be done. Might require a bit of work however ... :-) Second, ARexx just happens to know how to talk to "The System". That means it is ideal as a script processor. And you can use it's internal processing capability (i.e., the REXX language) to control the script's flow, and/or process data that may be generated as a result of invoking system commands. As a simple example of this, one of the fellows here (Bob), has AmiCron fire off an ARexx script when he wants to wake up. The script executes the "date" command, and parses it up and feeds it to the "say" command. Voila! Amy is an alarm clock. (BTW, the parsing is fairly extensive, so the thing will say "o'clock", and "twenty" rather than "two" "zero", etc.) Sure, you could write a dedicated program to do that, but doing it this way takes advantage of existing system commands and resources, and you get some- thing that works in a couple of hours, rather than in days. Third, ARexx is set up to talk to *any* program that wants to talk to it. And it does this via "plain message ports". Sure, the *format* of the messages is specialized, but that is true for all messages, to some extent. This makes ARexx an almost ideal macro processor for any application to use. No longer does a developer need to implement their own special macro facility, they can just add in some *simple* interface code (about 1.5K for the "dme" interface) and they have instant macros. And they get the processing power that the REXX language provides, just like in the system interface application above. Fourth, because ARexx is truly multitasking, and can handle an arbitrary number of "hosts" simultaneously, it can be used as the "hub" for application-to- application IPC. And the internal processing power of ARexx can perform data manipulations, format conversions, etc. inbetween them. So, for example, *if* Sculpt-3D and VideoScape3D both had the facilities in them to talk to ARexx (and had the necessary internal commands, naturally), they *could* exchange data, with neither of them being any the wiser about who "the other guy" was. Individually, they only need to talk to ARexx. Depending on the complexity, and quantity of data to be exchanged, one could have ARexx perform such data conversions, or use some user written (third party supplied ?) shared library functions, or even invoke yet a third standalone application to perform the processing. Fifth, the functions in those shared libraries can be made available to any application that wants to make use of them via the ARexx facility. Can you say, extensible applications? This can be a very powerful concept. Want a spelling checker inside your paint program? It may not make sense, but you could do it. All you need in the paint program is an ARexx interface, a way of "escaping" to an external command, and a means of specifying the data you want checked. Externally, you need ARexx, a shared library, and the dictionary (which could all be used by your word processor, spread sheet, and pagesetter). Oh yes, the "paint program" also needs to be able to detect and process the return codes ARexx sends back, so it can signal you when you make an error. I really fail to see how "clipboards, devices, and pipes" can provide these kinds of capabilities in a uniform and essentially transparent way (to the application, that is). As for "plain message ports", as I mentioned earlier, that's what ARexx *does* use. And ARexx is shipping now, and it works. For about $50. And it eat's up all of about 34K. So Ron, it's there now. It may not be the "best" way of doing IPC, nor "object oriented", or whatever, but it just might let you get on with the job of developing those nifty applications. Today. Standard disclaimer: I have no interest in ARexx, other than as a satisfied user of the product, etc. /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
peter@nuchat.UUCP (Peter da Silva) (03/30/88)
In article ... kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > Now wait a minute. ARexx is, first of all, an interpretive language processor, Bingo. AREXX is a script program that happens to include an IPC facility. > As a simple example of this, one of the fellows here (Bob), has AmiCron fire > off an ARexx script when he wants to wake up. The script executes the "date" > command, and parses it up and feeds it to the "say" command. Voila! Amy is > an alarm clock. (BTW, the parsing is fairly extensive, so the thing will say > "o'clock", and "twenty" rather than "two" "zero", etc.) I can already do this with pipes, etc... run date >pipe:datepipe run bawk ... <pipe:datepipe >pipe:bawkpipe say <pipe:bawkpipe It'd be nicer if I had a better scripting language than Execute, but the IPC part of it already exists... and I can use all my own UNIX tools. If bawk won't do it, icon will. Or I can gen up a program. Stick it all in sys:bin/ALARM and Execute it when the time comes. > Sure, you could write a dedicated program to do that, but doing it this way > takes advantage of existing system commands and resources, and you get some- > thing that works in a couple of hours, rather than in days. Just like writing UNIX shell scripts. Wow. Maybe if I had a UNIX-like shell that I could use for this... :->. > Third, ARexx is set up to talk to *any* program that wants to talk to it. And > it does this via "plain message ports". Sure, the *format* of the messages > is specialized, but that is true for all messages, to some extent. This makes > ARexx an almost ideal macro processor for any application to use. No longer > does a developer need to implement their own special macro facility, they can > just add in some *simple* interface code (about 1.5K for the "dme" interface) > and they have instant macros. And they get the processing power that the REXX > language provides, just like in the system interface application above. But all programs already know how to talk to pipes. The interface is already there. And you don't have to stick with a weird PL/1-like language. You have your choice of any number of weird C-like languages. > Fourth, because ARexx is truly multitasking, and can handle an arbitrary number > of "hosts" simultaneously, it can be used as the "hub" for application-to- > application IPC... Just like pipes. And they already have the "PIPE ports". > Fifth, the functions in those shared libraries can be made available to any > application that wants to make use of them via the ARexx facility. Just like pipes, except they already have the "PIPE ports". > I really fail to see how "clipboards, devices, and pipes" can provide these > kinds of capabilities in a uniform and essentially transparent way (to the > application, that is). As for "plain message ports", as I mentioned earlier, > that's what ARexx *does* use. AREXX uses plain message ports with an intermediary (can you say performance problems? I knew you could!). > And ARexx is shipping now, and it works. For about $50. And it eat's up all > of about 34K. And there are free PIPE:s, with source even. I asked "what about an AREXX:", and was met with silence. > So Ron, it's there now. It may not be the "best" way of doing IPC, nor > "object oriented", or whatever, but it just might let you get on with the > job of developing those nifty applications. Today. The name's "Peter". -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
jesup@pawl14.pawl.rpi.edu (Randell E. Jesup) (03/31/88)
In article <872@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >> Sure, you could write a dedicated program to do that, but doing it this way >> takes advantage of existing system commands and resources, and you get some- >> thing that works in a couple of hours, rather than in days. >Just like writing UNIX shell scripts. Wow. Maybe if I had a UNIX-like shell >that I could use for this... :->. Very similar to Unix shell-scripts, with one main difference: interactive ARexx script usage FROM other applications/programs. It's a pain to use shell scripts from WITHIN other programs. You can fire them off in a new shell, but it's tough to interact with them. ARexx isn't the only way to do these things, it just makes it easy, fast, and easy to debug. (Much the same reasons people use shell scripts instead of writing C programs for simple command-things. >But all programs already know how to talk to pipes. The interface is already >there. And you don't have to stick with a weird PL/1-like language. You have >your choice of any number of weird C-like languages. If you mean, "all programs invoked from CLI could theoretically read data from stdin (Input()), and send data to stdout (Output())", OK. But I suspect most programs (other than Unix filter/utility ports) ignore attempts to pass commands via stdin. Ever seen DPaint care about stdin? The point is, no matter what the program is, to make it work under external command you MUST include the ability in the design, whether it be parsing code for stdin, or ARexx port handling. If you don't like the Rexx language, write your own program that uses ARexx ports to control other programs in place of ARexx itself. >> Fifth, the functions in those shared libraries can be made available to any >> application that wants to make use of them via the ARexx facility. > >Just like pipes, except they already have the "PIPE ports". NO. Wrong. One cannot call code in a pipe. ARexx libraries are exec libraries that are accessed by calling them directly, like any other library. >AREXX uses plain message ports with an intermediary (can you say performance >problems? I knew you could!). You have a better way to pass a message? Remember, messages aren't copied, to send a message only requires a small number of instructions. >And there are free PIPE:s, with source even. I asked "what about an AREXX:", >and was met with silence. Most pipes out there are one-way devices. (I wrote a bidirectional one, but that doesn't matter. I never released it, and as of 1.3, it'll be a moot point.) Pipes don't provide an interactive envirionment. Why do you think Unix people invented (adopted) sockets and shared memory? What would you expect this hypothetical "Arexx:" to do, anyway?? I'm not suprised you got silence, as I can't figure out what you seem to be asking for. Pipes are useful things, but they are sorely lacking for many applications. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
hawes@dino.ulowell.edu (Bill Hawes) (04/02/88)
In his article peter@nuchat.UUCP (Peter da Silva) touts the use of pipes as an IPC mechanism ... Hey Peter, I do pipes, too ... As others have stated, just because you use one method for IPC doesn't preclude using others as well. In the WSHell you get piping support in the pure UNIX tradition of 3> program1 args | program2 args | ... ProgramN args yielding N concurrently-running processes with the expected input-output connections. It uses the pipe handler built into ConMan, which ensures multitasking-safe piping support by obtaining both pipe filehandles simultaneously (using a private packet called ACTION_DOUBLE.) Under WShell, you can mix-and-match executable programs with REXX macros in a piping system, so this allows you to use the REXX tracing/debugging facilities to monitor the pipe. Ever single-stepped a system of piped programs? As for a few specific comments: >Bingo. AREXX is a script program that happens to include an IPC facility. Communicating with external programs is hardly incidental to REXX. Of the three types of executable statements in the language --- assignments, instructions, and commands --- commands are reserved for communications with external programs. The semantics of a command are determined entirely by the external host. While it's true that in mainframe implementations of REXX these commands are not strictly "IPC", since there's no concept of a process (or even device-independent I/O), the Amiga implementation depends heavily on the system message-passing primitives. >AREXX uses plain message ports with an intermediary (can you say >performance problems? I knew you could!). The AREXX server is in the loop only to launch the macro program; it spawns a new process and forwards your invocation message as the startup. After that, the REXX program talks directly with your application, or any other AREXX host, or its STDIN and STDOUT streams, or anything else that you want it to do. And is that "intermediary" spelled as p-i-p-e-h-a-n-d-l-e-r? If it makes you more comfortable, you can think of a REXX program as an intelligent piping filter. >But all programs already know how to talk to pipes ... Don't I wish! Most of the AmigaDOS commands are at best marginally useful as filters. I'm getting comments back from WShell customers (many of whom haven't been exposed to piping before) asking for more examples of its uses. Maybe some of you with drawers full of filter programs could select your favorites and send them to me? >And there are free PIPE:s, with source even. Shucks, I guess not all the best things in life are free :-) I tried to price AREXX low enough so that people wouldn't hesitate to try it, and ignored advice to price it higher (from people who know lots more about marketing than I do.) If the price really is an obstacle, maybe we could take up a collection here to buy you a copy. I'll chip in the first $10. >I asked "what about an AREXX:", and was met with silence. Echoing Randell Jesup, I ask: what is an AREXX: device? If you can provide a useful spec, I'll consider writing it. Note that it would be trivial to define a DOS handler to invoke AREXX, but what would you gain? If you called it synchronously, you'd lose the ability to have the REXX program send commands to your application (since it would be WAITing the reply.) And if you intend to use it asynchronously, what's wrong with the present message-passing interface? Could you talk effectively to Intuition through an INTUITION: handler? I hope that you can be persuaded to give AREXX a try. From what you've shown of Browser, it sounds like adding an AREXX interface to it would be MIT**, and you'd end up with a fully-programmable file browser/launcher/ whatever, and you'd be able to talk to the other AREXX host programs. ** == Most Incredibly Trivial A side note>>> Apologies to any who may have tried to EMail me; I appear to be unmailable, though not unmalleable. My BIX and PLINK ids are WHAWES, and USnail is currently working rather well -- 2 days from the West coast. -- Bill Hawes
peter@nuchat.UUCP (Peter da Silva) (04/05/88)
In article <595@imagine.PAWL.RPI.EDU>, jesup@pawl14.pawl.rpi.edu.UUCP writes: > >But all programs already know how to talk to pipes. The interface is already > >there. And you don't have to stick with a weird PL/1-like language. You have > >your choice of any number of weird C-like languages. > If you mean, "all programs invoked from CLI could theoretically read > data from stdin (Input()), and send data to stdout (Output())", OK. But > I suspect most programs (other than Unix filter/utility ports) ignore attempts > to pass commands via stdin. Ever seen DPaint care about stdin? *I* don't care about stdin. In dPaint: select Save, and specify "PIPE:butcher". In butcher: select Load, and specify "PIPE:butcher". The programs talk to each other, pause when the PIPE: is full, and so on. Voila. IPC. > If you don't like the Rexx language, write your own program that uses > ARexx ports to control other programs in place of ARexx itself. Good idea. Something like this should be freely available to ship with everyone who wants to use REXX ports but doesn't want all their customers to have to buy REXX. This would solve my biggest complaint with REXX: you can't distribute it. > >> Fifth, the functions in those shared libraries can be made available to any > >> application that wants to make use of them via the ARexx facility. > >Just like pipes, except they already have the "PIPE ports". > NO. Wrong. One cannot call code in a pipe. ARexx libraries are > exec libraries that are accessed by calling them directly, like any other > library. Oops. You changed context on me, and I missed it. Explain how these shared libraries work (programmer interface, anyway). > >AREXX uses plain message ports with an intermediary (can you say performance > >problems? I knew you could!). > > You have a better way to pass a message? Remember, messages aren't > copied, to send a message only requires a small number of instructions. It takes extra context switches: Program sends message. Context switch. AREXX gets message. AREXX sends reply message. AREXX passes message on. Context switch. Final program gets message. Program replies. Context switch. AREXX gets reply. And at some point: Context switch. Original program gets reply from AREXX. If you don't have an intermediary: Program sends message. Context switch. Receiver gets message. If it's not a timing message, then: Receiver sends reply. Context switch. Originator gets reply. Twice as many context switches, best case. > >And there are free PIPE:s, with source even. I asked "what about an AREXX:", > >and was met with silence. > > Most pipes out there are one-way devices. (I wrote a bidirectional > one, but that doesn't matter. I never released it, and as of 1.3, it'll > be a moot point.) Pipes don't provide an interactive envirionment. Why do > you think Unix people invented (adopted) sockets and shared memory? Have you looked at System-V named pipes (FIFOs)? > What would you expect this hypothetical "Arexx:" to do, anyway?? > I'm not suprised you got silence, as I can't figure out what you seem to > be asking for. Open AREXX:function-name, giving a file handle. Send data to it, using DOS calls. Get replies back. Close fh. SO THAT PROGRAMS THAT DON'T KNOW FROM AREXX CAN USE IT. > Pipes are useful things, but they are sorely lacking for many > applications. True, but for a good many applications they're just fine. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
cmcmanis%pepper@Sun.COM (Chuck McManis) (04/06/88)
In article <885@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >*I* don't care about stdin. Good for you. >In dPaint: select Save, and specify "PIPE:butcher". In butcher: select Load, >and specify "PIPE:butcher". The programs talk to each other, pause when the >PIPE: is full, and so on. Voila. IPC. Try this too, make an execute file that has (not sure of the syntax here) .label: execute pipe:execute_me loop label execute that in a separate window, then in your favorite editor that has multiple buffers, use Save As pipe:execute_me as a command to execute the current buffer. >> If you don't like the Rexx language, write your own program that uses >> ARexx ports to control other programs in place of ARexx itself. > > Good idea. Something like this should be freely available to ship with > everyone who wants to use REXX ports but doesn't want all their customers > to have to buy REXX. This would solve my biggest complaint with REXX: you > can't distribute it. I've read most of the IPC stuff and this seems to be only identifiable problem with aREXX, basically, it isn't free. This is also why IPC will take *YEARS* to standardize, you see if a requirement is that the handler be free, then only people who are working in their spare time will write it, and if they are working in their spare time, they are usually not open to writing it the way *you* (the editorial 'you') want it written. Rather, they will write it they way they want it, it is their time after all. >It [aREXX] takes extra context switches: [stuff about how aREXX might work deleted] >If you don't have an intermediary: > Program sends message. > Context switch. > Receiver gets message. [more stuff edited out, this is the key anyway] In the above model, the the program sending the message either (uses the existing Message port facility (so there is no problem)) or be has all of the reliable message passing stuff built into it adding bulk to every program using IPC or it this not what you are suggesting? Even with the PIPE: example above you have to switch context into the pipe-handler. [Paraphrased : "What do you want out of aREXX?"] >SO THAT PROGRAMS THAT DON'T KNOW FROM AREXX CAN USE IT. Sorry Peter, there is simply no way that this will work. Programs *must* know about IPC to use it, in the case of the PIPE: device the programs already know about filesystem semantics and the pipe: device implements them, so programs that know about how to use the filesystem can use PIPE:. But what is painfully clear is that the filesystem semantics are insufficient for all of the things that people want to do. Think about the architecture of how programs communicate, or don't communicate. When filesystem semantics are sufficient, use pipes, when they aren't you need something more powerful. I think aREXX is a good stab at that more powerful facility. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
jesup@pawl21.pawl.rpi.edu (Randell E. Jesup) (04/07/88)
In article <885@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >In article <595@imagine.PAWL.RPI.EDU>, jesup@pawl14.pawl.rpi.edu.UUCP writes: >> If you mean, "all programs invoked from CLI could theoretically read >> data from stdin (Input()), and send data to stdout (Output())", OK. But >> I suspect most programs (other than Unix filter/utility ports) ignore attempts >> to pass commands via stdin. Ever seen DPaint care about stdin? >In dPaint: select Save, and specify "PIPE:butcher". In butcher: select Load, >and specify "PIPE:butcher". The programs talk to each other, pause when the >PIPE: is full, and so on. Voila. IPC. Data transfer, yes. Not what I would call IPC, however. You can't pass commands, it's an essentially one-way connection, and requires the user to do the work, etc, etc. >> If you don't like the Rexx language, write your own program that uses >> ARexx ports to control other programs in place of ARexx itself. >Good idea. Something like this should be freely available to ship with >everyone who wants to use REXX ports but doesn't want all their customers >to have to buy REXX. So what's stopping you? :-) >> NO. Wrong. One cannot call code in a pipe. ARexx libraries are >> exec libraries that are accessed by calling them directly, like any other >> library. >Oops. You changed context on me, and I missed it. Explain how these shared >libraries work (programmer interface, anyway). ARexx is implemented as a library of routines, any of which you can call the way you would other libraries. You can add external libraries of functions, which are callable by ARexx, and any other program. This allows ARexx macros to access a programs code, for example, without having the overhead of task switching, message passing, and command parsing. For example, a graphics program might put most of it's low-level primitives into a library, which ARexx (and others) could then call directly, instead of having to request the graphics program to do the operation and return the result. The only real addition to a standard library is a 'query' entrypoint in the library that matches names of routines to specific library entries. >> You have a better way to pass a message? Remember, messages aren't >> copied, to send a message only requires a small number of instructions. > >It takes extra context switches: [describes ARexx just being a switch between two tasks] >Twice as many context switches, best case. This is not what ARexx was designed for. If you don't want to use the macro language, why would you pass messages through it? ARexx is NOT a message-forwarder (though it could do it if you wanted it to). It is a programming language made for providing macros for other programs. It is also fairly powerful standalone. Now, if ARexx was performing some filtering operation, then having the messages run through ARexx makes sense. For your case (Arexx just passing them on), the programs could just send messages to each others Rexx ports. >> What would you expect this hypothetical "Arexx:" to do, anyway?? >> I'm not suprised you got silence, as I can't figure out what you seem to >> be asking for. > >Open AREXX:function-name, giving a file handle. >Send data to it, using DOS calls. >Get replies back. How? Reads, I assume? >Close fh. > >SO THAT PROGRAMS THAT DON'T KNOW FROM AREXX CAN USE IT. How? (Reads??) I suppose this would work, though you lose a lot of the functionality. What does this get you that a pipe doesn't for programs that aren't specifically coded to take advantage of this? (If they could be so coded, might as well code in an ARexx port instead, and get more functionality.) // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
peter@nuchat.UUCP (Peter da Silva) (04/08/88)
Look, I'm sure you're a phenomenal programmer, Bill. I'm ready to be amazed by your prowess, but I just can't get over the feeling that you don't really grok it. Putting pipes in a console handler? Defining an IPC protocol that's hooked up to a programming language? You seem to have a genius for mixing your metaphors. Did you have anything to do with the design of System V IPC? Have you ever heard of the paper "cat -v considered harmful"? I just find your programs frustrating. They're not Zen. They're so un-Amiga. Maybe it's just a matter of personal style, but I can't get over the feeling that we're not really working on the same machine. I'm not expressing myself very well, am I? Can you see what I'm getting at, though... In article <1954@dino.ulowell.edu>, hawes@dino.ulowell.edu (Bill Hawes) writes: > Don't I wish! Most of the AmigaDOS commands are at best marginally useful > as filters. I'm getting comments back from WShell customers (many of whom > haven't been exposed to piping before) asking for more examples of its uses. > Maybe some of you with drawers full of filter programs could select your > favorites and send them to me? That's why you want pipes to be something apart from ConMan. Then you can have your shell build its pipelines using that pipe device, and then used the fact that you have named pipes to hook in the programs that haven't been set up as filters. For gobs of pipable programs, just send them a few comp.sources.unix archives. > Shucks, I guess not all the best things in life are free :-) > I tried to price AREXX low enough so that people wouldn't hesitate to try > it, and ignored advice to price it higher (from people who know lots more > about marketing than I do.) If the price really is an obstacle, maybe we > could take up a collection here to buy you a copy. It's not the cost for a single copy. It's the fact that I can't distribute it with Browser. I can't even use it in any important way in a commercial program because it's not free. All I can do is provide a port and *hope* that people will react with "wow, that's neat" instead of "what the f*** is rexx". Now if it came with a dumb non-programmable version that I could just stick on the disk and use to talk directly to other programs, that'd be a different matter. But then if it did that I could also use other programming languages than REXX. Like icon, forth, etc... > >I asked "what about an AREXX:", and was met with silence. > > Echoing Randell Jesup, I ask: what is an AREXX: device? If you can provide > a useful spec, I'll consider writing it. Note that it would be trivial > to define a DOS handler to invoke AREXX, but what would you gain? Isolation and modularity. > If you > called it synchronously, you'd lose the ability to have the REXX program > send commands to your application (since it would be WAITing the reply.) You could send commands to REXX from programs that haven't been set up to deal with REXX. > And if you intend to use it asynchronously, what's wrong with the present > message-passing interface? Could you talk effectively to Intuition through > an INTUITION: handler? I already do. It's called CON:. You did a clone of it... don't you remember? One of the items on my stack of things to do when I have time is a CON: type handler that provides ANSI-style escape sequences to do things like: Menus. Function keys. Graphics (probably based on DEC Regis graphics). Changing the title bar. Adding a close box (that sends ^C). Scroll bars like the Bridge Card software's windows. And with a clipboard interface. That's the sort of thing that a CON: device needs. > I hope that you can be persuaded to give AREXX a try. From what you've > shown of Browser, it sounds like adding an AREXX interface to it would > be MIT**, and you'd end up with a fully-programmable file browser/launcher/ > whatever, and you'd be able to talk to the other AREXX host programs. I may do it. But I'm not sure that it'll do what I want. Have you seen what I'm planning for Browser? -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
peter@nuchat.UUCP (Peter da Silva) (04/09/88)
In article <627@imagine.PAWL.RPI.EDU>, jesup@pawl21.pawl.rpi.edu.UUCP writes: > >SO THAT PROGRAMS THAT DON'T KNOW FROM AREXX CAN USE IT. > How? (Reads??) I suppose this would work, though you lose a lot > of the functionality. What does this get you that a pipe doesn't for programs > that aren't specifically coded to take advantage of this? It gets you the ability to talk to other people's REXX ports. REXX sounds like a stranger beast all the time. Guess I'll have to get a copy of it just to see what the hell it is. It's certainly not the message passing program that I've been looking for, anyway. Hey! What happened to Amiga Xanadu? Anything new on that front lately? -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (04/11/88)
In article <48285@sun.uucp>, cmcmanis@pepper.UUCP writes: > In article <885@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > [Paraphrased : "What do you want out of aREXX?"] > >SO THAT PROGRAMS THAT DON'T KNOW FROM AREXX CAN USE IT. > > Sorry Peter, there is simply no way that this will work. Programs *must* > know about IPC to use it, in the case of the PIPE: device the programs > already know about filesystem semantics and the pipe: device implements > them, so programs that know about how to use the filesystem can use > PIPE:. How many programs out there *don't* know how to use the filesystem? > But what is painfully clear is that the filesystem semantics are > insufficient for all of the things that people want to do. But filesystem semantics are sufficient for *most* of the things people want to do. What they're not sufficient for is hard real-time stuff like (say) SMUS players or MIDI drivers. And even there the problem isn't the filesystem semantics, it's the filesystem speed. > Think about the architecture of how programs communicate, or don't > communicate. When filesystem semantics are sufficient, use pipes, when > they aren't you need something more powerful. I think aREXX is a good > stab at that more powerful facility. When I get my next royalty check I'll check it out. One problem with AREXX that nobody's really addressed yet is that it's not going to be usable by novices... people for whom the CLI is terra incognito. One outcome of this process should be something that can be used to sell Amigas to normal people. After all, that was one of the original goals. The patch-panel would be a good start. Particularly since it could also be used to sell UNIX... -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
lphillips@lpami.van-bc.UUCP (Larry Phillips) (04/11/88)
In <903@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes: > Putting pipes in a console handler? Defining an IPC protocol > that's hooked up to a programming language? You seem to have a genius for > mixing your metaphors. Well, I suppose pipes in a shell are a little different than the usual approach, but I don't see any great problem with it. In fact, _something_ should parse the pipe operator so that you don't have to muck about with redirection kludges, and can just use a nice, short pipe operator like... oh, let's use "|". As for an IPC protocol hooked to a programming language, there are two things I would mention. First, ARexx ports in a program do not necessarily need ARexx in order for another program to use them. If an editor has an ARexx interface that allows commands to be passed to it, any program can do a FindPort and send commands. It seems to me that the IPC protocol being spoken of on the net will do exactly the same thing. Second, allowing a programming language, especially a script/macro interpreter to do the calling (and to accept commands, data, or status back from a program) is a great way to make the facility even more powerful by allowing the user, rather than only the programmer, to specify how any two programs will interact > I just find your programs frustrating. They're not Zen. They're so un-Amiga. > Maybe it's just a matter of personal style, but I can't get over the feeling > that we're not really working on the same machine. Which programs of Bill's do you find frustrating? I know it isn't ARexx, since by your own admission, you don't have it. I use a combination of WShell, ARexx, ConMan, and PIP: to provide an extremely powerful and easy to use environment. UnAmiga? Last time I looked, script files were part of the Amiga, as were message ports, windows, command lines, and the ability to tailor applications to the needs of the user. When a programmer writes an application, he has no way of knowing what wild and wonderful thing a user might want to do with it. The author may not have even seen a program that I want to use in conjunction with it, yet if both contain sufficiently complete ARexx interfaces, I can use them together in ways that _I_ want to use them. > You could send commands to REXX from programs that haven't been set up to > deal with REXX. The ARexx interface is well documented. All you need to do from any program is a FindPort, then start sending messages that conform to the interface spec. Of course with the type of IPC being discussed here recently, all you would have to do is a FindPort, then start sending messages that conform to the interface spec. > One of the items on my stack of things to do when I have time is a CON: > type handler that provides ANSI-style escape sequences to do things like: > > Menus. > Function keys. > Graphics (probably based on DEC Regis graphics). > Changing the title bar. > Adding a close box (that sends ^C). > Scroll bars like the Bridge Card software's windows. > > And with a clipboard interface. That's the sort of thing that a CON: device > needs. Sounds a lot like the things you can do with WShell and ARexx. You really should take a good look at it Peter. I'd be very interested in hearing your comments about it once you've used it. -larry Disclaimer - I have met and chatted with Bill Hawes briefly, and own ARexx and WShell. Beyond that, I have no connection with Bill. -- Janus? Well, look at it this way. If you squint a little, the J could be Amiga checkmark, and the rest of the word describes MsDos. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
cmcmanis%pepper@Sun.COM (Chuck McManis) (04/12/88)
In article <1814@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: [I'll assume for the moment that y'all are following this and it can be edited liberally :-)] >How many programs out there *don't* know how to use the filesystem? Well, take any program that speaks IFF to files. To correctly write IFF files you have to be able to seek back to the front of the file to store lengths and such. Not to useful with a pipe. >But filesystem semantics are sufficient for *most* of the things people >want to do. What they're not sufficient for is hard real-time stuff >like (say) SMUS players or MIDI drivers. And even there the problem isn't >the filesystem semantics, it's the filesystem speed. I disagree, but this is probably a religious issue and not worth the bandwidth debating. If you are going to be at the DevCon we can pick it up there. [I wrote :] "I think aREXX is a good stab at that more powerful facility." >When I get my next royalty check I'll check it out. > >One problem with AREXX that nobody's really addressed yet is that it's not >going to be usable by novices... people for whom the CLI is terra incognito. >One outcome of this process should be something that can be used to sell >Amigas to normal people. Here your ignorance is showing. I can understand your dislike of ARexx because it is not free, and I have no problem with that, but before you go off an make blanket statements like the one above I suggest you evaluate the product. I upgraded to TxED plus which comes with a 'demo' version of the Rexx server. TxED uses ARexx to implement macros and such. What is nice is that using these macros are just as easy as using macros in MaxiPlan or something, no excursion to the CLI is necessary, no novice hostile features at all. If you support ARexx in your program it *is* transparent to "normal people" they just think "Wow, what a great macro lanugage this product has." With ARexx and a slideshow program that has an ARexx port, one can produce an instant titling program. My favorite is going to be after I have XLisp modified to support ARexx, combined with MicroEMACS you suddenly have *real* emacs with a Lisp interpreter and everything. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
jesup@pawl2.pawl.rpi.edu (Randell E. Jesup) (04/13/88)
In article <1814@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >But filesystem semantics are sufficient for *most* of the things people >want to do. What they're not sufficient for is hard real-time stuff >like (say) SMUS players or MIDI drivers. And even there the problem isn't >the filesystem semantics, it's the filesystem speed. It's fairly obvious that you're still looking at Arexx as only a dataswitch. Acting as a dataswitch for Arexx is like driving a Ferrari in first gear: sure, you can do 60+, but what about the other 4 gears? >One problem with AREXX that nobody's really addressed yet is that it's not >going to be usable by novices... people for whom the CLI is terra incognito. >One outcome of this process should be something that can be used to sell >Amigas to normal people. Remember, one of the major users of Rexx in the IBM world is by secretaries, many of whom are programming-illiterate, and quite a few computer-barely-literate. It was designed to be simple for non-computer people to use. For example, the original Rexx book says that easy-to-remember constants should be chosen for limits, like 100 or 500 or 20, instead of 128 or 1024 or 31 or 511, so that a non-computer person can remember them. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
randy@bcsaic.UUCP (Randy Groves) (04/13/88)
In article <49063@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >produce an instant titling program. My favorite is going to be after >I have XLisp modified to support ARexx, combined with MicroEMACS you >suddenly have *real* emacs with a Lisp interpreter and everything. Yes!!! I'd buy ARexx in a minute if you had this going! (I'm thinking about it anyway). How much memory do you think you'd need to run all that and have a reasonable amount left over for work? Are we talking 'economy Lisp Machine' here? How far along is this project?? -- -randy groves - Boeing Advanced Technology Center UUCP: ..!uw-beaver!uw-june!bcsaic!randy USNail: Boeing Computer Services CSNET: randy@boeing.com PO Box 24346 M/S 7L-68 VOICE: (206)865-3424 Seattle, WA 98124
peter@sugar.UUCP (Peter da Silva) (04/14/88)
In article <49063@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > In article <1814@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >How many programs out there *don't* know how to use the filesystem? > Well, take any program that speaks IFF to files. To correctly write > IFF files you have to be able to seek back to the front of the file > to store lengths and such. Not to useful with a pipe. Well, you don't *have* to, but it'd be nice. That's a good point. > >One problem with AREXX that nobody's really addressed yet is that it's not > >going to be usable by novices... people for whom the CLI is terra incognito. Here I don't mean that you need to use the CLI, but that you need to be technically literate enough to deal with the CLI and write macros and stuff. It's not just a matter of clicking a bunch of icons. > >One outcome of this process should be something that can be used to sell > >Amigas to normal people. That is, people who go bananas over Hypercard. > Here your ignorance is showing. I can understand your dislike of ARexx > because it is not free, and I have no problem with that, but before you > go off an make blanket statements like the one above I suggest you > evaluate the product. I upgraded to TxED plus which comes with a 'demo' > version of the Rexx server. TxED uses ARexx to implement macros and such. A "demo" version of the Rexx server? That sounds like just what the doctor ordered. What's the extent of this demo version, and is it distributable? > What is nice is that using these macros are just as easy as using macros > in MaxiPlan or something, no excursion to the CLI is necessary, no novice > hostile features at all. For a lot of people macro language *are* hostile. That's the only point I was making here. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
peter@sugar.UUCP (Peter da Silva) (04/14/88)
In article ... lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: > Well, I suppose pipes in a shell are a little different than the usual > approach, but I don't see any great problem with it. In fact, _something_ > should parse the pipe operator so that you don't have to muck about with > redirection kludges, and can just use a nice, short pipe operator like... > oh, let's use "|". Well, that's not what I was talking about. I'm not saying that the shell shouldn't do that... I'm just saying that the actual pipe handler should not be an magic part of another program. Rather, it should be something that DOS formally knows about. Of course in the current version of ConMan it is, but I didn't know that... not having a recent copy. But I feel better know that I know that I'm not the only one who's gotten confused on this subject :->. > As for an IPC protocol hooked to a programming > language, there are two things I would mention. > First, ARexx ports in a program do not necessarily need ARexx in order for > another program to use them. If an editor has an ARexx interface that > allows commands to be passed to it, any program can do a FindPort and send > commands. OK, but does any program other than ARexx actually do that? And I thought that a program's AREXX port was supposed to have a unique number tagged onto the end of it, so how's FindPort supposed to find it (of course I could be totally confused about *this*). Remember, whatever we come up with has to be usable by non-programmers. > It seems to me that the IPC protocol being spoken of on the net > will do exactly the same thing. It will also allow you to define a common pool of tagged message types that programs can use or ignore as they see fit, rather like IFF. > Second, allowing a programming language, especially a script/macro > interpreter to do the calling (and to accept commands, data, or status back > from a program) is a great way to make the facility even more powerful by > allowing the user, rather than only the programmer, to specify how any two > programs will interact Fine, but it should be up to the user to decide what that language should be. > Which programs of Bill's do you find frustrating? ConMan. > > You could send commands to REXX from programs that haven't been set up to > > deal with REXX. > The ARexx interface is well documented. All you need to do from any program > is a FindPort, then start sending messages that conform to the interface > spec. Of course with the type of IPC being discussed here recently, all > you would have to do is a FindPort, then start sending messages that > conform to the interface spec. And it shares the same problem. You're confused again... or is it just that you don't see why I would want to interface an existing program to this... like, say, DeluxePaint. > > One of the items on my stack of things to do when I have time is a CON: > > type handler that provides ANSI-style escape sequences to do things like: > > Menus. > > Function keys. > > Graphics (probably based on DEC Regis graphics). > > Changing the title bar. > > Adding a close box (that sends ^C). > > Scroll bars like the Bridge Card software's windows. > > And with a clipboard interface. That's the sort of thing that a CON: device > > needs. > Sounds a lot like the things you can do with WShell and ARexx. Really? In a standard console window running UNIX-type CLI-only programs that haven't been Amiga-ized? Or remotely via a terminal program like Matt Dillon's DTerm that opens a console window to do its rendering? Amazing. Plug here for Matt's program. It's very Zen. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
peter@sugar.UUCP (Peter da Silva) (04/15/88)
In article .... jesup@pawl2.pawl.rpi.edu (Randell E. Jesup) writes: > It's fairly obvious that you're still looking at Arexx as only a > dataswitch. Acting as a dataswitch for Arexx is like driving a Ferrari in > first gear: sure, you can do 60+, but what about the other 4 gears? The problem is that what I'm looking for (and what started off this discussion) is a data switch. A method of arbitrating who gets messages and what those messages mean. And while we're pouring on the analogies, consider a many-bladed swiss army knife. I know I'm only using the screwdriver portion, and that the main blade is better than most of the alternative knifes floating around, but right now I'm trying to drive screws. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
cmcmanis%pepper@Sun.COM (Chuck McManis) (04/16/88)
In article <1826@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: |>A "demo" version of the Rexx server? That sounds like just what the doctor |>ordered. What's the extent of this demo version, and is it distributable? You will have to check with Bill Hawes, since MicroSmiths also sells ARexx as an option I suspect they have a deal with Bill. |>> What is nice is that using these macros are just as easy as using macros |>> in MaxiPlan or something, no excursion to the CLI is necessary, no novice |>> hostile features at all. |>For a lot of people macro language *are* hostile. That's the only point I was |>making here. I am reminded of the saying "Making something that any fool can use and only fools will use it." [Note this doesn't imply you are being foolish] It makes the point that at some point, it ceases to be productive to simplify something. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
lphillips@lpami.van-bc.UUCP (Larry Phillips) (04/17/88)
In <1831@sugar.UUCP>, Peter da Silva writes: >> [ some stuff from me about pipes in Conman being OK ] > Well, that's not what I was talking about. I'm not saying that the shell > shouldn't do that... I'm just saying that the actual pipe handler should > not be an magic part of another program. Rather, it should be something > that DOS formally knows about. Of course in the current version > of ConMan it is, but I didn't know that... not having a recent copy. > But I feel better know that I know that I'm not the only one who's gotten > confused on this subject :->. OK.. I go along with that. The most recent Conman is really quite nice. The biggest problem with pipes at this time is the lack of programs suitable as filters. With ARexx, they are easy to write (and to modify for special cases). 'head' and 'tee' are two that were included as samples on the WShell disk. >> First, ARexx ports in a program do not necessarily need ARexx in order for >> another program to use them. If an editor has an ARexx interface that >> allows commands to be passed to it, any program can do a FindPort and send >> commands. > OK, but does any program other than ARexx actually do that? And I thought > that a program's AREXX port was supposed to have a unique number tagged onto > the end of it, so how's FindPort supposed to find it (of course I could be > totally confused about *this*). Probably not at this time, but with the documentation provided, you can write programs that use an ARexx port in any program. FindPort can be used to find the port by name. As far as I can see, the name of the port is as stated in the program opening the port. There is a unique identifier mentioned, but sounds like it's part of a message packet in case a message port is being shared. > Remember, whatever we come up with has to be usable by non-programmers. Well, sort of... actually, ARexx programs and those programs employing an ARexx interface need to be usable by non-programmers. This is no different from the Amiga in general. Until software is written, only programmers use the machine. One thing though... many people are somewhere in between programmers and users. Given a simple, easy to use, interpreted language, there will be a lot of programs written that would otherwise not have been considered. (I wouldn't say they will all be top quality :-) ) >> It seems to me that the IPC protocol being spoken of on the net >> will do exactly the same thing. > It will also allow you to define a common pool of tagged message types that > programs can use or ignore as they see fit, rather like IFF. Yes, and ARexx would serve as a good base for such things. I don't know if I understand enough of the implications of the IPC being talked about, or the suitability of ARexx as part of this, but I would hope that any standard settled upon will be compatible with ARexx. I don't know of anyone using it who doesn't like it, and think that it will become somewhat of a standard, or as much of a standard as a commercial program can become. >> Second, allowing a programming language, especially a script/macro >> interpreter to do the calling (and to accept commands, data, or status back >> from a program) is a great way to make the facility even more powerful by >> allowing the user, rather than only the programmer, to specify how any two >> programs will interact > Fine, but it should be up to the user to decide what that language should be. ARexx just happens to have that facility, now, today, and works well. Someone could write a similar one using a language other than ARexx, or could write some sort of completely compatible language that uses existing ARexx conventions. One important thing to remember is that there are a number of cmmercial and non-commercial programs that offer an ARexx interface now, today, and that work well. Personally, unless a substitute offered a lot more, and in addition, had as much support in programs, I wouldn't be mnuch interested. >> The ARexx interface is well documented. All you need to do from any program >> is a FindPort, then start sending messages that conform to the interface >> spec. Of course with the type of IPC being discussed here recently, all >> you would have to do is a FindPort, then start sending messages that >> conform to the interface spec. > And it shares the same problem. You're confused again... or is it just that > you don't see why I would want to interface an existing program to this... > like, say, DeluxePaint. Perhaps I am confused, perhaps not. I can certainly see how you would like to interface an existing program, but the problem is that there are no mechanism in most existing programs for commanding them from another program. The only way I see to do this would be to use something like 'journal' or 'copilot' to drive the keyboard and mouse to make the program do what you need. As far as allowing programs to interact in a more general sense, I am all for it. I commented at a user group meeting that _I_ couldn't see a need to have Pro MIDI Studio, Dpaint, and TxED interact, but that if they all could interact, _someone_ would undoubtedly find a use for doing it. >>> One of the items on my stack of things to do when I have time is a CON: >>> type handler that provides ANSI-style escape sequences to do things like: >>> Menus. >>> Function keys. >>> Graphics (probably based on DEC Regis graphics). >>> Changing the title bar. >>> Adding a close box (that sends ^C). >>> Scroll bars like the Bridge Card software's windows. >>> And with a clipboard interface. That's the sort of thing that a CON: device >>> needs. >> Sounds a lot like the things you can do with WShell and ARexx. > Really? In a standard console window running UNIX-type CLI-only programs that > haven't been Amiga-ized? Or remotely via a terminal program like Matt > Dillon's DTerm that opens a console window to do its rendering? Amazing. Perhaps I have misunderstood your meaning. With ARexx, WShell, and Conman running, I have the ability to set the title bar in an amazing number of ways (all things that the prompt can have), open windows and write/read to/from them, and close a CLI with the close box provided. Other programs do a lot of things that you mention, and of course can be called from an ARexx program. The clipboard is supported (I'd have to dig for the details). I suspect you are thinking along the lines of extending 'Browser', and I commend your present efforts on and further development of that program. I do think though, that ARexx is not quite what you think it is, and look forward to hearing your comments after you've used it. >> Plug here for Matt's program. It's very Zen. I was never able to get DTerm to operate from scripts. It would not recognize incoming strings. Too bad, because I really like the idea of driving things with a state machine, and the script capabilities of STerm look awesome on paper. -larry -- Janus? Well, look at it this way. If you squint a little, the J could be Amiga checkmark, and the rest of the word describes MsDos. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+