Val Brown
-
Posts
754 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Val Brown
-
-
-
-
QUOTE (Tomi Maila @ May 18 2008, 10:05 PM)
I guess the problem is that you have added folders to repository that already were part of other repository. A single file can only belong to one repository.What I sugges you do is
1) Go to your local folder where your files under souce code control reside
2) From TortoiseSVN right click menu select export to get a clean copy of your code
3) Create a new local repository (or remove all the files from the old repository)
4) Add your exported code to the new repository
5) Subscribe to this new repository
I'm actually starting "fresh" (nothing of mine under SCC) but apparently there were still some legacy .svn folders in one portion of the code. That dates from my use of a consultant who used SVN. I thought I had cleared out ALL of the prior .svn folders (so no more repository references) but I apparently missed a couple in the process.
-
QUOTE (tcplomp @ May 18 2008, 08:34 PM)
I'll try your suggestions and see what happens.
QUOTE (Val Brown @ May 18 2008, 08:45 PM)
The folders were clean -- ie the .svn folder in them were all removed. I use TC as well for things like this.I'll try your suggestions and see what happens.No this makes no difference. I'm really tired of trying to get this setup and to keep having this kind of problem occur. It may be that SVN works well for a lot of other people but it really has been disappointing for me.
It seems to me like the only option I have to uninstall SVN, brute force delete ALL of .svn folders that have been created during this process and then start all over again.
-
OK, I followed the instructions posted by Jim (thanks Jim) for a "lone gunman" developer and got my repository started on my local drive, added in my project and then began adding in folders and separate VIs. Mostly it has gone well EXCEPT for the files that seem to reference (well attempt to reference) a prior network repository. I've even removed that reference in repo-browser, tried "Clean Up", tried to SVN Delete the offending files and STILL I get the same error when the commit tries to send it to the networked repository.
How can I correct this?
-
QUOTE (gmart @ May 18 2008, 09:48 AM)
I probably wasn't clear since I didn't know what you meant by "my own functions". What I meant is that the Tools>>Source Control>>Refresh menu calls into the currently configured SCC provider. So yes, it would work for both VSS and SVN. What I should've said is that the menu is independent of any custom tools that you may have developed (see below).The palette VIs are not linked to the functionality of the Tools menu. So if you check in/out via the palette SCC VIs, you will need to manually refresh the project you are working within. It was a design decision to keep the palette VIs and the integration behavior separate.
I don't believe there is one VI that will do the refresh by itself. The code is part of the SCC code that works from the project. As far as that method goes, it won't return what you are looking for. I'm not even sure if it will work right since it's not a public method. Let's put it this way, I don't use it
I'm not intending to hijack this thread -- and this does seem to be related to the issues at hand -- can we get a list of pros and cons of using the toolkit to bring SVN into LV?
-
QUOTE (Jim Kring @ May 16 2008, 06:02 PM)
OK, thanks. BTW, was there a follow up article?
-
QUOTE (Aristos Queue @ May 16 2008, 03:15 PM)
Your article does not specify what LabVIEW version can create these corruptions. There were two corruptions known in LV8.2, both of which were fixed in 8.2.1. There was one corruption associated with 8.5 that was fixed in 8.5.1. I do not have any open bug reports of any corruptions since then.Please edit your article to specify which versions of LabVIEW are capable of creating these corruptions so that future readers don't continue to wonder if these are issues. It's irresponsible, in my opinion, to post an article such as this one without providing the version information. This article will still be available for reading -- and thus indexed by search engines -- years from now. Without a version number, this article becomes a source of FUD.
Your article opens with "a recent post on LAVA made me realize that this may still be useful." I'd just like to point out that the recent post on LAVA that you cited explicitly mentions that, no, he is not using LV Classes. If you know of any way by which the project and or class files can become corrupted that is not addressed by LV8.5.1, please report them ASAP so they can be fixed.
My SR is still open. Also if you (and the rest of JKI??) continue to use Subserversion, do you have any specific recommendations about setting it up for a single developer (yes, like me), working on a single computer (largely) using external HDs for backup (yes three in all) and needing to remain mobile, etc so NOT wanting to have an external server as part of the solution?
BTW, I do have an external server that is available but, ok call me old school, I don't like the security issues of having to network over the internet to have access to a repository. I would much prefer something that allowed me to keep the external HDs.
-
QUOTE (Tomi Maila @ May 14 2008, 11:23 AM)
Val, what way do your lvproj files get corrupted? The project files are xml files and are rather easy to edit with a text or XML editor such as freely available Microsoft XML Notepad. One thing you can try to do is to remove the "items in memory" section from the lvproj file or if that doesn't help then all the dependencies.ps Are you using LV Classes?
Tomi
Thanks for the reply. I can't say precisely in what way they're getting corrupted. All I know is that I go to open the project (either double-clicking on its icon or starting up LV and then using File/Open...) and I get back the message that the project file is corrupted. Yes, I'm aware that they are XML and I can certainly open them even in regular Notepad but I didn't want to do any particular editing as I wasn't at all clear what to change. I'll give a try to removing the items in memory section.
No, I'm not using LV Classes.
-
I have my 8.5.1 lvproj files getting corrupted frequently. Now I am using XP under Fusion but I don't understand how that's impacting this directly. Normal shutdowns and such -- no system crashes -- but still at times (that I can't even predict) the lvproj file gets corrupted.
So two questions:
1. Anyone else seeing similar behavior and, if so, what seems to precipitate or ameliorate it?
2. Anyone know of any way to fix a corrupt 8.5.1 lvproj file?
-
QUOTE (Aristos Queue @ Apr 20 2008, 03:18 PM)
And now, if you'll excuse me, irony of ironies, I have to get back to writing a report for LV marketing on "how to talk about LV when you're talking to computer scientists". There have been some problems with this. :-)Yes, even though reading and writing STD i/o is pretty direct (esp for an old line Unix hack like me) method for "getting attention", the biggest challenge in "real" programming is generally the GUI -- ie how do you maximally reach and interact with the intended audience/users. No matter how you slice it "dos app" has a very specific connotation and that isn't just "pipeline" or even "standalone" necessarily.
Let me say this all another way. Yes, the big advantage of LV is that no CS background is needed, even for complicated applications. The big problem with many other languages is, CS background is required, even for trivial tasks. This creates an asymmetry that IME frequently lays heavily on the hearts and minds of those with CS backgrounds. FWIW, having started with text-based programming "back in the day" it still seems pretty silly to me that many consider text-based languages to be the "ideal" and LV becomes seen as a "toy" or "incomplete", etc.
I think that, if the original post had called about a STD i/o based pipeline/standalone, it would have been a lot easier to have actually had a conversation.
Now I think I'll go over to an MSDN forum and ask about how to drop an LV event structure into the VS IDE by a straight "drag and drop" of its icon. After all, that IDE handles "by-ref" constructs doesn't it?
-
QUOTE (Omar Mussa @ Apr 18 2008, 06:20 PM)
I just figured out that 8.5.1 does not really exist -- it is only in your minds.http://lavag.org/old_files/monthly_04_2008/post-5746-1208571585.png' target="_blank">
Check the LabVIEW.exe version number yourself.
Looks like a rounding error to me.
-
QUOTE (sachsm @ Apr 17 2008, 04:21 PM)
If you monitor them one at a time (assuming different electrode placement) then a common EMG/ECG amplifier would work assuming you could adjust input filteringindividually for each case.
...or use a JTFA based detection scheme since both have differing signals in the time-frequency domain.
-
QUOTE (Jim Kring @ Apr 16 2008, 12:49 PM)
I upgraded early last week and haven't have any problems. I've used it in several projects and found that it fixed a build issue we were having in one of them (related to locked libraries).I downloaded it -- had to wait just a bit for the NI activation process to come online -- but I've had no problems at all with 8.5.1.
-
QUOTE (Val Brown @ Apr 5 2008, 10:20 AM)
Yes that's how it appears. I'm just like the guy waiting by the microwave saying it takes TOO long....BTW is there a separate update for the SCM? I found a patch for the SCM to download but not a separate update.
OK, so I'm activated now (gosh had to wait a whole 12 hours!!!)
Haven't yet checked out SCM.
-
QUOTE (Aristos Queue @ Apr 5 2008, 07:34 AM)
8.5.1 went live on the web sooner than a lot of groups expected. Have a bit of patience -- everything should be linked (such as the bug page and the activation stuff) on Monday.Yes that's how it appears. I'm just like the guy waiting by the microwave saying it takes TOO long....
BTW is there a separate update for the SCM? I found a patch for the SCM to download but not a separate update.
-
It just gets "curiouser and curiouser" -- now the NI Activation process is failing. It appears that some parts of NI.COM are "under repair" and the Activation Center is one of them.
-
QUOTE (TobyD @ Apr 4 2008, 03:23 PM)
Hmmmm you may be right and I may be conflating those two ideas. No wonder no one can say anything!
-
QUOTE (Darren @ Apr 4 2008, 02:20 PM)
I don't think any discussion of beta software (including the topic of having been a beta tester) is allowed outside the private NI channels.-D
So I understand that being the case DURING the beta program but presumably the actual release is at least as good as the beta and the "good" experiences of that could perhaps be posted just to say things like, yes I really liked...
-
-
QUOTE (Jim Kring @ Apr 4 2008, 09:38 AM)
What are your impressions of it?
-
QUOTE (Norm Kirchner @ Apr 1 2008, 12:48 PM)
I attended a few sessions @ NI week regarding vista and where to put your files.You DEFINITELY should find them on NI's site, and from the information that I can recall, it will give you exactly what you're looking for.
Yes, there were some good presentations and discussions there.
FWIW, I've taken a brute-force approach and just created my own APPPATH: viz, c:\companyname\... with subs under it including ..\common files where I post config info and such. It ain't "standard practice" but it definitely works and gives me the exact same location whether in Vista or XP.
-
QUOTE (Aristos Queue @ Mar 31 2008, 11:11 AM)
...dropping the Request Deallocation primitive onto the diagram <...> can reduce the amount of memory that LV uses at any one time, but that generally results in really bad performance characteristics.Can you say a little bit more about this: ie, in what way will using Request Deallocation degrade performance? If there are any good KBs or other resources re: this, could you post some here?
-
I'm going to offer a bit of a different perspective here and it's offered just FWIW.
There are several issues/threads involved here.
1. Can LabViEW be used for such a project -- and the answer to that is: obviously yes.
2. Is LabVIEW the "best" choice for such a project -- that's more difficult to answer unless we agree on the criteria for "best" but, FWIW, I'd say LV is better for such a project than most other languages other factors being roughly equivalent.
3. Can one learn LF while doing such a project -- Yes, of course that's possible; moreover, what's interesting about that question IMO is its converse: viz, can one learn C++ <or name your favorite language> while doing such a project? I think that answer to that is -- almost undoubtedly no, again other factors being roughly equivalent.
4. What role does prior experience with other languages and similar projects (in terms of scope and such) play in determining how easily one could learn LV while programming such a project? Here's the really tough one IMO. I think it all depends on what your specific prior experience was, how well you follow the general guidelines on modularizing code etc, and how much comfort you have in stretching into a new paradigm while coding an active project?
Depending on your timeframe, budget and personal predilections I would suggest considering this to be an ideal opportunity to really learn ABOUT programming in LV -- but only as long as that doesn't compromise the commitments you have to the ultimate customers of the project. Yes, your code won't be "ideal" -- how could it be? Of course it won't be as easy to rescale later -- how could it be? But would it be scaleable, maintainable, and extensible -- YES, if you follow the guideline of something like the LaVIEW Style Book (some title like that) from Blume, or the LabVIEW style documents.
FWIW I think the most fundamental question for you (or it would be were I in your shoes) is: How best can I reasonably serve my clients while also developing my skill base and developing code which will be allow for the big 3 (scaling, maintaining, extending) in the future? LV is, IMO, a much better solution for the long-term than any other language I know BUT your clients deserve your primary commitment.
OK so that's probably more than 2 cents but it's likely worth less than 2 cents...
Alfa String
in LAVA Lounge
Posted
QUOTE (FLAnatic @ Jun 13 2008, 07:42 AM)
It isn't even that Einstein is more accurate per se -- it's more complete. The difference is that Einstein's model reduces down to Newtonian mechanics when the "special" conditions of classical mechanics apply, for instance when not traveling near the speed of light or near a gravity well, etc.