JackDunaway

Neat! I see a prime candidate for Coerce to Type in there; this, and removing the decrement by pulling the ENUM output before the increment could tidy up that last bit of syntax.

On-board diagnostics linked to your smartphone -- the future is here. I'm sensing a mid-summer Christmas present this year... http://www.automatic.com/

Turn your volume on for this one; but make sure it's at 5%!!

Rolf; thank you for this reply. To follow up, I have received some ideas through another channel on how to solve this issue; I will report back after testing the suggestions. (Having just concluded the CLA Summit, I will be back on this project soon). Brief spoiler -- this channel's suggestions are not unlike yours.

(Replace the lowercase actor below with process or subsystem or service... it's more general than an Actor Framework Actor.) I had a brief offline conversation about this topic the other day about the semantic difference between a command and a request sent to an actor. An actor receiving requests is generally in charge of its health and destiny; an actor sent commands is subject to DoS attacks or other hazards from external sources, whether incidental or malicious. As Dak mentions, separating incoming messages from the job queue is a great implementation for receiving requests (I owe a lot of my understanding and respect for this concept to the JKI State Machine). The visual below represents an actor (the traffic intersection) and its response to individual messages from four distinct non-owning-but-using actors (the incoming lanes) defining their own concepts of priority (drivers with their own agenda). Were this intersection handling incoming requests rather than commands, it performs its job more effectively (by coordinating order, rate, and even batch-ness by aggregating requests to provide efficiency) and reduces undesirable interaction between the four independent actors. (Finally, I don't assert requests sent to actors are universally better than commands, since they each have merits in different problem domains; just acknowledging the existence of this concept, especially when chain-of-command and ownership does not naturally exist.) Originally from: http://chivethethrottle.files.wordpress.com/2013/01/random-t-01_18_13-920-55.jpg

Can you explain this one? And for clarity; this is for the .hgignore checked into your repo root or the global? Ignoring the ignore file.... I can see where this is desirable, but not necessarily the norm. I'm not well-versed enough in the FPGA domain to make a decision -- but would you say for the same reason as DLLs etc, it may be desirable to check this into SCC if it's part of an RT distro, and therefore not a good candidate for the baseline .gitignore?

Thanks for linking conversations to substantiate! Here's commentary: For the same reason I would not include DLL and other library exclusions from gitignore, I would not add an exclusion for ZIP, VIP, and OGP (since they can be dependencies as part of a distributable application -- e.g., they can be but are not necessarily 'end products'). And as for /built*$ and /build*$, the same conversation applies from Shaun's suggestions -- these are better placed in individual developer's Global ignore. But you're onto something with the .viobj -- are there instances where this can end up in the source directory?? Or is this a throwback to the early days when there was discussion if viobj would be stored locally with the source or in a global cache (spoiler: the global cache idea won out -- *i think* -- yet if there remain some cases where viobj is stored in the source dir, that's a great reason to include viobj in the default gitignore)

Yes; and this question prompted further digging and inspection of other gitignores in the repo, and the README.md has this information: "Global gitignores (OS-specific, editor-specific) should go into the Global/ directory." OS-specific includes .DS_Store and Thumbs.db, and something like */build/* would be considered editor-specific. So; for now, we're back to the original with just .aliases and .lvlps. For those using Hg: what do your .hgignore's look like?

Would you suggest for this reason removing Probes and Menu Palettes from the LVClass definition? These are precedences of conveniences/facilities to use the class effectively, yet do not define the operation of the class. Unit Test usage in this context could be considered an extension to documentation. (And: I'm not necessarily seriously supporting making Unit Tests a first class feature of the class definition; it was more, just throwing it out there to consider and iterate) If the Unit Test is a member of the class, what's to prevent white box testing with scripting? That's a form of inspection; sometimes better than the human eye (e.g., for catching an error wire that runs under a method rather than connected to its I/O). Unit test here could be used interchangeably with VI Analyzer test. I won't disagree. The value of unit test coverage roughly seems linked to economy of scale with larger projects/teams -- single devs on small projects likely don't offer their customers value with 100% coverage in lieu of more features; on the other hand, massive OSS projects with neutral Unit Test and Style arbiters allow hundreds of devs to contribute. Many LabVIEW projects tend toward the smaller spectrum. I've yet to work on a project, no matter how small, that wouldn't have benefited from at least a couple strategically-placed tests. YMMV. What are reasons to store the Manifest as a separate file from the LVClass?

Slick. +1. Slick. +1. +1 for starting a great topic to drum up some awesome tricks.

With regards to to the straightjacket -- this finally triggered a synapse none of us have keyed onto yet: unit testing. It's a manner in which the parent class can supply a bread crumb trail as to what is expected of a child class. Yet the child class can choose to fail or ignore these tests. Can we think of ways to incorporate unit tests as more of a first class feature of class definitions? Perhaps even making ad hoc execution of the tests as simple as right-clicking a ProjectItem that's part of the class?

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.

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!

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 How can this be improved?

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!!)