I have an app with a module that contains two schemes, SchemeA and SchemeB.
When running SchemeA, it uses a target called FirstTargetA.
When running SchemeB, it uses a target called FirstTargetB.
I also have another module in my app which contains two targets: SecondTargetA and SecondTargetB. The only diff between those two are different custom flags.
I have added SecondTargetA as a framework to FirstTargetA and added SecondTargetB to FirstTargetA, but when I run SchemeB, FirstTargetB is actually calling SecondTargetB and I don't understand why. It should even know it as it's not in the General->Frameworks, Libraries and embedded content section.
Can anyone tell me what should I look for? What could I miss?
Related
I am using gradle 6.8 and MarkLogic version is 10.0-5.2,
My XQuery code is in directory \ml-gradle\src\main\common. When I run the command mlLoadModules to load XQuery into the modules database it loads with default URI /common/test.xqy.
I want to add some prefix to the URIs e.g. /rsc/common/test.xqy. How can I achieve that?
Note: I don't want to create an extra folder in my source for prefix "rsc".
It's not supported, though you could write a custom Gradle task to change the URI to whatever you like.
Why do you not want to create an "rsc" folder above "common"? I think other developers would find it much more intuitive that "rsc/common/test.xqy" becomes "/rsc/common/test.xqy" when loaded, rather than "common/test.xqy" becomes "rsc/common/test.xqy", which begs the question - where is "rsc" coming from? And then that developer would need to understand what property / custom code is adding that "rsc".
I've followed all the steps from other similar questions, and I'm still stuck.
I need to use the function proc_pidpath in libproc.h to get the path of a BSD process by its PID. However, libproc.h is not a modular header, so I can't include it in my umbrella header:
Fair enough; now I try to include it in my module map:
framework module My_Modular_Framework {
umbrella header "My_Modular_Framework.h"
private header "/usr/include/libproc.h"
export *
module * { export * }
}
Well now I get this error-vomit where it seems like it thinks many system modules/headers are within my project:
I can't figure out what else to do. Like I said, I already tried following all the steps of other similar questions without any success. What can be done here? How can I use proc_pidpath? Is there another, more Swift-in-modular-framework friendly way to get a path from a process ID?
I don't want to enable "Allow Non-modular Includes In Framework Modules" because that defeats the purpose of a modular framework.
Since libproc.h and libproc.c are open-source (APSL 2.0) as a part of Apple's Darwin project, you can just include them (under the terms of the license, of course) in your project. Since neither imports any non-modular headers, you can compile it yourself and the compiler won't complain!
I'm using the SwiftAutomation framework to drive a scriptable app that searches for lyrics and returns a AS record. Everything was working correctly, until...
I mapped the AppleScript record to a custom Swift structure according to the SwiftAutomation documentation. The code in the xxxGlue.swift file looks correct, but the compiler complains about SwiftAutomation.SelfUnpacking, with several follow-on errors, when building the MacOSGlues framework.
public struct LFBLyricsInfoRecord: SwiftAutomation.SelfPacking, SwiftAutomation.SelfUnpacking { ... }
--> .../MacOSGlues/LyricsFBAGlue.swift:700:81: No type named 'SelfUnpacking' in module 'SwiftAutomation'
The SelfPacking public protocol is defined in SwiftAutomation, and SelfUnpacking protocol is defined right under it, but without the public keyword. Is that the cause of the compiler error, and if so, how do I fix it?
OK, I finally found a resolution. Seems you have to use different options for the aeglue utility when generating the glue file for the MacOSGlues framework and for the swift file where you actually use your automation, such as in the test project. In my case, where my scriptable app is named LyricsFBA.app, these were:
aeglue -S LyricsFBA.app
for MacOSGlues (generates a LyricsFBAGlue.swift that references SwiftAutomation, but does not include the custom record structure definition), and
aeglue -D -s 'LyricsInfo:lyricsInfo=score:Int+title:String+artist:String+composer:String+link:String+lyrics:String' LyricsFBA.app
for the test program (generatea a LyricsFBAGlue.swift that does not reference SwiftAutomation, but does include the custom record structure definition).
As I'm writing a Firefox XUL Extension I find that I want to share some functionality (the business logic) across the whole extension. What would be the best place to store this?
Can I create some sort of library (javascript) file which always gets loaded first?
You most likely want to create a JavaScript code module. You can use Components.utils.import() to load it:
Components.utils.import("chrome://myaddon/content/utils.jsm");
And in utils.jsm you define which symbols should be imported by that statement, e.g.:
var EXPORTED_SYMBOLS = ["Utils"];
var Utils = {
};
The module will be loaded when it is first used and stay in memory after that - there will be only a single module instance no matter how many places on your extension use it. Note that I used a chrome:// URL to load the module, this is supported starting with Firefox 4. Documentation recommends using resource:// URLs which is cleaner because modules don't actually have anything to do with the user interface - still, using a chrome:// URL is often simpler.
I would like to be able to build functionality for my application in a plugin style system for a couple reasons:
New projects can choose which plugins are necessary and not have code for functionality that's not needed
Other developers can build plugins for the system without needing too much knowledge of the core workings.
I'm not really sure how to go about implementing this. I would like to have a plugins folder to host these separately but I guess my questions are:
How do plugins interact with the core system?
How does the folder structure work? Would each hold the standard MVC structure: controllers, services, models, views, etc?
I guess if anyone has a tutorial or some documentation relating to this technique that would be helpful. I've done a bit of searching but it's all a little too closely related to the actual code they're working with instead of the concept and I hadn't found anything specifically related to nodejs.
I suggest an approach similar to what I've done on the uptime project (https://github.com/fzaninotto/uptime/blob/master/app.js#L46):
trigger application events in critical parts of your application
add a 'plugins' section in the applicaition configuration
each plugin name must be a package name. The plugin packages should return either a callback, or an object with an init() function.
either way, inject to the plugins the objects they will need to run (configuration, connections, etc) when calling init(), or executing the callback.
plugin modules register listeners to the application events and modify it
Benefits:
lightweight
rely on npm for dependencies
don't reivent the wheel
Create a plugin prototype for the base
functionality, and let the user define its plugin in a module. In the
module the user would inherit an object from the prototype, extend its
functionality, and then export a constructor which returns the plugin
object.
The main system loads all plugins by require("pluginname") and for
each calls the constructor.