Jump to content

Mariano Aristu

Members
  • Posts

    15
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Mariano Aristu

  1. Hi,

    I have a very big private package repository with lots of packages (near 250 packages), and when I go to manage repository it takes a minute more or less to load.

    I want to distribute this big repository in two or three, is there an easy and fast way to do it?

    It would be great in VIPM to view two repositories in paralell and have the option to move packages from one to the other

     

    Regards,

     

    • Upvote 1
  2. Any ideas about this?
     

    I've been trying to build the package in other computer, and I obtain the similar error but reporting issues with other vis

    Attached are the error files in both pc and also the bin files in case it could

    noviembre-09-2021 PC 2.txtvipmsupport_11-09-21_17-45-33 PC 1.binvipmsupport_11-09-21_17-43-35 PC 2.binnoviembre-09-2021 PC 1.txt

    VI Package Builder PC1.log VI Package Builder PC1.ogbld

  3. The package that I want to build depends of other package called medidas. This medidas package consist of some libraries that contains classes and child of this clases.

    When I open the project and show error list window I have no VIs with errors and also I can build and exe this the vis of the new package and builds correctly.

    This is not the first version of the package. I know that I have done some changes in the package that I want to build, and mainly of the are aesthetic changes and not related with the "medidas package"

    Atttached I send the error file in case you can extract some information

    noviembre-02-2021.txt

    As show in the attaced image I can call the openVI ref with the control string

     

    Thanks

  4. I've been playing with the latests version and It shows the message correctly. But I realised that I need a way to save in my source code all my dependencies (installed global or locally, It shouldn't matter) so the .vipc file must have a list with these dependencies and dragon should ask you where you want to install. Re-reading this threat now I understand that the location of the dependencies depends of the user and not depends of the source code.

  5. Ok, Now I understand. Dragon still knows the packages that are installed on lv-env folder despite the vipc file says that source code does not need them.

    The behavior seems now correct to me. I'm doing some tests but not in my production code, but I'm exicted to use it in production. I have several programs divided in many packages installed in the same vi.lib folder and dragon will help me to  lighten up the functions palette.

    Thank you.

    • Like 1
  6. What would occur in this situation?

    1.- LV-env folder is out of source code control.

    2.- .dragon and .vipc have, for example , 2 packages installed on the lv-env folder.

    3.- I use some of the vis in my source code

    4.- I’m happy with that and I make a commit

    5.- Now I include another package so .vipc changes (.dragon only points this .vipc file so it doesn’t change)

    6.- I make changes on my source code including vis of the new package

    7.- I’m happy with that again and make a new commit

    But I want to return to previous commit (step 4) reverting code with GIT for example.

    My source code returns correctly and the same happens to the .dragon and .vipc, but the content of the lv-env folder does not reflect what is written on the .vipc. It has some… “orphan vis”….

    How to deal with this situation?... I suppose I can delete the lv-env folder and generate it again applying the .vipc file. But if I have many packages installed this could take a lot of time

    It would be great if it was only necessary to apply the .vipc file and dragon recognize that there are some “orphan packages” installed and delete them

    Thanks,

  7. Hi I had a package named "cfgCampaña xdas" but due to the special character ñ I had some troubles to publish. I can not remember exactly the problem. Finally I renamed the package, it it published in my repository but the old package "cfgCampaña xdas" continues in the vipc file, but it is impossible to remove, and once I try to remove with the right click menu I can not close the window

    dependencias xdas.vipc vipmsupport_02-19-20_11-45-01.bin

×
×
  • Create New...

Important Information

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