Don wrote:
> That could have some difficult aspects, but here's an uncomplicated second step: The math libraries for Tango and Phobos aren't merely compatible, they are THE SAME! They are a cut-and-paste of each other, with a couple of trivial name changes.

I've seen this in a few other places as well.

I'm using DWin in my project, to get access to the windows registry. Within that library, there's a substantial copy/paste of code from the Tango project (core package, UserGdi, Types, etc). Or maybe Tango included code that was originally in DWin. I dunno the history of the code, but I do know that when I compile my code, I'm getting verbatim copies of the same stuff (except in cases where DWin has fixed a bug that didn't get propagated to Tango, or vice versa).

My guess is that DWin wants to stay compatible with Phobos, which is why it doesn't just directly depend on the Tango libs.

> The best situation I can imagine would be if Phobos started using the phobos namespace for stuff which is not common with Tango, and std was used for the common stuff.
> 
> My preferred option would be to remove tango.math.Math (stupid name anyway), combine it with tango.math.IEEE (another doubtful name) and rename it as std.math.
> The more advanced math functions would remain in Tango, since I like the two-level heirachy which Tango provides. The advanced functions which are currently duplicated (eg, std.math.tgamma) would be removed from Phobos.

I think that's a great plan. Thanks!

--benji

Don wrote:
> Benji Smith wrote:
>> I was just looking through bearophile's library (which is based on Phobos) and thinking about how it's too bad that I can't use it because my code is all based on Tango.
>>
>> I know there are plans currently in the works to implement a compatible runtime layer, via Sean's druntime project. And it'll be a breath of fresh air to get rid of the basic incompatibilities in the two runtimes.
>>
>> But if that's all that happens, it'll still leave an undesirable situation, since all the other userland stuff will be incompatible.
>>
>> Eventually, any significantly complex project is likely to have some dependent libraries built on top of both Phobos and Tango. At the very least, string-processing routines from both libraries will get compiled into the final executable.
>>
>> Not only will that result in duplication of functionality (and code bloat), but it'll also mean a bunch of bit-twiddling whenever sending a Tango type into a Phobos-dependent library function (and vice versa).
>>
>> Are there any plans in the works to mitigate that problem? Like, perhaps, negotiating a common API so that at least the names and argument types are the same in both libraries?
>>
>> I'm sure the two libraries will always include different subsets of functionality, but whenever they implement the same basic features, it'd be great if they used a compatible API.
>>
>> --benji
> 
> 
> That could have some difficult aspects, but here's an uncomplicated second step: The math libraries for Tango and Phobos aren't merely compatible, they are THE SAME! They are a cut-and-paste of each other, with a couple of trivial name changes.
> There are no licensing issues or personality clashes to worry about -- I've written most of both of them. They have no dependencies on anything else in either Phobos or Tango. I have write access to repositories of both Phobos and Tango.
> YET -- there are two bodies of code! This is absolutely ridiculous, and it's driving me mad.
> 
> How can we turn this into ONE body of code?
> It will only be possible if there is a namespace which is present in both Tango and Phobos. There are exactly three ways in which this can be done:
> Either
> (1) Tango needs to include part of the std namespace,
> (2) Phobos needs to include part of the tango namespace, or
> (3) Both need to start including a new namespace which is common to both.
> 
> Of these options, I think (2) is the least natural. For (1) to work, the modules invoved would need to be clearly designated as common.
> 
> 

I don't get it. Why is it that "For (1) to work, the modules invoved would need to be clearly designated as common." ? Since Tango will become compatible with Phobos (same runtime), can't Tango just use/depend-on some of Phobos functionality?


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Don wrote:
>> Benji Smith wrote:
>>> I was just looking through bearophile's library (which is based on Phobos) and thinking about how it's too bad that I can't use it because my code is all based on Tango.
>>>
>>> I know there are plans currently in the works to implement a compatible runtime layer, via Sean's druntime project. And it'll be a breath of fresh air to get rid of the basic incompatibilities in the two runtimes.
>>>
>>> But if that's all that happens, it'll still leave an undesirable situation, since all the other userland stuff will be incompatible.
>>>
>>> Eventually, any significantly complex project is likely to have some dependent libraries built on top of both Phobos and Tango. At the very least, string-processing routines from both libraries will get compiled into the final executable.
>>>
>>> Not only will that result in duplication of functionality (and code bloat), but it'll also mean a bunch of bit-twiddling whenever sending a Tango type into a Phobos-dependent library function (and vice versa).
>>>
>>> Are there any plans in the works to mitigate that problem? Like, perhaps, negotiating a common API so that at least the names and argument types are the same in both libraries?
>>>
>>> I'm sure the two libraries will always include different subsets of functionality, but whenever they implement the same basic features, it'd be great if they used a compatible API.
>>>
>>> --benji
>>
>>
>> That could have some difficult aspects, but here's an uncomplicated second step: The math libraries for Tango and Phobos aren't merely compatible, they are THE SAME! They are a cut-and-paste of each other, with a couple of trivial name changes.
>> There are no licensing issues or personality clashes to worry about -- I've written most of both of them. They have no dependencies on anything else in either Phobos or Tango. I have write access to repositories of both Phobos and Tango.
>> YET -- there are two bodies of code! This is absolutely ridiculous, and it's driving me mad.
>>
>> How can we turn this into ONE body of code?
>> It will only be possible if there is a namespace which is present in both Tango and Phobos. There are exactly three ways in which this can be done:
>> Either
>> (1) Tango needs to include part of the std namespace,
>> (2) Phobos needs to include part of the tango namespace, or
>> (3) Both need to start including a new namespace which is common to both.
>>
>> Of these options, I think (2) is the least natural. For (1) to work, the modules invoved would need to be clearly designated as common.
> 
> I don't get it. Why is it that "For (1) to work, the modules invoved would need to be clearly designated as common." ? Since Tango will become compatible with Phobos (same runtime), can't Tango just use/depend-on some of Phobos functionality?

I believe Tango aims to continue being separately distributable from Phobos, so this isn't likely to happen.  Another option would be for the math package to live in a separate project that's bundled with both libraries, though I don't know how either team feels about the logistics of such an arrangement.


Sean

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Don wrote:
>>> Benji Smith wrote:
>>>> I was just looking through bearophile's library (which is based on Phobos) and thinking about how it's too bad that I can't use it because my code is all based on Tango.
>>>>
>>>> I know there are plans currently in the works to implement a compatible runtime layer, via Sean's druntime project. And it'll be a breath of fresh air to get rid of the basic incompatibilities in the two runtimes.
>>>>
>>>> But if that's all that happens, it'll still leave an undesirable situation, since all the other userland stuff will be incompatible.
>>>>
>>>> Eventually, any significantly complex project is likely to have some dependent libraries built on top of both Phobos and Tango. At the very least, string-processing routines from both libraries will get compiled into the final executable.
>>>>
>>>> Not only will that result in duplication of functionality (and code bloat), but it'll also mean a bunch of bit-twiddling whenever sending a Tango type into a Phobos-dependent library function (and vice versa).
>>>>
>>>> Are there any plans in the works to mitigate that problem? Like, perhaps, negotiating a common API so that at least the names and argument types are the same in both libraries?
>>>>
>>>> I'm sure the two libraries will always include different subsets of functionality, but whenever they implement the same basic features, it'd be great if they used a compatible API.
>>>>
>>>> --benji
>>>
>>>
>>> That could have some difficult aspects, but here's an uncomplicated second step: The math libraries for Tango and Phobos aren't merely compatible, they are THE SAME! They are a cut-and-paste of each other, with a couple of trivial name changes.
>>> There are no licensing issues or personality clashes to worry about -- I've written most of both of them. They have no dependencies on anything else in either Phobos or Tango. I have write access to repositories of both Phobos and Tango.
>>> YET -- there are two bodies of code! This is absolutely ridiculous, and it's driving me mad.
>>>
>>> How can we turn this into ONE body of code?
>>> It will only be possible if there is a namespace which is present in both Tango and Phobos. There are exactly three ways in which this can be done:
>>> Either
>>> (1) Tango needs to include part of the std namespace,
>>> (2) Phobos needs to include part of the tango namespace, or
>>> (3) Both need to start including a new namespace which is common to both.
>>>
>>> Of these options, I think (2) is the least natural. For (1) to work, the modules invoved would need to be clearly designated as common.
>>
>> I don't get it. Why is it that "For (1) to work, the modules invoved would need to be clearly designated as common." ? Since Tango will become compatible with Phobos (same runtime), can't Tango just use/depend-on some of Phobos functionality?
> 
> I believe Tango aims to continue being separately distributable from Phobos, so this isn't likely to happen.  Another option would be for the math package to live in a separate project that's bundled with both libraries, though I don't know how either team feels about the logistics of such an arrangement.

That's option (3).

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Don wrote:
>>> Benji Smith wrote:
>>>> I was just looking through bearophile's library (which is based on Phobos) and thinking about how it's too bad that I can't use it because my code is all based on Tango.
>>>>
>>>> I know there are plans currently in the works to implement a compatible runtime layer, via Sean's druntime project. And it'll be a breath of fresh air to get rid of the basic incompatibilities in the two runtimes.
>>>>
>>>> But if that's all that happens, it'll still leave an undesirable situation, since all the other userland stuff will be incompatible.
>>>>
>>>> Eventually, any significantly complex project is likely to have some dependent libraries built on top of both Phobos and Tango. At the very least, string-processing routines from both libraries will get compiled into the final executable.
>>>>
>>>> Not only will that result in duplication of functionality (and code bloat), but it'll also mean a bunch of bit-twiddling whenever sending a Tango type into a Phobos-dependent library function (and vice versa).
>>>>
>>>> Are there any plans in the works to mitigate that problem? Like, perhaps, negotiating a common API so that at least the names and argument types are the same in both libraries?
>>>>
>>>> I'm sure the two libraries will always include different subsets of functionality, but whenever they implement the same basic features, it'd be great if they used a compatible API.
>>>>
>>>> --benji
>>>
>>>
>>> That could have some difficult aspects, but here's an uncomplicated second step: The math libraries for Tango and Phobos aren't merely compatible, they are THE SAME! They are a cut-and-paste of each other, with a couple of trivial name changes.
>>> There are no licensing issues or personality clashes to worry about -- I've written most of both of them. They have no dependencies on anything else in either Phobos or Tango. I have write access to repositories of both Phobos and Tango.
>>> YET -- there are two bodies of code! This is absolutely ridiculous, and it's driving me mad.
>>>
>>> How can we turn this into ONE body of code?
>>> It will only be possible if there is a namespace which is present in both Tango and Phobos. There are exactly three ways in which this can be done:
>>> Either
>>> (1) Tango needs to include part of the std namespace,
>>> (2) Phobos needs to include part of the tango namespace, or
>>> (3) Both need to start including a new namespace which is common to both.
>>>
>>> Of these options, I think (2) is the least natural. For (1) to work, the modules invoved would need to be clearly designated as common.
>>
>> I don't get it. Why is it that "For (1) to work, the modules invoved would need to be clearly designated as common." ? Since Tango will become compatible with Phobos (same runtime), can't Tango just use/depend-on some of Phobos functionality?
> 
> I believe Tango aims to continue being separately distributable from Phobos, so this isn't likely to happen.  Another option would be for the math package to live in a separate project that's bundled with both libraries, though I don't know how either team feels about the logistics of such an arrangement.
> 
> 
> Sean

But will it be distributed as a normal library intended to be run on a DMD install, or will it still be distributed as a modified DMD installation, as it is now? If so, why? I thought you had to modify the DMD installation only because the D runtime was not compatible.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Sean Kelly wrote:
>>
>> I believe Tango aims to continue being separately distributable from Phobos, so this isn't likely to happen.  Another option would be for the math package to live in a separate project that's bundled with both libraries, though I don't know how either team feels about the logistics of such an arrangement.
> 
> But will it be distributed as a normal library intended to be run on a DMD install, or will it still be distributed as a modified DMD installation, as it is now? If so, why? I thought you had to modify the DMD installation only because the D runtime was not compatible.

Since Phobos will only use druntime with D 2.0, the current Tango distribution will most likly continue to include a runtime, be it Tango's original runtime or druntime.  It will likely be up to the community exactly how Tango is packaged going forward.


Sean

Bruno Medeiros wrote:

> Sean Kelly wrote:
>> Bruno Medeiros wrote:
>>> Don wrote:
>>>> Benji Smith wrote:
>>>>> I was just looking through bearophile's library (which is based on Phobos) and thinking about how it's too bad that I can't use it because my code is all based on Tango.
>>>>>
>>>>> I know there are plans currently in the works to implement a compatible runtime layer, via Sean's druntime project. And it'll be a breath of fresh air to get rid of the basic incompatibilities in the two runtimes.
>>>>>
>>>>> But if that's all that happens, it'll still leave an undesirable situation, since all the other userland stuff will be incompatible.
>>>>>
>>>>> Eventually, any significantly complex project is likely to have some dependent libraries built on top of both Phobos and Tango. At the very least, string-processing routines from both libraries will get compiled into the final executable.
>>>>>
>>>>> Not only will that result in duplication of functionality (and code bloat), but it'll also mean a bunch of bit-twiddling whenever sending a Tango type into a Phobos-dependent library function (and vice versa).
>>>>>
>>>>> Are there any plans in the works to mitigate that problem? Like, perhaps, negotiating a common API so that at least the names and argument types are the same in both libraries?
>>>>>
>>>>> I'm sure the two libraries will always include different subsets of functionality, but whenever they implement the same basic features, it'd be great if they used a compatible API.
>>>>>
>>>>> --benji
>>>>
>>>>
>>>> That could have some difficult aspects, but here's an uncomplicated
>>>> second step: The math libraries for Tango and Phobos aren't merely
>>>> compatible, they are THE SAME! They are a cut-and-paste of each
>>>> other, with a couple of trivial name changes.
>>>> There are no licensing issues or personality clashes to worry about
>>>> -- I've written most of both of them. They have no dependencies on
>>>> anything else in either Phobos or Tango. I have write access to
>>>> repositories of both Phobos and Tango.
>>>> YET -- there are two bodies of code! This is absolutely ridiculous,
>>>> and it's driving me mad.
>>>>
>>>> How can we turn this into ONE body of code?
>>>> It will only be possible if there is a namespace which is present in
>>>> both Tango and Phobos. There are exactly three ways in which this can
>>>> be done:
>>>> Either
>>>> (1) Tango needs to include part of the std namespace,
>>>> (2) Phobos needs to include part of the tango namespace, or
>>>> (3) Both need to start including a new namespace which is common to
>>>> both.
>>>>
>>>> Of these options, I think (2) is the least natural. For (1) to work,
>>>> the modules invoved would need to be clearly designated as common.
>>>
>>> I don't get it. Why is it that "For (1) to work, the modules invoved would need to be clearly designated as common." ? Since Tango will become compatible with Phobos (same runtime), can't Tango just use/depend-on some of Phobos functionality?
>> 
>> I believe Tango aims to continue being separately distributable from Phobos, so this isn't likely to happen.  Another option would be for the math package to live in a separate project that's bundled with both libraries, though I don't know how either team feels about the logistics of such an arrangement.
>> 
>> 
>> Sean
> 
> But will it be distributed as a normal library intended to be run on a DMD install, or will it still be distributed as a modified DMD installation, as it is now? If so, why? I thought you had to modify the DMD installation only because the D runtime was not compatible.

Although that may be a reason, the real reason is to make it a onestop thing - you don't have to download two packages to get what you need.

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