The preview version of Kotlin includes M, like 1.4-M2.
What does this mean?
https://github.com/JetBrains/kotlin/pulls?q=is%3Aclosed+milestone%3A1.4
Stands for Milestone 2. <major>.<minor> <qualifier>
It is a qualifier, which means that it is a preview release before the final 1.4 release.
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN400
https://blog.soebes.de/blog/2017/02/04/apache-maven-how-version-comparison-works/
Related
I don't understand why the following does not work:
Main> 2.1 + 2.3
Error: Can't find an implementation for FromDouble Integer.
(Interactive):1:1--1:4
1 | 2.1 + 2.3
^^^
It works with integers, and if I understand the docs correctly, it should work with doubles too!
I get the same error with 2.1 * 2.3, but 2.1 - 2.3 and abs 2.1 work fine, which gives me the impression that there is a problem with the Num interface. However I'm a total beginner in Idris, so maybe I'm missing something very silly! I could not find any example of summing doubles on the web…
(I compiled Idris2 from the latest commit on github — 69f680e10a336c4f33414cfd55c13d41b68d735b.)
Edited to add: 2.1 + 2.3 actually works in a file (defining a constant), the problem only occurs in the REPL. I guess I'll have to file a bug.
I am programming an application in Kotlin that converts radians to degrees and vise-versa. I was testing it with JUnit and received this error.
// The code I ran
assertEquals(60.0, radians.toDegrees())
// The stacktrace
org.opentest4j.AssertionFailedError:
Expected :60.0
Actual :59.99999999999999
There is nothing I can do about this, as the program was dividing by PI and then multiplying by PI later on. I was wondering if there was a way I could run a comparison that would count this as a success because the values are close enough. In Python, you can use assertAlmostEqual() with a couple of parameters. What is the equivalent of doing this with JUnit.
I am using JDK 11, Java 8, Kotlin 1.3(whatever the latest version is)
In JUnit 4 and JUnit 5 you can specify a delta in the method when comparing doubles, specifying how much variance you are willing to tolerate.
assertEquals(60.0, myValue, 0.005);
There's also the Hamcrest IsCloseTo matcher, which sounds more like what you're used to.
"foo": "~0.2.1"
"foo": ">= 0.2.1"
What's the difference?
>= means any version equal or bigger to the mentioned release. For example 42.42.42 would be fine with >= 0.2.1 requirement (no matter how incompatible it would be in practice). Also, it means that 0.2.1-beta is not fine, as beta was before final release.
~ means reasonably close to the specified version (as in, compatible). It takes the semantic versioning definition, so any major version jumps aren't considered to be compatible (higher than the last number in specified version). For example, 42.42.42 or 0.3.0 is not fine with ~0.2.1 requirement. However, 0.2.1-beta or 0.2.42 is allowed, as it's reasonably close to the final version.
Tilde means next significant release. In your case, it is equivalent to >= 2.0, < 3.0.
A simple rule-of-thumb way is that the ~ allows the last digit to go up. e.g. ~2.2 means 2.2 and any 2.x where x is 2 or above. ~2.1.3 on the is also any 2.1.x where x is 3 or above.
http://getcomposer.org/doc/01-basic-usage.md#package-versions
Why is the Cuda variable 'blockIdx' called blockIdx instead of just blockId? It seems confusing since you can have both blockIdx.x and blockIdx.y, and since it's just the ID of the block, what's the 'x' all about? Same with threadIdx.
Just starting to get into Cuda and was trying to explain to someone how blocks and threads work and we both thought it was a weird/confusing naming convention.
Common shortcuts:
id - Identifier
idx - Index
in CUDA you talk about "block index" and "thread index", hence the shortcut Idx.
I need a compile time check for what version of glibc will be used.
The only compile time checks (ie #defines) I can find return the glibc date (__GLIBCXX__) and correspondence between the date and version seems iffy. How do you check at compile time for the version of glibc that will be used?
My code will compile and run on several systems, including a very old one. In particular I am interested in using malloc_info (see http://man7.org/linux/man-pages/man3/malloc_info.3.html). This was added to glibc in version 2.10. The program will be used on the same (or an identical system) it was built on.
I think what you're looking for is __GLIBC__ and __GLIBC_MINOR__, which represent an int of the major and minor version numbers of the GNU C Library. Have a look at this(archive link) for more details.
So if __GLIBC__ is greater than 2, or __GLIBC__ is equal to 2 and __GLIBC_MINOR__ is greater than or equal to 10, then malloc_info() should work.