chainer's document is very good, but I found every page in the document, I didn't found what is name rule of chainer report, How should I control the report name, and log it?
For example, the follow code:
trainer.extend(chainer.training.extensions.PrintReport(
['iteration', 'epoch', 'elapsed_time', 'lr',
'main/loss',
'validation/main/all',
]), trigger=print_interval)
Notice that main/loss and validation/main/all, why is there a main before /loss, How should I control to report loss? Also notice the validation/main/all.same question.
The prefix main is the name of the optimizer (and its target link) used in the updater you are using; StandardUpdater and other built-in updaters use the name main as the default name of the optimizer. If you are using one of the built-in updaters as is, this is always main unless you specify a special name. If you are using a customized updater that uses multiple optimizers, the custom updater assigns names to individual optimizers, which will be used as the prefix of items reported inside of the target link of the optimizer.
The prefix validation is the name of Evaluator extension. When you register an Evaluator with trainer.extend(), you can optionally pass name argument to override this prefix. For example, if you want to use multiple Evaluator objects each of which measures different things, you have to pass different names, which will be used as the prefix in the reported values.
As of the current version (v2.0.2), the naming rule of typical reported values are summarized in the document of chainer.report.
Related
I have added leangen/graphql-spqr as described in the readme.
Before we had a custom implementation of graphql types like in customtype.types.gql.
After implementation, everything works fine, except the type which are called e.g. OperatorInput, are named in the autogenerated graphql doc like "OperatorInputInput".
I tried to Change it like this in the declaration:
#GraphQLArgument(name = "OperatorInput", description = "Required fields for Operator") OperatorInput operator
But it wasn't applied.
Do you know any workaround?
This is intended. Keep in mind that in GraphQL's type system, input and output types are strictly different. Let's say you have this in Java:
public Book saveBook(Book in) {...}
The Book that is the return type and the Book that is the argument type are 2 different types in GraphQL, and must have unique names. So Input is added automatically to make the names unique.
If you're 100% sure you want to override this, register a custom TypeInfoGenerator via GraphQLSchemaGenerator#withTypeInfoGenerator. You can inherit from DefaultTypeInfoGenerator and override generateInputTypeName. BUT! Do pay attention that if you end up producing the same name for 2 different types, all hell breaks loose. So maybe only drop the suffix Input if the classname already ends with Input and never ever use such classes for output.
Btw #GraphQLArgument sets the name of the argument, not the name of the type of the argument.
I'm wondering what would be the best way to allow a block to send out a specific amount of Redstone output conditionally. While looking through other blocks that gave a Redstone output, I noticed that they were mostly using the getWeakPower() method. However, I noticed that this was a Deprecated method and my IDE formats the method with a strikethrough. Additionally, I also found another method named getStrongPower() (also Deprecated). Which one of these two method would be best to override or would there be a better way to set the Redstone output of a block.
Although these blocks have the #Deprecated annotation to them, the JavaDoc comment states that "Implementing/overriding is fine". These getWeakPower() and getStrongPower() methods are only flagged as being deprecated in the net.minecraft.block.Block class because they are not meant to be accessed from the Block class, instead they are supposed to be accessed from the net.minecraft.block.BlockState class as that will contain the most up to date state of a given block instance.
It seems that most blocks which use Redstone functionality override the getWeakPower() method to control the Redstone output of the block by returning a specific value from 0 to 15 from the method. It’s also possible to separately control the output of each side (only output on one side or different outputs on each side), by using the Direction parameter passed into the method to determine the returned value.
Note: You must override the canProvidePower() method to return true. Otherwise, neighboring blocks will not check the block for a Redstone output and the desired functionality won’t work.
I'm new to BRE and fairly new to BizTalk as a whole, so this may be quite simple and just evading me...
What I'd like to do is this: create a business rule in BRE that takes as an input the incoming message and checks to see if a value contained in message matches any of the values within a specified set of values. A sample message is as follows. The <isFound> field would then be updated accordingly.
<n1:DocumentTemplate xmlns:n1="mynamespace">
<rootOid>2.16.840.1.113883.3.51.60.2.5</rootOid>
<isFound>false</isFound>
</n1:DocumentTemplate>
Basically I'd like to match the <rootOid> node against a list of values. I've already created a business that will match the <rootOid> against a hardcoded value in the Conditions of the business rule...just as a proof of concept to learn the basics of how to use the BRE and call a rule in an orchestration.
I'm failing to find a way to match against a list of values beyond doing a giant list of hard-coded ORs in the "Conditions" of the Business Rule. The list of accepted values is large enough that doing a bunch of ORs is not going to work.
Ideally, I'd like to have a maintainable XML file full of acceptable <rootOid> values to check against from within the business rule.
I also realize that there is a way to call a database and read the values from a table/column for matching, but I'd rather keep SQL out of the equation so that this can be a little more self-contained.
One "Equal" expression is enough. Your RHS fact should be another vocabulary item. In case of XML type a proper path will pull all values one by one and cause multiple evaluations and respectively firing an action if there's a match. The key to remember: BRE is a pattern matching engine.
The vocabulary is just a convenient alias for the fact definition. Let's say you create an XML file with the following structure:
<options>
<value>A</value>
<value>B</value>
<value>C</value>
</options>
Define a vocabulary for this fact as
Name: PossibleValues
XPath Selector: /options/value
XPath Field: .
Then defining a rule as IF currentValue == PossibleValues will cause three condition evaluations as the RHS yields three facts into the working memory. Consequently, only those that were true will fire a rule (Action). Compare this to the default definition BRE creates when you pick a node from the XML schema which will only assert one (first) fact:
XPath Selector: /options/
XPath Field: value
(namespaces omitted for brevity)
At runtime pass this XML document as an argument to the BRE (whether in the orchestration or in .Net component depending on BRE invocation context). At design time for testing you have to implement Fact Creator component (implements IFactCreator) to provide an instance of required arguments.
Long-term facts (like the one in the question) are better managed using custom fact retrievers. Fact retriever is a .Net component that implements IFactRetriever. See the documentation for details. Inside fact retriever implementation load XML (from disk) and assert it into the working memory as TypedXmlDocument.
I add a FieldIndex for my content type according to the Plone.org instructions.
In the ZMI, I can see the indexed items at /mysite/portal_catalog/Indexes/Building. My content type (providing IMyType, with one field building) is folderish and contains a Photo (providing IPhoto, without building field) as allowed_content_types in profiles/default/types/MyType.xml file.
I want indexing only for MyType's building field. However, it seems items of Photo type get indexed with the value from their parents. That's annoying. Does the code #indexer(IMyType) mean indexing for IMyType and its contained types? How can I index only for IMyType?
What an indexer does is to get the attribute directly from the object being indexed. In Plone that is as special wrapper, one that will use registered indexers (as created with the #indexer decorator) if they exist.
However, if you index happens to index building and that is also an attribute on your IMyType objects directly, any contained objects will have that attribute through acquisition as well. Registering an indexer for IMyType does not prevent this.
There are a few ways around this:
Use a different name for your indexer, one that doesn't match the attribute name. Note that if all you do is index an attribute the indexer is redundant though, the index could just as well retrieve the attribute directly.
Register a "catch all" indexer:
from zope.interface import Interface
#indexer(Interface)
def catchall_ignore(ob, **kw):
# Raising AttributeError means: do not index anything
raise AttributeError
Instead of direct attribute access, now this indexer method will be used instead for Photos, causing the indexer to not register a value for building.
This is how acquisition works.
here how to workaround this:
http://plone.293351.n2.nabble.com/how-to-prevent-portal-catalog-from-indexing-acquisition-values-td2650735.html
"use a custom indexer that does the aq_explicit check."
how to know the field variable name when output by views. eg:now, i want to overwrite a field's output, the name which i added is field_hello. but i don't know what's the variable name of it? namely how to print the variable in views-view-field--field_hello.tpl.php
In the Views UI, under "Basic settings", you can click "Theme: Information" to get a list of what template files are currently being used and what file names can be used. You'll find all the default templates within your views/theme/ directory. If you copy one of those to create your custom template, e.g. views-view-field.tpl.php, you'll see they're heavily documented with all the variable names available. For field templates, you have $view, $field, $row, and $output. Depending on whether you want the pre-processed value or the processed value, you probably want $field or $output.
Using Theme Developer (formerly part of Devel), you can inspect a page and see what variables get passed to it and use them in your own templates.
If you talk about using a variable inside a views field: this is not possible due to security issues. Depending on the fields, there are some variables available and Vies tells you which one but you don't have easy access to ALL the variables that your template is able to process.
The simplest solution is to look inside the views module directory, views/theme/ all of these templates are the default view display and contain code that prints the varibles, arrays etc that your view will generate.