I am writing a GUI in Qt, where I have:
QApplication app(argc, argv);
which is invoked by:
app.exec();
Which returns only when the application terminates.
For executing SystemC simulation inside the application, I need to invoke:
sc_start(...);
Which also returns only when the simulation terminates.
Shall I hack Qt or SystemC to circumvent the problem, or is there some trick I can use? How can I avoid the deadlock of the two blocking calls?
You should run them inside two different threads or processes. And design a communication mechanism to exchange data between simulation and GUI.
Another common idea utilized by SystemC debuggers and interactive waveform viewers is to run SystemC under GDB and use GDB-MI protocol to control simulation from GUI.
Related
Supposing I have two applications, one that has features based on aspect oriented programming such as authentication, authorization, logging, exception handling etc. and the other one that connects to the previous application and has buttons that enable/disable aspects. Is there a way that I can do this? (while the AOP app is running)
You could write your program such that logging is disabled if some (global static) property is false. Of course then this effectively disables logging. (and yes you could write this behavior in 1 or many aspects)
However a AOP app is a compiled program, and aspects are just compiled code. There is no "now run the program as if the aspect wern't compiled in".And even if you recompiled your code you wouldn't be guaranteed everything just worked (except the logging). Some aspects can modify inputs that your program relies on for example. without the aspects your program might just crash.
I am working with the QuickTime API and need to perform a few lengthy (as in hours) operations in the background. Unfortunately, it is not multi-thread friendly, so I am falling back to perform the tasks in a separate process, so all QuickTime related calls can happen in its main thread.
After launching it, I need a way of getting feedback on its progress, since the operations can take very long.
I am unsure of how to do this, specifically:
Should the separate process be compiled as another cocoa app or a command line tool?
How to launch it from the main cocoa app?
How to periodically get an object from it to get status information?
How to determine when it finished?
How to avoid showing a window/console when called?
How to have it part of the .app bundle so that it does not appear as a separate executable to the user?
These are really 6+ questions, but they are very related and very specific, and I think anyone needing to launch external processes (instead of spawning worker threads) can benefit from their answers. Generic code examples would be very helpful.
If it is possible, then implement the functionality in a command line tool, or another form of GUI-less application. For Cocoa applications it is possible to prevent them appearing on the Dock or in the Force Quit dialog, however a command line tool is a single binary file which does that anyway, so that would probably be a better way.
In terms of launching the tool, NSTask & NSPipe are your friends in this endeavour. The tool can definitely be kept inside your main Application's bundle, inside the Resources directory or some such, and then launched when needed. You can use the pipe to communicate back and forth.
I don't have any example code to hand, and its been a long while since I've had occasion to use either of these classes so the information I can give is limited, but it should be enough to point you in the right direction.
I would like to call MQL4 or MQL5 function from my own imported DLL in Metatrader.
Is it possible?
Forest,
As far as i have experienced during the past 2 years working with MetaTrader, there is no real way to call MQL functions from an external DLL. But there are some custom built APIs that closely resemble to what you want to achieve:
MT4 API
MetaTrader™ Java / .Net API
These APIs do somewhat allow you to use MQL functionality out-of-the-box
Principle
After several hundred man*years in the FX domain, there is another approach to orchestrate a smooth and elegant MT4 Terminal co-operation with other processes than to try to push water up the hill or than to pay USD500+ for a kit, that will stop working right upon the next shock once Build 524-> Build 562->Build 586->Build 600->Build 609->Build 624->... moves again
A non-existent toy
Yes, MT4 architecture does not expose it's own interface to allow self to be "disturbed" by an undeterministic obligation to handle external low-level calls via DLL et al.
How to fix it
Nevertheless, it is possible to reverse the architecture and make MT4 Terminal act as a lightweight thin-Client, operating a smart messaging library, trough which the MT4 functions are being exposed for a remote call ( RPC ).
Example
This way a Python Node may collect MT4 data for numerical processing,
same way a PHP Node may in parallel handle remote-syslog-s,
same way a C++ Node may integrate another task,
same way another Python Node may act as a CLI terminal interface with a Custom-specific scripting-syntax language to command MetaTrader-side activities via command-line / stdio
simply -- whatever your application infrastructure needs can be done this way
( One may even improve a poor real-time features of the native MT4 threads to gain a much better soft-real-time predictability and a low-latency massively parallel architecture .. and still be on a safer-side, protected from being torpedoed by any next "new"-MQL4 )
nota bene: just to imagine the invisible threat, the headbang collision in "new"-MQL4.56789 is, besides others, that string, while being syntax-proposed as string, is not in fact a string but a struct and all your previous DLL-related work simply has to be re-worked and wrapped-around to emulate a string-as-struct or a new DLL-interface has to be designed for cases, which return a value in a buffered ArrayOfBYTEs, which MQL4.56789 side can receive and process, but which it cannot free on it's own and memory leaks.
If it's acceptable for your DLL to be a .NET DLL, then you could try
this MT4 .NET integration library called NQuotes.
With this library it's possible to access any MQL4 function from your DLL.
I am thinking of making a "programming game", i.e. where each player writes a program to control their "bot", and then the programs are pitted against each-other to see who wins (by some definition of "win").
To make this fair, each bot program should execute at the same speed, so using native pre-compiled C/C++ code seems out of the question.
I can think of 3 options, but am unsure about 2:
Use a language that runs in a VM - This would mean that bots are written in Java and compiled to JVM bytecode. Then every bot gets a JVM and I would need to control the JVM "clock" or whatever it has to control the execution speed.
Problem: Can the JVM "clock" be controlled, telling it to run X clock cycles worth of code?
Use a scripting language - Bots wuld be written in JS or Python or whatever.
Problem: Same as above - can the speed be controlled?
Use my own simplified language -
Problems: I am writing a game, not a compiler. It will mean anyone playing has to learn yet another language, which means no one will play.
So basically, I guess the question is can I control the execution speed of the JVM or some language interpreter (not in theory - in practice)? Or is there another option I didn't think of?
The JVM isn't real-time, nor, I suspect is your OS. Relying on the JVM and/or process interactions isn't going to work since you're at the mercy of OS scheduling, JVM thread scheduling etc.
If you want to coordinate multiple threads, then you should look at the JVM thread model and in particular how to use locks to coordinate 2 threads.
One option would be to write your own JVM that you instrument to run only a fixed number of bytecode instructions from each program. Bytecode is a lot easier to digest that human-readable source code, so you could get away with relatively little implementation work, while your users would get to program in any programming language that can produce Java bytecode.
It gets easier if you institute some restrictions like "no threads" and "no try/catch". You'll need to implement a few core language features from java.lang.* plus some domain-specific I/O features, but for most of the rest of the JRE (for example java.util.*) you should be able to get away with executing bytecode from an existing JRE implementation (modulo legal constraints if you distribute the game engine).
Expect a slowdown of between 10x and 100x (depending on your implementation technology) compared to running on an off-the-shelf optimized JVM.
Alternatively, run an existing JVM in debug mode, single-step through the contestant programs with your game pretending to be a debugger. Whether this is easier or harder than writing a bare-bones JVM yourself I'm not sure.
Can anyone please provide me with some tutorials, explaining running processes inside threads.
I mean process control, with in wxwidgets. I'm trying to implement a gui for a console application.
Some points to remember:
The main thread is special and is the only one which can support the GUI. Worker threads can however prepare bitmaps and then use AddPendingEvent or QueueEvent to tell the main thread they have data it can use.
Never free an area of memory in a different thread from the thread in which you allocated it.
wxString is not thread safe. It is risky to use it to communicate between threads.