I'd like to use WebGL Extensions from within Rust code that is compiled to WebAssembly. The web_sys::WebGlRenderingContext has a method get_extension which returns a JsValue.
I expect there is a way to either use the dyn_into method to get an ANGLE_instanced_arrays interface, which according to this webidl may be included in web_sys somewhere, but I can't seem to get at it. If it's not possible to get to the ANGLE_instanced_arrays interface, is it possible to call known methods and properties using the JsValue directly?
I noticed that you also posted your question on the wasm-bindgen issues log where they provided some useful information. For other people who come across this I thought I would share the link.
https://github.com/rustwasm/wasm-bindgen/issues/1257
As per this issue: wasm-bindgen issue 893 - Figure out how to support interfaces with NoInterfaceObject attribute The WebGL extensions should be available in the next release.
Related
When writing Rust documentation tests, is it possible to externalize parts of the code to an external file to keep the example short?
# include!("src/fragment.rs") appears to work and does not show up in the output. I have no idea how this interferes with Cargo's dependency processing, though.
I don't think it is officially supported at this moment; there is a related Cargo issue and a tool that attempts to allow it until it is introduced in Cargo (I haven't used it, though).
is there a way to inpect the traits an object provides at runtime. Similar to pythons dir()? I wish to inspect the contents of a core::str::StrSplits<'_> and would like to be able to view the traits it implements.
There is no facility for doing this at runtime; at compile time, however, there is, and this is what rustdoc does.
With that you can see things like the core::str::StrSplits documentation which covers the information you requested.
I have a driver that raises some warnings/errors during compilation, since the proc_fs api changed since its creation. The driver still uses create_proc_entry while the latest api version I am aware off, offers proc_create. Since I am new to driver programming under linux I tried to look at the source, however my ctags skills must be lacking since I only found proc_create in proc_fs.h. However, I would like to look at the implementation or some documentation, to know what error codes it returns so I know what I have to handle.
Can you point me to documentation for the proc api, or the source holding the definition of proc_create? A hint how it can be found would be appreciated as well.
create_proc is defined as an inline function, so it is fully implemented in the header proc_fs.h. It basically calls proc_create_data with a NULL for the data argument.
There seems very little documentation on these functions in the source so I'd recommend looking at other call sites within the kernel source, which you cam see listed in this LXR search.
BTW, creating new files in /proc seems frowned upon these days - it seems sysfs is where new interfaces should be created.
Best documentation for an API would be existing code itself. Check a few c files in fs/proc or grep for proc_create in the source code
I am new to Haxe.
When I try to convert the following line from C# to Haxe using CS2HX:
Interlocked.Increment(ref this.fieldName);
I get error from CS2HX:
ref/out cannot reference fields, only local variables
Now this makes me wonder - are Interlocked functions at all supported by Haxe - ?
Since I certainly would want to use Interlocked on fields and not on local variables.
Are there any alternative options besides using a lock?
Haxe should now have support for ref/out arguments extended so that fields are accepted too. The updates are in Git. Thanks go to #Waneck!
https://groups.google.com/forum/?hl=en#!topic/haxelang/3E-N93qoU38
CS2HX needs separate modification for that upgrade.
Maybe I will do that later myself, at the moment I have no time for that. I will post a comment here when I have updated CS2HX myself or find out that somebody else did it.
An alternative idea that came from that forum is using one-element array, I think that is pretty good too. Certainly better than using locks.
I am not worried about screen real estate. They have changed behavior and added new methods for tablet support. If I call one of these I assume that would cause a run-time failure for the older SDKs. Does this cause me to need a separate tablet version? This is the first time I have had to deal with this on Android and it wasn't clear to me what to do.
Documentation was incorrect and it worked. Don't know why I didn't think of reflection (doh!).
If those methods resides in some classes, which are not the part of pre-honeycomb SDK's you can try to use reflection to get (or not to in case of older devices) a honeycomb's class instance and call it's methods.
If you tell what methods/classes you are trying to use, i can try to make my answer more specific.