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
Related
I love the idea of combining the power (and existing libraries) of python with the rich user interfaces of Flutter, however I wonder about how Flet can interact with existing Flutter code-bases.
Specifically, is it possible to incorporate Flet into existing Flutter apps? Can I write a specific business-logic module in Flet (via python) and then access that module via standard Dart/Flutter?
I think such a mechanism would provide a lot of utility for developers, allow for a larger range of (language) expressivity in Flutter apps and make it easier for established codebases to adapt Flet without having to start from scratch.
FYI: I know that Flutter packages for python integration exist (e.g. Chaquopy and Starflut, or just running a custom python-based on-device web-service), but I am intrigued by the more native integration that Flet could afford (less marshalling logic, etc.)
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/
in case i have a source code and an api to generate windows executable version, is there any possibility or any easy approach to convert it into something that can be executed across Linux /mac or Solaris platforms?
If your code is in a .NET language, there are online and offline translators that can convert the code to Java.
This is just language translation, and doesn't convert the API calls, but it would be a first step in the process.
Another way to handle the problem would be to choose a cloud-based web service or bridge solution. If you have a significant amount of program logic, exposing APIs in this way would allow you to maintain much of the code in its existing language, while making it invocable on other platforms.
My team is currently creating an API that will interact with our core Ruby API.
The new API is for the public as the Ruby API is our private API. We want to be able to compile this new API into a PHP, Java, Python, etc., client libraries when we are ready to release.
Are there any gems, or other ways to write this new API so we can compile it into different client libraries?
There are several ways to think about exposing an API these days. If we're talking about creating a library in the sense of something compiled into other applications, that takes us down one path. If we're talking about providing, effectively, command line functionality callable from other contexts as system calls, that's another story. More broadly is the API is more of a service, like REST, that's different. I'll assume one of the first two.
There are several tools that will create a binary package for platforms. Look at ruby-tioolbox.com for some examples. None of these are compiling true executable code (as far as I know) but mainly provide an executable version of ruby with your code and dependencies packaged up. Perhaps the API appears callable as a system library (DLL for Windows, SO for UNIXy).
But either way, I would think you're dealing with ruby and your code loading and running as a separate process on each call. There's a library like this (not in Ruby) called ImageMagick, with a wrapper for ruby calls called MiniMagick that might be a pointer to the kind of pattern you're looking for.
If you want to run ruby and your app as a service, there are several tools for this -- this helps address the overhead of loading a process each time, and built into Ruby 1.9 is a Process class that daemonizes ruby, although presumably only on Unix. Check this SO answer
The best answer is probably that ruby, like other similar languages (e.g. Python) are really not designed to be low-level system libraries. There are likely many ways of accomplishing what you want in a given environment (notably Linux) ... but as far as I know nothing that really exposes executable codepoints to all languages.
It seems that the Win32 API (the C API for native Windows applications) is becoming more and more overtaken by more modern frameworks and toolkits, including Microsoft's own WPF and Qt.
If the programming language is not a concern -- if you're not set on a managed environment, or a functional programming style, etc. -- does Win32 API bring anything to the table? Is there any functionality that one can implement with Win32 API that's not available with WPF or other frameworks?
I know it's possible to mix Win32 code into WPF/managed software, so one doesn't have to choose one or the other. But what are some examples of needing to break out Win32 API when developing a program in a higher-level language/framework?
Another more specific example is "windows hooks".
I needed to hook some socket programs at some point and the only possible way was windows api.
To elaborate i wanted to receive all communication received on some listening socket on a different one. Doing this requires hooks
Certainly.
All the frameworks are written in terms of the Win32 API. The frameworks cover 80-95% of what programmers need to do, but if you need really low-level control over something, you'll need to drop to the underlying Win32 API. Some examples would be:
precise control over text rendering (via DirectWrite),
detailed control over speech recognition using SAPI (there are literally dozens of interfaces not exposed through System.Speech),
low-level networking code (i.e., anything not HTTP related),
Practically anything audio related, if you're interested in performance.
... and don't forget about direct hardware access like "WinUSB" and debugging functionality (writing programs that act as debuggers).
The Win32 API is nowhere close to be taken over by any framework at the moment.
If that was the case, most of the API would not be updated by Microsoft. Instead, lots of new interfaces are added and updated.
There are framekorks like Qt, but, unless what you need to create is trivial, you will eventually use the API, especially for new graphics libraries, audio, video, usb, ribbon, sockets, network, COM automation, biometrics, encryption, digital signatures, security, scripting, etc.
Actually, most libraries are quite outdated and, while you can create an application that relies mostly on worker threads and not on the interface, building a nice, modern and useful application today certainly requires the API. So investing on a framework that would only cover a minimum part of your application is not worth the learning curve, these frameworks mostly target really new and unexperienced windows developers.