www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - QtD is suspended

reply Max Samukha <spambox d-coding.com> writes:
After a good amount of hesitation, we have decided to put the QtD 
project on hold. QtD has a potential to become a complete and effective 
development platform for D but it is not going to happen soon (unless 
people with harder hearts take it over). We have spent half of the day 
hunting yet another dmd bug-o-feature and that is the last straw.

We offer our apologies to people who put their hope upon the project. 
Please come back in a year or two when the language has a stable 
compiler with the features fully specified, implemented and debugged.
Sep 16 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/16/10 9:22 CDT, Max Samukha wrote:
 After a good amount of hesitation, we have decided to put the QtD
 project on hold. QtD has a potential to become a complete and effective
 development platform for D but it is not going to happen soon (unless
 people with harder hearts take it over). We have spent half of the day
 hunting yet another dmd bug-o-feature and that is the last straw.

 We offer our apologies to people who put their hope upon the project.
 Please come back in a year or two when the language has a stable
 compiler with the features fully specified, implemented and debugged.

Hi Max, Sorry to hear that. Was this an issue of many small annoyances or a few big ones? Thanks, Andrei
Sep 16 2010
next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 09/16/2010 06:44 PM, Andrei Alexandrescu wrote:
 On 9/16/10 9:22 CDT, Max Samukha wrote:
 After a good amount of hesitation, we have decided to put the QtD
 project on hold. QtD has a potential to become a complete and effective
 development platform for D but it is not going to happen soon (unless
 people with harder hearts take it over). We have spent half of the day
 hunting yet another dmd bug-o-feature and that is the last straw.

 We offer our apologies to people who put their hope upon the project.
 Please come back in a year or two when the language has a stable
 compiler with the features fully specified, implemented and debugged.

Hi Max, Sorry to hear that. Was this an issue of many small annoyances or a few big ones? Thanks, Andrei

Hi Andrei, Both, I guess. The recent big one is the unspecified behavior of postblit on const/immutable structs and overloading by rvalue/lvalue. Specifically, we were bending the generator into generating Qt value types as structs and hit two problems: 1. The generated __cpctor (which does the blit and calls the postblit) is always non-const and takes a non-const reference to the original. That means copy-construction of const objects is impossible without casts. To proceed, we had to hack the compiler so that __cpctor took a const original reference and was called on a mutable target reference. That seemed to work but left us in uncertainty: how it actually should and will work? 2. A bug in the compiler doesn't allow us to overload struct parameters by ref-ness. So we had to generate by-value parameters where Qt has them by reference. And today we've encountered two other bugs in sequence. One was about the impossibility to access a template instance member from within a struct nested in another struct and the second didn't give any line/file information. We could probably work around or ignore all these problems but I think it is starting to take more time and nerve than we can afford.
Sep 16 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/16/10 14:37 CDT, Max Samukha wrote:
 On 09/16/2010 06:44 PM, Andrei Alexandrescu wrote:
 On 9/16/10 9:22 CDT, Max Samukha wrote:
 After a good amount of hesitation, we have decided to put the QtD
 project on hold. QtD has a potential to become a complete and effective
 development platform for D but it is not going to happen soon (unless
 people with harder hearts take it over). We have spent half of the day
 hunting yet another dmd bug-o-feature and that is the last straw.

 We offer our apologies to people who put their hope upon the project.
 Please come back in a year or two when the language has a stable
 compiler with the features fully specified, implemented and debugged.

Hi Max, Sorry to hear that. Was this an issue of many small annoyances or a few big ones? Thanks, Andrei

Hi Andrei, Both, I guess.

Thanks for replying. This is very helpful. I'll make some points below, definitely not as an attempt to revisit the decision you've already made.
 The recent big one is the unspecified behavior of
 postblit on const/immutable structs and overloading by rvalue/lvalue.
 Specifically, we were bending the generator into generating Qt value
 types as structs and hit two problems:

 1. The generated __cpctor (which does the blit and calls the postblit)
 is always non-const and takes a non-const reference to the original.
 That means copy-construction of const objects is impossible without casts.

 To proceed, we had to hack the compiler so that __cpctor took a const
 original reference and was called on a mutable target reference. That
 seemed to work but left us in uncertainty: how it actually should and
 will work?

Walter and I discussed a fair amount about copying objects with different qualifiers. The syntax we discussed was this(this) const { ... } which would be called after you copy a const or non-const object into a const object. Certain special typechecking applies inside that constructor, but nothing really difficult; it does entail a fair amount of work in the front end, which Walter hasn't find the time to put in. On a funny note, we figured that for a number of reasons it would help to allow C++-style constructors that offer access to the source; it just turns out some idioms need to modify the source as well as the destination. One obvious example is the built-in hashtable that is not shared properly when it's null. Making the copy constructor spring the hashtable to life would make it more uniform in behavior. The situation is a bit ironic - we worked on improving upon C++ constructors but it turns out something similar is still needed in certain situations. Anyway, regardless of whether C++-style constructors will be supported (as an alternative to postblit), the issue you mention is serious. But by and large I think the matter could gave have be settled in a different manner: by not catering for const in the first release. D has a lot to offer besides const, and its const subsystem is a good bit more restrictive than e.g. C++'s, mainly to help with concurrency. So until the typical D idioms for using const become established, it's not a crime to have QtD work without const. I wouldn't go back from a Lexus to a Yugo because the Lexus doesn't have a butt warmer :o).
 2. A bug in the compiler doesn't allow us to overload struct parameters
 by ref-ness. So we had to generate by-value parameters where Qt has them
 by reference.

 And today we've encountered two other bugs in sequence. One was about
 the impossibility to access a template instance member from within a
 struct nested in another struct and the second didn't give any line/file
 information.

 We could probably work around or ignore all these problems but I think
 it is starting to take more time and nerve than we can afford.

I understand. Let me ask you this - if your bugs had #1 priority, would that have helped? I mean, is the slow response time to bug submissions a large annoyance factor? Thanks, Andrei
Sep 17 2010
next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 09/17/2010 11:15 AM, Andrei Alexandrescu wrote:
 Thanks for replying. This is very helpful. I'll make some points below,
 definitely not as an attempt to revisit the decision you've already made.

 The recent big one is the unspecified behavior of
 postblit on const/immutable structs and overloading by rvalue/lvalue.
 Specifically, we were bending the generator into generating Qt value
 types as structs and hit two problems:

 1. The generated __cpctor (which does the blit and calls the postblit)
 is always non-const and takes a non-const reference to the original.
 That means copy-construction of const objects is impossible without
 casts.

 To proceed, we had to hack the compiler so that __cpctor took a const
 original reference and was called on a mutable target reference. That
 seemed to work but left us in uncertainty: how it actually should and
 will work?

Walter and I discussed a fair amount about copying objects with different qualifiers. The syntax we discussed was this(this) const { ... } which would be called after you copy a const or non-const object into a const object. Certain special typechecking applies inside that constructor, but nothing really difficult; it does entail a fair amount of work in the front end, which Walter hasn't find the time to put in.

Nice to hear that the problem is being worked on. What kind of typechecking will be performed in const/immutable postblit?
 On a funny note, we figured that for a number of reasons it would help
 to allow C++-style constructors that offer access to the source; it just
 turns out some idioms need to modify the source as well as the destination.

Funny. We seem to be in the opposite situation. We originally thought that postblit won't be enough for QtD but it looks like copying most (or all, not sure) value types in Qt do not need access to the source object.
 One obvious example is the built-in hashtable that is not shared
 properly when it's null. Making the copy constructor spring the
 hashtable to life would make it more uniform in behavior.

 The situation is a bit ironic - we worked on improving upon C++
 constructors but it turns out something similar is still needed in
 certain situations.

 Anyway, regardless of whether C++-style constructors will be supported
 (as an alternative to postblit), the issue you mention is serious. But
 by and large I think the matter could gave have be settled in a
 different manner: by not catering for const in the first release. D has
 a lot to offer besides const, and its const subsystem is a good bit more
 restrictive than e.g. C++'s, mainly to help with concurrency. So until
 the typical D idioms for using const become established, it's not a
 crime to have QtD work without const.

The thing is that D's const looked well suited for our purpose. Postblit and const were discussed in TDPL so we concluded that their design and implementation were more or less complete and harmonized. We took the effort to change the generator to properly generate const qualifiers and only after that discovered the postblit issues.
 I wouldn't go back from a Lexus to
 a Yugo because the Lexus doesn't have a butt warmer :o).

:) The Lexus doesn't start and has an obscenity scratched on its hood. A butt warmer would double its resale price.
 2. A bug in the compiler doesn't allow us to overload struct parameters
 by ref-ness. So we had to generate by-value parameters where Qt has them
 by reference.

 And today we've encountered two other bugs in sequence. One was about
 the impossibility to access a template instance member from within a
 struct nested in another struct and the second didn't give any line/file
 information.

 We could probably work around or ignore all these problems but I think
 it is starting to take more time and nerve than we can afford.

I understand. Let me ask you this - if your bugs had #1 priority, would that have helped? I mean, is the slow response time to bug submissions a large annoyance factor?

Definitely. The notorious one (http://d.puremagic.com/issues/show_bug.cgi?id=424), which hindered QtD development on Windows, drove a couple of good users away from D and became a powerful FUD generator, was submitted 4 years ago.
 Thanks,

 Andrei

I think one of the big factors causing annoyances is miscommunication. While you have immediate access to Walter, most of us have to settle for this NG and #d IRC channel (the latter has become a source of nothing but discouragement). We carefully follow discussions (at least we try to) in the mail-lists and NG but often do not know what is the final decision on a problem having been discussed. One example is the semantics of clear() and scoped(). As I understood from one of your posts, you agree that resurrecting the destroyed object by calling its default constructor is objectionable. However, no further action followed. So we are at a loss whether you have a better solution, are still thinking about one, don't have time to change the implementation or don't want to change the thing because it is engraved in TDPL. The same applies to 'scoped' moving the object. Another example is half-implemented 'inout'. Is a correct implementation fundamentally impossible or Walter haven't had time for it? Such unterminated discussions tend to stack up in our minds creating a possibly very exaggerated image of instability.
Sep 17 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/17/2010 09:02 AM, Max Samukha wrote:
 On 09/17/2010 11:15 AM, Andrei Alexandrescu wrote:
 Nice to hear that the problem is being worked on. What kind of
 typechecking will be performed in const/immutable postblit?

The tricky part in that constructor is that you must be able to assign the fields, so they are effectively non-const, but you must NOT escape outside the constructor as modifiable lvalues. Consider: int * global; void foo(ref int x) { global = &x; } struct S { int a; this(this) immutable { a = 5; foo(a); } } The program should not compile. If it did, global would be a backdoor for modifying an immutable object. Replacing const with immutable seems to make things less stringent, but not in reality. The same typechecking must be applied to const postblit because const is a subtype of immutable.
 On a funny note, we figured that for a number of reasons it would help
 to allow C++-style constructors that offer access to the source; it just
 turns out some idioms need to modify the source as well as the
 destination.

Funny. We seem to be in the opposite situation. We originally thought that postblit won't be enough for QtD but it looks like copying most (or all, not sure) value types in Qt do not need access to the source object.

Yah, it's a relatively rare situation. I enjoy the robustness of this(this), but see my most recent post.
 The thing is that D's const looked well suited for our purpose. Postblit
 and const were discussed in TDPL so we concluded that their design and
 implementation were more or less complete and harmonized. We took the
 effort to change the generator to properly generate const qualifiers and
 only after that discovered the postblit issues.

I understand. Were it not for that particular issue, it's not impossible you would have run into some others. D's immutability subsystem is not new, but it's one of the first deployed in a practical language. Just like with other features (exceptions, templates, lambdas, AOP...), some time is needed for the appropriate idioms to emerge. QtD was the first large-scale deployment of const, and it was expected to run into practical as well as theoretical matters. We haven't deployed const into Phobos yet for the same reason, and there is ongoing discussion on how to best go about it. Bottom line, I have a few thoughts on the matter. First, at this point in const's maturity, it's easier to convert a working codebase to using const than to design one from scratch for const. This is counter-intuitive, but it's dictated by const's immaturity. I'm sure the trend will reverse in a couple of years. (Come to think of this: it took over 15 years for C++'s exceptions to achieve any sign of idiomatic usage, and even now very few people know e.g. how to transport one exception from a thread to another. Java has made obvious-in-hindsight errors in designing its exception subsystem, even though it already had a large body of experience with C++ at its disposal.) Second thought is, I am sure the use of D's const, even after it matures, will be less pervasive than the use of const in C++. This inescapably follows from the fact that D const guarantees more and is more restrictive than C++'s const. In C++ I slap const on anything that comes in sight: function parameters, stack variables, member functions... At the same time, I fully realize that the assurance I get in return is quite weak. In D, I afford only a subset of uses of const, but the payout is much more powerful. Third thought is, we did not find the design for immutable and const as much as the design found us. What we wanted was a guarantee that you get to share immutable data, which we always believed is fundamental. Everything else was aftermath.
 I wouldn't go back from a Lexus to
 a Yugo because the Lexus doesn't have a butt warmer :o).

:) The Lexus doesn't start and has an obscenity scratched on its hood. A butt warmer would double its resale price.

And a tank full of gas would triple it :o).
 I understand. Let me ask you this - if your bugs had #1 priority, would
 that have helped? I mean, is the slow response time to bug submissions a
 large annoyance factor?

Definitely. The notorious one (http://d.puremagic.com/issues/show_bug.cgi?id=424), which hindered QtD development on Windows, drove a couple of good users away from D and became a powerful FUD generator, was submitted 4 years ago.

That bug comes often in my chats with Walter. The fact of the matter is that that is a difficult bug to find and fix in an assembly program. Walter is working slowly on translating the linker into C, which should simplify a lot of things. I'll also add that he did fix two comparably pernicious linker bugs, one recently.
 I think one of the big factors causing annoyances is miscommunication.
 While you have immediate access to Walter, most of us have to settle for
 this NG and #d IRC channel (the latter has become a source of nothing
 but discouragement).

Yah :o). I occasionally lurk there. It's amusing but hardly productive.
 We carefully follow discussions (at least we try to) in the mail-lists
 and NG but often do not know what is the final decision on a problem
 having been discussed.

I understand. At the same time, only this post took me quite a long time. Just like you all, most of my time of day is already spoken for. Doing my best.
 One example is the semantics of clear() and scoped(). As I understood
 from one of your posts, you agree that resurrecting the destroyed object
 by calling its default constructor is objectionable. However, no further
 action followed. So we are at a loss whether you have a better solution,
 are still thinking about one, don't have time to change the
 implementation or don't want to change the thing because it is engraved
 in TDPL. The same applies to 'scoped' moving the object.

Good point. Also, clear() has been a favorite topic on #d because it's good evidence of my incompetence. The intent of clear(obj) is rather simple. It's supposed to put obj in a well-defined, destroyable state that does not allocate resources. It's the type system's last-ditch effort to preserve safety while at the same time releasing all object state. Currently, clear() works incorrectly for classes, where it invokes the default constructor. SVN doesn't assign the blame to me, but the decision does originate in discussions I took part in. clear() shouldn't call the default constructor of the class because then the class object is free to allocate resources once again. What it should do is to blast the default initializer for each field in the class. That's a well-defined state that doesn't allocate resources - great. There are two problems with that state. One, the state might fail the invariant of the object, but that's expected - once you called clear(), you leave an empty shell behind that's unusable unless you reseat something into it. Second, calling the destructor again from that state is problematic (because of failing the invariant) and the GC calls the destructor. This is also solvable: the GC might memcmp() the state of the object against its default state. If comparison comes positive, the destructor is not invoked. We need to be careful that doesn't impact collection times.
 Another example is half-implemented 'inout'. Is a correct implementation
 fundamentally impossible or Walter haven't had time for it?

A correct implementation is possible and we have a good understanding of what it takes. Walter didn't get around to it yet.
 Such unterminated discussions tend to stack up in our minds creating a
 possibly very exaggerated image of instability.

I understand. Oddly enough, we only now have such a productive discussion, after the destructor has been called :o). Andrei
Sep 17 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 On a funny note, we figured that for a number of reasons it would help 
 to allow C++-style constructors that offer access to the source; it 
 just turns out some idioms need to modify the source as well as the 
 destination.
 
 One obvious example is the built-in hashtable that is not shared 
 properly when it's null. Making the copy constructor spring the 
 hashtable to life would make it more uniform in behavior.

At the basic level I feel uneasy with this whole idea of modifying the source while copying. It means that you can't copy the source if it is const. Do you really want to make const containers uncopyable? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 17 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/17/10 9:18 CDT, Michel Fortin wrote:
 On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 On a funny note, we figured that for a number of reasons it would help
 to allow C++-style constructors that offer access to the source; it
 just turns out some idioms need to modify the source as well as the
 destination.

 One obvious example is the built-in hashtable that is not shared
 properly when it's null. Making the copy constructor spring the
 hashtable to life would make it more uniform in behavior.

At the basic level I feel uneasy with this whole idea of modifying the source while copying. It means that you can't copy the source if it is const. Do you really want to make const containers uncopyable?

Again, the scenario is motivated by this: void main() { int[int] hash; fun(hash); assert(!(42 in hash)); hash[0] = 10; fun(hash); assert(42 in hash); } void fun(int[int] hash) { hash[42] = 42; } Walter's idea was as follows. If the hash's copy constructor has access to the source, then that constructor could lazily initialize the pointer internally shared by the existing instance (the one in main()) and the one being created (the one passed to fun()). Then, the program would behave more predictably and also stay efficient - lazy initialization for the win. Note that const objects don't have this problem. Also note that the non-null reference matter is related to this one. Andrei
Sep 17 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-09-17 11:14:21 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 On 9/17/10 9:18 CDT, Michel Fortin wrote:
 On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:
 
 On a funny note, we figured that for a number of reasons it would help
 to allow C++-style constructors that offer access to the source; it
 just turns out some idioms need to modify the source as well as the
 destination.
 
 One obvious example is the built-in hashtable that is not shared
 properly when it's null. Making the copy constructor spring the
 hashtable to life would make it more uniform in behavior.

At the basic level I feel uneasy with this whole idea of modifying the source while copying. It means that you can't copy the source if it is const. Do you really want to make const containers uncopyable?

Again, the scenario is motivated by this: void main() { int[int] hash; fun(hash); assert(!(42 in hash)); hash[0] = 10; fun(hash); assert(42 in hash); } void fun(int[int] hash) { hash[42] = 42; } Walter's idea was as follows. If the hash's copy constructor has access to the source, then that constructor could lazily initialize the pointer internally shared by the existing instance (the one in main()) and the one being created (the one passed to fun()). Then, the program would behave more predictably and also stay efficient - lazy initialization for the win.

I understand the intent quite well. I'm talking about what happens if the source is const? As in: struct A { int[int] hash; int[int] fun() { return hash; // hash can be altered, can copy } const const(int[int]) fun() { return hash; // here hash is const, what happens? } } With the second accessor the hash is const, so how can you copy it anywhere if copying requires altering the original? Should it be an error? Should the copy be detached when the source is const, breaking reference semantics? Or should we add logical-const (in addition to C++-style constructors)? Now that I think of it, you don't need a fancy struct to make this problem appear, you just need two layers of functions: void fun(const(int[int]) hash) { fun(hash); // calling ourself, how can we copy hash? } Although in this case we could probably assert() that hash is already initialized. In my mind it's simpler to just explain the notion that an uninitialized hash is null and detached from anything else until initialized. Objects works like this (minus the implicit initialization part), so it shouldn't be too hard to understand. Better have pragmatic semantics that work rather than idealistic semantics that fail at a number of cases. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 17 2010
next sibling parent Max Samukha <spambox d-coding.com> writes:
On 09/17/2010 06:48 PM, Michel Fortin wrote:
 On 2010-09-17 11:14:21 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 Now that I think of it, you don't need a fancy struct to make this
 problem appear, you just need two layers of functions:

 void fun(const(int[int]) hash) {
 fun(hash); // calling ourself, how can we copy hash?
 }

 Although in this case we could probably assert() that hash is already
 initialized.

 In my mind it's simpler to just explain the notion that an uninitialized
 hash is null and detached from anything else until initialized. Objects
 works like this (minus the implicit initialization part), so it
 shouldn't be too hard to understand. Better have pragmatic semantics
 that work rather than idealistic semantics that fail at a number of cases.

Another difference between object and AA - if one wants to initialize a class object reference, he does it with a sane syntax. To eagerly initialize an empty AA, woodoo is needed.
Sep 17 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/17/10 10:48 CDT, Michel Fortin wrote:
 I understand the intent quite well. I'm talking about what happens if
 the source is const?

The whole point is, mutation is the motivator. If you copy an empty hash, no problem because the receiver can't mutate it.
 In my mind it's simpler to just explain the notion that an uninitialized
 hash is null and detached from anything else until initialized. Objects
 works like this (minus the implicit initialization part), so it
 shouldn't be too hard to understand. Better have pragmatic semantics
 that work rather than idealistic semantics that fail at a number of cases.

That's a fair point. Andrei
Sep 17 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/17/10 12:04 CDT, Steven Schveighoffer wrote:
 On Fri, 17 Sep 2010 12:44:30 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 9/17/10 10:48 CDT, Michel Fortin wrote:
 I understand the intent quite well. I'm talking about what happens if
 the source is const?

The whole point is, mutation is the motivator. If you copy an empty hash, no problem because the receiver can't mutate it.

yeah, but he can read it: struct S { int[int] hash; const(int[int]) getHash() const { return hash; } } void main() { S s; auto h = s.getHash(); s.hash[1] = 1; assert(1 in h); // fails } -Steve

Good point! Andrei
Sep 17 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 9/17/10 10:48 CDT, Michel Fortin wrote:
 I understand the intent quite well. I'm talking about what happens if
 the source is const?

The whole point is, mutation is the motivator. If you copy an empty hash, no problem because the receiver can't mutate it.

Wouldn't copying a ref counted object require mutating the original?
Sep 17 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-09-17 21:08:29 -0400, Walter Bright <newshound2 digitalmars.com> said:

 Andrei Alexandrescu wrote:
 On 9/17/10 10:48 CDT, Michel Fortin wrote:
 I understand the intent quite well. I'm talking about what happens if
 the source is const?

The whole point is, mutation is the motivator. If you copy an empty hash, no problem because the receiver can't mutate it.

Wouldn't copying a ref counted object require mutating the original?

This is an interesting point. Reference counting requires updating the reference counter which lives alongside the referenced memory. So if you have a const reference-counting struct, you can't make a copy of it because const will transitively apply to the counter too, preventing it from being incremented. I'm not sure why you're talking about mutating "the original" though. You don't need to update the original smart pointer struct as the reference counter lives with the referenced memory to which you have access in postblit. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 17 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 17/09/2010 17:44, Andrei Alexandrescu wrote:
 On 9/17/10 10:48 CDT, Michel Fortin wrote:
 In my mind it's simpler to just explain the notion that an uninitialized
 hash is null and detached from anything else until initialized. Objects
 works like this (minus the implicit initialization part), so it
 shouldn't be too hard to understand. Better have pragmatic semantics
 that work rather than idealistic semantics that fail at a number of
 cases.

That's a fair point. Andrei

And perhaps even better would be to have the associative-arrays/hash-maps behave just like an object (and dynamic arrays), instead of being a covert pseudo-reference type that gets implicitly initialized. It is a more natural and consistent behavior. The only claimed drawback is performance, but I'm having a hard time understanding what use case motivates this: why do we want lazy initialized hashmaps anyways? You only get a performance benefit in the cases where you end up using the hashmap but not require it to be initialized, and these cases seems fairly rare. I don't think they justify the current behavior. Can someone give me a code sample or scenario where hashmap lazy initialization would be better than the more orthogonal object-like approach I mentioned above? -- Bruno Medeiros - Software Engineer
Oct 08 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 17 Sep 2010 12:39:06 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 09/17/2010 09:02 AM, Max Samukha wrote:

 One example is the semantics of clear() and scoped(). As I understood
 from one of your posts, you agree that resurrecting the destroyed object
 by calling its default constructor is objectionable. However, no further
 action followed. So we are at a loss whether you have a better solution,
 are still thinking about one, don't have time to change the
 implementation or don't want to change the thing because it is engraved
 in TDPL. The same applies to 'scoped' moving the object.

Good point. Also, clear() has been a favorite topic on #d because it's good evidence of my incompetence.

One bad decision does not mean incompetence unless you're in politics...
 The intent of clear(obj) is rather simple. It's supposed to put obj in a  
 well-defined, destroyable state that does not allocate resources. It's  
 the type system's last-ditch effort to preserve safety while at the same  
 time releasing all object state.

 Currently, clear() works incorrectly for classes, where it invokes the  
 default constructor. SVN doesn't assign the blame to me, but the  
 decision does originate in discussions I took part in. clear() shouldn't  
 call the default constructor of the class because then the class object  
 is free to allocate resources once again. What it should do is to blast  
 the default initializer for each field in the class. That's a  
 well-defined state that doesn't allocate resources - great.

 There are two problems with that state. One, the state might fail the  
 invariant of the object, but that's expected - once you called clear(),  
 you leave an empty shell behind that's unusable unless you reseat  
 something into it.

 Second, calling the destructor again from that state is problematic  
 (because of failing the invariant) and the GC calls the destructor. This  
 is also solvable: the GC might memcmp() the state of the object against  
 its default state. If comparison comes positive, the destructor is not  
 invoked. We need to be careful that doesn't impact collection times.

Slightly OT here, but memcmp isn't necessary. We have a couple easy tools at our disposal. One I've suggested in the past -- zero out the vtable. This makes a loud error if you try to use the object again (and I even think Sean added stack traces to null pointer violations recently), plus gives no access to the destructor (easily detectable by the GC). The other I just thought of, each object memory block has a GC flag (FINALIZE?) that indicates it should run a destructor. Just clear that flag. This may need some optimization, I think at the moment you need to take the GC lock. If you want to continue this discussion, move to D newsgroup probably... -Steve
Sep 17 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 17 Sep 2010 12:44:30 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 9/17/10 10:48 CDT, Michel Fortin wrote:
 I understand the intent quite well. I'm talking about what happens if
 the source is const?

The whole point is, mutation is the motivator. If you copy an empty hash, no problem because the receiver can't mutate it.

yeah, but he can read it: struct S { int[int] hash; const(int[int]) getHash() const { return hash; } } void main() { S s; auto h = s.getHash(); s.hash[1] = 1; assert(1 in h); // fails } -Steve
Sep 17 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Max Samukha wrote:

 After a good amount of hesitation, we have decided to put the QtD
 project on hold. QtD has a potential to become a complete and effective
 development platform for D but it is not going to happen soon (unless
 people with harder hearts take it over). We have spent half of the day
 hunting yet another dmd bug-o-feature and that is the last straw.
 
 We offer our apologies to people who put their hope upon the project.
 Please come back in a year or two when the language has a stable
 compiler with the features fully specified, implemented and debugged.

This is a loss, it must be frustrating for you spending so much time on it. Thank you anyway for the effort, it was quite exciting to see QtD almost come to be! I hope it will be continued some day.
Sep 16 2010
parent reply Georg Wrede <Georg.Wrede iki.fi> writes:
On 09/17/2010 01:01 AM, Lutger wrote:
 Max Samukha wrote:

 After a good amount of hesitation, we have decided to put the QtD
 project on hold. QtD has a potential to become a complete and effective
 development platform for D but it is not going to happen soon (unless
 people with harder hearts take it over). We have spent half of the day
 hunting yet another dmd bug-o-feature and that is the last straw.

 We offer our apologies to people who put their hope upon the project.
 Please come back in a year or two when the language has a stable
 compiler with the features fully specified, implemented and debugged.

This is a loss, it must be frustrating for you spending so much time on it. Thank you anyway for the effort, it was quite exciting to see QtD almost come to be! I hope it will be continued some day.

Having some experience in this, I really don't think other people can even begin to think what Max feels at this point. I could go on-and-on about this, but those who've never invested enough to break their back and then simply be met by folks who !believe! they have any way of understanding, I really think they should stay shut up. I left the language because of a personal quarrel with Andrei. And that was long after vigorously defending him in the Big Battle. But that should not mean I have any second thoughts about what should be done, or whether we can pull it off. The language as such, has a niche way bigger than it'd seem, in spite of reading this NG or the random outside article (found with Google). Man, I'd love to become an evangelist for D, and I really have a few ideas (that presumably, most of our long-time contributors recognize), that would help D in carving its own footprint on the map. The place and position are now very much clearer to me, than they were six months ago. This would mean establishing a place that doesn't necessarily challenge ASM, C, C++, or Python or Java. And, within this particular place, none of them can possibly challenge D. (!!)
Sep 16 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/16/10 18:48 CDT, Georg Wrede wrote:
 On 09/17/2010 01:01 AM, Lutger wrote:
 Max Samukha wrote:

 After a good amount of hesitation, we have decided to put the QtD
 project on hold. QtD has a potential to become a complete and effective
 development platform for D but it is not going to happen soon (unless
 people with harder hearts take it over). We have spent half of the day
 hunting yet another dmd bug-o-feature and that is the last straw.

 We offer our apologies to people who put their hope upon the project.
 Please come back in a year or two when the language has a stable
 compiler with the features fully specified, implemented and debugged.

This is a loss, it must be frustrating for you spending so much time on it. Thank you anyway for the effort, it was quite exciting to see QtD almost come to be! I hope it will be continued some day.

Having some experience in this, I really don't think other people can even begin to think what Max feels at this point. I could go on-and-on about this, but those who've never invested enough to break their back and then simply be met by folks who !believe! they have any way of understanding, I really think they should stay shut up.

Well I've used D for my thesis work since 2007, and indeed bugs can be very frustrating particularly when you're pressured to achieve something else than just finding your way around issues.
 I left the language because of a personal quarrel with Andrei.

I do recall you were annoyed at some point but I failed to perceive the extent. If there's anything I can do at this point to make things straight, please let me know.
 And that
 was long after vigorously defending him in the Big Battle. But that
 should not mean I have any second thoughts about what should be done, or
 whether we can pull it off.

 The language as such, has a niche way bigger than it'd seem, in spite of
 reading this NG or the random outside article (found with Google). Man,
 I'd love to become an evangelist for D, and I really have a few ideas
 (that presumably, most of our long-time contributors recognize), that
 would help D in carving its own footprint on the map.

 The place and position are now very much clearer to me, than they were
 six months ago. This would mean establishing a place that doesn't
 necessarily challenge ASM, C, C++, or Python or Java. And, within this
 particular place, none of them can possibly challenge D. (!!)

I'm sure we all here would be interested to hear more of your ideas. Thanks, Andrei
Sep 16 2010
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Georg Wrede wrote:

 On 09/17/2010 01:01 AM, Lutger wrote:
 Max Samukha wrote:

 After a good amount of hesitation, we have decided to put the QtD
 project on hold. QtD has a potential to become a complete and effective
 development platform for D but it is not going to happen soon (unless
 people with harder hearts take it over). We have spent half of the day
 hunting yet another dmd bug-o-feature and that is the last straw.

 We offer our apologies to people who put their hope upon the project.
 Please come back in a year or two when the language has a stable
 compiler with the features fully specified, implemented and debugged.

This is a loss, it must be frustrating for you spending so much time on it. Thank you anyway for the effort, it was quite exciting to see QtD almost come to be! I hope it will be continued some day.

Having some experience in this, I really don't think other people can even begin to think what Max feels at this point. I could go on-and-on about this, but those who've never invested enough to break their back and then simply be met by folks who !believe! they have any way of understanding, I really think they should stay shut up.

I take it this is directed at me. Look, it was a gut reaction. I don't understand why, but if anyone takes offense I'm sorry, I didn't want to provoke that.
Sep 17 2010
parent Max Samukha <spambox d-coding.com> writes:
On 09/17/2010 07:37 PM, Lutger wrote:
 Georg Wrede wrote:

 I take it this is directed at me. Look, it was a gut reaction. I don't
 understand why, but if anyone takes offense I'm sorry, I didn't want to provoke
 that.

I don't see why anybody should take offense from what you said. Quite the opposite - thanks for being around. I think Georg directed those words to somebody else.
Sep 21 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Is the most recent flavor of QtD the repositoy at bitbucket?
Sep 16 2010
parent klickverbot <see klickverbot.at> writes:
On 9/17/10 12:25 AM, Lutger wrote:
 Is the most recent flavor of QtD the repositoy at bitbucket?

Yes, it is. Reminds me that someone should probably update the Wiki page at dsourceā€¦
Sep 16 2010
prev sibling next sibling parent reply Emil Madsen <sovende gmail.com> writes:
--0015174c3bbc312e6204912a8b30
Content-Type: text/plain; charset=ISO-8859-1

Just curious about QtD, how far did the design process go in terms of %
before it got suspended?
10% - 25% - 50%? - and what would the time approximations be to finish it?

On 16 September 2010 16:22, Max Samukha <spambox d-coding.com> wrote:

 After a good amount of hesitation, we have decided to put the QtD project
 on hold. QtD has a potential to become a complete and effective development
 platform for D but it is not going to happen soon (unless people with harder
 hearts take it over). We have spent half of the day hunting yet another dmd
 bug-o-feature and that is the last straw.

 We offer our apologies to people who put their hope upon the project.
 Please come back in a year or two when the language has a stable compiler
 with the features fully specified, implemented and debugged.

-- // Yours sincerely // Emil 'Skeen' Madsen --0015174c3bbc312e6204912a8b30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Just curious about QtD, how far did the design process go in terms of = % before it got suspended?<br></div><div>10% - 25% - 50%? - and what would = the time approximations be to finish it?</div><br><div class=3D"gmail_quote= "> On 16 September 2010 16:22, Max Samukha <span dir=3D"ltr">&lt;<a href=3D"ma= ilto:spambox d-coding.com">spambox d-coding.com</a>&gt;</span> wrote:<br><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex;"> After a good amount of hesitation, we have decided to put the QtD project o= n hold. QtD has a potential to become a complete and effective development = platform for D but it is not going to happen soon (unless people with harde= r hearts take it over). We have spent half of the day hunting yet another d= md bug-o-feature and that is the last straw.<br> <br> We offer our apologies to people who put their hope upon the project. Pleas= e come back in a year or two when the language has a stable compiler with t= he features fully specified, implemented and debugged.<br> <br> </blockquote></div><br><br clear=3D"all"><br>-- <br>// Yours sincerely<br>/= / Emil &#39;Skeen&#39; Madsen<br> --0015174c3bbc312e6204912a8b30--
Sep 26 2010
parent reply Max Samukha <spambox d-coding.com> writes:
On 09/26/2010 05:36 PM, Emil Madsen wrote:
 Just curious about QtD, how far did the design process go in terms of %
 before it got suspended?
 10% - 25% - 50%? - and what would the time approximations be to finish it?

 On 16 September 2010 16:22, Max Samukha <spambox d-coding.com
 <mailto:spambox d-coding.com>> wrote:

     After a good amount of hesitation, we have decided to put the QtD
     project on hold. QtD has a potential to become a complete and
     effective development platform for D but it is not going to happen
     soon (unless people with harder hearts take it over). We have spent
     half of the day hunting yet another dmd bug-o-feature and that is
     the last straw.

     We offer our apologies to people who put their hope upon the
     project. Please come back in a year or two when the language has a
     stable compiler with the features fully specified, implemented and
     debugged.




 --
 // Yours sincerely
 // Emil 'Skeen' Madsen

I guess it is about 67%. Basic stuff is in place, including cross-language virtual dispatch, partially meta-object system, signals/slots etc, but more advanced features like Q_PROPERTY are to be implemented. A couple of months (very roughly) before we have a stable and feature-compete version.
Sep 26 2010
parent Max Samukha <spambox d-coding.com> writes:
On 09/27/2010 09:15 AM, Emil Madsen wrote:
 Is there a partly complete release? - that just basic stuff available?

Latest trunk: http://bitbucket.org/qtd/repo Wiki: http://www.dsource.org/projects/qtd I have a local branch that should fix a couple of major problems but it is not ready for a commit. Among other things, it supports generating struct wrappers for Qt value types, making it obvious that the lack of default struct constructors is a disaster.
Sep 29 2010
prev sibling parent Emil Madsen <sovende gmail.com> writes:
--0015174be87276f54e049137a8e1
Content-Type: text/plain; charset=ISO-8859-1

Is there a partly complete release? - that just basic stuff available?

On 26 September 2010 19:04, Max Samukha <spambox d-coding.com> wrote:

 On 09/26/2010 05:36 PM, Emil Madsen wrote:

 Just curious about QtD, how far did the design process go in terms of %
 before it got suspended?
 10% - 25% - 50%? - and what would the time approximations be to finish it?

 On 16 September 2010 16:22, Max Samukha <spambox d-coding.com
 <mailto:spambox d-coding.com>> wrote:

    After a good amount of hesitation, we have decided to put the QtD
    project on hold. QtD has a potential to become a complete and
    effective development platform for D but it is not going to happen
    soon (unless people with harder hearts take it over). We have spent
    half of the day hunting yet another dmd bug-o-feature and that is
    the last straw.

    We offer our apologies to people who put their hope upon the
    project. Please come back in a year or two when the language has a
    stable compiler with the features fully specified, implemented and
    debugged.




 --

 // Yours sincerely
 // Emil 'Skeen' Madsen

I guess it is about 67%. Basic stuff is in place, including cross-language virtual dispatch, partially meta-object system, signals/slots etc, but more advanced features like Q_PROPERTY are to be implemented. A couple of months (very roughly) before we have a stable and feature-compete version.

-- // Yours sincerely // Emil 'Skeen' Madsen --0015174be87276f54e049137a8e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is there a partly complete release? - that just basic stuff available?<br><= br><div class=3D"gmail_quote">On 26 September 2010 19:04, Max Samukha <span= dir=3D"ltr">&lt;<a href=3D"mailto:spambox d-coding.com">spambox d-coding.c= om</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">On 09/26/2010 05:36 PM, E= mil Madsen wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> Just curious about QtD, how far did the design process go in terms of %<br> before it got suspended?<br> 10% - 25% - 50%? - and what would the time approximations be to finish it?<= br> <br> On 16 September 2010 16:22, Max Samukha &lt;<a href=3D"mailto:spambox d-cod= ing.com" target=3D"_blank">spambox d-coding.com</a><br></div><div><div clas= s=3D"h5"> &lt;mailto:<a href=3D"mailto:spambox d-coding.com" target=3D"_blank">spambo= x d-coding.com</a>&gt;&gt; wrote:<br> <br> =A0 =A0After a good amount of hesitation, we have decided to put the QtD<b= r> =A0 =A0project on hold. QtD has a potential to become a complete and<br> =A0 =A0effective development platform for D but it is not going to happen<= br> =A0 =A0soon (unless people with harder hearts take it over). We have spent= <br> =A0 =A0half of the day hunting yet another dmd bug-o-feature and that is<b= r> =A0 =A0the last straw.<br> <br> =A0 =A0We offer our apologies to people who put their hope upon the<br> =A0 =A0project. Please come back in a year or two when the language has a<= br> =A0 =A0stable compiler with the features fully specified, implemented and<= br> =A0 =A0debugged.<br> <br> <br> <br> <br></div></div> --<div class=3D"im"><br> // Yours sincerely<br> // Emil &#39;Skeen&#39; Madsen<br> </div></blockquote> <br> I guess it is about 67%. Basic stuff is in place, including cross-language = virtual dispatch, partially meta-object system, signals/slots etc, but more= advanced features like Q_PROPERTY are to be implemented. A couple of month= s (very roughly) before we have a stable and feature-compete version.<br> </blockquote></div><br><br clear=3D"all"><br>-- <br>// Yours sincerely<br>/= / Emil &#39;Skeen&#39; Madsen<br> --0015174be87276f54e049137a8e1--
Sep 26 2010