Scenario:
I realized than in v1.63-2 of spatstat package, function weighted.mean() no longer exist (but exist in v1.56-1).
Question:
Is there a certain reason leading to the removal of this function or if it's been renamed?
Are you asking about weighted.mean or weighted.median? (Your question header mentions weighted.median but the question body mentions weighted.mean)
There is no function weighted.mean in the spatstat package (not in the current version and not in any previous version). The function weighted.mean is a generic function in the base R system (in the recommended package stats) which has several methods such as weighted.mean.default. There are also no methods for weighted.mean in the spatstat package (not in the current version and not in any previous version).
There is a function weighted.median in the spatstat package. It was introduced in spatstat version 1.47-0 and has been present in all subsequent versions.
Related
I am new to Rust and is trying to understand the Cargo thing. I read in their FAQ about "why do binaries have Cargo.lock in version control, but not libraries?" but do not understand what this means.
"Users dependent on the library will not inspect the library’s Cargo.lock (even if it exists). This is precisely because a library should not be deterministically recompiled for all users of the library.
If a library ends up being used transitively by several dependencies, it’s likely that just a single copy of the library is desired (based on semver compatibility). If Cargo used all of the dependencies' Cargo.lock files, then multiple copies of the library could be used, and perhaps even a version conflict."
Appreciate if anyone can explain this. Thanks.
Say we have the following crates:
string-tools: this is some kind of commonly used library exporting a FastString struct that has faster implementations of some commonly needed functions. This library has two versions: 1.0.1 and 1.0.2. Version 1.0.2 was recently released.
database: a library to interface with your favorite database. It needs to do some string processing, and so it uses the string-tools library. One of the public methods in database has a signature like this:
fn get_username(id: u64) -> string_tools::FastString
The library has not had a chance or need to update to version 1.0.2 of string-tools - maybe it's unaffected by any of the bugs that were fixed in the patch. Consequently, it's Cargo.lock pins the version of string-tools to 1.0.1.
client: this library is for interacting with the client. It also depends on string-tools, and has a method like this:
fn show_name(name: string_tools::FastString)
This library is using the most recent version of string-tools, version 1.0.2. That is also the version in its Cargo.lock.
You would like to write a website that makes use of the database and client libraries. When you build your project, Cargo compiles each library's dependencies with the versions that are specified in the Cargo.lock. This means that database uses version 1.0.1 of string-tools and client uses version 1.0.2. But now imagine that you've written some code like this:
client::show_name(database::get_username(id));
This should compile. After all, the get_username function returns a string_tools::FastString, which is accepted by the show_name function. But it doesn't! That's because the FastString returned by get_username comes from version 1.0.1 of string_tools, while show_name wants a FastString from version 1.0.2! This can't work; after all, when the patch to string-tools for version 1.0.2 was written, it's possible that the author added an additional field to the type. There's nothing reasonable for the compiler to do.
This kind of issue is avoided by having Cargo ignore the Cargo.lock file on libraries. Instead what it does is compile both database and client against the 1.0.2 version of string_tools. This is correct because 1.0.1 and 1.0.2 are "semver compatible versions." That means it is ok to change out one for the other, things must still compile. Now you no longer get a compiler error, because the types that the one function returns and the other function accepts are no longer different.
It is my understanding that when using stack to compile a project, no version constraints for dependencies should go in the .cabal (or package.yaml) files, because the resolver picks specific versions for you. This includes the GHC version and its base library. However, when creating a new project with stack new, it automatically adds a version constraint to the dependency to base.
Excerpt of auto-generated package.yaml
dependencies:
- base >= 4.7 && < 5
Why is that?
I don't know the canonical answer. But here's one reason why it might be nice.
For what is currently the only realistic implementation of Haskell, namely, GHC, the base version and the compiler version are inextricably linked. This means that suitable base constraints also communicate which version of the compiler is intended to be used.
That latter piece is interesting information to know about a package at a glance.
Now, it's also true that stack resolvers and GHC versions are inextricably linked. So you might think that information is already available. BUT currently, Hackage (the place that most Haskell packages get hosted for use by others) displays a bunch of information taken from cabal files, but no information taken from stack files. So if you want the information about GHC version to be conveniently available from the autogenerated Hackage summary of the package, this is one way to easily and automatically do that.
I'm quite new to the Haskell stack, so I might be misunderstanding how things are intended to work here, but I have a problem that I've seen a few times and am wondering if I'm going about the wrong way.
In short, I sometimes want to use a package with a version spec that is capped at a lower version of base than what my Stack resolver includes.
For example, I can't use the lts-12.14 resolver with PSQueue-1.1, because the former includes base-4.11.1 and the latter requires base >=4 && <4.11.
The two ways I have found to resolve that has been to either
add a specific version of base to my extra-deps, making sure that the pinned version is within the range my package allows; or
choose a different resolver (using e.g. https://www.stackage.org/diff/ to figure out which one is the latest resolver with an early enough version of base)
Both of these feel suboptimal, especially since I might want to use packages which have non-overlapping ranges (e.g. one >=3 && <4.11 and one >=4.11). I realize that using such a combination toghether might fail, especially if they are locked on different major-versions of base (assuming base uses semver), but so far I'm only writing pretty small programs, so if they seem to work I'm quite happy even if there are other, non-exercised code paths that will fail on the specific combination of packages and versions. In other words: I know the risk - but I can't chance it, because I don't know how to.
Is there a way to force Stack to allow a newer version of base than the one specified in the requirements of a dependency?
I think you are looking for allow-newer - https://docs.haskellstack.org/en/stable/yaml_configuration/#allow-newer
Ignore version bounds in .cabal files. Default is false.
The Semantic Versioning Specification (SemVer) defines:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
So starting with 1.0.0 is considered stable.
When starting a project normally version 0.1.0 is used and gradually increased, there is a point where the project can have something like 0.20.3 for months/years and it is "stable".
Therefore would like to know what could be considered good practices to follow besides the criteria, arguments before bumping a project to server 1.0.0.
How you are dealing with this?
If there are not issues/code activity in 3 months the version is dumped?
The development team decides when they have version 1.0.0. It is possible for a project to remain in experimental/prototype mode for very long periods of time. The only thing that matters here is whether the interface and implementation can be considered complete or not. What are your goals? Do you have all the planned v1 features in place? Do you have doubts w.r.t. implementation conformance to the documented interface?
Some teams don't have workflows that map onto the full semver spec, but they use packaging/release tooling that requires a semver version string. In order to be legal, they never release version 1.0.0, so any version bumps literally don't have full SemVer semantics. See #4 in the spec.
When I see SomeLib.0.20.3.pkg I assume it is not stable. A breaking change can occur on the very next minor field bump, whether or not there have ever been any such changes in the past. SemVer is a contract that allows the SomeLib developers to break things without notice in this particular case.
There is nothing in the spec that precludes a team from issuing a 1.0.0 and then returning to a long sequence of 0.x.x releases if they so desire to operate that way. This is similar to, but not exactly the same as using prerelease tags. When you issue 1.0.1-prerelease you are at least implying intent to release a work derived from 1.0.0 that is a bug-fix, but the prerelease tag is warning label that you are not yet certain of the safety of the changes you made. Following on from 1.0.0 to a sequence of 0.x.x releases says you might not even be deriving from 1.0.0 anymore. Basically, all bets are off again.
If you require any further elucidation on this matter, please ask, I am happy to try to answer any questions regarding SemVer.
I follow a version scheme for a library with a version number of three parts and a so version of two parts. example-1.0.0 and libexample.so.1.0.
The last number in the version string is updated when I make changes without breaking the ABI. The second number is updated when I add new symbols and the major version number is used for incompatible changes.
The so version is updated when symbols are added even if it does not break compatibility with other programs. This means that programs need to be recompiled because the so version has changed even if the library still is ABI compatible with older versions.
Should I avoid updating the so version when I add new symbols?
This means that programs need to be recompiled because the so version has changed even if the library still is ABI compatible with older versions.
That means you are not doing it correctly. You should only change SONAME when doing ABI-incompatible change. It is customary to use example.1 as the SONAME. Documentation.
P.S. If you only care about Linux, you likely should stop doing external versioning altogether, and instead use symbol versioning to provide a single libexample.so.1 that provides multiple ABI-incompatible symbols to both old and new client binaries.