[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Announcing new GRAS Feature - Block Factory

From: Josh Blum
Subject: [Discuss-gnuradio] Announcing new GRAS Feature - Block Factory
Date: Mon, 05 Aug 2013 07:00:36 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

Hello list,

As a follow-up to my last announcement "Advanced scheduler pw0ns SWIG
for you" (which I was quite excited about), I have since tried to
formalize the feature-set and document it:

What I am collectively calling the block factory is really:
* A CMake utility to build and install runtime loadable modules
* A system to load runtime modules from the specified paths
* An API to register block constructors into the factory
* An API to create blocks from the factory
* An API to register block methods into the framework
* An API to call into registered methods

That may sound complicated, but actually, all of the complexity is
handled in the guts of the framework. So in contrast, this is probably
the simplest it has even been for a user to create custom blocks. The
CMake projects that build and install a user's blocks are brief and to
the point -- no swig, a minimal number of files. Builds are quick and
snappy and its easy to debug build errors. The registration APIs are
very clean and non-invasive -- as are calling into the registered
factories and class methods. Here is the run-down:

The code guide has example snippets on how to painlessly register block
constructors and methods, and how to call into them at runtime:

This wiki page lists the pros and the cons of using this feature:

The module guide hosts a usable example CMake build project,
and explains in more detail how GRAS finds modules at runtime:

I switched every block in GrExtras over to this new system without
exception. Every C++ and CMake file stands as a useful example:

Something neat you can do; Here is an example of a block where the same
code takes on a different API depending upon which factory path is used:

I moved the Clang part of the GrExtras Clang Block into GRAS. The new
jit_factory() call provides the backend for the Clang Block. You can
literally just dump C++ source into this call, from Python, at runtime,
and find your blocks in the factory.

Using this set of features doesn't preclude the normal way of making
libraries or python modules. Blocks from a SWIG'd library work just fine
with blocks from a factory. And for that matter, block factories don't
do everything. If a user needs to have a set of utilities to go along
with the blocks, nothing is wrong with building your typical dlls along
with the modules for the block factory. Etc, etc...

I'm very proud of this work. And I think that this feature-set has the
potential to improve a lot of user's experiences. I hope y'all like it too!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]