Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!f.gp.cs.cmu.edu!mjw From: mjw@f.gp.cs.cmu.edu.UUCP Newsgroups: comp.sys.amiga Subject: Kicking, dropping etc (was some ghastly mac thing) Message-ID: <1665@pt.cs.cmu.edu> Date: 12 May 88 19:14:24 GMT Sender: netnews@pt.cs.cmu.edu Reply-To: mjw@f.gp.cs.cmu.edu (Michael Witbrock) Organization: Carnegie-Mellon University, CS/RI Lines: 114 Posted: Thu May 12 15:14:24 1988 Keywords: All this kicking , dropping etc seems good. However, I don't think that I could stand compiling if I had to move libraries etc about to get things done. To make the workbench truly usable (which we have to do to make the amiga a machine which even kids and mac-users (not serious mac programmers) can use) we need to provide the functionality of shell scripts, whithout having to understand what a shell script is. A modest proposal (which might be bogus, since I haven't thought too deeply about picture based programming languages). Make a new type of workbench object : a factory. Factories contaoin (at least ) 3 types of objecxts: conveyor belts, loading bays, holding bins. Primitive tools : opject producers, object duplicators , compilers. Editors.... Smaller factories. Factories have loading bays : these should be object type specific (if you drop an object on a factory, it should go to the correct loading bay) . When the correct combination of things appears at the factory loading bays, the factory starts up. - Factories should also be able to be told how to order things (i.e files) I guess these things appear in holding bins. conveyor belts take things from loading bays, bins, and the outputs of primitive tools and subfactories to other subfactories, tools, or the factory output. Needless to say, factories can be shown as Icons, or expanded. Scenario: Compiling a program with a make factory: A make factory contains 2 sets of order forms: 1 set for c files, one set for lib files. These make the factory fetch (I guess some factories need a kick knob to start them if they aren't fed anything) the c files and lib files. As c files arrive in a holding bin, they are carried on converor belts to the compiler object, which consumes them (non destructively - the default) an dspits out some assembler source (e.g.) this goes to an assembler holding bin (to allow async compile and assem) whence they are conveyed to the assembler, which spits out the object file. Compiler switches are just that: the compiler icon should be able to show a control panel. Object files go to a holding bin on the linker. The linker has a list of files which must be there before starting. When they are there, it orders the correct libraries, and chews until it spits out a executable. Notes : I know that I haven't dealt with such things as 'written bits' but I believe that the analogy can extend to cover m,ost of the tthings one can do with a O.S. Sorry anbout the typos, too painful to correct through Dnet at 1200 baud. When I say compiler, I mean a object which encapsulates the compiler code. In fact, I imagine that sometimes, such an object will act by assembling a command line to a regular progtram on the basis of its inputs and switches, and then just spawn a cli to execute that command line. Notice how nicely this allows evenm the naive user to correctly use multitasking hrough a proiducer consumer model. This is in the spirit of looking at the problems that other systems solve, (in this case shell scripts and naive user fdriendlyness), and trying to solve the same problem better. -------------------- I think this has potential, and is quite doable - I'd be tempted to hack up a prototype myself if I wasn't goingg to be out of the country for a month. Let me know what you think. Michael -- Michael.Witbrock@cs.cmu.edu mjw@cs.cmu.edu \ US Mail: Michael Witbrock/ Dept of Computer Science \ Carnegie Mellon University/ Pittsburgh PA 15213-6890/ USA /\ Telephone : (412) 268 3621 [Office] (412) 441 1724 [Home] / \