This page is under construction.
Robert L. Dickinsons communication and work on the Virtual Interaction Configuration.
RLD-digest2.html - not yet!
There is more communications between Robert and I that I'd like to post,
only I noticed how some in csa.misc seemed to want to play mind games (the
game of how well they can distort and dilute the value and meaning of such
communication.) Realizing the potential negative or anti-productive value
of such intentional efforts..... I suppose for now, the work (vic.library
and commands) itself speaks loudest. The ongoing digest may be helpful in
answering questions for those productively interested in the values
contained in the communications. Such as why this part or that part of the
VIC is done the way it is. With this in mind I think the best way to
perhaps approach this matter is to post that part of the digest that is
supportive of work completed to stage that the user can apply in use. Now
it's the matter of my finding the time to focus and determine these things. And
this because some find the time to focus anti-productively....Hmmmm.
AI and vic.library builds: (contains assembly source and binaries)
Newest on top.
But First a message from your sponsors.
From firstname.lastname@example.org Mon, 7 Feb 2000 18:56:24 -0600 (CST)
From: "Robert L. Dickinson"
To: "Timothy Rue"
Subject: Re: [GPL] VIC iteration
Date: 8 Feb 2000 00:56:24 GMT
On 1 Feb 2000, Timothy Rue wrote:
> Hi Robert,
> Considering the above (comments from Robert in another email), perhaps
> what is needed is a regearing for forward movement in a changing
> environment (your personal schedual environment).
> lets see now. First a little clean up of what we have.
> Currently we can exit a VIC group, but not one or part of a group.
Actually, this part worked, but you had to specify name#1 for example, not
name.1 as you would expect. I've fixed this to be consistent with the
directory naming, so doing "AI exit test.1 test.3" for example, should
exit two VICs out of that group (assuming they existed to begin with).
> * make it possible to do so (exit one or a part of a group)
> >From a user POV (not understanding the asm code) it appears we are able to
> create directories and delete them. Nothing yet is created in them.
This is still the case. Looks like this will be the next item to focus
> We can give AI some of it options without generating error messages.
> Perhaps for options that are not yet implimented in a way the user can see
> or use, we should generate an error window message "not yet implimented or
> user active" (I see you do keep track of the arguements given with the
> options that are accepted)
Warnings are now displayed in the error window.
> * go ahead and add enough code and comments so to accept the other options
> and a place to hold the arguement of them (for each vic?), as you have
> with the options you have accepted so far.
> >From here, if you have the placholders of these option arguements then you
> pretty much have the makings of the PK file (something to put into the VIC
> directories.) And there are of course the default creation of other files
> in these directories when none are otherwise supplied...
OK, I'll work on these files next.
> The PK functionality is what manipulates the contents of the PK files...
> But you really want to get to a point of something more user productive
> So the above is more a getting to an "easy to pick back up and continue"
> The SF functionality comes to mind as something most likely to bring about
> user productivity of any of the rest of the total VIC. It's the part that
> steps thru, line by line, processing of what you might call a script or
> sequence of lines (VIC commands as well as anything that is ignored by
> the VIC but passed on to where ever the OP is set to).
> SF is the part the makes it all move in sequence.
> Now lets say we had SF working to the point that it would step thru a
> sequence given it and ignore all VIC commands that do not yet exist in a
> user active way (maybe generate a warning mesage in the error window that
> that option is not yet available) but still deal with what is available as
> well as send non-vic lines to where OP is set to.
> Here is the workable thing about this. If a VIC command or option is not
> yet available, then it's not likely anyone is going to write a sequence
> that includes such commands or options. But as the commands become
> available and others make use of them in writting sequences...... Well
> formerly written scripts of sequences won't break!
> With no available user usable VIC commands or options and SF hardwired to
> output to the shell that invoked it.... (does the shell simply echo the
> results to the output where it can be redirected or does the shell execute
> the lines SF gives it? * making an unknown shell execute such results it
> gets from a program it executes is part of the problem that inspired the
> Anyway.... SF w/o VIC commands and options is like a bare bones shell that
> only filters out any VIC commands and options it receives, from what it
> As we add VIC commands and options we do more than just act like a simple
> Here are a few incomplete but leading thoughts (along the lines of getting
> something more user productive going, and perhaps helping to add to itself
> a generation of vic development momentum.)
> Hmmmm, There is IQ written in Arexx. I even have something of a working
> Gui4cli gui (point and click) for it. Let me know if you'd like me to send
> it to you (the gui4cli gui - which is not yet available on my web pages)
> But if this IQ setup got it's arguements from the PK file (maybe even help
> in setting some PK file settings....)
> Hmmmm, and if the output of IQ was sent thru SF to catch/filter/execute
> any available VIC commands (including any IQ commands it receives)...
> [**** Of course using this Arexx version of IQ is only so to help increase
> user productivity level of what you have done so far. Certainly Arexx IQ
> is slower than what it would be in Assembly...:)]
All right----this all sounds good; thanks again for taking the time to
steer me back on the forward path. I guess the next thing will be to get
some files in the directories, then go from there. A lot of the
discussion above is very helpful in understanding the big picture of where
we are going, but as we get closer some of the details might need to be
explored more (for my understanding, anyway), but for right now I'll focus
on getting some files in the VIC directories.
Let me know if you find any issues or bugs in this version.
Have a nice day,
[Attachment: vic_4.3.lha added 2/10/00]
vic_4.2.lha added 12/21/99
vic_4.1.lha added 11/28/99
vic_3.2.lha added 11/17/99 (filename change from
format below but still contains both AI and the vic.ibrary w/source)
vic_3.1 I have not posted due directory creation names used the wildcard
"#" and could prevent some directory tools from deleting them ( possibly confuse the
user as well in their effort to manually delete them)
aiviclib2-1.lha added 10/12/99
AI command documentation/Specification