Feeds

Visitors Voice: That is why we sponsor the Search API Solr module

Planet Drupal - Mon, 2014-10-20 06:03
Since june 2014 we sponsor the Search API Solr module. There are no strings attached, and we sponsor the maintainer Thomas Seidl a.k.a Drunken Monkey with a couple of hours every month that he can spend as he likes. It could be bug fixing, features asked for or working on the Drupal 8 version. We […]
Categories: FLOSS Project Planets

Calligra Gemini - now also for Linux :)

Planet KDE - Mon, 2014-10-20 04:07

Some people may remember earlier this year when Krita Gemini became (to my knowledge) the first open source software to become greenlit on Steam. For those who don't, yeah, that really happened ;) Krita Gemini was a project created in cooperation between the KDE community's Calligra team, the little software consultancy KO GmbH, and a large semiconductor manufacturer named Intel, who had some devices they needed to be able to show off. Krita Gemini is available on the Steam store, though not yet for Linux (as it turns out, Steam packaging for Linux is even more awkward than building stand-alone installers for Windows, an odd sort of situation for us used to sensible package managers)


Earlier this year (late April 2014) the team from KO and Calligra which built Krita Gemini had a teleconference with the Intel team, and we agreed that other applications would be well suited to a similar attention, and we came up with the idea of building Calligra Gemini, an application which would encapsulate Words and Stage, Calligra's word processor and presentation tool respectively, in the same way that Krita Gemini encapsulates Krita, with automatic switching between the existing desktop UX and a new touch friendly UX created for the purpose. Over the last little while, i've been posting builds on the project minisite (along with release notes and screenshots and such).


So now, with the initial work on that project reaching its conclusion, i decided that it was time to expose a few more people to it than what's been the case so far. So, over the course of this weekend, between making some tasty bread, cleaning and cooking dinner, i have been working on some packages for people who don't run Windows. Specifically, i have made a set of packages for openSUSE (just 13.1, in various guises, for now - others will follow), and they're available right here (and also shown on the project's minisite linked above)


Finally, i also released a short story i've been writing over the last couple of weeks (while waiting on the editors to get back to me on the novel i've also been working on). This is relevant here because i have been dogfooding; it was written entirely using Calligra Gemini, and the pdf and ePub versions were produced using the Calligra features as well. Finally, the work is stored in a git repository, which is also controlled by Calligra Gemini's support for using Git as cloud storage. The story is available as pdf and ePub on my deviantArt page :)

The word of the day is: Geiko
Categories: FLOSS Project Planets

Michal Čihař: Enca 1.16

Planet Debian - Mon, 2014-10-20 04:00

As a first tiny project in this HackWeek, Enca 1.16 has been just released. It mostly brings small code cleanups and missing aliases for languages, but fixes also some minor bugs found by Coverity Scan.

If you don't know Enca, it is an Extremely Naive Charset Analyser. It detects character set and encoding of text files and can also convert them to other encodings using either a built-in converter or external libraries and tools like libiconv, librecode, or cstocs.

Full list of changes for 1.16 release:

  • Fixed typo in Belarusian language name
  • Added aliases for Chinese and Yugoslavian languages

Still enca is in maintenance mode only and I have no intentions to write new features. However there is no limitation to other contributors :-).

You can download from http://cihar.com/software/enca/.

Filed under: Enca English SUSE | 0 comments | Flattr this!

Categories: FLOSS Project Planets

What do you require from KTracks?

Planet KDE - Mon, 2014-10-20 03:59

In a series of articles we illustrate the user centered design process from scratch, based on a still missing application in the KDE world: KTracks, an endurance activity tracker. In this part #2 we talk about requirements.

Keep on reading: What do you require from KTracks?

Categories: FLOSS Project Planets

Peter Bengtsson: django-html-validator

Planet Python - Mon, 2014-10-20 00:48


A couple of weeks ago we had accidentally broken our production server (for a particular report) because of broken HTML. It was an unclosed tag which rendered everything after that tag to just plain white. Our comprehensive test suite failed to notice it because it didn't look at details like that. And when it was tested manually we simply missed the conditional situation when it was caused. Neither good excuses. So it got me thinking how can we incorporate HTML (html5 in particular) validation into our test suite.

So I wrote a little gist and used it a bit on a couple of projects and was quite pleased with the results. But I thought this might be something worthwhile to keep around for future projects or for other people who can't just copy-n-paste a gist.

With that in mind I put together a little package with a README and a setup.py and now you can use it too.

There are however some caveats. Especially if you intend to run it as part of your test suite.

Caveat number 1

You can't flood htmlvalidator.nu. Well, you can I guess. It would be really evil of you and kittens will die. If you have a test suite that does things like response = self.client.get(reverse('myapp:myview')) and there are many tests you might be causing an obscene amount of HTTP traffic to them. Which brings us on to...

Caveat number 2

The htmlvalidator.nu site is written in Java and it's open source. You can basically download their validator and point django-html-validator to it locally. Basically the way it works is java -jar vnu.jar myfile.html. However, it's slow. Like really slow. It takes about 2 seconds to run just one modest HTML file. So, you need to be patient.

Categories: FLOSS Project Planets

Francois Marier: LXC setup on Debian jessie

Planet Debian - Sun, 2014-10-19 22:00

Here's how to setup LXC-based "chroots" on Debian jessie. While this is documented on the Debian wiki, I had to tweak a few things to get the networking to work on my machine.

Start by installing (as root) the necessary packages:

apt-get install lxc libvirt-bin debootstrap Network setup

I decided to use the default /etc/lxc/default.conf configuration (no change needed here):

lxc.network.type = veth lxc.network.flags = up lxc.network.link = virbr0 lxc.network.hwaddr = 00:FF:AA:xx:xx:xx lxc.network.ipv4 = 0.0.0.0/24

but I had to make sure that the "guests" could connect to the outside world through the "host":

  1. Enable IPv4 forwarding by putting this in /etc/sysctl.conf:

    net.ipv4.ip_forward=1
  2. and then applying it using:

    sysctl -p
  3. Ensure that the network bridge is automatically started on boot:

    virsh -c lxc:/// net-start default virsh -c lxc:/// net-autostart default
  4. and that it's not blocked by the host firewall, by putting this in /etc/network/iptables.up.rules:

    -A INPUT -d 224.0.0.251 -s 192.168.122.1 -j ACCEPT -A INPUT -d 192.168.122.255 -s 192.168.122.1 -j ACCEPT -A INPUT -d 192.168.122.1 -s 192.168.122.0/24 -j ACCEPT
  5. and applying the rules using:

    iptables-apply
Creating a container

Creating a new container (in /var/lib/lxc/) is simple:

sudo MIRROR=http://http.debian.net/debian lxc-create -n sid64 -t debian -- -r sid -a amd64

You can start or stop it like this:

sudo lxc-start -n sid64 -d sudo lxc-stop -n sid64 Connecting to a guest using ssh

The ssh server is configured to require pubkey-based authentication for root logins, so you'll need to log into the console:

sudo lxc-stop -n sid64 sudo lxc-start -n sid64

then install a text editor inside the container because the root image doesn't have one by default:

apt-get install vim

then paste your public key in /root/.ssh/authorized_keys.

Then you can exit the console (using Ctrl+a q) and ssh into the container. You can find out what IP address the container received from DHCP by typing this command:

sudo lxc-ls --fancy Fixing Perl locale errors

If you see a bunch of errors like these when you start your container:

perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "fr_CA.utf8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C").

then log into the container as root and use:

dpkg-reconfigure locales

to enable the same locales as the ones you have configured in the host.

Categories: FLOSS Project Planets

Vasudev Ram: Published my first presentation on SpeakerDeck - using Python

Planet Python - Sun, 2014-10-19 21:33

By Vasudev Ram



SpeakerDeck is an online presentation service roughly like SlideShare. SpeakerDeck seems to have been created by Github Inc.

I just published my first presentation on SpeakerDeck. It is a quickstart tutorial for the vi editor. Note: vi, not vim. I had written the tutorial some years ago, when vim was not so widely used, and vi was the most common text editor on Unix systems.

About the tutorial:

I first wrote this vi quickstart tutorial for some friends at a company where I worked. They were Windows and network system administrators without prior Unix experience, and had been tasked with managing some Unix servers that the company had bought for client work. Since I had a Unix background, they asked me to create a quick tutorial on vi for them, which I did.

Later on, after learning the basics of vi from it, and spending some days using vi to edit Unix configuration files, write small shell scripts, etc., they told me that they had found the tutorial useful in getting up to speed on vi quickly.

So, some time later, I thought of publishing it, and sent an article proposal to Linux For You magazine (an Indian print magazine about Linux and open source software). The proposal was accepted and the article was published.

About generating the tutorial as PDF and uploading it to SpeakerDeck:

The original vi quickstart tutorial was in text format. Last year I wrote XMLtoPDFBook (as an application of xtopdf, my Python toolkit for PDF creation), which allows the user to create simple PDF e-books from XML files. So I converted the vi tutorial to XML format (*) and used it to test XMLtoPDFBook. I therefore had the tutorial available in PDF format.

(*) All you have to do for that - i.e. to convert a text file to the XML format supported by XMLtoPDFBook - is to insert each chapter's text as a <chapter> element in the XML file. Then give the XML file as the input to XMLtoPDFBook, and you're done.

SpeakerDeck requires that presentations be uploaded in PDF format. It then converts them to slides. So I thought it would be a good test of SpeakerDeck and/or xtopdf, to upload this PDF generated by xtopdf to SpeakerDeck, and see how the result turned out. I did that today. Then I viewed the resulting SpeakerDeck presentation. It was good to see that the conversion turned out well, AFAICT. All pages seem to have got converted correctly into slides.

The presentation can be viewed here:

A vi quickstart tutorial

If you prefer plain text to presentations, you can read the vi quickstart tutorial here.

- Vasudev Ram - Dancing Bison Enterprises

Click here to signup for email notifications about new products and services from Vasudev Ram.

Contact Page

Share | Vasudev Ram
Categories: FLOSS Project Planets

Neil Williams: OpenTAC – an automation lab in a box

Planet Debian - Sun, 2014-10-19 18:34

I’ve previously covered running LAVA on ARM devices, now that the packages are in Debian. I’ve also covered setting up the home lab, including the difficulty in obtaining the PDU and relying on another machine to provide USB serial converters with inherent problems of needing power to keep the same devices assigned to the same ser2net ports.

There have been ideas about how to improve the situation. Conferences are a prime example – setting up a demo involving LAVA means bringing a range of equipment, separate power bricks, separate network switches (with power bricks), a device of some kind to connect up the USB serial converters (and power brick) and then the LAVA server (with SATA drive and power brick) – that is without the actual devices and their cables and power. Each of those power cables tend to be a metre long, with networking and serial, it quickly becomes a cable spaghetti.

Ideas around this also have application inside larger deployments, so the hardware would need to daisy-chain to provide services to a rack full of test devices.

The objective is a single case providing network, power and serial connectivity to a number of test devices over a single power input and network uplink. Naturally, with a strong free software and open development bias, the unit will be Open Hardware running Debian, albeit with a custom Beaglebone Linux kernel. It’s a Test Automation Controller, so we’re using the name OpenTAC.

Progress

Open hardware ARM device running Debian to automate tests on 4 to 8 devices, initially aimed at LAVA support for Linaro engineers. Power distribution, serial console, network and optional GPIO extensions.

The design involves:

  • A Beaglebone Black (revC)
    • USB hotplug support required, certainly during development.
  • Custom PCB connected as a Beaglebone Cape, designed by Andy Simpkins.
  • Base board provides 4 channels:
    • 5V Power – delivered over USB
    • Ethernet – standard Cat5, no LEDs
    • Serial connectivity
      • RS232
      • UART
    • GPIO
  • Internal gigabit network switch
  • Space for a board like a CubieTruck (with SATA drive) to act as LAVA server
  • Daughter board:
    • Same basic design as the base board, providing another 4 channels, equivalent to the base channels. When the daughter board is fitted, a second network switch would be added instead of the CubieTruck.
  • Power consumption measurement per channel
    • queries made via the Beaglebone Black over arbitrary time periods, including during the test itself.
  • The GPIO lines can be used to work around issues with development boards under test, including closing connections which may be required to get a device to reboot automatically, without manual intervention.
  • Serial connections to test devices can be isolated during device power-cycles – this allows for devices which pull power over the serial connection. (These are typically hardware design issues but the devices still need to be tested until the boards can be modified or replaced.)
  • Thermal control, individual fan control via the Beaglebone Black.
  • 1U case – rackable or used alone on the desk of developers.
  • Software design:
    • lavapdu backend module for PDU control (opentac.py) & opentac daemon on the BBB
      • telnet opentac-01 3225
    • ser2net for serial console control
      • telnet opentac-01 4000

The initial schematics are now complete and undergoing design review. A lot of work remains …

Categories: FLOSS Project Planets

Dirk Eddelbuettel: littler 0.2.1

Planet Debian - Sun, 2014-10-19 17:09

A new maintenance release of littler is available now.

The main change are a few updates and extensions to the examples provided along with littler. Several of those continue to make use of the wonderful docopt package by Edwin de Jonge. Carl Boettiger and I are making good use of these littler examples, particularly to install directly from CRAN or GitHub, in our Rocker builds of R for Docker (about which we should have a bit more to blog soon too).

Full details for the littler release are provided as usual at the ChangeLog page.

The code is available via the GitHub repo, from tarballs off my littler page and the local directory here. A fresh package has gone to the incoming queue at Debian; Michael Rutter will probably have new Ubuntu binaries at CRAN in a few days too.

Comments and suggestions are welcome via the mailing list or issue tracker at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Thorsten Alteholz: Key transition, move to stronger key

Planet Debian - Sun, 2014-10-19 16:44

Finally I was able to do the enormous paperwork (no, it is not that much) to switch my old 1024D key to a new 4096R one. I was a bit afraid that there might be something bad happening, but my fear was without any reason. After the RT bug was closed, I could upload and sent signed emails to mailing lists. So thanks alot to everyone involved.

old key, 0xD362B62A54B99890 pub 1024D/54B99890 2008-07-23 Key fingerprint = 36E2 EDDE C21F EC8F 77B8 7436 D362 B62A 54B9 9890 uid Thorsten Alteholz (...) sub 4096g/622D94A8 2008-07-23 new key, 0xA459EC6715B0705F pub 4096R/0xA459EC6715B0705F 2014-02-03 Schl.-Fingerabdruck = C74F 6AC9 E933 B306 7F52 F33F A459 EC67 15B0 705F uid [ uneing.] Thorsten Alteholz (...) sub 4096R/0xAE861AE7F39DF730 2014-02-03 Schl.-Fingerabdruck = B8E7 6074 5FF4 C707 1C77 870C AE86 1AE7 F39D F730 sub 4096R/0x96FCAC0D387B5847 2014-02-03 Schl.-Fingerabdruck = 6201 FBFF DBBD E078 22EA BB96 96FC AC0D 387B 5847
Categories: FLOSS Project Planets

Published my first presentation on SpeakerDeck – using Python

LinuxPlanet - Sun, 2014-10-19 15:30

By Vasudev Ram



SpeakerDeck is an online presentation service roughly like SlideShare. SpeakerDeck seems to have been created by Github Inc.

I just published my first presentation on SpeakerDeck. It is a quickstart tutorial for the vi editor. Note: vi, not vim. I had written the tutorial some years ago, when vim was not so widely used, and vi was the most common text editor on Unix systems.

About the tutorial:

I first wrote this vi quickstart tutorial for some friends at a company where I worked. They were Windows and network system administrators without prior Unix experience, and had been tasked with managing some Unix servers that the company had bought for client work. Since I had a Unix background, they asked me to create a quick tutorial on vi for them, which I did.

Later on, after learning the basics of vi from it, and spending some days using vi to edit Unix configuration files, write small shell scripts, etc., they told me that they had found the tutorial useful in getting up to speed on vi quickly.

So, some time later, I thought of publishing it, and sent an article proposal to Linux For You magazine (an Indian print magazine about Linux and open source software). The proposal was accepted and the article was published.

About generating the tutorial as PDF and uploading it to SpeakerDeck:

The original vi quickstart tutorial was in text format. Last year I wrote XMLtoPDFBook (as an application of xtopdf, my Python toolkit for PDF creation), which allows the user to create simple PDF e-books from XML files. So I converted the vi tutorial to XML format (*) and used it to test XMLtoPDFBook. I therefore had the tutorial available in PDF format.

(*) All you have to do for that - i.e. to convert a text file to the XML format supported by XMLtoPDFBook - is to insert each chapter's text as a <chapter> element in the XML file. Then give the XML file as the input to XMLtoPDFBook, and you're done.

SpeakerDeck requires that presentations be uploaded in PDF format. It then converts them to slides. So I thought it would be a good test of SpeakerDeck and/or xtopdf, to upload this PDF generated by xtopdf to SpeakerDeck, and see how the result turned out. I did that today. Then I viewed the resulting SpeakerDeck presentation. It was good to see that the conversion turned out well, AFAICT. All pages seem to have got converted correctly into slides.

The presentation can be viewed here:

A vi quickstart tutorial

If you prefer plain text to presentations, you can read the vi quickstart tutorial here.

- Vasudev Ram - Dancing Bison Enterprises

Click here to signup for email notifications about new products and services from Vasudev Ram.

Contact Page

Share | var addthis_config = {"data_track_clickback":true}; Vasudev Ram

Categories: FLOSS Project Planets

KDE Telepathy 0.9.0 Released

Planet KDE - Sun, 2014-10-19 14:54

Today we released the 0.9 series of KDE Telepathy, a multiprotocol instant messaging client for Plasma.

Amongst the many bugfixes the following features are worth highlighting.

OTR Encryption

One of the most recurring feature requests we've seen over the years was OTR encryption. OTR builds an extra level of encryption on top of the existing protocol embedding all data in the mesasges themselves. This prevents any potential sniffing from the server as well as providing perfect forward secrecy and non-deniable authentication

This summer Marcin Ziemski volunteered to step up to the task and implemented full support for OTR3, including shared secret authentication and key management.

A full video can be seen here

Group Chats

All aspects of group chats recieved a massive overhaul, there is a new join chat dialog, one can stay logged into a room when you close the window and we've redesigned the main chat window to be easier when talking to multiple people.

Video Calls Revisited

Video calls have had both a technical and UI overhaul. Diane Trout ported a lot of QtGstreamer and the CallUI to GStreamer 1.0.

This port allowing us to future proof for the new technologies and have more chance of working calls.

In addition Ekaitz Zárraga has rehauled the UI bringing it into the 21st century which can be seen in the screenshot.

We encourage you to try it out. Depending on your and your partner's setup, you might now have a good video chat experience. For best results use a real jabber server (Not Facebook or Google!) the same client and be sure to have all GStreamer codecs installed.

Speed Improvements and Bug Fixing

Naturally the release brings a slew of bug fixes and improvements not listed here. Specificially the contact list has undergone extensive profiling and optimising since 0.8.

Fundraising

You may notice some of the features were highlighted in the report from our previous sprint report. If you like the new features be sure to contribute to our winter fundraiser so we can keep doing sprints in future.



Categories: FLOSS Project Planets

Rob Galanakis: PracticalMayaPython: RuntimeError: Internal C++ object (PySide.QtGui.QStatusBar) already deleted.

Planet Python - Sun, 2014-10-19 13:30

TLDR: If you get that error for the code on page 163, see the fix at https://github.com/rgalanakis/practicalmayapython/pull/2/files

In August, reader Ric Williams noted:

I’m running Maya 2015 with Windows 7 64-bit. On page 163 when we open the GUI using a Shelf button, the GUI status bar does not work, (it works when called from outside Maya). This RuntimeError appears: RuntimeError: Internal C++ object (PySide.QtGui.QStatusBar) already deleted.

I no longer have Maya installed so I couldn’t debug it, but reader ragingViking (sorry, don’t know your real name!) contributed a fix to the book’s GitHub repository. You can see the fix here: https://github.com/rgalanakis/practicalmayapython/pull/2/files
And you can see the issue which has more explanation here: https://github.com/rgalanakis/practicalmayapython/issues/1

Thanks again to Ric and ragingViking. I did my best to test the code with various versions of Maya but definitely missed some things (especially those which required manual testing). If you find any other problems, please don’t hesitate to send me an email!

Categories: FLOSS Project Planets

Bryan Pendleton: A day at ARK 2000

Planet Apache - Sun, 2014-10-19 13:15

We had the opportunity to spend a glorious day at ARK 2000, which is one of the facilities of a rather unusual organization called the Performing Animal Welfare Society.

Through the generosity of friends, we found ourselves with a pair of tickets to one of PAWS's annual fund-raisers, the "Elephant Grape Stomp." This event is sort of an open house to visit the sanctuary, which is located in the Sierra Nevada foothills, about 2 hours from our house.

During the event, we were able to visit three parts of the sanctuary:

  • The cats and bears area, which holds Siberian Tigers, African Lions, and American Black Bears, as well as at least one leopard (who was feeling unsocial so we didn't see her).
  • Bull Mountain, where PAWS has a facility for two male Asian Elephants (held separately, but adjacently)
  • The Asian and African Elephant compound, where about 10 female elephants are living in two separate areas.

At all three locations, booths were set up with information, local restaurants were serving delicious food, and local wineries (from the thriving Murphy's wine region) were pouring scrumptious Sierra Nevada wines.

Visiting ARK 2000 is sort of an unusual experience.

It is not a zoo, and the animals are not there to entertain you.

And it's not a breeding facility; they aren't trying to produce more of these animals here.

I would say it's more like a senior citizen facility for animals who have been taken from rather difficult circumstances and given a dramatically more humane situation in which to live out their lives.

Still, it was very nice and peaceful. The weather was superb, and we had all the time we wanted to stand quietly and watch the animals as they relaxed, contentedly, in their space.

Several of the staff were on hand, including the primary elephant keeper and the primary bear keeper, to answer questions and help explain what we were seeing and why.

And some of the sights were indeed unusual, such as the three custom transport containers that they use to move the elephants long distances (most recently used to bring three elephants from Toronto to California). This is not the sort of item you can get at your local hardware store!

For example, keeping bull elephants is rather different than keeping female elephants. The extraordinary strength and aggressive tendencies of the bull elephants means that they must be located in a particular situation, with a pen of fantastic strength. In some of the pictures, you can see, I think, the difference in the containment fences for the male elephant as opposed to those for the females. (Of course, the females are plenty strong enough; apparently they like to uproot the oak trees just for fun, and so the facility has built massive protective cages around some of the trees to try to keep the ladies from clearing them out entirely.)

I think the highlight, for me, were the 4 Siberian Tigers, absolutely majestic animals, who were all together in one pen and were particularly active, bounding around their space, playing together, alertly aware of everything and everyone that was around them.

There's lots of information about PAWS on their website. It's not obvious what is going to come of the organization now that its founder, Pat Derby, has passed on. Still, from all evidence they are still going strong, and hopefully they will find a new generation to continue their excellent work.

Categories: FLOSS Project Planets

Calvin Spealman: Farewell to XMLHttpRequest; Long live window.fetch!

Planet Python - Sun, 2014-10-19 10:04
The days of XMLHttpRequest and weird choices for capitalization are numbered. WhatWG has a spec ready for some time now to replace it: window.fetch. Just look at how easy it is.



Just look at how nicer that is all with soon-to-be native APIs. But you don't have to wait, because there is a polyfill available. Start using the Fetch Polyfill in your projects today.
Categories: FLOSS Project Planets

BangPypers: October 2014 Meetup report

Planet Python - Sun, 2014-10-19 06:57

The October Bangpypers meetup happened at the InMobi office near Bellandur. Sanketsaurav facilitated the workshop. Krace helped the meetup as a volunteer.

The workshop was focussed on build REST Service using TastyPie. The workshop started at 10.25 and wen t to till 1.45. Sanket explained all the concepts required to build REST service in depth with examples.

There were about 35 participants for the workshop.

Find the content of the workshop here

Special thanks to Iliyas Shirol for being a great help in organizing the event at InMobi.

We also have a mailing list where discussion happens about Python.

Categories: FLOSS Project Planets

Python Diary: Building a CARDIAC Assembler in Python

Planet Python - Sun, 2014-10-19 06:44

In my last article I gave a fully working example of a CARDIAC CPU simulator in Python. This article will continue down the path of creating a build toolchain for the Cardiac. Due to how the Cardiac accepts data from the outside world, namely in the form of a deck of cards or plain numbers, developing an assembler was a bit more difficult than a traditional bytecode assembler. At least when I build a binary assembler, I assemble the bytecodes in-memory. This ensures that all memory pointers are correctly pointing to the proper memory addresses, and also eliminates errors due to how information is stored. This is similar to how the MS-DOS DEBUG.EXE worked to build .COM files. It was simple and yet very effective. This tends to be the model I normally follow, as it makes debugging the virtual machine very easy. This is how I built up my simple-cpu project, and now I am in the process of enabling dynamic memory relocation to better enable the loading binary files. I also recently added a full memory map interface to it as well, so now memory mapped I/O is possible, and I plan on using that to allow my binaries to directly draw onto an SDL surface. Anyways, onward to the Cardiac Assembler, as that is the real reason your here today!

As of this post, you can view all the source code for this post and the last one on my Python Experiments Bitbucket repo.

The assembler is going to use just the standard Python library modules, so no fancy GNU Bison or YACC here. First, let's begin by defining what our language will look like, it's overall syntax. Here is deck1.txt turned into an Assembly program:

# This deck1.txt converted over to ASM format. # Lines which start with a hash are comments. # Here we declare our variables in memory for use. var count = 0 var i = 9 # This is needed to add the special Cardiac bootstrap code. bootstrap # Program begins here. CLA STO $count label loop CLA $i TAC $endloop OUT $count CLA $count ADD STO $count CLA $i SUB STO $i JMP $loop label endloop HRS # End of program. end

To make developing programs for the CARDIAC easier, the assembler is going to introduce the concept of variable storage, and labels. The first few lines here that begin with var are basically setting aside memory addresses to store these variables in question. The bootstrap statement is more of a Macro as it just writes out a basic bootstrap loader for use on CARDIAC. There is also an alternative bootloader, which uses a second stage boot program to load in your code. This has the advantage of being able to load in very large programs without needing a very large deck. I'd recommend playing around with both options when assembling your programs. The bootloader was custom built code made by me, here is an assembly listing of it:

INP 2 JMP 0 INP 89 INP 1 INP 90 CLA 89 INP 91 ADD INP 92 STO 89 INP 93 CLA 98 INP 94 SUB INP 95 STO 98 INP 96 TAC 3 INP 97 JMP 89 INP 98 INP 13 INP 2 JMP 89

The bootloader is passed in the size of the deck to load, and loops over each card to load in your program, this means that your input program will no longer need to have lots of address markings. It can also be used to load in other data into a specific memory address. I am planning on updating the bootloader code to also act like a subroutine, so you could call it to load additional data into memory. Okay, so onto the actual Assembler now.

from cmd import Cmd from cStringIO import StringIO import shlex, sys class AsmError(Exception): pass class Assembler(Cmd): """ I am sure this could be done better with say GNU Bison or Yacc, but that's more complicated than needed for a simple assembler. """ op_map = { 'inp': 0, 'cla': 1, 'add': 2, 'tac': 3, 'sft': 4, 'out': 5, 'sto': 6, 'sub': 7, 'jmp': 8, 'hrs': 9, } padding = '00' def configure(self): self.start = self.addr = None self.pc = 0 #: Allows us to keep track of the program pointer. self.var_map = {} #: This is used to keep track of variables. self.labels = {} #: Stores the label names, and where they point to. self.buffer = StringIO() #: This is our buffer where we will store the CARDIAC deck self.size = 0 def emptyline(self): """ This is requried due to how the Python Cmd module works... """ pass def unknown_command(self, line): self.stdout.write('*** Unknown syntax: %s\n'%line) @property def ptr(self): """ This will always give the proper pointer in the deck. """ if self.addr: return self.addr return self.pc def write_cards(self, *card_list): """ Helper fuction to make life easier. """ for card in card_list: self.buffer.write('%s\n' % card) self.pc += len(card_list) #: Increment the program pointer. def write_addr(self): """ This method will only write out the address if we're in that mode. """ if self.addr: self.write_cards('0%s' % self.addr) self.addr +=1 self.size +=1

The first thing to notice here, is that the assembler is a subclass of Cmd, which is a command line parser. I choose to use a command-line parser and it makes things easier and can also be used interactively if I need to debug or later want to enable that feature. The first thing we declare in this class, is a dictionary called op_map, which maps our op codes to actual byte codes. This makes it efficient to write the output and also add new opcodes in the future. The first method here, configure() could have well been an override of __init__(), but I choose to just have it a separate method that I can call manually. The next 2 methods are specific to the command parser, and tell it how to handle empty lines and invalid commands. The ptr property added here is to make it transparent to the code the proper location in the deck at runtime. This is required due to how the Cardiac bootstraps code. You cannot just load in RAW code, you need to bootstrap your deck of cards, and the deck itself needs to keep track at which memory locations each of it's operations are being placed in. Since I offer 2 modes of assembly here, and also support RAW assembly, there are different ways the exact memory pointer is obtained for runtime variables and jumps. The next 2 methods are for writing specific card types, one being a normal list of cards, while the other being an address card. The address cards are only used if you assemble using bootstrap, the original Cardiac bootstrap program.

Since this is a command processor Python subclass, next we are going to put in some commands that our source code can use to perform specific tasks:

def do_exit(self, args): return True def do_bootstrap(self, args): """ Places some basic bootstrap code in. """ self.addr = 10 self.start = self.addr #: Updates all required address variables. self.write_cards('002', '800') self.pc = self.start def do_bootloader(self, args): """ Places a Cardiac compatible bootloader in. """ self.write_cards('002', '800') addr = 89 #: This is the start address of the bootloader code. for card in ('001', '189', '200', '689', '198', '700', '698', '301', '889', 'SIZE'): self.write_cards('0%s' % addr, card) addr+=1 self.write_cards('002', '889') self.pc = 1 def do_var(self, args): """ Creates a named variable reference in memory, a simple pointer. """ s = shlex.split(args) if len(s) != 3 or s[1] != '=': raise AsmError('Incorrect format of the "var" statement.') if s[0] in self.var_map: raise AsmError('Variable has been declared twice!') value = int(s[2]) self.var_map[s[0]] = '000'+str(value) def do_label(self, args): """ Creates a named label reference in memory, a simple pointer. """ if args == '': raise AsmError('Incorrect format of the "label" statement.') if args in self.labels: raise AsmError('Label has been declared twice!') ptr = '00'+str(self.ptr) self.labels[args] = ptr[-2:]

Okay, there's a fair amount to explain with this code. Firstly, the two first methods here, bootstrap and bootloader are obviously Cardiac specific, and it's doubtful that a homemade Assembler will even need such things. The bootstrap() method sets up some variables required for that mode of assembly, namely the address variables used to keep track which memory location we are at. We also write 2 basic cards, the bootstrap that Cardiac needs to load your program in a real or simulated Cardiac. The next method, bootloader is a bit more complex, it writes the same initial bootstrap required by all cardiac programs, but also writes out a second stage bootloader program which is responsible for loading in your program. Once I get to the guide about creating a compiler, the compiler will automatically choose which mode of assembly will be used based on the program being compiled.

The next two very important methods, do_var, and do_label are responsible for controlling the variable and label system of the assembler. They make it easy to set a side a memory address for use as a variable, and to place in a label within your code so that you may JMP to it. If these didn't exist, you would be forced to keep track of memory addresses yourself, and if you update your program, you will also need to update the memory addresses... So, variables and labels keep track of all that for you, and the memory addresses are generated automatically during assembly time. Both of these methods should be fairly easy to understand what they are doing. They are storing the variable and label name into a hash along with the needed metadata.

def default(self, line): """ This method is the actual lexical parser for the assembly. """ if line.startswith('#'): return s = shlex.split(line) op, arg = s[0].lower(), '00' if len(s) == 2: if s[1].startswith('$'): arg = '*%s' % s[1][1:] else: arg = self.padding+s[1] arg = arg[-2:] if op in self.op_map: self.write_addr() self.write_cards('%s%s' % (self.op_map[op], arg)) else: self.unknown_command(line) def do_end(self, args): """ Finalizes your code. """ for var in self.var_map: ptr = self.padding+str(self.ptr) self.write_addr() self.write_cards(self.var_map[var][-3:]) self.labels[var] = ptr[-2:] if self.start: self.write_cards('002', '8%s' % self.start) self.buffer.seek(0) buf = StringIO() for card in self.buffer.readlines(): if card[1] == '*': #: We have a label. card = '%s%s\n' % (card[0], self.labels[card[2:-1]]) elif card[:4] == 'SIZE': card = '000'+str(self.size-1) card = '%s\n' % card[-3:] buf.write(card) buf.seek(0) print ''.join(buf.readlines()) return True

Now onto the bread and butter of the assembler, these two methods here do most of the heavy lifting during the assembly process. First lets talk about default(), this method is called by the command-line parser when it cannot find the command the end-user attempted to call. Makes sense? So, here is where we place the code to check if any of those lines are assembly instructions and process them accordingly. First we filter out any comments, any line that starts with a hash is a commented line, simple as that. Next, we use the help of shlex module to parse the actual line. This module splits all the tokens into separate array elements, it even works with quotation marks, so take this line for example: echo "Example echo command" will result in only 2 array elements, the first being echo, and the second being the string. In the next line we set some needed defaults for Cardiac cards, so if there is a missing argument it will still work fine on the Cardiac. It is here that we also check the arguments to see if we are using any variables or labels and mark them accordingly in the buffer for the second pass.

The last and final method here do_end is when you place end in your code at the very end. This method is essentially the last pass, and which generates the final assembled code. It gathers together all the variables, and generates a table of pointers to them. Then we write out the required cards to run the program the Cardiac just loaded, if we are using the original bootstrap. The bootloader doesn't use this, the bootloader manages that during runtime. Then we seek the buffer to the beginning and being our last pass through the assembled data. We check for any memory pointer references and fill in the holes as needed in the output code. If using the bootloader, it needs to be passed the size of the program code to be loaded, and this is where we fill that in so that the bootloader can locate the variable. Then finally, we display the assembled Cardiac code to standard output.

You can find all the source for both the simulator and this assembler on my Python Experiments BitBucket page, along with an example deck that counts to 10 in both Assembly and Cardiac ready format. The code assembled by this assembler should run without error on either a real cardiac or a simulated one. You can find a simulator made in JavaScript by a Drexel University professor by following the links through this blog page here: Developing Upwards: CARDIAC: The Cardboard Computer.

Hopefully this guide/article was helpful and inspiring to you, and I hope to have the final part of this guide/toolchain ready for consumption soon, the guide on how to build a Compiler for the Cardiac computer.

Categories: FLOSS Project Planets

Benjamin Mako Hill: Another Round of Community Data Science Workshops in Seattle

Planet Debian - Sat, 2014-10-18 21:19
Pictures from the CDSW sessions in Spring 2014

I am helping coordinate three and a half day-long workshops in November for anyone interested in learning how to use programming and data science tools to ask and answer questions about online communities like Wikipedia, free and open source software, Twitter, civic media, etc. This will be a new and improved version of the workshops run successfully earlier this year.

The workshops are for people with no previous programming experience and will be free of charge and open to anyone.

Our goal is that, after the three workshops, participants will be able to use data to produce numbers, hypothesis tests, tables, and graphical visualizations to answer questions like:

  • Are new contributors to an article in Wikipedia sticking around longer or contributing more than people who joined last year?
  • Who are the most active or influential users of a particular Twitter hashtag?
  • Are people who participated in a Wikipedia outreach event staying involved? How do they compare to people that joined the project outside of the event?

If you are interested in participating, fill out our registration form here before October 30th. We were heavily oversubscribed last time so registering may help.

If you already know how to program in Python, it would be really awesome if you would volunteer as a mentor! Being a mentor will involve working with participants and talking them through the challenges they encounter in programming. No special preparation is required. If you’re interested, send me an email.

Categories: FLOSS Project Planets

Yakuake Skins

Planet KDE - Sat, 2014-10-18 19:43
Yakuake

is a drop-down terminal for Linux. You can drop-down the terminal via the F12 key.

Settings

Es you can see in the settings you have connection via GHNS (http://kde-look.org/index.php?xsortmode=high&page=0&xcontentmode=87) so the easiest way to get a new skin is the Get New Skins search.

But how can you make your own skin?

Make your own skin

A Skin is basically a set of PNG files and a text file naming them along with setting a few properties like image positions and colours. It’s a quite restrictive format, there is no support for vector data or scaling, but on the other side you can change a lot.

Skills

what do you need to make your own skin:

  1. Installed Yakuake for testing (and using)
  2. an Idea
  3. Inkscape (or a image program for the .png files)
Sample

When you go to the Opendesktop.org page in the section Yakuake skins you can grab a skin of mine like

why mine? Because in the download archiv file the original svg files are also included. So it is easy to make new skins with Inkscape.

Breeze-Thin

Breeze Standard

You have to move the files to ~/.kde/share/apps/yakuake/kns_skins/ also when you download skins via GHNS they are located there.

Files
  1. title folder and title.skin
  2. tabs folder and tabs.skin

the setting of the title (window decoration) and tabs bar are located in the two .skin files.

title folder and title.skin [Description] Skin=Breeze-Thin Author=Andreas Email=mail@mail.com Icon=/icon.png

Skin name and icon for the skin selection in the application settings.

[Border] red=61 green=174 blue=233 width=0

When you’d like to have a border all around the terminal window. With width=0 there will be no border used.

[Text] x=25 y=0 red=239 green=240 blue=241 text=Drop-Down Terminal

Window decoration text with colour and position.

[Background] back_image=/title/back.png left_corner=/title/left.png right_corner=/title/right.png

the back_image is important, because the image heigh is used for the title height. So I use in the Breeze-thin theme NO background. I made a transparent (99 % transparent) png file with a size of 1×12. So the title bar is 12 px height. For the left_corner I made also a 99 % transparent png file.

[FocusButton] x=60 y=0 up_image=/title/focus_up.png over_image=/title/focus_over.png down_image=/title/focus_down.png [ConfigButton] x=40 y=0 up_image=/title/config_up.png over_image=/title/config_down.png down_image=/title/config_down.png [QuitButton] x=20 y=0 up_image=/title/quit_up.png over_image=/title/quit_down.png down_image=/title/quit_down.png

On the right area there are three buttons possible. The focus, configure and quit button

The x and y coordinate is for the position. I made every “icon” 20×12 so that the icons are not moved in y direction (y=0) if you have icons without padding than you can use the coordinate for the padding. I’d prefer to make every png file the right (back_image) height. I prefer to made the icons without background, because the background will be used from the back_image. At this three icons I use a background because I made the icons 20 px width so that when you don’t hover the x icon the quit option will also be selected.

For up, over and down you can use different icon files like

  • up
  • over
  • down
tabs folder and tabs.skin [Description] Skin=Breeze-Thin Author=Andreas Email=home@mail.com Icon=/icon.png

Same as in the title.skin file.

[Background] back_image=/tabs/back_image.png left_corner=/tabs/left_corner.png right_corner=/tabs/right_corner.png

The back_image is important for the tabs height so when you want to change the height, you have to change the back_image file. As in the title bar left and right_corner is supported (for rounded- or special corner styles).

[Tabs] x=20 y=0 red=239 green=240 blue=241

Colour of the tabs text. You can only choose one colour. So when you have different colours for the selected (dark) and unselected (light) tabs you have to choose a colour where you can read the text on both tabs. The x and y position if for the starting point of the tabs (20 px from the left border).

separator_image=/tabs/separator.png selected_background=/tabs/selected_back.png selected_left_corner=/tabs/selected_left.png selected_right_corner=/tabs/selected_right.png unselected_background=/tabs/unselected_back.png unselected_left_corner=/tabs/selected_left.png unselected_right_corner=/tabs/selected_right.png

on the tabs bar you have

  1. selected tab
  2. unselected tab
  3. separator

You can choose the

  • selected_background
  • selected_left_corner
  • selected_right_corner

with the left and right corner you can also make something like an firefox australis theme. If you don’t use the left and right_corner the tabs are smaller, because the left and right_corners are added to the tabs width. If the png files don’t have the same size than the back_image file, the back_image file will be shown on the bottom area. so the starting coordinate is the tabs-top area.

the unselected tab support in the yakuake 2.9.9 version only the unselected_background png file. So it is not possible to have the rounded corners, … at the unselected tabs. In future releases the unselected_left_corner and unselected_right_corner are supported.

prevent_closing_image=/tabs/lock.png prevent_closing_image_x=0 prevent_closing_image_y=0

When you use the right mouse on a tab the prevent_closing_image will be shown. I use the same size as for the back_image so x and y are 0. The background of the lock.png file is transparent.

[PlusButton] x=0 y=0 up_image=/tabs/add_up.png over_image=/tabs/add_down.png down_image=/tabs/add_down.png [MinusButton] x=20 y=0 up_image=/tabs/close_up.png over_image=/tabs/close_down.png down_image=/tabs/close_down.png

The plus button is on the left side and the minus (close terminal) on the right. As always I use the icon hight from back_image. Up, over and down is supported.

No title bar

Remove the Icon sections (FocusButton, ConfigButton, QuitButton). You need only the [Background] section. for the back_image you use a 1×1 large transparent (99%) png file.

SVG -> PNG

I made svg files and with a short script which I located in ~/bin I generate from the svg files png files which will than be used for the skin.

find -name "*.svg" -o -name "*.SVG" | while read i; do     inkscape -f "$i" -e "${i%.*}.png" done Questions

If you need something please ask at Opendesktop.

Thanks for reading, Andreas


Categories: FLOSS Project Planets

Salim Fadhley: My newest project: Getting code onto Pyboards the easy way

Planet Python - Sat, 2014-10-18 19:04
My latest python project is a way of making Mycro Python “pyboards” easier to use. Pyboards are small microcomputers which can execute code written in Micropython, which is a Python3 compatible language. It has the same grammar as cPython3 and includes a small subset of the standard library. They are an amazing invention because they open […]
Categories: FLOSS Project Planets
Syndicate content