I've got NSBundle file named main.jsbundle packaged by react-native bundle, which tool I can use to explore it's contents? I can see that it got the minified js code inside, and also some sort of index at the beginning of file. I need to extract the js code in order to debug an issue.
NSBundle is a totally different thing – it is a native class representing an Apple format of packaging applications and frameworks, allowing to access and manipulate it from native code.
You are asking about a React Native bundle, which is quite a loose concept of a single file of minified JS code + an assets folder for images and data. You can actually de-minify the js-bundle using conventional tools such as uglify-js and try to inspect it.
You can also use sourcemaps produced by Metro, and maybe metro-symbolicate to understand how the minified code from the bundle maps to actual sources, although I can't recommend anything more specific without knowing the problem at hand. There is also no documentation for metro-symbolicate, meaning you'll have to grok its sources.
As #ivanmoskalev pointed out, this might not be necceserily NSBundle. Anyway, piping the file through strings outputs pretty much just the javascript part of the file, so that works for me.
Related
The CSS (from LESS) is not rendering or compiling in my ng-boilerplate app.
I'm creating an app using ng-boilerplate and rails using these tutorials here, and we've integrated a working rails server with the angular. The angular is working on any page... as in, we can use:
$scope.animal = "dogs"
and
<div> I like {{animal}}! </div>
to get
I like dogs!
However, the Less and CSS (which was copied and pasted from a functional ng-boilerplate app without rails where it worked and compiled from all the different directories just fine) is not compiling to the build directory nor rendering. In fact, in this new app (the one with the rails), not even the original css/less from the ng-boilerplate template will compile or render.
We tried using the following commands, as the tutorial suggested, which created weird nested build directories (a build inside the build inside the build) and didn't fix the problem.
cd public
ln -s ../build UI
Meanwhile, the UI folder is linked to the build folder using a symlink but...
The LESS (from different files in different directories) is all supposed to compile to one CSS file called ng-boilerplate.css (which it did in the original app without rails), and instead there's a file called ng-boilerplate-0.3.1.css, which is empty. I tried renaming that, but it re-renames itself back to the 0.3.1 one every time grunt builds it.
I'm using rails version 4.2.1 and ruby says it's 2.1.0p0.
I hope that you have already found a solution, as I realise that this post is quite old. However, since this question appears reasonably highly when I was google searching, I felt it should have an answer.
When using ng-boilerplate, you need to be aware that, although it's compile process finds all of your JS files and makes nice compiled JS code, the same is not done for the LESS files in their build process. If you look in the directory 'src/app/less/' and view the 'main.less' file, you can see a small note mentioning that he would like to automate this process. Instead, it is at this point that you unfortunately need to manually import all of your LESS files.
The LESS way to import files is this for anybody who is unsure:
#import '../app/less/fileToImport.less'
The path can be relative or absolute.
I've been trying to load a library into lua file. Sparing the details, as they are not really important, I have tried this many ways.
The final way, and the one I believe to be correct although I still can't get it to work, is to use "package.loadlib". See code:
ed = package.loadlib("Encode_Decode.lua", "luaopen_ed")
print(ed)
But when I run the program I get this error:
Encode_Decode.lua is either not designed to run on Windows or it
contains an error. Try installing the program again using the original
installation media or contact your system administrator or the
software vendor for support.
I know the program runs because I used it internally to test it's encoding and decoding abilities and it worked fine. I'd really prefer not moving the contents of the library over as my main lua file is crowded as it is. I will if I have to though.
Yes it is in the main folder. I've also tried changing the extension of the library file into a .dll, with the same error.
What am I doing wrong?
I apologize in advance if this is a duplicate, I did my best to research this problem as thoroughly as I could. But to be honest it's almost 3 AM and I've been searching for almost an hour.
Stupid beginner mistake, used the wrong syntax.
require("Encode_Decode")
print(dec("bnVs")) --returns "nul"
package.loadlib is used for loading shared libraries; i.e. .dll or .so files. You're passing a .lua file to it, so Windows attempts to load it as a .dll and fails when it can't.
To load Lua source code, you can use dofile. Alternatively, you can use require, which is a bit more complex, but handles loading modules only once and works with both Lua and C modules.
I'm running on a platform that has very limited disk space and I was looking at disk usage of OpenDaylight.
The biggest directories are the plugins and configuration/org.eclipse.osgi/bundles directories. The plugins directory is where all my bundles are, so I'm OK with it. But the configuration/org.eclipse.osgi/bundles directory seems to contain mostly copies of my bundles.
For example configuration/org.eclipse.osgi/bundles/117/1/bundlefile is an exact copy of plugins/org.opendaylight.controller.clustering.services-implementation-0.4.0.jar. That is a big waste of disk space.
I've tried to find a configuration option to disable that and found nothing. Is there something?
I've looked at the Equinox source code as well and didn't find anything. Can somebody point me to the location in the code where this is done? I'd like to disable that or at least replace it by a hard link.
After asking the nice people on the Equinox mailing list, I've got to those conclusions:
With Equinox and some other OSDI implementations, you can add a "reference:" in front of the bundle URLs to avoid useless copies (still have to copy the native libs embedded in the bundles).
OpenDaylight is using org.apache.felix.fileinstall to avoid having to specify all the bundles to load. It just loads all the bundles found in a directory. And FileInstall doesn't allow to add the "reference:" in front of the URLs.
My solution was to remove FileInstall from the loaded bundles and add all the bundles manually to the list with the "reference:" string added to the "file:" URLs.
I am working in a very large iOS project and it has so many classes and resources that it takes very long time to index and compile them. As it still grows more and more, I need to do something about this because I am spending too much of my time waiting for the IDE to let me work.
My first idea was to pack all the images in a custom bundle so the IDE will see it as a single file and would be faster to index and copy it, but I have seen that a bundle is nothing more than a simple folder with an extension, so I guess that the performance would still be slow. Then I read that if I used "blue folders" instead of "yellow groups" for my images, Xcode would not index them. But this way is not easy right now, as I should replace my function that looks for images to look for them in that folder (absolute paths?)
So my last approach will be saving time in both compile time and indexing. I want to modularize my code in multiple libraries so it will not be necessary to compile it "ever" again and this way Xcode won't need to index the source files neither.
I have followed some tutorials and now I know how to create a static library and include the header files in another project. But my current problem is as follows.
My application has several "independent" modules, so I want to create a static library for each one (and maybe I'll generate an image bundle for each one too...). But all of those modules use a common core, which I'd like to maintain in a static library too. So, if I do it like this, I will have to include the main core library in every module library, and I'm afraid this will not be the most optimum way, as the binary code of the core will be there several times, right?
I guess the correct solution would be to generate a dynamic library for the core and static ones for the modules, but I can't find how to generate the dynamic one... Furthermore, I'm not sure this would be the solution.
So I ask you: what options do I have? Is compiling the core several times the best approach I have?
Thank you so much for your help!
Dynamic linking is not supported in IOS, so this isn't an option. While the static libraries are added to the other libraries, it isn't embedded inside the other static library, you can see this when you do a build, the other libraries should show as a separate libraries inside the project folder, hence each static library/project will only get included once in the app build.
In the end ... I am not sure this will save you a lot of time you are expecting if you are using static libraries in the same workspace. I use static libraries in some projects and if I do a Clean on the app, then a build, the static library will get re-built also.
I've downloaded a package and am trying to build/install it. The project's wiki page has a command that looks like
qmake VAR=/path/to/something/ project.pro
It says that this command should tell qmake to generate a make file. Instead, I'm getting
qmake: Nothing to be done for `project.pro'.
Why is qmake not generating the make file like it's supposed to?
Without knowing the project in questions or the contents of the project (.pro) file, it is difficult to diagnose. One possibility is that qmake was already run, or that the files it is to generate are included with your download. In these circumstances, there really is nothing to be done for said project.
As a side note, may I recommend downloading "Qt Creator" and opening the project file in there? Qt Creator tends to make Qt development and project building a lot easier.
I just answered my own question... apparently there is more than one qmake. On my system, we're using a qmake: distributed parallel make, scheduling by Grid Engine. I found /etc/alternatives/qmake which is the QT qmake...