[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuradio-discuss
Subject:    Re: [Discuss-gnuradio] pure python block?
From:       "Matteo Campanella" <matteo () matcam ! net>
Date:       2006-03-24 8:01:33
Message-ID: 16174.212.239.26.199.1143187293.squirrel () thenetfather ! dyndns ! org
[Download RAW message or body]

I guess that, being the array approach the one used in c++ blocks, that
would be the best to use in python as well. So I would definitely work
with input and output arrays.

ciao
Matteo

> On Thu, Mar 23, 2006 at 09:31:01PM +0100, Matteo Campanella wrote:
>> Suppose I am willing to test some ideas, and that I do not care about
>> latency or speed - I just want to be able to drop some quick lines of
>> code to see if the idea is a good one or not... it would be nice to
>> write a function in python and put it in the graph to see how it
>> performs in the chain, using no real time sources or sinks (eg files)
>>
>> is it possible? how?
>>
>> Matteo
>
> This is not currently possible.
>
> But then it's not impossible either ;)
>
> We could either leverage the "ufunc" framework that was briefly
> mentioned in the past week, or create a new C++ block derived from
> gr_block, gr_sync_block, etc, that accepts a python closure as a
> constructor arg.  The block's work method would then recursively
> invoke the interpreter to evaluate the python code.
>
> What kind of args do think the python code would accept?
> Is it sample at a time, or would you be passing, say NumPy arrays for
> the input and output?
>
> Eric
>
>





[prev in list] [next in list] [prev in thread] [next in thread]