For instance, I saw the following line in ATSLIB:
#define ATS_PACKNAME "ATSLIB.libats.deqarray"
What is the meaning of this line? What purpose does it serve?
Say you declare a function in a file XYZ.dats:
extern fun foo (...): ...
The ATS compiler generates a global name for foo using the full path
of XYZ.dats, which is often hard to read.
If the flag ATS_PACKNAME is set, then the global name for foo is
${ATS_PACKNAME}foo, where ${ATS_PACKNAME} is the string value of
ATS_PACKNAME.
http://discourse.ats-lang.org/t/ats-packname/645/2
Related
When I type list mystruct into gdb, I receive the lines of code used to define mystruct. How can I ask gdb to give me the file it is reading from to print those lines? Getting that file from the gdb python interface would be preferable. The more easily parsable the better.
Thanks!
For showing definition of a type there is a command ptype:
$ ptype mystruct
...
To know where type is defined, command info types regex:
$ info types ^mystruct$
<filename>:<line>
And to print lines of source file, command list filename:start_line,filename:end_line:
$ list myfile.c:100,myfile.c:110
if not enough
$ list +
Note that there is possible several same type definitions, so info types can give several locations.
Update
Since this is a matter of compatibility between compiler (that generates debugging information, e.g. DWARF) and gdb that reads it, for some reason, it's not always possible to retrieve detailed information, e.g. line number. This can be workaround-ed by using specific tools, e.g. for DWARF there is a dwarfdump tool, that has access to all DWARF information in the file. The output for structure type
struct mystruct {
int i;
struct sample *less;
}
looks like:
$ dwarfdump -ie ./a.out
...
< 1><0x00000079> structure_type
name "mystruct"
byte_size 0x0000000c
decl_file 0x00000002 ../sample.h
decl_line 0x00000003
sibling <0x000000a8>
< 2><0x00000085> member
name "i"
decl_file 0x00000002 ../sample.h
decl_line 0x00000004
type <0x0000004f>
data_member_location 0
< 2><0x0000008f> member
name "less"
decl_file 0x00000002 ../sample.h
decl_line 0x00000005
type <0x000000a8>
data_member_location 4
Here you have information on which line not only type declaration starts, but also line number for each member.
The output format is not very convenient, and heavy - you should write your own parser. But it could be better to write your own tool using libdwarf or utilize pyelftools on python. Here is one of examples.
In case you have compiled with debug information (-g3) option,
you can use:
info macro mystruct
e.g
info macro SOCK_RAW
(gdb) info macro SOCK_RAW
Defined at /usr/include/x86_64-linux-gnu/bits/socket_type.h:33
included at /usr/include/x86_64-linux-gnu/bits/socket.h:38
included at /usr/include/x86_64-linux-gnu/sys/socket.h:38
included at /home/nirl/cpp_tut/filter/filter.cpp:1
``
Is it possible to typeset -i (synonymous with declare -i, see a manpage or a reference) in bash without assigning to a variable?
Consider the following example:
typeset -i a=42;
foo $a;
Is it possible to achieve the same functionality without using a helper variable?
Assume foo is not editable (for example, a binary) with reasonable ease.
Put the declaration of type inside the function's body. You can use either declare or (to be more explicit) local for this:
foo() {
local -i arg=$1
....
}
No other solution is possible without modifying the function's body (or adding a wrapper which performs typechecking before passing the arguments as untyped strings), as arguments to functions (and to external commands) are passed as strings, regardless of any type declarations which may have been made beforehand.
Technically, I'm using Tagbar in vim to view a file's tags, but this question should apply generally to exuberant ctags, v5.8.
Suppose I've got the following python file, call it foo.py:
class foo:
def bar(baz):
print(baz)
Let's run ctags on it: ctags foo.py. The resulting tags file looks like this:
!_ some ctags version / formatting stuff not worth pasting
bar foo.py /^ def bar(baz):$/;" m class:foo
foo foo.py /^class foo:$/;" c
The bit I'm interested in is the last field of the second line, class:foo. That's the scope of the bar() function. If I use tagbar in vim, it nests the function in the class accordingly.
Now suppose I'm adding support for a new language in my ~/.ctags. In fact, I'm adding support for this puppet file:
class foo {
include bar
}
Suppose I use the following ~/.ctags arguments. The 'import' regex is ugly (errr... ugly for regex) but it gets the job done enough for this example:
--langdef=puppet
--langmap=puppet:.pp
--regex-puppet=/^class[ \t]*([:a-zA-Z0-9_\-]+)[ \t]*/\1/c,class,classes/
--regex-puppet=/^\ \ \ \ include[ \t]*([:a-zA-Z0-9_\-]+)/\1/i,include,includes/
That generates the following tag in my tags file:
bar foo.pp /^ include bar$/;" i
foo foo.pp /^class foo {$/;" c
Notice neither line contains scoping information. My question is this: Is there anyway for me to construct the --regex-puppet argument, or --regex-<LANG> lines generally, to collect information about a tag's scope? To perhaps declare that tags meeting criterion A are always going to be scope-parents of tags meeting criterion B?
man ctags suggests no clear way to add arbitrary scope information, but I might be overlooking another solution (snipped slightly for emphasis):
--regex-<LANG>=/regexp/replacement/[kind-spec/][flags]
Unless modified by flags, regexp is interpreted as a Posix extended regular expression. The replacement should expand for all matching lines to a non-empty string of
characters, or a warning message will be reported. An optional kind specifier for tags matching regexp may follow replacement, which will determine what kind of tag is
reported in the "kind" extension field (see TAG FILE FORMAT, below). The full form of kind-spec is in the form of a single letter, a comma, a name (without spaces), a
comma, a description, followed by a separator, which specify the short and long forms of the kind value and its textual description (displayed using --list-kinds). Either
the kind name and/or the description may be omitted. If kind-spec is omitted, it defaults to "r,regex". Finally, flags are one or more single-letter characters having the
following effect upon the interpretation of regexp:
b The pattern is interpreted as a Posix basic regular expression.
e The pattern is interpreted as a Posix extended regular expression (default).
i The regular expression is to be applied in a case-insensitive manner.
No, unfortunately that is not possible with the regex pattern support in ctags. The only way to get ctags to generate correct scopes is to write a parser as an additional module in C. I would like to add support for a better handling of new languages to ctags if I find the time, but so far that hasn't worked out and I'm also still unsure about the best approach.
If you're mostly interested in Tagbar support there is another approach, though: Tagbar supports arbitrary tag-generating programs as long as their output is compatible to the ctags one, so you could write a simple parser in, say, Python and configure Tagbar to use that. Have a look at :h tagbar-extend (especially the last subsection "Writing your own tag-generating program") if that would be an option for you.
I'm working on such feature at universal ctags project:
https://github.com/universal-ctags/ctags/pull/562
.
(Don't expect too much; regex parser is not enough for complicated syntax.
The new feature is for a language with simple syntax.)
Example 1::
$ cat /tmp/input.foo
class foo:
def bar(baz):
print(baz)
class goo:
def gar(gaz):
print(gaz)
$ cat /tmp/foo.ctags
--langdef=foo
--map-foo=+.foo
--regex-foo=/^class[[:blank:]]+([[:alpha:]]+):/\1/c,class/{scope=set}
--regex-foo=/^[[:blank:]]+def[[:blank:]]+([[:alpha:]]+).*:/\1/d,definition/{scope=ref}
$ ~/var/ctags/ctags --options=/tmp/foo.ctags -o - /tmp/input.foo
bar /tmp/input.foo /^ def bar(baz):$/;" d class:foo
foo /tmp/input.foo /^class foo:$/;" c
gar /tmp/input.foo /^ def gar(gaz):$/;" d class:goo
goo /tmp/input.foo /^class goo:$/;" c
Example 2::
$ cat /tmp/input.pp
class foo {
include bar
}
$ cat /tmp/pp.ctags
--langdef=pp
--map-pp=+.pp
--regex-pp=/^class[[:blank:]]*([[:alnum:]]+)[[[:blank:]]]*\{/\1/c,class,classes/{scope=push}
--regex-pp=/^[[:blank:]]*include[[:blank:]]*([[:alnum:]]+).*/\1/i,include,includes/{scope=ref}
--regex-pp=/^[[:blank:]]*\}.*//{scope=pop}{exclusive}
$ ~/var/ctags/ctags --options=/tmp/pp.ctags -o - /tmp/input.pp
bar /tmp/input.pp /^ include bar$/;" i class:foo
foo /tmp/input.pp /^class foo {$/;" c
I would like to use both the InnoIDE and ISCC/ISPP, the difference being that I would like to pass in a parameter, which will override a #define in the script.
In the command line I can pass /Dmyarg=myvalue. That is the same as #define myarg myvalue in the script.
Sadly, the script takes precedence over the command line value. I know, as I tried. I can obviously comment out the #define in the script and the command line define will work, however then I will not be able to use the IDE to build.
Is it possible to set a #define inside InnoIDE somewhere for the project or is there some means to have the command line #define take precedence?
In your script, do something like this:
#ifndef myarg
# define myarg "mydefault"
#endif
Now, if you compile in the IDE or if you use the command line without specifying /Dmyarg="something", then it will use the default specified in the script. Otherwise, if you do specify something on the command line then it will use that instead.
Consider the following code:
$ANIMAL = COW PIG CHICKEN VAMPIRE
all:
#echo $(ANIMAL, F, >.txt)
I strove to find a section in GNU make manual that mentions the above syntax, but I couldn't find anything related to it. What does it print and how is the syntax structured for the functionality?
Added: When a line starts with "#--" what does it mean?
#-- $(GEN_ENV); ...
To answer your addition: In regular Makefiles (read: POSIX, GNU, ...)
a leading '#' supresses echoing of the command.
a leading '-' says to ignore a non-zero exit status
both can be combined, and repetitions are okay, so #---###-#---echo foo is the same as #-echo foo
This is called "macro modifiers". This is not a GNU make feature. Take a look at this chapter of OPUS make tutorial. The general syntax of these modifiers:
$(name,modifier[,modifier]...)
name is macro expanded, then each modifier is applied in succession to the elements of the expanded value.
Take a look then at the list of modifiers and it becomes clear that it forms a list of file names (truncates paths of each variable in ANIMAL) with .txt added. So, in your case it shoud output:
COW.txt PIG.txt CHICKEN.txt VAMPIRE.txt
PS
I looked through the reference mentioned above and don't think the first line ($ANIMAL = ) is correct since macro definition should start without $.
Based on your comments it seems you are actually using OpusMake, rather than GNU make. You can find more information about it on the Opus Software, Inc. website, and also in this handy reference guide. From those sources you can see that you have an example of a macro employing macro modifiers in its expansion.
Generally speaking $(FOO) is expanded to the unmodified value of the variable FOO, while $(FOO,mod1[,mod2[,...]]]) expands to the value of FOO, modified according to the modifiers you specify. Note that you can string together any number of modifiers, and they will be applied in left-to-right order.
There's a ton of possible modifiers, but your example specifically uses two:
The F modifier, which means "use just the final path component of each pathname in the variable value"
The >str modifier, which means "append the text str to each space-separated word in the value".
Here's a quick example:
FOO=abc/def ghi/jkl
BAR=$(FOO,F)
BAZ=$(FOO,>.txt)
BOO=$(FOO,F,>.txt)
BAR will have the value def jkl (ie, just the filename portion of each path).
BAZ will have the value abc/def.txt ghi/jkl.txt (ie, append .txt to each space-separated word in the value)
BOO will have the value def.txt jkl.txt (ie, first take just the filename portion of each path, then append .txt to each)