JackDunaway

I definetely think so. It runs nicely in the vein of the existing option 0x20 (do not display the loading dialog). That option list was the first place I checked when looking for this functionality. Will you post such an idea?

 

Cheers,

Steen

Rather than adding it to my (lossy) IdEx queue; by all means, I would gladly vote for your post -- and remember, etiquette there would suggest not showing a brown banner on an invoke node :-)

Would it be worthwhile to create an Idea Exchange entry suggesting that Open VI Ref have a new option, 0x200 for example, that would behave the same as this private function? This feature is incredibly more performant for tasks such as what hooovahh describes above.

You can create your own "self, signed" certs or you can use a free service. However. If you are going "public" and it will be used for commerce you really, really (can't enphasis enough.......REALLY) should buy one from a trusted CA

Yep; I'm a little ahead of you here; sorry for not giving all the details.

I have already set up the web service with a cert from a trusted CA (it's one shown in the Trusted Root Certification Authorities using the Certificates snap in on mmc.exe).

When accessing the web service from a browser; no problems. Green lock and everything (in Chrome). When accessing from LabVIEW -- "LabVIEW could not verify the authenticity of the server".

I have a hunch this could be because the cert is 2048-bit; the one from Google that LabVIEW likes/accepts is 1024-bit. I have not yet been tempted to re-key the service at 1024-bit, because i've found it's a bit cumbersome to install a 3rd-party CA cert using the Web Services configuration panel. Additionally, i have verified with Wireshark that even when LabVIEW is configured with "verify server=FALSE", the connection proceeds no probs with SSL encryption -- which somewhat lessens the severity of this issue, but I still would like to find the correct workaround.

Sleuthing a bit further with Wireshark:

It appears that the final SSL transaction from LabVIEW to the Web Service is: TLSv1 Record Layer: Alert (Level: Fatal, Description: Unknown CA)

Where does LabVIEW get its list of known/trusted Certification Authorities? This appears to be my problem.

Attempting to connect over HTTPS to a web service written in LabVIEW, I get the following error:

Error 363507 - LabVIEW could not verify the authenticity of the server

Shown below, this code demonstrates the issue. The 'workaround'? Set the 'verify server' flag to false.

Shown at the bottom is a simple HTTPS connection to Google works no prob -- could this indicate a misconfiguration on my web service?

Any ideas? Thanks!

*/build/* << This is perhaps too specific to your strategy for build artifact output folders; for instance, my personal hgignore contains builds/* and similarly deployments/*

.DS_Store << I like this

Thumbs.db << I like this

.dll << No; I currently have third-party libraries checked into SCC

.so << Not sure; but could have same argument as .dll

.out << Not sure; but could have same argument as .dll

Annotated within the quote

While creating a new a new repo in GitHub, I noticed there is not a template .gitignore for LabVIEW -- let's make one!

After contacting GitHub support asking the proper channel for submitting a .gitignore to their set of templates, i received the following response: "We have an open source repository, https://github.com/github/gitignore that we use to accept contributions for the gitignore templates. The way we accept new contributions is through pull requests" From the readme.md on that repo, "Since this repo includes a large and diverse number of programming languages, frameworks, editors, and ecosystems, it's very helpful if you can provide a link to information supporting your pull request" -- we will use this thread and public discussion as documentation and justification for LabVIEW.gitignore.

So, I went ahead and forked the repo and created a new LabVIEW.gitignore, found here: https://github.com/wirebirdlabs/gitignore/blob/master/LabVIEW.gitignore

Please, feel free to contribute to this thread, and once we've come to a consensus, hopefully GitHub will accept the Pull Request.

Here's the contents of the file right now:

# http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/lv_file_extensions/*.aliases*.lvlps

An especially interesting thread on "River Detection" in typography came onto my radar as a thread from the Signal Processing Stack Exchange (i had not heard of this forum until finding the River Detection thread)

Anyway, the real gem here is finding an entire forum dedicated to signal processing strategy; but this one problem was interesting.

What is a 'river' in typography? "rivers are bands of white space that result from accidental alignment of interword spaces in the text. Since this can be quite distracting to a reader bad rivers are considered to be a symptom of poor typography. An example of text with rivers is this one, where there are two rivers flowing diagonally" link to the thread

image from "River" detection in text

Thanks to G Systems hosting; looking forward to seeing everyone there.   

Pro-tip: The weather is liable to change any day, but if next weekend is how the past few weeks have been in ATX, you'll likely prefer a light jacket and pants for the patio in the evening. (Don't get the same mental picture as still sweating at 10PM at the LAVA BBQ!!)

I still don't understand why you want to impose a must implement requirement on Construct.  Why does your parent care if n child object was created in a Construct vi or with an object cube and a bunch of setters?  Either way is valid.  Using a Construct vi is entirely a stylistic decision.

Since subclasses inherit state from the parent, it could be desirable to ensure the parent object is constructed properly by imposing 'Must Call Parent' in addition to 'Must Implement'. (Any parent enforcing 'Must Implement' without specific functional requirements such as this is probably is better designed without the contract, allowing the subclass designer the freedom to construct the object with a constant and setters.) And 'Must Call Parent' also can ensure atomicity on construction when it's important to fully construct the object before invoking any methods on it.

What is it better to do? Put so many restrictions that they have to edit your code for their use case (and you will get all the flack for their crap code), or make it easy to override/inherit so they can add their own crap code without touching your "tested to oblivion" spaghetti -  regardless of what you think they should or shouldn't do.

It sounds like the overzealous parent class designer you describe is taking contracts to an extreme, and has crossed the line of "strategically-placed contracts to make the class easy to use correctly and hard to use incorrectly".

Just for clarity: do you suggest 'Private' scope should not exist, or should developers just consider 'Protected' way more often?

mje in this thread said he had to install the runtime separately to make his installation work correctly.  I tried this, and the exes are now running correctly. 

This sounds like you need to ensure that the Math Kernel Libraries are included into your installer.

Specifically, if you have downloaded the full RTE to your computer and run the self-extracting archive, it's the MSIs at the location: C:National Instruments DownloadsLabVIEW Run-Time Engine2012 (32-bit) f3ProductsMKL_2012

It's often possible to include only segments of the RTE without requiring the 200MB+ footprint; in this case, I think it's MKL for ya.

Hope this helps!

A good example, because “Send” being a method of Message has always looked wrong to me.  Messages are written; sending is an action of a communication channel.

I tend to agree; Send.vi is an invocation of the message transport mechanism -- Messenger.lvclass -- and Construct.vi (i prefer this terminology to Write.vi) is a member of a concrete instance of Message.lvclass -- something I realized a while back after naïvely convolving the message with the messenger.

This aside, i still want to impose 'Must Implement' on Construct.vi for Message.lvclass, yet it clearly cannot be 'Must Override' because message construction has a unique ConPane for each concrete message type.

Also, what about messages that have no data, and thus don’t need a creation method of any kind?  They don’t need to implement Send or Write.  

An object always carries 'data' -- even if it's payload-free, the type carries information about the message. There still exists benefits for requiring Construct.vi for these payload-less message objects -- even though that method effectively takes no inputs to construct.

And I'm trying to answer that question by saying, wholeheartedly, without reservation, hesitation or exception, that yes, the parent must, should, needs and wants to declare the restrictions. I'm saying that the parent has to declare what it itself is to be used for. If that design is "I am a free-floating class meant to be used in any number of applications as one of my child classes", then it will have few restrictions. If the parent class is designed to be used as a framework, then it will have many restrictions. But it is the parent class that decides its own usage. And that has ramifications for the children because the children *are* instances of the parent. And as instances of the parent, they want, need, must and should adhere to the rules of the parent.

Completely agreed; this is precisely the sentiment and context in which 'Must Implement' was proposed. A good article on this topic is Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly.

Any of the arguments above about contracts making a library harder to use, or promoting hacks to simply fulfill a contract in order to subclass, just seem... misguided. The whole point of 'Must Implement' or 'Must Override' (or any strategic contract, such as timing requirements) is to make the library easy to use correctly and hard to use incorrectly.

Consider for Actor Framework, if Message.lvclass were to define 'Must Implement' on Send.vi (as it already specifies 'Must Override' on Do.vi). Do you agree this as a good use of the contract to make subclass creation more robust and even simpler? Does this example better explain my sentiment for wanting 'Must Implement'?

Would this work?

 

2013-02-21_1157.png

This was my first thought also. This is an extremely handy method for performing VI server tasks on a single VI that don't require its static hierarchy to be loaded (psstt... this method can be orders of magnitude faster than Open VI Ref since, not only does it not load static dependencies, it does not load the owning library definition or sibling members).

Okay, I found some code from a couple years back we can pick apart....

I want to acknowledge this, and will get back with a proper response (after the mad rush to the #CLASummit).

In the meantime, here's a fun article. It's an ironic allegory comparing Functional to Object-Oriented programming: http://steve-yegge.blogspot.de/2006/03/execution-in-kingdom-of-nouns.html

A few great quotes:

One of our first instincts as human beings is to find shelter from the elements; the stronger the shelter, the safer we feel. In Javaland, there are many strong things to make the citizens feel safe. They marvel at the massive architectural creations and think "this must be a strong design". This feeling is reinforced when they try to make any changes to the structure; the architectural strength then becomes daunting enough that they feel nobody could bring this structure down.

...advocating Object-Oriented Programming is like advocating Pants-Oriented Clothing.

This article comes down a little hard on OOD, but I think its in good fun; his conclusion and the spirit to to embrace the merits of both OO and Functional! They're not mutually exclusive!

Add another vote for more code*. I have communications classes (actors, actually), that allow Byte or string messages to happen over a few different kinds of pipes. These get used in more than one project. Instrument-specific command-to-useful-string conversions are performed in their own classes. Yes, lots of code - but extremely useful, in my case.

This sounds like a different set of business and technical parameters than "i have a relatively simple test program I'm writing...I doubt this device will ever change...I don't know if with this necessary quick turnaround time it's worth writing a parent class" 

And to be crystal clear, whether or not you can answer these questions to my satisfaction is irrelevant.  What's important is that you can answer them to your satisfaction.

"this consideration is one that can easily take seconds and affect end-user experience of your application" is an oversimplification. For my app, there are numerous independently lazy-loaded application components. If all were to be loaded at once, it would take seconds. By ensuring loose coupling by eliminating static dependencies between these applications components, they are able to load independently. (It didn't always work this nicely) 

And I agree with the sentiment of your concern. You don't ever have to worry about dependencies until you do, and you will.

This may be a case of real world vs. ideal world but I just wanted some suggestions.

This general question is well-characterized and addressed by YAGNI. My anecdotal advice, initially suspect all code as a liability, not an asset. No code is better than no code.

(***Edited, to link to en.wikipedia.org/wiki/YAGNI since BBCode apparently chokes on unescaped apostrophes in URLs)

I'm not discounting your experience, but this comment does raise flags.  Exactly how big is your library that it would take seconds to load the entire thing?

Reword your question to "how big is your library and its static dependencies that it would take seconds to load the entire thing?", and perhaps we can lower those red flags. 

Congrats to the strong CLA showing in France, just in time for your hosting of the #CLASummit! Look forward to seeing you in Austin or in Paris in a month or two 

First, NotifyUser implies gaining the user's attention somehow...

Great feedback on the example.

To tweak the example, consider a base class called ProbeDisplay.lvclass whose job is to show a human-readable string for the Probe Watch Window. One could imagine there might be a lot of VIServer legwork and IDE voodoo in the base class (since it's desirable to reuse these abilities through inheritance), whereas child implementations such as ProbeDisplay.lvclass and ProbeDisplay-MyClass.lvclass would be relatively simple: serializing unique datatypes, and for the sake of illustration even sets of datatypes with multiple inputs on the ConPane if we could create some new WackassProbeExecutiveAggregator.lvclass child implementation. Now, it's clear you cannot just say "all implementations should be strings" -- now what do you do?

OK, in the meantime rewriting this post, you came in with some good reference material that will take time (read, maybe days, weeks, after CLA Summits even) to chew on:

Principles of Object Oriented Design

In return, here's a link that has helped me, from which I recognized the name Uncle Bob (who has 3 contributions on this list): 97 Things Every Programmer Should Know

And finally...

Have I ever wished I could change the conpane of overriding methods?  Yep.  Have I ever created child classes for a specific data type?  I'm pretty sure I have.  But these were driven by a desire for expediency, not because they were the correct design decisions.

It would be eternally helpful to do a post mortem on what the *right* solution would have been if you're able to share. (Or if Shaun is game, let's tackle his example in post #23) Perhaps, we decide the 'correct' solution is syntactically way too burdensome and in the architectural atmosphere, but at least we would feel less icky about the solutions as developed.

You want to enforce "must call parent", but you can't say what connector pane the parent function has? Huh?

No, the other way around: a child can always statically determine the ConPane of the parent (right?) -- I'm just suggesting parent does not necessitate the ConPane of an Implemented child method, like with an Overridden method.

You want the parent to say "I have a function and it must be called at some point by my children, but I can't say what function they need to call it from and I can't say anything about their setup". At that point, why are these children at all? Why aren't you using a delegate?

The child class must mark at least one method as Implementing the parent method. Maybe it has the same filename; not necessarily (if GUIDS in the class definition could establish this relationship). There would exist a facility for marking the child method as Implementing the parent requirement (currently, the facility for marking a method as Overriding is purely filenaming convention; if we all agree that this would be better served by GUIDS, with the ability to freely name files, we still need to develop a non-implicit facility for marking a method as Overriding a parent method!!)

I'm really missing what relationship you think these two classes have and why you think there's any sort of child relationship involved.

Can you comment on the specific example of NotifyUser.lvclass and its children? (from post #7, the tl;dr version copied below for convenience) I can't think of a better example; sorry.

Consider the class, NotifyUser.lvclass which only has one method, DisplayMessage.vi, whose purpose is to display a string to a user. Later down the road, you consider it worthwhile to display other types of things to users, like Bools and Numerics, so you decide to subclass NotifyUser.lvclass since it's already got all the business logic for displaying messages. The illustration below shows this:

Notice how the two implementations have separate ConPanes from the parent.... That's where Must Implement saves us -- the ability to establish a relationship between child and parent methods, without requiring them to have the same interface.

Another thing to note above is that the two children are broken with the message "This VI attempts to override a static VI in an ancestor class." This is due to today's design limitation that subclasses cannot have the same method names as parent methods, except in the case of overrides. Further, note that in the middle diagram, use of the "Call Parent Method" is unrecognized. These two issues would be addressed by a "Must Implement" feature, shown below...

Now, with "Must Implement", we have the ability to contractually require functionality in subclasses while maintaining the ability to extend parent class functionality, having acknowledged that Dynamic Dispatch is the incorrect tool when distinct function interfaces are desirable.

Just my two cents, but as the designer of a child class, I wish to have my child objects function properly in code written for the parent (and thus am interested in overriding and/or calling parent methods where required), but I am not actually interested in being required to do things with code written for the child.  

Then you're totally with the consensus on this thread.

So does this mean you don't use the 'Must Implement' flag? Or if you do, is it just strictly in the context of ensuring run-time polymorphism won't encounter an unimplemented method? (these questions are open to all, not just drjdpowell)

It is valid syntax if you don't use classes since it is simply calling a common sub-vi. You seem to be arguing for classic labview behaviour (which already exists).

For clarity, the reason this is not valid syntax is explained by this error: "This VI attempts to override a static VI in an ancestor class. An ancestor class has a VI by the same name that does not have a dynamic dispatch input terminal. Only dynamic member VIs can be overridden in child classes. To correct this, change the name of this VI so that it does not match any ancestor VI names or edit the ancestor to include a dynamic dispatch input terminal."

I think you're hinting that this error and problem does not exist in non-LVOOP, 'classic' LabVIEW -- true. (And the consensus seems to be that we would like to see this relationship defined by an abstracted GUID rather than filenaming enforcement, but I digress...)

Yet this "classic labview behaviour" does not exist as you suggest (in any manner other than adherence to convention), since there's no concept of the "Call Parent Method" node or an inheritance relationship defined. Call this pedantic, but those relationship/constructs/contracts do help establish intent for subclass design, and ensure certain essential parent abilities are called from the subclass.

Try again, from the top, using small words and pictures, please.

OK.

Here are pictures. And since those pictures describe a problem that could probably be solved with a Generic input, look at this picture, yet instead of having two methods DisplayMessage-Bool-YesNo.vi and DisplayMessage-Bool-YeaNay.vi, consider just one method DisplayMessage-Bool.vi that has two inputs: the Bool to display, and a second Enum which defines how to localize the message (e.g., {"YeaNay", "YesNo"})

Here's the setup: when inheriting from parent classes, a subclass might redefine behavior of the parent. This redefinition of behavior may even be required by the parent, with "Must Override". Additionally, the parent may specify "Must Call Parent" in order to ensure some essential task is performed.

Here's the problem: Dynamic Dispatch defines and requires an interface -- a ConPane -- a function prototype (this is clearly a requirement for run-time polymorphism). Additionally, only Dynamic Dispatch affords the contracts of Must Override and Must Call Parent. I find myself wanting to enforce these types of contracts ('Must Implement' and 'Must Call Parent'), yet with a separate ConPane for the concrete implementation.

Here's something that I've observed many smart people do (and done myself): Put a variant (or another stringly-typed parameter) on the ConPane of a Dynamic Dispatch VI because strong-typing was in some manner breaking their inheritance mojo. Or, a more 'sophisticated' approach is to replace this input with an object. The problem is now 'fixed' on the Dynamic Dispatch method, but pushed into another location (e.g., the construction of this object and/or the handling of this object inside the method), *and* now with a larger codebase. (*** EDIT *** One additional code smell is the presence of an "unused input")

Here's where everyone keeps getting hung up on this thread: Dynamic Dispatch affords the ability of run-time polymorphism. I'm specifically stating that sometimes it's desirable forgo this ability in favor of a more descriptive concrete API -- defining concrete methods with more specific ConPanes and Function names -- yet without losing the ability to define a linkage between parent and child abilities. It bugs me to see dozens of Do.vi functions in a big LabVIEW app implementing the Command Pattern, or in the Head First Design Patterns book see the Animal method makeNoise() abound instead of quack() or moo() or bark(). I totally understand that many application domains require run-time polymorphism (including the Command Pattern) or dependency injection (including not knowing which Animals might makeNoise() in an app) -- but for the many application domains that don't have these requirements, concrete implementations tend to be far easier to implement and maintain. It's much easier to work with a composition of one cow and one duck than anArbitrarySetOfAnimalsWhoImplementBarnyardInterfaces[], both as a human with finite cranial horsepower, and with a system whose types can be checked with static analysis rather than probing around run-time errors.

Here's a request: Please don't quote me as an arguing against Dynamic Dispatch or interfaces or inheritance or generic programming or... Each of these concepts has merits, and application domains where they shine. Don't misquote me saying static composition is better than dependency injection, or Implemented methods categorically allow more coherent APIs than Overridden methods. (I love the opportunities to work on systems that require these higher-level abstractions.) But what you can quote is my pragmatic desire to decouple some components of our beloved language in order to allow random access to each of its merits -- in this case, Inheritance of abilities and Implementation contracts, yet without Run-Time Polymorphism and specified interfaces.

Here's what I'm proposing: Right now 'Must Override' and 'Must call parent' come with the requisite usage of Dynamic Dispatch and a specified interface. Let's change the name of 'Must Override' to 'Must Implement', then allow this and 'Must call parent' as attributes of any given class member, not just Dynamic Dispatch methods.

Here's where you come in: Is there a better solution to the problem? Is the presence of the perceived problem (wanting a more descriptive API for concrete implementations and a language-feature for linking implementations to parent behaviors) indicative of a bad programming practice on my part? What other languages address this issue? It's nearly inconceivable to assume this issue has not been either: 1) already implemented in a language or 2) characterized then rejected as an anti-pattern -- so I'm eagerly awaiting links to answers if this sounds familiar to anyone!