JackDunaway

Chris Anderson recently interviewed Elon Musk -- great conversation between two real-life "LabVIEW Champions"* here: http://www.wired.com...on-musk-qa/all/ Brief intro to these two, and how they are connected to LabVIEW: Elon Musk founded SpaceX and Tesla Motors (both companies use LabVIEW extensively) after selling Paypal. Chris Anderson showed support in the LabVIEW community championing a lower-cost LabVIEW, spurring an IdEx Idea with 400 supporters for a new version of LabVIEW that would increase market penetration of graphical programming.

Nope - two classes, from the same lvproj (co-developed), built into the same package, with the same VIPB build produces the error.

Thanks, Mike. Again, this lower-priority for me, a somewhat esoteric bug with a simple workaround, so don't twist any arms too hard for the sake of this thread And as a final update -- I created a source distribution and did not see this error (it only happens with VIPB) -- though I'm certainly not beyond ruling out my own process error along the way that results in these errors.

Ouch! Below the belt! No, but I would vote for turning this feature off -- the main reason is when trying to reply to two separate veins of conversation within one thread. Having two discrete posts is more organized. (e.g., for linking to specific content, for readability in digestible chunks, for email subscriptions...) Anyone else have thoughts on this?

When posting a message, then soon after posting a second message on the same thread before another person posts, rather than creating a new message, the second message appends the first message as an edit. Can this behavior be disabled at the user level or community level? And what rules govern this behavior? It seems that until N amount of time elapses, the next message will edit the first message -- what is N? (Anecdotally, it feels like an hour or so)

Right, yeah, to qualify, it's sublibraries that I ended up avoiding, for three reasons: 1) Edit-time performance 2) Crazy corruption and linkage problems 3) Architecturally -- to my understanding, loading a LVLIB member loads all the members, and I want members to be loaded ad hoc (lazy-loaded). The main reason I was investigating LVLIB is as an intermediate step to later investigate Packed Project Libraries, which *might* be acceptable in the third category (loading performance) -- just need to benchmark to test the theory. OK, I may have been inappropriately attributing this deficiency to lvclasses; I'm co-developing the classes (so we're OK there -- this friendly signage is probably occurring) and distributing using VIP (so here may be where the bug is introduced). The password protection is not existent in development; it's applied with VIPB. (I've alerted Michael of this thread, to weigh in) To conclude, it's possible that I could further investigate at an academic level by creating a source distribution (rather than VIP) just to confirm password protecting is not a LV native hurdle to friendship; but this is kinda low on my priority list right now. (publicizing the few methods and moving along is way less painful) Yeah, but the one part left out of this sequence is password protection prior to distribution. Once the two co-developed classes were password protected and co-packaged via VIPB, then installed to another machine via VIPM, FlyFactory was broken since it called community members of FlyPluginBase, since FlyPluginBase could not identify FlyFactory as a friend since FlyFactory is password protected. To be clear, this is the problem I attributed as a LVClass deficiency, but you're saying it could be a VIPB issue.

Wait... whaaaaa? "Facilitate" is like the opposite of what happened here

Wait... what? Plugins would be easier without strict filenaming convention defining hierarchical relationships.

Quite true. What I'm doing is not unlike the Flyweight Pattern, where the Flyweight friends the Flyweight Factory. The Flyweight would ostensibly mark many of its core methods as private, but since the FlyweightFactory (and only the FlyweightFactory) needs access, they can't be private. Friending seemed like the right implementation strategy (Inheritance is just wrong, and publicizing methods feels icky), but is incompatible with password-protecting the libraries. So, the "icky solution" stands for now, but I'm up for re-evaluating design decisions for a better solution. ***EDIT: And again, to ensure minimal feather rufflage -- the title Community scope "unfriendly" to password protection -- bad design decision? was meant to ask if *I* am making a bad design decision; not to ask if it was a bad design decision by LabVIEW to not allow friending between password-protected classes. ***

Errmmm... yeah, about that (blush) My first attempt at distributing with a "master LVLIB wrapper" was a dismal (personal) failure. Performance fell through the floor. Trying to pull classes back out of the LVLIB caused massive project-wide corruption in several classes. I'm pretty sure this initial attempt was my own fault... which essentially consisted of selecting a few dozen classes and dragging them all into an LVLIB at once (don't try this at home, kids). Perhaps a more gradual, graceful approach to building the LVLIB would have been more successful. But another technical hiccup would have involved the desire to lazy-load individual classes, and to my understanding the "master lvlib wrapper" would cause them all to load at once. I still have my eye on LVLIB and even Packed Project Libraries as a distributable, but finer points such as this must be set aside for now. That was a long answer for your simple question, but "yes", I'm just trying to distribute two naked classes with a one-way friendship relationship. And the current workaround: change scope of those methods from "Community" to "Public".

I'm having a separate GChat about this issue, and will copy what I just wrote moments ago: "the main prob is that filenames (rather than embedded GUIDS) are used as identifiers in class hierarchies. it's frustrating. same thing bites you with Dynamic Dispatch VIs -- they must have the same filename (which I personally find annoying)... filenaming convention should be abstracted from class functionality" So, I think we're independently coming to the same conclusions here, crelf *** EDIT: and this is not a bash against the current convention, I'm sure it exists for good reason. It's just that I'm running into problems, and just trying to flesh out the best practice ***

While trying to distribute two classes with password-protected class members, where the first Class A has friended Class B, I'm getting the following error: "The first time you establish access to a community scoped item in a password-protected library, you must enter the password for that library. This can prevent users from replacing a friended class on disk with another class of the same name. Enter the password for the locked library in the Project Library Properties dialog box." Does this imply that it's a bad design decision to distribute password protected libraries that have community-scoped members and friended libraries?

OK, my LAVA membership revocation is no longer a threat... it was *borderline* painful to watch, but had some particularly clever humor/writing. And a comparison to The League (or Sunny) is not bad with the dark humor between the gang, not to mention Zaboo is about as unsavory as Rafi. Considering watching season 2 against my better judgment

Not a joke, we're trying to drill to the center of the earth: http://edition.cnn.c...sion/index.html "It will be the equivalent of dangling a steel string the width of a human hair in the deep end of a swimming pool and inserting it into a thimble 1/10 mm wide" --Damon Teagle, University of Southampton, UK (crelf: no TWSS jokes out of this quote are allowed)

I mean, if I can watch a season in 43min... will give it a shot. (Personally, can hardly wait for AHS to come out again in a couple weeks, so I'm leery about introducing anything new that might upset the show lineup...)

Can you give a teaser on why it's so good? (I've not seen you give such a strong endorsement since Arrested Development!) Kinda looks like... The League meets Big Bang Theory

Here's the scenario to create a bug: change the interface of the VI with banner "Files" and wired enum "Save Cues" to have a string filepath instead of a Filepath filepath (perhaps not the best example... consider changing say a DBL to a U32). Yet that change was not propagated back to the message sender, whatever is stuffing that queue. Now, you've got a bug that manifests itself as a run-time bug. Whereas, if the Variant to Data had the Filepath wired as its type, that case structure above would have broken when the "Files" VI ConPane was changed. Sure, you could change the Variant to Data type within that case and still forget to change the message senders, but since you're in the domain of changing message datatypes, you're much more likely to remember to change the senders also. Whereas, in the current implementation above, a change to the ConPane of the "Files" VI might not necessarily trigger the correct synapses in your brain to also change your message datatypes. I guess in a nutshell it just simplifies the mental ruleset and memory stack size required of developers when you're able to depend on the broken run arrow and compiler messages. And that probably means fewer possibilities for creating bugs.

Another thought on this matter: a broken run-arrow is your friend; the mentality of "avoid the broken run-arrow" to justify language features feels flawed (think: "auto-insert feedback node into cycles"). A broken run-arrow and strong, explicit typing is like a friendly heads-up at compile-time saying "you did it wrong". Compare this to the insidious manifestation of a run-time error, or even worse, unexplained or quirky behavior with no error, inadvertently introduced by automatic code mutations. The compiler constantly validates all syntax (yay!), whereas run-time, it's not so easy to exercise every execution path to flush out the bugs.

On the "abusable" spectrum, this ranks more toward the "asking for problems" side. That's a little different, since it's downstream vs. upstream type propagation, and sources-to-sinks is one-to-many.

+1 for "bug". Recently read an article entitled "Coffeescript: less writing, bad readability" where the consensus is that explicit is better than implicit when comparing Coffeescript (implicit syntax) vs Javascript (explicit syntax), and the same principles seem to apply here.

Yes, yes, I know... and I have come to agree with you... hold on, brb... (writing a response on that thread)... OK, back, here's the response copied: "Two and a half years later... I'm on the same side of the fence as Shane now. The points I mentioned above represent anti-patterns I was using at the time, and have since found much greater success wrapping messengers inside a class with a well-defined API. So... Kudos!" which can be read here. Thanks, Shane! It's taken me a while to catch up to you Can you provide a reference? I’ve only seen mention of that problem when the two events are in different event queues in the same event structure, such as a statically-registered event and a dynamically-registered one. As far as I'm concerned, this "can't guarantee order" is sort of an urban legend, with a grain of truth. I remember vividly Ton's example, and even though I think there's another thread, here's one instance. As long as you're OK with and understand that these two events are fired synchronously, they are stuffing two discrete queues operating asynchronously, so the order in which they are handled cannot be guaranteed. And here's a screenshot from his post that illustrates the "problem": This is a great explanation of why the "can't guarantee event order" should be considered a false urban legend. By the way, James, many great "random thoughts" that effectively provide a good practical understanding on considerations when using User Events.

Ah, yes, I ran into this limitation myself before realizing I had made a fundamental mistake. The Event Registration Refnum should not be part of the Messenger Class Private Data - the User Event Ref (the Messenger) is what needs to be stored in the Class Private Data. When creating a new mailbox, you can call this method N times for each of your N subscribers. This falls into the "messenger is decoupled from the mailbox" feature of User Events. Note that once an Event Registration is created by this method, the ownership is passed out of the class and to the subscriber (the VI with the Event Handler Structure that uses the refnum). Here's a screenshot of that VI:

Go a step farther, and make the VI broken. One easy way is to make one input "Required" -- then you can "turn off" the compiler error by creating a constant on that input. This forces yourself to go back and fix it, ensuring you can't forget and, say, make a build without the fix.

Yeah, I keep all mah named queue refs in mah global vars to make the programming more handier. Again, this boils down to best practices. SubPanelling implies asynchronicity, which can lead to race conditions and missed messages. One notable example is the Shutdown event -- it's possible that a system can issue the shutdown command the moment after a command to begin SubPanelling has begun. (We would agree here it's a bad programming practice to "stream" events into an unhandled queue for too long; that would probably be an abuse of pre-registration.)