At some point when a new processor architecture is implemented, the elf.h header file needs to be updated. Is there a central authority that "owns" or has responsibility for maintaining a canonical elf.h? Is there at least some form of registry for all the different machine type EM_* definitions?
Related
I have two ontologies ontology1.owl and ontology2.owl where the first depends on the second (ontology1.owl imports ontology2.owl).
I have an RDF file instance1.rdf that conforms to ontology1. instance1.rdf refers to individuals from instance2.rdf which conforms to ontology2.owl.
I have an application that employs instance1.rdf to do some specific logic. However, data from instance2.rdf are also required for the processing as instance1.rdf refers to individuals from instance2.rdf. Let's assume that all instances and ontologies are available on the web. For example:
http://www.example.com/ontology1.owl
http://www.example.com/ontology2.owl
http://www.example.com/instance1.rdf
http://www.example.com/instance2.rdf
QUESTION
The entry for my application should be instance1.rdf which the user should provide (or provide a link to it). However, it's not the user's responsibility to know the required instance2.rdf, it's rather the application responsibility and this can be known by encoding such dependency in instance1.rdf. Is there any elegant way to make instance1.rdf refer to instance2.rdf, so that my application knows where to retrieve instance2.rdf from and load it? The
NOTES
I do not want to use owl:import. The reason is that both files instance1.rdf and instance2.rdf are RDF files, I do not want to use owl constructs here.
A possible workaround is that in instance1.rdf, I create a special property, e.g., dependsOn, and set the value of the property to the link to instance2.rdf, and handle the rest in my application. Is this straightforward?
Vulkan has instance and device extensions, but I cannot find any information anywhere about what the difference between them is. What does it mean exactly if something is a device extension or an instance extension? Why is VK_KHR_external_memory a device extension and VK_KHR_external_memory_capabilities an instance extension? Why is it not just a single, unified extension system?
The difference between instance extensions and device extensions is the difference between instances and devices.
The Vulkan instance is the piece of code that is used to set up devices. It deals with things like enumerating VkPhysicalDevices and querying their properties, as well as the call to create VkDevices itself.
The Vulkan device is for dealing with Vulkan rendering systems.
Device extensions pertain to the behavior of a particular VkDevice object which was created with that extension activated. As such, that extension cannot describe the behavior of stuff that happens before the device is created.
External memory, for example, has obvious implications for the rendering system. So it is a device extension. However, particular VkPhysicalDevice objects have different properties that can be queried with regard to their external memory functionality. You need to be able to query these properties before you create the device, because if the device doesn't provide the properties you need, there's no point in making the device at all. Or at least, of making the device with that extension active.
But device extensions govern the behavior of a device. If you don't have a device yet because you haven't created one, because you're trying to decide whether to create one at all... what do you do?
Well, that behavior has to be an instance extension. It extends the part of Vulkan that deals with the set up for devices, not that governs the behavior of the device itself.
I'm interested to know what data is held in the MetaData annotation added to each Kotlin class.
But most fields give no more detail than
"Metadata in a custom format. The format may be different (or even absent) for different kinds."
https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/jvm/runtime/kotlin/Metadata.kt
Is there are reference somewhere that explains how to interpret this data?
kotlin.Metadata contains information about Kotlin symbols, such as their names, signatures, relations between types, etc. Some of this information is already present in the JVM signatures in the class files, but a lot is not, since there's quite a few Kotlin-specific things which JVM class files cannot represent properly: type nullability, mutable/read-only collection interfaces, declaration-site variance, and others.
No specific actions were taken to make the schema of the data encoded in this annotation public, because for most users such data is needed to introspect a program at runtime, and the Kotlin reflection library provides a nice API for that.
If you need to inspect Kotlin-specific stuff which is not exposed via the reflection API, or you're just generally curious what else is stored in that annotation, you can take a look at the implementation of kotlinx.reflect.lite. It's a light-weight library, the core of which is the protobuf-generated schema parser. There's not much supported there at the moment, but there are schemas available
which you can use to read any other data you need.
UPD (August 2018): since this was answered, we've published a new (experimental and unstable) library, which is designed to be the intended way for reading and modifying the metadata: https://discuss.kotlinlang.org/t/announcing-kotlinx-metadata-jvm-library-for-reading-modifying-metadata-of-kotlin-jvm-class-files/7980
Kotlin removes the Java "one top-level public class per file" restriction, which I've learned to love. I wonder if there are reasons for this discussed somewhere and whether there are some guidelines how to deal with this new freedom?
You can still use that Java rule as a convention and name your files after your classes. Or you can start putting more classes into a single Kotlin file, in which situation I'd recommend naming the files after their purpose. Each file will usually contain classes or other top-level elements that are related to each other (if they are not, maybe they don't belong to the same file in the first place?). There should be single word or a small number of words that express the purpose of all the classes in a single file, which is then a natural candidate for the file name.
On Kotling.org you can find the Coding Conventions document that answers to all your doubts.
If I may, I think these sections taken from the aforementioned page may be useful to you:
Source file names
If a Kotlin file contains a single class (potentially with related top-level declarations), its name should be the same as the name of the class, with the .kt extension appended. If a file contains multiple classes, or only top-level declarations, choose a name describing what the file contains, and name the file accordingly. Use camel humps with an uppercase first letter (e.g. ProcessDeclarations.kt).
The name of the file should describe what the code in the file does. Therefore, you should avoid using meaningless words such as "Util" in file names.
and...
Source file organization
Placing multiple declarations (classes, top-level functions or properties) in the same Kotlin source file is encouraged as long as these declarations are closely related to each other semantically and the file size remains reasonable (not exceeding a few hundred lines).
In particular, when defining extension functions for a class which are relevant for all clients of this class, put them in the same file where the class itself is defined. When defining extension functions that make sense only for a specific client, put them next to the code of that client. Do not create files just to hold "all extensions of Foo".
Refer to the document for any other concern you may have.
I think that the main point is chosing a coding convention that works for your team. That said, I think this Kotlin.org convention could be considered as a sort of standard, that I would expect to be at least known, if not followed, by any Kotlin developer, and the default choice for any project unless there are compelling reasons to change.
I'm undecided as to what classes I could have that could adapt to an existing system which is an online video game. Here's what I want to achieve:
Get a series of settings from objects in the server.
Listen for clients to connect.
For each client, check that the settings on the client correspond with those from the server.
If settings don't correspond (something has been tampered with), either disconnect the client or change their settings.
This will be handled by class that will act as an entry point and can serve as a form of controller.
Now, the settings are strewn accross a number of instances: players, weapons, flags, lights, etc. In procedural programming, I'd get all this information and store it an array. However, is there a better way of doing this according to an OO approach? Can I make one or more classes that will have the values of these settings and act as a form of facade?
Encapsulate the settings data and behavior into at least one object (i.e. Settings). Depending on how your system is constructed this becomes part of other objects' composition (e.g. Player, Weapon, etc...), perhaps via dependency injection, or referenced from some global context. Settings is responsible for validation the match between client and server (e.g. Settings.validateClientServerSettingsMatch()). In terms of retrieving individual settings, two possible approaches explicit or implicit.
Explicit
Your Settings object, or perhaps other entities that make its composition, have methods for each setting managed. So it could be something like Settings.getPlayerSettings().getSomeSetting() or 'Settings.getSomePlayerSetting()`. How nested really depends on your system. Either has the advantage of making clear what settings are available to the client development and it procides compile time type checking if you're using a language such as Java. The tradeoff is needing to alter an object every time a new setting comes into play.
Implicit
This just has a generic method in the Settings object - Settings.getSetting(settingName). This makes it very easy to add settings, at the expense of any sort of useful type checking, unless you do something on your own using some meta magic of sorts in a language such as Python or Ruby or large case statements in Java.