On Monday, 2 September 2013 at 03:47:56 UTC, H. S. Teoh wrote:
>
> My guess is that gdb actually uses a superset of Dwarf, with its own
> idiosyncratic extensions that only gcc knows about.

This isn't terribly surprising, though ostensibly it shouldn't be doing that unless you use the -ggdb switches[0] (For C, I do actually use -ggdb3 for the macro expansion).

-Wyatt

[0] http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

On Tuesday, 3 September 2013 at 15:41:29 UTC, Wyatt wrote:
> On Monday, 2 September 2013 at 03:47:56 UTC, H. S. Teoh wrote:
>>
>> My guess is that gdb actually uses a superset of Dwarf, with its own
>> idiosyncratic extensions that only gcc knows about.
>
> This isn't terribly surprising, though ostensibly it shouldn't be doing that unless you use the -ggdb switches[0] (For C, I do actually use -ggdb3 for the macro expansion).
>
> -Wyatt
>
> [0] http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

When you look at gdb source code, it isn't that surprising at the end. It is basically dmd power 10.

On 3 September 2013 07:04, Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/2/2013 1:36 PM, H. S. Teoh wrote:
>
>> It's things like this "keyhole interface", that caused me to be convinced that the GUI emperor has no clothes, and to turn to CLI-only development.
>>
>
> One of the giant failures of the GUI interface, and that VS suffers from, too, is when you need to do repetitive operations.
>
> On the CLI, I constantly use the history list, and I constantly write throwaway scripts to automate what I'm doing at the moment. It makes everything I do, no matter how obscure, only 2 or 3 keypresses.
>
> With VS, or any GUI, if there's not a button to do it, I'm reduced to:
>
> move mouse
> click
> move mouse
> click
> move mouse
> type
> move mouse
> click
> type
>
> to get something done. And if I want to do it again, I have to repeat that process. After the 10th time, it's gaaaaahhh I hate it and go back to the CLI.
>
> I scan a lot of photos. I have a GUI photo editor. A common thing I do is straighten the photos, because they never go through the scanner straight. So it's:
>
> right shift click on the picture
> select open with
> select photoeditor
> select edit
> select rotate
> select autorotate
> select apply
> select save
> select exit
>
> Sounds easy, right? It is easy. Now do it to 1000 photos. With a command line tool:
>
> write a script that does it to one picture, name it cc.bat
>
> do:
>    dir/b *.jpg >doit.bat
>
> open the file and use the macro feature to prepend "cc " to each file name, maybe 10 keystrokes
>
> execute the script
>
> Done! And CLI Clint goes and surfs the n.g. while GUI Gus has just gotten to picture 4, only 996 more to go!
>

Visual studio has macros. Ctrl-Shift-R, do your repetitive task,
Ctrl-Shift-R, then hit Ctrl-P and it'll repeat what you did as many times
as you like.
I use this all the time. I barely touch the mouse in VS, and GUI isn't very
good.

On 3 September 2013 07:26, Peter Alexander <peter.alexander.au@gmail.com>wrote:

> On Monday, 2 September 2013 at 21:04:24 UTC, Walter Bright wrote:
>
>> One of the giant failures of the GUI interface, and that VS suffers from, too, is when you need to do repetitive operations.
>>
>> ...
>>
>
> I agree most GUI's could be better in that respect.
>
> The solution: use the GUI most of the time and CLI when that's the better tool. No need to throw out the baby with the bathwater.
>

Visual Studio has one of the best instant macro recording features I've ever seen...

On Tuesday, 3 September 2013 at 16:36:11 UTC, Manu wrote:
> On 3 September 2013 07:04, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 9/2/2013 1:36 PM, H. S. Teoh wrote:
>>
>>> It's things like this "keyhole interface", that caused me to be
>>> convinced that the GUI emperor has no clothes, and to turn to CLI-only
>>> development.
>>>
>>
>> One of the giant failures of the GUI interface, and that VS suffers from,
>> too, is when you need to do repetitive operations.
>>
>> On the CLI, I constantly use the history list, and I constantly write
>> throwaway scripts to automate what I'm doing at the moment. It makes
>> everything I do, no matter how obscure, only 2 or 3 keypresses.
>>
>> With VS, or any GUI, if there's not a button to do it, I'm reduced to:
>>
>> move mouse
>> click
>> move mouse
>> click
>> move mouse
>> type
>> move mouse
>> click
>> type
>>
>> to get something done. And if I want to do it again, I have to repeat that
>> process. After the 10th time, it's gaaaaahhh I hate it and go back to the
>> CLI.
>>
>> I scan a lot of photos. I have a GUI photo editor. A common thing I do is
>> straighten the photos, because they never go through the scanner straight.
>> So it's:
>>
>> right shift click on the picture
>> select open with
>> select photoeditor
>> select edit
>> select rotate
>> select autorotate
>> select apply
>> select save
>> select exit
>>
>> Sounds easy, right? It is easy. Now do it to 1000 photos. With a command
>> line tool:
>>
>> write a script that does it to one picture, name it cc.bat
>>
>> do:
>>    dir/b *.jpg >doit.bat
>>
>> open the file and use the macro feature to prepend "cc " to each file
>> name, maybe 10 keystrokes
>>
>> execute the script
>>
>> Done! And CLI Clint goes and surfs the n.g. while GUI Gus has just gotten
>> to picture 4, only 996 more to go!
>>
>
> Visual studio has macros. Ctrl-Shift-R, do your repetitive task,
> Ctrl-Shift-R, then hit Ctrl-P and it'll repeat what you did as many times
> as you like.
> I use this all the time. I barely touch the mouse in VS, and GUI isn't very
> good.

But can the macro feature actually figure out which files you
want to rotate (as in the above example).  If you still have
interact with the File Open Dialog 1000 times are you in any
better shape? Even if you have a shortcut to the other steps?

On 3 September 2013 12:34, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> On Tue, 3 Sep 2013 11:18:03 +1000
> Manu <turkeyman@gmail.com> wrote:
> >
> > I think I've repeated myself 3 or 4 times here, but one more time for good measure...
> >
> > Requiring IDE assistance to make code _readable_ seems completely
> > fail to me.
> > 1) You're not always reading code in your IDE, often in commit logs,
> > diff windows, emails, chat clients.
> > 2) With so much hate for IDE support, it seems like a massive
> > contradiction to say that an IDE should be required to make code
> > readable.
> >
> > Reading code is the most fundamental task in programming. Anything that gets in the way of code readability is an epic fail.
> >
>
> First of all, not everybody agrees that separating out function definitions makes code easier to read rather than harder.
>
> Also, maintainability is just as important as readability, and "poor
> maintainability" is a very big and very common objection to C++'s
> separation of member function definitions from class definitions. You're
> essentially writing and maintaining full documentation completely by
> hand and a lot of people feel very bogged down by the extreme
> non-DRYness of that very quickly, especially when there are already so
> many other ways to get the same information without maintaining
> it manually: Automatic Doc generators, high-level IDE class browsing,
> and code folding (and code folding is *not* an IDE thing, but an
> extremely common code editor thing).
>

So then don't write your code that way. I didn't tell you how to write your
code.
I just said I hate inline function definitions, and so do all my
colleagues. It demonstrably slowed us down, and it's annoying.

On 3 September 2013 18:04, Gary Willoughby <dev@nomad.so> wrote:

> Requiring IDE assistance to make code _readable_ seems completely fail to
>> me.
>> 1) You're not always reading code in your IDE, often in commit logs, diff
>> windows, emails, chat clients.
>> 2) With so much hate for IDE support, it seems like a massive
>> contradiction
>> to say that an IDE should be required to make code readable.
>>
>> Reading code is the most fundamental task in programming. Anything that gets in the way of code readability is an epic fail.
>>
>
> You're still confusing code readability with getting an overview of a class. They are two different things.
>

They're not different, it's a subset.

If you need an overview that you can view in text, add comments at the top
> of the class with a method signature on each line. That will give you the overview you need and reproduce the total nightmare of keeping it in sync with the methods. Something you would also have to do with separate declarations and implementations.
>

I think it's MUCH more of a nightmare trying to organise a class to be as readable as possible with this limitation. I'm always juggling the code, moving shit around, most of the time there's no perfect solution, and every time, it's a waste of time and money. Things often demand to be grouped either conceptually, or by visibility, and you can't have both. Visibility blocks like public:/private: basically enforce you split up your variables into a few different areas, and once they become interleaved with functions, you're screwed.

On 3 September 2013 18:38, John Colvin <john.loughran.colvin@gmail.com>wrote:

> On Tuesday, 3 September 2013 at 01:18:16 UTC, Manu wrote:
>
>> On 3 September 2013 02:19, John Colvin <john.loughran.colvin@gmail.**com<john.loughran.colvin@gmail.com>
>> >wrote:
>>
>>  On Monday, 2 September 2013 at 03:14:38 UTC, Manu wrote:
>>>
>>>  On 2 September 2013 04:00, bearophile <bearophileHUGS@lycos.com> wrote:
>>>>
>>>>  Manu:
>>>>
>>>>>
>>>>>
>>>>>  Seriously, how do you quickly read and understand the API through the
>>>>>
>>>>>  noise?
>>>>>>
>>>>>>
>>>>>>  The noise increases if you have to repeat the class name for each
>>>>> method
>>>>> :-)
>>>>>
>>>>>
>>>>>  Except that you can _read the class definition_.
>>>>
>>>> Look, I'm just giving an account of the collective experience from our
>>>> weekend. None of us could find anything easily in each others classes,
>>>> or
>>>> quickly get a reasonable overview of it's design and how it worked.
>>>> This leads to needless conversations, asking the other person about it,
>>>> and
>>>> all those questions that I should be able to understand at a glance.
>>>> This WILL affect productivity in the office.
>>>>
>>>> The reason was that functions were polluting the class declaration. 9
>>>> times
>>>> out of 10, when I look at a class declaration, I want to know what it
>>>> is,
>>>> what it has, and what it can do.
>>>>
>>>>
>>> Code folding? It's a pretty standard feature of most editors since forever.
>>>
>>>
>> I think I've repeated myself 3 or 4 times here, but one more time for good measure...
>>
>> Requiring IDE assistance to make code _readable_ seems completely fail to
>> me.
>> 1) You're not always reading code in your IDE, often in commit logs, diff
>> windows, emails, chat clients.
>>
>
> for some people, all of those things are emacs.


I've never met a professional at work in well over a decade that uses
emacs. Only computer geeks/enthusiasts.
Granted, this probably reflects industry standards in my work, but it is
what it is.

 2) With so much hate for IDE support, it seems like a massive contradiction
>> to say that an IDE should be required to make code readable.
>>
>
> There's a different between and IDE and an editor, but it's a pretty blurry line. There are lots of people here(myself included) who don't feel the need for a full blown IDE, but I'd be surprised if (almost) anyone here used an editor that didn't support such basic things as code folding.
>

I hate code folding. I think it's even worse. It ruins my mental picture of
the code, and it's annoying and fiddly to micro-manage.
Strangely enough, I've never seen anyone at work use it either.

anyway, in the end it's a trade-off.
> Definitions inside class:
>    -you know where it is (never ends up in a different file etc)
>    -declarations always in sync
>    -it clutters the signature
>
>    solution: code folding or go-to-next-function or minimal documentation.
> Worst case you can scroll and you'll know if you've got to the end of the
> class then it's not there.
>
> Definitions seperate:
>    -clear class signature
>    -no idea where to find implementation
>
>    solution: go-to-definition. Worst case you have to go through separate
> files searching for a definition by eye. Even if it has to be in the same
> file, you have no hint where.
>

Who said anything about separate files? I never said that.

Both cases require some editor features in order to be ideal, but if you
> don't have those tools (e.g. in all the other places you've mentioned*) then it's just a choice between having to scroll a bit some of the time or having to occasionally go on a blind code-hunt.
>

Yes, it is a *choice*.
I'm not trying to force you to put your functions outside your class
definition if you don't want to.

*A lot of people use version-control aware editors to do a lot of what
> you're talking about e.g. view a diff.

On 3 September 2013 03:24, Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/1/2013 9:26 PM, Manu wrote:
>
>> Might I suggest one step further to you Walter, that it might be
>> worth-while for
>> you to take an interest personally into Visual-D, and maybe Mago. Since
>> you're
>> probably the primary Windows contributor?
>> Perhaps try and work with these tools on a daily basis for a while.
>> Especially
>> try some intensive debugging sessions under Visual-D/VS.
>> You might find that it may short-circuit a lot of micro-bug reports in the
>> debugging experience.
>>
>
> At some point I have to delegate. I can't personally take charge of everything.
>
> You are an expert with VS, you work extensively with others who use VS, and you know exactly what you need VisualD to do. Please work with the VisualD developer (Rainer)!
>

I get the impression Rainer is way overloaded. I haven't seen any movement in the bug list for months.

I'm the wrong person to do this. I try IDEs now and then, and have never
> been happy with them. I don't need the features they have. I know I'm out of step because of that, but it makes me the wrong person to fix it.
>

Fair enough.

Someone wrote sth along the line of "How egotistical! Some want
this and want that. D doesn't get better or more popular by
wanting ever more things".

I'll very soon begin to work on a project. Originally it was
planned to it in Ada. Relevant feature sets are roughly equal
with D offering a little more (like comfortable unittests) and
Ada being well proven.

I *want* to go D. And I would, of course, gladly tell everyone
who doesn't run away fast enough that our application is
developed in D.(The application will quite probably have a good,
even international visibility but by no means be major or widely
known. The major (and very well useable, not "crippled") part of
it will be free, btw.)

In other words: One can contribute also by using (and talking
about) D - not only by defending it teeth and claws or by writing
code for or around D itself.

Here is my current resumee:

- dmd not debuggable -> not an acceptable solution, no matter how
fast it compiles.
- gdc possibly still buggy (Disclaimer: Probably it was just bad
luck that I fell over a bug (not even an important one) and am a
little wary now - No offense intended. I'm immensely grateful
that with gdc there is an alternative and, even better, GDB
*works* with gdc - hurray!!)
- gdc (2): I have to either use an old version (4.63) or build it
myself along with gcc, which is a major hurdle
-ldc not yet tried. Dunno.
- Windoze stuff not yet tried. But the mere thought that D might
force me to use Windoze puts dark shadows over D, sorry.

- IDEs: Some existing. Using geany with good support for D is
perfectably acceptable (Me not liking fat IDEs anyway). It comes
down to a very acceptable editor with some gadgets (like class
viewer) with a small engine driving builds and a debugger
interface (or do I mix that up with Code:Blocks?))
Summary: Good starting grounds. Perfection and dreamland can be
reached later.

- libraries: Looks between regrettable (lots of old/broken/pre
alpha stuff) and uncomfortable (equals increased development
cost/time).
Major problem: No readily available mechanism (I know of and
would trust/use) to 2/4 automate C lib binding.

The situation being that I must, and pretty soon, make a
decision, it - for me - comes down to:

- dmd would be used for coverage and doc and possibly profiling
but not for compilation.
- Can I trust the GDC guys, are they professionals? My impression
so far: Yes. That's important to me because GDC clearly is the
compiler I'd go with.
- Will they provide at least GDC 4-7 binaries (they did for GDC
4-6 (debian)) - dunno. Would be a very big Plus.
- IDE *is* a major issue for general language uptake. For myself
though I'd have a quite acceptable base. Worst case: Fumble and
finetune in Scite engine for D. No sweat.

As for libs and stuff D looks lousy and unorganized. For me
that's not a problem, I'll bite and find my way through. For
general language uptake and acceptance though that's about as
attractive as the more remote corner of a used car shop.

Red line: When in a project I have to "fight" the project - not
the tools; those must simply work reliably.

The community seems quite OK. Very little flames and hate, quite
professional with a tendency to be friendly; they strongly seem
to prefer to discuss and elaborate minute details, work-arounds
and hacks, and seems to react rather pissed to any critical
remark on D, but I feel that there would basically always an
answer if one had a question.
Andrei (sorry, the core people *are* important because they shape
language and community) is a matter for itself and W. Bright
would rather discuss the availability of TV programs than to
answer, even when addressed directly, if he doesn't like someone
or consider him unworthy because being newb or whatever. The
layer around them though seems more open and accessible. Good
enough, no, actually even quite good.

In summary, my resumee is quite positive (if with quite some
bumps) but *THE* go or break issue is debugging with dmd and GDC
being reliable. For the former I don't hold my breath, for the
latter I'm quite positively looking ahead.

Now destroy me. A+ -R