Looking at Three.js's build script, I see they use Google Closure compiler. I am having a small script utilizing Three.js. Can I use Google Closure to compile the script with Three.js as a library (instead of having Three.min.js preambled or included in an HTML tag) so the final output javascript is much smaller.
I'm asking this because I don't see any goog.provide in Three.js source.
It looks like the build command does not specify a compilation level. That means it is using the default SIMPLE_OPTIMIZATIONS.
If that is indeed true, then no, you probably cannot include the source as a library as it is not compatible with ADVANCED_OPTIMIZATIONS.
One way to do this is to prepend the three.js script to the compiler output using whatever shell or build system you are using.
Related
Emscripten provides CyberDWARF for inspecting variables at runtime via the console as a JS API. Is it possible to use CyberDWARF when compiling Rust to asm.js or Wasm?
Source maps are possible, but it would be nice to be able to inspect variables that appear in the original source.
Not CyberDWARF, but you can use LLDB with Wasmtime: https://hacks.mozilla.org/2019/09/debugging-webassembly-outside-of-the-browser/
I am using rtags which is a C++ source code indexer based on clang. I have been able to play around with it and now I want to actually index the firefox source code. I am pretty new to this stuff and this tool uses cmake to generate a compile_commands.json file to pass over to the program that indexes code.
Is there a way I can generate a the compile_commands.json file for the firefox source code that provides the exact compilation line for each translation unit inside the firefox source?
You can generate compile_commands.json by
mozilla_cnetral/mach build-backend -b CompileDB
In my environment(Ubuntu 16.04), it was created at mozilla_cnetral/obj-x86_64-pc-linux-gnu/.
Reference:
https://developer.mozilla.org/en-US/docs/Developer_Guide/Editor_Configuration#rtags_(LLVMClang-based_Code_Indexing)
Not sure if I follow the part "Is there a way I can generate a the compile_commands.json file for the firefox source code that provides the exact compilation line for each translation unit inside the firefox source?". But I can offer simply that you can generate a compile_commands.json file from a make-based system using the bear utility (which I obtained from my package manager: brew). After a make clean, I do 'bear --append make' and it traces the make build process and produces the compile_commands.json. More can be learned here: https://vxlabs.com/2016/04/11/step-by-step-guide-to-c-navigation-and-completion-with-emacs-and-the-clang-based-rtags/
As the article referenced implies, my motivation was to be able to use the wonderful rtag system inside Emacs. Hope this helps a bit.
I am accustomed to linking against libGL.so on most Linux distributions. Either mesa's implementation or NVIDIA's. However, I would really like to limit myself to OpenGL ES 2.X functionality, so I am attempting to link against and use libGLESv2.so. However, I see that glX functions are not present in libGLESv2.so dynamic section:
nm --dynamic /usr/lib64/nvidia/libGLESv2.so | grep glX
Also attempting to link agains libGLESv2.so results in undefined references to glX functions.
This leads me to my question. What is the correct way to "GetProcAddress" while dynamically linking against libGLESv2.so? Also how do you construct the appropriate context without glX?
I'm not sure how easy this will be for you to figure out and how relevant for your applications but in pi3d we get the drawing context using libEGL.so (or libegl.dll from ANGLE on windows).
This where the dynamic libraries are found and loaded
https://github.com/tipam/pi3d/blob/master/pi3d/constants/init.py
and this is where the surface is created and attached to the GLESv2 functions
https://github.com/tipam/pi3d/blob/master/pi3d/util/DisplayOpenGL.py
I'm building off a project in three.js and one of the ideas I'm fiddling around with would allow users to write their own shader code. Code from the user would dynamically load to the gpu, much like in this example. In such a setup, the user would benefit greatly from having some way to display compile time errors generated by his code. I've looked into the code from the above example, but this instance works directly with WebGl.
Are there any alternatives I might consider that leverage the three.js library to detect compile time shader errors?
I'm just guessing but it looks like what you'd want to do is use WebGL to compile and link the shaders. If there are errors display them. If compiling and linking was successful then make a three.js ShaderMaterial and pass in the shader source that just worked.
If you view-source on glsl.heroku.com/e you can see in the createShader code it checks for errors and attempts to highlight specific lines in the source.
I'd like to extend ace with a mode for a custom language. As far as I can tell, the general process is:
Download the ace source.
Create a new lib/ace/mode/foo.js for your custom language.
run "make build" (or similar) to rebuild ACE.
Use the newly compiled build/src-min-no-conflict (or whatever) ACE distribution in your website.
But I want to just use an existing ACE distribution from their website, combined with my standalone new mode. I don't want to have to rebuild ACE as part of my build process in order to build my new mode. I got close by doing:
ace.config.setModuleUrl("foo-mode", "./foo.js");
session.setMode("foo-mode");
But I quickly ran into requirejs / dependency problems. For instance I couldn't do require("ace/mode/matching_brace_outdent") inside my mode. I temporarily hacked around that by first calling setMode('ace/mode/c_cpp') (which as a byproduct defines the matching_brace_outdent module). But I ran into even worse problems trying to get a custom WorkerClient to work.
Is my only option to build my mode as part of ACE? Or am I missing something?
Try the pre-built release.
https://github.com/ajaxorg/ace-builds/releases
You might need to edit other files (lists of modes etc.) depending on how you wish to present your new language in the UI:
With regards to require under no-conflict mode in custom modes that aren't workers, if you define your custom mode as a module or a series of modules inside define or ace.define, you should just be able to use the require provided to you in the function wrapper:
ace.define("ace/mode/your_module_name",
["require","exports","module","ace/your_other_dependencies"],
function(require, exports, module) {
// you can use require('...') here
});
I believe you can also use ace.require.
I am less sure about how to "manually build" a custom worker, but following this answer, I think I got it to work by copying code around the core of the relatively slim worker-json.js.