This may seem strange, so I will try to explain it as best I can:
I want to write an application for OS X that will accept some code as an input and will produce a visual output. The input will be in Objective C and the output will be the output that this code describes.
The output may be text or graphics based, it doesn't matter. What matters is that I don't know how can I make this input be handled as Objective C code and be executed by the system as such. I have a big experience with Objective C, but I hadn't had the chance to get involved with something like this.
Can anyone point me in the right direction?
So if I understand correctly, you want to:
Take Objective-C input
Parse it
And show its structure to the user in a visually digestible form.
Now the hard part is parsing it - for that you'll need a compiler front-end, possibly LLVM-clang. When you have an abstract syntax tree of the code, you can walk that tree and easily construct some graphics or structured, human-readable text to describe what the code does.
Edit: so you want to actually compile and execute that code. Then you have to go one step further and compile the code then run it.
Related
I was wondering if there were a way to compute the size of a reg in Verilog. I researched it quite a bit, and found $size(a), but it's only in SystemVerilog, and it won't work in my verilog program.
Does anyone know an alternative for this??
I also wanted to ask as a side note; I'm having some trouble with my test bench in the sense that when I update a value in the file, that change is not taken in consideration when I simulate. I've been told I might have been using an old test bench but the one I am continuously simulating is the only one available in this project.
EDIT:
To give you an idea of what's the problem: in my code there is a "start" signal and when it is set to 1, the operation starts. Otherwise, it stays idle. I began writing the test bench with start=0, tested it and simulated it, then edited the test bench by setting start to 1. But when I simulate it, the start signal remains 0 in the waveform. I tried to check whether I was using another test bench, but it is the only test bench I am using in this project.
Given that I was on a deadline, I worked on the code so that it would adapt to the "frozen" test bench. I am getting now all the results I want, but I wanted to test some other features of my code, so I created a new project and copy pasted the code in new files (including the same test bench). But when I ran a simulation, the waveform displayed wrong results (even though I was using the exact same code in all modules and test bench). Any idea why?
Any help would be appreciated :)
There is a standardised way to do this, but it requires you to use the VPI, which I don't think you get on Modelsim's student edition. In short, you have to write C code, and dynamically link it to the simulator. In the C code, you can get object properties using routines such as vpi_get. Useful properites might be vpiSize, which is what you want, vpiLeftRange, vpiRightRange, and so on.
Having said all that, Verilog is essentially a static language, and objects have to be declared with a static width using constant expressions. Having a run-time method to determine an object's size is therefore of pretty limited value (since you should already know it), and may not solve whatever problem you actually have. Your question would make more sense for VHDL (and SystemVerilog?), which are much more dynamic.
Note on Icarus: the developers have pushed lots of SystemVerilog stuff back into the main language. If you take advantge of this you may find that your code is not portable.
Second part of your question: you need to be specific on what your problem actually is.
I've been using go for a bigger project and love it, and for my testing i've been using the
func ExampleXxx {
... code ...
//Output:
//...expected output ...
}
method for testing. When it fails it will say
got:
... bunch of lines showing the output of test ...
want:
... the comment you put in to show what you expected ...
is there any way to make it show just the difference? I can take the two and copy to separate files and run a diff etc, but I'd much rather just have it show the parts that were wrong as some of my tests have longer output.
Thanks in advance
EDIT:
I'm using http://golang.org/pkg/testing/#hdr-Examples and want the output to show a diff not the current output. I know I can do the diff manually.
No, you cannot do this. This is not the intended use of Examples.
Examples are a nice way to show how some function will behave: Examples exists to document. The main reason for validating the example output is to make sure the Examples are valid/correct, not that your code is okay. For the later you have Test functions
Most often the output of an Example displays input and output (or just output) of one invocation of a certain function/method per line; sometimes Examples use the different lines to show parts of a complex result, e.g. one line per element of the returned slice.
I think your use of Examples to "verify the flow of my program" contradicts the intention of Examples. I would use Test functions and use any of the available diff tools to generate a got, want, diff output myself if I'd like to test e.g. a text processor on large bunches of input.
If I understand your question correctly, it sounds like GoConvey would do the trick... It's a TDD tool that runs in the browser, and it will show you colored diffs for most failures:
You can use it with your existing tests; if you don't want to convert to the GoConvey DSL, that's okay. You don't have to be using a TDD workflow per-se in order for it to work, but if you can run go test, this tool should be able to pick it up. (I've never used the Example functions for testing... I'm not sure what you mean by that, honestly.)
(There's a new web UI in the works that will still show the diff. See below.)
These are contrived examples, but obviously the diff is more useful with longer output.
Is that kind of what you're looking for?
From the style guide: https://code.google.com/p/go-wiki/wiki/Style#Useful_Test_Failures
if got != tt.want {
t.Errorf("Foo(%q) = %d; want %d", tt.in, got, tt.want) // or Fatalf, if test can't test anything more past this point
}
This will put out only errors of course. There is nothing built into go that lets you show the diff. I think just piping this to whatever diff tool you are using against your last output would still be best.
Go is great, but no reason to re-invent tools that already do fantastic jobs that already exists at the terminal.
Our current testing is a simple in-house tool which runs the named target, logs its output and compares it with a expected output. The expected output and real output are both text files.
This has an obvious downside, if some changes of line number change which has no function effect is regarded as failure.
We are thinking to use tools like expect to do this, but we like to know if there are some other alternatives. Googling does not return any immediate answers.
Our platform is linux; the users of this tool does not need to write testing code, basically they currently just provide a plain text file of expected result and we should not ask them to write code or some complex form.
Thanks for your inputs.
I searched the internet but did not find a concrete answer that why decompilers are unable to produce original source code. I dint get a satisfactory answer. Somewhere it was written that it is similar to halting problem but dint tell how. So what is the theoretical and technical limitation of creating a decompiler which is perfect.
It is, quite simply, a many-to-one problem. For example, in C:
b++;
and
b+=1;
and
b = b + 1;
may all get compiled to the same set of operations once the compiler and optimizer are done. It reorders things, drops in-effective operations, and rewrites entire sections of code. By the time it is done, it has no idea what you wrote, just a pretty good idea what you intended to happen, at a raw-CPU (or vCPU) level.
It is even smart enough to remove variables that aren't needed:
{
a=5;
b=func();
c=a+b;
d=func2(c);
}
## gets rewritten as:
REGISTERA=func()
REGISTERA+=5
return(func2(REGISTERA))
For starters, the variable names are never preserved when your program is compiled. ...so the best it could possibly do would be to use meaningless variable names throughout your re-constituted program. Compiling is generally a one-way transformation - like a one-way hashing function. Like the hash, it may be possible to generate something else that could hash to the same value, but it's highly unlikely the decompiled program will be the exact same as your original.
Compilers throw out information; not all the information that is in the source code is in the compiled code. For example in compiled Java, you can't tell the difference between a parameterized and unparameterized generic type because the information is only used by the compiler; some annotations are only used at compile time and are not included in the compiled output. That doesn't mean you couldn't get some sort of source code by decompiling; it just wouldn't match nor would be as informative as the actual source code.
There is usually not a 1-to-1 correspondence between source code and compiled code. If an essentially infinite number of possible sources could result in the same object code (given unbounded variable name lengths, etc.), how is a decompiler to guess which one to spit out?
The idea is that given a specific input to the program, somehow I want to automatically step-in through the complete program and dump its control flow along with all the data being used like classes and their variables. Is their a straightforward way to do this? Or can this be done by some scripting over gdb or does it require modification in gdb?
Ok the reason for this question is because of an idea regarding a debugging tool. What it does is this. Given two different inputs to a program, one causing an incorrect output and the other a correct one, it will tell what part of the control flow differ for them.
So What I think will be needed is a complete dump of these 2 control flows going into a diff engine. And if the two inputs are following similar control flows then their diff would (in many cases) give a good idea about why the bug exist.
This can be made into a very engaging tool with many features build on top of this.
Tell us a little more about the environment. dtrace, for example, will do a marvelous job of this in Solaris or Leopard. gprof is another possibility.
A bumpo version of this could be done with yes(1), or expect(1).
If you want to get fancy, GDB can be scripted with Python in some versions.
What you are describing sounds a bit like gdb's "tracepoint debugging".
See gdb's internal help "help tracepoint". You can also see a whitepaper
here: http://sourceware.org/gdb/talks/esc-west-1999/
Unfortunately, this functionality is not currently implemented for
native debugging, but I believe that CodeSourcery is doing some work
on it.
Check this out, unlike Coverity, Fenris is free and widly used..
How to print the next N executed lines automatically in GDB?