As such, it’s impossible to manually set powersaving either using sysfs or via a command like iwconfig power.

Worst part is that the drivers aren’t even correctly advertising themselves to mac80211 (the underlying layer of the WiFi stack) as able to handle power saving operations thus preventing any event to be propagated back to the driver. You can find more information about the problem on the following thread.

Of course this sucks quite a bit for people who cares about their battery life and who don’t want to wait for 2.6.32 kernel. That’s why we decided to try up compat-wireless.

Compat-wireless is a set of scripts that allows you to install the freshest drivers from the linux-wireless project (list of driver here) in a safe fashion i.e. without messing up your distribution supplied modules and without need for a kernel recompilation. These new modules are also very easy to uninstall and everything is made to prevent you from nuking too much your system.

Turns out that in recent revision of the drivers (>= 2009-10-28), powersave is back in a sort of automated fashion and blocking powersave operations are now limited to the faulty driver/chipset : iwl4965. So if you either use iwlagn or iwl3945 (lsmod will tell you) chances are good that you will get back your nice powertop output (it did for a friend and I).

As for installing the beast, the instructions on the official website starting from here are simple and straightforward.

Of course, if you were using iwl4965 your are still left out. However, if power saving weren’t breaking up your driver on earlier kernel version, you can simply comment out the .broken_powersave = true configuration statement in iwl-4965.c (line 2282 or so) under drivers/net/wireless/iwlwifi/.

If you are using Wicd and usually stare at Banshee trying to download cover art or post to last.fm while you are disconnected, the following patch add just the support to fix this.

Here is the associated bug report to get the patch integrated.

In other news, school restarted with its bunch of new responsibilities, limiting significantly free hacking time.

• Use an indexed data structure as your source like an array, a list or anything which implements the generic IList<T> interface.

  You can also use ParallelEnumerable.Repeat and ParallelEnumerable.Range as input. Notice the ‘Parallel’ word in front as it’s not the same as Enumerable.(Range|Repeat)

• Never use an ordering operator like OrderBy and never assume that the query should be ordered.

  The overloads of some operator that provide an index integer are also to avoid.

• As a general rule, try to stick to the general scheme of Select-Where-Aggregate with any number of Select and Where (like the famous MapReduce).

  The syntactic sugar operators based on Aggregate like Min, Max, Average, etc… can also be used.

• If you can manage it in your code, use the ForAll method with an action delegate instead of iterating over the query with foreach

• Of course, forbid any synchronization (locks, semaphore, …) inside the operator selectors/predicates. The purest your lambdas are, the better.

• The functions used with operators should be predictive and stable i.e. not depend on something uncertain time-wise like a network call and should yield approximately the same execution time with each input.

  Sure, this is not always possible but if it is, it does prevent the engine from having to repeatedly balance the query execution itself.

The PLinq MSDN page contains some additional tricks and explanations if you are interested.

Check it out : http://blip.tv/file/2402061/

He even cite Mono around 4:30 (btw Erik, Mono has supported C# 3.0 for quite a long time now ).

To conclude, « Go purify yourself because you are all sinners » .

Check out the following message on Moonlight mailing-list for instructions on how to get the same thing.

Just to make you salivate :

BubbleMark running at ~50 fps without too much visual glitches
(direct link : http://www.youtube.com/watch?v=Ekfb6jCyDmM)

Two hacking days later, I actually got something to « work ». At the moment it’s quite rough, hacky and it probably kills kitteh too (be careful, it makes shana angry, you wouldn’t like that).

Basically, what I did is to plug the OpenVG layer inside Moonlight custom version of cairo (using that code as a base) and then tweaked Moonlight to use the new surface (together with some changes in how drawing and caching is done internally).

Following is a screencast of the thing running Bubble Mark :

(Direct link : http://www.youtube.com/watch?v=dywInr08ySg)

As you can see there are a lot of drawing issues remaining but the basic stuff is here. The code is not terribly faster (+10 fps or so) but that may come either from a bug in my graphic card driver (it already does the bizarre thing of slowing down after some time) or an other part of Moonlight.

It will definitely be better when OpenVG becomes more widespread, has more optimized implementations and can actually run on its own rather than on top of OpenGL (I’m eager to try that on top of Gallium3D when it will be ready).

As for inclusion in the mainline tree, I don’t know. I mostly did the thing for fun as a proof-of-concept and it’s certainly far too crappy to ever get integrated as is, but maybe someone will step up and do it correctly later .

Talk is cheap. Show me the code.
— Torvalds, Linus

Summary

Zencomic is the comic strip-driven productivity enhancer that periodically makes your day funnier by showing comic like Dilbert or XKCD in a bubble.

What’s new aka The Cool Stuff ™

New, window-based, popup

Tired of having some comic showing far too small ? This is for you !

Now, if you go to the preference dialog, you will be able to switch to a window-based popup which shows your comics in all their greatness at the expense of taking more window space and making your boss, who was incidentally passing by, angry at you (in that case, a quick click on the popup will close it).

Can I haz lolcats ?

Lolcat greatness is here with the addition of a new addin :

The remaining

• For the Gnome Do junkie, Zencomic now correctly comes with a .desktop file so that you can launch it from there
• Made the preference dialog show in a little saner way i.e. by coming up directly at the front (which apparently wasn’t the case with some WM).
• The traditional round of bugfixes (should you still spot one don’t hesitate to manifest in the comments)

Downloadz

Tarball : http://netherilshade.free.fr/mono/zencomic-0.2.1.tar.gz

If by any chance you feel this is an application that should come in your distribution, don’t hesitate to contribute some packages .

Since we are nearing midterm evaluation, I thought about doing a kind of status report like last year. Unfortunately, I haven’t been as active as I wanted to this time (exams were more time consuming this semester). However there is still some cool stuff that have already landed and which are described next.

What has been done since last year

Actors and Software-transactional-memory goodness

I took some time to implement rudimentary version of those two parallel programming paradigms earlier this year.

See this post which describes in more details the ideas behind them and some examples.

New more efficient scheduler’s deque

The scheduler’s deque that was used before was quite complex due to the fact that the inherent storage mechanism was based on a doubly linked-list which is rather hard to get right when you add parallel and concurrency constraints (see ABA problem for instance).

The algorithm I was using was mostly designed with C++ in mind where you can mess up with pointers pretty easily and make freely use of CAS on pointers as integers. Since I wanted to avoid any kind of unsafe or native code in the library, I tried to port that algorithm down to C#.

After some mail exchange with a fellow person (hey Susan o/) who was using Mono’s ParallelFx on a big box in a laboratory, we started to see some concurrency problems with my code. Turns out that the ABA prevention code wasn’t really working with my C# rewrite. Therefore I decided to hunt for another, more C#-friendly, type of scheduler’s deque.

Actually, I did find it and it’s the one used now under the CyclicDeque name. It’s particularly swift because it only do integer manipulations that are particularly fast with the C# Interlocked methods and doesn’t suffer of the ABA problem because, using the vast range of values available with 64 bits integers, it’s based on a forward-only algorithm.

With the tests I was able to do, this new deque works more reliably and faster than the precedent. It’s currently enabled by default but I need to do some 32 bits checks to see if it behaves as expected on those plateforms.

New types

Following the new type introduced as part of my first SoC and the two parallel paradigms I described above, I have done some other parallel and concurrent code to be used both internally and publicly.

One of those is a new collection, ConcurrentSkipList that provides a thread-safe implementation of a skip-list (a nice tree-ish list container). This skip-list implementation is also used for the ConcurrentDictionary type.

The other is a stripped down CountdownEvent called Snzi (Scalable non-zero indicator) that basically do the same thing except that instead of keeping a count record, Snzi just tells in a binary fashion if there is or not a count remaining. That weaker semantic opens the door for more scalable and efficient optimizations.

Optimizing, fixing and hardening

The final task that occupied me during the inter-soc period was mostly tuning and bug-fixing the existing parts with a focus on Task reliability and PLinq performance and correctness.

What have I begin to do for this SoC

Currently I’m hard working on the .NET 4 port of Mono’s ParallelFx as it comes with a whole lot of new stuff and API changes.

The ParallelFx team over at Microsot has been publishing posts these last months about the new things coming down the pipe (check out their blog if you still haven’t do so).

At the moment, the System.Threading.Tasks namespace port is fairly complete and Tasks/Future unit tests are all back to green.

I’m now working a bit on the Collections namespace, adapting some of my code to the new API (notably ConcurrentDictionary) and seeing how to implement the new Partitioner pattern.

What to expect next

First of all, the following weeks are going to be quite more productive as, with big thanks to Alan and Miguel, I’m going to spend a month in Dublin hacking in the Novell offices. Looking forward to this.

As for the next, the plan is to continue porting the existing code to .NET 4, first with the Parallel loops class (with probably some further optimizations on data source partitioning) and then PLinq.

In addition, since Mono recently enabled the .NET 4 profile in SVN, some of the ParallelFx code will also soon transition from the google code repository to official Mono’s trunk for early mass consumption.

Finally, last but not least, I’m going to devote the rest of the summer to testing ParallelFx more extensively with, both, improving the existing test suite with harder parallel stress-testing and the development of a Chess-like parallel correctness checker.

See you at the end of the SoC for another full report .

Let’s say for instance that you want to enable at compile time a specific feature in your project. Now what you can do is add a switch to your deployment project which will be turned in something like --enable-super-feature on configure side (i.e. you will be able to run configure like ./configure --enable-super-feature).

This will actually define (as in #define) a symbol that you can use with #if … #endif constructs in your code to activate your specific feature.

Since we are at it, here is a little screenie :

I will add support asap for simple makefile projects. The UI is also probably a bit rough, if there are any usability expert out of there I will gladly accept any sensible criticism .