September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 |
September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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
|
September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joakim | 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. |
September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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 |
September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Wyatt | 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 |
September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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!
|
September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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.
|
September 26, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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/ |
September 30, 2014 Re: What are the worst parts of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
Copyright © 1999-2021 by the D Language Foundation