I'm currently implementing a way to manage execution of a test in robot framework using using tkinter and the builtin listeners.
I was able to make a Pause/Resume system relatively easily but I'm unable to make a Stop system.
In the RobotFramework UserGuide there is an example to insert keywords in test cases like this:
ROBOT_LISTENER_API_VERSION = 3
def start_test(test, result):
test.keywords.create(name='Log', args=['Keyword added by listener!'])
The issue is, that this is deprecated and doesn't work. I have the following error when trying to use this :
UserWarning: 'keywords' attribute is read-only and deprecated since Robot Framework 4.0. Use 'body', 'setup' or 'teardown' instead.
I don't know how to use Body setup or teardown to do what I want and I was unable to found any example similar to the deprecated one
Apparently I needed to ask the solution to find one by myself
So I just needed to make something like this :
test.setup.config(name="Fatal Error", args=["Force Quit"])
or
test.teardown.config(name="Fatal Error", args=["Force Quit"])
Why is the Object.keys function on the global object not returning the process field?
> Object.keys(global)
[
'global',
'clearInterval',
'clearTimeout',
'setInterval',
'setTimeout',
'queueMicrotask',
'clearImmediate',
'setImmediate'
]
> global.process
process {
version: 'v13.7.0',
versions: {
node: '13.7.0',
v8: '7.9.317.25-node.28',
uv: '1.34.1',
process is not actually a key on the global object as of node version 12 (Described in the changelog https://nodejs.org/tr/blog/uncategorized/10-lts-to-12-lts/#notable-changes-in-node-js-12-0-0, implemented through PR https://github.com/nodejs/node/pull/26882). Instead it has a defined getter for it. E.g. try out global.__lookupGetter__('process') and you should see that you get a function back.
> Object.keys(global)
[
'global',
'clearInterval',
'clearTimeout',
'setInterval',
'setTimeout',
'queueMicrotask',
'clearImmediate',
'setImmediate'
]
> global.__lookupGetter__('process')
[Function: get]
> global.__lookupGetter__('process')()
process {
version: 'v13.7.0',
versions: {
node: '13.7.0',
...
The reason for the change as described in the PR:
This implements just the semver major breaking changes from #26334 Restrict process and Buffer globals to CommonJS, which is to make global.process and global.Buffer getters / setters over value properties.
...
The other referenced PR is https://github.com/nodejs/node/pull/26334 which is described as:
This PR deprecates access to global.process and global.Buffer access in ECMAScript modules only, while ensuring they continue to behave fine for all CommonJS modules and contexts providing comprehensive backwards compatibility.
This is done by making them getters which check the context in which they are called and throw when inside an ECMAScript module. To avoid this getter slowpath in accesses, process and Buffer are also added as a context to the compileFunction wrapper in CJS. In addition these getters are only defined as soon as there is a load of an ECMAScript module to avoid any slowdowns in these cases.
The benefits of this are that then ECMAScript modules don't by default have to assume access to all the root-level-security functions and properties on process allowing access control to be added in future, as well as helping towards browser compatibility by making process an import.
ECMAScript modules share the same realm global, so there isn't a way to do this otherwise. In addition once users start running and writing and publishing ECMAScript modules in Node.js that assume the process and Buffer globals exist, it becomes very difficult to change this then.
For these reasons I think it is quite important to land this with the ECMAScript modules implementation in Node.js to provide these properties, or risk never being able to provide them at all in Node.js due to ecosystem compatibility constraints.
With the new 3.0.0 version of Fabric JS we have to apply requestRenderAll() in order to see the handles when one objects is active.
My question is:
does requestRenderAll() replace some kind renderAll() method. Are there any important differences between both methods. When we have to use each of them and do we have to use them together?
I now that Canvas.renderall is a sync operation and requestRenderAll() method is regarded as improvemnt. But do we still need renderAll() and if "yes", when. And also - is renderAll() going to be deprecated in near future?
We have a type named OldThing which we want to deprecate over time.
We need an NDepend query/rule that says from this point on, don't add any more calls to 'OldThing'.
We currently use NDepend and have a baseline build for checking things like don't make large methods even larger.
So, we'd like to use NDepend to track any additional calls made to OldThing. I have the following CQL query:
// <Name>Don't use OldThing going forwards</Name>
warnif count > 0
let containsMethods = Methods.WithFullNameIn(
"MyNamespace.OldType.get_Foo()",
"MyNamespace.OldType.get_Bar()")
from m in Application.Methods.UsingAny(containsMethods)
where m.IsUsedRecently()
select m
... the trouble is, it doesn't seem to work; it doesn't find any new calls.
Is there a better way of doing this in NDepend (perhaps by utilising trend metrics)?
You don't need where m.IsUsedRecently(), this is only for third-party method calls.
Then you need to double check that the let expression is matching the proper deprecated methods (you could also match them all at once by using the ObsoleteAttribute).
Finally you should make this rule critical and it should work :)
The method CGWaitForScreenRefreshRects is deprecated in Mac OS X v10.8.
The alternative method mentioned in class reference(CGRegisterScreenRefreshCallback) is also deprecated.
What should I use to get the screen updates in 10.8?
Look at CGDisplayStream.h. It is new set of APIs added to 10.8. Their is rare documentation on it though.