Jump to content

Mellroth

Members
  • Posts

    37
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Mellroth

  1. Have you been able to reproduce the bug with the files I uploaded? /J
  2. Hi, Attached is a simple example using the LabVIEW DynamicDispatch example as source. The internal package contains the three classes Shape, Triangle and Square. All these classes have a method named Identify. The public code is supposed to use these three classes internally, but not expose them, hence we add them as an internal dependency. If the wireflow_lib_wf_internalclasses-1.0.0.1.vip is added as a internal dependency, the build of the public package fails with the error shown in the attached image, if we remove the package from the list of dependencies the public package package builds just fine. If we monitor the VIPM temp build folder during the build, and if we check other internal packages, we see that the folder where VIPM puts the internal dependencies and adds the name-spacing is a flat structure. Since several methods have the same name it means that they will still have the same name after the name-spacing, resulting in the failed builds /J JKI example.zip
  3. We recently hit a really big bug (at the moment it is a showstopper) when trying to build a new package with a number of internal dependencies. * LV2014 * VIPM 2016 What happened was that VIPM complained about VI salready in memory, throwing error 1357, for several files in the dependency hierarchy. We were able to nail it down to that VIPM puts all dependencies in a flat structure. This means that if you link to a dependency with a class hierarchy and dynamic dispatch, all dispatched VIs will be placed in the same flat structure and thus getting the error 1357. We even tried to workaround this by putting each class in a separate llb when building the vip file of the internal dependency. This probably affects other types of packages, e.g where name-spacing via lvlib is used. I haven't found anything about this being a known issue, so please update VIPM to preserve the hierarchy of the dependencies, or at least handle a scenario with internal deps with name duplicates /J
×
×
  • Create New...

Important Information

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