I have implemented a Rascal function that receives a CompilationUnit, performs some Java transformations, and then returns the resulting CompilationUnit (from lang::java::m3::AST). Is there any library function to pretty print a Java CompilationUnit back to a Java source file?
(There is a more or less related question)
Related
Unlike inclusion of global.jsp with every component jsp in CQ5, sightly does not include any such dependency. How does it actually access all the global objects. What is the backend process of it. And how sightly code compiles to java??
how sightly code compiles to java?
Sling sightly API has two bundles to support this, the first step is to compile sightly into Abstract Syntax Tree (The Abstract Syntax Tree maps plain Java source code in a tree form. This tree is more convenient and reliable to analyse and modify programmatically than text-based source.) This is done by Apache Sling Scripting Sightly Compiler
Next is to convert (transpile) the Abstract Syntax Tree into java source code. This is achieved in bundle Java Compiler
How does it actually access all the global objects.
To understand this you need to understand how script resolution occurs in Sling and how are resource resolved to scripts which is core to Sling Scripting engine. To understand basics of ScriptEngine look at java docs here, implementation of this is SightlyScriptEngine
The way script resolution works is that the resource is adapted to DefaultSlingScript , this is done by SlingScriptAdapterFactory.
SlingScriptAdapterFactory has references to BindingsValuesProvider which is passed to the DefaultSlingScript. One of the implementation of BindingsValuesProvider is AEMSightlyBindingsValuesProvider (you can see this as a service in /system/console/services) which provides the default objects.
The DefaultSlingScript then responsible for invoking SightlyScriptEngine and calling its method eval which populates the default objects in binding and then setting this binding as request attribute.
I'm going through the EUnit chapter in Learn You Some Erlang and one thing I am noticing from all the code samples is the test functions are never declared in -export() clauses.
Why is EUnit able to pick these test functions up?
From the documentation:
The simplest way to use EUnit in an Erlang module is to add the following line at the beginning of the module (after the -module declaration, but before any function definitions):
-include_lib("eunit/include/eunit.hrl").
This will have the following effect:
Creates an exported function test() (unless testing is turned off, and the module does not already contain a test() function), that can be used to run all the unit tests defined in the module
Causes all functions whose names match ..._test() or ..._test_() to be automatically exported from the module (unless testing is turned off, or the EUNIT_NOAUTO macro is defined)
Glad I found this question because it gives me a meaningful way to procrastinate and I was wondering how functions get created and exported dynamically.
Started by looking at the latest commit affecting EUnit in the Erlang/OTP Github repo, which is 4273cbd. (The only reason for this was to find a relatively stable anchor instead of git branches.)
0. Include EUnit's header file
According EUnit's User's Guide, the first step is to -include_lib("eunit/include/eunit.hrl"). in the tested module, so I assume this is where the magic happens.
1. otp/lib/eunit/include/eunit.hrl (lines 79 - 91)
%% Parse transforms for automatic exporting/stripping of test functions.
%% (Note that although automatic stripping is convenient, it will make
%% the code dependent on this header file and the eunit_striptests
%% module for compilation, even when testing is switched off! Using
%% -ifdef(EUNIT) around all test code makes the program more portable.)
-ifndef(EUNIT_NOAUTO).
-ifndef(NOTEST).
-compile({parse_transform, eunit_autoexport}).
-else.
-compile({parse_transform, eunit_striptests}).
-endif.
-endif.
1.1 What does -compile({parse_transform, eunit_autoexport}). mean?
From the Erlang Reference Manual's Module chapter (Pre-Defined Module Attributes):
-compile(Options).
Compiler options. Options is a single option or a list of options. This attribute is added to the option list when
compiling the module. See the compile(3) manual page in Compiler.
On to compile(3):
{parse_transform,Module}
Causes the parse transformation function
Module:parse_transform/2 to be applied to the parsed code before the
code is checked for errors.
From the erl_id_trans module:
This module performs an identity parse transformation of Erlang code.
It is included as an example for users who wants to write their own
parse transformers. If option {parse_transform,Module} is passed to
the compiler, a user-written function parse_transform/2 is called by
the compiler before the code is checked for errors.
Basically, if module M includes the {parse_transform, Module} compile option, then all of M's functions and attributes can be iterated through using your implementation of Module:parse_transform/2. Its first argument is Forms, which is M's module declaration described in Erlang's abstract format (described in Erlang Run-Time System Application (ERTS) User's Guide.
2. otp/lib/eunit/src/eunit_autoexport.erl
This module only exports parse_transfrom/2 to satisfy {parse_transform, Module} compile option and its first order of business is to figure out what are the configured suffixes for test case functions and generators. If not set manually, using _test and _test_ respectively (via lib/eunit/src/eunit_internal.hrl).
It then scans all the functions and attributes of your module using eunit_autoexport:form/5, and builds a list of to be exported functions where the suffixes above match (plus the original functions. I may be wrong on this one...).
Finally, eunit_autoexport:rewrite/2 builds a module declaration from the original Forms (given to eunit_autoexport:parse_transform/2 as the first argument) and the list of functions to be exported (that was supplied by form/5 above). On line 82 it injects the test/0 function mentioned in the EUnit documentation.
I am trying to learn a bit about Vala and wanted to create a Calculator to test how Gtk worked. The problem is that I coded everything around the supposition that there would be a way to parse a string that contained the required operations. Something like this:
string operation = "5+2/3*4"
I have done this with Python and it is as simple as using the compilers parser. I understand Python is math oriented, but I thought that perhaps there would be Vala library waiting for me as an answer... I haven't found it if it does exist, but as I was looking at the string documentation, I noticed this part:
/* Strings prefixed with '#' are string templates. They can evaluate
* embedded variables and expressions prefixed with '$'.
* Since Vala 0.7.8.
*/
string name = "Dave";
println (#"Good morning, $name!");
println (#"4 + 3 = $(4 + 3)");
So... I thought that maybe there was a way to make it work that way, maybe something like this:
stdout.printf(#"$(operation)")
I understand that this is not an accurate supposition as it will just substitute the variable and require a further step to actually evaluate it.
Right now the two main doubts I am having are: a) Is there a library function capable of doing this? and b) Is it possible to work out a solution using string templates?
Here's something I found that would do the work. I used the C++ libmatheval library, for this I first required a vapi file to bind it to Vala. Which I found here. There are a lot of available vapi files under the project named vala-extra-apis, and they are recognized in GNOME's Vala List of Bindings although they are not included at install.
You could parse the expression using libvala (which is part of the compiler).
The compiler creates a CodeContext and runs the Vala parser over a (or several) .vala file(s).
You could then create your own CodeVisitor decendant class that visits the necessary nodes of the parse tree and evaluates expressions.
As far as I can see there is no expression evaluator that does this, yet. That is because normally vala code is translated to C code and the C compiler then does compile time expression evaluation or the finished executable does the run time evaluation.
Python is different, because it is primarily a scripting language and has evaluation build directly into the runtime / interpreter.
Im looking for a DOM parser for the lua language that works similar to the great PPI parser for perl.
Basically i have a lot of lua scripts bound to specific entities - i want to evaluate some specific function calls within these scripts to show some generic information about a script (generate a report for example).
E.g.
function func1()
....
if(check(1,4))
end
end
In this case, i want the dom parser to find the function call check with a number of arguments.
I dont want to use regexp or similar tools, a DOM parser would be the best.
LuaInspect is what you want.
LuaInspect builds an AST (what you are calling a DOM) from Lua code, and can perform static analysis on it. It can generate an HTML report, and is also used to for code completion in some editors.
command.lua is LuaInspect's main file, which uses ast.lua to build the AST, etc.
Could anyone explain how to work WebSharper translator in conjunction with the F#?
Is it translate F# code to JS itself or using F# compiler for it?
In second case, what F# compiler are doing when finds [] attribute in source? Does compiler generate functions in any case and in runtime construct JS as reflection from compiled bytecode or there something other?
I develop WebSharper. Good question!
Roughly the compilation looks like this:
a.dll: a.fs b.fs c.fs
fsc ...
a.dll.js: a.dll
WebSharper.exe ..
When functions are annotated with [<JavaScript>], which is an alias for [<ReflectedDefinition>], the F# compiler does not only compile these functions to .NET IL, but also stores the representation of their syntax in the DLL metadata. This representation has type Quotations.Expr and can be recovered by reflection. Have a look at Quotations.DerivedPatterns.MethodWithReflectedDefinition.
WebSharper is therefore a source to source translator, and it is pretty direct (preserves lambdas, for example). In WebSharper 2.0 we have an intermediate Scheme-like language, but that is only there to help optimize the generated code.