Fwd: fft_sink_c.win._points

GNU Radio
1

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

2

On Wed, 2008-11-12 at 17:23 -1000, Christian Kendi wrote:

What happend?

This may be a side effect of how we implemented the GL/non-GL import
into a common Python namespace. I’ll take a look at it (or Josh, feel
free).

-Johnathan

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  • -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    • -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1

Hi,

any update on this issue ?

Chris.

El Nov 12, 2008, a las 10:35 PM, Johnathan C.
escribió:

    • -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v1.4.7 (Darwin)

iD8DBQFJIut3p+9ff145KVIRAh14AJkBbtC/KRJJH+D726gci19SuNZljgCfWu9O
v5oUTTNlGIkLv8V/zT1COSA=
=BNV6

    • -----END PGP SIGNATURE-----
  • -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)

iD8DBQFJIu0Fp+9ff145KVIRAr7MAJ0eJKKFbZnRRJo/sKvElu3Py5hTmgCeLTlQ
Hoabu/78tnetnDstamIiQS8=
=mFIC

  • -----END PGP SIGNATURE-----
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)

iD8DBQFJIvdMp+9ff145KVIRAlI1AJ4lES6UaZb4NusmHvc2WXQCXoddvACfQjAr
9cHjllFxu0cuwhCqP1Ezzw4=
=XaCO
-----END PGP SIGNATURE-----

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  • -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

Hi,

any update on this issue ?

Chris.

El Nov 12, 2008, a las 10:35 PM, Johnathan C.
escribió:

  • -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)

iD8DBQFJIut3p+9ff145KVIRAh14AJkBbtC/KRJJH+D726gci19SuNZljgCfWu9O
v5oUTTNlGIkLv8V/zT1COSA=
=BNV6

  • -----END PGP SIGNATURE-----
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)

iD8DBQFJIu0Fp+9ff145KVIRAr7MAJ0eJKKFbZnRRJo/sKvElu3Py5hTmgCeLTlQ
Hoabu/78tnetnDstamIiQS8=
=mFIC
-----END PGP SIGNATURE-----

5

On Tue, 2008-11-18 at 11:27 -0500, Christian Kendi wrote:

This may be a side effect of how we implemented the GL/non-GL import
into a common Python namespace.

My initial guess was wrong.

The _points variable was never intended to be used externally, and when
the GL version of the fftsink was created, it was replaced by ‘samples’.

It should be the case (though I haven’t tested it) that if you are using
the non-GL sink, you can still access fft_sink_c.win._points, otherwise,
you need to use fft_sink_c.win.samples. However, no promises that this
will stay the same in the future.

A solution to this would be to add a getter function with a well-defined
name that we’d promise to maintain, but it is somewhat questionable the
usefulness of this value anyway.

-Johnathan