Jump to content

Antoine Chalons

Members
  • Posts

    836
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by Antoine Chalons

  1. This is great! Just in case we are thousands of LV users silently wishing for native TOML support : https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-native-support-for-TOML-file-format/idi-p/4136157
  2. I see. Well it's great that you created it and shared it on GitHub. The tree display is also a nice feature. Now.. If jsontext gets support for comments and LabVIEW objects, it will be a no brainner.
  3. Sounds great. I've seen you're also working issue 56, which would be another big advantage of jsontext over the TOML library.
  4. Intersting, have you considered submitting your bug-fixes on the github repo? Also, have you implemented support for path? or do you just use strings?
  5. Hi all, A customer is pushing us towards using TOML file for app configuration. So far we're using json - thanks to jsontext from JDP Science - and we're happy with it. I've been testing the MIT-Licensed TOML library available here, but in term of features it's far behind jsontext. The cool thing with TOML - really cool - is the support for comments. So just out of curiosity, has anyone ever tried to use TOML?
  6. Sorry for the lack of clarity, what I meant by threadsafe CLFN is this : therefore : reentrant As opposed to non-threadsafe CLFN : therefore : not reentrant. In my applications I don't need reentrancy for my libpq calls, but as I was trying to make this package as generic as possible. Yes I've tested step by step and running the same simple thing : PQconnect / PQfinish crashes when CLFNs are reentrant, not at the PQconnect though, at the PQfinish. The data base that I try to access does exist and the settings in the string are correct. The result is the same wether this VI is set as reentrant or not. Ok, I'm fealing cheated. If I understand correctly it means NI's libpq.so pretends to be threadsafe but actually isn't.
  7. I've opened a support request with NI because on NI Linux RT, calling libpq.so with a threadsafe CLFN crashes LabVIEW while calling it with a non-threadsafe CLFN works fine. Funny enough, the only exception I've found to this is using a threadsafe CLFN calling "PQisthreadsafe" with a threadsafe CLFN, calling any other function triggers a crash.
  8. Running on Linux RT with the libpq.so compiled by NI : so they did build the library as thread safe and I get the same on Windows with the libpq dll deployed with the VIP.
  9. I've just pushed new branch to Dr Powell's repo, and built a new version of this package. I used LabVIEW 2017 SP1. What's new : added support for Linux Rt targets (possibly Linux in general but not tested) (issue #1) added support for boolean parameter (issue #2) fix a weakness in parameter detection (issue #3) VIP 0.2.2-b16 can be downloaded from here.
  10. 😮 How many of these are use to control the Large Hadron Collider ? 😄
  11. Very true!! I do use nested combinations of set and map - not hugely deep but it does turn out to be very useful. And yes it might not be trivial to handle ALL possible cases. But let's engineer ambitiously, no?
  12. Would it be possible to add support for maps / sets - as if they were arrays - ? I can really remember if they were added in LV 17 or 18 or 19....
  13. Do you have access to any hardware? "Technical task" is a bit vague... A few years ago I started playing around with https://projecteuler.net/ It was a fun way to practice algorithms with LabVIEW, I think I solved the first 50 or 60. I'm not sure if this is "technical" Any idea on what you like to do? Any special interest? What's your course?
  14. Welcome! What you're looking for is called a shift register : https://www.ni.com/getting-started/labview-basics/shift-registers
  15. You can run multiple instances of the same LabVIEW version by adding the following key in your LabVIEW.ini file AllowMultipleInstances=True I have never tried to have more than one L Instance running the application builder at the same time... Now that I think of if it, I've never even tried to use an instance for coding while another instance is compiling. LabVIEW crashes so well without trying all that... I rarely run multiple instances at the same time anyway. The alternative I can suggest is to use a dedicated build machine (virtual or not depending on you IT infrastructure)
  16. I've just installed the whole LV2020 SP1 env and updated my IC-3173, and now I can't reproduce these issues.
  17. Bug described on NI Forum : https://forums.ni.com/t5/LabVIEW/Map-weirdness-on-Linux-RT/td-p/4114641 With video and code. I would be eternally thankful if anyone could try to reproduce on various Linux RT targets with LabVIEW 2020.
  18. I'm confused... what is the connection between SQLite and PostgreSQL?
  19. Here is a nice one, see my post on NI Forums found in LV2019 SP1, if someone could check LV2020, it would be nice.
  20. My informations from inside NI is that this is largely untrue. NXG team will be re-assigned to other projects and a large part focusing on non-Windows OS support 😮 I don't have much details but different sources corroborate this.
  21. Here is the best I could find : https://forums.ni.com/t5/LabVIEW/Isn-t-it-time-for-LV-2020-SP1/m-p/4108112#M1184087
  22. I think when NIWeek was moved to may instead of august they said the release cycle might change, I think AQ posted something about that on LAVA, can't find it though.
  23. I'm sure you'll get plenty of different opinion on that topic. My rule is to only use SP1 versions for customer release (not sure NI will continue using the 202X and 202X SP1 pattern though). I remember reading a blog post from John Pasquarette in which he described the bi-annual release cycle that started in 2009 but I can't spot the article again.
  24. - I have no idea if what I'm going to say makes sense or not - on Windows the CLFN were all "any thread" and it worked fine.
×
×
  • Create New...

Important Information

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