The aurelia.json file has a bundles.source property. It appears to use the glob syntax that minimatch supports. The out-of-the-box au new template, though, includes square brackets around some patterns. E.g.
"[**/*.js]"
In my experience, square brackets have meant ranges, such as [a-z] mapping to abcdefg...wxyz. That is also what minimatch respects.
> match = require("minimatch");
> match("q", "[a-z]");
true
What do square brackets mean to the Aurelia CLI when processing the bundles.source property?
The brackets actually define whether or not we trace the dependencies of what we find based off the glob pattern. The double star pattern (**/*) is actually what defines the "search sub folders too" part of the pattern.
While it's documented in the section for configuring JSPM, it is also applicable for configuring with the CLI. documentation
Our goal is to create a bundle of our application code only. We have to somehow instruct the bundler not to recursively trace the dependencies. Guess what? [*.js] is how we do it.
[*.js] will exclude the dependencies of each module that the glob pattern *.js yields. In the above case it will exclude aurelia-framework, aurelia-fetch-client and so on.
For example, you'll make a pattern like this: [src/**/*.js], you are asking for every javascript file in the folder and every sub-folder of src without tracing any dependencies. This mean that if module A in src requires module B in test, then module B won't be included because we indicated with the brackets that we're not tracing dependencies.
Again, if you took a pattern like this: src/**/*.js, you are asking for every javascript file in the folder and every sub-folder of src including any dependencies of those files. This means that if module A in src requires module B in test, then module B will be included because we are including dependencies.
It is important to note that this is how Aurelia defines its dependencies. While we use glob patterns and minimatching, the bracket syntax (as far as I know) is not part of those libraries, but rather a way for Aurelia to quickly and easily define if we're tracing or not.
Related
I know that you can make a function file in Octave in which the file name is the same as the function which defines one function, but I would like to define multiple functions in one file. Is there any way to do this, or do I need a separate file for each function.
In this answer I will assume that your main objective is a tidy workspace rather than explicitly a one-file requirement.
Let's get the one-file approach out of the way. You can create a script m-file (not a function m-file), and define a number of command-line functions there. The octave manual has a section on this. Here's an example:
% in file loadfunctionDefinitions.m
1; % statement with side-effect, to mark this file as a script. See docs.
function Out = Return1(); Out = 1; end
function Out = Return2(); Out = 2; end
% ... etc
% in your main octave session / main script:
X = Return1() + Return2();
However, this is generally not recommended. Especially if you would require matlab compatible code, since matlab introduced 'script-local functions' much later than octave, and decided to do it in a manner incompatible to the existing octave implementation: matlab expects script-local functions to be defined at the end of the script; octave expects them to be defined before first use. However, if you use normal function files, everything is fine.
While I appreciate the "I don't like a folder full of functions" sentiment, the one-function-per-file approach actually has a lot of benefits (especially if you program from the terminal, which makes a wealth of tools twice as useful). E.g. you can easily use grep to find which functions make use of a particular variable. Or compare changes in individual functions from different commits, etc.
Typically the problem is more one of having such function files littering the directory, when other important files are present, e.g. data etc, and having so many files in one place makes finding what you want hard to spot, and feels untidy. But rather than have a single file with command-line definitions, there are a number of other approaches you can take, which are probably also better from a programmatic point of view, e.g.:
Simply create a 'helper functions' folder, and add it to your path.
Use subfunctions in your main functions whenever this is appropriate, to minimize the number of unnecessary files
Use a private functions folder
Use a 'package directory', i.e. a folder starting with the character '+', which creates a namespace for the functions contained inside. E.g. ~/+MyFunctions/myfun.m would be accessed from ~/ via MyFunctions.myfun(), without having to add +MyFunctions to the path (in fact you're not supposed to).
Create a proper class directory, and make your functions methods of that class
The last option may also achieve a one-file solution, if you use a newer-style classdef based class, which allows you to define methods in the same file as the class definition. Note however that octave-support for classdef-defined classes is still somewhat limited.
I wrote a library in Cython that has two different "modes":
If rendering, I compile using GLFW.
If not rendering, I compile using EGL, which is faster, but I have not figured out how to render with it.
What is the recommended way to handle this situation?
Right now, I have the following directory structure:
mujoco
├── __init__.py
├── simEgl.pyx
├── simGlfw.pyx
├── sim.pxd
└── sim.pyx
simEgl.pyx contains EGL code and simGlfw.pyx contains GLFW code. setup.py uses an environment variable to choose one or the other for the build.
This works ok, except that I need to recompile the code every time I want to switch between modes. There must be a better way.
Update
I agree that the best approach is to simultaneously compile two different libraries and use a toggle to choose which one to import. I already do have a base class in sim.pyx with shared functionality. However this base class must itself be compiled with the separate libraries. Specifically, sim.pyx depends on libmujoco.so which depends on either GLFW or EGL.
Here is my exhaustive search of possible approaches:
If I do not compile an extension for sim.pyx, I get ImportError: No module named 'mujoco.sim'
If I compile an extension for sim.pyx without including graphics libraries in the extension, I get ImportError: /home/ethanbro/.mujoco/mjpro150/bin/libmujoco150.so: undefined symbol: __glewBlitFramebuffer
If I compile an extension for sim.pyx and choose one set of graphics libraries (GLFW), then when I try to use the other set of graphics libraries (EGL) this does not work either unsurprisingly:
ERROR: GLEW initalization error: Missing GL version
If I compile two different versions of the sim.pyx library, one with one set of libraries, one with the other, I get: TypeError: unorderable types: dict() < dict() which is not a very helpful error message, but appears to result from trying to share a source file between two different extensions.
Something like option 4 should be possible. In fact, if I were working in raw C, I would simply build two shared objects side by side using the different libraries. Any advice on how to get around this Cython limitation would be very welcome.
(This answer is just a summary of the comments with a bit more explanation.)
My initial suggestion was to create two extension modules defining a common interface. That way you pick which to import in Python but be able to use them in the same way once imported:
if rendering:
import simGlfw as s
else:
import simEgl as s
s.do_something() # doesn't matter which you imported
It appears from the comments that the two modules also share a large chunk of their code and its really just the library that they're linked with that defines how they behave. Trying to re-use the same sources with
Extension(name='sim1', sources=["sim.pyx",...)
Extension(name='sim2', sources=["sim.pyx",...)
fails. This is because Cython assumes that the module name will be the same as the filename, and so creates a function PyInit_sim (on Python 3 - Python 2 is named slightly differently but the idea is the same). However, when you import sim1.so it looks for the function PyInit_sim1, fails to find it, and gives an error.
An easy way round it is to put the common code in "sim.pxi" and use Cython's largely obsolete include mechanism to textually include that code in sim1.pyx and sim2.pyx
include "sim.pxi"
Although include is generally no longer recommended and cimport is preferred since it provides more "Python-like" behaviour, include is a simple solution to this particular problem.
How can I use a different React version with Reagent, Om, Rum, Quiescent or Brutha?
Self answer since this is asked frequently:
First you have to tell Leiningen to exclude the cljsjs/react dependencies:
[rum "0.6.0" :exclusions [[cljsjs/react] [cljsjs/react-dom]]]
If you have other dependencies pulling in cljsjs/react you can use a global exclusion:
:exclusions [[cljsjs/react] [cljsjs/react-dom]]
Next you have to satisfy the compiler since it won't find the namespaces cljsjs.react and cljsjs.react.dom. For this create two files that hold these namespaces in your source directory. For instance
- src/cljsjs/react.cljs
- src/cljsjs/react/dom.cljs
Both only need the namespace declaration and can otherwise be empty (ns cljsjs.react).
Now you can include any React version you'd like manually in your HTML file with a normal <script> tag.
Alternative:
You can also use foreign-libs compiler option.
I have two libraries libA and libB.
libA contains a file Action.h
libB contains a file action.h
I want to generate doxygen documentation in the same output directory for both libraries. This directory is to be used in Windows, for which action.html and Action.html is unfortunately considered to be the same file. To prevent this clash, I wish to render the generated files unique by prepending their path names to them.
Therefore, I set FULL_PATH_NAMES to YES.
I expect to see something like libA_Action.html and libB_action.html when I generate the documentation, but I don't! I still see Action.html and action.html. Its as if the FULL_PATH_NAMES parameter does nothing at all. Do I also need to set some other parameter in the Doxyfile to make the FULL_PATH_NAMES parameter work correctly?
You're probably running doxygen twice - one time for each library. If that is the case, doxygen isn't aware of the fact that it might clash with an output from another run, so when it find an existing file, it assumes that it is leftover from a previous run, and overrides it.
Setting FULL_PATH_NAMES doesn't help, as doxygen has no idea that multiple libraries exist, so, as far as doxygen is concerned, the prefix is identical to all files, so even when you adding a force it, it adds nothing (That's probably a bug).
The solution to your problem is setting both libraries as inputs to the same doxygen project.
You can do it by setting INPUT to multiple folders in the configuration file:
INPUT = ...bla\Lib1 \
...bla\Lib2
I tried to build a shared library using wx and STL, and failed in an error of "multiple definition of". Please refer to:
https://code.google.com/p/gppanel/issues/detail?id=7
The declaration of wxPointListNode is not found in the sources. The suspicious lines are like these:
include/mathplot.h:85:WX_DECLARE_LIST(wxPoint, PointList);
include/mathplot.h:87:WX_DEFINE_LIST(PointList);
include/gpLineLayer.h:16:typedef std::deque<mpPointLayer*> mpPointList_t;
What the problem is?
Without the actual code this is just a guess, but I suspect that
include/mathplot.h:87:WX_DEFINE_LIST(PointList);
generates the full definition of PointList, including a non-templated method wxPointListNode::DeleteData. mathplot.h is included by all of the .cpp files (gpPanel.cpp, gpSeries.cpp, and baseData.cpp). Each cpp file is compiled into a .o file, so each has its own definition of DeleteData, and when you try to link the .o files together into lib/libgpPanel.so the linker issues the errors you're reporting.
The definition of the method needs to be in its own cpp file that's compiled and linked in.
All wxWidgets methods with DEFINE in their name expand into a definition of something and a definition can only be used once in a module, so it typically can't appear in a header file (unless you can guarantee that it's included by only a single source file). So just don't put it there.
Moreover, if this is your code, you should avoid using the legacy WX_DECLARE_LIST macro at all and just use std::list<> or std::vector<> instead. Or, if you really want to use only wx (which can only be important if you are targeting some embedded platform without good STL implementation), then use wxVector<>.