Jump to content

ShaunR

Members
 View Profile  See their activity

  • Posts

    4,856

  • Joined

  • Days Won

    293

 Content Type 

Everything posted by ShaunR

  1. 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.
  2. ShaunR
    You forgot the /rant tag
  3. 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.
  4. 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)
  5. 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?
  6. 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.)
  7. ShaunR
    Something like this? ab.vi
  8. 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?
  9. 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.
  10. 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
  11. 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.
  12. ShaunR
  13. 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.
  14. 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)
  15. 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?.
  16. 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.
  17. ShaunR
    In fact. It could probably read the current project dependencies (from the install database) and switch the symlinks to the ones required. Hmmmm.
  18. ShaunR
    I didn't need to update the other toolkits. I had to keep reinstalling the new Encryption Compendium if the other toolkits broke because of a change (until I had fixed it.)
  19. ShaunR
    I have thought about this before (project based, sandboxed). I work on projects on a different drive to LabVIEW which isn't a problem when working on individual toolkits; as they are self contained. But it got much harder once I started needing the Encryption Compendium in everything I always needed to have it installed in the LabVIEW vi.lib directory and any time I updated it had to reinstall for the other toolkits to amke sure they still worked as expected. So I played around with symlinks placed in the vi.lib directory which worked pretty well and could keep the menus in the IDE. Just replacing the symlink to different versions was also OK and worked but I couldn't figure out a way to stop some VIs recompiling (so just lived with it). Thinking off-the-cuff. We could probably have an IDE helper to select different VI.lib toolkit versions on-the-fly.
  20. ShaunR
    That's useful. IIRC, zlib supports gzip and the control files look straight forward enough.
  21. ShaunR
    @hooovahh: Thanks for moving the posts. No need to clutter the other thread with this. If that is the the cmd line one, it's of no interest to me. I can't imagine how you would use a command line to create a palette. I would also suspect it doesn't install existing VIPM and NIPM files and, if that is true, it is doomed.
  22. ShaunR
    A few years ago, I created an installer with a view to replacing VIPM in its entirety Partly because of this and a few other features that I wanted, but mainly because VPIM broke compatibility with VIPM 2014. I got as far as an installer which had categories, 64/32 bit support and some other features such as code signing, which was based around SQLite databases. The ini file feature of the SQLite API for LabVIEW was created specifically so that I could ingest VIPM spec files for this installer to install them instead of VIPM. It could also build packages (a SQLite database file instead of an INI file and a less sophisticated zip file) for its own format but I stopped short at the VIPM format as it was too restrictive (for the reasons we have discussed) and I didn't want to step on JKIs toes by releasing a competitive product. It has remained in my private toolbox ever since. Now that we have two installers, the NI and JKI ones; I can envisage one manager doing both, which IMO the NI one should have done from the get-go. If that is the case, we can kind of ignore the VIPM package format for building (but still able to install and convert them) and subsume both package managers. If we decided that we wanted to support the VIPM build standard, then that is possible too, with the same caveats as VIPM as regards bitness etc or by extending the format. However. I don't see much utility in supporting the VIPM build but I do see a lot of the code in the OpenG Package builder being useful since there is nothing inherently wrong with the zipped file format used by VIPM for distribution. Do you know anything about the NI Package Manager formats?
  23. ShaunR
    OpenG DEAB tool? It is quite likely I already have code for many of the features required for a package manager. Certainly the installation side since I've had my own for a few years, some of which is in the SQLite API installer (kind of precursor). What it lacks is the builder side but much of what is required exists (at least in part) as individual scripting tools. However, I'm still reliant on the JKI PM for menu creation and applying licences. For my purposes, I find the JKI package manager insufficient for my distribution of 32 & 64 bit binaries causing me to be heavily reliant on the pre/post install VI and carefully ensuring they aren't handled by the Package Manager. A useful feature for me would be to be the ability to define slightly different configurations for 32 & 64 bit LabVIEW at the individual file level. Please do post what you have.
  24. ShaunR
    I do neither
  25. ShaunR
    Let's agree to disagree Very much so. But lets not forget the great job VIPM does with versioning, dependencies and applying licences. That's just not true. What is true is that it is a hack at best to create a LabVIEW service. Perhaps this is what was meant.
×
×
  • Create New...

Important Information

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

  I accept