Following github I added this dependency to my leiningen project file:
[net.mikera/core.matrix.stats "0.5.0"]
Then in my clojure code I use this:
(use 'core.matrix.stats)
The result is this:
FileNotFoundException Could not locate core/matrix/stats__init.class or core/matrix/stats.clj on classpath: clojure.lang.RT.load (RT.java:443)
I examined the lein .m2/respository directory and the file core/matrix/stats-0.5.0.jar is there and does contain stats.clj. I re-did lein deps, but still the file-not-found exception. Has anyone else had this difficulty? I could use Incanter, but for this simple project core.matrix.stats is enough.
Looking at the sources, the namespace seems to be clojure.core.matrix.stats, so try this:
(use 'clojure.core.matrix.stats)
(And yes, the README seems to be outdated.)
Related
Versions
Cypress version: 8.4.0
Preprocessor version: 4.2.0
Node version: 12.18.2
Hi all, apologies if this is a stupid question, I'm quite new/noob with cypress, let alone cypress + cucumber.
So I wrote some automation tests in cucumber, and they work fine. I have the feature files in the integration folder, and the step definition folders in the integration folder too. Now I'm trying to have some structure where under integration I have a folder named step_definitions (will show better in screenshot).
folder structure
In package.json I put the following:
"cypress-cucumber-preprocessor": { "nonGlobalStepDefinitions": true, "nonGlobalStepBaseDir": "step_definitions", "commonPath": "common", "stepDefinitions": "step_definitions" }
When I try to run the tests, I get the below error:
Error: We've tried to resolve your step definitions at step_definitions, but that doesn't seem to exist. As of version 2.0.0 it's required to set step_definitions in your cypress-cucumber-preprocessor configuration. Look for nonGlobalStepDefinitions and add stepDefinitions right next to it. It should match your cypress configuration has set for integrationFolder. We no longer rely on getting information from that file as it was unreliable and problematic across Linux/MacOS/Windows especially since the config file could have been passed as an argument to cypress.
Any pointers are appreciated :)
It seems to me that the problem in your case in "stepDefinitions": "step_definitions" have you tried to give the full path like "stepDefinitions": "cypress/integration/step_definitions"?
You should set nonGlobalStepDefinitions to false or remove this setting, as you don't have a separate folder for the step_definitions but it is inside the integration folder instead.
So, in order to use your structure, please modify that section in the package.json file to:
"cypress-cucumber-preprocessor": {
"commonPath": "cypress/integration/step_definitions/common",
"stepDefinitions": "cypress/integration/step_definitions"
}
That would be enough. It works.
We're running eXist-db version 3.0 and want to try running XProc within it.
We found that the XProcxq Module is now part of eXist: http://exist-db.org/exist/apps/doc/extensions.xml#module_xprocxq
However, in attempting to use it we get the error below and wondered if anyone had suggestions for where we could be going wrong?
As specified at the top of the module page linked to, we added the module to the conf.xml file and restarted eXist. (This could be where we went wrong, but that's a guess on our part)
This is what the module we added looks like in conf.xml:
<module uri="http://xproc.net/xproc" class="org.exist.xquery.modules.xprocxq.XProcxq/>
Here is the simple started XQuery I've attempted to use:
xquery version "1.0" encoding "UTF-8";
import module namespace const = "http://xproc.net/xproc/const";
import module namespace xproc = "http://xproc.net/xproc";
import module namespace u = "http://xproc.net/xproc/util";
declare variable $local:XPROCXQ_EXAMPLES := "/db/examples"; (:CHANGE ME:)
let $stdin :=document{<test>Hello World</test>}
let $pipeline :=document{
<p:pipeline name="pipeline"
xmlns:p="http://www.w3.org/ns/xproc"
xmlns:c="http://www.w3.org/ns/xproc-step">
<p:identity/>
</p:pipeline>
}
return
xproc:run($pipeline,$stdin)
Here is the error:
error found while loading module xproc: IO exception while loading module 'http://xproc.net/xproc' from 'http://xproc.net/xproc'
I posed your question to the exist-open mailing list (where I'd encourage you to join for future eXist-db questions), and it appears XProc support in eXist is currently between a rock and a hard place. The xprocxq library you mentioned is woefully underdeveloped (abandoned by its original creator), and the much better developed Calabash module is incompatible with the current version of Saxon used in eXist, due to a dependency on that version of Saxon. I'd welcome you to join exist-open to discuss further. Perhaps there's some other workaround for you.
It needs to be rebuilt.
According to http://exist-db.org/exist/apps/wiki/blogs/eXist/eXist30RC1
EXPath packages that incorporate Java libraries may no longer work with eXist 3.0 and may need to be recompiled for our API changes; packages should now explicitly specify the eXist versions that they are compatible with.
I am working on the update to the XProc EXPath module.
The XMLCalabash module for eXist has now been rebuilt for a newer version of eXist and Calabash and should work with eXist 3.0.RC1.
To build your own Jar package for eXist 3.0.RC1 run:
$ git clone https://github.com/eXist-db/eXist-XMLCalabash.git
$ cd eXist-XMLCalabash
$ rm -rf src/test
$ mvn package
The Jar is then in the target/ folder. You should copy it to $EXIST_HOME/lib/user modify $EXIST_HOME/conf.xml to load the module and then restart eXist.
Updated
The XML Calabash module for eXist, now also has a PR so that it will support the upcoming eXist 3.0.RC2 -
https://github.com/eXist-db/eXist-XMLCalabash/pull/2
However you cannot built it remotely until eXist 3.0.RC2 is released.
Is there a way to link with a library that's not in the current package path.
This link suggests placing everything under the local directory. Our packages are installed in some repository elsewhere. I just want to specify the libpath to it on windows.
authors = ["Me"]
links = "CDbax"
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
But trying cargo build -v gives me
package `hello v0.1.0 (file:///H:/Users/Mushfaque.Cradle/Documents/Rustc/hello)` specifies that it links to `CDbax` but does not have a custom build script
From the cargo build script support guide, it seems to suggest that this should work. But I can see that it hasn't added the path. Moving the lib into the local bin\x68_64-pc-windows-gnu\ path works however.
Update
Thanks to the answer below, I thought I'd update this to give the final results of what worked on my machine so others find it useful.
In the Cargo.toml add
links = "CDbax"
build = "build.rs"
Even though there is no build.rs file, it seems to require it (?) otherwise complains with
package `xxx v0.1.0` specifies that it links to `CDbax` but does not have a custom build script
Followed by Vaelden answer's create a 'config' file in .cargo
If this is a sub crate, you don't need to put the links= tag in the parent crate, even though it's a dll; even with a 'cargo run'. I assume it adds the dll path to the execution environment
I think the issue is that you are mistaking the manifest of your project with the cargo
configuration.
The manifest is the Cargo.toml file at the root of your project. It describes your project itself.
The cargo configuration describes particular settings for cargo, and allow for example to override dependencies, or in your case override build scripts. The cargo configuration files have a hierarchical structure:
Cargo allows to have local configuration for a particular project or
global configuration (like git). Cargo also extends this ability to a
hierarchical strategy. If, for example, cargo were invoked in
/home/foo/bar/baz, then the following configuration files would be
probed for:
/home/foo/bar/baz/.cargo/config
/home/foo/bar/.cargo/config
/home/foo/.cargo/config
/home/.cargo/config
/.cargo/config
With this structure you can specify local configuration per-project,
and even possibly check it into version control. You can also specify
personal default with a configuration file in your home directory.
So if you move the relevant part:
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
to any correct location for a cargo configuration file, it should work.
I'm having trouble getting the lobos database migrations library for Clojure to play with the maven-clojure-plugin and Maven-style project structure. Lobos looks for database migrations in the lobos.migrations namespace. If I layout the project Leiningen style:
src/
lobos/
migrations.clj
lobos correctly finds lobos.migrations at run time, when run via lein. However, if I lay out the project Maven-style:
src/
main/
clojure/
lobos/
migrations.clj
and use the maven-clojure-plugin to run the same tests, lobos no longer finds lobos.migrations. I thought this was an issue with the clojure-maven-plugin, but I have the same issue (lobos not finding lobos.migrations) if I run via leon, setting the source paths in project.clj appropriately:
:source-paths ["src/main/clojure"]
If I move lobos/ back under src/ and add src/ as a source path:
:source-paths ["src" "src/main/clojure"]
then lobos correctly finds lobos.migrations again.
I would like to use a Maven-style project layout (and eventually the maven-clojure-plugin). How can I help lobos find lobos.migrations? Where have I gone wrong?
The lobos.migration/*src-directory* variable indicates the source root for finding source for the *migrations-namespace*. If lobos.migration/*reload-migrations* is true (the default), then lobos.migrations looks for the migrations namespace in this source directory. The default is src/, so it needs to be rebound to src/main/clojure in order to use a Maven-style directory structure.
One other notable issue: when running from a JAR (i.e. not from source), you must disable reloading of the migrations namespace as well:
(binding [lobos.migration/*reload-migrations* false]
;; run migration
)
You need to change the dynamic variable lobos.migration/*migrations-namespace*. This is documented here: https://github.com/budu/lobos#migrations.
I'm going through the Spring MVC tutorial. I have a build.xml and build.properties file as well as a simple jsp file. When I try to run ant, I get this error:
Buildfile: /<home>/dev/Spring/springapp/build.xml
BUILD FAILED
/<home>/dev/Spring/springapp/build.xml:85: taskdef class org.apache.catalina.ant.InstallTask cannot be found
using the classloader AntClassLoader[/usr/local/apache-tomcat/current/lib/catalina-ant.jar]
Total time: 0 seconds
I looked in the catalina-ant.jar file, and sure enough there is no InstallTask class. Did this jar file change, since the spring tutorial was written? If so, where can I find the InstallTask.
The tutorial you are following is out of date - the InstallTask has been deprecated in favour of the DeployTask.
Newer distributions no longer include the deprecated class. You should be able to revise your buildfile simply by changing 'Install' to 'Deploy', something like:
<taskdef name="install" classname="org.apache.catalina.ant.DeployTask">