Walter Bright Wrote:

> The large volume of bug fixes is because a lot of people contributed patches. Thanks!
> 
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.042.zip
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.027.zip

Walter, there is still a reference to 'new.h' in dmd 1.042 in 'ph.c'.

在 Wed, 01 Apr 2009 17:13:45 +0800，Walter Bright <newshound1@digitalmars.com> 写道:

> Max Samukha wrote:
>> Great! Does it mean opDot is deprecated?
>
> Yes.

I wish opDot be changed to something else like the thing that I proposed in my last reply.

davidl wrote:
> 在 Wed, 01 Apr 2009 16:43:57 +0800，Max Samukha <samukha@voliacable.com.removethis> 写道:
> 
>> On Tue, 31 Mar 2009 22:21:59 -0700, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>
>>> The large volume of bug fixes is because a lot of people contributed
>>> patches. Thanks!
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.042.zip
>>>
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.027.zip
>>
>> Great! Does it mean opDot is deprecated?
> 
> why not make opDot some compile time stuff?
> 
> class V
> {
>     opDot(char[] method, ...)
>     {
>         // runtime lib to figure what the method is, and then call it with vararg!
>     }
> }

I'm in favor of adding more dynamic stuff to D, but it's going to happen slowly.

davidl:
> why not make opDot some compile time stuff?

You mean run time.

> this can be particular useful for COM

And GUIs, I guess. It smells of Object-C++, but the syntax is nicer.
But such runtime code must be not included into the executable if this feature is nowhere used in the code. D executable are already quite big enough.

Bye,
bearophile

bearophile wrote:
> davidl:
>> why not make opDot some compile time stuff?
> 
> You mean run time.

No, he means compile time. The name becomes a template value parameter, which is available at compile time.

> 
>> this can be particular useful for COM
> 
> And GUIs, I guess. It smells of Object-C++, but the syntax is nicer.
> But such runtime code must be not included into the executable if this feature is nowhere used in the code. D executable are already quite big enough.

There's not necessarily any runtime code.

> 
> Bye,
> bearophile

Walter Bright:

>On Windows, if there are multiple source files on the command line they are now read with a background thread. This may speed up compilation.<

I have tried on Windows, on a 2-core CPU and the CPU usage is about 50% still (only one core used). I have not timed much difference in compilation times (it's 24 modules).

Bye,
bearophile

On Wed, 01 Apr 2009 17:03:01 +0800, davidl <davidl@126.com> wrote:

>? Wed, 01 Apr 2009 16:43:57 +0800?Max Samukha <samukha@voliacable.com.removethis> ??:
>
>> On Tue, 31 Mar 2009 22:21:59 -0700, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> The large volume of bug fixes is because a lot of people contributed patches. Thanks!
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.042.zip
>>>
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.027.zip
>>
>> Great! Does it mean opDot is deprecated?
>
>why not make opDot some compile time stuff?
>
>class V
>{
>     opDot(char[] method, ...)
>     {
>         // runtime lib to figure what the method is, and then call it with
>vararg!
>     }
>}
>
>this can be particular useful for COM
>
>consider:
>
>UnknownComponent.itsparticularMethod(34,"adf"); <-- bind every com
>component is troublesome and waste time.
>The runtime can use typelib info to give us something useful
>
>Also this can help DDL to be further more useful.
>
>I don't need to bind my plugin.
>I just directly call myplugin.mymethod("asdf");
>The opdot will eventually resolve the mymethod in the plugin, then call it!
>I will really enjoy to see this happen.

The name is known at compile time, so it probably should be

opDot(string member)(...)
{
}

or even an arbitrary template named opDot that the compiler would try to instantiate with the name as first parameter, for example:

c.foo!(whatever)(v);

would be rewritten as

c.opDot!("foo", whatever)(v);

bearophile wrote:
> I have tried on Windows, on a 2-core CPU and the CPU usage is about 50%
> still (only one core used).

Well, I that's a pure reader thread running in the bg it wouldn't take any
cpu time. That's because it's basically just waiting for data transfers from the disk to put them in a queue for the compiler thread.

Walter Bright wrote:
> The large volume of bug fixes is because a lot of people contributed patches. Thanks!
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.042.zip
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.027.zip

...because the file dmd/linux/lib/libphobos2.a is empty.

-Lars

0ffh wrote:
> bearophile wrote:
>> I have tried on Windows, on a 2-core CPU and the CPU usage is about 50%
>> still (only one core used).
> 
> Well, I that's a pure reader thread running in the bg it wouldn't take any
> cpu time. That's because it's basically just waiting for data transfers from the disk to put them in a queue for the compiler thread.

Sorry for self-reply. I wonder if the reader also does tokenisation?
I suppose it could... but that would probably be quite fast, as well.