I call the function XLoadQueryFont(port->dpy, "8x13"), but it returns a NULL. I'm pretty sure I had this working before. If I type locate 8x13, one of the results is
/usr/share/fonts/misc/8x13.pcf.gz
I don't know what the function dislikes, and was wondering as to how to track the problem down.
Update:
Using "fixed" produced an app that executed.
Based on tofo's comments:
I had to install the xlsfonts binary on Arch to get xlsfonts. It listed adobe, lucida, bitstream and misc fonts. xlsfonts | grep misc returned
-misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1
-misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
Most probably you have deleted or corrupted your fonts.alias file in /etc/X11 (or similar location, depending on your distribution, can be anywhere in the font path).
The "8x13" is typically no name, but rather an alias that is defined in this file.
To ensure your server can use this font name, check that your fonts.alias file contains at least the lines (note your actual font names might vary)
8x13 -Misc-Fixed-Medium-R-SemiExpanded--13-120-75-75-C-80-ISO8859-1
8x13bold -Misc-Fixed-Bold-R-SemiExpanded--13-120-75-75-C-80-ISO8859-1
If those aliases are not present or don't resolve to a valid font, you cannot use the "8x13" name. More aliases can be defined as needed.
Related
I'd like to understand what makes ClearCase create paths like these (more than one ##):
\TUNE\Integration\XmlFiles\PM_Content##\main\integ_mp1601\4\CommunityLink.png##\main\integ_mp151\151x\1
Rather than the more typical (single ##):
\TUNE\Integration\XmlFiles\PM_Content\CommunityLink.png##\main\integ_mp160\160x\1
I don't seem to have a control over it and it is not immediately obvious to me why CC does that. And when it happens there seems to be nothing I can do to "convince" it to use the simpler format.
First, a bit of context:
'##' is linked with dynamic views
You can see that concept with version extended path: using a pathname_ccase syntax, you can add characters to the end of a relative or full path name, turning it into a VOB-extended path name.
VOB-extended path names that specify versions of elements are the most commonly used; they are called version-extended path names.
/vobs/proj/foo.c##/main/motif/4
That means you can:
The idea is: in a dynamic view, you can access (read the content of) any version of a file through the extended pathname.
Now, why multiple '##'?
The documentation adds:
This symbol is required to effect a switch from the standard file/directory namespace to the extended element/branch/version namespace.
There are two equivalent ways to think of ##:
When appended to the name of any element, the extended naming symbol turns off transparency (automatic version-selection).
Thus, you must specify one of the element's versions explicitly.
The extended naming symbol is part of an element's official name.
For example, foo.c is the name of a version (the particular version that appears in the view); foo.c## is the name of the element itself.
So with:
TUNE\Integration\XmlFiles\PM_Content##\main\integ_mp1601\4\CommunityLink.png##\main\integ_mp151\151x\1
You have:
PM_Content## the name of the element (folder) PM_Content at its version \main\integ_mp1601\4
CommunityLink.png## the name of the element (gile) CommunityLink.png at its version \main\integ_mp151\151x\1
That happens when the current PM_Content folder, visible in the view, no longer lists CommunityLink.png (which was deleted/rmname'd):
you need to select the right folder version (which does list the file)
then you can access to any version of the file you want
I have a class with a port of dimensions [x,y] which is connected to another class having a matching port. Now I want to provide value to these variables [x,y] through external function call in which I basically read a .xml file and obtain values for x and y. But Dymola gives an error for this since during compilation it comes out as a non fixed size array.
Screenshot of error is attached.
The array sizes are structural parameters and they usually cannot depend on external function calls because they should be known at compile time. This is however supported in for example OpenModelica where a dll of the external function is built and called and the results are fetched during model compilation.
The only way to support this in all tools is to generate the model using an external tool which reads the xml and changes the .mo file with the values read.
You could probably have something like Parameters.mo:
package Parameters
constant Integer nTube = <EXTERN_NTUBE>;
constant Integer nSeg = <EXTERN_NSEG>;
end Parameters;
and your external tool will read the XML and bind and in Parameters.mo which you can then use in your models via Parameters.nTube and Parameters.nSeg. Maybe it would be good to give some defaults so that it works to use this file directly:
package Parameters
constant Integer nTube = 1;
constant Integer nSeg = 2;
end Parameters;
and then your external tool will replace 1 and 2 with the needed values before compilation.
This should be improved in Dymola 2017 (without the need for modifying the Modelica code). In earlier versions of Dymola it should work if the you translate the C-functions called to compute nTube and nSeg.
If that does not help your complete code would be needed to analyze the problem.
Can anybody explain to me why XOpenDisplay() doesn't fail with bad display names? As long as the names follow the syntax convention, it always seems to succeed - even if the specified host name doesn't exist. XOpenDisplay() only seems to fail if the string uses a bad syntax, e.g.
d = XOpenDisplay("foobar"); // fails - presumably because of bad syntax in string
d = XOpenDisplay("foobar:0.0"); // works - although there is no host named "foobar"
When specifying a hostname that doesn't exist, XOpenDisplay() seems to fallback to $DISPLAY. Is that how it is supposed to be? I didn't find anything about these fallbacks in the Xlib documentation. If it is correct behaviour, is there a way to check whether the returned display really connected me to "foobar:0.0" or whether it is just a fallback to $DISPLAY?
That does seem like rather weak behavior, but http://tronche.com/gui/x/xlib/display/opening.html says:
The encoding and interpretation of the display name is implementation
dependent.
So it seems that this "interpretation" is allowed.
To tell if the default display was opened instead, you might try:
d_default = XOpenDisplay(NULL);
d = XOpenDisplay("foobar:0.0");
if (!d || d == d_default) {
// foobar:0.0 was not opened.
}
If this doesn't work because d and d_default are different even though referring to the same hardware, you might try comparing a field of the _XDisplay struct instead of the returned pointers, which are apparently pointing to different structs which somewhere must have similar data since they reference the same hardware. See the following reference for possibilities, but the simplest (if it works) might be to see if d->fd == d_default->fd.
Reference: http://xwindow.angelfire.com/page28.html
The only way I know of to force connection to a particular display is to stick the desired display name into the environment:
setenv("DISPLAY", "foobar:0.0", 1);
d = XOpenDisplay(0);
This is generally also desirable as the proper display name is also propagated to any child processes that are started, though if you want to avoid that, you could record the old $DISPLAY and restore it afterwards.
I was assigned to edit part of Ansi C application but my knowledge of pure C is just basics. Anyway current situation is I have map1_data1.h, map1_data2.h, map2_data1.h, map2_data2.h and variables in those files are always connected to the map name = map1_structure in map1_data1.h and so on.
In app there is #include for each file and in code then something like
if (game->map == 1){
mapStructure = map1_structure
} else {
mapStructure = map2_structure
}
I have to extend this to be able to load the map dynamicly so something like
void loadMap(int mapId){
mapStructure = map*mapId*_structure // just short for what i want to achieve
}
My first idea to do so was removing map name connection in variables name in map1_data.h and have just structure variable in there. That requires only one header file at time to be loaded and thats where I'm stucked. Havent found any clues to do so on google.
I would like to have it as variable as possible so something like #include "map*mapId*_data1.h" but should be ok to have 1 switch in one place in whole app to decide on what map to be loaded.
One more thing, the app keeps running for more than 1 game = it will load various maps in one run.
Judging from the comments, you have a single type, call it Map, which is a structure type containing a collection of different data types, including 3D arrays and points and so on. You need to have some maps built into the program; later on, you will need to load new maps at runtime.
You have two main options for the runtime loading the maps:
Map in shared object (shared library, dynamically loaded library, aka DLL).
Map in data file.
Of these two, you will choose the data file over the shared object because it is, ultimately, simpler and more flexible.
Shared Object
With option 1, only someone who can compile a shared library can create the new maps. You'd have a 'library' consisting of one or more data objects, which can be looked up by name. On most Unix-like systems, you'd end up using dlopen() to load the library, and then dlsym() to find the symbol name in that library (specifying the name via a string). If it is present in the library, dlsym() will return you a pointer.
In outline:
typedef void *SO_Handle;
const char *path_to_library = "/usr/local/lib/your_game/libmap32.so";
const char *symbol_name = "map32_structure";
SO_Handle lib = dlopen(path_to_library, RTLD_NOW);
if (lib == 0)
...bail out...
map_structure = dlsym(lib, symbol_name);
if (map_structure == 0)
...bail out...
You have to have some way of generating the library name based on where the software is installed and where extensions are downloaded. You also have to have some way of knowing the name of the symbol to look for. The simplest system is to use a single fixed name (map_structure), but you are not constrained to do that.
After this, you have your general map_structure read for use. You can invent endless variations on the theme.
Data file
This is the more likely way you'll do it. You arrange to serialize the map structure into a disk file that can be read by your program. This will contain a convenient representation of the data. You should consider the TLV (type-length-value) encoding scheme, so that you can tell by looking at the type what sort of data follows, and the length tells you how many of them, and the value is the data. You can do this with binary data or with text data. It is easier to debug text data because you can look at and see what's going on. The chances are that the difference in performance between binary and text is small enough (swamped by the I/O time) that using text is the correct way to go.
With a text description of the map, you'd have information to identify the file as being a map file for your game (perhaps with a map format version number). Then you'd have sections describing each of the main elements in the Map structure. You'd allocate the Map (malloc() et al), and then load the data from the file into the structure.
I typically code most of my C projects in Vim. I am comfortable with navigation, search and replace, and indexing via Ctags/Cscope.
One feature I would like to have, if possible, is a keymapping that will show the datatype for a variable under the cursor on screen.
For example, if my cursor is on a variable, "test123" (ie: int test123 = 0) is there a way to have the type (int) and some other details about the variable shown in another tab within Vim?
Also, is there something similar that would do the same for a struct variable, and show a list of all its members in the descriptive tab as well as the type (ie: struct)?
I've also noticed that sometimes while coding, I have a tab titled "[Scratch][Preview]" at the top of Vim that appears to fulfill this requirement, but I have no idea what triggers it (searches and Ctag searches don't seem to trigger it). It looks like so:
name: myStruct::instanceOfStrct| 2 cmd: /^ int instanceOfStrct;$/
.. (up a dir) | 3 kind: m
</code/test/test.c | 4 struct: myStruct
|+config/ | 5 access: public
|+lib/ | 6 filename: /code/test/test.c
I think this is something that already exists in Vim to some extent, but I have not idea how to work with it.
Thank you.
I do not know of any plugin that does what you want, however it should be quite possible using libclang. There is a fork of clang_complete that adds 'go to definition' functionality which is close to what you want. However development on that plugin seems to have stagnated.
Also the scratch buffer appears when doing autocompletion to give more information about a specific completion. It can be enabled and disabled using the completeopt setting.