On Thursday, 25 September 2014 at 17:44:49 UTC, Jacob Carlborg wrote:
>
> LLDB supports OS X, Linux and FreeBSD. 32 and 64bit on all of these platforms [1].

It mentioned only 32-bit ELF on the "About" page.  Since that matches with what was previously the case in terms of debugging support, I didn't bother to read into it further.  How strange that this incredibly important detail isn't top, front, and centre.

> Are you looking for Windows support?
>
If I had the extreme misfortune of working on Windows, I'd just use the Visual Studio debugger.  As much as I hate to admit it, it's the best-in-class.

-Wyatt

On Friday, 26 September 2014 at 04:37:06 UTC, H. S. Teoh via Digitalmars-d wrote:
>
> So basically, we're paying (1) lower performance, (2)  non-random access
> for strings, (3) subtle distinction between index and count and other
> such gotchas, and (4) tons of special-cased Phobos code with the
> associated maintenance costs, all for incomplete Unicode correctness.
> Doesn't seem like the benefit measures up to the cost. :-(

Yep.  When I use algorithms on strings in D, I always cast them to ubyte[].  Which is a poor solution.

Sean Kelly:

> When I use algorithms on strings in D, I always cast them to ubyte[].  Which is a poor solution.

In Phobos we have "representation", and "assumeUTF" that are better than naked casts. I use them only sparingly (and I avoid cast), despite I use strings often.

Bye,
bearophile

On Fri, Sep 26, 2014 at 10:22:49AM +0000, Joakim via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 13:56:20 UTC, Andrei Alexandrescu wrote:
> >On 9/25/14, 4:30 AM, Joakim wrote:
> >>I'm sorry but it's ridiculous for you two co-BDFLs not to put these new priorities or pre-approved features (perhaps even a list of features you'd automatically reject) in a list on the wiki and maintain it yourselves.  It's the least you can do considering the veto power you have.
> >
> >That's sensible. We have the "preapproved" tag at http://issues.dlang.org exactly for that kind of stuff. (I should note, however, that sometimes it backfires - I've added https://issues.dlang.org/show_bug.cgi?id=13517 with preapproved knowing it's sensible and entirely noncontroversial and got unexpected pushback for it.)
> 
> That's not enough.  While it's nice that a "preapproved" tag is being used on bugzilla, most of those issues are too low-level and an obscure bugzilla tag hardly fits the bill, particularly when most D users have never seen the D bugzilla let alone use it.  It needs to be a page on the wiki or the main site, which you or any user can link to anytime people want to know the plan.

I'm thinking either a wiki page, or a dedicated webpage on dlang.org, that contains a link to a prebaked bugzilla query that returns all preapproved issues. Or perhaps just add that to http://dlang.org/bugstats.php .


> I gave a specific example with dfix, yet to get an answer on that. Brian may have marked his DIP 65 as rejected a couple months back, but that still doesn't answer the broader question of using a dfix tool for other cleanup.
[...]

I'm thinking we, the community, should just go ahead with writing a dfix utility, promote it, and use it. Once it becomes a de facto standard, it will be much easier to convince the BDFLs to "officially" adopt it. ;-)


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.

On 2014-09-26 08:51, Atila Neves wrote:

> Because I don't use unittest blocks, I use my own library. The one thing
> it can't use the compiler for is discover what files are in a directory,
> so I need to generate the main function that calls into unit-threaded
> with a list of compile-time strings. What I need/want is that every time
> I add a new source file to the project, it gets auto-generated
> automatically and is a dependency of the unittest build in dub.

Yeah, this sucks. That's way this is needed: https://github.com/D-Programming-Language/dmd/pull/2271

-- 
/Jacob Carlborg

On 2014-09-26 14:14, Wyatt wrote:

> It mentioned only 32-bit ELF on the "About" page.

I don't know which "About" page you're reading. The one I'm reading [1] doesn't mention ELF at all.

[1] http://lldb.llvm.org/index.html

-- 
/Jacob Carlborg

On Friday, 26 September 2014 at 07:56:57 UTC, Marco Leise wrote:
> Am Wed, 24 Sep 2014 23:56:24 +0000
>
> You do know that your email is in plain text in the news
> message header? :p

Actually I did not, as I am not presently using a newsreader to
access the forums, just the web page.  I keep forgetting to
install a proper reader :)  Thanks!

On 9/26/2014 6:55 AM, Sean Kelly wrote:
> On Friday, 26 September 2014 at 04:37:06 UTC, H. S. Teoh via Digitalmars-d wrote:
>>
>> So basically, we're paying (1) lower performance, (2) non-random access
>> for strings, (3) subtle distinction between index and count and other
>> such gotchas, and (4) tons of special-cased Phobos code with the
>> associated maintenance costs, all for incomplete Unicode correctness.
>> Doesn't seem like the benefit measures up to the cost. :-(
>
> Yep.  When I use algorithms on strings in D, I always cast them to ubyte[].
> Which is a poor solution.

Now you can use the adapters .byCodeUnit or .byChar instead.

Reading this thread makes me a little sad, because all of the wish list stuff seems to be about features that VS already has, and the I use every day :(

> For example, the idea of stepping through lines of code (i.e. individual
> statements) is a convenient simplification, but really, in modern
> programming languages there are multiple levels of semantics that could
> have a meaningful concept of "stepping forward/backward".

Only for C#, I would love to see this for native code:
http://msdn.microsoft.com/en-us/library/h5e30exc%28v=vs.100%29.aspx

On Thursday, 25 September 2014 at 05:30:56 UTC, Walter Bright wrote:
> On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
>> printf debugging FTW! :-P
>
> There's more than that, but yeah. Most of my types I'll write a "pretty printer" for, and use that. No conceivable debugger can guess how I want to view my data.
>
> For example, I can pretty-print an Expression as either a tree or in infix notation.

autoexp.dat can do this in the debugger:
http://msdn.microsoft.com/en-us/library/zf0e8s14.aspx

>> I don't agree with that. I think symbolic debuggers should be improved
>> so that they *can* become useful with high level abstractions. For
>> example, if debuggers could be made to understand templates and
>> compile-time constants, they could become much more useful than they are
>> today in debugging high-level code.
>
> The fact that they aren't should be telling. Like maybe it's an intractable problem :-) sort of like debugging optimized code.

http://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/

On 23/09/2014 20:05, Andrei Alexandrescu wrote:
> On 9/23/14, 12:01 PM, Sean Kelly wrote:
>> On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote:
>>>
>>> Well put. Again, the two things we need to work on are C++
>>> compatibility and the GC. -- Andrei
>>
>> Has much thought gone into how we'll address C++ const?
>
> Some. A lot more needs to. -- Andrei

The resurrection of head-const?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros