Lars Ivar Igesund Wrote:

> Based on historical evidence, this doesn't sound like a particularly good idea. The current situation ensued for a reason.

* sigh *

On Fri, 15 Aug 2008 14:41:20 -0700, Walter Bright wrote:

> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Steven Schveighoffer wrote:
>>>> As far as threads, I agree.  One must be chosen.
>>>
>>> The threading issue is more problematic. D 2.0 is doing a ground up rethink on how to approach threading, and it's hard to imagine that not impacting the threading part of the library.
>> 
>> So is classic threading going to be thrown out entirely?  If so then I guess it eliminates the problem of exposing a Thread class.
> 
> I don't know. Bartosz is working on it. He understands the issues far better than I do. What I do believe is that handling concurrency well will be a breakthrough feature for D.

Sounds like a nifty feature, but please keep in mind that users like
to have control about everything if they want to.
Otherwise D is becoming quite restricted.

Like the garbage collector (GC) can be turned off and manual memory management can be used, automatic threading in D should give similar control.


But the current gc handling is a bit inflexible. Turning off the gc still leaves the gc code in the binary without additional work. But that's another story. :)

superdan wrote:
> Christopher Wright Wrote:
>> I don't believe that you would do so. But by requiring Tango to be placed in the public domain, you're allowing everyone else to do so.
> 
> he didn't require tango to be placed in the public domain. he asked for the same deal he gave to tango. actually he didn't even ask. he just mentioned what it takes for him to look at the code.

He wanted permission to license Tango as Phobos is licensed. Phobos was licensed in a BSD-like license, but Walter has been changing it to public domain.

Walter did explicitly say that he wanted to relicense Tango as public domain, I believe.

>> The BSD license is explicit permission. Or do you intend to redistribute Tango code without proper attribution?
> 
> no. he just wants to escape the tyranny of slander. he's just worried that a tyrangot will _claim_ walt redistributed tango code without proper attribution.

The accusation was ridiculous. As such, Walter would trivially fulfill the requirements of the BSD license.

On Fri, Aug 15, 2008 at 09:25:50PM -0400, Christopher Wright wrote:
> The accusation was ridiculous. As such, Walter would trivially fulfill the requirements of the BSD license.

What about the users of the language? Suppose the standard library was BSD licensed and I wrote a D program. Am I now required to add their copyright notice with my program whenever I distribute it?

That's a pain in the ass. I like to distribute my programs in binary form just by giving a link to the .exe saying 'here it is, do whatever you want with it. Have fun!' With the BSD license restrictions, I couldn't do that.

The license in the phobos files is perfect for me. That's how a standard library should be licensed - infinitely convenient.

-- 
Adam D. Ruppe
http://arsdnet.net

We offer World of Warcraft Power Leveling and World of Warcraft powerleveling,Age of Conan Powerleveling and Lord fo Ring Online Powerleveling.WoW Powerleveling service and cheap wow Powerleveling,World of Warcraft Power leveling sale for you. AOC Power leveling,Cheap AOC Powerleveling .All service is faster,safer,and cheaper.We Please remember,we are your online game helper.
<a href=http://www.pvpsale.com>WOW Powerleveling</a>
<a href=http://www.pvpsale.com/powerleveling.asp>WOW Power leveling</a>
<a href=http://www.pvpsale.com/World-of-Warcraft-US-Powerleveling.asp>World of Warcraft Powerleveling</a>
<a href=http://www.pvpsale.com/World-of-Warcraft-EU-Powerleveling.asp>World of Warcraft power leveling</a>
<a href=http://www.pvpsale.com/World-of-Warcraft-US-Gold.asp>wow gold</a>
<a href=http://www.pvpsale.com/World-of-Warcraft-EU-Gold.asp>wow gold</a>
<a href=http://www.pvpsale.com/Age-of-Conan-Powerleveling.html>Age of Conan Powerleveling</a>
<a href=http://www.pvpsale.com/Age-of-Conan-Power-leveling.html>Age of Conan Power leveling</a>
<a href=http://www.pvpsale.com/AOC-Powerleveling.asp>AOC Powerleveling</a>
<a href=http://www.pvpsale.com/AOC-Power-leveling.asp>AOC Power leveling</a>
<a href=http://www.pvpsale.com/AOC-Powerleveling.html>AOC Powerleveling</a>
<a href=http://www.pvpsale.com/AOC-Power-leveling.html>AOC Power leveling</a>
<a href=http://www.pvpsale.com/Final-Fantasy-XI-Gil.asp>Final Fantasy XI Gil</a>
<a href=http://www.pvpsale.com/Final-Fantasy-XI.asp>FFXI Gil</a>
<a href=http://www.pvpsale.com/Florensia-Gold.asp>Florensia Gold</a>
<a href=http://www.pvpsale.com/Dekaron-EU.asp>Dekaron Dil</a>
<a href=http://www.pvpsale.com/Requiem-Online.asp>Requiem Gold</a>
<a href=http://www.pvpsale.com/Rohan-Online.asp>Rohan Gold</a>
<a href=http://www.pvpsale.com/Warhammer-Online-Powerleveling.asp>Warhammer Powerleveling</a>
<a href=http://www.pvpsale.com/Warhammer-Online.asp>Warhammer Online</a>

Lutger wrote:

> Lars Ivar Igesund wrote:
> 
>> Steven Schveighoffer wrote:
>> 
>>> This is my view (might not work, but I think it could).  For purposes of
>>> simplicity, I'll assume Walter currently develops the Phobos runtime
>>> (not that he doesn't, but I'm really not sure :).
>>> 
>>> Maintenance of the merged runtime would become Walter's responsibility,
>>> with your help if necessary (ideas and help understanding, and
>>> enhancements if
>>> you wish).  Any changes desired for the runtime would go through Phobos
>>> (and
>>> Walter).  The Tango lib would use the now tango-fied Phobos runtime,
>>> with alias imports for existing code (e.g. tango.core.Thread would
>>> either publicly import std.thread or would privately import it, and
>>> alias the Thread class).
>> 
>> Based on historical evidence, this doesn't sound like a particularly good idea. The current situation ensued for a reason.
>> 
>> Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.
> 
> How does it ignore it? It sounds rather like the opposite to me: the very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.

Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.

> 
>> If there should be a common-common (not only "just" compatible) runtime, it shouldn't be controlled by one compiler vendor. Note that the Tango runtime consists of 3 parts, where only one is compiler specific. That particular part should probably be controlled/reviewed by the compiler vendor, the rest (GC, threading, other things) should be independent.
> 
> I'll admit my understanding is limited, but I'd guess that will lead to even further fragmentation and non-portability.

The compiler part would have to conform to the necessary interfaces, of course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> Lutger wrote:
> 
>> Lars Ivar Igesund wrote:
>>
>>> Steven Schveighoffer wrote:
>>> 
>>>> This is my view (might not work, but I think it could).  For purposes of
>>>> simplicity, I'll assume Walter currently develops the Phobos runtime
>>>> (not that he doesn't, but I'm really not sure :).
>>>>
>>>> Maintenance of the merged runtime would become Walter's responsibility,
>>>> with your help if necessary (ideas and help understanding, and
>>>> enhancements if
>>>> you wish).  Any changes desired for the runtime would go through Phobos
>>>> (and
>>>> Walter).  The Tango lib would use the now tango-fied Phobos runtime,
>>>> with alias imports for existing code (e.g. tango.core.Thread would
>>>> either publicly import std.thread or would privately import it, and
>>>> alias the Thread class).
>>> Based on historical evidence, this doesn't sound like a particularly good idea. The current situation ensued for a reason.
>>>
>>> Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.
>> How does it ignore it? It sounds rather like the opposite to me: the very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.
> 
> Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
> 
>> 
>>> If there should be a common-common (not only "just" compatible) runtime, it shouldn't be controlled by one compiler vendor. Note that the Tango runtime consists of 3 parts, where only one is compiler specific. That particular part should probably be controlled/reviewed by the compiler vendor, the rest (GC, threading, other things) should be independent.
>> I'll admit my understanding is limited, but I'd guess that will lead to even further fragmentation and non-portability.
> 
> The compiler part would have to conform to the necessary interfaces, of course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil.
> 

I don't understand your point. are you suggesting that things like the
GC will be independent from the compiler?
It seems to me that the model suggested by Sean is the way to go:
ie:

my code
----------
standard library user code and standardized APIs to the runtime (threading, etc
---------------------------------
compiler + runtime A  | compiler + runtime B | .....


if a user isn't satisfied by runtime/compiler A he should just switch
vendors.
All the user facing APIs are standardized in the stdlib so all is needed
is to recompile..

Lars Ivar Igesund wrote:

> Lutger wrote:
...
>> How does it ignore it? It sounds rather like the opposite to me: the very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.
> 
> Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.

Ok I think I understand and agree that some room for this potential would be good, of course. What I'm worried about is that D libraries will depend on specific api (not only implementation) of the runtime, which could lead to a mess when we'll have more and more of such implementations.

Simply put, I'm afraid that in the future to make a cross-platform code we'll have to do something equivalent to a C++ header file consisting of dozens of bizarre #ifdef ... #elif etc. logic. Or worse, need a massive porting effort or wrapping libraries a la tangobos if you need a D library developed for a different compiler.

Perhaps more interfaces could be standardized? I don't know. I'd hate to see a thread in some years called 'phobos vs tango vs dil vs dang vs llvmdc vs etc.' ;) </hyperbole>

Lutger wrote:

> Lars Ivar Igesund wrote:
> 
>> Lutger wrote:
> ...
>>> How does it ignore it? It sounds rather like the opposite to me: the very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.
>> 
>> Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
> 
> Ok I think I understand and agree that some room for this potential would be good, of course. What I'm worried about is that D libraries will depend on specific api (not only implementation) of the runtime, which could lead to a mess when we'll have more and more of such implementations.
> 
> Simply put, I'm afraid that in the future to make a cross-platform code we'll have to do something equivalent to a C++ header file consisting of dozens of bizarre #ifdef ... #elif etc. logic. Or worse, need a massive porting effort or wrapping libraries a la tangobos if you need a D library developed for a different compiler.

A way to ensure that there are common, good and well defined interfaces is what I try to hint at. I don't think all of those can be properly achieved by letting one vendor decide. I also think that having a common place to have the compiler independent implementation would help this goal, ie that compiler vendors don't need to write this themselves.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Yigal Chripun wrote:

> Lars Ivar Igesund wrote:
>> Lutger wrote:
>> 
>>> Lars Ivar Igesund wrote:
>>>
>>>> Steven Schveighoffer wrote:
>>>> 
>>>>> This is my view (might not work, but I think it could).  For purposes
>>>>> of simplicity, I'll assume Walter currently develops the Phobos
>>>>> runtime (not that he doesn't, but I'm really not sure :).
>>>>>
>>>>> Maintenance of the merged runtime would become Walter's
>>>>> responsibility, with your help if necessary (ideas and help
>>>>> understanding, and enhancements if
>>>>> you wish).  Any changes desired for the runtime would go through
>>>>> Phobos (and
>>>>> Walter).  The Tango lib would use the now tango-fied Phobos runtime,
>>>>> with alias imports for existing code (e.g. tango.core.Thread would
>>>>> either publicly import std.thread or would privately import it, and
>>>>> alias the Thread class).
>>>> Based on historical evidence, this doesn't sound like a particularly good idea. The current situation ensued for a reason.
>>>>
>>>> Also, I find that this discussion quite completely ignores the fact that DMD is not the only D compiler anymore, and Walter is not the only one with a vested interest in the functionality. In fact it looks like quite many of the Tango conference attendants wants to discuss the runtime.
>>> How does it ignore it? It sounds rather like the opposite to me: the very existence of multiple runtimes and the vested interest in those runtimes (Tango's primarily) are the key reason for unification.
>> 
>> Unification, yes. You misunderstood my point, which is that the runtime implementation (not the compiler specific portion and direct language support) should, IMO, be independent. As long as Walter/DigitalMars is the developer of the language itself, it will be natural that eventual new features that the language requires from the runtime, will be bootstrapped by code from Walter, but I think Sean's work on the runtime in Tango shows that such initial implementation can have large potential for improvements.
>> 
>>> 
>>>> If there should be a common-common (not only "just" compatible) runtime, it shouldn't be controlled by one compiler vendor. Note that the Tango runtime consists of 3 parts, where only one is compiler specific. That particular part should probably be controlled/reviewed by the compiler vendor, the rest (GC, threading, other things) should be independent.
>>> I'll admit my understanding is limited, but I'd guess that will lead to even further fragmentation and non-portability.
>> 
>> The compiler part would have to conform to the necessary interfaces, of course, but at some level the implementation details needs to be, and not all can be kept in the compiler itself, thus it must be somewhere in the runtime. I don't see this as a problem, just a necessary evil.
>> 
> 
> I don't understand your point. are you suggesting that things like the
> GC will be independent from the compiler?
> It seems to me that the model suggested by Sean is the way to go:
> ie:
> 
> my code
> ----------
> standard library user code and standardized APIs to the runtime (threading, etc
> ---------------------------------
> compiler + runtime A  | compiler + runtime B | .....
> 
> 
> if a user isn't satisfied by runtime/compiler A he should just switch
> vendors.
> All the user facing APIs are standardized in the stdlib so all is needed
> is to recompile..

A common interface (API and ABI) would make this easier, but I just tend to think that a common implementation as long as possible would be even better - unification of efforts etc.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango