Thoric

Thanks for the reply Jack. Really? Maybe I'm missing something then? In my master library I have a bunch of classes, sublibraries (containing more classes) and XControls. I wish for some class functions not to be publicly callable so as to prevent end-users messing around, so I'm to choose from scope choices of Community, Protected or Private. Private is for callers within the class itself. Protected is similar, but also accessible to child classes. Community (and this is from the LV Help) "The item is visible when users view the LabVIEW class. Only friends and VIs within the project library can call community VIs.". Well this is what I need for my class VIs, because my XControls are within the owning LabVIEW library and listed as Friends of the class(s). If I make these class VIs public I surely expose them to the end-user?

I'm encountering this exact issue when test installing my toolkit in LabVIEW 2013. Built in VIPM, I get this error when first loading the newly installed library into memory. LabVIEW first asks me for the password for the various libraries, but it can't be provided so I end up with the error mentioned in the original post attributed to numerous VIs. I've opened a support request with JKI as this is a known issue with VIPM, but I wonder if there's any advice I can get here on how to circumvent this issue? Or why I only see the error in LabVIEW 2013? I'm quickly trying to catch up with the thread content (I'm not a formally trained OOP developer like some you folks so I'm just about treading water here), but from what I understand I can avoid this by: 1. Password protecting my source in LabVIEW, not VIPM. This would mean careful cloning of the Project before building it. 2. Avoiding the Friend relationship, and exposing functions as Public to ensure friend classes (and XControls) can access them. Disagreeable, given I'm trying to protect content.

Note that in LV2013 you can flush events. Although I haven't used it yet, I'm pretty sure this means you can flush the event queue of any further resize events. Special care may need to be taken to ensure you get the current resized dimensions when handling the event though.

Inlining also has the advantage of removing redundant code from the subVI if not required for that particular call (Look for "DFIR Decompositions" in this white paper). The obvious advantage here is not performance, but code size reduction.

Very similar to your experience, the project reports fine but it's VIPM package builder that's failing to build. Once I sorted out these oddities it builds fine (albeit very slowly now?) I'll check out your link Neil, I think it might be great to dissolve the mutation history. I can't see why that would be useful once a library is set in stone (which I hope it now is).

Creating a virtual folder, moving everything into that, and using the "convert to library" feature seems to have worked. It needed a mass compile to resolve the masses of errors that were created, but it may be I have a working structure now. Some further testing is needed to be confident... Edit: After further testing it appears that some of the friendships between XControls and classes were not migrated, so a friend of the XControl previously at: PTP_Sequencer.lvlib:class.lvclass that moved to PTP_Sequencer.lvlib:ptp_sequencer_core.lvlib:class.lvclass was still listed in the XControl's Friends tab as being at the original namespace path. Therefore it lost it's friendship which broke some VIs. Simply removing the invalid class friendships and re-adding them solved this issue.

Hi Aristos, This is LV2011SP1. I wanted to try discussing the issue without code because it's part of the PTP Sequencer toolkit. However, I guess it doesn't really matter too much, so I'll be more accurate. I was rearranging my classes to the following structure: PTP_Sequencer.lvlib - ptp_sequencer_public.lvclass - ptp_sequencer_core.lvlib - ptp_sequencer_element.lvclass - ptp_sequencer_container.lvclass - ptp_sequencer_loop.lvclass - ptp_sequencer_branch.lvclass - ptps_ps_service.lvlib - ptps_pub_sub_service.vi - (lots more classes) I have everything under PTP_Sequencer.lvlib currently, and I'm trying to add ptp_sequencer_core.lvlib. When I create the _core library and start moving the classes into it, that's when all holy hell breaks loose. Although LabVIEW doesn't complain about the move, things start getting weird afterwards. I didn't want to create a service request because I suspect I'd be told "these issues are resolved in LabVIEW 2012...", but I want the toolkit developed in an older release to ensure compatibility with as many users as I can. I can't go older than 2011 due to the use of a few features that came out in that release (DVRs?). I may still have the corrupted versions because I've been backing up to separate folders at regular intervals to ensure I can revert easily. I'm about to try to achieve the above hierarchy again anyway, so I'll probably have a new corrupt version in a few minutes... Well that didn't go well. LabVIEW popped!

I've been bashing my head against the proverbial wall for a couple of days now trying to understand what was corrupt in my LV project hierarchy. On the face of it, all appeared to be fine, but I was getting some very unusual errors when executing my VIs. Errors that hadn't occurred before I rearranged stuff. In my project I have a number of classes, with various inheritances and other defined relationships, and I recently moved some things around to make it, well, better organised. I ensured I didn't destroy the relationships required to maintain access to class methods etc. Indeed, after the rearrangement, there were no broken VIs, and a mass compile (for good measure) came back clean. Now, although the majority of my classes were working fine, I had a very bizarre "Out of Memory" error occurring when accessing the private data of one particular class's DVR via an in-place structure. The private data of the class is nothing more than an array of a cluster of elements. Typically the array is empty, and in the in-place structure I am combining the contents of one class's array of elements into another's. And indeed, in the above error case I had two empty classes, so the build array function had no real work to do, yet I saw some very odd behaviour. Firstly, when highlight execution was on, the array datawire from the unbundle terminal of the in-place element structure should show "#0" to indicate no elements in the array, but in fact would regularly show #84 for one, and I would never get to see the other due to the "Out of memory" error. This was very repeatable, even after rebooting my computer. Where was it getting 84 elements from!? In a generic probe place on the class itself I would see that although the class wires showed normal content (zero elements in their private data), their Value field showed an incorrect namespace entry. This class is owned by a single library, so the namespaced title is mylibrary.lvlib:myclass.lvclass. However, the probe's namespaced title was mylibrary.lvlib:sublibrary.lvlib:myclass.lvclass, where sublibrary.lvlib is a library definition that I emptied and removed a few days ago. Yes, the class used to belong inside this library, but no more. In the library project view, the class can be confirmed to live directly within mylibrary.lvlib only. sublibrary.lvlib isn't even on the file structure anymore, it's literally gone - yet LabVIEW didn't seem to recognise this conflict. After seeing this I realised there was a corruption, but I couldn't see how to properly inspect the defined class ownership properties, or influence it? There's nothing under the Properties panel accessible from the right-click menu? I wondered if dragging the class out of mylibrary.lvlib and back in again would help, but it is changing these ownerships that caused this mess in the first place, so I decided to close down LabVIEW and overwrite the myclass.lvclass file on disk with a backup from earlier that pre-dated the original move into sublibrary.lvlib. Voila, this solved my issue immediately. So I'm quite perturbed to see that a bad ownership property in a class can cause LabVIEW to keel over with very odd execution behaviour, yet otherwise believe everything is fine in the hierarchy itself. Is there a way to inspect class ownership properties throughout a project to look for inconsistencies? To validate the information already there? I already tried a mass compile and that didn't resolve it. Now, I actually want it, and some other classes, in sublibrary.lvlib, contained within mylibrary.lvlib, but I've been trying for two days to recover my project after trying this once. I wonder now if I even dare try to rearrange my classes again!

I suspect this is an ideal job for the Champions. Over to another forum.....

I tend not to edit Wikipedia myself, I find my technical prose is usually inadequate. However, I just took a glance at the LabVIEW entry on Wikipedia and I am horrified. There are inaccuracies, irrelevancies, it's choppy, and generally poorly gathered. Too many cooks here I feel. I wonder who is responsible for this content? I understand that the general public are required to maintain these pages, but is there a core group of enthusiasts that like to keep this page accurate? I suspect not, because the leading paragraph still stated that the current release is LabVIEW 2012 - which tells me there are no LabVIEW enthusiasts who are also keen on keeping this page up to date. (I changed it to 2013 - my first Wiki alteration!)

Hi Val. It was great to meet you and your wife at NI Week this year. And thank you for the lift too, you saved me an enormous taxi fare!

I'm not an expert on computer science, so my opinion doesn't carry much weight, but I'll stand by that argument any day I think the inadvertent development in massively paralleled architectures for the relatively isolated field of GPUs caught most manufacturers by surprise. Although there's a massive amount of momentum that needs to be reversed, they're almost falling over each other to catch up with the realisation that this architectural arrangement presents us with an easier path of progression throughout processor development in general. In Bret's presentation he ends by pronouncing the design of a mass array of interconnected processes as the future (1980's future), which strikes a remarkable parallel (no pun intended) with our expectations of where CPU design is destined to take us in the coming decade. It's been a long time coming it seems...

I found it quite interesting that the presenter was able to make us realise, through his clever time travelling presentation, that we've been stuck following a path of relatively narrow development in the computer science field. I always find it astonishing to read that the entrepreneurs of yesteryear were sometimes way ahead of their time. So far ahead that we can still learn from their profound ideas today.

Awesome, thank you Michael for posting this. Actor Framework - 1973. Who knew!

QUOTE (jlokanis @ Sep 20 2007, 10:37 PM) Awesome. Thank you very much for sharing this :-)