I'm writing a few custom CIFilters for a program. Based on the fact that CIKernel's kernelsWithString: will take multiple kernels from the same file (and a few similar clues I can't recall right now), it seems like I could provide them all in 1 plugin. Am I barking up the wrong tree, or is this doable?
I made an admittedly flawed attempt at this, and the 2 filters do show up. However, one was flawed, and using [[CIFilter filterWithName:filterName] attributes] on it produces null for the parameter list.
I believe I've fixed it now, but [CIPlugIn loadAllPlugIns] "loads newly added image units, but image units (and the filters they contain) that are already loaded are not removed." Either my fix is being ignored, or I haven't actually fixed it. Unless somebody knows a method that unloads a filter (which the Core Image Programming Guide implies is possible), I can't be sure without rebooting.
Apparently I had a misunderstanding of how the CIPlugin system works: it is not global. That is, each program's loaded plugins are independent of other programs'. So to update a plugin, simply close all programs that are using it, and replace the plugin.
To answer the main issue, yes, it's fairly easy to put multiple filters in 1 plugin.
Each filter needs it's own XxxPlugInLoader : NSObject <CIPlugInRegistration> class and Xxx : CIFilter class. (The filters' bundleForClass appear to all load from the same bundle.)
The kernels can be in the same *.cikernel file or not, but if together avoid loading the *.cikernel for each filter (it won't hurt, but it's inefficient).
Set up 1 Description.plist and 1 Description.strings, with the info for all the filters. In the plist, each filter's CIFilterClass entry must match the CIFilter class defined above. Each filters CIAttributeDescription entry is a key into the strings file.
Related
I'm using Jooq Code Generator and I noticed that when I make a change in the DB and run the code generator, it makes changes to all files, not just to those that should have been changed.
For example, I add a new table, so I see the new class for the table, and the new class for the table record, and I see that the table was added to the schema class. But in classes that represent other tables, that shouldn't have been affected at all, I also see changes, in the "imports" section.
In some files I see that just an empty line was added. In others I see that the location of specific import lines was changed. And in other classes, a line of import that contains * is replaced by the entire list of imported classes, or vice-versa.
Example:
My questions are: Why does Jooq does that?? And can I turn this behavior off?
Thanks!
The jOOQ code generator doesn't produce that particular import you've shown, i.e. import org.jooq.*;. You must have done that yourself, either manually, or via some post processing on generated code.
If you did this manually, then this is clearly against the idea of what jOOQ generated code should be, namely derived code, which shouldn't be modified manually. It wouldn't be possible for the code generator to detect which parts you modified (and intend to keep) and which parts you didn't modify (and are thus allowed to be overwritten). Just don't do that.
If you did this via automated post processing, then jOOQ's code generator still cannot detect this, but after overwriting everything, you would just have to re-apply this post processing, and the end result should be unmodified code.
I have an attribute of type pim_catalog_number, but I need to change this to pim_catalog_simpleselect. I cannot change this in Akeneo and if I try to overwrite it by importing a new attributes-file I get the notice that I am not allowed to change the type.
But I have a scenario where I need to do this. So what's the proper way to do this? I can imagine doing some direct SQL queries, but what are the consequences of changing the type directly in the database?
For now the only solution is to export the product values, delete the attribute, create the attribute with the right type and then re-import the products.
We are currently working on a proper solution to do that, but with all the feature of the PIM involved (history, rules, proposals, search, etc) it's not an easy task. We dedicate 1 dev full time on this task for the next three months to come up with a nice solution.
If I've read the documentation correctly, checking the "Filter results from generated files" option is supposed to hide code-generated files from the results of for instance the commmand ReSharper.ReSharper_GotoFile. This does not happen in my solution.
Evidence: ErrorController.generated.cs is code-generated and should be caught by both the wildcard *.Generated.cs and my manual configuration of the T4MVC-folder. Does not happen:
Configuration and solution view:
Anything I've misunderstood or misconfigured?
As far as I can see, the documentation is a little misleading, and this setting only affects searching for types, not files. If this setting is on, go to type will filter results from generated files. This doesn't mean that the types won't appear, though.
If, for example, you add a class Foo in a generated file, then trying to navigate to Foo will still show the result from the generated file, because that's the only result, and, ReSharper figures that if you asked for it, you should get it. If, however, there is more than one result, ReSharper will filter out any that are in generated files.
But it's hard to get more than one result - you can have multiple Foo classes in your project, but they'll have different namespaces, so they'll be different. Which means this setting only really works with partial types. If you have a partial class split across two files, one of which is generated, then trying to navigate to that class will only navigate you to the non-generated file (turning off the option displays a little menu asking which file you want to show). Also, ctrl+clicking the class name doesn't swap between the two class declarations (turning off the option does this).
And it only seems to affect types - you can navigate to symbols in those classes, even symbols that are defined in the generated file (again, there's only one symbol, so it doesn't get filtered). Which means the scope of this setting is actually quite limited.
I have the following Message-level entry in my Error List from CodeContracts:
CodeContracts: Checked 410 assertions: 404 correct (6 masked)
I can't figure out:
What masked assertions are
How to locate the 6 that it mentions
Whether or not I should be concerned about them
Sorry for not posting code... I have no idea how to recreate this in a small sample :)
Many thanks
It's simple, in your project properties>Code Contracts>Static Checking> put the warning at "hi".
Now ccCheck made more warning.
Bye.
These seem to be assertions that are masked by virtue of their inclusion in the "baseline" file. From the documentation (emphasis mine):
6.6.8 Baseline
Bringing an existing code base to a point where the verier emits only a few warnings is dicult and time consuming, as it requires adding numerous contracts. To make it easier to use contracts on existing code bases, and to focus warnings introduced by new code or code changes, the Baseline functionality can be used.
To use the baseline functionality, check the box labelled Baseline and provide a file name to store the baseline in. The path is relative to the project output directory. When the analysis is run and the baseline file does not exist, the baseline is created. During this run, all warnings are shown in the output and stored in the baseline file as XML.
When the analysis is run and the baseline file exists, then the baseline acts as a filter and warnings already found in the baseline are not shown again. New warnings are shown and stored in a file called <baseline>.new, where <baseline> is the file name of the baseline file. Since the files are stored as textual XML, it is possible to edit them and to add additional failures to the baseline. The format does not depend on method ordering and additional XML tags for grouping can be introduced freely.
I was wondering about the "masked" messages, too; I turned off the "baseline" option, and they no longer appeared. The answer to your second question therefore seems to be "clear the 'baseline' check box."
As to whether you should be concerned about them, I would say, yes, you should.
I know i can use
<mt:EntryAssets lastn="1">
<img src="<$mt:AssetThumbnailURL width="100"$>" />
</mt:EntryAssets>
to show the 'last' asset...how do I show the 'first' or 'oldest' assest?
[I'll point out here that "first" and "oldest" are not necessarily the same question.
You'll see why this is important below. Given the snippet you used, I'm going to assume what you're asking for is first as in position within the entry content. Sorry for length, but this is one of my pet bugs.]
Technically, you can't. That bug(summarized further down if you don't have an Fbz account) has finally been attached to a milestone, so hopefully this won't always be the case.
Practically, reversing the sort order will usually probably output what you expect:
<mt:entryassets limit="1" sort_order="ascend">
...as long as you compose your entries top-to-bottom, and don't later mess with the assets much
The underlying problem is that the current EntryAssets implementation doesn't actually take your content into account. It just loads a list of associated assets and then sorts them by the created_on dates of the assets themselves, not what physical order they appear in or even when they were attached to that particular entry. So as an extreme example, if you insert five images into a post, my snippet above will return the first image, as expected. If you later reverse their order and save, it'll still output that same image, which is now the (ordinal) last one. So, back to what I said at top, you're thinking "first" and MT is always giving you "oldest." And this requires an even further assumption that you're always uploading the assets at time of composition. If one of them was already in the system from say, two years ago, it's going to get returned because it's just older than everything else.
If you're using MT4.3x with the Entry Asset Manager in the sidebar of the composition screen and use it to attach(rather than insert) assets, this is going to get even more complicated, because there's no way to distinguish between assets that were associated with the entry via each manner.
So.
If you absolutely need the returned asset to be predictable, you'll need to actually distinguish it from the group in some way. There's this suggestion to tag the asset with "#first" or something similar. It's not great, but you'll at least know what you're getting(assuming you only tag one asset per entry as such). If you've got custom fields available, you might see if it makes more sense to create a separate "featured/thumbnail image" asset field that it would go into so that you could explicitly test for it. It'll ultimately depend some upon why you're wanting to extract this particular asset.