Jim Kring

Hey @turbophil. Just a thought. Would using nested tests (instead of test suites) meet your requirements? You can call tests as subVIs inside of a VI that calls it's own "Define Test.vi" -- this would allow you to control the order of execution of those test subVIs.

Hi @turbophil. Which version of Caraya are you using? @Francois Normandin and team have been working hard and released a new version (1.1.0.119) just this week with at least one improvement to Test Suites. I don't know if what you're reporting was fixed or not. Thanks for reporting this issue and I'm sure we'll get you an answer or a fix soon. -Jim

Update: It appears we have a working version of VIPM for Big Sur. If anyone wants to help test. Let me know.

Hi @JamesW Thanks for letting us know you're having some trouble. We've working on a VIPM 2020 SP3 right now with some improvements to the VIPM Service and Command-Line API. I'll ping you off-line and see if we can figure out what's going on and get you up and working. Regards, -Jim

OK, I found a little more information. It seems that the permissions of temporary files and folders has changed (lots of security changes/improvements in Big Sur) and some of the operations VIPM is trying to do with temp files/folders are producing permission errors. I'm going to keep looking into this more.

Thanks. I'm installing Big Sur on a Parallels Virtual Machine specifically for testing LabVIEW and VIPM. Not yet taking the plunge on my daily machine.

I'll keep you posted...

@pkeller OK, so it's not that. I'm going to put on my thinking cap and have a big cup of coffee, now -- stay tuned...

Could you try this VI and see if it runs OK for you? (the Mac Unzip Single File from Archive.vi uses the command line unzip to do this) Point it at a package file and try to read the spec data. Here's how it looks on my computer. Mac Unzip Single File from Archive.vi Test Read Package Spec on MacOS.vi

OK, thanks. That's very helpful. Downloading spec files seems to work OK. This means: It's not a downloading issue. It's not a cache permissions issue. However, operations with packages seems to not work. This seems to point to an issue with inspecting the package files. Yes, to get things working in VIPM 2020 for MacOS Catalina (as I mentioned in another thread) we had to use 64-bit LabVIEW and we changed all zip/unzip operations to use the command line. My guess is that something changed in Big Sur. Can you run zip and unzip from a terminal command line and tell me what you see? I'm curious whether they are available and what versions are installed. Here's what I get on my macOS Catalina system.

Ya, there's something fishy happening. It seems like the package is not actually getting downloaded and copied into the cache. Can you try quiting VIPM, renaming the "cache" folder as "_cache", restarting VIPM, and then trying... - Refresh package list (check network for package updates) - File >> Open Package File(s) >> Add to Library ...and see if anything shows up in the cache.

I've attached the SHA 256 package file. Can you try downloading it and then opening this using the File >> Open Package File(s) menu item? Then, see what happens? university_of_leeds_lib_sha256-1.1.2.7.vip

Oooh... I think we're getting closer... I'm pretty sure there's no way the "Use System Proxy Settings (Windows Only)" setting will work on Mac. After you change the setting to No Proxy, please exit and restart VIPM, then try the downloading SHA256 again and see if the ersity_of_leeds_lib_sha256-1.1.2.7.vip file shows up in the cache.

Hmmm, if you choose "Download" then it should definitely download the package file into the cache folder. I wonder if this is where things are going wrong. Questions: 1) Are you signed in to VIPM? (Tools >> Sign In) 2) What setting do you have for Network Proxy? SeeTools >> Options... >> Network >> Configure Proxy to Access the Internet

Thanks for checking the permissions -- for what it's worth, those look the same as on my Mac (10.14 Mojave) And, thanks for passing along those error files. Strangely, those files (Nov 30 and Dec 01) don't seem to have the Error Code 1 or the Error Code 5000 errors in them. Can you try this test to download a package file? Right click on the SHA256 package from University of Leeds and choose Download. Check to see if the university_of_leeds_lib_sha256-1.1.2.7.vip package file show up in the cache.

I'm a little bit stumped by this one. My intuition is that it might be a permissions issue. Can you look to see if this folder is writable to everyone? Macintosh HD >> Library >> Application Support >> JKI Does the cache folder have a bunch of *.spec files in it? Macintosh HD >> Library >> Application Support >> JKI >> VIPM >> cache Also, can you look in the errors folder to see if there is an error log file? Macintosh HD >> Library >> Application Support >> JKI >> VIPM >> error

FYI, we've created Knowledge Base entry for this issue: VIPM 2020.1 Crashing on macOS 11 "Big Sur"

Thanks for the update @pkeller. I'm glad we're over that hurdle. Does the same thing happen for other packages? Thanks for your patience. We don't have too many users/testers on Mac and the Big Sur changes have been pretty significant.

@pkeller Can you try executing these two commands from the terminal? defaults write "VI Package Manager" NSGraphicsContextAllowOverRestore -bool YES defaults write "VI Package Manager" NSViewAllowsRootLayerBacking -bool NO I believe that this will make it so that VIPM can run (similar to how the commands in my previous reply enable the LabVIEW IDE to run).

Thanks for posting this @pkeller. There's been a lot of grief (in general and not just with LabVIEW) due to Big Sur, from what I'm hearing. Regarding that helpful discussion thread on the NI LabVIEW forum, did you try executing the suggested command lines into a terminal? defaults write com.ni.labview NSGraphicsContextAllowOverRestore -bool YES defaults write com.ni.labview NSViewAllowsRootLayerBacking -bool NO I'm wondering if you tried that and whether it helps to get VIPM running. I'll also ping NI to see if I can find out more... Thanks, -Jim

You're welcome. Hope that helped.

OK, glad you found a work around (sort of). Sorry that VI Package builder couldn't handle that automatically.

I think that what you’re seeing is the control is highlighted because the user is tabbing through the controls. This is built-in to all of labview’s controls. I think the only thing you can do is to configure the control to skip tabbing, but I’m not sure if you want to do that because some users really like to tab through controls with the keyboard instead of using the mouse.

Another update: We created a new Knowledge Base entry for Error 1357 during a package build (File Already Exists) Let me know if that makes sense and/or if I missed anything.

Hi again, Ivan. I went ahead and created a new Knowledge Base entry for this issue, since many others have experienced this error message: Error 1357 during a package build (File Already Exists) Let me know if that makes sense and/or if I missed anything (other possible workarounds or made any misstatements in the recommended workarounds).