I am trying to migrate from version 0.8.1 to 0.9.1 in Scala js. Previously, if I wanted to have a user defined attribute in an element I did so as follows:
button("my-attribute".attr = "false")
But does no longer compiles in version 0.9.1. What is the correct approach now?
I'm not sure what library you were using, but it almost looks like ScalaTags. If so, the syntax you want is:
button(attr("my-attribute") := "false")
ScalaTags Docs
I vaguely recall that ScalaTags used to have the .attr syntax you describe – it definitely looks familiar, but I can't find it right now. Maybe it was removed... And it is definitely :=, not =.
Also, the only relevant library I know where 0.9.1 is a relevant version number is scala-js-dom, but that library doesn't provide anything like the example you're describing.
Related
I have seen some old questions/answers that said it's impossible to create a type alias on Flutter. I just want to make sure whether it's the case, as the language seems to have been updated numerous times since.
My specific question is, how can I make a type alias like this:
typealias Json = Map<String, dynamic>;
?
Or is there any workaround, because I've tried to use empty mixin to do this but it says that there are 18 missing method implementations.
Small update on Randai Schwartz's comment.
The feature seems (as of April 2021) almost ready and will probably be released in the next minor version or the one after it.
When you read this, it is probably worth checking the following issue:
https://github.com/dart-lang/language/issues/65
This should allow to do:
typedef NewTypeName = OldTypeName;
Update:
Flutter officially supports now typedefs. :)
So you can just use my code example above.
At this point, typedefs are supported only for Function types (https://dart.dev/guides/language/language-tour#typedefs). There is talk of adding more, but not any time soon (https://github.com/dart-lang/language/issues/115).
Flutter 2.2 has been released together with Dart 2.13, now SimonEritsch code should work as you wanted as long as you run flutter upgrade on your terminal or upgrade your dart.
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 am trying to use Casbah, I get a strange error right in the beginning, on this line:
val mongoDB = MongoConnection("MyDatabase")
the error on MongoConenction says:
class file needed by MongoConnection is missing. reference type
MongoOptions of package com.mongodb refers to nonexisting symbol.
I do not know what to do with this. The jars that I have attached to my projects are:
casbah-commons_2.9.1-3.0.0-SNAPSHOT.jar
casbah-core_2.9.1-3.0.0-SNAPSHOT.jar
casbah-gridfs_2.9.1-3.0.0-SNAPSHOT.jar
casbah-query_2.9.1-3.0.0-SNAPSHOT.jar
casbah-util_2.9.1-3.0.0-SNAPSHOT.jar
which looks like a full setup of Casbah and I do not understand what it might be yearning for. So there is the question number one - what do I have to do to resolve this problem?
The question number two is - the Casbah tutorial says that I could import just one thing, and get the mongoConn() method, which is also not truth. The mongoConn() simply does not get found if I follow the instructions. So, how can I acheive that everythong works as in the tutorial?
I don't know the details of your setup, but it seems like you are not referencing the dependencies of the casbah-commons module.
According to the docs, those are:
mongo-java-driver, scalaj-collection, scalaj-time, JodaTime, slf4j-api
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.
I searched the web for how to enforce srictfp in Scala but could not find any hint of it. There are some people complaining about it, but real solutions cannot be found. There is a bugtracker entry about it which is almost two years old. As it seems there is no elegant fix for it on the way I'm looking for workarounds.
My current idea is to set the appropiate method flag ACC_STRICT in the generated bytecode by myself somehow but I have no idea what would be the best solution to do so. A Scala Compiler Plugin comes to mind or just hacking flags in a hex editor. Maybe someone faced the same challenge and can tell me his or her solution?
You could add a post-processor in your build process that would add the strictfp modifier to the generated class (i.e. setting the ACC_STRICT flag as you say).
You can implement such a post-processor using Javassist for example. This could look like this:
CtClass clazz = ClassPool.getDefault().makeClass(
new FileInputStream("old/HelloWorld.class"));
CtMethod method = clazz.getDeclaredMethod("testMethod");
method.setModifiers(method.getModifiers() | Modifier.STRICT);
clazz.detach();
clazz.toBytecode(new DataOutputStream(new FileOutputStream(
"new/HelloWorld.class")));
You would then have to find a way to configure which classes/method need to be modified this way.
Scala has a strictfp annotation now:
#strictfp
def f() = …