When using gnu smalltalk (without emacs integration) what commands/process does one use to explore the contents of a namespace ? For example, I want to find out how to use the contents of NetClients but if I just type
NetClients examine
I get an enormous amount of text scrolling past. Is it even possible to pass this into something like less so I can scroll back and forth through it ? Ideally I'd like to see a list of classes for example, along with their general description. Then for those classes I'd like to be able to see only their selectors.
If you want to search in the text output when sending messages, I would simply redirect the output to file.
I would do the following:
gst -a > netclients_namespace.txt
type: NetClients examine
check the netclients_nemespace.txt file where you will have the output of the messages. You can check it while the gst is still running
If you are done just break it via ctrl+c
Explaining:
-a --smalltalk-args Pass the remaining arguments to Smalltalk.
Allows you to type in the messages and get the output redirected.
Edit: (missed that question about classes at Namespace)
That being said I'm not big fan of GNU Smalltalk as I don't like the CLI only interface in supports. I think the biggest advantage of Smalltalk from the beginning was its GUI support and if you need it you can use CLI if the Smalltalk environment you are using is supporting it like Smalltalk/X-jv.
Usually inspect is the keyword used in Smalltalk instead of examine. Which will give you an internal view of an object.
If you want to list classes at Namespace you could do it the following way:
NetClients do: [ :namespaceDetail |
namespaceDetail isClass ifTrue: [ namespaceDetail printNl ]
].
To print description of the classes you could to it like this:
NetClients do: [ :namespaceDetail |
namespaceDetail isClass ifTrue: [
'--->' printNl. namespaceDetail printNl. '<---' printNl.
namespaceDetail comment printNl
]
].
In similar fashion you would get selectors.
Related
I am working on a project where our verification test scripts need to locate symbol addresses within the build of software being tested. This might be used for setting breakpoints or reading static data from memory. What I am after is to create a map file containing symbol names, base address in memory, and size. Our build outputs an ELF file which has the information I want. I've been trying to use the readelf, nm, and objdump tools to try and to gain the symbol addresses I need.
I originally tried readelf -s file.elf and that seemed to access some symbols, particularly those which were written in assembler. However, many of the symbols that I wanted were not in there - specifically those that originated within our Ada code.
I used readelf --debug-dump file.elf to dump all debug information. From that I do see all symbols, including those that were in the Ada code. However, the format seems to be in the DWARF format. Does anyone know why these symbols would not be output by readelf when I ask it to list the symbolic information? Perhaps there is simply an option I am missing.
Now I could go to the trouble of writing a custom DWARF parser to get the information but if I can get it using one of the Binutils (nm, readelf, objdump) then I'd really like prefer a standard solution.
DWARF is the debug information and tries to reflect the relation of the original source code. Taking following code as an example
static int one() {
// something
return 1;
}
int main(int ac, char **av) {
return one();
}
After you compile it using gcc -O3 -g, the static function one will be inlined into main. So when you use readelf -s, you will never see the symbol one. However, when you use readelf --debug-dump, you can see one is a function which is inlined.
So, in this example, compiler does not prohibit you use optimization with -g, so you can still debug the executable. In that example, even the function is optimized and inlined, gdb still can use DWARF information to know the function and source/line from current code block inside inlined function.
Above is just a case of compiler optimization. There might be plenty of reasons that could lead to mismatch symbols address between readelf -s and DWARF.
Suppose I have the following code in Go:
foo, bar := someFunc(baz)
I would like to create a Vim function to check type of foo or bar when editing a file.
Is there any tool or reliable source of information for functions from Go's packages I could use or? As for the functions declared in the file I'm editing I was thinking about simply parsing all the functions declared in that file.
You are looking for something like godef
If the -t flag is given, the type of the expression will also be
printed. The -a flag causes all the public members (fields and
methods) of the expression, and their location, to be printed also;
the -A flag prints private members too.
I know it is being used by various vim and emacs scripts.
The Go Oracle does this and much more.
vim-go is a complete vim setup for Go.
It includes integration with the previously mentioned godef (as :GoDef) and Go oracle (as :GoImplements, :GoCallees, :GoReferrers, etc) as well as other tools.
I am using OCLint static code analysis tool for objective-C and want to find out how to customize rules? The rules are represented by set of dylib files.
In lieu of passing configuration as arguments (see Jon Boydell's answer), you can also create a YML file named .oclint in the project directory.
Here's an example file that customizes a few things:
rules:
- LongLine
disable-rules:
rulePaths:
- /etc/rules
rule-configurations:
- key: LONG_LINE
value: 20
output: filename
report-type: xml
max-priority-1: 10
max-priority-2: 20
max-priority-3: 30
enable-clang-static-analyzer: false
The answer, as with so many things, is that it depends.
If you want to write your own custom rule then you'll need to get down and dirty into writing your own rule, in C++ on top of the existing source code. Check out the oclint-rules/rules directory, size/LongLineRule.cpp is a simple rule to get going with. You'll need to recompile, etc.
If you want to change the parameters of an existing rule you need to add the command line parameter -rc=<rulename>=<value> to the call to oclint. For example, if you want the long lines rule to only activate for lines longer than 150 chars you need to add -rc=LONG_LINE=150.
I don't have the patience to list out all the different parameters you can change. The list of rules is here http://docs.oclint.org/en/dev/rules/index.html and a list of threshold based rules here http://docs.oclint.org/en/dev/customizing/rules.html but there's no list of acceptable values and I don't know whether these two URLs cover all the rules or not. You might have to look into the source code for each rule to work out how it works.
If you're using Xcode script you should use oclint_args like this:
oclint-json-compilation-database oclint_args "-rc LONG_LINE=150" | sed
's/(..\m{1,2}:[0-9]:[0-9]*:)/\1 warning:/'
in that sample I'm changing the rule of LONG_LINE to 150 chars
the usual installation descriptions tells me that I need to run Pharo at least three files:
image file
changes file
source file (e.g. PharoV10.sources)
I've run Pharo 2 without the sources file and i didn't see any problem. All sources seemed to be avaiable.
So, why do I need the sources file (e.g. PharoV10.sources)?
The image file contains only the compiled code, not the original source code. The changes file contains source code for the stuff that you added to the system yourself but not source code for existing system classes. To get the source code for existing system classes you need the sources file.
Having said that, Smalltalk can decompile the code and produce what looks like source code if the sources file isn't available. This code will be missing proper variable names, comments and spacing. You really don't want to use decompiled source code so you need access to the sources file.
3 possible explanations, try to identify the joke:
the Browser is smart enough to show you a source reconstructed (Decompiled) from the CompiledMethod byte codes. Hint: in this case, you loose all comments
there is a search path for the sources files, and one is found somewhere on your disk
Pharo is changing so fast that every source is now found in the .changes file
For verifying 1., you could try to browse references to Decompiler (there are a bit too many uses to my own taste).
For verifying 2., you could start browsing implementors of #openSourceFiles
For verifying 3., you could evaluate this snippet:
| nSources nChanges |
nSources := nChanges := 0.
SystemNavigation default allBehaviorsDo: [:b |
b selectorsDo: [:s |
(b compiledMethodAt: s) fileIndex = 1
ifTrue: [nSources := nSources+1]
ifFalse: [nChanges := nChanges+1]]].
^{nSources. nChanges}
It is also possible that Pharo downloads PharoV10.sources automatically.
I've found it almost impossible to pass quoted arguments (containing spaces) to REBOL 3 scripts. For example:
rebol -q script.r "foo bar" 40
If you examine system/script/args, it contains the string "foo bar 40". This is useless! Information was lost. I need to know that "foo bar" was the first argument and 40 was the second. If I examine system/options/args, I get the following block: ["foo" "bar" "40"]. Again, useless! Information was lost.
I suspect that the solution to this is to use argument delimiters of some kind, e.g.,
rebol -q script.r 'foo bar' -n 40
This could easily be handled by PARSE, but I still don't like it. It shouldn't be terribly difficult for system/options/args to contain one string per passed argument.
REBOL's a pleasure to use, and this is the first thing I've found with which I was really disappointed. :(
In REBOL 3, the behaviour you observe is a known bug.
(At the moment, R3 internally passes args from the OS to scripts as a single string, concatenating all original arguments in the process. Currently this process is not fully reversible, which is the cause of this bug. R3 probably should_ pass arguments as a list of strings instead, effectively preserving the original argv but stripped of arguments used by the interpreter itself.)
In REBOL 2, system/options/args is safer to use for command-line arguments, whereas system/script/args can be used to pass values between REBOL scripts more directly. I assume that similar behaviour will be kept for R3.
Here's a quick script to inspect argument parsing behaviour:
REBOL []
print system/version
print "options args:"
probe system/options/args
print "script args:"
probe system/script/args
REBOL 2, on OSX:
2.7.7.2.5
options args:
["foo bar" "40"]
script args:
"foo bar 40"
REBOL 3, on OSX:
2.100.111.2.5
options args:
["foo" "bar" "40"]
script args:
"foo bar 40"
You can escape the quotes:
rebol -q script.r \"foo bar\" 40
Don't know if this is a shortcoming of shell or REBOL?