I know how to set a new type. What I want to do is modify an existing type. I want to add haml files to the ruby type. I could probably use --set-type and redefine the ruby type but I don't know how to redefine it and still include files called 'Rakefile' and files where the first line indicates that it is an executable Ruby script (First line matches /^#!.*\bruby/)
Here is the existing documentation for the ruby type:
ruby .rb .rhtml .rjs .rxml .erb .rake .spec; Rakefile; First line matches /^#!.*\bruby/
There are three arguments that let you work with type definitions. From ack --help:
File type specification:
--type-set=TYPE:FILTER:ARGS Files with the given ARGS applied to the given
FILTER are recognized as being of type TYPE.
This replaces an existing definition for TYPE.
--type-add=TYPE:FILTER:ARGS Files with the given ARGS applied to the given
FILTER are recognized as being type TYPE.
--type-del=TYPE Removes all filters associated with TYPE.
If all you want to do is add .haml files to the existing Ruby spec, use
--type-add=ruby:ext:haml
If you want to see how existing types are defined, use --dump.
$ ack --dump | ack ruby
--type-add=ruby:ext:rb,rhtml,rjs,rxml,erb,rake,spec
--type-add=ruby:firstlinematch:/^#!.*\bruby/
--type-add=ruby:is:Rakefile
Related
I am trying various different options of building Asterisk 11 and these will be deployed on various servers. They are all built from the same sources and have what I presume to be some sort of checksum embedded in the version ID (26dd464).
In order to distinguish the various versions of the executable I would like to add my own version number or string on similar. I note that /usr/src/asterisk/main/version.c specifies a const char [] variable asterisk_version, but if I manually edit this it gets overwritten as part of the make process. Is there a sensible way I could specify some sort of identifying label (e.g. as a parameter passed to make or some such)?
In /usr/src/asterisk/build_tools/make_version_c you can specify it. This script overwrites the file you've mentioned (/usr/src/asterisk/utils/version.c).
What would be the best practice - if there is any - to parse multiple config files?
I want to parse the mysql server configuration and also write the configuration again.
The configuration allows to issue multiple lines like:
!includedir /etc/mysql.d/
So the interesting thing is, that some configuration may be located in the main file but other may be located in a sub file.
I think pyparsing only works on ONE single file or one content string.
So I probably first need to read all files and maybe restructures the contents like adding headers for the different files...
====main file====
[mysql]
....
!includedir /etc/mysql.d/
====/etc/mysql.d/my.cnf====
[client]
.....
I would only have one pyparsing call.
Then I could parse everything into one big data object, group the file sections and have the file names as keys. This way I could also write the data back to the disk...
The other possibility would be to parse the main file and programmatically parse all other files that were found in the main file.
Thus I would have several pyparsing calls.
What do you think?
In your pyparsing code, attach a parse action to the expression that matches the include statements, have it parse the contents of the referenced files or directory of files, then merge those results into the current parse output. The parse action would make the successive calls to parseString, your code would only make a single call.
See this new example added to the pyparsing examples directory: https://github.com/pyparsing/pyparsing/blob/master/examples/include_preprocessor.py
need to run a workflow where the session has source and target variables which will be feeded the value through PMCMD command.is it possible
You cannot directly pass the source and target table names, but you can parameterize those names and put those in parameter file. Then you can pass the parameter file path in pmcmd.
You cannot have source and target names in PMCMD command
Instead create a parameter file and provide the source and target names using the
parameter identifiers like $DBConnection_Src= and $DBConnection_Tgt=
Have below format,
[Folder_Naem.WF:Workflow_Name.ST:SessionName]
$DBConnection_Src=Source_Name
$DBConnection_Tgt=Target_Name
Create this parameter file and provide the path and file name,
In the mapping tab for source and target provide the parameters specified in the parameter file
Parameter file is very helpful for dynamic parameter changes. You can edit the parameter file rather than making changes in the informatica workflow
Robot Framework allows you to import multiple resource files containing keywords with the same names, and to call them using their full name to differentiate between them. For example, if you have Resource1.robot that has a keyword called "Test Keyword" that does some action, and Resource2.robot that also has a keyword called "Test Keyword" that does a different action, when you import both resources into a test suite, your test cases can access those keywords with the syntax Resource1.Test Keyword or Resource2.Test Keyword depending on the functionality that you want.
Is there a way to do that with variables? I have two resource files - patient_records_resource.robot and patient_search_resource.robot. patient_records_resource defines a variable ${LAST NAME EDIT} | name=lname, and patient_search_resource defines a variable with the same name ${LAST NAME EDIT} | id=last-name. I'm running into the problem where a test case imports both of those files, and needs to access both of those edit boxes at different points, and consistently picks the wrong one. I have tried things like patient_search_resource.LAST NAME EDIT with no success, but that's approximately what I'm looking for.
I know I could just rename one of them, but I'd like to use that as a last resort solution. Everyone on my team makes sure to create unique variable names within a single resource file, but coming up with unique variable names across the whole test suite to avoid these collisions would add some overhead that we don't want.
There is no way to do that with variables.
All variables from resource files have the same priority. If multiple variables have the same name then only the one that was imported first is taken into use. [source]
Your only options are:
Splitting the suite with both imports into two sub-suites, ensuring that each sub-suite only imports one of the resources.
Your last resort solution: modifying your variable names to all be unique.
I agree that the latter option adds a bothersome amount of overhead, but, until RF changes the way it handles variables, it's probably your best option. Personally, I prefix all variables with a sequence of letters unique to the resource file (e.g. a resource named "Member_Central_Logging_Functions" might have all variables prefixed with MCLF).
I have named utilities and would like to mark names for later i18n usage. Is this the right way?
<utility
name="Home"
i18n:attributes="name"
provides=".interfaces..."
factory=".shortcut...." />
The utility's name is not a translatable message id, but an internal technical id. You cannot use it for translation purposes.
If you look at zope.component.zcml you can see the interface for the directive containing:
class IUtilityDirective(IBasicComponentInformation):
"""Register a utility."""
name = zope.schema.TextLine(
title=_("Name"),
description=_("Name of the registration. This is used by"
" application code when locating a utility."),
required=False)
If you look at for example http://wiki.zope.org/zope3/zcml.html it will tell you that an attribute needs to be of type MessageID to be translatable in ZCML.
If you have a ZCML directive with an attribute of type MessageID, all you need to do is to define an i18n:domain for the ZCML file. The ZCML machinery knows what attributes are translatable itself based on them being of the right type. So you don't need any extra markup to note any attributes like you need in TAL.
All that said, if you work inside Plone and use i18ndude to extract messages, it won't extract any messages from ZCML files - simply because there's not a single message being defined in ZCML, that's also actually shown anywhere in the Plone UI.
If you have utilities and want to give them translatable names, give them a title attribute, like:
from zope.i18nmessageid import MessageFactory
_ = MessageFactory('mydomain')
class MyShortCut(object):
title = _('My shortcut')
and use the title attribute in the UI.
You do not want to do that. The name attribute is meant for application use, not end-users, and needs to be stable.
If you translate it, then you'll have to translate all named look-ups through-out your code too!
Titles and descriptions can be translated, using the i18n_domain="domain" marker on the <configure> element.