I am building a console application in Linux Ubuntu. Setting environment variables in Qt Creator's Run Environment panel is not working, both if I switch on the flag "Run in terminal" or not. It looks like they are just ignored. If I export those variables outside Qt Creator, in a plain terminal, and then run my console application, everything is fine.
I am using Qt Creator 3.5.1.
Ok so I think you are setting the variables in the correct place, but just in case here is a screen shot of where I set mine.One thing to note which we already discussed in the comments is what "kit" you are running. In the screenshot below, I only have one kit set up, but if you have more than one, you have to choose the appropriate kit by clicking on the little monitor icon in the bottom left of Qt Creator.
Then in code I use the following:
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
// Get the variable or a default value if the variable is not set.
// Qt abstraction that should work cross platform.
QString s = QProcessEnvironment::systemEnvironment().value("VAR_ONE", "");
// Get variable in platform dependent way.
char * s2 = getenv("VAR_ONE");
// Print out the results.
qDebug("%s", s.toStdString().c_str());
qDebug("%s", s2);
return a.exec();
}
If you are doing all of this and still having issues, I would try making an new empty console application and see if the above works to narrow down if the problem is with your Qt Creator in some way or if the project you are working in has some setting that is off.
Related
I am trying to create a util for logging.
I need to know the actual differences between print() vs debugPrint() and log().
Many answers I have seen are outdated or confusing. Also, some upvoted answers are contradict.
I am trying to print error messages in red color. I am using ANSI code to achieve it.
debugPrint("\x1B[31m HelloDebug \x1B[0m");
The above one print in red color.
But when i do the same using log(), its not printing in red color. Its escaping the ANSI code.
One thing I found out was log() has error parameter.
If i pass something as error , it handles red color by default.
Here in the first one using log, red is not coming because ANSI code is ignored. But in debugPrint using it's working fine. In third one it takes error red by default. But extra line is added even for empty string message.
Code:
Output:
Is it possible use ANSI code for making color text using log?
Because I have other ANSI code to make different color text.
I dont want use debugPrint because if I print some thing too frequently , the system ignore the logs.
After digging some time I found out that log function is implemented in c++ in the dart runtime.As the log function is external function in dart sdk.
external void log(
String message, {
DateTime? time,
int? sequenceNumber,
int level = 0,
String name = '',
Zone? zone,
Object? error,
StackTrace? stackTrace,
});
https://github.com/dart-lang/sdk/blob/main/runtime/lib/developer.cc
Also I see some different answers while digging.
The below answer says debugPrint only available inside widget class. Is it still true?
https://stackoverflow.com/a/52241553/9248098
EDIT:
While using debugPrint and when I launch app from Android studio terminal, the ANSI color is working in android but when I run it same in iOS its escaping the characters in same Android Studio terminal.
If ANSI code support is based on terminal support, I couldn't figure out why its having issue in same terminal in iOS.
It is well explained in this page Debugging Flutter apps programmatically
debugPrint() is similar to print() but with a throttles applied to prevents being dropped by Android’s kernel.
If you have linter setup on VSCode or other IDE, you will see this warning whenever you use print in your code. For more information, you can refer to Avoid print calls in production code.
To avoid the lint error, you can use kDebugMode with print or debugPrint instead.
if (kDebugMode) {
print('test print');
}
// OR
debugPrint('test debugPrint');
As for log(), it actually allows you to include more information on the logging output. For example, you can add the runtimeType and the relevant object in the log that can help you in debugging the code.
log(
'test log',
name: runtimeType.toString(),
error: myObj,
);
** btw I tried log with ANSI code log("\x1B[31m HelloDebug \x1B[0m");, it is working as expected.
I am trying to detect object using ssd_mobilenet_v1_coco model. My own trained model file .pb file is used for detection. After successful build , click run button and I got the below error.
"Not found: Op type not registered 'NonMaxSuppressionV2' in binary running on IPhone. Make sure the Op and Kernel are registered in the binary running in this process. "
I can executed and launch ios app for already trained .pb model file in below link.
please give a solution to fix the above issues and launch ios app.
https://github.com/JieHe96/iOS_Tensorflow_ObjectDetection_Example
The problem is exactly what the error says - The operation NonMaxSuppressionV2 is being used by the model (.pb file) you're using but it is not registered with tensorflow library while getting compiled for iOS platform.
This is because tensor flow restricts a lot of operations [especially the ones usually required only for training] on iOS/Android platforms so that the size of compiled libraries are less.
To rectify the above problem you can do the following -
Update the file present ops_to_register.h file present here.
Add the "NonMaxSuppressionV2Op<CPUDevice>" (Don't forget to add coma if you're adding in middle of array ) to kNecessaryOpKernelClasses array.
Like this -
constexpr const char* kNecessaryOpKernelClasses[] = {
"BinaryOp< CPUDevice, functor::add<float>>",
"BinaryOp< CPUDevice, functor::add<int32>>",
"AddNOp< CPUDevice, float>",
"NonMaxSuppressionOp<CPUDevice>",
//Added NonMaxSuppressionV2Op
"NonMaxSuppressionV2Op<CPUDevice>",
...
//Other operations
...
};
And also isequal(op, "NonMaxSuppressionV2") to constexpr inline bool ShouldRegisterOp(const char op[])
Like this -
constexpr inline bool ShouldRegisterOp(const char op[]) {
return false
|| isequal(op, "Add")
|| isequal(op, "NoOp")
|| isequal(op, "NonMaxSuppression")
//Added NonMaxSuppressionV2
|| isequal(op, "NonMaxSuppressionV2")
|| isequal(op, "Pack")
//other stuff
...
;
After you modify this file re-run everything from scratch as mentioned in the quick-start section of repo's readme.
If you are still losing some other operations. Repeating the same procedure for them too will work.
Hope that helped.
One of the used references for my code is Refprop which includes required functions such as Temperature. In debug mode, there isn't any problem, but when outside the vb I run the code there is a "type mismatch" error to calculate TR_O_P_Com.
Option Explicit
Sub Simulation()
Sheets("Sheet1").Activate: Range("A:ZZ").Select: Selection.ClearContents
'
TR_O_P_Com = Temperature("R134A", "HP", "si", HR_O_P_Com / 1000, PR_S_P_C) - 273.15
and when I use F8 in debug mode there isn't any problem! I have declared all of the variables such as HR_O_P_Com and TR_O_P_Com.
I am so grateful if you help me to remove this error.
Regards
Seems like dll and exe has different method signature. For example in dll method A(int a, int b) and in exe you are calling with A(int a, char c). But not sure. Use all the latest dll and exe after the compilation and try again.
Did you compile the code in release mode? First use the exe that has been generated in debug mode out side of vb. If that works fine then try with the exe in release mode.
This script (source code) can be perfectly executed in the production mode.
void main() {
int greeting = "Hello world!";
print(greeting);
}
This is a traditional hello world example that works fine in Dart.
The result is "Hello world!".
This script is self enough because not required other functionality and it works as expected.
Now I have small questions:
Can I consider that this script is valid and correct source code in Dart language becuase it works as expected?
If this script is valid source code in Dart language then why it cannot be executed in non-production mode?
If some code that can be perfectly executed in the production mode but cannot be executed in other mode then which mode in Dart more correct (production mode or other mode)?
P.S.
As a programmer, I am interesting not in theory and practice but I have interest only in answers in my small questions based on real example (even if it are very small).
If my questions are not so correct then I would like to know why?
Because they are directly related to programming in Dart language.
It is valid because types are ignored in production mode.
In checked mode (intended for development only) types are checked and you get an exception.
Types in Dart are not for runtime but for development time to make tools able to reason about the code and show possible bugs.
This means it doesn't matter if you type String or var. You cannot omit it completely because this violates the syntax.
It can be executed in production mode
# ~/dart/playground/bin/dart_valid
$ dart main.dart
Hello world!
It fails in checked mode (development mode)
# ~/dart/playground/bin/dart_valid
$ dart -c main.dart
Unhandled exception:
type 'String' is not a subtype of type 'int' of 'greeting'.
#0 main (file:///home/zoechi/source/my/dart/playground/bin/dart_valid/main.dart:2:18)
#1 _startIsolate.isolateStartHandler (dart:isolate-patch/isolate_patch.dart:216)
#2 _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:115)
pub build fails because it uses the analyzer which utilizes type annotations like in checked mode and throws.
Is there a way to set the execution point while debugging Xcode/lldb? To be more specific, after hitting a breakpoint, moving the execution point manually to another line of code?
If you're looking at moving it up or down with in a method you can click and drag the green arrow to a specific point. so if you want to back up a line before the breakpoint. click on the green arrow that is produced and drag it up. If you hit run you'll hit your breakpoint again
In Xcode 6, you can use j lineNumber - see documentation below:
(lldb) help j
Sets the program counter to a new address. This command takes 'raw' input
(no need to quote stuff).
Syntax: _regexp-jump [<line>]
_regexp-jump [<+-lineoffset>]
_regexp-jump [<file>:<line>]
_regexp-jump [*<addr>]
'j' is an abbreviation for '_regexp-jump'
One of the great things about lldb is that it's easy to extend it with a little bit of python scripting. For instance, I threw together a new jump command without much trouble:
import lldb
def jump(debugger, command, result, dict):
"""Usage: jump LINE-NUMBER
Jump to a specific source line of the current frame.
Finds the first code address for a given source line, sets the pc to that value.
Jumping across any allocation/deallocation boundaries (may not be obvious with ARC!), or with optimized code, quickly leads to undefined/crashy behavior. """
if lldb.frame and len(command) >= 1:
line_num = int(command)
context = lldb.frame.GetSymbolContext (lldb.eSymbolContextEverything)
if context and context.GetCompileUnit():
compile_unit = context.GetCompileUnit()
line_index = compile_unit.FindLineEntryIndex (0, line_num, compile_unit.GetFileSpec(), False)
target_line = compile_unit.GetLineEntryAtIndex (line_index)
if target_line and target_line.GetStartAddress().IsValid():
addr = target_line.GetStartAddress().GetLoadAddress (lldb.target)
if addr != lldb.LLDB_INVALID_ADDRESS:
if lldb.frame.SetPC (addr):
print "PC has been set to 0x%x for %s:%d" % (addr, target_line.GetFileSpec().GetFilename(), target_line.GetLine())
def __lldb_init_module (debugger, dict):
debugger.HandleCommand('command script add -f %s.jump jump' % __name__)
I put this in a directory where I keep Python commands for lldb, ~/lldb/, and I load it in my ~/.lldbinit file with
command script import ~/lldb/jump.py
and now I have a command jump (j works) which will jump to a given line number. e.g.
(lldb) j 5
PC has been set to 0x100000f0f for a.c:5
(lldb)
This new jump command will be available both in command-line lldb and in Xcode if you load it in your ~/.lldbinit file -- you'll need to use the debugger console pane in Xcode to move the pc instead of moving the indicator in the editor window.
You can move the program counter (pc) in lldb using the lldb command register write pc. But it's instruction based.
There's an excellent lldb/gdb comparison here that is useful as an lldb overview.