pothosware/pothos-util

Common utility modules used in other Pothos modules

pothos-util's Issues

use EvalEnvironment as an sptr only

passing by reference is currently or will be causing an ownership deletion badness issue. Make it an sptr so block eval can own a reference.

eval expression -- remove object serialize/deserialize

The returned object from the compile and load is sitting on module memory, the object has to be deleted before the module can be unloaded. Problem: we want the object, we dont want the module. Lazy solution: serialize and de-serialize into a new object of the same contents. Problems: slow, unnecessary, serialization not supported for all types.

• either manage the lifetime of the loaded module
• or figure out a way for a returned object to not sit on module memory

serialization for vector of numeric types

builtin expression compiler

Current state

The expressions are used in the PothosGUI parameters and in the JSON topology markup. Currently, simple expressions are parsed like numbers and strings, and complicated expressions are compiled and the resulting Object is extracted from the compiled library.

Although it doesnt sound like it, this was the lazy/quick solution. But it has drawbacks:

• its slow to compile simple expressions in the system's compiler (gcc/msvc/clang)
• dont want to require a compiler to be installed, like for binary windows installers

New compiler

Basically, we need to split expressions into tokens, and figure out which tokens are functions, constants, and variables.

• Compiler input: list of variable names and expression or each variable
• Compiler input: the expression to evaluate
• Compiler output: a Pothos::Object() holding the result

Supported expressions

• numbers: -1, 3.4, 1e8, 5lu
• strings: "hello world"
• bools: true, false
• math ops: +, -, *, /, * * (exp op)
• bit ops: &, |, ^
• boolean ops: and, or, xor, &&, ||, ^^
• parens: (1 + 2)
• using a variable: 1.0 * foo
• builtin variables: j, PI, other math constants
• builtin functions: log, log2, pow, other std math stuff

Containers of expressions

We support jSON formatting for containers when possible

• lists of expressions: [expr1, expr2, ...]
• maps of expressions: {expr1:expr2, expr3:expr4}

The result will be a Pothos::Object containing a Pothos::ProxyVector, Pothos::ProxyMap (respectively). The system already knows how to deal with these data types and convert them.

Example operation

• start with: 1 + 2
• extract tokens: 1, +, 2
• transform: function("add", obj(1), obj(2))
  • 1 and 2 are recognized as type "int"
• evaluate: the add function should inspect the types and basically call something like:
  • out = Pothos::Object(o1.convert() + o2.convert());
• every thing builds upon this

eval expression - support C list syntax {4, 2, 8}

this should return a std::vector of an numeric type

JSON stringify unicode escape issue

This may or may not be a POCO bug, or perhaps a misunderstanding of how to deal properly with utf8 unicode escaping. Currently working around it: https://github.com/pothosware/gnuradio/blob/pothos_support/GrPothosUtil/GrPothosUtil.py#L657

The bug happens when a unicode escape is converted from string into JSON, and then back into a string with the stringify() call. Used here: https://github.com/pothosware/pothos-util/blob/master/DocUtils.cpp

This bug is to investigate the root cause

compiler wrappers: scoped temporary file object for autodeletion