Is there a way how I can call golang functions from jsonnet?
Now that there is a go port of jsonnet and for example ksonnet is adding custom native functions I am wondering if there is a way how to extend jsonnet with more native functions?
I have many packages written in golang (with unit-testing, etc) and now it seems like I will need to rewrite some of them into jsonnet.
As discussed in the go-jsonnet's issue Custom builtin functions #223, you can introduce your custom golang functions but a pluggable support is not available - you cannot directly use the functions in a jsonnet binary.
You need to compile your own binary/library that creates an instance of vm.NativeFunction jsonnet VM and then add your native functions there.
Related
How can one call custom Wasm host functions from a Go guest?
I've looked at a few examples that show loading a self-contained witx/wat/wasm defined function, but haven't found an example for performing a host-defined call. Some examples I've looked at are for wazero and wasmtime-go here:
wazero example
wasmtime-go example
It would be ideal to be able to make these WebAssembly host calls using pure Go if possible.
Specifically, I'm trying to implement the host calls from the Fastly Compute#Edge ABI defined by compute-at-edge.witx and typenames.witx, but this should be generally applicable to any host defined call / function.
While building operators using OperatorSDK: Go framework, we end up creating Kubernetes resources such Deployments, Services etc programmatically by leveraging structs from k8s modules/packages. Compared to creating these manifests in yaml/json formats, this is quite cumbersome and requires quite a bit of coding. And any changes to the manifest would require code changes and the new version of the operator needs to be rolled out.
I am wondering whether existing templating/overlay tools such as Helm or Kustomize can be used for building these k8s resources within the operator code. This would also enable you to externalise the manifest/template files from the operator code. I couldn't find any good examples of how these tools can be used as modules/libraries within a Go program. Please provide any pointers, suggestions or alternate approaches.
Related question: Kubernetes operator create Deployment using yaml template
This talks about how you can read a yaml file and unmarshal it into a Deployment object. Here, I would still need to code templating/overlay logic within the operator.
You can use the helm engine programmatically, by calling engine.Render.
func Render(chrt *chart.Chart, values chartutil.Values) (map[string]string, error)
I've been working with a golang application lately that does network i/o using a bunch of protocols- HTTP (TCP), DNS and WHOIS (UDP) as well as a few others. Some make use of third-party APIs
The application is open-source so I would like to make changes allowing me to specify the network interface for the sockets to bind to, allowing me to use different interfaces depending on a runtime flag. The only way around this without writing code would be to modify the system-wide routing table each time I want to utilize a different interface, which isn't a very appealing solution
Before I go an modify every instance where a Dialer is used (or try to create a wrapper that they can all use) is there a golang feature that would allow setting the interface globally once, so that the various Dialer invocations would "Just Work"- and adhere to the interface I specified?
I did some searching and have only found ways to do this when each Dialer is created (using DialerContext.LocalAddr) but given I'm really a C programmer and not a golang programmer, I realize I may be totally missing a golang idiom for doing something like this
What is the difference between a Win32 or DirectX wrapper and a Win32 or DirectX framework?
A wrapper is typically a family of functions that contain the function calls for a library or API like win32, DirectX, etc., in some sort of abstracted way to the end-user. Many times they are customized so that the functions you call in the wrapper is not exactly the same as the original API, or some default parameters have been setup for you to make working with the API a bit easier. Also in the specific instance of a language wrapper, the functionality has been embedded in the language's run-time API, and then exposed to the end-user. For example, one could expose the win32 calls to a Python user by creating a C-library plug-in for python with the win32 API calls, and then creating a python library that may have customized python functions that call the win32 functions exposed by the C-library plugin. In this case the Python library "wraps" the native C-based win32 library.
A framework is like a wrapper, but in its most-typically used definition, it's a little different in that it works by creating some type of run-time environment that you create callbacks to plug into, so that when the frame-work wants to-do some task, you've written a function that is called for that task. This is called the "Hollywood Principal" of programming, which basically says, "don't call us, we'll call you". So in working with this model, you create functions, register them with the frame-work, and your function is called when the frame-work needs to call it, and the framework passes its own internal parameters as your function arguments. A good example is a GUI-framework, where you create callbacks for buttons and other events, and the GUI-framework calls those functions as it processes its runtime event-loop.
So I guess one way to think of the primary differentiation between the two is that wrappers tend to be static (i.e. exposing libraries and functions with customized function calls either that fill-in default values for you or translate them to a different language), whereas a framework tends to be dynamic (i.e. its a runtime system that you create callbacks for, and register it with the framework that are then called during some time of runtime event loop or kernel, etc., like a GUI toolkit).
Wrappers tend to make it possible (oftentimes easier) to access complex systems, complex code or combinations of calls from multiple classes and so forth. For example, you may create a Facebook wrapper in C# or Java to interact with getting user data from the Facebook API, which has many REST-based functions which return JSON. A framework is a set of related objects, functions, and so forth to provide a particular functionality, or enhance a particular functionality, so you wouldn't use either a wrapper or framework. Oftentimes you'll use a both, using a wrapper to access a framework. This is especially true with legacy systems :)
I need to call a RPC client which is implemented in C from a Java class.
The interaction is one way only(i.e) Java has to invoke specific functions in C, while C need not return anything to the calling Java code.
Can someone explain me the pros & cons in using either of the types (JNI/Runtime.exec)?? and which is the best option for my case?
Runtime.exec() will launch a separate process for each call. Your Java caller needs to consume the output of each process.
JNI would require a native, dynamically linked library. Depending on your operating system, you may need to explicitly export functions. You would define a Java class with "native" methods, generate a C header/stub file with javah, and implement the native methods by calling your C client functions.
Runtime.exec() probably consumes the most resources. I personally would use an in-process call to native code.
Instead of JNI, consider using JNA, which makes it easy to call C functions from Java without an ad hoc native glue layer. Your C functions would need to be in a native, dynamically linked library. In Java, you declare their signatures, load the library, and call the functions.
For Windows DLLs, be aware that you need to export functions for them to be available from outside the DLL.