I'm playing with command model binding and I looked at the example github project and I have issues when using the dependency:
"org.scalatra" % "scalatra-data-binding" % "2.2.0-RC1"
Taking the example project code i.e.
abstract class TodosCommand[S](implicit mf: Manifest[S]) extends ModelCommand[S] with ParamsOnlyCommand
class CreateTodoCommand extends TodosCommand[Todo] {
val name: Field[String] = asType[String]("name").notBlank.minLength(3)
}
case class Todo(id: Integer, name: String, done: Boolean = false)
I am unable to compile when I use the command[CreateTodoCommand] method from the CommandSupport trait i.e.
scala: type arguments [au.com.xxx.sapi.seo.CreateTodoCommand] do not conform to method command's type parameter bounds [T <: SeoServlet.this.CommandType]
val cmd = command[CreateTodoCommand]
^
I'm not that clued up with Scala but I would assume that as ParamsOnlyCommand extends Command and there is this line in the command support trait, then there should be no issues:
type CommandType <: org.scalatra.databinding.Command
Any ideas why I am getting this issue?
Cheers, Chris.
It's very likely that the reason you're having problems is that we're still linking to an ancient example version, for which the docs no longer apply. I thought I'd caught all of the example projects in the docs and moved them into https://github.com/scalatra/scalatra-website-examples, but apparently I missed this one. Sorry for the hassle!
I'll see if I can fix this today sometime, and provide a compiling example. In the meantime, you might try updating all your Scalatra-related dependencies to the 2.2.0 release - and see if that fixes anything straight away.
The latest stable release of Scalatra is currently 2.2.1, but you'll need to be careful around commands as I remember #casualjim saying that he'd changed the way things worked to some extent between 2.2.0 and 2.2.1.
In Scalatra 2.2.1, "org.scalatra" %% "scalatra-commands" % "2.2.0" I have no issues. but I don't know scalatra-data-binding is also standalone.
Related
it is appearing in some big modules like matplotlib. For example expression :
import importlib
obj = importlib.import_module('matplotlib')
obj_entries = obj.__dict__
Between runs len of obj_entries can vary. From 108 to 157 (expected) entries. Especially pyplot can be ignored like some another submodules.
it can work stable during manual debug mode with len computing statement after dict extraction. But in auto it dont work well.
such error occures:
RuntimeError: dictionary changed size during iteration
python-BaseException
using clear python 3.10 on windows. Version swap change nothing at all
during some attempts some interesting features was found.
use of repr is helpfull before dict initiation.
But if module transported between classes like variable more likely lazy-import happening? For now there is evidence that not all names showing when command line interpriter doing opposite - returning what expected. So this junk of code help bypass this bechavior...
Note: using pkgutil.iter_modules(some_path) to observe modules im internal for pkgutil ModuleInfo form.
import pkgutil, importlib
module_info : pkgutil.ModuleInfo
name = module_info.name
founder = module_info.module_finder
spec = founder.find_spec(name)
module_obj = importlib.util.module_from_spec(spec)
loader = module_obj.__loader__
loader.exec_module(module_obj)
still unfamilliar with interior of import mechanics so it will be helpfull to recive some links to more detail explanation (spot on)
I have a simple Chapel program to test the NetCDF module:
use NetCDF;
use NetCDF.C_NetCDF;
var f: int = ncopen("ppt2020_08_20.nc", NC_WRITE);
var status: int = nc_close(f);
and when I compile with:
chpl -I/usr/include -L/usr/lib/x86_64-linux-gnu -lnetcdf hello.chpl
it produces a list of errors about SysCTypes:
$CHPL_HOME/modules/packages/NetCDF.chpl:57: error: 'c_int' undeclared (first use this function)
$CHPL_HOME/modules/packages/NetCDF.chpl:77: error: 'c_char' undeclared (first use this function)
...
Would anyone see what my error is? I tried adding use SysCTypes; to my program, but that didn't seem to have an effect.
Sorry for the delayed response and for this bad behavior. This is a bug that's crept into the NetCDF module which seems not to have been caught by Chapel's nightly testing. To work around it, edit $CHPL_HOME/modules/packages/NetCDF.chpl, adding the line:
public use SysCTypes, SysBasic;
within the declaration of the C_NetCDF module (around line 50 in my copy of the sources). If you would consider filing this bug as an issue on the Chapel GitHub issue tracker, that would be great as well, though we'll try to get this fixed in the next release in any case.
With that change, your program almost compiles for me, except that nc_close() takes a c_int argument rather than a Chapel int. You could either lean on Chapel's type inference to cause this to happen:
var f = ncopen("ppt2020_08_20.nc", NC_WRITE);
or explicitly declare f to be of type c_int:
var f: c_int = ncopen("ppt2020_08_20.nc", NC_WRITE);
And then as one final note, I believe you should be able to drop the -lnetcdf from your chpl command-line as using the NetCDF module should cause this requirement to automatically be added.
Thanks for bringing this bug to our attention!
I'm having problem understanding how to correctly set the COMPILE_DEFINITIONS target properti in CMake.
my target is add_library(modelutilities STATIC ${modelutilities_SRCS})
I if use
set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} ${Qt5Widgets_COMPILE_DEFINITIONS})
set_target_properties(modelutilities PROPERTIES
VERSION "0.0.1"
SOVERSION 0
EXPORT_NAME "ModelUtilities"
ARCHIVE_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
LIBRARY_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
RUNTIME_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/bin"
COMPILE_DEFINITIONS ${modelutilities_COMPILE_DEFINE}
)
everything works fine, but if I add another line between them with set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} MODELUTILITIES_LIB) it stops working complaining that set_target_properties was called with the wrong number of arguments.
Anyone can spot what I'm doing wrong?
P.S.
I already tried using doublequotes: set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} "MODELUTILITIES_LIB"). It did not change anything
P.P.S.
If I message(STATUS ${modelutilities_COMPILE_DEFINE}) QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB in the first case and QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB;MODELUTILITIES_LIB in the second
With newer version of CMake, what is being preached is the idea of targets. So, for example, instead of include_directories() it's now preferred to use target_include_directories().
That being the case I think you'd be better served using the preferred target_compile_definitions() to set compile definitions for your utilities library.
One advantage you get is that your can scope your compile definitions using the PUBLIC or PRIVATE keywords.
I would like to share a common version variable between an sbtPlugin and the rest of the build
Here is what I am trying:
in project/Build.scala:
object Versions {
scalaJs = "0.5.0-M3"
}
object MyBuild extends Build {
//Use version number
}
in plugins.sbt:
addSbtPlugin("org.scala-lang.modules.scalajs" % "scalajs-sbt-plugin" % Versions.scalaJs)
results in
plugins.sbt:15: error: not found: value Versions
addSbtPlugin("org.scala-lang.modules.scalajs" % "scalajs-sbt-plugin" % Versions.scalaJs)
Is there a way to share the version number specification between plugins.sbt and the rest of the build, e.g. project/Build.scala?
sbt-buildinfo
If you need to share version number between build.sbt and hello.scala, what would you normally do? I don't know about you, but I would use sbt-buildinfo that I wrote.
This can be configured using buildInfoKeys setting to expose arbitrary key values like version or some custom String value. I understand this is not exactly what you're asking but bear with me.
meta-build (turtles all the way down)
As Jacek noted and stated in Getting Started Guide, the build in sbt is a project defined in the build located in project directory one level down. To distinguish the builds, let's define the normal build as the proper build, and the build that defines the proper build as meta-build. For example, we can say that an sbt plugin is a library of the root project in the meta build.
Now let's get back to your question. How can we share info between project/Build.scala and project/plugins.sbt?
using sbt-buildinfo for meta-build
We can just define another level of build by creating project/project and add sbt-buildinfo to the (meta-)meta-build.
Here are the files.
In project/project/buildinfo.sbt:
addSbtPlugin("com.eed3si9n" % "sbt-buildinfo" % "0.3.2")
In project/project/Dependencies.scala:
package metabuild
object Dependencies {
def scalaJsVersion = "0.5.0-M2"
}
In project/build.properties:
sbt.version=0.13.5
In project/buildinfo.sbt:
import metabuild.Dependencies._
buildInfoSettings
sourceGenerators in Compile <+= buildInfo
buildInfoKeys := Seq[BuildInfoKey]("scalaJsVersion" -> scalaJsVersion)
buildInfoPackage := "metabuild"
In project/scalajs.sbt:
import metabuild.Dependencies._
addSbtPlugin("org.scala-lang.modules.scalajs" % "scalajs-sbt-plugin" % scalaJsVersion)
In project/Build.scala:
import sbt._
import Keys._
import metabuild.BuildInfo._
object Builds extends Build {
println(s"test: $scalaJsVersion")
}
So there's a bit of a boilerplate in project/buildinfo.sbt, but the version info is shared across the build definition and the plugin declaration.
If you're curious where BuildInfo is defined, peek into project/target/scala-2.10/sbt-0.13/src_managed/.
For the project/plugins.sbt file you'd have to have another project under project with the Versions.scala file. That would make the definition of Versions.scalaJs visible.
The reason for doing it is that *.sbt files belong to a project build definition at the current level with *.scala files under project to expand on it. And it's...turtles all the way down, i.e. sbt is recursive.
I'm not sure how much the following can help, but it might be worth to try out - to share versions between projects - plugins and the main one - you'd have to use ProjectRef as described in the answer to RootProject and ProjectRef:
When you want to include other, separate builds directly instead of
using their published binaries, you use "source dependencies". This is
what RootProject and ProjectRef declare. ProjectRef is the most
general: you specify the location of the build (a URI) and the ID of
the project in the build (a String) that you want to depend on.
RootProject is a convenience that selects the root project for the
build at the URI you specify.
My proposal is to hack. For example, in build.sbt you can add a task:
val readPluginSbt = taskKey[String]("Read plugins.sbt file.")
readPluginSbt := {
val lineIterator = scala.io.Source.fromFile(new java.io.File("project","plugins.sbt")).getLines
val linesWithValIterator = lineIterator.filter(line => line.contains("scalaxbVersion"))
val versionString = linesWithValIterator.mkString("\n").split("=")(1).trim
val version = versionString.split("\n")(0) // only val declaration
println(version)
version
}
When you call readPluginSbt you will see the contents of plugins.sbt. You can parse this file and extract the variable.
For example:
resolvers += Resolver.sonatypeRepo("public")
val scalaxbVersion = "1.1.2"
addSbtPlugin("org.scalaxb" % "sbt-scalaxb" % scalaxbVersion)
addSbtPlugin("org.xerial.sbt" % "sbt-pack" % "0.5.1")
You can extract scalaxbVersion with regular expressions/split:
scala> val line = """val scalaxbVersion = "1.1.2""""
line: String = val scalaxbVersion = "1.1.2"
scala> line.split("=")(1).trim
res1: String = "1.1.2"
In application.conf (in Play 2.0.4, sbt 0.11.3) I could use following substitutions:
app {
major = 0
minor = 1
revision = 62
date = 0127
version = ${app.major}.${app.minor}.${app.revision}.${app.date}
}
After upgrade to Play 2.1.0 and sbt 0.12.2 and using this suggestion for Build.scala,
val conf = ConfigFactory.parseFile(new File("conf/application.conf"))
I get error when I do play clean:
Caused by: com.typesafe.config.ConfigException$NotResolved: need to call resolve() on root config; tried to get value type on an unresolved substitution: ConfigSubstitution(${app.major}"."${app.minor}"."${app.revision}"."${app.date})
at com.typesafe.config.impl.ConfigSubstitution.valueType(ConfigSubstitution.java:54)
at com.typesafe.config.impl.DefaultTransformer.transform(DefaultTransformer.java:15)
at com.typesafe.config.impl.SimpleConfig.findKey(SimpleConfig.java:118)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:135)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:140)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:108)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:146)
at com.typesafe.config.impl.SimpleConfig.getString(SimpleConfig.java:188)
at ApplicationBuild$.<init>(Build.scala:12)
at ApplicationBuild$.<clinit>(Build.scala)
Based on Play Configuration documentation this kind of substitution should be supported:
Implementations must take care, however, to allow objects to refer to
paths within themselves. For example, this must work:
bar : { foo : 42,
baz : ${bar.foo}
} Here, if an implementation resolved all substitutions in bar as part of resolving the substitution ${bar.foo}, there would be a
cycle. The implementation must only resolve the foo field in bar,
rather than recursing the entire bar object.
Any ideas how to fix this?
Your syntax is correct. It seems that you actually need to call resolve() as the error message says, to resolve substitutions. I guess in 2.0.x the play framework did this and provided a config that was already resolved this way. Now that the config API is used directly it needs to be resolved manually.
Add a call to resolve() in this line:
val conf = ConfigFactory.parseFile(new File("conf/application.conf")).resolve()
AFAIK, my understanding of the doc is that you should use something like:
app {
major = 0
minor = 1
revision = 62
date = 0127
version = ${major}.${minor}.${revision}.${date}
}
I did not test it...
And maybe it worked under 2.0.4 because of a bug ?