Home › 2016 › Seite 8

Jahresarchive: 2016

Python Usergroup @ realraum

Geschrieben am von

On February 1 there was once again the monthly Python Usergroup Graz meeting.
This time it didn’t take place at the Spektral, though, as at the
last second (well, a week in advance…) a schedule collision happened and the
nice folks behind spektral had to use that room for themselves. Luckily,
within a couple of hours a new venue for that evening was found at the
Realraum! Big thanks to Michael and everyone else who helped here!

So, what happened? We had two talks! Horst gave a short tour through some of
nice string-formatting mechanisms you have with Python, something he had already
written about here a couple of weeks ago. If you want to learn more, simply
read that post and visit pyformat.info, which contains many more examples 😉

Right after that, we had a quick introduction into some of the awesome things
you can do with Pandas. Big thanks to Moritz for that 😊 You can find his
slides on our mailinglist.

We also had three visitors from the Vienna Python usergroup who come by
every once in a while and who have their next meetup incl. a coding dojo
on February 17 at the Metalab 😊

The next meetup in Graz will be on March 1 most likely again at the
Spektral. Official announcement will be made soonish on Meetup.com,
our website and all the other nice places you can find us 😃

Report on membershipmeeting Feb2016

Geschrieben am von

This months membership meetup was more cozy than usual. Also a lot more productive, judging on what happened the days after ;-)

The highlights:

  • Easterhegg 2016. Originally we wanted to help out with cool lighting and take part as a big realraum delegation from Graz. Unfortunately tickets were quite suddenly and unexpectadly sold out. So there will be no realraum @ Easterhegg 2016 Salzburg. Too bad. Very sad. Some of us are going to Revision16 instead though.
  • Lasercutter exhaustvent and OLGA vents. Is finally going to be built. See upcoming post with pictures.
  • Curtain: Will finally happen. New curtain rod installation was finished on Wednsday and Curtain is scheduled for hanging on Friday.
  • mur.at: The future of our internet uplink is in flux. Interessting stuff will happen 2016/2017.
  • Finances: Over the next months we will test and then maybe introduce a new formal system for financing stuff in realraum.

Light in realraum is now faster

Geschrieben am von

licht.realraum.at, went FTLw today. That is… it became much Faster Than Last week. :-)

Since the Raspbian image upgrade and move to a bigger (but slower) SDcard, licht.realraum.at had become truly sluggish. To the point that pressing a button to turn on the light or change the stereo volume could take up to 6 seconds until something happened. (Obviously we disabled the swap-file long ago.)

The problem was quickly identified. Processes don’t load quickly enough.
The fact that the whole systems was a dunghill of bashscript cgi-scripts and python helper scripts also did not help. At all.

First attempt to rectify this: rewrite the python helper rf433ctl.py. Formerly it was a simple script that would be called by the cgi-script and send the appropriate bytes down to the teensy.
Each call to it, however now took forever. So. I rewrote it as a daemon that would constantly stay in memory and be nudged by other instances of it via RPC. The idea being, if it’s already completely in memory, loading a second instance should be faster. Right? Wrong!. Unfortunately that did not work out at all.

Second attempt to rectify this: Remove the kiosk functionality and thus memory-hog midori from licht. Thankfully a very nice person gifted us a RaspberryPi per (almost) anonymous letter, so we had the necessary hardware on-hand to split the functionality onto two separate boxes: licht.realraum.at and smallkiosk.realraum.at
Unfortunately, even freeing up 60% of memory did not even put a dent into the problem.

So.. third and last attempt. Hit it with go ;-> In a 3 hour session, I rewrote the whole dunghill as a monolithic golang daemon/webserver/tty-handler which, once loaded, always stays in memory. Then I got rid of lighthttpd and the python scripts. Result… Speedup from 6s to <=0.05s !! Should have done this right away really...