Jump to content

LogMAN

Members
  • Content Count

    541
  • Joined

  • Last visited

  • Days Won

    51

Everything posted by LogMAN

  1. What you describe is called a fork Forks are created by copying the main branch of development ("trunk") and all its history to a new repository. That way forks don't interfere with each other and your repositories don't get messy.
  2. If you are leaning towards Mercurial you should visit the Mercurial User Group: https://forums.ni.com/t5/Mercurial-User-Group/gh-p/5107
  3. Git I don't hate it - the centralized nature of SVN simply didn't cut it for us. No. It was my decision. Pro - everything is available at all times, even without access to a central server. Con - It has too many features, which makes it hard to learn for novice users. Only when I merge the unmergeable, so anything related to LabVIEW 😞
  4. Please keep in mind that it is only my mental image and not based on any facts from NI. Perhaps both. If we can understand the current behavior it is easier to explain to NI how to change it in a way that works better for us. Here is an example that illustrates the different behavior when using indicators vs. property nodes. The lower breakpoint gets triggered as soon as the loop exits, as one would expect. I have tried synchronous display for the indicator and it doesn't affect the outcome. Not sure what to make of it, other than what I have explained above 🤷‍♂️
  5. Disclaimer: The following is based on my own observations and experience, so take it with a grain of salt! The user interface does not follow the dataflow model. It runs in its own thread and grabs new data as it becomes available. In fact, the UI update rate is much slower than the actual execution speed of the VI -->VI Execution Speed - LabVIEW 2018 Help - National Instruments (ni.com). The location of the indicator on the block diagram simply defines which data is used, not necessarily when the data is being displayed. In your example, the numeric indicator uses the data from the
  6. A Static VI Reference is simply a constant Generic VI Reference. There is no way to distinguish one from another. It's like asking for the difference between a string constant and a string returned by a function. The Strictly Typed VI Reference @Darren mentioned is easily distinguishable from a Generic VI Reference (notice the orange ⭐ on the Static VI Reference). However, if you wire the type specifier to the Open VI Refnum function, the types are - again - indistinguishable. Perhaps you can use VI Scripting to locate Static VI Reference
  7. Sure thing, it's also good to know there is a thread like that - first time I've head of it 😮
  8. The number to string functions all have a width parameter: Number To Decimal String Function - LabVIEW 2018 Help - National Instruments (ni.com) As long as you can guarantee that the number of digits does not exceed the specified width, it will always produce a string with fixed length (padded with spaces).
  9. I discovered a potential memory corruption when using Variant To Flattened String and Flattened String To Variant functions on Sets. Here is the test code: In this example, the set is serialized and de-serialized without changing any data. The code runs in a loop to increase the chance of crashing LabVIEW. Here is the type descriptor. If you are familiar with type descriptors, you'll notice that something is off: Here is the translation: 0x0008 - Length of the type descriptor in bytes, including the length word (8 bytes) => OK 0x0073 - Data type (Set
  10. There is a VI in OpenG LabVIEW Data Library that does this for you. I took this as a challenge and added two VIs to my library on GitHub - https://github.com/LogMANOriginal/LabVIEW-Composition Decompose Map extracts variant keys and values of variant maps Decompose Set extracts variant elements of variant sets I have successfully tested these VIs with various different types, but there could still be bugs. Let me know if you find anything. I strongly discourage using these in production!
  11. Only the name is deleted, commits are left untouched. It is actually possible to restore the branch name if you know the commit hash - https://stackoverflow.com/a/2816728 This can be useful if you deleted a branch before it was merged into master, or if you want to branch off a specific commit in the history that is currently unlabeled. Here is some documentation from Atlassian, generally applicable to GitHub as well: Git Branch | Atlassian Git Tutorial Pull Requests | Atlassian Git Tutorial
  12. The Network Graph mentioned by @JKSH does give you some visualization on GitHub. I personally prefer the visualization in Sourcetree and bash. Here is an example for GitHub - microsoft/vscode: Visual Studio Code The command I use is git log --oneline --graph You can see that branches still exist even after merging. Only the name of the branch, which is just a fast way to address a specific commit hash, is lost (although it is typically mentioned in the commit message). That said, some branches can be merged without an explicit merge commit. This is called "fast-forw
  13. Here is some information about this error: VISA Error -1073807339 (0xbfff0015) Timeout Expired Before Operation Completed - National Instruments (ni.com) There could be many reasons for a timeout error. The error message only indicates that a timeout occurred before a reply was received, which is not very useful. NI IO Trace might give you some additional clues. Maybe put the master in a shift-register on your while loop. Not sure if that makes a difference. This is specified in the Modbus Application Protocol, although implementations vary between 1-based and 0-based. The
  14. You got it right. "Delete branch" will delete the branch on your fork. It does not affect the clone on your computer. The idea is that every pull request has its own branch, which, once merged into master, can safely be deleted. This can indeed be confusing if you are used to centralized VCSs. In Git, any repository can be remote. When you clone a Git repository, the source becomes remote to the clone. It doesn't matter if the remote is on your computer or on another server. You can even have multiple remote repositories if you wanted to. You'll notice that the clone - by def
  15. For starters, there are a few DWarns: c:\nimble\penguin\labview\components\mgcore\trunk\18.0\source\ThEvent.cpp(216) : DWarn 0xECE53844: DestroyPlatformEvent failed with MgErr 42. e:\builds\penguin\labview\branches\2018\dev\source\typedesc\TDTableCompatibilityHack.cpp(829) : DWarn 0xA0314B81: Accessing invalid index: 700 e:\builds\penguin\labview\branches\2018\dev\source\objmgr\OMLVClasses.cpp(2254) : DWarn 0x7E77990E: OMLVParam::OMLVParam: invalid datatype for "Build IGL" e:\builds\penguin\labview\branches\2018\dev\source\typedesc\TypeManagerObjects.cpp(818) : DWarn 0x43305D39: chgtosrc o
  16. LogMAN

    Dear NI

    It could be open source and still be maintained by NI, as long as they have a way to generate revenue. There is also great potential in the NXG platform, which - as far as I know - is written in C#. Even if LabVIEW is not of interest to millions of people, keep in mind that most open source projects only receive contributions from a small portion of their users. The Linux kernel is probably not a good comparison, because it is orders of magnitudes more complex than LabVIEW. Nevertheless, Linux "only" received contributions from approx. 16k developers between 2005 and 2017 - 2017 Linux Ker
  17. Good selection by @Mefistotelis Try to figure out what motivates them (games, machines, information, ...) and help them find the right resources. Try different things, perhaps something sticks. If not, move on to the next. Here are two links that can get you started with python in a few minutes. Take your first steps with Python - Learn | Microsoft Docs Python Getting Started (w3schools.com)
  18. Not sure where you got that. It's a valid approach: Command pattern - LabVIEW Wiki The Actor Framework, for example, takes this idea to the extreme. I'm not a fan of the 0ms timeout case because it adds unnecessary polling. The rest sounds good to me. It is probably best if you build a prototype to see what works best for you.
  19. You use some patterns in the wrong context. The Factory pattern is only a means to create new objects without explicitly referencing them. Here is a very simple example using a Boolean to select from two classes. In this example, Class 1 and Class 2 both are children of Superclass. Depending on the input value, one of them will be returned. The caller doesn't need to know how to create those objects and only sets the input value to True or False. A typical implementation uses a String instead of a Boolean, which allows for many more options and adding more classes later.
  20. Glad to hear it worked out well for you. I wish I had this confidence 10 years ago... I agree. Unfortunately the decision is not always up to us, especially for young teams without expert recognized by higher-ups. In our case it went something like this: NI is also not very helpful in dampening expectations: The rest is history. To be fair, our case was a single incident. The general experience with contractors has been very positive and insightful. Still, I would probably raise an eyebrow if a CLA told me that they don't know how to work with classes. Just see
  21. Actually had to google that. If I understand it correctly, you are saying that my sentence is phrased in a way that is offensive to you (and others perhaps). That was not my intention. Let me try to explain myself and hopefully clear up what I presume is a misunderstanding. By "A CLA who isn't familiar with fundamental OOP concepts..." I mean somebody who has no prior knowledge about OOP whatsoever. They don't know what a class is and how inheritance or encapsulation works. It is my opinion that this makes them incapable of choosing between different OOP frameworks and libraries themse
  22. Did you only come here to mock me? If you disagree with something I said, please feel free to express your point of view and perhaps we can find common ground.
  23. I believe it should. OOP (and interfaces in the near future) are architecturally relevant and at the core of frameworks and libraries that drive so many applications. A CLA should be able to assess if a particular framework is a good choice architecturally, or not. A CLA who isn't familiar with fundamental OOP concepts is incapable of making such decisions and in worse case puts the entire project at risk by making random decisions or avoiding OOP because they don't see the value in it. It probably makes sense to focus on fundamental concepts in the exam, because frameworks and libra
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.