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
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
parent reply "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
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 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).
 


Thanks for your replies I will try tangobos, and therefore move over to 
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