Switch from Phobos to Tango

I feel we should definitely keep Phobos compatibility, probably using tangobos. I hope it's no big problem.

Maybe support both tango and phobos with tangobos?

I think using tangobos will just annoy Tango folks. Still pondering if we should fully goto tango or not.

Also, when doing the conversion, I want to keep our own redblacktree and dlinkedlist templates /unless/ the tango ones are better and more bug free.

I think 100% tango is the way to go. With DSSS, tango should be easy to install prob by the time v.3 is out. Plus the Virtual File System feature will be nice.

Also... only switch to the tango version of RBTree (set) etc. if tango's version is faster, otherwise if not faster, try to get faster impl accepted into tango :)

Hrm... The other option...

Wait until after the D conference to see if phobos will become compatible with tango... then Arc can just use phobos and tango users can just use tango with arc.

I actually want to do this job... to get some experience with Tango, and to give myself time to relax and think about good API design.

Also: http://www.dsource.org/projects/arclib/wiki/WhyUseTango

If we do switch to tango, I assume we will be able to replace

-> flexsignal -> signalobj -> signalencapsulation

with tango's signal?

http://www.dsource.org/projects/tango/docs/current/tango.core.Signal.html

Or, if that's not enough, which signal template are we going to standardize on?

Signalobj and signalencapsulation are both currently unused, as far as I am aware; we should probably get rid of them (also for 0.2), to not confuse our users - I simply forgot they were there.

flexsignal vs. Tango Signal:

• mixin <-> struct (no big deal)
• function signatures can just be compatible <-> signatures must match exactly
• weak ptr behaviour <-> no weak ptr behaviour
• no statement about connecting/disconnecting in slot <-> con/discon in slot is ok

The Tango signal documentation claims that the weak pointer behaviour would be inherently unsafe. I'm not sure what they mean.

So far I've identified 3 areas that will be more difficult to port to tango than normal.

1. Sound System - Use of std.mmfile. I assume tango's tango.io.MappedBuffer? will do the job
2. XML System - Use of std.stream w/ no real tango equiv.
3. Serialization System - Use of std.stream w/ no real tango equiv.

Everything else will be pretty straight forward, I think.

I ported everything but XML, GUI, serialization and sprite. I did it by removing all std. includes and resolving errors from there. The subsystems I noted are currently excluded from compilation in dsss.conf. With this setup, arc compiles again and several of the unittest work, too.

This was simpler than I expected. The only thing that was making trouble was (as you expected) the mmfile in the arc.sound. I circumvented the problem a bit by using the full slice of the MappedBuffer. (it seems to always map the whole file anyway)

Done