The Origen compiler defaults to reloading the target when running in inline mode. This slows down the compiler performance, can this be disabled?
The inline compiler call can be passed the 'preserve_target' option to avoid reloading the target.
Origen.compile("#{Origen.root}/templates/my_template.txt.erb", preserve_target: true)
Related
I know that for css, html, and gsp files you can just refresh the browser without having to rebuild the application in order to see your updated changes. If you're stepping through code in debug mode, and make a change for a groovy or class file, do you have to rebuild the application in order to see the change?
IntelliJ does not update the classes in your running application automatically. You need to compile them manually (this will not be a full project rebuild - IntelliJ will build the project incrementally and compile only the changed classes and the code that depends on them), and then IntelliJ will offer you to reload the changes (which may fail if the changes you made aren't supported by the Java hotswap).
Note that some Web frameworks may be able to reload the changed classes automatically, independently of whether you're running your code from IntelliJ or not.
Say you're stopped on a break point, and want to edit the source code of the method you're in. Make the edit, save it, then run > Reload Changed Classes. Then, in the debugger controls, Drop Frame. Without dropping the frame, you won't execute the your newly recompiled method body.
By default, there's no keybindings for these 2 commands, but you can create them via the KeyMap in the settings (ctrl + alt + s). Even better, you can make a macro that will execute both these commands for you.
I wish it was easier and automatic, like in eclipse, but oh well.
I've told VC++ to compile my program in release mode, yet the assert() statements still fire. I thought assertions were supposed to be compiled out of release builds for performance. What's going on? Is there some other setting I need to set skip compiling them?
Check which preprocessor symbold you're defining. A Debug build would normally define _DEBUG, and a Release build would normally define NDEBUG. Assertions would normally be switched off when NDEBUG is defined.
Open the app under the debugger. Do debug->break when the assertion dialog is up. Look at the source file where the assert is firing. Now look at the build settings of that file. If the settings seem right and you are loading the release version, set /P and /d1PP on the compiler command line to reveal where the errant #define is coming from.
Martyn
I'm using Qt Creator on Ubuntu to develop C. Whenever I run with the debugger, I get the message warning: GDB: Failed to set controlling terminal: Invalid argument. This happens even with a hello world program. How can I solve this?
This is a bug in Qt Creator, which is not invoking GDB correctly (either inside a pseudoterminal, or with command line arguments that tell it not to expect to be run inside a pseudoterminal). It is also a bug in GDB, which could figure out for itself that it wasn't being run inside a pseudoterminal and behave accordingly. I suspect the GDB maintainers will take the position that this is Qt Creator's fault, and vice versa, alas.
There is a claimed workaround here: http://www.qtforum.org/article/31905/debugging-qt-application-on-linux.html but it sounds kinda dodgy to me.
Whether this warning is a bug or not, it is informative as a clue that you have the option to tell QtCreator to cause your program to run in a terminal which may be useful for debug output. See Setup GDB with QtCreator to enable this option.
If you don't want a terminal open, then just ignore the warning.
I have added some ToolBars(CToolBar [FIXEDBMP]) and a AnimateControl(CAnimateCtrl [FIXEDBMP,FIXEDSIZE]) to a ReBar (CReBar). No Specific positioning is done for any of the Tool Bars or Animate Controls. Now The Animate Control gets MISALIGNED(Goes in the Top Left over the Menu Bar) ONLY in the Release Build, whereas in the debug build it is in the desired position(Top Right along with other ToolBars). I am not sure if there are any Issues with Release DLL or am I missing some thing?
One of the following:
in Debug you have an ASSERT() that evaluates the result of a method call which modifies the state of the AnimateControl. On Release, that method call is not being evaluated.
You have code that executes only on Debug through #ifdef
A variable is either being explicitly initialized differently on Debug and Release, or you are using uninitialized variable in your code.
Without seeing the actual code it will be hard to tell more.
When porting unix project developed in C language to windows and compiling it with VS 2005, compiler reports errors related to incorrect type conversion like " can not convert 'const char*' to 'char*' ". Is it possible to disable this strong checking through compiler options.
-Thanks for attention
Assuming your code is valid C (C89, specifically, since VC++ doesn't support C99), it will be automatically disabled if you either name the file with a .c extension, or in project properties, set it to "Compile as C"
That should disable all C++-specific features and type checks.
I'm pretty sure, you only need to set the "Compile as C" commandline option (/TP). I'm not entirely familiar with ANSI-C (Over ANSI-C++) but i'd strongly recommend converting it to be type safe regardless. Why return a const and then ignore this fact?
I'm not sure you can - it may be the case that the C code isn't valid (and the Unix compiler you're using incorrectly allows it). You can disable warnings, but I don't think you can disable specific errors.
If you haven't already, you can change the project options to compile as C instead of C++ (Prpoerties -> Config Properties -> C/C++ -> Advanced) but I don't think that'll help.
If you can compile as C++, const_cast might be able to help: http://msdn.microsoft.com/en-us/library/bz6at95h(VS.80).aspx