I am already done forking the smart contracts of the Uniswap, I am looking at forking the interface and then linking it up with the smart contract, is there a guide or way I can do this, I can't seem to find how to do this.
Related
Does Flutter provide any documentation on creating plugins for Windows platform as they do for Android/IOs?
Specifically regarding event channels?
Im trying to develop my first Windows Plugin and have managed to get simple method calls from dart -> native c++ to work, but I'm not sure exactly where to start for method channels.
Several pub.dev projects I've looked are quite complex and a bit overwhelming. Id prefer to not just copy past tons of code I may not need and dont understand. I'm looking for basic examples, preferrably reference implementations from flutter themselves.
I am trying to make a Rust program that emulates a webcam. This question and this answer suggest that the best way to do this is by creating a DirectShow source filter. Based on the PushSource sample in the Windows SDK and some C# implementations on CodeProject, it seems like the canonical way to do this is to extend the DirectShow BaseClasses provided in the Windows SDK. However, this is where my understanding breaks down.
I found the cxx crate and was able to get the classes from BaseClasses into my program, but how do I inherit from them or instantiate them? This crate does not seem to be designed for use with COM, and it is not clear how to call the constructors of classes.
Once I have done that first part, how do I expose my new classes as COM components? I found the com crate, but it seems to expect me to import the base classes using their GUIDs. However, I have no idea how to figure out what their GUIDs might be.
A community member would like to utilise Python to integrate aspects of their application with NEAR. Would it be possible to build an application on NEAR using Python? Can the NEAR API be used with Python?
With NEAR you build on 2 fronts:
"Inside": Contracts (to write code that runs on-chain and changes state in the system)
"Outside": API (to create dApps that communicate with NEAR)
Contracts
We currently support two languages:
Rust (near-sdk-rs)
and AssemblyScript (near-sdk-as)
You can find more examples of contracts written in both of these languages in our NEAR Examples GitHub org, many of which are running live on near.dev
In the future we will support any language that we (or our community) decides to enable from a pretty long list where “enable” means building out the sdk like near-sdk-rs and near-sdk-as linked above.
API
We currently have a JSON RPC API that you can use from any language (including Python) as well as a convenient wrapper for JavaScript developers called near-api-js. Again, we (or our community) can decide to build more convenient wrappers for any other language we want to support, including Go, Java, C#, Python, Ruby, etc
As a side note, if someone in the community is interested in Python specifically, there’s a ton of it currently being used to do things like run tests (nearcore pytest), manage builds (nearcore scripts) and deploy nodes (nearup) as well as simulate some of the on-chain stuff like the Runtime
I use py-near
https://pypi.org/project/py-near/
built-in transactions with FT
fully asynchronous library
good documentation
built-in transfers NEAR/Ft by SMS
multiple RPC node support
I'm working on an online game that will communicate with the backend using gRPC protocol. There are gRPC client libraries for iOS, Android and JavaScript.
The plan is to implement the game logic and rendering using Haxe, but networking using native code with gRPC. What's the recommended approach for that? I can see 2 options:
Implement and build the game using Haxe in a way that it exposes some methods to native, e.g. a method to update game state using server data, and also accepts some callbacks from native, like a callback that is called every time the player makes an action that should be sent to the server. Then the callbacks and appropriate method calls can be implemented in the native projects generated by Haxe, using native tools like Xcode.
Implement networking using native tools like Xcode and expose them to Haxe somehow. Then the game logic written in Haxe will call native methods and provide callbacks implemented in Haxe to native.
What's the recommended approach? It seems to me that the first approach might be simpler and have less potential issues. If you could also point me to some articles about that, it would be great, since I haven't found anything detailed enough.
Even though not complete, maybe these guides can help:
https://github.com/snowkit/hxcpp-guide/tree/master/work-in-progress/build
or as an example:
https://snowkit.github.io/linc/
Window's COM allow us to wrap our application function for out-of-process invocation. If the COM interfaces are well defined and design, it is certainly great to consume the services via scripts and any programming platform that support COM/Automation/Active-X.
I am just wondering if there exist any alternate methods to design of what COM does? Or something close or similar methodology?
I am using Delphi in Win32 platform.
I'm not entirely sure, but it seems that you're talking about an alternate to COM for creating plug-ins for your software?
If so, there are myriad options:
TMS Software's Plugin Framework
RemObject's Hydra
Project JEDI's JVCL includes a plugin system
You can also roll your own. I wrote an article many years ago that provides the fundamentals (though the linked source is long since gone to the great bit bucket in the sky).
Corba
or
IBM's SOM
I'm sure there are others as well but those are the 2 others i can think of off the top of my head ...
If you want a TCP/IP (over the internet or over a LAN) interface for your objects, consider SOAP, and REST.
If you want to write plugins for your delphi app and not use COM/OLE-Automation, consider RemObjects SDK.