www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Tango / Phobos / future dilemma

reply Spacen Jasset <spacen yahoo.co.uk> writes:
Hello,

Currently I am using phobos for my work, which suit at the moment since 
I am mainly using opengl.

Unfortunately I would like use a library that requires Tango, and there 
is yet another library that I would like to use that is coded for 
phobos. Since they both incorporate a core runtime I presume that this 
situation is impossible without akward workarounds?


Secondly, I have an uneasy feeling about the situation whereby there are 
two libraries that function independently of each other. What lies ahead 
for this state of affairs; and indeed, what is Walter's and the Tango 
team's position on it?
May 26 2008
next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 27 May 2008 00:25:18 +0100, Spacen Jasset wrote:

 Hello,
 
 Currently I am using phobos for my work, which suit at the moment since
 I am mainly using opengl.
 
 Unfortunately I would like use a library that requires Tango, and there
 is yet another library that I would like to use that is coded for
 phobos. Since they both incorporate a core runtime I presume that this
 situation is impossible without akward workarounds?
 
 
 Secondly, I have an uneasy feeling about the situation whereby there are
 two libraries that function independently of each other. What lies ahead
 for this state of affairs; and indeed, what is Walter's and the Tango
 team's position on it?

Well, actually there is tangobos which is a compatibility lay on top of Tango. www.dsource.org/projects/tangobos/ As for the future, I see a problem using Tango as currently it seems that the Tango team is not interested in working with D2. But I'm sure when it is finally released there will be more push to do so. Otherwise there isn't much from Walter as to what to do about it. I hope to see a good conclusion where there is only one library.
May 26 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Spacen Jasset" <spacen yahoo.co.uk> wrote in message 
news:g1fgst$o0r$1 digitalmars.com...
 Hello,

 Currently I am using phobos for my work, which suit at the moment since I 
 am mainly using opengl.

 Unfortunately I would like use a library that requires Tango, and there is 
 yet another library that I would like to use that is coded for phobos. 
 Since they both incorporate a core runtime I presume that this situation 
 is impossible without akward workarounds?


 Secondly, I have an uneasy feeling about the situation whereby there are 
 two libraries that function independently of each other. What lies ahead 
 for this state of affairs; and indeed, what is Walter's and the Tango 
 team's position on it?

Well at the D con last year (which was almost a year ago), Walter and the Tango team decided that the two libraries could coexist, as long as they had a common runtime, or something along those lines. After the con, Walter made a few changes to the Phobos runtime and, ... well, nothing since then. D2 has been the all-encompassing focus of Walter's efforts since about the same time. Sad, since this is _really_ an issue that needs to be addressed. No, I take that back: this should have been addressed _ages ago_.
May 26 2008
next sibling parent reply Sascha Katzner <sorry.no spam.invalid> writes:
Jarrett Billingsley wrote:
 Sad, since this is _really_ an issue that needs to be addressed.  No, I take 
 that back: this should have been addressed _ages ago_.

I agree, the current situation is VERY bad for D as a language. I see only one solution at the moment that would (IMO) be fair for everyone: ***** 1) Tango has to loose the claim to be a replacement for Phobos, instead it *has* to be an enhancement on top of Phobos (and *perhaps* merge with Phobos later, but this is a different discussion). 2) At the same time Walter should open Phobos to everyone (that includes the Tango team). ***** ... ideally this should be put in action with the first stable release of D2. I think we will never get a better chance to correct this error of the past as plain and simple like that. LLAP, Sascha
May 27 2008
next sibling parent Ty Tower <towerty msn.com.au> writes:
I came in to have a look
There was dmd ,but which version 1 or 2 to choose .Hmmm
So then there is Tango and Phobos which  to choose .Hmmm
So I want to use DWT so that sorts it a bit .

Then I have to learn DSSS. Hmmmm
and then Mercurial .Hmmmmmmm

I liked the language so I'm still here persevering and there are a few very
bright people on here and I like that too.

I think I will send "D" my Grandfather's current formula for mixing viagara and
eye drops.
It can then go take a long hard look at itself! 
May 27 2008
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
Sascha Katzner wrote:
 Jarrett Billingsley wrote:
 Sad, since this is _really_ an issue that needs to be addressed.  No, 
 I take that back: this should have been addressed _ages ago_.

I agree, the current situation is VERY bad for D as a language. I see only one solution at the moment that would (IMO) be fair for everyone: ***** 1) Tango has to loose the claim to be a replacement for Phobos, instead it *has* to be an enhancement on top of Phobos (and *perhaps* merge with Phobos later, but this is a different discussion).

Except the Phobos runtime and garbage collector are inferior to those of Tango. Plus the result would not be DRY: there'd be two IO systems, for instance. Also, Tango has changes to object.d, I believe, for things like stack traces on exceptions.
 2) At the same time Walter should open Phobos to everyone (that includes 
 the Tango team).

Given this, Phobos would adopt the Tango runtime, which would effectively make Phobos an extension of Tango. Except that it would be updated to new dmd releases sooner. That said, a few of the Tango devs do, I believe, have write access to Phobos. Still, this turns the situation from a near monopoly into a monopoly. I can't come out with a new and improved D runtime. On the other hand, most other languages do just fine with similar (per-compiler) monopolies.
May 27 2008
parent reply Sascha Katzner <sorry.no spam.invalid> writes:
Chris Wright wrote:
 Except the Phobos runtime and garbage collector are inferior to those of 
 Tango.

I think it is kind of silly to debate what parts of which library are superior, if we want to rectify this situation. Fact is that we have currently 2 incompatible D languages (if you doesn't count D 2.0), which is a big bummer for the growth of the D community. So either one of them has to go or they have to merge in some way. Since neither Walter nor the Tango team seems willing to give up, a merge is the only way. The only question is how to do that in detail.
 Plus the result would not be DRY: there'd be two IO systems, for 
 instance. Also, Tango has changes to object.d, I believe, for things 
 like stack traces on exceptions.

I see no reason why those two IO systems couldn't coexist on top of a common low level cache. Sure you have to change some parts of both libraries, but I'm confident that in the long run this could be more than worthwhile.
 Given this, Phobos would adopt the Tango runtime, which would 
 effectively make Phobos an extension of Tango. Except that it would be 
 updated to new dmd releases sooner.

It's circumstantial how you call it. The important point is that they both merge and this is only possible if both sides are willing for concessions. LLAP, Sascha
May 27 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sascha Katzner wrote:
 I see no reason why those two IO systems couldn't coexist on top of a 
 common low level cache.

(All of the statements below are AFAIK & IIRC from the newsgroup discussions on this subject) I do: Walter seems convinced that using the libc buffering is the Right Thing To Do(TM) because it allows intermixing of *printf(), putc*(), etc. with writefln & friends without explicitly syncing them. The Tango devs have a good reason to use their own, separate, buffering solution: the tests showing better performance. (And many people consider it bad style to use C-style I/O in D programs anyway, so "it's just not worth it" becomes a good argument pretty quickly here) This just doesn't allow a "common low level cache" since neither of their buffering solutions allows the use of a common buffer unless the other one switches (Phobos can't change libc while much of the Tango IO functionality depends on using the custom buffer and its good performance depends on interfacing directly to the OS[1])... In other words, it's a fundamental disagreement about how to best do I/O. [1] Also, changing the Tango I/O code to use libc instead of direct OS calls isn't very helpful since it still won't be synced to C-style I/O (there'll still be an extra buffer in front of the Tango stuff that would only send stuff to libc when full or explicitly flushed).
May 27 2008
next sibling parent Chris Wright <dhasenan gmail.com> writes:
Koroskin Denis wrote:
 C++ has both C-style stdio (fopen, fwrite, etc) and custom iostreams.
 Both of them have overlapping functionality, and no one cares.
 
 Since D can directly interface with C code and we can't throw away that,
 C-style IO _will_ present in D. And that's Ok, I don't see any problems
 here. Guys that think that it's the right way would use that, others would
 use Tango way.

In Tango, you can use printf and friends if you import tango.stdc.stdio. So even if you use tango, you don't have to do io the tango way. It's just that you have to write your own wrappers for it if you want your code to look like tango.io.Stdout and share buffers with C io.
May 27 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Koroskin Denis wrote:
 On Tue, 27 May 2008 18:49:26 +0400, Frits van Bommel
 <fvbommel remwovexcapss.nl> wrote:
 
 Sascha Katzner wrote:
 I see no reason why those two IO systems couldn't coexist on top of a
 common low level cache.

(All of the statements below are AFAIK & IIRC from the newsgroup discussions on this subject) I do: Walter seems convinced that using the libc buffering is the Right Thing To Do(TM) because it allows intermixing of *printf(), putc*(), etc. with writefln & friends without explicitly syncing them. The Tango devs have a good reason to use their own, separate, buffering solution: the tests showing better performance. (And many people consider it bad style to use C-style I/O in D programs anyway, so "it's just not worth it" becomes a good argument pretty quickly here) This just doesn't allow a "common low level cache" since neither of their buffering solutions allows the use of a common buffer unless the other one switches (Phobos can't change libc while much of the Tango IO functionality depends on using the custom buffer and its good performance depends on interfacing directly to the OS[1])... In other words, it's a fundamental disagreement about how to best do I/O. [1] Also, changing the Tango I/O code to use libc instead of direct OS calls isn't very helpful since it still won't be synced to C-style I/O (there'll still be an extra buffer in front of the Tango stuff that would only send stuff to libc when full or explicitly flushed).

C++ has both C-style stdio (fopen, fwrite, etc) and custom iostreams. Both of them have overlapping functionality, and no one cares. Since D can directly interface with C code and we can't throw away that, C-style IO _will_ present in D. And that's Ok, I don't see any problems here. Guys that think that it's the right way would use that, others would use Tango way.

C++ has duplicated functionality for many of the C constructs like IO, casting, arrays vs. stl vectors, etc.. I wouldn't say that no one cares, on the contrary, this is a source for confusion and bugs, it adds unneeded complexity which IIRC is one of the reasons for creating D in the first place. C++ already provides this awful solution with its backwards compatibility, so if you want to mix code just use C++ (I have to do this at work and it's a huge PITA). D provides only linking capability to C libraries and I'd prefer the faster Tango implementation which needs explicit syncing of IO instead of crippling the entire D language. I imagine that the needed explicit syncing can be provided as part of Tango. Besides, how many use-cases are there for linking c libraries to your D code which use C IO? I assume of course that C libraries will be linked to D code only when there's no suitable D code that accomplishes the same thing. for example, if I need a regexp lib I can simply use Tango's regexp package which is both more convenient to use and faster than equivalent C/C++ libs. Had I used a C lib I would have needed to take care of the differences between C and D in my code _anyway_ because of other issues like memory handling for example. according to your logic, would you suggest D needs to get rid of its GC to be compatible to the C memory handling mechanisms? I personally like the GC, and I prefer that the programmer will need to explicitly change the default memory handling for those rare IMO cases when this is needed instead of making use of malloc as the default in D. People keep forgetting here that D is a _new_language_ and should be developed accordingly and not as an extension to C++ and it's idioms. We already have C++ (and the future c++0x standard) for that. --Yigal
May 27 2008
prev sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Tue, 27 May 2008 18:49:26 +0400, Frits van Bommel  
<fvbommel remwovexcapss.nl> wrote:

 Sascha Katzner wrote:
 I see no reason why those two IO systems couldn't coexist on top of a  
 common low level cache.

(All of the statements below are AFAIK & IIRC from the newsgroup discussions on this subject) I do: Walter seems convinced that using the libc buffering is the Right Thing To Do(TM) because it allows intermixing of *printf(), putc*(), etc. with writefln & friends without explicitly syncing them. The Tango devs have a good reason to use their own, separate, buffering solution: the tests showing better performance. (And many people consider it bad style to use C-style I/O in D programs anyway, so "it's just not worth it" becomes a good argument pretty quickly here) This just doesn't allow a "common low level cache" since neither of their buffering solutions allows the use of a common buffer unless the other one switches (Phobos can't change libc while much of the Tango IO functionality depends on using the custom buffer and its good performance depends on interfacing directly to the OS[1])... In other words, it's a fundamental disagreement about how to best do I/O. [1] Also, changing the Tango I/O code to use libc instead of direct OS calls isn't very helpful since it still won't be synced to C-style I/O (there'll still be an extra buffer in front of the Tango stuff that would only send stuff to libc when full or explicitly flushed).

C++ has both C-style stdio (fopen, fwrite, etc) and custom iostreams. Both of them have overlapping functionality, and no one cares. Since D can directly interface with C code and we can't throw away that, C-style IO _will_ present in D. And that's Ok, I don't see any problems here. Guys that think that it's the right way would use that, others would use Tango way.
May 27 2008
prev sibling next sibling parent Lutger <lutger.blijdestin gmail.com> writes:
Spacen Jasset wrote:

 Hello,
 
 Currently I am using phobos for my work, which suit at the moment since
 I am mainly using opengl.
 
 Unfortunately I would like use a library that requires Tango, and there
 is yet another library that I would like to use that is coded for
 phobos. Since they both incorporate a core runtime I presume that this
 situation is impossible without akward workarounds?
 
 
 Secondly, I have an uneasy feeling about the situation whereby there are
 two libraries that function independently of each other. What lies ahead
 for this state of affairs; and indeed, what is Walter's and the Tango
 team's position on it?

I can't find the relevant threads, but the idea is that the Phobos runtime will change a bit to suit Tango and Tango will be a library that runs on top of the phobos runtime. However, this will not happen for the D1.x branch since that has been feature-freezed, and I think the Tango team will only start serious efforts to port to D2.x once it is stable enough. In the best case it will be before the end of the year since Walter mentioned that D2 will be stabilized somewhere this fall. That might be too optimistic though. In the meantime tangobos seems to work pretty well.
May 27 2008
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Spacen Jasset wrote:

 Hello,
 
 Currently I am using phobos for my work, which suit at the moment since
 I am mainly using opengl.
 
 Unfortunately I would like use a library that requires Tango, and there
 is yet another library that I would like to use that is coded for
 phobos. Since they both incorporate a core runtime I presume that this
 situation is impossible without akward workarounds?

It should be pretty trivial to support any Phobos using libraries via Tangobos.
 Secondly, I have an uneasy feeling about the situation whereby there are
 two libraries that function independently of each other. What lies ahead
 for this state of affairs; and indeed, what is Walter's and the Tango
 team's position on it?

(Note to Spacen; the answer below is as much to others who have participated in this thread) Back at the conference, we agreed with Walter to have the runtimes compatible for D 2.0, and since the differences today are more or less all about improvements in Tango, this should be in Walter's hands. It would be dis-corteous to our users - both commercial and open source alike - to remove those improvements, that is degrade performance and unstabilize, for the sake of a compatibility that can be achieved via Tangobos. FWIW, to our knowledge, those wishing for us to comply with/use Phobos are in a very small minority compared to those using Tango (and Tangobos which can be claimed to be the opposite solution). -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
May 27 2008
parent Spacen Jasset <spacenjasset yahoo.co.uk> writes:
Lars Ivar Igesund wrote:
 Spacen Jasset wrote:
 
 Hello,

 Currently I am using phobos for my work, which suit at the moment since
 I am mainly using opengl.

 Unfortunately I would like use a library that requires Tango, and there
 is yet another library that I would like to use that is coded for
 phobos. Since they both incorporate a core runtime I presume that this
 situation is impossible without akward workarounds?

It should be pretty trivial to support any Phobos using libraries via Tangobos.
 Secondly, I have an uneasy feeling about the situation whereby there are
 two libraries that function independently of each other. What lies ahead
 for this state of affairs; and indeed, what is Walter's and the Tango
 team's position on it?

(Note to Spacen; the answer below is as much to others who have participated in this thread) Back at the conference, we agreed with Walter to have the runtimes compatible for D 2.0, and since the differences today are more or less all about improvements in Tango, this should be in Walter's hands. It would be dis-corteous to our users - both commercial and open source alike - to remove those improvements, that is degrade performance and unstabilize, for the sake of a compatibility that can be achieved via Tangobos. FWIW, to our knowledge, those wishing for us to comply with/use Phobos are in a very small minority compared to those using Tango (and Tangobos which can be claimed to be the opposite solution).

tango for my code. I must admit that I have considered porting the code I have back to C++ - not really because of the "technical problems" with D, but because of the disconcerted feeling I have with situations such as this and why they arise.
May 28 2008