-
Notifications
You must be signed in to change notification settings - Fork 123
Conversation
documentation, code comments and tests are still WIP |
Seems like there are still memleaks (tests fail). It would be great if we can get this merged soon. |
1ca9614
to
8c49b1d
Compare
I fixed as much as I could, but there are still some problems left, which I wasn't able to solve:
|
e9019c3 may have fixed this |
@markus2330 I tried to change the CMake configuration some more, but I wasn't able to fix the problems with the FULL builds. I think someone else has to take a look at the problem |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good! Finally we approach the final API!
The linker problems seems to be fixed by @sanssecours already. The failing test seem to be caused by a missing tag, see review comments.
@@ -0,0 +1,58 @@ | |||
number:0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept for (highlevel) errors?
@Piankero maybe you can also help here.
f1b768d
to
1e48beb
Compare
Unfortunately no 😢. I think the latest commit fixed the linker problem of the full build on macOS, but also introduced multiple problems in the Linux build. I might work again on the PR later, but for now I have to go to work… |
@sanssecours Thanks for your help, I might be able to fix it myself now. I didn't think the order of the |
I finally made some progress with the linker error.... I first built the CMake target For both versions I ran 41,42c41,42
< T _elektraGetBooleanArrayElementByTag
< T _elektraGetBooleanByTag
---
> t _elektraGetBooleanArrayElementByTag
> t _elektraGetBooleanByTag
45,46c45,46
< T _elektraGetCharArrayElementByTag
< T _elektraGetCharByTag
---
> t _elektraGetCharArrayElementByTag
> t _elektraGetCharByTag
[...]
222,235c222,235
< D KDB_TYPE_BOOLEAN
< D KDB_TYPE_CHAR
< D KDB_TYPE_DOUBLE
< D KDB_TYPE_ENUM
< D KDB_TYPE_FLOAT
< D KDB_TYPE_LONG
< D KDB_TYPE_LONG_DOUBLE
< D KDB_TYPE_LONG_LONG
< D KDB_TYPE_OCTET
< D KDB_TYPE_SHORT
< D KDB_TYPE_STRING
< D KDB_TYPE_UNSIGNED_LONG
< D KDB_TYPE_UNSIGNED_LONG_LONG
< D KDB_TYPE_UNSIGNED_SHORT
---
> d KDB_TYPE_BOOLEAN
> d KDB_TYPE_CHAR
> d KDB_TYPE_DOUBLE
> d KDB_TYPE_ENUM
> d KDB_TYPE_FLOAT
> d KDB_TYPE_LONG
> d KDB_TYPE_LONG_DOUBLE
> d KDB_TYPE_LONG_LONG
> d KDB_TYPE_OCTET
> d KDB_TYPE_SHORT
> d KDB_TYPE_STRING
> d KDB_TYPE_UNSIGNED_LONG
> d KDB_TYPE_UNSIGNED_LONG_LONG
> d KDB_TYPE_UNSIGNED_SHORT It seems all of the symbols that result in undefined reference errors in variant B, are not exported from I am not sure what needs to change in order for theses symbols to be exported, but maybe @sanssecours or somebody else knows what to do with this information. |
26d7be2
to
84ceb62
Compare
I just pushed a few commits that should fix the linker problems. I am not sure that adding |
96eb88c
to
fe98762
Compare
fe98762
to
e4e1830
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the great work! Now everything seems to be ok, further changes in the next PR please!
return -1; | ||
} | ||
|
||
// use API |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add at least one getter or do not close elektra here.
No need to specify the base path `/sw/org/myapp/#0/current` anymore, as the high-level API keeps track of that for you. | ||
The API supports the CORBA types already used by some plugins. The high-level API should also be used in combination | ||
with a specification (`spec-mount`). When used this way, the API is designed to be error and crash free while reading values. | ||
Writing values, can of course still produces errors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
produce
* | ||
**************************************/ | ||
|
||
const char * elektraGetValue (Elektra * elektra, const char * name); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be const void *
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function calls keyString()
internally, so it has the same return type.
If the function should support binary data, I would propose this signature instead:
const void * elektraGetValue (Elektra * elektra, const char * name, size_t * size);
Passing NULL
to size would be allowed, that way one could use (const char *) elektraGetValue (elektra, "mykey", NULL);
to get the current behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@markus2330 any comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay.
I would recommend to not support binary data for now. So simply remove the *Value*
functions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But your proposal is also ok. (If you have already implemented, documented and tested it.)
* | ||
**************************************/ | ||
|
||
void elektraSetValue (Elektra * elektra, const char * name, const char * value, KDBType type, ElektraError ** error); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also void *
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as for elektraGetValue
, if we want to support binary data, we need to add a size parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above.
* @param DISABLE_UNDEF_PARAMETERS define to disable undefining of parameters after the macro. Use if parameters | ||
* are used within another supermacro. | ||
* @param CODE_ONLY optional, defaults to 0. Set to 1 to only generate to function body. This is useful, if you want to create a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generate the?
key-values, create a separate handle for each thread to avoid concurrency issues. | ||
|
||
#### Configuration | ||
Currently there is only one way to configure an `Elektra` instance: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Too early in document?
recommended you either use `atexit()` in you application or set a custom callback, to make sure you won't leak memory. | ||
|
||
The callback should interrupt the thread of execution in some way (e.g. by calling `exit()` or throwing an exception in C++). It should | ||
not return to the calling function. If it does, the behaviour is generally undefined, getter-functions will, however, most likely return 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It must not return to the calling function. (No further explanation needed.)
void elektraFatalErrorHandler (Elektra * elektra, ElektraErrorHandler fatalErrorHandler) | ||
``` | ||
This allows you to set the callback called by Elektra, when a fatal error occurs. Technically a fatal error could occur any time, but | ||
the most common use case for this callback is inside of functions that do not take a separate `ElektraError` argument. For example, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also consider to use the fatal error handler if the user passed 0 to the functions that take an ElektraError argument.
## Reading and writing values | ||
|
||
### Key names | ||
When using `KDB` and `KeySet` directly you would have to specify the whole key name to access a value. In the high-level API you do not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simply say how it is for the high-level API.
passing them only `"message"` as the name for the configuration value. | ||
|
||
### Read values from the KDB | ||
A typical application will want to read some configuration values at start. This should be made as easy as possible for the developer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be much earlier.
Basics
doc/news/_preparation_next_release.md which contains
*(my name)*
)Please always add something to the the release notes.
(first line should have
module: short statement
syntax)Checklist
Check relevant points but please do not remove entries.
For docu fixes, spell checking, and similar none of these points below
need to be checked.