Comments:

Flat Nested Threaded Embedded

Oldest First Newest First

Author	Thread:
Jon.Capps	Utility library opinion survey Posted: Thursday, April 22, 2004 10:55 AM (EST) I prefer a single workspace, but I realize it is not always practical.  However, it would be nice if the "DESCRIBE" variable in the workspace reflects the last update date and/or version.  The workspace should be named consistently - i.e. DavinTools or some such so that tool libs from various places can coexist; that way I can have them in one directory and remember where I got them.  That way I can get a new version and simply overlay the last version.    Speaking of distribution, are all the functions in the libraries locked?  When I use a library tool, I do it to save time.  If I can look at the code, I usually want to tinker a bit - thus defeating my original purpose.  Locking prevents this (for mere mortals), or do you have a tool that unlocks?
davin.church	Utility library opinion survey Posted: Thursday, April 22, 2004 2:43 PM (EST) Thanks.   When you download a large workspace like that, do you go through an read the entire DESCRIBE variable every time you download a new copy just so you can see anything that's new in the workspace?  And what about the serendipity of stumbling across a tool in one that you could use but didn't think existed?   Keeping up with tool documentation (and signifying what's new) is probably a bit easier with separate workspaces.  But then again it's more difficult to download several small workspaces than one large one.   No, I don't lock my libraries (and neither does anyone else that I know of).  That would defeat much of the purpose of having tool libraries.  Having APL code that does a job is better than having some compiled external program do the same thing, in part because you can open it up and make changes so it will work better for you.
Eric.Baelen	Utility library opinion survey Posted: Thursday, April 29, 2004 10:35 AM (EST) With improved speeds of connection, I think the larger collection (workspace) is justified.
anico	Utility library opinion survey Posted: Monday, May 03, 2004 1:15 PM (EST) My opinion is that purpose-specific workspaces are easier to use than mega-store type workspaces. Even if the workspace has only one function, putting in a workspace alone makes it easier to find.   Updating the same workspace over time as new tools of the same type become available, insures that the latest version is always available.   Thanks,
anico	Utility library opinion survey Posted: Monday, May 03, 2004 1:26 PM (EST) (2) A large workspace would be more usable is "groups" could be set up.   If you could copy just one "group" from the workspace, then separate workspaces wouldn't be necessary.   How about a Describe by Group.
davin.church	Utility library opinion survey Posted: Monday, May 03, 2004 1:51 PM (EST) Thanks anico, that's kinda the feeling I have.  It's not so much about the download time per se (most workspaces aren't all that big even on dial-ups), but more about the organizational & updating aspects.  I've taken a mixed approach in the past, where large collections like my DATES utilities are separated into their own workspace.  That way people will know generally what's in there and where to look when they want to find something.  And if something in a combined workspace is updated, how do you know if it's from one of the pieces you want or one of the pieces you don't care about?   But when you start splitting them up, you then have to decide how far to take that.  For an extreme example, I've got a small set of related one-liners out there (that probably everyone has) to delete (1) trailing blanks, (2) leading & trailing blanks, (3) extraneous blanks, and (4) all blanks.  So, do you go to the extreme where this constitutes a separate set of blank-removal utilities?  I'd think not.  So where in between that and everything-in-one-WS would you draw the line?
davin.church	Utility library opinion survey Posted: Monday, May 03, 2004 2:04 PM (EST) So without )GROUP, how do you propose to implement such groups?  I don't think "packages" are a good method for this sort of thing.  You can document them with group describe variables, but how do you copy them?  Or know which group has been updated?
brent.hildebrand	Utility library opinion survey Posted: Monday, May 03, 2004 4:50 PM (EST) The way I store my personal utilities/tools is via user command files.  I have workspaces where I develop tools, but when I have a set I use all the time, I save them to my user command file (UCF)  using the groups concept.  An example, I have a set of utilies for working with files.  I can load them from the UCF by executing,  ]ULOAD .GRPFILES    My most frequently used tools are in the UCF, so I can load them individually or collectively.  And the group can be made up of variables and functions, so a describe variable can be included.  And if you don't include the /R option to the ]ULOAD command, it will not overwrite any functions currently in the workspace.  One enhansement to the ULOAD command might be to have it set the 2 []AT timestamp of functions loaded from the UCF to the time it was saved in the UCF via the []FRDCI to preserve the functions timestamp, but I digress.
davin.church	Utility library opinion survey Posted: Monday, May 03, 2004 5:15 PM (EST) That's not a bad idea, Brent.  But I wonder if everyone would be familiar enough with that method to use it generically.  I know many APLers that have no idea what user commands are, much less how to manipulate them at that level.   And of course, that does make getting a whole group at once easier, but it's also a little more difficult to just look through a group and pick one of several alternate choices for use.  Reading the group doc or the group contents list is close, but still awkward.   (FWIW, back in the 70's I tried to propose an extension that allowed functions to be explicitly marked with the subroutines they required, so if they were then copied their subroutines would automatically come with them.  Of course, it all fell on deaf ears and nothing like it ever quite materialized.)   (And yes, I think there are quite a few improvements that could be made to the UCMDS system, but I've never had the time or urgency to do anything about it.)
Michael.Hughes	Utility library opinion survey Posted: Thursday, May 13, 2004 3:39 AM (EST) I would say that its better to keep the different tools isolated as no one could possibly guess the weird and wonderful ways other APL people will use them.   Almost everyone will have their own method of code version control, etc. etc. and I think its easier to incorporate tools/utilities if they are as simple and as complete as possible.  That way they can be used more easily and confidently.
Michael.Hughes	Utility library opinion survey Posted: Thursday, May 13, 2004 3:50 AM (EST) I always keep my code as strands of []vrs in components of a file so related fns can be grouped together.  Similar to User Commands but I find it simpler and quicker for larger applications.    The code is simply defined with a []def{each}[]fread.   All it would need to work would be a single get or define function.  You could add your own help and possibly simple tree or list of utilities to be included automatically when the top level fn was defined.  It is also possible to check if a fn/variable is present and only define the module if the code doesn't exist.   Unfortunately I have never got round to writing this fn (I just []def the relevant components) but a good general fn could be written.
davin.church	Utility library opinion survey Posted: Thursday, May 13, 2004 12:29 PM (EST) Yes, this is another good way to keep personal utility libraries.  The Zark library also has it's own method, attached to a ]-command for retrieval.  And surely most programmers have their own favorite structures or methods.  (And the new "grand utility library(?)" that's being worked on will probably have its own, too.)   But I guess I should be asking how we should be distributing such contributions so that the maximum number of APLers will be able to find, update, and use contributed tools in the best/easiest possible way.  The fancy methods used by most of us for our own stuff is likely to be too complicated for general distribution management.  I was actually leaning toward some form of workspaces, in part because everyone knows how to )LOAD a workspace.
Michael.Hughes	Utility library opinion survey Posted: Tuesday, May 18, 2004 6:54 AM (EST) Thats why I felt small workspaces which contained code and documentation on a single theme would be better. The simpler and smaller the better.    1. It is not intimidating to an inexperienced APLer 2. It can easily be incorporated into our own, hopefully,  more sophisticated code control systems 3. It is easier to detect what needs updating in your own system after a fix/update to the utility supplied.