Daniel Keep wrote:
> 
> Andrei Alexandrescu wrote:
>> Don wrote:
>>> [snip]
>>>
>>> It means that any code which uses a library based on both Tango and a
>>> library based on Phobos will end up with two copies of all of the
>>> functions, and they'll have different name mangling etc. You end up
>>> with two incompatible Bigints, for example, even though they have
>>> identical code inside.
>> Oh, I see. You want your library to be usable whether the end user
>> prefers Phobos or Tango. But then why not stick it into a namespace of
>> your choosing? Let's say your libraries are general enough to warrant
>> putting them in a common core, but then anyone who defines some library
>> don't have to go to the "core ombudsman" to add it to the common
>> namespace. They'd just create unique namespaces of their own. No?
>>
>>
>> Andrei
> 
> I think he means this: let's say you're writing app A.  A depends on
> libraries B and C.  B depends on Phobos, and C depends on Tango.  Both B
> and C happen to use BigInts or IO or anything else that isn't shared.
> 
> All of a sudden, you've now got to link in TWO standard libraries
> instead of just one, each with potentially duplicated code.

And you can't obtain a BigInt from library B and pass it into library C, since they are different types; even though they have 100% identical source code except for the name.

> 
> From personal experience, the alternative isn't much better: writing
> code that switches between the two.
> 
> I have an XML library that can use either Phobos or Tango.  It does this
> by implementing all the calls it needs in a shim library, essentially
> using it's own standard library.
> 
> It gets really fun when you need to implement some call that's trivial
> in one library, but really hard in the other.  I remember having to
> build an IO layer so that both Phobos and Tango had the same semantics
> regarding EOF or something...
> 
> Urgh.
> 
>   -- Daniel

Don wrote:
> Daniel Keep wrote:
>>
>> Andrei Alexandrescu wrote:
>>> Don wrote:
>>>> [snip]
>>>>
>>>> It means that any code which uses a library based on both Tango and a
>>>> library based on Phobos will end up with two copies of all of the
>>>> functions, and they'll have different name mangling etc. You end up
>>>> with two incompatible Bigints, for example, even though they have
>>>> identical code inside.
>>> Oh, I see. You want your library to be usable whether the end user
>>> prefers Phobos or Tango. But then why not stick it into a namespace of
>>> your choosing? Let's say your libraries are general enough to warrant
>>> putting them in a common core, but then anyone who defines some library
>>> don't have to go to the "core ombudsman" to add it to the common
>>> namespace. They'd just create unique namespaces of their own. No?
>>>
>>>
>>> Andrei
>>
>> I think he means this: let's say you're writing app A.  A depends on
>> libraries B and C.  B depends on Phobos, and C depends on Tango.  Both B
>> and C happen to use BigInts or IO or anything else that isn't shared.
>>
>> All of a sudden, you've now got to link in TWO standard libraries
>> instead of just one, each with potentially duplicated code.
> 
> And you can't obtain a BigInt from library B and pass it into library C, since they are different types; even though they have 100% identical source code except for the name.

This will partially be solved by structural casts. I have an implementation but haven't put it in phobos yet. Structural casts will allow types that have the same layout to be cast to one another. Of course, that's still not ideal but it's one step forward.


Andrei

Denis Koroskin Wrote:

> I think believe we could take advantage of current state of both libraries in D2 - they are both incomplete and being redesigned to fit D2 better.
> We could revisit both Tango and Phobos, and clean them up by removing outdated modules and modules with same functionality. This will make Phobos really small and much easier to learn.
> 
> On the other hand, Tango will continue providing all the extended functionality.
> 
> Here is a list of Phobos modules that I believe could be safely removed:
> 
> - crc32 and std.md5 - these should be deprecated in favor of tango.io.digest.Crc32 and tango.io.digest.Md5 Tango is better designed and has support for other algoriths (MD2, MD4, SHA256, SHA512, Tiger and more). See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto for details.
> 
> - std.atomics - tango.core.Atomic is superior to it (std.atomics has nothing but CAS anyway).
> - std.base64 - deprecate in favor of tango.io.encode.Base64
> - std.cover - is it supposed to be visible to user? Should it be in Phobos?
> - std.loader - deprecate in favor of tango.sys.SharedLib
> - std.bitarray
> - std.openrj
> - std.process - merge with tango.sys.Process
> - std.regexp - buggy, deprecate in favor of tango.text.Regex
> - std.socket, std.socketstream - deprecate in favor of tango.net.*
> - std.uni - deprecate in favor of tango.text.Unicode
> - std.uri - deprecate in favor of tango.net.Uri
> - std.xml - deprecate in favor of tango.text.xml.*
> - std.zip and std.zlib - deprecate in favor of tango.io.compress.*
> 
> In almost *all* cases Tango has cleaner, faster and less buggy implementation of the same functionality.

That's an interesting list.  Without the ability to distribute Phobos and Tango together from the digitalmars.com site, I doubt anything will get dropped from Phobos in favor of what is in Tango.  For a combined distribution to ever occur requires a whole lot more coordination between Phobos and Tango that I doubt we'll see for a very long time.



> Other modules - does anyone use any of these:
> std.bitmanip
> std.bind
> std.boxer
> std.outbuffer
> std.stdint
> std.syserror
> std.system
> ?

std.bind is useful for binding data that will change before the delegate is called.  I've used bind a lot when doing inter-thread communication with queues of pending commands.

I'd also like to use a variant of bit array with fixed sizes, easier initialiation, and uses the SSE instruction set.  Right now, neither Phobos nor Tango contains what I want.

On Thu, 22 Jan 2009 23:38:04 +0300, Jason House <jason.james.house@gmail.com> wrote:

> Denis Koroskin Wrote:
>
>> I think believe we could take advantage of current state of both libraries in D2 - they are both incomplete and being redesigned to fit D2 better.
>> We could revisit both Tango and Phobos, and clean them up by removing outdated modules and modules with same functionality. This will make Phobos really small and much easier to learn.
>>
>> On the other hand, Tango will continue providing all the extended functionality.
>>
>> Here is a list of Phobos modules that I believe could be safely removed:
>>
>> - crc32 and std.md5 - these should be deprecated in favor of tango.io.digest.Crc32 and tango.io.digest.Md5
>> Tango is better designed and has support for other algoriths (MD2, MD4, SHA256, SHA512, Tiger and more).
>> See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto for details.
>>
>> - std.atomics - tango.core.Atomic is superior to it (std.atomics has nothing but CAS anyway).
>> - std.base64 - deprecate in favor of tango.io.encode.Base64
>> - std.cover - is it supposed to be visible to user? Should it be in Phobos?
>> - std.loader - deprecate in favor of tango.sys.SharedLib
>> - std.bitarray
>> - std.openrj
>> - std.process - merge with tango.sys.Process
>> - std.regexp - buggy, deprecate in favor of tango.text.Regex
>> - std.socket, std.socketstream - deprecate in favor of tango.net.*
>> - std.uni - deprecate in favor of tango.text.Unicode
>> - std.uri - deprecate in favor of tango.net.Uri
>> - std.xml - deprecate in favor of tango.text.xml.*
>> - std.zip and std.zlib - deprecate in favor of tango.io.compress.*
>>
>> In almost *all* cases Tango has cleaner, faster and less buggy implementation of the same functionality.
>
> That's an interesting list.  Without the ability to distribute Phobos and Tango together from the digitalmars.com site, I doubt anything will get dropped from Phobos in favor of what is in Tango.  For a combined distribution to ever occur requires a whole lot more coordination between Phobos and Tango that I doubt we'll see for a very long time.
>

Is there any problem? Walter gave a special permission to Tango team to distribute DMD with Tango. I believe Tango team can give similar permission to distribute DMD with Tango, too. It ships in a bundle with LDC, at least, and I don't see why it can't ship with DMD. Unless Walter is against it.

Oh, and Tango2 should exists, of course.

>
>
>> Other modules - does anyone use any of these:
>> std.bitmanip
>> std.bind
>> std.boxer
>> std.outbuffer
>> std.stdint
>> std.syserror
>> std.system
>> ?
>
> std.bind is useful for binding data that will change before the delegate is called.  I've used bind a lot when doing inter-thread communication with queues of pending commands.
>
> I'd also like to use a variant of bit array with fixed sizes, easier initialiation, and uses the SSE instruction set.  Right now, neither Phobos nor Tango contains what I want.

Denis Koroskin Wrote:

> On Thu, 22 Jan 2009 23:38:04 +0300, Jason House <jason.james.house@gmail.com> wrote:
> 
> > Denis Koroskin Wrote:
> >
> >> I think believe we could take advantage of current state of both
> >> libraries in D2 - they are both incomplete and being redesigned to fit
> >> D2 better.
> >> We could revisit both Tango and Phobos, and clean them up by removing
> >> outdated modules and modules with same functionality. This will make
> >> Phobos really small and much easier to learn.
> >>
> >> On the other hand, Tango will continue providing all the extended functionality.
> >>
> >> Here is a list of Phobos modules that I believe could be safely removed:
> >>
> >> - crc32 and std.md5 - these should be deprecated in favor of
> >> tango.io.digest.Crc32 and tango.io.digest.Md5
> >> Tango is better designed and has support for other algoriths (MD2, MD4,
> >> SHA256, SHA512, Tiger and more).
> >> See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto
> >> for details.
> >>
> >> - std.atomics - tango.core.Atomic is superior to it (std.atomics has
> >> nothing but CAS anyway).
> >> - std.base64 - deprecate in favor of tango.io.encode.Base64
> >> - std.cover - is it supposed to be visible to user? Should it be in
> >> Phobos?
> >> - std.loader - deprecate in favor of tango.sys.SharedLib
> >> - std.bitarray
> >> - std.openrj
> >> - std.process - merge with tango.sys.Process
> >> - std.regexp - buggy, deprecate in favor of tango.text.Regex
> >> - std.socket, std.socketstream - deprecate in favor of tango.net.*
> >> - std.uni - deprecate in favor of tango.text.Unicode
> >> - std.uri - deprecate in favor of tango.net.Uri
> >> - std.xml - deprecate in favor of tango.text.xml.*
> >> - std.zip and std.zlib - deprecate in favor of tango.io.compress.*
> >>
> >> In almost *all* cases Tango has cleaner, faster and less buggy implementation of the same functionality.
> >
> > That's an interesting list.  Without the ability to distribute Phobos and Tango together from the digitalmars.com site, I doubt anything will get dropped from Phobos in favor of what is in Tango.  For a combined distribution to ever occur requires a whole lot more coordination between Phobos and Tango that I doubt we'll see for a very long time.
> >
> 
> Is there any problem? Walter gave a special permission to Tango team to distribute DMD with Tango. I believe Tango team can give similar permission to distribute DMD with Tango, too. It ships in a bundle with LDC, at least, and I don't see why it can't ship with DMD. Unless Walter is against it.


If after all the pledges to fix the Tango/Phobos split and a lot of time to take action, eveything should be fixed. When we have to say "can" "could" or other hypothetical terms, it makes me think there is a problem.

I am disapponted that druntime can't make its way into D1. Without that, nothing will happen with D1, ever. Meanwhile D2 is at least on hold. Lately, there's been discussion of how the licenses of Phobos and Tango are different. I assume that any legal ambiguity will block distribution by digital mars



> Oh, and Tango2 should exists, of course.
> 
> >
> >
> >> Other modules - does anyone use any of these:
> >> std.bitmanip
> >> std.bind
> >> std.boxer
> >> std.outbuffer
> >> std.stdint
> >> std.syserror
> >> std.system
> >> ?
> >
> > std.bind is useful for binding data that will change before the delegate is called.  I've used bind a lot when doing inter-thread communication with queues of pending commands.
> >
> > I'd also like to use a variant of bit array with fixed sizes, easier initialiation, and uses the SSE instruction set.  Right now, neither Phobos nor Tango contains what I want.
> 
> 
>