MKS How to list all members with their revision number on a devpath - repository

I am familiar with the MKS CLI, namely the si field, however I have a tough time honing in on the right command to get the information I need.
I am wanting to write a command against an MKS repository with
The devpath name
The rev number of that dev path
And the output to be
A list of all the members of that dev path
With each member, the specific rev of that member for that devpath rev.
I have a feeling si rlog ... can do this, but I can't figure out the right commands.

si viewproject --project=? --devpath=? should give you what you want.

You can use si rlog if you dont want to see subproject info but you have to limit to a single revision e.g. member revision
si rlog -R --project=? --devpath=? --noheaderformat --notrailerformat --revision=:member --format="{membername}\t{revision}\r\n"
If you are speaking of revision number of devpath I guess you mean a checkpoint within that devpath. Then you should do something like
"--projectrevision=1.2.1.2" instead of "--devpath=?"

Related

Finete State machine visualizer

I need an application that prints/visualizes input/output pairs during the FST runs. I mean, for each state of the fst, it needs to print out a tuple that contains input for that state and output of the state. Right now I can generate fst files that is compatible with foma,hfst and xfst fst tools. So, I guess the visualization tool I need should be enough to compatible with any of them. Is there anyone who knows such a tool ?
foma can produce dot format files that can be visualized by graphviz. On Debian/Ubuntu, install graphviz with
$ sudo apt-get install graphviz
foma can read att format files (produced with hfst-fst2txt for anything HFST can read, or lt-print for anything from lttoolbox); assuming you've got such a file named myfst.att, you can do
$ foma
foma[0]: read att myfst.att
foma[1]: view
to display the full FST. That will show each input/output pair on each edge between states of the FST.
But you say "during runs" – are you talking about also showing the queue of "live states"? If so, I don't know of a tool that does this, that would be nice! One thing you could do is to modify the HFST source to output the list of live states and string vectors as it's processing, and then combine that with the dot file to e.g. colour in the live states. (If so, you may want to take this to the #hfst channel on irc.freenode.net.)
There is also a script att2dot.py on https://ftyers.github.io/2017-%D0%9A%D0%9B_%D0%9C%D0%9A%D0%9B/hfst.html that can be used on the command line like
hfst-fst2txt chv.lexc.hfst | python3 att2dot.py | dot -Tpng -ochv.lexc.png if you prefer something more scriptable. If you use that from the Python library of HFST, you might be able to get the "live states" for every part of an analysis more easily.

Find the date/time a process was created in OpenVMS

I can't seem to find the date/time a process was created in OpenVMS V8.3-1H1.
The sh proc/all PROCESS_NAME command does show a Connect time which at first I though it is the time since the process was created, but after a few tests I discovered that it is not.
I have search the PDF documents I have from HP, the Ask the Wizard archive and openvms.org but to no avail.
The HP OpenVMS DCL Dictionary, for f$getjpi explains the item code LOGINTIM as String, Process creation time. So try a
$ write sys$output f$getjpi(0,"LOGINTIM")
and see if that's what you want/need.

Find the bzr revno corresponding to a revision-id

I'm still trying to figure out how the revision numbering works with bzr, despite having read the understanding revision numbers bzr documentation.
I have a local branch of an upstream repository. The local revision is 689, and I haven't made any local changes.
If I do bzr missing url/to/upstream, bzr tells me that I'm missing 10 revisions: 689-698.
Clearly the upstream revision numbering changed, since the remote 689 is now different from my local 689. What I'm trying to figure out is:
What sequence of events causes an upstream branch to get renumbered? Did my local revno 689 become a merged revision number upstream when somebody else made a change and pushed it up?
How can I use the revision-id from my local revision 689 to determine what the merged revision number is upstream? Is there a way to retrieve this using command-line bzr and/or loggerhead?
You have 2 questions there, so:
Did my local revno 689 become a merged revision number upstream when somebody else made a change and pushed it up?
Yes, that's exactly what happened.
How can I use the revision-id from my local revision 689 to determine what the merged revision number is upstream?
For CLI bzr:
Simple method: run bzr log -n0 --show-ids and search the output for your revision-id. Then scroll back to the top and see which revision has your revision id merged.
You can use qlog command (from QBzr plugin) to make your history exploring much pleasant.
With bzr 2.3+ you can use mainline: revision modifier: bzr log -r mainline:your-revid

Git - how do I view the change history of a method/function?

So I found the question about how to view the change history of a file, but the change history of this particular file is huge and I'm really only interested in the changes of a particular method. So would it be possible to see the change history for just that particular method?
I know this would require git to analyze the code and that the analysis would be different for different languages, but method/function declarations look very similar in most languages, so I thought maybe someone has implemented this feature.
The language I'm currently working with is Objective-C and the SCM I'm currently using is git, but I would be interested to know if this feature exists for any SCM/language.
Recent versions of git log learned a special form of the -L parameter:
-L :<funcname>:<file>
Trace the evolution of the line range given by "<start>,<end>" (or the function name regex <funcname>) within the <file>. You may not give any pathspec limiters. This is currently limited to a walk starting from a single revision, i.e., you may only give zero or one positive revision arguments. You can specify this option more than once.
...
If “:<funcname>” is given in place of <start> and <end>, it is a regular expression that denotes the range from the first funcname line that matches <funcname>, up to the next funcname line. “:<funcname>” searches from the end of the previous -L range, if any, otherwise from the start of file. “^:<funcname>” searches from the start of file.
In other words: if you ask Git to git log -L :myfunction:path/to/myfile.c, it will now happily print the change history of that function.
Using git gui blame is hard to make use of in scripts, and whilst git log -G and git log --pickaxe can each show you when the method definition appeared or disappeared, I haven't found any way to make them list all changes made to the body of your method.
However, you can use gitattributes and the textconv property to piece together a solution that does just that. Although these features were originally intended to help you work with binary files, they work just as well here.
The key is to have Git remove from the file all lines except the ones you're interested in before doing any diff operations. Then git log, git diff, etc. will see only the area you're interested in.
Here's the outline of what I do in another language; you can tweak it for your own needs.
Write a short shell script (or other program) that takes one argument -- the name of a source file -- and outputs only the interesting part of that file (or nothing if none of it is interesting). For example, you might use sed as follows:
#!/bin/sh
sed -n -e '/^int my_func(/,/^}/ p' "$1"
Define a Git textconv filter for your new script. (See the gitattributes man page for more details.) The name of the filter and the location of the command can be anything you like.
$ git config diff.my_filter.textconv /path/to/my_script
Tell Git to use that filter before calculating diffs for the file in question.
$ echo "my_file diff=my_filter" >> .gitattributes
Now, if you use -G. (note the .) to list all the commits that produce visible changes when your filter is applied, you will have exactly those commits that you're interested in. Any other options that use Git's diff routines, such as --patch, will also get this restricted view.
$ git log -G. --patch my_file
Voilà!
One useful improvement you might want to make is to have your filter script take a method name as its first argument (and the file as its second). This lets you specify a new method of interest just by calling git config, rather than having to edit your script. For example, you might say:
$ git config diff.my_filter.textconv "/path/to/my_command other_func"
Of course, the filter script can do whatever you like, take more arguments, or whatever: there's a lot of flexibility beyond what I've shown here.
The closest thing you can do is to determine the position of your function in the file (e.g. say your function i_am_buggy is at lines 241-263 of foo/bar.c), then run something to the effect of:
git log -p -L 200,300:foo/bar.c
This will open less (or an equivalent pager). Now you can type in /i_am_buggy (or your pager equivalent) and start stepping through the changes.
This might even work, depending on your code style:
git log -p -L /int i_am_buggy\(/,+30:foo/bar.c
This limits the search from the first hit of that regex (ideally your function declaration) to thirty lines after that. The end argument can also be a regexp, although detecting that with regexp's is an iffier proposition.
git log has an option '-G' could be used to find all differences.
-G Look for differences whose added or removed line matches the
given <regex>.
Just give it a proper regex of the function name you care about. For example,
$ git log --oneline -G'^int commit_tree'
40d52ff make commit_tree a library function
81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
7b9c0a6 git-commit-tree: make it usable from other builtins
The correct way is to use git log -L :function:path/to/file as explained in eckes answer.
But in addition, if your function is very long, you may want to see only the changes that various commit had introduced, not the whole function lines, included unmodified, for each commit that maybe touch only one of these lines. Like a normal diff does.
Normally git log can view differences with -p, but this not work with -L.
So you have to grep git log -L to show only involved lines and commits/files header to contextualize them. The trick here is to match only terminal colored lines, adding --color switch, with a regex. Finally:
git log -L :function:path/to/file --color | grep --color=never -E -e "^(^[\[[0-9;]*[a-zA-Z])+" -3
Note that ^[ should be actual, literal ^[. You can type them by pressing ^V^[ in bash, that is Ctrl + V, Ctrl + [. Reference here.
Also last -3 switch, allows to print 3 lines of output context, before and after each matched line. You may want to adjust it to your needs.
Show function history with git log -L :<funcname>:<file> as showed in eckes's answer and git doc
If it shows nothing, refer to Defining a custom hunk-header to add something like *.java diff=java to the .gitattributes file to support your language.
Show function history between commits with git log commit1..commit2 -L :functionName:filePath
Show overloaded function history (there may be many function with same name, but with different parameters) with git log -L :sum\(double:filepath
git blame shows you who last changed each line of the file; you can specify the lines to examine so as to avoid getting the history of lines outside your function.

Expression that either returns the output string from a program, or a specific string, if the program doesn't exist

I'm using mercurial as a SCM, and an output from the hg parents command in my makefile to store build number and version information in my program. However, mercurial is not always present on machines where I try to build the program. Thus, hg parent fails.
I'd like to use a substitute string (hard-coded or output from other program) when mercurial is not available. But I'm no good in makefile scripting.
Can you provide a hint how to compose a makefile-command that would store the output from a hg parents if it's available, or output from date if hg is not available, in the internal variable.
This is bit cranky but it works for me:
X=$(shell hg parent || date)