An error message in my browser has informed me that:
ClojureScript could not load :main, did you forget to specify :asset-path?
According to the documentation, :asset-path is a compiler option. What is the correct place in my leiningen configuration file for a compiler option such as :asset-path? It doesn't seem to work at the top level.
The project is freshly generated using this command:
lein new figwheel-main <name> -- --reagent
I'm hosting the website on my own server, with the output files hosted at /static/cljs-out, hence the need for the :asset-path option.
Leiningen version is 2.9.1, figwheel-main version is 0.2.16
The :asset-path option can be placed in the build specific configuration file, dev.cljs.edn in my case. This file is found in the project's root folder.
^{:watch-dirs ["test" "src"]
:css-dirs ["resources/public/css"]
:auto-testing true
}
{:main flaglib2.core
:asset-path "/static/cljs-out/dev"}
This answer is possibly specific to figwheel-main projects. The rules seem to be different for cljs-build projects, as per cfrick's comment above.
Related
I have a basic ReadTheDocs repository. As per the advice of the build page, I sought to use a .readthedocs.yml to configure it:
Configure your documentation builds! Adding a .readthedocs.yml file to your project is the recommended way to configure your documentation builds. You can declare dependencies, set up submodules, and many other great features.
I added a basic .readthedocs.yml:
version: 2
sphinx:
builder: dirhtml
fail_on_warning: true
and got a build failure:
Problem in your project's configuration. Invalid "sphinx.builder": .readthedocs.yml: Your project is configured as "Sphinx Html" in your admin dashboard, but your "sphinx.builder" key does not match.
This was surprising as it seemed contrary to the guidance in the admin dashboard at https://readthedocs.org/dashboard/PROJECTNAME/advanced/ which led me to assume that I could set whatever I liked in the admin dashboard, but it would be overridden by my .readthedocs.yml (which is the behaviour I expected and wanted):
These settings can be configured using a configuration file. That's the recommended way to set up your project. Settings in the configuration file override the settings listed here.
I updated the setting in the admin dashboard to match the .readthedocs.yml and then got a build error:
Sphinx error:
master file /home/docs/checkouts/readthedocs.org/user_builds/PROJECT_NAME/checkouts/latest/source/contents.rst not found
which looks like https://github.com/readthedocs/readthedocs.org/issues/2569 (RTD not finding Sphinx configuration) - but it's not clear why that's happening because prior to adding .readthedocs.yml, the project built just fine.
I'm struggling to model what's actually going on here:
The config file isn't acting as an "overlay" / "override" onto the web settings - as per the first error, some forms of disagreement are a build failure
It's almost like if the config file exists, the web config is ignored - this would explain the contents.rst issue arising, but this isn't consistent with the first error
Adding a python.install entry to .readthedocs.yml eventually got the site building, but it's still not clear to me if I'm generally doing the right thing, and/or how successful future config changes will be.
The reason you're getting the error is that the sphinx version you're using locally doesn't match with the version readthedocs is using at the time you initiated the build process.
See here: You can use a requirements.txt file to use the same version of sphinx you use locally. I had the same issue. I've solved it by simply adding my version Sphinx==3.1.2
Also, I added a .readthedocs.yml file in my project directory where docs/ resides, pointing to where the conf.py because
I was using an extension sphinxcontrib.napoleon which readthedocs build process fails to recognize.
Wanted readthedocsbuild process to use a specific version on Sphinx.
# .readthedocs.yml
# Read the Docs configuration file
# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
# Required
version: 1
# Build documentation in the docs/ directory with Sphinx
sphinx:
configuration: docs/source/conf.py
# Build documentation with MkDocs
#mkdocs:
# configuration: mkdocs.yml
# Optionally build your docs in additional formats such as PDF
formats:
- pdf
# Optionally set the version of Python and requirements required to build your docs
python:
version: 3.7
install:
- requirements: docs/requirements.txt
a
and added all the dependencies needed to generate the documentation in docs/requirement.txt
Babel==2.8.0
imagesize==1.2.0
readme-renderer==26.0
Sphinx==3.1.2
sphinx-argparse==0.2.5
sphinx-rtd-theme==0.5.0
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==1.0.3
sphinxcontrib-images==0.9.2
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-napoleon==0.7
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.4
I'm using PhpStorm's Command Line Tool Support for using Laravel's artisan as a "Tool based on Symfony console" as shown below:
Problem is I want to share this across all my projects (global scope). But if I hard code the path to /home/user/project/artisan in Tool path then it runs the that project's directory (not my currently open one). If I just put artisan it doesn't run.
Is there a template variable like $ProjectDir$ or something I can add in the Tool path?
I am working on MySQL optimization with another researcher and we are using git for version control. The problem is that each of us has to compile those sources on separate machines and running cmake . generates different versions of makefile on our machine. If we think about the following cases
1. A changes source
2. A runs cmake, builds the source, and test performance
3. B pulls the code change
4. B changes source, runs cmake and builds the source
After the step 4, B will have a different version of Makefile and files such as cmake_install.cmake that depend on users and user paths.
For example, some of the files have the following diffs.
# The program to use to edit the cache.
-CMAKE_EDIT_COMMAND = /usr/local/bin/ccmake
+CMAKE_EDIT_COMMAND = /usr/bin/ccmake
# The top-level source directory on which CMake was run.
-CMAKE_SOURCE_DIR = /home/dcslab/userA/mysql/mysql-5.6.21-original
+CMAKE_SOURCE_DIR = /home/dcslab/userB/mysql-5.6.21-original
# The top-level build directory on which CMake was run.
-CMAKE_BINARY_DIR = /home/dcslab/userA/mysql/mysql-5.6.21-original
+CMAKE_BINARY_DIR = /home/dcslab/userB/mysql-5.6.21-original
These are all user-dependent paths generated by cmake commands. The direct way to resolve this conflict is to untrack Makefiles or any file generated by cmake after initially committing them. I am wondering if there is any better and legit way of managing projects using cmake for more than one user. Thanks for your help in advance!
Files generated by CMake are machine-dependent, so they will not work on any machine except one where they has been generated. Because of that, they are useless on for others and there is no needs to track them in git. There are two ways for achive this:
Tune gitignore for ignore files, generated by CMake, on commit. Patterns for such files are relatively simple and can be found by googling. Disadvantage of this approach is that files, generated by project's CMake scripts (configure_file, add_custom_command) will not be automatically ignored and will require explicit notion in gitignore
Perform out-of-source builds, that is not run cmake from source directory. CMake generates additional files only in build directory, correct project's CMake scripts also should follow this rule. So git repo will be clean without any gitignore patterns.
It is common practice to perform out-of-source build in ./build subdirectory of source directory. In this case you can add /build/** to gitignore, and everything will work.
An important part of good engineering -- and especially in research -- is reproducability. It is unfortunate that the code you are working on can be influenced by the environment in which it is built (you may want to look at the Bazel for future projects to reduce external dependencies). Given that this code already has this external dependency problem, you can at least counter the effects by using a consistent environment via virtualization. In particular, you may want to take a look at Docker, which would allow you and your collaborators to build/run code using a common system image, thereby ensuring that all builds and executions are derived from a predictable, consistent environment.
I've installed caffe on a server a while ago, and back then it worked properly.
Now I'm following the LeNet MNIST tutorial again (http://caffe.berkeleyvision.org/gathered/examples/mnist.html), and running
./examples/mnist/create_mnist.sh
returns
build/examples/mnist/convert_mnist_data.bin: error while loading shared libraries: libglog.so.0: cannot open shared object file: No such file or directory
I've noticed that liibglog.so.0 is not in /lib which might be the reason for it, but I'm not allowed to copy that file into /lib directory, since I'm not a root user.
Is there workaround for this?
The easiest way to work around the lack of shared libraries in system directories is to use LD_LIBRARY_PATH with the directory where the shared library lives.
Before running the the command that requires a library, run the following in the following the same shell.
export LD_LIBRARY_PATH=~/local/lib
You can also stick this in your .bashrc for convenience.
An alternate solution is to use the following command line flag while compiling, but that requires mucking with other people's build scripts.
-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)
I'm new to JRuby, I installed it on windows 8, and I'm following it's wiki. When the wiki said to change a configuration option, it dose not say exactally where I can find the file where the option resides, it gives only its name but not the full path.
So is their a method that I can run on jirb to find the path to any configuration path.
thanks.
The .jrubyrc file is searched in your current directory (user.dir Java property), your home directory (user.home), and since you're on Windows, also in HOMEDRIVE\HOMEPATH, in this order (and the first one wins).