I'm looking to create my own scripting language, highly based off of lua (im planning on it being lua but easier to understand for me) so I need to know where the predetermined functions / variables file is, because I would like to edit that. If you have a solution, please comment and let me know!
Every table in the standard library is defined in its own C file. In the src directory of the Lua source package, look for the file whose name is similar to the library name. Global functions are defined in lbaselib.c.
Related
Specifically, my issue is that I have CUDA code that needs <curand_kernel.h> to run. This isn't included by default in NVRTC. Presumably then when creating the program context (i.e. the call to nvrtcCreateProgram), I have to send in the name of the file (curand_kernel.h) and also the source code of curand_kernel.h? I feel like I shouldn't have to do that.
It's hard to tell; I haven't managed to find an example from NVIDIA of someone needing standard CUDA files like this as a source, so I really don't understand what the syntax is. Some issues: curand_kernel.h also has includes... Do I have to do the same for each of these? I am not even sure the NVRTC compiler will even run correctly on curand_kernel.h, because there are some language features it doesn't support, aren't there?
Next: if you've sent in the source code of a header file to nvrtcCreateProgram, do I still have to #include it in the code to be executed / will it cause an error if I do so?
A link to example code that does this or something like it would be appreciated much more than a straightforward answer; I really haven't managed to find any.
You have to send the "filename" and the source of each header separately.
When the preprocessor does its thing, it'll use any #include filenames as a key to find the source for the header, based on the collection that you provide.
I suspect that, in this case, the compiler (driver) doesn't have file system access, so you have to give it the source in much the same way that you would for shader includes in OpenGL.
So:
Include your header's name when calling nvrtcCreateProgram. The compiler will, internally, generate the equivalent of a std::map<string,string> containing the source of each header indexed by the given name.
In your kernel source, use #include "foo.cuh" as usual.
The compiler will use foo.cuh as an index or key into its internal map (created when you called nvrtcCreateProgram), and will retrieve the header source from that collection
Compilation proceeds as normal.
One of the reasons that nvrtc provides only a "subset" of features is that the compiler plays in a somewhat sandboxed environment, without necessarily having all of the supporting tools and utilities lying around that you have with offline compilation. So, you have to manually handle a lot of the stuff that the normal nvcc + (gcc | MSVC| clang) combination provides.
A possible, but non-ideal, solution would be to preprocess the file that you need in your IDE, save the result and then #include that. However, I bet there is a better way to do that. if you just want curand, consider diving into the library and extracting the part you need (blech) or using another GPU-friendly rand implementation. On older CUDA versions, I just generated a big array of random floats on the host, uploaded it to the GPU, and sampled it in the kernels.
This related link may be helpful.
You do not need to load curand_kernel.h yourself and add it to the include "aliases" mechanism.
Instead, you can simply add the CUDA include directory to your (set of) include paths, e.g. by adding --include-path=/usr/local/cuda/include to your NVRTC compiler options.
(I do this in my GPU-kernel-runner test harness, by default, to be on the safe side.)
In the autoconf manual, it is noted that
AC_INIT (package, version, [bug-report], [tarname], [url])
defines multiple macro names such as AC_PACKAGE_NAME and PACKAGE_NAME.
Running configure also generates a config file with definition like the following:
define HAVE_LIBGMP 1
As I am writing C++ code, I find these macros annoying yet useful. In fact, it happened many times that I needed to link with a library that uses the autotools and thus has these macros in its headers. So the situation is that there is conflict on headers macros such as:
define PACKAGE_NAME "library"
define PACKAGE_NAME "mine"
So, I was wondering if there was a way to tell the autotools to define at least some of these macros inside some kind of structure as follows:
`struct header_information{
static string package_name;
static bug_report;
....
}`
and then initialize it with the right macro names.
This solution would keep these informations encapsulated and does not pollute the global namespace ?
It seems to me like you want to abuse a package-private, build-system-ony configuration header file (config.h) that just so happens to define a convenient macro name that you'd like to use. I think the pretty obvious answer is "don't do that", or else you're on your own.
Unless I'm misunderstanding you?
Those defines are there so that the particular library can use them. It's not meant for other things to include. In fact, the majority of the things in config.h are completely useless outside of the particular package.
That doesn't mean that the library that config.h file belongs to couldn't provide what you're looking for, by defining a public struct in a header that uses those variables. Or perhaps a library that uses pkg-config (if you're just looking for package names) can provide some of information for you. But I don't think that autotools would or should provide that information to you.
I have created a separate include files for general purpose uses in my assembly programs. (such as string operations / formatted input/etc.)
When i include those files i notice all of the functions get included in the target binary file.
Is there way I can manage to include only the used functions(like using include files in C/C++ library files)?
I'm using MASM and targeting x86.
To extract separate functions from an object file, the linker needs to know where each one starts and where it ends. It can't reliably tell that from the assembly, so you need to help it.
A common way is to put each function into a separate file and assemble them like that; this way the linker can include or exclude each object file independently. This is the simplest way and works with most assemblers, not just MASM, so I'd recommend trying it.
Another way could be to put each function into a separate segment; the MS linker can exclude unused segments but only if they're marked as so-called "COMDAT" (communal data). Unfortunately, MASM does not support setting this attribute.
There have been some work on adding this info to the OBJ file as a post-processing step, but unfortunately the archive with the tool seems to be gone from the Internet:
Function level linking with MASM
Additional links:
How to achieve "function level linking" with MASM? (includes a tool for semi-automated splitting into several files).
flat assembler - COMDAT support
MSDN forums - Comdat
JWASM:
Support for COFF COMDATs
The last link mentions "Support for COMDAT is added in jwasm v2.10."
I am wondering where the variables in
firebreath\build\{ProjectDir}\gen\global\config.h
should be modified best. I want to increase for example
#define FBSTRING_PLUGIN_VERSION "1.0.0.0"
But when I do this in the file directly, it is going to be overwritten next time I modify
my_WiXInstall/Sources/myInstaller.wxs (in VC++ 2010)
and build the WiX-project, because then all templated files are being re-build again (including config.h).
How is this done correctly? Do I use the wrong config.h or is it wrong to modify the mentioned wxs-file. Of course I could modify the "Generated" wxs-file, but that would mean keeping track of the version numbers in it by myself. That feels wrong too.
I am confused. Please help!
I have found the answer by myself: The variables/makros should be changed in
\firebreath\projects\{ProjectDir}\PluginConfig.cmake
They will then be distributed through the templates into all related files of the project.
I would like to do the following . I have declared a structure in my program and in run time when the program is being executed, if there is a user input, I should be able to create another new structure/edit that structure in my code. How can we do that? Is this what "A self modifying code"? Please clarify .Please give some examples .Thanks
Let me give an idea of what I wish to do , I have a "Structure/Class " called "student", which contains variables like "int roll_no" and "int reg_no". If the user wishes to add a new variable like "char name" in run time how can it be done?
Have a look on this:
http://bracha.org/Site/Talks.html
There is talk about reflection, which is probably what you want - reflection is not only about introspection (which most of developers already knows) but also about changing meaning of language constructs and runtime code manipulation.
Best languages for this kind of stuff are probably ruby and smalltalk.
If your language does not support these capabilities, you have still option to leverage code-generation - which is possible in almost every programming language but it is much easier in dynamic ones with "eval" support. For example this kind of stuff is possible even in C/C++ but your app has to embed compiler.
Java is good choice too (thx to classloaders and a lot of libraries for bytecode manipulation)
Oh, I've almost forgot, have a look on lisp and metacircular evaluation.
Sounds like you don't need to modify the existing code, but rather emit some new code in runtime. It is easy to do with any environment where your compiler is present in runtime. It is true for .NET, for JVM-based environments, various Lisps, etc.