OSSPACK

I just visited Portland and discovered a few places that I didn't know about when I lived there - and neither did several other veteran Portlanders. For your edification, the top three "Gee, I wish I'd known about that" for me:

To his credit, Zach Brown has been trying to get me to go to Teardrop Lounge for months, but I'm still grumpy I didn't know about this place sooner. The proprietors are certified bartender nerds who craft the most amazing and subtle cocktails from the most unlikely substances. They make their own tonic water, they are that into the science of drink. It's also a beautifully decorated mellow space. Someone should organize a beering there.

Jake's Famous Crawfish is one of those well-known landmarks that you ignore because, hell, everyone knows about this place and it can't possibly live up to the hype. Well, actually, Jake's really *is* one of the top 10 seafood restaurants in the nation. Let me think... Yep, the best seafood I've ever had. Prices to match, but you gotta live sometime.

Ace Hotel in downtown Portland is a wonderfully funky yet high class hotel located one block from everything (or at least one block from a free ride on Portland's excellent public transit system to everything). The Ace is located in what used to be Crackhead Central but is now a bustling hip neighborhood whose greatest downfall is the inevitable infestation of hipsters. I'm okay with that; I'm already immune from living in the Mission.

Feel free to leave your best-of-Portland comments...

We have released Banshee 1.0 Release Candidate 1 just over a week after Beta 2, and with over 24 bugs fixed and a few last minute features.

• View the release notes
  
• Banshee 1.0 RC 1 Source (bz2)
  
• openSUSE 10.3 users can
  
• Foresight 2.0 users: Use PackageKit or Conary to install banshee-1
  
• Ubuntu users should go to the Banshee team's PPA
• Note: you might get Beta 2 until RC 1 packages are up

Banshee 1.0 is right around the corner. We are now string and feature frozen until its release, so translators, please update your translations!

Digg It!

After Andrea O. K. Wright’s wildly popular (popular as in she had to schedule a second session after the first one literally overflowed with people) RailsConf talk it seems like now is a good time to give an update on my plans for the Omnibus Concurrency Library, especially after I’ve neglected it for so long.

At this point, the next version of the library is likely to be a complete rewrite, licensed under an MIT-style license similar to Rubinius’. It will aim to support at least the following Ruby implementations, with others following as time and interest permit:

• Ruby 1.8
• Ruby 1.9
• Rubinus
• JRuby

Portability

Presently, only JRuby presents opportunities for improved parallel performance with Omnibus’ thread-centric implementation; under Ruby 1.8, 1.9, and Rubinius, performance will necessarily be equal to or less than single-threaded performance. Why support them at all? There are two main reasons:

The first reason to support green-threaded Ruby implementations is for the sake of portability, allowing the same program that runs under JRuby on a multi-core behemoth from Sun to scale all the way down to a single-CPU machine running Ruby 1.8 with its green threads.

Secondly, concurrent programming abstractions are often convenient ways to structure programs even on single-processor systems. (If they weren’t, nobody would ever bother with Ruby 1.8’s green threads.)

Additionally, the concurrency picture for some of these Ruby implementations is not necessarily bleak in the long-term: Rubinius already permits taking advantage of multiple threads per process in separate VMs. A future version of Rubinius may offer more fine-grained multicore support, and a future version of Omnibus may find ways to exploit things like the existing per-VM multicore support, or even include support for fork-based parallelism for some purposes.

Organization

Rather than Omnibus remaining a monolithic library, I’m also going to be breaking things up in order to enable individual components to be released as separate gems (and hopefully in a more timely fashion):

• concurrent – “omnibus” gem which pulls in the others as dependencies
• concurrent-actors – Actors for Ruby
• concurrent-futures – Futures for Ruby
• concurrent-joins – Join calculus for Ruby
• concurrent-parallel – Parallel algorithms and parallel extensions to core/stdlib classes (corresponding roughly to TBB parallel algorithms)
• concurrent-primitives – Grab-bag of simple primitives like channels
• concurrent-selectable – Semaphore and a few other primitives which can be waited on using existing event-based IO libraries, or just IO.select (DONE)
• concurrent-sequential – Force strict sequential execution of asynchronous tasks, even in the face of multiple threads or reentrancy. Don’t laugh, it’s useful.
• concurrent-tasks – Task-oriented parallelism (similar to TBB tasks)

Major Changes and Incompatibilities

One of the major changes coming is that the library will handle asynchronous tasks (e.g. from futures, or joins) by dispatching them to a TBB-like task scheduler instead of simply spawning a new thread for each task. In most cases this means that the creation of continuation tasks is the preferred alternative to blocking, although there will still be provisions to support blocking tasks. The largest effect of this change will be the elimination of transparent futures from the core library, since they have the effect of causing arbitrary tasks to block, and have consistently been the most difficult feature of the library to implement portably anyway.

There will also be some less drastic, but incompatible, changes to the rest of the existing APIs. In particular, parallel algorithms will take grain sizes rather than a count of threads to spawn, and the actor API will be modified to match the current Rubinius API more closely.

Timeline

Especially since Omnibus is a spare time project for me at the moment, I can’t commit to a timetable for the new release, but at the moment I’m aiming to have the new release out in 2-3 months. Watch this space.

(Incidentally, feel free to contact me if you’re interested in funding some aspect of Omnibus development. I am committed to finishing Omnibus regardless, but obviously paid projects have to take precedence.)

After Andrea O. K. Wright’s wildly popular (popular as in she had to schedule a second session after the first one literally overflowed with people) RailsConf talk it seems like now is a good time to give an update on my plans for the Omnibus Concurrency Library, especially after I’ve neglected it for so long.

At this point, the next version of the library is likely to be a complete rewrite, licensed under an MIT-style license similar to Rubinius’. It will aim to support at least the following Ruby implementations, with others following as time and interest permit:

• Ruby 1.8
• Ruby 1.9
• Rubinus
• JRuby

Portability

Presently, only JRuby presents opportunities for improved parallel performance with Omnibus’ thread-centric implementation; under Ruby 1.8, 1.9, and Rubinius, performance will necessarily be equal to or less than single-threaded performance. Why support them at all? There are two main reasons:

The first reason to support green-threaded Ruby implementations is for the sake of portability, allowing the same program that runs under JRuby on a multi-core behemoth from Sun to scale all the way down to a single-CPU machine running Ruby 1.8 with its green threads.

Secondly, concurrent programming abstractions are often convenient ways to structure programs even on single-processor systems. (If they weren’t, nobody would ever bother with Ruby 1.8’s green threads.)

Additionally, the concurrency picture for some of these Ruby implementations is not necessarily bleak in the long-term: Rubinius already permits taking advantage of multiple threads per process in separate VMs. A future version of Rubinius may offer more fine-grained multicore support, and a future version of Omnibus may find ways to exploit things like the existing per-VM multicore support, or even include support for fork-based parallelism for some purposes.

Organization

Rather than Omnibus remaining a monolithic library, I’m also going to be breaking things up in order to enable individual components to be released as separate gems (and hopefully in a more timely fashion):

• concurrent – “omnibus” gem which pulls in the others as dependencies
• concurrent-actors – Actors for Ruby
• concurrent-futures – Futures for Ruby
• concurrent-joins – Join calculus for Ruby
• concurrent-parallel – Parallel algorithms and parallel extensions to core/stdlib classes (corresponding roughly to TBB parallel algorithms)
• concurrent-primitives – Grab-bag of simple primitives like channels
• concurrent-selectable – Semaphore and a few other primitives which can be waited on using existing event-based IO libraries, or just IO.select (DONE)
• concurrent-sequential – Force strict sequential execution of asynchronous tasks, even in the face of multiple threads or reentrancy. Don’t laugh, it’s useful.
• concurrent-tasks – Task-oriented parallelism (similar to TBB tasks)

Major Changes and Incompatibilities

One of the major changes coming is that the library will handle asynchronous tasks (e.g. from futures, or joins) by dispatching them to a TBB-like task scheduler instead of simply spawning a new thread for each task. In most cases this means that the creation of continuation tasks is the preferred alternative to blocking, although there will still be provisions to support blocking tasks. The largest effect of this change will be the elimination of transparent futures from the core library, since they have the effect of causing arbitrary tasks to block, and have consistently been the most difficult feature of the library to implement portably anyway.

There will also be some less drastic, but incompatible, changes to the rest of the existing APIs. In particular, parallel algorithms will take grain sizes rather than a count of threads to spawn, and the actor API will be modified to match the current Rubinius API more closely.

Timeline

Especially since Omnibus is a spare time project for me at the moment, I can’t commit to a timetable for the new release, but at the moment I’m aiming to have the new release out in 2-3 months. Watch this space.

(Incidentally, feel free to contact me if you’re interested in funding some aspect of Omnibus development. I am committed to finishing Omnibus regardless, but obviously paid projects have to take precedence.)

What IronRuby Running Rails *REALLY* Means and Why Miguel de Icaza Deserves The Credit

Grats to Miguel ;-)

Sparkde is a an animation studio located in Rome that is switching to an open source production pipeline. As part of this effort, I am joining them to help rig and animate an upcoming project in blender. I’ve been busy rigging this past week and a half, and will be in the studio for the next 4-5 weeks for the animation. The project is for CNIPA (Center for infotech in Public Administration), and it will be made as I said with blender for 3D ( Fedora Linux as the operating system for the studio).

I’m thrilled to go work on the movie and meet the team, including Enrico Valenza (EnV) who worked on Elephants Dream and on Big Buck Bunny. I hope this starts open source filmmaking movement in Italy - after all, Rome, Open City sparked the Italian Neorealism movement ;)

Match of the century - 24 hours of footbal in my Alma Mater.

Today Department of Quantum and Physic Electronic (which I finished do not even remember when, but I started studying in MIPT 10 years ago) play with axes, or theirs another name: Department of General and Applied Physics.
After about half of the match we won with +18 goals (31:13).

This happens once per year and usually I tried to move to MIPT and watch part of the game like this year. Tomorrow will move there too of course to met with old friends and celebrate the win! Comments (0)

I've been continuing to make improvements to the API over the past few days and have just made a 2.3.1 release.

The main focus of this release has been a redesign of the header API which has been nagging at me for quite a while now. To fix it, I've done the following:

• Renamed GMimeHeader to GMimeHeaderList, GMimeHeader felt more like it should be a single header (name/value pair).


• Introduced a new GMimeHeader, altho it is internal only at the moment. I had originally planned on making it public (hence the rename of the old GMimeHeader struct).


• Introduced a GMimeHeaderIter which can be used to iterate forward and backward over the headers, allowing you to change header values (but not names). It also allows removal of headers which makes it possible to remove any header you want, whereas the old API would only let you remove a header by name (which was a problem if there was more than 1 by the same name).


• Got rid of g_mime_header_foreach() because that API sucked and has been replaced by the far more useful GMimeHeaderIter API.

The GMimeHeaderIter API looks like this:

GMimeHeaderIter *g_mime_header_iter_copy (GMimeHeaderIter *iter);
void g_mime_header_iter_free (GMimeHeaderIter *iter);

bool g_mime_header_iter_equal (GMimeHeaderIter *iter1, GMimeHeaderIter *iter2);

bool g_mime_header_iter_is_valid (GMimeHeaderIter *iter);

bool g_mime_header_iter_first (GMimeHeaderIter *iter);
bool g_mime_header_iter_last (GMimeHeaderIter *iter);

bool g_mime_header_iter_next (GMimeHeaderIter *iter);
bool g_mime_header_iter_prev (GMimeHeaderIter *iter);

gint64 g_mime_header_iter_get_offset (GMimeHeaderIter *iter);
const char *g_mime_header_iter_get_name (GMimeHeaderIter *iter);
bool g_mime_header_iter_set_value (GMimeHeaderIter *iter, const char *value);
const char *g_mime_header_iter_get_value (GMimeHeaderIter *iter);

/* if the iter is valid, removes the current header and advances 
 to the next - returns TRUE on success or FALSE otherwise */
bool g_mime_header_iter_remove (GMimeHeaderIter *iter);

Currently, the way to get a GMimeHeaderIter is to call g_mime_header_list_get_iter() which returns a newly allocated iter. I'm not sure if this is the best API or not tho... some other thoughts I've had are:

GMimeHeaderIter *g_mime_header_iter_new (void);
bool g_mime_header_list_get_iter (GMimeHeaderList *list, GMimeHeaderIter *iter);

The second function would initialize iter and return TRUE, or, if list was empty, it could return FALSE.

Another option would be to just have:

GMimeHeaderIter *g_mime_header_iter_new (GMimeHeaderList *list);

Then, if list is empty you'd just get back an invalidated iter. If, later, headers were added to list, then perhaps the iter could auto-magically become valid again. This would more-or-less work the same as the current code - except that the way to instantiate a GMimeHeaderIter is different.

To be honest, now that I've written these 2 ideas down, I think I prefer the first idea.

So... iterators. Since you can have multiple iterators for the same GMimeHeaderList, it is important to invalidate them on at least two occasions:

• when the GMimeHeaderList is destroyed


• when the header that an iter points to is removed; either by a call to g_mime_header_list_remove() or via a call to g_mime_header_iter_remove() on another iter instance.

You'll be pleased to note that only iters that reference a header that got removed are invalidated. This fact seems to be an argument in favor of my first idea above, as it would allow re-use of iters once they get invalidated.

really do not sell you only one shoe. Not even if they only have the one shoe of the pair. For example, when they accidentally sold a mismatching pair.

No sir, the shoe goes back to the factory. Even if it’s last year’s model, out of sale, can’t be ordered. That one shoe will sit there in the other factory next to the other bigger shoe, and both of them will die of loneliness. They will not allow me to save one of those two.

Sucks, after 4 hours of shopping.

Nice collection of incredible Japanese Sushi Art.