First, some context: I drive qooxdoo from other languages such as Lisp and ClojureScript, and I dynamically generate code to reference individual classes.
This normally fails because the qooxdoo generator looks through the static source to see which classes to include.
In the past I have just whomped explicit mentions of classes into Application.js. This works great, but recently I started to grok the config.json syntax and thought it would be nice to take a less kludgy approach.
I managed to add code like this to the "source-build" job and that build then worked:
"include" : ["qx.ui.mobile.page.Manager"]
But I use many classes in an app, so adding that to each job would be error-prone and still ugly.
I tried adding the "include" to the "mobile-common" job which the other jobs extend but to my surprise that did not work. Hmm.. could there be a bug in the job "extend" logic?
I could just add "include" : ["qx.ui.mobile.*"] to all the jobs but that is still ugly and excessive (and I would have still to pull in multiple other classes in each job).
Looking back at all this, it seems there would be no problem if the job "extends" mechanism successfully picked up the "include" option. I just ran the generator with the verbose option -v and can confirm the page manager class is not included if I add the "include" to mobile-common, but it is if I do so on the specific job.
Am I missing something?
Kenny,
you're quite right using the "mobile-common" job, and it is really strange that it doesn't work. As I don't know your exact config.json file I can only provide some guesses here:
The default "mobile-common" job provided with the mobile skeleton already contains an "include" key. You did not by any chance add a second one to the job?!
Are you using the mobile config.json directly, or did you create another config file and are including the one that contains the default "mobile-common"? If you use job shadowing (i.e. define "mobile-common" in one config file but also in another which is included by the first), this will influence the content of the resulting job definition (maybe in an unexpected way).
The default "mobile-common" job has (for whatever reason) a = in front of the include key, to protect from overriding. You might want to remove that and see what happens.
If all fails you can still create your own includer job (like "my-includes"), add an "include" key to it, and then add this job to the "extend" list of the relevant source* and build* jobs. Make sure to add it before the mobile-common entry. This way you can at least maintain your additional include patterns in a single place.
Related
When two PHP files are on the same namespace, adding a "use" to them for the other one is not necessary, but possible. However, PhpStorm inspection marks the unnecessary uses on PHP files as errors, warns about using them, and does not autocreate them when typing the class name on the file.
The thing is, I like having them on the file even that they are not necessary. That makes me easier to check the file dependencies, and to search-replace the namespaces when I move classes around. I know about the refactoring features of PhpStorm, but they are not always available for me and my co-workers.
So, is there a way of telling PhpStorm to behave with unnecessary uses as it does with regular ones? Not marking them as errors, autocompleting, etc.
I'm creating some default "drag and drop" templates for our developers, and one section is the required tags. Most of the tags reference a variable: nice and easy. But one wants to reference the resource itself and I cannot figure out a way to it. Does anyone have any suggestions?
The tag itself is called "Context" and it's value should be the "type" of the resource it is in, e.g. "Microsoft.Web/serverfarms". This is desired to aid with billing. Obviously I could either create a different template per resource type (not ideal considering the number of different resources) or rely on the devs to update the field manually (not ideal either as relying on them to add the tags manually hasn't worked so far in a lot of cases), but I am trying to automate it.
Extrapolating from the [variables('< variablename >')] function I did try [resources('type')] but Azure complained that "resources is not a valid selection". I thought it might have complained that it couldn't tell which resource to look at, but it didn't get that far. Internet searches have not turned up anything useful so far.
I can't find a way to do this cleanly either (I hope someone corrects me though! This is a topic for us too). The reference and resourceId functions look promising, but both are unavailable inside of the resources block, would require some parsing, and also require the api version, which you probably also need to vary by resource and so you're just back to where you started. ARM won't even let you use a variable for the resource type property(probably a good thing), so that option is out too.
As such, you'll either have to live with your team having to replace that chunk of text manually or pursue some alternative.
The simplest thing that comes to mind would be to write a script in a language that understands JSON. That script reads the template, adds the tag to the resource, then saves the template again.
A similar approach would be to do it after the resources are deployed by writing a script that loops through all resources and making sure they have the tag. You can use automation to schedule this on a regular basis if you're concerned about it being missed. If you're deploying the templates using a script, you could add it in that script too.
There's some things you probably do with nested templates, but you probably wouldn't be making anyone's life easier or making the process more reliable.
This could be achievable potentially through some powershell specifically around Resource and Resource Group. Would need to run a Get-AzResource either at the subscription or potentially just the resource group level. Then pull the ResourceType field from the object return and use a Set-AzResource command passing in the ResourceID from above and the new tag mapped to the returnedResourceType field.
In the autoconf manual, it is noted that
AC_INIT (package, version, [bug-report], [tarname], [url])
defines multiple macro names such as AC_PACKAGE_NAME and PACKAGE_NAME.
Running configure also generates a config file with definition like the following:
define HAVE_LIBGMP 1
As I am writing C++ code, I find these macros annoying yet useful. In fact, it happened many times that I needed to link with a library that uses the autotools and thus has these macros in its headers. So the situation is that there is conflict on headers macros such as:
define PACKAGE_NAME "library"
define PACKAGE_NAME "mine"
So, I was wondering if there was a way to tell the autotools to define at least some of these macros inside some kind of structure as follows:
`struct header_information{
static string package_name;
static bug_report;
....
}`
and then initialize it with the right macro names.
This solution would keep these informations encapsulated and does not pollute the global namespace ?
It seems to me like you want to abuse a package-private, build-system-ony configuration header file (config.h) that just so happens to define a convenient macro name that you'd like to use. I think the pretty obvious answer is "don't do that", or else you're on your own.
Unless I'm misunderstanding you?
Those defines are there so that the particular library can use them. It's not meant for other things to include. In fact, the majority of the things in config.h are completely useless outside of the particular package.
That doesn't mean that the library that config.h file belongs to couldn't provide what you're looking for, by defining a public struct in a header that uses those variables. Or perhaps a library that uses pkg-config (if you're just looking for package names) can provide some of information for you. But I don't think that autotools would or should provide that information to you.
I have defined list_t in my project that got list module API like list_pop(). But now I have to use MySQL lib to communicate with DB, but the MySQL lib still got its list implements, and also defined a list_pop() API. In my other modules, I have to link both of them, and comes the conflict.
One of my solution is, separately include header file for different list API calling, this works well, but while some function need to call both of MySQL::list_pop() and local::list_pop(), how to notify the compiler the correct link point? Is there some GCC trick that can do these without any changes to local::list_pop()?
For most practical purposes, you are going to have to rename one or the other set of functions. It is probably easier to rename your own than those of MySQL.
The simplest approach is to simply add a prefix that has a higher probability of being unique (enough), such as your initials, or the codename of your project, or something. Or you can rename everything to avoid collisions, being aware that MySQL might add a new function in the future.
This is exactly why namespaces were invented for C++, and why C projects usually have systematic prefixes on sets of functions.
There is a way to solve this. Refactor your list_pop() to, say, my_list_pop().
There is one other way to solve this,
Looking at the header of the MySQL my_list.h here, https://github.com/lgsonic/mysql-trigger/blob/master/mysql/my_list.h you can see that list_pop is just a macro, and its binded at compile time, not at runtime(hence not a real library function). Changing list_pop of MySQL to list_pop_my(just in the #define) can make it do what you want it to do.
In my Symfony2 app I'm having a very basic bundle named AnimalsBundle() with a very basic entity.
I can successfully extend this bundle by creating a new bundle MammalsBundle() via Bundle Inheritance. However, it is not possible to register one further bundle InsectsBundle() that also extends the AnimalsBundle(). Whenever I'm trying to do this, Symfony throws a
[LogicException]
Bundle "AnimalsTextBundle" is directly extended by two bundles "MammalsBundle" and "InsectsBundle".
So out of the box it's obviously not allowed. First of all, I'm not really sure why this is not allowed and - most important - how can I solve this?
I know it's been more than year now, but I just came across your question and the answer maybe useful to someone anyway..
Symfony doesn't allow a bundle to be extended directly by more than one bundle, simply because if two bundles are overriding the same files, it wouldn't be possible to determine what bundle should be used. However you can achieve what you want by doing the following :
AnimalsBundle <|---- MammalsBundle <|----- InsectsBundle
This way InsectsBundle indirectly has AnimalBundle as a parent and can override files from it.
I know, that this has been a log time since the question has been asked, but for those in need of an answer I'll suggest the following:
1) Try to avoid bundle inheritance except the cases you are 100% positive that you need to.
2) Given the example in question, the better setup will look smth like this: you have a CreatureBundle, which consists mostly of abstract classes and interfaces. Make each descendant bundle depend on CreatureBundle and implement each Creature specific code with those abstract classes and interfaces in CreatureBundle.
Based on personal experience I can tell that managing dependencies is much easier task than managing inheritance issues in case something goes wrong. If you'll ever need to alter the ancestor bundle's logic, you'll save yourself lot time by not having to dig through inherited code and alter the same logic in every descendant bundle.
Edit: Although my suggestions might lead to tighter coupling and basically contradicts latest Symfony's 'best practices' guide (which states that 'single bundle per app' is a best practice), in the end you'll realize that this approach eventually makes code maintenance easier.
I can't think of a use case where you could possibly need to do this. Bundles are meant to be almost like standalone applications. You have the dependency injection container at your disposal if you need resources from another bundle.
Perhaps you should re-think your project structure.