I have a BAM file:
ERR174327.487900 99 chr9 80320323 60 101M = 80320752 530 AGGGACATTGGTCCAAAAGGTTTTAATTAACCATACACCCTGCTCTACAAATCTAAAAAACTGTAGGACAGTATTTTGAGTCTCCAAGTATCCAGTGATAA CCCFFFFFHHHHFIJJJJJJGIJJJJJJJJJJJJJJJJIJIJJJJJIIJJJIJIJJJJJJJGICEHIHFHH=BFFADFFDCCCDCDDDCCCDADC#>ADC# NM:i:0 AS:i:101 XS:i:0 RG:Z:group1
I need to read the optional fields NM:i:0 AS:i:101 XS:i:0 RG:Z:group1 in my C++ code. I am able to use the htslib library to read everything but those optional fields.
The source file for the htsib library is here on Github. Unfortunately, I am not able to find a function that can read those fields.
Q: How to read the optional fields with htslib?
in bam.h
/*!
#abstract Retrieve data of a tag
#param b pointer to an alignment struct
#param tag two-character tag to be retrieved
#return pointer to the type and data. The first character is the
type that can be 'iIsScCdfAZH'.
*/
static inline uint8_t *bam_aux_get_core(bam1_t *b, const char tag[2]);
Related
One of the most widely used functions for output generation in Omnet++ is recordScalar.
virtual void recordScalar (cComponent *component, const char *name, double value, opp_string_map *attributes=nullptr)=0
Is there a more comprehensive function than recordScalar that stores structured data as value instead of storing a double number? Or coding it ourselves.
Or coding a similar function to write mentioned outputs in a text file in the format of JSON by that function?
By structured data, I mean struct data type in c++. like this:
struct logtype {
int src;
int dest;
int messagescount; // the count of messages transmitted between src and dest and vice versa
};
Thanks
OMNeT++ does not contain ready to use tool for storing complex structures. However, OMNeT++ uses C++ and one can write own method that will store some data to a text file, or to a JSON file, or to any file.
I had a piece of code in IAR.
#if defined (__ICCARM__)
#define __vectors __root const uVectorEntry __vector_table[] # ".intvec"
#define __stack { .ui32Ptr = (uint32_t)Stack + sizeof(Stack) }
typedef union
{
void (*Handler)(void);
uint32_t ui32Ptr;
} uVectorEntry;
#endif
It needs to be redone for GCC.
Everything that after defining along the way is also independent of the compiler.
Perhaps only 1 line #define __vectors __root const uVectorEntry __vector_table[] # ".intvec" requires a reaction.
This is the startap file for stm32f103c8t6 (Cortex-M3).
More precisely a small piece of it.
So __vector_table[] must have 59 elemehts, and it is interrupt vector table.
__vectors is likely used in vector table definition in the form __vectors = { /* vector table elements */ };. Macro definition is as follows:
const uVectorEntry __vector_table[] is standard C declaration for a const table.
__root is an attribute that specifies that this object must not be removed by the compiler or linker even if it might seem unused.
# ".intvec" specifies that __vector_table should be placed in .intvec section by the linker.
__stack is likely used in the vector table to have the end address of stack, to initialize stack pointer at boot time.
To put it shortly, all non-standard parts are there to ensure that vector table is in correct location and is not removed.
Is the syntax for TypeScript comments documented anywhere?
And by any chance, does it now support the C# /// system?
Current
The TypeScript team, and other TypeScript involved teams, created a TSDoc specification. https://tsdoc.org/
Example straight from the docs:
export class Statistics {
/**
* Returns the average of two numbers.
*
* #remarks
* This method is part of the {#link core-library#Statistics | Statistics subsystem}.
*
* #param x - The first input number
* #param y - The second input number
* #returns The arithmetic mean of `x` and `y`
*
* #beta
*/
public static getAverage(x: number, y: number): number {
return (x + y) / 2.0;
}
}
Past
TypeScript uses JSDoc. e.g.
/** This is a description of the foo function. */
function foo() {
}
To learn jsdoc : https://jsdoc.app/
But you don't need to use the type annotation extensions in JSDoc.
You can (and should) still use other jsdoc block tags like #returns etc.
Just an example. Focus on the types (not the content).
JSDoc version (notice types in docs):
/**
* Returns the sum of a and b
* #param {number} a
* #param {number} b
* #returns {number}
*/
function sum(a, b) {
return a + b;
}
TypeScript version (notice the re-location of types):
/**
* Takes two numbers and returns their sum
* #param a first input to sum
* #param b second input to sum
* #returns sum of a and b
*/
function sum(a: number, b: number): number {
return a + b;
}
Update November 2020
A website is now online with all the TSDoc syntax available (and that's awesome): https://tsdoc.org/
For reference, old answer:
The right syntax is now the one used by TSDoc. It will allow you to have your comments understood by Visual Studio Code or other documentation tools.
A good overview of the syntax is available here and especially here. The precise spec should be "soon" written up.
Another file worth checking out is this one where you will see useful standard tags.
Note: you should not use JSDoc, as explained on TSDoc main page: Why can't JSDoc be the standard? Unfortunately, the JSDoc grammar is not rigorously specified but rather inferred from the behavior of a particular implementation. The majority of the standard JSDoc tags are preoccupied with providing type annotations for plain JavaScript, which is an irrelevant concern for a strongly-typed language such as TypeScript. TSDoc addresses these limitations while also tackling a more sophisticated set of goals.
You can add information about parameters, returns, etc. as well using:
/**
* This is the foo function
* #param bar This is the bar parameter
* #returns returns a string version of bar
*/
function foo(bar: number): string {
return bar.toString()
}
This will cause editors like VS Code to display it as the following:
You can use comments like in regular JavaScript:
1 Introduction
[...] TypeScript syntax is a superset of ECMAScript 2015 (ES2015) syntax.
2 Basic Concepts
[...] This document describes the syntactic grammar added by TypeScript [...]
Source: TypeScript Language Specification
The only two mentions of the word "comments" in the spec are:
1 Introduction
[...] TypeScript also provides to JavaScript programmers a system of optional type annotations. These type annotations are like the JSDoc comments found in the Closure system, but in TypeScript they are integrated directly into the language syntax. This integration makes the code more readable and reduces the maintenance cost of synchronizing type annotations with their corresponding variables.
11.1.1 Source Files Dependencies
[...] A comment of the form /// <reference path="..."/> adds a dependency on the source file
specified in the path argument. The path is resolved relative to the directory of the containing source file.
TypeScript is a strict syntactical superset of JavaScript hence
Single line comments start with //
Multi-line comments start with /* and end with */
I have a code compiled with ghs compiler in which the sections have been defined in c code as
#pragma ghs section data = ".shareddata"
// some c code
#pragma ghs section data = default
how do we define pragmas for sections using gcc for the above thing
In general, gcc discourages the use of pragmas, instead suggesting that you use attributes for both functions and variables.
From the GCC manual ("Declaring Attibutes of Functions"):
Normally, the compiler places the code it generates in the text section. Sometimes, however, you need additional sections, or you need certain particular functions to appear in special sections. The section attribute specifies that a function lives in a particular section. For example, the declaration:
extern void foobar (void) __attribute__ ((section ("bar")));
puts the function foobar in the bar section.
From "Specifying Attributes of Variables"
Normally, the compiler places the objects it generates in sections like data and bss. Sometimes, however, you need additional sections, or you need certain particular variables to appear in special sections, for example to map to special hardware. The section attribute specifies that a variable (or function) lives in a particular section. For example, this small program uses several specific section names:
struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };
struct duart b __attribute__ ((section ("DUART_B"))) = { 0 };
char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };
int init_data __attribute__ ((section ("INITDATA")));
main()
{
/* Initialize stack pointer */
init_sp (stack + sizeof (stack));
/* Initialize initialized data */
memcpy (&init_data, &data, &edata - &data);
/* Turn on the serial ports */
init_duart (&a);
init_duart (&b);
}
Use the section attribute with global variables and not local variables, as shown in the example.
You may use the section attribute with initialized or uninitialized global variables but the linker requires each object be defined once, with the exception that uninitialized variables tentatively go in the common (or bss) section and can be multiply “defined”. Using the section attribute changes what section the variable goes into and may cause the linker to issue an error if an uninitialized variable has multiple definitions. You can force a variable to be initialized with the -fno-common flag or the nocommon attribute.
Some file formats do not support arbitrary sections so the section attribute is not available on all platforms. If you need to map the entire contents of a module to a particular section, consider using the facilities of the linker instead.
I'm baffled by this one.... SQLite is a separate project and part of a Workspace. When building the target, LLVM is complaining:
<path>/sqlite3.c:44924:24: Incomplete definition of type 'struct Btree'
That's at line 44924 (and 14 other places following 44924). Here's what else I am seeing:
7145: /* Forward declaration */
7146: typedef struct Btree Btree;
...
11378: struct Btree {
11379: sqlite3 *db; /* The database connection holding this btree */
11380: BtShared *pBt; /* Sharable content of this btree */
11381: u8 inTrans; /* TRANS_NONE, TRANS_READ or TRANS_WRITE */
11382: u8 sharable; /* True if we can share pBt with another db */
11383: u8 locked; /* True if db currently has pBt locked */
11384: int wantToLock; /* Number of nested calls to sqlite3BtreeEnter() */
11385: int nBackup; /* Number of backup operations reading this btree */
11386: Btree *pNext; /* List of other sharable Btrees from the same db */
11387: Btree *pPrev; /* Back pointer of the same list */
11388:#ifndef SQLITE_OMIT_SHARED_CACHE
11389: BtLock lock; /* Object used to lock page 1 */
11390:#endif
11391:};
...
44919: static void lockBtreeMutex(Btree *p){
44920: assert( p->locked==0 );
44921: assert( sqlite3_mutex_notheld(p->pBt->mutex) );
44922: assert( sqlite3_mutex_held(p->db->mutex) );
44923:
44924: sqlite3_mutex_enter(p->pBt->mutex);
44925: p->pBt->db = p->db;
44926: p->locked = 1;
44927: }
I also tried renaming the struct at 11378 to struct Btree_S (and changed the typedef). Same problem.
I guess my question is, how can it be incomplete? Any ideas?
Ensure that sqlite3.c is compiled as C, not C++.
Found the answer.... The preprocessor macro SQLITE_HAS_CODEC=1 was not defined. Why was it not defined? Because of Xcode 4: Project does not honor $(inherited) Build Setting in Workspace?.
$(inherited) does not work in Xcode 4 as expected across projects in a parent/child relationship (despite what the IDE's tree view shows us), and what the documentation implies about $(inherited).
Xcode configuration files (xcconfig) do not work as expected either. I could not get the configuration file assigned to other child projects (only the top level project).
Apple should fire their entire QA department and technical writers, and hire a new bunch of ID10Ts.