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
Related
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.
I am struggling trying to traverse an MDLAsset instance created by loading an SCNScene file (.scn).
I want to identify and extract the MDLMeshs as well as camera(s) and lights. I see no direct way to do that.
For example I see this instance method on MDLAsset:
func childObjects(of objectClass: Swift.AnyClass) -> [MDLObject]
Is this what I use?
I have carefully labeled things in the SceneKit modeler. Can I not refer to those which would be ideal. Surely, there is a dictionary of ids/labels that I can get access to. What am I missing here?
UPDATE 0
I had to resort to pouring over the scene graph in the Xcode debugger due to the complete lack of Apple documentation. Sigh ...
A few things. I see the MDLMesh and MDLSubmesh that is what I am after. What is the traversal approach to get it? Similarly for lights, and camera.
I also need to know the layout of the vertex descriptors so I can sync with my shaders. Can I force a specifc vertex layout on the parsed SCNScene?
MDLObject has a name (because of its conformance to the MDLNamed protocol), and also a path, which is the slash-separated concatenation of the names of its ancestors, but unfortunately, these don't contain the names of their SceneKit counterparts.
If you know you need to iterate through the entire hierarchy of an asset, you may be better off explicitly recursing through it yourself (by first iterating over the top-level objects of the asset, then recursively enumerating their children), since using childObjects(of:) repeatedly will wind up internally iterating over the entire hierarchy to collect all the objects of the specified type.
Beware that even though MDLAsset and MDLObjectContainerComponent conform to NSFastEnumeration, enumerating over them in Swift can be a little painful, and you might want to manually extend them to conform to Sequence to make your work a little easier.
To get all cameras,
[asset childObjectsOfClass:[MDLCamera class]]
Similarly, to get all MDLObjects,
[asset childObjectsOfClass:[MDLObjects class]]
Etc.
MDLSubmeshes aren't MDLObjects, so you traverse those on the MDLMesh.
There presently isn't a way to impose a vertex descriptor on MDL objects created from SCN objects, but that would be useful.
One thing you can do is to impose a new vertex descriptor on an existing MDL object by setting a mesh's vertexDescriptor property. See the MDLMesh.h header for some discussion.
Essentially, I have multiple XSD files for a file format, because it's the main method of configuring the program, so I need versions of it with English strings, versions with German strings, etc. And if the file says in its <schema> statement which XSD it's using, it seems like I should be able to go through it without ever making a string comparison.
e.g. I want to avoid doing this:
xmlNodePtr cur = xmlDocGetRootElement(doc);
if(!xmlStrncmp(cur->name, (const xmlChar *) "settings"))
{
// do things
}
Because the string "settings" will change depending on the xsd file used, it could be "paramètres" or "einstellungen," etc. Typically this is done with a separate stings file, but it seems like the xsd has all the information needed to function as that strings file.
However, it's unclear if for example, if the nth attribute in an element is defined by the XSD as optional with a default value, will libxml2 tell me it's the nth attribute, and give it the default value, when I iterate over the properties in the node?
Similarly, it seems like there should be a way to find out that an element is the nth element in the <xs:choice> or the nth item in the <xs:enumeration> but I can't for the life of me figure out how to do it.
e.g. in this enumeration:
<xs:restrict base="xs:string">
<xs:enumeration value="glucose"/>
<xs:enumeration value="fructose"/>
<xs:enumeration value="sucrose"/>
<xs:restrict>
"glucose" would be 0, "fructose" 1, "sucrose" 2, etc in the order that they appear.
Is there a decent way to do this?
Your troubles stem from the design decision that you've made to maintain parallel XSDs with semantically identical components yet lexically different names.
Don't do that.
It's a terrible design decision that'll undermine the benefits of a standard XML vocabulary. Choose a naming convention, including a single natural language, and use it consistently.
Save I18N for the translation of content (see Best Practices for XML Internationalization), not markup.
It is well known how to obtain a TODO list in Doxygen, typing:
\todo Item one
\todo Item two
and so on, but when something has been done, how to keep track of this?
If I have done item two I don't want to remove it, I want to mark it as done:
\todo Item ono
\done Item two
How do I do this?
I dug around in the Doxygen documentation and stumbled over the \xrefitem. It's supposed to be:
A generalization of commands such as \todo and \bug. It can be used to
create user-defined text sections which are automatically
cross-referenced between the place of occurrence and a related page,
which will be generated. On the related page all sections of the same
type will be collected.
The first argument is an identifier uniquely representing the
type of the section. The second argument is a quoted string
representing the heading of the section under which text passed as the
fourth argument is put. The third argument (list title) is used as the
title for the related page containing all items with the same key. The
keys "todo", "test", "bug" and "deprecated" are predefined.
So you could specify a new alias, e.g. "done" in your Doxyfile:
ALIASES += "done=\xrefitem done \"Implemented TODOs\" \"Implemented
TODOs\" "
And in your code you should be able to use the new "done" tag like all the others:
/// \done fixed broken function
According to the doxygen manual there is no such "inverse" of the \todo command. Perhaps you can just keep the \todo and mark it manually as done, somehow.
Unfortunately doxygen's Markdown doesn't seem to support strikethrough (unlike Stack Overflow's, obviously), that would otherwise have been a good and common choice. Perhaps you can set it up using custom styling and spans.
I'm not sure I got how to define private functions right.
When I'm writing a package mathematica, I just do this:
BeginPackage["myPackage`"]
myPublicFunction::usage="myPublicFunction blahblahblah";
Begin["Private"]
myPrivateFunction[input_]:= ... ;
myPublicFunction[input_]:= ... ;
End[]
EndPackage[]
Is this the correct way or am I missing something?
Yep, that's a correct way. It may pay off to understand some of the internal package mechanics. Mathematica contexts are similar to namespaces in other languages. They can be nested. Every symbol belongs to some context. At any given moment, some context is "current". Whenever a new symbol is created, the system must decide to which context the symbol will belong. This happens at parse-time. The fundamental quantity (variable) here is $ContextPath. It is basically the search path for symbols. It is a list of contexts, and whenever the system sees a new symbol, it tests if the symbol with the same short name (that is, the name of the symbol proper, without the context) exists in some context on the $ContextPath. If it does exist, then the given occurrence of the symbol will be associated with that existing one. If it does not, then the symbol is created in a current context. Note that this is a dynamic thing - if you change the $ContextPath at any moment, the next symbol occurrence can be associated with a different symbol.
Anyways, what BeginPackage does is that it simply replaces the current value of $ContextPath with just {youPublicPackageContext, "System'"}, plus possibly additional contexts that you publicly import through the second optional argument of BeginPackage. Therefore, all symbols that are in the "public" section, are parsed into the public context, if they are not in "System'" or other contexts that you import. And what EndPackage does is to restore the value of the $ContextPath to what it was before you started loading the package. So, technically the usage message is not the only way to make a symbol public in your main context - you could just as well simply type a symbol with a semicolon, like myFunction; (this practice is discouraged, I just mentioned it to clarify the mechanism). Now, what happens when you enter Begin["'Private'"] is that the current context becomes YourContext'Private' (a sub-context). The $ContextPath is not changed. Therefore, any symbol entered there, which does not exist in your public package or other imported packages (that is, contexts currently on the $ContextPath), automatically is parsed into the 'Private' subcontext.
What really makes these symbols private is that whenever you import your package into some other context (package), only the main package is added to the $ContextPath, but not its sub-packages. Technically, you can break encapsulation by manually adding YourPackage'Private' to the $ContextPath (say, PrependTo[$ContextPath, YourPackage'Private']), and then all your private functions and other symbols will become public in that particular context where you do the import. Again, this practice is discouraged, but it explains the mechanics. The bottom line is that the notion of private or public can be entirely understood when we know how symbols are parsed, and what are the manipulations with $ContextPath and $Context (another system variable giving the value of the current context), that are performed by commands such as Begin and BeginPackage. To put it another way, one could, in principle, emulate the actions of BeginPackage,Begin, End and EndPackage with a user-defined code. There are just a few principles operating here (which I tried to outline above), and the mechanism itself is in fact very much exposed to the user, so that if, in some rare cases, one may want some other behavior, one can make some "custom" manipulations with $ContextPath and Context, to ensure some non-standard way of symbol parsing and therefore, control package-scale encapsulation in some "non-standard" way. I am not encouraging this, just mentioning to emphasize that the mechanism is in fact much simpler and much more controllable than it may seem on the surface.