dikini.net

I was just browsing through make, and tumbled upon this really cool idea - motorway wind turbines. It can reduce the carbon footprint of the automobile. And some electricity. And less auxiliary weather meddling. The wind created by by the stream of cars on the motorway and it's effects on the local weather and the one in China are still not studied, regardless of the advances of chaos theory and other intellectual beauties.

Driving at 90mph - get bladed? Can be really good for "drive safe" campaigners.

update:hmm, there a discussion on slashdot about the same core idea, thanks dogsbody, my festive friend.

Macros have (let's say) two main responsibilities - adding syntactic sugar and abstraction of common patterns. The syntactic sugar bit is something which probably should happen at compile time, at least in a weakly typed language like php. So I'll skip them. The abstraction of computation, well this is wat codified design patterns are. This is what function, classes and the rest of the things we read about and use usually do. To abstract a function in php there are at least two different strategies, probably more, but these two are effective in diametrically different situations. The first one is a combination of the ideas of generic functions (higher order functions) and partial evaluation. In code it can look something like:

The Drupal way in programming is 60% about hooks 10% about nodeapi and the rest is ingenuity. That's allright, but one fact has always troubled me. And that is - how much effort is spent on discovering which module implements the hook I need. Far enough, the old caching/memoizing trick does the job to ensure that the cpu time is not expensive. Yeah, but still it's outside simplicity might be, just might be implemented in a more elegant fashion.

Drupal hooks implement a nearly Aspect Oriented API. The cross-cut is the point where the hook is invoked. aspect(cross-cut) === hook. The different aspects are declared as moduleName_hook. The disatvantage is that these are indiscriminate. Hooks are always fired. Pros - simplicty, cons - wasted cpu cycles.

I wonder. Is it possible to achieve a similarly simple syntax, but with the added advantage of not firing unnessesary hook calls.

minor imporvements - Rev 4 - vlado (2 file(s) modified)minor imporvements
[relations svn]

As it says on the box minor improvements. Actually the changes are a mockup of some of my ideas for better/proper database abstraction, and a variation on some of Adrian's model thoughts.

  sqlgen_join(
    // functional form
    sqlgen_table('n'=>'node'),
    //array(ish) form
    array('r'=>'node_revisions'),
    // the join constrains, defines the new relation
    sqlgen_constraints(
      array('node_revisions'=>'may be null'), 
      sqlgen_and(
        sqlgen_eq( arg('node','nid'),arg('node_revisions','nid') ),
        sqlgen_eq( arg('node'=>'vid'),arg('node_revisions','vid'))
      )
    ),
    //result filtering
    sqlgen_cond( sqlgen_eq(arg('node','nid'),$nid)) 
  );

This is the functional form. It provides a good abstraction. It is independant of the underlying structure. In my opinion it has better code readability. Can be thoroughly unit tested.

 $view=array(
    '*'=>'node_revisions',
    '*'=>'node',
    'name'=>'user',
    '#cond'=>array(
      '#op'=>'AND',
      array(
          '#op'=>'eq',
          array('node','nid'),
          array('node_revisions','nid')),
      array('#op'=>'eq',
          array('node','vid'),
          array('node_revisions','vid')),
      array('#op'=>'eq',
          array('node','nid'),
          '#param'=>'node_view_id')
      )
    );

The array form, can easily become a mess. It is faster using arrays, rather than using functions to generate them, but could be daunting.

Both cases provide a close native equivalent to s-forms in php. Although you have eval(), the native php syntax is not as easily manipulateable as in lisp.

Still both forms have a significant advantage over 'embeded SQL'. We can get native php expression of the concepts in the db. We can optimise the queries, based on both data knowledge and database backends. Database independence is obvious. No rewrite_sql hacks. So things like coding a new/custom permission system becomes a breeze. Content type mashups, view/form remixing becomes possible.

As I've said this is just a mockup.

updated the comments in the functional form for readability

I'm scratching my brains at the moment to see how could I do live jamming with my noise/music.

I have a few requirements:

• code the music or the different loops live
• change the loops live
• automatic variations
• responsive control
• no crashes
• external control via midi and/or osc

This leads to a few more questions, I'll add more as they come:

• what should be the underlying language
• can I use midi controllers to change the language constructs?
• how can I change both control and the audio?