Search Results: "will"

3 April 2013

Julien Danjou: Hy, Lisp in Python

I've meant to look at Hy since Paul Tagliamonte started to talk to me about it, but never took a chance until now. Yesterday, Paul indicated it was a good time for me to start looking at it, so I spent a few hours playing. But what's Hy? Python is very nice: it has a great community and a wide range of useful libraries. But let's face it, it misses a great language. Hy is an implementation of a Lisp on top of Python. Technically, Hy is built directly with a custom made parser (for now) which then translates expressions using the Python AST module to generate code, which is then run by Python. Therefore, it shares the same properties as Python, and is a Lisp-1 (i.e. with a single namespace for symbols and functions). If you're interested to listen Paul talking about Hy during last PyCon US, I recommend watching his lightning talk. As the name implies, it's only a few minutes long. <iframe allowfullscreen="allowfullscreen" class="shadow" frameborder="0" height="374" src="http://www.youtube.com/embed/1vui-LupKJI?wmode=transparent&amp;autohide=1&amp;egm=0&amp;hd=1&amp;iv_load_policy=3&amp;modestbranding=1&amp;rel=0&amp;showinfo=0&amp;showsearch=0#t=16m14s" width="500"></iframe> Does it work? I've been cloning the code and played around a bit with Hy. And to my greatest surprise and pleasure, it works quite well. You can imagine writing Python from there easily. Part of the syntax smells like Clojure's, which looks like a good thing since they're playing in the same area. You can try a Hy REPL in your Web browser if you want. Here's what some code look like:
(import requests)

(setv req (requests.get "http://hy.pault.ag"))
(if (= req.status_code 200)
(for (kv (.iteritems req.headers))
(print kv))
(throw (Exception "Wrong status code")))

This code would ouput:
('date', 'Wed, 03 Apr 2013 12:09:23 GMT')
('connection', 'keep-alive')
('content-encoding', 'gzip')
('transfer-encoding', 'chunked')
('content-type', 'text/html; charset=utf-8')
('server', 'nginx/1.2.6')
As you can see, it's really simple to write Lispy code that really uses Python idioms. There's obviously still a lots of missing features in Hy. The language if far from complete and many parts are moving, but it's really promising, and Paul's doing a great job implementing every idea. I actually started to hack a bit on Hy, and will try to continue to do so, since I'm really eager to learn a bit more about both Lisp and Python internals in the process. I've already send a few patches on small bugs I've encountered, and proposed a few ideas. It's really exciting to be able to influence early a language design that I'll love to use! Being a recent fan of Common Lisp, I tend to grab the good stuff from it to add them into Hy.

Petter Reinholdtsen: Isenkram 0.2 finally in the Debian archive

Today the Isenkram package finally made it into the archive, after lingering in NEW for many months. I uploaded it to the Debian experimental suite 2013-01-27, and today it was accepted into the archive. Isenkram is a system for suggesting to users what packages to install to work with a pluggable hardware device. The suggestion pop up when the device is plugged in. For example if a Lego Mindstorm NXT is inserted, it will suggest to install the program needed to program the NXT controller. Give it a go, and report bugs and suggestions to BTS. :)

Joey Hess: upstream git repositories

Daniel Pocock posted The multiple repository conundrum in Linux packaging. While a generally good and useful post, which upstream developers will find helpful to understand how Debian packages their software, it contains this statement:
If it is the first download, the maintainer creates a new git repository. If it has been packaged before, he clones the repository. The important point here is that this is not the upstream repository, it is an independent repository for Debian packaging.
The only thing important about that point is that it highlights an unnecessary disconnect between the Debian developer and upstream development. One which upstream will surely find annoying and should certainly not be bothered with. There is absolutely no technical reason to not use the upstream git repository as the basis for the git repository used in Debian packaging. I would never package software maintained in a git repository upstream and not do so. The details are as follows: So using the upstream git repository is valuable. And there is absolutely no technical value, and plenty of potential friction in maintaining a history-disconnected git repository for Debian packaging.

Michal &#268;iha&#345;: Weblate and Hackweek 9

You might have already noticed that there is Hackweek 9 coming next week. At SUSE we will get pizzas, icecream and other nice stuff, but most importantly we can spend the week on hacking anything we want. Same as last year, I want to spend most of my Hackweek on Weblate, nice crowdsourcing tool for translations. The major goal is to finish 1.5 release, what should not be that hard. The most challenging bits for new machine translation interface are already implemented, and the rest is pretty much only tweaking of existing code. Another thing we want to explore is possibility of using Weblate for openSUSE translations. Currently they are mostly kept in SVN, what is blocker for using Weblate, but we will see what can be done there.

Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!

Daniel Pocock: The multiple repository conundrum in Linux packaging

I'm involved with a number of free software projects as both a developer and as the maintainer of packages for various distributions such as Debian (which also feeds packages to Ubuntu) and OpenCSW. I regularly come across the following situations:
  • Developers of great software who would like to see it packaged, distributed and promoted conveniently through platforms like Debian
  • Users of Linux distributions who are keen to use free software if it is presented in a convenient and accessible manner they are familiar with.
Sadly, despite everybody having the best intentions, there is sometimes a chasm separating these two groups of people. Upstream developers are often busy developing new features and don't have time to work on the intricacies of packaging. I hope that by sharing a few of my own experiences I can help more developers get their software packaged more easily. Fortunately, a number of great tools like git-buildpackage have emerged for streamlining the packaging process, but this has also created more confusion for developers who have their own git repositories and don't quite understand how the Debian git repository and patching process relates to their own repository. The autotools world Here, I focus on autotools based software, because this type of software has it's own peculiar issues when packaging. In particular, these issues appear when using a version control system to track upstream releases. Some of the concepts can be applied to the study of regular Makefile or cmake projects as well. Here is a diagram giving an overview: Let's work through each of the steps in the diagram: The upstream release
  1. The developer/release manager updates the version number in
    configure.ac
    (sometimes called configure.in) and tags the code. (Usually this tag is on a dedicated release branch.)
  2. The developer checks out a copy of the code from the tag into a fresh working directory
  3. The developer runs the autoreconf/automake tools, usually from a bootstrap script. These tools create a number of new files that don't exist in the project repository. Finally, the developer runs
    make dist
    , which puts all the files,
    including the generated files, into a distribution tarball. It is worth emphasizing this point: the tarball is not just an archive of the files from the repository/tag, it also contains a number of
    files generated by autotools.
  4. The developer uploads the tarball to a web site such as the Sourceforge download page. Usually a release announcement is made now containing checksums for the tarball.
At this point, the upstream developer's work is done and packaging teams from various projects such as Debian will take over. Sometimes, the upstream developer is also building the packages and continues
onto the next steps himself: Packaging
  1. The package is downloaded by the package maintainer
  2. If it is the first download, the maintainer creates a new git repository. If it has been packaged before, he clones the repository. The important point here is that this is not the upstream repository, it is an independent repository for Debian packaging. The maintainer uses the git-import-orig tool to import the upstream tarball into the packaging repository. The git-import-orig tool captures an exact snapshot of the upstream release tarball contents in a branch called upstream. One point where the Debian repository differs fundamentally from the upstream repository is that all files from the tarball will be tracked in the Debian git repository, even those automatically generated files that were created by autotools and don't exist in the upstream repository.
  3. The maintainer creates or updates the various artifacts for packaging. These files are kept on the master branch, and the tarball contents from the upstream branch are merged into master to create packages.
  4. When the maintainer feels the code is ready, he will check out a clean copy of the repository to build the package from.
  5. The maintainer executes a tool such as git-buildpackage or regular dpkg-buildpackage, which creates the *.deb files.
  6. The files are checked with a tool like lintian and some manual testing/installation. If all is OK, a tag is made in the packaging repository, with a suffix appended to the upstream version number to indicate which iteration of the package it applies to.
AttachmentSize
release-packaging-workflow.dia3.97 KB

2 April 2013

Wouter Verhelst: Switching away from mutt

After having used mutt for about a decade, I decided it's time I move away from it, for various reasons that I won't go into here. I've been evaluating thunderbird^Wicedove now for a few weeks, but I can already see I won't keep using it forever, because I find too many issues with it:
  1. I can't tell the thing that I never ever ever want to write HTML-formatted emails. While there is an option "Compose messages in HTML format" in the "Account settings" dialog, that only seems to impact the behaviour of the client upon "new mail", not its reply behaviour, forcing me to go to Options->Format and switch it off.
  2. To make matters worse, the HTML editor and the plain-text editor are not the same dialog. That means it is not possible to switch on HTML formatting if it wasn't on originally (not a problem for me, but I can imagine it being a problem for others), but also that the fugly quoting style (vertical line next to the text) of the HTML editor is not removed when you switch from HTML to plain-text. Further on, it has issues when you want to remove white space, where it will remove entire quoting levels rather than just an empty line. This is horrible, horrible behaviour.
  3. While there is support for multiple email addresses connected to the same IMAP account, it does appear that there is no support for automatically choosing the right email address based on user-defined rules, such as "which mail folder are we currently in". Having to remember that I need to select the right mail address is tiresome and error-prone; e.g., when I'm in a Debian-related mail folder, I want my mail client to use my Debian mail address automatically. It appears the only way in which icedove can automatically select sender addresses is by checking the recipient list in the To: and Cc: headers for any of its configured mail addresses, and using that to decide what to put in the from: header.
Any one of the above would eventually be enough for me to grow tired of icedove and switch to something else; but the three combined mean that I'll be looking for something else fairly soon. Suggestions are, of course, welcome.

1 April 2013

Lisandro Dami&aacute;n Nicanor P&eacute;rez Meyer: On the road to Qt 5: Qt 4.8.4 and qtchooser uploaded to experimental

I have just uploaded Qt 4.8.4 to experimental. Apart from being the newest upstream release of the 4 series, it adds the basic support for coexisting with Qt 5. Because of this support it will need to go trough the NEW queue though, so we will need to be patient.

Developers will be interested in qtchooser, the tool that allows to switch between Qt 4 and 5 development apps. It has also been uploaded to experimental.

Of course, all this has been possible thanks to the efforts of the wonderful Qt/KDE team =)

Update: our efficacious FTP masters have already made Qt pass the NEW queue. Thanks a lot!

Benjamin Mako Hill: Mystery Hunt 2013

A few months late, perhaps, but I wanted to mention that my team (Codex) competed, once again, in the MIT Mystery Hunt. The prize for winning is the responsibility of writing the hunt next year. After being on the 2012 writing team I have mixed feelings about the fact that we did not win again. Although I did not walk away with another coin, I did manage to make an appearance in a multimedia story that the MIT Tech shot about the hunt which provides nice introductions to those who are not familiar with it. <iframe allowfullscreen="" frameborder="0" height="315" src="http://www.youtube.com/embed/R-tmBfZ8CwQ" width="560"></iframe> It was fun to reflect a little bit on why I find the hunt so fun. I said:
In my day job, I work on a lot of problems that maybe don t have answers. It s really awesome to work in a space where if you put in 1-5 hours of mental energy, you will have a solution. Someone has test-solved for it, you know that it s solvable; you know that there is an answer and that there was designed to be an answer. There s something really satisfying about being able to do that.
If you re looking for a team to hunt on next year, feel free get in contact codex is generally quite open to new members.

Hideki Yamane: Release Note translation


Once finished translating Wheezy Release Note to Japanese language.

Before releasing Wheezy, I've prepared to translate Release Note to Japanese. I know, it will be changed some times before it would be really released but do much as we can before it is good thing.

Also I think if we can do time-based update for Release Note - add new info, delete obsolete info, review and finish it (since sometimes some English speakers may not care about translations unintentionally or ignore it to hurry. We translators require some days to do it - to make it with good enough quality, at least. ;)

Andrew Pollock: [life/repatexpat] Day #1 of repatriation

Well, we're back in Brisbane, for good. Now starts the long and involved process of bootstrapping a new life for myself. Fortunately it's slightly more familiar territory than starting up in the US was. The tenants in my Hawthorne apartment have agreed to terminate their lease early, and I should get the keys tomorrow. The lease on my Woolloongabba apartment ends on Friday I think, and all of our stuff is scheduled to be delivered there next Monday. My primary goal is to get my apartment habitable for Zoe and I as soon as possible. That means beds and a fridge, and Zoe's going to need some way of being kept entertained while I'm running around like a chook with its head cut off, which is most likely going to mean a TV and a DVD player. This week is going to be spent doing a lot of running around. I need to get a car, get a Queensland driver's licence, get the electricity on, get the ADSL on, buy appliances, furnish Zoe's room, furnish my room, heck, furnish the whole apartment, really. It's going to be very full on busy. I don't want to race out and buy anything today, even though the shops seem to be open, because I want to measure up my apartment first. The day's sole purchase was an electric screwdriver from Bunnings. There will be much Ikea assembly in my future.

Russ Allbery: Review: Echo

Review: Echo, by Jack McDevitt
Series: Alex Benedict #5
Publisher: Ace
Copyright: November 2010
Printing: November 2011
ISBN: 1-937007-00-6
Format: Mass market
Pages: 367
This is the fifth book in the ongoing Alex Benedict series, but reading the previous volumes is generally optional. While there are references to earlier events (and indeed I resorted to Wikipedia at one point to refresh my memory of the plot of the the first book in the series), they aren't critical to the plot. They mostly are background for the reactions of other characters to Benedict and his firm. Echo opens with the now-familiar prologue, giving us a fleeting and limited glimpse into the mystery that Benedict and Chase Kolpath will be pursuing for the rest of the book. This time, it features the explorer Somerest Tuttle, who has spent most of his life looking for intelligent alien life. (In the far future setting of these books, humanity has spread through a large region of the galaxy but has only encountered one other alien race.) In the twilight of his career and life, a friend who works as a tour guide for astronomical tours comes to him with a story about something she saw. What, we don't know, and won't for most of the book. But, whatever it is, Tuttle never goes public with it, which is directly contrary to what everyone would expect him to do with any news about alien life. Benedict and Kolpath get involved some years later, after Tuttle's death, when a stone slab with unknown markings that was part of his estate shows up on the future equivalent of Craigslist, free to the first person who will haul it away. Benedict finds that interesting enough to go pick up, but then is really hooked when someone else goes to considerable lengths to try to make the slab disappear before anyone can get a good look at it. This, slowly, leads into poking around Tuttle's life and connections, the star tour industry, and the possible origins of the slab. If you've read any of the previous books in this series, Echo is more of the same, and I mean that in a good way. I think McDevitt is at his best when writing this sort of cross between scientific puzzle, mystery, and non-military adventure, full of people who care deeply about knowing and understanding things and don't like to be thwarted in their efforts. There is McDevitt's trademark halting and red-herring-ridden investigation that succeeds in being engrossing and compelling, plenty of opportunities to guess what's really going on (a bit easier this book than in some others), and a bit of action that I thought was better-handled than the somewhat strained action scenes of The Devil's Eye. The book moves right along, despite multiple reversals in the progress of the investigation, and the final revelation does indeed justify the strange behavior of the various people Benedict encounters. As with McDevitt in general and this series in particular, there is one caveat: the astronomical details are often interesting, but the world building in general is not terribly believable. Despite supposedly taking place millennia into the future, the society is a straight transplant (projection would imply more change than exists) of middle-class American culture, with bonus air cars, space ships, and slightly better computers. Similarly, alien ecologies suffer from severe Star Trek problems: all the planets feel like copies of Earth with a few minor tweaks. This just goes with the territory, and if you're up to the fifth book of the series, you've probably gotten used to it, but the unrealistic lack of divergence is actually used as a plot point here. That strained my suspension of disbelief a bit. That said, this sort of extremely familiar social context does give the books an oddly calm, comfortable feeling. It's tempting to describe McDevitt as cozy science fiction. There's a bit of danger, a bit of suspense, but one is fairly certain that everything will work out in the end and the reader will leave the book knowing the solutions to most of the mysteries raised without having to work very hard at understanding the society or the puzzle. If that's what you're in the mood for (and I was when I read Echo), McDevitt delivers reliably. If you like the Alex Benedict series in general, recommended, as this is an excellent example of the type. Rating: 8 out of 10

31 March 2013

Enrico Zini: A proposal to solve gender imbalance in Debian

A proposal to solve gender imbalance in Debian We've done all we can so far: Debian Women, the Diversity Statement, the anti-harassment contact, gender neutral language, lots of education all round, but we still suffer from a strong gender imbalance in Debian. I think that the reason is that the majority group of cisgender men in the project, although they don't actively work /against/ the rest, still have /no incentive/ to be inclusive, and generally do not understand what bearing a female name online is like. I think it is about time we addressed that, and after a lot of thinking and discussing with many other concerned debianers, I think I have just the right proposal, which is twofold. The first part is this: since the goal is to have an equal gender perception in Debian, we can just decide to only approve one obviously-male-named DD for every obviously-female-named one. That's right: no new obviously-male-named DD unless an obviously-female-named DD has just been approved. It may sound like affirmative action gone wild, but please stop a moment to think about it: this would create precisely the right incentive for the currently dominant group of developers to be inclusive! People shouldn't just assume they can get a Debian account regardless of what happens around them. We already ask NM candidates to fix RC bugs and, well, gender imbalance should be treated as an RC bug, and everyone should feel compelled to join the effort to fix it! Now, of course since there currently are many male names in NM but not a single female name, it would not be reasonable to just stop the flow of new developers into the project: that would just have the effect to make us starve on personpower. So here is the second part of the proposal: the one-female-name-one-male-name policy will not be enforced for, say, a year. But during this year, everyone currently in NM or joining NM will be asked to adopt a female identity. Crazy? No, genius! It's about time people understood what it means to get advances in private every time they make a public contribution! What better way than just trying it out for themselves? On top of that, as more and more female names appear in Debian changelogs, fake or not, people will finally start to understand that it does not matter what name is used to sign the contribution, but the contribution itself. I don't know if this will give us a community where people realise female or male contributions are equally valuable, which is what I hope, or a community where people will think that everyone is a cisgender man even if they have female names. In the end, really, it does not matter. Either way, we finally get to have a community where everyone is /guaranteed/ to be treated the same. But gender imbalance isn't the only imbalance we have in Debian. People accrue a reputation over time, good or bad, and this reputation tends to stick on you for years, regardless of how you may change, for better or for worse. When we evaluate the merit a contribution, we should not be biased by the reputation of the contributor! How can new contributors be taken seriously otherwise? I believe we are loosing lots of fresh, good ideas this way. And how much damage could be wrecked on the project by a well-respected contributor, like a Debian Account Manager, who is having a funny day? I think we can address this just as I propose to address gender imbalance: let's swap identities from time to time, like it usually happens with nametags at the end of Debconfs. Let's see gregoa upload a patched versions of python3.2, and enrico upload a new upstream version of eglibc! See if we won't finally have some peer review at last! Reputation and real identities have many merits, but we have come to rely too much on them, and it is hurting us. It is time we did something about it, before it is too late!

Nathan Handler: Debian Mobile

For one of my classes, the final project is to work on a personal project for four weeks. Since I have never done mobile programming before, I decided I would use this project as a chance to teach myself the basics of Android development. Paul Tagliamonte recently blogged about a Google Summer of Code project idea for a Debian Android application. It was this post that motivated me to create a Debian Android application for my final project. We are only in the middle of week one, but my plan is to have at least a basic BTS and PTS interface done by the end of the project. Then, depending on a few things, I hope to turn it into a Google Summer of Code project or simply continue developing it on my own. As I mentioned, I am only a few days into the project. One of the first hurdles I encountered was interacting with the SOAP interfaces available for the PTS and BTS. There are a few examples available on the wiki, but there are not any for Java. A Google search also failed to return any clear and simple results. As a result, I decided I would create a Python script that would accept requests from the Java Android application via a REST API and pass them on to the SOAP API before returning the result as JSON. Before I could finish writing the script, Paul mentioned that he had already written a similar program a few months ago. I immediately stopped working on my script and began preparing a patch for Paul's program to add support for some missing PTS SOAP functions as well as the entire BTS. After a few hours, I had the ability to query the PTS and BTS via a REST API from Java. While I normally prefer to use VIM for my programming, I decided to follow Google's recommendation and use Eclipse. I was able to follow their guide to get the SDK setup and a simple demo application running. One of the few hurdles I encountered was when I wanted to make web requests. Due to the ability for such requests to stall, you are required to perform them in a separate thread. This only becomes aparant when you try to test your application on an actual device; the emulator will happily run the process in the main thread. Regardless, I was eventually able to modify the demo application to allow me to make requests to my Python REST server and then parse and display the result. Here are some screenshots of the application running. Main Screen API Functions Information Entered Result If you have any feature suggestions, questions, or comments, feel free to send me an email (nhandler@debian.org). The source code for the Android application is currently not available, but I plan to put it up in a git repository sometime in the near future. The source code for the Python script that provides a REST API to access the PTS and BTS SOAP interface is available on GitHub.

30 March 2013

Michael Stapelberg: Analyzing RC bug messages

Recently, I was wondering how many Debian Developers are actively working on RC bugs in some way or another in the time period of the last release (squeeze) to now (shortly? before wheezy). I therefore grabbed the mailing list archives of debian-bugs-dist@ from gmane, used only those messages whose X-Debian-PR-Message header matches an RC bug (list retrieved from UDD) and then attributed the message counts to the appropriate Debian Developer. I am sure that there are subtle mistakes in the data I retrieved and that there most likely is a better way to achieve the same results, but this is only to get a trend and should be good enough for that. So, it turns out that 514 different Debian Developers have sent messages regarding RC bugs since squeeze. That s about half of our 985 total active Debian Developers. I would love to show a good histogram of the actual message counts (not sure how well received showing the raw data is ), but I suck at visualizing such data in a compact way. Is there anyone familiar with R (or other free data visualization tools) and willing to help? I can send you the CSV file, just send me an email to stapelberg@.

Joey Hess: Goodreads vs LibraryThing vs Free software

Four years ago I started using Goodreads to maintain the list of books I've read (which had lived in a flat text file for a decade+ before that). Now it's been aquired by Amazon. I doubt it will survive in its current form for more than 2 years. Anyway, while Goodreads has been a quite good way to find what my friends are reading, I've been increasingly annoyed by the quality of its recommendations, and its paucity of other features I need. It really doesn't seem to help me keep up with new and interesting fiction at all, unless my friends happen to read it. So I looked at LibraryThing. Actually, I seem to have looked at it several times before, since it had accounts named "joey", "joeyh", and "joeyhess" that were all mine. Which is what happens to me on sites that lack Openid or Browserid. Digging a little deeper this time, I am finding its recommendations much better than Goodreads' -- although it seems to sometimes recommend books I've already read. And it has some nice features like tracking series, so you can easily tell when you've read all the books in a series or not. The analytics overall seem quite impressive. The UI is cluttered and it seems to take 5 clicks to add and rate a single book. It supports half stars. Overall I get the feeling this was designed for a set of needs that doesn't quite match mine. For example, it seems it doesn't have a single database entry per book; instead each time I add a book, it seems to pull in data from primary sources (library of congress, Amazon cough) and treat this as a separate (but related) entry somehow. Weird. Perhaps this makes sense to say, librarians. I'm willing to adjust how I think about things if there's an underlying reason that can be grasped. There's a quite interesting thread on LibraryThing where the founder says:
Don't say we should open-source the code. That would be a nightmare! And I have limited confidence in APIs. LibraryThing has the book geeks, but not so much the computers geeks.
I assume that the nightmare is that there would be dozens of clones of the site, all balkanized, with no data transfer, no federation between them. Except, that's the current situation, as every Goodreads user who is now trying to use LibraryThing is discovering. Before I ever started using Goodreads, I made sure it met my minimum criteria for putting my data into a proprietary silo: That I could get the data back out. I can, and have. LibraryThing can import it. But the import process loses data! And it's majorly clunky. If I want to continue using Goodreads due to its better UI, and get the data into LibraryThing, for its better analytics, I have to do periodic dumps and loads of CSV files with manual fixups. This is why we have standards. This is why we're building federated social networks like status.net and the upcoming pump.io that can pass structured data between nodes transparently. It doesn't have to be a nightmare. It doesn't have to rely on proprietary APIs. We have the computer geeks. Thing is, sites like GoodReads and LibraryThing need domain-specific knowledge, and communities to curate data, and stuff like that. Things that work well in a smallish company. (LibraryThing even has a business model that makes sense, yearly payments to store more books in it.) With free software, it's much more appealing to sink the time we have into the most general-purpose solution we can. Why build a LibraryThing when we could build something that tracks not only books but movies and music? Why build that when we could build a generic federated network for structured social data? And that's great, as infrastructure, but if that infrastructure is only used to build a succession of proprietary data silos, what was the point? So, could some computer & book geeks please build a free software alternative to these things, focused on books, that federates using any of the fine APIs we have available? Bear in mind that there is already a nice start at a comprehensive collection of book data in the Open Library. I'd happily contribute to a crowd funded project doing this.

Thomas Goirand: An afternoon of fun hacks, booting Debian

Step one: building OpenRC, and force it with a big hammer to replace sysv-rc. openrc A few minutes later, with even more hacks, we have a more decent boot process which uses Gentoo boot scripts (amazingly, most of them do work out of the box!): openrc_take2 Notice the udev script, which is hacked from the Debian sysv-rc, still has the color scheme of Debian, while the other scripts are just drop-ins from Gentoo. Of course, this is only a big hack to have the above. There is only so much you can do in a 4 hours hacking session. It will need more serious work to make it a viable solution (like finding a way to upgrade smoothly and allow the first reboot to shutdown processes which aren t running using cgroup, converting existing init scripts automatically, hooking into update-rc.d, etc.). Though the proof of concept is there: the rc-status command works, we have cgroups working, and so on. Thanks to Patrick Lauer for spending with me this fun afternoon, hacking OpenRC in SID.

Evgeni Golov: Opera, standards and why I should have stayed in my cave

So you probably heard that I have that little new project of mine: QiFi the pure JavaScript WiFi QR Code Generator. It s been running pretty well and people even seem to like it. One of its (unannounced) features is a pretty clean stylesheet that is used for printing. When you print the result will be just the SSID and the QR code, so you can put that piece of paper everywhere you like. That works (I tested!) fine on Iceweasel/Firefox 10.0.12 and Chromium 25.0. Today I tried to do the same in Opera 12.14 and it failed terribly: the SSID was there, the QR code not. And here my journey begins First I suspected the CSS I used was fishy, so I kicked all the CSS involved and retried: still no QR code in the print-out. So maybe it s the QR code library I use that produces a weird canvas? Nope, the examples on http://diveintohtml5.info/canvas.html and http://devfiles.myopera.com/articles/649/example5.html don t print either. Uhm, let s Google for opera canvas print And oh boy I should not have done that. It seems it s a bug in Opera. And the proposed solution is to use canvas.toDataURL() to render the canvas as an image and load the image instead of the canvas. I almost went that way. But I felt that urge need to read the docs before. So I opened http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#dom-canvas-todataurl and https://developer.mozilla.org/en-US/docs/DOM/HTMLCanvasElement and started puking:
When trying to use types other than image/png , authors can check if the image was really returned in the requested format by checking to see if the returned string starts with one of the exact strings data:image/png, or data:image/png; . If it does, the image is PNG, and thus the requested type was not supported. (The one exception to this is if the canvas has either no height or no width, in which case the result might simply be data:, .)
If the type requested is not image/png, and the returned value starts with data:image/png, then the requested type is not supported.
Really? I have to check the returned STRING to know if there was an error? Go home HTML5, you re drunk! Okay, okay. No canvas rendered to images then. Let s just render the QR code as a <table> instead of a <canvas> when the browser looks like Opera. There is nothing one could do wrong with tables, right? But let s test with the basic example first: Yes, this is 2013. Yes, this is Opera 12.14. Yes, the rendering of a fucking HTML table is wrong. Needles to say, Iceweasel and Chromium render the example just fine. I bet even a recent Internet Explorer would That said, there is no bugfixworkaround for Opera I want to implement. If you use Opera, I feel sorry for you. But that s all. Update: before someone cries ZOMG! BUG PLZ!!! , I filled this as DSK-383716 at Opera.

Steve Kemp: Time passes, Thorin sits down and starts singing about gold.

This weekend I have mostly been reading Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of His Time . In modern times we divide the earth up into rings of lines, latitude and longitude, as wikipedia will explain. Finding your latitude is easy, finding your longitude is a difficult process, and it was vitaly important when people started to sail large distances, the book contained lots of stories of sailors being suddenly suprised by the appearance of land - because they'd misjudged their position. Having four ships, containing garlic, pepper, and other goods of value exceeding the total wealth of the UK, sink all at once was a major blow. Not to mention the large number of sailors who lost their lives. There were several solutions proposed, involving steady hands and telescopes, etc, but the book mostly discusses John Harrison and his use of watches/clocks.
John Harrison was featured in Only Fools & Horses, as the designer of the watch that made Delboy & Rodney millionaires. ->Time on our hands
The idea of using a clock is that you take one with you, set to the time of your departure location. Using that clock you can compare the time to the local-time, by viewing the sun, etc. Calculating the difference between the two times allows you to see how far away, in degrees, from your port, and thus how far you've traveled. Until harrison came along clocks weren't accurate enough to keep time. His clocks would lose a second a month, until then clocks might lose 15 minutes a day. (With more variations depending on temperture, location, and pressure. Clearly things like pendulum clocks weren't suitable for rocking ships either.) All in all this book was a great read, there were mentions of Galilao, Newton, and similar folk who we've all heard of. There was angst, drama, deceit, and some stunning craftmanship. Harrison was a woodworker, and he made his clocks out of wood (+brass where necessary). Choosing fast/slow-grown wood depending on purpose, and using wood that secreted oils naturally allowed him to avoid lubrication - which improved accuracy, as lubricants tend to thin/thicken when temperature/pressure change. A lovely read, thank you very much. In other news I received several patches for my templer static-site generator, and this has resulted in much improvement. I've also started using Test::Exception now, and slowly updating all my perl code to use this.

29 March 2013

Dirk Eddelbuettel: R / Finance 2013 Open for Registration

The annoucement below just went to the R-SIG-Finance list. More information is as usual at the R / Finance page:
Now open for registrations: R / Finance 2013: Applied Finance with R
May 17 and 18, 2013
Chicago, IL, USA
The registration for R/Finance 2013 -- which will take place May 17 and 18 in Chicago -- is NOW OPEN! Building on the success of the previous conferences in 2009, 2010, 2011 and 2012, we expect more than 250 attendees from around the world. R users from industry, academia, and government will joining 30+ presenters covering all areas of finance with R. We are very excited about the four keynotes by Sanjiv Das, Attilio Meucci, Ryan Sheftel and Ruey Tsay. The main agenda (currently) includes seventeen full presentations and fifteen shorter "lightning talks". We are also excited to offer five optional pre-conference seminars on Friday morning. To celebrate the fifth year of the conference in style, the dinner will be held at The Terrace of the Trump Hotel. Overlooking the Chicago river and skyline, it is a perfect venue to continue conversations while dining and drinking. More details of the agenda are available at:
http://www.RinFinance.com/agenda/
Registration information is available at
http://www.RinFinance.com/register/
and can also be directly accessed by going to
http://www.regonline.com/RFinance2013
We would to thank our 2013 Sponsors for the continued support enabling us to host such an exciting conference:
International Center for Futures and Derivatives at UIC Revolution Analytics
MS-Computational Finance at University of Washington Google
lemnica
OpenGamma
OneMarketData
RStudio
On behalf of the committee and sponsors, we look forward to seeing you in Chicago!
Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson,
Dale Rosenthal, Jeffrey Ryan, Joshua Ulrich
See you in Chicago in May!!

R&#233;mi Vanicat: New printer: Samsung SCX-3400

I've just buy a new printer/scanner, and as the documentation found on the web on how to setup the printer falsely instruct me to download some third-party driver, I will explain here how to set it up: By the way, Dear lazy web, I was wondering. In gimp, when I ask it to create a new image using Xsane, the menu give me the choice between the "Device Dialog" or my webcam. Is there any way to have my scanner there?

Next.

Previous.