Jump to content

Black Pearl

Members
  • Content Count

    410
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Black Pearl

  1. 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
  2. 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
  3. 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
  4. I really like that piece of code. But harlequinade as user name sounds like a softdrink. Sorry, got addicted from lulz. Felix
  5. 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
  6. 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 p
  7. 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 f
  8. 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 u
  9. 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
  10. 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
  11. Seems like it's only supporting class diagrams. Especially for LV I think stateDiagrams are important. Felix
  12. 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
  13. That was a pretty cool posting for #5k! Felix
  14. 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 aroun
  15. Well, check the enternal 'being' of a *.vipc Felix
  16. 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
  17. You could post to the dark side: 'Urgent - Plz hlp - I have got 24h for this homework assignment: ...' Felix
  18. 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 th
  19. 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
  20. 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
  21. 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
  22. What about using a second application instance? I haven't done this, so I'm not sure how easy this would be. But then the 2nd App.Instance would crash and your main App.Instance would get errors when calling it, which you can deal with (recover). Felix
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.