I'm trying to instrument byte code by converting it to jimple, adding code lines to jimple and compiling the jimple back to byte code. The problem is that I can't compile the jimple code back to byte code at all, is it possible?
What is the problem you are facing? Normally Soot automatically outputs the corresponding .class files.
Related
I have some third party application that I have to use, it generates UTF16LE encoded json files.
When I put these manually on my server and try haxe generated php to parse these files, it refuses. It seems it can't detect and convert to the encoding haxe php accepts.
I don't know where to start. Converting it on the client is an impossibility, there are too many of such files and need too frequently be parsed. So I have to use php. It would be nice if haxe has a way to convert it to the encoding it accepts. I have tried RTFM, but I so far I havent found anything that says haxe can convert it. Before I start reinventing some second wheel, I rather make sure there isn't some obvious way to it with haxe.
I am using Haxe version 4.2.1+bf9ff69
What am I overlooking? Is haxe php able to solve this, or is going native php the only option?
== SOLVED ==
As these json files do not need any emoticon support or whatever characters for non-english language, my solution was to strip everything except basic printable ASCII characters.
import sys.io.File;
import php.Syntax;
// some function body
return Syntax.code('preg_replace( "/[^[:print:]]/", "",{0})',File.getContent(_path));
I couldn't share these file on the web, because of privacy concerns. Also I discovered these files had ... wait for it - double BOM's- hacked into it.The BOM detector I threw in reported the first BOM it found happening to be UTF16LE.
Enterprise spaghetti monster probably the reason. Thought I had seen it all, but with that, one probably can't never have seen it all. The wonders of human ingenuity.
Just a blunt strip instead of making my own ludicrous code to unfudge that stuff and justice served. Hurrah.
I have observed that the domain class compile output file(.class file) keep changing without modification to the source file(.groovy) in grails.
see:https://github.com/grails/grails-core/issues/10868 .
And grails domain class compiled output file keep changing without modification .
I doubt it's something related to groovy AST injecting.
I have tested normal groovy class(without any AST), the compiled byte code is identical every time. Anyone can explain this symptom？
I am trying to write source code in one language and have it converted to both native c++ and JS source. Ideally the converted source should be human readable and resemble the original source as best it can. I was hoping haxe could solve this problem for me. So I code in haxescript and have it convert it to its corresponding C++ and JS source. However the examples I'm finding of haxe seems to create the final application for you. So with C++ it will use msbuild (or whatever compiler it finds) and creates the final exe for you from generated C++ code. Does haxe also create the c++ and JS source code for you to view or is it all done internally to haxe and not accessible? If it is accessible then is it possible to remove the building side of haxe so it simply creates the source code and stops?
Thanks
When you generate CPP all the intermediate files are generated and kept wherever you decide to generate your output (the path given using -cpp pathToOutput). The fact that you get an executable is probably because you are using the -main switch. That implies an entry point to your application but that is not really required and you can just pass to the command line a bunch of types that you want to have built in your output.
For JS it is very similar, a single JS file is generated and it only has an entry point if you used -main.
Regarding the other topic, does your Haxe code resembles the generated code the answer is yes, but ... some of the types (like Enum and Abstract) only exist in Haxe so they will generate code that functionally works but it might look quite different. Also Haxe has an always-on optimizer/analyzer that might mungle your code in unexpected ways (the analyzer can be disabled). I still find that it is not that difficult to figure out the Haxe source from the generated code. JS has support for source mapping which is really useful for debugging. So in the end, Haxe doesn't do anything to obfuscate your generated code but also doesn't do much to try to preserve it too strictly.
Sorry about the short title, but I honestly can't get a better description of what is happening because I don't know enough...
Some background first, I am "converting" a multi-byte application to support unicode and I've made the standard char/string wchar_t/wstring changes and the my code is building without problems.
What happens is that when the application is being initialized it hits an assert when it registers the applications's document templates. The code is the standard
CMultiDocTemplate* pRepDocTemplate = NULL;
pRepDocTemplate = new CMultiDocTemplate(IDR_DIAGNOSTIC_REPORT_TYPE,
RUNTIME_CLASS(CDiagnosticReportDoc),
RUNTIME_CLASS(CChildFrame), // custom MDI child frame
RUNTIME_CLASS(CDiagnosticReportView));
and CDiagnosticsReportView has the standard DECLARE_DYNCREATE and IMPLEMENT_DYNCREATE in the header and source.
The assert is at doctmpl.cpp line 29 (mfc120ud.dll - at least is using the correct dll), but I can't find the source code anywhere to actually know what is happening.
The inheritance tree is pretty straightforward:
CDiagnosticReportView
\->CReportViewBase
\->CXTPReportView
\->CView
CXTPReportView is part of a framework that we are using which is provided by Codejock (Codejock extreme toolkitPro). From the build pane I know that it's linking against it's unicode debug dll (ToolkitPro1631vc120UD.dll)
Suffice to say that in the multibyte configuration this problem doesn't occur.
The project is configured to use the UNICODE character set (Project properties->Configuration Properties->General->Character Set).
Any help would be appreciated!
Thanks in advance!
It all had to do with the fact that I was linking against the non UNICODE build of Codejock. Even though I saw a reference to the UNICODE dll, the lib wasn't the correct one!
Problem was solved when I opened my eyes ;)
I am attempting to install my own GroovyResourceLoader and was wondering if there was an authorative guide somewhere describing all hte moving bits.
Ive noticed when groovy attempts to compile a script, it does attempt to find types by sending paths to the GRL. However it does some strange things sometimes it uses '$' as a separator and other times it uses plain old '.'.
Heres a snapshot of some logging of an attempt to load something. Ignoring the auto import stuff, notice how it using '$' as the package separator and then by replacing each '$' it one at a time with a '.'.
-->a$b$groovy$X$Something
-->a.b$groovy$X$Something
-->a.b.groovy$X$Something
Im using Groovy 1.8.0.
The "$" you see come from Groovy trying to match inner classes. I strongly assume you have somewhere an "a.b.groovy.X.Something" which will lead groovy to try to discover all kinds of inner class combinations for this one. You could for example have a "a$b$groovy$X$Something.groovy" file.