Is there some way by which, I can get the list of all supported JVM arguments via some API ?
I am writing a program where i need to merge two files which contain JVM arguments. In existing file i need to put new incoming parameters and also merge the value of parameters on both the sides (preference will be given to already existing value).
So, I want to get a list of all possible JVM arguments which can be present in the file.
I don't want to put a hard coded list as my program will be running across multiple platforms like windows, linux and unix etc. and JVM on each platform can have different list of supported arguments.
So i want to write the program in a way which works across multiple platforms.
Thanks in Advance.
The list of all possible arguments of all possible JVMs is, by necessity, always incomplete, even if you restricted yourself to a range of JVMs from a single vendor. And even if you had one, the next patch would probably allow yet another -X.... option.
What is more, such a list wouldn't tell you if a given combination of command line arguments would be correct for a certain, but unknown, JVM. For this, you would need the intersection of the allowed command line arguments of a set of JVMs. Depending on what versions you want to support, it will probably turn out that you could only have non -X... options, except maybe the most common ones like -Xmx, -Xss and -Xms
Related
I use C++ to address the following task:
I'd like to get the list of all API functions, which are used by the particular process. It can be any Windows 7 process - 32 or 64 including system processes.
So far, the only solution I see - is to create a kernel driver to intercept all possible APIs, listen them for some time and check if particular process called them. It won't guarantee me full list of APIs of that process, but at least will give me some of them.
This method looks dangerous and not effective.
If there is any simpler way to deal with that task? If there is a way to get a full list of APIs of the process, not just the ones called during some time?
Thank you.
No, it's not possible, at least in any meaningful or general sense.
I can write a program that (for example) takes interactive input from the user in the form of a string, then uses GetProcAddress to find the address of a function by that name, and invokes that function.
Note that although using interactive input to read function names is fairly unusual, reading them from some external file is quite a bit more common.
Also note that a kernel driver isn't really the correct place to look either. If you want to do this, you want to intercept at the level of the DLLs used by the program.
One possibility is to create a "shadow" DLL for every DLL to which the program links statically. Then if it calls LoadLibrary/GetProcAddress, you can dynamically intercept those calls to determine what functions it's calling in them, and so on.
This still won't get an absolute result, since it could (as outlined above) get data at runtime to find functions in one execution that it doesn't use in another.
If you want an existing tool to do (approximately) that, consider depends.exe. It's been around for quite a while, and works quite well.
This is about programming in the large with SML. First a summary of what's seems to be available for that purpose, then a tiny summary, then finally, the simple question.
The use pseudo‑clause
Top-level type, exception, and value identifiers (standardml.org)
Note that the use function is special. Although
not defined precisely, its intended purpose is
to take the pathname of a file and treat the
contents of the file as SML source code typed
in by the user. It can be used as a simple build
mechanism, especially for interactive sessions.
Most implementations will provide a more sophisticated
build mechanism for larger collections of source
files. Implementations are not required to supply
a use function.
Then later
val use : string -> unit (* implementation dependent *)
Its drawbacks are: not supported by MLton at least, and while not standardized, seems to have the same behaviour with all major SML systems, which is to reload a unit as many times as a use is encountered for it, which is not OK due to the generative semantic of SML (defining a structure multiple times, will result into as much different definitions, which is especially wrong with types definitions).
ML Basis Files
There exist so called “ML Basis Files”: MLBasis (mlton.org) and ML‑Kit ML Basis Files (sourceforge.net).
The load pseudo‑clause
MoscowML has load which acts like use which uses only once, i.e. does not reload a unit if it's already loaded, which is what's expected to compose a system.
Summary
load is nice, but only recognized by MoscowML
MLBasis Files may be nice, but it's not recognized by neither Poly/ML nor Moscow ML
MLton does not recognize use
Putting everything in a single big bundle file, is the only one interoperable thing working with all compilers and interpreters; that works, but that quickly become a burden.
The question
Is there a known interoperable way to compose a system made of multiple SML source files?
One system you did not mention is SML/NJ's Compilation Manager (CM), which is quite powerful. And there are a few other, less known systems.
But that notwithstanding, the situation is indeed dire. There simply is no standardised separate compilation mechanism for SML. In practice that means that writing portable Makefiles or something alike is rather painful.
For HaMLet I went through that pain, in order to make it compile with 7 different SML implementations. The approach is to use a restricted (dependency-ordered) CM file and the necessary amount of make + sed hackery to generate meta files for other systems from that. It can also generate a file containing respective 'use' invocations for all the sources, for all other systems that at least support that. All in all it's not pretty, but works sufficiently well.
I have an application with which I work daily.
The developers have provided a variety of convenience arguments which when passed to the exe perform certain tasks. While debugging an issue the tech support guy told me to run the exe with some special args which reduced a lot of manual steps of my job. However, the developers are not kind enough to share a list of all such args. So I wanted to know whether there is any way to just determine the args which an exe accepts? The application is developed in C++.
The first thing I would do is run something like strings (under UNIX-like operating systems) on the executable to extract anything that looks like an option.
That won't tell you how to use a particular option but, if your strings command returns:
--option1
--option2
--run-faster
--use-less-cpu
--format-hard-disk
it's a pretty safe bet that those are valid options. Shorter options may not show up so easily since strings tends to be for obviously textual data.
Even if you don't have something like strings, there's a good chance all the options will be lumped together in the executable just because of the way many compilers and linkers work.
And, as Eugeny Loy kindly points out in a comment, the sysinternals suite from Microsoft has a strings utility as well.
By the way, I'd give serious pause before trying to test if --format-hard-disk is a valid option :-)
I need something (like annotations, reflections, defines, or something completely different) that I can add to a arbitrary function or function call.
For every function f, which has this something added, a specific function t should be invoked with the parameters of f.
The function t should now send its parameters over the network to a other program.
Is there a way to do something like this?
The general principle behind this is called marshalling, where the parameteres of a function are wrapped up in a way that you can send them to some other computer. The sender marshalls the parameters, the receiver unmarshalls. Both need to have an understanding on the types, and must do it in a way consistent with the different computer architectures.
Remote procedure calls (RPC) are one way of sending function calls from one computer to another, and need some marshalling behind them.
XMLRPC, as pointed out by Victor, is one way to do it, where the marshalling happens via XML. There are lots of other packages, and googling for RPCs and marshalling should give more possibilities, but XMLRPC might be just what you want.
CORBA and DCOM are related mechanism. The idea of sending function calls between computers is one major concept in distributed systems, so maybe look a round a little more, probably there are very simple solutions to your specific problem.
XMLRPC library might be the one you're looking for, if you just want to call the function on the remote machine. It generates the code for marshalling the parameters using the XML RPC specs.
You can use Google Protocol Buffers for this: https://developers.google.com/protocol-buffers/docs/overview
It is an easy to use and portable serialisation library. In addition you will be able to write programs able to 'talk' to your C++ code (deserialize objects serialised by your C++ code) in different languages, like Python, Java, and others, which can be very useful, for example for easier testing.
If you are in a Linux/BSD environment, do 'man rpcgen'. I found it easier to build distributed apps with than DCE/CORBA.
Let's give what you are trying to do a name, 'inter-process function call' or IFC.
I have been working on a IFC compiler (ifcc) for generating scalable cloud apps with realtime browser based visibility built into the apps.
The prototype compiler is working. The visibility portion of the framework is also working but not yet integrated into the compiler for generating instrumented code.
Ifcc takes as its input a C include file and based on the function prototype declarations in the .h file, it generates C source code for marshalling, and, client and server proxy/stubs suitable for use in a heterogenous (takes care of byte ordering/big endian/little endian) environment.
And, Oh, by the way, ifcc is a smart compiler. It not only handles arrays, typedefs, nested structures, etc. but it also does arbitrary pointer chasing. E.g. if you call a function with a pointer to doubly link list, it will package it up, send it and recreate the doubly link list at the receiving end.
If people are interested in playing with it, add a comment with output of 'uname -a' of your system as well as which compiler you are using. If there is lots of interest I may make it available for developers to learn/play/experiment with.
What packages do you use to handle command line options, settings and config files?
I'm looking for something that reads user-defined options from the command line and/or from config files.
The options (settings) should be dividable into different groups, so that I can pass different (subsets of) options to different objects in my code.
I know of boost::program_options, but I can't quite get used to the API. Are there light-weight alternatives?
(BTW, do you ever use a global options object in your code that can be read from anywhere? Or would you consider that evil?)
At Google, we use gflags. It doesn't do configuration files, but for flags, it's a lot less painful than using getopt.
#include <gflags/gflags.h>
DEFINE_string(server, "foo", "What server to connect to");
int main(int argc, char* argv[]) {
google::ParseCommandLineFlags(&argc, &argv, true);
if (!server.empty()) {
Connect(server);
}
}
You put the DEFINE_foo at the top of the file that needs to know the value of the flag. If other files also need to know the value, you use DECLARE_foo in them. There's also pretty good support for testing, so unit tests can set different flags independently.
For command lines and C++, I've been a fan of TCLAP: Templatized Command Line Argument Parser.
http://sourceforge.net/projects/tclap/
Well, you're not going to like my answer. I use boost::program_options. The interface takes some getting used to, but once you have it down, it's amazing. Just make sure to do boatloads of unit testing, because if you get the syntax wrong you will get runtime errors.
And, yes, I store them in a singleton object (read-only). I don't think it's evil in that case. It's one of the few cases I can think of where a singleton is acceptable.
If Boost is overkill for you, GNU Gengetopt is probably, too, but IMHO, it's a fun tool to mess around with.
And, I try to stay away from global options objects, I prefer to have each class read its own config. Besides the whole "Globals are evil" philosophy, it tends to end up becoming an ever-growing mess to have all of your configuration in one place, and also it's harder to tell what configuration variables are being used where. If you keep the configuration closer to where it's being used, it's more obvious what each one is for, and easier to keep clean.
(As to what I use, personally, for everything recently it's been a proprietary command line parsing library that somebody else at my company wrote, but that doesn't help you much, unfortunately)
I've been using TCLAP for a year or two now, but randomly I stumbled across ezOptionParser. ezOptionParser doesn't suffer from "it shouldn't have to be this complex"-syndrome the same way that other option parsers do.
I'm pretty impressed so far and I'll likely be using it going forward, specifically because it supports config files. TCLAP is a more sophisticated library, but the simplicity and extra features from ezOptionParser is very compelling.
Other perks from its website include (as of 0.2.0):
Pretty printing of parsed inputs for debugging.
Auto usage message creation in three layouts (aligned, interleaved or staggered).
Single header file implementation.
Dependent only on STL.
Arbitrary short and long option names (dash '-' or plus '+' prefixes not required).
Arbitrary argument list delimiters.
Multiple flag instances allowed.
Validation of required options, number of expected arguments per flag, datatype ranges, user defined ranges, membership in lists and case for string lists.
Validation criteria definable by strings or constants.
Multiple file import with comments.
Exports to file, either set options or all options including defaults when available.
Option parse index for order dependent contexts.
GNU getopt is pretty nice. If you want a C++ feel, consider getoptpp which is a wrapper around the native getopt.
As far as configuration file is concerned, you should try to make it as stupid as possible so that parsing is easy. If you are bit considerate, you might want to use yaac&lex but that would be really a big bucks for small apps.
I also would like to suggest that you should support both config files and command line options in your application. Config files are better for those options which are to be changed less frequently. Command-line options are good when you want to pass the immediate changing arguments (typically when you are creating a app, which would be called by some other program.)
If you are working with Visual Studio 2005 on x86 and x64 Windows there is some good Command Line Parsing utilities in the SimpleLibPlus library. I have used it and found it very useful.
Not sure about command line argument parsing. I have not needed very rich capabilities in that area and have generally rolled my own to save adding more dependencies to my software. Depending upon what your needs are you may or may not want to try this route. The C++ programs I have written are generally not invoked from the command line.
On the other hand, for a config file you really can't beat an XML based format. It's readable, extensible, structured, etc... :) Plus there are lots of XML parsers out there. Despite the fact it is a C library, I tend to use libxml2 from xmlsoft.org.
Try Apache Ant. Its primary usage is Java projects, but there isn't anything Java about it, and its usable for almost anything.
Usage is fairly simple and you've got a lot of community support too. It's really good at doing things the way you're asking.
As for global options in code, I think they're quite necessary and useful. Don't misuse them, though.