Jump to content

Antoine Chalons

Members
  • Posts

    955
  • Joined

  • Last visited

  • Days Won

    34

Posts posted by Antoine Chalons

  1. Let me make sure I understand what you mean by this :

    11 hours ago, bjustice said:

    I've found that comments in the original LV-TOML library seem to work pretty well.

    You mean, they are ignored and don't mess up with extracting the data, right? (appart from the case in issue #1)

     

    Because for me one thing that is a bit annoying is if you load data from a TOML file that has some comments, as soon as you write using this lib, you lose all the comments, or am I missing something?

  2. 9 hours ago, Porter said:

    A nice feature would be to optionally preserve top-level comments (lines that start with #). I don't think that this is a trivial to implement, but it could be useful.

    And it might even be simple to preserve inline comments while we're at it (keep the comment with the key-value pair).

    I've been thinking about this but as I said above, this a not a short term need for me.

    I do hope I'll find some me-time to play with comments during the summer.

     

    Interestingly, there is a reported issue on the original repo that is linked to comments : https://github.com/erdosmiller/lv-toml/issues/1

  3. 9 hours ago, Porter said:

    Just a little detail, you might want to add some text at the top of the license file along the lines of:

    Contributions up to v1.2.1 Copyright (c) 2017, Erdos Miller

    Ah.. I knew I'd screw-up the license handling... I have to say I didn't even look up how to handle open source license when forking.

    My bad, will fix that soon.

  4. On 3/15/2021 at 2:41 PM, bjustice said:

    Yep!  TOML is like INI file syntax learning how to do everything that JSON can do... with comments.  I'm a fan.

    I've also been using the Erdosmiller library.  I've found a few bugs, it's not full-feature, and it's not TOML 1.0 compliant. (TOML just 1.0'd recently).  It's the best I've found thus far though, and it's been working well enough for me.

    @bjusticeI've seen issue #2 that you created on the original repo, I have to say I don't understand the problem nor the suggested solution.

    Could you post more info about this please?

  5. I'm going to fork the repo on GitHub and work on it for my needs, What I'm planning to do is :

    short term :

    - move to LV2017 (just because it's the oldest I have already available on a VM)

    - add support for path

    - improve error reporting

     

    hopefully one day :

    - add support for comments

     

    At this point, I'm not planning to do any major refactoring.

    If anyone wants to participate... feel free : https://github.com/AntoineChalons/lv-toml

  6. 6 hours ago, JKSH said:

     

    So what happens with customers who have a Development Suite, where a single serial number is used to activate a variety of different products?

    Well that's my case as well, and it worked with my (what we use to call) DSRL license number.

     

    As for uploading files, I created a srq last week and could upload files. Maybe things have changed since.

    If I go to my existing SRQs I can still upload files, I just tried, it worked.

     

    What I'm suspecting is that based on your account (partner / not partner / company, etc..) NI filters and gives you a different feature set for creating your SRQ, that wouldn't shock me.

  7. 2 hours ago, drjdpowell said:

    I have been coming round to supporting comments in JSONtext, at least for ignoring comments on reading (which is quite simple to implement, I think).  And possibly features to be more forgiving of common User error, such as missing commas.

    Sounds great.

     

    I've seen you're also working issue 56, which would be another big advantage of jsontext over the TOML library.

  8. 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?

  9. 23 hours ago, Rolf Kalbermatter said:

    What do you mean with "threadsafe CLN"? It is a rather bogus terminology in this context.

    What you have is "reentrant" which requires the library to be multithreading safe and "UI Thread", which will allow the library to do all kind of non multithreading safe things. That trying to call PGisthreadsafe() from any context is not crashing is to be expected. This function simply accesses a readonly information that was created at compile time and put in the library. There is absolutely nothing that could potentially cause threading issues in that function. That every other function simply crashes even if you observe proper data flow dependency so that functions never can attempt to access the same information at the same time, would be utterly strange. That would not be just the reentrant setting causing multithreading unsafe issues but something much more serious and basic.

    I at least assume that you tried this also in single stepping highlighting mode? Does it still crash then?

    Sorry for the lack of clarity, what I meant by threadsafe CLFN is this : image.png.d6b373ebf2433629ff91419e079c00ee.png therefore : reentrant

    As opposed to non-threadsafe CLFN : image.png.1dfe46978bd1cee1e897f1e6e368df06.png 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.

    image.png.d97ea32e4d2233209885155547625db4.png

    22 hours ago, ShaunR said:

    That's because it's hard-coded to return a simple Boolean when compiled.

    
    int
    PQisthreadsafe(void)
    {
    #ifdef ENABLE_THREAD_SAFETY
        return true;
    #else
        return false;
    #endif
    }

     

    Ok, I'm fealing cheated. If I understand correctly it means NI's libpq.so pretends to be threadsafe but actually isn't.

  10. 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.

  11. On 1/21/2021 at 1:44 PM, ShaunR said:

    It depends how it is compiled.

    There seems to be a function to determine whether the binary is thread safe, yielding 1 if it is and zero if it isn't.

    
    
    int PQisthreadsafe();

    Source

    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.

    image.png.a28d33a9535794cbc9ccd2042b58d6c0.png

×
×
  • Create New...

Important Information

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