On Thursday, 2 October 2014 at 16:26:15 UTC, ketmar via Digitalmars-d wrote:
> and i must say that integrating such
> console in C projects was tiresome. with D i can do it almost
> automatically, skipping annoying "variable registration" and wrappers for functions.
>
> the first thing i wrote in D was "console module" -- just to test if
> all that "CTFE, and traits, and metaprogramming" promises are real. and
> then i became immediately hooked to D. ;-)

That's pretty cool, so you basically use the reflection capabilities of D to "generate" your own custom CLI to the application?

I had not thought of that before. Interesting idea!

On Thu, 02 Oct 2014 16:45:21 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> That's pretty cool, so you basically use the reflection capabilities of D to "generate" your own custom CLI to the application?
yes. some naming conventions and one mixin -- and all interesting variables and functions from the given module are automatically registered in command console. so i can inspect and change variables and fields, call free functions and class/struct member functions, even write simple scripts. it's really handy. and i connect to this console using telnet (if telnet support is activated).

this also allows some forms of unified "automated testing" even for GUI apps, all without building special "debug versions", i.e. on production code.

Dne 2.10.2014 v 19:02 ketmar via Digitalmars-d napsal(a):
> On Thu, 02 Oct 2014 16:45:21 +0000
> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
>> That's pretty cool, so you basically use the reflection capabilities of D to "generate" your own custom CLI to the application?
> yes. some naming conventions and one mixin -- and all interesting variables and functions from the given module are automatically registered in command console. so i can inspect and change variables and fields, call free functions and class/struct member functions, even write simple scripts. it's really handy. and i connect to this console using telnet (if telnet support is activated).
> 
> this also allows some forms of unified "automated testing" even for GUI apps, all without building special "debug versions", i.e. on production code.
> 

That is mighty interesting. Would you be willing to share some code? Right now, I am teaching my students about debugging in C/C++ and I want to give them some perspective from other languages and environments.

Thanks.
Martin

On Thursday, 2 October 2014 at 17:02:35 UTC, ketmar via Digitalmars-d wrote:
> yes. some naming conventions and one mixin -- and all interesting
> variables and functions from the given module are automatically
> registered in command console. so i can inspect and change variables
> and fields, call free functions and class/struct member functions, even
> write simple scripts. it's really handy. and i connect to this console
> using telnet (if telnet support is activated).

Sounds like a great topic for a blog post! If this is easy to do then this is very useful when writing game servers or servers that retain state in general.

Please share when you are ready, I am gonna leach off yer code… ;-)

On Fri, 03 Oct 2014 10:00:07 +0200
Martin Drašar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> That is mighty interesting. Would you be willing to share some code?
alas, only very old and rudimentary module is available. basically, it's the core of the full-featured console, but... only the core, and not very well written. i'm planning to opensource fully working thingy with bells and whistles eventually, but can't do it right now. :-(

anyway, here it is: http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d

please note that this is not very well tested. i'm keeping it just for nostalgic reasons.

ah, and you can ignore the license. consider that code as public domain/WTFPL.

there is no struct/class support there, only variables and free functions. yet free functions supports various types of arguments and understands default agrument values.

On Fri, 03 Oct 2014 08:30:10 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Please share when you are ready, I am gonna leach off yer code… ;-)
sure, i'm planning to open it as PD/WTFPL as soon as i'll settle some issues. there is nothing really spectacular here, i must say, just tedious wrapper generators and parsers. yet it can save some time for other people. ;-)

for now you can take the ancient version and use it as a base for your
own: http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d
(don't mind the license, consider is PD/WTFPL)

it supports UDA annotations for getting help ('cmd ?'), variables and free functions. and please don't blame me, that was the first 'serious' code i did in D, learning D as i writting the module. ;-)

Am Thu, 25 Sep 2014 21:19:29 +0000
schrieb "Marc Schütz" <schuetzm@gmx.net>:

> I think it should just refuse to work on char[], wchar[] and dchar[]. Instead, byCodeUnit, byCodePoint (which already exist) would be required. This way, users would need to make a conscious decision, and there would be no surprises and no negative performance impact.

Hey, that was what I proposed for Rust over a year ago: https://github.com/rust-lang/rust/issues/7043#issuecomment-19187984

-- 
Marco

On 2014-09-25 23:23:06 +0000, H. S. Teoh via Digitalmars-d said:

> On Thu, Sep 25, 2014 at 03:48:11PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 9/25/14, 2:03 PM, eles wrote:
>>> On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
>>> 
>>>> lack of attention paid to tightening up what we've already got and
>>>> deprecating old stuff that no one wants any more.  And inconsistency
>>>> in how things work in the language.
>>> 
>>> The feeling that I have is that if D2 does not get a serious cleanup
>>> at this stage, then D3 must follow quickly (and such move will be
>>> unstoppable), otherwise people will fall back to D1 or C++next.
>> 
>> I'm not sharing that feeling at all. From that perspective all
>> languages are in need of a "serious cleanup". -- Andrei
> 
> I mean, enterprises use deprecation cycles with their products all the
> time, and we don't hear of customers quitting just because of that. Some
> of the more vocal customers will voice their unhappiness, but as long as
> you're willing to work with them and allow them sufficient time to
> migrate over nicely and phase out the old stuff, they're generally
> accepting of the process.

Unless you're Oracle -- in which case you end up with a horrible amalgamation of poorly thought out features.  Features which work in such narrow cases that they're mostly useless.

-S

On 09/20/2014 05:39 AM, Tofu Ninja via Digitalmars-d wrote:
> There was a recent video[1] by Jonathan Blow about what he would want in a programming language designed specifically for game development. Go, Rust, and D were mentioned and his reason for not wanting to use D is is that it is "too much like C++" although he does not really go into it much and it was a very small part of the video it still brings up some questions.
>
> What I am curious is what are the worst parts of D? What sort of things would be done differently if we could start over or if we were designing a D3? I am not asking to try and bash D but because it is helpful to know what's bad as well as good.
>
> I will start off...
> GC by default is a big sore point that everyone brings up
> "is" expressions are pretty wonky
> Libraries could definitely be split up better
>
> What do you think are the worst parts of D?
>
> [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
>
The worst part of D is the limited libraries.  This often causes me to choose Python instead, I'm sure it often causes others to choose Java or C++ or ...

Mind you, many of the libraries "sort of" exist, but they don't work well.  This is a pity, because if there were, say, a decent wrapper for SQLite then there would be many more uses.  (Yes, I know that the C interface code is included...that's why I picked that particular example.)

OTOH, it's not clear how to solve this, outside of convincing more people to spend time wrapping libraries.  But I'm not the right person, because my prior attempts have ended up being half-hearted failure....also I don't really like the D template syntax.  (For that matter I'm dubious about the entire "template" approach, though many people clearly find it reasonable.)

On 2014-09-25 01:54:26 +0000, H. S. Teoh via Digitalmars-d said:

> On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
>>> You're misrepresenting my position.*In spite of their current flaws*,
>>> modern build systems like SCons and Tup already far exceed make in
>>> their basic capabilities and reliability.
>> 
>> Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: "Be
>> the change you want to see in dlang's build system" :o). -- Andrei
> 
> Well, Cliff & I (and whoever's interested) will see what we can do about
> that. Perhaps in the not-so-distant future we may have a D build tool
> that can serve as the go-to build tool for D projects.
> 
> T


Please submit PRs for dub, instead of creating a new project.   Dub is a nice way of managing library packages already.   I'd rather not use two different tools.