I have a requirement where I have to get the compiled code dynamically from the server and execute them from the OS X application. In short, the idea is to have few classes and methods in the compiled code(it can be a .dylib, .a or a bundle) hosted on a server, and the application downloads it form the server and accesses those classes dynamically. The completed code might contains HTML, javascript, Objective-C, or Swift.
Option 1. Static library
It has to be part of the consuming application at compile time, so i think we can rule this option out.
Option 2. Dynamic library
I am struggling here, is it possible to download the dylib form the server and copy them in one of the application folders, and run from there dynamically using dlopen. is it possible?
Option 3. Bundle
I did not look into this yet, but the idea is similar to dylib.
Option 4. any other possibilities..
Surely you can download a dylib. Why should that be impossible?
Then you can store it in one of the paths the dynamic linker is looking for. This is described here.
Even I did not test it, I do not know, why this shouldn't work.
Related
Currently, with my Intern setup, I'm using an unbuilt Dojo build when running my Intern tests; like, for example, a test module loads app/ProductModuleA, and ProductModuleA references and loads dojo/request. I need to have the dojo/request.js file in the appropriate directory structure in order for the module to be resolved without errors and therefore the test to be able to run. Our product code does use a built dojo.js file and our previous DOH tests were able to use this, too, without any issues--I don't understand how that worked because I don't know anything really about building Dojo.
I know I've seen snippets in various Internet forums (like here) and the Intern User Guide that Intern supports source maps, which I guess suggests it's possible to use a built dojo.js file in conjunction with running Intern, but I haven't found anything at all in detail. Insights, or pointers to documentation or examples that so far I haven't been able to find?
One of the benefits of AMD is that you don't have to do anything special to your code when switching between a built and unbuilt Dojo. The first time you load a dependency using an unbuilt Dojo, the loader requests it over the network and then caches the result. Subsequent loads use the cached dependency. The loading process works the same with a built Dojo; the main difference is that all the modules built into the built Dojo are pre-cached. The loader doesn't have to request them over the network the first time because they start out in the module cache.
For Intern to use a built Dojo, you just need to make sure you're using the built Dojo as your loader during tests. You can do this by setting the useLoader option in your Intern config.
I tried what Jason suggested and it still didn't work--I was getting 404s for a Dojo_ROOT.js module, though nothing in tests or product files explicitly load that. I'm sure this is due to something unique in my product's build environment. That's okay, I will just use the Dojo source for now and return to this later.
I want to compile coffeescript from my Mac OSX app, but I'm unsure how to go about doing this. It seems like node tasks are heavily dependent on other libraries installed to the system. How can I go about compiling coffeescript files from my app?
A couple ideas:
The 'Try Coffeescript' section on coffeescript.org compiles in the browser by including the coffeescript compiler as a javascript tag. You could do something like that in a UIKit WebView where you have control over the javascript execution.
PhoneGap/Codova based app
Make a request out to a node server or other js environment and return the compiled code via service call.
I'm not sure you've provided enough context for which one of these might work, but they are the first things that come to mind.
For a project I am doing, I want the Mac application to accept plug-ins. I like the whole idea of just adding Bundles to the application to extend it's functionality.
Only I came across a small question, where I can't find the answer to:
I need to include a JSON parser in my application, for some functionality. Is it possible for a plug-in Bundle to also use that same parser? Or does every plug-in that uses a JSON parser, need to include the parser themselves?
What is the best way to do this for separate Bundles?
On OS X there are two types of loadable things, a dylib and a plugin. (These two terms have specialized technical meaning in the context of mach-o, the binary format OS X uses.)
A loaded dylib can't refer to the libraries in the executable, while a loaded plugin can. As a side effect, a dylib can be loaded to any executable, but a plugin can only be loaded into the executable you specify when you make the plugin.
So you want to make a plugin. There is a template in the XCode to do that. Don't forget to specify the target executable in the linker flag, which can be set somewhere in the inspector.
For more, read Code Loading Programming Topics.
If you create a static library for iOS do you have to distribute the header file(s) with it or is there another way to get it to work?
Currently I have a single my_lib.a file for both device and simulator but when I drag it into another test app to use it, it says it can't find the header and that all the places I'm using it in the code are undeclared. So I figure I'm either doing something wrong, or I have to also send the appropriate header files with it.
Background to my process:
I've seen two guides for creating a static library for both device and simulator. One on this site: Build fat static library (device + simulator) using Xcode and SDK 4+
and one here: http://mark.aufflick.com/blog/2010/11/19/making-a-fat-static-library-for-ios-device-and-simulator
I used the second site to just try it out. I'm also a bit curious if I did it correctly. I just went into the Release-iphone(os|simulator) folders and found the .a in the ios one and the .o in the simulator one.
The short answer is yes, you have to package header files with your static library. You have to package header files with any library in fact, dynamic or static. The library itself contains the compiled code, but you still have to tell the compiler about the identifiers in the library so when it's compiling your code it knows that they exist.
If you care, you can package your static library into a static framework with a little care. You simply create the same directory structure that a dynamic framework has, with your .a file in place of the .dylib (or .so) file. Frameworks contain a directory for headers, so you can distribute the binary and headers as a single package, and you can easily import headers from a framework without messing with the Additional Header Search Paths build setting.
Just in case it's useful - I followed Ray Wenderlich's instructions from here and was able to produce a framework for iOS that supported several architectures at once (including the simulator). The instructions are a bit too long to just copy-paste here.
We created a plugin; it is a DLL (Run-Time Dynamic Linking) which uses a 3rd party library (wxWidgets) and also links dynamically to that. The host software seems to scan our plugin, but exported functions are not called. We checked all dependencies with DependencyWalker.
We see in the debugger that the plugin is loaded, but the DllMain is not called, and the plugin is unloaded.
We tried loading our plugin from a simple test application using LoadLibrary and GetProcAddress which recognized and called the exported functions.
Having wxWidgets linked statically worked fine, though.
Does anyone have an idea why the exported function, respectively DllMain are not called, or can point out a tool which is capable to monitor the whole DLL loading process?
If wxWidgets is loaded already into the process address space before your plugin is loaded (the host app could do that, or there might be another plugin linking to wxWidgets which is loaded before yours), then there might be a chance that it is another version, missing some of the entry points that your plugin needs. Running the host app under DependencyWalker or WinDbg should show you which wxWidgets DLL is loaded, and you could try to load your plugin from your test app using exactly the same wxWidgets DLL. That should reveal whether there are missing dependencies.
Perhaps the host software does some funky things when loading the plugin and doesn't like wxWindows.
Anyways, try using the ProcessExplorer from the SysInternals suite to check what the process is doing.