Jump to content

ShaunR

Members
 View Profile  See their activity

  • Posts

    4,940

  • Joined

  • Days Won

    306

 Content Type 

Everything posted by ShaunR

  1. ShaunR
    It's the nature of the beast. I had something similar today but not quite on the same scale. Every time I tried to build a zip archive with the option "Recurse Directories" .. it didn't. So I went through the code checking paths and and found it was because the boolean wasn't being set for some reason. So having gone down the hierarchy checking hte file paths I then went back up checking the boolean only to find that the control on the front panel wasn't wired to the unzip sub vi for that option. Now you might say DUH! But in my defence, it wasn't obvious because two boolean controls where vertically compressed and the wire of boolean control above (which was a function to be worked on next and therefore expected to be unwired) went underneath the "Recurse Directories" and came out looking like it's wire.. So if I had tried the other option (Include Empty Dirs) it would have recursed and I would have known immediately rather than 20 minutes later .
  2. ShaunR
    Thanks Michael. Things seem to be much improved.
  3. ShaunR
    I often wondered about the legality of that. Technically, you need never buy a copy of LabVIEW if you just use a VM and are happy with the trial logo permeating the front panel. M$ have particular rules about VMs (and Apple actively prohibit their OS on them) but NI have never (to my knowledge) explained their stance on them.
  4. ShaunR
    As per usual, I'm n outlier here. I hardly ever disable Automatic Error Handling and prefer to use Clear Error.vi where necessary (although I have my own Clear Error.vi which is re-entrant rather than the native on which is not). My reasoning is thus. It demonstrates that the error condition has been considered and a specific decision has been made to ignore it. Automated test harnesses reveal uncaught errors (by never completeing) wheras they may pass if AEH is turned off. I'd rather an error dialogue pop up on a customer machine which at least gives me some iinformation of where to look if an unconsidered error occured rather than them saying "I press this button and it doesn't work". Turning it off is is a code-smell for "cowboy coder"
  5. ShaunR
    In a pinch, you can download the trial of the latest version and use that to back-save. It's not a permanent solution as the trial period is something like 7 days. Most developers subscribe to the NI SSP (Service and support package) and get yearly updates of the latest version but that doesn't mean there are no "issues" and the only workable solution is if everyone, in the entire company, is on the same version and upgrade at the same time.
  6. ShaunR
    This is one of the reasons I still use 2009 (apart from performance and robustness ). The only viable option is to program in the minimum LabVIEW version you intend to support. It's one of the main issues with cooperative, group development and requires a strict regime of everyone sunchronizing versions in repositories. It can be done with different versions by back saving, but it usually ends in tears. Backward compatibilty in LabVIEW is exceptional. Forward compatibility requires a crystal ball and unicorn droppings.
  7. ShaunR
    You're not liable, though. JKI is. That is my point. You gonna sue?
  8. ShaunR
    Have they? The zlib library isn't GPL or LGPL and the Vis are BSD. I assume that Rolf is intending to make an intermediary library to be LGPL and that means compliance with, now, 3 licences - the most onorus being LGPL. That's not my vision and would argue that it would be no better than under vi.lib. I think we both see the value of install but for uninstall you don't want to touch the target packages - just delete or recreate the links.
  9. ShaunR
    Practically speaking. If you delete a hard-link, you delete the target. If you delete a soft-link, you only delete the link. There's a little more to it than that, but not much. Windows file APIs are link-aware. The in-built LabVIEW ones are not.
  10. ShaunR
    I was specifically talking about GPL but some of it probably applies to LGPL as some people (like Centos) have re-licenced to older versions due to "Licence compatibility issues".....so here we go Noone can decide if dynamic linking is a derivitive work or not. The burden of making available source code for a few years. Noone can decide what derivative licences are compatible, not comptible or if any code monkey, like me, is in violation. It's unclear, to me, what happens when a customer makes their application; what burdens are imposed on them. As I undertand it, they have the same distribution burdens that I would have (which they might not be aware of) and that could open them up to a legal threat. The problem with GPL is that everyone (including lawyers) argue about what does and doesn't constitute a violation. It is the uncertainty that means it is unusable, especially in cases where the original licences (like ZLib) are so permissive and are not surrounded by these complications.
  11. ShaunR
    You forgot the /rant tag
  12. ShaunR
    An indicator has two "labels". The label and caption. Show the caption (should be defaulted to the same as the labe and hide the label). Then rename the controls to 1_Home, 2_Ensaio etc (The caption will be what the user actually sees without the numbers). Now you can get the label name, split off the number and put it into a cluster with the value (if you have less than 10 controls, you don't need to convert to a numeric). Make sure the number is the first item in the cluster because LabVIEW will automatically sort on the first element so you can use the sort array directly. From there you can sort the cluster and now you know your clustered booleans are in numerical order.
  13. ShaunR
    Well. Having to use TPLAT I have various tools for, how should I say, un-cocking its cock-ups No compromises. Either it installs stuff properly with a click or two or it will be relegated to "just another installer that doesn't really do what I need" Sweet. What licence is it? (Please don't say, GPL, please don't say GPL, please don't say GPL)
  14. ShaunR
    OK. So what sort of features would we want in a new package manager? Here are a coulple that I've long hoped for: The ability to export a package dependancy list (Just the names and versions? Or more than that?). The ability to export licences of a package and all its dependancies. Automatic detection of 32 and 64 bit binaries. Support installation of VIPM, OGPM, LVPM, executables (like setup.exe) and zipped packages. Import from public online repositories (like Github, Bitbucket etc). What else?
  15. ShaunR
    main.vi I've back-saved to LV 2012 but I don't have 2012 available ATM to check (and can't remember when the "Inserted VI" property was introduced.)
  16. ShaunR
    Something like this? ab.vi
  17. ShaunR
    I think this would cause issues. The packages would already be stored "globally" with links in the vi.lib. Two reasons why the vi.lib. It's on the Labview search path. Menus are auto-populated in addons. Putting the library in a project directory effectively puts the library "out of view" for LabVIEW and you could potentially have different version in the vi.lib and in various projects. The result of the latter would mean linking would boil down to whatever was opened first - from the palettes or from any one of the projects. I think we'd be back to square one. There would be nothing to stop people from adding a symlink in the project directory pointing to the symlink in vi.lib which, I think, would achieve the same goal, but with only one, static, repository. Is that what you are suggesting?
  18. ShaunR
    That's some LabVIEW voodoo I have intentionally steered well clear of I would actually prefer a completely automated (no click) solution for users but with the ability to modify the project links for maintainers.
  19. ShaunR
    This is why I suggested Each LabVIEW version has its own installed toolkits and links to the repo are pre-pended with the LabVIEW version e.g. C:\ProgramData\_LV_Repo\9.0.1\Encryption Compendium for LabVIEW\1.0.0
  20. ShaunR
    You want the symlink to be in the LabVIEW search path (vi.lib, User.lib etc) to force LabVIEW to also search the other locations transparently, if required. This is another reason why it is usually a good idea to have sandboxed projects to ensure LabVIEW uses relative paths instead of absolute paths when linking (projects and lvlibs). By the way. You can do all this manually now, just by moving the toolkits and creating the links. Although I'm not sure, off-hand, what the different flavours of SCC do with symlinks. Then all you'd need is a simple IDE helper to make it trivial choose which versions you wanted.....It only takes ms to delete and create a symlink.
  21. ShaunR
  22. ShaunR
    Possibly. This is why "Real men run as root" Anyhoo. I think any attempt to create a [universal] builder/installer would be best envisaged on Windows first to prove the concept, so these kinds of quirks could be ironed out later. The success of such an endeavour would (I think) be very dependant on symlinks as they are kind of like a silver bullet to allowing different library versions and LabVIEW versions of the libraries to exist side-by-side and swap between. The conclusion I came to with my investigation was that a separate repository (in "Program Data") of installed toolkits, under each LabVIEW and toolkit version, enabled very quick and easy uninstall and version change by simply creating and deleting symlinks in the vi.lib directory pointing to them. Once that is achieved, then project based installs become a simple matter of choosing which links are present for each project whilst still maintaining menus in the palettes.
  23. ShaunR
    If you are seeing the CR char, it is likely that the termination is CRLF. Try setting you termination char to 0A (decimal 10)
  24. ShaunR
    For the use case I outlined earlier (OpenSSL) the ideal behaviour would be to include the symlink and the file. Reasoning: When I distribute the library, the symlinks generally link to existing OpenSSL binaries in the 'shared' folder. These pretty much always exist and just a symlink would suffice. However. For the general case, a binary may not already exist or, if it does, if may be an older version; the latter of which also applies to my use case. By including both the symkink and the file itself, the application has the option to write out the file if it does not exist or update the file to the newer version (after backing up the original file of course). Caveat: This use case is fairly straight forward on Windows. However. If the external binary is, say, a Linux binary such as libstd.so.6 then we are in trouble with this naive process. Anecdotally. LabVIEW doesn't seem to 'see through' symlink chains consistently on Linux. For example. I found It is not enough to link to libstd.so. Instead one must link to the binary libstd.so.6 the suffix of which which can be distro dependant. Maybe I'm just not understanding a fundamental characteristic of Linux symlinks, and it has been a while since I had to confront these quirks after dropping its support. But could you to expand on your thoughts of how to handle symlinks to external binaries in a platform agnostic way?.
  25. ShaunR
    That sounds extremely useful. When building the encryption Compendium, I have to create dummy dll files for the OpenSSL binaries then delete them and create symlinks in the Post Install VI (NI refused to put them in the LabVIEW search path). I have a VI for creating symlinks which would suffice for an IDE helper but build support would be great. As regards the shortcuts. While nice to have for completeness, I don't think it should hold up a release. I would be tempted to leave it out entirely and see who complains and what they expect to happen. Then make a judgement call for the behaviour a in later release, if at all.
×
×
  • Create New...

Important Information

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

  I accept