Google Analytics

Saturday, September 19, 2015

Python and Kivy: out of here!

A while back I started a Home Security project.  After examining several different approaches, I settled on Beaglebone Black for the hardware, programming with Python and presentation using Kivy.

After much work on Kivy, and continuing issues with the Linux Angstrom that was on the Beaglebone, I came to the conclusion that it just wasn't ready for prime time, and I suspended my project waiting for the technology to catch up.  This was easy to do, as I always have more to do on my plate than time to do it!

Recently, I decided it was time to take another look at this project.  I purchased a new Rev C Beaglebone Black, then started working with it.  This was a major improvement, as this version also moved from Linux Angstrom to Debian.  I was unwilling to try and work with Angstrom again, so the move to Debain was great news.

I became convinced that the pyvenv development environment would work best, but that entailed moving to Debian release 8 or 8.1 instead of the current 7x version, and Python 3.4.  So I quickly got well acquainted downloading and installing various test releases of Debian 8.1 for the Beagle.

Once the OS and Python versions issue was resolved, I set up the project on GitHub, and started moving forward, with the first task to set up do to builds on the Beaglebone while using pycharm as the IDE on my host Ubuntu system.  I mounted a host directory onto the Beagle using sshfs, so that code changes I made within pycharm would be directly available for code running on the Beagle via the shared directory.  I would edit in the IDE on my host, then use a terminal session that was logged into the Beagle to run and test the code.   This worked really well, and all my source code was maintained on my host and pushed to github as well.

With those issues resolved, I began to look into the presentation layer.  I really was concerned about trying to use Kivy after all the disappointment from a while back.  Looking at the emails from the Kivy group - there were still a lot of issues.

All of my previous work in IT had primarily been devoted to development on the back end, with very little work on front end presentations.  However, I had come across some articles regarding html5 and it's ability to work with websockets, so I wanted to take this opportunity to do a little deep dive into html5 to see how that might better fit my presentation layer problem.

The first thing was to take a look at the Beagle's onboard webserver.  I had not really taken a look at that in the past, but now with all presentation options on the table, I did take a look.

Wow!  What an insight that was!  A little bit of nodejs code, and batta-bing, I was serving up simple web pages!  And there was a direct ability to push data from the Beagle to the presentation via a web page.  This really looked like the approach I had been seeking: a user has a web page up (a security monitor), the Beagle first supplies the current state of all sensor elements, then pushes any updates (sensor state change) to be displayed on the web page without the user having to refresh the web page.

This was it!  While I was happy to drop Kivy, it also looked like the easiest approach would be to move totally away from Python and over to JavaScript as well!  That was a shock!  This also meant I no longer needed pycharm; I no longer needed the sshfs (well, it may be a little early yet to decide that), I no longer needed pyvenv, so I no longer needed Python 3.4, and that meant I no longer needed Debian 8.1 either.......holly cow!  The last weeks worth of changes to the OS, pyvenv, pycharm, Python - all now relegated to the trash heap!

I'm going to take a look at Debian, nodejs, and JavaScript to see if there's any benefits to staying with Debian 8.1 (which at this time is in 'test' mode; prelease), but I'm hoping it's not needed, so I can stay with the standard deployment.

So: this project has abandoned Python and Kivy!!!

Moving to JavaScript and Nodejs!!!

I will be documenting the development of the Beagle project, utilizing JavaScript, nodejs and bonescript here.  Stay tuned for updates!

I will be placing my detailed notes on setting up a development environment for the Beagle for Python here on this blog at a later date, as they may be of use to someone doing Python development for use on a Beagle for their project.

Wednesday, September 2, 2015

ThinkOrSwim (TOS) on Linux!

Please check the date you are reading this - because TOS makes frequent changes, the information I'm providing here may not work for you.

I'm currently running TOS on three (3) different platforms: Ubuntu 14.04, Windows 7 (on VirtualBox in Ubuntu 14.04), and on LinuxMint 17.02.

All are working, although the Windows version is, by far, working the best.  There just doesn't appear to be much interest from TOS in making this a quality experience on a Linux based machine!

I'm not going to detail any installation on Windows - the TOS installation is fine.

Instead, these are are my 'notes' from installing on LinuxMint - it was the same as on Ubuntu.

- from a terminal, verify the version of Java you are running, using the command
        java -version
The response to this on my machine is: "build 1.7.0-88-b15".

The main thing here is that it must be version 1.7.......!  TOS will not work with 1.8..... or newer!   If you aren't running version 1.7, then you will need to resolve this before you go any further.  In my case, it took me a while to resolve, but ultimately I ended up (first) verifying I didn't have any applications using Java 1.8, (next) I uninstalled Java 1.8, then I obtained Java 1.7 from Oracle and installed it.

The following assumes you running 1.7...!

- pull the Linux distribution down from TOS website.  Specify the Ubuntu/Debian version.

- save it to your download folder.

- run the TOS install, being sure to install for just yourself, not for all users (this is very critical) at the popup window.  We won't be launching via the desktop icon, so there's no need to let it install this.  Instead, we will be launching from via a terminal shell command.

- once installed, you'll have to make some mandatory edits to some of your TOS files.

- the first edit change is associated with the amount of memory that can be used by the Java Virtual Machine.  It comes preconfigured with a really low value.  So, we're going to change this.  I'm using a starting value of 1024 MBytes, and a max value of 2048 MBytes.  That means TOS will start with a minimum of 1.024 GBytes of memory allocated, and can consume up to 2.048 GBytes.  Make sure you have enough memory to support those values, or set to your own system capabilities!

- in terminal, enter: cd  #to make sure we are starting at your home directory
- in terminal, enter: cd thinkorswim
- in terminal, enter: cp thinkorswim.vmoptions thinkorswim.vmoptions.bak #to make a backup copy you can revert to if needed.
- in terminal, enter: gedit thinkorswim.vmptions
- in gedit, find the line: -Xmx<>m  , and change the value to -Xmx2048m # I no longer know what my original values were, but seems like it was 512m
- in gedit, find the line: -Xms<>m  , and change the value to -Xms1024m #remember - adjust these values so as not to exceed the amount of free memory you have available, or else you will start swapping, and the system will be too unresponsive for you to use at that point.
- exit and save from gedit.

- the next edit change is associated with changing the TOS shell script that launches TOS.  It's located in the same directory you were in above (~/thinkorswim).  So, you are going to gedit the directory/file ~/thinkorswim/thinkorswim

- in terminal, find out where the Java executable is located, by issuing the following command in the terminal: whereis java
- my response to this contains multiple fields, separated by 'space'.  The installation on my machine makes use of file links, so I'm going to show you how mine resolved.  The first field response to 'whereis java' is the important field.  On my machine, it begins with /usr/bin/java

-- Steps to see linkage:
-- in terminal, enter: ls -al /usr/bin/java   #responds /usr/bin/java -> /etc/alternatives/java

-- in terminal, enter: ls -al /etc/alternatives/java #responds /etc/alternatives/java -> /usr/lib/jvm/java-7-oracle/jre/bin/java

--this is the actual location of the file.  You should be able to use any of these values in your thinkorswim shell script, but if you have problems, use the last one - the actual file and location.

- Verify this on your system!  If it doesn't resolve to Java version 7, then you can't use it.  I haven't tested it, but even if you have a Java version 8 installed, if you point to this final location of Java 7, then it probably should work.

- in terminal, enter: cp thinkorswim thinkorswim.bak #making a backup copy you can revert to if needed.
- in terminal, enter: gedit thinkorswim
- in gedit, find the line:  #INSTALL4J_JAVA_HOME_OVERRIDE
- you are going to remove the comment (#) character, so do that!
- next, you will need to enter (assuming you are going to use the final location from above), or the links (if they are all set up properly): /usr/lib/jvm/java-7-oracle/jre/bin/java   
- Your line should look like this:

(unless you used your verified link /usr/bin/java instead.  Note that these links can change if Java updates to 1.8 or newer on you at some point, so a good reason to use the hard coded version until TOS ever gets around to upgrading their JVM version reliance.)

- At this point, the changes required to get going should be complete.

- However, this would not work correctly on either my Ubuntu system, nor my LinuxMint system, if I used the desktop launcher for TOS.  However, if I opened a terminal, and from the ~/thinkorswim directory entered:
   sh thinkorswim
then my system would work correctly.  If I did it from the launcher, it may work for a while, then crash, or not work at idea what the issue was.

The TOS system on my Linux based machines are not as robust nor as reliable as running on Windows, even though it is running inside of a VirtualBox instance on the Ubuntu machine!  However, it does work.  I use it on the LinuxMint node to display some graphs, while on the Ubuntu/VirtualBox/Windows node I do my trading, with a total of 4 monitors - 2 on Ubuntu/VirtualBox/Windows, and 2 on LinuxMint.

Hope this helps!!!


Monday, May 12, 2014

Learning Kivy - Part 6


Table of Contents

  • Learning Kivy - Part 1
  • Learning Kivy - Part 2
  • Learning Kivy - Part 3
  • Learning Kivy - Part 4
  • Learning Kivy - Part 5
  • Learning Kivy - Part 6

  • After a LOT OF WORK, I was finally able to get some code working that incorporates the following:

    • Thread, with a simulation of a Socket.  This writes to a Queue.
    • Main thread - Kivy GUI thread, that reads from the Queue
    • Queues
    Where I've been having issues is:
    • Getting both threads up and running (Thread for Socket simulation, thread for main Kivy GUI), while not causing either thread to block.  Over the years, I've written a lot of Thread software, yet there still issues.  I still don't know what the problem was.
    • Getting both threads to use the same Queue.  For some brain-fart reason, I was creating two (2) Queues, one in each thread, then was surprised that the data I was pushing into the Queue wasn't available to be read on the other Queue!  Clearly a misunderstanding on my part.  I've used Queues before, and knew how they worked, so I don't even have the excuse of ignorance to justify this - it was just a plain brain-fart.  In the code, I create a global variable that has the Queue, which makes it available for each thread.  I'm not saying that's the best approach, but I wasn't trying to research the best approach for Queues, I was trying to get Kivy going.
    • These were the two (2) main problems.

    Here's the code.  It does the following:
    1. Builds a simple Kivy Language BoxLayout (via my ShowGUI class) via the 'Bulder.load_string' command.
    2. Creates a global variable q and assigns Queue instance to it.
    3. Creates an instance of my SimSocket class.  The class has methods that will create some data, then push it onto the Queue.
    4. Creates a Thread named 'simSocket' that links to the callback SimSocket method "put_on_queue".
    5. Starts the 'simSocket' thread.
    6. Runs Kivy.
    Once running, the following takes place:
    1. On the Terminal, initialization messages, followed by comments that say data is being written to the Queue, and shows the data.
    2. A pop-up GUI appears.
    3. Data is read from the queue.
    4. The GUI updates with the  the data that is being pulled from the queue, at a rate of 1/60 of a second.
    5. It continues to run until you stop it, or it reaches 1 million messages.
    ======Python Code Follows=========

    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    Trying to build up a foundation that satisfies the following:
        - has a thread that will implement code that:
            - simulates reads data from a Python socket
            - works on the data
            - puts the data onto a Python Queue
        - has a Kivy mainthread that:
            - via class ShowGUI
                - reads data from the Queue
                - updates a class variable of type StringProperty so it will
                    update the label_text property.

    from threading import Thread
    from Queue import Queue, Empty
    import time

    from import App
    from kivy.uix.boxlayout import BoxLayout
    from import StringProperty
    from kivy.lang import Builder
    from kivy.clock import Clock


            text: str(root.label_text)


    q = Queue()    

    class SimSocket():
        global q

        def __init__(self, queue):
            self.q = queue

        def put_on_queue(self):
            print("<----- ..threaded..simsocket.put_on_queue="" entry="" font="">
            for cntr in range(1000000):
                print(".....threaded.....SimSocket.put_on_queue(): Loop " + str(cntr))
                self.some_data = ["SimSocket.put_on_queue(): Data Loop: cntr: " + str(cntr)]
            print("..threaded..SimSocket.put_on_queue(): thread ends")

    class ShowGUI(BoxLayout):
        label_text = StringProperty("Initial - not data")
        global q
        def __init__(self):
            super(ShowGUI, self).__init__()
            print("ShowGUI.__init__() entry")
            Clock.schedule_interval(self.get_from_queue, 1.0 / 60.0)

        def get_from_queue(self, dt):
            print("---------> ShowGUI.get_from_queue() entry")
                queue_data = q.get(timeout = 5)
                self.label_text = queue_data[0]
                for qd in queue_data:
                    print("SimKivy.get_from_queue(): got data from queue: " + qd)
            except Empty:
                print("Error - no data received on queue.")
                print("Unschedule Clock's schedule")
    class KivyGui(App):
        def build(self):
            return ShowGUI()

    def main():

        global q
        ss = SimSocket(q)
        simSocket_thread = Thread(name="simSocket",target=ss.put_on_queue)
        print("Starting KivyGui().run()")

        return 0

    if __name__ == '__main__':


    BBQ Review - Hickory Pit Bar-B-Queue, Chattanooga, Tennessee

    BBQ Review - Hickory Pit Bar-B-Queue, Chattanooga, Tennessee

    Note: I don't publish any negative reviews at all, so you only see reviews for places I stop at and enjoy.  I don't think it's fair to write a negative review for an establishment that might have had an off day.

    These guys (Mr. and Mrs. Ford) just won Fifth in a Nation-wide award from TripAdvisor!  That's no small feat; per TripAdvisor, their "community of millions of travelers" had decided that this BBQ restaurant is worthy of 5th place in the USA!

    The award was posted Thursday, May 8, 2014.  I learned of it on Friday, May 9, 2014.  I was there eating a big-ol' BBQ Pork sandwich on Saturday, May 10 - the next day!

    My wife and I planned the trip for Saturday, May 10th, 2014, to see relatives in Chattanooga TN that would require us to go right by this restaurant on our way to visit!

    Coming from Atlanta on I-75 N., we took Exit 1B for Ringgold Ave, then headed West for one (1) mile, and located the restaurant on the right side of the highway.

    It's small!  Like 2 tables outside, 4 or 5 tables inside!

    We tried to time our arrival at 11:30, so that hopefully we might avoid the major crush I was expecting.  Well, I was wrong - there was already a major crush, and it just got bigger and longer as we waited....45 minutes to be served, after waiting about 15 minutes to order.

    The staff was doing all they could, but they were overwhelmed.  Everyone was pleasant though, and we didn't hear anyone complain about the wait.

    They were, however, in addition to taking orders from the people that stood in line to place their order at the counter, also taking orders at the drive-up window, as well as orders over the phone.  That meant anyone placing an order via their car or over the phone was jumping to the head of the line and this meant the line was at least 3 times as long as what we saw standing in line. 

    At some point Mrs. Ford realized this wasn't fair to the people that had traveled to eat with them, and stopped taking any further orders over the phone, which continued to ring non-stop!

    There was no where to sit for us, so we took 'take-out', and ate it in our vehicle.  That was a little difficult, because this was a huge BBQ Pork sandwich, heavily laden with sauce!  Careful attention was required, after multiple wraps with napkins, to try and keep it off of our cloths - we both succeeded, which I would have thought would be impossible!

    So - what did we think?


    Worth the wait?  No, but then nothing would have been worth the wait!  The wait will change as the excitement wears thin, or they adjust their staff to the new reality.

    WOULD WE GO BACK!  YES!  After the excitement has died down somewhat.

    This is ONE HUGE BBQ PORK SANDWICH.  Next time, I'll ask for it to be NAKED, so I can better judge the meat, but it's the real-deal!

    Friday, May 9, 2014

    BBQ in the News - Smokin' Ribs

    This is from an article on smoking ribs on a bullet-style smoker that caught my attention, and wanted to share with you.

    Link to complete article at

    Excerpts from the article:

    Pork Belly Slim’s Method for Mouth-Watering Barbecued Ribs

    This photo, from D'Artagnan ( shows ribs finished with coffee barbecue sauce.
    This photo, from D’Artagnan ( shows ribs finished with coffee barbecue sauce (not the method used by Pork Belly Slim, but similar).

    It’s that time of year. The flowers are in bloom, the weather is warm and we’re all excited to get outside after a colder winter than we’ve had in a few years.  For me, and a lot of others, spring means BBQ season is open, and it’s time to dust off the smoker, grab some charcoal and wood for smoke, and start the fire.