-
Posts
410 -
Joined
-
Last visited
-
Days Won
13
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by Black Pearl
-
[Discuss] UML2LV State Machin Compiler
Black Pearl replied to Black Pearl's topic in Code Repository (Uncertified)
You are welcome. I'll send you a PM so we can discuss this in private. Felix -
Check my post (it's #3). But I didn't supply an argument for it. Felix
-
Using scripting to relink to a different copy of dependencies
Black Pearl replied to Daklu's topic in VI Scripting
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 -
[Discuss] UML2LV State Machin Compiler
Black Pearl replied to Black Pearl's topic in Code Repository (Uncertified)
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 -
Using scripting to relink to a different copy of dependencies
Black Pearl replied to Daklu's topic in VI Scripting
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 -
topics to be covered in a 1hour labview session
Black Pearl replied to Madhav's topic in LabVIEW General
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 -
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
-
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
-
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. Yes, I was thinking about using these hooks to pass the revision number from the SCC to the package. 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). 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 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
-
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
-
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. 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
-
That now makes sense to me. So forget about the rants... 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
-
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