dannyt
-
Posts
416 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by dannyt
-
-
HI,
I was reading this article today about the growth of GIT and I found the figure below quite interesting, plus there were a few comparison comments that were informative.
but Eclipse's 2011 survey of 704 developers still has Subversion as the source code management system of choice, with 51.3 percent of respondents using it. CVS, also a centralized system, comes in second at 13.3 percent. Git follows with 12.8 percent, while Mercurial was used by 4.6 percent
It placed the user base of GIT as much greater than Mercurial and yet I have noticed in the LabVIEW world a general settling on Mercurial & SubVersion
cheers
Danny
-
No this is a remote connection from a window PC to a Linux device.
This thread might be of interest to you it covers TCP/IP error 66 & 56 disconnection errors and some suggestion on how to overcome or deal with them
cheers
Dannyt
-
HI,
A big sorry to the Lava Admin's I am having a bad day today.
I created a new uncertified CR today and got the thread title wrong, WRONG TITLE could I please ask a admin to change the Tile -
from
[Discuss] Danny Thomson
to
[Discuss] ClearCase API
I initially clicked on the "Report to Moderator" link to make this request, and just as I posted the report I notice the small print that that link should only be used to report " ONLY for reporting objectionable material " I am not sure if I managed to press Cancel in time or not, so sorry if I submit the report as well. like I said I am having a bad day.
cheers
Dannyt
-
Name: ClearCase API
Submitter: dannyt
Submitted: 13 Jun 2011
File Updated: 15 Jun 2011
Category: *Uncertified*
LabVIEW Version: 2010
License Type: BSD (Most common)
ClearCase API v1.0.0
Copyright © 2011, Danny Thomson
All rights reserved.
Author: Danny Thomson
LAVA Name: Dannyt
Contact Info: Contact via PM on lavag.org
LabVIEW Versions:
LabVIEW 2010
Dependencies:
oglib_string v2.6-1
oglib_file v3.0.1-1
Description:
The API provides an interface to communicate with the CleaCase source control tool.
This API is not meant as a integrated ClearCase provider in LabVIEW.
Installation and instructions:
Installation is performed by VIPM, after which a palette is created in the user.lib palette.
sourcecode can be found here BitBucket
Examples:
No examples are included
Known Issues:
This package only supports Windows ClearCase clients and only supports Base ClearCase no UCM is supported at present.
Acknowledgements:
Thanks to Ton Plomp for inspiration with his Mecurail API
Version History:
v1.0.0: Initial release of the code.
License:
BSD (Most common)
Support:
If you have any problems with this code or want to suggest features:
please go to lavag.org and Navigate to LAVA > Resources > Code Repository (UnCertified) and
search for the "" support page.
Distribution:
This code was downloaded from the LAVA Code Repository found at lavag.org
Some Details of functions provided
=================================
Supports Windows only, though most of the Cleartool commands and options are the same on Unix
Assumes default instilation of ClearCase working with Dynamic Views
If ClearCase is NOT installed in default location then you can manually alter install location in ClearToolPath.vi
Two types of methods
1) VI using ClearCase Cleartool command line all named *_ct.vi
2) VI using the ClearCase Automation Library (CAL) all named *_cal.vi
No interface currently provided for UCM ClearCase operations
Add.vi
========
This VI will add an element or directory to Clearcase ie create a new ClearCase Object.
NOTES
1 The Parent Object (directory) must be a ClearCase Object
2 The Parent object will automatcially be checkedout if it is not already checkedout
3 By default both the parent dir and the added object will be left checkedout
4 If adding a file, the file must already exist
5 If adding a directory , the directory must NOT exist, remember to set Directoy? to true
A creation comment can be added Comment.
Copyright 2011 - Danny Thomson
No waranty included
BranchInfo.vi
=============
This Vi checks if the Branch Name passed in exists in the VOB specified by a Valid VOB Object and if it does it will return the following information.
branch exist? true / false
locked state? True (locked) False (unlocked)
branch description Branch creation comment
obsloete? True (locked & obsolete) false (just locked)
Note only the supplied VOB is checked branch could exist in other VOBs
uses Cleartool command describe -type brtype with formating options
Copyright 2011 - Danny Thomson
No waranty included
CheckIn.vi
====================
This VI will attempt to checkoutin a ClearCase Object (file or folder).
uses ClearTool --- uncheck/out | unco [ –kee/p | –rm ] { –cact [ pname ... ] | pname ... }
–kee/p
Preserves the contents of the checked-out version under a file-name of the form element-name.keep (or, to prevent name collisions, element-name.keep.1, element-name.keep.2, and so on).
–rm
Does not preserve the contents of the checked-out version. Thus, any edits that had been made to the checked-out version are lost.
NOTE. Error -2904 if files in not checked out
Copyright 2011 - Danny Thomson
No waranty included
CheckOut.vi
=================
This VI will attempt to checkout a ClearCase object (FIle or Folder).
INPUTS
----------
FileName & Path itme to be checked out can be file or floder
Checkout comment A checkout comment
checkout Type see below
CC Branch A optional branch to checkout on e.g \main \main\dev\ats\111 see below
uses ClearTool
checkout | co [ –res/erved ] [–unr/eserved [ –nma/ ster ] ]
[ –out dest-pname | –nda/ ta ] [ –pti/me ]
[ –bra/nch branch-pname | –ver/sion ] [ –nwa/rn ]
[ –c/omment comment | –cfi/le comment-file-pname | –cq/uery | –cqe/ach
| –nc/omment ][ –q/uery | –nq/uery |–use/hijack ] pname ...
–res/erved
Reserves the branch: no user in another view can perform a reserved checkout of the same branch (but any number of unreserved checkouts can be performed); no new versions can be created on the branch until your checkout is changed to unreserved with unreserve or resolved with checkin or uncheckout. If you specify both –reserved and –unreserved, this command performs a reserved checkout if possible; otherwise, an unreserved checkout.
–unr/eserved [ –nma/ster ]
Leaves the branch unreserved; other users, in other views, can check out the same version (but at most one of the checkouts can be reserved).
CC BRANCH
Default - blank. View Config specifications rules will be applied.
This allows a specific branch to be used to be used to checkout the file. NOTE branch must in this case MUST be the full branch path ie \main\dev-ats-456 not the branch type dev-ats-456. If CC Branch is used the CC warning messages are suppresed as they WILL occurs, but do not indicated we have have a problem, the branch used MUST EXISTS for the objects being checked out
Copyright 2011 - Danny Thomson
No waranty included
CreateBranchType.vi
===================
This VI will create a new ClearCase Branch Type
Uses CAL
Copyright 2011 - Danny Thomson
No waranty included
CreateLabelType.vi
===================
This VI will create a new ClearCase Label Type
NOTE Label Type Names cannot have spaces in them, else they will be invalid
Uses CAL
Copyright 2011 - Danny Thomson
No waranty included
FileInfo.vi
=================
This Vi finds information on the ClearCase element & version matching the input File or Folder
Outputs
----------
View Private File True if item is not a ClearCase Object other outputs are only valid IF this is FALSE
Labels List of Labels applied to this element. Label (0) is latest label
Flags
IsCheckedOut -- True / False
IsLatest -- True / False
General Info
Branch -- associated branch for file
Extended Pathname -- full ClearCase exteneded pathname ie test.vi@@/main/dev-ats-345
identificer -- see above the bit after ther @@
comment -- if checked in checkin comment else shows checkout comment
using CAL
Copyright 2011 - Danny Thomson
No waranty included
FilesOnBranch.vi
=====================
This Vi lists files on the clearcase branch Branch Name provided.
This VI needs a path to a Valid VOB Object to work.
Default is for Output paths to be Absolute Pathnames using the Windows Mapped Drive. This can be change using the Return Path Type input
Output Cluster
- Total Files on branch
- LabVIEW files on branch ie llb, vi, vit, ctl
- Directories on branch
- Other files On branch
uses ClearTool
find pname -all -nxname -visible -version "brtype(%s)" -print
NOTE. This VI does NOT check the branch exists, such a check should be run first CtViewExists.vi
Copyright 2011 - Danny Thomson
No waranty included
GetConfigSpec.vi
=====================
Gets the ClearCase View Configuration Spec for the View specified ViewTag
Uses ClearTool -- catcs -tag
Copyright 2011 - Danny Thomson
No waranty included
GetViewTagAndCSpec
=====================
This Vi will get the ClearCase ViewTag & releated View Configuration Spec
valid for the provide file or folder
Uses ClearCase Automation Libray
Copyright 2011 - Danny Thomson
No waranty included
LabelFiles.vi
==============
This VI will attach a already created Label Type to the version of the current directory selected by your view,
and to the currently selected version of each element in and below the current directory.
Uses CAL
Copyright 2011 - Danny Thomson
No waranty included
ListBranchTypes.vi
===================
This VI will provide a list of all the Branch Types in a VOB
This VI can take a long time if there are many branches in the VOB !!!!!
using CAL
Copyright 2011 - Danny Thomson
No waranty included
ListCheckOuts.vi
=======================
This Vi finds Checkedout files in the VOB selected by the
File Or folder in VOB input
Output
----------
2-D arrray listing checkedout files
Columns are PathName - View checkedout in --- branch checkedout on -- user checkedout to
using CAL
Copyright 2011 - Danny Thomson
No waranty included
ListLabelTypes.vi
=================
This VI will provide a list of all the Label Types in a VOB
This VI can take a long time if there are many Labelss in the VOB !!!!!
using CAL
Copyright 2011 - Danny Thomson
No waranty included
ListPrivateFiles.vi
========================
This Vi lists the view private files in the VOB and View specified
Inputs
-------
Valid VOB Object Specify VOB
ViewTag Specify ViewTag
Include Checkouts ?(F) If True Checkedout files will be included in results else they will be ignored
Default is for Output paths to be Absolute Pathnames using the Windows Mapped Drive. This can be change using the Return Path Type input
Output Cluster
- Total Files on branch
- LabVIEW files on branch ie llb, vi, vit, ctl
- Directories on branch
- Other files On branch
uses ClearTool
cleartool lsp·rivate [ –tag view-tag ] [ –inv·ob vob-selector ] [ –l·ong | –s·hort ]
[ –siz·e ] [ –age ] [ –co ] [ –do ] [ –oth·er ]
NOTE. This VI does NOT check the branch exists, such a check should be run first CtViewExists.vi
Copyright 2011 - Danny Thomson
No waranty included
SetConfigSpec.vi
====================
Set the ClearCase View Configuration Spec for the View specified ViewTag
Input
-------
Filename Text File that supplieds the view config spec
Uses ClearTool -- setcs -force filename.txt
No waranty included
UndoCheckOut.vi
--------------------
This VI will attempt to undo a checkout on ClearCase File.
uses ClearTool --- uncheck/out | unco [ –kee/p | –rm ] { –cact [ pname ... ] | pname ... }
–kee/p
Preserves the contents of the checked-out version under a file-name of the form element-name.keep (or, to prevent name collisions, element-name.keep.1, element-name.keep.2, and so on).
–rm
Does not preserve the contents of the checked-out version. Thus, any edits that had been made to the checked-out version are lost.
NOTE. Error -2904 if files in not checked out
No waranty included
ViewExists.vi
-----------------
This Vi checks that the VIEW specified by the supplied View Tag exists
Using ClearTool --- lsview
No waranty included
-
My interest in text representation would be version control. At my company, the general procedure for software qualification is that old versions are compared to new versions with text compare by a non-technical QA guy, and I explain all of the changes. This actually works out very well, since it forces me to have formal check of all changes. This is not possible with my version of LabVIEW.
I disagree totally, this IS possible with LabVIEW.
It has been possible (though not necessarily easy) with LabVIEW for several version now, but has become increasingly easy with LabVIEW 2010 and useing the seperate source & compile code feature.
Using separate source and compile code feature in LabVIEW 2010 you can now ensure that only VI's that you have actually change i.e. edited by a developer are saved into the source control tool. So this mean is is now easy to see which file you need to compare, rather than as used to be the case all those recompiled file and the file you actually changed.
Using the LVCompare tool will allow you to do a side by side compare of the differences and you can sit down with somebody and talk them through the changes just as you could with a text file (it help to have two monitors one version on each)
Dannyt
-
Hi,
Finally I have gotten round to doing some work on a package of code that I would like to end up in the Lava CR.
It is an API to allow use of the ClearCase source control in LabVIEW. I am not sure how many people will find it of interest but just doing this has been a learning experience for me.
I have used Ton Plomp's Mecurial API package as inspiration, thanks Ton.
A lot of the code I have had and been using for a couple of years, but making into an API that anybody can use has changed how I have to look at the code. I have now done quite a bit of functionality, but I have a general question and would like some advice.
Thought the example below is a specific the questions it ask can generally be applied to a number of my VI's
I have a VI GetExtendedPathName.vi that gets for a file or folder the ClearCase extended pathname for example my.vi@@\main\dev-ats-23\4, in getting the information I also find out if the file or folder in question is checkedout and also some other possible information about that VI.
So the first question is should I provide both the extended pathname and the file 's checkedin / checkout state as output in the same VI or should I separate this out into two VI
GetExtendedPathName.vi & IsObjectCheckedOut.vi even thought the code within each is basically the same I am just ignoring one of the possible output.
I know I could write a private GetObjectInfo.vi which is called by two public VI's GetExtendedPathName.vi & IsObjectCheckedOut.vi but at the top level user view should there be two VI or one. I currently only have one VI but I feel this is wrong.
Second question is on how to address error's in particular predictable error's. So in the example above in order to get this information the file or folder I am looking at needed to be a ClearCase object (i.e. added to the repository at some time), so one possible error is if the user trys to get this information on a file that is still not added into the source control system. In this case should I return the error " −2911 The specified file is not under source control" or as I know what that error means should I clear the error and set a FP flag "File is View Private" true.
The second question also applies to things like checkin or checkout file if you try to checkout an already checkedout file should you error or clear the error and flag that file is already checkedout.
I hope these questions make some sense and I would appreciate other peoples views on this.
I suppose a final question is would anyone actually be interest or find such a package useful.
cheers
Dannyt
-
Hi,
I have added an idea here to hopefully improve the usability of the LVCompare function idea link
I would like to optional command line switch to be available from within the resulting "Differences" window
cheers
Dannyt
-
Hi,
A small update, if you want to be able to use the possible command line switches, with the LVCompare.exe and ClearCase you will need to use some form of wrapper to allow you to select the switch options and add them to the ClearCase passed in args and pass then onto LVCopmare.
Here is a simple version, written in LabVIEW 2010.
When you do a ClearCase difference it will launch the pop up below allow you to select the compare options then launch the compare
The Zip file contains the files
go_compare.vi
Go-Compare.exe
Install NOTES.txt
To install
1) Copy the executable to the dir
C:\Program Files\National Instruments\Shared\LabVIEW Compare\
2) Edit the Clearcase map file
C:\Program Files\Rational\ClearCase\lib\mgrs\map make a copy first :-)
the lines for the z_whole_copy compare & xcompare should be changed
from
z_whole_copy compare ..\..\bin\cleardiff.exe
z_whole_copy xcompare ..\..\bin\cleardiffmrg.exe
to
z_whole_copy compare ..\..\..\..\National Instruments\Shared\LabVIEW Compare\Go-Compare.exe
z_whole_copy xcompare ..\..\..\..\National Instruments\Shared\LabVIEW Compare\Go-Compare.exe
if you only want the default LVCompare without the wrapper to change compare options use
z_whole_copy compare ..\..\..\..\National Instruments\Shared\LabVIEW Compare\LVcompare.exe
z_whole_copy xcompare ..\..\..\..\National Instruments\Shared\LabVIEW Compare\LVcompare.exe
Hope some people find this useful
-
That looks really sweet, I am now trying to think of a good excuse to use a tray icon in our project +1 from me
cheers
Dannyt
-
Because he can't afford more?
-
Absolutely amazing
-
I tried saving the data in the loop but it creates many files. I have placed a time tag on the file path so that each time the program starts it writes the data/time on the file name. Inside the loop when it saves the data, it tries to save it to the same file but the time and hence file name have changed, so it creates multiple files. How can I solve this?
It is quite simple to save the data in each loop to only one file, by doing something like this -
Firstly as you are talking about spreadsheets I would format any data to be saved in a CSV format so this can easily be open in Excel or as a text file later.
Open a file before you loop starts, this could be either a new files or an existing one. Pass the reference to this file into you loop and each time round your loop append you data into the file, when your loop finishes close the file.
Look in the LabVIEW Example Finder, there is a example VI "Write to Text File.vi" in the Fundamentals --> File Input & Output category that shows how to write to the same file in a loop
Danny
-
As for OpenG - that feature would require LabVIEW 2010. The next upgrade of the libraries are for 2009. So this question may pop up in the future (although given the feedback here on LAVA it seems that this feature needs some work).
OK, I can see that it is for now an irrelevance for OpenG. My personal experience of LabVIEW 2010 & this separation feature is only to the good I must say.
As for packages in general - end users install a package which contains dist code. They do not check in and out the code etc. I am not sure how this would affect the end user? Would it help with builds? Etc.
I would like to see a discussion of the benefits here.
In answer to this part, hopefully developers of packages in general ARE keeping their source code in some sort of SCC, and it is from this they build thier packages. So if they are working in LabVIEW 2010 they will get the benefit for themselves in maintaining that code. It provides no benefit as you say to the end user of the package.
Danny
-
Just a general though / question and I think this applies to both OpenG & LAVA CR's so I was not quite sure where to put this.
I am working on a LAVA CR package and I intend to separate source & compile code and it had me thinking. What is the general take that people have on the separation of source & compile code issue for new tools or LAVA CR's that a LabVIEW 2010 or newer. I did see a comment, but cannot find it now, for NI that this will sometime in the future become the default setting rather than an option.
As this setting can be do programming, I was also think that maybe this could be a feature request for the VIPM, similar to the mass compile on install setting.
Dannyt
-
Just right click and select "generate code". Nothing clever. Even I can do it
wow
meant to give +1 to Shaun but gave it to jgcode hey so both have +1
-
Hi
I was looking at Ton Plomp's Mercurial API over the last few days (I hope to announce why in a few weeks) and I noticed a piece of code similar to this
It took me a couple of seconds to see it was a simple pattern match and as I always use the Match Pattern privative or for something more complicated a match regular expression privative I was intrigued as to why he did it this way and looking further I found out something I suspect many of you know already.
I ran some tests using Ton's method, Match Pattern & Match Regular Expression all just match something at the start of a string. I ran each in a loop 500000 times
EDIT Picture updated thank you Shaun
I think I knew Match Regular Expression was a "heaver" VI than Match Pattern, I think it says so in the documentation somewhere, but it was interesting to see it was so much slower than the other two methods. I am sure that at times in my code I have used Match Regular Expression where it is not really called for, often I was trying to match something more complicated then when the matching was optimised I never changed back to the simpler match pattern.
It is interesting to see that in terms of performance both the other method are the same in terms of time, but Ton's method only uses ~75K for my test VI but around ~210K for the match pattern.
Anyway, thanks Ton, I must look at more of the LAVA CR code it is so interesting seeing how others do things.
cheers
Dannyt
-
You can track this bug here: ID: 3275738
Kudos for your optimism
I have added your post to the bug tracker, its in the system now, which is better than before
thank you
-
HI,
I have copied this issue I raise on the OpenG forums a while ago now as it is a tool I use a lot and I have a proposed fix (maybe not the best one). I would really like to see if this could be progressed.
cheers
Dannyt
--------------------------------
Hi,
Under LabVIEW 7.0 I found the package ogrsc_compare_vi_to_disk-1.1-1 to be very useful, we used it a great deal to carry out peer reviews of our code.
Since recently upgrading to LabVIEW 8.2.1, I found this package no longer worked.
I have spent a bit of time playing with it and have now managed to fix it. I had to change the main VI compare_vi_to_disk__compare_vi_to_disk.vi
to be aware of application contexts. I do not know if my method is the best way to fix this problem, or if this work is already in progress, but it does work
and allows me to use this useful package again.
In case anybody else find this useful I have attached a labVIEW 8.2.1 copy of my fix below, it needs to replace the existing version in the
the compare_vi_to_disk.llb in C:\Program Files\National Instruments\LabVIEW 8.2\project. I have only check it works for package version 1.1-1
compare_vi_to_disk__compare_vi_to_disk.vi
compare_vi_to_disk__compare_vi_to_disk_auto_run_off.vi
The second version is with the auto run at open disable, so less hassle to see the changes.
How does one go about requesting, the package to be updated or offering help to get packages update ?
-
1
-
-
Hehe, and if you look at my profile, you'll see that I have the same friend twice.
they must be very friendly then
-
A reminder from our firends at sixclear that "Suspend When Called" isn't just to suspend when called
Excellent little titbit thank you
-
pretty please, what am I doing wrong with my friends list ?
bump
-
Congratulation
-
Hi Jim and All
I would like to thank and applause the people who have made this happen
:beer_mug:
it just makes so much sense. I think it is a great step forward in revitaling the OpenG community and look forward to see how this evolves OpenG going forward.
cheers
Dannyt
-
1
-
-
Ok,
I've got another rebuild that installs cleanly (for me anyway) on LV2010 64bit. Unfortunately the Code Repository file uploader is being funny and not letting me upload the file right now.
Edit: Code Repository playing ball now. Version updated. Any reports problems installing on LabVIEW 2010 or 2009 happily accepted.
Hi Gavin,
That is great thank you, I can now load the package OK into LabVIEW 2010
An intresting article on GIT's growth
in Source Code Control
Posted
Yes I noticed the comment about large binaries. I think it depends on the project size you are working on, small tool-set type projects it is not a problem, but large application maybe be a different matter
Danny