A bunch of links nabbed from Michael Tiemann's OSI blog

• Getting Schooled In Design
  
• Designing a New OSI
  
• Redhat Magazine - Design Thinking special
  
• Intro to design thinking
  
• Stanford's new d.School
  
• The Empathy Economy
  
• Thinking design: A pencil, a ruler, and a cup of coffee (Part 1,Part 2)
  
• The Power of Design
  
• Better Linux release notes through design thinking
  
• Design Gets Its Due in Davos
  
• Design books that inspire us
  
• The Business of Design

I like this, because the second from last link focusses on design books. 3 of which I already own. Though it would be good to read the other 7 probably.

It also matches with the way I tend to manage development in Kamaelia's SVN - it's set up to encourage a high diversity of ideas, large amounts of checkins, and rigourously stable and clean code in releases. Design is crucial in making something new. Taking that design and moving it to engineering is just as vital however, and there are some very important steps to bear in mind how that happens. (not least that the skill set can be extremely different and many people need to learn at least one of those sets of skills)

Quick and simple access to the BT console (based on notes here)

# sdptool add-channel=27 SP
# rfcomm listen /dev/rfcomm0 27
Waiting for connection on channel 27
Connection from 00:11:22:33:44:55 to /dev/rfcomm0
Press CTRL-C for hangup
connect using btconsole.py on phone
on different console on linux
minicom -s -m (set device to /dev/rfcomm0 )

Also, facebook image syncing:

curl 2>/dev/null -O -A "Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1) Gecko/2006102
3 SUSE/2.0-30 Firefox/2.0" http://www.facebook.com/p/Michael_Sparks/747770380
F=`grep profileimage 747770380|sed -e "s/^.*http:/http:/"|sed -e "s/\.jpg.*/\.jpg/"`
G=`grep profileimage 747770380|sed -e "s/^.*http:/http:/"|sed -e "s/\.jpg.*/\.jpg/"|sed
 "s#.*/##"`
curl 2>/dev/null -O $F
mv $G michael.jpg
cp michael.jpg /usr/local/httpd/sites/com.yeoldeclue/docs/michael.jpg

Ever needed to only allow emails from specific people through to specific addresses using exim? If you have then hopefully this post is of use to you. I'm writing it up here because it's proving useful to me right now.

Blocking email to all addresses except specific ones using exim is pretty easy. First of all create one file /etc/blocked_emails.list, and add to it a list of email addresses which are blocked:

foo@bar.com
bibble@bar.com
etc@bar.com

Next step is to create a list of addresses those emails can send to. Put these into a file called /etc/exceptions.list and list one local part per line - for example:

john
bob
rita

You then have two possible modes here. You can either defer accepting email so it takes a while to bounce, or have it deny delivery immediately. The former is in many cases actually preferable because someone will assume its been delivered and only find out its bounced, with a relatively innocuous error message some days later. Given you only tend to block people because they're being OTT, this gives them a chance to cool off and for any nasty messages to be lost, unread, in the ether.

To have the mail system defer delivery of email from any of the blocked_emails, to any address other than any of the emails in the exceptions, put the following in your exim ACL's rules for rcpt checking:

begin acl

acl_check_rcpt:

  accept local_parts   = /etc/exceptions.list
         senders = /etc/blocked_emails.list

  defer   message = Mailbox full, retry later
          senders = /etc/blocked_emails.list

The message is deliberately innocuous. However if the person (or persons) ramps up their antisocial behaviour and doesn't take the hint, you can change this to instantly deny access and send a message back immediately rather than 4-24 hours later by changing defer to deny:

begin acl

acl_check_rcpt:

  accept local_parts   = /etc/exceptions.list
         senders = /etc/blocked_emails.list

  deny   message = Your email has not been and will not be delivered - it has been blocked
          senders = /etc/blocked_emails.list

It's really sad when things come to this. There is an advantage to using config files like this however in that you only need to edit the contents then of blocked_emails and exceptions in order to re-allow emails through, or to block access completely to all emails.

In case anyone is wondering why I know these rules and why I'm writing it up - it's because I'm in the situation where I'm having to use this right now.

The PyCon UK Society has announced a UK Python Conference. This is an affordable community conference taking place on 8th/9th September. The conference is fantastic value, especially if you take advantage of the extra early bird booking offer. Both new and experienced Python programmers will benefit from the varied programme.

Why am I posting about this? I'd personally like to invite UK pythonistas to come, share their knowledge with others, learn new things and hang out. It's a community conference, which means it has the following characteristics:

• You can help make it amazing, by participating & speaking, by helping, by attending!
• It is cheap
• It will be fun, and accessible. We (I'm helping organise this :) ) really want the conference to be accessible to all, from those who have no idea of what python is, let alone coded in it, through to those who are working on their upteenth bytecode hack/compiler.

Seriously though aside from this, I'm really posting about this because despite being a language pragmatist - ie I'll use any language that gets the job done - I'm largely finding that I'll use python for almost everything these days. Community conferences are a real opportunity to dive in and help and learn and share. Like python itself, the conference is also platform agnostic, so you're welcome if you use Windows, Mac OS X, Solaris, FreeBSD, or even the same OS as me - Linux :) .

From the pygame mailing list:

From: Noah Kantrowitz [ check pygame archives for email (don't want to cause spammage) ]
Subject: [pygame] Calling all game developers

Calling all game developers! The One Laptop Per Child project needs
talented game developers to work on software for the XO laptops. Thanks
to a few awesome developers, PyGame is now up and running under Sugar
(the OLPC graphical environment) and should be included in the build
system shortly. What we need now is games geared towards children in
developing areas. Information about PyGame on the XO can be found at
http://mailman.laptop.org/pipermail/games/2007-April/000036.html. I
would ask anyone interested in either building new games or porting
existing ones to join the OLPC games list
(http://mailman.laptop.org/mailman/listinfo/games) and discuss your
ideas there. This is a chance to have a major impact on the lives of
millions of children, as well as work on a unique platform. If you have
any questions please don't hesitate to email me, or ask on the games list.

--Noah Kantrowitz
OLPC Evangelist

If you know and enjoy pygame and are looking for something good and fun, it'd be well worth getting in touch.

Tongue in cheek, but I quite like (based on occam's razor):

"Given a variety of options, the dumbest one is probably right" - applies to "which decision did management make"

(not to be taken seriously :)

I had a great idea today, and I've registered the domain for it just now. I'm probably going to knock up something quite quickly (I hope - time permitting, having a social life is restricting part time hacking somewhat :), but it's something that's probably useful for work, but also scratches a few itches as well. In short though, it's the beginnings of a possible answer to the question: How do you do a bigger piece of high quality film or TV in an open source way. That said, I don't want to restrict the tools to just an open source/creative commons approach, but I think this has some potential real mileage. More as I go on.

Well, after getting a mini axon standing" compiling using shedskin yesterday, I've taken the next steps to see if we can get a full mini-axon system compiling. The good news is that, with 1 piece of manual assistance, we can! As a result I have here a compiled version of a mini-axon system.
Yes, you heard right - we have a compilable to executable version of Kamaelia thanks to shedskin.

First of all, what manual change do we need to make? Well, due to the fact we activate various microprocesses in the same way, we need to warn the C++ compiler of this fact, and help shedskin out a bit. The code shedskin creates that's problematic is this:

• int scheduler::activateMicroprocess(lambda2 some_gen, microprocess *some_obj) {
      __iter<int> *microthread;

      microthread = some_gen(some_obj);
      (this->newqueue)->append(microthread);
      return 0;
  }
  

This is the fixed code:

• template<class Klass>
  int scheduler::activateMicroprocess(__iter<int> *(*some_gen)(Klass *), Klass *some_obj) {
      __iter<int> *microthread;
  
      microthread = some_gen(some_obj);
      (this->newqueue)->append(microthread);
      return 0;
  }
  

A corresponding change occurs in the generated .hpp file as well. The resulting code then compiles cleanly and runs correctly :-) Yay!

The mini-axon code looks like this:

• class microprocess:
      def __init__(self,name="hello"):
          self.name = name
  #------------------
  def scheduler_main(zelf):
      result = 1 # force type of result to int
      for i in xrange(100):
          for current in zelf.active:
              yield 1
              try:
                  result = current.next()
                  if result is not -1:
                      zelf.newqueue.append(current)
              except StopIteration:
                  pass
  
          # This shenanigans is needed to allow the type checker to understand
          # The various types in this function...
          for a in xrange(len(zelf.active)): zelf.active.pop()
          for b in zelf.newqueue: zelf.active.append(b)
          for c in xrange(len(zelf.newqueue)): zelf.newqueue.pop()
  
  class scheduler(microprocess):
      def __init__(self):
          # super(.... not supported)
          microprocess.__init__(self)
          self.active = []
          self.newqueue = []
  
      def activateMicroprocess(self, some_gen, some_obj):
          microthread = some_gen(some_obj)
          self.newqueue.append(microthread)
  #------------------
  class component(microprocess):
      def __init__(self):
          microprocess.__init__(self)
          self.boxes = { "inbox" : [], "outbox": [] }
      def send(self, value, outboxname):
          self.boxes[outboxname].append(value)
      def recv(self, inboxname):
          result = self.boxes[inboxname][0]
          del self.boxes[inboxname][0]
          return result
      def dataReady(self, inboxname):
          return len(self.boxes[inboxname])
  #------------------
  def postman_main(zelf):
      while 1:
          yield 1
          if zelf.source.dataReady(zelf.sourcebox):
              d = zelf.source.recv(zelf.sourcebox)
              zelf.sink.send(d, zelf.sinkbox)
  
  class postman(microprocess):
      def __init__(self, source, sourcebox, sink, sinkbox):
          microprocess.__init__(self)
          self.source = source
          self.sourcebox = sourcebox
          self.sink = sink
          self.sinkbox = sinkbox
  #------------------
  def Producer_main(zelf):
      while 1:
          yield 1
          zelf.send(zelf.message, "outbox")
  
  class Producer(component):
      def __init__(self, message):
          component.__init__(self)
          self.message = message
  #------------------
  def Consumer_main(zelf):
      count = 0
      while 1:
          yield 1
          count += 1 # This is to show our data is changing :-)
          if zelf.dataReady("inbox"):
              data = zelf.recv("inbox")
              print data, count
  
  class Consumer(component):
      def __init__(self):
          component.__init__(self)
  #-------------------
  p = Producer("Hello World")
  c = Consumer()
  postie = postman(p, "outbox", c, "inbox")
  
  myscheduler = scheduler()
  myscheduler.activateMicroprocess(Consumer_main,c)
  myscheduler.activateMicroprocess(Producer_main,p)
  myscheduler.activateMicroprocess(postman_main,postie)
  
  MT = scheduler_main(myscheduler)
  for i in MT:
      pass
  

As you can see, this isn't really so very different from the usual code. (There's lots of sugar missing of course!)

Well, I looked at shedskin as I mentioned the other day, and now have this working locally. One thing we encourage people new to Kamaelia is to build their own mini-core of the system - Axon. This provides basic microprocesses, basic component communications and scheduling. Whilst this may sound hairy, having run the mini-axon tutorial past many new programmers, including the tutor list, it seems pretty OK. (The tutorial is pretty gentle and provides very small simple steps aimed at someone new to python) The rest of this post after the fold has the meat in.

The other handy thing hough is that this provides a neat mechanism for handling how to experiment with new systems written from scratch, such as Shed Skin. As a result, I've done this, and the first step towards a Kamaelia system is the ability to tag a generator with context, and run multiples of them. Along the way I've discovered many limitations of shed skin (which is spectacular software IMO), which is by no means a criticism, but to its credit this can be worked around. As a result here's a basic concurrency framework in python that compiles directly to very reable C++.

Limitation 1, shed skin generators can't be a method. Therefore any class related stuff must not have any generator in it! Thus our microthread class looks like this:

• class microthread:
      def __init__(self,name="hello"):
          self.name = name

The name is a test to check differentiation is happening.

Our microthread now is then just a standalone generator, but takes a mutable argument as if its pretending to be in the class:

• def mainG(zelf):
      i = 1
      while i < 10:
         yield zelf.name + ":" + str(i)
         i = i+1

Incidentally, the way you therefore create a mainG microthread is as follows:

• mainG(microthread("name")

This looks a little ugly, but the important thing as far as I'm concerned is, it works. Spectacular :)

Limitation 2: Shedskin looks at an argument "self", and thinks "that's bogus in a class definition, I'll get rid of that". This causes problems here, which is why we have "zelf" instead.

Limitation 3: No list comprehensions, and also if you put too many function calls together like(this(sort(of(thing())))), then shed skin creates intermediary classses to help itself. As a result you need to be MUCH more explicit about things you want to happen if you want to avoid this foibles.

So we create our microthreads:

• N = [ "One", "Two", "Three", "Four" ]
  MT = []
  for n in N:
      MT.append( microthread(n) )

Attach the generator behaviour to them and put them in a simple process list:

• PS = []
  for M in MT:
      U = mainG(M)
      PS.append(U)

And finally we can have a simple manual scheduler to run them:

• while 1:
      for P in PS:
          beta = P.next()
          print 'hello, world!', beta

That is then translated to C++ by shedskin which you can then compile and run and get the following output:

• hello, world! One:1
  hello, world! Two:1
  hello, world! Three:1
  hello, world! Four:1
  hello, world! One:2
  hello, world! Two:2
  hello, world! Three:2
  hello, world! Four:2
  hello, world! One:3
  hello, world! Two:3
  hello, world! Three:3
  hello, world! Four:3
  hello, world! One:4
  hello, world! Two:4
  hello, world! Three:4
  hello, world! Four:4
  hello, world! One:5
  hello, world! Two:5
  hello, world! Three:5
  hello, world! Four:5
  hello, world! One:6
  hello, world! Two:6
  hello, world! Three:6
  hello, world! Four:6
  hello, world! One:7
  hello, world! Two:7
  hello, world! Three:7
  hello, world! Four:7
  hello, world! One:8
  hello, world! Two:8
  hello, world! Three:8
  hello, world! Four:8
  hello, world! One:9
  hello, world! Two:9
  hello, world! Three:9
  hello, world! Four:9
  terminate called after throwing an instance of '__shedskin__::StopIteration*'
  Aborted

This is exactly what I would expect, and is as far as I'm concerned absolutely spectacular on the part of Mark. Really, really cool work.

Now I'm having lunch, after lunch I'll see if I can get the rest of a mini-axon up and running. If so, this could be quite quite fun :-)

Summary - We ruled!

• http://www.entertainmentmanchester.com/theatre/reviews/rncm-mikado.htm

Hearing of people enjoying the show is great, and makes all the hardwork worthwhile. If you still want to see the show, it's being put on again in Buxton for one night only - March 3rd.

Photos from the show:

• http://www.mugss.org/show/photos/