Jim Kring

I'll ping Rolf K (main developer of the OpenG Zip Library) to see how much work this would take and if he has time.

Congrat's, Sergey!

No, it's a new LabVIEW installation and I've just been too lazy to go into the options dialog to change the settings.

Here is a link to the idea: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-Insensitive-Comparison-Mode-for-String-Equality-Comparison/idi-p/1121574#A5477 Thanks for checking this out.

I would argue that it shouldn't be cached, by default. Almost. Only as long as there are no dynamic calls in the call chain -- there is the possibility that dynamic calls using VI Server CBR nodes could cause the same WaR bug to appear. The difference between a bug and a feature can be debate without end. I don't want this performance "feature", because it causes a "bug" in my code. Since this constraint is not published, I feel it's a bug. Dynamic dispatch VIs cannot be set to preallocated reentrancy -- it will cause them to be broken. I would argue that if there's a use case for a performance improvement whose implementation has constraints on modes of use, that this be made an optional, Boolean argument (named something like: reuse messaging queues for minor performance boost). Cheers,

Could be... my memory queue is used in a lossy mode, occasionally

Here are my thoughts on why the internal notifier queues are going invalid. 1) The internal notifier queues are created inside WaR 1.1) WaR is reentrant. 2) WaR is called inside a reentrant Dynamic Dispatch Method VI 2.1) Reentrant Dynamic Dispatch VIs must use the Share clones between instances setting. 3) the reentrant Dynamic Dispatch Method VI is called inside several asynchronously running top-level VIs. The problem is basically that specific instances of WaR are being called inside the call chains of several different top-level VIs. So, there's no way to gaurantee which call chain the cached internal notifier queue was created within (thus binding the queue's lifetime to the lifetime of the top-level VI). Bottom line: never, ever cache a reference inside the shift register of a reentrant VI which is the creator of the reference. There is no way to gaurantee that such a VI won't be called by a reentrant Dynamic Dispatch Method VI from multiple asynchronously running top-level VIs. Now, in defense of whoever designed the refactored (with queues) Rendezvous, Dynamic Dispatch Method VIs didn't exist back in the 8.0 days (which is about the time when the Rendezvous, Semaphores, etc. were refactored with Queues, if memory serves me right).

I got some CAR numbers from NI: CAR 222274, 222275 and 222276 respectively

I've posted a list of various bugs in the Rendezvous VIs (the root bug caused a couple other bugs to show up) on the NI forums, here: http://forums.ni.com/ni/board/message?board.id=170&message.id=492924

CVS is built on top of RCS, BTW.

It's a FLA Hi All, Thanks, everyone, for your recommendations of VIPM. As you know, JKI has put a lot of energy into the tool and we plan to put a lot more effort into it in the future. In fact, we're actively working on VIPM 2010, right now, which will provide a lot of powerful and flexible packaging features that make it the best choice for creating distributions of LabVIEW reuse libraries and add-ons. We'll will be blogging about some of the new features we're working on soon, too. If you have specific questions for JKI or want to evaluate VIPM Professional/Enterprise, please contact us. We're more than happy to chat with you. Thanks, -Jim

Hi Jason, I actually haven't played with the new merge tracking features in subversion 1.5 -- it's on my list, too. I figured I'd check out Mercurial first, to see about whether to jump to the next curve (Hg) rather than just taking an incremental step forward (svn 1.5). Plus, we use FogBugz as our bug tracker at JKI and Mercurial is part of the Kiln product companion to FogBugz -- so, it probably wouldn't be a difficult jump. -Jim

I've been doing a little more light research, but still haven't had a chance to dive in head-first. I've found a great resource: Hg Init: a Mercurial Tutorial by Joel Spolskey. The first section, Subversion Re-education, is inspiring and makes me want to move forward. However, I worry a lot about the fact that Mercurial keeps a copy of every revision (binary delta's it seems, thankfully) of every file in the repository on every developers machine. Since LabVIEW files are binary, this means that the repository might grow very large. The recommended strategy is to use a new repository for every project, rather than one big repository for all projects. However, it seems to me that as time goes by projects that have lots of binary (LabVIEW) files might grow very large and have many revisions, which will be too big a burden for developers. That said, there's no better answer than testing it out on a real (hopefully, low-risk) project and seeing how it goes...

You can find it here: https://lumen.ni.com/nicif/us/evallvmaint/content.xhtml Cheers,

Very cool!

What I mean is that SVN does not keep track of what's been already merged between branches. This makes it nearly impossible to maintain multiple branches (feature branches, developer branches, maintenance branches) and merge between them. Yes, I'm curious too. I think that LabVIEW's diff and merge support, while very nice to have, are still lacking. I would like to see them improved such that they could handle merging between two hierarchies of VIs (in memory concurrently), rather than just between two individual VIs. Cheers,

Ya, I've read those links too. I'll be curious to hear what people think after using LabVIEW with Mercurial. Regarding the SCC API, the other problem with it, IMO, is that the API assumes a locking (check out / check in) model, which doesn't really fit well with concurrent access (commit and merge) models. Cool! I look forward to hearing your results. I'm going to try to find some opportunities to play around with it, too. Thanks,

Has anyone used Mercurial for source code control in LabVIEW? It looks like it might be the next step in the evolution: CVS ==> SVN ==> something that can merge/branch worth a damn. Cheers,

You can learn more about my feature suggestion and show your support by giving it your kudos/votes on the LabVIEW Idea Exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Saved-Searches-and-Results/idi-p/1068144 Thanks!

I dugg it!

You can learn more about my feature suggestion and show your support by giving it your kudos/votes on the LabVIEW Idea Exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Support-for-Additional-3rd-Party-Installers-when-building-an/idi-p/1065737#A4036 Thanks!

Yep, and he's recently moved his family from Austin, TX to Hollywood, CA. He still does some LabVIEW consulting work. Ya, that's pretty accurate Jeff did a whole lot of work on the 3rd edition. I did an unimaginable amount of work. I don't have to tell you, crelf, about that Thanks for the kind words and the recommendations. I assumed you were having some fun Cheers