I checked out the latest plovr and added closure to my project using bower. while compiling the code with closure-compiler.jar in advanced_compilation works without any error or warning, using plovr gives the following errors:
/closure/goog/ui/buttonrenderer.js:107: WARNING - goog.ui.ButtonRenderer.base is never defined
var element = goog.ui.ButtonRenderer.base(this, 'createDom', button);
^
/closure/goog/ui/menu.js:425: WARNING - goog.ui.Menu.base is never defined
var handled = goog.ui.Menu.base(this, 'handleKeyEventInternal', e);
^
/closure/goog/ui/menu.js:447: WARNING - goog.ui.Menu.base is never defined
goog.ui.Menu.base(this, 'setHighlightedIndex', index);
^
/closure/goog/ui/select.js:61: WARNING - goog.ui.Select.base is never defined
goog.ui.Select.base(this, 'constructor',
^
/closure/goog/ui/select.js:142: WARNING - goog.ui.Select.base is never defined
goog.ui.Select.base(this, 'handleMenuAction', e);
^
I have set closure library in config.js using
"closure-library": "bower_components/closure-library/closure/goog/",
is there a way to solve this?
This is a mismatch that is bound to happen when an updated Library is used along with a stale Compiler release (Plovr is known to get behind compiler releases). These particular warnings are about .base not being supported by the Compiler release bundled with Plovr. .base was introduced as an alternative to goog.base and the superClass_ property to comply with ES5 strict when expressing inheritance (no poking arguments.callee).
Here are a few options:
Use the closure-library bundled with Plovr
Grab Plovr's source; replace closure-compiler and build with ant build (I have personally not tried this recently)
The Medium team maintain their own Plovr fork, which is more in line with recent Closure Compiler releases. Since you're in a node environment, you can try with NPM: npm install plovr --save-dev (I use this fork personally with an updated vanilla Library checkout)
Related
After updating my deno version to 1.9 today I had started having the following problem when running my tests or my scripts:
TS2729 [ERROR]: Property 'boundary' is used before its initialization.
readonly dashBoundary = encoder.encode(`--${this.boundary}`);
~~~~~~~~
at https://deno.land/std#0.63.0/mime/multipart.ts:266:52
'boundary' is declared here.
constructor(reader: Deno.Reader, private boundary: string) {
~~~~~~~~~~~~~~~~~~~~~~~~
at https://deno.land/std#0.63.0/mime/multipart.ts:269:36
I checked and I am not using the mime repository anywhere in my code, instead some other repositories must use it.
I am using the following repositories:
x/abc
std/uuid
std/fs
std/path
std/fmt
std/testing
I made sure that I am explicitely using the newest version for all of the imports of the std library (std version 0.93.0).
When I am running the files that are importing the std library (instead of running the entire application) no errors occur.
Does anyone have an idea how to resolve the error?
It seems like the repository x/abc was the problem.
I did not add a version when importing it implicitly. When importing implicitly it in the following way it worked:
import abc from "https://deno.land/x/abc#v1.3.1/mod.ts";
I generate code with the scalaxb-sbt plugin that, when compiled, generates a good number of warning messages. Is there any way to hide compilation warnings for generated code or by package?
The silencer compiler plugin allows to suppress compiler warnings. It supports filtering out files by path. This will filter out all generated files from warnings:
scalacOptions += "-P:silencer:pathFilters=src_managed"
For Scala 2.12.13+ or 2.13.2+
Recent versions of the Scala compiler integrate the silencer plugin, see configurable warnings.
So now you don't need any plugin, just add the following line to build.sbt:
ThisBuild / scalacOptions += "-Wconf:src=src_managed/.*:silent"
Using this option will suppress warnings for generated code that lives under a directory called src_managed anywhere in your source tree.
This solved my problem with code generated by zio-grpc, where the compiler emitted warnings like parameter value evidence$3 in method live is never used (adding this info only for better searchability).
In your sbt console you could try the following:
set logLevel in compile := Level.Error or eventually set logLevel in sourceGenerators := Level.Error
and experiment with different settings. Once you are happy you could apply this setting in your build.sbt.
More detailed information can be found in the sbt documentation: http://www.scala-sbt.org/release/docs/Howto/logging.html
I found that I needed to do set logLevel in Compile := Level.Error in my sbt console session in order for this to work. This is with a capital C in Compile. This is with sbt version 0.13.11. This is also to turn all warnings off, though.
Put the code in a subproject, and set scalacOptions differently in that project? Whether this will work depends on whether the support even exists in scalac for suppressing the particular kind of warning you are getting. See for example https://issues.scala-lang.org/browse/SI-1781 . What kind of warnings are you needing to suppress exactly? Certain warnings like unchecked warnings can be suppressed with e.g. #unchecked without having to do the subproject thing.
So I have a Q_OBJECT tagged class, which requires pregenerated .moc to be usable.
In my .qbs file, I have a CppApplication item; this seems to be the wrong type of project, as qbs does not call moc ClassName.cpp to generate moc's for me. What should be used instead/tweaked?
-
So I knew about Qt.core dependency, but it wasn't working on my crippled install of Qt; while I was trying to fix it, these facts came up:
It was required to detect Qt toolchain (qbs-setup-qt) and call qbs-config-ui
Qbs indeed stores the build rules in core.qbs, linked in via Qt/core dependency.
it's possible to copy/paste the build rules into my own .qbs file and avoid external dependencies; I'm considering this as a dirty hack for deploying the code on really crippled build systems (now I have a word for Qt support on Gentoo).
I think you might be missing the dependency of the application on the Qt-modules.
The rule for generation of the moc files is part of the Qt.core module.
You might add this dependency with:
CppApplication {
name: "MyApp"
files: "path_to_source/**"
Depends { name: "Qt.core" } // Optional
Depends { name: "Qt.widgets" }
}
As all other Qt modules have an implicit dependency on Qt.core the explicit dependency could on Qt.core could be skipped if there is a dependency on a different Qt-module (Qt.widgets in this example).
More details could be found at http://doc.qt.io/qbs/qt-modules.html
Background: I've got a Play 2.0 project, and I am trying to add something to do aspectj weaving using aspects in a jar on some of my classes (Java). (sbt-aspectj doesn't seem to do it, or I can't see how). So I need to add a custom task, and have it depend on compile. I've sort of figured out the dependency part. However, because I don't know exactly what I'm doing, yet, I want to develop this using the IDE (I'm using Scala-IDE). Since sbt projects (and therefore Play projects) are recursively defined, I assumed I could:
Add the eclipse plugin to the myplay/project/project/plugins.sbt
Add the sbt main jar (and aspectj jar) to myplay/project/project/build.sbt:
libraryDependencies ++= Seq(
"org.scala-sbt" % "main" % "0.12.2",
"aspectj" % "aspectj-tools" % "1.0.6"
)
Drop into the myplay/project
Run sbt, run the eclipse task, then import the project into eclipse as a separate project.
I can do this, though the build.scala (and other scala files) aren't initially considered source, and I have to fiddle with the build path a bit. However, even though I've got the sbt main defined for the project, both eclipse IDE and the compile task give errors:
> compile
[error] .../myplay/project/Build.scala:2: not found: object keys
[error] import keys.Keys._
[error] ^
[error] .../myplay/project/SbtAspectJ.scala:2: object Configurations is not a member of package sbt
[error] import sbt.Configurations.Compile
[error] ^
[error] .../myplay/project/SbtAspectJ.scala:3: object Keys is not a member of package sbt
[error] import sbt.Keys._
[error] ^
[error] three errors found
The eclipse project shows neither main nor aspectj-tools in its referenced-libraries. However, if I give it a bogus version (e.g. 0.12.4), reload fails, so it appears to be using
the dependency.
So,...
First: Is this the proper way to do this?
Second: If so, why aren't the libs getting added.
(Third: please don't let this be something dumb that I missed.)
If you are getting the object Keys is not a member of package sbt error, then you should check that you are running sbt from the base directory, and not the /project directory.
sbt-aspectj
sbt-aspectj doesn't seem to do it, or I can't see how.
I think this is the real issue. There's a plugin already that does the work, so try making it work instead of fiddling with the build. Using plugins from build.scala is a bit tricky.
Luckily there are sample projects on github:
import sbt._
import sbt.Keys._
import com.typesafe.sbt.SbtAspectj.{ Aspectj, aspectjSettings, compiledClasses }
import com.typesafe.sbt.SbtAspectj.AspectjKeys.{ binaries, compileOnly, inputs, lintProperties }
object SampleBuild extends Build {
....
// precompiled aspects
lazy val tracer = Project(
"tracer",
file("tracer"),
settings = buildSettings ++ aspectjSettings ++ Seq(
// stop after compiling the aspects (no weaving)
compileOnly in Aspectj := true,
// ignore warnings (we don't have the sample classes)
lintProperties in Aspectj += "invalidAbsoluteTypeName = ignore",
// replace regular products with compiled aspects
products in Compile <<= products in Aspectj
)
)
}
How do you do develop an SBT project, itself?
If you're interested in hacking on the build still the first place to go is the Getting Started guide. Specifically, your question should be answered in .scala Build Definition page.
I think you want your build to utilize "aspectj" % "aspectj-tools" % "1.0.6". If so it should be included in myplay/project/plugins.sbt, and your code should go into myplay/project/common.scala or something. If you want to use IDE, you have have better luck with building it as a sbt plugin. That way your code would go into src/main/scala. Check out sbt/sbt-aspectj or sbt/sbt-assembly on example of sbt plugin structure.
I created a gradle build file for a Flex swc project, which compiles successfully in intellij IDEA.
My project contains dependency
internal group: 'org.as3commons', name: 'as3commons-logging', version: '2.7', ext: 'swc'
Compilation fails, with errors like
....\lib\as3commons-logging-2.7.swc(org.as3commons.logging.integration:SLF4ASIntegration)
Error: Type was not found or was not a compile-time constant: [com.furusystems.logging.slf4as.bindings]::ILogBinding.
I see that logging library indeed contains references to interfaces from other libraries, but in the IDE somehow it passes compilation and even works.
Which gradlefx option should I set?
Solved!I changed dependency configuration from 'internal' to "merged"!
cool :)
Also, we have a support forum for GradleFx which you can find here: http://support.gradlefx.org/home