I've started using CocoaLumberjack and was interested in using their custom log levels feature. They have a handy config available at https://github.com/CocoaLumberjack/CocoaLumberjack/wiki/CustomLogLevels to get you started. I don't know exactly what I want right now, so I left it as is.
Next I set my debug level in my code using this...
static const int ddLogLevel = LOG_LEVEL_DEBUG;
However with this set up it appears only messages of GREATER severity than LOG_LEVEL_DEBUG get presented. Meaning calls to DDLogInfo() and above show up, but not DDLogDebug(). This is also true as I slide upwards. So...
static const int ddLogLevel = LOG_LEVEL_INFO;
...ignores DDLogInfo() and DDLogDebug(), but shows for DDLogNotice() and higher. Surely the expected behavior is to be inclusive of that warning level.
Here's the code deep inside CocoaLumberjack that makes the decision...
for (DDLoggerNode *loggerNode in loggers) {
// skip the loggers that shouldn't write this message based on the logLevel
if (!(logMessage->logFlag & loggerNode.logLevel)) {
continue;
}
dispatch_group_async(loggingGroup, loggerNode->loggerQueue, ^{ #autoreleasepool {
[loggerNode->logger logMessage:logMessage];
}});
}
In my first example, my log level is 111111 (63) and message flag (using DDLogDebug()) is 100000 (32). 63 & 32 is YES, so this fails (with the NOT). So I would think the message would get logged. Moving the log method up to DDLogInfo() which has a message flag of 010000 (16). This is still YES and therefore fails with the NOT, so we get logged. But I see it in this case. Anyone have any experience with this?
I think I've worked it out. In CocoaLumberjack itself, in DDLog.h, the log level flags are defined like so:
#define LOG_FLAG_ERROR (1 << 0) // 0...00001
#define LOG_FLAG_WARN (1 << 1) // 0...00010
#define LOG_FLAG_INFO (1 << 2) // 0...00100
#define LOG_FLAG_DEBUG (1 << 3) // 0...01000
#define LOG_FLAG_VERBOSE (1 << 4) // 0...10000
However, the CustomLogLevels MyLog.h file defines them like so:
#define LOG_FLAG_FATAL (1 << 0) // 0...000001
#define LOG_FLAG_ERROR (1 << 1) // 0...000010
#define LOG_FLAG_WARN (1 << 2) // 0...000100
#define LOG_FLAG_NOTICE (1 << 3) // 0...001000
#define LOG_FLAG_INFO (1 << 4) // 0...010000
#define LOG_FLAG_DEBUG (1 << 5) // 0...100000
Note that it adds an extra FATAL flag, which has the effect of shifting all of the other flags down a place. This is the cause of the issue you were seeing.
if you have custom levels higher than the inbuilt, try initialising with:
[DDLog addLogger: [DDASLLogger sharedInstance] withLogLevel: LOG_LEVEL_CUSTOM];
[DDLog addLogger: [DDTTYLogger sharedInstance] withLogLevel: LOG_LEVEL_CUSTOM];
where LOG_LEVEL_CUSTOM is defined in your MyLog.h as:
#define LOG_LEVEL_CUSTOM (LOG_FLAG_ERROR | LOG_FLAG_WARN | LOG_FLAG_INFO | LOG_FLAG_CUSTOM)
Related
I want to write a configuration file with qmake that #defines a few values. But I cannot simply create variables that contain the hash or pound character (#). Nonworking example:
lines = "/* Autogenerated: do not edit */"
if(foo): lines += "#define MYLIB_WITH_FOO 1"
else: lines += "#define MYLIB_WITH_FOO 0"
write_file(config.h, lines)
The hash starts a comment (inside the string!), so this won't work. How to generate the proper #defines for write_file under qmake?
There's a predefined variable called LITERAL_HASH specially created to deal with this problem.
If this name seems too long you can create one of your own:
H = $$LITERAL_HASH
lines = "/* Autogenerated: do not edit */"
if(foo): lines += "$${H}define MYLIB_WITH_FOO 1"
else: lines += "$${H}define MYLIB_WITH_FOO 0"
write_file(config.h, lines)
The trick is to use $$system() to create the hash character. This example works for me under Windows and Linux:
pound = $$system(printf $$system_quote(\43))
if(foo): lines += "$${pound}define MYLIB_WITH_FOO 1"
else: lines += "$${pound}define MYLIB_WITH_FOO 0"
It is usual on a C or C++ application sources to include a "config.h" header, that is generated by the buildsystem from a template (for instance "config.h.in"). This is available using autotools, and also CMake - see: configure_file(). But what about Qmake?
Here is an alternative using QMAKE_SUBSTITUTES. Another reference.
test.pro
TEMPLATE = app
QT = core
CONFIG += cmdline c++11
VERSION = 1.2.3
FOO = 1
QMAKE_SUBSTITUTES = config.h.in
SOURCES += main.cpp
DISTFILES += config.h.in
config.h.in
/* Autogenerated: do not edit */
#ifndef CONFIG_H
#define CONFIG_H
#define MYLIB_VERSION '"$$VERSION"'
#define MYLIB_BANNER '"Project version $$VERSION created with Qt $$QT_VERSION"'
#define MYLIB_WITH_FOO $$FOO
#endif // CONFIG_H
main.cpp
#include <QCoreApplication>
#include <QDebug>
#include "config.h"
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
qDebug() << MYLIB_BANNER;
if (MYLIB_WITH_FOO) {
qDebug() << "Foo included!";
}
return 0;
}
Output:
Project version 1.2.3 created with Qt 5.12.5
Foo included!
My main goal is trying to get macros (or even just the text) before function parameters. For example:
void Foo(_In_ void* p, _Out_ int* x, _Out_cap_(2) int* y);
I need to gracefully handle things like macros that declare parameters (by ignoring them).
#define Example _In_ int x
void Foo(Example);
I've looked at Preprocessor record objects and used Lexer::getSourceText to get the macro names In, Out, etc, but I don't see a clean way to map them back to the function parameters.
My current solution is to record all the macro expansions in the file and then compare their SourceLocation to the ParamVarDecl SourceLocation. This mostly works except I don't know how to skip over things after the parameter.
void Foo(_In_ void* p _Other_, _In_ int y);
Getting the SourceLocation of the comma would work, but I can't find that anywhere.
The title of the questions asks for libclang, but as you use Lexer::getSourceText I assume that it's libTooling. The rest of my answer is viable only in terms of libTooling.
Solution 1
Lexer works on the level of tokens. Comma is also a token, so you can take the end location of a parameter and fetch the next token using Lexer::findNextToken.
Here is a ParmVarDecl (for function parameters) and CallExpr (for function arguments) visit functions that show how to use it:
template <class T> void printNextTokenLocation(T *Node) {
auto NodeEndLocation = Node->getSourceRange().getEnd();
auto &SM = Context->getSourceManager();
auto &LO = Context->getLangOpts();
auto NextToken = Lexer::findNextToken(NodeEndLocation, SM, LO);
if (!NextToken) {
return;
}
auto NextTokenLocation = NextToken->getLocation();
llvm::errs() << NextTokenLocation.printToString(SM) << "\n";
}
bool VisitParmVarDecl(ParmVarDecl *Param) {
printNextTokenLocation(Param);
return true;
}
bool VisitCallExpr(CallExpr *Call) {
for (auto *Arg : Call->arguments()) {
printNextTokenLocation(Arg);
}
return true;
}
For the following code snippet:
#define FOO(x) int x
#define BAR float d
#define MINUS -
#define BLANK
void foo(int a, double b ,
FOO(c) , BAR) {}
int main() {
foo( 42 ,
36.6 , MINUS 10 , BLANK 0.0 );
return 0;
}
it produces the following output (six locations for commas and two for parentheses):
test.cpp:6:15
test.cpp:6:30
test.cpp:7:19
test.cpp:7:24
test.cpp:10:17
test.cpp:11:12
test.cpp:11:28
test.cpp:11:43
This is quite a low-level and error-prone approach though. However, you can change the way you solve the original problem.
Solution 2
Clang stores information about expanded macros in its source locations. You can find related methods in SourceManager (for example, isMacroArgExpansion or isMacroBodyExpansion). As the result, you can visit ParmVarDecl nodes and check their locations for macro expansions.
I would strongly advice moving in the second direction.
I hope this information will be helpful. Happy hacking with Clang!
UPD speaking of attributes, unfortunately, you won't have a lot of choices. Clang does ignore any unknown attribute and this behaviour is not tweakable. If you don't want to patch Clang itself and add your attributes to Attrs.td, then you're limited indeed to tokens and the first approach.
I would like to write out an indicator that can take in input the int shift of an assigned timeframe, and turns out a value related to another timeframe.
As an example, I would like to write an MACD indicator over a 100 periods of M15, that can return out its value 1,2,3,4,5,6,7... minutes before the current candle.
Since in the current candle this indicator "changes" its value, tick by tick, I think that should be possible to write out such an indicator, but I can not figure out how to do it.
MQL4 language principally has tools for this:
However, as noted above, your experimentation will need thorough quant validations, as the earlier Builds did not support this in [MT4-Strategy Tester] code-execution environment ( and more recent shifts into New-MQL4.56789 have devastated performance constraints for all [CustomIndicators], the all [MT4-graph]-GUI-s together plus the all [Expert Advisor]-s use, since all these suddenly share one ( yes, ONE and THE ONLY ) computing thread.
Ok, you have been warned :o)
So,
if indeed keen to equip your [CustomIndicator] so as to be independent of the GUI-native-TimeFrame, all your calculations inside such [CustomIndicator]-code must use indirect access-tools to source the PriceDOMAIN data - so never use any { Open[] | High[] | Low[] | Close[] }-TimeSeries data directly, but only using { iOpen() | iHigh() | iLow() | iClose() }
All these access tools conceptually have a common signature:
double iLow( string symbol, // symbol
int timeframe, // timeframe
int shift // shift
);
and
if your code
obeys this duty,
your [CustomIndicator]( iff the StrategyTester will not finally spoil the game -- due quant testing will show this )
will be working with data from timeframe & shift of your wish.
Implementation remarks:
Your [CustomIndicator]-code has to implement a "non-GUI-shift" independently from the GUI-native-TimeFrame shift-counting. See an iCustom() signature template for inspiration. The GUI-TimeFrame-shift is like moving the line-graph on GUI-screen, i.e. in GUI-native-TimeFrame steps, not taking into account your [CustomIndicator] "internal"-"non-GUI-shift" values, so your code has to be smarter, so as to process this "internal"-"non-GUI-shift" during a value generation. If in doubts, during prototyping, validate the proper "mechanics" on Time[aShiftINTENDED] vs iTime( _Symbol, PERIOD_INTENDED, aShiftINTENDED )
Due to quite a lot of points, where an iCustom() call-interface may be a bit misleading, or a revision-change-management error-prone, we got used to use a formal template for each [Custom Indicator] code, helping to maintain referential integrity with a iCustom() use in the actual [ExpertAdvisor] code. It might seem a bit dumb, but those, who have spent man*hours in search for a bug in { un- | ill- }-propagated call-interface changes, this may become a life-saver.
We formalise the call-interface in such a way, that this section, maintained in the [CustomIndicator]-code, can always be copied into the [ExpertAdviser] code, so that the iCustom() signature-match can be inspected.
//vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//!!!!
//---- indicator parameters -------------------------------------------------
// POSITIONAL ORDINAL-NUMBERED CALLING INTERFACE
// all iCustom() calls MUST BE REVISED ON REVISION
//!!!!
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
#define XEMA_CUSTOM_INDICATOR_NAME "EMA_DEMA_TEMA_XEMA_wShift" // this.
//--- input parameters ------------------------------------------------------ iCustom( ) CALL INTERFACE
input int nBARs_period = 8;
extern double MUL_SIGMA = 2.5;
sinput ENUM_APPLIED_PRICE aPriceTYPE = PRICE_CLOSE;
extern int ShiftBARs = 0;
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
/* = iCustom( _Symbol,
PERIOD_CURRENT, XEMA_CUSTOM_INDICATOR_NAME, // |-> iCustom INDICATOR NAME
XEMA_nBARs_period, // |-> input nBARs_period
XEMA_MUL_SIGMA, // |-> input MUL_SIGMA
XEMA_PRICE_TYPE, // |-> input aPriceTYPE from: ENUM_APPLIED_PRICE
XEMA_ShiftBARs, // |-> input ShiftBARs
XEMA_<_VALUE_>_BUFFER_ID, // |-> line# --------------------------------------------from: { #define'd (e)nums ... }
0 // |-> [0]-aTimeDOMAIN-offset
); //
*/
#define XEMA_Main_AXIS_BUFFER_ID 0 // <----xEMA<maxEMAtoCOMPUTE>[]
#define XEMA_UpperBAND_BUFFER_ID 1
#define XEMA_LowerBAND_BUFFER_ID 2
#define XEMA_StdDEV____BUFFER_ID 3
#define XEMA_SimpleEMA_BUFFER_ID 4 // sEMA
#define XEMA_DoubleEMA_BUFFER_ID 10 // dEMA
#define XEMA_TripleEMA_BUFFER_ID 11 // tEMA
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//!!!!
//---- indicator parameters -------------------------------------------------
// POSITIONAL ORDINAL-NUMBERED CALLING INTERFACE
// all iCustom() calls MUST BE REVISED ON REVISION
//!!!!
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Found a way to write it in a very simple way:
double M1 (int shift) {double val = iCustom(NULL,PERIOD_M1, "my_indicator",100,2.0,30.0,0,shift); return(val);}
double M15 (int shift) {double val = iCustom(NULL,PERIOD_M15,"my_indicator",100,2.0,30.0,0,shift); return(val);}
int s1_15;
double B_M1_M15(int i) {
if (i>=0 && i<15 ) s1_15=0;
else if (i>=15 && i<30 ) s1_15=1;
else if (i>=30 && i<45 ) s1_15=2;
else if (i>=45 && i<60 ) s1_15=3;
else if (i>=60 && i<75 ) s1_15=4;
return NormalizeDouble(MathAbs(M1(i) - M15(s1_15)),Digits);
}
and so on for every others couples of timeframe.
I would like to access and modify single entries in a non-contiguous submatrix view. I tried it like this:
#include <armadillo> // version 5.200.2
int main()
{
arma::mat A(4, 4, arma::fill::zeros);
arma::uvec b(4);
b << 2 << 3;
auto view = A.elem(b, b);
view(0, 0) = 1.0; // Error: No operator()
}
This doesn't work because the expression returned by A.elem(b, b) appears to have no operator() defined. I found that the same thing works with contiguous views like e.g. submat(). Is there any solution/workaround for this or is it simply not possible in the non-contiguous case?
I have a large enum (for the sake of transparency 63 values), and I am now creating a NS_Options bitflag based on that enum. Is there a way that I can write this so that it will be flexible?
The main concerns I have with hardcoding it are:
If I add/remove an enum, I will have to manually add/remove it in my bitflag.
There is a lot of typing to generate these.
My .h file is getting intensely long (because I like to use whitespace and adequate comments)
The only solution I've come up with thus far is:
#define FlagForEnum(enum) 1 << enum
typedef NS_ENUM(NSInteger, ExampleEnum)
{
Value1,
Value2,
...
ValueN
}
typedef NS_OPTIONS(NSNumber, ExampleEnumFlags)
{
Value1Flag = FlagForEnum(Value1),
Value2Flag = FlagForEnum(Value2),
...
ValueNFlag = FlagForEnum(ValueN)
}
This is a barely adequate solution when I remove an enum (at least I get a compile error), and if the enum ordering gets changed, the flags' bitshifted position changes too (not that it truly matters, but it seems comforting). But it doesn't solve the 'this-is-a-lot-of-typing' problem, or the 'what-if-I-forget-to-add-a-flag' problem.
You can use a technique called X Macro
#define VALUES \
VALUE_LINE(Value1) \
VALUE_LINE(Value2) \
VALUE_LINE(Value3)
typedef NS_ENUM(NSUInteger, ExampleEnum)
{
#define VALUE_LINE(x) x,
VALUES
#undef VALUE_LINE
}
typedef NS_OPTIONS(NSUInteger, ExampleEnumFlags)
{
#define VALUE_LINE(x) x##Flag = 1 << x,
VALUES
#undef VALUE_LINE
}
Here is a slightly better (in terms of less typing) preprocessor #define solution. Although this still isn't as elegant as I'd like.
#define BitShift(ENUM_ATTRIBUTE) (1 << ENUM_ATTRIBUTE)
#define CreateEnumFlag(ENUM_ATTRIBUTE) ENUM_ATTRIBUTE##Flag = BitShift(ENUM_ATTRIBUTE)
typedef NS_ENUM(NSUInteger, ExampleEnum)
{
Value1,
Value2,
...
ValueN
}
typedef NS_Options(NSUInteger, ExampleEnumFlags)
{
CreateEnumFlag(Value1),
CreateEnumFlag(Value2),
...
CreateEnumFlag(ValueN)
}
This will create flags of the form Value1Flag, Value2Flag, ..., ValueNFlag.