I need to change event-loop in vibed. Docs says that "vibe.d has always used libevent under the hood by default" and "libasync is a cross-platform event loop library written completely in D".
How I can change libevent to libasync?
I found example of dub.json config, but how I can set it in dub.sdl?
upd: it's seems that versions "libasync" is working.
If you want to use built-in libasync support in vibe-d, add the following to your dub.json:
"dependencies": {
"vibe-d": ">=0.8.1"
},
"subConfigurations": {
"vibe-d": "libasync"
}
If you prefer SDL, your dub.sdl file should contain something like:
dependency "vibe-d" version=">=0.8.1"
subConfiguration "vibe-d" "libasync"
Related
Is it possible to specify a C/C++ include path to a remote preprocessor server?
The point here is to have once central location for header files. This makes upgrades, version consistency, and a host of other things much better than people running all willy-nilly including different versions of things.
Minimal, Complete, and Verifiable Example
Typical include. On Linux, would default to /usr/include/ or the like; in Windows VS, to a location specified in the $(IncludePath) variable.
#include <iostream>
int main() {
std::cout << "hello, world" << std::endl;
return 0;
}
Now imagine that we set our include path as follows:
C_INCLUDE_PATH=192.0.2.17://usr/include;/usr/include;
The above would first check the remote server at 192.0.2.17 to see if the iostream library existed. Failing this, /usr/include would be checked.
This is a bit of a stretch to illustrate the point:
#include <192.0.2.17://iostream>
int main() {
std::cout << "hello, world" << std::endl;
}
Thanks, Keith :^)
Since you want version control anyway you could just use git (like thousands of other projects). So each user has a local clone of anything needed.
To answer the original question: No. I'm not aware of any preprocessor supporting such an include scheme.
I'm not aware of any compiler that retrieves include files or libraries remotely, so this is not something you can do directly.
The best you can do is have these dependencies on an NFS share that you can mount and then add that path to your include path.
I wouldn't put references to this in the code like that, and as dbush said, you'd have to enhance the preprocessor.
But there might be cute ways to do this within the Make system. That is, if you're using Make (for instance), you could add steps to the Makefile that force a refresh of data.
However, I would suggest this is WRONG because it's not just the include files that need to be fresh. If an include has changed, the related code has probably also changed, and you would need those changes, too. Your magic #include stuff isn't going to do a thing to make sure people have the right code / libraries that the includes are for.
I'm not sure why proper use of source code repositories don't already handle this for you.
I am getting started with Unreal Engine 4. I come from Libgdx and I am familiarized using WebSockets clients in my games and NodeJS with 'ws' on the server.
How ever, I can't find information about Websockets and Unreal Engine 4.
I know that given that it is programmed with C++ you can add external static libraries to the unreal project.
Can I use this c++ websocket library?
https://github.com/zaphoyd/websocketpp
Will it run on Windows, Mac and console?
I am not an expert of c++ and static libraries.
Please help, thanks!
You can follow this tutorial on TCP Sockets.
You will need to make some changes on the code, as it doesn't run on UE 4.10 (the tutorial is originally from 2014).
On the .h file define 2 timer handles:
FTimerHandle TimerHandle_Connection;
FTimerHandle TimerHandle_Socket;
On the .cpp file, inside StartTCPReceiver(...) change the line where the timer is set to:
GetWorldTimerManager().SetTimer(TimerHandle_Connection, this, &AYourClass::TCPConnectionListener, 0.01, true);
and on TCPConnectionListener(...) change the line where the timer is set to:
GetWorldTimerManager().ClearTimer(TimerHandle_Connection);//optional, only if you want to stop listening for new connections
GetWorldTimerManager().SetTimer(TimerHandle_Socket, this, &AYourClass::TCPSocketListener, 0.01, true);
(Another option would be to thread these functions instead of having them in timers)
Just in case, if you are new to UE, don't add the code directly on the IDE. Go to the Content Browser > Add New > New C++ Class. You can create a new class that inherits from Actor, and when you want to start to listen to connections, you spawn that Actor.
You can use any websocket or third party asset with unreal engine. You can simply add the headers in your Build.cs file using PrivateIncludePathModuleNames for example (there's also a public include path) and it takes an array of strings where each string is a folder essentially. If you want to add a library (lib) file you can just add it like this:
if (Target.Platform == UnrealTargetPlatform.Win32 ||
Target.Platform == UnrealTargetPlatform.Win64)
{
PublicSystemLibraries.Add("crypt32.lib");
}
You can also add full paths here. If you want to do a delayed load you can just use PublicDelayLoadedDlls.Add("name") <- I may have the syntax wrong on this one but it's easy to google it.
I am working on a plugin which will have its own plugins to handle various events.
Now I'm thinking of enabling this plugins to add their own "commands". But I wonder how to treat that most efficiently. I have a list of my own commands which I search in the article anyway. Should I then just trigger a DoWhatYouWant($article)-event - or, since I do the searching (and parsing of params) anyway, perhaps I could build a global command-list and then trigger an "ExecuteCommand($article,$cmd,$params)"-event? Sounds nicer, but then (I think) I'd have to build this command-list (so that my program know what to look for), so every plugin would have to somehow 'advertise' what it could do, i.e. the names of commands it could handle - and I have no idea how that could be done.
Or is there a better (more standardized?) approach?
If you import your plugins trough the plugin helper
JPluginHelper::importPlugin('mycmdplugins');
then you can get all available commands which are supported by your sub plugins like
$cmds = JDispatcher::getInstance()->trigger('onMyAwesomeCmds');
With the $cmds variable you know now which commands are supported by the sub plugins and you can parse the article for them. Then you can do
foreach ($cmds as $cmd) {
preg_match_all("{".$cmd."*}", $article->text, $matches, PREG_SET_ORDER);
if (!empty($matches)) {
JDispatcher::getInstance()->trigger('onMyAwesome'.ucfirst($cmd), array($article, $params));
}
}
To eliminate more repeating tasks I suggest that the additional plugins will extend a base class from your plugins folder.
I have the following statements:
static Logging::Logger* common_logger = new Logging::Logger(Logging::Logger::LEVEL);
In the Logger.h i have
class Logger {
public:
enum LEVEL {
Debug,
Warning,
Notification,
Error
};
}
I have included the file Logger.h inside my another class as :
Logging::log(CustomDialog::logger, Logging::Entry, CustomDialog::CLASSNAME, "CustomDialog");
I need to know if this is the right way to do the reason why i am doing this is to get logs based upon the level.
Regards,
Take a look at Log4cxx - it's easy to use and contains just about every feature you might want in a logging framework for C++. It's extensible, it can be configured through configuration files, and it even supports remote logging out of the box.
You can use ACE_DEBUG, it seems old-school (ala printf) but thread-safe, reliable and fully configurable (use logfiles, stdout etc..) You'll have to link against libACE(Adaptive Communication Framework) of course, but it's development packages are easily available in many linux distros per default nowadays. I've been looking over the list from that C++ logging libraries post, mentioned by Als, but it seems most people are running into mem leaks with many of the frameworks and boost::Log is not out yet.
Another point is that most logging libraries using streams, for example like this:
// from thread 1
mlog(mlog::DEBUG) << "Debug message goes here" << mlog::endl;
// from thread 2
mlog(mlog::INFO) << "Info message goes here" << mlog::endl;
will not work as expected in a multithreaded environment, while ACE will perform correctly there.
The output of the above will look something like this:
[thread1 | 12:04.23] Debug me[thread2 | 12:04.24] Info message goesssage goes herehere
I'm trying to use QHttp for an update app. But there is a problem for me which I can't solve.
I try to download a file (works perfectly) but if there is no connection to the internet, the file is created but has 0 bytes. My old file is then overwritten with the empty file, which is not so good for the application trying to use the file. What I need is to check if the computer is connected to the internet.
Note: proxy may set. I used this example from Qt's homepage.
You should switch to the QNetworkAccessManager as Mike Suggested, here is an example of a slot on the finished() signal:
void ApplicationUpdate::replyFinishedhttpGetChangeLog(QNetworkReply* myReply) {
if (myReply->error() != QNetworkReply::NoError)
{
QByteArray returnedData = myReply->readAll();
if (returnedData.size() > 0) {
if( m_fileChangeLog->exists() )
{
m_fileChangeLog->close();
m_fileChangeLog->remove();
}
m_fileChangeLog->open(QIODevice::ReadWrite);
QDataStream out( m_fileChangeLog );
out.writeRawData(returnedData.data(), returnedData.size());
m_fileChangeLog->flush();
m_fileChangeLog->close();
}
}
}
Firstly, you should probably now be using QNetworkAccessManager rather than QHttp.
Using either of them, you should do a dummy query to a site you pretty much always know will be up (e.g. http://www.google.com/) and use that as a test to see if you have an internet connection.
A better way of doing this would be instead to use QNetworkAccessManager to read into a QByteArray and then check it isn't empty before writing to your file.
Whenever you write a file that might already exist, you should create a QTemporaryFile first, then, after successful download, rename it to the final name.
i ran into the same problem, after a bit of poking around, I've isolated the problem down to the project configuration file (.pro), in the broken configuration I was linking the networking library explicitly with the statement : "LIBS += -lQtNetwork". In the working configuration, I used the more formal (and qt compilant) approach of delcaring what Qt components are included in the project, like so: "QT = core gui network xml", adjust accordingly for your sitiation, the netowkring slots did not work on windows when explicitly linked but did work on linux. Using the qt compilant approach works on both platforms.