Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: HYPER FUNCTIONALITY Message-ID: Date: 29 Apr 91 03:45:26 GMT References: <1991Apr25.073105.23324@agate.berkeley.edu> <1991Apr28.010519.14364@zorch.SF-Bay.ORG> Organization: Not an Organization Lines: 139 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. > 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