ShaunR

Nope. I just said all SCCs are crap for LabVIEW including Git. Rolf was comparing Git and SVN features. That comment was a friendly dig at odoylerules who loves Git and thinks my SCC system is copying zip files This is the same problem that came up with people wanting to know how to attribute the OpenG software for licencing. Various people suggested similar things to you but I'm not sure if an authoritative answer was ever proffered.

The DFIR was introduced in 2009 and LLVM in 2010, I think. Anyway. Enough off topic shenanigans . Back to the discussion "my SCC could take your SCC in a fight".. I think the answer as to whether things should move to Git is probably not down to features, but preferences. If 90% of people prefer Git because all their other projects are there, then why not?. If no-one cares apart from 1 or 2 zealots then there is little point. Maybe a straw poll? There is one input that has not been considered, and it is the amount of effort required by the OpenG team to actually move it and if it would have a negative impact on the existing contributors who may be reluctant to learn a new platform.

I don't see why all VI terminals can't have an option to adapt to type. We have them for CLFN which is very useful. It'd be great if it was just a checkmark on the compane like the "Required" or "Dynamic Dispatch". Then it would be easy to fix the type of controls/inidcators and mix-n-match adaptive and static types and we wouldn't even need a special type of VI/Xnode.

Well. A bit off topic but deserves a response. Two points here. . They have already figured out how to identify and merge differences. In fact they figured it out a long time ago, then stopped. That's 80% of the problem already solved, IMO. I've said before and I'll say it again. I don't care that the features I want are hard. It's closed source, paid-for software so it's up to NI to figure out how to make it happen; not for you or I to be technical apologists for them. Anything is possible with enough resources, time and the will to do it. The only thing lacking is the last one. As far as I can tell,. NI stopped doing hard or interesting stuff in LabVIEW around 2009 (maybe even 8.x) and have been serving us IDE placebos ever since - just look at whats been implemented from the idea exchange!

This is a bit different in that LabVIEW generates an exact representation of the LabVIEW panel by scanning the VI FP and essentially converting controls and indicators to HTML and Javascript - the panel is automagically created for any application. A pure HTML/JS UI to a LabVIEW back end is much easier but you have to create the page for the application.

I suggest you count to 10 then re-read what I wrote.

That's just regurgitating the spiel. The power of Git isn't in forking or cloning - you can do that by copying a zip file. It is in having a local repository that you can make incremental commits and checkouts that can also be synchronised with the main trunk - offline AND online commits or "staging" as it is called. Other SCC all have to be on-line to make commits. The point I (and I think Rolf) are making is that all SCC including Git are not fit for purpose when it comes to LabVIEW so why change from one inadequate source control to another inadequate source control? It's not as if we have never used Git. It's just that is it as crap as all the others for LabVIEW. I, certainly, end up just using them purely for backup and restore due to LabVIEW peculiarities and Git is a very complicated backup and restore. Whats really needed is for NI to get their finger out and give us a proper LabVIEW SCC system instead of faffing around with IDE cosmetics

Yup. Good example of where a VIM wipes the floor with the other solutions in terms of conciseness and ease of implementing..

I think it is a Linux cultural thing compounded by young basement hackers, personally. I saw a discussion somewhere where an application developer likened most programs written by Linux people today to a game called "Mount Your Friends". Seeing the go-to "architecture" (and I use the term loosely) of writing applications is to pipe and string together, program after program and hack upon hack , with the mantra "it works so it must be good" - I'm inclined to agree with them The Linux world has the cleverest, most intelligent and awe inspiring coders and programmers that there is. I'm humbled by some of their abilities' to put advanced mathematics and theories into code........ but they couldn't write a decent or user friendly application if their life depended on it .

Glad I'm not the only one. Even if you account for not being able to diff LabVIEW code - which is a huge benefit of SCC - the creation of hundreds of clones of the source code trunk as a normalised workflow is an abomination. I think the idea was originally to be able to pick and choose code created by the herd of cats to improve the trunk but what actually happens is you end up with 1,000 slightly different variation of the same thing none of which are exactly what you want. So.....you create another clone .

Good god no That's a sure fire way to allow managers to think "1/2 his timescales because he always over estimates" and will get you working weekends as the deadline approaches while they picnic with their families! There is no such thing as "properly" in management - only working or not. It takes this long, costs this amount of money, period! (because you never guess or estimate, you always calculate to ensure the project is on-time and on-budget, right? ) If you are pressured, you supply a list of features and ask them to cross off the ones they don't really need or want and you will recalculate. Alternatively, they can give you a deadline and you will supply them with the features that can be achieved within it. You want the reputation that your first plan is considered, calculated, already optimized and accurate for an on-time and on-budget delivery and there is no point in questioning it if they need everything you have listed.

It usually arises with subcontractors especially on rentacoder type sites where it's a race to the bottom. . Companies like to "own" source code outright. It greatly simplifies licencing issues or risk.. If you work for a company then there is probably something in your contract that says anything you write they own. With this mind-set. When you subcontract out work, you need to know that the code you are getting is original and that the sub contractor is disavowing all rights to it. This puts pressure on the sub contractor to supply working solutions with vanilla code. Sometimes things are just too hard or not enough time for them so they take tried and tested solutions and try to pass it off as their own so that they can get paid. If ripping out OpenG licencing terms for a piece of code that probably will never be looked at means make or break for a milestone payment then it's a very attractive solution especially if your contract includes a "No open source or third party code" requirement.

Cockroach #1,545,432,323 reporting in! Your VI is not shared re-entrant so you are not suffering from the problem I was outlining. It's an application issue rather than a sneaky LabVIEW issue.

Yeah. That's not what I'm after, though. I just want to open an appliance that someone else has gone through the excruciating pain of creating. Call me lazy but I've been mauled by Linux distros and the RIO evaluation board usb image so someone else can go through that for these platforms, thank you very much

When they say "RT" they really mean the Pharlap RT OS which is now called the NI Hypervisor, I think. (Windows PXI racks). That is Windows with an RT kernel. Interesting that new embedded platforms are coming with GUIs. Should be able to get VNC working on them too. Does anyone have a VMware or Virtualbox image of one of these GUI enabled systems?

Change the VIs reentrancy to be "Pre-allocated", rather than "shared", and see if it resolves your issue. The elapsed timer VI is one of those that relies on an uninitialised shift register and is set to pre-allocated so it must be called from either another pre-allocated clone or from a normal VI.

I usually gently point out these "discrepancies" if I have firm suspicions and give them the opportunity to rectify it and/or respond. They may have an agreement in place or they might have received the code in good faith but were not as diligent as you were and have been caught holding the ball. I'm fairly lenient with individuals and ignorance but can't abide business decisions that produce this situation. After that, it depends. I might ask the supplier if I can check with the original authors to see what their reaction is or I might tell the authors straight away-it really depends on their reaction and who they are. An expletive ridden email response telling me to insert parts of my anatomy in various orifices will definitely result in the latter with supporting evidence after several hours of investigation of all the software they have ever written, to boot. Does it happen alot? Not really in the LabVIEW world-much more in other domains. Most of the time it is an oversight or some engineer somewhere hiding a lack of ability from a boss. Corporate misappropriation does happen but it is an exception rather than the rule. It's happened twice to me with my software and both times a gentle nudge resolved it with no drama. Generally these things are a bit like witnesses at road accidents-noone wants to get involved even though they should.

Is your VI shared, re-entrant?

Yup. I can see this too with your example (@200ms). Tried it in LV2009, 2014 & 2015 and they all exhibit the behaviour. Looks like a Graph Indicator bug since the using a "Convert From Dynamic Data" set to "scaler" and placing an indicator doesn't do it.

Has no-one created a vmware image yet? Building Linux distros is like unraveling a jumper with chopsticks to make a tank-top.

This was a problem for me too.cThere is no elegant solution that I know of. You either architect your software to call dynamically the functions you need (plugin architecture) which works great in classic Labview where nothing is broken but you are stuffed if you use classes. Then, as you describe, the conditional disable. This is the only alternative I have found so far (open to more ideas) that works for everything but has some caveats (like the dependency has to be installed first so upgrades are difficult). I just put the onus on the developer/user to add a conditional disable tag into their project which also has the side effect of allowing them to choose whether to ship with that feature or not if they do have it (toolkits, obviously). The default shipped state is the plugin is disabled and they add the tag when they enable it which will either activate the feature if it is installed or break their VIs.

Nice. We didn't need a spec, but since you've given us one - polymorphic VIs are great. They never encapsulated Moveblock. I don't know why - it's the single most useful function for CLFNs. Tempting to wish for callback features but I'm ambivalent. If there is one good way to crash a LabVIEW program, it is to write some of it in another language. CLFNs are a last resort when no other options exists rather than standard coding practice. After all. If you want to write GPF ridden software, there are better languages like C and C++

OK. So it is a thin wrapper around the Tiny C Compiler.(Note that TCC is LGPL licenced ) It looks like the "State" is an opaque pointer to a structure so you might want to choose "Unsigned Pointer-Sized Integer" so that it is 32 and 64 bit ready. I would also suggest putting each function in a case structure and checking for 0. You can't test a pointer in C to see if it exists so the best you can do is hope that the library returns null pointers when memory is released or memory can't be allocated. For your DSNewPtr, which is a LabVIEW function; there are already VIs for that and others. I forget whether they are under resources or in vi.lib but I think you should separate out LabVIEW functions and application specific functions. LabVIEW functions are reuseable and usually cross platform , whereas application specific ones are or may not be. Looking forward to being able to auto-compile libbitcoin from LabVIEW

Amen! Although I don't think I've seen it. It was more to poke fun at eulogising ones own software.

Software is like a fart. Yours is OK but everyone elses stinks.