October 06, 2014
On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote:
> On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
>> On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote:
>>> On 10/5/14, 3:08 PM, eles wrote:
>>>> On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:

I like the safety that a GC guarantees, but is a too big price to
be paid for that...
October 06, 2014
On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
>
> TDPL was an absolutely awesome book because it expained "why?" as opposed to "how?". Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out.
>

I would also add that it's scaring not having seen a single comment of Andrej here:
https://github.com/D-Programming-Language/dmd/pull/3998

> Right now I have no idea where the development is headed and what to expect from next few releases. I am not speaking about wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++ support, thread about killing auto-decoding, recent ref counting proposal - all this stuff comes from language authors but does not feel like a strategic additions. It feels like yet another random contribution, no different from contribution/idea of any other D user.

+1 on all.


> I am disturbed when Andrei comes with proposal that possibly affects whole damn Phobos (memeory management flags) and asks to trust his experience and authority on topic while rejecting patterns that are confirmed to be working well in real production projects. Don't get me wrong, I don't doubt Andrei authority on memory management topic (it is miles ahead of mine at the very least) but I simply don't believe any living person in this world can design such big change from scratch without some extended feedback from real deployed projects.

+1000

---
/Paolo
October 06, 2014
On Mon, 06 Oct 2014 07:44:56 +0000
Paolo Invernizzi via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998
it's not about c++ interop or gc, so it can wait. existing D users will not run away, they are used to be second-class citizens.


October 06, 2014
On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote:
> On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote:
>> On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
>>> On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote:
>>>> On 10/5/14, 3:08 PM, eles wrote:
>>>>> On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
>
> I like the safety that a GC guarantees, but is a too big price to
> be paid for that...

Just look at this abomination from here:

http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html

sqlConnection.Close();
sqlConnection.Dispose();
sqlConnection = null;

Is this your idea about releasing a resource? Why is this better than writing delete/dispose sqlConnection?

If you ask to use structs for RAII, I am afraid that you will receive a DFront proposal.
October 06, 2014
Dne 3.10.2014 v 16:42 ketmar via Digitalmars-d napsal(a):
> 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.

Thanks a lot. I just briefly gone through the code and I have a question about the console use:

That code is able to register functions and variables with some annotations and execute them by string commands. How do you generally use it for debugging purposes? That is, how do you use this console interactively? In your previous mail you wrote that you use a telnet. Do you have another mixin that at some specific point inserts a code that pauses the execution of surrounding code and starts listening for telnet commands?

Also, how do you make your console work in multithreaded programs?

Thanks,
Martin




October 06, 2014
On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote:
> I like the safety that a GC guarantees, but is a too big price to
> be paid for that...

What if you only had precise GC on class objects and nothing else? That believe could be done in a performant manner.

October 06, 2014
On Mon, 06 Oct 2014 10:22:01 +0200
Martin Drašar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

as i said this is the very first version of cmdcon, not the one i'm using now. i'm not able to publish the current version yet.

> That is, how do you use this console interactively?
> In your previous mail you wrote that you use a telnet.
> Do you have another mixin that at some specific point inserts a code
> that pauses the execution of surrounding code and starts listening
> for telnet commands?
it depends of event loop, actually. i have my own event loop code, and there is hook for telnet channel. that hook collects line to execute, calls cmdcon executor and outputs cmdcon output. maybe i'll publish some std.socket-based sample later.

> Also, how do you make your console work in multithreaded programs?
you should register only shared and global vars (and i'm really missing
__trait(isGShared) here!), there is no sense to register thread locals
in multithreaded program.

but you can register free functions and execute 'em. that free functions should take care of threading.

really, i have to revisit that code and write some samples. i'll try to do that soon. and maybe i'll update public versino of cmdcon a little too. ;-)


October 06, 2014
On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright wrote:
> On 9/24/2014 7:56 AM, Don wrote:
>> For example: We agreed *years* ago to remove the NCEG operators. Why haven't
>> they been removed yet?
>
> They do generate a warning if compiled with -w.
>
>
>>> What change in particular?
>> I've got a nasty feeling that you misread what he wrote. Every time we say,
>> "breaking changes are good", you seem to hear "breaking changes are bad"!
>
> It would be helpful having a list of what breaking changes you had in mind.

Perhaps it would be a good idea to have a themed update? Currently you and Andrei are busy with the C++ changes, when that is settling down maybe the community could focus on a cleaning house update. With clear update themes (which does not preclude the usual mixture of things also going on) people can air issues and get it ye or nay'd clearly. Combining the previously discussed auto-update code tool with a set of breaking changes would make sense.
October 06, 2014
Dne 6.10.2014 v 12:15 ketmar via Digitalmars-d napsal(a):
> On Mon, 06 Oct 2014 10:22:01 +0200
> Martin Drašar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> as i said this is the very first version of cmdcon, not the one i'm using now. i'm not able to publish the current version yet.
> 
>> That is, how do you use this console interactively?
>> In your previous mail you wrote that you use a telnet.
>> Do you have another mixin that at some specific point inserts a code
>> that pauses the execution of surrounding code and starts listening
>> for telnet commands?
> it depends of event loop, actually. i have my own event loop code, and there is hook for telnet channel. that hook collects line to execute, calls cmdcon executor and outputs cmdcon output. maybe i'll publish some std.socket-based sample later.
> 
>> Also, how do you make your console work in multithreaded programs?
> you should register only shared and global vars (and i'm really missing
> __trait(isGShared) here!), there is no sense to register thread locals
> in multithreaded program.
> 
> but you can register free functions and execute 'em. that free functions should take care of threading.
> 
> really, i have to revisit that code and write some samples. i'll try to do that soon. and maybe i'll update public versino of cmdcon a little too. ;-)
> 

Ok, thanks for your answers. If you get your code to publishable state, I am sure a lot of people will be interested.

Cheers,
Martin



October 06, 2014
On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
>
> No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for "imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing" could have been huge deal.

> Right now your rationales get lost in forum discussion threads

Jerry Christmas, this right here!  Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds.  Judging by the recent thread where someone (Ola?) asked what "C++ support" actually means and received precisely zero useful guidance, no one else does either. (This isn't to say I don't think it's important, but the scope of what you're doing right now and how it materially helps end users isn't really clear.)

> There was a go at properties

SALT.

-Wyatt