LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Roadmap (2022)


@billko wrote:

wiebe@CARYA wrote:

@billko wrote:


I do commit often.  Sometimes the commits are minutes apart.  And the notes from the revision text goes into the commit message.  And what's "debatable"?  


It's debatable that a VI's history belongs in the revision history.

 

In fact, I am debating it.


I guess probably soon now this should be taken offline, but I'm curious what you think should belong there?  If not a VI's history, what history?


None? I think the argument is that the revision history should not be inside the VI at all. If you want to see the file's history, you look in SCC.

 

I can see the point, but I'm not sure what is really gained by removing it. 🤷‍

 

 


wiebe@CARYA wrote:

For instance, if we wanted an XML based file it would be a lot easier if the binary file didn't need to coexist. Supporting n methods is typically not n times as hard, but more like x^n as hard (x will be >2 😊).

 

A new GUI system based on HTML5 or WPF (sigh) or whatever would be much harder to make if the old GUI system needs to coexist.

 

You could argue that a converter has to be made anyway. But keeping this separate will keep the both code bases smaller. Testing this functionality separate will also be easier.


Perhaps it could be executed better and/or done without breaking lots of other capabilities like it did, but that almost sounds like a pitch for NXG. 😜

Message 71 of 100
(1,091 Views)

@JimB. wrote:

@billko wrote:

wiebe@CARYA wrote:

@billko wrote:


I do commit often.  Sometimes the commits are minutes apart.  And the notes from the revision text goes into the commit message.  And what's "debatable"?  


It's debatable that a VI's history belongs in the revision history.

In fact, I am debating it.


I guess probably soon now this should be taken offline, but I'm curious what you think should belong there?  If not a VI's history, what history?


None? I think the argument is that the revision history should not be inside the VI at all. If you want to see the file's history, you look in SCC.

 

I can see the point, but I'm not sure what is really gained by removing it.


Well this debate should be another thread, but I version a lot of source code, shell scripts, launchdaemon plist files, etc.  Including contract negotiations and project management documents, I want that version with the document and not have to go back to the metadata in the git repository.  So some folks feel the version information is useful and should be kept. And not send the final recipient of the code, document, diagram to some other possibly private repository.  This is not "debatable" since the personal choice of where one prefers the documentation is not a universal truth any more than it is debatable whether one prefers chocolate or vanilla ice cream.

 

Scott (remember it takes all kinds to fill the freeways)

LabVIEW ChampionLabVIEW Channel Wires

0 Kudos
Message 72 of 100
(1,082 Views)

@billko wrote:

wiebe@CARYA wrote:

@billko wrote:

wiebe@CARYA wrote:

@billko wrote:

@crossrulz wrote:

@billko wrote:

@crossrulz wrote:

@BertMcMahan wrote:

I feel like I've heard that a lot of things are impossible "due to maintaining legacy compatibility". I wonder if they'll wind up biting the bullet and starting to deprecate some of the older stuff and release a non-backward-compatible version. I have no idea what kinds of features might break though... just spitballing.


I have personally been advocating for the removal of "ancient", rarely used features.  First on my list would be "revision history" as that is something that belongs in external tools, ie Source Code Control.

 

I do see a possible benefit in removing "old" mutation code (pre-2009?  2012?).  That is something that would need some strong consideration though (how many people are still trying to upgrade LabVIEW 8.6 or earlier code?).


That's funny.  I know I'm in the minority, but I put stuff in the revision notes all the time so when it comes to actually committing, I have notes for my commit.


Free Labels would accomplish the same job...


To me, that's unnecessary BD clutter.  Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.


That's debatable. Most will say it belongs in SCC. Commit often.


I do commit often.  Sometimes the commits are minutes apart.  And the notes from the revision text goes into the commit message.  And what's "debatable"?  


It's debatable that a VI's history belongs in the revision history.

 

In fact, I am debating it.


I guess probably soon now this should be taken offline, 


Why? I hope I'm not being offensive, I don't feel offended.

 


@billko wrote:
, but I'm curious what you think should belong there?  If not a VI's history, what history?

Nothing belongs there. It's history 😋! (<< To be sure: that is a joke.)

 

I'm not doubting that the purpose of the revision history is to store a history of revisions.

 

It's just that for me SCC does a far better job, so to me the revision history never had any use. In fact, even before I started using SCC, I didn't use the revision history.

0 Kudos
Message 73 of 100
(1,039 Views)

wiebe@CARYA wrote:

@billko wrote:

wiebe@CARYA wrote:

@billko wrote:

wiebe@CARYA wrote:

@billko wrote:

@crossrulz wrote:

@billko wrote:

@crossrulz wrote:

@BertMcMahan wrote:

I feel like I've heard that a lot of things are impossible "due to maintaining legacy compatibility". I wonder if they'll wind up biting the bullet and starting to deprecate some of the older stuff and release a non-backward-compatible version. I have no idea what kinds of features might break though... just spitballing.


I have personally been advocating for the removal of "ancient", rarely used features.  First on my list would be "revision history" as that is something that belongs in external tools, ie Source Code Control.

 

I do see a possible benefit in removing "old" mutation code (pre-2009?  2012?).  That is something that would need some strong consideration though (how many people are still trying to upgrade LabVIEW 8.6 or earlier code?).


That's funny.  I know I'm in the minority, but I put stuff in the revision notes all the time so when it comes to actually committing, I have notes for my commit.


Free Labels would accomplish the same job...


To me, that's unnecessary BD clutter.  Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.


That's debatable. Most will say it belongs in SCC. Commit often.


I do commit often.  Sometimes the commits are minutes apart.  And the notes from the revision text goes into the commit message.  And what's "debatable"?  


It's debatable that a VI's history belongs in the revision history.

 

In fact, I am debating it.


I guess probably soon now this should be taken offline, 


Why? I hope I'm not being offensive, I don't feel offended.

 


@billko wrote:
, but I'm curious what you think should belong there?  If not a VI's history, what history?

Nothing belongs there. It's history 😋! (<< To be sure: that is a joke.)

 

I'm not doubting that the purpose of the revision history is to store a history of revisions.

 

It's just that for me SCC does a far better job, so to me the revision history never had any use. In fact, even before I started using SCC, I didn't use the revision history.


Oh, I simply meant we were veering off course from the original topic and thought we might want to just summarize our viewpoints so we don't take up too much space.  I wasn't at all offended or anything.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 74 of 100
(1,033 Views)

@billko wrote:
Oh, I simply meant we were veering off course from the original topic and thought we might want to just summarize our viewpoints so we don't take up too much space.  I wasn't at all offended or anything.  

We are off topic indeed... But I think I'm all done. 

0 Kudos
Message 75 of 100
(1,028 Views)

wiebe@CARYA wrote:

@billko wrote:
Oh, I simply meant we were veering off course from the original topic and thought we might want to just summarize our viewpoints so we don't take up too much space.  I wasn't at all offended or anything.  

We are off topic indeed... But I think I'm all done. 


Me, too.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 76 of 100
(1,033 Views)

Anybody ever still using Database Access? 🤣

 

NeilPate_0-1658147222698.png

 

0 Kudos
Message 77 of 100
(657 Views)

@Neil.Pate wrote:

Anybody ever still using Database Access? 🤣

 

NeilPate_0-1658147222698.png

 


The only person I ever heard of using that feature (Ben) has now been retired for a few years.  So that is another one of those features I would not mind being stripped out of LabVIEW.


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 78 of 100
(653 Views)

@crossrulz wrote:

@Neil.Pate wrote:

Anybody ever still using Database Access? 🤣

 

NeilPate_0-1658147222698.png

 


The only person I ever heard of using that feature (Ben) has now been retired for a few years.  So that is another one of those features I would not mind being stripped out of LabVIEW.


Didn't someone complain recently (a week or two ago) that the database access had problems with binary data, or was that something else?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 79 of 100
(641 Views)

@Neil.Pate wrote:

Anybody ever still using Database Access? 🤣

 

NeilPate_0-1658147222698.png


I use it to freak out the newbies 😂.

 

The SubVI Node Setup (right above the Enable Database Access menu) does a great job at that too.

0 Kudos
Message 80 of 100
(608 Views)