Jump to content


Jim Kring

Member Since 15 Mar 2006
Offline Last Active Apr 30 2017 03:43 PM
-----

#6075 Un-Publish/Deprecate vs. Install Other Version

Posted by Jim Kring on 29 May 2015 - 09:05 PM

Hi James,

 

Here's the reasoning behind the current behavior:

 

- If a user installs a package, it gets added to the package cache (regardless of where it came from: double-clicked from the desktop or downloaded from a repository)

- The package list gets populated from a combination of the repository and what's found in the cache.

 

Now, it might make sense to tweak this behavior, such that deprecated packages (as defined by a repository) are flushed from the cache. I think that this behavior would meet your needs and wouldn't have any negative side-effects (except that people who choose to actively install a deprecated package would need to download it again, since it wouldn't ever be cached).

 

Additionally, it might be helpful if unpublished packages (when we query the repo and we detect that it was in the repo previously but no longer in the repo) were flushed from the cache. This would be a little trickier, since we would have to catch the event at the time the package is unpublished (we would see the package is published and then it disappears from the repository's package list).

 

I'll pass the ideas along to the JKI team.


  • 1


#6021 When will this be released?

Posted by Jim Kring on 13 April 2015 - 04:54 PM

I'm dying to see more of this.  I bid on a project that may start soon and will use the JKI State Machine, and I'd love to consider State Machine Objects.

 

Hi Jim: Depending on how eager you are to play with this, I could get you an early release to test and provide feedback.

 

Jon: Same goes for you.


  • 1


#6003 State Machine License

Posted by Jim Kring on 27 March 2015 - 04:26 PM

Hi, Brian. This is a timely question.

 

JKI recently announced several open source projects, here: http://jki.net/open-source

 

The JKI State Machine is one of them and will be released under the BSD license. We've actually already put the source code on GitHub.

 

We'll be releasing the package on vipm.jki.net for installation with VIPM, shortly.


  • 1


#5953 Build resource package similar to JKI_RSC

Posted by Jim Kring on 13 February 2015 - 05:57 PM

Hey Chris,

If you're looking to create your own root-level menu, we support this with the Custom Category feature.

2015-02-13_09-40-37.png

The "RSC" thing is just part of the package name. And, I would not recommend trying to replicate what the rsc_palette packages do, since it involves a lot of arcane and complex stuff that I can't remember all the details about right now and I'm one of a small handful of people in the world who understand the details -- I don't recommend joining that club Posted Image
  • 1


#5847 Manually Add Packages to vipc

Posted by Jim Kring on 05 December 2014 - 09:52 PM

Hey James,

Thanks for your question: it inspired me to write up a short blog post on pinning packages :)

Have a great weekend!

-Jim
  • 1


#5845 Manually Add Packages to vipc

Posted by Jim Kring on 05 December 2014 - 08:17 PM

Hi James,

I've just updated the How to use VI Package Configurations (VIPC) help document to include some info about how to manually add new packages to a VI Package Configuration file. Basically, there's two ways:

You can manually add packages to a VIPC file by dragging & dropping them from the VIPM Main package list into the VI Package Configuration window, as shown below:

2014-12-05_12-12-13.png

Or, you can right-click on the package from the VIPM Main package list and choose Send to Configuration, as shown below:

2014-12-05_12-10-43.png

I hope that helps!
  • 1


#5643 Extract license text from VIP file

Posted by Jim Kring on 01 May 2014 - 10:28 PM

Actually, I think I spoke too soon. I see that if the build spec doesn't give any license text, the license file isn't included in the ZIP. I added logic to handle this gracefully. Thanks!


The spec file contains the license agreement name, whereas the "license" text file contains the actual license agreement content. Back in the days of OGP files, we only supported the license agreement name in the spec file and not including the actual agreement itself.

It sounds like you've got what you need. Hopefully my addition comments are helpful, too :)
  • 1


#5627 Extract license text from VIP file

Posted by Jim Kring on 22 April 2014 - 04:59 PM

Is there a way to do extract the full text of a software license/copyright from a .vip with the VIPM API? I need to automatically collate the licenses for dependencies in a new text file as part of our build process.


Here is an unofficial way to read the license text that is not guaranteed not to break in the future :) (and, if you can't find an officially supported way to do this, feel free to suggest it in the VIPM Idea Exchange)

Read VIP License Text.png
(this uses the OpenG ZIP Library)
  • 2


#5346 Can't run test case :-(

Posted by Jim Kring on 01 October 2013 - 04:36 PM

I agree with this list, and last point should really be made clearer to new users, I was hit by this too.

By the way, is VI Tester still maintained? A quick browse of the forum shows known bugs, and enhancements that should be straightforward to implement, but the last release is nearly 3 years old...

Thanks anyway for making it available!


Hi Charles! Thanks for the feedback on your getting started experience. I agree that these three things could be improved.

Yes, VI Tester is still maintained, minimally at the moment, but (fairly) we'd love to be able to give it even more love than we're able to right now.


Let's keep the dialog going. It's great to hear that people use/love VI Tester and it motivates all of us at JKI!
  • 1


#5221 JKI module template

Posted by Jim Kring on 03 July 2013 - 03:17 PM

Hi,

I was wondering if there was an area/site with active development and discussions around the module template you presented a while ago (http://blog.jki.net/...-now-available/). I have used this for a recent project and I really liked the framework (for working with multiple instruments at the same time), and I thought it would be interesting to see how others use it and mabey learn more about how to best use it. I only found one related post on this forum (from 2011).

Either way thanks for the free stuff :)


No, but that's a fantastic idea! We use and love this framework (obviously) and have a lot more we could talk about.

When did you evolve the template at all for your application? Did you hit any limitations? There are (hopefully) some cool features coming in LabVIEW 2013 that will make this design pattern even better, so stay tuned.
  • 1


#3644 [Feature Request!] Supports Icon Layers in LV 2009+

Posted by Jim Kring on 07 December 2010 - 11:51 PM

Great idea! This would certainly be a cool feature.

In the meantime, you could store your icon with layers in the icon of a VI that you keep in your VI Package's source folder (for example, rather than creating a Photoshop or GIMP file with layers). You'd then need to copy and paste it from your VI into the (LabVIEW) icon editor in VIPM.
  • 1


#3589 VIMP crashes after splash screen

Posted by Jim Kring on 21 November 2010 - 08:25 PM

As the title and topic description says...

When I start VIMP it crashes. It happens always (except after the installation of VIMP, so generally speaking I could also just reinstall and the problem is fixed for 1 time :))

When i check the log it tells me that there are some permissions issues. Now the error log seems pretty straightforward to me but I'm wondering how can I fix this?


Can you try running VIPM as administrator and see if that helps? It looks like you have a file permission issue.

Which version of windows are you using?

Thanks,
  • 1


#3426 New Package (System) Auto-Dependency

Posted by Jim Kring on 10 September 2010 - 03:53 PM

A "System" package is an under-the hood feature in VIPM that is used to support installing files outside of LabVIEW. In fact, you can sort of think of the "?.?" LabVIEW version (in the drop-down list of the VIPM Main UI) as the "System" destination.

When you build a package that includes files to be installed outside of the LabVIEW root folder, VIPM creates two packages: one for the files installed under LabVIEW and one for the files installed outside of LabVIEW. And, The LabVIEW Package has a dependency on the System Package.

If a System Package is installed, it will show as installed in every LabVIEW version (when you switch LabVIEW versions in the VIPM Main package list UI). This is critical, because you don't want to install a System Package more than once (in different LabVIEW versions). It's OK to install LabVIEW Packages into multiple LabVIEW versions (<LabVIEW>\MyFiles), but it's not OK to install a System Package mutliple times ("C:\MyFolder"), because the files would get overwritten.

The end result is that if you build a package that includes VIs that get installed in LabVIEW and a DLL that gets installed into the Windows System folder, VIPM will build a LabVIEW package for the VIs and a system package for the DLL. So, you can have the VIs installed into multiple independent LabVIEW versions, but the DLL will only get installed once into the system folder.

One other behind-the-scenes feature is that VIPM includes the system package inside the LabVIEW package (as sort of an internal package). This means that you only have to distribute a single package file to your users/customers.

Now, there are a few things we could do to improve the user experience in VIPM to make it more clear what's happening with the System Packages. For the first release of this feature, we simply show the the System package to the user as a first-class package, but we've considered the possibility of hiding these or perhaps showing them as more closely related/coupled to their LabVIEW package counterparts.

-Jim
  • 1


#3017 Apply packages programmatically?

Posted by Jim Kring on 22 December 2009 - 05:19 PM

Is there anyway in the meantime to do it from a command line?


Warning: The following is not an officially supported feature and may cause your computer to explode! ;)

In VIPM 3.0 you can use the following (quotes required):

"C:\Program Files\JKI\VI Package Manager\support\VIPM File Handler.exe" -- "/command:apply" "/source:path\to\vipc\file" "/quiet:TRUE"

The /quiet parameter is used to suppress dialogs and can be set to TRUE or FALSE.

Note: on Windows 64-bit, you'll need to use "Program Files (x86)" instead of "Program Files"
  • 1


#2929 jki state machine producer consumer loop

Posted by Jim Kring on 31 October 2009 - 09:58 PM

I tried to do what you have said for the producer consumer loop with events and data for the JKI state machine. I created a cluster with user all user events I needed and worked from there. I am sending the project file attached for labview version 2009 (could not be saved in Labview version 8.2 because it generates an error). I hope that this is what you had in mind.


Helcio,

You did pretty good :wacko:

Here is a new version with some changes:

Attached File  jki_producer_consumer_loop_with_events_and_data_lv_2009.zip   89.66KB   713 downloads
You'll notice several things:

Every different event now has a type definition
Will definitely save you a LOT of time, if the event data ever changes.

The cluster of user events is now a type definition
Could save you a LOT of time, when the number of events ever changes.

I renamed "jki create and register events.vi" to "jki create events.vi"
"Creating" and "Registering" events should be separated, because we might have multiple consumer loops that register (subscribe) to the events.

1.png

I renamed the event cluster output of "jki create events.vi" to "My User Events"Since this is the name that shows up in the event structure, we want it to be readable ("user events out" doesn't really apply well).

0.png

Don't use variant data + string message for events with well-defined data type
Using variants takes too much work. Since you have multiple events, make each events data type different.

2.png

There are still a few more improvements that I would probably make, that move it into a more object-/component-oriented" design. I'll make another follow-up post, soon, with some of these improvements.

Regarding LVOOP...

However, I have no clue how I could use LVOOP to avoid having to convert variant, therefore you will see conversions all over the code:

Sorry about that. LVOOP is a pretty advanced topic. In case you're interested, what I meant was: you can create a parent class called "Event.lvclass" and then create child classes for specific event types. Each child class can implement a dynamic method called "Handle Event.vi". Inside the event structure, when the event happens, you can call "Event.lvclass:Handle Event.vi". This will then dynamically dispatch to the child implementation, based on the type of the event object.
  • 1