Jump to content

joerghampel

Members
  • Content Count

    30
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by joerghampel

  1. I've only seen/used TOML for GitLab CI's gitlab-runner configuration (i.e. not in LabVIEW)...
  2. 1. What type of source control software you are using? Git on GitLab with Git Fork or Git Tower 2. You love it, or hate it? LOVE it!! 3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else We get to choose, and git is the scc system of our choice. 4. Pro's and Con's of the source control you are using? Pro: Decentralised, very popular (i.e. many teams use it), very flexible, very fast, feature branches, tagging, ... Con: Complicated to set up if using SSH, Exotic use cases/situatio
  3. I wrote a blog post about separating compiled code a while ago, it might be interesting for you: https://www.hampel-soft.com/blog/separate-compiled-code-from-source/
  4. For those of you interested in exploring CI/CD with git (and especially with GitLab), please take 5 minutes to visit our Release Automation Tools for LabVIEW website. At the very least, you'll get an impression of (and maybe some inspiration through) what we've been doing for ourselves and for some of our customers for quite some time now. A ready-made solution might save you a lot of development time. If you want more details, I can share recordings of webinars we did a while back. I'd also be happy to show you around myself, too. Spoiler(?) alert: This is a commercial tool.
  5. +1 for allowing GitHub as a GPM repo (and GitLab, too). I watched Derek's CLA Summit presentation on What's new in GPM and was intrigued by the local/private repositories! Don't get me wrong, we already share our own libs and might also do so via GPM, but this makes it probably viable to use it for our customer projects. I will definitely have a play with it in the holidays (and am looking forward to it 🙂 )
  6. Yes, I was quite excited about that! But last time I checked, there was no way for private or local repositories. Is that still the case? Thanks for rephrasing. Yes, I think this is what I'm saying.
  7. The second discussion started - again, with Fab - after James' and my presentation on Open Source and Inner Source with LabVIEW. With Github, for example, it seems rather easy to a) publish an open source project and b) contribute to it, once you've learned the very few steps needed to fork a repo and create a pull request. I have no idea how that aligns with what you guys have in mind, but it would be great if there was a way to combine the ease of use of existing platforms with a central repository of LabVIEW code and tools greatness.
  8. The first discussion with Fab, Dani and Jerzy Kocerka was about where to keep the code. We quickly came to the conclusion that it would be great if GCentral did not host their own repositories on their own servers, but rather was able to tap into existing services like Github, Gitlab, Bitbucket and so on. That might also help with acceptance. Personally, I would like to keep our code in our own repos at gitlab.com. We have our readme's, our documentation platform, etc etc. But if there was an easy way to plug into the GCentral website of available code, I'd love to register our offerings
  9. As a community member just wanting to drop my thoughts and ideas for further discussion, I want to give my feedback in a more colloquial way (hence I created this thread).
  10. After discussing with some of the GCentral team and other community members at NIDays Europe in Munich yesterday, I would like to give feedback here so you guys can make of it what you will. Frankly, I didn't really understand that the "User Personas and User Stories" thread is meant for that - I wouldn't have looked into it if Fab had not pointed me towards it. I would like to suggest to rephrase the title of the feedback thread to something that is more easily understood by the majority of people, not only by the top notch of LabVIEW software developers. Moreover, I don't feel co
  11. To ensure NIER collects the most useful information, you need to set a few INI keys on the process that is executing the LabVIEW code (Development System: LabVIEW.ini in the LabVIEW directory; Run-Time Engine: in a [LVRT] section within the .ini file next to the executable). INI keys: NIERDumpType=full LVdebugKeys=True DWarnDialog=True DPrintfLogging=True promoteDWarnInternals=True Of these keys, you should always set the NIERDumpType=full key when debugging an issue, because this key will cause a larger crash dump with more debugging information to be created. The other INI keys c
  12. I've been using ADO.NET in the last years for Windows applications, and the NI DCT before that. I did one project on RT with the MySQL TCP connector, but as mentioned by @smithd it was difficult getting it to perform well enough. Recently, I've been working with SQLite (with your toolkit as well as directly using the DLL). Next will be to try and get SQLite running on real-time, on linux first, then Phar Lap and perhaps VxWorks - again like @smithd ;-)
  13. I'm using git, but all of my customers who go with SVN use the Tortoise SVN client and are happy with it.
  14. Good point, Shaun. In fact, SingleBoard-RIOs made me think about generating a readme file, so that I could easily find out about the version of the application when connecting only via FTP.
  15. I agree with everything you write, hoovah. But ;-) Customers tend to copy directories and store and reuse projects from time to time. I don't see any reliable way to clearly identify one VI outside of version control other than writing some kind of identifier or history to the VI (be it block diagram, VI properties, front panel, whatever).
  16. I agree that the version information should be (at least also) stored in the .exe file properties, that's what I do as well. But: There is a good reason to store version info on the block diagram. Everybody can identify the version of the VI itself, not the executable, even if it's not under version control any more. I do have customers that don't use their own version control system, and I have no internet access to use mine. So, what I ended up with, is generating an .exe with my build script at the end of the work day, writing the version info also to the readme textfile (which might or
  17. I create tags for each build. That way, I have "names" for my releases, like for example "v1.2.3". You can easily automate the creation and publishing of tags from within a pre-build VI or a build script. This might help you with naming your installers? I also used to modify the source of a VI to store version information, and sometimes still do (it's an optional part of my build script now). What I like better, and what I do more often now, is create a text file which contains all sorts of information (kind of a readme file for the application). When run from an .exe, I read the version i
  18. True that. Even before LV2014 and this very handy VI... It was the fact that you can't modify the version from the pre-build VI that made me look into automating the whole process.
  19. No need to get jealous. The whole process only works on some of my projects. With our own framework and reuse libraries, there's still some manual work involved, but it gets better all the time... I'm not ready yet to just share the whole code, but you can definitely PM me if you have any specific questions.
  20. LabVIEW 2014 also introduces a VI for editing the build spec version (which was possible before, but not as intuitive): Set Build Specification Version VI
  21. I'm using git, and because of its decentralized nature, there is no one incrementing commit number that I could put into the "build number" field. What I decided to do instead is: Create a tag in the VCS (which is just a named pointer to a commit) which is following the semver notation If building a Windows applicationWrite the tag info into the major / minor / patch fields of the build spec Write the build timestamp into the description field of the build spec If building a source distributionAppend tag label and build timestamp to each VI's description (so it shows up in context help) Auto
  22. I haven't used this VI much myself. I agree that name conflicts are the most obvious reason for wiring an application instance. Also, it probably won't work in the Run-Time Engine. And if you call it from the Tools menu, you might or might not want it to run in that application instance (NI.LV.Dialog). Perhaps someone else with more experience can chime in?
  23. You can read up about application instances here. If you don't wire the terminal, it most probably uses the instance of your calling VI.
  24. \vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi seems to do what you ask for (see screenshot).
  25. With the last post being nearly 5 years old, perhaps someone has found a ways to achieve something like this? I'm using vi.lib\AppBuilder\AB_API_Simple\Build.vi for programmatically building stuff, and I'd really like the possibility to register for a user event, similar to the NI System Configuration Toolkit (vi.lib\nisyscfg\Register User Event.vi). (cross-posted here)
×
×
  • Create New...

Important Information

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