I m using GNU Screen daily for definitely more than a decade and I became maintainer of Debian s screen package nearly exactly two years ago. Nevertheless it still happens occassionally that I discover features yet unknown to me. Recently I had one of these moments again: I looked for a specific line in the long output of a command which has run inside a Screen session. For that I entered Screen s copy mode with Ctrl-A [ and scrolled around with arrow keys and page-up and -down keys. But didn t find it. I thought, it would be cool if I can search for the string I m looking for. Intu tively I typed /, the search string and pressed enter. And it worked! It jumped to the next occurrence of that string. Of course I immediately had to check if tmux has such a feature, too. And it indeed has, but it seems to be a less sophisticated implementation:

Feature	Key-binding in GNU Screen	Key-binding in Tmux
Switch into copy/scroll mode (needed for the remainder)	Ctrl-A [	Ctrl-B [
Search for string once, forward	/ + string + Enter	Ctrl-S + string + Enter
Search for string once, backward	? + string + Enter	Ctrl-R + string + Enter
Search for string again, forward	/ Enter	Ctrl-S Enter
Search for string again, backward	? Enter	Ctrl-R Enter
Incremental search for string, forward	Ctrl-S + string	-
Incremental search for string, backward	Ctrl-R + string	-
(Incremental) search for next occurrence, forward	Ctrl-S again	-
(Incremental) search for next occurrence, backward	Ctrl-R again	-

Being able to do incremental search like with GNU Emacs gave me yet another reason for continuing to use Screen and not to switch Tmux. ;-)

not much activity around RC bugs on my side in the last weeks; & the ones I worked on were all in the Debian Perl Group:

• #722332 libcommon-sense-perl: "libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say()."
  ensure same version of perl at build and runtime (pkg-perl)
• #723917 src:libcatalyst-dispatchtype-regex-perl: "FTBFS: Module::Build version 0.4004 required--this is only version 0.4003 at Build line 41."
  fix build dependencies (pkg-perl)
• #723927 src:libdancer-plugin-auth-extensible-perl: "FTBFS: POD error"
  add patch to fix POD (pkg-perl)
• #723933 src:libemail-mime-perl: "FTBFS: test failures in t/ct_attrs.t"
  upload new upstream release (pkg-perl)
• #724109 src:libmoosex-getopt-perl: "libmoosex-getopt-perl: FTBFS: Tests failures"
  upload new upstream release (pkg-perl)
• #724111 src:libtemplate-declare-perl: "libtemplate-declare-perl: FTBFS: Tests failed"
  upload new upstream release (pkg-perl)
• #724196 src:libmldbm-sync-perl: "libmldbm-sync-perl: FTBFS: make[1]: *** No rule to make target /usr/local/lib/perl5/5.6.1/i686-linux/Config.pm', needed by Makefile'. Stop."
  re-create Makefile in clean target (pkg-perl)
• #724235 src:libio-compress-lzma-perl: "FTBFS: IO::Compress::Base version 2.061 required--this is only version 2.060"
  fix alternative dependencies (pkg-perl)
• #724303 src:libvideo-fourcc-info-perl: "libvideo-fourcc-info-perl: FTBFS: fails t/99kwalitee.t: no license information"
  don't run author tests during build (pkg-perl)
• #725393 libhttp-server-simple-psgi-perl: "libplack-perl and libhttp-server-simple-psgi-perl: error when trying to install together"
  add versioned Breaks/Replaces (pkg-perl)
• #725585 src:libhttp-request-params-perl: "libhttp-request-params-perl: FTBFS: Tests failed"
  add patch from CPAN RT (pkg-perl)

on an unrelated note: following the discussion on debian-project, I finally revoked my old opengpg key 0x00F3CFE4 which served me well from 1998 until 2009. since then, I've only been using 0x8649AA06 anyway ...

I wish I had known about that quote from Michael Graves before now. I would have perhaps had an answer to some recent visitors to makespace.

There are regular scheduled visits to makespace where people can come and view our facilities, and perhaps start the process of becoming a member if they decide they like what they see.

However, we sometimes get people who just turn up at the door. If a member feels charitable they may choose to give a short tour rather than just turn the person away. I happened to be in one Friday afternoon recently varnishing a folding chair when two such people rang the doorbell. There were few other members about and because watching varnish dry was dull I decided to be helpful and do a quick tour.

I explained that they really ought to return for a scheduled event for a proper tour, gave the obligatory minimal safety briefing, and showed them the workshops and tools. During the tour it was mentioned they were attending a certain local higher education establishment and were interested in makespace as an inexpensive studio.

Before they left I was asked what I was working on. I explained that I had been creating stools and chairs from plywood. At this point the conversation took a somewhat surreal turn, one of them asked, well more demanded, who my principle influence had been in designing with plywood.

When I said that I had mainly worked from a couple of Google image searches they were aghast and became quite belligerent. They both insisted I must have done proper research and my work was obviously influenced by Charles and Ray Eames and Arne Jacobsen and surely I intended to cite my influences in my design documents.

My admission that I had never even heard the names before and had no design documents seemed to lead to a distinctly condescending tone as they explained that all modern plywood design stemmed from a small number of early 20th century designers and any competent designers research would have revealed that.

At this point in proceedings I was becoming a bit put out that my good deed of showing off the workshop had not gone unpunished. I politely explained that I designed simply by generating a requirement in my head, maybe an internet search to see what others had done, measuring real things to get dimensions and then a great deal of trial and error.

I was then abruptly informed that my "design process was completely invalid and there were well established ways to design furniture correctly and therefore my entire design was invalid" and that I was wasting time and material. I thanked them for their opinion and showed them out, safe and well before anyone gets any ideas.

I put the whole incident out of my mind until I finished writing up the final folding chair post the other day. It struck me that perhaps I had been unknowingly influenced by these designers. It was certainly true I had generated ideas from the hundreds of images my searches had revealed.

I did some research and it turns out that from the 1930s to the 1950s there were a string of designers using plywood in novel ways from the butterfly stool by Sori Yanagi through formed curvy chairs by Alvar Aalto and eero saarinen.

While these designers produced some wonderfully iconic and contemporary furniture I think that after reviewing my initial notes that two more modern designers Christian Desile and Leo Salom probably influenced me more directly. Though I did not reference their designs beyond seeing the images along with hundreds of others, certainly nothing was directly copied.

And there in lies an often repeated observation: no one creates anything without being influenced by their environment. The entire creative process of several billion ape descendants (or Golgafrincham telephone sanitisers if you prefer) is based on the simple process of copying, combining and transforming what is around us.

I must accept that certain individuals at points in history have introduced radical improvements in their field, people like Socrates Galileo Leonardo Newton Einstein. However, even these outstanding examples were enlightened enough to acknowledge those that came before. Newtons quotation "If I have seen further it is by standing on the shoulders of giants" pretty much sums it up.

In my case I am privileged enough to live in a time where my environment has grown to the size of the world thanks to the internet. My influences, and therefore what I create, is that much richer but at the same time it means that my influence on others is similarly diminished.

I have joined the maker community because I want to create. The act of creation teaches me new skills in a physical, practical way and additionally I get to exercise my mind using new techniques or sometimes things I had forgotten I already knew. I view this as an extension of my previous Open Source software work, adding a physical component to a previously purely mental pursuit.

But importantly I like that my creations might provide inspiration for someone else. To improve those chances in the wider world I force myself to follow a few basic rules:

Release

Possibly one of the hardest things for any project. I carefully avoided the word finish here because my experience leads me to the conclusion that I always want to improve my designs.

But it is important to get to a point in a project where you can say "that is good enough to share", this is more common in software but it really applies to any project.

Share

If your aim here is to improve your society with your contribution sharing your designs and information is important. I think there is nothing better than someone else taking one of your designs and using it and perhaps improving on it, remember that is what you probably did in one way or another better to make it less hard for that to happen.

Ensure your design files are appropriately licensed and they are readily accessible. I personally lean towards the more generally accessible open source licences like MIT but the decision is ultimately yours.

Licencing is important, especially in the current copyright happy society. I know it sounds dull and no one takes that seriously, right? Sorry, but yes they do and it is better for you to be clear from the start, especially if there is a software component to your project. Oh one personal plea, use an existing well known licence, the world simply does not need another one!

Write about it

The blog posts about the things I have made sometimes take almost as much time as the creation. The clear recording on my thoughts in written and photographic form often gives me more inspiration for improvements or other projects.

If someone else gets pleasure from the telling then that can only be good. If you do not do this then your voice cannot be heard and you wasted an opportunity to motivate others.

Feedback

If you do manage to get feedback on your creation, read it. You may disagree or not be interested for the current project but the feedback process is important. In software this often manifests as bug reports, in more physical projects this often becomes forum or blog comments.

Just remember that you need a thick skin for this, the most vocal members of any society are the minority with inflammatory opinion, the silent majority are by definition absent but there is still useful feedback out there.

Create again

By this I simply mean that once you are satisfied yourself on a project move on to the next. This may sound a little obvious but once you have some creative momentum it is much easier to keep going project to project than in you leave time between.

Also do not have too many projects ongoing, by all means have a couple so you do not get stuck waiting for materials or workshop time but more than three and four and you will never be able to release any of them.

Those students were perhaps somewhat misguided in how they stated their opinions, but they are correct that in the world in which we find ourselves we are all influenced. Though contrary to received wisdom those influences are more likely to be from the internet and our peers in the global maker society than historical artists.

The tail end of this week was mostly spoiled by the discovery that libbeanstalkclient-ruby was not included in Wheezy. Apparently it was removed because the maintainer had no time, and there were no reverse dependencies - #650308. Debian maintainers really need to appreciate that no official dependencies doesn't mean a package is unused. Last year I needed to redesign our companies monitoring software, because we ran out of options that scaled well. I came up with the (obvious) solution:

• Have a central queue containing jobs to process.
  • e.g. Run a ping-test on host1.example.com
  • e.g. Run an SSH-probe on host99.example.com
  • e.g. Fetch a web-page from https://example3.net/ and test it has some text or a given HTTP status code.
  • (About 15 different test-types are available).
• Have N workers each pull one job from the queue, execute it, and send the results somewhere.

I chose beanstalkd for my central queue precisely because it was packaged for Debian, had a client library I could use, and seemed to be a good fit. It was a good fit, a year on and we're still running around 5000 tests every minute with 10 workers. The monitoring tool is called Custodian Custodian, and I think I've mentioned it before here and on the company blog. It looks like we'll need to re-package the Ruby beanstalk client, and distribute it alongside our project now. That's not ideal, but also not a huge amount of work. In summary? Debian you're awesome. But libraries shouldn't be removed unless it can't be helped, because you have more users than you know.

We learn to code by actually writing code and we did it because we enjoyed it. Now it is my day job and I get to do it a lot more. The only difference being its a lot more Java now. Jaseem and I have decided to take up a pet project of ours and finish it in a week. Jaseem is writing Conway s Game of Life in Elisp and I will be implementing a single player AI powered Reversi game in Erlang. I have been learning and writing Erlang for some time now it is something I enjoy. I believe actor model is one of the best ways to express concurrency primitives and the functional way of things is beautiful in itself, but I digress. Back in college we used to write code because it was something we enjoyed. Now there is not much that I write, apart from what I do at my day job, and this is an exercise in bringing those glory days back. Now read about this in his words.

I just received an USB headset from Plantronics. Since it has a keypad on it, with buttons to mute the microphone and to adjust the volume, it appears as both a sound card and a keyboard. Problem: that keyboard sends a mouse ButtonPress 1 (yes, a mouse button event, do not ask me how that is materially and logically possible) when the microphone is muted, and only sends the corresponding ButtonRelease 1 when it is unmuted. As a result, the pointer behaves as if the mouse button was pressed continuously, rendering the desktop quite unusable.This situation has been the object of many discussions and bug reports. All of them always suggest the same solution: making X.Org ignore the keyboard associated to the headset, with an important side effect: volume adjustment will no longer be possible using the headset buttons. Microphone muting will still be available though, since it is implemented directly in the headset. There is a better solution however: remap the mouse button 1 of that keyboard (yes, the idea that a keyboard has mouse buttons is quite funny) to disable it. To do that temporarily:

 $ # Get the identifier of the Plantronics keyboard
$ xinput --list
  Virtual core pointer            id=2  [master pointer  (3)]
      Logitech USB Optical Mouse  id=10 [slave  pointer  (2)]
  Virtual core keyboard           id=3  [master keyboard (2)]
      Power Button                id=6  [slave  keyboard (3)]
      Logitech USB Keyboard       id=8  [slave  keyboard (3)]
      Plantronics .Audio 400 DSP  id=11 [slave  keyboard (3)]
$ # Remap its mouse button 1 to 0 (disable)
$ xinput --set-button-map 11 0

And to do it permanently, create a file /etc/X11/xorg.conf.d/plantronics.conf and restart X.Org:

 Section "InputClass"
    Identifier "Plantronics"
    MatchVendor "Plantronics"
    Option "ButtonMapping" "0"
EndSection

This way, the mouse button 1 events from the headset keyboard are ignored, while all the other events it generates, that is KeyPress/KeyRelease XF86AudioLowerVolume and XF86AudioRaiseVolume, are not.

Now that GSOC is over and DebianDroid is in a more functional state i ve decided to finally publish the app to the Google Play Store and to F-Droid. That way I can get way more feedback about it plus it might already be useful for some people.

---

You can find a features and todo list in the readme in my github repo or alioth mirror. Special thanks to Hans-Christoph Steiner (my gsoc mentor) and to Paul Tagliamonte for their help and feedback along the way. If you want to help send me your feedback about the app via mail to onexemailx@gmail.com or via github or play store. I m looking for bugs, new feature ideas, suggestions for rest/soap/any other apis I can use to implement features in the todo list and also possibly for other icon or design ideas. That s all for now. :) Edit: I did a last minute rename of the app package to net.debian.debiandroid (since debian.com doesn t exist) and it was a bit more complicated that I expected so I had to republish the app in the play store. Just uninstall the old one and install it again from the link above. I changed the description of the old app as well so it should be clear which is which. Sorry for the inconvenience. The good thing is that I fixed some bugs/crashes as well.

Here in the US, the Affordable Care Act is finally going into effect, with accompanying drama. I managed to get signed up today at healthcare.gov. After not having health insurance since 2000, I will finally be covered starting January 1 2014. Since my income is mosty publically known anyway, I thought it might be helpful to blog about some details. I was uninsured for 14 years due to a combination of three factors:

1. Initially, youthful stupidity and/or a perfectly resonable cost/benefit analysis. (Take your pick.)
2. Due to the US health insurance system being obviously broken, and my preference to avoid things that are broken. Especially when the breakage involved insurers refusing to cover me at any sane level due to a minor and easily controlled pre-existing condition.
3. Since I'm not much motivated by income levels, and am very motivated to have time to work on things that are important to me, my income has been on average pretty low, and perhaps more importantly, I have intentionally avoided being a full-time employee of anyone at any point in the past 14 years (have rejected job offers), and so was not eligible for any employee plans which were the only reasonable way to be covered in the US. (See point #2.)

So, if you're stuck waiting in line on healthcare.gov (is this an entirely new online experience brought to us by the US government?), or have seen any of the dozen or so failure modes that I saw just trying to register for a login to the site, yeah, it's massively overloaded right now, and it's also quite broken on a number of technical levels. But you can eventually get though it. Based on some of the bugs I saw, it may help to have an large number of email addresses and use a different one for each application attempt. It also wouldn't hurt to write some programs to automate the attempts, because otherwise you may have to fill out the same form dozens of times. And no, you can't use "you+foo@bar.com" for your email; despite funding the development of RFC-822 in the 80's, the US government is clueless about what consititutes a valid email address. But my "favorite" misfeature of the site is that it refuses to let you enter any accented characters, or characters not in the latin alphabet when signing up. Even if they're, you know, part of your name. (Welcome back to Ellis Island..) I want to check the git repository to see if I can find the backstory for these and other interesting technical decisions, but they have forgotten to push anything to it for over 3 months. The good news is that once you get past the initial signup process, and assuming you get the confirmation mail before the really short expiration period of apparently less than 1 hour (another interesting technical choice, given things like greylisting), the actual exchange is not badly overloaded, and nor is it very buggy (comparatively). I was able to complete an application in about an hour. The irony is that after all that, I was only able to choose from one health insurer covering my area on the so-called "exchange". (Blue Cross/Blue Shield) I also signed up for dental insurance (it was a welcome surprise that the site offers this at all) and had a choice of two insurers for that. The application process was made more uncertian for me since I have no idea what I'll end up doing for money once my current crowdsourced year of work is done. The site wants you to know how much income you'll have in 2014, and my guess is anywhere between $6000 (from a rental property) and about what I made this year (approx $25000 before taxes). Or up, if I say, answered the Google pings. The best choice seemed to be to answer what I made this year, which is also close to what I made last year. So, I'll be paying around $200/month for a combination of not very good health insurance, and not very good dental insurance. There is around $750/year of financial aid to people at my guesstimated 2014 income level, which would drop that to $140/month, but I will let them refund me whatever that turns out to be in a lump sum later instead. For comparison, I am lucky to spend rather less renting a three bedroom house situated in 25 acres of woods.. It's strange to think that all of this is an improvement to the system here in the US, especially given all the better options that could have been passed instead, but it seems that it probably is. Especially when I consider the many people around me who are less fortunate than myself. If you'd like a broader perspective on this, see Tobias Buckell's "American healthcare was already socialized by Reagan, we re just fighting about how to pay for it".

After 1.5 month of work, I am proud to officialy release OUnit 2.0.0. This is a major rewrite of OUnit to include various feature that I think was missing from OUnit1. The very good news is that the port of the OASIS test suite has proven that this new version of OUnit can drastically improve the running time of a test suite. OUnit is a unit test framework for OCaml. It allows one to easily create unit-tests for OCaml code. It is based on HUnit, a unit testing framework for Haskell. It is similar to JUnit, and other XUnit testing frameworks. Download OUnit v2.0.0 Documentation of v2.0.0 Website The basic features:

• better configuration setup
  • environment variable
  • command line options
  • configuration files
• improved output of the tests:
  • allow vim quickfix to jump in the log file where the error has happened
  • output HTML report
  • output JUnit report
  • systematic logging (verbose always on), but output log in a file
• choose how to run your test:
  • run tests in parallel using processes (auto-detect number of CPU and run as many worker processes)
  • run tests concurrently using threads
  • use the old sequential runner
• choose which test to run with a chooser that can do smart selection of tests:
  • simple: just run test in sequence
  • failfirst: run the tests that failed in the last run first and skip the success if they are still failing
• some refactoring:
  • bracket: use a registration in the context but easier to use
  • remove all useless functions in the OUnit2 interface
• non-fatal section: allow to fail inside non-fatal section without quitting immediately the whole test
• allow to use OUnit1 test inside OUnit2 (smooth the transition)
• timer that makes tests fail if they take too long, only when using the processes runner (I was not able to do it cleanly using threads and sequential)
• allow to parametrize filenames so that you can use OUNIT_OUTPUT_FILE=ounit-$(suite_name),log and have $(suite_name) replace by the test suite name
• create locks to avoid accessing the same resources within a single process or the whole application (typically to avoid doing a chdir while another thread is doing a chdir elsewhere)
• create a in_testdata_dir function to locate test data, if any

Migration path OUnit 2.0.0 still provides the OUnit module which is exactly the same as the last OUnit 1.X version. This way, you are not forced to migrate. However, this means that you will gain no advantage of the new release and even some slowdown due to increase complexity of the code. Though, I strongly recommend to upgrade to OUnit2. Here is a checklist to do the migration:

• replace all open OUnit by open OUnit2
• the test function now takes test_ctxt argument, so replace all fun () -> ...) by fun test_ctxt -> ...
• bracket are now inlined so bracket setUp f tearDown is now let x = bracket setUp tearDown test_ctxt in
• make sure that you don't change global process state like chdir or Unix.putenv or that you don't rely on another test setting something for the next test

The OASIS test suite migration In order to check that everything was working correctly, I have migrated the OASIS test suite to OUnit2. This is a big test suite (210 test cases) and it includes quite big sequences of tests (end to end tests from calling oasis setup to compiling and installing the results). This was really time consuming and I wish to see a significant speedup for the tests with OUnit2. You can see the result in term of code of the full migration here. Here are the results on my Intel Core i7 920/SSD:

• Pristine test suite (210 tests):
  • oUnit v1: 52.36s (i.e. latest OUnit v1.x, reference time)
  • oUnit1 over oUnit2: 60.39s (OUnit v2.0.0 using the OUnit v1 layer)
• Migration to OUnit2 (166 tests):
  • processes (8 shards): 10.12s
  • processes (autodect, 4 shards): 12.99s
  • sequential: 58.77s

The migration was quite heavy because this test suite had a big design problem. It uses in-place modification of the test data. I think I pick this design because I thought this was a good idea to decrease the running time. As a matter of fact, this was a huge mistake, that keeps popping failed test cases because one of the previous tests was failing. I have refactored all this and now we start by copying the test data into a temporary directory, which ensure that everything is always starting from pristine test data. During the redesign, I have decided to reduce the number of tests by merging some of them. This should have no big impact on the running time, although this is not as pure 1:1 comparison with OUnit v1. Although it is still testing exactly the same thing. This explain the loss of ~50 tests, which in fact has been merged in other tests. The overall speedup is 4x compared to OUnit v1, when using processes. However there is a 12% increase compared to OUnit v1 for sequential and a 15% increase when using OUnit v1 compatibility layer. While this is not very good score, I hope this is small enough to compensate the huge win of being able to run tests in parallel with processes. And now the magic ! At this point, if you read carefully the numbers, you would have noticed that there is a 4.5x decrease in speed when you compare sequential and 4 processes for OUnit2. Since we are only actively testing in 4 shards, it looks strange. I don't expect a super-linear speedup due to the use of processes. I have checked that every tests was indeed running and found no solutions to this mystery. Right now, I think this is due to the fact that we are running less tests in more processes which should lighten the load of the GC (which may not trigger at all). I am not sure about this explanation and will welcome any bug report which shows a problem in the implementation of either sequential or processes runner. Although, this is great. Help still wanted If you find any bugs with OUnit v2, this is the time to submit a bug. OUnit BTS If you want to try to fix bugs by yourself, please checkout the latest version of OUnit:

 $> darcs get http://forge.ocamlcore.org/anonscm/darcs/ounit/ounit

Patches always welcome.

Matt Palmer wrote an insightful post about the use of the word professional [1]. It s one factor that makes me less inclined to be a member of professional societies. The TED blog has an interesting article about Wikihouse which is a project to create a set of free designs for houses to be cut out of plywood with a CNC milling machine [2]. The article also links to a TED talk by Alastair Parvin of the Wikihouse project which covers many interesting things other than designing houses. An XKCD comic has one of the best explanations of bullying I ve ever seen [3]. If you aren t familiar with XKCD then make sure you hover your mouse over it to read the hidden text. The Fair Phone is a project to develop a smart phone starting with conflict-free resources and with fully free software (not like a typical Android build) [4]. It s an interesting project and the price and specs seem within the normal range so you re not paying a huge premium for a conflict-free phone. Unfortunately they only have one model with a 4.3 display, if they had a competitor for the Galaxy Note then I d be interested. Patrick Stokes wrote an insightful article about why I m entitled to my opinion is a bogus argument [5]. Jim Daly wrote an interesting TED blog post interviewing Rishi Manchanda about Upstream Doctors who look for the root causes of medical problems rather than just treating the symptoms [6]. Brian Krebs wrote an insightful article about the value of a hacked email account [7]. If you are trying to convince your users to use better passwords then this should help. Ron Garrett wrote an insightful series or articles on morality hooked on the premise of whether it s wrong to torture kittens [8]. Part of his conclusion is that people who believe it s wrong to do such things tend to be more capable of working in large groups and forming a productive and efficient society. The TED blog has an interesting post by Karen Eng summarising Andreas Raptopoulos talk about using autonomous drones to deliver parcels in parts of the world that don t have usable roads [9]. Delivering parcels (which would start with medical supplies but would presumably move on to commercial transport) by drone is apparently really cheap. Being cheaper than building roads isn t going to be difficult but it seems that they are going to make it cheaper than paying people to deliver parcels even if the roads were built. The main web site about this project is www.matternet.us, they are hiring electrical engineers. Here is the link for Andreas TED talk [10]. The TOR blog has an interesting article by Emily Asher-Perrin comparing the different houses of Hogwarts [11]. It s an insightful article about personality attributes and gives more information than is available in the movies (I d read the books if I had time).

• [1] http://hezmatt.org/~mpalmer/blog/2013/05/14/a-modest-vocabulary-proposal.html
• [2] http://blog.ted.com/2013/05/23/how-to-print-out-your-own-house/
• [3] http://xkcd.com/1216/
• [4] http://www.fairphone.com/
• [5] http://theconversation.com/no-youre-not-entitled-to-your-opinion-9978
• [6] http://tinyurl.com/n2rvo94
• [7] http://krebsonsecurity.com/2013/06/the-value-of-a-hacked-email-account/
• [8] http://tinyurl.com/nczyspd
• [9] http://tinyurl.com/kxu8dxp
• [10] http://www.youtube.com/watch?v=eqcX3AM5oh8
• [11] http://tinyurl.com/o4sbt3l

By popular demand: (source: myeerah's avatar on Why, God, Why? forum. I guess (s)he's the author)

A new version of Rcpp is now on the CRAN network for GNU R; binaries for Debian have been uploaded as well. Once more, this release brings a large number of exciting changes to Rcpp. Some concern usability, some bring new features, some increase performance; see below for the detailed list. We have now released three updates on a quarterly cycle; if we keep this up the next version ought to be ready at the end of December. As in the past, we tested the release rather rigorously by checking against all packages I could (relatively easily) built on my server: this time it successfully passed \code R CMD check for all 107 packages I can build locally out of a total of 136 packages. (Two failed: one for an error in \code Makevars , and one for the need of an X11 server during tests; this may get addressed in the in test script next time). As all of these 107 packages passed, we do not expect any issues with dependent packages. Should there be issues we would appreciate a note, preferably with reproducible code, to the rcpp-devel mailing list. The complete NEWS entry for 0.10.4 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.10.5 (2013-09-28)

• Changes in R code:
  • New R function demangle that calls the DEMANGLE macro.
  • New R function sizeof to query the byte size of a type. This returns an object of S3 class bytes that has a print method showing bytes and bits.
• Changes in Rcpp API:
  • Add defined(__sun) to lists of operating systems to test for when checking for lack of backtrace() needed for stack traces.
  • as<T*>, as<const T*>, as<T&> and as<const T&> are now supported, when T is a class exposed by modules, i.e. with RCPP_EXPOSED_CLASS
  • DoubleVector as been added as an alias to NumericVector
  • New template function is<T> to identify if an R object can be seen as a T. For example is<DataFrame>(x). This is a building block for more expressive dispatch in various places (modules and attributes functions).
  • wrap can now handle more types, i.e. types that iterate over std::pair<const KEY, VALUE> where KEY can be converted to a String and VALUE is either a primitive type (int, double) or a type that wraps. Examples :
    • std::map<int, double> : we can make a String from an int, and double is primitive
    • boost::unordered_map<double, std::vector<double> >: we can make a String from a double and std::vector<double> can wrap itself
    Other examples of this are included at the end of the wrap unit test file (runit.wrap.R and wrap.cpp).
  • wrap now handles containers of classes handled by modules. e.g. if you expose a class Foo via modules, then you can wrap vector<Foo>, ... An example is included in the wrap unit test file.
  • RcppLdFlags(), often used in Makevars files of packages using Rcpp, is now exported from the package namespace.
• Changes in Attributes:
  • Objects exported by a module (i.e. by a RCPP_MODULE call in a file that is processed by sourceCpp) are now directly available in the environment. We used to make the module object available, which was less useful.
  • A plugin for openmp has been added to support use of OpenMP.
  • Rcpp::export now takes advantage of the more flexible as<>, handling constness and referenceness of the input types. For users, it means that for the parameters of function exported by modules, we can now use references, pointers and const versions of them. The file Module.cpp file has an example.
  • No longer call non-exported functions from the tools package
  • No longer search the inline package as a fallback when loading plugins for the the Rcpp::plugins attribute.
• Changes in Modules:
  • We can now expose functions and methods that take T& or const T& as arguments. In these situations objects are no longer copied as they used to be.
• Changes in sugar:
  • is_na supports classes DatetimeVector and DateVector
• Changes in Rcpp documentation:
  • The vignettes have been moved from inst/doc/ to the vignettes directory which is now preferred.
  • The appearance of the vignettes has been refreshed by switching to the Bistream Charter font, and microtype package.
• Deprecation of RCPP_FUNCTION_*:
  • The macros from the preprocessor_generated.h file have been deprecated. They are still available, but they print a message in addition to their expected behavior.
  • The macros will be permanently removed in the first Rcpp release after July 2014.
  • Users of these macros should start replacing them with more up-to-date code, such as using 'Rcpp attributes' or 'Rcpp modules'.

Thanks to CRANberries, you can also look at a diff to the previous release 0.10.4. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

During the last week I was attending the first Heidelberg Laureates Forum as one of the lucky 200 accepted young scientists. The HFL is a (from now on hopefully yearly) event that brings together Fields Medalists, Abel Prize laureates and Turing Award winners with young scientists (undergraduates, Ph.D. students and postdocs) from both fields in the city of Heidelberg. The extremely well organized week consisted of lectures from the laureates, some workshops held by postdocs, excursions and plenty of good food. Videos of the lectures are available (but don t work on Linux, at least not for me ), and I have shot a few pictures of the event as well. I believe that my favourite lectures where Michael Atiyah s Advice to a Young Mathematician , Vladimir Voevodsky s Univalent Foundations of Mathematics , William Morton Kahan s Desperately Needed Remedies for the Undebuggability of Large-Scale Floating-Point Computations in Science and Engineering and Alan Kay s Putting Turing to Work . Where are all the functional programmers? During that event, one gets to talk to many other math and computer scientists researchers; sometimes just Where are you from? and What do you do? , sometimes long discussions. Unfortunately, I hardly found one who is into functional programming language research is that only because the event was parallel to ICFP (which I really would have liked to attend as well), or is functional programming really just about 1% of all computer science? What is a proof? My other research interest lies in interactive theorem proving, especially using Isabelle. Of course that is a topic that one can discuss with almost everyone at that event, including the mathematicians. The reactions were rather mixed: On the one end of the spectrum, some mathematicians seriously doubt that they would ever trust a computer to check proofs and that it would ever be efficient enough to use. Others would not mind having a button that tells whether their paper written in LaTeX is correct , but were not keen to invest time or thought into making the proof readable by the computer. And then there were some (but very few!) who had not heard of theorem proving before and were very excited by the prospect of being able to obtain certainty about their proofs immediately and without having to bother other scientists with it. During the mathematician s panel discussions, where I posed the question Do you see value in or even a need for machine-checked proofs in mathematics. , Efim Zelmanov (Fields Medal 1994) said a proof is what other mathematicians see as a proof . I found this attitude a bit surprising for me, a proof has always been a rigorous derivation within a formal system (say, ZFC set theory), and what we write in papers is a (less formal) description of the actual proof, whose existence we believe in. Therefore I was very happy to see Vladimir Voevodsky give a very committed talk about Univalent Foundations and how using that as the language for mathematics will allow more of mathematics to be cast in a formal, machine-checked form. I got the chance to discuss this with him in person, as I wanted to hear his option on Isabelle, and especially on the usefulness of the style of structured proof that Isar provides, and which is closer to the style of proofs that mathematicians use in papers. He said that he enjoyed writing his proof in the style required in Type Theory and in Coq, and that maybe mathematicians should and will adjust to the language of the system, while I believe that a structured proof languages like Isar, independent of the underlying logic (HOL in this case; which is insufficient to form a base for all of abstract mathematics), is a very useful feature and that proof assistants should adjust to the mathematicians.
We also briefly discussed the idea of mine to work with theorem provers already with motivated students in high schools, e.g. in math clubs, and found that simple proofs about arithmetic of natural numbers could be feasible here, without being too trivial. All in all a very rewarding and special week, and I can only recommend to try to attend one of the next forums, if possible.

Yesterday, i said a sad goodbye to an old friend at ABC No Rio. Cookiepuss was a steadfast companion in my volunteer shifts at the No Rio computer center, a cranky yet gregarious presence. I met her soon after moving to New York, and have hung out with her nearly every week for years. She had the run of the building at ABC No Rio, and was friends with all sorts of people. She was known and loved by punks and fine artists, by experimental musicians and bike mechanics, computer geeks and librarians, travelers and homebodies, photographers, screenprinters, anarchists, community organizers, zinesters, activists, performers, and weirdos of all stripes. For years, she received postcards from all over the world, including several from people who had never even met her in person. In her younger days, she was a ferocious mouser, and even as she shrank with age and lost some of her teeth she remained excited about food. She was an inveterate complainer; a pants-shredder; a cat remarkably comfortable with dirt; a welcoming presence to newcomers and a friendly old curmudgeon who never seemed to really hold a grudge even when i had to do horrible things like help her trim her nails. After a long life, she died having said her goodbyes, and surrounded by people who loved her. I couldn't have asked for better, but I miss her fiercely.

Continuing last month progress report onOUnit2. The release is just a few days away, I am testing real life application and the core of the work is already in the VCS. The basic features:

• better configuration setup
  • environment variable
  • command line options
  • configuration files
• improved output of the tests:
  • allow vim quickfix to jump in the log file where the error has happened
  • output HTML report
  • output JUnit report
  • systematic logging (verbose always on), but output log in a file
• choose how to run your test:
  • run tests in parallel using processes (auto-detect number of CPU and run as many worker processes)
  • run tests concurrently using threads
  • use the old sequential runner
• choose which test to run with a chooser that can do smart selection of tests:
  • simple: just run test in sequence
  • failfirst: run the tests that failed in the last run first and skip the success if they are still failing
• some refactoring:
  • bracket: use a registration in the context but easier to use
  • remove all useless functions in the OUnit2 interface
• non-fatal section: allow to fail inside non-fatal section without quitting immediately the whole test
• allow to use OUnit1 test inside OUnit2 (smooth the transition)
• timer that makes tests fail if they take too long, only when using the processes runner (I was not able to do it cleanly using threads and sequential)
• allow to parametrize filenames so that you can use OUNIT_OUTPUT_FILE=ounit-$(suite_name),log and have $(suite_name) replace by the test suite name
• create locks to avoid accessing the same resources within a single process or the whole application (typically to avoid doing a chdir while another thread is doing a chdir elsewhere)
• create a in_testdata_dir function to locate test data, if any

Still remaining to do, but quite straightforward:

• sys admin (website, release process)
• update the whole documentation

Some things that I decided not to do for OUnit 2.0 release:

• introduce a 'cached' state to avoid rerunning a test if you can programmaticaly determine that the result will be the same.

The main development is now done, but before releasing I decided to test it first on a real scale application. The first big migration to OUnit2, will be the OASIS test suite. This is a pretty big test suite (100+ tests) that takes a fair amount of time to run. I hope that during the next week I will be able to port the whole test suite and come back with some timing results. You can follow my progress on porting OASIS to OUnit 2.0, in github. Help wanted If you have a long standing issue with OUnit, this is the time to submit a bug. OUnit BTS If you want to try the dev version of OUnit:

 $> darcs get http://forge.ocamlcore.org/anonscm/darcs/ounit/ounit

Patches always welcome. You can read the documentation of the devel version the website.

As a maintainer of several software packages I often find myself copying text snippets from the README file into different places (savannah, github, freecode, emails, etc). Recently I had a need to generate a list of software packages that included every project s name, brief summary, license and URL. I could have generated that list manually by copying the text from every project s README and COPYING files. However then I would have to maintain my list manually to keep it in sync with all the projects. This easily leads to stale information, so I thought a better approach would be to put the information I needed into each projects source code version control system. The advantage is that the manual work to extract the information may be automated by a script, since the data is in a usable format. I ll explain here how my solution works. To be able to find the information using only the URL to the repository, I needed a filename convention. The filename I chose was BLURB; for the etymology, see Wikipedia s page about Blurb. The data format in the file is similar to normal email headers. An example illustrate the principles well. Below is the BLURB file for one of my projects.

Author: Yubico
Basename: libyubikey
Homepage: http://opensource.yubico.com/yubico-c/
License: BSD-2-Clause
Name: Yubico C low-level Library
Project: yubico-c
Summary: C library for manipulating Yubico YubiKey One-Time Passwords (OTPs)

The format is simple: UTF-8 text with each line starting with a header followed by a colon ( : ), some whitespace, and some content. If a line starts with whitespace, it is a continuation of the previous line s content (trim leading whitespace). The following table describes the fields that I use. I may update this blog post in the future with new fields or improved explanations (for reference, current date is 2013-09-24).

Header	Meaning
Project	Short identifier for the project (e.g., gcc , emacs )
Name	Official name of the project in English
Summary	Brief one-line summary of the project s purpose in English
Author	Origin of the project
Homepage	URL to the project s website
License	License keyword, preferrably using one of the SPDX license identifiers
Basename	The tarball basename, if different from the project name

Finally some reflection of the solution. After quick design, I thought that I couldn t be the first one with this problem, and I tried to find other similar efforts. I haven t been able to find any standardization effort that have the following properties:

• Stores the information inside each upstream project s own source code repository
• Provides a filename convention so that it is possible to find the data with only the source code repository link
• Encode data in a format that is easy to extract using simple command line tools
• Not encode information about releases (i.e., what happened in a particular version)

The related efforts that I found were SPDX which at first look seemed to offer what I wanted. However on closer examination it failed to deliver on all the requirements above, and appeared to have somewhat different goals. However I found the SPDX license list useful and refer to it. Another effort is Eric S. Raymond s freecode-submit and shipper but its primary focus is to encode information about each release. The design of the BLURB file is clearly influenced by these tools. Another influence has been Debian s specification for machine-readable copyright information. The Free Software Foundation s list of software projects seemed like another candidate, but it doesn t suggest any way to store the information in the upstream project itself.

Review: Throne of the Crescent Moon, by Saladin Ahmed

Series:	Crescent Moon Kingdoms #1
Publisher:	DAW
Copyright:	January 2013
ISBN:	0-7564-0778-8
Format:	Mass market
Pages:	367

Doctor Adoulla Makhslood is the last ghul hunter in Dhamsawaat. He's an old man, and tired, and increasingly uncertain whether he wants to continue putting his life in danger to fight one more fight. But there are no replacements; his young and idealistic dervish apprentice, despite obvious skill, is too inexperienced and uninterested in the knowledge and investigation that makes Adoulla so good at what he does. So, when a young boy shows up on his doorstep, a survivor of a vicious ghul attack, he goes hunting once again. And both finds something much darker and stronger than he expected and meets an unexpected ally: a shape-shifting girl who is herself a survivor of something far worse than ghuls. Throne of the Crescent Moon is a first-novel fantasy that has made quite a splash, including a Hugo nomination (although I thought a win was unlikely, and I was right). One of the more interesting comments I've read about it was the observation by Jo Walton that if it had come out in 1980, it would have been an amazing, unusually wonderful, non-normative book. That it isn't is evidence of the changes in fantasy since then. The field has grown. As you might guess from the publisher's insistence on comparing it with The Arabian Nights, and from the names mentioned above, this book is set in an unspecified Middle Eastern culture and draws heavily from its mythology. It does not contain any western characters; the entire story is native to its region. The same is true of the mythology, which gave it a refreshing originality for me. And while I'm not the best one to judge, the presentation of that setting seemed free of the tint of the exotic. People live here, there are factions and multiple cultures, and the supernatural is a backdrop to most of the city. This would be very unusual decades ago. It's a bit less unusual now, and the story itself is a familiar ensemble fantasy, if refreshingly free of extended map exploration journeys. Ahmed brings together five characters with very different backgrounds and throws their varying talents at a problem. A few of those elements are a bit too familiar: female sexuality as a threat to male power is a world-building element that I could do without, for example. I also found the villain completely inadequate in its unidimensional evil (reinforced with a few more torture scenes than I needed to read), and even the attempted complication felt too predictable to me. Except for one touch of perspective, I'd call Throne of the Crescent Moon a competent, enjoyable, but somewhat forgettable fantasy novel, albeit one that's refreshingly concerned with a city instead of countrysides and travel. That touch is in the age of several of the protagonists. We get sections following several of the main characters in tight third person, but Adoulla is the first protagonist and the focus of much of the book. And Adoulla is neither young nor inexperienced, and is not going through the typical fantasy bildungsroman. He's old, experienced, a bit set in his ways, cranky, cantankerous, and deeply in love with his city. In tone, this shifts the story towards Star Wars as seen through the eyes of Obi-Wan Kenobi instead of Luke Skywalker. And that change I really liked, and would be happy to see become more common in fantasy. There was a bit of a downside for me in three of the five main characters being older. At times, Throne of the Crescent Moon has an elegiac tone, a feeling of life, power, and time slipping away and cultures and ways of life being lost. That's not my favorite thematic element. I tend to find it more depressing than I really want in my reading. But, here, the mature perspective more than makes up for some occasional negativity. I particularly liked how the older characters treated the likely budding young romance, which would have been the center of many books in this genre, with bemused detachment and playful encouragement without giving it more significance than it deserves. There's another romance that ends up being more significant, and which needs the weight of time and well-lived lives to become so. I don't think this book deserves a Hugo, but it is an enjoyable fantasy with some interesting characters and a refreshing perspective and setting. The villain really isn't adequate to the story, there's a bit too much torture for my liking, and I could have done without a few of the tropes, but it's a solid entry in its genre and a pleasant few hours of reading. And despite being advertised as the first of a series, it comes to a satisfying conclusion. Rating: 7 out of 10

On a regular basis, I find myself the odd-man-out when it comes to talking about how to work with Python on Debian systems. I'm going to write this and post it so that I might be able to point people at my thoughts without having to write the same email in response to each thread that pops up. Turns out I don't fit in with the Debian hardliners (which is to say, the mindset that pip sucks and shouldn't exist), nor do I fit in with the Python hardliners (which is to say apt and dpkg are out of date, and neither have a place on a Development machine). I think our discourse on this topic has become petty and stupid in general. Let's all try to step back and drop a bit of the attitude. pip doesn't suck, and neither does apt. The truth is, both sides are wrong. As with any subject, the real answer here is much more nuanced than either side presents it. I'm going to try and present my opinion on this, in the way that both my Pythonista self and my Debianite self see the issue. Hopefully I can keep this short, to the point, and caked with logic. The case for dpkg (the Debianite in me) In defense of dpkg and apt, imagine having to install python-gnome2 on all your systems when you install. It'd be hell on earth. Imagine having a user try to do this. It's insane to assume that end-users will be using pip for this purpose. pip is fun and all, but it's also installing 100% untrusted code to your system (perhaps as root, if you're using pip with sudo for some reason), and hasn't been reviewed for software freeness, which is something Debian (and Debian users) take seriously. This isn't even to mention the hell that pip wreaks on dpkg controlled files / packages. Try to remember how much of your system running (yes, right now) is running because of Python or Python modules. Try to imagine how much of a pain in the ass it'd be if you couldn't boot into GNOME to use nm-applet to connect to wifi to pip install something. I'm sure even the most extreme pip'er understands the need for Operating System level package management. Debian also has a bigger problem scope - we're not maintaining a library in Debian for kicks, we're maintaining it so that end user applications may use the library. When we update something like Django, we have to make sure that we don't break anything using it (although, to be honest, the fact that we package webapps is an entire rant for later) before we get to update it to the newest release. Hell, with a few coffees, I could automate the process of releasing a .deb with a new upstream release, 100% unattended. I won't, however, since this is an insane idea. Let's go over a brief list of things I do before uploading a new package:

1. Review the entire codebase for simple mistakes.
2. Review the entire codebase for license issues.
3. Review the entire codebase for files without source, and track down (and include source for) any sourceless files (such as pickle files, etc).
4. Get to know the upstream, get to know open bugs, write something using the lib, in case I need to debug later.
5. Install the package.
6. Test the package.
7. Work out any Debian package issues (this is easy).

Now, a brief list of things I do before I update a package:

1. Review the changes between the last uploaded version (in diff format, if it's sane, otherwise get the VCS and review), ensure all the above are still OK.
2. Review for Debian-local issues (such as how it will upgrade, using piuparts, and adequate, etc).
3. Check to make sure it won't break any reverse dependencies.
4. Review for bugfixes that I might need to bring back to the stable release.
5. Figure out if I should (or even can) backport the package, if API is stable.
6. Review for bugs (upstream or in Debian) that I need to mention in the debian/changelog.

Clearly, this isn't a quick-and-dirty task. It's not a matter of getting a package updated (technically), it's a much more detailed process than that. This is also why Debian is so highly regarded for its technical virtuosity, and why the ISS decided to deploy Debian in space, despite other commercial distros such as Red Hat, or Ubuntu, and community distros, such as Fedora or Arch. It's also not Debian's job to package the world in the archive. This is an insane task, and it's not Debian's place to do it. We introduce libraries as things need them, not because we wrote some new library that someone may find slightly useful at some point in the future. maybe. Upstream developers and language communities (not only Python here) tend to lose sight of why we're doing this in the first place, which is our users. This isn't some sort of technical pissing contest to see who can distribute the software in the best way. Debian-folk always keep end users as our highest priority. I quote the Debian Social Contract, when I say that Our priorities are our users and free software. No one's trying to get developers to use dpkg to create software. In fact, as you'll see below, I actively discourage using system modules for development. The case for pip (the Pythonista in me) In defense of pip, the idea that Debian will keep the latest versions of packages is insane. The idea that we can keep pace with upstream releases is nuts, and the idea that every upstream release on pypi is ready to ship is bananas. b-a-n-a-n-a-annas. As a developer, I don't want to support every release, and I surely don't want other people depending on some random snapshot. Often times, I'll put stuff up on pypi as a preview, or to release often, and solicit feedback without having to give out instructions on using a git checkout (it's also easier to have them try a version from pypi so I can cross-ref the git tag to reproduce issues when they file them) pypi is easy, ubiquitous and works regardless of the platform, which means less of my development time is spent packaging stuff up for platforms I don't really care about (Arch, Fedora, OSX, Windows), even though I value feedback from users on those systems. The effort it takes to release something is limited to python setup.py sdist upload, and it's in a place (and in a shape) that anyone can use it without having 10 sets of platform-local instructions. Even ignoring all the above, when I'm writing a new app or bit of code, I want to be sure I'm targeting the latest version of the code I depend on, so that future changes to API won't hit me as hard. By following along with my dependencies' development, I can be sure that my code breaks early, and breaks in development, not production. Upstreams also tend to not like bug reports against old branches, so ensuring I have the latest code from pypi means I can properly file bugs. Lastly, I prefer virtualenv based setups for development, since I'm usually working on many things at once. This often means version mismatches in libraries, which brings in API changes (another whole rant here as well). I don't want to keep installing and uninstalling packages to switch between the two projects, and using a chroot(8) means a lot of overhead and that it's disconnected from my development environment / filesystem, so I resort to virtualenv to isolate my Development environment. Final notes I don't want to keep arguing about this. Just accept that the world's a big place and that there exist use-cases that both apt and pip need to exist and work in the way they're working now. At the very least, try and understand there exist smart people on both sides, and no one is trying to screw anyone over or keep their own little private club to themselves. Hopefully, going forward, we can make sure that the integration between these two tools gets better, not worse. Help make this dream a reality. Contribute to a productive tone, not a destructive one. In short:

• Use pip without sudo always. Don't tell people to use sudo.
• Use apt or dpkg when deploying system-wide.
• Understand people are going to package, and they will be more concerned about software using your library then keeping your library up to date.
• Understand Debian Developers and package maintainers have to do a lot of work when updating or sponsoring an upload.
• Understand upstream developers can't be bothered to fix every issue with every release (release early, release often) with some snapshot you introduced into unstable.
• Use pip and virtualenv in development setups, so we can upgrade your app when we upgrade the lib.

Well at least he should be according to Sartre though I am not entirely convinced the repercussions of my choice to manufacture another folding chair were entirely thought through.

After my most recent posting the urge to do "just one more iteration" became too great and I succumbed. I therefore present version 4 of my folding chair which corrects all the previously discovered issues.

The popliteal height (420mm) and buttock popliteal length (400mm) are both comfortable for a wide selection of people. The seat slopes a few degrees front to back and the back rest no longer comes further forward than the rear of the seat.

There is a small gap above where the seat folds in when flat but that is only an aesthetic issue when being stored.

Manufacture wise the design is simple to produce although I really will have to teach our CNC router how to use the round over bit to reduce the finishing steps as currently that takes longer than the CNC operation.

In future if I make more of these I will use this design and, once she is less annoyed at me for making another chair, I am going to consult with my wife on adding some cushioning material to the seat and backrest.

And of course that concludes my furniture making for a while...yeah, right!

there have been comments which have complained about my usage of space on sheets and suggested I waste too much material. That is probably true and in my own defence I have not been working with this machine for very long and am not quite used to what I can "get away with" yet.

I was looking at the sheet after removing the last chair design and had a thought, I had not attempted a side X type folding design and perhaps I could squeeze one into the offcuts? I kinda got carried away, it roughly went:

• Measure the available offcut space
• Measured the remaining 18mm dowel leftover from my dowel hinge experiments
• Found the largest width and height area I could get out of the sheet the CNC router ruined.
• Sketched a design
• Capture design to a DXF
• Carefully spread the pieces over the available material in the CAM software
• Generate a toolpath.
• Cut material

If all of that sounds like and utterly mad way to design a size X stool, you are of course correct, but it worked, and it was a very fast process taking less than four hours from idea to stool.

There are a couple of issues:

• the popliteal height is 470mm ( I was aiming at 420 and missed...badly)
• It uses a lot of expensive hardwood dowel (1373mm plus cutting width and only way I could get it accurate was to use the disc sander to remove fractions till the length was correct)
• I used pockets for the interference seat joints rather than through cuts and discovered that you need to allow tolerance depth (the pegs are 10mm deep and the sockets need to be at least 10.2 not the 10mm I cut)
• Dowel joints are great but have a small surface area so friction fit joints work loose.

It is pretty simple to put together and aside from needing half the clamps in makespace to hold it in place while the glue dried, I had no trouble.

Though this is definitely not a case of use glue "sparingly" I put generous amounts in all the dowel joints and all the seat slots and got very little ooze so I guess it could have used more.

The final varnished stool is pretty robust but folds up nicely the concept of hooking to its own pivot dowel means it stays closed when flat which makes it very portable.

Total cost was an estimated 10.00 ( 4.25 dowel, 2.50 of 24mm ply, 1.75 for 18mm ply, 0.50 tool wear, 1.00 varnish) though the materials in my case could be argued to have cost nothing.

It has been suggested that I could make an entire picnic table and chairs set this way but if I did I would reduce the stool height by 50mm and examine ways to use less dowel.

This is usually the bit where I point you all at the freely usable design files on github and all the photos on flikr and wrap up.

But you know what the Monty Python boys say? "Nobody Expects the Spanish inquisition"

Or in this case my final (and yes I am going to do something else next) chair design. It is based on the stool, in fact it is the stool design with the outer legs extended and a back rest added.

The modified design reduces the dowel requirements to 775mm but requires a bit more sheet material (cannot get this one entirely from offcuts).

Total cost was an estimated 10.50 ( 2.50 dowel, 4.50 of 24mm ply, 1.75 for 18mm ply, 0.50 tool wear, 1.25 varnish).
Because it is based on the stool design it suffers from the height issue and in addition the back rest is a bit far back to be completely comfortable.

Neither of the side X designs have flaws that interest me enough to follow the iterative approach again to solve them. Both the designs work well enough and rounded out my adventures with folding chairs and indeed furniture for now.

As always the design files are on github and the images are on flikr.