• Mr Rossum, tear down that GIL - request of Juergen Brendel
• It isn't Easy to Remove the GIL by Guido van Rossum

I was pointed to a good writeup upon Hardware/Software overview of tendencies in multi-core computing. It sheds some light upon progress made in the area touched by Guido in different languages/systems/platforms.

If we’re going to live in a world where CPUs are cheap and parallelism is the norm, then we need to think in those terms. If we need Perl/Python/Ruby/etc. programs to interact with parallelized libraries written in C/C++/Fortran, where’s the harm in spawning another process? Let the two halves of the program communicate over some IPC mechanism (sockets, or perhaps HTTP + REST). That model is well known, well tested, well-understood, widely deployed and has been shipping for decades. Plus, it is at least as language-agnostic as Parrot hopes to become. (+2 points if the solution uses JSON instead of XML.)

Fourth, there’s Patrick Logan, who rightly points out the issue simply isn’t about a multi-core future, but also a multi-node future. Some applications will run in parallel on a single machine, others will run across multiple nodes on a network, and still others will be a hybrid of both approaches. Running programs across a network of nodes is done today, with tools like MapReduce, Hadoop and their kin.

If you have a grid of dual-core machines today, and need to plan out how to best use the network of 64-core machines you will have a decade from now, here’s a very simple migration plan for you: run 32x as many processes on each node!

With that said, here is my recipe for taming the multi-core dust bunny:

• Determine what kind of parallelism makes sense for you: none, flyweight, fine-grained or coarse grained.
• Avoid troublesome low-level concurrency primitives wherever possible.
• Use tools like GHC’s Nested Data Parallelism for flyweight concurrency (one program, lots of data, spread out over multiple CPUs on a single machine).
• Use tools like GHC’s Software Transactional Memory for lightweight concurrency (many interoperating processes managing shared data on a single machine).
• Use tools like MapReduce and friends for heavyweight concurrency (work spread out across multiple cooperating processes, running on one or many machines).

.term:opener-init{
  evt-init-elementSelector: '.details';
}

.term:opener-open{
  action-client: executeCommand;
  executeCommand-commandName: replaceInnerHTML;
  executeCommand-commandSelector: '#status';
  executeCommand-html: 'expanded';
}

.term:opener-close{
  action-client: executeCommand;
  executeCommand-commandName: replaceInnerHTML;
  executeCommand-commandSelector: '#status';
  executeCommand-html: 'collapsed';
}

and HTML for the samle is:

<hr />
<div id="status">Current status</div>
<hr />

<div class="term">
  History
  <div class="details">
    Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum
    iaculis eros eu purus. Integer accumsan leo id lorem viverra vulputate.
    Donec feugiat nunc molestie massa nonummy pulvinar. Proin porta pede
    sit amet lectus. Duis leo urna, tempor non, condimentum condimentum,
    commodo non, libero. Integer feugiat, pede at.
  </div>
</div>

The resulting behaviour on page is:

If you do not see a flash movie above, see original post.

The important thing is that on open and close you can have client-side or server-side actions. You can disable default expand/collapse behaviour, with preventDefault parameter:

.term:opener-open{
  preventDefault: true;
}

dl:opener-init{
  evt-init-elementSelector: '> dd';
  evt-init-controllerPlacementSelector: '> dt';
}

if the above sample is applied to following HTML code:

<dl>
  <dt>History</dt>
  <dd>
    Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum
    iaculis eros eu purus. Integer accumsan leo id lorem viverra vulputate.
    Donec feugiat nunc molestie massa nonummy pulvinar. Proin porta pede
    sit amet lectus. Duis leo urna, tempor non, condimentum condimentum,
    commodo non, libero. Integer feugiat, pede at.
  </dd>
</dl>

And the result is:

If you do not see a flash movie above, see original post.

The whole definition list has opener assigned. Controller (clickable handle) is inserted into <dt> element, not in root of list (that can confuse some browsers). This is why I avoided dl/dt/dd example in my introduction post.

opener-selector:opener-init {
   evt-init-elementSelector: element-selector;
}

All elements that matches opener-selector will get controller that will offer expand/collapse functionality with mouse click.

Real-life example is:

.term:opener-init {
   evt-init-elementSelector: '.details';
}

and having HTML code:

<div class="term">
  History
  <div class="details">
    Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum
    iaculis eros eu purus. Integer accumsan leo id lorem viverra vulputate.
    Donec feugiat nunc molestie massa nonummy pulvinar. Proin porta pede
    sit amet lectus. Duis leo urna, tempor non, condimentum condimentum,
    commodo non, libero. Integer feugiat, pede at.
  </div>
</div>

will produce into something like:

If you do not see a flash movie above, see original post.

Then we had proper <ul><li> nested structure that was huge step forward.

Then we had icons eliminated, that is another big step (not perfect yet, complex hover/active styles still makes life of designer hard).

And now we have Plone-3.0 knocking our doors. The most prominent feature everybody will be talking about is Ajax in Plone. Some will be mentioning KSS that made thing happen for complex CMS.

We had some efforts to address each of the items above, but none of them has matured enough to find its way into Plone code-base. And now we are going to address Ajax aspect of navigation tree.