Walter Bright wrote:
> Jascha Wetzel wrote:
>> Walter Bright wrote:
>>> Post a snippet of the output and point out what is unclear, and I'll
>>> try to help.
>>
>> the sections that come first, before the list of functions sorted by
>> "func time":
>>
>> ------------------
>> 1 A
>> 1095 B
>> 1856 C
>> D 2952 122732995 3009972
>>
>> the sections appear to list the functions that are directly called by
>> the top most in the section. but i can't figure out what the numbers
>> mean and why there are some entries with a single one on the left and
>> some with 3 numbers on the right of the function name.
>
> I renamed the functions for simplicity.
>
> D is called 2952 times. 1 of those calls comes from A. 1095 come from B.
> 1856 come from C. Note that 1+1095+1856 = 2952. (The A, B, C counts are
> called the "fan in".) The "fan out" is a list of counts of what D calls,
> and follows the line for D.
>
> The total number of timer ticks spent in D is 3009972, excluding
> whatever D calls. The total number of timer ticks in D, including
> whatever D calls, is 122732995.
>
> From this information you can not only determine where the time is
> being consumed, but *why*, as you know where the calls are coming from.
> You can do this to determine the runtime relationships between
> functions, which can be used to set the link order (and this is output
> by the profiler in the form of a .def file).
Thank you for explaining this. (And actually, it makes perfect sense once you /know/.)
For those like me, knowing with a certainty what numbers are what, and what the layout of
all that data means, should breathe new life into this nifty compiler feature.
-- Chris Nicholson-Sauls

Walter Bright wrote:
>> (The closest I recall is "refactoring" C++ code, but that's something
>> where the CLI won't help you either)
>
> Sure it does, the CLI has very powerful text processing tools available
> to it.
Maybe for rename refactoring. Most other refactoring operations need an
actual semantic tool, you can't do it with CLI text processing tools.
But that is a moot point: when you do such rename refactoring, most of
the times the IDE built-in search-replace facilities are just as good as
using the CLI, if not better. For example in Visual Studio C++ I find it
more convenient to do search replace in the IDE, since it already knows
which C++ files belong to the project and which don't.
That's not saying there aren't cases where using the CLI is better, but
in those cases (which should not be common), one can just fire up a
shell, do it, and go back to the IDE.
Walter Bright wrote:
> Bruno Medeiros wrote:
>> But again this was a shell-specific point. When programming, I don't
>> recall ever *having the need* to do a series of repeated actions in an
>> IDE. Perhaps you can give an example?
>
> Here are some:
>
> .. global file renaming
> .. running automated test suites
> .. interfile search/replace across a subset of the project files
> .. copying a subset of the project files into another directory
> .. running the debugger with the same complex set of commands, over and
> over
>
Some of those actions are simple to perform (like running automated test
suites, or running the debugger with the same complex set of commands) :
they should consist simply of a command invocation, whether in a GUI, or
in an CLI shell.
The others may indeed be repetitive to perform, but the same argument as
above holds: if they are easier to do in the CLI (which should be an
uncommon case, if the IDE is good), then fire up the CLI, do it, and go
back to the IDE.
An interesting and ironic side story:
When I diff the docs of DMD releases, I have some regexps that clear out
some common but unsignificant changes. However, because these are
multi-line regexps, I have to load up my text editor (EmEditor) and use
the search/replace feature of the editor, because GNU's sed -e, or any
other standard GNU tool that I know of, does not support multi-line
regexps. At least as far as I could find, If I am wrong and anyone know
sa way, let me know, so that I can put it in a script. :)
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

I'm just reposting this with a different subject to give it an easier to
find subject line.
Walter Bright wrote:
Jascha Wetzel wrote:
> Walter Bright wrote:
>> Post a snippet of the output and point out what is unclear, and I'll
>> try to help.
>
> the sections that come first, before the list of functions sorted by
> "func time":
>
> ------------------
> 1 A
> 1095 B
> 1856 C
> D 2952 122732995 3009972
>
> the sections appear to list the functions that are directly called by
> the top most in the section. but i can't figure out what the numbers
> mean and why there are some entries with a single one on the left and
> some with 3 numbers on the right of the function name.
I renamed the functions for simplicity.
D is called 2952 times. 1 of those calls comes from A. 1095 come from B.
1856 come from C. Note that 1+1095+1856 = 2952. (The A, B, C counts are
called the "fan in".) The "fan out" is a list of counts of what D calls,
and follows the line for D.
The total number of timer ticks spent in D is 3009972, excluding
whatever D calls. The total number of timer ticks in D, including
whatever D calls, is 122732995.
From this information you can not only determine where the time is
being consumed, but *why*, as you know where the calls are coming from.
You can do this to determine the runtime relationships between
functions, which can be used to set the link order (and this is output
by the profiler in the form of a .def file).

Bruno Medeiros wrote:
> Walter Bright wrote:
>>> (The closest I recall is "refactoring" C++ code, but that's something
>>> where the CLI won't help you either)
>>
>> Sure it does, the CLI has very powerful text processing tools
>> available to it.
>
> Maybe for rename refactoring. Most other refactoring operations need an
> actual semantic tool, you can't do it with CLI text processing tools.
Yes, you can. It's just that tools for this are not currently written.
> But that is a moot point: when you do such rename refactoring, most of
> the times the IDE built-in search-replace facilities are just as good as
> using the CLI, if not better. For example in Visual Studio C++ I find it
> more convenient to do search replace in the IDE, since it already knows
> which C++ files belong to the project and which don't.
Are you saying that Visual Studio is better at refactoring C++ code than
sed? :boggles:
> That's not saying there aren't cases where using the CLI is better, but
> in those cases (which should not be common), one can just fire up a
> shell, do it, and go back to the IDE.
They shouldn't be common because if they are, that functionality should
be integrated into the IDE.
> Walter Bright wrote:
> > Bruno Medeiros wrote:
> >> But again this was a shell-specific point. When programming, I don't
> >> recall ever *having the need* to do a series of repeated actions in an
> >> IDE. Perhaps you can give an example?
> >
> > Here are some:
> >
> > .. global file renaming
> > .. running automated test suites
> > .. interfile search/replace across a subset of the project files
> > .. copying a subset of the project files into another directory
> > .. running the debugger with the same complex set of commands, over and
> > over
> >
>
> Some of those actions are simple to perform (like running automated test
> suites, or running the debugger with the same complex set of commands) :
> they should consist simply of a command invocation, whether in a GUI, or
> in an CLI shell.
And for the rest, you need the command line. Now, there's a command line
in Visual Studio....
> The others may indeed be repetitive to perform, but the same argument as
> above holds: if they are easier to do in the CLI (which should be an
> uncommon case, if the IDE is good), then fire up the CLI, do it, and go
> back to the IDE.
True, if the IDE is any better than vim, for instance. (I'm looking
directly at the XML editor in Visual Studio. It takes *ages* to load a
file of a few kilobytes, and after that, it's slow. Now, if I could get
vim to do syntax highlighting for aspx files, it'd be hands-down better.)
>
> An interesting and ironic side story:
> When I diff the docs of DMD releases, I have some regexps that clear out
> some common but unsignificant changes. However, because these are
> multi-line regexps, I have to load up my text editor (EmEditor) and use
> the search/replace feature of the editor, because GNU's sed -e, or any
> other standard GNU tool that I know of, does not support multi-line
> regexps. At least as far as I could find, If I am wrong and anyone know
> sa way, let me know, so that I can put it in a script. :)
>
sed goes line-by-line. You could use vim...that does multiline searches.
And you can give it command line arguments that describe vim commands to
execute.

Christopher Wright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>>> (The closest I recall is "refactoring" C++ code, but that's
>>>> something where the CLI won't help you either)
>>>
>>> Sure it does, the CLI has very powerful text processing tools
>>> available to it.
>>
>> Maybe for rename refactoring. Most other refactoring operations need
>> an actual semantic tool, you can't do it with CLI text processing tools.
>
> Yes, you can. It's just that tools for this are not currently written.
>
I didn't say do it in the CLI, I said do it in the CLI *with
(tradicional) text processing tools* (grep, sed, awk, etc.).
>> But that is a moot point: when you do such rename refactoring, most of
>> the times the IDE built-in search-replace facilities are just as good
>> as using the CLI, if not better. For example in Visual Studio C++ I
>> find it more convenient to do search replace in the IDE, since it
>> already knows which C++ files belong to the project and which don't.
>
> Are you saying that Visual Studio is better at refactoring C++ code than
> sed? :boggles:
>
For the common rename-refactoring, yes. Are you saying it's not? :3
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D