Fault on opening Examples....

[wiebe@CARYA]

---

@sth wrote:

---

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.

---

Could also be a rights issue? I don't know how that's arranged on non-M$...

[Christina_R]

---

@sth wrote:

---

The error occurs before Example Finder opens

---

Oh, I thought you were seeing the error when an example opened! My guess would be that it's a VI that LabVIEW is running as part of launching Example Finder. Example Finder is a built app.

[Christina_R]

---

@sth wrote:

---

Why would LabVIEW do unusual patterns for file I/O?  Just to be weird?

---

LabVIEW being a... mature product as it is, it probably uses older APIs for file I/O than many other apps. Also, there's some complexity from being multi-platform.

[sth]

---

@Christina_R wrote:

---

@sth wrote:

---

Why would LabVIEW do unusual patterns for file I/O?  Just to be weird?

---

LabVIEW being a... mature product as it is, it probably uses older APIs for file I/O than many other apps. Also, there's some complexity from being multi-platform.

---

Being a mature product myself, I appreciate that.   But at the basics it should be POSIX compliant which is more mature than LV!  But somehow the code wrapper around that POSIX call in LV manages to confuse the code translator for the M1 CPU which is quite a feat.  I have been impressed by the amount of X86_64 code that runs well on the arm64.  Next I will test the Windows arm64 translator running under Parallels since I got the Windows arm64 version up and running.

The only think I can think of is that the endedness became confused when a I16 array is converted to a byte array for a string variable or something "weird" as I supposed.  There was a lot of cruft in trying to get LV to work with the original compiler limitations of the 90s.  My guess is that cross compiling for multiple platforms exposes bugs that were hidden in the code making the final product more robust!  Just haven't gotten NI to see it that way.