For this commit only the first element from the {N, M} list is read
and assigned.
This is better than not reading this value at all.
the commit also updates test_files and test data files with correct
values for the effective_freq_slot attribute
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I1e60fe833ca1092b40de27c8cbfb13083810414e
This is a feature that was requested by Esther due to their workflows at
Orange. There's also a standalone converter avaialable as
`gnpy-convert-xls`.
Change-Id: I1a483d168db0744fbf115e05e679e13b57d79398
There's no need to limit this to just the transmission_main_example, so
let's unify this handling.
Change-Id: I585f407c7f80da12fd33baf7261c35c736d78df2
I think this is a little bit cleaner that duplicating the info about the
default for some of these options.
Change-Id: If218a26ede3e71628f4839b4e505c4f4aa217699
Let's use the --option format instead of positional arguments; that way
it's more obvious that it can be omitted. Note that this constitutes a
change of behavior for the path_requests_run example.
Change-Id: Ic6653cf419e1a8573c3585190a88fc51500f549d
Try to indicate whether an option takes just JSON, or a JSON or an XLS
file. Also add some extra descriptions.
Change-Id: Ifb81d46f6ac659da79b08201a414822e9c318a1e
We talked about this earlier today on a call, and agreed with Esther and
Alessio that this is probably a relict from the past. The file does not
appear to contain much useful information, anyway, so let's try to
remove it and wait if someone complains.
Change-Id: I215eeb37498b28b15ece2300f4bbdd184ac52f4a
This is something which got added in bc9eee32, but it never got
finalized to have a user-visible effect. To the best of my knowledge, it
only created a file which was never used.
I removed code which created that file in 0d542f22, so let's clean up
the rest.
I think this should also restore functionality of running convert.py in
a standalone mode. Looking at the ArgParser, the invocation never
considered the names_matching parameter.
Change-Id: Id0f4aa1db2d22233f74fb273176168a16ace4072
I would like to create a package for distribution to PIP, and this seems
like the path of least resistance.
This is, apparently, the way for shippign arbitrary data with Python
[1]. I've at least tried to make it user-firendly via adding a simple
utility which just prints out whatever that data path is.
[1] https://python-packaging.readthedocs.io/en/latest/non-code-files.html
Change-Id: I220ecad84b1d57d01e3f98f15befc700bd97c0b8
It's a bad habit to write files into the source code repository. It will
also become impossible if gnpy is installed into a systemwide, possible
read-only location.
The old behavior can be reactivated by using an extra option to tell
GNPy where to put the generated file.
Change-Id: I9ad43890ca5886f516885de5938a4778870a06c5
The main reason for doing this is becasue of the next commit which
re-adds testing of the generated wrappers.
Change-Id: I7137c6cf7a5b414fc708a15b125eaf88e996366c
...which will be done in the next commit. One has to be careful with
sys.argv here because it uses different indexing than when passing args
explicitly.
Change-Id: I53833a5513abae0abd57065a49c0f357890e0820
This converts our first free-standing example entry point into a
function. It will become very handy when we start distributing these
entry points via setuptools.
Change-Id: Icd2e4658337f93cd0b0301978e2dc640de0cc72b
This also moves SimParams handling to a single place. As a result,
path_requests_run has just become Raman-aware (to the minimal possible
extent, OK).
Change-Id: I4e31af5c67335963ddab567d304f48a899cd569e
