robotdotnet / networktables Goto Github PK

@jkoritzinsky Would you be opposed to updating the managed version of NetworkTables to require .NET 4.6? Apparently there are some edge cases where the Async locking code can cause a StackOverflow or a deadlock that were fixed in 4.6. There are also a few odd workarounds I have had to do in 4.5.1 that we would not need in 4.6. NetworkTables.Core would stay 4.5.1, which the WPILib is going to continue using, so we don't need an update there as well. The NetStandard versions would stay the same as they currently are however.

EDIT: It would also allow me to just include the AsyncEx package as a dependency instead of copying the source code. For the managed version I think that is fine, as mode use cases for it are deployments that can handle multiple libraries anyway. NetworkTables.Core will keep as one file as it makes copying to the RoboRio much easier.

These are being changed in .NET Core to not behave like we need them to, so we need to create our own. Mostly we can use either the ReferenceSource or the NETCore code to do this

When the DS Client cannot connect, it continuously prints an error.

More of a question than an issue (sorry). Have you integrated your c# NetworkTables into Unity3D? I'm a mentor for a team in CT and am trying to build a simulation environment in Unity given that we can't meet in person due to the pandemic. I'm using WPIs robot simulation that relies on Network tables underneath the HAL and want to read/write the network tables from C# code in Unity. I'm using a Linux (Ubuntu) platform ATM and have been able to build your code in VSCode and have brought enough of the DLLs into Unity as plugins so that it doesn't complain when building. When I run in Unity, I can create an instance and ask it for tables/entries, but no Joy on actually getting data. Thanks in advance for any suggestions you have. I really appreciate all you've done here!

To reproduce use:

NetworkTable.AddGlobalConnectionListener(SetConnectivityMarker, true); .. private void SetConnectivityMarker(NetworkTables.Tables.IRemote remote, ConnectionInfo conn, bool connected) { ... }

Exception thrown is MissingMeberException, details can be seen in this screenshot

There is a lot of issues with it. Starting from being way too C++ based, hard to unit test and hard to maintain. In addition, it uses too many custom classes that make certain things very hard to use, test and add.

There should be async versions of these methods for teams to be able to use. In NetworkTables, they should be implemented natively when possible, however on ntcore they will be implemented with Task.Run.

Currently we store all Values in an object type, which results in boxing, and some interesting code. Instead Value should become a base class, with every type having its own Value. This might help with serialization later as well for some potential ntcore features.

Currently, we round robin to connect to different IP's. Instead, this should happen in parallel. #69 would include this, but this is more important to then the whole rewrite.

I've been trying to connect to my roborio using the address roboRIO-xxx-FRC.local as the address, set in NetworkTable.setIpAddress("roborRIO-xxx-FRC.local"). It always fails with error message NT: ERROR: could not resolve roboRIO-2706-FRC.local address (TcpConnector.cs:74)

Until we unlist these packages, they will always be selected as the most recent package because the major version will be much higher than our newest Semantic Versioning packages.

It does not seem like flush it working. Need to debug

'F:\Dev\FrcSmartDashboard\RdnNetworkTables\src\FRC.NetworkTables.Core\Native\Uname.cs' could not be found.
'F:\Dev\FrcSmartDashboard\RdnNetworkTables\src\FRC.NetworkTables.Core\Native\LoaderUtilities.cs' could not be found.
'F:\Dev\FrcSmartDashboard\RdnNetworkTables\src\FRC.NetworkTables.Core\Native\LibraryLoader.cs' could not be found.

I haven't been able to find any documentation on trying to use this module. I'm trying to make my own little Dashboard for the robot using C# and Windows Presentation Forms and I've installed this using NuGet.

What is the basic syntax for if I'd like to get the SmartDashboard table while connected to the robot, and then get values from it?

Further down the line, I'd also like a camera feed if possible. I see that you have some sort of camera feed thing set up. If I wanted just a basic feed, what would setting that up look like in C#?

I'm actually debating just removing all the inheritdoc docs and replacing them with static. Keeping the sandcastle builds maintained to copy the inheritdocs to the XML is a pain, and they really don't give us much benefit. It should be a pretty easy modification in NetworkTables. WPILib will be harder, but it's less of an issue there at least for right now, since we only build for net451.

@jkoritzinsky what do you think?

I ran the portability tester, and got the following regressions that need to be changed to enable .NET Core support

NetworkTablesCore

• System.AppDomain does not exist (We only use for shutdown hooks. Recommended change is to use a static object with a finalizer to do the same thing)
• System.EntryPointNotFoundException (Create our own. Necessary)
• System.Environment Is64BitProcess and OSVersion (Use System.Runtime.InteropServices.ProcessArchitechture and OSDescription)
• System.OperatingSystem.GetPlatform (Figure out something new. Necessary for us however)
• System.PlatformID (Again Necessary for us. Figure something out)
• System.Reflection.Assembly.GetExecutingAssembly (Typeof(CurrentType).GetTypeInfo().Assembly)
• SuppressUnmanagedCodeSecurityAttribute (Can remove, but maybe IfDef it out. Its good to have on windows)

NetworkTablesManaged

• System.Base64FormattingOptions (No alternative, Probably will have to roll our own library)
• System.Convert.ToBase64String (Again roll our own. Needed for NtCore spec)
• System.IO.Stream.Close (Replace with Dispose())
• System.IO.StreamWriter directly opening file (Replace with File.Open and pass that stream to the StreamWriter)
• System.Net.Dns.GetHostEntry (Figure out something new. TBD)
• System.Net.Sockets.NetworkStream missing get_Socket (This is gonna be a big one, don't know what we will do.)
• System.Net.Sockets.TcpClient missing BeginConnect, Close, Connect, EndConnect, and get_Client (Again big changes will need to be figured out.)
• System.Net.Sockets.TcpListener.AcceptSocket (Again a big change. Might just have to move to raw sockets

From the looks of it, NetworkTablesCore is much easier to port, which makes sense since its just a thin wrapper. NetworkTablesManaged is going to require a lot more work.

When shutting down NetworkTables, it will throw an AggregateException containing a DNS exception about a host not being found when shutting down network tables after connecting to an invalid host (for example, a team number for a robot that is not present). I expected the Shutdown method to handle all exceptions and make sure everything is shut down before returning.

I have a workaround of calling NetworkTable.Shutdown in a try-catch in a loop until it succeeds, but I'd prefer to not have to do that.

I was noticing that on some systems, trying to access an IPv6 network address would throw an exception. Currently, IPv6 address from DNS are ignored, however at some point I would like to fix this, and only disable IPv6 for the systems that do not support it.

Currently everything has to be uploaded manually. RoboRio libraries are grabbed separately, but desktop libs are in this repo, so we should automate them. If we do, we should remove the native libraries from the repo and have the build script automatically grab them.

It's possible for UTF to corrupt string data, and if we are a server, we might end up corrupting that data between clients. Instead of storing strings as strings internally, just store them as byte[]s, and only do the UTF conversion when a string is specifically requested by the user.

The code currently does not do this, which could result in passing a non null terminated string to C through P/Invoke. Also most likely move the string to UTF conversion, along with some other utility code to NativeLibraryUtilities, and maybe rename that to be a more general FRC utility library.