|
| From: | Sreejith RK Nair |
| Subject: | Re: How to run the program without showing the block diagram in windows 10? |
| Date: | Thu, 21 Dec 2023 12:33:23 +0530 |
Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-request@gnu.org
You can reach the person managing the list at
discuss-gnuradio-owner@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Vector Sink/Source Type Support (David Reuss)
2. Survey regarding Open Source Licensing of GR 4.0 (Josh Morman)
3. Re: Vector Sink/Source Type Support (Jeff Long)
4. How to run the program without showing the block diagram in
windows 10? (Sreejith RK Nair)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Dec 2023 09:44:40 -0800
From: David Reuss <david.a.reuss@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: Vector Sink/Source Type Support
Message-ID:
<CALSEBRttnmypEjUEALu_qG4u9iBmnAVxHhFjK4qDak2aWmh5Qg@mail.gmail.com" target="_blank">CALSEBRttnmypEjUEALu_qG4u9iBmnAVxHhFjK4qDak2aWmh5Qg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
We have a few gnuradio blocks in an OOT module that require double
precision inputs and outputs. To help us test these blocks we created our
own vector sink/source blocks that are direct copies of the gnuradio vector
sink/source but with added support for doubles.
This works well, but I was wondering if there is a reason that vector
sink/source don't support double, std::int64_t and gr_complexd types, or
whether this is something that might be useful for me to create a pull
request for? These blocks are already templated (source:
https://github.com/gnuradio/gnuradio/blob/main/gr-blocks/lib/vector_sink_impl.cc),
so it should be easy enough to add support for more types.
Thank you,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231219/c08f7291/attachment.htm>
------------------------------
Message: 2
Date: Tue, 19 Dec 2023 12:50:30 -0600
From: Josh Morman <jmorman@gnuradio.org>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: Survey regarding Open Source Licensing of GR 4.0
Message-ID:
<CA+JSbFpxV12p4m+yAUcuky4dhy7EM0EYQSFV83FGeqDn8WDiEA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
A quick follow up on one topic that was presented in the Q4 Project Update
video:
Tl;dr - the core of the code being merged as “GR 4.0” is LGPL. We want
your opinion on how this will impact you and if further action is needed
for licensing considerations. Please submit your feedback here:
https://forms.gle/u7PjYGhzfrshkngd9
Look forward to your responses.
Thanks,
Josh
—--
As has been widely discussed, the upcoming major version of GNU Radio, GR
4.0, is based on a new codebase developed by the team at GSI-FAIR and is
being migrated into the GNU Radio GitHub Repository. Apart from the vast
and promising changes of this major revision, the code being migrated is
currently licensed as LGPL, which means that there are different
ramifications than the entirety of GNU Radio 3.x being GPLv3. The plan is
that blocks ported over with IP from GR3 (apart from very trivial blocks)
will remain in modules that are licensed as GPLv3. So for the vast
majority of GNU Radio use cases, the situation for derived works of
flowgraphs using signal processing blocks will not change.
But with the core (base classes and schedulers) being LGPL, this allows
derived works to link with GR, but have a different license. Source
changes to the core GR codebase would still need to be provided to those
receiving any derived works. This could enable the following situations:
1.
A GNU Radio user could create an OOT not bound by GPLv3 - so long as the
OOT does not link against any of the GR GPL code (e.g. gr-filter or
gr-digital)
1.
The OOT could not be distributed in binary form if it is built
against GPLv3 modules without the artifact being licensed as GPLv3
2.
Realistically, this would limit non-GPL usage of GR4 OOTs in
flowgraphs to custom blocks that have been licensed accordingly
2.
An application such as a graphical frontend linking to GR4 under the
hood could be created under a non-GPL license
Note: The above is not legal guidance to any users of this codebase, but a
statement of a licensing change compared to previous GNU Radio revisions.
Each user should consult counsel where needed to understand their own usage
Links:
https://github.com/fair-acc/graph-prototype
https://events.gnuradio.org/event/21/contributions/390/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231219/ebe5d92c/attachment.htm>
------------------------------
Message: 3
Date: Tue, 19 Dec 2023 15:34:44 -0500
From: Jeff Long <willcode4@gmail.com>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: Re: Vector Sink/Source Type Support
Message-ID:
<CAC5f9jZdKtUkVSToAE23MWAxVBJGK8RrXoP_YTai63M-b=dQSw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We don't seem to have any blocks in-tree that support either of these
types, so it wouldn't be of general use and would be hard to test with CI.
My opinion is that this is something to look into for GR4.0, unless there
is some demand for more precision in 3.X.
On Tue, Dec 19, 2023 at 2:57 PM David Reuss <david.a.reuss@gmail.com> wrote:
> Hello,
>
> We have a few gnuradio blocks in an OOT module that require double
> precision inputs and outputs. To help us test these blocks we created our
> own vector sink/source blocks that are direct copies of the gnuradio vector
> sink/source but with added support for doubles.
>
> This works well, but I was wondering if there is a reason that vector
> sink/source don't support double, std::int64_t and gr_complexd types, or
> whether this is something that might be useful for me to create a pull
> request for? These blocks are already templated (source:
> https://github.com/gnuradio/gnuradio/blob/main/gr-blocks/lib/vector_sink_impl.cc),
> so it should be easy enough to add support for more types.
>
> Thank you,
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231219/cbad1d5f/attachment.htm>
------------------------------
Message: 4
Date: Wed, 20 Dec 2023 20:23:05 +0530
From: Sreejith RK Nair <sreejithrknair143@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: How to run the program without showing the block diagram in
windows 10?
Message-ID:
<CAKfesxd-VJVmx01_dBpZYFHunXPPOvqaWfvQDSf7zZ5tkeBQhQ@mail.gmail.com" target="_blank">CAKfesxd-VJVmx01_dBpZYFHunXPPOvqaWfvQDSf7zZ5tkeBQhQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have done a project for my internship using gnu radio. I want to run my
project on another pc(windows 10) and show the output but not the block
diagram .My invigilator should only see the output. Can anyone suggest a
way to do this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20231220/9ae9622d/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 254, Issue 16
*************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |