Jump to content

ShaunR

Members
 View Profile  See their activity

  • Posts

    4,871

  • Joined

  • Days Won

    296

 Content Type 

Everything posted by ShaunR

  1. 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.
  2. ShaunR
  3. 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.
  4. 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)
  5. 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?.
  6. 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.
  7. ShaunR
    In fact. It could probably read the current project dependencies (from the install database) and switch the symlinks to the ones required. Hmmmm.
  8. 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.)
  9. 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.
  10. ShaunR
    That's useful. IIRC, zlib supports gzip and the control files look straight forward enough.
  11. 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.
  12. 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?
  13. 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.
  14. ShaunR
    I do neither
  15. 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.
  16. ShaunR
    We already know how to share code. The problem is it is fragmented, de-integrated, and unsearchable across the myriad of different platforms and websites. The LVTN is supposed to alleviate that by having a central listing/repository and VIPM is the UI to administer it. What VIPM doesn't have (at least in the Community Edition) is a submission process - build, upload & publish. There is nothing to stop publishing being on Github, BitBucket or any other repository either- could be all of them and have the best of both worlds. If VIPM isn't doing it as we would like; we can always go back to its predecessor to build in what we need (Tell us about your enhancements, Rolf )
  17. ShaunR
    VIPM is the sure-fire method. It has it's quirks but ticks most boxes. There are only a couple issues that mean it doesn't necessarily suit all people, one of which is getting your repository listed. That should be up to the developer. You can argue all day and night about which licences are better or worse, but the developer is the arbiter of his creation. One of the other deficiencies of VIPM is not having a way of documenting all the licences of a package with all it's dependencies. That could be addressed fairly straightforwardly, but so far hasn't. For your particular conundrum, I would suggest multi-licencing. List multiple licences (e.g. CC-0, Public domain, MIT, BSD) then tell people they can use any one of them to their liking. Public domain is the "free"est but it is not recognised in some countries (Germany?). If it's in VIPM that's not an issue. Getting it in there is. I really thought the NI Package Manager (which I always said they should have done instead of using the JKI one) would address all this. They could even have had native SCC integration. But from what I have seen it is a poor replacement for VIPM targeted at NI products rather than addons.
  18. ShaunR
    What is this? The 1990s?. One of the major problems with search and distribution is verification. By that I mean verified as in tested, robust code that is fit-for-purpose. One reason why many packages aren't on the Tools Network is this overhead. It's also why we have the Lava CR vetting.
  19. ShaunR
    DHCP is UDP/IP not TCP/IP.
  20. ShaunR
    The second is usually used when there are multiple inputs and the terminal spacing forces bends in the wires. If you are forced to have bends because otherwise the terminals would overlap to keep the tram-lines, then you might as well make more room on the diagram for labels and controls/indicators so it doesn't look cluttered.
  21. ShaunR
    Yes and no. I find it useful to find the unhandled errors. When I build the final solution I have a scripting VI that turns it off along with others (like debug enable, VI short names etc). There are two error practices that may be being conflated from what you describe and what smithd is concerned with (and Darren describes in his talk) . Having a pass-through error (error in/out with no affecting code) and having a case structure around code with a switch on error; one case of which passes through.
  22. ShaunR
    The Sqlite API for LabVIEW has encryption and is free for non-commercial use.;)
  23. ShaunR
    I can. If you use event driven comms then you need it. Ala:
  24. ShaunR

    NI DAQ alternatives

    ShaunR replied to Zyga's topic in Hardware

    It's a fairly vague requirement that needs a bit more digging before examples can be offered. You also say that an Ethernet connected device is a possibility. These will always be cheaper than NIs cDAQ. There there are hundreds of Ethernet solutions out there but you can narrow that down for certain criteria. You say DIO. Does that mean you don't need a multifunction device (with analogue)? Single function devices are much cheaper and, when it comes to DIO, dedicated Input or output channels are generally cheaper than programmable - even if on the same board (e.g. 8 digital in, 8 digital out). What voltage range will you be working with? For DIO there are options for 24v,12v,5v and 3.3v. 24v are rare whilst 5v are ubiquitous. Does the IO need to be isolated? Non isolated devices are always cheaper but more risky. How many channels of digital in and digital out do you require? I so miss the NI DIO96! For DIO does it need to be current sourcing or sinking? How much current needs to be provided/dissipated - per channel, per bank or per device? What is the nature of the signal you are trying to detect? If it is transience, then most Ethernet DIO devices have on board processing to edge detect, vastly reducing the need for fast update rates in the client. If the processing is, say, sampling a signal, then the update rate at the client end will be crucial. These are the kinds of things that need to be considered when looking at a device of any type. What you require or choose will greatly reduce the applicability of the devices on offer and in some cases make you compromise on your requirements.
  25. ShaunR
    It does surprise me. I would have thought an entry for VI Type would have been added to the enum.
×
×
  • Create New...

Important Information

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

  I accept