Announcement

Collapse
No announcement yet.

Updates and problem encountered

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Updates and problem encountered

    Hello Bridge team,

    After a long hiatus I am back to working on the Bridge.NET version of Robot Raconteur. The C++ core libraries are now open source, and can be found on github (https://github.com/robotraconteur/robotraconteur). This project was recently awarded a grant from the US ARM Institute, so I will be working on it full time for the next year (http://arminstitute.org/arm-18-01-projects/).

    I have been working on getting the C# version of the library up to the new standard. I currently have the C# Standard library and C# Core library up and running, and am now working on getting the Bridge version working. Thanks to your work over the last few years, I have not had to make many changes to the C# code to get it to compile with Bridge. There were a few notable missing pieces of functionality and bugs that I encountered. I can figure out some workarounds, but I will let you know and see if you can correct them easily.
    • TypeCode is defined, but Type.GetTypeCode is not implemented
    • Task should implement IAsyncResult
    • Stream should implement ReadAsync and WriteAsync
    • The "Options" property on ClientWebSocket doesn't work. Error says that "getOptions()" is not defined
    • The abstract class WebSocket is not defined. This is annoying because it breaks code that can also accept server websockets.
    • Have WebSockets been tested to make sure they work?
    • The System.Buffer class is not implemented
    • Array.LongLong and Array.Copy with long indices is not implemented
    • Convert.ChangeType is not implemented
    • Task.Delay with a cancellation token is not implemented
    • Uri.EscapeDataString and Uri.UnescapeDataString are not implemented
    While I can understand the need to keep the standard library as small as possible, these should not add much overhead to the core library and they all are important to the core functionality of the standard library.


    #2
    Now I am also seeing this error:
    • System.TypeCode.Object is not defined. It appears that System.TypeCode doesn't work.

    Comment


      #3
      Hello @johnswason!

      Thanks for the extensive feedback on features you're missing with Bridge.

      For one, we rave the Task.Delay w/ cancellation token in our radar: Issue #2405

      For the remaining others, I didn't look up each one, but I believe we'd need to log issues in github for each. For the missing namespaces/classes/inheritance, I believe just the mention is enough, but probably an existing implementation that doesn't work would better off a test Deck showing how you are trying to use it.

      About "Have WebSockets been tested to make sure they work?", we have developed its main bunch around 2016 via a #1047 issue contributed by the community, and at least two issues since then have been reported and fixed. So that's a case we probably need a Deck in the issue, in order to be able to reproduce and fix the issue.

      Our focus actually is in having the .NET support as broad as possible (with of course the minimal footprint in javascript as possible), but we usually tend to focus development on user-requested (or contributed) support of the .NET framework.

      Comment


        #4
        fabricio.murta it might be faster for me to patch some of the things I need fixed and issue PRs. A few years ago there was a problem with your contributor agreement. Are you still requiring that to be signed?

        Comment


          #5
          A CLA is required for PR's to be accepted.

          A few years ago there was a problem with your contributor agreement.
          Did you have an issue with a specific term or condition of the CLA, or just that the acceptance process was not working? Any further details you can provide would be helpful.

          Comment


            #6
            The main problem with the CLA was it being too broad. I don't mind signing over individual pull requests, but the blanket CLA as written is not going to work.

            I've pushed the current status of my code to GitHub in my personal repo. The code without any workarounds can be found here: https://github.com/johnwason/RobotRaconteurNETStandard I started doing some workarounds, but decided that it would make more sense to try to improve the Bridge core library. My initial workarounds can be found here: https://github.com/johnwason/RobotRa...dge_workaround . Ideally the entire RobotRaconteurNetStandardSharedSource project will be identical between the Core and Bridge use cases, with only a few preprocessor fences where unavoidable.

            Comment


              #7
              The main problem with the CLA was it being too broad. I don't mind signing over individual pull requests, but the blanket CLA as written is not going to work.
              The CLA only applies to code that is submitted by you to Bridge and we only accept code into the project by pull-request. If you have time, let us know specifically what terms or conditions you're taking exception to and we'll review. The CLA document itself is obviously a generic, but maybe too generic. We just used the document template provided by the cla-assistant.io extension which operates the CLA processing within GitHub.

              I took a quick look through your bridge_workaround branch but it's just one big commit for the entire project and I couldn't locate just the Bridge fixes. Can you link directly to the files|folder related Bridge fixes or workarounds?

              Comment


                #8
                I will have to check with my lawyer for the specific issues with the CLA.

                You can see the workarounds by comparing the "master" and "bridge_workaround" branches.

                https://github.com/johnwason/RobotRa...round...master

                Comment


                  #9
                  Looks like Task.Delay with CancellationToken support should be supported in Bridge 17.8.0. Issue #2405 is tracking the enhancement.

                  We'll try and work our way through your other workarounds and create issues for each. It would be very helpful if those workarounds could be simplified down to individual reproducible Deck.NET samples. That would help with the process of creating separate GitHub Issues for each.

                  Comment


                    #10
                    Ok, I will go through tomorrow and create a few decks to point out where I have run into problems.

                    Comment


                      #11
                      Sample decks:

                      [#716] TypeCode problems: https://deck.net/3ec6d03190f7f8b75d0d962891d5203d

                      [#3962] [#3951] [#2406] [#2405] Task related problems: https://deck.net/4d6bc26d07eb1df86474f0b67d73fce6

                      Stream is just missing Async methods including ReadAsync and WriteAsync. See line 223 and 750 of https://github.com/johnwason/RobotRa...amTransport.cs
                      Also shown in AsyncStreamTransport is missing ConfigureAwait in Task

                      WebSocket problems: https://deck.net/52056af3950f450d65b8708033edff22

                      System.Buffer is missing. An implementation can be found on line 358 of https://github.com/johnwason/RobotRa.../Extensions.cs

                      Array operations using long instead of int: https://deck.net/105502736d5f5221c3da7851ffc000a0

                      [#977] Convert.ChangeType is not implemented. A limited implementation can be found on line 636 of https://github.com/johnwason/RobotRa.../Extensions.cs

                      Uri class needs to be filled out in general, including Escape and Unescape functions. Line 339 of https://github.com/johnwason/RobotRa.../Extensions.cs uses a relatively ugly hack. I don't think it produces the same output as the normal C# libraries.
                      Last edited by geoffrey.mcgill; 2019-05-20 @ 12:47 AM.

                      Comment


                        #12
                        Very nice. Thanks.

                        We'll work our way through these samples. There is some work being done with Task right now in preparation for 17.8.0, so we'll be sure to review your sample.

                        Comment


                          #13
                          My lawyer said the CLA should be ok.

                          What issues have you already started working on? I don't want to duplicate effort.

                          Comment


                            #14
                            Most related are the Task related issues in the upcoming 17.8.0 release:

                            https://github.com/bridgedotnet/Brid...l%3Aarea-task+
                            Last edited by geoffrey.mcgill; 2019-05-14 @ 09:20 PM.

                            Comment


                              #15
                              A pull-request for adding TypeCode support has been submitted.

                              The feature is being tracked in issue #716.
                              https://github.com/bridgedotnet/Bridge/issues/716

                              Comment

                              Working...
                              X