www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos/Tango Unification Plans

reply Benji Smith <dlanguage benjismith.net> writes:
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
Oct 12 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Benji,

 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
 

The first step is an incredibly important step in the right direction for now (the runtime); I'm excited to see this happening. Many thanks to Sean, Walter, Andrei, and others for allowing this to go forward. I'm guessing it might not be best to push for too much more as that solution is being worked out. ;-) Eventually, similar to other suggestions here, I was hoping that Tango could be viewed as a group of addon libraries (tango.net, tango.io, tango.util, etc), selectively available to dmd users to use at whim and easily packaged with the std compiler as an addon subdirectory (since the runtime is shared). In many respects that is exactly the current function of the Tango user packages except that these are based on the Tango runtime/core. This is pretty much how Tangobos gets along too. Of course, this may involve a minimal amount of merging of some shared concepts in Phobos/Tango at the core level, like you suggest; therefore, perhaps waaay in the future, this is what will have to be worked out (well... that and the need for Tango to move to D 2.0 and differences in licensing?). But beyond that, it's not so simple as the above, I imagine, because there is the management, interpersonal, and community factors involved at the higher level that are invariably much more complicated than just merging and packaging of code. Yep, probably best just to be content with the druntime for now... that's a big move in itself ... and a great one. If we demand too much of these guys, they are gonna balk. :-D -JJR
Oct 12 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
John Reimer wrote:
 Yep, probably best just to be content with the druntime for now... 
 that's a big move in itself ... and a great one.  If we demand too much 
 of these guys, they are gonna balk. :-D

Oh, don't get me wrong. I think it's a fantastic first step. I was just wondering whether there's a "step two" on the drawing board yet. --benji
Oct 12 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Benji Smith wrote:
 John Reimer wrote:
 Yep, probably best just to be content with the druntime for now... 
 that's a big move in itself ... and a great one.  If we demand too 
 much of these guys, they are gonna balk. :-D

Oh, don't get me wrong. I think it's a fantastic first step. I was just wondering whether there's a "step two" on the drawing board yet.

Step one is gonna be a doozy!
Oct 12 2008
parent Benji Smith <dlanguage benjismith.net> writes:
Walter Bright wrote:
 Benji Smith wrote:
 John Reimer wrote:
 Yep, probably best just to be content with the druntime for now... 
 that's a big move in itself ... and a great one.  If we demand too 
 much of these guys, they are gonna balk. :-D

Oh, don't get me wrong. I think it's a fantastic first step. I was just wondering whether there's a "step two" on the drawing board yet.

Step one is gonna be a doozy!

And I'm sure I speak for us all when I say we *REALLY* appreciate it. Being able to use both libraries will be a huge win. --benji
Oct 12 2008
prev sibling parent reply Don <nospam nospam.com.au> writes:
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. --- Suggestion #1 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. --- There are many other alternatives, perhaps someone will suggest a better or more acceptable alternative. I don't care, as long as I can stop having to copy & paste all my code. Yes, lots of stuff is going to break. But I think we have to accept that. The potential gains from healing this massive schism in D are enormous.
Oct 13 2008
next sibling parent reply Moritz Warning <moritzwarning web.de> writes:
On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:

[..]
 Suggestion #1
 
 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.
 
 ---
 
 There are many other alternatives, perhaps someone will suggest a better
 or more acceptable alternative. I don't care, as long as I can stop
 having to copy & paste all my code.
 
 Yes, lots of stuff is going to break. But I think we have to accept
 that. The potential gains from healing this massive schism in D are
 enormous.

I agree that lot's of stuff is going to break and that the benefits are big. If a merge is ever going to happen (and I hope it does) it has do be done today rather than tomorrow. Here is a three step plan: - plan the basic design concept of a new std. namespace. - rename the current std. to phobos. - continue to populate std from Phobos and Tango. The main point of debate would be the structure of the new std namespace. It's hard to combine simplicity and small size have to be combined with the feature richness and speed of Tango.
Oct 13 2008
parent Don <nospam nospam.com.au> writes:
Moritz Warning wrote:
 On Mon, 13 Oct 2008 09:56:06 +0000, Moritz Warning wrote:
 
 On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:

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


The near future is that Tango and Phobos will live next to each other because they are about to get a a common runtime. Phobos may become a library for starting with D and people will switch to Tango further or later. Similar to the way it is already. People who (have to?) care about the Phobos license (Public Domain) vs. Tango license (BSD style/Public Domain mix) will probably stay with Phobos. Tango already shares quite some code with Phobos. So it might be not that unlikely that Tango and Phobos would be bundled along with a compiler. Phobos would then be able to redirect to Tango for shared code.

 
 Maybe Phobos will be dropped and Walter&staff become part of the Tango 
 team. But that would introduces a bunch of human related problems.

When I look at the team for Phobos and Tango, I actually don't see that many areas where they are in direct competition. Andrei and Bartosz seem much more interested in algorithms and stuff close to the runtime, whereas Tango has a lot of contributers with a much stronger application focus, and a huge body of code that began in Mango. It would be a monumental waste of time for Andrei to implement a HttpClient code, for example.
Oct 13 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Mon, 13 Oct 2008 09:56:06 +0000, Moritz Warning wrote:

 On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:
 
 [..]
 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.


The near future is that Tango and Phobos will live next to each other because they are about to get a a common runtime. Phobos may become a library for starting with D and people will switch to Tango further or later. Similar to the way it is already. People who (have to?) care about the Phobos license (Public Domain) vs. Tango license (BSD style/Public Domain mix) will probably stay with Phobos. Tango already shares quite some code with Phobos. So it might be not that unlikely that Tango and Phobos would be bundled along with a compiler. Phobos would then be able to redirect to Tango for shared code. Maybe Phobos will be dropped and Walter&staff become part of the Tango team. But that would introduces a bunch of human related problems. Either way, things are about to get a lot better from the user perspective Time will tell.
Oct 13 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Mon, 13 Oct 2008 15:12:17 +0200, Don wrote:

 Moritz Warning wrote:
 On Mon, 13 Oct 2008 09:56:06 +0000, Moritz Warning wrote:
 
 On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:

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


because they are about to get a a common runtime. Phobos may become a library for starting with D and people will switch to Tango further or later. Similar to the way it is already. People who (have to?) care about the Phobos license (Public Domain) vs. Tango license (BSD style/Public Domain mix) will probably stay with Phobos. Tango already shares quite some code with Phobos. So it might be not that unlikely that Tango and Phobos would be bundled along with a compiler. Phobos would then be able to redirect to Tango for shared code.

 Maybe Phobos will be dropped and Walter&staff become part of the Tango
 team. But that would introduces a bunch of human related problems.

When I look at the team for Phobos and Tango, I actually don't see that many areas where they are in direct competition. Andrei and Bartosz seem much more interested in algorithms and stuff close to the runtime, whereas Tango has a lot of contributers with a much stronger application focus, and a huge body of code that began in Mango. It would be a monumental waste of time for Andrei to implement a HttpClient code, for example.

Right, this diminishes friction. Let's see what will happen. I think things need to go step by step, without thinking about a master plan.
Oct 13 2008
prev sibling next sibling parent Benji Smith <dlanguage benjismith.net> writes:
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
Oct 13 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Oct 16 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
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
Oct 16 2008
next sibling parent Don <nospam nospam.com.au> writes:
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).
Oct 17 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Oct 17 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
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
Oct 17 2008
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Oct 18 2008