Jump to content

ShaunR

Members
  • Content Count

    4,128
  • Joined

  • Days Won

    217

Everything posted by ShaunR

  1. I think we've articulated the goal well enough. However, a VIM doesn't necessarily have a reference like Queues et. al. so I'm not sure there would be an "uncomplicated" first order solution for it even though it's a kind of natural progression from singular VIMs to libraries of VIMs. In theory, the second order solution is to use those primitives internally since they have that behaviour which should propegate out but I was unable to see if that worked with DVRs and trying queues didn't illicit the behaviour.
  2. Seems VIMs can no longer be used in polymorphic VIs either. I don't think this is a good idea. The VIMs I've played around with (before the type case structure was introduced) relied on at least one terminal having a type which would dictate the undefined types due to the nature of the internal polymorphic VIs (like a Queue or DVR). This is why I was trying to get a VIM to create a DVR which "should" define the type across all connected VIs which would solve this problem. In a nutshell, I'm expecting this set of VIMs (rightly or wrongly) to behave like the Queue, Notifier et. al. primi
  3. Never mind. It seems that you cannot have DVRs inside VIMs any more.
  4. If you were to use a DVR (or the user supplied DVR) and put the reference onto a single element queue inside the ViM. Wouldn't you get all the type checking and polymorphism for free across all the VIs without all the type cases?
  5. I can't find them in the examples finder (tried a few different words). The button on VIPM shows the directory with them, though. FWIW. I hate the example finder. You neeed to know the right words for what you're searching for and it's a lot of clicks and typing to get there (ignoring the excrutiating pain of actually creating the Example Finder special files). It's much preferable to have them in the same pallet as the VIs; as you had originally. They need to take that requirement off of the tools network checklist.
  6. The examples were missing when I installed the VIP package so it took me a bit of time to figure out why wires were broken (see bottom row of VIs). The rows above are what happens when the correct data type is applied to the "Add To Buffer" Is it possiblee to to make the "Add To Buffer" select the correct instance depending on the "Create Buffer" data type?
  7. It's the other way round. You include the files contained in an LLB in a lvlib. You end up with two files, the lvlib (XML description) and the LLB (the Vis).
  8. They will be vetted and approved by their respective governments. The problem as I see it isn't limiting execution to signed code, it is who has capability to create and control the keys. "Derived keys" are weasel words for backdoors. But I see it as worse than that. These proposed hardware keys only limit what you can run, not what they (M$ et.al.) can run and they are major players in my threat model. Remember the the Clipper Chip? Or the Apple "Kill Switch"?. These kinds of technologies are packaged as "security" but give the corporate behemoths an inordinate amount of control over you
  9. Signing is great but just be aware the weakness is key distribution. Not so much a problem with physical distributions but a concern over the internet depending on your threat model.
  10. Chinese, Russian and North Korean companies too? Excuse me if I'm not entralled by allowing M$/Intel/Apple/etc backdoors or control of what I can and can't run in an age where computers are always connected and OS telemetry is rife. I reject this dystopian sales pitch for "security" which is nothing more than a hardware version of Certificate Authorities aimed squarely at market control.
  11. Hmm. Just looked at my creatfile in the Zip Library. Seems I used "FNewRefNum" rather than a cast so I was obviously talking out of my backside. I guess I remembered all the stuff that didn't work rather than what did.
  12. Is that a consequence of using an intermediary DLL and "adapt to type" on the CLFN? Using the type cast at the LabVIEW level should mitigate this for TCP and file refs. Depends on what you want to do with them. Deleting the target? If the LabVIEW delete function is based on deletefile (and I can't remember off hand if it is because it doesn't take a filename), then deleting the target depends on the FILE_FLAG_DELETE_ON_CLOSE when calling createfile. I'll have to go back over this because I figured it out last time with the Zip library but for release, only needed long filename support
  13. This is what I deduced for Windows. (It was a while ago, but this is what I recall) Casting the refnum to an integer reveals the same value as the windows file handle (from Process Hacker). Casting it back enables using the native LabVIEW functions. Casting the handle from CreateFileW to a LabVIEW file refnum also allows usage of all the native file functions(including delete) but the LabVIEW delete function isn't symlink aware (treats it as a normal file). The LabVIEW file functions just seem to be primitives of the windows functions *A (which is what can be seen in the imports table).
  14. Nothing what. It's just an interesting data presentation showing the rise and fall of languages over time. It's just a shame LabVIEW isn't on there.
  15. Neither is SQLite. My (brief) foray into this area was before those solutions were available.
  16. Well. SQLite doesn't let you use point cloud queries directly like LASTools or PGPointCloud. drjdpowell would be better to answer that question on how he did it.
  17. If you grew up on Fortran I would have hoped they had let you retire by now. No rest for the wicked?
  18. RTree just gives you a bounded nearest neighbour search. How you come up with those bounds is not within that scope.
  19. "Just". Without it, it would be a debugging nightmare and if I was coming up with that method, I would "just" think it wasn't working.
  20. Yup. On first glance I thought something could have been done with bytearraytostring etc. But the handle created isn't an array (in the LabVIEW sense) so a Moveblock would be needed to copy into another array to dereference it (double the memory required-not what we want). The really devious bit of your code is the sequence structure. That's some voodoo I probably would never have thought of.
×
×
  • Create New...

Important Information

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