In the commands.scala file here of the ReactiveMongo Github repo, we are seeing the following :
trait Command {
private[reactivemongo] def commandKind: CommandKind
}
This is a clear difference from previousl releases (0.20.x and earlier).
By changing this trait, one is making the implementation of a def named commandKind mandatory for any custom command implementation.
Does this mean that going forward implementing a custom ReactiveMongo command must always be done by introducing the package [reactivemongo] into our own projects ?
This is rather confusing, as that requirement appears to be absent in the examples given here
Related
I tried to use Kotlin's coroutine channels, but got a warning about the code using an ObsoleteCoroutinesApi. Where is the replacement for the deprecated channels code?
As of today, no replacement yet exists for the Kotlin Coroutine Channels API. Despite confusing naming, they added this annotation to indicate that the existing API is being rewritten and will be replaced.
It's a warning that you can accept. If you have kotlinOptions.allWarningsAsErrors = true stopping you from building your app, you can simply add the #ObsoleteCoroutinesApi annotation to the top of the class to indicate that you accept the risk that your code will require changes.
However, this may quickly spiral out of control as you need to apply these markers to every class that uses these APIs and then every dependency that uses those classes, ad infinitum. To accept these risks project-wide, add the following to your gradle options:
kotlinOptions.freeCompilerArgs += [
"-Xuse-experimental=kotlinx.coroutines.ExperimentalCoroutinesApi",
"-Xuse-experimental=kotlinx.coroutines.ObsoleteCoroutinesApi"]
Feel free to update this answer when a replacement API exists.
what is the main difference between the 2 classes.
mainly, what situation would i use one and not the other?
org.apache.hadoop.hdfs.protocol package
http://www.sching.com/javadoc/hadoop/org/apache/hadoop/hdfs/protocol/HdfsFileStatus.html
org.apache.hadoop.fs package
https://hadoop.apache.org/docs/r2.6.1/api/org/apache/hadoop/fs/FileStatus.html
HdfsFileStatus is marked with #InterfaceAudience.Private and #InterfaceStability.Evolving annotations (check the source code). The first annotation means it intended to be used for internal Hadoop implementations. The second annotation means the file might be changing (backwards compatible support might not be available between releases). Basically you should not use HdfsFileStatus in your code.
I'm using Pharo 5.0. In a couple of cases, I have found a limit or possibly a bug in an existing Pharo class (e.g., something in DBXTalk/Garage, or Regex-Core). I would like to be able to modify a selector or set of selectors that exist(s) in a class outside of my own project and make that part of my package.
I have found several instructions on how to create a new selector in an outside class and move that into my package (e.g., as shown in this tutorial). That's very cool. But in some cases I actually want to modify an existing selector in the outside class and have my copy of that selector override the one in the outside class when I use it. I don't wish to modify the existing 3rd party or Pharo pre-supplied package.
In GNU Smalltalk, I can do that just as a normal part of doing a class extend. For example:
Kernel.MatchingRegexResults extend [
at: anIndex [
"My updated version of the 'official' Kernel.MatchingRegexResults#at: selector"
"This is part of my package so overrides the 'official' version"
...
]
foo [
"My new foo selector"
]
]
How can I do this in Pharo 5.0? I've done quite a bit of searching but couldn't find a means of doing it. The words "extend" or "override" do not appear in the Pharo by Example and Deep Into Pharo books.
Please note that, in addition to what Milan Vavra wrote, every method in a protocol named *YourPackage-(something) will belong to the package YourPackage, regardless of the package that the class belongs to. At least in Squeak, there is the convention to put methods overridden like this in the *YourPackage-override protocol. Pharo probably has a similar naming convention. The Move to package feature moves the method to such a "starred" protocol.
However, it is discouraged to use such overrides because you cannot have two packages provide an implementation for the same method simultaneously. Monticello will try to preserve both the original method and the overriding method (see senders of PackageInfo>>isOverrideCategory:), but it's still possible that your override method will be overridden by updates to its original package or you will miss updates to the original method, possibly breaking things.
The "Right Way" is to refactor the original method in the original package to make its behavior more easily customizable.
The code in GNU Smalltalk syntax
Kernel.MatchingRegexResults extend [
at: anIndex [
"method body"
]
foo [
"My new foo selector"
]
]
would look like this
!MatchingRegexResults methodsFor: 'protocol'!
at: anIndex
"method body"
!
foo
"My new foo selector"
! !
in a Pharo change set that can be filed in from File Browser.
But please note that in both cases, GNU Smalltalk and Pharo Smalltalk, you are actually replacing the original version of the method in that class.
In GNU Smalltalk you might not be accustomed to saving the image and hence you might think that the extend syntax does not modify the original method in the original class.
Actually it does exactly that.
With GNU Smalltalk you typically start with the same old unmodified image each time you run gst.
This is because the default place for the image in GNU Smalltalk is not writable to the normal user. So gst reads the same read-only image each time, you modify it in-memory with class definitions and extensions, your modified image only lives temporarily while your program is running, and is discarded on program exit.
The official site of Typescript get me ask a question,
"Do we need to use namespace or not?".
The following quote explains the 2 things well:
It’s important to note that in TypeScript 1.5, the nomenclature has
changed. “Internal modules” are now “namespaces”. “External modules”
are now simply “modules”, as to align with ECMAScript 2015’s
terminology, (namely that module X { is equivalent to the
now-preferred namespace X {).
So, they suggest that TS team prefer namespace.
Further, it says we should use "namespace" to struct the internal module:
This post outlines the various ways to organize your code using
namespaces (previously “internal modules”) in TypeScript. As we
alluded in our note about terminology, “internal modules” are now
referred to as “namespaces”. Additionally, anywhere the module keyword
was used when declaring an internal module, the namespace keyword can
and should be used instead. This avoids confusing new users by
overloading them with similarly named terms.
The above quote is all from the Namespace section, and yes, it says again, but in a internal secnario.
but in the module section, one paragraph, says that:
Starting with ECMAScript 2015, modules are native part of the
language, and should be supported by all compliant engine
implementations. Thus, for new projects modules would be the
recommended code organization mechanism.
Does it mean that I don't need to bother with namespace, use module all along is the suggested way to develop?
Does it mean that I don't need to bother with namespace, use module all along is the suggested way to develop?
I wouldn't put it exactly that way... here's another paraphrase of what has happened. One upon a time, there were two terms used in Typescript
"external modules" - this was the TS analog to what the JS community called AMD (e.g. RequireJS) or CommonJS (e.g. NodeJS) modules. This was optional, for some people who write browser-based code only, they don't always bother with this, especially if they use globals to communicate across files.
"internal modules" - this is a hierarchical way of organising your variables/functions so that not everything is global. The same pattern exists in JS, it's when people organise their variables into objects/nested objects rather than having them all global.
Along came Ecmascript 2015 (a.k.a. ES6), which added a new formal, standard format that belonged in the "external modules" category. Because of this change, Typescript wanted to change the terminology to match the new Javascript standard (being that it likes to be a superset of Javascript, and tries its best to avoid confusion for users coming from Javascript). Thus, the switch of "external modules" being simplified to just "modules", and "internal modules" being renamed to "namespaces".
The quote you found here:
Starting with ECMAScript 2015, modules are native part of the language, and should be supported by all compliant engine implementations. Thus, for new projects modules would be the recommended code organization mechanism.
Is likely alluding to guidance for users who were not yet using (external) modules. To at least consider using it now. However, support for ES6 modules is still incomplete in that browsers as of May 2016 don't have built-in module loaders. So, you either have to add a polyfill (which handles it at runtime) like RequireJS or SystemJS, or a bundler (like browserify or webpack) that handles it at build time (before you deploy to your website).
So, would you ever use both modules (formerly "external modules") and namespaces? Absolutely - I use them both frequently in my codebases. I use (external) modules to organise my code files.
Namespaces in Typescript are extremely useful. Specifically, I use namespace declaration merging as a typesafe way to add extra properties to function objects themselves (a pattern often used in JS). In addition, while namespaces are a lot like regular object variables, you can hang subtypes (nested interfaces, classes, enums, etc.) off of their names.
Here is an example of a function with a property (very common in NodeJS libs):
function someUsefulFunction() {
// asynchronous version
return ...; // some promise
}
namespace someUsefulFunction {
export function sync() {
// synchronous version
}
}
This allows for consumers to do this common NodeJS pattern:
// asynchronous consumer
someUsefulFunction()
.then(() => {
// ...
});
// synchronous consumer
someUsefulFunction.sync();
Similarly, say you have an API that takes in an options object. If that options type is specific to that API,
function myFunc(options?: myFunc.Options) {
// ...
}
namespace myFunc {
export interface Options {
opt1?: number;
opt2?: boolean;
opt3?: string;
}
}
In that case, you don't have to pollute a larger namespace (say whole module scope) with the type declaration for the options.
Hope this helps!
I'm trying to run instrumentation test cases but getting the below error while dex conversion
UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dex.DexException: Too many classes in --main-dex-list, main dex capacity exceeded
at com.android.dx.command.dexer.Main.processAllFiles(Main.java:494)
at com.android.dx.command.dexer.Main.runMultiDex(Main.java:334)
at com.android.dx.command.dexer.Main.run(Main.java:244)
at com.android.dx.command.dexer.Main.main(Main.java:215)
at com.android.dx.command.Main.main(Main.java:106)
:App:dexDebug FAILED
How to resolve this issue in gradle?
Let's first understand the problem:
On pre-Lollipop devices, only main dex is being loaded by the framework. To support multi-dex applications you have to explicitly patch application class loader with all the secondary dex files (this is why your Application class have to extend MultiDexApplication class or call MultiDex#install).
This means that your application's main dex should contain all the classes that are potentially accessible before class loader patching.
You will receive java.lang.ClassNotFoundException if your application code will try to reference a class that was packaged in one of your secondary dex files before successfully patching application class loader.
I've documented here how plugin decides which classes should be packaged in main-dex.
If total amount of methods that those classes are referencing exceeds the 65,536 limit, then build will fail with Too many classes in --main-dex-list, main dex capacity exceeded error.
I can think of three possible solutions for this issue:
(The easiest solution, but not suitable for most of the
applications) Change your minSdkVersion to 21.
Shrink your application code. This was discussed many times previously (see here and here).
If none of the above solutions work for you, you can try to use my workaround for this issue - I'm patching the Android gradle plugin to not include Activity classes in main dex. It's a bit hacky, but works well for me.
There's an issue in Android bug tracker regarding this error. Hopefully the Tools team will provide a better solution soon.
Update (4/27/2016)
Version 2.1.0 of Gradle plugin allows to filter main-dex list classes.
Warning: this is using an unsupported api that will be replaced in the future.
For example, to exclude all activity classes you can do:
afterEvaluate {
project.tasks.each { task ->
if (task.name.startsWith('collect') && task.name.endsWith('MultiDexComponents')) {
println "main-dex-filter: found task $task.name"
task.filter { name, attrs ->
def componentName = attrs.get('android:name')
if ('activity'.equals(name)) {
println "main-dex-filter: skipping, detected activity [$componentName]"
return false
} else {
println "main-dex-filter: keeping, detected $name [$componentName]"
return true
}
}
}
}
}
You can also check my example project that demonstrates this issue (and applies the above filtering).
Update 2 (7/1/2016)
Version 2.2.0-alpha4 of Gradle plugin (with build-tools v24) finally solves this issue by reducing multidex keep list to a minimum.
The unsupported (and undocumented) filter from 2.1.0 should not be used anymore. I've updated my sample project, demonstrating that build succeeds now without any custom build logic.
One other way to resolve this issue is to remove classes with Runtime annotations from the main DEX file:
android {
dexOptions {
keepRuntimeAnnotatedClasses false
}
}
This is particularly helpful for applications which are using dependency injection frameworks since even for Dagger annotations are usually kept in runtime.
You have two choices.
use ProGuard to strip down number of methods
use multidex feature
My advice - go with ProGuard, it require as little as zero changes to source code