I'm using NetBeans 6.5 and I have some javascript files that it claims are binary files and won't display annotations. svn propedit shows that the svn:mime-type is text/javascript and to display the annotations on the command line I have to run "svn annotate --force file.js".
from http://subversion.tigris.org/svn_1.4_releasenotes.html:
svn blame --force Displays the output
of blame, even if the file is binary.
It looks like this is not a NetBeans-specific problem, but something related to how svn handles Your .js files. It would be good to add a proper tag to this question.
from http://subversion.tigris.org/faq.html#binary-files:
Subversion just looks at the first
1024 bytes of the file; if any of the
bytes are zero, or if more than 15%
are not ASCII printing characters,
then Subversion calls the file binary.
(...) Subversion treats the following
files as text: (...) Files with a
svn:mime-type starting "text/"
If Your javascript file contains binary data, You might consider moving it to the end of the file.
There is a chance that the property is set to " text/javascript" or something that looks like text/javascript to human, but not to the svn.
There is a chance that the file used to be binary, but it's not anymore, however You have updated Your repository while not having write access to .svn/ directory (and svn still 'thinks' the file is binary).
There is a chance You have changed the property to the right one, but have not commited it yet.
Finally, the most powerfull solution to svn problems I have ever encountered was to copy the file, delete it the from svn, commit, add the file back (from the copy) and commit. Beware: You loose change history by doing so.
I wish You good luck on finding out what has caused this problem!
Related
is there a way to convert or something like "dehash" "dist" folder in angular to its dependencies files?
I lost my source of project and don't have any idea how to get back my source :(
nothing I could yet . I tried nothing.plz help if there is a way
I am not aware of any tools that provide such functionality. As you essentially want to reverse the compilation step, it would be pretty hard because many of the information present in source files get removed because they are only relevant for the compilation (i.e. config files, meta data, etc.).
Usually you would use git or a similar version control system and thus never loose anything.
As per the documentation of ammo.js, it says:
The most straightforward thing is if you want to write your code in C++, and run that on the web. If so, then compile your code into LLVM, link it with bullet, and compile that to JavaScript using emscripten.(The easiest way to link it is to add your .bc file to the llvm-link command in make.py.)
So how can I compile the following code written in C++ into LLVM bitcode, link it and run it on web? BulletHelloWorld example
How can I link it in make.py? Is it necessary to always use the ammo.idl file even if I want to compile a specific program and not want to expose the entire bullet library to JavaScript?
Link to make.py
So lets start with the basics. Incase you donot know about make and cmake, study it before proceeding.
First you need to build the Bullet Library from source to use it on the web. From what I can see, you need to pass in flags to build it independent of python. Study these flags and see what is required by you.
The Bullet Library is using cmake to generate the build files - so first get a makefile out of cmake and then you can “emcc make” the generated makefile.
The output of this step ie a .bc file, is to be “linked” to the output of the next step.
Now the example.cpp that you want to compile depends on some headers of the Bullet Library. So while compiling your main.cpp file you will need to pass the em++ binary the path to these headers. This once compiled should generate your main.bc
Now you need to call em++ again, but with the main.bc along with the .bc from the previous step as parameters and also provide the required output file ie js/html. In one sense we are now linking all the “.bc” files to generate js/html.
Lookout for some missing symbol “warnings” as that could mean your code wont run.
Btw all this is available on the official emscripten website, so incase of confusion you should refer it.
With the aid of node-google module I wrote a simple node module to enable a 'text web search' feature to my web app, presenting results in one of my views.
Since after a quite small number of queries from the same IP Google returns a 503 error, I decide to use the module on the client, so the limit is per client, not per server.
I did use browserify to convert the node module to a script to be sourced in a client page.
The script just requires 'google.js', and it's just 20 lines of javascript long:
'use strict';
var google = require('google');
var Google = Object.create({});
var Google.search = function(text, callback) {
...
});
// end of the script
The command I use is simply:
$ browserify google-search-module.js -o app/scripts/google-search.js
The problem is that the output browserify produces is far bigger than I did expect: a 1.2 kB module becomes a 2.4 MB script! Probably it's including all 'google' dependencies, too, but..,
The question is: is this normal? Is my search page expected to load a 2.4 MB file just to search some text on Google?
I'm quite sure I'm missing something, but can't understand what... :-(
That is expected behaviour. Browserify loads all modules imported with require() recursively, and outputs a single file. There are ways around this, but they are unlikely to work in your paticular case.
Normally, with Browserify, you might work with one huge bundle in development, but then build a much smaller production version. If you were using jQuery, for example, you could install the package locally into your node_modules folder. Then, for production, you could set the --exclude flag to have Browserify ignore anything in your node_modules folder, instead relying on a CDN to deliver jQuery to the client.
I say this is unlikely to work in your case because node-google really is a Node module. There is no guarantee that it will work in the browser (it may or may not). You really should determine if it is working before you start planning your next line of attack.
If it is working, you have two possible remedies:
Minify your bundle and make sure it is served gzipped. The resulting file size will likely be fewer than 100kB, if you can live with that.
Find some other module for doing a Google search, or implement one of your own. This is probably the best solution unless you must use node-google for some reason.
Of course, if it isn't working in the browser anyway, only the second solution is available.
I was trying to install node_mouse and when I looked in my node modules folder and instead of a normal .js file extension, I found a .node file extension. How could I run node_mouse? I looked this up and I think it might be an addon written in C++, but I'm not exactly sure(Node addons)
Yep these .node files are Node Addons (binary modules) and you should be able to just use require() on them. Be aware that it will look for .json and .js files first.
From the documentation:
The filename extension of the compiled Addon binary is .node (as
opposed to .dll or .so). The require() function is written to look for
files with the .node file extension and initialize those as
dynamically-linked libraries.
When calling require(), the .node extension can usually be omitted and
Node.js will still find and initialize the Addon. One caveat, however,
is that Node.js will first attempt to locate and load modules or
JavaScript files that happen to share the same base name. For
instance, if there is a file addon.js in the same directory as the
binary addon.node, then require('addon') will give precedence to the
addon.js file and load it instead.
You should also be aware that these are binary modules, so loading them is a lot like just running a standard executable file (Think .exe file if you are just familiar with Windows). Like native executables they are a lot more dependent on the particulars of your system and also potentially a security risk. While a standard .js module will be portable (with a few caveats) a .node binary module will be fundamentally built for a particular machine architecture and OS and often even a particular version of Node. If you are having trouble loading a binary module you should make sure you are running the right version for your system, and confirm with the provider that your system is actually supported.
Sometimes specific functionality or performance needs requires it but with Node.js you shouldn't be loading binary modules unless you really have to.
PS: This is an old question and answer but I happened to come across something that reminded me of this, so for the record: Don't use node_mouse which looks like a garbage package, instead global-mouse-events looks far more promising.
Yes, the normal "require" usage is appropriate for .node files. The point of these files is to create portable binaries (using node-gyp, from C++) that can be referenced like normal node requires. See the hello.js section of the node addon docs:
const addon = require('./build/Release/addon');
console.log(addon.hello());
After looking into this NPM lib, it is loaded by node correctly on my Windows, Mac, and Linux VM's with several different node versions, but the binary throws an array of errors. On windows, it has a specific version of windows as a build target (likely NT, because windows 10 throws an error):
Error: %1 is not a valid Win32 application.
On OS X, this is dyld failing to open a shared library referenced by the binary. (See man dlopen):
Error:dlopen(/.../node_mouse/node_mouse.node, 1): no suitable image found.
On Linux, we get an ELF header error, which tells us that the binary can't be run on this OS.
Error: /app/available_modules/1484064894000/node_mouse/node_mouse.node: invalid ELF header
The author seems to do a lot of Windows NT work, so if you really need this working, find a fresh copy of Windows NT with all the dev add ons.
Lastly, consider the security risk of running third-party closed source binaries in your code base (especially ones that control mouse movement).
In node.js express app and nodeunit tests I widely use coffeescript without saving resulting javascript files on disk to avoid project clogging by javascript translations.
When I got any error in coffeeScript file I see in console: the filename where error was occured and line number (for example 37): /pathTo_File/fileName.coffee:37. But I dont have 37th line in my coffee file!!! I have two times less lines there.
I guess that I got error on 37th row in my output javascript file, but I don't have it on disk. Coffeescript files only.
So how I can get line number with error in coffeescript file?
I understand that I can translate my coffee script file manually (using console) to js and see there line number and guess on what line I got that error on my coffee file. But maybe there is something faster.
My IDE is WebStorm and os is osX.
CoffeeScript 1.6.1 and above include support for generating source maps, a way to tell your JavaScript engine what part of your CoffeeScript program matches up with the code being evaluated. Browsers that support it can automatically use source maps to show your original source code in the debugger. To generate source maps alongside your JavaScript files, pass the --map or -m flag to the compiler.
http://coffeescript.org/#source-maps