LabVIEW 2022 Public Beta
Fault on opening Examples....
Installed LV 2022 beta on Mac OS 12.4.1
Opened LV just fine. Then asked to open the examples. Got the following error.
Then when ask to continue, the examples open just fine. Not sure what is going on.
Just to note, this is on an Apple Silicon laptop under Rosetta 2, so there is ample reason for NI to dismiss this, but that is the hardware I have to test this at the moment.
@Christina_R wrote:
this "internal warning" is a notification that LabVIEW wasn't able to add a file to the cache. There are a number of reasons why this could happen, and I don't think we need to dig in for more details since LabVIEW doesn't yet officially support your Mac.
Christina, thanks for the clarification. And though LV is not officially on an M1 Mac, file access is not and should not be CPU dependent.
However, your pointer to cache read/writes may be pointing to an error that should be fixed. My preferences have a different "default data" folder than default and I have a new one for each version. So in this case my LabVIEW default data folder is called "LabVIEW Data 22". Is the example finder trying to use that setting in LV or does it have its own setting that is the default?
I am on vacation and traveling and only have my (fantastic) M1 MacBook Air. But I will test this on my Intel Desktop sometime after I get home. With the same preferences file.
On a related issue (minor bug), the "example finder" application has a menu item for preferences that does not do anything and if there are no preferences for "example finder" then that menu item should be removed.
I haven't had problems with file operations in many other programs. I wonder what LV does that is so different. But that may be the issue.
My comment on the cache directory, was the opposite, was IF the objcache location that Example Finder uses is NOT the one that LV uses there could be an issue. If the Example Finder does not look at the LV preferences it will be looking for a non existent directory on my system. The way Example Finder is built as a separate launchable application should mean that it has its own preferences rather than using LV. Can that be a problem if it is looking for the object cache which is in a non-default location?
Thinking further on this, since "example finder" is multi-version (ie all versions of LV use the same example finder application then are they putting their ObjFileDB in the same location or do they inherit that individual setting from the calling version of LV?
It does not appear that example finder uses the system objFileDB as the date doesn't change as it is called/updated. Would this also apply to the merge, compare applications? Do they use the ObjFileDB in the Users preferences or some global one?
@Christina_R wrote:
@sth wrote:My comment on the cache directory, was the opposite, was IF the objcache location that Example Finder uses is NOT the one that LV uses there could be an issue.
I don't understand what you're saying about Example Finder... Example Finder doesn't, itself, open VIs. It instructs the LabVIEW IDE to open the examples.
Maybe I am completely off base here. I was thinking that Example Finder was executing VIs to find and display the examples (ie Example Finder is written in LV) and those needed to to find their code that is not in the VIs themselves but in the Object Cache.
The error occurs before Example Finder opens and there is no problem having the LV IDE open the Object Cache. So I assumed it was the VIs internal to Example Finder that needed the object cache and thus triggered the error.
If Example Finder is looking for the object cache and that file is NOT in the default location for the user, is that a problem? That path can be set in the LV IDE so that the LV IDE uses that default location. BUT Example Finder does not know about the settings in the LV IDE?
Maybe this is taken care of and I am back from vacation and will check all this on an Intel iMac to eliminate the M1/Rosetta 2 issues. And thus be in step with official release information.
@Christina_R wrote:
I have no doubt that LabVIEW does unusual patterns with its file I/O. We intend to port instead of relying on Rosetta 2, but I can't promise a timeline.
That is great and of course I look forward to it and timelines are always aspirational! Why would LabVIEW do unusual patterns for file I/O? Just to be weird? 🙂 Anyway, I installed the beta on an Intel machine (though it is also an "unsupported" OS (Mojave)) and the examples open just fine. Still not sure exactly why the VIObjCache is accessed by either the LV IDE or the Example Finder when it launches. You were right, it is a Rosetta 2 issue.
@sth wrote:
Still not sure exactly why the VIObjCache is accessed by either the LV IDE or the Example Finder when it launches.
I assume a VI is loaded...
That would (try to) access the VIObjCache, assuming the VIObjCache is the compile cache database.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
I assume a VI is loaded...
That would (try to) access the VIObjCache, assuming the VIObjCache is the compile cache database.
Obviously, but is that VI being loaded dynamically by the LabVIEW IDE or by the "Example Finder"? They may have different pointers to individual VIObjCaches depending on preference settings.
