|
From: R.K. O. Ph.D. <rk...@ow...> - 2001-07-13 00:16:19
|
> > > The purpose of this latest version, was to fix all the known bugs > [more snippage] At least known by me. Sorry to say, I did not look at the SourceForge bug tracker items. I'm just used to looking at bugs submitted to this list. I'll have to figure out how to get SourceForge to email me when new bugs are submitted. I have noticed that I've left some documentation in a embarrassingly turbulent state, which I will clean up, but the code itself should be pretty good. > > Hello, Dr. Owen. > > First of all, it's great to hear from you -- it's been awhile and > the modules-interest list has been kinda quiet. Thanks for the > big update; I'll build and begin testing today. > > I posted a bug in the Sourceforge problem report area last week; > do those postings generate an email to you and/or Robert Minsk? > I thought to send a message to the list, but I thought it would > be redundant. I just noticed it now. However, there were no .version files in the download tar ball. If the problem persists, and it's not related to deep directories, then upload them again with the .version files. I'll try to fix it. > > > Now it comes to the heart of the matter. There have been some requests > > to fix modules to handle deep modulefile directories with regards > > to version files, etc.. > > [snip] > > I wish I had something intelligent to offer on this, but it's > so unnecessary in our usage of modules that it's a don't-care > to me... I wonder if any of the requestors of the feature might > be able to expand on their usage model so this lost soul could > better understand the need for these changes? I hate it when > my clue meter isn't registering... I like to group my modules into categories. For example, browsers/netscape/4.61, browsers/netscape/6.0, browsers/opera/4.0, etc. and what happens is that the .version files don't get read. Say browsers/netscape/.version points to 4.61 which is totally ignored and netscape/6.0 will be loaded if doing "module load browsers/netscape" > > [big snip] > > > However, to accomplish these changes, it will require rewriting a > > good portion of the locating module parts. And while I'm at it, I > > intend to make the code more object oriented to make the code easier > > to deal with. I think most everyone who has looked at the sources > > will agree that there are too many global variables, side effects, > > and special cases embedded in the code making the simplest of changes > > a potential catastrophe waiting to be triggered later. A potential > > windfall may be the ability to use other embedded interpretors > > besides Tcl (just a thought). > > If it might make the code more approachable for a (newbie) > programmer such as myself, I'd love to see it. Of all the > open source projects I've benefited from, modules is the one > that I'd most like to contribute to. We really could use someone to put up web pages up on modules.sourceforge.net. If I do it, then the pages will turn out rather bland. > > Best regards, > > - Leo Butler > > Thanks for the input, R.K. +-----------------------+----------------------------------+ | R.K.Owen,PhD | rk...@ow... (408)377-5373 | | KooZ Software | | | NERSC/LBNL | rk...@ne... (510)486-7556 | +-----------------------+----------------------------------+ |
