FLOSS Project Planets

Drupal Association News: They’re back! Personalized membership certificates are here.

Planet Drupal - Fri, 2015-05-01 08:44

We all like to show our love for Drupal, and over the past few years, we’ve let Drupal show it loves you! Due to popular demand, we are bringing back a fun gift to Drupal Association members -- personalized certificates of membership. In 2014, we delivered these downloadable certificates to over 600 members and we hope to break this record during the months of May and June this year.

Join as a member or renew your current membership anytime before June 30 and you’ll receive a personalized certificate of membership.

Sign me up

This is a token of our gratitude for your support of Drupal and the community. Thanks for everything you do for Drupal.

Personal blog tags: Membership
Categories: FLOSS Project Planets

BlackMesh: DrupalCon LA has 5 dedicated sprint days. Should you be there? YES!

Planet Drupal - Fri, 2015-05-01 08:18
What is a Sprint? Sprints are times dedicated to focused work on a project or topic. People in the same location (physical space, IRC, certain issue pages) work together to make progress, remove barriers to completion, and try to get things to "done". The goal is to get an issue to Reviewed and Tested By the Community (RTBC), and keep it there. (Keeping it there means quickly addressing feedback, like when a someone moves an issue back from RTBC to Needs Work, or Needs Review.)

Instead of a person working by themselves on many things, we work together, with others, on a few things to get them done. We do not measure success by the number of patches posted. We measure success by the reviews we do, issue summaries we update, change records we post, and the number of issues we get to RTBC.

DrupalCon is a supportive environment to begin contributing Though sprints might sound intimidating, the sprints at DrupalCon have a history of both informal and formal ways for integrating new contributors in this process. If you have experience with Drupal, then you have the skills we need to help with contribution to the Drupal project. And, DrupalCon is the most supportive environment to start your contribution journey. Who? We welcome project managers, bug reporters, site builders, themers, QA testers, writers to help with documentation, accessibility specialists, usability specialists, developers, and contributors to other open source projects to help fix upstream bugs. When?
  • Extended sprints begin Saturday, May 9 and Sunday, May 10 at an off-site location: IndieDesk.
  • Monday, May 11, sprints at the conference venue in room Room 408AB run concurrently with the community summit and other trainings.
  • There is a lounge for work all throughout the event at the venue in Room 408AB, and off-site which is open 24 hours at the Westin Bonaventure Hotel in the Ballroom on 3rd floor.
  • Then Friday, May 15 is the most awesome sprint day which you should not miss an hour of.
  • Followed by more extended sprints at IndieDesk Saturday, May 16 and Sunday, May 17.
Why should you sprint? Sprinting with others allows barriers to contributing to be removed in real time. You will learn a lot just by sitting at a table with others and seeing how they work. Having others see how you work, might result in them giving you time saving tips that will help you contribute and... might also help when you return to your regular routine after the sprint. It is fun. You will get to network and meet the real human people who work on Drupal itself. Sprints include some down time. We have to eat! Conversations at lunch and dinner can be both enjoyable and eye opening. Finally, trust that you do have skills that will be appreciated at the sprints. We are really good and finding ways for everyone to contribute. Topics In addition to generally "contributing", there are some specific topics in Core, Contrib modules, themes, and infrastructure with people organizing work in those areas and gathering others to collaborate with them. Core Some of the focus for Core during the DrupalCon sprints will be:
  • Getting D8 done
  • Multilingual
  • Front-end United
Getting D8 done For getting D8 done, there are different ways of being involved. One way, is working on D8 criticals. Read the page on helping with Drupal 8. Angie Byron (webchick) is also giving a session to update people on the status of the current criticals. We are also looking for experienced contributors join a group of people who will triage issues with the priority of Major. (We are still working on instructions for doing the major triage. Join us at the event!) Multilingual The best way to get involved with the Drupal 8 Multilingual Initiative (D8MI) is to start on the D8MI website. And then look at the issues we are currently focusing on. Jump right in, or come by our weekly meeting in IRC in the #drupal-i18n channel. The next meeting is May 6th at 4pm UTC. Front-end United Front-end United people will be working on: CSS, JavaScript, Twig, UX, themes, the theme system, markup, and stuff! Contrib Some of the focus for Contrib during the DrupalCon sprints will be:
  • Content Staging in D8
  • Media in D8
Content Staging in D8 Information about content staging in Drupal 8 is on the deploy project page. Media in D8 Current focus for media is on entity_embed, entity_browser, media_entity and fallback_formatter. Work is happening in the drupal-media project on github. The presentation by Chandan Singh has a recent update. Drupal.org Drupal.org is running on Drupal 7. If you are familiar with Drupal 7 and do notwant to dive into Drupal 8 yet, you can still really help with the release of Drupal 8, by working on Drupal.org itself. Drupal.org has a lot of projects where it tracks issues. There are 42 Drupal.org related projects which each have their own issue queue. searching for the d.o hitlist tag (across all projects) yields a list of issues that are relevant for the sprint. Infrastructure The big push for infrastructure right now, includes blockers to Drupal 8. Issue: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 release has lots of details, but can be a little overwhelming to dive into. Confersations happen in IRC in the #drupal-infrastructure channel. One of the blockers is the new testbot Continuous Integration system (testbot CI 2.0). There are 7 projects related to DrupalCI. DrupalCI: Modernizing Testbot Initiative is the main overall project. And updates and confersations happen in the Drupal.org Testing Infrastructure groups.drupal.org group and in IRC in the #drupal-testing channel. Sign-up Signup to help with a topic, or lead a topic in the DrupalCon LA sprint spreadsheet.

Photo credit: Jeremy Thorson

Categories: FLOSS Project Planets

Code Karate: Mobile friendly navigation using the Mmenu Module

Planet Drupal - Fri, 2015-05-01 07:28
Episode Number: 206

As a request from David over at luxor.me, we checked out the Mmenu module. This little gem allows you to use various javascript libraries to create a mobile friendly navigation. The navigation it produces is similar to the slide in menus you find side a lot of mobile applications.

Tags: DrupalBlocksDrupal 7Site BuildingDrupal Planet
Categories: FLOSS Project Planets

Code Karate: More control over your Drupal Admin menu with Administration Menu Source

Planet Drupal - Fri, 2015-05-01 07:18
Episode Number: 205

Sometimes you have a situations where your normal Drupal administration menu just won’t cut it. Maybe you have someone that needs to perform some administrative tasks on your site such as managing content and comments, or perhaps something more complex such as managing the Drupal blocks. This person might be a technical wizard, but there is also a good chance that they might not be. In fact, they might be the person in the office that calls you when their “computer is broke”.

Tags: DrupalDrupal 7Site BuildingDrupal PlanetSite Administration
Categories: FLOSS Project Planets

digiKam Recipes 4.7.1 Released

Planet KDE - Fri, 2015-05-01 07:01

A new release of digiKam Recipes is ready for your reading pleasure. This version features completely rewritten material on using digiKam to emulate various photographic effects (including the new recipe on how to create a faded vintage look). The book features two new recipes: Geotag Photos with Geofix and Update the LensFun Database. As always, the new release includes minor updates, fixes and tweaks.

Continue to read

Categories: FLOSS Project Planets

OpenSource.com: Help map Nepal, OpenMRS for Ebola, Apache Mesos for Apple, and more open source news

Planet Apache - Fri, 2015-05-01 07:00

In this week's edition of our open source news roundup, we take a look at helping earthquake victims in Nepal, OpenMRS and the fight against Ebola, Apple's Siri to leverage Apache Mesos, and more. Open source news roundup: April 25 - May 1, 2015

Categories: FLOSS Project Planets

Miriam Ruiz: Sexualized depiction of women in SuperTuxKart 0.9

Planet Debian - Fri, 2015-05-01 06:59

It has been recently discussed in Debian-Women and Debian-Games mailing lists, but for all of you who don’t read those mailing lists and might have kids or use free games with kids in the classroom, or stuff like that, I thought it might be good to talk about it here.

SuperTuxKart is a free 3D kart racing game, similar to Mario Kart, with a focus on having fun over realism. The characters in the game are the mascots of free and open source projects, except for Nolok, who does not represent a particular open source project, but was created by the SuperTux Game Team as the enemy of Tux.

On April 21, 2015, version 0.9 (not yet in Debian) was released which used the Antarctica graphics engine (a derivative of Irrlicht) and enabled better graphics appearance and features such as dynamic lighting, ambient occlusion, depth of field, and global illumination.

Along with this new engine comes a poster with a sexualized white woman is wearing an outfit that can be depicted as a mix of Native american clothes from different nation and a halo of feathers, as well as many models of her in a bikini swim suit, all along the game, even in the hall of the airport.

They say an image is worth more than a thousand words, don’t they?


Categories: FLOSS Project Planets

Sergey Beryozkin: Opend Id Connect Certification Strategy

Planet Apache - Fri, 2015-05-01 06:30
I've just read about an OpenId Connect Certification open strategy. IMHO it is brilliant and no doubt will guarantee a wider adoption of OIDC. Mike Jones's explanation of why it will work is a good read.

The closed (payed-only) certification model limits the adoption of a given technology by the implementors.
Categories: FLOSS Project Planets

François Dion: The computer network in space - Part 1!

Planet Python - Fri, 2015-05-01 05:12
First in flight
First in flight is the (unofficial - official is "Esse quam videri") North Carolina motto.

Our launch is not a first in flight from a HAB (high altitude balloon) perspective (see also: "Rocket man and the Near Space Circus"), but the mechanical aspects (see also the article on our self-leveling rigging: "learn from the past - 103 years old technology in space"), hardware and network topology and innovations packed in the software will definitely be first in flight.(Launch is now D-1, April 21st from Mocksville)

Team Near Space Circus HAB "NSC01" ready to launch
  • Sending micro controllers into near space to take measurements? Done.
  • Sending a raspberry pi with a camera module into near space? Done.
  • Sending multiple gopros into near space? Done.
  • Taking pictures from near space? Done.
Anything left to do that hasn't been done?

Genesis of NSC01
One would think there is nothing left to do that has not been done before. Really, launching weather balloons for gathering data and taking high altitude pictures has been done many thousands of times before, even well before the age of the digital camera.

In fact, in NASA technical memorandum TM X-2208 published in 1971, it covers flights done in the later part of 1969 by the Langley Research Center in Virginia. This served as inspiration as to part of the payload for our own launch, an homage if you will. In this flight, they used medium format film cameras, both in the visible spectrum and the infrared.

So we started with that concept, we will have a Raspberry Pi with an infrared (PiNoir type) camera, and another with a regular CSI camera. Plus a very analog tech which I'll cover in Part 3.

And we quickly realized that we just opened Pandora's box... Innovation was possible everywhere we looked.

Eye in the sky
In my collection of Raspberry Pi related stuff, I had a few cameras already, including one infrared with an S-mount and lens. For a first flight, we could have simply gone with that and a regular raspberry pi camera (with its neutral lens which is not bad at all quality wise; neutral lenses are relatively easy to make compared to wide or tele lens). But we really wanted a wider shot, particularly as the 1080p video is cropped and gives even less coverage.

I didn't want to destroy the other modules to add the S-mount (commonly used on CCTV cameras), so I opted instead for a magnetic mount with a conversion lens. That way the camera can be used without conversion lens, or with a telephoto, wide or even a fish eye conversion lens.

Fish eye, wide, S-mount and magnetic mount RPI cameras
Of course, most people discard conversion lens as junk. And optically, they are terrible, with lots of barrel distortion and other issues. In fact, barrel distortion is easy to see on videos on youtube taken with wide (it is the built in lens actually) lens "extreme sports" type of video cameras that are so popular. The closer to the edge, the more it distorts.

But this was not going to be a show stopper for us. With the right software, I was convinced we could get some really decent shots. So I mounted a camera with a wide angle lens on top of the raspberry pi case, powered the pi with my phone spare battery pack (with a micro USB lead) and took pictures to calibrate my software (written in Python) and then went downtown Winston Salem to take pictures of buildings with lots of horizontal and vertical lines. Distortion is easily seen there.
And the results were quite nice:
Raspberry Pi camera with low cost wide angle, software corrected80 x 60 degrees fov, portrait. Low distortion Fairly wide angle. Test shot from our HAB diy cam for @GSBChallenge pic.twitter.com/jimojcs8sM
— Francois Dion (@f_dion) March 25, 2015

What is left is the normal angling of lines due to perspective, but barely any lens distortion. Nice. Now let's move on to the computer.

Like groceries
So, a HAB with a few computers is like doing groceries for a family with a few kids. The more kids, the more expensive it gets. A single Raspberry Pi model A+ is only $20 plus shipping. And we knew from day 1 that we would use two of them. At a minimum.

Then we started looking at options to mount 4 cameras on the payload. For 360 panoramic pictures... Well, with the wide angle lens we used we'd need 5. But 6 is a nice round number, and due to crop factor of the 1080P mode, just making 360 degrees. How to connect 6 CSI cameras to 2 Raspberry Pi?

Plan A was building or buying a multiplexer. But time ran out for building, and we couldn't buy a real multiplexer. We did have a CSI switcher (made for 4 cameras per board) that I had ordered from Turkey. I had it in hand, but it never did work. I tried to get a replacement but the vendor never contacted me back. Caveat emptor.

Plan B was 1 Raspberry Pi per camera. And we had 6 regular cameras for the 360 panoramic, and 1 infrared CSI camera facing downward. So 7 Raspberry Pi it is...

Imagine your grocery bill with 7 kids...

Micro SD in their numbered SD adapters to avoid confusion
And so it went for our project. 7 Pi, 7 cameras, 7 micro sd memory cards (a mix of 32GB and 64GB cards), enough battery power for all of that. Oh yeah, power...

12V != 5V
We figured that for all the gear we would have onboard (7 Raspberry Pi, 7 CSI cameras, 1 USB camera, 2 GPS, sensors, 1 APRS transmitter doing 10W bursts every 2 minutes), we would use 3S (3 cells is series) Lithium Polymer batteries, commonly used in RC and drone applications.

Two 3S 4000 mAh LiPos with XT60 connectors; cameras
We went with two, in order to make it easier to distribute the weight and redundancy. But that meant connecting them together in parallel. This was perfect for the APRS transmitter (transmitting our location, voltage and temperature every two minutes) as it expected a 12V source.

The two LiPo batteries connect on this side
But the Raspberry Pi expect 5V, not 12V. So we added two UBECs. These are switching voltage regulators. They are not really designed to run in parallel, but we ran them for 12 hours straight many times with no issues. Look on RC forums, people say you cant do it. Well, you can. They do lose some of their efficiency that way, because they use PWM to regulate their output and measure their output as part of that. When 2 are in parallel, the output of one interferes some with the feedback loop of the other. Still, we were ok to lose some efficiency for redundancy.

5V UBECs (switching, not linear)And we needed an octopus loom with 7 microusb to distribute the 5V to the 7 Raspberry Pi. It's about as light weight as we could make it... We did try to connect directly to GND and 5V on the GPIO header, but when it came time to network the 7 Pi together, it caused some issues. I'll talk about that in Part 2.

Power distribution to 7 Raspberry Pi
Where is the network?
I did say we had a computer network we were sending into space, didn't I?

Raspberry Pi #1, 2 and 7
And I'll leave you today in conclusion of part 1 with a shot of the 7 Raspberry Pi networked inside the payload.

All 7 Raspberry Pi before the power wiring harness is put in place

Part 2 will go into the details of the network itself (article is now up: http://raspberry-python.blogspot.com/2015/04/the-computer-network-in-space-part-2.html), the master/slave component and the deadman's switch (now up, also) and part 3 will talk about the data gathering aspects. And in the interim, try to guess how we are networking the 7 Raspberry Pi.

And you can track our first launch progress (and real time data on the day of the launch) by keeping an eye on #NSC01 on twitter, following @pyptug or myself.

Francois Dion

[Update: added links to part 2 and to the deadman's switch]

Categories: FLOSS Project Planets

Keith Packard: the machine architecture

Planet Debian - Fri, 2015-05-01 01:44
The Machine Architecture

Here's a brief introduction to some of the hardware concepts within The Machine.

As the team at HP that I'm working with are busy working on Linux kernel changes motivated by the hardware, I'm hoping that providing this kind of documentation will help Linux kernel developers outside of HP evaluate that work, and work by others in related areas.

Joining HP and learning about The Machine

In January, I joined HP to work on Linux for The Machine.

I'd watched Martin Fink's video and read other articles on the new hardware coming out of HP labs. I had hints of what they were up to, and the possibilities seemed exciting enough to entice me to go back to HP.

When I arrived at HP, one of the first things I got to read was the external reference specification for The Machine. 170 pages detailing a more significant shift in computer architecture than I had been given any hints of, both in my interviews at HP and from what I could see in the press.

Since then, I've been eager to tell people about what we're doing, and I'm happy to say that we're finally ready to start the conversation with this brief description.

A Short Outline of Storage within The Machine

The basic unit of The Machine is a collection of hardware grouped in a Load Store Domain. A Load Store Domain consists of:

  • Multiple independent Compute Nodes

    • Independent operating systems
    • Local memory
    • Load/store access to shared, in-memory storage
  • Shared byte-addressable persistent memory:

    • Non-volatile wrt operating system life cycle
    • Global address space
    • Hardware access control
    • Accessed with standard CPU load/store instructions

Here's a diagram of how the various bits of the hardware are hooked together:

And, a brief description of the elements within the picture:

  • Compute Node. A set of processing cores, caches and various ancillary peripherals.
  • Local Store. Memory directly connected to the processing cores.
  • Firewall. Hardware access control between the compute node and shared memory.
  • Shared Byte-addressable Persistent Memory. This is the storage within The Machine. It is accessed directly via normal CPU load/store instructions in units as small as one byte.

I've intentionally drawn the shared memory in a large box to emphasize the notion that this machine is more "memory-centric" and less "processor-centric".

The shared byte-addressable persistent memory forms the sole persistent storage within The Machine.

More to Come

I'll continue to publish information about The Machine and our related Linux work as we work on the hardware and software.

Categories: FLOSS Project Planets

Mike Hommey: Announcing git-cinnabar 0.2.2

Planet Debian - Fri, 2015-05-01 00:55

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Get it on github.

What’s new since 0.2.1?
  • Don’t require core.ignorecase to be set to false on the repository when using a case-insensitive file system. If you did set core.ignorecase to false because git-cinnabar told you to, you can now set it back to true.
  • Raise an exception when git update-ref or git fast-import return an error. Silently ignoring those errors could lead to bad repositories after an upgrade from pre-0.1.0 versions on OS X, where the default maximum number of open files is low (256), and where git update-ref uses a lot of lock files for large transactions.
  • Updated git to 2.4.0, when building with the native helper.
  • When doing git cinnabar reclone, skip remotes with remote.$remote.skipDefaultUpdate set to true.
Categories: FLOSS Project Planets

Bryan Pendleton: On the great joy of reproducing a bug

Planet Apache - Fri, 2015-05-01 00:42

Dave Winer completely nails it: Reproducible

This is the kind of "bug report" that makes programming for users so frustrating. You hear a user is losing data, but have absolutely no idea how to reproduce the problem. It's something you've never seen the software do, can't imagine it actually doing. The description sounds like magic, but nothing in software happens by magic, all programmers will tell you. I believe it's happening but I have no idea why.

And then, after plenty of work and sweat and tears

we had arrived at the Holy Moment in debugging -- reproducibility. I told him "reproducible" is the programmer's favorite word. If you can tell me the steps to reproduce the problem, then I can find it and fix it. Until it's reproducible all I can do is share your frustration.


Categories: FLOSS Project Planets

Vasudev Ram: Can a Python data structure reference itself?

Planet Python - Fri, 2015-05-01 00:13
By Vasudev Ram

As part of some Python work, I was tinkering with the built-in globals() function of Python, when I noticed this:
>>> g = globals()
>>> g
{'a': 'A', 'A': 'C', 'C': 4, 'b': 'a', 'g': {...}, '__builtins__':
module '__builtin__' (built-in)>, 'k': '__doc__', '__package__': None, '__name__
': '__main__', '__doc__': None}
>>> # The variable g seems to have got stored inside of itself!
>>> id(g)
>>> id(globals())
>>> g['g'] == g
>>> g['g']['g'] == g
>>> g['g']['g']['g'] == g
>>> id(g['g']['g']['g']) == id(g)
The above does make a kind of sense, when you remember that the globals() function returns a dict representing the current global symbol table, i.e. all the currently defined attributes (objects) in the global scope.

So when I said g = globals(), the variable g got created in the global scope; so when I next print g, it should contain g itself, i.e. g (a list) contains itself as a list item (of g).

But on further thought, it seems like this should depend on the order of the evaluation of the statement g = globals():

Case 1) If the variable g is created first (and hence the global symbol table now contains it), and if only after that is the globals() function called, and its return value assigned to g, then things should work as shown in the above interpreter output.

Case 2) But if the evaluation works in a different order, i.e. the globals() function is first called (before the variable g is created), then at this point its return value (the dict) should not contain the item with key 'g' (and value g), and it is this dict that should get assigned to the variable g. Hence when we print g, we should not see g again within it.

Considering the above output, it seems like Case 1 is what actually happens. Also, I realized that if the globals() function is returning a copy of the dict that represents the global state, the above output should not work. But it seems to be returning the original dict itself, as shown by this:
>>> id(g) == id(globals())
To explore this further, I thought of trying to create a similar self-referential structure, but without using globals():
lis = []
print 'lis:', lis
print 'id(lis):', id(lis)
print 'lis:', lis
print 'id(lis):', id(lis)
print 'id(lis[1]):', id(lis[1])
print lis == lis[1]
print lis[1] == lis[1][1]
And the output again seems to indicate that the list lis now references itself, that is, contains itself as an item.

I then thought of testing my Python function to flatten an arbitrarily nested list, with the above definition of lis, as the input argument. As expected, it terminated with a run-time error about recursion limit exceeded. See the post linked in the previous sentence for the flatten function - and some variations on it, in the comments on that post.

I'll write more about this in a following post, after fixing the flatten function to handle this case. On first thought, the fix seems straightforward: at any level in the recursion, check if id(lis) == id(lis[i]) - for any i, and if so terminate with an error about this being a self-referential list - but I'll write and test it first, then blog the results.

The more interesting question is whether this is a known Python feature, or an undocumented one (seems unlikely), or a bug (unlikely), and also whether similar behavior exists in other languages. Interested to hear what others think / know about this.


I looked in the official Python Language Reference, at the Section 3. Data model:


and saw this excerpt:

[ CPython implementation detail: CPython currently uses a reference-counting scheme with (optional) delayed detection of cyclically linked garbage, which collects most objects as soon as they become unreachable, but is not guaranteed to collect garbage containing circular references. ]

Not sure whether it is relevant to the topic at hand, since, on the one hand, it uses the words "cyclically linked", but on the other, it says "garbage collection".

The image at the top of the post is of an ouroboros, which is "ancient symbol depicting a serpent or dragon eating its own tail", according to Wikipedia. Sort of appropriate, I guess, because Python :)

- Vasudev Ram - Online Python and Linux training and programming

Dancing Bison Enterprises

Signup to hear about new products or services that I create.

Posts about Python  Posts about xtopdf

Contact Page

Share |

Vasudev Ram
Categories: FLOSS Project Planets

Python Software Foundation: Highly Contagious: Python Spreads through South America!

Planet Python - Fri, 2015-05-01 00:03
As you may recall, I previously posted about a wonderful project in South America that has been funded in part by the PSF. That first blog post described the Python events that Manuel Kaufmann had organized in Argentina and his plans to move on to Paraguay and then Bolivia. Please check it out at Python in Argentina. I’m very happy to report that Manuel Kaufmann has continued to be busy bringing Python events and knowledge to more and more people, as he left Argentina for Paraguay. He recently reached out to us to tell about his experiences. Here's a recap: First of all, PyDay Asunción took place as scheduled on March 28th. This event was the culmination of Manuel’s efforts in creating the brand new Python Paraguay community. His Paraguayan adventure began by meeting with people from different Software Libre groups (PHP, OpenStreetMap, Sugar, Google Code In, etc) in an attempt to merge them into a new community focussed on Python. Their first meeting had 13 attendees who immediately began organizing for PyDay Asunción.  This first PyDay (or mini-conference) in Paraguay was a great success. Over 100 people with varying levels of programming and Python skill attended. Manuel was pleased to report that among the presenters were a 17 year old boy and a young woman–clearly the diversity of our community is growing demographically as well as geographically. In addition, the importance of this event was marked by the Paraguayan government, who declared PyDay Asunción an official Technology and Cultural Event. Congratulations to Manuel and everyone who worked to make this a reality.You can read more about the day (in Spanish) at Manuel’s own blog post.

PyDay Asunción Of course, as before, the momentum didn’t stop at one event. With a new community formed, new events were bound to occur. It always amazes me the way hard work and a good idea will grow. In fact, Manuel reported that some of the attendees of last month’s PyDay Formosa, Argentina were so enthused that they travelled 400 km to attend and help out at PyDay Paraguay. That kind of passion and commitment says a lot about the quality of these events and the desire for more. Perhaps Python is contagious! Similarly, Manuel tells us that a talk at PyDay Paraguay gave rise to another event: HACKÁra Asuka Guaraní: an event to translate the Sugar platform to Guaraní. This event was organized by Ricardo Saucedo and Martín Abente (one of the members of Python Paraguay). In fact, the idea of this event came out of Martin’s talk at PyDay Asunción. There were around 15 teenagers including 6 girls and a teacher who helped with the translation into their native language. According to Manuel, this potentially could lead to many people who don't speak Spanish being able to learn programming.

Manuel has no intention of slowing down. Although his original plan was to spend three months on the project, he hasn’t yet made it to Bolivia, so he’s going to extend his time commitment. One problem he’s having is with his car. Apparently it needs quite a bit of TLC to keep it going. If you’d like to help with that, Manuel is accepting donations at Manuel’s Project. Since a little goes a long way to keep a car running, I hope you'll join me in giving him the cost of a latte or two.

In any case, his project appears unstoppable, with many future events either completely set to go or in the planning stages. The following events are already scheduled for May:  In addition, Manuel has some exciting ideas for future projects, such as creating a Robot Course for kids, and bringing Facundo Batista (one of the best Argentinian Python hackers) to Asunción, Paraguay to develop a 3-days course. These are in the early planning stages, but if I know Manuel, I think we can look forward to hearing about their successful completion in the future.
If you’d like to follow Manuel’s travel plans, or provide some support, please visit his website.

I would love to hear from readers. Please send feedback, comments, or blog ideas to me at msushi@gnosis.cx.
Categories: FLOSS Project Planets

Wingware News: Wing IDE 5.1.4: May 1, 2015

Planet Python - Thu, 2015-04-30 21:00
Wing IDE 5.1.4 adds a Find Symbol in Project dialog, supports Django 1.8 and debugging Django with auto-reload enabled, adds preliminary support for Python 3.5, adds Change Case options to the Source menu, and makes about 40 other improvements.
Categories: FLOSS Project Planets

Justin Mason: Links for 2015-04-30

Planet Apache - Thu, 2015-04-30 19:58
Categories: FLOSS Project Planets

François Dion: The computer network in space - Part 2

Planet Python - Thu, 2015-04-30 19:35

- You're flying! How?
- Python!
( https://xkcd.com/353/ )
Part one of this series of articles on Team Near Space Circus flight NSC-01 can be found  >here<. It covered the physical layout of the 7 Raspberry Pis, 8 cameras and power system. It left off as we were about to go into the details of the network topology itself.

A satellite or a bowl of spaghetti?Plan A: 2 Pi in a Pod...
The initial plan was for 2 Raspberry Pi using a serial communication protocol. The Model A+ does not have an ethernet port. Of course a Raspberry Pi 2 has one, and is more powerful, but it also consumes a lot more power than the A+. Our battery pack would have had to be much larger if we went down that path, and that meant significantly heavier. We had a goal of 2Kg for the payload itself, and we were getting close, so serial it was...

Serial communication
DB25 (serial or parallel)DB9 (serial)
Many early personal computers typically had two interfaces, either built in or available through an expansion card: a serial (either a DB9 or DB25 connector) and a parallel interface (either a DB25 or 36 pins Centronics connector, aka IEE1824). The parallel interface was typically used for printers (and great for DIY DACs with resistor ladders, but that's a story for another time), while the serial port was mostly used for modems or scientific equipment.

RS-232 was introduced in 1962, so it's been around for quite a while now. Many serial connections were actually TTL (5V), such as on the Digital Decwriter III, but it was quite easy to convert them to a +/- voltage range (and even more so since the mid 80s with ICs such as the MAX232). The initial purpose was to connect a DTE (Data Terminal Equipment), a fancy way of saying a computer, and a DCE (Data Communication or Circuit-terminating Equipment).

On a DB9 connector, the pins would be (DB9 male connector pictured):

RxD is Receive Data and TxD is Transmit Data. What if you need to connect two DTE together? You need a Null-Modem adapter or cable. The simplest Null-Modem circuit requires 3 wires (2 if you can guarantee the ground on each end to be the same):

GND(7) to GND(7), TxD(5) to RxD(4), RxD(4) to TxD(5)
Raspberry Pi Header
The Raspberry Pi doesn't have a DB9 or DB25 connector. But if you look at the 40 pin header, notice on the top row, the 4th and 5th pins:
Raspberry Pi Model A+ with pinout as overlay
TXD and RXD. It is a serial port, but it is *not* RS-232 compatible as far as voltage levels are concerned (a 1 is marked by a negative voltage in the range -3V to -15V, and a 0 by a positive voltage in the range +3V to +15V), as it is a TTL interface (a 1 is marked by a positive voltage, either 3V3 or 5V and a 0 is marked by 0V). But that is fine, we are only connecting to another Raspberry Pi.

The primary issue with this serial port is that the Raspbian operating system has a console (TTY) associated it. Meaning that you could connect this to a computer, with the right cable, and see the boot process and get a console prompt, and be able to type commands, as if you had a keyboard and monitor connected directly to the Raspberry Pi.

In our case, however, we want to use the port for something else, our own communication network, so we have to disable this feature. It was once a manual process, and I had written a script to do it, but...

sudo raspi-config
The raspi-config now has an option under the Advanced Options selection to disable the serial port console, so we can use it directly:

Advanced -> SerialOnce we have reconfigured the serial port, we can quit raspi-config and reboot. For each compute node, beside disabling the serial port console, we also enabled on the advanced page the SPI and I2C options, and on the main page we configured the time zone, enabled the camera and expanded the filesystem. We also overclocked nodes 1-3 to 800 MHz while nodes 4-6 ran at 700 MHz (so we can measure the impact of overclocking).
Plan B: A Pi clusterBy using a pair of Raspberry Pi, the communication process is pretty straightforward. With two nodes, we can use SLIP or Point to Point Protocol (PPP). Initially, this was the thought for NSC-01 and we would not have to write the code for the network layer.

6 Raspberry Pi cameras1 Infrared Raspberry Pi camera (pointing down)
But without a functioning camera switcher, the only option was to use one node per camera (each Raspberry Pi has 1 CSI camera connector, even thought the Broadcom chip supports 2 - most cell phones have a front and rear camera). With 7 CSI cameras in total, that meant 7 Raspberry Pi.

Time to dig in our bag of tricks...
Token Ring4 Node token ring network architecture

As I was going through the options, I started thinking about good old IBM Token Ring (and FDDI). Conceptually, at least. I wasn't going to make something compatible with 802.5, but instead reuse the concept with the serial UART, transmit to receive from one node to the next.

Conceptually, a node is always listening to the serial port. Is this data for me? (if it's a broadcast or if it's addressed to me) If not or if a broadcast, I send it right away to the next node, and process it if it is addressed to me. So let's get into the details.

The diagram
7 Raspberry Pi networked togetherIn the previous article, one of the pictures clearly showed 7 Raspberry Pi connected together inside the payload. I've included here a fritzing diagram to help in detailing what is going on here.

In the diagram above, I didn't have a Raspberry Pi model A+ for fritzing, so I used the closest thing for our purpose, a Raspberry Pi model B+. Both of them have a 40 pins GPIO header. First row at the top, from left to right has 5V, 5V, GND, TxD and RxD. We'll stop there for right now.

Here I've simply connected node 1 TxD to node 2 RxD (blue wire), node 2 TxD to node 3 RxD (pink), node 3 TxD to node 4 RxD (brown), node 4 TxD to node 5 RxD (cyan), node 5 TxD to node 6 RxD (orange), node 6 TxD to node 7 RxD (yellow) and finally node 7 TxD to node 1 RxD (green), in a nice circular (or ring) fashion.

The GND are not daisy chained from one Pi to the next, because they are all powered by the same source, through their microusb plugs.

Initially, I tried to power the Pi directly from the 5V pin on the GPIO header, but the signal was decoding only partly. By further connecting the 3.3V (that was key, the UART operates at 3V3 so the HIGH signal was not detected reliably when powered with only 5V) and GND together, it made it more reliable, but also more complicated. I reverted back to powering all the 7 nodes using microusb (as detailed in the previous article).
What's great about Raspbian is that not only do we have Python installed, but Python 2.x and 3.x are there, along with many things that are normally optional, such as pygame, pyserial, RPi.GPIO etc. Batteries are quite definitely included with Python on the Raspberry Pi.

Still, for the networking software, we did install two modules from pypi using pip3 (we are using Python 3), docopt and sh.

For the bulk of the development, I used a Raspberry Pi Model B+ connected to my laptop and to a second Raspberry Pi using the serial port and the network switch. That way my laptop could see both Raspberry Pi and I could push new versions of the software using scp.

I also had a "field" version, in case I needed to do last minute changes:

Raspberry Pi sidekick in sidecar configuration (DHCP server on laptop)
docopt: helps you to define interface for your command-line app, and automatically generate a parser for it.

For example, in the case of the network controller, token.py, it accepted one argument, the node number. In the future, we'll probably derive the node number from a personality module on the GPIO header, but it was a simple solution that could be done in software, not adding any weight to the payload. The downside was having to keep track of all the microsd cards:

micro SD card transport - For nodes 1 to 7 plus 1 backup

And, so back to docopt, here is how it was used for token.py. At the top of the file, after the shebang line (so the script can be an executable), I included the docstring which defines the interface (lines 2 to 5), which is a required field <address>. This is a simple case, but as cases get more complicated, it really pays off to use docopt.

Then on line 14 I import the docopt module (I group imports alphabetically first by what's included, then a blank line, then again alphabetically I add the imports that have to be installed - just a convention):

1 : #!/usr/bin/env python3
2 : """
3 :
4 : Usage: token.py <address>
5 : """
6 : from datetime import datetime
7 : import logging
8 : from logging.handlers import SysLogHandler
9 : import RPi.GPIO as gpio
10: import serial
11: import subprocess
12: from time import sleep, time
14: from docopt import docopt

I then conclude the script by passing the arguments that docopt figured out are there (and validated) in the docstring (__doc__), to the main function:

168: if __name__ == "__main__":
169: arguments = docopt(__doc__)
170: main(arguments)

And how does one use it in the code itself? In the body of the main function I do the following:

97 :
98 : def main(args):
99 : my_addr = int(args['<address>'])

In case an air traveler wants to check our website...
SHsh: is a full-fledged subprocess replacement for Python 2.6 - 3.4 that allows you to call any program as if it were a function:

`python from sh import ifconfig print ifconfig("eth0") `

Continuing with the code in token.py, you simply import what you need from the shell and sh transparently builds a function for you to call. In this case I needed access to date and rmmod:

1: #!/usr/bin/env python3
2: """
4: Usage: token.py <address>
5: """
6: from datetime import datetime
7: import logging
8: from logging.handlers import SysLogHandler
9: import RPi.GPIO as gpio
10: import serial
11: import subprocess
12: from time import sleep, time
14: from docopt import docopt
15: from sh import date, rmmod

Then further down in the code I can call date() to call the actual date command from the OS so it is not only in the right format, but in the right timezone (there are other ways to do this, but sh was going to be used heavily for gathering stats, so it made sense to introduce it here):

154: # synchronize time
155: s = str(date())+' \n' # from the OS
156: bin = bytes(s, "ascii")

So, how about accessing a serial port in Python? And are there things to keep in mind when using Python 3?

First thing first, we import serial (line 10). This module is already installed on the Raspberry Pi.

Then, within the body of the main function, we establish a serial connection (line 101). We specify the device that corresponds to the serial UART. This is /dev/ttyAMA0. We also specify the bitrate, expressed in bits per seconds (bps). 115200 is the fastest we can use with the default clock settings for the UART, and is what was used for the flight. As a reference, acoustic coupler modems worked at 300 bps...

We felt that at higher rates it might not give us as reliable a signal, but we will experience with faster rates on future flights (we only had time to do 1 flight within the Global Space Balloon Challenge window). Back in 2012, Gert Van Loo stated:

"The UART and the SPI can be driven by DMA so there is no SW limitation.The real maximum for all those interfaces is only set by the signal integrity.This is certainly the case for I2C as it has to use pull-up resistors to get the signals high again.I know the clocking is rather confused. I built the damn chip and I still have no idea how to control all the clocks.The clocking structure is very complex with a limited number of resources (PLL's) which are used for aplethora of things to drive. (A quick count shows 36! clocks being generated) There will be many cases where it is just not possible to give you ALL the frequencies you want."And in fact, it is possible to get up to 921600 bps (8 times what we used) in a controlled environment, at the OS level In an environment full of RF, including a 10W 2M transmitter, with a python module, I'd be happy with 4 times (460800) or even twice (230400) our rate. If nothing else, it would drive our latency down some.
Wow, that was quite the detour, anyway, back to our establishing the serial connection. The last thing we specify  on line 101 is timeout=1. This is a 1 second timeout. We will be blocking on reads (line 113), but don't want to wait more than 1 second for the data. 

In the original token ring world, a frame is defined in the following way:

A start delimiter, access control, frame control, destination address and source address, then the data, and finally a frame check sequence, end delimiter and frame status. I found this later, after I designed the frame for our system, and it is interesting that it is quite similar, in functionality, but implemented slightly differently.

In our case, the frames are small in size, they should never go above 1 second to transmit. And if they do, then we kick out that partial request and the balance of the request and we'll get the next one that is complete. So, we assume that if we get a full frame, the first byte is always first, and the frame always conclude with a newline (that way the ser.readline() returns before the 1 second timeout). We thus avoid the start delimiter (the end delimiter is newline). 

The first byte for our protocol is the source address (1 byte = 254 addresses, 0 and 255 have special meaning). The second byte is the destination. On an 8 node setting (the default), this is a bitmask, and 255 (FF) is broadcast. On a "large" cluster,  this address is the individual node address, and 255 (FF) is still broadcast. You gain number of nodes, but loose directed broadcast (say, I want to send something to node 1, 2 and 6, I would use a destination of 9 in the 8 node mode, but in extended mode I have to send 3 individual frames). Then the status. This can be a static status (the packet gets back to the originator) or a counter status (each time a node processes the frame, it decreases the status) or a no status needed, where the nodes simple forward the original frame, but do not send a status. This is followed by a command. This allows for shorter data segments, since we just need the variable part of the command. Finally, the data, a variable number of bytes terminated by newline (\n).

As we get to higher speeds, I will definitely add the frame check sequence of the original token ring to our design.
10 : import serial
11 : import subprocess
12 : from time import sleep, time
13 :
14 : from docopt import docopt
15 : from sh import date, rmmod
98 : def main(args):
99 : my_addr = int(args['<address>'])
101: ser = serial.Serial('/dev/ttyAMA0', 115200, timeout=1)
111: while not master:
112: logger.debug("I am SLAVE") # Everywhere but node 1
113: tokens = ser.readline()
115: if len(tokens) == 0:
116: logger.debug("No token received in the past 1 second")

What about writes? As an example, in the case of the master controller, it starts its job by sending a KEEPALIVE frame. This is defined by a series of bytes on line 36. Source is 01 (master node), destination is 255 (FF) broadcast, status is FF (no response needed), then command 05 which is a keepalive. Data segment is of length 0 since \n is encountered immediately. This is the shortest well formed frame that can be sent. And that is what the master controller sends on line 152 using ser.write. As long as we keep everything as type bytes, the serial module works well in Python 3.

Pretty simple, overall (!). Well, considering this was all designed over the course of a handful of days. Python really helped.

36: KEEPALIVE = b'\x01\xff\xff\x05\n' # keepalive packet
149: # I am master, or I am taking over
150: if my_addr == 1:
151: sleep(15)
152: ser.write(KEEPALIVE)
153: sleep(1)

We will be creating a module for reuse out of the token.py application, so that other people can use a serial token ring setup themselves. This should be published to pypi. We'll also publish a demo implementation for a master/slave setup.
Deadman's SwitchI'm concluding this article here, as it is already quite long. But I invite you to read about a most interesting device, the Deadman's switch. This was used in our High Altitude Balloon, but it can be used in all kinds of scenarios. Read about it here: http://raspberry-python.blogspot.com/2015/04/deadmans-switch.html

And don't forget to check back regularly for more updates, such as part 3 of this series of articles (the data gathering aspects).

Francois Dion
Categories: FLOSS Project Planets

François Dion: Deadman's Switch

Planet Python - Thu, 2015-04-30 18:59
From Wikipedia:
"A dead man's switch (for other names, see alternative names) is a switch that is automatically operated if the human operator becomes incapacitated, such as through death, loss of consciousness or being bodily removed from control. Originally applied to switches on a vehicle or machine, it has since come to be used to describe other intangible uses like in computer software."
NSC-01For Team Near Space Circus' participation in the Global Space Balloon Challenge with NSC-01, we wanted to make sure that once powered up, and enclosed, we would still have control of the computer cluster and the timeline of events, as to what would happen when. As we devised a network with 7 nodes (see part 1 and also part 2 of the computer network in near space) with a master controller and many slave nodes, we needed a way for the system to wait on a signal from us.

A plain old switch would do the trick of course. But what if the balloon took off and we forgot to flip the switch? Or somebody tripped and let the balloon go? 

Martin DeWitt demoes why we need a deadman's switch
Then the master controller would have stayed in standby mode, sending keep alive frames to the other nodes and we would have had no images, no video, no gps data etc. Not good.

Tethered switchIf you've ever spent any time on a threadmill, no doubt you've encountered a tethered switch. Usually it's a magnetic plug, with a string, terminated by a clip. You clip it to yourself, so if you ever fall down/off the threadmill, you end up yanking the plug off the machine, and it stops right away.

Simple deadman's switch, just needing a string
Since the Raspberry Pi has many GPIO pins, all we needed to do was create a simple circuit between two of them that, once interrupted, would signal that it was time for the master controller to go to work.

We will need two GPIO pins, how about GPIO17 and 27?Why two GPIOS? We could have connected a GPIO to 3V3 and GND through resistors (to protect/limit current), to ensure LOW and HIGH modes. But, trying to keep things as simple as possible from a hardware perspective (software doesn't weigh anything, hardware does), using two GPIOs made a lot of sense. Set one GPIO as input, one as output, raise the output HIGH, the input now sees a value of 1. Open the circuit (by pulling the wire out), and the input no longer sees HIGH, it now reads 0.

Our sponsors (bottom half of payload) with IR cam
radar reflector on the left, deadman's switch on right w/carabiner
A string attached on one end to the wire sticking out of the side of the payload and on the other end to a carabiner clip is really all that was needed.

Deadman's switch code
We've already covered the serial port, sh and docopt in part 2 of the computer network in near space. If you are wondering about these things (and lines 98 to 101 in the code below) I urge you to go and read that article first. I've left here the core of what is needed for implementing the software side of the deadman's switch. We first need the GPIO module. On line 9, we import it as gpio (because uppercase is usually reserved for constants). Then on line 102 we set up the gpio module to operate in BOARD mode. That means physical board pin numbers. In the field, you can always count pins, but you might not have a GPIO map handy... But if you prefer Broadcom nomenclature there is a mode for that too.

So GPIO17 is the 6th pin on the bottom and GPIO27 is the 7th. Since odd pins are at the bottom and even at the top, this means pin 11 and 13. Line 103 sets up pin 11 to be an output, and line 104 sets up pin 13 to be an input. Finally, line 105 "arms" the deadman's switch by setting pin 11 to HIGH. Pin 13 should now be reading a 1 instead of a 0.

9: import RPi.GPIO as gpio
98: def main(args):
99: my_addr = int(args['<address>'])
101: ser = serial.Serial('/dev/ttyAMA0', 115200, timeout=1)
102: gpio.setmode(gpio.BOARD)
103: gpio.setup(11, gpio.OUT)
104: gpio.setup(13, gpio.IN)
105: gpio.output(11, gpio.HIGH)

We are now going into the actual functionality of the switch. We establish a simple while loop on line 161, reading pin 13. As long as we see 1, the circuit is closed and on line 162 we send a KEEPALIVE frame to the other nodes (see previous article). We also sleep for 1 second on line 163 (no need to poll faster than that). The moment we get a 0, the while loop exits, and before starting the master controller on line 165, we log our launch time on line 164 (the logging aspects will be in a future article).

160: # deadman's switch
161: while gpio.input(13) == 1:
162: ser.write(KEEPALIVE)
163: sleep(1)
164: logger.debug("We are launching! (on {})".format(datetime.now()))
165: master_controller(ser, counter) # forever controlling the Pi network until I die

And that is it!

This can be implemented in all kinds of different projects. Have fun with it!

Francois Dion, Rich Graham, Brent Wright, Chris Shepard and Jeff Clouse
Carabiner clipped to my belt while Jeff adds redundant safety stringsFrancois Dion
Categories: FLOSS Project Planets

FSF Blogs: Friday Free Software Directory IRC meetup: May 1

GNU Planet! - Thu, 2015-04-30 18:51

Join the FSF and friends today, Friday, May 1, from 2pm to 5pm EDT (18:00 to 21:00 UTC) to help improve the Free Software Directory by adding new entries and updating existing ones. We will be on IRC in the #fsf channel on freenode.

Tens of thousands of people visit directory.fsf.org each month to discover free software. Each entry in the Directory contains a wealth of useful information, from basic category and descriptions, to providing detailed info about version control, IRC channels, documentation, and licensing info that has been carefully checked by FSF staff and trained volunteers.

While the Free Software Directory has been and continues to be a great resource to the world over the past decade, it has the potential of being a resource of even greater value. But it needs your help!

If you are eager to help and you can't wait or are simply unable to make it onto IRC on Friday, our participation guide will provide you with all the information you need to get started on helping the Directory today!

Categories: FLOSS Project Planets

Friday Free Software Directory IRC meetup: May 1

FSF Blogs - Thu, 2015-04-30 18:51

Join the FSF and friends today, Friday, May 1, from 2pm to 5pm EDT (18:00 to 21:00 UTC) to help improve the Free Software Directory by adding new entries and updating existing ones. We will be on IRC in the #fsf channel on freenode.

Tens of thousands of people visit directory.fsf.org each month to discover free software. Each entry in the Directory contains a wealth of useful information, from basic category and descriptions, to providing detailed info about version control, IRC channels, documentation, and licensing info that has been carefully checked by FSF staff and trained volunteers.

While the Free Software Directory has been and continues to be a great resource to the world over the past decade, it has the potential of being a resource of even greater value. But it needs your help!

If you are eager to help and you can't wait or are simply unable to make it onto IRC on Friday, our participation guide will provide you with all the information you need to get started on helping the Directory today!

Categories: FLOSS Project Planets
Syndicate content