-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Command line tools for building and deploying packages #391
Open
akbertram
wants to merge
62
commits into
master
Choose a base branch
from
wip-tooling
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Use common packager module that is also used by maven * Implement dependency resolution for package dependencies
* Record assumptions we make about the runtime state * If subsequent executions satistify those assumptions, reuse the compiled loop body
Interestingly, it's not even neccessary to add our own compiler specialization for the case of x^-1. We can achieve the same effect by adding a branch to the Ops.pow() function, which will be inlined by the JVM, and, if the exponent is constant, work its way into the machine code.
We want more freedom to be able to use different strategies for storing SEXPs on the stack. For example, for atomic vectors of known type with constant attributes, we can store them as primitive arrays. To make this possible, we use a similar pattern to GExpr in gcc-bridge, so that each type of storage is responsible for converting to another kind.
* Use liveness analysis to determine which arrays/SEXPs can be safely mutated in place to safely avoid duplicating the vector * Improve subset/replace value inference in order to delegate to specialized operators
This step actually turns out to be essental, as we otherwise can end up with phi-statements that rely on uninitialized values and cause the byte-code validation to fail.
When compiling a loop body or other SEXP, changes to local variables may still be visible in the environment after the compiled code terminates. For example: s <- 0 for(i in 1:1000) { s <- s + i } print(s) If we compile only the `for` expression, then the value of s must be updated in the enclosing Environment instance so that it is visible when print(s) is evaluated. We had been updating all local variables at each exit path, but this actually doesn't work for more complex control flows. For example: for(i in 1:1000) { for(j in seq_along(x)) { s <- s + 1 } } If the value of x is not known at compile time, then it is possible that x has a length of zero and the inner loop never executes. In this case, the values of s and j should *not* be updated in the enclosing environment (nor _could_ we, as they have no value) What we can do is insert UpdateEnv() statements by doing a depth-first search of the Reverse Dominance Tree.
The command line builder will now look for an extra 'Dependencies' field in the DESCRIPTION file, which should contain fully qualified package names, such as 'org.renjin:readxl' or 'com.acme:mypackage'
When building, packages will include a pointer at META-INF/org.renjin.package/{packageName} that allows the ClasspathPackageLoader to lookup packages on the classpath by its unqualified name. This also delegates resolution of unqualified package names to the PackageLoader implementation. This allows the AetherPackageLoader to query packages.renjin.org so that we don't have to cycle through org.renjin.cran, org.renjin.bioconductor group ids. This does withdraw support for loading packages in the format '{groupId}.{packageName}', which is ambiguous: only {groupId}:{packageName} will be accepted.
lapply() actually can be described to have non-standard evaluation of arguments as it relies on match.fun(). This is a first step towards compiling lapply() calls.
Argument need only be provided to the Specializer interface, they shouldn't have to be matched again when calling Specialization.getCompiledExpr().
* Improved new sapply() implementation * Moved as.vector() to R code so the compiler can better infer types/attributes * Moved tests in Java related to as.vector and types to R code * Retain original SEXP of arguments so that we can implement substitute() at compile time
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.