The MongoEnvironmentSetter#setLatencySmoothFactor method updates the system property com.mongodb.latencySmoothFactor and it isn't available since 2.12.0 ( related git hashes 0375c984fccf9cb0868b406c145f8fd3e263348c 1ae976fa2342cdddeade622f293dc3fccbb80a58). I found the following tickets related to that:
https://jira.mongodb.org/browse/JAVA-763
https://jira.mongodb.org/browse/JAVA-786
https://jira.mongodb.org/browse/JAVA-859
https://jira.mongodb.org/browse/JAVA-930
https://jira.mongodb.org/browse/JAVA-931
But I didn't find the equivalence to this property. Any thoughts? Which are the steps to do in a migration if some application has configured this property?
There is no equivalent in 2.12, as the driver no longer performs any smoothing of round-trip times. Smoothing may be added in a future release, but most likely it won't be configurable. I'm not sure what the MongoEnvironmentSetter is, but assuming this is something you control, your best option is to ignore that property or remove it.
Related
I am trying to pass a parameter to ksy file. The parameter is of type another ksy file. The reason is that i need to access all the fields from the ksy file passed as parameter.
Is that possible?
If yes, would you please provide me with syntax code snippet so I can mimic it.
If no, what would be another solution?
Thank You.
Affiliate disclaimer: I'm a Kaitai Struct maintainer (see my GitHub profile).
First, I recommend always using the development version of the Kaitai Struct Web IDE (https://ide.kaitai.io/devel/), not the stable one. The stable IDE deployed at https://ide.kaitai.io/ has KS compiler of version 0.8, which is indeed the latest stable version, but already 2 years old at the moment. But the project is under active development, new bug fixes and improvements are coming every week, so the stable Web IDE is pretty much outdated. And thanks to the recent infrastructure enhancement, the devel Web IDE now gets rebuilt every time the compiler is updated, so you can use even the most recent features.
However, you won't be able to simulate the particular situation you describe in the Web IDE, because it can't currently handle top-level parameteric types (there is no hook where you can pass your own values as arguments). But it should work in a local environment. You can compile the commontype.ksy and pty.ksy specs in the Web IDE to the target language you want to use (the manual shows how to do it). The code putting it together could look like this (Java):
Commontype ct = new Commontype(new ByteBufferKaitaiStream(new byte[] { 80, 75 }));
Pty r = new Pty(
new ByteBufferKaitaiStream(new byte[] { 80 }), // IO stream
ct // commonword
);
Note that the actual parameter order of the Pty constructor may be different, e.g. in Python come the custom params (commonword) first and then the IO object. Check the generated code in your particular language.
Are #babel/runtime and #babel/plugin-transform-runtime supposed to be on the same version (e.g. both 7.2.0 exactly)? Or can I (as a library author) specify #babel/runtime dependency as ^7.0.0, whilst having the latest #babel/plugin-transform-runtime?
I'm aware that during the beta versions of Babel 7, there was a breaking change in beta.56 (see https://stackoverflow.com/a/51686837/2148762), but I'm guessing this should no longer be the case with the current stable version?
The reason I ask this is I'd ideally want the helpers from #babel/runtime to be shared across different packages, and to me leaving the version range open seems like a good idea. But at the same time, I'm not sure how low I should go (^7.0.0 or ^7.2.0), and whether there's an implicit contract between #babel/runtime and #babel/plugin-transform-runtime with regards to version numbers.
By default, #babel/plugin-transform-runtime is only allowed to output references to #babel/runtime that work on ^7.0.0 because it does not know what version you'd otherwise want to use, and doing anything else would cause lots of issues for users. This means that what you want to do is safe. The downside of this is that, if we add new helpers moving forward, your code would not be able to take advantage of the #babel/runtime version of them (because you might still be using a #babel/runtime version that doesn't have them.
Users can specify the version in the arguments for the transform, if you want to specifically make use of helpers that may have been added to Babel since 7.0.0, e.g.
{
"plugins": [
["#babel/plugin-transform-runtime", { version: "^7.2.0" }],
]
}
would then require you to have "#babel/runtime": "^7.2.0" in your package.json.
For instance, since support for the newer decorators proposal didn't land until Babel 7.1.5, if you use transform-runtime and non-legacy decorators, the decorators helper will still be inserted into every file where you use decorators, instead of importing it from #babel/runtime. To get the shared helper, you need to specify version: "^7.1.5" in your options for transform-runtime.
Can I (as a library author) specify #babel/runtime dependency as ^7.0.0, whilst having the latest #babel/plugin-transform-runtime?
Yes, this is safe.
I'm guessing this should no longer be the case with the current stable version?
Correct, that issue was because people failed to take the beta versioning into account.
I have a question related to V4L-DVB drivers. Following the
Building/Compiling the Latest V4L-DVB Source Code link, there are 3 ways to
compile. I am curious about the last approach (More "Manually
Intensive" Approach). It allows me to choose the components that I
wish to build and install using the "make menuconfig". Some of these components (i.e. "CONFIG_MEDIA_ATTACH") are used in pre-processor directives that define a function in one shape if defined, and a function in another if not defined (i.e.
dvb_attach, dvb_detach) in the resulting modules (i.e. dvb_core.ko)
that will be loaded by most of the DVB drivers. What happens if there are two
drivers (*.ko modules) on the same host machine, one that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH defined and another that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH undefined, is there a clean way to handle this?
What is also not clear to me is: Since the V4L compilation environment seems very customizable (by setting the .config file), if I develop a driver using V4L-DVB structures, there is a big chance that it has conflicts with other drivers since each driver has its own custom settings. Is my understanding correct?
Thanks!
Dave
I have found the following information in paper by Andrew Reynolds and co -authors "Model Finding for Recursive Functions in SMT"
"If CVC4’s finite model finding mode for recursive functions is enabled (using the command-line option
--fmf-fun)"
But I have install current version of CVC4, --fmf-fun is not available in CVC4?Can you please guide me in this.
The option --fmf-fun is not available in the latest stable release (1.4), however, it is available in the latest development release.
You can download the latest development version of CVC4 at http://cvc4.cs.nyu.edu/downloads/ (on the right of the page).
I'm trying to convert a persistence layer from a plain old database (using ScalaQuery) to MongoDB, and I'm running into an odd issue. I use the Casbah driver, which is a Scala wrapper around the official MongoDB Java driver. Both the Java and Scala driver define - according to the docs and the overview of the .jar when I open it in Eclipse - a method findOneById that takes a single DBObject as parameter (with an ID in it).
However, when I try to access it, I get a missing method exception from the Scala compiler, both in Eclipse and SBT - Scala version 2.9.0-1, SBT 0.10.1.
What might cause this? Is this perhaps a known SBT / Scala compiler bug?
I just removed my entire repository so all dependencies get downloaded freshly, but this didn't fix the problems.
Are you sure that you call findOneById on a MongoCollection instance ?
Maybe it's the parameter type that is wrong, as I can see on the documentation (http://api.mongodb.org/scala/casbah/2.1.2/scaladoc/com/mongodb/casbah/MongoCollection.html), findOneById should take an Id of type AnyRef and optionnaly the fields to return.
You should try something like mongoCollection.findOneByID(1.asInstanceOf[Object]).
Regarding BBObject, it seems that it doesn't appear in the list of parameter (except as an implicit parameter useful to convert the fields that you request to a DBObject). Maybe the signature of the method changed since a previous release.
Hope this will help.