This is the cousin of this question over here asking the same thing for C.
Basically, is there a better way than to just turn it into a giant byte array and putting it in a source file?
Alternatively, does a macro have the ability to do this? (Rust Macros... are a dense looking and their exact capabilities are not known to me.)
You probably want include_bytes!.
If you are in older versions of Rust, use include_bin! instead.
You could alternatively use this tool https://github.com/pyros2097/rust-embed Which was created by me which generates rust code for your resources.
Related
I am so surprised when I look into the substrate-relevant project code. It's so hard to understand, runtime macros everywhere.
Now, It's easier for you to develop your own blockchain base on the Substrate framework. The most difficult section might be how to make rustc accept your code.
It is not necessary to use the macros to develop on Substrate. As you may know, the macros ultimately expand to be real rust code, so if you understand the inner working of Substrate at that level, then of course you can write that code yourself, but this will certainly not be as easy as using the macros.
I believe the macros expand to about 3x the lines of code as you write, and contains logic that we try to keep opaque from the average runtime developer.
It is a fair criticism that the runtime macros can be hard to debug or work with, but we are looking to solve this issue by using Rust attribute macros and staying closer to traditional Rust syntax.
See the tracking issue here: https://github.com/paritytech/substrate/issues/5678
Can I change the core functionality of Python, for example, rewrite it to use say("Hello world") instead of print("Hello world")?
If this is possible, how can this be done?
I see a few possibilities as to how to accomplish this. I've arranged them in order of how much programming is needed/how obnoxious they are:
Renaming builtins
If, as in your example, you are simply more comfortable using say() or printf() than print(), then you can, as others have answered, just alias the builtin function to your own function with something like say=print.
Rewriting builtins
Let's pretend we don't trust the official implementation of print() and we want to implement our own. A lot of the internals in Python such as stdin are contained in the sys library. You could, if you wanted, implement your own. I asked a question a couple years ago here that discussed how to rename the _ variable to ans which might be illuminating to take a look at.
Sending your code through a preprocessor
Ok, so gcc doesn't require C code as input. If you use the right precompiler flags, then you could get away with evaluating #define macros in your source code before you send it to python. Technically a valid answer, but obnoxious as heck.
Writing modules in another language
Cython (python written in C) can have modules written for it in C. You could build a wrapper for printf in C (or assembly, if you'd rather) and use that library in your python code.
Recompiling Python
Unfortunately, doing the above is not possible with all tokens. What if, in a fit of fancy, we'd like to use whilst loops instead of while loops? The only way to accomplish this is actually altering the functioning of python itself. Now, this isn't for the faint of heart or the new programmer. Compilers are really complicated.
Since, however, Python is open source and you can download the source code here, in theory, you could go into the compiler and manually make all the edits you want, then compile your version of python and use that. By no means would your code be portable (as essentially you'd be making a fork of python) but you could technically do it.
Or just conform to the Python standards. That works too.
Writing a PEP
Python is a living language. It's constantly being updated. The ruling body of "What gets included" is the BDFL-delegate and the Council, but anyone can write a Python Enhancement Proposal that proposes to change the language in some way. Most features in Python started out as a PEP. See PEP 0001 for more details.
yes you can just write
say = print
say("hello")
The lexer/parser file located here is quite large and I'm not sure if it is suitable for just retrieving a list of Rust functions. Perhaps writing my own/using another library would be a better route to take?
The end objective would be to create a kind of execution manager. To contextualise, it would be able to read a list of function calls wrapped in a function. The function calls that are within the function will then be able to be re/ordered from some web interface. Thought it might be nice to manage larger applications this way.
No. I mean, not really. Whether you write your own parser or re-use syntex, you're going to hit a fundamental limitation: macros.
So let's say you go all-out and expand macro_rules!-based macros, including the ones defined in external crates (which means you'll also need to extract rustc's crate metadata loading... which isn't stable). What about procedural macros and custom derive attributes? Those are defined in code and depend on compiler-internal interfaces to function.
The only way this is likely to ever work correctly is if you build on top of the compiler, or duplicate a huge amount of work (which also involves unstable binary interfaces).
You could use syntex to parse the Rust code in a build script.
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 downloaded the .ply files in the Stanford 3D scanning repository, and am using Stanford's code from that page (ply.h, plyfile.c) to parse them. However, looking at this code, I see that it's rife with mallocs that are never freed. I could close my eyes and look the other way, but it makes my teeth itch.
I can think of two workarounds:
One is to use Hans Boehm's garbage collector, or something similar, which redefines "malloc" so that it does so within a garbage collector. I've never used this library, but perhaps there's a way to have it operate just on the mallocs in the Stanford code and not anywhere else.
The other workaround is to use a different parser, preferably a C++ one with nicely RAII-ified memory management. I see a few alternative parsers and converters listed at the above link, but rather than kill a day or two trying them all, I was hoping to get a recommendation here.
Can anybody recommend a way to parse .ply files without memory leaks, either by containing the memory leaks in the Stanford parser, or using a different parser, or by some third method I haven't thought of?
Try also RPly.
This library looks promising; until someone else answers this question, I'll mark this as the answer: http://assimp.sourceforge.net/
Another library is the one used by MeshLab
http://vcg.sourceforge.net/index.php/Tutorial