Black Pearl

* Inside the OpenG builder there is a method used to relinke the vi's.

No. It's just saving the vi's with a new name. Must have been somewhere else I've seen this, propably it was the OpenG commander.

Felix

Thanks, I'll play around with Replace (instead of RepNoAttrib) next week.

This is one of the main reasons that I have discontinued to work on this project, as I couldn't make it working in other LV versions.

Felix

Ideas:

* Just use the OpenG builder to create a source distribution.

* Inside the OpenG builder there is a method used to relinke the vi's.

* The OpenG builder prebuild script allows you to change the build specs before the actual build process, so you can add the additional files to the build spec. I guess that VIPM isn't doing it different.

Felix

Assuming they are programmers and assuming you want to impress them.

I'd show them how 'highlight execution' works.

(a) that way they see how these funny pictures form together a sort of code

(b) they see how easy it is to debug an application

In a second step, use highlight execution to demonstrate Ben's suggestion of 'multithreading without thinking'.

Felix

Looking at your process this would mean the reuse user placed vi.lib and user.lib under SCC as well?

See the earlier discussion, the packages are under SCC inside the project and applied (extracted) to the user.lib. The user.lib itself is not managed by SCC.

Felix

And, hey, at least you came out of it with a VI which simulates AN ENTIRE UNIVERSE. That's something, right?

I really like that piece of code.

But harlequinade as user name sounds like a softdrink.

Sorry, got addicted from lulz.

Felix

QSM

Felix

The wire.

Felix

This is a great point. We've played with Hg a little bit at JKI and I've used it on a couple small projects. We're continuing to evaluate it; even if we never switch over to it ourselves we need to understand it for our customers.

Although mercurial is a free software, they offer you very good support. I joined their mailing list for the questions related to managing zip files and got a reply from the support team within 24h.

Felix

Justin, the similarity of our diagrams are not coincidence, it's by design:

1. VIPM is designed for that purpose, so it is designed to fit in that picture

2. My own design is planned on minimizing the effort to switch over once I get my boss convinced that I need better software tools (that'll be the hard job).

Point 2 is why I'm really happy you joined this discussion and want to thank you, because this confirms to me that my architecture is pretty flexible and I'm on the right track. Thank you for this!

To get a bit more abstract in the debate, I really think you should check out the powers of DRCS (distributed revision control systems) like mercurial. What did stunn me most while playing around with hg is the ability to adapt to any architecture with little effort.

So at the first step, I can have my repositories local

In the next step I share repositories via USB thumbdrive to pass (directionally) the project from one developer to the next

In a third step, I migrate this architecture to a central repository on a server.

The migration from step 2 to step 3 is important, as this is a change in topology. The 'after' developer is now not getting the data by push from the 'before' developer' but by pull from the server. Having such a flexebility allows to (by proof of induction) realize complex topologies as well such as presented in Joel Spolskys post on hg.

Hope this helps you to develope VIPM to the next step. It's really easy to install TotoiseHg, create some repositories with minimal data and try out how to manage topologies.

Felix

In the meantime I did bring my scetch to an electronic form: EDIT: See at the end of post.

Another quick note on this. Depending on what you want to do with the information (see my post above where I don't quite understand what that is ), you might be able to do exactly what you want with VIPM's Custom Actions. You can create special VIs that run at pre-/post-build, pre-/post-install, and pre-/post-uninstall time for each package. This gives you a tremendous amount of flexibility in terms of mangling your VIs or various support files exactly the way you want, in an automated way.

Install Actions and Uninstall Actions are available in VIPM Community.

Build Actions are available in VIPM Professional and Enterprise.

Yes, I was thinking about using these hooks to pass the revision number from the SCC to the package.

Correct. I'm not a hardcore mercurial user so I can't comment intelligently on exactly how that would happen, but in SVN, if you had a directory of packages under source code control you'd have to delete the old package and then Commit that change.

SCC is a bit troubling when changing file names or locations. The only problems I had with SVN were related to this (saving a vi in a new location and deleting the old, forced update before commit, merge conflicts ) and I think a fellow developer stopped using SVN for this reason. I found hg to be much more robust in this case (automatically find renames, much nicer to resolve merge conflicts on a file basis).

However, this is another advantage of VIPC files. The VIPC file contains a list of packages (and their versions!) so you can never have the duplicate package problem you're describing. You'd handle your package upgrades this way:

1. Build the new package.
2. Open your existing VIPC file for a given project and drag the new package into it (requires VIPM Pro).
3. Save the VIPC.
4. Commit the modified VIPC file to SCC. Use a commit comment like "Upgraded blackpearl_lib_kraken_tracker.vip to 2.0.1."

This way you're not "adding" or "removing" files from SCC -- you're just updating the package configuration (VIPC file) that you're already tracking.

Ok, now I see another usage of the VIPC format.

Well actually you are just making the replacement of the file intransparent to the SCC.

Back to my older posts. Drawing the distribution scetch again braught back why I was looking at propagating the Changeset ID into the package.

I was mainly thinking about how to know if the project has the same packages that are currently installed in the user.lib. If my analysis is right, this is managed by the VIPM having a config file where it stores the currently installed packages with their version number.

So if I apply the vipc file, it can check this against it's own data base and manage all versioning conflicts.

Felix

In my book Built files do not belong in SCC, for mercurial I excluded the following items from scc:

While above statement is true, the point of view towards the packages changes. For the reuse developer, the packages are 'built files' that should not be placed under SCC.

However the user of the reuse lib (packages) will see them as part of his source, hence place them under SCC.

Felix

Maybe I'm sort of misunderstanding your goals, but in my experience it's not necessary to capture the repository revision inside the package itself. What we typically do at JKI is add a tag, or at least a commit comment, to the source repository (we use SVN) when we build a package. The package itself is versioned, of course (1.0, 1.1, 2.0, etc.) and if we want to know what SVN rev it came from we can look that up in the SVN repository itself. We find that's the easiest way to capture the information, since it's basically one of the core features of any SCC system and doesn't require us to write software. This keeps the package format itself lightweight.

Justin, thank you for the feedback.

My goals aren't really clear, that's why I'm posting here.

(a) I'm still working on the overall architecture. I think I should try to get an electronic drawing of it and post it.

(b) I'm learning/evaluating a lot of new stuff (using mercurial, testing diff-tools, using packages).

But your post has brought something to my attention. If I created a newer version of a package, the file name would change (containing the version).

This is useful when I have a share, so for each package all the versions can reside in a single directory and it's easy for the user to get the correct version.

On the other hand, when I place the packages in the project folder, two issues might arise:

(a) conflicting versions, there are 2 packages of the same library with different versions. This is pretty easy to get by accident, as just deleting the file wouldn't remove it from the repository, so on an update it would be restored.

(b) automatic tracking by the SCC would fail. So I need to use a rename command so it's tracked at what stage the newer package was applied.

Felix

For mercurial there is an option to store zip files uncompressed (should me more efficient):

http://www.selenic.c...l#decode-encode

I'll see if I get that working.

This doesn't work. I contacted the mercurial support and they told me that it's only working if a single file is zipped, not for a complete archive.

Well, apparently Beyond Compare works well, but my trial is running out and its prompting me to buy a key.

Its 30-50 bucks, so its not a ball-breaker, but I look forward to seeing if you come up with an alternative.

Free & OS alternative is WinMerge

Make sure you also download the 7-zip-Plugin.

I'd like too know how it's compared (using user-diff ) to BeyondCompare.

Felix

I don't think I qualify for the 'coolest job', but mine is pretty interesting and fun.

I work part time (30 h) on a permanent position. I really enjoy not having full-time as this gives me a cool time with my daughter and for private LV projects.

I work for a small company, which has the following effects:

* I'm pretty much involved in the complete life-cycle of a project from the initial developement (heavy LV coding) until service visits (maintanance, support) at the customer site.

* It's a nice 'start-up' culture where you have a lot of freedom but also heavy responsibility. I enjoy the freedom but I've experienced others struggeling with the little structure we have. You need to manage yourself.

We are a specialist company delivering high precision measurement setups to the industry. If they can't go with COTS products or know that a certain requirement will be really difficult, they go with us. So work is always full of interesting challanges, and sometimes the developement phase is streched to on-site developement at some big industrial companies. This is interesting because there I see a pretty tightly controlled (managed) enviornment, as opposed to my company.

Also in many situations, the equipement is sited in the secret R&D labs of these companies, where I see the products that won't hit the market for some years (or not at all). Needless to say that I meet some really brilliant/crazy scientists there.

Felix

Seems like it's only supporting class diagrams.

Especially for LV I think stateDiagrams are important.

Felix

FWIW - VIPM uses a VIP format for packages (which is the 'new' OGP format if you like).

VIPC is a file that contains packages (VIP or OGP files).

Seeing that the VIP format is an extension of the OGP I would say is better - i.e. in VIPM 2010 supports non-symbolic installation locations using sub-packages.

That now makes sense to me. So forget about the rants...

I just downloaded Beyond Compare as it can be configured to handle diff's of packages, but it seems you have to pay for it

I also look for a non-commercial way, preferable OS, as this allows to better adjust it to the specific needs of LV.

For mercurial there is an option to store zip files uncompressed (should me more efficient):

http://www.selenic.com/mercurial/hgrc.5.html#decode-encode

I'll see if I get that working.

Felix

That was a pretty cool posting for #5k!

Felix

The original ogp format is brilliant.

My rant was only targetting the vipc format, 'cause it doesn't add a lot of new information and does this in a 'bad' way.

-> Information: The only new things I found was a second icon and inside the config.xml the ID. I guess the ID is used for the features of VIPM enterprise.

-> 'bad' way: In the original ogp the spec file is a config file, hence extendible. So it would have been easy to add the extra information to that as new entries. Then the spec file is duplicated outside the ogp container. All of this is zipped, hence basically a zip around a zip, which isn't really efficient.

Going back to my original work, I get these questions/topics/tasks/ideas:

* Namespacing via OpenG builder? So my reuse project would have under SCC the original code (and the build/package scripts). Then non-SCC a folder for the namespaced vi's and a folder for the created packages. As far as I know, VIPM allows you to do both in a single step (namespacing + packageing).

* Propagating the revision from the repository inside the package. My idea was to add this as extra info (sections) to the spec file or to autogenerate a file that goes into the package and is installed alongside.

* Make the package format transparent to SCC/diff. I found that beyond compare is able to handle .zip and it might be that others diff tools have hooks to unzip the files for them.

Any comments?

Felix

Well, check the enternal 'being' of a *.vipc

Felix

Ok, back to the seriouse side. I've got a tool that checks for every vi that is called by the main vi and isn't sitting in the subfolders down the main. I'll pass them to ogpb (and the install location). done, or not?

Ahh, I see, the IPM has the package list and can track it down to the individual vi... smart. Then it can 'guess' the package and list the oackage in the dependencies. Smart & greate work at JKI.

But still: vipc format is a joke.

Felix

Maaaan, I hate it when they leave it as an exercise for the reader.

You could post to the dark side: 'Urgent - Plz hlp - I have got 24h for this homework assignment: ...'

Felix

Hi,

I'm a theoretical OOPer. My problem is that I'm stuck in 7.1. and really like uml...

So here my therotical 'insights'.

There is a line of developement in other languages as well from the cluster (record, struct) to the class. In this developement of programming languages, different features were added, merged, dismissed as evolution plays. Using a type def, you introduce the class(=*.ctl)/object(=wire) abstraction already. With the Action Engine, we got encapsulation (all data is private) and methods (including accessors). With LVOOP we have inheritance. Still LVOOP isn't supporting things that other languages do since ages (interfaces, abstract classes and methods). But on the other hand it allows for by-val implementation (objects that down have an identity) as well as by-ref.

I severly consider LVOOP unfinished, because it doesn't allow you to draw code the same as you do non-LVOOP code with wires and nodes. It's mainly some trees and config-windows.

But also I don't think the evolution of other OOP languages is not yet finished. See uml, where you only partially describe the system graphically, which means you never can create a compilable code (partially undefined behaviour). Also uml still has a lot of text statements (operations and properties are pure BNF text-statements).

So the merging towards a graphical OOP code is still work in progress.

Let's get practical. On my private project I have to deal with OOP designs (uml/xmi and LV-GObjects). One issue that isn't possible to handle with type def/AE is to represent the inheritance. Let's say I want to deal with control (parent), numeric control (child) and string control (child) and have some methods to serialize them to disk.

For a generic approach I started using variants. The classID (string) is changed to a variant. All properties I read from the Property nodes are placed as Variant attributes. This can even be nested, e.g. for dealing with lables (the get serialized as decoration.text as an object of their own and the set as attribute). Wow, I have compositions!

Well, I lose all compile time safety. But I wonder what I'd get when combining it with AEs and some 'plugin' way to get dynamic dispatch.

Ahh, wasn't C++ written with C?

Felix

Well thats your call - but with a callout like that you know we are all expecting you to post the tool to LAVA within 24 hrs (I have started the countdown already)

Sorry, but to boring...

Actually, my file manager plainly told me what a vipc file is. I leave this to the readers to 'hack' on their own. In the end you have little more than you already get from OpenG Package Builder.

Well, this 'little' prevents me from creating vipc files (I'm not sure if this was intended by JKI), but since ogp's install the same way I don't care.

So back to the big picture of reuse. It's not done with creating a reuse library, but you need to make it damn easy for others to use the reuse library. That's where the team at JKI did put in all the effort for VIPM (which I think is worth the money). That's why I want my vi's in the palette (see earlier in this discussion).

So I better invest my time on thinking: how can I make it easy for my team to use the reuse lib, what are individual concerns, habits and dreams on code reuse. For the installation of reuse code on the developement machines, VIPM community will be the best, because it's professional looking and easy to use.

Creating snapshots, I think about a simple wrapper around the OpenG package builder's core, that just displays a small dialog: 'All your vi's from the reusable library are sucessfully added to your repository. Do you want to see the details? -> NO'.

On the other hand, I think it's easy to create a small 'Installer' (there used to be a 'OpenG Commander' which was the predecessor of VIPM, so propably most code is already written). Then I can just get the snapshot in the user.lib/.. for field testing without the need to install LV2009-RT and VIPM.

Felix

jgcode, is this a manual process relying on the discipline of the developer? So after update, do apply the vipc. Before commit, capture a snapshot?

After all, the vipc format isn't really complicated. So I should be able to write my own snapshot tool in a day...

Felix

Ok, as expected, there wasn't any issues using VIPM 2010 to install the *.ogp on 7.1.

So the remaining question is, how to ensure the packages in the project are in sync with the packages installed in the LabVIEW folder. I see two possible sources of corruption:

* I use a different (newer) version of my user.lib/subPackage and forget to update the packages in the project

* I use a completely new package and forget to update the project

both sadly would corrupt the repository.

Any 'best practices' or even preferred automation options to deal with this?

Felix