• Benji Smith (22/22) Oct 12 2008 I was just looking through bearophile's library (which is based on
• John Reimer (25/57) Oct 12 2008 The first step is an incredibly important step in the right direction fo...
• Benji Smith (4/7) Oct 12 2008 Oh, don't get me wrong. I think it's a fantastic first step. I was just
• Walter Bright (2/9) Oct 12 2008 Step one is gonna be a doozy!
• Benji Smith (4/14) Oct 12 2008 And I'm sure I speak for us all when I say we *REALLY* appreciate it.
• Don (39/68) Oct 13 2008 That could have some difficult aspects, but here's an uncomplicated
• Moritz Warning (13/36) Oct 13 2008 I agree that lot's of stuff is going to break
• Moritz Warning (16/27) Oct 13 2008 The near future is that Tango and Phobos will live next to each other
• Don (8/40) Oct 13 2008 When I look at the team for Phobos and Tango, I actually don't see that
• Moritz Warning (5/48) Oct 13 2008 Right, this diminishes friction.
• Benji Smith (13/28) Oct 13 2008 I've seen this in a few other places as well.
• Bruno Medeiros (8/65) Oct 16 2008 I don't get it. Why is it that "For (1) to work, the modules invoved
• Sean Kelly (7/68) Oct 16 2008 I believe Tango aims to continue being separately distributable from
• Don (2/72) Oct 17 2008 That's option (3).
• Bruno Medeiros (8/81) Oct 17 2008 But will it be distributed as a normal library intended to be run on a
• Sean Kelly (6/18) Oct 17 2008 Since Phobos will only use druntime with D 2.0, the current Tango
• Lars Ivar Igesund (8/87) Oct 18 2008 Although that may be a reason, the real reason is to make it a onestop
• Paul D. Anderson (2/18) Oct 13 2008
• Sean Kelly (4/14) Oct 13 2008 Until D 2.0 is finalized I think it's allowable for code to break
• Benji Smith (2/12) Oct 13 2008 Noooooooooooooooo!!!!
• John Reimer (7/21) Oct 13 2008 I think that just "ups" the complexity. You may have just made a whole ...

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

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

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

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!

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

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.

---


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.

Moritz Warning <moritzwarning web.de> writes:

On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:

[..]

 
 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.

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.

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.

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.


 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.

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.

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

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

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

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

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

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

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

Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:

Benji Smith Wrote:

 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




If these changes (and others discussed here lately) are going to break a lot of
code, is it time to move to 3.0?
 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

Sean Kelly <sean invisibleduck.org> writes:

Paul D. Anderson wrote:
 Benji Smith Wrote:
 
 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




 
 If these changes (and others discussed here lately) are going to break a lot
of code, is it time to move to 3.0?

Until D 2.0 is finalized I think it's allowable for code to break 
between compiler releases.


Sean

Benji Smith <dlanguage benjismith.net> writes:

Paul D. Anderson wrote:
 Benji Smith Wrote:
 
 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




 
 If these changes (and others discussed here lately) are going to break a lot
of code, is it time to move to 3.0?

Noooooooooooooooo!!!!

John Reimer <terminal.node gmail.com> writes:

Hello Paul,

 Benji Smith Wrote:
 
 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
 




 If these changes (and others discussed here lately) are going to break
 a lot of code, is it time to move to 3.0?


I think that just "ups" the complexity.  You may have just made a whole bunch 
of people faint with that suggestion. :-D

But I'm assuming you are suggesting that "3.0" respresent the merge of Phobos 
and Tango?  If that's the case, I don't think there need be an incremental 
version value to represent the change.

-JJR