I need to test in the browser because I am using WebAudio. Okay, so since I'm using tape, I run
browserify -t babelify index.js | browser-run -p 3000
The problem is that I'm using Nitrous.io, so the test complains:
Error: Cannot find module '__mySource/models/audio' from '/home/nitrous/code/mrr/source/__mySource/test/audio/model/metronome'
So now I need I need to go into my code and customize all imports for the sake of Nitrous. So instead of
import {initialize} from '__mySource/models/audio';
I now need to hack all imports
import {initialize} from '/home/nitrous/code/mrr/source/__mySource/models/audio';
which is clearly unacceptable. Hopefully there is a simple fix for this problem.
Typically I recommend that developers should use relative paths (starting with a './' or '../') when importing or requiring files. Absolute paths can vary from machine to machine so those are also problematic.
It is possible to define aliases that act like pseudo-packages but those can be tricky to configure and are often more confusing to developers than just using the standard commonjs naming.
So try using relative paths for your imports (or requires) that don't refer to files inside another actual package.
Related
If I move ComponentFoo.js from folder X to folder Y, than a bunch of import statements break. Looking into this it seems there are many solutions for typescript, but what about js / es6? If I move a file in the editor, it should find all the import statements and update them to the new location. Is this possible?
Old post, but this might help some Googlers. This feature can be enabled and disabled in User Settings. For Javascript and Typescript, it's called "Updated Imports On File Move".
I had apparently disabled it and just figured the feature was broken :X
VS Code has built-in support for this for both javascript and typescript since VS Code 1.24.
For JavaScript specifically, you need to make sure VS code's language support can find all the references to the file so that imports referring symbols in that can be updated properly. Definitely create a jsconfig.json for your project, and also consider enabling semantic checking for JavaScript so that VS Code shows when imports are not being properly resolved
If your project is configured properly but files are not being updated, make sure you are running the latest VS Code insiders build and report an issue if it still doesn't work
for flutter developers you should move files one by one. vscode doesn't support multi file moving with refactor yet.
Just use IntelliJ. It handles all kinds of refactoring perfectly. I'm a huge fan of VS Code, but refacotoring is definetly not one of it's stengths. Some imports don't get detected, and the imports can get modified in a weird way. For example, I had an import like this:
import { myStore} from 'src/common/stores/myStore';
When moving the file of myStore.ts to a different folder, VS Code constructed this bull**it:
import { myStore} from 'src/common/composables/myStoreStore';
The line above is no typo!
Btw I'm using vetur, maybe thats causing it, I don't know ...
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.
Migrated existing webpack project to use webpack 3.5.5 and its new config. Using express server instead of webpack-dev-server.
I had to setup the resolve in webpack as below.
const resolve = {
extensions : ['.js'],
modules : [
'node_modules',
'src',
'testApplication'
]
};
When i debug this webpack application using chrome developer tools I can see the 2 versions of source files.
The first one under webpack://
It is exactly matching with the source
The second one under webpack-internal://
This one is the babel compiled version of the source.
My questions are
Is there someway where I get only a first version of the file instead of both?
I thought node_modules should have been implicitly defined as a module rather than me specifying it explicitly in resolve, is there someway that I can make the build work without having the node_modules defined in resolve.
After using the same source code with webpack 3.5.5(migrated it from webpack 1.14.0) the express server start seems to have slowed node. My guess is that having specified the node_modules in modules under resolve has caused it. Any ideas?
You can configure the source maps using Webpack's devtool property. What you want is devtool: 'source-map'(source). This will only show you the original source code under webpack://. Note that there are other options that might be more appropriate for your use case.
["node_modules"] is in the default value for resolve.modules. However, if you specify resolve.modules you need to include "node_modules" in the array. (source).
It seems strange that you specify "src" and "testApplication" in resolve.modules. If you have local source files you should require them using relative paths e.g. require("./local_module"). This should work without having src in resolve.modules
Specifying node_modules in resolve.modules is not responsible for any slow down (see 2.). There are many possible reasons the slow down. E.g. maybe you are erroneously applying babel to the whole node_modules folder?
It seems to be resolved (or at least greatly improved) in Chrome 66.
Sorry for the noob question but I'm trying to start up a new application with Sails and include my assets. I'm using Bower to manage my packages for things like Bootstrap and JQuery. I had a read of this question and added a .bowerrc file which is now installing my Bower components to /assets.
I'm now confused as to how I should proceed to add these files into my project. It seems as though I can't just do a <script> tag in the header as I'm used to because it's giving me a file not found. Reading through the sails documentation it seems like Grunt should be creating a .tmp/public/assets folder in my project, but whenever I run sails lift and go to .tmp/ there is nothing in there.
I also read in the documentation that I should be using some kind of asset injection, I tried adding this to my HTML and it seems like it doesn't do anything.
My other question is around how I go about referencing images in my HTML. Obviously I can't just do something like src='assets/images/image.png, how should I go about this? Is there something really obvious that I'm missing?
Sails use grunt tasks to do lot of things during lift and build. You can get much better look how everything work if you take some time and check what is inside Gruntfile.js from root of your sails project.
About your specific question here is some information:
- from sails docs: "In order to take advantage of asset injection, minification, and concatenation you must put your assets in folder under assets/linker". This exactly mean that everything what you will put inside assets/linker directory will be affected by grunt tasks during lift. It mean that all files/directories from linker will be copy to .tmp/public and also some of that files will be processed before saved to .tmp/public.
- About adding tags. If you take a look at Gruntfile.js you will find this variables: var cssFilesToInject = [...] and var jsFilesToInject = [...] which contain files that will be automatic added to layout header during sails lift.
- About your 'other question', yes you can do something like 'src='linker/images/image.png' if you move that files to linker directory (assets/linker).
I hope this help :).
So for a particular CGI perl script I have included JSON like this to handle some .json files:
use lib "./modules/JSON/lib";
use JSON;
This works fine and well. The web directory holds the files required in the modules folder.
However, the JSON module is very slow. I read that JSON:XS can be much, much faster but I can't seem to simply use it as so:
use lib "./modules/JSON-XS";
use JSON::XS;
There is no lib folder in the JSON-XS files, i've tried combinations of use (ie, using both folders and etc) but it didn't work.
And no I cannot simply install the module for this particular project.
Any help is appreciated.
And no I cannot simply install the module for this particular project.
You can't use a module without installing it. You've just been getting away with doing a half-assed job of it. That won't work for JSON::XS, though. The reason it's fast is because it's written in C, so you'll need to compile the C code. The easiest way by far to do this is to use the provided installer instead of reinventing the wheel.
(You do know you can install a module into any directory, and that this does not require special permissions, right?)
Perl distributions are usually usable in an uninstalled state. What you just need to do is to call perl Makefile.PL && make (or for a Module::Build-based distribution: perl Build.PL && ./Build). This will do all necessary compilations (if it's an XS module) and copy the library files into the blib subdirectory. In your script instead of use lib you would write use blib:
use blib "/path/to/JSON-XS";
Note that if a module has dependencies, then you have to resolve it yourself and add that many use blib statements. JSON::XS does not have that many dependencies, but it will be really inconvenient for other modules. In this case you should probably seek another solution, e.g. using CPAN.pm together with local::lib.
Okay this finally worked for me:
I did this process to all the dependencies (in the order of no dependencies to more dependencies)
export PERL5LIB = ~/path/to/modules/perl5
perl Makefile.PL PREFIX=$PERL5LIB LIB=$PERL5LIB
make
make test
make install
This installed all modules into a directory I called perl5. It also means that when you try to install other modules locally the dependencies issue does not appear due to the PREFIX/LIB additions.
Then all I did was add this to my perl CGI script:
use lib "./modules/perl5";
use JSON::XS;
PS: JSON::XS is so much faster!
:D