On 19-Nov-02 03:32:58 Kingsley wrote: > What is the scope for variables, is it limited to the particular > VIC that was 'in focus' when the var was defined, or are they > global to all VICs ? Kingsley, I got the recent status report. The variables need to work thru files. That's the whole point of oi-files. The ability to collect sets of variables and their values and to changes those sets within any given VIC, by simply changing the OI line in the PK file. right now I see a duplicate pk file being created in place of a default.oi file. I figured this was temporary, as a test. There really is no global, but rather a home directory where VICs can share files in read/write mode. This way it is possible to have VIC A, B and C sharing one set of Variables while D, E, and F share another set... Yet both may be using the same variable names, these variables are in different files and therefor are different. For an OI file to be read/write by more than one VIC, it must be in the Home directory. And each of those VICs must have that file listed in their PK file, on the OI line field one "HOME:filename". It's clear that you are thinking in terms of typical shell use of variables. But the only thing that is like typical shell use of VIC variables is how they are accessed in writing, as in the use of "$" to indicate it is a variable that needs to be replaced with the value it holds, in processing it. There is more further down the road as to how these .oi files may be used. I realize it will be slower, but in this case the turtle crosses the finish line, and the rabbit never will. This way of dealing with variables will allow some things to be possible that otherwise would not be possible. The only way to speed this process up is if there is a way to insure what is in memory of a given VIC, regarding variables, is a up to date mirror of the file. And that may be overhead that eats up any speed gained. Hmmmm.. A VIC processing a input line identifies a variable, it looks at what oi file is being used (listed in the PK file) and looks into that file for the variable and it's values. If the file is in the HOME: (VIC-HOME) directory then more than one VIC may be setting variables and values. The only concern over using files in such a manner is make sure there is no read and write collisions. Or anytime a VIC is going to modify an oi file, other vics need to wait before accessing the file, for the modification to be done. I'm sending you this, knowing the sooner you know a flag is up, the better. Let's clairify. A PK file represents a whole VIC process. If a VIC sets a PK file down, and picks up another PK file, to later return to the first PK file, what happens to the variables that belong to the first PK file if the second needs a completely different set that happens to use the same variable names? (This is only one possibility of many that needs to be able to store variables in files to later reload or pass to other VICs) Feedback please. ------------------------------------------------------ Hi Kingsley, the following is some information you may find useful. enjoy the weekend... Tim in pk.py ------------- class PK: "Place Keeper" def parseRun(self,state,config,command,stdin): handled = 0 output = [] error = errors.ok args = string.split(command) if (len(args) > 1 and string.lower(args[0]) == 'pk'): handled = 1 del(args[0]) ..... ------------- By making the len(args) test for greater than 1 instead of greater than 0, we won't "IndexError: list index out of range" if/when we only enter: VIC> pk Instead we will get a "unknown command" and NOT get booted out of the VIC system. Actually it should be a PK syntax error as PK requires some argument... shrug... but in any event it won't cause a python exit. ;) ++++++++++++++++ I again had problems in creating Home and Rooms (if they did not exist) In checking things out I found lib/posixpath.py and crossed checked it with AmigaPython, Windows python 2.0, 2.1, and 2.2, lib/posixpath.py files. All are the same in regards to isdir() and isfile(). Actually on the Amiga 2.0 python, posixpath.py just imports amigapath.py but still isdir() and isfile() are the same. Based on the instruction found in posixpath.py I tried the following code replacements and they seem to work on AmigaPython and I suspect Windows Python versions will work too, as well I suspect posix compliant systems will too. Maybe I'm missing something else that you see. in files.py ----------- #this def isDir(path): return (os.path.isdir(path)) #instead of this def isDir(path): result = 0 try: ### For python versions < 2.2 file_mode = os.stat(path)[stat.ST_MODE] if (stat.S_ISDIR(file_mode)): result = 1 except: ### For python >= 2.2 file_mode = os.stat(path).st_mode if (stat.S_ISDIR(file_mode)): result = 1 return result #this def isFile(path): return(os.path.isfile(path)) #instead of this def isFile(path): result = 0 try: ### For python versions < 2.2 file_mode = os.stat(path)[stat.ST_MODE] if (stat.S_ISREG(file_mode)): result = 1 except: ### For python >= 2.2 file_mode = os.stat(path).st_mode if (stat.S_ISREG(file_mode)): result = 1 return result ----------- +++++++++++ I found "VIC> PK -?" broke but "VIC>AI -?" still works. Both will load the browser and help file, but upon exiting the browser "VIC>PK -?" .... ---- Ram Disk:> python main.py NO CURSES VIC> ai -? VIC> pk -? Traceback (most recent call last): File "main.py", line 218, in ? parseRunPiper(state,stdscr,config,command,global_command_modules); File "main.py", line 130, in parseRunPiper handled,stdout,error = command_modules[i].parseRun(state,config,command,stdin) ValueError: unpack tuple of wrong size ---- I know the parseRunPiper() is at an expermental stage. Maybe the above will be info helpful to you. ------------------------------------------------------ Hi Kingsley, I've spent some time and frustration (a human thing we all share) trying to figure out or see a solution direction to concurrency reads/writes of oi-files in a platform independant way. (I suppose this might also apply to shared HOME based PK filenames too.... shrug...) First I went to IRC #python where I was kicked and then banned and so I moved it over to usenet comp.language.python (I think that is the right NG)... anyway... Perhaps this was all for not, as you may already be experienced with a solution you can use in this project. But I needed to see a solution direction. Not the coded details, that's your job, but a communicatable solution direction. I've attached (zipped) the relative usenet posts that lead up to the following quote (more of the thread can be found in usenet - and yeah, I was pissed about IRC....).... so that you may know alot was considered and looked into, by myself, in this solution direction quest. "....the solution direction is that of using threading locks to control the code that provides access to files for read and write operations. While anything outside of the python coded application would need to either not access it for writes or go thru the python coded application to make updates to the file, where the threading locks would again be applied. Another possible direction is that of using thread locks to control a stream/pipe that is read by a file writer. As "variable ; tag ; value" exist on a single line and such stream control locks is a common simple example given in such things as the O'Reilly python books. Where in updating the file the method of preventing external program conflict in reading the file, while it is being written/updated by the python program, a matter of using two files. A temp file the internal python program writes then renames to the correct name, letting the os manage the conflict avoidance during the rename (where if the OS fails.... It's an OS problem that in any decent OS should have already dealt with.)" So, a VIC, in it's own room, would simply write out (and over) the current (as listed in the VICs PK file OI line, current oi-filename) variable set each time there is a change to a variable. SO to mirror update into the file what is in memory. When the VICs rooms current oi-file is changed, prior variables in that VICs memory are cleared and the new ones read in from the new "current" file. Saves happen as changes in memory happen, reads only happen when the oi-file is changed. External programs that may access and alter the oi-files (as a rule to be put in the user manual) will have no effect on the variables the VIC is using, but instead must have (via the one AI command that can do this) the VIC reload the oi-file (preferable by another name) after the external program makes changes. In otherwords, this is a written rule for the user manual, rather than a programmed rule. This would be straight forward for oi-file handeling in VIC rooms. (perhaps, for performance, later in another phase of the project a VIC OI flag might be added to the SF-LPC flags, so that the oi-variables are only written to file at fewer select times. When it is known another VIC or external program doesn't need to get a copy from file.) But for oi-files access in and thru HOME, then some sort of threading lock use could be used to control and prevent internal (memory) variable and oi-file corruption. Noting that such a control mechanism would have to exist for each HOME based variable-set/oi-file in use. Anyway, like I said, all this may be for not, as you may already have the matter addressed.