LiveCode Python Integration

[jmwright]

Something that I've done in the past is to have the server accept a 'Q' character that causes it to shut down. I could do that so that the LiveCode app can gracefully shut the server down. Will that work?

[matthewmaier]

Yeah, that would be great. I know I can talk to the server through the socket.

On Sun, Jun 28, 2015 at 9:28 AM, Jeremy Wright notifications@github.com wrote:

Something that I've done in the past is to have the server accept a 'Q' character that causes it to shut down. I could do that so that the LiveCode app can gracefully shut the server down. Will that work?

— Reply to this email directly or view it on GitHub https://github.com/jmwright/apogee2_work_activity/issues/3.

[jmwright]

Ok, try commit 2a7b9906175bb0bddbd57231c70f831f2f3930cd

There are a couple things that I would like to figure out if we were going to use this long-term, but hopefully this gets us by for now. Please let me know if you have any issues with it on Windows. I've only tested it in Linux.

[matthewmaier]

I ran into the limit of my github skills. how do I merge that new file into my branch?

On Sun, Jun 28, 2015 at 11:29 AM, Jeremy Wright notifications@github.com wrote:

Ok, try commit 2a7b990 https://github.com/jmwright/apogee2_work_activity/commit/2a7b9906175bb0bddbd57231c70f831f2f3930cd

There are a couple things that I would like to figure out if we were going to use this long-term, but hopefully this gets us by for now. Please let me know if you have any issues with it on Windows. I've only tested it in Linux.

— Reply to this email directly or view it on GitHub https://github.com/jmwright/apogee2_work_activity/issues/3#issuecomment-116311401 .

[jmwright]

git fetch upstream

https://help.github.com/articles/syncing-a-fork/

[jmwright]

Sorry, forgot

git merge upstream/master

[matthewmaier]

I got the new version of the server and "Q" causes it to stop (I get a 10053 error because technically I can't disconnect first)

It's not strictly necessary so I'm about done fighting with it, but controlling the python server from livecode script isn't working.

Not sure why launch in livecode isn't working anymore. This is my batch/command file: set /p name= What is your name? cd C:\Users\theyogi\Documents\GitHub\apogee2_work_activity\Server deviceserver.py -f 2013_6_11_15_8_37.csv

When I run it from the file explorer I get the prompt and the server starts. When I launch it from livecode script the terminal window appears briefly but the prompt doesn't appear and the server doesn't start.

On Sun, Jun 28, 2015 at 1:21 PM, Jeremy Wright notifications@github.com wrote:

Sorry, forgot

git merge upstream/master

— Reply to this email directly or view it on GitHub https://github.com/jmwright/apogee2_work_activity/issues/3#issuecomment-116325682 .

[jmwright]

Is there a way to redirect the output from the deviceserver.py line (or the entire command file) to a file? That should tell us if the window is closing so quickly because of an error.

[matthewmaier]

since the shepard test stand is expected to deal with events that are over relatively quickly (a couple seconds) is it okay to just wait for all of the data to come in and then process it? does the processing need to happen in real time as each individual message arrives?

On Sun, Jun 28, 2015 at 8:20 PM, Jeremy Wright notifications@github.com wrote:

Is there a way to redirect the output from the deviceserver.py line (or the entire command file) to a file? That should tell us if the window is closing so quickly because of an error.

— Reply to this email directly or view it on GitHub https://github.com/jmwright/apogee2_work_activity/issues/3#issuecomment-116410358 .

[jmwright]

The stakeholders (J and Greg) will have to decide that. The current UI processes and displays the data in real time, but they may make an argument that much of that is unneeded. Is it difficult to process the data in real-time with LiveCode?

[matthewmaier]

No; at least I don't think so. I was just looking at the dump and thinking that it all appeared in one second and it would be fewer steps to just process the whole thing than to keep going back for each piece and the user wouldn't notice the difference.

How much of the interface's processes are you working on ahead of time? I've got Livecode to where it can get all of the data from the server. I suppose I could write a handler to ensure the formatting is clean. The rest depends on what the customer wants. Like, do they want real time? Do they want controls and options and different displays?

Here's an example of a tutorial for displaying a line graph in Livecode that I can just grab when I need it http://lessons.runrev.com/m/4071/l/7049-how-to-make-a-simple-line-graph But certain graphics choices can add a lot of complication and/or learning time.

I'm trying to keep the comparison between the two options at the work activity consistent.

On Sun, Jun 28, 2015 at 9:06 PM, Jeremy Wright notifications@github.com wrote:

The stakeholders (J and Greg) will have to decide that. The current UI processes and displays the data in real time, but they may make an argument that much of that is unneeded. Is it difficult to process the data in real-time with LiveCode?

— Reply to this email directly or view it on GitHub https://github.com/jmwright/apogee2_work_activity/issues/3#issuecomment-116427155 .

[jmwright]

How much of the interface's processes are you working on ahead of time?

I haven't had time to do any Kivy work yet. I was just going to add text boxes for the thrust and temperature reading, and then do a little bit of experimentation with a chart widget that I found in the Kivy "garden". https://github.com/kivy-garden/garden.graph

Kivy is new to me, so I want to make sure I can get some sort of graph working ahead of time. At most, I'd probably end up with a test app with two text boxes and a simple chart on it.

I don't think that we need to spend a lot of time ensuring data format quality. If there's a data formatting issue for this activity, I think we should just fix it on the server-side. Our task is to test the UI frameworks, and so I'd like to keep us from getting bogged down in the data or its transmission, if possible.

Does LiveCode have the concept of data binding? That's where you bind a variable to a GUI element, and they always stay in sync after that. Might make any real-time work easier.

[matthewmaier]

Livecode runs on messages so there won't be any problem telling one thing to update another if necessary.

Does that mean you expect most of the work to be GUI stuff? Like, make it pretty and add lots of options? I 'spose that makes sense.

On Sun, Jun 28, 2015 at 9:32 PM, Jeremy Wright notifications@github.com wrote:

How much of the interface's processes are you working on ahead of time?

I haven't had time to do any Kivy work yet. I was just going to add text boxes for the thrust and temperature reading, and then do a little bit of experimentation with a chart widget that I found in the Kivy "garden". https://github.com/kivy-garden/garden.graph

Kivy is new to me, so I want to make sure I can get some sort of graph working ahead of time. At most, I'd probably end up with a test app with two text boxes and a simple chart on it.

I don't think that we need to spend a lot of time ensuring data format quality. If there's a data formatting issue for this activity, I think we should just fix it on the server-side. Our task is to test the UI frameworks, and so I'd like to keep us from getting bogged down in the data or its transmission, if possible.

Does LiveCode have the concept of data binding? That's where you bind a variable to a GUI element, and they always stay in sync after that. Might make any real-time work easier.

— Reply to this email directly or view it on GitHub https://github.com/jmwright/apogee2_work_activity/issues/3#issuecomment-116431135 .

[jmwright]

Mostly GUI work is what I am expecting, and it's what I had in mind when I suggested trying out LiveCode and Kivy together. I don't think we have enough time to dive into things like data integrity and processing.