This was the standard boiler plate I was using:
var stage = new createjs.Stage("canvas1");
createjs.Ticker.addEventListener("tick",stage);
stage.enableMouseOver();
...
createjs.Ticker.setFPS(12);
createjs.Ticker.addListener(stage,false);
Apparently createjs.Ticker.addListener is no longer supported. How should the above code be changed?
Your example shows both the correct and deprecated usage.
// OLD
createjs.Ticker.addListener(stage,false);
// NEW
createjs.Ticker.addEventListener("tick", stage);
//OR
createjs.Ticker.on("tick", stage);
The changes make Ticker use the same Event dispatcher pattern that the rest of CreateJS does.
Additionally, the framerate method has changed to a setter:
// OLD
createjs.Ticker.setFPS(12);
// NEW
createjs.Ticker.framerate = 12;
It will depend on what version you use of EaselJS. I updated the demo you posted to the latest version using those changes: http://jsfiddle.net/lannymcnie/Aprdf/80/
Unfortunately there are still demos out there with out-of-date code. Let me know if you have any other questions.
Related
I'd like to take an action the first time a user loads a new version of my VS Code extension. This is different from merely detecting first run as described by the How to run vscode extension command just right after installation? because I don't want to detect "just right after installation" I want to detect first run of each new version which is a totally different problem.
Mike Lischke's answer to that question doesn't actually answer that question, it answers this question, but that doesn't mean this is a duplicate question, it means the response to the other question doesn't actually answer the asked question, and since unlike many people I actually read the question, I didn't bother to read the answers, because answers to that question are not what I seek. Frankly I'm tempted to delete the question myself just to spite Stack Overflow because I'm fed up with this crap. Do whatever you like.
Searching the net turned up sample code
export function activate(context: vscode.ExtensionContext) {
if (context.firstTimeUse) {
//do the one-time-per-version-update thing
}
}
but ExtensionContext doesn't seem to have this property, at least not any more.
So how do you do it now?
I could record the version in a file and compare to the file before updating it, but if there's baked in support I'd rather do it the supported way.
There is no supported mechanism.
Since each update gets a new folder, you don't need to log a timestamp, just probe for the file. If it exists, not first run. If it doesn't exist, first run so create the file and do other first run things.
This is so simple and straightforward there probably won't ever be a supported mechanism. Thanks to Lex Li in the comments for confirming that this is the standard solution.
If you need to differentiate major, minor and maintenance releases, the simplest solution is to store the version string in context.globalState. You begin by trying to fetch from context.globalState. Absence means first run ever. If it's present, an exact match for current version means no change. For a non-match you can parse out major and minor version numbers context.globalState.
const currentVersion = context.extension.packageJSON.version as string;
const lastVersion = context.globalState.get("version") as string ?? "0.0.0"
if (lastVersion !== currentVersion) {
logger.warn(`Updated to ${currentVersion}`);
const lastVersionPart = lastVersion.split(".");
const currVersionPart = currentVersion.split(".");
if (lastVersionPart[0] !== currVersionPart[0]) {
// major version change
advertiseWalkthrough();
if (lastVersionPart[1] !== currVersionPart[1]) {
// minor version change
launchWhatsNew();
} else {
// it's a maintenance version change so don't pester the user
}
}
context.globalState.update("version", currentVersion);
}
In my quarkus application i'm using micrometer to retrieve metrics (like in this guide : https://quarkus.io/guides/micrometer).
In JVM mode everything works fine, but in native mode system_cpu_usage is "Nan".
I tried bumping micrometer to 1.8.4 and adding :
{
"name":"com.sun.management.OperatingSystemMXBean", "allPublicMethods": true
},
to my reflect-config.json but no luck. I also tried generating the reflect-config (and other native configuration files) with the graalvm tracing agent but still no luck.
This may be a bug.
Micrometer is looking for a few known implementations of the MXBean:
https://github.com/micrometer-metrics/micrometer/blob/b087856355667abf9bf2386265edef8642e0e077/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/system/ProcessorMetrics.java#L55
private static final List<String> OPERATING_SYSTEM_BEAN_CLASS_NAMES = Arrays.asList(
"com.ibm.lang.management.OperatingSystemMXBean", // J9
"com.sun.management.OperatingSystemMXBean" // HotSpot
);
so that it can find the methods that it should be invoking...
https://github.com/micrometer-metrics/micrometer/blob/b087856355667abf9bf2386265edef8642e0e077/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/system/ProcessorMetrics.java#L80
this.operatingSystemBean = ManagementFactory.getOperatingSystemMXBean();
this.operatingSystemBeanClass = getFirstClassFound(OPERATING_SYSTEM_BEAN_CLASS_NAMES);
Method getCpuLoad = detectMethod("getCpuLoad");
this.systemCpuUsage = getCpuLoad != null ? getCpuLoad : detectMethod("getSystemCpuLoad");
this.processCpuUsage = detectMethod("getProcessCpuLoad");
(Note specifically "getFirstClassFound", which is constrained against the first list).
Speculation on my part, but I suspect Graal is returning a different type, which is possible from here:
https://github.com/oracle/graal/blob/6ba65dad76a4f54fa59e1ed2a62dedd3afe39928/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/management/ManagementSupport.java#L166
would take some digging to know which, but I would open an issue with Micrometer so we can sort it out.
new to Fluent/NHibernate and trying to upgrade code base to the latest FluentNHibernate from version 1.1.0.685. The PersistenceConfiguration type used to have a Cache method (below) and no longer there. Is this done differently in subsequent releases? I couldn't find anything in their release notes of the changes.
public TThisConfiguration Cache(Action<CacheSettingsBuilder> cacheExpression)
{
cacheExpression(this.cache);
return (TThisConfiguration) this;
}
I am stuck at this point where I see yslow is no more going for PhantomJS 2.0 as phantom.args property in API is deprecated. But in earlier version it works.
Please let me know which version of PhantomJS works with yslow?
phantom.args is deprecated from PhantomJS 2.0 onwards. Either use an older version (not recommended) or edit your yslow script to use system.args instead. Note that the system module must be required.
system.args[0] is always the script name and system.args[1] is the first, but before phantom.args[0] was the first argument. So you will also need to change all the indexes by one.
PhantomJS had a major overhault with version 2 which also included a much newer version of WebKit.
One has to change yslow.js at line 22.
I made changes like this
//args = phantom.args,
args = require('system'),
And it worked perfectly... This should be patched to yslow then!!!
It will get you off from the error but the arguments are not falling on right place yet.
I then changed to
//args = phantom.args,
system = require('system'),
args = system.args,
len = args.length,
But still no good sign!!!
Okay this is working quite fine but yet not confirmed it is stable and working great. I changed the index now to the below
line 69: for (i = 1; i < len; i += 1) {
and also changed phantom.args to args[0] just to have proper --help output description. But still i am in doubt whether it is correctly indexing now or not.
Apparently there is a fix for this problem but it has not been merged yet in the main branch.
I have the following in my feature.template.xml
...
<VersionRange BeginVersion="1.0.0.1" EndVersion="1.0.0.2">
<CustomUpgradeAction Name="1.0.0.1_TO_1.0.0.2"></CustomUpgradeAction>
</VersionRange>
<VersionRange BeginVersion="1.0.0.2" EndVersion="1.0.0.3">
<CustomUpgradeAction Name="1.0.0.2_TO_1.0.0.3"></CustomUpgradeAction>
</VersionRange>
...
My feature upgrade event is as follows:
public override void FeatureUpgrading(SPFeatureReceiverProperties properties, string upgradeActionName, System.Collections.Generic.IDictionary<string, string> parameters)
{
using (SPSite site = (SPSite)properties.Feature.Parent)
using (SPWeb mySite = site.RootWeb)
{
switch (upgradeActionName)
{
case "1.0.0.1_TO_1.0.0.2":
//execute logicA
break;
case "1.0.0.2_TO_1.0.0.3":
//execute logicB
break;
default:
break;
}
}
Am I correct in saying that if the site is currently version 1.0.0.0, it will be upgraded to v 1.0.03, executing both logicA and logicB above. This means that sharepoint would call featureupgrading event for each version upgrade.Is this correct? Or do I need to do something different to achieve this?
I also have the following concerns:
What exactly do the the BeginVersion and EndVersion mean.
I especially do not understand the BeginVersion. What happens if instead of 1.0.0.2 I set it to 1.0.0.1 as well?
Any assistance would be greately appreciated, as I did not find any good relevant details online or on books.
When you add a new Feature to your VS SharePoint project, Visual studio initializes your Feature with version 0.0.0.0.
In the properties window you can set a version number for your feature.
When you want to upgrade an existing feature you'll have to define the range of versions for which you want your upgrade actions (code, new manifest, ...) to happen.
E.g.: You deployed your feature without changing the version number. Your current deployed feature has version number 0.0.0.0.
You want to upgrade your feature and set the version number to 2.0.0.0.
If you define a versionrange as follows:
<VersionRange BeginVersion="1.0.0.0" EndVersion="2.0.0.0">
You'll notice nothing will happen when you call SPFeature.Upgrade() since 0.0.0.0 is not in the defined versionrange.
If you use this versionrange
<VersionRange EndVersion="2.0.0.0">
or
<VersionRange BeginVersion="0.0.0.0" EndVersion="2.0.0.0">
You'll notice your FeatureUpgrading eventreceiver or other upgrade actions will be triggered.
Your upgraded feature will now have version number 2.0.0.0.
If you call SPFeature.Upgrade again nothing will happen again, because 2.0.0.0 exceeds the defined versionrange. So BeginVersion is included, EndVersion not.
Every feature with a version number between [0.0.0.0 - 1.x.x.x] will be upgraded if you use the latter versionranges.
I think you can also leave the BeginVersion and EndVersion attributes entirely out. Then you're upgradeactions will be triggered at every SPFeature.Upgrade() call. (To be verified)
For more information: Chris O'Brien wrote an interesting articles series about this topic, cfr. http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html