Justin Goeres

I submitted a picture of myself to Dork Yearbook and they posted it.

Anyone have pictures of themselves that attest to their geek cred?

QUOTE (Aristos Queue @ Apr 12 2009, 12:34 PM)

"I only want to see the important parts, but it keeps showing me every play-by-play. I thought this was supposed to be execution highlights."

Now that you've brought it up, it would be pretty cool to be able to select an area of a diagram and say "highlight execution only among these nodes, but run the rest of the code without highlighting."

QUOTE (Black Pearl @ Apr 12 2009, 05:08 AM)

Until now, every developer has his code secured by using cryptographic containers (TrueCrypt).

We now want to use the advantages of a small network including SCC (Subversion).

What we could do, is check in/check out of the complete crypto-container. But that would not allow to have each single VI put under revision control individually.

What other options do we have? We have not yet any experience with the SVN process, but are planning the network structure including folder structure of the central server. Is there any encryption support by SVN?

What security threat, specifically, is it that you're trying to prevent?

If you're trying to secure the network traffic between your SVN server and clients, your clients can talk to SVN via https. You can set it up to use password authentication (which your clients can cache so they don't have to enter the password on every update or commit), or SSL keys.

If you're worried about client security, like a laptop being stolen while it's got checked-out code on it, then keep the code in an encrypted area on the local drive (TrueCrypt, as you mentioned, would do this).

If you're worried about the SVN repository itself being secure, it depends a lot on what type of machine you're hosting the repository on. That having been said, the repository is just a database that's made up of lots of files, so I would think that whatever standard security measures you normally use on the host OS (permissions, good passwords, turning off unnecessary services, etc.) would be steps in the right direction.

Since you mentioned that you haven't worked with the SVN process yet, I'll also point out that the folder structure of your repository is defined inside the repository. The host computer knows nothing about what's in there. As far as the host is concerned, the repository is just a big collection of semi-random-looking data.

QUOTE

Password-protected VIs aren't related to (or affected by) SVN at all. The password protection is just a property of the VI file itself that only LabVIEW cares about. SVN sees it as just another file. That having been said, I can't imagine ever using password protection on VIs that are under active development within a team.

QUOTE

In general, password protected VIs are not secure for any reasonably rigorous definition of security, and if you really need to protect your code you will want to do more than just password protect it.

QUOTE (crelf @ Apr 10 2009, 07:24 AM)

You totally had me until the comma. I completely agree with the unit testing, but I think the second part of that sentence is irrelevant, and possibly incite-ful. If you successfully unit test your code to well written requirements (usling standard processes, of course) then you're covered - the system design need not be considered.

Yep. Upon rereading my post, you're right. It was unnecessary.

QUOTE (bsvingen @ Apr 9 2009, 11:37 PM)

There is no way anyone can convince me that including undocumented and experimental code that potentially can lower this reliability, is ethical. (emphasis added)

But there's the rub: "code that can potentially lower this reliability."

You seem to believe that the mere existence of any undocumented features, or experimental features that are left in the software (or the runtime that it executes in) but not exposed to the user, automatically constitutes a lower-reliability system. I say unit test the code, and design the system so that no individual piece puts too much trust in any other piece.

QUOTE (normandinf @ Apr 9 2009, 07:06 PM)

It would be C only after four iterations. It's B in the general case where you get to stop the loop before the fourth iteration.

After four iterations, running average is the same as average of the last four measurements.

Actually, if you stopped the loop before the 4th iteration the result wouldn't be the running average. It would be a weird weighted average of the first measurement (the one outside the loop) with the measurements from each time the loop executed before you stopped it.

That having been said, if I were editing the CLAD I'd rephrase choice B as "The average of all measurements taken since the loop started running will be displayed." That's a clearer description of what it's trying to say.

EDIT: Doh! Christian posted over me while I was typing!

QUOTE (Darren @ Apr 9 2009, 07:20 AM)

Ben, your use of the term octothorpe just made my day! I thought my dad and I were the only ones who used the true name of the # symbol!

History shows that I choose between "octothorpe" and "pound sign" somewhat randomly, but with a weighting factor that skews toward "octothorpe" the more I drink.

QUOTE (bsvingen @ Apr 7 2009, 11:12 PM)

One reason is that statistics show that computerized control is more fail safe than any other alternative (mechanical or electric).

Please produce these so-called statistics. When the brakes fail on my car (or the electronic systems that control them), I still pull the mechanical emergency brake lever.

QUOTE

You act as if (1) there are no mechanical or electrical interlocks in place anywhere in the system to prevent the software from actually getting what it wants, and (2) there aren't independent subsystems on the car that impose other software-based interlocks on each other. I assure you there are.

QUOTE

Again, I dispute your claim that there is "no manual or mechanical backup whatsoever" in those systems. I will absolutely guarantee that there are thousands and thousands of electromechanical interlocks throughout those systems that exist solely to prevent the software from getting what it wants if it tries to do something stupid. That's not to say that something couldn't be overlooked and that a software error couldn't cause a catastrophe, but in fact those designs address that concern, too, by using multiple redundant levels of interlocks. Your continuing claim that there's nothing in place to anticipate the possibility of a software malfunction is patently false.

QUOTE

This, we agree on.

QUOTE

Yes, but the fact that we demand reliability from the control software doesn't mean that we've stopped using mechanical and electrical safety systems.

QUOTE

That's what unit testing is for.

For the record, I also agree with crelf that you're confusing undocumented features with experimental features.

Look, I'm not saying that every developer in the world should go plunging willy-nilly into every undocumented (or experimental!) nook and cranny of their development tools. However, if what we're talking about is the ethics of undocumented or experimental features in LabVIEW, then the ethical risk of using those features is borne by you, the developer. Also borne by you is the ethical risk of shipping software that doesn't do what it's supposed to. So if you're not willing to assume the risks associated with hidden/undocumented/experimental features in a given situation, then you definitely shouldn't use them. And in any case, you should thoroughly test your code to prove that it works correctly. But you can't say that NI is a fundamentally unethical company just because these features exist. Unless, like I said, you intend to impugn every single software development group in the entire world.

QUOTE (bsvingen @ Apr 6 2009, 12:56 AM)

The point is: You wouldn't use Google Chrome and a $500 laptop as a controller for the space shuttle even though it can be done

But that has nothing to do with the issue of whether Google Chrome has undocumented features. It has to do with the fact that Google Chrome, from a technical standpoint, doesn't have the capabilities to accomplish the task at hand. (Unless one of those "undocumented features" is "continuous monitoring and control of thousands of sensors and actuators, with multiple levels of redundancy and guaranteed real-time access.")

QUOTE

I write "software" and I care about documentation of the compiler a lot.

QUOTE

I don't think that's relevant. In any significant hardware system with serious safety risks like you've mentioned, the hardware must always fail to a safe state. A well-designed system will do this without the software being involved. So the idea of whether the software has "unrevealed/undocumented features" is moot, because a good hardware design specifically assumes that's the case and works around it.

QUOTE

I think that NI would strongly disagree with that (although I can't speak for them specifically). The features aren't "random," the software engineers most surely aren't "arbitrary," and you have no idea about their industry experience.

QUOTE

In terms of shipping a product, I usually prefer pragmatism over ideology, so I guess it doesn't bother me. To each his own.

QUOTE (bsvingen @ Apr 5 2009, 08:30 AM)

I used LV to program the embedded controller, then everything about that controller must be documented, and using software that I know include tons of undocumented/unrevealed features is simply not an option.

You're equivocating. Earlier in the thread you said "The only ethical correct thing to do is to document everything, also unrevealed and untested features. All undocumented features should be removed." Now you're saying that you can't (won't/shouldn't) use software with "tons of undocumented features." Which is it? None, or just less than "tons?"

If "none" is what you really meant, I would suggest you put down the mouse, shut off the computer, and go find a new profession that doesn't involve computers in any way. Your operating system, your web browser, your word processor, and any reasonably useful development tool you can think of have hundreds, if not thousands of undocumented features. To say that this somehow implies that the entire software development world is fundamentally unethical strikes me as a rather novel idea.

Either that or you're one of the most talented trolls ever to grace this forum .

I have a solution.

QUOTE (PaulG. @ Mar 19 2009, 11:22 AM)

I'm volunteering you to join the open source space shuttle control softare development team. And you get a seat on the first flight. Kick the tires and light the fires! :thumbup:

NASA already http://news.cnet.com/8301-13772_3-10097880-52.html' rel='nofollow' target="_blank">built their issue-tracking system on Bugzilla.

QUOTE (Cat @ Mar 19 2009, 04:27 AM)

Every time my cow-orker who is a C#.NET, etc whiz tries to explain it to me, it sounds like he's talking about ways of accessing typeDef-ed clusters with data and their associated info. It must be more complicated than that. I looked at the LV OOP stuff back when it came out in 8.2, but it seemed like it was adding code on top of what I was already doing. Once again, I assume my lack of knowledge is the problem.

Yeah, that's actually a pretty good explanation. So you're already like 50% of the way there .

A key point (for me) is to remember that software is always an abstract representation of a system that you could (in principle) build in real life. And in real life, we interact with literal objects (like a scissors) that have literal properties (pointy, left-handed, jammed) and literal methods (cut). So it makes sense to impose rules on our software abstractions that sort of mimic the objects we deal with in real life, because it's easier for us to visualize them that way.

To carry my metaphor way too far, if you were "cutting paper" in software, there's nothing stopping the paper from somehow knowing that the scissors is left-handed. That's essentially because computers are magic. But it's probably dangerous to let the paper know that, because the paper really shouldn't know whether a left-handed or right-handed person is cutting it. Indeed, what if you later write "Scissors 2.0 -- ambidextrous!"? Now all your paper will be broken, because it makes assumptions about the scissors. All it has to know is "I am being cut." Just like in real life.

Again, there's nothing prima facie in the world of computers that prevents paper & scissors from knowing way more about each other than they really should. So smart humans have come up with programming paradigms that allow us to enforce restrictions on ourselves, to help us create better abstractions. OOP is the dominant way of doing that.

So there. That's encapsulation and information hiding. Now it's someone else's turn to explain inheritance .

And yes, at first OOP does feel like you're adding code on top of what you're already doing. In fact, it's possible that you're already doing good OOP-like things in your code to begin with. But using the native OOP takes some of the management work out of your code and puts it in the LabVIEW compiler.

QUOTE (mesmith @ Mar 19 2009, 04:53 AM)

we need to know more about your data to offer any useful suggestions.

That's a key point. Just to play the contrarian, do you really need to compress the data at all? If you don't compress the data, how big will your files be after six months or a year?

Disk space is practically free. You can get a 1TB external drive for $100. Unless you're storing more than that amount of data (or need to transport it on a thumb drive or something), just buy one of those. If your data is uncompressed it's also easier to work with. You don't have to go through the gymnastics of going through a zip layer every time you want to look at it.

The reason you can't get a block diagram reference in a built EXE is because VIs in built EXEs have their block diagrams removed during the build process. There's literally no block diagram to get a reference to.

QUOTE (bsvingen @ Feb 25 2009, 04:17 PM)

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

Dataflow code (i.e. what you write in LabVIEW) is fundamentally the expression of relationships between pieces of data. That's one of the key differences between dataflow and imperative programming. And those relationships (in this case, the wires) determine the execution order of elements of your block diagram. If the error wires, or any other wires for that matter, were hidden, you would be hiding key information about your program's execution from yourself (not to mention anyone else unfortunate enough to see it!). Just for starters, you'd be unable to tell if a particular new wire you create would form a cycle (circular data dependency). And if it did, you'd be equally unable to tell why your diagram was suddenly broken.

At runtime, the error wire also contains critical information about the outcome of whatever operations preceded it. That information is used to make all kinds of decisions, as other people pointed out. In the process of making these decisions, the error wire can branch and merge in complicated ways that affect the execution flow of the program. Masking out that kind of information would break the entire relationship between looking at your block diagram and understanding how its code executes.

Hiding the error wires would break the whole dataflow paradigm. It would be like hiding all the individual "if" statements in C code, but not the code inside the { } blocks that follow them, or something.

I would suggest that if you really are having trouble with error wires polluting your block diagrams, you've got too much going on in your diagrams and should use more subVIs.

QUOTE (bsvingen @ Feb 25 2009, 04:17 PM)

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

Dataflow code (i.e. what you write in LabVIEW) is fundamentally the expression of relationships between pieces of data. That's one of the key differences between dataflow and imperative programming. And those relationships (in this case, the wires) determine the execution order of elements of your block diagram. If the error wires, or any other wires for that matter, were hidden, you would be hiding key information about your program's execution from yourself (not to mention anyone else unfortunate enough to see it!). Just for starters, you'd be unable to tell if a particular new wire you create would form a cycle (circular data dependency). And if it did, you'd be equally unable to tell why your diagram was suddenly broken.

At runtime, the error wire also contains critical information about the outcome of whatever operations preceded it. That information is used to make all kinds of decisions, as other people pointed out. In the process of making these decisions, the error wire can branch and merge in complicated ways that affect the execution flow of the program. Masking out that kind of information would break the entire relationship between looking at your block diagram and understanding how its code executes.

Hiding the error wires would break the whole dataflow paradigm. It would be like hiding all the individual "if" statements in C code, but not the code inside the { } blocks that follow them, or something.

I would suggest that if you really are having trouble with error wires polluting your block diagrams, you've got too much going on in your diagrams and should use more subVIs.

QUOTE (Aristos Queue @ Feb 25 2009, 08:15 AM)

I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire.

The worst part of this idea, in my opinion, is that it would've made a really great April Fool's joke. And now you've used it all up .

My recollection is that it means the default value of that control is of a class other than the class type of the control. E.g. your control is of type Multimeter.lvclass but the actual default value of the front panel terminal is of something like Keithley.lvclass, which is a child of Multimeter.lvclass.

I've never done the specific thing you're talking about, but if it's possible it will probably involve venturing into

<labview>\resource\Framework\Providers\LVClassLibrary

What you're talking about, though, is replacing the template for override VIs. I don't see a .vit anywhere for those, so it's apparently not as straightforward as the accessor methods. That having been said, there is a VI called CLSUIP_CreateOverride.vi that is probably implicated in the process. It's all very black-box because everything is password protected, but if you felt really really brave you might be able to work out how to bend things to your will.

And if you figure it out, please tell the rest of us .

QUOTE (crelf @ Jan 12 2009, 07:03 PM)

maintaining a custom builder for something this trivial is a pain when you work on many many projects and have more than a handful of developers. I suppose I could make it a standard operating proceedure

It can be, but it's pretty much a write-once-per-project item (which you can make a fairly decent template for). Also, it can be part of a one-click build process that lets anybody on your team build the app (and documents the build process, assuming your code is commented).

QUOTE

"Life is never easy for those who dream."

This has been a problem for me, too, for a long time. I eventually just gave up and stopped including installer directories in SVN. If I need to commit something, I commit a zip file of the installer.

However, this topic reminded me that a similar problem exists when using Keynote (or Pages) on a Mac with SVN-controlled documents. Namely, that Keynote (or Pages) blows away all the .svn folders when it saves a file (this is not technically a bug for reasons that are beyond the scope of this board, let alone this thread ). A while back, Omar pointed me to a script that restores the missing .svn stuff that has solved that problem for me. It's a OS X(/Linux/Unix) shell script, but it could be pretty easily replicated in a Windows batch file.

I don't recall exactly how it works, but the sequence of operations is essentially this:

1. Find the target directory's location in SVN.
   
2. Do an export of just the SVN metadata from that branch of the tree to a temp location. (I'm guessing at this -- it definitely doesn't take long enough to be doing a full export from scratch)
   
3. Copy all the SVN metadata you just exported from its temp location into the target directory. This recreates the missing .svn's.
   
4. Delete the temp files.
   

When it's done, voila! The .svn folders have magically reappeared and all is right with the world. In the case of Keynote/Pages, I just run the script after I save and before I commit. It's a minor hassle, but one I can live with.

My favorite part is "The aardvark asked for a dagger."

Also, make sure to watch it twice so you can read the crawl at the bottom of the screen.

I've seen errors like this in a few different situations:

1. When I was using a cheap USB->RS232 adapter, and either the adapter hardware was no good or the drivers were no good. The solution was to try a different (and usually more expensive) adapter.
   
2. When I was running a USB->RS232 adapter at a higher baud rate than it actually supported, and didn't realize it. The solution was to change the speed of the port.
   
3. When the CPU my program was running on was really heavily loaded. (this is probably not your problem; I mean really heavily loaded, like 100% CPU usage for 30 minutes straight)
   

I suppose it could also be a problem with your sensor device, but that's unlikely.

QUOTE (BobHamburger @ Dec 21 2008, 06:01 AM)

What I had in mind was to make some parts of the Forum Guidelines (i.e. Section 4, http://wiki.lavag.org/Forum_Guidelines#Homework_hustlers' rel='nofollow' target="_blank">Homework hustlers) more explicit and/or visible during the new account registration process. It's all too common when installing new software or setting up a site membership to have to scroll down through a Terms of Use agreement and click that you agree; the problem is that nobody actually reads these things.

There is nothing you could possibly do to the forum guidelines or user agreement that would actually cause it to be read (& followed) by the kinds of people who post HH questions. It's tilting at windmills.

I actually think we handle the HHs pretty well here. Personally, I ignore most of them, or if I have a few minutes I'll write a "show us what you've got so far" response. If I'm having a really bad day, I occasionally take a rhetorical swing at one of them to make myself feel better.

And here's the thing: we want people with homework problems in LabVIEW to be successful, so they'll have a great experience with LabVIEW. And we want LAVA to be the friendly, cool place where LabVIEW users congregate. If there are users here who occasionally want to do people's homework for them, then that honestly doesn't bother me too much. And now that I'm rereading the Forum Guidelines section you linked above, I think it's too strict. People should be able to come here with simple, newb-level LabVIEW questions for their job, so why not the same kind of questions for their school work? (provided they show some initiative, which is the way we currently handle most of it)