I am looking for Lua-protobuf binding that supports all protobuf syntax like oneof. I tried a couple of available libraries but they don't support oneof. I will use it in openresty.
Related
I'm making a Dart library that uses FFI to interact with Rust code and I have some questions.
I couldn't find any official information about native interop behavior and I've been steering only by other examples and Dart SDK code.
For instance, Dart FFI doesn't map bool types directly, instead, it uses Int8. I also don't know what happens if the sizes of the types don't match. Is there any documentation that explains these "rules"?
The boolean type is supported on the master branch. It is available on dev from 2.15.0-233.0.dev, in the 2.15 beta, and will be part of the 2.15 stable release.
As for sizes. You could try generating a C header file from your Rust API and then using package:ffigen to generate the Dart bindings.
I am working on the dart_ping package and although it currently is tagged with iOS support, it does not actually support iOS. This is due to the way pub.dev detects supported platforms. I have filed an issue on dart-sdk repo.
Nonetheless, I would like to add iOS support while still preserving support for dart native. Right now, dart_ping works by calling the host OS's ping binary. The ping binary is available on Windows, macOS, Linux, and Android but not on iOS.
Current methods of performing a ping on iOS use native Objective-C code and call them via either method channels or ffi. Since method channels are a flutter feature rather than a dart feature, using them would require dart_ping to depend on the flutter sdk, which would prevent it from being used in a dart native application (perhaps server side).
Ffi on the other hand, is a dart native feature and is capable of doing what I want. However, I cannot seem to find a way to include the iOS framework/library/binary for ping in my dart_ping package in a way that instructs a flutter application to include it and link it to the iOS target/runner.
Is there any way to keep dart native support in my package while also supporting the edge case of iOS needing an extra non-dart framework? Even federated plugins depend on the flutter sdk. It seems to me that we need a pure dart equivalent to the federated plugin system.
TLDR: How do I add a pre-compiled iOS framework or binary to a dart package without depending on the flutter sdk and call it only when the package is used on iOS ?
For your specific case of adding iOS support only for Flutter users of your package but keeping the package as pure Dart without a dependency on the Flutter SDK should be possible by having a Flutter plugin package that depends on your Dart package.
In the pure Dart package you can have FFI calls to a native iOS library, but its actually the Flutter plugin package that supplies the native iOS library per the Flutter documentation for using FFI.
You would of course need to make it very clear in the documentation for your pure Dart package that for iOS, it should only be used via the "wrapper" plugin package.
Unfortunately this is a rather convoluted way to do it, but I don't know of a better way to achieve this as of now.
There is further discussion on this topic in the comments in this issue, which as of today is still open.
I'm compiling c++ to web assembly using clang --target=wasm32 --no-standard-libraries. Is there a way to convince clang to generate sqrt? It's not finding <math.h> with this target.
Do you already tried to compile without the flag --no-standard-libraries? If you remove it, the clang probably will find math.h library (because its a standard library).
This is because wasm32-unknown-unknown is a completely barebones targets in Clang, and doesn't have any standard library - that is, no math.h, no I/O functions, not even memcpy.
However, you can usually get away with using --target wasm32-wasi + WASI SDK instead: https://github.com/WebAssembly/wasi-sdk
It includes the whole standard library, including even functions for interacting with the filesystem via the WASI standard in compatible environments.
If your code doesn't depend on filesystem / clock / other I/O, then you can safely use WASI-SDK to get math.h, memcpy, malloc and other standard functions, and the resulting WebAssembly will be compatible with any non-WASI environments as well.
We are prebuilding some libraries (mainly with carthage) for some of our projects to reduce development times. These libraries are not updated very often, but we want to update our XCode versions pretty fast.
Now every time a new XCode brings a new swift version, we are seeing this incompatibility issue
File.swift:4:8: error: module compiled with Swift 5.3.2 cannot be imported by the Swift 5.4 compiler: /......./Debug-iphoneos/Alamofire.framework/Modules/Alamofire.swiftmodule/arm64-apple-ios.swiftmodule
How can I pre-build my dependencies in a way that a swift update wont affect it and I dont have to re-build the dependencies with every xcode update (I thought thats what ABI stability was for? How can I activate that?)
It sounds like you're misunderstanding what ABI stability enables. The main benefit is that it allows the OS to include only one version of the Swift standard library, and for all Swift binaries to share it. What you want is "module stability". From the docs on ABI stability:
ABI stability is about mixing versions of Swift at run time. What
about compile time? Right now, Swift uses an opaque archive format
called “swiftmodule” to describe the interface of a library, such as a
framework “MagicKit”, rather than manually-written header files.
However, the “swiftmodule” format is also tied to the current version
of the compiler, which means an app developer can’t import MagicKit if
MagicKit was built with a different version of Swift. That is, the app
developer and the library author have to be using the same version of
the compiler.
To remove this restriction, the library author needs a feature
currently being implemented called module stability. This involves
augmenting the opaque format with a textual summary of a module,
similar to what you see in Xcodeʼs “Generated Interface” view, so that
clients can use a module without having to care what compiler it was
built with.
This is not yet supported in any version of Swift.
The latest version of Delphi, XE4, allows for the building of iOS applications. There was some discussions on the newsgroups to use native iOS libraries for HTTPS/Posting to avoid issues with OpenSSL libraries and Indy 10. What's the recommended way of using native libraries to perform HTTP Posting? (In my example, JSON document upload and response.)
I figured it out...
Background:
Indy, the "native" code used for webservice calls in XE4, relies on OpenSSL. In most situations, OpenSSL is linked to via dynamic library (in windows a DLL). iOS does not support dynamic libraries, therefore once the code is compiled into a binary and sent to an iOS device, the OpenSSL calls fail because there is no backing library. The solution is to compile OpenSSL into your project. You can do this by downloading the OpenSSL source and adding it to your project, or source the static libraries from somewhere else and add them to your project. I found the static libraries here:
http://indy.fulgan.com/SSL/OpenSSLStaticLibs.7z
That is one of the indy mirrors, so hopefully it should be OK. You need to put the two files somewhere that your project is knowledgeable of and then add IdSSLOpenSSLHeaders_Static to your uses. Now, your compiled code will include the OpenSSL code and your issue should be resolved.