Jump to content

Francois Normandin

Members
  • Posts

    1,206
  • Joined

  • Last visited

  • Days Won

    46

Posts posted by Francois Normandin

  1. 0-BSD is the only OSI-certified license that gives the same level of restrictions as Public Domain, while still, as you well know from those other presentations you referred to, being recognized in (almost) all countries. Public domain and The Unlicense are not recognized universally.

    Like Shaun points out, the biggest worry is that someone can claim my work as theirs because the license is open enough that you can copy any part, or the whole, without attribution. 

    Honestly, I don't think the prospect of someone claiming I cheated would meet any level of credibility, since all the development is done in a 3rd-party public repository and I never squash my commits. Easy to prove I went through the development process and I couldn't temper with the commit hashes/timestamps of those commits. You can see all the mistakes, dead-ends, reworks, fixes... Anyway, whether or not you use a more restrictive license would not prevent someone from falsely claiming their work predates yours. If that were to happen, I trust the LabVIEW Community will hold the reputation of the original developer. 

    If the work you want to release is owned by a company, I would recommend to not use 0-BSD. Make sure there is at least an attribution clause.
     

    • Thanks 1
  2. No you cannot. 

    Your simplified example, if the interface is truly abstract, is equivalent to trying to prevent someone from dropping a "empty string constant" on the block diagram. 

    Fundamentally though, it would prevent you from using the direct cast to exercise the override, as shown in the bottom example.


    image.png.da189c191bb874755effadee90e6a047.png

     

    The only restriction is that one cannot create a DVR of the interface from outside the interface itself.
    I have to admit that I have not investigated the consequence of such a pattern in the context of interfaces...

    image.png.cc7330564ffa66d2721ec33873ba8bbe.png
     

    • Like 1
  3. This is not strictly the answer to your question, but if you only use this for elapsed time, I suggest you switch to UTC time instead... There is no daylight savings time in UTC frame of reference, so you are certain it won't hit you.

    Also, here's a library (shameless plug) you might find useful: https://www.vipm.io/package/labview_open_source_lib_epoch_datetime/
    It serves Unix, GPS and ISO time, including support for leap years (and even leap seconds... all 37 of them)

  4. Networks Streams implement (and abstract) the concept of Quality of Service without the developer needing to add code for managing intermittent connections. A handshake ensures that all the data transmitted has reached the other endpoint in the order they were sent. Yes, it is probably just a buffer on the sender's side and some ACK replies from the receiver (and incoming buffer), bundled into a seemingly unidirectional stream. For sure there's an overhead compared to straight TCP, but I'm not sure the overhead is that large if you take into account the handshaking that you would need to reproduce the same QoS feature.

    TCP is more flexible and interoperable.

    If you need to add QoS to your app, and your app is all LabVIEW on both sides, then Network Streams make sense for reliable 1-to-1 high speed data transfers. If you send lots of small messages, an IoT protocol over TCP is probably more suited for the task (MQTT, etc.).

     

  5. Quote

    "Improved Python node now supports 3.6 through 3.9"

    We've been calling 3.9 with LabVIEW 2019 without a glitch. Not exactly sure what "support" means in this context.

    _ _ _

    Different topic... If the statement below were a regular expression, wouldn't a "?" be more appropriate? It would stand a better chance of matching at least one element 😉
    image.png.a0381a215b2a7237fad026f4841671b5.png

     

    • Haha 1
  6. On 3/31/2021 at 2:43 AM, JKSH said:

    What license is the code published under?

    It's not listed on the repo, but it is under the MIT license. (It's now been added to the repo)

    • Like 1
  7. I assumed Messenger did this too, although I don't use it. 🙂

    In SMO, it's a settable parameter by the user based on their needs. The SMO process itself actually should abort in a few milliseconds, so it is heavily dependent on the process overrides.

    image.png.4da4e923e5a397bee23df7436ca494bc.png

     

    (edit for clarity) The STOP call is a last resort in case the "autoshutdown" message does not work. Even if enqueued at the front, when the actor loop is locked because a "do" is performing a blocking action, stop will kill the thread. Also, Stop will effectively handle a parallel loop that is running concurrently to the actor message handling loop and does not implement correctly the shutdown messages. I daresay it should never happen in production code. The onProcessKill override is provided to have a way to log this event when it occurs. If the developer killed the caller in development mode, that's fine and can be ignored. If it happens in production code, it should be a concern.

     

  8. You might want to inspect JKI SMO's way to handle this. The SMO Process has a "passive watchdog" that monitors a single-element queue and gracefully exits if the asynch process completes normally... but it will stop the whole asynch thread if the queue reference goes idle. 

    Note that you should use such a mechanism only if you always want your asynch process to get killed in case of a caller going out of memory. (This should be an ultimate way to exit, not a normal way...)
    SMO process still tries to abort before it ultimately kills the thread.

    (This is a screenshot from SMO:Process.vi)

    image.png.aec7cc968112a0562c151402f4e30c9c.png

  9. 1. Nowadays, Git 100%.

    2. Love it. 

    3. I forced it on my team, but even for my hobby coding, I use SCC. Those closer to retirement are having a hard time. For the younger folks fresh out of school, they'd be surprised if we didn't use Git. I wouldn't bet that all of them know what SVN means.

    4. 

    Pros:

    • Large support community online. When stuck, I just spell it out in the search engine and I find a post on stackoverflow that solves my problem 
    • It allows enforcement of a workflow that achieves modularity by design, through submodules.
    • Easy to deploy a repo through a usb stick for offline instruments, and to merge offline changes back to server
    • No one can reserve a file and accidentally prevent others to work

    Cons: 

    • No LV integration for visualizing changes

    5. SCC never screws up, the developer or the client app does. The app client I use (SourceTree) has a tendency to show "detached heads" that magically disappear when I close the app and open it back again. Detached heads are very confusing and every time I see one, I'm extra careful not to lose any work done. They never occur in a simple repos: only when dealing with submodules. That's a buggy behavior of the app, not a failure of SCC itself.

    • Like 1
×
×
  • Create New...

Important Information

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