kent@swrinde.nde.swri.edu (Kent D. Polk) (04/19/91)
In article <1991Apr18.065847.8050@agate.berkeley.edu> navas@cory.Berkeley.EDU writes: >In article kent@swrinde.nde.swri.edu (Kent D. Polk) writes: >> >>Where does it exist? What exists that allows me to programmatically [...] >I absolutely positively don't want this thread to die. :) Thanks. >As far as I am concerned this is the extensibility that ARexx promised, but >which is really beyond the means for it to deliver. What many people don't understand is that AREXX, Exec, Intuition, and PPIPC messages can all co-exist with this environment. Arexx to provide the 'standard' external control mechanisms. >Why so many Amiga programmers continue to spit out boring MS-DOS/Mac-type >software is really beyond me. I was beginning to think I was alone... I almost get sick nowadays when I have to sit and listen to MSDOS programmers talk about their 'latest accomplishments' - doing stuff that is little more than a remake of stuff I was doing in PLM-80 on ISIS-II back in '79 or a remake of some Unix capability from the mid 80's!! It is really painful to see that they haven't really progressed that much in 12 years. >If there were 100hours to the day I'd be writing all of these. As it is, I >haven't included my favorite, because I am writing it... Mind discussing it or do are you trying to upstage 'Onion' ? :^) >This goes beyond data sharing -- dynamic or otherwise. More like a >program requesting certain functionality, and a SupremeServer trying to meet >those demands within the resources of the computer system at hand. Exactly. Snap-On Power Tools for Computers... >There are some technical difficulties for the general case. I will be >working rather hard all summer to find and fix as many as possible, so >STAY TUNED! Well then, how about an entertaining commercial? >> "What will happen to our memory now that we can keep it on paper?" > >>From experience :: it gets shredded. > see reference :: Iran Contra Hearings. And I though I had come up with a good oldie that would last a while. Went all the way back to the Greek philosophers for that one... You get my other 'oldie': ===================================================================== "Duct Tape is like the Force... It has a Light Side, a Dark Side, and it holds the Universe together" ===================================================================== Old motocrossers should remember this one, (or at least identify with it :^) Kent Polk - Southwest Research Institute - kent@swrinde.nde.swri.edu
navas@cory.Berkeley.EDU (David C. Navas) (04/23/91)
Copyright (C) 1991 by David C. Navas All Rights Reserved Rights to distribute all information herein are granted to Internet and connected nodes by the author, with the understanding that the rights to further distribute, sell or express said information contained within are reserved solely by said author. :) [I hate lawyer-speak] Sorry, but a bunch of this info is leading in the direction of some darn lucrative work for some, unnamed, programmer who is going to have a bunch of free time on his hands this summer -- and if things get organized well enough I'll try to publish something on this subject, so... [Actually, my work is rather orthogonal, but better not take any chances.] [Anyone know of a better way of expresing all that stupid stuff? I lost Mike Farren's fine example.] ---- In a previous article, Pete Goodeve writes to express why ARexx does not meet a specific set of opportunities, which I previosuly labelled "HyperFunctional." Now that's what I'm interested in. It's perfectly true that ARexx plus a whole lot of extra baggage and layers can give you similar things, but so could an Xserver -- and I ain't advocating that either for similar reasons. If you think of the evolution of computer science from a 21 year old's perspective (which I happen to do with relative ease :) ) in the following manner: Instruction Data | | Function Structure \ / \ / object-oriented integration of class/method/object One realizes that HyperLinks only seem to do half of the job: | HyperLinks ...that is, there's no equivalent definition for HyperFunctions! Seems to me to kludge that idea onto a text-only, macro-oriented *language* is a worse sham than adding object-oriented stuff to 'C'. ;) [Perhaps less upsetting would be to compare it to adding HyperLinks with 'grep'] We're not just talking adding interconnectivity between apps with ARexx ports. Let's talk about adding functionality to existing apps by run-time, even call-time, binding of program functions -- which would transparently allow those functions to work either within the thread of the process, or allow it to be exported to other programs. Without the programmer worrying about the details. Libraries *might* do for work within threads, but there are nasty problems with SetFunction()... ARexx *might* do for work between threads, but now we have two sets of interfaces to deal with -- low on the ZEN rating. The real problem with talking about this is that no reasonable user-interface spec has been created for the idea of Hyper-Functionality. What does it mean that a program *could* connect to a thesaurus if one was in the system? How does one anticipate that you might tell your WordProcessor to go and get a picture from VistPro [(C) HyperCube Engineering], which might be based on the imported data of some spreadsheet which held all the data for some raytracer -- which of course needs the abilities of an Interchange-clone.... What's the programmer's model for it? Sloughing off these details as a "user-problem" (as ARexx seems to do) is not only not acceptable (to me), but it's ignoring a realm of unexplored territory in the world of computer science. Not only that, it's a world which the Amiga is uniquely positioned to explore and exploit. Consider: the Amiga is the only popular system with a CPU-affordable inter-communicating environment. Workbench (tm of some branch of Commodore) is a better metaphor for taking a slew of "programs" and "building" a bigger, more powerful "program," than the desktop metaphor is. etc. etc. My dream is that when I add a spreadsheet to my system, *every* single program automatically has every ability that that spread-sheet has. I'm not sure how such things should be done, ARexx certainly has its place in that world. But it would be a pretty passive role -- certainly programming in REXX would, for the most part, be totally eliminated. Even worse is what the user-interface/metaphor would be. Personally I can see a rather large revolution/evolution on the way, and I wouldn't mind my favorite computer riding the wave... Make of all of this as you will -- maybe you think I should spend six weeks with a psychologist, maybe you think I'm Ted Nelson's half-cousin, but I'd love to see these concepts wrung for every idea contained therein. I happen to think that with the advent of ARexx, file notification, dynamic data exchange, etc. we are just starting to see the tip of an iceburg as big as Olympus Mons. As always, merely one man's inflated opinion. PS> Anyone know of a listing of Tymnet numbers? Later folks: David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
limonce@pilot.njin.net (Tom Limoncelli) (04/23/91)
In article <12952@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU (David C. Navas) writes: > We're not just talking adding interconnectivity between apps with ARexx > ports. Let's talk about adding functionality to existing apps by run-time, > even call-time, binding of program functions -- which would transparently Congrats! You've just re-invented Tcl. Well, not exactly, but I'd look up the Usenix Winter '90 Proceedings for an article on Tcl, and the following Winter conference proceedings has a followup article. Tcl might be what you are looking for. It's been ported to the Amiga already. It has a lot of good things in it. I'd almost prefer it over ARexx, except I'm not going to try to convince C-A to drop ARexx and pick up Tcl. :) Tom -- Tom Limoncelli tlimonce@drew.edu tlimonce@drew.bitnet 201-408-5389 Three witches making a potion. One asks, "A Liza Minnelli record, light beer, poppers, Frye boots; what's this spell for anyway?"
pete@violet.berkeley.edu (Pete Goodeve) (04/23/91)
In <Apr.23.01.10.46.1991.8069@pilot.njin.net> (23 Apr), Tom Limoncelli (limonce@pilot.njin.net) writes: > In article <12952@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU (David C. Navas) writes: > |> We're not just talking adding interconnectivity between apps with ARexx |> ports. Let's talk about adding functionality to existing apps by run-time, |> even call-time, binding of program functions -- which would transparently > > Congrats! You've just re-invented Tcl. Well, not exactly, [...] Uh...right. Not exactly (:-)) [I should let Dave respond -- he probably will anyway -- but I couldn't resist jumping in...] Both Dave and I are WELL aware of Tcl. We ought to be..: the author is right here in the EECS department at Berkeley! Dave has actually taken a class or two from him. I even ported the Tcl Interpreter myself to the Amiga, but only as a quick trial to see how it would work in this sort of context; I left the heavy stuff to the guys at Hackercorp. I was pleased though at how easily it DID port. > [......] It has a lot of good things in it. I'd almost prefer it > over ARexx, except I'm not going to try to convince C-A to drop ARexx > and pick up Tcl. :) I agree. And it's interesting that John Ousterhout is trying to do under Un*x the sort of thing that the Amiga is much more at home doing. However-- as I said -- it's not quite the hyperfunctionality we're after. Being still strictly a text-string-interpreter, just like ARexx, it isn't really dynamic enough at run-time to do the sort of things I believe Dave is thinking of. Like ARexx, it's easy to pass text commands around; hard to pass anything else (like data buffers). The only kind of run-time binding you can really do is to supply new text for responding to a certain event: OK for some applications -- not for all. (Often too slow, for one thing.) On the other hand, its embeddability and extensibility makes it rather atttractive as a possible component of a Hyperfunctional system. It's well worth keeping in mind. -- Pete --
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/25/91)
In article <MWM.91Apr23135328@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <1991Apr22.071413.22219@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > In <MWM.91Apr18120110@raven.pa.dec.com> (18 Apr), > Mike (My Watch Has Windows) Meyer (mwm@pa.dec.com) writes: > > In article <1991Apr18.065847.8050@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: > You SEE? ^^^ vvvv ... I KNEW it would happen... (:-)) > >What? You typed it in - and that's what it said. > ... My thoughts were that hyperfunctionality could be obtained through dynamically linked object modules. You would basically have a shared library that has the following calls: func = GetHyperFunc("display_bitmap") ... use function ... RelsHyperFunc(func) The scheme has the following advantages: (1) The object module associated with one or more functional names is independant of the calling code (i.e. can be third party), easily replacable and upgradable. (2) Programming overhead is minimal.. basically you just call GetHyperFunc(function_name) and it works. (3) The shared library searches for and finds the appropriate third party module containing the function and dynamically links it to the parent. (4) The module, being an object module, can reference other global variables and/or external routines (such as amiga.lib tags) that do not necessarily exist in the calling program. These external routines might in fact be other third party modules or .lib's (e.g. amiga.lib) that basically cause a recursive call to GetHyperFunc(). Thus, third party modules can depend on ALL OS calls being available to them. (5) STANDARD FUNCTIONS Third parties, the net, whoever, can define defacto standard functions such as 'IffToBitmap' with standardized arguments and standard return values, then others can improve on the initial offering by producing compatible modules that use the same call/return interface. In otherwords, a manual page for each function, like the autodocs. (6) FUNCTION ENTRY POINTS The shared library would require each third party module to have EITHER an assembly register based entry point for each interface function OR a stack based entry point. An assembly register entry point would begin: _asm_<function> A C stack entry point would begin: _stk_<function> THE LIBRARY WILL AUTOMATICALLY GENERATE CODE TAGS FOR PROGRAMS THAT REFERENCE THE _stk_ BASED FUNCTION IN A MODULE BUT WHERE THE MODULE ONLY DEFINES AN _asm_ BASED FUNCTION, AND VISE VERSA. In otherwords, the entry point type is INVISIBLE to any calling program. Other future entry point types can be defined. The associated .FD file that tells the library how to create a _stk_ interface from an _asm_ interface and vise versa MUST exist as const data in the object module based at a symbol named '_lib_fd', in otherwords, completely contained within the third party object module. The format will be extensible to allow more than _stk_ and _asm_ entry point types. (7) The procedure that generates code tags to convert the calling program's call format to the object module's call format is dynamically extensible as well. Procedures for _stk_ and _asm_ entry points (stk->asm and asm->stk) are built in to the shared library, but if new entry points are defined the shared library will itself search for third party functions that convert from one type to another. For example, a module that generates entry tags to convert from _fubar_ to _stk_ would be named: _stk_lib_convert_fubar_stk ^ \__________/ ^ ^ | | | convert to | | `--convert from | `- dedicated control name `- type of interface to the conversion procedure, must exist (using a _stk_ or _asm_ is safest since those are guarenteed to exist, being built into the shared library) The first key to all of this is 'THIRD PARTY' ... 'MIX AND MATCH' ... once you have mix-and-match capability at the USER LEVEL.. the user installs one third party module to do something but if some other third party comes up with a better one said user can install the better one without touching any of his application programs. The second key is complexity... through an extremely simple call you can interface to extremely complex modules, such as 'BitMapToPostScript' or something similar. The third key is in the dynamic linking capability. Note, I have written a shared library that does dynamic linking into a running program by searching for it's executable and symbol table, but in my opinion this particular capability -- linking to the calling process's symbols, is a BAD thing. In my opinion this is a loose, at least for now (dynamically linking object module's into the *calling* program and giving them access to the calling program's global's and other routines). First of all, RESIDENTed programs have no symbol table and no way to find the original executable. Secondly, the capability will lead to bad module implementations. Thirdly, there is no easy way to determine how to access a parent's existing variables.. for example, if the parent is using the small-data model (and there is no way to tell if it is without adding more complication), you are up the proverbial s*it creek. Also, the reentrantability of the third party modules is lost because you cannot assume the calling program will stick around (what happens if a second calling program wants to use the same module?) Finally, it adds incredible complexity to the shared library. It is MUCH easier for the shared library to do dynamic linking between OBJECT modules than it is to do dynamic linking to a pre-loaded and running executable whos symbol table might not be easily found. BUT DO NOT GET CONFUSED. I *AM* advocating dynamic linking BETWEEN third party modules. This is, in fact, how a module is able to call, say, OpenScreen()... it gets linked run time into another module that has the tag. You can even dynamically link into shared global variables that also exist in a given module. What I am NOT advocating is that the shared library be required to dynamically link an object module's unresolved references to the calling program's procedures. Not only that, but the interface specification still applies. If a module wants to call the C stack version of OpenScreen() but only a tag for the assembly register version exists, the shared library will generate the appropriate interface code to convert. The module itself would reference 'OpenScreen' normally, but a special default type would be encoded as a const data item, say called '_lib_deftype'. So, when all is said and done here is an example of a third party module, written in C: -------- cut -------- /* * default call type for calls that are not prepended with a type. */ const char lib_deftype[] = { "_stk_" }; /* * lib_fd defines the assembly and stack interface. Note that all * integer values in a stack interface are passed as longs. * * future extensions to other types or custom specifications may * be listed here using other ## constructions * * ##std standard (assembly & stack interface) * ##shared indicates the module functions are reentrant, otherwise * a duplicate of the module is made for each task calling * GetHyperFunc() for a function defined in this module. * * ## .. future constructions, any unknown construction is * ignored. * * note: var-args routines are supported with ..., but who knows * how we can standardize the call interface, mayabe just * require a stack only interface? */ const char lib_fd[] = { "##shared\n" "##std\n" "CalculateStuff(a,b,c)(D0,D1,D2)\n" "FuBarBletch(x)(A0)\n" }; /* * if no pre-tags are specified the lib_deftype[] is assumed as the * call format. If we were to specify a pretag, we would say something * like: asm_CalculateStuff(__asm register D0 a, register D1 b, ..) * etc, etc (not really SAS/C but you get the idea). * * This default action allows the source code to be easily portable, * especially of compiler options are used to automatically change * the default... for example, -mRR in DICE automatically registerizes * normal routines and the only change required to this source would * be to change lib_deftype[]. */ long CalculateStuff(a,b,c) long a, b, c; { } long FuBarBletch(x) long x; { ... OpenScreen() blah blah blah, etc... } -------- cut -------- That's it! That's the entire third party module! Easy to write, eh? So what do people think? Remember that libraries are also easy since they are simply object modules JOIN'd together. A third party could introduce a library of functions. Note that this specification does not impose any restrictions on what a module does or how it does it, you could easily encompass a streams system, message passing system, or other system simply by implementing them in your modules. You could, for example, provide the capability for AUTOMATIC cutting and pasting without the application even being aware of it! -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
pete@violet.berkeley.edu (Pete Goodeve) (04/25/91)
In <dillon.6935@overload.Berkeley.CA.US> (24 Apr), Matthew Dillon (dillon@overload.Berkeley.CA.US) writes: > > My thoughts were that hyperfunctionality could be obtained through > dynamically linked object modules. You would basically have a > shared library that has the following calls: > > func = GetHyperFunc("display_bitmap") > > ... use function ... > > RelsHyperFunc(func) > Hmm. Yes. I like it. [Not that I think it replaces or supersedes ppIPC, you understand... (:-)) All these various approaches have rather different areas of applicability, and independent, multitasked, processes will often be a better solution. I don't see Kent's system, or a MIDI net, say, being done with dynamic linking.] Some comments on its present stage, however: > (3) The shared library searches for and finds the appropriate > third party module containing the function and dynamically > links it to the parent. This would probably have to be something more elaborate than a "search path", so that the user could specify for a given parent module which version (there might be several on file) of a function was required. > (5) STANDARD FUNCTIONS > > Third parties, the net, whoever, can define defacto standard > functions such as 'IffToBitmap' with standardized arguments > and standard return values, then others can improve on the > initial offering by producing compatible modules that use > the same call/return interface. > I think you would need some way for the caller to specify the argument structure of a function as well, at the HyperFunc(..) point, to ensure that things matched properly. Someone is bound to want to change a function's spec at some point, and this is a sure path to calamity unless there is a check. The lib_fd entry already provides the template at the other end (or a lot of it anyhow). You might even want to extend this to some form of "Polymorphism" (a la Object Oriented Programming). The caller's declaration of the type of data that was to be passed would then be taken into account in selecting the appropriate matching function. This could help reduce an otherwise large namespace. > > The first key to all of this is 'THIRD PARTY' ... 'MIX AND MATCH' ... Ahh yes -- the magic keywords.(:-)) I've been using the same ones in my advocacy of ppIPC for quite a while... > > The third key is in the dynamic linking capability. Note, I have written > a shared library that does dynamic linking into a running program by > searching for it's executable and symbol table, but in my opinion > this particular capability -- linking to the calling process's symbols, > is a BAD thing. Agreed -- I didn't like THAT scheme much at all...(:-)) This one is a lot more promising. -- Pete --
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/26/91)
In article <1991Apr25.073105.23324@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: >In <dillon.6935@overload.Berkeley.CA.US> (24 Apr), >Matthew Dillon (dillon@overload.Berkeley.CA.US) writes: >> >> My thoughts were that hyperfunctionality could be obtained through >>.. >> (5) STANDARD FUNCTIONS >> >> Third parties, the net, whoever, can define defacto standard >> functions such as 'IffToBitmap' with standardized arguments >> and standard return values, then others can improve on the >> initial offering by producing compatible modules that use >> the same call/return interface. >> >I think you would need some way for the caller to specify the argument >structure of a function as well, at the HyperFunc(..) point, to ensure that >things matched properly. Someone is bound to want to change a function's >spec at some point, and this is a sure path to calamity unless there is a >check. The lib_fd entry already provides the template at the other end (or >a lot of it anyhow). Achk! right. I guess it makes sense to use 2.0 style tags, so HyperFunc(...) would be something like: HyperFunc(funcName, ...) And then there would some tags: HT_CCALL, 1, request C calling interface HT_ACALL, 1, request Assembly calling interface HT_CUSTOM, "_fub_", request some other interface Thus allowing for future extensions. >> The first key to all of this is 'THIRD PARTY' ... 'MIX AND MATCH' ... >Ahh yes -- the magic keywords.(:-)) I've been using the same ones in my >advocacy of ppIPC for quite a while... I think the main problem with all of these things is lack of ease of use (i.e. if the programmer has to do any work at all he winds up not using it). I've been seriously thinking of adding a new keyword to DICE to automate the process, something like: __dynamic void fubar(int, int); main() { ... fubar(1, 2); } Which would completely *HIDE* the HyperFunc() call. Under DICE this is easy, I can have the compiler generate autoinit and autoexit code to set up the appropriate vectors and silently make 'fubar' into a function pointer instead of a function proper. I do the same thing with libraries under DICE now.... you just call OpenWindow() and DICE automatically opens and closes the library for you, make things much easier to deal with and even more portable in the sense that the program source doesn't know it has to open library X to get function Y. I'd like the HyperFunc stuff to work the same way. And, as I mentioned, you can also completely hide cut & paste, your IPC, AREXX, whatever... inside these functions without the program having to do anything to get the 'features'. >> The third key is in the dynamic linking capability. Note, I have written >> a shared library that does dynamic linking into a running program by >> searching for it's executable and symbol table, but in my opinion >> this particular capability -- linking to the calling process's symbols, >> is a BAD thing. > >Agreed -- I didn't like THAT scheme much at all...(:-)) > >This one is a lot more promising. > -- Pete -- You and me both... it didn't look like a mistake then, but after trying to use it for a little while BOY was it a mistake! -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
davidm@uunet.UU.NET (David S. Masterson) (04/26/91)
>>>>> On 24 Apr 91 20:53:22 GMT, dillon@overload.Berkeley.CA.US (Matthew >>>>> Dillon) said: Matt> (5) STANDARD FUNCTIONS Matt> Third parties, the net, whoever, can define defacto standard Matt> functions such as 'IffToBitmap' with standardized arguments Matt> and standard return values, then others can improve on the Matt> initial offering by producing compatible modules that use Matt> the same call/return interface. Isn't the problem of defining standards the hard problem in this? -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
pete@violet.berkeley.edu (Pete Goodeve) (04/26/91)
In <803@tnc.UUCP> (25 Apr), GUY GARNETT (Wildstar) (m0154@tnc.UUCP) writes: > > It seems to me that a ARexx => ppIPC program (or even function > library) could be written fairly easily. > [.....] > The reverse should also be possible: a ppIPC => Arexx program. > > With these two modules, anything that understands Arexx could be > interfaced (with the appropriate Arexx script) to ppIPC. > I think so too. I've often toyed with the idea of doing some such, but have had too many other things to think about to actually DO anything. It would be cumbersome to have it manage ALL the options that ppIPC has, but it should suffice for most needs. Especially as I see ARexx's role as providing Command and Control functions rather than much data passing. Unlike Mike Meyer, I get a severe attack of the squirms when I think of using ARexx for data (structures) other than text strings. It's rather like returning to the bad old days of BASIC peeks and pokes: leaving manipulations with things like hex adddresses at the user-editable script level is NOT something I favour. However, it CAN be done if one is willing to accept the risk. (And it WOULD provide a convenient way of prototyping ppIPC stuff!) My goal with ppIPC, though, is to provide bulletproof applications for the (average) User. But please, I would love to see such an interface implemented. I suspect it will NEVER reach the top of my project stack (which monotonically increases) so go for it, somebody! -- Pete --
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (04/28/91)
This discussion is getting too narrowly focused. It's all very well to trumpet the wonders of plug and play alogrithms, but without an equal effort on standardizing the data and its description on which those algorithms act, there is going to be pitifully small product of this effort. In a 1974 weather project, what made the same sets of filters and graphing algoriths work on 122 quite different data streams was that they were all thrown into a very primative framework as a time stamped sequence of scaled values with an associated structure containing the scaling constants, ascii data stream names, and so on. How about a few words from the prinicpals of this discussion on what's to be done to make that set of algorithms process the very disparate data streams and structures without hiccups? Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
Lee_Robert_Willis@cup.portal.com (04/29/91)
I w >re: Hyper-functionality - > >I remember reading a SIGGRAPH article a few years back which >discussed writing applications as two cooperating co-programs: >a user-interface (client); and a 'nuts-and-bolts' (server) program. ... >If this paradigm (good word) was followed, and if software publishers >were sufficently motivated, they could include in the purchase package >the source code for the GUI program, and a programmers guide on >how to interface to the server. > >This allows owners to rewrite the GUI (how many times have >you wanted to do that?) without threatening the author's >profit margin. (He hasn't given away any secrets, since >all the good stuff is safely tucked away in the 'nuts-and-bolts'. > >And with the server interface fully documented, other parties >can build on to this application to write composite applications. > >(It's not dynamic linking, but I think its do-able with a lot >less fuss.) On second thought, all of the above could be accomplished without 'cooperating coprograms' simply by moving all the 'nuts and bolts' into a library. It's even more a lot less fuss. I really like this concept. It's implementable with current Amiga technology, doesn't require any new standards be written, and allows the purchaser of a software package to fully utilize the power of the package. (Assuming he can program) Lee Lee_Robert_Willis@cup.portal.com
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/29/91)
In article <1991Apr28.010519.14364@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >This discussion is getting too narrowly focused. It's all very well to >trumpet the wonders of plug and play alogrithms, but without an equal >effort on standardizing the data and its description on which those >algorithms act, there is going to be pitifully small product of this >effort. > >In a 1974 weather project, what made the same sets of filters and >.. I agree completely. My project, which is now working by the way!, does not impose any kind of standard in terms of the interface call names. Basically, the way it works in its current state is that when you write an object module, any variable that you wish to be exportable must begin with hyper_ ... in otherwords, an object module might declare: hyper_MyFuBar() { ... } But another module or program that uses this function would access it normally: main() { .. MyFuBar(); } The reason for the naming convention is to prevent a programmer's global variables from causing havoc with the system... you must explicitly declare which routines in an object module can be 'seen' from other object modules or calling programs, done by prefixing the variable or routine name with 'hyper_'. --- One plus with shared libraries is that the calling format is rigid and must be specified precisely. A dynamic object linker/loading scheme as I have working now, and will post soon, is no where near as rigid... it can't be if it is supposed to support mix-and-match. So the weight is really on the programmers who write object modules for the system to do a good job on their interface specification. The dynamic object linker/loader also has a greater probability of creating problems. When you mix libraries and object modules from different authors together debugging can be difficult! Despite the problems I think there is a definite nitch for this sort of thing due to its massive data hiding capabilities... you can define a functional interface to display an IFF picture, for example, and entirely hide said interface's IPC capabilities as well as most of its internals. With a normal amiga shared library this isn't so easy, not because you can't do it (you can), but because a shared library doesn't work well for single-function modules. Who is going to go to the hassle to write a shared library that contains only one function? >How about a few words from the prinicpals of this discussion on what's >to be done to make that set of algorithms process the very disparate >data streams and structures without hiccups? > >Kent, the man from xanth. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> Right now it's a programmer-eat-programmer situation. If one programmer comes up with an interface specification (i.e. routine name, arguments specification.. basically a MAN page) then implements it, and another programmer decides he doesn't like the way it was implemented, said other programmer can write his own object module with the same interface specifications and simply replace the original (as can any other user). I think the best way for this to proceed, especially for people who have far reaching formal interfaces they want to define, is to agree on a format for such proposals. I suggest a MAN page format such as those found in the autodocs, which already amply describe various library functions on a function by function basis. The only difference here is that you can also specify global variables. For example, if someone were to propose a general IPC interface he would do so by posting the autodocs style man pages. Say his IPC interface requires the use of a global semaphore to run atomic operations... A man page describing this might look something like this: foo.ipc/FooIpcSem foo.ipc/FooIpcSem NAME FooIpcSem - global shared semaphore structure for running atomic operations SYNOPSIS __dynamic struct SignalSemaphore FooIpcSem; STORAGE FUNCTION This semaphore may be used to ensure atomic access to IPC ports. All IPC interface calls use this semaphore internally and so you may use it externally (via ObtainSemaphore()) to synchronize atomic operations with all other IPC users. ^L __dynamic is a new storage qualifier I have added to DICE, BTW. For example: __dynamic int a; DICE would actually generate a pointer storage and silently indirect all references. Autoinit code would automatically load the pointer with the appropriate real-memory address retrieved by calling dynamic.library. All done transparently. I have decided to release another freeware version of DICE that includes this storage qualifier, probably in a month or so. Having compiler support for something like this makes the whole system MUCH easier to use! Otherwise you have to go about calling library routines and manually indirecting the results, checking error codes, etc... when all you really wanted to do was interface to a specific call. I should also mention that I have implemented auto_start capability for object modules... If an object module contains a specifically named routine, _auto_start(), that routine is automatically called by the library when it loads the module (a similar routine exists for when a module is to be unloaded). Thus, in the above example, the semaphore would come into existance already initialized and ready for use. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/29/91)
In article <dillon.7083@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <1991Apr28.010519.14364@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>This discussion is getting too narrowly focused. It's all very well to >>.. Oh, also to note: When I release this baby it will include a minimum of most standalone (i.e. reentrant) ANSI c.lib functions (e.g. sprintf, all the string functions, etc...) and an amiga.lib compatible link library, and another library called sharlibs.lib which provides automatic declaration & initialization of various library base variables. This ought to be enough to get most people started. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA