How to apply diff rules of the languages in gitattributes - libgit2

For example, the .gitattributes file of lg2s has the line *.cs diff=csharp. the output of the codes
using (var repo = new Repository(#"path\to\lg2s"))
{
var tree1 = repo.Lookup<Commit>("a845db9").Tree;
var tree2 = repo.Lookup<Commit>("d677741").Tree;
var patches = repo.Diff.Compare<Patch>(tree1, tree2);
foreach (var patch in patches)
{
Console.WriteLine(patch.Patch);
}
}
is (shortly)
diff --git a/LibGit2Sharp/RepositoryStatus.cs b/LibGit2Sharp/RepositoryStatus.cs
## -59,8 +59,8 ## namespace LibGit2Sharp
but the output of git bash is (shortly)
diff --git a/LibGit2Sharp/RepositoryStatus.cs b/LibGit2Sharp/RepositoryStatus.cs
## -59,8 +59,8 ## internal RepositoryStatus(Repository repo, StatusOptions optio
the second line not same.
Looks like there are an in-depth discussion Add .gitattributes support libgit2/#508, but the PR Add APIs for git attributes libgit2/#516 is merged or not?
How many languages were supported now?
Can we specify the rules without gitattributes file?

This is actually an issue of diff drivers and custom function context rules for diffs, not one of attributes.
Those files do have the diff=csharp attribute; the problem is that the attribute doesn't mean anything to libgit2.
When git and libgit2 generate diffs, they use regular expressions to find the name of the function in which a diff hunk occurs. They also have a fallback rule if no regular expression is available to find the first line that did not start with whitespace.
git contains a table of built in diff drivers that includes a definition of the csharp driver.
libgit2 does not contain that table (as discussed in the PR that merged diff driver support) and hence has no built in notion of what pattern to use for diff=csharp.
Your alternatives for solving this are either:
Make an entry in your .git/config file (or your $HOME/.gitconfig) that implements diff.csharp.xfuncname with a pattern to search, or
Start a Pull Request to libgit2 that imports the driver definitions. The issue with importing (and the reason I didn't take it on) is that it will involve getting permission from the original authors of the code to relicense it for use in libgit2).
If you decide to start a Pull Request and you get the author of the CSharp xfuncname patterns to agree to relicense the code for libgit2, let me know and I'll be happy to collaborate on the actual implementation!

Related

Is there an official Concourse pipeline grammar?

I couldn't find it online after a little bit of searching, so i'm asking it here. Is there a 'reference' bnf grammar file for yaml file of concourse's pipeline ? As a side project, I'm trying to create an IntelliJ plugin that could do syntax highlight and auto completion for CI/CD Concourse pipelines, and would try to avoid manually retyping all that grammar to minimize error risk and time.
I don't believe there's a "grammar file" - the types are defined in code. For example, the top level pipeline is defined here as:
type Config struct {
Groups GroupConfigs `yaml:"groups" json:"groups" mapstructure:"groups"`
Resources ResourceConfigs `yaml:"resources" json:"resources" mapstructure:"resources"`
ResourceTypes ResourceTypes `yaml:"resource_types" json:"resource_types" mapstructure:"resource_types"`
Jobs JobConfigs `yaml:"jobs" json:"jobs" mapstructure:"jobs"`
}
The atc.Config.Validate() command is also based on code - not an external grammar.
You could probably reason through those source files to determine the structure. It might be possible to generate a jsonschema from the go types and then use that.

How to calculate a module's dist hash

I have Perl 6 installed in ~/.rakudo-star/rakudo-star-2018.04, using LoneStar. When zef installs a module, it gets installed into a subdirectory of the Rakudo Perl 6 directory. In here is a directory named perl6/site/resources, which seem to hold all the installed files. How can I figure out which module is contained in which file, using Perl 6?
If you want to get the source of a namespace that would get loaded you can do:
my $module-name = 'Test';
# Get a Distribution object which provides an IO interface to its contents
my $compunit = $*REPO.resolve(CompUnit::DependencySpecification.new(:short-name{$module-name}));
my $distribution = $compunit.distribution;
my $handle-from-name = $distribution.content($distribution.meta<provides>{$module-name}.keys[0]).open;
say $handle-from-name.slurp(:close);
# Or if we already know the name-path:
my $handle-from-path = $distribution.content("lib/Test.pm6").open;
say $handle-from-path.slurp(:close);
Note that $compunit.distribution will only work if resolve returned a CompUnit from a CompUnit::Repository::Installation repository.
rakudo#1812 is the framework to improve this further, allowing individual repositories to be queried ( $*REPO.resolve iterates the linked list of repos to give a result ) and unifying behavior for resolve/candidates/etc between CompUnit::Repository::Installation and CompUnit::Repository::FileSystem.
If I remember correctly, you shouldn't. It's zef the one that must take care of it. But if you positively have to, use the SHA1 signatures in the directory with zef locate
zef --sha1 locate 5417D0588AE3C30CF7F84DA87D27D4521713522A
will output (in my system)
===> From Distribution: zef:ver<0.4.4>:auth<github:ugexe>:api<>
lib/Zef/Service/Shell/PowerShell/download.pm6 => /home/jmerelo/.rakudobrew/moar-2018.06/install/share/perl6/site/sources/5417D0588AE3C30CF7F84DA87D27D4521713522A
From your question, it's not too clear if what you want to do is the opposite, that is, find out which SHA1 corresponds to which file; in that case, try and to this:
zef locate bin/lwp-download.pl
which will return
===> From Distribution: LWP::Simple:ver<0.103>:auth<Cosimo Streppone>:api<>
bin/lwp-download.pl => /home/jmerelo/.rakudobrew/moar-2018.06/install/share/perl6/site/resources/059BD7DBF74D1598B0ACDB48574CC351A3AD16BC

How do I generate the variation file for all assets

I'm new to Akeneo, and I discovered profile configuration for assets.
So I imported my YML in order to add asset transformations, and now, cli based, I can't find a command that allows me to generate the variation file for all assets. I saw the command to do that asset by asset and channel by channel, but I need to do that for all of them.
Do you know how I can manage to do that ? I already tried pim:asset:generate-missing-variation-files but that didn't change anything
There is no built-in command to do that, however you could develop a very simple command to achieve this.
You can use the pimee_product_asset.finder.asset service to call retrieveVariationsNotGenerated() in order to retrieve every variation that are not yet genreated, then finally use the pimee_product_asset.variation_file_generator to generate the variation with generate().
Not tested code, but this would be like that:
$finder = $this->get('pimee_product_asset.finder.asset');
$generator = $this->get('pimee_product_asset.variation_file_generator');
$variations = $finder->retrieveVariationsNotGenerated();
foreach ($variations as $variation) {
$generator->generate($variation);
}

How do I find the version and authority of a Perl 6 module?

In Bar.pm, I declare a class with an authority (author) and a version:
class Bar:auth<Camelia>:ver<4.8.12> {
}
If I use it in a program, how do I see which version of a module I'm using, who wrote it, and how the module loader found it? As always, links to documentation are important.
This question was also asked on perl6-users but died before a satisfactory answer (or links to docs) appeared.
Another wrinkle in this problem is that many people aren't adding that information to their class or module definitions. It shows up in the META.json file but not the code.
(Probably not a satisfying answer, because the facts of the matter are not very satisfying, especially regarding the state of the documentation, but here it goes...)
If the module or class was versioned directly in the source code à la class Bar:auth<Camelia>:ver<4.8.12>, then any code that imports it can introspect it:
use Bar;
say Bar.^ver; # v4.8.12
say Bar.^auth; # Camelia
# ...which is short for:
say Bar.HOW.ver(Bar); # v4.8.12
say Bar.HOW.auth(Bar); # Camelia
The ver and auth methods are provided by:
Metamodel::ClassHOW (although that documentation page doesn't mention them yet)
Metamodel::ModuleHOW (although that documentation page doesn't exist at all yet)
Unfortunately, I don't think the meta-object currently provides a way to get at the source path of the module/class.
By manually going through the steps that use and require take to load compilation units, you can at least get at the prefix path (i.e. which location from $PERL6LIB or use lib or -I etc. it was loaded from):
my $comp-spec = CompUnit::DependencySpecification.new: short-name => 'Bar';
my $comp-unit = $*REPO.resolve: $comp-spec;
my $comp-repo = $comp-unit.repo;
say $comp-repo.path-spec; # file#/home/smls/dev/lib
say $comp-repo.prefix; # "/home/smls/dev/lib".IO
$comp-unit is an object of type CompUnit.
$comp-repo is a CompUnit::Repository::FileSystem.
Both documentations pages don't exist yet, and $*REPO is only briefly mentioned in the list of dynamic variables.
If the module is part of a properly set-up distribution, you can get at the meta-info defined in its META6.json (as posted by Lloyd Fournier in the mailing list thread you mentioned):
if try $comp-unit.distribution.meta -> %dist-meta {
say %dist-meta<ver>;
say %dist-meta<auth>;
say %dist-meta<license>;
}

Branching with clearcase remote client

I am trying to branch a file in ClearCase Remote Client.
I have the branch set up and the config spec is updated to handle the branch.
But I can't find the option, and the googling isn't helping much.
The way I understand your question, it sounds like you want to somehow select a command from a Clearcase RC menu(s) and have the branch explicitly created(?)
Clearcase has no explicit "Generate Branch for this File" command; you would want the "Checkout" command in this case. Branching is indirect and is a result of checking out a version of a file in a view that has a config spec with the '-mkbranch ' operation in it. I.e. the following config spec will create the dev_1.0_branch once I check it out (for any and all vobs and files):
element * CHECKEDOUT
element * .../dev_1.0_branch/LATEST
element * /main/LATEST -mkbranch dev_1.0_branch
The first line is standard for views in which you are doing development, line 2 will assure that I see any file that has a dev_1.0_branch (particularly important for the checkout+mkbranch to work as expected :-), and line 3 will select the latest version of any file that does not have a dev_1.0_branch and will create the branch if (and only if) the file version selected by that rule is checked out.
Please let me know if any of the above sounds greek to you, particularly any of the config spec rules. Having worked with ClearCase for a long time, I assume and use a lot of its terminology and concepts as if it's common knowledge :-P.
One thing of note: if you checkout the file, then immediately uncheckout the file, you will leave an empty branch on that file (i.e. in the above you would have a file with a version such as: foo.c##/main/dev_1.0_branch/0, but no /main/dev_1.0_branch/1 version). Many sites prefer to keep the version tree clean and remove empty branches (one can be found in this IBM Rational Technical article)
Just to be clear, I'm familiar with ClearCase Base & ClearCase MultiSite, but have not worked with the Remote Client yet.
--- 2009-Jun-29 Update
In response to Paul's comment below, if you want to be selective in what files are branched, you can modify the "*" to be more specific. For example, if you want to only branch foo.c in the FOODEV VOB, but leave everything else on main:
UNIX config spec:
element * CHECKOUT
element * .../my_dev_branch/LATEST
element /vobs/FOODEV/src/foo.c -mkbranch my_dev_branch
element * /main/LATEST
(For windows, you would want to use Windows conventions. I.e. \FOODEV\src\foo.c).
You can also select a directory and all elements below the directory (again UNIX config spec):
element * CHECKOUT
element * .../my_dev_branch/LATEST
element /vobs/FOODEV/src/mycomponent/... -mkbranch my_dev_branch
element * /main/LATEST
The main page for config_spec (cleartool man config_spec from the command line on windows or unix) provides decent guidance in the "Pattern" section for how to write the element/version selector (2nd column).
You can do a lot of complex version selection with the config specs. Please let me know if you would like more details or specifics.
Here's a config spec that I used for fixing a particular bug, with names changed to disguise some of the guilty.
element * CHECKEDOUT
element * .../TEMP.bugnum171238.jleffler/LATEST
mkbranch -override TEMP.bugnum171238.jleffler
include /clearcase/cspecs/project/version-1.23.45
To create the branch, in each VOB, I used a command:
ct mkbrtype -c 'Branch for bug 171238' TEMP.bugnum171238.jleffler#/vobs/project
Previously, we used config specs with -mkbranch rules appended to the various element lines.