I'm wondering if there are tsd definitions for cycle.js, motorcycle.js, most.js and snabbdom.
No, not yet. But they will in an upcoming version (we are working on it currently).
Related
Recently I had updated my dependencies on activity-ktx according to this
https://developer.android.com/jetpack/androidx/releases/activity#1.2.0
However, the registerForActivityResult() is not found. It is working before this update. Is there anything changes in androidx.activity:activity-ktx:1.2.0?
I managed to solved my question. I think I will post my answer here in case it helps for the others.
My solution is to update this dependencies.
implementation 'androidx.appcompat:appcompat:1.3.0-beta01'
My AS didn't warn me about the update only when I changed the version to 1.3.0.
PS: I am referring to this Cannot access 'androidx.activity.result.ActivityResultCaller'
I'm using SQ 7.3-alpha1 with sonar-kotlin-plugin-1.0.1.965.jar. However, I cannot deactivate a special warning inside my Kotlin code for repositories in Spring Data where I need an "_" in a method name.
I tried both //NOSONAR and #Suppress("kotlin:S100") and #SuppressWarnings("kotlin:S100"). Any hint is appreciated.
You're not able to deactivate that issue because none of the mechanisms you're trying to use have been implemented for Kotlin.
Instead, you'll have to do this from the UI side.
Great news, https://jira.sonarsource.com/browse/SONARSLANG-373 is fixed in version 1.6 of Sonarslang. So an update to that version might improve the situation. I’ve not tested it yet, hence the cautious wording.
A lot of angular related projects use a pre-release versioning scheme of the following:
e.g. angular-cli
1.0.0-beta.22,
1.0.0-beta.22-1,
1.0.0-beta.24
e.g. #angular/material
2.0.0-alpha.9
2.0.0-alpha.9-1,
2.0.0-alpha.9-2,
2.0.0-alpha.9-3,
2.0.0-alpha.10,
2.0.0-alpha.2.0.0-alpha.11,
2.0.0-alpha.11-1,
Due to the way semantic versioning works (dot separators, numeric always lower precedence to alphanumeric parts), 2.0.0-alpha.9-experimental-pizza is still the highest version for #angular/material, even tough 2.0.0-alpha.11 is released.
Similar for angular-cli, where 1.0.0-beta.22-1 is still the highest version, even though 1.0.0-beta.24 is released.
This causes package.json dependencies with ^ versions, e.g.
"angular-cli" : "^1.0.0-beta.22-1"
to not upgrade to 1.0.0-beta.24, because 24 is a numeric version and therefore smaller than 22-1.
I also posted this as an issue to the #angular/material issue tracker here but got no response.
Is this just an oversight, or am I missing something?
Update:
angular-cli now has versions
angular-cli#1.0.0-beta.25
angular-cli#1.0.0-beta.25.1
angular-cli#1.0.0-beta.25.2
angular-cli#1.0.0-beta.25.3
etc.
So it seems this was an oversight.
Short answer is that these are manual processes. The team hasn't invested in automating them yet. At least that's speaking for the Angular CLI, since I'm a contributor to the repository source code (but not a team member).
In pretty much all recent releases, something happened at the release, so they had to issue another version. Hence things like 1.0.0-beta.xx, has been quickly followed by 1.0.0-beta.xx-1.
Some tests are hard to run before publishing the packages. Especially for the CLI which publishes a range of packages not just one (a couple webpack plugins that the CLI uses are available as separate packages for other non-CLI seed projects to use).
Usually when the team is happy with a version, they explicitly tag it as latest, which is something npm allows publishers to do, so, you shouldn't in theory have this Angular Material alpha 9 vs alpha 11 problem, unless alpha 11 is not tagged as latest or something.
Long time later, I think it was an oversight in the alpha / betas. This is now resolved and angular projects follow semver also for the pre-release tags.
I inherited this project that used NAudio 1.7.1.16.
In there they use SignalGenerator.Frequency1 and SignalGenerator.Frequency2 to generate a TwoTone sound.
However, the later version 1.7.2 and latest 1.7.3, Frequency1 and Frequency2 and SignalGeneratorType.TwoTone does not exist any more!
So how do I do the TwoTone thing with the latest version of NAudio?
You must have inherited a custom build of NAudio. NAudio's SignalGenerator has never had a TwoTone option. It has been unchanged ever since it was added in 2012.
I'm attempting to install Pieradmin on a clean image of Pharo 1.4 (Summer), using the commands:
Gofer it
renggli: 'pier2addons';
package: 'ConfigurationOfPierAdmin';
load.
ConfigurationOfPierAdmin loadBleedingEdge.
It progresses for a while and comes up with the error:
This package depends on the following classes:
ImageSegment
You must resolve these dependencies before you will be able to load these definitions:
writeKernel:on:
You can proceed and it will finish installing all its dependencies.
I have two questions:
Where can I get the class ImageSegment?
Or, if I can't, does it matter that writeKernel:on: isn't there?
Nathan,
The dependency on ImageSegment is almost certainly coming from the package Pier-Pharo-Persistency defined in ConfigurationOfPier2>>baseline2060: where it is included as part of Core group for Pier ... which at first glance makes it appear that the Pier-Pharo-Persistency is pretty much required for Pier.
You could fiddle with the ConfigurationOfPier2>>baseline2060: and remove Pier-Pharo-Persistency from the Core group, then try the load again, but you may just be creating another more subtle problem for yourself. It's probably a good idea to ask this question on the Pier mailing list
OTOH, I'm pretty sure that Pier-Admin works in Pharo-1.3 so that would be your best option.
Dale
Yes, ImageSegment was removed from Pharo 1.4. And ReferenceStream was also removed from Pharo 2.0. The idea was to rely on new and better tools like Fuel serializer (see http://rmod.lille.inria.fr/web/pier/software/Fuel).
Yanni and me have done 2 things: Pier persistence and kernel export/import based on Fuel. You can find the code in:
Gofer it
squeaksource3: 'pierfuel';
package: 'Pier-FuelPersistence-Core';
package: 'Pier-FuelPersistence-Test';
load.
Then you can do, for example:
PRFuelExporterImporter new exportKernelNamed: 'pierDBX' toFilename: 'pierDBX.fuel'
And:
PRFuelExporterImporter new importNewKernelNamed: 'pierDBX' fromFilename: 'pierDBX.fuel'