Is there an open source TCL script generator for NS2? There is NAM that comes with NS2. Is there anything else. A web based one would be great!
NSG is a good TCL code generator that is free. Check out
https://sites.google.com/site/pengjungwu/nsg
You may also want to check out mannasim
http://www.mannasim.dcc.ufmg.br/
A general Tcl script generator? That's quite tricky, as Tcl's really a general programming language. But if you're interested in just generating simple programs, it's not that hard. A Tcl command is a sequence of words separated by spaces and terminated by a newline character. Where you've got characters that are Tcl's metacharacters, you can quote them by putting a backslash in front (except for newline; replace that with \n instead). Anything more complicated than a simple call can probably be relegated to a procedure, but I doubt you need anything particularly complex for NS2 scripts.
If you want something pre-written, there's NSG but I don't know very much about it. It's Java, not web-based.
This operation system is user-friendly to criation of the TCL scripts.
There also several tools includes him. Mannasim, Castalia, OMNET++...
Look: http://sourceforge.net/projects/liowsn/
Related
I would like to intercept the behavior of read to give some control over the interning of symbols. I might, for example, wish for read to throw an error if a previously uninterned symbol shows up in the input stream. Or perhaps I want to limit the packages in which new symbols can be interned.
Is there a way to hook the interning process without rewriting the reader from scratch?
I am ok with alternate reader implementations. Using read itself is not a must.
You can't do this with the reader defined by the standard without jumping through huge hoops: you'd have to implement the process of accumulating and parsing tokens (including all the number parsing stuff) and then provide suitable ways of intervening. The standard tells you enough that you should be able to do that, but it's a lot of work: I suspect that most of any reader implementation is that stuff.
Of course specific implementations might provide convenient points at which you can intervene.
The other approach would be to use a portable, extensible reader. There is at least one thing which may be such a thing: Eclector, and there may well be others. I don't know anything about it, unfortunately.
How are we actually supposed to include our OpenCL code in our C projects?
We can't possibly be supposed to ship our .cl files along with our executable for the executable to find them and load them at runtime, because that's stupid, right?
We can't be supposed to use some stringify macro because a) that's apparently not portable/leads to undefined behaviour and b) it all breaks down if you use commas not enclosed in brackets like when defining many variables of the same type, I've spent an hour here looking for a solution to that and there doesn't seem to be one that actually works and c) that's kind of stupid.
Are we expected to write our code into C string literals like "int x, y;\n" "float4 p;\n"? Because I'm not doing that. Are we supposed to do a C include-style hexdump of our .cl files? That seems inconvenient. What are we actually supposed to do?
It's bad enough that all these approaches basically mean that you have to ship your program with your OpenCL code essentially open sourced when your OpenCL code is probably the last thing you want open sourced, on top of it it seems every OpenCL project I've seen uses one of the approaches listed above, it just doesn't seem right at all, it's like the people who made OpenCL forgot about something.
This thread: OpenCL bytecode running on another card mentions SPIR, a "platform-portable intermediate representation for OpenCL device programs". Other than that, you are basically restrained to the options you already mentioned.
Personally, I began to use C++11 raw string literals to get rid of my nasty stringify-macros. Don't know if C++ is an option for you, however.
Concerning your rejection of the "ship our .cl files along with our executable" approach: I don't see why this is inherently stupid -- the CL "shaders" are an application resource like all other separate files beside the executable, and thus are part of the "application bundle". It's perfectly reasonable to have such kind of files, and each operating system has its way to deal with it (in win32, the program directory is the bundle https://blogs.msdn.microsoft.com/oldnewthing/20110620-00/?p=10393 , OSX has its own bundle concept, etc...).
Now, if you are worried about other people peeking into your OpenCL code, you can still apply some obfuscation methods (e.g. encrypt your .cl-files by a key which is more or less cleverly hidden in your executable).
[edit/sidenote]: We could also investigate how other companies deal with this issue in the context of, for example, OpenGL/Direct3D shaders. In my limited experience, gaming companies tend to dump their shaders in text form somewhere in their application directory, for all to see (and even to tamper with). So in the gaming world at least, there is no great deal of secrecy in that respect... Wonder what adobe or CAD software companies do in their professional software.
I don't like reinventing the wheel and this seemed like a pretty basic function. The same concept as these two questions except specifically for QStrings? QRegExp has an escape function so I'm wondering if I've just overlooked the QString version or whether there's a good reason there isn't one.
I doubt there would be such a function built into Qt, as it's really unlikely to be a frequently-required thing to do with QStrings. (Or at least, I can't think of any plausible usage that it would be worth the Qt maintainers supporting.)
QRegExp::escape() is a bit different, as it's doing a specific task of escaping characters that are known to have special meaning in regular expressions. Qt provides a method for this because it is a normal and common thing to need to do with regular expressions.
So, I think your best bet is going to be to take one of the example snippets of code that you linked to in the question, and roll your own function.
I have a linux console application - a scientific simulation program that I use. It opens up a TCL shell that you then issue commands to. Normally what I do is pre-write all my test vectors and look at the output by manually inputting the data, but now I'd like to move on to something more complicated: incorporating external feedback.
My idea is, I'll have a external simulation running that takes the output of the simulator and then generates new test vectors on the fly to feed back into the simulation. I'm kind of hazy on the on the details of how to implement this. I am semi-familiar with C and with Python.
I guess, getting into specifics - how do I hook into the program's terminal I/O? I'd prefer to use Python if possible. Are there any references I can read to get up to speed on this?
Your idea is quite reasonable. Python supports this very well: Sub-process launching, and inter-process communication. Documentation like the following might be helpful:
http://docs.python.org/library/subprocess.html
In short, you're going to "read from" child-process stdout (and maybe stderr), and "write to" child-process stdin. You can have your interactive console like you describe, or read from/write to text files, and even "hook-together" processes to talk (like piping "mycommand | mycommand2").
For Python, there are many strong examples (like the "scons" build system written in Python that does this a lot). Further, the Qt's QProcess class makes this pretty easy, and there are a few really good Python wrappers available like "PySide", "PyQt", and "PythonQt" (probably others).
Let's say you have a function foo() compiled into a program that is running on Unix.
While the program is running, can one "replace" the function foo by dynamically loading an object file containining a modified version of foo()?
On an embedded system I worked on in the past, we could unprotect the text segment and then essentially "patch" the address of foo() to point to the newly modified foo().
It was used for debugging on occasion and with lots of special constraints, on customer sites.
Is this possible on Unix?
It depends on the environment, I suppose. I know that hot-swapping production code is trivial in Erlang modules and not too difficult in Ruby. C might be a different animal.
Yes. That's how debuggers like gdb work, after all.
The short of it is yes, of course it's possible. The question should really be, "how difficult?"
You can load & unload shared libraries (.so & .DLL) all you want on Linux & Windows. Specific variants of UNIX, I'm not sure about. This would be the easiest way to achieve your goal.
If you don't mind getting your hands dirty, you can always patch up the code segment to jump to someplace else out on the heap. I don't recommend it.