(Updated Title)
This is the way things fit together:
Definitions:
1. "system context":
Anything run within a terminal window, (command line), called during boot, or anything executed outside an IDE.
2. "IDE context":
Anything run within an IDE like Thonny, mu, or anything else.
Background:
1. GoPiGo background robot libraries and software:
* Run continuously after the robot finishes booting.
* Manages its own SPI and i2c communication independently of any other processes that use it.
* Manages its own mutexes in /run/lock
* Runs in the "system context" as defined above.
* Fully respects the system path.
2. A terminal session as either "pi" or "root":
* Runs on demand.
* Manages things under program control.
* Runs within the "system context" as defined above.
* Fully respects the system path.
3. An IDE session, IDE started as either "pi", or "root" from the command line (sudo thonny, etc.)
* Runs on demand.
* Manages things both under program control and by itself.
* Runs within its own local context. ("IDE context" as defined above.)
* Completely ignores the system path unless it is specifically noted within the program file and local paths are appended.
Structure:
1. The GoPiGo libraries normally run from egg files in the normal system Python path as installed.
2. If I redirect the library paths in the system profile, (/etc/profile), it uses those.
3. The Waveshare e-Paper display demo code and libraries rum within %home%/e_paper.
* Though they can run from a command line, they are typically run within a context like Thonny so you can see the program's output.
Problem:
In order for my SPI mutex tests to be valid, (AFAIK), they must be using the same library include paths to be valid because I may run both GoPiGo AND Waveshare software at the same time in two IDE windows to whatch how they interact
I am not a sufficiently experienced programmer, nor am I an expert in the way GoPiGo libraries work, so I am compelled to assume they must run within the same path context, especially if I am running them side-by-side in an IDE where I can control them.
Also:
1. I want to isolate the GoPiGo libraries I am using to test from the system installed GoPiGo libraries.
2. I cannot assume that files and/or libraries called/included during program execution, (which can call/include other libraries outside my control), execute in the same path context as the original program.
Therefore:
I want to guarantee that any and all processes/programs run within the same path context. Ideally the system path as I defined it within /etc/profile.
I do not want to depend on explicitly specified paths in the code since I cannot guarantee that all parts of the code running within the IDE's context use the same path specification.
This is the way things fit together:
Definitions:
1. "system context":
Anything run within a terminal window, (command line), called during boot, or anything executed outside an IDE.
2. "IDE context":
Anything run within an IDE like Thonny, mu, or anything else.
Background:
1. GoPiGo background robot libraries and software:
* Run continuously after the robot finishes booting.
* Manages its own SPI and i2c communication independently of any other processes that use it.
* Manages its own mutexes in /run/lock
* Runs in the "system context" as defined above.
* Fully respects the system path.
2. A terminal session as either "pi" or "root":
* Runs on demand.
* Manages things under program control.
* Runs within the "system context" as defined above.
* Fully respects the system path.
3. An IDE session, IDE started as either "pi", or "root" from the command line (sudo thonny, etc.)
* Runs on demand.
* Manages things both under program control and by itself.
* Runs within its own local context. ("IDE context" as defined above.)
* Completely ignores the system path unless it is specifically noted within the program file and local paths are appended.
Structure:
1. The GoPiGo libraries normally run from egg files in the normal system Python path as installed.
2. If I redirect the library paths in the system profile, (/etc/profile), it uses those.
3. The Waveshare e-Paper display demo code and libraries rum within %home%/e_paper.
* Though they can run from a command line, they are typically run within a context like Thonny so you can see the program's output.
Problem:
In order for my SPI mutex tests to be valid, (AFAIK), they must be using the same library include paths to be valid because I may run both GoPiGo AND Waveshare software at the same time in two IDE windows to whatch how they interact
I am not a sufficiently experienced programmer, nor am I an expert in the way GoPiGo libraries work, so I am compelled to assume they must run within the same path context, especially if I am running them side-by-side in an IDE where I can control them.
Also:
1. I want to isolate the GoPiGo libraries I am using to test from the system installed GoPiGo libraries.
2. I cannot assume that files and/or libraries called/included during program execution, (which can call/include other libraries outside my control), execute in the same path context as the original program.
Therefore:
I want to guarantee that any and all processes/programs run within the same path context. Ideally the system path as I defined it within /etc/profile.
I do not want to depend on explicitly specified paths in the code since I cannot guarantee that all parts of the code running within the IDE's context use the same path specification.
Statistics: Posted by jharris1993 — Wed Jul 03, 2024 11:19 am