In my project I've got some internal config structures containing options registration using default values (let's say Config.x=0, Config.y=0), those values are not modifable for a client.
Sometimes users of my application want to modify default values of those fields before parsing command line arguments, so before parsing they just change those values manually (let's say Config.x=3, Config.y=4) and then fetch command-line/.ini ifle options and parse it using parseOptions.
If those external arguments contain only a part of those options i.e. Config.x=9, values of other options will be those which are registered using boost::program_options, not those currently assigned, so the result would be Config.x=9, Config.y=0 instead of Config.x=9, Config.y=4. So basically it seems that, boost::program_options::parseOptions clears all options before parsing.
Is there anyway to prevent boost from clearing already assigned options in case they do not appear in command-line arguments?
This can't be done. However, you should be able to create parsed_options either manually¹, or you can supply the options as a "faux" configfile so you can actually use the configfile parser on it.
Once you have the parsed_options you can store/notify them as usual.
¹ though this isn't supported/documented, see the comment at boost::program_option::basic_parsed_options<>
Related
I've applied the guidance on programmatic usage of M2Doc (also with this help) to successfully generate a document via the API, which was previously prepared by using the M2Doc GUI (configured .docx plus a .genconf file). It seems to also work with a configured .docx, but without a .genconf file.
Now I would like to go a step further and ease the user interface in our application. The user should come with a .docx, include the {m:...} fields there, especially for variable definition, and then in our Eclipse application just assign model elements to the list of variables. Finally press "generate". The rest I would like to handle via the M2Doc API:
Get list of variables from the .docx
Tell M2Doc the variable objects (and their types and other required information, if that is separately necessary)
Provide M2Doc with sufficient information to handle AQL expressions like projectmodel::PJDiagram.allInstances() in the Word fields
I tried to analyse the M2Doc source code for this, but have some questions to achieve the goal:
The parse/generate API does not create any config information into the .docx or .genconf files, right? What would be the API to at least generate the .docx config information?
The source code mentions "if you are using a Generation" - what is meant with that? The use of a .genconf file (which seems to be optional for the generate API)?
Where can I get the list of variables from, which M2Doc found in a .docx (during parse?), so that I can present it to the user for Object (Model Element) assignment?
Do I have to tell M2Doc the types of the variables, and in which resource file they are located, besides handing over the variable objects? My guess is no, as using a blank .docx file without any M2Doc information stored also worked for the variables themselves (not for any additional AQL expressions using other types, or .oclAsType() type castings).
How can I provide M2Doc with the types information for the AQL expressions mentioned above, which I normally tell it via the nsURI configuration? I handed over the complete resourceSet of my application, but that doesn't seem to be enough.
Any help would be very much appreciated!
To give you an impression of my code so far, see below - note that it's actually Javascript instead of Java, as our application has a built-in JS-Java interface.
//=================== PARSING OF THE DOCUMENT ==============================
var templateURIString = "file:///.../templateReqs.docx";
var templateURI = URI.createURI(templateURIString);
// canNOT be empty, as we get nullpointer exceptions otherwise
var options = {"TemplateURI":templateURIString};
var exceptions = new java.util.ArrayList();
var resourceSetForModels = ...; //here our application's resource set for the whole model is used, instead of M2Doc "createResourceSetForModels" - works for the moment, but not sure if some services linking is not working
var queryEnvironment = m2doc.M2DocUtils.getQueryEnvironment(resourceSetForModels, templateURI, options);
var classProvider = m2doc.M2DocPlugin.getClassProvider();
// empty Monitor for the moment
var monitor = new BasicMonitor();
var template = m2doc.M2DocUtils.parse(resourceSetForModels.getURIConverter(), templateURI, queryEnvironment, classProvider, monitor);
// =================== GENERATION OF THE DOCUMENT ==============================
var outputURIString = "file:///.../templateReqs.autogenerated.docx";
var outputURI = URI.createURI(outputURIString);
variables["myVar1"] = ...; // assigment of objects...
m2doc.M2DocUtils.generate(template, queryEnvironment, variables, resourceSetForModels, outputURI, monitor);
Thanks!
No the API used to parse an generate don't modifies the template file nor the .genconf file. To modify the configuration of the template you will need to use the
TemplateCustomProperties class. That will allow you to register your metamodels and service classes. This instormation is then used to configure the IQueryEnvironment, so you might also want to directly configure the IQueryEnvironment in your code.
The generation in this context referes to the .genconf file. Note The genconf file is also an EMF model, so you can also craft one in memory to launch you generation if it's easier for you. But yes the use of a .genconf file is optional like in your code example.
To the list of variables in the template you can use the class TemplateCustomProperties:
TemplateCustomProperties.getVariables() will list the variables that are declared with their type
TemplateCustomProperties.getMissingVariables() to list varaibles that are used in the template but not declared
You can also find le list of used metamodels (EPackage nsURIs) and imported services classes.
The type of variables is not needed at generation time, it's only needed if you want to validate your template. At generation time you need to pass a map from the variable name to its value as you did in your example. The value of a variable can be a any object from your model (an EObject), a String, an Integer, ... If you want to use something like oclIsKindOf(pkg::MyEClass) you will need to register the nsURI of pkg first see the next point.
The code you provided should let you use something like projectmodel::PJDiagram.allInstances(). This service needs a ResourceSetRootEObjectProvider() that is initialized in M2DocUtils.getQueryEnvironment(). But you need to declare the nsURI of your metamodel in your template (see TemplateCustomProperties). This will register it in the IQueryEnvironment. You can also register it yourself using IQueryEnvironment.registerEPackage().
This should help you finding the missing parts in the configuration of the AQL environment. Your code seems good and should work when you add the configuration part.
Regard class weka.attributeSelection.InfoGainAttributeEval
Javadoc says it has 2 options, which are expressed as command line parameters:
-M
treat missing values as a seperate value.
-B
just binarize numeric attributes instead
of properly discretizing them.
While from Weka GUI it says it has 3 options with symbolic names:
OPTIONS
missingMerge -- Distribute counts for missing values. Counts are distributed across other values in proportion to their frequency. Otherwise, missing is treated as a separate value.
binarizeNumericAttributes -- Just binarize numeric attributes instead of properly discretizing them.
doNotCheckCapabilities -- If set, evaluator capabilities are not checked before evaluator is built (Use with caution to reduce runtime).
Which option set is correct and how to know correspondence?
There is not just one correct settings. It depends on the dataset and how you wish to apply your attribute selection. The values in the GUI are default ones and of course it is not guaranteed that they are the correct settings.
In case you mean how to check the options, as you can see in the javadoc, the options in the GUI are fields of the class, not just symbolic names; they have getters and setters. You can set them via setOptions() method or via setters however you wish and if you'd like to know their values, you can get them via getters if we mention using Weka API.
I am trying to figure out whether an edge/lane is internal. When SuMO creates internal edges/lanes, it prefixes them with a colon [1]. Currently, I am exploiting this information, however, it seems that you also can annotate arbitrary other edges as internal using the tag function. This is also set for internal edges created by SuMO [1]. Therefore, I want to retrieve the information via TraCI.
To my knowledge, there is no TraCI command to retrieve this information (i.e. either the value of function or whether the edge/lane is internal).
The classes MSEdge and MSLane in the microsim directory have methods to retrieve both of those values, however, the classes Edge and Lane from libsumo do not.
I also checked whether the value of the function tag might get added to the parameter map during initialization, which I could access via TraCI's getParameter. This also does not seem to be the case. I checked some files from the netimport directory but could not find anything satisfactory.
Is there any other way to retrieve the function/isInternal information via TraCI without adding a new TraCI command (and the aforementioned missing methods in libsumo)?
This is a static property of the network so the easiest way of retrieving the information is to parse the network. In Python you can use sumolib for that:
import sumolib
net = sumolib.net.readNet("my.net.xml")
function = {}
for e in net.getEdges():
function[e.getID()] = e.getFunction()
There is currently no TraCI call for that but the colon thing is a very good indicator. The main developers are also a bit reluctant to add all static information retrieval to the TraCI API in order not to overload it.
I have a trigger which acts after 3 checks of ping. Interval of checks 3 minutes.
I need to send message like:
Host unavailable from [time of first unsuccessfully check];
Trigger [time of trigger acts]
Which macros i need to use?
With the comment about scripts I'll offer the following.
Configuration/Actions allow you to specify the content of a message. That message can be thought of as simply passing parameters to something. The easy default is that it sends email, but the same parameters can be passed to a script.
Inside the Operations section, you specify the operation as to whom to send (again, think of this as a parameter), and what media type. The user/groups become a parameter as well.
Under Administration, Media types, you can define a media type of "Script". This invokes an external script you write, and passes to it parameters, which by default the first three are the send-to, subject, and message content. You can (in later Zabbix versions) include other parameters there as well (I do not recall if there is a limit). Before that, I started just passing any data I wanted in a predictable and delimited fashion in the message body, then I parse it out inside my script.
Inside the script itself, you pick up the strings passed in, and do whatever you want. So if one parameter (subject, explicitly a 4th+ parameter, or buried in a predictable place inside the body of the message) is a time, you can then operate on that time in the language of your choice, replace it, expound upon it, etc. Then when you have what you want, you send the message from within the script as desired.
Different actions can send using different media types, so you could do a script only for certain types of triggers, based on the conditions written in the action (e.g. a specific trigger name). So you can use default behavior for some, and custom-write other triggers as desired. The key is to have predictable format in the Config/Action/Triggers, and depend on that format in the Administration/Media types parameters, and inside the script they call. Don't forget to make the script accessible to the zabbix service account and place in the location specified in the zabbix config file. I find it useful to stick with an email-format, then I can "test" my actions by just emailing them, take the resulting email and use it to call my scripts outside of zabbix and ensure they work.
The ability to extend the default alerts by using scripts (and in turn a callable interface to zabbix server itself that can pull additional data from zabbix at script execution) makes alerting a bit arcane, but incredibly powerful. In general you can dynamically include almost anything, including graphs, in the alerts by reacting to the script parameters, and pulling together data to email.
I have several Jenkins parameterized jobs that uses the same parameters and parameters values.
When I have to change the default value of one of those parameters, I need to go over all of those jobs and reconfigure them.
A simple solution to this problem would be an option to retrieve all parameters from config file (in the master/ in the workspace) but I could not find a sufficient implementation for that.
I want to be able to feed build with standard Java config file (in format "key"="value") and then refer to those parameters like every other parameters during the build.
Do you know of an appropriate solution?
Use EnvInject Plugin to read your parameters from a file as environment variables in an Inject Environment Variables build step. The glitch is that then you can't override them easily. One solution would be to use it in conjunction with the Conditional BuildStep Plugin. You can then can define a boolean parameter OVERRIDE that would be false by default. You can then run your Inject build step conditionally only when OVERRIDE is false. When you need to override your parameters with values provided by hand (on in a custom call to run the job) specify the override values and set OVERRIDE to true.
I use hudson with ant and set parameters (customer) in my hudson job. This parameter is then the name of a property file that i open with ant as follow:
<loadproperties> srcFile="${project.dir}/build/resources/${customer}.properties"/>