X.Org

Recently, I've started programming in Common Lisp. My idea here is to use cl-irc, an IRC library into an event loop. This can be really useful, for example to trigger action based on time, using timers. Creating a connection The first step is to ... [More] create a basic cl-irc:connection object on our own. This can be achieved easily with this: (require :cl-irc) (defun connect (server) (cl-irc:make-connection :connection-type 'cl-irc:connection :client-stream t :network-stream ? :server-name server)) This will return a cl-irc:connection object, logging to stdout (:client-stream t) and having the server name server. Note that the server name could be any string. You probably noticed the ? I used as :network-stream value. This is not a real and working value: this should be a stream established to the IRC server you want to chat with. This is where we'll need to use cl-async:tcp-connect to establish a TCP connection. As you can read in this function's documentation, all we need to pass is the server address, two callbacks for read and general events, and the :stream option to get a stream rather than a socket. So you would do something like: (require :cl-irc)(require :cl-async) (defun connection-socket-read (socket stream) (format t "We should read the IRC message from ~a ~%" stream)) (defun connection-socket-event (ev) (format t "Socket event: ~a~%" ev)) (defun connect (server &optional (port 6667)) (cl-irc:make-connection :connection-type 'cl-irc:connection :client-stream t :network-stream (as:tcp-connect server port #'connection-socket-read #'connection-socket-event :stream t) :server-name server)) (as:start-event-loop (lambda () (connect "irc.oftc.net"))) If you run this program, it will connect to the OFTC IRC server, and then notice you each time the server is sending you a message. Therefore our problem here is how we you treat the message read from the stream in connection-socket-read and handle them in the name of our connection object you used? We can't link both together at this point. We can't build a closure, because as the time we use as:tcp-connect we don't have the cl-irc:connection instance. Also we can't change easily the read-cb parameter of our network-stream established by as:tcp-connect, simply because cl-async doesn't use to do allow that. Building a closure So one solution here is to hack cl-irc:make-connection so we can build an cl-irc:connection instance without providing in advance the network-stream, allowing us to build a closure including the cl-irc:connection to read event for. This is what we're going to do in the connect function. (require :cl-irc)(require :cl-async)(require :flexi-streams) (defun connection-socket-read (connection) (loop for message = (cl-irc::read-irc-message connection) while message do (cl-irc:irc-message-event connection message))) (defun connection-socket-event (ev) (format t "Socket event: ~a~%" ev)) (defun connect (server port nickname &key (username nil) (realname nil) (password nil)) ;; Build an instance of cl-irc:connection, without any network/output stream (let* ((connection (make-instance 'cl-irc:connection :user username :password password :server-name server :server-port port :client-stream t)) ;; Use as:tcp-connect to build our network stream, and build a ;; closure calling `connection-socket-read' with our `connection' ;; as arguments (network-stream (as:tcp-connect server port (eval `(lambda (socket stream) (declare (ignore socket stream)) (connection-socket-read ,connection))) #'connection-socket-event :stream t))) ;; Set the network stream on the connection (setf (cl-irc:network-stream connection) network-stream) ;; Set the output stream on the connection (setf (cl-irc:output-stream connection) ;; This is grabbed from cl-irc:make-connection (flexi-streams:make-flexi-stream network-stream :element-type 'character :external-format '(:utf8 :eol-style :crlf)))  ;; Now handle the IRC protocol authentication pass (unless (null password) (cl-irc:pass connection password)) (cl-irc:nick connection nickname) (cl-irc:user- connection (or username nickname) 0 (or realname nickname)) connection)) (as:start-event-loop (lambda () (connect "irc.oftc.net" 6667 "jd-blog"))) And here we are! If we run this, we're now using an event loop to run cl-irc. Each time the socket has something to read, the function connection-socket-read will be called on the non-blocking mode socket. If there's no message to be read, then the function will exit and the loop will continue to run. Using timers You can now modify the last line with this: (defun say-hello (connection) (cl-irc:privmsg connection "#jd-blog" "Hey I read your blog!") (as:delay (lambda () (say-hello connection)) :time 60)) (as:start-event-loop (lambda () (let ((connection (connect "irc.oftc.net" 6667 "jd-blog"))) (cl-irc:join connection "#jd-blog") (say-hello connection)))) This will connect to the IRC server, join a channel and then say the same sentence every minute. Challenge accomplished! And I'd like to thank Andrew Lyon, the author of cl-async, who has been incredibly helpful with my recent experimentations in this area. [Less]

The Third Berlin Open Source Meetup is going to take place on Sunday, January 20th. You are invited! It's a public event, so everybody is welcome, and please feel free to invite others!

TL;DR: Show location information retrieved directly from ModemManager in a gnome-shell indicator. Location Indicator in gnome-shell I’ve been wanting to try to write a gnome-shell extension from some time, and I ended up finding enough free time ... [More] during the past weeks. So I ended up writing a gnome-shell extension which would show information about your current location as provided by your modem. Note that this information is not coming from GeoClue; the new ModemManager1 interface is not integrated yet there. ModemManager exposes these types of information in the Location interface: 3GPP location, which is given as a set of 4 parameters, and specifies which is the current network cell which is giving mobile coverage to the modem: MCC/MNC: Identifies the ‘mobile country code’ and the ‘mobile network code’; i.e. country and operator. LAC and Cell ID: Identifies the ‘location area code’ and ‘cell id’ pair. Once all these items are known, a query to an open database of cell IDs can give us the exact location of the tower giving us coverage, and therefore a good approximation of where we are located. GPS location, given if the modem has a built-in GPS. Currently Option/HSO modems are supported, as well as QMI-powered modems with the ‘PDS’ service implemented. CDMA Base Station location, given as Latitude/Longitude coordinates, and available in QMI-powered modems prepared for CDMA networks. As with the 3GPP one, this location information specifies where the station giving coverage to your modem is located, which is a good approximation of where you are located. Beware! You’ll need ModemManager >= 0.7 (i.e. git master) in order for this extension to work. You can download and install the extension in the following link: https://extensions.gnome.org/extension/569/location-indicator The sources are kept in a git repository in gitorious.org: https://gitorious.org/aleksander/gnome-shell-location-indicator If you find the extension itself mostly useless, you may still want to take a look at the source code to see yet another example of how to talk to DBus interfaces from within gnome-shell, including the use of the new standard ObjectManager interface with a Gio.DBusObjectManagerClient. Filed under: Development, FreeDesktop Planet, GNOME Planet, GNU Planet, Lanedo Planet, Planets Tagged: 3gpp, cdma, extension, gnome, gnome-shell, gps, location, ModemManager, QMI [Less]

In some error cases, GNOME will display a full-screen window with only a single button. The window claims that "Oh no! Something has gone wrong." and "A problem has occurred and the system can't recover. Please log out and try again." The button ... [More] merely allows a user to log-out and thus quit the current session. Killing that window with xkill also quits the session. Most of the crashes I get is from experimental code crashing gnome-settings-daemon. Certainly not something fatal, certainly not something that should prevent me from continuing to work in my current session. After all, the menu key still works, the hot corner works, everything works, but closing the dialog will throw me out of my session. And because that pesky dialog is always on-top, I'm down to one monitor. Luckily, the dialog can be disabled. Update Jan 3: As Jasper points out in the comments, Alt+F4 will close the window. Though I tried Ctrl+W and Ctrl+Q, I haven't used Alt+F4 in ages. Sometimes the right solution is so much simpler :) The dialog is displayed by gnome-session and it's named the fail whale (code). It's triggered only for required apps and those can be configured. $ cat /usr/share/gnome-session/sessions/gnome.session | grep Required RequiredComponents=gnome-shell;gnome-settings-daemon; Drop g-s-d from the required components, restart the session, and you won't see the error anymore. Try it by sending SIGABRT to g-s-d. $ kill -ABRT `pidof gnome-settings-daemon` Doing so twice (g-s-d restarts once) will trigger the error unless g-s-d is dropped from the required components. It should go without saying, but the above will only display the error message, it won't fix the actual error that causes the message to be displayed. [Less]

MicroPeak Serial Interface — Flight Logging for MicroPeak MicroPeak was original designed as a simple peak-recording altimeter. It displays the maximum height of the last flight by blinking out numbers on the LED. Peak recording is fun and easy ... [More] , but you need a log across apogee to check for unexpected bumps in baro data caused by ejection events. NAR also requires a flight log for altitude records. So, we wondered what could be done with the existing MicroPeak hardware to turn it into a flight logging altimeter. Logging the data The 8-bit ATtiny85 used in MicroPeak has 8kB of flash to store the executable code, but it also has 512B (yes, B as in “bytes”) of eeprom storage for configuration data. Unlike the code flash, the little eeprom can be rewritten 100,000 times, so it should last for a lifetime of rocketry. The original MicroPeak firmware already used that to store the average ground pressure and minimum pressure (in Pascals) seen during flight; those are used to compute the maximum height that is shown on the LED. If we store just the two low-order bytes of the pressure data, we’d have room left for 251 data points. That means capturing data at least every 32kPa, which is about 3km at sea level. 251 points isn’t a whole lot of storage, but we really only need to capture the ascent and arc across apogee, which generally occurs within the first few seconds of flight. MicroPeak samples air pressure once every 96ms, if we record half of those samples, we’ll have data every 192ms. 251 samples every 192ms captures 48 seconds of flight. A flight longer than that will just see the first 48 seconds. Of course, if apogee occurs after that limit, MicroPeak will still correctly record that value, it just won’t have a continuous log. Downloading the data Having MicroPeak record data to the internal eeprom is pretty easy, but it’s not a lot of use if you can’t get the data into your computer. However, there aren’t a whole lot of interfaces avaialble on MicroPeak. We’ve only got: The 6-pin AVR programming header. This is how we load firmware onto MicroPeak during manufacturing. It’s not locked (of course), and the hardware supports reading and writing of flash, ram and eeprom. The LED. We already use this to display the maximum height of the previous flight, can we blink it faster and then get the computer to read it out? First implementation I changed the MicroPeak firmware to capture data to eeprom and made a ‘test flight’ using my calibrated barometric chamber (a large syringe). I was able to read out the flight data using the AVR programming pins and got the flight logging code working that way. The plots I created looked great, but using an AVR programmer to read the data looked daunting for most people as it requires: An AVR programmer. Adafruit sells the surprisingly useful USBtinyISP programmer. There are Windows drivers available for this, and you can get the necessary avrdude binaries from the usbtiny page above. The programmer itself comes in kit form, so you have to solder it together. There are other programmers available for a bit more than come pre-assembled, but all of them require that you wander around the net finding the necessary drivers and programming software. A custom MicroPeak programming jig. We have these for sale in the Altus Metrum web store but, because they need special pogo pins and a pile of custom circuit boards, they’re not cheap to make. With the hardware running at least $120 retail, and requiring a pile of software installed from various places around the net, this approach didn’t seem like a great way to let people easily capture flight data from their tiny altimeter. The Blinking LED The only other interface available is the MicroPeak LED. It’s a nice LED, bright and orange and low power. But, it’s still just a single LED. However, it seemed like it might be possible to have it blink out the data and create a device to watch the LED and connect that to a USB port. The simplest idea I had was to just blink out the data in asynchronous serial form; a start bit, 8 data bits and a stop bit. On the host side, I could use a regular FTDI FT230 USB to serial converter chip. Those even have a 3.3V regulator and can supply a bit of current to other components on the board, eliminating the need for an external power supply. To ‘see’ the LED blink, I needed a photo-transistor that actually responds to the LED’s wavelength. Most photo-transistors are designed to work with infrared light, which nicely makes the whole setup invisible. There are a few photo-transistors available which do respond in the visible range, and ROHM RPM-075PT actually has its peak sensitivity right in the same range as the LED. In between the photo-transistor and the FT230, I needed a detector circuit which would send a ‘1’ when the light was present and a ‘0’ when it wasn’t. To me, that called for a simple comparator made from an op-amp. Set the voltage on the negative input to somewhere between ‘light’ and ‘dark’ and then drive the positive input from the photo-transistor; the output would swing from rail to rail. Bit-banging async The ATtiny85 has only a single ‘serial port’, which is used on MicroPeak to talk to the barometric sensor in SPI mode. So, sending data out the LED requires that it be bit-banged — directly modulated with the CPU. I wanted the data transmission to go reasonably fast, so I picked a rate of 9600 baud as a target. That means sending one bit every 104µS. As the MicroPeak CPU is clocked at only 250kHz, that leaves only about 26 cycles per bit. I need all of the bits to go at exactly the same speed, so I pack the start bit, 8 data bits and stop bit into a single 16 bit value and then start sending. Of course, every pass around the loop would need to take exactly the same number of cycles, so I carefully avoided any conditional code. With that, 14 of the 26 cycles were required to just get the LED set to the right value. I padded the loop with 12 nops to make up the remaining time. At 26 cycles per bit, it’s actually sending data at a bit over 9600 baud, but the FT230 doesn’t seem to mind. A bit of output structure I was a bit worried about the serial converter seeing other light as random data, so I prefixed the data transmission with ‘MP’; that made it easy to ignore anything before those two characters as probably noise. Next, I decided to checksum the whole transmission. A simple 16-bit CRC would catch most small errors; it’s easy enough to re-try the operation if it fails after all. Finally, instead of sending the data in binary, I displayed each byte as two hex digits, and sent some newlines along to keep the line lengths short. This makes it easy to ship flight logs in email or whatever. Here’s a sample of the final data format: MP dc880100fec000006800f56d8f63b059 73516447273fa93728301927d91b7712 730bbf0491fe88f7c5ee8ee896e3fadc 9dd9d3d502d1afcea2cbafc6b4c34ec1 bfbfcabf10c03dc05dc070c084c08fc0 9cc0abc0b9c0c1c0ccc0dcc020c152c4 71c9a6cf45d623db7de05ee758edd9f2 b4f9fd00aa074311631a9221c4291330 c035873b2943084bbb52695c0c67eb6b d26ee5707472fb74a4781f7dee802b84 09860a87e786ad868a866e8659865186 4e8643863e863986368638862e862d86 2f862d86298628862a86268629862686 28862886258625862486 d925 Making the photo-transistor go fast enough The photo-transistor acts as one half of a voltage divider on the positive op-amp terminal, with a resistor making the other half. However, the photo-transistor acts a bit like a capacitor, so when I initially chose a fairly large value for the resistor, it actually took too long to switch between on and off — the transistor would spend a bunch of time charging and discharging. I had to reduce the resistor to 1kΩ for the circuit to work. Remaining hardware design I prototyped the circuit on a breadboard using a through-hole op-amp that my daughter designed into her ultrasonic guided robot and a prefabricated FTDI Friend board. I wanted to use the target photo-transistor, so I soldered a couple of short pieces of wire onto the SMT pads and stuck that into the breadboard. Once I had that working, I copied the schematic to gschem, designed a board and had three made at OSHPark for the phenomenal sum of $1.35. Aside from goofing up on the FT230 USB data pins (swapping D+ and D-), the board worked perfectly. The final hardware design includes an LED connected to the output of the comparator that makes it easier to know when things are lined up correctly, otherwise it will be essentially the same. Host software Our AltosUI code has taught us a lot about delivering code that runs on Linux, Mac OS X and Windows, so I’m busy developing something based on the same underlying Java bits to support MicroPeak. Here’s a sample of the graph results so far: Production plans I’ve ordered a couple dozen raw boards from OSH Park, and once those are here, I’ll build them and make them available for sale in a couple of weeks. The current plan is to charge $35 for the MicroPeak serial interface board, or sell it bundled with MicroPeak for $75. [Less]

Lots of numbers from running cairo-traces on a i5-2500, which has a Sandybridge GT1 GPU (or more confusingly called HD2000), and also a Radeon HD5770 discrete GPU. The key results being the geometric mean of all the traces as compared to using a ... [More] software rasteriser: UXA (snb): 1.6x slower glamor (snb): 2.7x slower SNA (snb): 1.6x faster GL (snb): 2.9x slower EXA (r600g): 3.8x slower glamor (r600g): 3.0x slower GL (r600g): 2.7x slower fglrx (xlib): 4.7x slower fglrx (GL): 32.0x slower [not shown as it makes the graphs even more difficult to read] All bar one of the acceleration methods is worse (performance, power, latency, by any metric) than simply using the CPU and rendering directly within the client. Note also that software rasterisation is currently more performant than trying to use the GPU through the OpenGL driver stack. (All software, except for the xserver which was held back to keep glamor working, from git as of 20121228.) [Less]

A while ago I had a discussion with Benjamin on IRC about the health of the GTK+ project, he seems pretty pessimistic about the state of GNOME in general and GTK+ in particular, and I showed my disagreement. Now don't get me wrong, there are ... [More] challenges and I do share some concerns. Mostly, the fact that programming and delivering GNOME apps these days is way too complicated compared to other development platforms, consuming and viewing large online datasets and the lack of a coherent set of widgets and guidelines for touch driven devices are among those. Some of these issues will be covered at the DX hackfest of course and I'm certain that we will find solutions in the long term. Benjamin raised that there seems to be less and less GTK+ hackers, and strongly disagreed with that fact, I perceive a lot more people doing stuff in GTK+ and GNOME than when I joined GNOME back in 2004. However, he caught me at something, I did not have numbers to back that up, and he was right, without actual data, I was just basing my opinion on perception. This is one of those times where I am glad that data backs up my gut feeling, I wrote down a little script to count the number of different contributors on each GNOME release (or each 6 months on pre-2.0 times).These are the results: Notice that on top of the total contributors I have also plotted the amount of translations. I have to say that we have an outstanding group of translators who are doing a remarkable job in the GNOME community, however while the amount of translators reflects the good health of our translators community, it does not really reflect the health of the project code wise, therefore I decided to do another chart with just code contributions: This chart shows what my gut feelings told me already, a lot of people are contributing to GTK+ these days, more than ever. There are a few points in time where contributions have risen up noticeably, one is in the 2.18 release, which I suspect has to do with the adoption of Subversion over CVS, and the other one is during the 3.0 release.All in all, there seems to be a rough average of 60 people contributing code on each release, this has enormous potential. Of course, a lot of these contributions are small, but it means that a lot of people find it possible to contribute code which means that this perception that people are running away from core GTK+ development is not true. In fact, it has only gotten better steadily during the past few years.Not only in terms of people contributing patches, but 3.x has been an outstanding release series (though a bit bumpy stability wise), CSS theming and a new cairo based theming API, the broadway and wayland backends, file and font chooser improvements, a massive code cleanup in several places... the list just goes on. Not to mention that the grounds for 4.0 are being settled already like the paint clock work by Owen and the work Emmanuele has been doing on Clutter 2.0.I remember that back in 2004, the sole suggestion of adding a new widget to the toolkit was received very negatively by the maintainers (for good reasons at the time), that is not the case anymore, things are at an optimal stage to get the improvements we need in. At the end of the day is up to us to see the cup half empty or half full, FOSS communities are a lot about enthusiasm so I think we are better off making an effort at looking at the bright side of life and stop ourselves from actively undermining others people's enthusiasm, the worst thing we can do if we love GNOME is to let people think that there is no point in investing our time and passion in it. So all in all, I think that there are challenges, but we have loads opportunities to improve as well. We have many facts to celebrate and be excited about.Let's keep on rocking.  [Less]

In order to start the year in a good mood, what's the best than squashing some bugs on OpenStack? Therefore, the Ceilometer team is pleased to announce that it organizes a bug squashing day on the Friday 4th January 2013. We wrote an extensive page ... [More] about how you can contribute to Ceilometer, from updating the documentation, to fixing bugs. There's a lot you can do. We've good support for Ceilometer built into Devstack, so installing a development platform is really easy. The main goal on this bug day will be put Ceilometer in the best possible shape before the grizzly-2 milestone arrives (10th January 2013). This version of Ceilometer will aim to keep compatibility with Folsom, so early deployers can enjoy some of our new features before upgrading to Grizzly. After that date, we'll start merging more extensive changes. We'll be hanging out on the #openstack-metering IRC channel on Freenode, as usual, so feel free to come by and join us! [Less]

Hello guys, things are working well and nice for the GNOME DX Hackfest, as I mentioned in my previous post, the venue is confirmed and the dates are confirmed as well (30th, 31th Jan and 1st of Feb). A budget request has been set to the board of ... [More] directors to hopefully bring people in need for sponsorship to the hackfest.Some people have already confirmed their attendance, Lennart Poettering, Frederic Peters and yours truly being some of them. I'm sure a big bunch just have forgotten to confirm, so please read carefully. This is a call of action to attendees and people who were willing to attend but can't: If you are NOT going to attend, remove yourself from the tentative list. If you ARE going to attend, remove yourself from the tentative list and add yourself to the confirmed attendees list. If you are waiting for sponsorship do nothing. Thanks a lot to everyone! This hackfest is kindly hosted by the betagroup coworking space in Brussels. Update: Meg Ford has pointed out that I did not explain what to do if waiting for sponsorship, fixed. [Less]

GNOME 3.7.3 just got released earlier today, and includes some great new work. I won't be posting screenshots, because some of the UIs aren't final, and we'll be iterating until 3.8 is released (and it's my birthday ;).Cleaning upWe've cleaned up ... [More] gnome-settings-daemon plug-ins, and gnome-control-center panels, as well as removing the support code for GNOME Fallback, saving us around 10k lines of code.gnome-control-center (now "Settings" in the UI) is faster to start, and gnome-settings-daemon require less code to write additional plug-ins.New panels3 new panels got added:Search panel, to control the search output in gnome-shell, as well as control which directories and file types Tracker should index.Notifications, to manage the notifications that will show up on your desktop. The filtering is done in gnome-shell itself, and would allow you to only show specific notifications in the lock screen for example. See Giovanni's post if your application uses notifications.Privacy, which still requires quite a bit of work, would be the go-to place to ensure your identity isn't leaked on the network, or visible on your system. You can see how some of the features in the two aforementioned panels will also affect your privacy.With the above panels merged, we're left with the re-design of the Power panel, which should mean the end of the "Screen & Brightness" panel (half of the settings went to the Privacy panel, the other half will go to the Power panel).New backend featuresFirst, users of Wacom tablets, you'll be happy to know there's now a button you can press to see, in an OSD, the current configuration of your tablet buttons. This feature has been long in the making, but the results are great. There's coverage for every tablet known to libwacom, and support for touchrings, touchstrips and modeswitch buttons. Select the button you want to use for the help in the Settings panel.Secondly, we now support the draft "Idle Inhibition" specification from Freedesktop.org.We also have some unfinished features.The remote-display plugin will disable animations in the desktop when using the desktop over VNC or Spice.And the cursor plugin will hide the mouse cursor until first used, or when using a touchscreen, similarly to what Windows 8 supports (it's the only system other than ours that supports both cursor pointers and touchscreens).Those 2 plugins should hopefully be working by the time of the GNOME 3.8 release.Until next time. [Less]