After the engine analyzing each byte of the binary WebAssembly module, how does it organize and store the section information? For instance, let's say the Type Section has several entities with a kind func_type, and each func_type also has many of its own fields. How does V8 store those info from the perspective of the c++ code and the overall engine?
The WasmModule class has a list (well, a std::vector) of function signatures, as well as other data read from the module's wire bytes; see here: https://cs.chromium.org/chromium/src/v8/src/wasm/wasm-module.h?sq=package:chromium&g=0&l=185. You can find most of the other class definitions further up in the same file.
Related
Is it possible to generate structure classes from a custom StructureDefintion in a similar fashion as HAPI generates official DSTU2/3 structure classes?
I want to implement some local StructureDefinition from simplifier.net (For example: https://simplifier.net/NictizSTU3/nl-core-address/).
The documentation of HAPI wasn't helping me either, am i suppose to use the hapi-tinder-plugin?
It seems tedious and error prone to hand write custom structures as specified in http://hapifhir.io/doc_custom_structures.html
For me the ideal workflow is something like:
Fetch StructureDefinition from simplifier
Generate models for the StructureDefinition
Register generated models in HAPI and fill the models accordingly
Generating classes from profiles is on our list of things to do, but doing it well (particularly when there's slicing involved) isn't super-easy, so most of the reference implementations have been holding off until there's funding support to get it done.
When writing a kernel module, can programmer make use of data structures, like task_group, task_struct, already defined in kernel?
Yes, after including corresponding header, kernel module can use anything that is defined in that header: data structures, macros, static inline functions...
As for functions, declared in the header file and implemented in kernel's source file, only those which are exported using EXPORT_SYMBOL/EXPORT_SYMBOL_GPL can be used in modules.
Kindly regret if this question is silly. I am finding it difficult to get what it really means.When i read 'Hadoop the definitive guide' it says that the best advantage of avro is that code generation is optional in Avro. This link has a program for avro serialization/deserialization with/without code generation. Could some one help me in understanding exactly what with/without code generation mean and the real context of the same.
It's not a silly question -- it's actually a very important aspect of Avro.
With code-generation usually means that before compiling your Java application, you have an Avro schema available. You, as a developer, will use an Avro compiler to generate a class for each record in the schema and you use these classes in your application.
In the referenced link, the author does this: java -jar avro-tools-1.7.5.jar compile schema student.avsc, and then uses the student_marks class directly.
In this case, each instance of the class student_marks inherits from SpecificRecord, with custom methods for accessing the data inside (such as getStudentId() to fetch the student_id field).
Without code-generation usually means that your application doesn't have any specific necessary schema (for example, it can treat different kinds of data).
In this case, there's no student class generated, but you can still read Avro records in an Avro container. You won't have instances of student, but instances of GenericRecord. There won't be any helpful methods like getStudentId(), but you can use methods get("student_marks") or get(0).
Often, using specific records with code generation is easier to read, easier to serialize and deserialize, but generic records offer more flexibility when the exact schema of the records you want to process isn't known at compile time.
A helpful way to think of it is the difference between storing some data in a helpful handwritten POJO structure versus an Object[]. The former is much easier to develop with, but the latter is necessary if the types and quantity of data are dynamic or unknown.
I've been using mogenerator for a while now, and while there is a reasonable Getting Started Guide and a Stack Exchange article on the command line options, I haven't found a good guide for all of the functionality it provides.
In short: what, above and beyond the classes that Core Data provides for you, what does mogenerator actually generate?
(Frankly, I kept finding little pleasant surprises in the headers/implementations that I didn't realize were in there and I decided to step through the mogenerator templates and code and document what I found in a Stack Exchange Q&A. I'd love to see additional answers and edits, however. )
In addition to its core feature of a two class system, mogenerator helps you by automatically implementing a number of best practices regarding Core Data in your machine header and implementation files.
Property Accessors
Methods to access the attributes of your Entities are the core of what mogenerator generates. But there are some nice features implemented in the accessors above and beyond what the out of the box Xcode class generator provides to you.
Scalar Accessors
Xcode's built in generator gives you the option of "use scalar properties for primitive data types". This option gives you choice of having Xcode create properties with NSTimeIntervals instead of NSDates for date types, BOOLs instead of NSNumbers for boolean types, and int16_t (or similar) rather than NSNumbers.
I find this infuriating because most of the time I prefer the primitive types, but not for NSDates which are much more useful than a NSTimeInterval. So Core Data is giving me the choice of objects, in which case I will be constantly unboxing stuff and making stupid mistakes like if(myBooleanAttribute) (which is always YES because myBooleanAttribute is a NSNumber, not a BOOL). Or I can have scalars, but in that case, I get NSTimeIntervals that I'll always have to convert to NSDates. Or I can hand edit all of the generated files by hand to give me my desired mix of NSDates and BOOLs.
On the other hand, mogenerator provides you with both options. For example, you will get both a myBooleanAttribute getter that gives you an NSNumber (for easy storage in an NSArray) and a myBooleanAttributeValue getter that gives you an actual BOOL. Same with integers and floats. (Mogenerator does not generate NSTimeInterval accessors: only NSDates.)
Typed Transformable Properties
If you have a transformable property, you can set a specific UserInfo key ( attributeValueClassName ) in the attribute that will specify the class that your property will return/accept. (And it will properly forward declare the class etc.) The only place I found this documented was on Verious.
In contrast, the Xcode code generator will only type these transformable attributes as id types.
Validation Declaration
While mogenerator does not automatically generate any validation methods, it does include the proper signature as a comment in the machine h file. The seems to largely be for historical reasons, but it does mean that it is easy to copy and paste the signature if you decide to implement it in your human file implementation. (I wouldn't actually uncomment the declaration as you aren't supposed to call validation directly.)
Primitive Accessors
Core Data already provides you these accessors to the primitive values, but for some reason doesn't include them in its Xcode generated headers. Having mogenerator include them in its header files makes it much easier to access a primitive value.
Fetched Properties
mogenerator will generate accessors for fetched properties. As far as I can tell there is no way to have the Xcode generator do this.
Helper methods
Automatic NSFetchedResultsController generation
If you have a to many relationship in your Entity and you pass --template-var frc=true into mogenerator, mogenerator will automatically generate a method to create a fetch request for the child objects associated with a parent object. It even automatically generates a unique cache name, and isolates everything inside an #if TARGET_OS_IPHONE preprocessor macro.
Even if this doesn't fit your particular needs, it is a great example of how the templates can be extended.
+fetchMyFetchRequest:moc_
If you like defining your fetch requests in the model, this is a lot better way to retrieve them than hardcoded strings.
-MyEntitySet
Mogenerator uses the magic of KVC to give you a NSMutableSet proxy into your relationships.
+entityName
Need to provide a entity name to a NSFetchRequest or other Core Data method? It's easy to avoid hard coded strings by using this simple method that returns the name of the entity as an NSString.
+insertInManagedObjectContext: and entityInManagedObjectContext:
Another way to avoid hardcoding entity names is to use these helper methods.
Typed object ids
Each of your headers and implementations also includes a MyEntityID class. They are empty interfaces and implementations that merely subclass the NSManagedObjectID class. Also, each model class has a helper method called objectID that overrides the standard objectID method in NSManagedObject. The helper method does nothing but cast the superclass's return value to the MyEntityID type.
The net result: the compiler can catch your mistakes if you ever accidentally interchange your object ids from different entities.
Miscellaneous
Subclassing a Custom Superclass
One of the command line options is --base-class: which allows you to specify a base class that all of your generated classes will inherit from. This is very useful, either so that you can have a base class where you define convenience methods (which, given Core Data, you probably should) or so you can use an off the shelf Core Data toolkit like SSDataKit (or both).
includem
A simple little thing, but if you specify a --includem argument, mogenerator will generate a header file that includes all of your model header files. Convenient if you want to include all of your headers in a PCH, or something some other standard header you include.
Const Definitions of All Attributes, Relationships, Fetched Properties
An extern declaration of a struct is included in the header that has an NSString defined for every attribute and relationship defined in your Entity. This allows you to define predicates and other parameters, without baking the names of your entities into your strings. For example,
req.predicate = [NSPredicate predicateWithFormat:
#"(%K == YES) AND (%K <= %#)",MyObject.favorite, MyObject.availableDate, [NSDate date]];
(This type of struct used for "namespaced" constants is described My Mike Ash on his blog
const Definitions of User Info Keys/Values
Similarly an extern declaration of a struct is defined in the header that includes the keys as members of the struct, and the values as a values. i.e.
NSLog(#"User info for key my key is %#",MyObjectInfo.mykey) //will log "myvalue"
Alternate Templates
One of the interesting things about mogenerator is that in building mogenerator its author (Wolf Rentzsch) has basically built a generic parser and templating engine for the xcdatamodel files produced by Xcode. So you don't need to use the mogenerator templates. You can provide your own with a simple command line argument. There are lots of user contributed templates on the GitHub site.
In fact, you don't even have to use Core Data. Many of the contributed templates allow you to generate a series of ordinary NSObject model classes based on the data model. (So called PONSOs: "plain old nsobjects"). Want to use the data modeler in Xcode, but some other persistence mechanism? mogenerator can help you there.
You don't even need to generate objects at all: another interesting submitted template just provides a diff of two different model versions.
In iOS SDK, NSDictionary has got writeToFile and dictionaryWithContentsOfFile methods to write a dictionary into a file and to read the contents of a file as dictionary. Is it possible to do the same in WP7 (C#) ?
Yes, but you have to serialize the dictionaary and write to a file yourself.
Alternatively you could add to IsoaltedStorageSettings and let the framework do the serialization for you.
I believe the SilverlightSerializer library is capable of serializing a dictionary; you could serialize your dictionary to a byte array and write it to Isolated Storage.
SilverlightSerializer examples: http://whydoidoit.com/silverlight-serializer/
Or try SharpSerializer, there's a WP7 version available (and a NuGet package): http://www.sharpserializer.com/en/tutorial/index.html
#saikamesh, Here is a thread that covers XML serialization of dictionary in .NET. Why isn't there an XML-serializable dictionary in .NET?. It lists a number of different approaches. You can then write the output string to a file in isolated storage.
You can find mappings of iPhone classes to Windows Phone classes at iPhone and Android to WP7 mapping site
Isolated storage provides a file system. Serialisation is an orthogonal problem.
It is possible to write any object graph into IsolatedStorageSettings provided every object in the graph is DataContract serialisable. Many common framework types are not, for example GeoCoordinate.
Arguably, IsolatedStorageSettings is a dictionary. But the caveat stands regarding DataContract seralisability.
It is equally possible and a lot smarter to write your dictionary to a file, because the more you store in ISS the longer it takes to instantiate. This can seriously affect app load and resume times. You will still have to manage serialisation yourself to the extent that unsupported classes are involved. Your biggest handicap would be the absence of BinaryFormatter from the framework (I don't know whether Mango adds it.)