LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What’s the best way of distributing code to a new dev pc?


@SteveChandler wrote:

@User002 wrote:

@SteveChandler wrote:

GIT and Mercurial do not do VI Package Management. They do not have LabVIEW pallette editors or dependency checking. They do not connect to the tools network and there are no VI Package Configurations.


Man am I happy about the simplicity of a clean vanilla LabVIEW installation with only GIT and Mercurial as a code distribution and version control back end.

 

Less is more.

 

Br,

 

/Roger

 

 


Again, VIPM has nothing to do with source control. You absolutely do not need to use it. I use it because it simplifies package management and because there are a lot of tools out there that you need VIPM to install.

 

VIPM is for stuff that goes into vi.lib. It is code that a developer will use and not edit. It is not meant for distributing a project to another development machine that will be working on that project. If you do not create "reuse code" then you do not need  the package builder. Regardless of that, VIPM is the tool that you need to install reuse code such as OpenG. It is to LabVIEW what RPM is to Linux.


Not so fast. It is a developer tool mainly. Such as GIT.

But without the external-tool stigma crappyness attached to it.

 

The "RPM" for LabVIEW is a MSI/Setup.exe. Smiley LOL

 

Br,

 

/Roger

 

0 Kudos
Message 21 of 36
(710 Views)

You should check out this webcast on code reuse http://zone.ni.com/wv/app/doc/p/id/wv-2085. There are problems that cannot be solved with source control although I give you five stars for using it and five more for your enthusiasm!! You are a mile ahead of many people who think that source control is an added layer of complexity when, as you already know, it is to simplify problems.

 

[Edit: And even though there might be some bugs in VIPM, it is the only tool that I know of that solves the problem that it is intended to solve]

=====================
LabVIEW 2012


0 Kudos
Message 22 of 36
(708 Views)

@User002 wrote:
Yes, it is called a branch.

No, a branch means you are dealing with a different set of code.  This is exactly what you do NOT want with a reuse library.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 23 of 36
(698 Views)

@SteveChandler wrote:

You should check out this webcast on code reuse http://zone.ni.com/wv/app/doc/p/id/wv-2085. There are problems that cannot be solved with source control although I give you five stars for using it and five more for your enthusiasm!! You are a mile ahead of many people who think that source control is an added layer of complexity when, as you already know, it is to simplify problems.


Thanks! I appreciate it.

 

Yes, GIT works great for me for both LV and text based languages. I'm using tortoisegit as a windows shell extention.

A good VCS simplifies a lot in my daily developer life, specially with good commit-comments to the changes, etc, branching, merges (text based), tags, releases, etc.

 

I think the LV world is very much immature compared to world-class text based software houses in terms of SW dev techniques.

 

Br,

 

/Roger

 

0 Kudos
Message 24 of 36
(696 Views)

@crossrulz wrote:

@User002 wrote:
Yes, it is called a branch.

No, a branch means you are dealing with a different set of code.  This is exactly what you do NOT want with a reuse library.


A branch usually shares the common ancestor, at least in decent VCS's(in GIT creating a new branch adds about 20kb). It is not a complete different code. A fork would be more or like a complete disconnect.

 

Br,

 

/Roger

 

0 Kudos
Message 25 of 36
(693 Views)

@User002 wrote:


I think the LV world is very much immature compared to world-class text based software houses in terms of SW dev techniques.


Depends what you consider "world-class".  At my previous company, we (the LabVIEW developers) used a lot more SW dev techniques than the actual software and VHDL people.  And this is for code going into space (rockets, satellites, Mars rovers, etc).


I would say most of the LabVIEW developers are using the same or equivalent techniques as the majority of normal software developers.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 26 of 36
(686 Views)

@crossrulz wrote:

Depends what you consider "world-class".  At my previous company, we (the LabVIEW developers) used a lot more SW dev techniques than the actual software and VHDL people.  And this is for code going into space (rockets, satellites, Mars rovers, etc).

 

I would say most of the LabVIEW developers are using the same or equivalent techniques as the majority of normal software developers.


Since you have been working with rocket science you are hereby disqualified from speaking about the common LV coding practises. Smiley LOL

 

The classic WTF when opening up LV code "someone else" have written: http://thedailywtf.com/Articles/Labview-Spaghetti.aspx

 

If you'd think such coders know anything about SW dev practises and teqniques. You'd be wrong!

 

Br,

 

/Roger

 

Message 27 of 36
(683 Views)

That is NOT the normal.  That was written a long time ago.  LabVIEW and its ecosystem has evolved A LOT since then.  Also, what you linked to is a typical beginner code.  But you know what, I've seen even worse in C++.  I will concede that it is easier to get bad code to work in LabVIEW.  But as a whole, the LabVIEW ecosystem is just as evolved as any other language's ecosystem.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 28 of 36
(667 Views)

RogerIsaksson wrote:

A branch usually shares the common ancestor, at least in decent VCS's(in GIT creating a new branch adds about 20kb). It is not a complete different code. A fork would be more or like a complete disconnect.

 

Br,

 

/Roger

 


While it is not completely different, it is different enough to not be the same. You have project A and project B using some subVI. You fix a bug in the subVI that affects project A but project B saw the bug as a feature. You can solve this by including a copy of the subVI in both projects. VIPM helps with this kind of situation.

 

I just realized that we are completely hijacking some poor guys thread. I just wanted to reemphasize that VIPM has nothing whatsoever to do with source control and JKI has never claimed it to be any kind of replacement. Arguing that GIT is better than VIPM is like arguing that phones are better than cars. You can call someone or drive over and talk to them. Which is better really depends. But phones and cars have very different purposes.

=====================
LabVIEW 2012


0 Kudos
Message 29 of 36
(664 Views)

Kudos for the rocket scientist comment Smiley Very Happy

 

But if you want to see real spaghetti code take a look over here.

 

=====================
LabVIEW 2012


0 Kudos
Message 30 of 36
(663 Views)