View mode: basic / threaded / horizontal-split · Log in · Help
August 08, 2007
Re: Overloading/Inheritance issue
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
August 09, 2007
Re: Overloading/Inheritance issue
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
August 10, 2007
-profile output: Walter's profiler tips
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).
August 10, 2007
Re: Overloading/Inheritance issue
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.
August 11, 2007
Re: Overloading/Inheritance issue
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
Next ›   Last »
3 4 5 6 7
Top | Discussion index | About this forum | D home