Path: utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Amigix.library in progress... (was Re: Wildcards) Message-ID: Date: 22 Mar 90 17:56:23 GMT References: <102618@linus.UUCP> <5405@sugar.hackercorp.com> <5421@sugar.hackercorp.com> Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 126 In-Reply-To: peter@sugar.hackercorp.com's message of 19 Mar 90 14:16:57 GMT On 19 Mar 90 14:16:57 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Peter> In UNIX, you have to use several expressions: Peter> _*.[ch] _*.bak ck*.[ch] ck*.bak *test*.[ch] *test*.bak Deven> For csh users: {_,ck,*test}*.{[ch],bak} Deven> AmigaDOS's (x|y|z) syntax is directly analogous to csh's {x,y,z}. Peter> No, it isn't. In most cases it can be used the same way, but Peter> it's not identical. Peter> The csh {,} syntax is parsed before wildcarding is done. It's Peter> not really an alternation operator, like the Amiga (|) syntax Peter> supports. For example, expanding {core,*.o} will produce the Peter> string "core" whether or not there is a file matching that Peter> pattern. This can be useful, but it's not the same thing. That's true. You're right there. But, it's close enough for casual use. Peter> Also, as other people have pointed out, there's still no Peter> closure operator. How about all file names of the form cx Peter> followed by any number of digits? Peter> cx#(0|1|2|3|4|5|6|7|8|9) Can't. But, it IS nicer to be able to use "[0-9]" instead of "(0|1|2|3|4|5|6|7|8|9)"... Peter> Also, of course, it's not available in scripts. No reason why some Unix shell shouldn't allow full regexps for globbing. They just don't, usually. :-) [tradition, y'know.] Deven> Granted, AmigaDOS wildcards are flexible and powerful, but I Deven> find them less convenient to use than Unix wildcards, under Deven> most circumstances. Peter> Which is why my original message, that started this whole chain Peter> off, suggested using UNIX wildcards interactively and the more Peter> powerful Amiga wildcards in scripts. Well, I'd like to be able to use Unix wildcards in scripts too, unless I really need the closure or some such. Peter> That suggestion, by the way, was that *all* uses of wildcards Peter> be marked explicitly, and all arguments not marked as wildcards Peter> not be wildcarded. On the Amiga, for example, anything not Peter> enclosed in parentheses would be treated literally. I would like to be able to do "Join *.c wx#(y|z) ab#c.* to '*'" and have it work as expected. That is, first *.c is Unix semantics, second wx#(x|y) is AmigaDOS semantics, third ab#c.* is a combination, and the fourth (fifth) '*' is an escaped wildcard, so it would open the console as * normally does for BCPL... Peter> Anyway, Deven, get back to coding up Amigix & quit wasting time Peter> on News. :-> News isn't as hard as debugging... *sigh* Well, I starting building the shared library yesterday. Layed down all the structure and wrote a few functions. Used the sample.library from the 1.3 Includes & Autodocs RKM as a guide. Right now, the functions in the library [and this will change] are malloc(), calloc(), AllocMem() [not necessarily externally visible], and free(). The allocators call Exec's AllocMem for the actual block and for a MemList block to describe it. All memory allocated is tacked onto the task's tc_MemEntry list, which means it will be freed by RemTask when the task exits or if another task removes it. The sick Unix semantic of freeing a block of memory and still using it is supported. Implementation is as follows. The free() function will scan the tc_MemEntry list for a MemList with a single block with a matching address pointer. If it finds it, it does a Remove() and AddHead() on it, and sets the node type to -1 as a flag. When any of the memory functions is called (malloc(), calloc(), free()), it first calls a subroutine which checks the node type of the first node in the tc_MemEntry list of the task, and if it is -1, then it does a RemHead() and FreeEntry() on it. If the node type is not -1, it does nothing. In the event on an exit, then RemTask will still clean up the "freed" block, since it is still in the tc_MemEntry list, and RemTask doesn't care what the node types are. I have written these functions completely (in assembly) but I have not tested or debugged them yet. I still need to write other memory- related functions, such as realloc(), ReallocMem() [a tougher one; I may be forced to muck around in the system memory lists directly], bcopy(), bzero(), bswap() [nonstandard perhaps, but obvious, no?] and bcmp()... I need to add in the SwapMem functions I wrote recently. If I make AllocMem() externally visible as a library vector, [I probably will] then I will add a FreeMem() to go with it. For those sitting there thinking "Why?" -- this AllocMem is like the malloc() in that is saves the block in the tc_MemEntry structure for tracking, but allows a requirements argument. The FreeMem() will probably NOT free memory if it can't find the matching block in the tc_MemEntry list -- might be an invitation for a "freeing memory already freed" GURU. Why write bcopy() when there is exec.library CopyMem()? Because bcopy will handle arbitrary overlapping memory blocks, which CopyMem() does not. [might as well deal with that issue ONCE so you can later forget it and use bcopy without worrying about if the blocks overlap.] Bcopy() will be be efficient. Bzero() will simply zero a block of memory efficiently. bswap() will swap two blocks of memory efficiently, arbitrarily overlapping. Bcmp() will compare two blocks of memory, also efficiently. And so forth. Then I need to deal with the I/O (fd) structure, and functions for that, and I need to add the System Task, and _then_ I can attack fork() itself. Or maybe vfork() first. I'll half-implement exec(). (Initially.) It gets a little complex. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.