I can't find in SimGrid documentation an expansions of abbreviations:
TMGR, TMGRTrace, XBT, SURF (Speeded up Robust Features?), SIRFJni, ModelPtr, CPUPtr, XbtDict.
How do they expand? Or where can I find info about it?
Most of these names are mostly historical, with no real meaning. Here is my understanding of these names. Other may disagree. I don't think that these things are documented, actually.
TMGR is trace manager
XBT is the reverse for TBX since it's the toolbox we use
SURF had only a french meaning, which is something like "server to use fake resources" (Serveur pour l'Utilisation de Ressources Factices), because at the beginning (back in 2003) we thought that it should be an external server. Now it's a part of the library as you know.
SurfJNI comes from Surf and JNI which is Java Native Interface, the technology allowing to call C++ code from Java.
(Something)Ptr is just a Pointer over the Something.
Related
The title says it all. But, are there too many files to be replaced and is there a risk? What I mean is, there are files like d3d11.dll. Could I replace the files with with something like d3d12.dll or something like that?
When code is compiled it uses 'headers' and usually links to 'libraries' which refer to functions inside the dll. When the game loads it maps the DLL into the address space of the executable so that the program can use features in the DLL.
So if the Game does D3D11_DrawTriangles, it will end up calling that feature in d3d11.dll. Dropping in the DX12 DLL won't work because the expected function is no longer there (and besides, the executable would still be looking for the 11 DLL - it wouldn't even load).
Upgrading from DX11 to DX12 is a major undertaking; the graphics APIs are very different.
Put another way: It's like someone dropped a Fiat engine into your Volvo. Would it work? How much effort would it be to rewire all the pipes and electronics to make it work?
I would like to use the helm-semantic-or-imenu command to navigate components of type annotated Python code, but whatever code analyzer is used to dentify the components doesn't seem to recognize the type annotated python code. Functions with the return type annotation doesn't get recognized at all and functions with annotated arguments show the type instead of the arguments names in the signatures
The main problem I have is that I do not properly understand the components that is involved in making this work (when it does work). Obviously it might help to somehow update the code analyzer, but in which project do I find that? helm? semantic? imenu? or as someone mentioned somewhere else with regards to code analysis python.el? I could really use some help getting started to solve this. If the code analyzer is found in python.el, can I then try to modify and make emacs use a local version preferentially over the installed one?
EDIT:
After making the initial post I finally made a break through in trying to figure out where the components come from. I searched for python*.el in all of the file systemsystem and discovered these:
./usr/share/emacs/26.2/lisp/cedet/semantic/wisent/python.elc
./usr/share/emacs/26.2/lisp/cedet/semantic/wisent/python-wy.elc
I found the source for emacs 26.2 and discovered that indeed it seems python-el is responsible for parsing python files for semantic. It also internally uses the python-wy for recognizing a large portion of the language components. But unfortunately that is where I hit a brick wall. I was hoping to be able to monkey patch the function that recognizes a function definition via an re or something, but semantic actually solves the problem the right way. So python-wy seems to be auto-generated from a formal grammar definition file (in emacs git admin/grammars/python.wy) and figuring out how to modify that it is unfortunately much beyond my abilities.
The semantic python backend doesn't appear to parse type annotations correctly (and there hasn't been much recent development on those libraries as far as I can tell). Since helm-semantic-or-imenu favors semantic when it is active, you can disable semantic altogether for python buffers unless you use its other features (personally I only use it for C/C++).
When the semantic mode-specific libraries are loaded they set imenu-create-default-create-index and imenu-default-goto-function, causing imenu to use semantic instead of python.el's imenu function.
To disable semantic support for your python files you can customize the semantic-new-buffer-setup-functions, only adding entries for modes you want semantic support for, eg. in your semantic hook (or alternatively with the customize UI),
(setq semantic-new-buffer-setup-functions
'((c-mode . semantic-default-c-setup)
(c++-mode . semantic-default-c-setup)
(srecode-template-mode . srecode-template-setup-parser)
(texinfo-mode . semantic-default-texi-setup)
;; etc.
;; (makefile-automake-mode . semantic-default-make-setup)
;; (makefile-mode . semantic-default-make-setup)
;; (makefile-gmake-mode . semantic-default-make-setup)
))
When converting a thrift object for nodejs:
thrift -r --gen js:node state_service.thrift
The following error is thrown:
[ERROR: /state_service.thrift:33] (last token was 'not') Cannot use
reserved language keyword: "not"
The lines in the code around 33 are:
typedef bool Not
struct Exp {
1: string left
2: Not not
3: BinaryOp op
4: AnyValue right
}
I am using the most recent Thrift version 0.9.2
Try to change the not to something else, i think the problem is that 'not' may have another meaning in the language that you choose to generate.
2: Not not
The solution is to not use the reserved language keyword, as advised by the Thrift compiler. These keywords are reserved for a reason. Thrift is a cross-language tool, and not is indeed a keyword in some of them.
I don't want to change the processing code only because of a faulty js converter.
I beg to differ. Faulty is something that does not work, altough it should. Thrift clearly tells you that what you are about to try is illegal (as of today) and what the problem is.
To put it another way: With Linux, you can put uppercase and lowercase letters in a file name (actually you can put a whole bunch of strange things in, but I'll make it easy). So creating a FILE and a file in the same folder will work perfectly. If you now take your program and run it on Windows, relying on that behaviour, you will sooner or later run into trouble and may start to complain you "dont want to change your processing code only because of that faulty OS".
Note that complaining will not help you out of the pothole, altough the endorphines emitted during that process will make sure you have a fun time. The solution is of course to wait until Microsoft fixed their faulty OS, because you make the rules. Correct?
Of course not. So if you feel the implementation is wrong - fine! This is Open Source, and nobody claimed perfection. You are free to provide a patch, and we will happily review it. But please make sure you tested it with all 20+ languages currently supported by Thrift.
In Common Lisp, quicklisp is a popular library management tool. I'm going to use that tool and I'm going to try and use CL-WHO. I use the SBCL 1.0.57 implementation. I'm going to answer my own question below.
As a beginner, it's not clear how ASDF and quicklisp actually work together. And so it's not clear how to actually use packages or libraries that you've downloaded through quicklisp in an external source file. The quicklisp FAQ, at least at this moment, does not help. In python, it's incredibly simple: you can just put 'import somemodule' and life is great. Is there an equivalent for CL+quicklisp?
If you search, you find many results. Here are some of the most relevant ones I've found:
Lisp importing/loading file
How to use packages installed by quicklisp?
When I was reading through these originally, at least one question came to mind: do I actually have to care about ASDF if I'm using quicklisp? Quicklisp seems to be a higher level management tool. Other people suggest using quickproject. But is that really necessary?
The analogy to Python's imports is the system definition... well, this is a very loose analogy, but, it's the way to go. You declare dependencies in the system definition and then in source code you expect it to be there, so that if you later refer to the bits of the foreign code, you just do it.
Eg. in the system definition you might have: (usually it would be in my-program.asd file)
(defsystem :my-program
:version "0.0.1"
:serial t
:description "My program"
:components ((:file "some-source-file"))
;; `some-external-package' here is the "import", i.e. here you
;; declared that you will be using code from this package.
;; ASDF will generally "know" how to get the code of that package
;; from here on. But if it doesn't, then there are ways to "help it"
;; similar to how in Python there's a procedure to prepare your local
;; files to be used by easy_install
:depends-on (:some-external-package))
Later on in your code you just assume that the some-external-package is available to your program, e.g.:
(some-external-package:exported-symbol)
should just work. ("Your code" is the some-source-file.lisp, you've specified in the components).
This is the ASDF documentation on how to define systems
After you have this file in the place where ASDF might find it*, assuming you have ASDF installed (available to your Lisp, SBCL comes bundled with it), you'd load this system using (asdf:load-system :my-program) Explained here.
* - A quick way to test it would be to do
(push "/path/to/your/system/definition/" asdf:*central-registry*)
Download cl-who through the instructions on the quicklisp page and run this:
#!/usr/bin/sbcl --script
(load "~/quicklisp/setup.lisp")
(ql:quickload "asdf")
(asdf:load-system 'cl-who)
(with-open-file (*standard-output* "out.html" :direction :output)
(cl-who:with-html-output (*standard-output* nil :indent t)
(:html
(:head
(:title "Test page"))
(:body
(:p "CL-WHO is really easy to use")))))
To the beginner, or someone who's really lazy, there's no reason why you should have to write 3 lines at the top instead of just one (like in python).
I have a game which uses std::wstring as its basic string type in thousand of places as well as doing operations with wchar_t and its functions: wcsicmp() wcslen() vsprintf(), etc.
The problem is wstring is not supported in R5c (latest ndk at the time of this writting).
I can't change the code to use std::string because of internationalization and I would be breaking the game engine which is used by many games ...
Which options do I have?
1 - Replace string and wstring with my own string classes
This would give me better platform independency, but it is ridiculous to reimplement the wheel.
I've already started with a COW implementation of strings. I need it to be COW because I use them as keys in hash_maps.
This is of course lots of work and error prone ... but it seems it is something I can do.
2 - Try to fix the NDK recompiling the STLPort with my own implementations of the wide char string functions of the C standart library (wcslen, mbstowcs ... )
This would be the preferable way ... but I have no idea how to do it :(
How do I replace a function (lets say wcslen) in the libstdc++.a or libstlport_static.a? (not sure where they are :()
And as well I'm not sure which functions I need to reimplement, I know wcslen is not working so I guess they should be all ...
3 - Do you have any other idea?
I can't wait for an official fix for this and I will have to go with option #1 if I can't realize how to do #2.
I've read somewhere that if you target 2.3 you can use wstrings, but I ought to target Android 2.1.
PS: Forgot to say I need to use STL of course, but no RTTI and I can live without exceptions.
Thanks in advance!
Try out CrystaX's NDK. It has had stl support long before the official google one. The current version (r5), which is based off the of the official ndk r5, is still beta 3, but it does have wchar_t support.
http://www.crystax.net/android/ndk-r5.php
I'm suffering from the same problem as you, but my only other thought is to load the strings via the JNI (as jstring* in native land), then convert them to UTF characters as necessary. Take a look at the available JNI string functions here:
http://download.oracle.com/javase/1.5.0/docs/guide/jni/spec/functions.html#string_operations
Qt provides an excellent copy-on-write, international-friendly string implementation, QString, that is LGPLed.
You could, in theory extract it from the Qt source and use it in your own project. You will find the QString implementation in src/corelib/tools/qstring.h and .cpp in a Qt source download. You would also need the QChar, QByteArray, QAtomic, and QNamespace includes/classes (all under the corelib folder,) and you should define QT_NO_STL_WCHAR when compiling. (For this I would compile by hand or using my own script/Makefile.) Not simple, but once you get it up and running your life will be a lot simpler. It's better than reinventing the wheel, because it comes with loads of convenience functions and features.
Rather than stripping out just QString, you could also just use the QtCore module as a whole. See the android-lighthouse project for a Qt port to Android. (Also, it might be better to get your sources from there than from the above "vanilla" link, regardless of what you do.)