Difference between revisions of "Python Scheduling Application"
Russ hensel (talk | contribs) |
Russ hensel (talk | contribs) |
||
| Line 28: | Line 28: | ||
Reading the section on design as well may help understand this section. | Reading the section on design as well may help understand this section. | ||
| + | === Parameters === | ||
| + | The general parameter setup is explained in [[Configuration Files For Python]] and another example of its uses is discussed in [[Smart Terminal Parameter Examples]] There are additional features of the parameter setup here: | ||
| − | + | * The additional use of a global dict is different in this application. | |
| + | * Most of the parameters are set up almost as soon as the application starts, but a second set of parameters is run from the processing_helper ( if any ) to set up additional parameters. This setup is delayed so that it can reference objects that have not be created until near the end of the application initialization. It is in the method: init_from_helper( ). | ||
| + | |||
| + | === A Dictionary === | ||
Each scheduling activity may have its own ( but sharable ) set of parameters for that activity. These are stored in a dictionary, which is in turn stored in a master dictionary of all activity parameters. It is set up in parameters.py and is called: AppGlobal.parameter_dicts. When an event related function is called it is passed the name of the dictionary ( a string ) in AppGlobal.parameter_dicts and it gets out the correct dictionary it needs as in: | Each scheduling activity may have its own ( but sharable ) set of parameters for that activity. These are stored in a dictionary, which is in turn stored in a master dictionary of all activity parameters. It is set up in parameters.py and is called: AppGlobal.parameter_dicts. When an event related function is called it is passed the name of the dictionary ( a string ) in AppGlobal.parameter_dicts and it gets out the correct dictionary it needs as in: | ||
Revision as of 07:32, 22 March 2018
Contents
Introduction
Such an early draft not ready for reading!!
Note that this is an article started by Russ Hensel, see "http://www.opencircuits.com/index.php?title=Russ_hensel#About My Articles" About My Articles
The purpose of this program is to give an all python application for scheduling activities on all platforms: win, mac, linux, raspberry pi. I wrote it because I did not find a suitable program ( with good documentation ) after a not too exhaustive search. So here it is, let me know if useful.
Features
- Python 3.6.
- Extensible.
- All Python, cross platform.
- Some examples code/configurations in the download.
- Parameter file allows some customization without programming.
- Intended for Python programmers, not python naive uses ( sorry ).
- Can email if special circumstances encountered.
- Sleep tolerant ( but becomes inactive ).
- GUI tracks recent events.
- Maintains log file.
- GUI runs in one thread, events ( now one at a time ) in another thread.
Use
There are 2 steps to creating a scheduling activity.
- Create a new type of activity by programming ups it actions. This may not be necessary if an appropriate bit of code has already be written.
- Edit the parameter file ( parameters.py ) to activate and schedule your the activity.
Explaining an Example Setup
Reading the section on design as well may help understand this section.
Parameters
The general parameter setup is explained in Configuration Files For Python and another example of its uses is discussed in Smart Terminal Parameter Examples There are additional features of the parameter setup here:
- The additional use of a global dict is different in this application.
- Most of the parameters are set up almost as soon as the application starts, but a second set of parameters is run from the processing_helper ( if any ) to set up additional parameters. This setup is delayed so that it can reference objects that have not be created until near the end of the application initialization. It is in the method: init_from_helper( ).
A Dictionary
Each scheduling activity may have its own ( but sharable ) set of parameters for that activity. These are stored in a dictionary, which is in turn stored in a master dictionary of all activity parameters. It is set up in parameters.py and is called: AppGlobal.parameter_dicts. When an event related function is called it is passed the name of the dictionary ( a string ) in AppGlobal.parameter_dicts and it gets out the correct dictionary it needs as in:
a_dict = AppGlobal.parameter_dicts[ a_dict_name ]
then individual elements are fetched as in:
my_count = a_dict["failed_connect_count"]
Install
Get code from github, put where you put your python code, run. .... a bit more info later
Design
Some Big Ideas
The things that "happen" are events, they are set up in the parameter file in the method init_from_helper( ) using another method add_event_next_given_time() (more methods of this time may be added in the future if needed ). The components of an event are the following:
- A name for the event, to help you track it.
- A function that is run when the event is due.
- A time to first run the event ( minute, hour, day )
- A name ( string ) to be used to access supplementray data/parameters related to the event.
- A time delta for the next occurence after the specified when the event will be run again.
- A count for the number of times to run/rerun the event, -1 = "forever" .
- A function that is run after the event is run that is intended to reschedule the event in some way.
- Most of the design is similar to Python Smart Terminal Technical except for the plug in processing modules.
The GUI
The graphical user interface runs in a separate thread from the events ( on thread for the gui, one thread for all the events )
The purpose of the GUI is to:
- Give notice of each event as it is run and typically notes any exceptional conditions. Since this could take an almost unlimited amount of memory old events may be truncated.
- Allow the user to interact with the system. At a later time I will post a screenshot and describe the function of the different components.
Logging
Standard Python logging, see: Python Smart Terminal Technical
Parameters
Basically the same way as in the Smart Terminal, some more details will follow, see: Python Smart Terminal Technical
