I am using a module called TimeIsTime (https://www.azerothcore.org/catalogue-details.html?id=342405971) to accelerate the day/night cycle in game.
So far, I made some changes on it for my own usage, but each time I had to recompile my worldserver to get the changes recorded, is there a faster way ?
I saw someone use the reload [modulename] command in the worldserver prompt to refresh it at runtime, but I didn't managed to get the same result.
I had no luck trying to find the information on the Wiki page.
Any solution ?
Thanks
Any changes to the source code of a C++ module require a full re-run of cmake and a clean build. There is no way to bypass this that i am aware of.
As an alternative the Eluna engine allows the execution of Lua code which can be changed and loaded at runtime.
Related
I am new to Meteor. I just start using Meteor for the first time. It seems a bit slow. I am developing on a Macbook Pro with SSD. I am using Firefox, and Vim. I tend to save the files frequently, causing it to refresh the browser. It takes a few seconds for the browser to refresh. I do not have much code yet. Are you experiencing this slowness? How can this be improved? Does MDG have any plan to improve this? If I make change to a file, can we cause the browser to just reload that file rather than doing a full build and causing the browser to reload all the files? Am I missing something? Thank you!
Unfortunately, you can't do anything about it. However, the complete rebuild takes place only when you change the server side code. For any client changes, the change is almost instantaneous.
You can try some workarounds by removing some packages from meteor but they will affect debugging.
There is a great thread on this issue on Meteor's Github Issue section. You can find it here
Also, you may consider using WebStorm as it is the only IDE with built-in meteor support. May help you speed up your dev time.
UPDATE: You may try using import functionality in Meteor 1.4 to define file dependencies. Also, have a look at this package
I'm trying to learn about the guts of Unix right now, mostly through experimentation. When I was first starting, I found myself looking through forum posts, copying and pasting bash code. When I broke something, I often had to do a fresh install because I couldn't remember what exactly I had changed where. Now, the simple solution is to record a log of all the system files I've changed and keep original copies of all the default files so I can revert if necessary. It would be great if there was a cl tool which did this for me automatically. It would be even greater if I could step back through changes. Basically, I'm looking to version control my entire OS.
Does anything like this exist? I would also accept alternative strategies for spelunking through Unix without causing permanent damage if you think I'm going about this wrong.
Using debian if it matters.
I am using aspnet_complier command for building website, first time it is compiling complete website i.e all pages, but after modification on the site, it is again compiling all the pages. It should compile only that pages that have been changed or modified.
And other things are
1) How can i speed up the aspnet_compiler ?
2) how can i exclude warning from the output ?
Please suggest on the same.
According to the documentation, "You can also recompile an application in place after adding new source files to it. The tool compiles only the new or changed files unless you include the -c option".
Unfortunately, there doesn't appear to be an option to hide warnings.
Speed up the process by making sure the machine where you run it is appropriately powered. eg. an SSD disk should probably help.
I'm getting crazy with a bad memory access in a qt program when i'm using qglwidget::rendertext function. My program is super simple, I'm only one pointer, but the crash doesn't seem relate to that because the debugger stops sometimes when i call rendertext, sometimes when i close the programs. i'm not experienced c++ programmer and this is getting me crazy.
but i've found this BUG REPORT. It seems recent (Updated: 25/Apr/13 8:47 AM) and due to the fact I don't know what to do with this bad memory access i think it worths to give it a try.
the solution patch is posted here but i don't know what to do.. do i have to recompile all qt 4.8? only the opengl part? can i avoid to recompile everything?
Go to the directory where you compiled Qt and change the file qt/src/opengl/qpaintengine_opengl.cpp. Make the changes that the author made, or download the author's file and replace it in your source directory. Change directory to the main qt directory and run make. Be sure not to re-run ./configure before you do the make or it will rebuild the whole thing.
After make has finished, run sudo make install and it will put the newly compiled QPaintEngine module into your install directory. Unfortunately, I don't know if this will work if you have a number of configurations (like static libraries), but it's worth a try.
I have done this with modules in QtMobility hundreds of times. You also have to remember that you have a Frankenstein's Monster version of Qt now, and when you upgrade remember to re-patch if the change was not committed to the newest build.
Hope this helps.
A lot of time can pass between the moment a stack trace is generated and the moment the stack trace is thoroughly investigated. During that time, a lot can happen to the file in question, sometimes obscuring the original error. The error might have been fixed in the meantime (overlapping bugs).
Is it possible to get Stacktraces that show the offending file at the time of the error?
Not elegantly, and you normally don't want the user browsing through code that's throwing unexpected exceptions anyway (open door to an attacker).
Usually, what happens in a dev shop is that the user reports an error, stack trace, and the build it occurred on. As a tester, you can grab that build from your archives (you ARE keeping an archive of all supported releases somewhere handy, RIGHT?), install, run, and try to reproduce the error, working with the user to provide additional info as necessary. I've seen very few bugs that couldn't be reproduced EVENTUALLY, even if it required running the program against a backup of the user's production database to do it.
As a developer, you can download that build's source code from your version control repository (you ARE using version control, RIGHT?), and examine the lines in the stack trace to try to discover the problem by inspection, and/or build and run it to reproduce the error. Then, you go back to the latest source version, build, and run the same steps (a UI automation system can help out here), and if you don't get the error, someone else already found and fixed it. If you still get the error, you also got an updated stack trace with lines that match the current build, allowing you to set your breakpoints and step through.
What KeithS said, plus there are ways to capture more helpful state information at the time of the Exception using the Exception.Data property. See http://blog.abodit.com/2010/03/using-exception-data-to-add-additional-information-to-an-exception/
While KeithS' answer as pretty much correct, it can be easier and more elegant than you think. If you can collect a dumpfile (instead of just a stack trace), you can use a Symbol Server and Source Server in combination with your debugger to automatically pull your correct-version code from source control.
For example: if you enable PDB output and source-server integration in MSBuild, and upload the resulting PDBs to a symbol server, Visual Studio can automatically load the correct source control from a TFS or SourceSafe repository based on the information in a minidump.