Jump to content

Francois Normandin

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

Profile Information

  • Gender
  1. @felipefoz is aware of this, but for other folks out there, this is set to be part of Caraya 1.2 when released. https://github.com/JKISoftware/Caraya/issues/121
  2. @Mathilde (I just saw this thread today) Caraya is not well suited for automated code coverage calculation as it executes at the VI level, not the application level. There is no inspection performed and the framework is all geared towards individual assertions. An application could be developed, on top of Caraya, to inspect code and report on the minimum number of assertion tests to be performed to cover all conditions, but it would probably still be opened to interpretation since different assertions can be done on the same case to test all the limit conditions. As an examp
  3. I'd love to be able to filter out the vipm.io content with labels such as "open source" to only list the projects that have a public repository that I can fork and/or contribute to. This would filter out any package that do not accept contributions. Free does not mean opened. I know that "tags" could be useful filters, but tags do not mean that the information is verified. If there are multiple packages that provide solutions to similar functionality, I'd like to further filter down the list. On the other hand, some users might want to filter out the open source projects in favor of com
  4. @turbophil The reason we exclude the Test Suites from the list of scanned VIs is that we need to create a Test Suite when finding tests programmatically (from the CLI or through VI Server calls). Since the Caraya 1.x architecture does not support nested Test Suites, we have to exclude them from the list, otherwise we'd throw errors. It is not a fundamental choice, but rather a legacy decision to preserve backward compatibility when we upgraded from 0.6 to 1.x. The feature, I think, requires a modification of the Test Suite architecture, one that has a potentially rather large impact
  5. Sure. Here is a sample project with LV2013 SP1 and a build deployed in LV2017 reproduces the issue. The package installs the example under "vi.lib/testing" folder. testing_lib_rtm_bugtest- RTM LVLIB Bug.zip
  6. This bug affects VIPM 2019 (not tested with earlier versions). Problem: The .mnu file located inside a library does not relink when building the library into a package. How to reproduce: In Caraya.lvlib, there is an "Application Menu.rtm" menu file that defines the menu for the interactive UI of the Basic Test Manager class. After building the package, the menu file's URL does not relink properly in Caraya.lvlib. Before build (from source Caraya.lvlib): After installed package (from toolkit location of Caraya.lvlib): Current Workaround:
  7. Hummm, lately I tried to put the classes in llb files and I got errors that VIPM could not detect the LabVIEW version of the files. At first, I attributed that to a file corruption and I took the VIs out of the llb when I resaved them. I thought that was it, but I reput it in a llb and couldn't build again. If I can make it work with LLBs, I'd be glad to do it. Does it mean I need to deploy with "Destination Type" == Directory ?
  8. Has this issue been resolved? If not, is there a known workaround? I'm thinking about putting the child class in a separate package but I don't know if I'll have problems with namespacing, and I find it's not a very efficient way if I want to distribute my plugins all separate: it could make for an impressive number of packages. It probably would anoy people if I started posting these on LVTN for example... Just a thought, would it be possible to change the filenames in the package as a pre-build instruction and rename them with proper namespacing on install? François.
  9. Thanks Jim. Now that you explain it, I remember during the beta tests that it was mentioned. I just forgot what form it would take in real life! So it's obvious that the PNGs that serve for the creation of customized controls don't have to be reintalled/uninstalled for each LabVIEW version. Clever.
  10. This is the first time I build a package that takes two lines in VIPM. The second is named identically with a reference to (System) and is an auto-dependency. It seems to work fine and I see it happens with stuff on the LabVIEW Network. What does it mean? http://screencast.com/t/ODIzODBiZjkt
  11. Hi folks, I'm trying to come up with a way to build packages that will add some controls or functions to an already existing palette created with a previously built package. This would be like some sort of "Expansion packs" to extend functionality of a library. I realize I'm talking about dependencies and VIPM deals with that quite transparently, but here's the twist: I want to have these palettes expand much like the OpenG palettes... that use dynamic palettes. How can I access similar functionality for my packages without using a post-built installer? I'm not sure I make sense...
  12. Cool indeed. Chris, you seem more happy than I am... thanks Jim. [Long shot] What about VIPM 2.x? [/Long shot]
  13. Hi Philippe, actually, I would still like to know if there are any VIPM 2.x updates available. (Of course, there might not be any...) Unchecking this bullet will remove any notifications. Well, I'll get the news of new updates from the RSS feeds anyway, so it's a good workaround. thanks, François
  14. Hi JKIs, I'm working with VIPM 2.0.3 Professionnal and hasn't received funds to update to version 3 as of now. If I update without upgrading my support plan, I'll have to downgrade to Community edition. Is there a way to have VIPM not look for version 3 updates if I have a Pro Edition?
  15. Is there anyway in the meantime to do it from a command line?
  • Create New...

Important Information

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