I'm trying to keep a contract as small as possible. I know that if you import a solidity library, only the functions actually utilized in that library get compiled into the contract, increasing it's size.
I'm not sure if that goes for importing interfaces.
For example:
interface IDoThings {
function transfer(address from, address to, uint256 amount) external;
function setValue(uint256 newVal) external;
function owner() external view returns (address);
}
contract DoingThings {
function getOwnerOfAnotherContract(address target) public view returns (address) {
return IDoThings(target).owner();
}
}
When this get's compiled down, will the function selectors for transfer & setValue also be included in the contract's bytecode, or will only the owner function selector be included?
interface is like typescript types, they are used in compilation time and in the javascript bundle you do not see any type definitions.
If you compile your code at https://remix.ethereum.org/
this is what you will get
[
{
"inputs": [
{
"internalType": "address",
"name": "target",
"type": "address"
}
],
"name": "getOwnerOfAnotherContract",
"outputs": [
{
"internalType": "address",
"name": "",
"type": "address"
}
],
"stateMutability": "view",
"type": "function"
}
]
there is nothing about interface or its function signatures
They do not.
Solidity v0.8 without bytecode optimizer:
with the unused interface declarations: 554 bytes
without: 554 bytes
Related
I'm trying to change method calls color in VSCode. I know I can change the Function scope color as follewed:
{
"name": "Function call",
"scope": "meta.function-call.object",
"settings": {
"foreground": "#e26f60"
}
}
Is there an equivalent for method calls. I would like to only highlight the foo_method() in the following code:
class Foo():
def foo_method(self):
print("Called Foo from class")
foo_object = Foo()
foo_object.foo_method()
The scope of the method call to foo_method is:
meta.function-call.generic.python
meta.function-call.python
meta.member.access.python
source.python
So to just target methods, try using a more specific scope selector in your theme. For example, meta.member.access meta.function-call will select all meta.function-call scopes under meta.member.access scopes:
{
"name": "Function call",
"scope": "meta.member.access meta.function-call",
"settings": {
"foreground": "#e26f60"
}
}
(you may need to further tweak the scope selector based on your specific needs)
I am writing a vscode extention for a specification language. I would like to provide the users of the plugin with a specific task. The task could be made available using tasks.json.
Is there a way to add tasks to the tasks.json of a user that uses that extension?
The documentation didn't help me here either. When you provide tasks through the extension there is the TaskProvider API. The example doesn't go into much detail about how these tasks are created though, compared to the classical tasks.json approach.
In your package.json you need to define the types of tasks this extension contributes. This has nothing to do with the type in tasks.json. It's rather a freeform string. If you need custom problem matchers you also need to define theme here.
"contributes": {
"taskDefinitions": [
{
"type": "mytask"
}
],
"problemMatchers": [
{
"name": "mywarnings",
"base": "$gcc",
"fileLocation": [
"relative",
"/"
]
}
]
},
In extension.ts you need to provide the tasks. Say we have an array of vscode.Task in tasks you can do:
vscode.tasks.registerTaskProvider('mytask', {
provideTasks: () => {
return tasks;
},
resolveTask(_task: vscode.Task): vscode.Task | undefined {
// as far as I can see from the documentation this just needs to return undefined.
return undefined;
}
});
If you want to create a shell task you need the following:
new vscode.Task (
{type: 'shell'}, // this is the same type as in tasks.json
ws, // The workspace folder
'name', // how you name the task
'MyTask', // Shows up as MyTask: name
new vscode.ShellExecution(command),
["mywarnings"] // list of problem matchers (can use $gcc or other pre-built matchers, or the ones defined in package.json)
);
I hope this helps. The bigges issue I see is the overloading of various names (like type), and that the format in tasks.json is completely different to the way tasks are built with TaskProvider API.
I am new to drools.
I want to check in RHS that if a field is present in POJO or not.
{
"category": [
{
"nlp": [
{
"mainCategory": "Politics"
}
],
"crawler": [
{
"isNLP": true,
"mainCategory": "Politics"
}
]
}
]
}
This is list of the pojo that are generated
EsRootDoc.java
Crawler.java
Nlp.java
EsRootDoc is the main class which have methods and fields.`when
$RHSmap1:EsRootDoc()
and
$map1:EsRootDoc($categorylist1:category)
$category2:Category($nlplist2:nlp) from $categorylist1
$nlp2:Nlp(mainCategory=="politics") from $nlplist2
then
$RHSmap1.setEvent("fight");
end`
This is giving me following error
[Error: unable to resolve method using strict-mode: com.orkash.EnrichmentService.EnrichmentController.tempJsonToClass.EsRootDoc.setEvent(java.lang.String)]
[Near : {... $RHSmap1.setEvent("fight"); ....}]
I need to provide a check in RHS :- that if EsRootDoc has a field event or not
There is nothing in Drools (as far as I know) that allows you to do what you are looking for. The RHS of a rule is - almost- pure Java. The basic rule then is: if it can't be done in Java, it can't be done in the RHS of a rule in Drools.
The good news is that what you are trying to do can be achieved in Java using reflection. My recommendation would be for you to create a helper class that uses reflection to set the value of an attribute in an object if that attribute exists. Your rules then would look like this:
rule 'Some Rule'
when
$RHSmap1:EsRootDoc()
$map1:EsRootDoc($categorylist1:category)
$category2:Category($nlplist2:nlp) from $categorylist1
$nlp2:Nlp(mainCategory=="politics") from $nlplist2
then
Helper.setAttribute($RHSmap1, "event", "fight");
end
Hope it helps,
Let’s say we I have one route and one target:
"routes": [{
"pattern": "modify",
"name": "modify",
"target": [
"master",
"modify"
]
}],
"targets": {
"modify": {
"viewName": "Modify",
"viewId": "modify",
"viewLevel": 2
}
}
So I can access the route by this.getRouter().navTo("modify"), meanwhile I can access the target by this.getRouter().getTargets().display("modify"). Both API can carry parameter by the second argument. It seems to achieve the same effect.
I can access target without defining a route for it. So I did not quite understand why I need a route?
Ref: sap.m.routing.Targets and
sap.ui.core.routing.Router
display displays the target view without changing the hash value in contrast to navTo.
You can find more information in the tutorial "Display a Target Without Changing the Hash".
Both API can carry parameter by the second argument. It seems to achieve the same effect.
The data in display method is for the display event handler. When the event is fired, the handler carries the data we passed earlier.
The parameter map we can pass to navTo is mandatory if the pattern actually awaits a parameter, e.g. if we've defined the pattern like this initially: "pattern": "modify/{id}". Check out "Navigate to Routes with Mandatory Parameters".
Just complement Boghyon's answer:
Route pattern is defined in Router, and hash is set in Router. That's the main difference.BTW, UI5 uses crossroads and hasher to help implementing router.
navTo() in sap.m.routing.Router is borrowed from sap.ui.core.routing.Router
display() in sap.m.routing.Targets is borrowed from sap.ui.core.routing.Targets
in _routeMatched of Route, oRouter._oTargets._display is called. So _display is called in both Router and Targets.
The parameter they use are different.navTo use Route name, and display use Target name. Sometimes they are defined the same.
onToPage2 : function () {
// this.getOwnerComponent().getRouter().navTo("pageRoute2");
this.getOwnerComponent().getRouter().getTargets().display("pageTarget2");
},
onToPage1 : function () {
this.getOwnerComponent().getRouter().navTo("pageRoute1");
// this.getOwnerComponent().getRouter().getTargets().display("pageTarget1");
}
I've got a snippet of IDL that looks like this:
[ object, uuid(...), pointer_default(unique) ]
interface IVirtualMachine { /* ... */ }
[ object, uuid(...), pointer_default(unique) ]
interface IVirtualServer : IUnknown
{
HRESULT FindVirtualMachine(
[in] BSTR configurationName,
[out,retval] IVirtualMachine **virtualMachine);
};
[ uuid(...), version(1.0) ]
library VirtualServerLib
{
[ uuid(...) ]
coclass VirtualServer
{
[default] interface IVirtualServer;
};
[ uuid(...) ]
coclass VirtualMachine
{
[default] interface IVirtualMachine;
};
};
...when I compile it with MIDL and then look in the generated type library, VirtualMachine (upper-case V) has been turned into virtualMachine (lower-case V).
If I call my coclass XirtualMachine, for example, it's all good.
What the hell?
This is a terrible bug/feature of MIDL. It doesn't allow the same identifier to appear with different casing, so it replaces all subsequent instances of a word with the casing from the first time it was seen.
See the KB220137
OK. Worked it out. It was this line here:
[out,retval] IVirtualMachine **virtualMachine);
If I change it to:
[out,retval] IVirtualMachine **ppVirtualMachine);
...then it works fine. Something screwy in MIDL, I guess. Maybe it's trying to do VB-like case correction.