Justin Goeres

Vote!

QUOTE (normandinf @ Nov 26 2008, 05:58 AM) It probably is . I just don't want to implement it myself if there's a better way. However, posting/Googling/yelling/crying haven't yet produced a solution .

QUOTE (normandinf @ Nov 25 2008, 05:05 PM) But that only gets me the contents of the PATH environment variable. I'm talking about something like the following example of which in the OS X Terminal: [18:58:35]$ which curl/opt/local/bin/curl It returns the path to the curl binary. If curl isn't in the user's path (for instance, if it's not installed in the system), it returns nothing. Obviously I could take the results of the VI you posted and list the directories recursively until I've either exhausted everything or found what I'm looking for, but I'm hoping there's a less brute-force solution than that.

On Windows, is there a(n easy) way to verify if a given EXE is in my user's PATH? I'm looking for something similar to which on Unix/Linux. I know there's an actual Windows port of which, but that's not what I mean. I'm looking for something built-in that I can run via System Exec.vi (or other magic).

QUOTE (crelf @ Nov 16 2008, 07:20 PM) My problem with it is that it's hard to extend the library. Especially now that they've refactored it to use LVOOP, the ActiveX reference to (for instance) the Standard Report is really tightly encapsulated as private class data. Without that reference, you can't do anything to the report except what NI chooses to expose. If they're going to do the Report Generation in LVOOP (which I think is a good idea, btw), they should expose the report reference through a Protected VI so that users can easily add a child class of NIReports.lvclass (or whatever they call it) that modifies or extends the behavior for their needs without modifying things in vi.lib. That's one of the bullet-point features of LVOOP! In the current implementation, everything is really locked down :thumbdown:. Other than that, though, I like the library just fine .

QUOTE (ASTDan @ Nov 13 2008, 10:50 AM) I have a VI somewhere that does exactly this. I will try to dig it up (and clean it up) this weekend and send it to you. Regarding changing the font of individual cells in a table -- I've never tried to do that, but I think it's possible.

QUOTE (ASTDan @ Nov 4 2008, 08:00 AM) No problem. Data backup has become sort of a pet issue for me, because I think far too many people are really living on the edge and taking risks with their important data. It's really, really worth the time to set up a backup system. Think of it like buying insurance, but for your data. And if you do it right and get something reasonably automated, you can stop worrying about it. That's the real hidden benefit . Actually, the fireproof safe is a good idea! I have a safe already and could buy a new drive. I think I could create another backuppc task to another drive, and it would only run when that drive is connected. Then I'd just have to plug the new drive in every month or so, leave it overnight, and put it back in the safe. :ninja: EDIT: BTW, when I started making notes & buying parts for this, I got a little bit of the old "OMG what's this new contraption?" thing from my wife. I sold her on it entirely based on the we never have to worry about data backup again angle, shortly after she lost some of her old PhD. work in a USB key accident .

I wanted to answer the rest of your question more fully . QUOTE (ASTDan @ Nov 3 2008, 07:29 AM) When I was working independently, I took some time to figure out a backup solution for my business. It's really worth the peace of mind to do it right, and it's not that hard considering the value of the information you're protecting (whether it's personal financial data & family photos or company IP). Here's a summary of what I did. This served me well while I was in my own business, and now is doing an equally bang-up job for my personal & family data. Level 1 / Windows Workstations: All project work (this includes work projects and any "personal projects" where rev control is useful) is checked out from an SVN repository on the Server. Non-project work (like Invoices, Expense receipts, etc.) is stored on network shares provided by the Server, and are mirrored locally using the built-in Windows Offline Files feature (this makes it reasonably easy to carry work with you when you travel, and sync changes when you come back, as well as providing redundancy). Level 1 / Mac & Linux Workstations: All project work is checked out from SVN as on Windows, and all systems use the same network shares as the Windows machines. However, because Windows Offline Files doesn't exist for the Mac, some non-SVN user documents are stored locally. All user data & system configuration data is backed up nightly to External Backup (see below) via SSH. Level 2 / Server: A Linux box (but it could be any OS) providing an SVN repository and SAMBA (SMB) network shares. Each user is provided with a "home" directory, and I also have "family" and "public" shares with permissions set for family members and visitors/friends. The main data storage on this machine is a 600GB RAID5 array (3 drives of 300GB each). SVN & Windows Offline Files provide redundancy for the data served to the workstations, and the RAID5 array provides resistance against data loss due to drive failure. FYI, I built this machine for about $600 two and a half years ago, and that even includes buying a super-fancy case (which was totally worth the money). It took a few days to get it built & working, but I learned a lot doing it. This machine (and the network router) are plugged into a small UPS, that provides about 20 minutes of power in case of blackouts. Level 3 / External Backup: Data on the Server itself is backed up (using backuppc) to an external Firewire drive attached to the server. All user data, fileshares (including SVN repo) & OS configuration data is backed up each night. 7 previous incremental backups and the last 2 full backups are stored. This provides another level of redundancy for the data on the server, in the unlikely event that the RAID5 would ever fail. It also provides a brief historical archive, to guard against accidental destruction of files that aren't under SVN control. Note that this system provides 3x data redundancy (2x for non-SVN data on the Mac ) for all user & project data. That's the critical data you create that, if you lost it, would be right up there with having your car stolen. Except that you can probably buy another car. You can't buy replacements of your wedding photos or your hundred-year-old great grandma. There should really probably be a Level 4 / Off-site, but for the time being I lock the doors of my house and just pray it doesn't burn down. And if it burns down, I'll have other problems equal to or larger than granny's missing pictures.

QUOTE (ASTDan @ Nov 3 2008, 07:29 AM) As to whether a backup system will cause problems with your repositories, the answer is not if you do it right . I run my personal (non-JKI) SVN system on an Ubuntu Linux box in my office. For backups I use http://backuppc.sourceforge.net/' rel='nofollow' target="_blank">backuppc. It backs up all the data I need backed up on my server, and also backs up my MacBook Pro via an SSH tunnel (which, in principle, would even work over the internet when I'm on travel). On the Linux box, one of the directories I point backuppc to is the one where SVN keeps its database. SVN is really just a frontend to a database, and the database is where the filesystem of your repository lives. As such, if you make sure to backup the whole database then you can also just restore the whole database in the future after a catastrophe. Of course, I also back up /etc, which is where SVN keeps its config. So basically, my advice (regardless of platform) for backing up your SVN repository is to (A) make sure you back up the whole repository, which is pretty easy because it's contained under a single directory, and (B) also back up whatever directory contains your configuration for SVN, so if you have to recover you can reset to a good config, too (otherwise you might have to remind SVN where its repo is, who its users are, etc.). It goes without saying (but I'll say it anyway ) that once you start backing up your repository (which you should!) you do not need to backup your checkouts. In fact, I personally don't backup my checked-out SVN directories specifically to encourage myself to commit frequently . EDIT: I do not know much about using backuppc with Windows machines. In my case, any files that I need backed up in Windows are stored on network shares from the fileserver, which is backed up. Backuppc supposedly works with Windows, but I've never bother to try it .

I think we're missing the obvious: It's a Canadian conspiracy.

QUOTE (BrokenArrow @ Oct 28 2008, 12:25 PM) It could also be caused by poorly-written drivers for your USB-to-serial converter (or serial-port PCI card) if you've got anything like that in the loop.

It says I am The Cap'n. Who would've thought there could be two?

Aye, let it be known to all ye bilge-rats and swashbuckling wire-weavers that today be Talk Like a Pirate Day 2008. So whether ye depart port this fine morn on the Good Ship State Machine, or whether ye be holed up in The Producer-Consumer Tavern nursing yer head from last night's feast, do it like a pirate, or I'll keelhaul ya. ARRR!!!

QUOTE (Norm Kirchner @ Sep 10 2008, 12:24 PM) I don't think anyone's really being all that critical of it. It takes what seems to be a pretty hard problem and comes up with generally fairly reasonable layouts. I think it's interesting to consider, though, that the tool will always be the product of a few developers' ideas of "good style," boiled down to a set of heuristics. NI has done a really good job on it, but that doesn't mean it's not interesting to look at the cases where it comes up short anyway. And FWIW, I'm actually kind of impressed by how little it modified the examples above . You can kind of see by the changes it makes how it weights different nodes and different wiring patterns. For the sake of argument, though, the handling of free labels is really inconvenient. For the large number of us who use free labels to label our wires, we either have to change our workflow to do the labels after a cleanup (which means they're not labeled during initial development ), or resign ourselves to replacing them all the time , or just never use the Magic Fingers . For such a banner feature that it got airtime at an NIWeek keynote, that's a bit disappointing, and that's not its only shortcoming. I still think it's pretty clever, and reasonably well executed, and a godsend for a large number of LabVIEW developers. But the problem it's trying to solve is fundamentally pretty hard.

Instead of calling the Block Diagram Cleanup "The One True Tool," I think I'm going to call it "The Magic Fingers."

QUOTE (Aristos Queue @ Sep 10 2008, 05:23 AM) Good point. I didn't change any of the default settings. This is fresh-from-the-shrinkwrap behavior.

For fun (and inspired by our other discussion), I decided to apply the Block Diagram Cleanup Tool to several examples from the 99 Bottles of Beer thread from a while back. I picked 3 VIs from that thread to run the tool on. I didn't pick these for any particular reason, other than that they're all reasonably different from each other. I opened them in LV86, took a "before" screenshot, then ran the Cleanup Tool and took a "after" screenshot. I didn't do any cleanup of the "after" code, other than that I removed some free text labels (which had been scattered to the wilderness areas of the diagram, because we already know those aren't handled well). On balance, I think the Cleanup Tool generally made these VIs worse in terms of readability, particularly near the Format Into String primitives. At the very least, I don't think it improved them much, if at all. And while these are non-trivial VIs, they're not terribly complicated. So what's the deal? Were these VIs just pretty "clean" to begin with? What do y'all think? Aristos Queue BEFORE AFTER Orko BEFORE AFTER Justin Goeres BEFORE AFTER

QUOTE (Aristos Queue @ Sep 9 2008, 02:59 PM) But Darren was also coding an exceedingly simple VI. I've tried to use The One True Tool on other VIs that are really still pretty simple (inputs: a couple of LVOOP objects, maybe a DBL and an error cluster; outputs: an LVOOP object & error cluster) but that include a couple nested cases or loops with shift registers, and it makes some really eyebrow-raising decisions due to its obsession with the error wire. Generally I'm a big fan of straight error wires, but except in the simplest VIs, it really makes odd decisions. Also, I tend to arrange my block diagram terminals so they roughly match the connector pane of the VI (not by distance, just by top-to-bottom order on the left & right sides of the diagram). The block diagram cleanup tool does not share this preference, which puts it strongly at odds with a key personal aesthetic. So are the diagrams cleaner? Sometimes. Are they more useful and easier to understand as I drill down through a chain of subVIs? Usually not . Now, that having been said, I think it's a great tool for people who don't already have a decade of personal style worn into the faux-woodgrain of their desks. It gives them a chance to see what their code would look like, if it were reasonably clean, and that's a big step forward. The cleanup performs so well on simple VIs, in fact, that I can see Quick Drop as being something that encourages users to write not cleaner diagrams, but simpler diagrams. And that's good for everybody :thumbup: . QUOTE It's below my standards for a clean diagram, but not by much. We shall see how this goes in the future, but it would not surprise me to see, over time, LV style end up matching what the code clean up tool creates. As layout quality improves, I think that many programmers will decide to let the tool handle the layout rather than nudging nodes pixel by pixel. I think that this could be true, but it will require NI to put real effort into refining and continuing to develop the block diagram cleanup. It's pretty surprisingly good for just having come out of the gate, but I'm afraid it could be seen by NI as "good enough" and just allowed to languish. Or worse, NI could devote more resources to it in lieu of fixing other, worse problems in LabVIEW, and leave us all with shiny, clean, lickable block diagrams that still don't do what we want .

You forgot one. Newcomer Accepted to KinderGarden Primary school student Secondary school student High school student Freshman Sophomore Junior Senior Graduate Postdoc (PhD) Adjunct Professor Associate Professor Professor Professor Emeritus alfa

QUOTE (HChandler @ Sep 5 2008, 08:58 AM) You have all the control you need. But like Yair said, the problem stems (mostly) from the fact that LabVIEW can't simultaneously have 2 VIs in memory with the same (qualified) name. This takes some getting used to, but honestly, for the most part you're feeling helpless right now because you don't yet know how to use the tools that are in front of you. Everyone goes through that at some point, with every new language. QUOTE Admittedly, I'm a babe in the woods when it comes to LV development, and I should have laid a better foundation. Still, I would much rather deal with a Makefile than the interminable dialogs and "stuff being done because it was programmed that way by someone who's assumed (and you know what that means) that everyone is on the same page with regard to programming style. And I would much rather deal with LabVIEW's project windows, VI hierarchy, and linking behaviors than cryptic Makefiles and 10 pages of compiler warnings/errors. It's all a function of what toolset you're used to working with, and the discomfort you feel when you move to a different workbench. QUOTE Or should I say styles. Like everything in labview, I've got a million ways to screw myself over. I've got the project, llbs, lvibs, all of that OO stuff, project folders (auto populating and virtual). I have very little determinism. Too much gets done for you, and in ways that you might not want to have happen. Actually, it's generally very deterministic. Unless you're misusing the word? That having been said, I can sympathize with you. LabVIEW is pretty aggressive about the way it tries to resolve subVI linkages, and even though the dialogs and warnings you get are a lot more helpful than they used to be (there was a time when there were no cross-linking messages -- it just happened invisibly!), as a novice user it's hard to understand when you've gotten yourself into a ditch until you've driven several miles in it.

I just discovered Zoë Keating today and immediately liked her stuff well enough to buy her album from iTunes (or, if you prefer, Amazon's MP3 Store, or even the old-fashioned way). As described by a post on BoingBoing: QUOTE So I was looking at my block diagrams, and thinking, "Apocalyptic landscapes? Sounds about right...." Or maybe I have a thing for cellists with dreadlocks? QUOTE (crelf @ Sep 3 2008, 06:47 AM) I agree that The Internet has become something that should be personified I'll let it be the judge of that.

QUOTE (Ed Dickens @ Sep 3 2008, 08:56 AM) NOSe LoGBooK? NOrm'S LonG BeaK?

QUOTE (Yair @ Sep 2 2008, 09:07 AM) I love that The Internet gives us things like this.

via Flickr

That's funny because it's almost plausible .