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

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.

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

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.