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
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.



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.



 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 reply 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).



 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
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 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 reply "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
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 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 parent reply Emil Madsen <sovende gmail.com> writes:
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
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 reply Emil Madsen <sovende gmail.com> writes:
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
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