Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/08/2017 in all areas

  1. No thanks. That's putting the cart before the horse. Software works *for* me to make *my* workflow easier/simpler/productive. If some software doesn't work for me then I'll write some that does - even in another language if the fancy takes me Are you really suggesting that every project should be in it's own VM? That would mean I would have 523 VMs (and counting) just for Windows without even considering Linux, Mac, RT, VXWorks or test machines .
    1 point
  2. I've considered writing one, however, i have a different philosophy on dependencies and prefer all dependencies not native to labview live underneath the main project file instead of sharing files across projects within user.lib and vi.lib. Pallets would be stored in the user libraries section of the pallet viewer and all pallets would be re-written to point back to the project specific dependencies directors instead of user.lib and vi.lib. Something feels really wrong having to rewrite program files directories to maintain dependencies. I've also considered using NPM, which is the nodejs package manager, to maintain labview packages instead of vipm in combination with the approach above. This a little more involved as i need to write a script to handle different types of packages and it requires packages to have a package.json instead of a "spec" file inside of them. So there would be additional work with that. Anyway, i haven't started anything yet, but i'm also curious what else it out there.
    1 point
×
×
  • Create New...

Important Information

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