I recently upgraded Android studio to Dolphin 2021.3.21 with following settings.
kotlin G plugin:1.7.10
com.android.tools:r8:3.3.75
Android G plugin : 7.2.2
and using Java 11
When I rebuild my project it's failing and the reason is:
Task :app:l8DexDesugarLibQaDebug FAILED
Warning: Human desugared library specification format version 200 mismatches the parser expected version (100). This is allowed and should happen only while extending the specifications.
Error: java.lang.IllegalStateException: This is not a JSON Array.
Human desugared library specification format version 200 mismatches the parser expected version (100). This is allowed and should happen only while extending the specifications.
java.lang.IllegalStateException: This is not a JSON Array.
I too had the same situation.
If you are implementing the following two libraries, I solved it when I lowered the version as below.
implementation 'androidx.appcompat:appcompat:1.5.1'
coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.1.5'
Related
I try to build IoT Edge module termo sensor from the Microsoft sources. When I build project, I got the error:
"Error CS1061 'DeviceClient' does not contain a definition for
'SetInputMessageHandlerAsync' and no accessible extension method
'SetInputMessageHandlerAsync' accepting a first argument of type
'DeviceClient' could be found (are you missing a using directive or an
assembly reference?)"
Then I created IoT Edge module from the scratch, compare assembly version and start building the module and everything was built ok.
I follow to the DeviceClient class from the VS 2017 IDE for the app which is built ok.
But when I follow to the DeviceClient class in the application with building problem - I saw, that there is no such method.
I compare assembly version - it's equal.
I found the problem. In the module from the scratch is used ModuleClient instead of DeviceClient in the Microsoft Sources. :-)
I'm playing around with using Swagger / OpenAPI docs/specs to generate REST API client code in C#, but I'm running into several problems.
Most notably - when trying to use the Swagger.io Petstore example as a starting point:
Using the VS 2017 Add > REST API client option in VS 2017, I don't get any code produced - instead an error is shown:
Generating client code and adding to project started
Generate client code for REST API with following parameters:
REST API Name: OpenApiClientClient, Base namespace: OpenApiClient, Metadata file path: C:\Users\Marc\AppData\Local\Temp\WebToolsAutoRest\OpenApiClientClient\201807162213351660\swagger.json
[Info]AutoRest Core 0.16.0.0
[Info]Initializing modeler.
[Info]Initializing modeler.
[Info]Parsing swagger json file.
[Info]Generating client model from swagger model.
[Fatal]Error generating client model: Collection format "multi" is not supported (in parameter 'status').
Exception: There was an error during code generation when trying to add a client for the REST API
Generating client code and adding to project failed
Adding REST API client for failed
So if the Swagger sample app isn't compatible - how will others be?? (and I tried a few others, all with the same results, unfortunately).
What's wrong here? Am I missing something, do I need to add some extra tooling to VS 2017 to make this work?
UPDATE:
OK, so I now tried to install Autorest using npm directly:
npm install -g autorest
This appears to work - no errors shown or anything.
But trying to run Autorest - with a set of command line parameters, or even just on its own - results in an error:
AutoRest -CodeGenerator CSharp -Modeler Swagger
-Input https://petstore.swagger.io/v2/swagger.json
-Namespace Services.UserServiceClient -OutputDirectory d:\projects
-AddCrendentials true
or just
AutoRest <kbd>Enter</kbd>
results in:
AutoRest code generation utility [version: 2.0.4280; node: v9.9.0]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
Failure:
Error: Unable to start AutoRest Core from C:\Users\Marc.autorest\#microsoft.azure_autorest-core#2.0.4280\node_modules\#microsoft.azure\autorest-core
Error: Unable to start AutoRest Core from C:\Users\Marc.autorest\#microsoft.azure_autorest-core#2.0.4280\node_modules\#microsoft.azure\autorest-core
at main (C:\Users\Marc\AppData\Roaming\npm\node_modules\autorest \dist\app.js:232:19)
at
Any further ideas?
Visual Studio 2017 is using a very old version of AutoRest. The issue you are seeing is this one which was fixed in AutoRest v. 1.0. As explained in the comments in that issue:
Are you referring to the autorest version that's built-into visual studio? -- That's incredibly old, and we didn't update that (we've changed the whole way autorest works).
You are going to need to install node and use autorest from the command line.
Looks like it's not possible to update AutoRest used by Visual Studio 2017, so you'll need to call AutoRest directly.
I also had this problem so I built a tool for it called REST API Client Code Generator. I worked in teams where we used tools like AutoRest, NSwag, and Swagger Codegen to generate our REST API Clients and it always annoyed me that the "Add New - REST API Client..." tooling in Visual Studio didn't always work and was very troublesome when it was time to re-generate the client
This would add the OpenAPI specification file (Swagger.json) to the project and set a custom tool so that every time changes are made to it the REST API Client code is re-generated. You can also right click on the Swagger.json file and switch code generators
I built the tool mainly for personal use and for use within my teams but if you find it useful and think it lacks something you really need then please reach out
Try running autorest --reset. This worked on windows with node v8.12.0. Prior to running that command I was getting the same error.
I'm currently trying to convert xml files to a completely different format, using IntelliJ Community Edition +Saxon to write and debug the stylesheet.
I have already Saxon-HE 9.7.0-5 as the top-most module dependency.
Running the stylesheets with the XSLT-Runner works just fine, but when I try to debug it, I get some errors.
When I specify no VM arguments I get:
java.lang.UnsupportedOperationException: Unsupported Transformer: net.sf.saxon.jaxp.TransformerImpl
at org.intellij.plugins.xsltDebugger.rt.engine.local.LocalDebugger.prepareTransformer(LocalDebugger.java:98)
at org.intellij.plugins.xsltDebugger.rt.engine.local.LocalDebugger.<init>(LocalDebugger.java:51)
at org.intellij.plugins.xsltDebugger.rt.engine.remote.DebuggerServer$1.<init>(DebuggerServer.java:55)
at org.intellij.plugins.xsltDebugger.rt.engine.remote.DebuggerServer.<init>(DebuggerServer.java:55)
at org.intellij.plugins.xsltDebugger.rt.engine.remote.DebuggerServer.create(DebuggerServer.java:71)
at org.intellij.plugins.xsltDebugger.rt.XSLTDebuggerMain.start(XSLTDebuggerMain.java:53)
at org.intellij.plugins.xslt.run.rt.XSLTRunner.main(XSLTRunner.java:143)
When I specify the VM-Arguments
-Dxslt.transformer.type=saxon
as recommended here, I get the following error:
javax.xml.transform.TransformerException: The URI http://www.w3.org/2005/xpath-functions does not identify an external Java class
Has anyone else experienced this?
IntelliJ IDEA Supports Saxon 9 Debugging up to Saxon 9.3.0.11.
As of Saxon 9.4.0.0 the net.sf.saxon.lib.TraceListener interface introduced braking changes net.sf.saxon.lib.TraceListener#open() => net.sf.saxon.lib.TraceListener#open(Controller) that got never adapted by JetBrains.
Since Maven artifacts for 9.3 are hard to come by you might want to manually get it from from SF.
https://sourceforge.net/projects/saxon/files/Saxon-HE/9.3/
Regarding your stack trace; It has a different story but ultimately results in going back to 9.3.
As of today, 9.3 seems to be the latest version that works with the current IntelliJ 2017.1.2 version.
I have written and built an R package that depends on Rcpp and requires the C++0x standard (for using the tgamma function in C++). I have tested the package on various desktop computers and operating systems, and it always seems to install and work fine. However, I would also like to use the package on an HPC server. When I try to install the package there in my local R library tree using R CMD INSTALL test (where test is the name of the package), I get the following error message from the compiler:
/usr/include/c++/4.4.7/c++0x_warning.h(31): catastrophic error: #error directive: This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
#error This file requires compiler and library support for the upcoming \
^
compilation aborted for Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.cpp (code 4)
make: *** [Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.o] Error 4
ERROR: compilation failed for package ‘test’
It basically tells me that I should enable C++0x support when the compiler is called (as in this post). Yet, I thought adding the statement CXX_STD = CXX11 to the src/Makevars file in the R package would actually tell the compiler that this version needs to be used. And indeed that seems to be the case on various desktop computers I have tried. So my question is: how can I tell the compiler on the server that this C++ version should be used for compilation? Alternatively, how else can I install the package?
On the server, I load the module for R by entering module load math/R on the terminal before trying to install the package, and it reports back that the following modules were loaded:
Loading module dependency 'compiler/intel/13.1'.
Loading module dependency 'numlib/mkl/11.0.5'.
Edit 1: The server is a German university cluster called bwUniCluster. It is based on KITE 2.0/RHEL6.5/Lustre 2.5.2. As far as I can tell from the module message reported above, it seems to be the Intel C++ Compiler XE (ICPC) version 13.1.3. But actually I have no clue about compilers, so if you need to know anything more specific, please let me know.
Edit 2 It's also possible to execute module load compiler/gnu/4.9 on the terminal before I try to install the package. This results in the following error message (similar as the one above), which leads me to think that this is not a version problem:
/pfs/data1/software_uc1/bwhpc/common/compiler/gnu/4.9.2/bin/../include/c++/4.9.2/bits/c++0x_warning.h(32): catastrophic error: #error directive: This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
compilation aborted for Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.cpp (code 4)
make: *** [Metropolis_Sampler_Beta_Edgewise_Cpp_Statistics.o] Error 4
ERROR: compilation failed for package ‘test’
Edit 3: One of the comments suggests that both the R package and R itself need to be compiled using the same compiler version. Is this correct? R was built using g++ 4.4.7 on this machine. Does this mean that the only feasible solution is to convince the sys admin to recompile R with the other 4.9.2 compiler and provide it as a new module? I find this hard to believe, given the following sentence in the "Writing R Extensions" manual:
On these platforms, it is necessary to select a different compiler for C++11, via personal or site Makevars files.
The solution was indeed to recompile R on the server with a newer compiler, in this case Intel 14 (as discussed in Edit 3 in the original post). The sys admin was so kind to set up a new module for this R version.
At my end, I have the following setup
C:>where play
C:\apps\play-2.2.0\play
C:\apps\play-2.2.0\play.bat
C:>where scala
C:\apps\scala\bin\scala
C:\apps\scala\bin\scala.bat
Scala -version > Scala code runner version 2.10.2 -- Copyright 2002-2013, LAMP/EPFL
Play - version >
play 2.2.0 built with Scala 2.10.2 (running Java 1.7.0_21), http://www.playframework.com
This is not a play application!
Use play new to create a new Play application in the current directory,
or go to an existing application and launch the development console using play.
You can also browse the complete documentation at http://www.playframework.com.
When I run at my play prompt > reload, update, I get following error
[error] Modules were resolved with conflicting cross-version suffixes in {file:/C:/<filepat>}<appname>:
[error] org.scala-stm:scala-stm _2.10, _2.10.0
[trace] Stack trace suppressed: run last *:update for the full output.
[error] (*:update) Conflicting cross-version suffixes in: org.scala-stm:scala-stm
[error] Total time: 7 s, completed Oct 18, 2013 1:33:41 PM
[modelingApp] $
After adding the follwoing in Build.scala
"dependencyGroupId" %% "dependencyArtifactId" % "dependencyVersion" exclude("org.scala-stm", "scala-stm_2.10.0")
Get following error
[trace] Stack trace suppressed: run last *:update for the full output.
[error] (*:update) sbt.ResolveException: unresolved dependency: dependencyGroupId#dependencyArtifactId_2.10;dependencyVersion: not found
[error] Total time: 8 s, completed Oct 18, 2013 1:22:18 PM
[modelingApp] $
The issue is that the only means of detecting scala version mismatch in sbt is via this artifact extension "_".
This particular issue is that the version of scala-stm that Play is depending on is declaring it is ONLY compatible with scala 2.10.0, whereas your build says it can take anything from the 2.10.x series. sbt is issuing a warning that these are different.
In practice, the scala-stm artifact is actually safe to use, it's just misconfigured on publish (documentation error at the time I believe). So in this case, it's safe to ignore the error. however, in general, this error should be taken seriously. It's very possible that different Scala binary version numbers declared on artifacts may lead to RUNTIME errors (not compile time) that insidiously sneak into your code.
You can use the conflictWarning key to control how this message is logged. I believe if you want to ignore the warnings completely (not recommended, as most should be legitimiate issues), then you can use this setting:
conflictWarning := ConflictWarning.disable
Also, I believe this is a duplicate of this question: Conflicting cross-version suffixes in: com.twitter:util-core
It is a known issue on Play:
Conflicting cross-version suffixes in: org.scala-stm:scala-stm
Maybe you use play slick that is not ready for Play 2.2.
Try
"com.typesafe.play" %% "play-slick" % "0.5.0.2-SNAPSHOT"
Or if it is another lib that has a dependency to Play 2.1.x, try
//replace the name and versions with that of your library
//since Scala 2.10.0 do not put the minor version into the artifact name:
//scala-stm_2.10 instead of scala-stm_2.10.0
"the lib vendor" %% "name" % "version" exclude("org.scala-stm", "scala-stm_2.10.0")
I had the same error when upgrading from Play 2.1.* to Play 2.2.*. The project included secureSocial which also needed to be updated to Play 2.2.
"securesocial" %% "securesocial" % "2.1.0"
to
"ws.securesocial" %% "securesocial" % "2.1.3"
See Secure Social Installation Documentation
It depend on your scala version, for example i use:
"com.typesafe.akka" % "akka-remote_2.11" % "2.3.6"
for scala 2.11.1.
You can find appropriate version from this link.