January 24, 2007
"kris" <foo@bar.com> wrote in message news:ep6c92$2ti3$1@digitaldaemon.com...
> Like, for instance, an updated GC? When did that ever top the list of real-world issues for D?

I'm often running into problems with the (old!) GC, and the only fix is to manage memory manually here-n-there, until you end up with some mixed GC, malloc/free frankenstein code. I surely hope the new GC will solve my problems :)

L.


January 24, 2007
Lionello Lunesu wrote:
> "kris" <foo@bar.com> wrote in message news:ep6c92$2ti3$1@digitaldaemon.com...
> 
>>Like, for instance, an updated GC? When did that ever top the list of real-world issues for D?
> 
> 
> I'm often running into problems with the (old!) GC, and the only fix is to manage memory manually here-n-there, until you end up with some mixed GC, malloc/free frankenstein code. I surely hope the new GC will solve my problems :)

Yeah, I agree. There's things that each of us would like resolved. For example, phobos deadlocks in the gc when using multiple threads - sometimes only beyond a day or two - and it's been that way since before  last April. But, that affects only a select few people. In fact, it seems I'm the only one who managed to trip it (though Sean fixed it in both Tango & Ares).

From another viewpoint, lib issues and debugger issues tend to affect the public in general; especially those new to the language, who may be used to the relative luxury of functional debuggers and libs :-D

On one hand, I was bitchin' that priorities seem as crazy as the recent weather up north. On the other, I was relaying a subtle but serious concern about the direction of D, and its general daily usability.

While I often bitch and gripe about the language and its various flaws, and it's clear that Walter and I can't agree on anything notable these days, I'll happily stick by the assertion that D has awesome potential (and will keep putting serious effort into improving the few areas that I /think/ I can contribute to).

All the same, I suspect that now it's more a case of the "managment" of how D progresses which will be the deciding factor whether it lives or dies by the corporate hand (phew! There's a run-on). That's just an opinion, but it's what drove the response to Andrei's post, along with my mistaken belief he was tied in somewhat more deeply to the progression of D.

My apologies for placing /that/ selection of real-world usability issues above the troubles you've been having with the GC ;)  It was silly of me to even make mention of it.

- Kris
January 24, 2007
kris wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> That being said, my view on what should be fixed in D is a bit different. For example, as I said, one of my main foci is putting a lead sarcophagus around "inout" before its radioactive waste affects too much code that will become broken later. Also, implicit conversion rules will change, and again I want to get that in ASAP so not too much code suffers. And so on.
> 
> Aye, and that is certainly appreciated. Some of the items you've mentioned recently have long been festering sores for many. It'll certainly be refreshing to see some attention focused upon those.
> 
> Regarding implicit conversion rules -- are you including the "issues" currently surrounding signature-matching when using constants?

Could you give more detail?

Andrei
January 24, 2007
Andrei Alexandrescu (See Website For Email) wrote:

> 
> I think this ia a good point. Probably varargs_reduce must be linear to make the most conservative assumptions. There is always the chance of defining varargs_reduce_parallel. Thanks!
> 
> 
> Andrei

My thought exactly.  It would be nice to have a vargags_reduce and simply add _parallel to it for instant speed gains.  I also think that there will be other functions that could go the same way.  Perhaps _parallel (or whatever we decide to call it) should be standardized.
January 24, 2007
kris wrote:
> Lionello Lunesu wrote:
>> "kris" <foo@bar.com> wrote in message news:ep6c92$2ti3$1@digitaldaemon.com...
>>
>>> Like, for instance, an updated GC? When did that ever top the list of real-world issues for D?
>>
>>
>> I'm often running into problems with the (old!) GC, and the only fix is to manage memory manually here-n-there, until you end up with some mixed GC, malloc/free frankenstein code. I surely hope the new GC will solve my problems :)

Could you explain further?  Is this simply a problem with false positives or is there something else going on?

> Yeah, I agree. There's things that each of us would like resolved. For example, phobos deadlocks in the gc when using multiple threads - sometimes only beyond a day or two - and it's been that way since before  last April. But, that affects only a select few people. In fact, it seems I'm the only one who managed to trip it (though Sean fixed it in both Tango & Ares).

For the record, I read through the Phobos code looking for the problem but nothing jumped out at me (and the lack of a usable stack trace didn't help much).  And the Tango/Ares Thread code is a complete rewrite so I couldn't simply submit my version to Walter for inclusion in Phobos.

>  From another viewpoint, lib issues and debugger issues tend to affect the public in general; especially those new to the language, who may be used to the relative luxury of functional debuggers and libs :-D

I've gotten pretty used to debugging via code inspection and an occasional well-placed printf since discovering D, but the library issues are obviously a major point of concern with Tango in development.  There are certainly far fewer of them then there were a year ago, but a few major stumbling blocks still exist.


Sean
January 24, 2007
"Sean Kelly" <sean@f4.ca> wrote in message news:ep8a08$2t4o$1@digitaldaemon.com...
> Could you explain further?  Is this simply a problem with false positives or is there something else going on?

I'm afraid I'm not 100% sure. The memory use was definitely higher than it should be and there were quite a few memory leaks (false positives).  The biggest problem however was not the memory use, but the fact that the GC would get slower and slower. This particular application was using mostly strings (big ones), so apart from the pointers to those strings, there werent' many pointers.

L.


January 24, 2007
Sean Kelly schrieb am 2007-01-24:
[...]
> For the record, I read through the Phobos code looking for the problem but nothing jumped out at me (and the lack of a usable stack trace didn't help much).

Have you tried Flectioned's Trace.getTrace() ?

Thomas


January 24, 2007
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Sean Kelly schrieb am 2007-01-24:
> [...]
>> For the record, I read through the Phobos code looking for the problem but nothing jumped out at me (and the lack of a usable stack trace didn't help much). 
> 
> Have you tried Flectioned's Trace.getTrace() ?

No.  Would it work for a deadlock situation?


Sean
January 24, 2007
Lionello Lunesu wrote:
> "Sean Kelly" <sean@f4.ca> wrote in message news:ep8a08$2t4o$1@digitaldaemon.com...
>> Could you explain further?  Is this simply a problem with false positives or is there something else going on?
> 
> I'm afraid I'm not 100% sure. The memory use was definitely higher than it should be and there were quite a few memory leaks (false positives).  The biggest problem however was not the memory use, but the fact that the GC would get slower and slower. This particular application was using mostly strings (big ones), so apart from the pointers to those strings, there werent' many pointers.

Ah, that is because all those strings are being scanned for pointers. The Tango GC that keys on element size addresses this issue, and the new Phobos GC that uses TypeInfo does as well.  For the record, Tango will be using TypeInfo just like Phobos as soon as the next DMD release is out (we're holding with 1.0 until the bugs are fixed).


Sean
January 24, 2007
Andrei Alexandrescu (See Website For Email) wrote:
> kris wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> That being said, my view on what should be fixed in D is a bit different. For example, as I said, one of my main foci is putting a lead sarcophagus around "inout" before its radioactive waste affects too much code that will become broken later. Also, implicit conversion rules will change, and again I want to get that in ASAP so not too much code suffers. And so on.
>>
>>
>> Aye, and that is certainly appreciated. Some of the items you've mentioned recently have long been festering sores for many. It'll certainly be refreshing to see some attention focused upon those.
>>
>> Regarding implicit conversion rules -- are you including the "issues" currently surrounding signature-matching when using constants?
> 
> 
> Could you give more detail?
> 
> Andrei

Yep -- will get back to you with examples (probably tomorrow)