Jump to content

Recommended Posts

8 hours ago, ShaunR said:

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.

I get that. But thinking about it even more. It seems you would want to have a feature to completely remove an installed Package ?. Otherwise you would have an ever-expanding database of files.

Share this post


Link to post
Share on other sites
On 11/1/2018 at 8:59 AM, Rolf Kalbermatter said:

If there are specific situations where someone wants to discuss a different license for whatever reason with me for any of these libraries, I'm willing to discuss that. But as a community submission it will remain as it is for the foreseeable future.

I've resolved the issue.

Zlib Library for LabVIEW (BSD-3)

Share this post


Link to post
Share on other sites

Getting back to this again.

What should we do with plain zip files?

What I'm thinking of are the zip packages which are basically "install to a place of your choice-have fun" type packages. Many of these are given away as "driver" packages for interfacing to hardware.

OGPM, VIPM and NIPM all have meta data of how and where to install but a simple zip file has no meta data.

How would we handle this? Should we handle this?

Share this post


Link to post
Share on other sites

I would tend to say that it is overkill. If you really want to handle this it coudn't really be more than a 1:1 copy of the complete content to the user selected destination directory. Personally I find that this is easier to handle in 7-zip or similar on windowed desktops and on the command line if you work predominantly there (though why would you use LabVIEW then 😀).

Share this post


Link to post
Share on other sites
15 minutes ago, Rolf Kalbermatter said:

I would tend to say that it is overkill. If you really want to handle this it coudn't really be more than a 1:1 copy of the complete content to the user selected destination directory. Personally I find that this is easier to handle in 7-zip or similar on windowed desktops and on the command line if you work predominantly there (though why would you use LabVIEW then 😀).

Well. You could also generate a menu so it appears in the palette.

Share this post


Link to post
Share on other sites

If you install it in instr.lib or user.lib and do a menu refresh (application property node) it should be added anyways although with a default icon but what else would you want to add there? Creating a nicer default icon?

Share this post


Link to post
Share on other sites
1 hour ago, Rolf Kalbermatter said:

If you install it in instr.lib or user.lib and do a menu refresh (application property node) it should be added anyways although with a default icon but what else would you want to add there? Creating a nicer default icon?

True. I'm just spit-balling.

You may also get version control out of it.

Share this post


Link to post
Share on other sites

 What should the source code minimum version be? By that I mean the source code of the package manager itself, as it would ideally be open source.

Obviously 2009 is my preference but that requires 3rd party toolkits for HTTP and HTTPS; which is not really tenable for most people. Later versions are plagued by stability and performance issues so I guess what I'm asking is what is the minimum stable version of LabVIEW that should be supported based on prevalence.

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

2013 is my go-to for stable+old. 2010+11 had the new compiler, 12...I dunno what happened with 12, but it sure seemed to be unstable. Its probably a lie that my brain made up, but it always seems like the even years are much worse than the odd years, with the exception being that 2018 seems pretty solid.

2013 has the new compiler (2010) with the performance issues resolved (2012), auto-concatenating terminals (2012), somewhat improved web service scheme, get class instance by name, dotnet CLR got bumped to 4.0 (I know this may be a negative to you ;) ). The only big issue I know of is the attached code comment arrow thing, which results in an instacrash at a later date if you duplicate any multi-frame structure that has one inside.

You miss out on custom right click menus (2015), VIMs and read-only DVRs (2017), and the CLI, python node, and type disable structure (2018) -- of these only the custom right click menu is probably helpful.

Edited by smithd

Share this post


Link to post
Share on other sites

I also use 2013 as my base for most reuse packages.  It has the new tunnel options including the valuable "conditional" (fixed over 2012 to have good performance) and Variant Type VIs that are about 100 times faster (than in 2011 at least).  The next really useful feature is VIMs in 2017.

Share this post


Link to post
Share on other sites
On 2/19/2019 at 6:54 AM, smithd said:

dotnet CLR got bumped to 4.0 (I know this may be a negative to you ;) )

I don't care what version of .NET is required. All .NET is banned from my projects and some of my hair has grown back as a result :D

I too have products in 2013 and have found it relatively stable. It was my next choice if I were to be dragged kicking and screaming from 2009 :)

Anyone else prefer an earlier version than 2013?

Edited by ShaunR
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

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