Running external module and accessing the created objects

[Dave Angel]

On 03/09/2013 11:56 AM, Kene Meniru wrote:
> Dave Angel wrote:
>
>> On 03/09/2013 10:34 AM, Kene Meniru wrote:
>
>>> To use my program the user needs a script file I will call user.py.
>>> Functions from my program must be imported into this file with
>>> something like "from myapp import *".
>>
>> And does the user run this script by doing
>>       python  user.py
>>
>
> Yes
>
>>>
>>> myapp.py is a module in my program that has all the functions that the
>>> user needs to describe building components. There is also a main
>>> controller object that is imported into myapp.py module called app.
>>>
>>> When python parses user.py module,
>>
>> You presumably mean, "When Python runs the script user.py"
>>
>
> When the user types and enters at the command line: "python user.py"
>
>>> the functions the user has provided
>>> creates building components which are then saved in a dictionary
>>> located in an object called doc that is part of my program.
>>
>> What program is that?  Looks to me like you're writing a series of
>> modules, a framework perhaps, that is invoked by the user script.
>>
>
> Yes. I am writing many functions and classes in many modules that work
> together.
>
>>>
>>> The user is free to use the functions in myapp.py to describe building
>>> components. When this process is complete or when the user wants to
>>> view their work-in-progress, they have to place a function called
>>> view() on the last line in user.py.
>>
>> Don't you mean the code in user.py has to *call* the function app.view()
>> when they're all done with defining the components?  That has nothing to
>> do with being the last line.
>
> Well... yes. The function is app.view() but it is not called automatically
> by the code in user.py. The following is an example of the contents of
> user.py
>
> ################### begin user.py #############################
> from buildes import *
>
> site("Willow_Creek_Ct", 5)
> """Create a site with name and number of boundaries."""
> level("level1", 3000)
> level("level2", 3000)
> """Create levels with name and height."""
> setLevel("level1")
> """Set the current level to place objects"""
> space("Dining", 5)
> """Create a space with 5 sides (walls)"""
> linearSide("Dining-S1", 3683, 152, 0)
> """Initialize the first side of space called Dining"""
> offset("Dining-S1", (3000, 0, 0))
> """Install the first side of Dining space called Dining-S1"""
> view(POV)
> """Exports objects to POV-Ray format"""
> ################### end user.py #############################
>
>>
>>> This function currently exports
>>
>> You mean writes files into the file system?
>>
>
> Yes.
>
>>> the components into POV-Ray or OpenSCAD format. These are CAD programs
>>> that read script files to render or create images of the described
>>> artifacts. So this means that to view their work the user needs to run
>>> python on user.py to export the building and then run POV-Ray or
>>> OpenSCAD on the exported file to see the building.
>>
>> At that point, the user.py script has completed, and Python is done,
>> right?
>>
>
> Yes
>
>>>
>>> I want to make it possible for the user to preview the building
>>> components without having to use the external rendering programs. I
>>> can currently have the app object provide this preview but it means
>>> that the user will have to process user.py with python then exit the
>>> graphic window each time they need to see changes.
>>
>> What changes are those?  You can't change a script while it's executing.
>>    Could you clarify this so I can rethink the following paragraph?
>>
>
> Working on the user.py is an iterative process. The user adds new objects or
> changes the parameters of the objects already there and envokes "python
> user.py" each time to see the changes made. Just like using a program like
> LaTeX. You edit your text file and run LaTeX on the file to see the changes
> you made. The process continues until you finish the document.
>
>>
>>
>> So the solution I am looking for is to have a graphic window open that
>> watches user.py for changes.

It would then have to be a separate executable.  Are you really saying 
you want this window to keep "running" after the script ends?  And that 
somehow it notices that the user has rerun the  user.py script?  Or 
could it simply be a window created during the user.py run that stays 
running till it's closed, which ends the script as well?

>> If there is a change the graphic window
>> updates the rendition of the created components without further
>> intervention by the user.

Is running the script considered intervention?  Or do you mean literally 
that somebody watches the script for changes (eg. by watching the 
timestamp)?

>> However this means that the graphic must
>> somehow run python to parse user.py and then be able to access the
>> objects stored in doc so that the coordinates can be used to update
>> the view. This is where I am having difficulty.
>

Either the "graphic" is in the same process, in which case the script 
can only be "parsed" once, or the "graphic" is in a second process, in 
which case you're talking some interesting interprocess communication 
(ipc).  That's certainly do-able, but it's way beyond the scope of the 
kind of programming you've been talking about.  But sometimes just using 
a regular file for transfer is adequate.

If you really want two processes, then you should consider having the 
user run the the graphic app, with a commandline parameter of user.py, 
and have it create the user.py process.  The user.py process runs till 
it has created all the data, then sends it via some ipc to the graphic 
app.  Once sent, it terminates.  The graphic app reads the ipc stuff, 
updates its graphics, then idles, watching for timestamp changes on the 
user.py file.

If you choose to use external file(s) to communicate between the two 
processes, you might use pickle or shelve.


-- 
DaveA