I do the following cloning for all arrays defined in my source code.
For every array A, I create a copy A' and make all the basic blocks use A' and finally restore A' contents to A. This is perfectly possible writing a LLVM transformation pass using IRBuilder.CreateMemcpy
However, there is a scheduling problem when I register my custom pass with clang. Sometimes, it applies very late that causes A to marked read-only array and gives a run-time error when I do the restoration. If I schedule my pass very early [via EP_AsEarlyAsPossible], it screws up on loop info and other analysis that my custom pass depends on.
Can anyone help me resolve this scheduling issue?
Related
After upgrading to Vaadin 23.0.x (from former 22.0.2) I now keep getting the following error when opening a certain dialog:
2022-08-01 18:56:25,977 ERROR [http-nio-8085-exec-5] net.mmo.utils.kism.ui.views.nodes.NodeView: java.lang.IllegalStateException: All bindings created with forField must be completed before calling readBean
at com.vaadin.flow.data.binder.Binder.checkBindingsCompleted(Binder.java:3070)
at com.vaadin.flow.data.binder.Binder.readBean(Binder.java:2110)
at net.mmo.utils.kism.ui.views.nodes.NodeForm.readBean(NodeForm.java:487)
at net.mmo.utils.kism.ui.views.nodes.NodeForm.setNode(NodeForm.java:211)
This dialog has worked perfectly fine since I wrote it (using version 18.0.x about 2 years ago) and up to v22.0.2. I can't make sense of that error message and I don't understand what the issue could be here. I verified that issue going back and forth and the difference is really only the Vaadin version upgrade. Before it, the dialog works just fine and after it I get the above Exception when opening it.
I also can't quite believe what I think the message is stating here: if it would indeed check that I define or complete any bindings AFTER calling Binder.readBean() - how could it know that already in that very moment, i.e. when the code calls readBean() - as indicated by the stacktrace?
If there would indeed be any bindings being defined afterwards, IMHO it could only find that out AFTER said readBean()-call, i.e. when any additional bindings were actually defined, couldn't it?
So, could someone please try to "translate" or explain that issue or the background behind it to me?
The error basically states the problem: in the process of binding a field to a property (or getter/setter in general), the finishing step of actually binding was not undertaken. So the process was started with .forField() but never finished by .bind().
Since the error message as of now only states the fact, but not the culprit, a developer would be in need of a debugger to inspect the private state of the Binder, where the map incompleteBindings holds the current state of the Binder. The content of this map may help to find the culprit, e.g. by only holding one entry and by inspecting the flow of the program so far, that would conclude, what binding attempt failed. Or e.g. via the included field types.
Other than plain "bugs" by the developer, there are some potential reasons, why this suddenly happens by like an update or what places to look for:
multiple (re-)binding was recently added (e.g. to first bind "automatically" and then hand-tune the result); this holds potential, that older versions of the code just kept the initial binding and ignored the dangling second process.
the binding process uses a builder pattern; builder must build up on the result of the previous steps. This means, that in imperative code, there is the chance, that this chained call miss reassigning the build step. E.g.
var b = binder.forField(field)
if (predicate)
b.asRequired() // XXX: should be `b = b.asRequired()`
b.bind(...)
(this may or may not be a source for this kind of problem, but it's good to point out here, since the binder builder implementation actually switche(s|d) the builder (in the past)
In build definition (on Variables tab) I am trying to define a custom variable (Build.Repository.Clean) using simple expression $[not(false)]. But when I print variables during build -- regardless of expression used, Build.Repository.Clean value is always false.
Strangely enough, definining it with something like $(FullBuild) (where FullBuild is another custom variable) works just fine.
Am I missing something?
Notes:
using TFS 2018
Backstory:
Trying to set Build.Repository.Clean variable depending on a custom variable QuickBuild (which can be set by user when kicking off a build). Tried specifying $[not(variables.QuickBuild)] (and other variations of same expression) -- no luck.
here is how it works right now (but I'd rather have QuickBuild instead of FullBuild -- just can't figure out how to negate a variable):
Update 3:
Well, ignore if it changes clean operation during queue time. For what you are looking for, you could try this format:
Build.Repository.Clean=$[not(eq(variables.QuickBuild,'True'))]
If QuickBuild=True, Build.Repository.Clean=False,
If QuickBuild=False, then Build.Repository.Clean.Clean=True
For example:
I have set the clean option in Get Source Step, Clean=true
Build.Repository.Clean=$(FullBuild)
FullBuild=false
Now when I queue the build, then try to change the FullBuild=false during queue
time.
What you thought, the Build.Repository.Clean should change to False , then the clean operation will not be executed. But the truth is, the Build.Repository.Clean is still True and the clean is executed.
Even you do not update the value of FullBuild=false during the queue time, directly set the value FullBuild=false in build pipeline. This will also not use.
In the opposite, if you set Clean=false in Get Source Step. No matter what kind of value you input in FullBuild or Build.Repostiory.Clean during queue build.
It will not clean during the build pipeline.
Conclusion: It's not able to change the clean operation during queue time. This is not related any expression at all. Not matter what kind of value you set for Build.Repository.Clean.
Update 2
After go through your question and all comments once again. Seems your truly goal is assigning the clean options at queue-time based another customized variable.
Since you are not able to change Build.Repository.Clean during queue time. So you are trying to use this workaround. It's not support. There is not a way to assign the clean options at queue-time.
You may have to pre-define this variable in your build pipeline.
Also take a look at this question: How to clean build using self-hosted agent when queuing
In your scenario, you can create two build pipelines as an ugly workaround. One for incremental build (Disable the Clean option in get source step, or use variable Build.Repository.Clean = False), and another one enable the Clean option.
Hope it's clearly.
Expressions are not evaluated when they are used to initialize custom variables (on Variables tab). I.e. variable value ends up being a string with value equal to your expression (e.g. '$[not(<whatever>)]'). Later, when that variable gets used in context that expect boolean -- it still doesn't get evaluated, instead it gets type-casted and any non-empty string yields true.
On the other hand variable substitution happens -- i.e. value $(MyVar) gets replaced with value of MyVar.
Built-in variable seem to be special in sense that if you override them -- this process happens at the start and it's value gets immediately replaced with resulting value.
Note -- this may (or may not) be related to this.
Bottomline: you can't use expressions to override value of a built-in variable.
Let's say I have a rule like this.
foo(
name = "helloworld",
myarray = [
":bar",
"//path/to:qux",
],
)
In this case, myarray is static.
However, I want it to be given by cli, like
bazel run //:helloworld --myarray=":bar,//path/to:qux,:baz,:another"
How is this possible?
Thanks
To get exactly what you're asking for, Bazel would need to support LABEL_LIST in Starlark-defined command line flags, which are documented here:
https://docs.bazel.build/versions/2.1.0/skylark/lib/config.html
and here: https://docs.bazel.build/versions/2.1.0/skylark/config.html
Unfortunately that's not implemented at the moment.
If you don't actually need a list of labels (i.e., to create dependencies between targets), then maybe STRING_LIST will work for you.
If you do need a list of labels, and the different possible values are known, then you can use --define, config_setting(), and select():
https://docs.bazel.build/versions/2.1.0/configurable-attributes.html
The question is, what are you really after. Passing variable, array into the bazel build/run isn't really possible, well not as such and not (mostly) without (very likely unwanted) side effects. Aren't you perhaps really just looking into passing arguments directly to what is being run by the run? I.e. pass it to the executable itself, not bazel?
There are few ways you could sneak stuff in (you'd also in most cases need to come up with a syntax to pass data on CLI and unpack the array in a rule), but many come with relatively substantial price.
You can define your array in a bzl file and load it from where the rule uses it. You can then dump the bzl content rewriting your build/run configuration (also making it obvious, traceable) and load the bits from the rule (only affecting the rule loading and using the variable). E.g, BUILD file:
load(":myarray.bzl", "myarray")
foo(
name = "helloworld",
myarray = myarray,
],
)
And you can then call your build:
$ echo 'myarray=[":bar", "//path/to:qux", ":baz", ":another"]' > myarray.bzl
$ bazel run //:helloworld
Which you can of course put in a single wrapper script. If this really needs to be a bazel array, this one is probably the cleanest way to do that.
--workspace_status_command: you can collection information about your environment, add either or both of the resulting files (depending on whether the inputs are meant to invalidate the rule results or not, you could use volatile or stable status files) as a dependency of your rule and process the incoming file in the what is being executed by the rule (at which point one would wonder why not pass it to as its command line arguments directly). If using stable status file, also each other rule depending on it is invalidated by any change.
You can do similar thing by using --action_env. From within the executable/tool/script underpinning the rule, you can directly access defined environmental variable. However, this also means environment of each rule is affected (not just the one you're targeting); and again, why would it parse the information from environment and not accept arguments on the command line.
There is also --define, but you would not really get direct access it's value as much as you could select() a choice out of possible options.
What do these warnings mean when running our pipeline?
1497 [main] WARN com.google.cloud.dataflow.sdk.Pipeline - Transform
AsIterable2 does not have a stable unique name. In the future, this
will prevent reloading streaming pipelines
The warning in question indicates that the specified transform -- AsIterable2 -- isn't uniquely named. A likely cause of this is that there are two applications of an AsIterable transform at the top-level.
You can get rid of the warning by using the PTransform#setName method on the transform in question.
We attempt to infer names from the class names being applied. The only times it should be necessary to set an explicit name are:
When using an anonymous PTransform or DoFn.
When the same named transform is used multiple times within the same PTransform.
Specifically, requirement #2 means that if you use a named PTransform multiple times within an outer PTransform you need to make sure that each application has a different name. For instance:
input.apply(someTransform)
.apply(View.<TableRow>asIterable().withName("iterable1"));
input.apply(someOtherTransform)
.apply(View.<TableRow>asIterable().withName("iterable2"));
instead of:
View.AsIterable<TableRow> iterable = View.TableRow>asIterable().setName("aName");
input.apply(someTransform).apply(iterable);
input.apply(someOtherTransform).apply(iterable);
I'm using a closed-source application that loads Lua scripts and allows some customization through modifying these scripts. Unfortunately that application is not very good at generating useful log output (all I get is 'script failed') if something goes wrong in one of the Lua scripts.
I realize that dynamic languages are pretty much resistant to static code analysis in the way C++ code can be analyzed for example.
I was hoping though, there would be a tool that runs through a Lua script and e.g. warns about variables that have not been defined in the context of a particular script.
Essentially what I'm looking for is a tool that for a script:
local a
print b
would output:
warning: script.lua(1): local 'a' is not used'
warning: script.lua(2): 'b' may not be defined'
It can only really be warnings for most things but that would still be useful! Does such a tool exist? Or maybe a Lua IDE with a feature like that build in?
Thanks, Chris
Automated static code analysis for Lua is not an easy task in general. However, for a limited set of practical problems it is quite doable.
Quick googling for "lua lint" yields these two tools: lua-checker and Lua lint.
You may want to roll your own tool for your specific needs however.
Metalua is one of the most powerful tools for static Lua code analysis. For example, please see metalint, the tool for global variable usage analysis.
Please do not hesitate to post your question on Metalua mailing list. People there are usually very helpful.
There is also lua-inspect, which is based on metalua that was already mentioned. I've integrated it into ZeroBrane Studio IDE, which generates an output very similar to what you'd expect. See this SO answer for details: https://stackoverflow.com/a/11789348/1442917.
For checking globals, see this lua-l posting. Checking locals is harder.
You need to find a parser for lua (should be available as open source) and use it to parse the script into a proper AST tree. Use that tree and a simple variable visibility tracker to find out when a variable is or isn't defined.
Usually the scoping rules are simple:
start with the top AST node and an empty scope
item look at the child statements for that node. Every variable declaration should be added in the current scope.
if a new scope is starting (for example via a { operator) create a new variable scope inheriting the variables in the current scope).
when a scope is ending (for example via } ) remove the current child variable scope and return to the parent.
Iterate carefully.
This will provide you with what variables are visible where inside the AST. You can use this information and if you also inspect the expressions AST nodes (read/write of variables) you can find out your information.
I just started using luacheck and it is excellent!
The first release was from 2015.