Option in bpls to show the expression string for derived variables

[anagainaru]

Added the option --show-derived in bpls to print the expression string for derived variables.

$ ./bin/bpls expAdd.bp --show-derived -l
  float    derived/addU  2*{10, 3, 6} = 2.98842 / 28.085
    Derived variable with expression: x =sim1/Ux  y =sim1/Uy  z =sim1/Uz  x+y+z
  float    sim1/Ux       2*{10, 3, 6} = 0.000224775 / 9.94031
  float    sim1/Uy       2*{10, 3, 6} = 0.0201616 / 9.83318
  float    sim1/Uz       2*{10, 3, 6} = 0.0031 / 9.95085

[eisenhauer]

My only thought here was whether or not we should be returning std::string rather than char* if we're passing outside the Engine class. Inside BP5, or between engine and serializer, we've stuck more closely to C than C++ memory management (for good reason, given the nature of BP5 metadata management and the pain points in BP4 Dims handling). But this would be the first unmanaged pointer returned out of Engine.h. This particular use case isn't a worry at all, and maybe there wouldn't be any other uses, but it's maybe something to think about as we add interfaces.

[anagainaru]

@eisenhauer I like the idea of returning the value in a std::string more than an internal pointer. I'll change it tonight.

Small question: why are we testing the output of bpls -h?

[eisenhauer]

Small question: why are we testing the output of bpls -h?

Completeness? (Really, I have no idea...)

[pnorbert]

@eisenhauer I like the idea of returning the value in a std::string more than an internal pointer. I'll change it tonight.

Small question: why are we testing the output of bpls -h?

Can't remember anymore. I think was completeness but probably overkill.

[pnorbert]

Would you be able to indent the expression lines under the variable? I.e. 4 spaces for each line

[pnorbert]

My only thought here was whether or not we should be returning std::string rather than char* if we're passing outside the Engine class. Inside BP5, or between engine and serializer, we've stuck more closely to C than C++ memory management (for good reason, given the nature of BP5 metadata management and the pain points in BP4 Dims handling). But this would be the first unmanaged pointer returned out of Engine.h. This particular use case isn't a worry at all, and maybe there wouldn't be any other uses, but it's maybe something to think about as we add interfaces.

We could return a const char const * in the core, to avoid modifications but not necessary to have a copy at this point. If this goes up to the bindings, there a copy must be made to return to users.

[pnorbert]

but then again, if it was already returning a string, I would not complain about wasting memory by this copy

[eisenhauer]

@pnorbert That's a fair point... This is not bindings, so we're responsible for making sure things are handled safely internally. const or not, the string pointed to by the char* is valid as long as the variable is valid, which on the read size in BP5 is at least from BeginStep to EndStep in streaming mode (longer for RRA) and that's all we need for bpls. So, I'll retract my criticism...

[anagainaru]

Fair points, I will return a const char * and will add 4 spaces.

When the derived variable spans on multiple lines the spaces will only be applied to the first line. @lizdulac is working on having the compressed version of the expression encoded on the writer side so it looks nicer when we plot it.

[anagainaru]

Aaaah, I corrected the text shown in bpls -h but I forgot to update the useless test, sorry @eisenhauer you'll have to approve again

[eisenhauer]

No worries!