www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Standard Library Concerns (Phobos / Tango)

reply Tim Burrell <tim timburrell.net> writes:
Hey all,

It seems that even though Phobos is open source, it's difficult for
people to contribute to.  Patch submissions aren't being accepted as
readily as they should be, and bugs remain even months after having a
fix submitted by users.

Not to mention that it's confusing for new users to have to deal with
two standard libraries.  I think it would be a really good thing for the
language as a whole if there were only one standard library.

My personal opinion is that Walter should let go of Phobos and adopt
Tango as the official standard library.  I know there are people out
there that prefer the Phobos API over Tango's, but I have a feeling that
if Walter asked the Tango people to maintain the Tangobos base as the
official standard library for D they would be okay with that.

It would be a win-win situation for everyone, including Walter.  His
time would get to be spent more on D itself, as he would likely only
need to oversee the standard library in terms of input regarding the API
and patchset accepts.

The community would gain a huge win because there would only be one
unified standard library.

Phobos users would still be able to use the Phobos API but would gain
the benefits of using an API that they feel they can contribute to, and
that has a proven track record of being responsive to fixing bugs.
They'd also gain the ability to use the odd Tango class when desired.

And Tango users wouldn't have to deal with using a non-standard library
as the basis for their app, plus the ability to use the odd bit of the
Phobos API would be nice now and again as well.

I really feel strongly that a move toward a single standard library is
the right thing to do for D.  There's very few cons to such a move and a
great many pros.

Anyone else have any thoughts on the matter?

Tim.
Feb 06 2008
next sibling parent reply downs <default_357-line yahoo.de> writes:
Tim Burrell wrote:

 Hey all,
 
 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.
 
 Not to mention that it's confusing for new users to have to deal with
 two standard libraries.  I think it would be a really good thing for the
 language as a whole if there were only one standard library.
 
 My personal opinion is that Walter should let go of Phobos and adopt
 Tango as the official standard library.


Vote in favor, not that it matters.

I prefer Phobos' structure to Tango, however it remains a simple fact that
Tango is technically superior and better maintained. I'm sick of running into
Phobos bugs and limitations while trying to make my code work. The only thing
holding me back from switching is that Phobos is, for better or worse, the
_standard library_. If Walter dropped it for Tango(bos), I'd be a very happy
critter indeed.

 --downs, pessimistic
Feb 06 2008
next sibling parent reply "dominik" <aha aha.com> writes:
"downs" <default_357-line yahoo.de> wrote in message 
news:foci1o$1e9$1 digitalmars.com...

 Vote in favor, not that it matters.

 I prefer Phobos' structure to Tango, however it remains a simple fact that 
 Tango is technically superior and better maintained.


You stole my words. I vote in favour too, if that matters.
Feb 06 2008
parent reply "Saaa" <empty needmail.com> writes:
 Vote in favor, not that it matters.

 I prefer Phobos' structure to Tango, however it remains a simple fact 
 that Tango is technically superior and better maintained.


 You stole my words. I vote in favour too, if that matters.


Vote++;
Feb 06 2008
parent Jason House <jason.james.house gmail.com> writes:
Saaa Wrote:


 Vote++; 


There's another thread that has an official poll.  Enter your answer there...
Feb 06 2008
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
downs, el  6 de febrero a las 15:57 me escribiste:

 Tim Burrell wrote:

 Hey all,
 
 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.
 
 Not to mention that it's confusing for new users to have to deal with
 two standard libraries.  I think it would be a really good thing for the
 language as a whole if there were only one standard library.
 
 My personal opinion is that Walter should let go of Phobos and adopt
 Tango as the official standard library.


 
 Vote in favor, not that it matters.
 
 I prefer Phobos' structure to Tango, however it remains a simple fact that
Tango is technically superior and better maintained. I'm sick of running into
Phobos bugs and limitations while trying to make my code work. The only thing
holding me back from switching is that Phobos is, for better or worse, the
_standard library_. If Walter dropped it for Tango(bos), I'd be a very happy
critter indeed.


Exactly the same feeling.

Maybe GDC could make the step and provide tango as the standard library.
If successful, I guess DMD will follow that path.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
- i bet microsoft's developers were on diet when they had to do win95
- microsoft has developers?
Feb 06 2008
parent reply Tim Burrell <tim timburrell.net> writes:
Leandro Lucarella wrote:

 Exactly the same feeling.
 
 Maybe GDC could make the step and provide tango as the standard library.
 If successful, I guess DMD will follow that path.


Honestly, I'd take this over no action, as it might spur Walter to
follow suit, but it could actually end up being another a step backward
for the language... then instead of two compilers and two competing
standard libraries we've got two competing compilers that ship with
different standard libs.  Ie, even more confusion for people new to the
language!

I think it would go a long way if there could be some official action on
this on Walter's part.

I know it's a bit complicated because Walter is actively developing D2,
and thus language changes need to be precipitated by library API changes.

I really believe with a little bit of communication this would hold no
problem for replacing the standard library.  It could go a number of
ways, not the least of which is for Walter to simply maintain his own
branch of the standard lib, and when D2 is ready push the changes down
to the rest of the Tango team.

Ideally though this could potentially set up a situation where the users
have more direct contact with language changes as well -- which I think
would also be a boon.  Ie, how does this language change affect the
standard library, and this standard library feature would really be
improve by adding language feature X.

Obviously it would depend on Walter, but even if he still wants total
control over the language (not necessarily a bad thing, D is pretty
sweet!), he can still feel free to give up Phobos in favor of Tango and
not have to worry about D2, or playing slave to the standard library.

I can't really think of a compelling reason NOT to do this!
Feb 06 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Tim Burrell, el  6 de febrero a las 11:47 me escribiste:

 Leandro Lucarella wrote:

 Exactly the same feeling.
 
 Maybe GDC could make the step and provide tango as the standard library.
 If successful, I guess DMD will follow that path.


 
 Honestly, I'd take this over no action, as it might spur Walter to
 follow suit, but it could actually end up being another a step backward
 for the language... then instead of two compilers and two competing
 standard libraries we've got two competing compilers that ship with
 different standard libs.  Ie, even more confusion for people new to the
 language!


If tangobos complies with phobos, is not a "different stantdard library"
it's a different *implementation* of the standard library (and some
additions, the tango API).


 I think it would go a long way if there could be some official action on
 this on Walter's part.


I think you missed the compatibility layer premise. If the new
implementation is backward compatible, what's the long way?

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Cuanta plata que aquí circula y yo que ando con gula...
	-- Sidharta Kiwi
Feb 06 2008
prev sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
downs wrote:

 Tim Burrell wrote:

 Hey all,

 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.

 Not to mention that it's confusing for new users to have to deal with
 two standard libraries.  I think it would be a really good thing for the
 language as a whole if there were only one standard library.

 My personal opinion is that Walter should let go of Phobos and adopt
 Tango as the official standard library.


 
 Vote in favor, not that it matters.


I vote in favour, too, hoping that it actually does matter.
Feb 06 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Maybe this is the type of thing that should be done as some kind of poll...
Something that asks d users which standard library setups they're ok with.
phobos
tango
tango+tangobos
tango + phobos (two standards)

With mass participation and some real numbers to support hunches, it may be
easier to encourage action by others.  Personally, I'd vote for tango or
tango+tangobos.  My port to Tango (last year) was relatively painless except
for I/O.

Tim Burrell Wrote:


 Hey all,
 
 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.
 
 Not to mention that it's confusing for new users to have to deal with
 two standard libraries.  I think it would be a really good thing for the
 language as a whole if there were only one standard library.
 
 My personal opinion is that Walter should let go of Phobos and adopt
 Tango as the official standard library.  I know there are people out
 there that prefer the Phobos API over Tango's, but I have a feeling that
 if Walter asked the Tango people to maintain the Tangobos base as the
 official standard library for D they would be okay with that.
 
 It would be a win-win situation for everyone, including Walter.  His
 time would get to be spent more on D itself, as he would likely only
 need to oversee the standard library in terms of input regarding the API
 and patchset accepts.
 
 The community would gain a huge win because there would only be one
 unified standard library.
 
 Phobos users would still be able to use the Phobos API but would gain
 the benefits of using an API that they feel they can contribute to, and
 that has a proven track record of being responsive to fixing bugs.
 They'd also gain the ability to use the odd Tango class when desired.
 
 And Tango users wouldn't have to deal with using a non-standard library
 as the basis for their app, plus the ability to use the odd bit of the
 Phobos API would be nice now and again as well.
 
 I really feel strongly that a move toward a single standard library is
 the right thing to do for D.  There's very few cons to such a move and a
 great many pros.
 
 Anyone else have any thoughts on the matter?
 
 Tim.
Feb 06 2008
parent Tim Burrell <tim timburrell.net> writes:
Jason House wrote:

 Maybe this is the type of thing that should be done as some kind of poll...
Something that asks d users which standard library setups they're ok with.
 phobos
 tango
 tango+tangobos
 tango + phobos (two standards)
 
 With mass participation and some real numbers to support hunches, it may be
easier to encourage action by others.  Personally, I'd vote for tango or
tango+tangobos.  My port to Tango (last year) was relatively painless except
for I/O.


Good Call!  Poll created! (see my post regarding Standard Library Poll)

Tim.
Feb 06 2008
prev sibling next sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
I also want to see the "community driven" AND "standard" lib.

Tango meets my needs.
  - fast fixing of errors
  - More open for feature addition
  - performant design
  - more plattforms
  - contribution feels more welcome

So actually the "community driven" attribute is more important for me 
than the "standard" tag is.

It would be so cool if all would work together, the tango team AND 
walter, andrei, and the other phobos contributors.

The existance of both only produces frictional loss. And it feels like a 
dark shadow over the community.

People who actually run their projects don't have trouble with it. They 
have their toolchains installed. Its only the newbies and the 
lib-writers that have to fight the differences. This is bad for the 
community as a whole.
Feb 06 2008
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
D1/Phobos1 needs to be taken out of Walters hands. He doesn't care about it,
even though it's 
the version of D with the largest userbase. If he cared he would reply to this
thread as well 
as the countless others before it (on the same topic).

Even though D2 is probably going to be finished by fall this year, I'm pretty
sure there are 
lots of D users who will not migrate. D2 is basically a new language and some
of the things it 
forces down your throat are some of the things I (and probably not just me)
really liked not 
having to worry about. (yes I'm talking about const).

As long as Phobos1 does not receive fixes it might as well be considered dead.
To me there is no doubt on what needs to be done here. Ditch Phobos and start
using Tango. The 
sooner you do it the sooner you will feel comfortable with it.

It's kinda sad, but I don't see a bright future for D when issues as important
as this are 
simply just ignored.
Feb 06 2008
next sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomas Lindquist Olsen wrote:

 D1/Phobos1 needs to be taken out of Walters hands. He doesn't care about
 it, even though it's the version of D with the largest userbase. If he
 cared he would reply to this thread as well as the countless others
 before it (on the same topic).


You do realize you're posting just two hours after the original post in
this thread?  Apparently Walter needs to have a constant eye on the
group and hair-trigger response in order to show you he cares....

- --Joel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHqevlzLx4GzBL9dYRAmC9AJ4/qTjrThk/XtyZMiogqVnDDLWp4QCggw3p
2s5RC63Q97dzb0Utaxo1C4M=
=QFPO
-----END PGP SIGNATURE-----
Feb 06 2008
next sibling parent Tim Burrell <tim timburrell.net> writes:
 D1/Phobos1 needs to be taken out of Walters hands. He doesn't care about
 it, even though it's the version of D with the largest userbase. If he
 cared he would reply to this thread as well as the countless others
 before it (on the same topic).


 
 You do realize you're posting just two hours after the original post in
 this thread?  Apparently Walter needs to have a constant eye on the
 group and hair-trigger response in order to show you he cares....


I don't think anyone was saying that.  Whether or not it's true, it
appears that a good deal of the D community feels that Walter isn't
concerned about what users of his language think.  Obviously this isn't
the only time issues have been brought forth that the community feels
one way about that go unanswered and ignored.

I would say though that I think your response is justified... finger
pointing isn't the way to go here.

I would never chastise Walter for not responding within a certain time,
but it would be nice to get his opinion on the matter.  If he says "too
bad guys, you feel one way, but it's my language and this is how it's
gonna be." then that would be nice to know!  Maybe he has a master plan
that we don't know about.  I'm open to hearing anything from him, but
silence on matters that the community cares about isn't a good way to
lead, and whether or not he likes it, by virtue of beign D's creator
Walter is a leader.
Feb 06 2008
prev sibling parent Darryl Bleau <user example.net> writes:
Joel C. Salomon wrote:

 Tomas Lindquist Olsen wrote:

 D1/Phobos1 needs to be taken out of Walters hands. He doesn't care about
 it, even though it's the version of D with the largest userbase. If he
 cared he would reply to this thread as well as the countless others
 before it (on the same topic).


 
 You do realize you're posting just two hours after the original post in
 this thread?  Apparently Walter needs to have a constant eye on the
 group and hair-trigger response in order to show you he cares....
 
 --Joel


I was going to say the same thing, until I realized that his judgment of
'care' was likely referencing the threads included in 'the countless
others before' and not this specific thread.
Feb 06 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
downs:

I prefer Phobos' structure to Tango,


I agree. So maybe this too is an issue to be addressed. I mean some of the
current structure of Tango my be changed a bit, before adopting it as the std
lib. I think this too is a worthy discussion topic.


Tomas Lindquist Olsen:

 D1/Phobos1 needs to be taken out of Walters hands.


If you talk like that I think Guido Van Rossum too would not answer much :-)
I think you have to be much more gentle, etc.

Bye,
bearophile
Feb 06 2008
next sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
bearophile wrote:

 downs:

 I prefer Phobos' structure to Tango,


 
 I agree. So maybe this too is an issue to be addressed. I mean some of the
current structure of Tango my be changed a bit, before adopting it as the std
lib. I think this too is a worthy discussion topic.
 
 
 Tomas Lindquist Olsen:

 D1/Phobos1 needs to be taken out of Walters hands.


 
 If you talk like that I think Guido Van Rossum too would not answer much :-)
 I think you have to be much more gentle, etc.
 
 Bye,
 bearophile


You're probably right. I realise it comes out a bit harsh, it's not really
meant as a personal 
attack, but with the way D is developed it's hard to point anywhere else but
Digital Mars, i.e. 
Walter.

I'm just really disappointed that D1 is neglected. It's something that's on my
mind a lot (I've 
invested quite a bit of my spare time in D), and every now and then when these
topics come up 
the outcome is exactly the same. Nothing happens.
Feb 06 2008
prev sibling parent reply "dominik" <aha aha.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:focsqq$10c4$1 digitalmars.com...

 I mean some of the current structure of Tango my be changed a bit, before 
 adopting it as the std lib. I think this too is a worthy discussion topic.


khm :)
http://www.digitalmars.com/d/2.0/phobos/std_bitmanip.html
Feb 06 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
dominik:

 khm :)
 http://www.digitalmars.com/d/2.0/phobos/std_bitmanip.html 


Can you explain me what you mean? I can't read your mind...

[Regarding that module, I think it's better than not having an automatic way of
managing bitfields at all (It's not much different from the module I have
improved a bit starting from the code given by another person. I think Walter
has to write a thank you to that person at the bottom of that std_bitmanip
page). But if you write two 15 lines long benchmarks to compare the speed of
that bitfield management to how GCC 3.x manages bitfields, you may find it's 2
or more times slower.]

Bye,
bearophile
Feb 06 2008
parent reply "dominik" <aha aha.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:fod8t8$1tf6$1 digitalmars.com...

 dominik:

 khm :)
 http://www.digitalmars.com/d/2.0/phobos/std_bitmanip.html


 Can you explain me what you mean? I can't read your mind...


sorry :) I like that! I use it extensively, and would like to see it in 
simillar form in tango, or bring in bitfields to D as a first class citizen.
Also, while I'm at the numbers.. walter did AWHILE ago Bigint implementation 
for zortech I believe, wouldn't it be nice to make it a part of D, not 
library per se? Be ti simple BCD implementation, I don't care, but I care 
for BigInt.
Feb 07 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
dominik:

 walter did AWHILE ago Bigint implementation 
 for zortech I believe, wouldn't it be nice to make it a part of D, not 
 library per se? Be ti simple BCD implementation, I don't care, but I care 
 for BigInt.


I'd like to have such bignum lib in the std lib. If someone here knows of a
*working* bignum lib, please tell me, because I have tried many but none works.

Muti precision integral values are very useful, not for crypto purposes as some
say, but because they don't overflow, so you can use them without caring of
that *large* class of bugs (a certain percentage, like 10-30%, of all bugs
comes from integral type overflows/underflows). Reducing that cognitive burden
has the side effect of speeding up coding a bit too, because you can focus your
minds on other things.
Experience shows that on modern CPUs a certain (often large) percentage of the
code doesn't need to be optimized a lot (this is why scripting languages are so
used today), while you can use fixnums in the speed critical sections of the
code.
Said that, the DMD can grow smarter: it can infer some of the situations where
a bigint doesn't actually needs to be a bigint (silly example: for(bigint i =0;
i < 100; n++) {}) and it can replace them with fixnums :-) This can probably
speed up the code enough, so people will use them in a more relaxed way, and
this will reduce bug count even more :-) I don't know how much easy such bound
inferring is, and how much it can slow down the compiler.

Bye,
bearophile
Feb 07 2008
parent jcc7 <technocrat7 gmail.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 dominik:

 walter did AWHILE ago Bigint implementation
 for zortech I believe, wouldn't it be nice to make it a part of D,
 not library per se? Be ti simple BCD implementation, I don't care,
 but I care for BigInt.


 I'd like to have such bignum lib in the std lib. If someone here
 knows of a *working* bignum lib, please tell me, because I have
 tried many but none works.


I've never needed a bignum lib, so I don't know what actually might work.

Have you tried the bigint in DWin?
http://www.dsource.org/projects/dwin/browser/trunk/math/bigint/

I think it's an updated version of the bigint in Deimos:
http://www.dsource.org/projects/deimos/browser/trunk/etc/bigint

Other related things in Deimos:
http://www.dsource.org/projects/deimos/browser/trunk/etc/bigrational.d
http://www.dsource.org/projects/deimos/browser/trunk/etc/longrational.d
Feb 08 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Tomas Lindquist Olsen wrote:

 D1/Phobos1 needs to be taken out of Walters hands. He doesn't care about 
 it, even though it's the version of D with the largest userbase. If he 
 cared he would reply to this thread as well as the countless others 
 before it (on the same topic).


That reminds me of the whole "George Bush doesn't care about black 
people" thing.

I'm sure Walter cares a lot, and not only that, I think he reads most of 
the newsgroup posts. He replies when he has something interesting, and 
likely non-inflammatory to say.

DMD 1.x should remain *very* stable, so only bugfixes should appear 
there, which Walter has continually provided. As far as Phobos 1.x is 
concerned, I think some *NON-BREAKING* additions would be nice, but I 
generally think, besides bugfixes, stability is more important in that 
branch.

My requirement (in case anyone cares): If I write an application with D 
1.x/ Phobos 1.x today, I want it compiling without change in 2 years.
Feb 06 2008
parent reply Tim Burrell <tim timburrell.net> writes:
Robert Fraser wrote:

 DMD 1.x should remain *very* stable, so only bugfixes should appear 
 there, which Walter has continually provided. As far as Phobos 1.x is 
 concerned, I think some *NON-BREAKING* additions would be nice, but I 
 generally think, besides bugfixes, stability is more important in that 
 branch.
 
 My requirement (in case anyone cares): If I write an application with D 
 1.x/ Phobos 1.x today, I want it compiling without change in 2 years.


Personally, I'm looking to the future.  D is in a great position because
it's a new language, and it's starting to pique a lot of interest.  The
next few years are probably a bit of a crucial time for it.  Especially
because when D2 is released it'll _already_ be breaking backwards
compatibility, so there's no issue there.

No one's talking about pulling Phobos and your D1 written Phobos apps
out from under you.

But even so, what we should be doing is figuring out what's best for the
language as a whole, and not what's best for the code we've already
written.  It's easy to keep a copy of Phobos 1.x around or, as others
have suggested, ensure there's a compatibility layer available for
legacy applications.

The problem is really that while, yes, Walter has provided bug fixes, he
hasn't gone the distance in opening up Phobos to other contributors.
There are patch submissions that would fix critical bugs that are months
and months old (there's even a good example on the NG today from Downs).

Phobos development isn't keeping up with demand.  Many people are
frustrated at long standing bugs in Phobos.  Now look at the situation,
we've got two standard libraries, where MOST of the D community is
opting for a library OTHER THAN the alternative!

It's not a healthy state of affairs!

Phobos will _never_ be able to keep up with Tango in terms of
reliability, quality, etc, simply because Phobos isn't really open.
Even just on a pure man hours scale -- Walter can't do it all, nor
should he have to.  He's designed a really great language, but I think
it's time to pass the torch on the standard library.

There are plenty of people who prefer Phobos but agree that Tango is
technically superior.  The fact that there's already a compatibility
layer available makes the legacy code argument that much more moot.

You can have your cake and eat it too!  Everything's basically already
in place!  A new standard library that is open, well maintained, and
that has Phobos compatibility available.

I fully agree 1.x should remain stable, but I also think 2 should drop
Phobos.  It may be in active development now, but the cycle will just
continue!  Now is the perfect time to sort all this stuff out!
Feb 06 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Tim Burrell wrote:

 The problem is really that while, yes, Walter has provided bug fixes, he
 hasn't gone the distance in opening up Phobos to other contributors.
 There are patch submissions that would fix critical bugs that are months
 and months old (there's even a good example on the NG today from Downs).
 
 Phobos development isn't keeping up with demand.  Many people are
 frustrated at long standing bugs in Phobos.  Now look at the situation,
 we've got two standard libraries, where MOST of the D community is
 opting for a library OTHER THAN the alternative!


Speaking of bugs. If Phobos ceases to be the standard library, then bugs 
in Phobos should be excised from bugzilla, and a separate bug tracker 
should be created for the standard library.


 It's not a healthy state of affairs!
 
 Phobos will _never_ be able to keep up with Tango in terms of
 reliability, quality, etc, simply because Phobos isn't really open.
 Even just on a pure man hours scale -- Walter can't do it all, nor
 should he have to.  He's designed a really great language, but I think
 it's time to pass the torch on the standard library.


Now Andrei and Brad are working on Phobos, and I think Walter doesn't do 
much with it. But that's two people instead of probably a dozen or so 
who actively work on Tango.


 You can have your cake and eat it too!  Everything's basically already
 in place!  A new standard library that is open, well maintained, and
 that has Phobos compatibility available.


Right. Walter just has to tell Brad and Andrei to use that instead and 
drop it in the zipfile with each release. And probably send a prerelease 
version of the compiler to Sean and Kris a day or two before, which he 
already has to do with Andrei and Brad... So it's pretty much no extra 
work for him.
Feb 08 2008
prev sibling next sibling parent reply Darryl Bleau <user example.net> writes:
 I really feel strongly that a move toward a single standard library is
 the right thing to do for D.


+1. Ideally though, the tangobos compatibility layer would be dropped
entirely, as I feel that it's existence would still introduce confusion
to new users. The current situation would remain nearly the same, except
that the standard library would simply include this 'other' standard
library layer... (this would make me scratch my head, were I new to D).
There would still be a separation in code like there is today, except
we'd have tangobos/tango versus phobos/tango.

A separately available tangobos whose intended function is to aid in
moving legacy phobos apps to tango would make more sense, imo, than
giving that layer persistence in the new standard lib.

At some point you just have to decide that a certain direction is the
way to go, and go there. Tango-D is nearly a completely separate
language from Phobos-D but I think it's clearly made it's mark and is an
obvious direction to move in. D2 might be a good place to do it.
Feb 06 2008
parent Tim Burrell <tim timburrell.net> writes:
Darryl Bleau wrote:

 +1. Ideally though, the tangobos compatibility layer would be dropped
 entirely, as I feel that it's existence would still introduce confusion
 to new users. The current situation would remain nearly the same, except
 that the standard library would simply include this 'other' standard
 library layer... (this would make me scratch my head, were I new to D).
 There would still be a separation in code like there is today, except
 we'd have tangobos/tango versus phobos/tango.


A good point.  I believe you're correct... now that I think about it, it
may be best not to go this way.  Replacing inconsistency for another
kind of inconsistency isn't necessarily the greatest option.


 A separately available tangobos whose intended function is to aid in
 moving legacy phobos apps to tango would make more sense, imo, than
 giving that layer persistence in the new standard lib.


A great suggestion.  Agreed.
Feb 06 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
You always know there's a topic on either const or the standard 
libraries when the newreader reports 40+ new posts in a day :-).
Feb 06 2008
prev sibling next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 06 Feb 2008 10:49:17 -0400, Tim Burrell wrote:


 Hey all,
 
 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.


Yes, this has been a long standing issue with Phobos development.


 Not to mention that it's confusing for new users to have to deal with
 two standard libraries.  I think it would be a really good thing for the
 language as a whole if there were only one standard library.


Yes, of course.


 My personal opinion is that Walter should let go of Phobos and adopt
 Tango as the official standard library.  I know there are people out
 there that prefer the Phobos API over Tango's, but I have a feeling that
 if Walter asked the Tango people to maintain the Tangobos base as the
 official standard library for D they would be okay with that.


I have not been 'converted' to the Tango style of coding as I still prefer
the old-fashioned Phobos style, but that is just a discipline issue. I
would happily use Tango if it were the One True (tm) standard D library,
however, at least for D1 users and for existing Phobos apps, we would need
a Tangobos for a while too.

The main issues for me is that whatever standard library is in place, that
it is maintained in a timely manner (including documentation) and contains
the functionality that I need to use. Phobos has yet to achieve this for
me.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
7/02/2008 10:22:23 AM
Feb 06 2008
parent reply Moritz Warning <moritzwarning _nospam_web.de> writes:
On Thu, 07 Feb 2008 10:30:38 +1100, Derek Parnell wrote:


 On Wed, 06 Feb 2008 10:49:17 -0400, Tim Burrell wrote:
 

 Hey all,
 
 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.


 
 Yes, this has been a long standing issue with Phobos development.
 


Just some thing I have missed to be mentioned in this discussion.
I hope I can contribute some some interesting/productive perspective.

Due to Phobos simpler size:
- it's easier to maintain and adapt
- it's easier to start with
- it avoids to get in the way of peoples coding philosophies
- people want to have new features (but Phobos feature set is comparable 
to the C++ std)

Due to Tangos bigger size and range of functionally (Logging, FilePath, 
Time classes, Clustering, Http stuff..).
- Tango will have many changes as there were already
- it's hard to design smth. that satisfy most needs if.
   Depending on the subject of the aim, it may be even impossible.
- Tango doesn't offer D2.0 compatibility (despite some early attemps)
- people want to change features, since they don't fit all their special 
needs

Phobos is also an important workground to get first hand experience for 
Walter if a new feature is usefull.
For every new DMD 2.0 version he must also offer a standard library.
Keeping Tango up to date with all D2.0 language experiments would at 
least slow down language development considerable.

Tangobos could be a good start point to solve the issue,
but it would have to be a _true_ subset of Tango that doesn't depend
on the higher level features of Tango.
That issue introduces two hurdles:
- the design of Phobos and Tango must get in some sync on that level
- some basic Tango features that Phobos also does have are probably glued 
together with fancy stuff on class level.

But I think it can be done.

Phobos need to get some more basic OO (Object Orientated) design (console 
output, threads?) and Tango need to unglue some stuff from it's OO that 
doesn't have to be OO style.

Some first attemps have already been made.
(e.g. Phobos with Tango Threads, Tango and Phobos changes to be more 
compatible)

In a nutshell, I think that Tango is not ready yet to be _the_ standard 
lib. It can't move as fast as the D2.0 language evolves.

Java has a big std library, but Sun also have manpower/money.
Still, it takes time for them to improve the language
and yet, they will continue to have oudated parts in theire std library 
on regular basis (e.g. gui stuff). :>

For myself, I'm a satisfied Tango user.
But I try not to use all fancy high level features often since they
sometimes don't fit my needs, code philosophy, intended encapsulation or 
behaviour.
Feb 06 2008
next sibling parent reply Moritz Warning <moritzwarning _nospam_web.de> writes:
On Thu, 07 Feb 2008 00:58:50 +0000, Moritz Warning wrote:


 Just some thing I have missed to be mentioned in this discussion. I hope
 I can contribute some some interesting/productive perspective.


Before sb. points out that I forgot to realize that Phobos doesn't get 
enough fixing despite patch are available (thanks to the effort of 
users!)...
It's a pity that Phobos bugs/fixes doesn't get more attention from
the maintainers. :|
But it doesn't make Tango a more suitable library for that purpose.
Feb 06 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Moritz Warning wrote:

 On Thu, 07 Feb 2008 00:58:50 +0000, Moritz Warning wrote:
 

 Just some thing I have missed to be mentioned in this discussion. I hope
 I can contribute some some interesting/productive perspective.


 
 Before sb. points out that I forgot to realize that Phobos doesn't get 
 enough fixing despite patch are available (thanks to the effort of 
 users!)...
 It's a pity that Phobos bugs/fixes doesn't get more attention from
 the maintainers. :|
 But it doesn't make Tango a more suitable library for that purpose.


Yes it does. Bugs inhibit the usability of a library, and everyone has 
to use the standard library. So a buggy library is a poor candidate for 
the standard library, especially when there's an alternative that's much 
  more reliable.
Feb 07 2008
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Fri, 08 Feb 2008 01:02:25 -0500, Christopher Wright wrote:


 Moritz Warning wrote:

 On Thu, 07 Feb 2008 00:58:50 +0000, Moritz Warning wrote:
 It's a pity that Phobos bugs/fixes doesn't get more attention from
 the maintainers. :|
 But it doesn't make Tango a more suitable library for that purpose.


 
 Yes it does. Bugs inhibit the usability of a library, and everyone has 
 to use the standard library. So a buggy library is a poor candidate for 
 the standard library, especially when there's an alternative that's much 
   more reliable.


I know you are not really suggesting that Tango is bug-free ;-)

Leaving aside any usability aspect for now, the major problem with Phobos
is the apparent difficulty in getting bug fixes and improvements
incorporated into the source code. 

I assume that Walter does not want Phobos to contain bugs, and that he
actually wants people to use it, so therefore I assume that there must be
some logistical reasons for the submissions not making into the release
packages. If those logistical problems can be solved then there is every
reason why Phobos should remain, in addition to the option of Tango.

Of course, it would even better if developers could use both libraries in
the same application (without a Tangobos layer).

So Walter, how can we or anyone else help solve the logistics issues?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
8/02/2008 5:06:07 PM
Feb 07 2008
parent reply kris <foo bar.com> writes:
Derek Parnell Wrote:

[snip]


 Of course, it would even better if developers could use both libraries in
 the same application (without a Tangobos layer).



Hiya Derek

Just wanted to clarify that the Tangobos package (from Gregor) is not a
'layer', as you described it above. It is the phobos source code with a handful
of minor changes made to it. Folks who download the Tango distro can use both
the phobos API and the Tango API side by side, if they choose to do so. There's
no thunks, redirects, or other intermediate steps involved that might impede
the phobos API.

What's different is this: the underlying phobos runtime components are removed
and replaced with the Tango equivalent instead. This includes the GC, typeinfo,
Object implementation, threading, and a few others. Some "runtime-heavy"
phobos-based code are reasonably likely to execute more efficiently or
effectively because of this change.

To be specific, the Tango distro already provides what Walter has noted he
would like to see at some point in the future -- both API operating atop a
common runtime. This has been available for some time now (basically since
Tangobos was created; recently it has been bundled instead, as one of the
download options, to make things trivial to setup and use). 

Sean has described earlier why it is more effective to run phobos atop of the
Tango runtime, rather than the other way around, so I won't rehash that here.
Nor will I bore you with why the Tango runtime is often a better choice, since
others have already gone over that. Those are implementation details anyway,
rather than functional capabilities.

Given all the above it should be clear that developers can already use both
libraries, on the same runtime, in the same application -- it's not some future
promise ;)

Hope this helps to clarify things?

- Kris
Feb 08 2008
parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 08 Feb 2008 21:18:42 -0500, kris wrote:


 Derek Parnell Wrote:
 
 [snip]
 

 Of course, it would even better if developers could use both libraries in
 the same application (without a Tangobos layer).


 
 Hiya Derek
 
 Just wanted to clarify that the Tangobos package (from Gregor) is not a
 'layer' ...


Thanks Kris. I was not aware of that. I assumed that it was a wrapper
around Tango that made it look like Phobos. 


 Hope this helps to clarify things?


It sort of does, but it seems that we now have the 'best of both worlds'
with Tangobos, so what will be coming from DigitalMars? Will we then have
four options: Tango, Tangobos, 'classic' Phobos and 'modern' Phobos?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Feb 09 2008
parent "Kris" <foo bar.com> writes:
"Derek Parnell" <derek psych.ward> wrote in ...

 On Fri, 08 Feb 2008 21:18:42 -0500, kris wrote:


 Derek Parnell Wrote:

 [snip]


 Of course, it would even better if developers could use both libraries 
 in
 the same application (without a Tangobos layer).


 Hiya Derek

 Just wanted to clarify that the Tangobos package (from Gregor) is not a
 'layer' ...


 Thanks Kris. I was not aware of that. I assumed that it was a wrapper
 around Tango that made it look like Phobos.


 Hope this helps to clarify things?


 It sort of does, but it seems that we now have the 'best of both worlds'
 with Tangobos, so what will be coming from DigitalMars? Will we then have
 four options: Tango, Tangobos, 'classic' Phobos and 'modern' Phobos?



To hazard a guess, perhaps this was the motivation for that recent poll?
Feb 09 2008
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 07 Feb 2008 00:58:50 +0000, Moritz Warning wrote:


 On Thu, 07 Feb 2008 10:30:38 +1100, Derek Parnell wrote:
 

 On Wed, 06 Feb 2008 10:49:17 -0400, Tim Burrell wrote:
 

 Hey all,
 
 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.


 
 Yes, this has been a long standing issue with Phobos development.
 
 


 Just some thing I have missed to be mentioned in this discussion. I hope
 I can contribute some some interesting/productive perspective.
 
 Due to Phobos simpler size:
 - it's easier to maintain and adapt
 - it's easier to start with
 - it avoids to get in the way of peoples coding philosophies - people
 want to have new features (but Phobos feature set is comparable to the
 C++ std)
 
 Due to Tangos bigger size and range of functionally (Logging, FilePath,
 Time classes, Clustering, Http stuff..). - Tango will have many changes
 as there were already - it's hard to design smth. that satisfy most
 needs if.
    Depending on the subject of the aim, it may be even impossible.
 - Tango doesn't offer D2.0 compatibility (despite some early attemps) -
 people want to change features, since they don't fit all their special
 needs
 
 Phobos is also an important workground to get first hand experience for
 Walter if a new feature is usefull.
 For every new DMD 2.0 version he must also offer a standard library.
 Keeping Tango up to date with all D2.0 language experiments would at
 least slow down language development considerable.
 
 Tangobos could be a good start point to solve the issue, but it would
 have to be a _true_ subset of Tango that doesn't depend on the higher
 level features of Tango. That issue introduces two hurdles:
 - the design of Phobos and Tango must get in some sync on that level -
 some basic Tango features that Phobos also does have are probably glued
 together with fancy stuff on class level.
 
 But I think it can be done.
 
 Phobos need to get some more basic OO (Object Orientated) design
 (console output, threads?) and Tango need to unglue some stuff from it's
 OO that doesn't have to be OO style.
 
 Some first attemps have already been made. (e.g. Phobos with Tango
 Threads, Tango and Phobos changes to be more compatible)
 
 In a nutshell, I think that Tango is not ready yet to be _the_ standard
 lib. It can't move as fast as the D2.0 language evolves.
 
 Java has a big std library, but Sun also have manpower/money. Still, it
 takes time for them to improve the language and yet, they will continue
 to have oudated parts in theire std library on regular basis (e.g. gui
 stuff). :>
 
 For myself, I'm a satisfied Tango user. But I try not to use all fancy
 high level features often since they sometimes don't fit my needs, code
 philosophy, intended encapsulation or behaviour.


I agree that Tango isn't able to keep up with the rapid changes in D2 or 
D3? But, in my opinion I don't think it has to in order to be called the 
standard library. D2 has not been released, it has no obligation to 
provide the same environment as D1. D2 is publicly available because 
Walter relies greatly on community input/testing. Phobos can be used as 
the testing standard library, and Tango for releases.

Sure this causes people to go out of their way to test the latest D, but 
I don't see this as a problem. Since D now has stable branches, the beta 
branch shouldn't be used for production. Don't get me wrong, Phobos 
should still be a viable option for developing in.

What I think should be done. D1 should be left alone, an option of 
downloading dmd with Phobos or Tango should be available. Starting with 
D2 Tango should take over as the standard library (no tangobos). Phobos 
should be an add-on. This can either be like Tango is now where you 
download and install it, or it can come with the compiler and have a 
compiler flag to switch them.

Currently Tango is the oddball out library, you have to go to the trouble 
to find and use it. Yet many of the projects at Dsource build on it. Many 
of the projects that were built on Phobos are going to the trouble to 
switch. The only ones that aren't looking at switching seem to be the 
dead projects. This to me is a big indicator that Tango should take the 
stand. People are going to avoid using Tango because it is not "the" 
standard library.
Feb 06 2008
next sibling parent reply Dan <murpsoft hotmail.com> writes:
Jesse Phillips Wrote:

 I agree that Tango isn't able to keep up with the rapid changes in D2 or 
 D3? But, in my opinion I don't think it has to in order to be called the 
 standard library. D2 has not been released, it has no obligation to 
 provide the same environment as D1.


Yes, but D1 is stable.  I have program Y that assumes Phobos is the standard
library.  As long as stable compilers are released when Phobos is the standard
library, those stable D versions will have to stay with Phobos.

If you guys want Tango to be the standard library, ship it with the dev
compiler.


The only ones that aren't looking at switching seem to be the 
 dead projects. 


I found that mildly offensive.  I use Phobos because it's more suited to my
needs [read: better for me].  The reasons I prefer Phobos are:

1) I know what it does
2) I understand it's conventions

The *only* reason I'd consider switching to tango is if the compiled algorithms
were *noticeably* faster, or tango offered some feature that I didn't want to
spend time figuring out how to implement myself.  I learn things for the
purpose of understanding how they work, but if the algorithm is more or less
the same, I don't care.

I don't like OO things.  They're opague.  I don't understand what they do
inside.

Regards,
Dan
Feb 06 2008
next sibling parent reply Sebastian Beschke <s.beschke gmx.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan schrieb:

 I don't like OO things.  They're opague.  I don't understand what they do
inside.


Which is pretty much the point of OO. Ideally, however, they'll be so
well documented that you'll understand how to use them. (Granted that's
not always true with Tango, but it's improving.)
It's a way to get complexity out of your head to allow you to
concentrate on your own project-specific complexities.

If you want to understand something in Tango, you can still read the
source code. I don't see how this affects a possible standard library
choice.

Regards
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHqtA6Kb/1n5A2TAMRAni+AKCA+3RzB1exHwi83AB2gXCq2V0bjwCfXtYy
wSnPiNjD/7rQBa4KoGk26Qw=
=K4SA
-----END PGP SIGNATURE-----
Feb 07 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sebastian Beschke:

 Which is pretty much the point of OO.


I agree, but the lesson here is probably that some people don't understand OO
well, or they don't want to use it everywhere, or it doesn't go well with their
mindset, or they need to go faster and they want to program in a more C-style,
etc. Java has OOP only, but D allows other kinds of programming too, so maybe
it may be better to not have a std lib that is fully OOP, so it can be used
when you program differently (like functional-style). Tango doesn't need to be
perfect for everyone, but probably there are ways to modify its structure
enough to make it look good enough for most people :-) I know very little about
Tango still, but I have seen there are lot of people that think some changes
may be in order before making it the D std lib :-)



 If you want to understand something in Tango, you can still read the source
code.


The source code of Phobos is a simpler read to me (it's a matter of style too,
I presume, not just of higher complexity coming from higher capabilities).

Bye,
bearophile
Feb 07 2008
next sibling parent Sean Kelly <sean f4.ca> writes:
bearophile wrote:

 Sebastian Beschke:

 Which is pretty much the point of OO.


 
 I agree, but the lesson here is probably that some people don't understand OO
well, or they don't want to use it everywhere, or it doesn't go well with their
mindset, or they need to go faster and they want to program in a more C-style,
etc. Java has OOP only, but D allows other kinds of programming too, so maybe
it may be better to not have a std lib that is fully OOP, so it can be used
when you program differently (like functional-style). Tango doesn't need to be
perfect for everyone, but probably there are ways to modify its structure
enough to make it look good enough for most people :-) I know very little about
Tango still, but I have seen there are lot of people that think some changes
may be in order before making it the D std lib :-)


I know I've said this before, but to me, the important thing is that a
library could be efficiently and easily applied to my needs.  And I
believe this has more to do with the assumptions the library makes than
whether it uses functions or objects.  For example, let's say that I
want to copy a file and I don't want any memory to be allocated in the
process nor do I want an exception thrown if a failure occurs, but
instead I want a return value to indicate the failure.  If the only
means provided for this by the library allocates a buffer to do so then
I'm sunk.  And if the routine or routines throw on failure then I have
to trap the exceptions, which means a loss of efficiency.

The Tango library was designed to make as few assumptions as possible
about intended use, and thus it is very modular.  It does have a fairly
considerable learning curve in some cases as a result, but in exchange,
I feel that it can be easily molded to the programmer's needs in many
more cases than would otherwise be possible.  Don't like objects?
Create wrapper functions to do the operations which require them.  Doing
so is trivial and it must only be done once.  In exchange, it is quite
likely that you won't be fighting the API because it made invalid
assumptions about how it should be used.


 If you want to understand something in Tango, you can still read the source
code.


 
 The source code of Phobos is a simpler read to me (it's a matter of style too,
I presume, not just of higher complexity coming from higher capabilities).


The source code of Tango is definitely more spread out, so you will
likely have to look at more files to sort out how to do something than
you would in Phobos.


Sean
Feb 07 2008
prev sibling parent reply Dan <murpsoft hotmail.com> writes:
bearophile Wrote:


 Sebastian Beschke:

 Which is pretty much the point of OO.




The point of OO is to not know what you're doing?  Maybe that's why I'm so
averse.


 
 I agree, but the lesson here is probably that some people don't understand OO
well, or they don't want to use it everywhere, or it doesn't go well with their
mindset, or they need to go faster and they want to program in a more C-style,
etc. 


It's the mindset, apparently.  I have no preference for syntax.  It's what's
inside that counts IMHO, and with OO you have no idea what's inside.


Java has OOP only, but D allows other kinds of programming too, so maybe it may
be better to not have a std lib that is fully OOP, so it can be used when you
program differently (like functional-style). Tango doesn't need to be perfect
for everyone, but probably there are ways to modify its structure enough to
make it look good enough for most people :-)


Agreed, but I'm continuing to use Phobos as long as it's better for me, and at
the moment it still is.


 I know very little about Tango still, but I have seen there are lot of people
that think some changes may be in order before making it the D std lib :-)
 

 If you want to understand something in Tango, you can still read the source
code.




Yes, if I want to understand anything in Tango, I need to study.  I already
understand Phobos because it's similar to what I already know.

You say that Tango presents better GC and IO?

I couldn't possibly allocate 16 consoles and iterate through them without an
undefined number of cache misses - because I can't control where they exist.

I couldn't possibly define classes and use copy-on-write semantics to expand
them during runtime; something that was key to my thinking in the Walnut 2.x
project.

I couldn't possibly be informed about the memory footprint of my program, or
understand how many mispredicted? branches are taken because of the possibly
painful multiple-constructor system.  I also cannot partially instantiate an
object if I only need part of it for some rare case.

I can keep going on the limitations of OO.

But essentially the point is that unless it's beautiful inside, I don't care
how convenient your notation is.  If the insides on which your library is built
is "don't look!" then I have trouble believing they're beautiful unless you
have a whole slew (like, hundreds) of benchmarks to show me.

Regards,
Dan
Feb 07 2008
next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 07 Feb 2008 19:06:23 -0500, Dan wrote:


 bearophile Wrote:
 

 Sebastian Beschke:

 Which is pretty much the point of OO.




 
 The point of OO is to not know what you're doing?  Maybe that's why I'm
 so averse.
 
 

 I agree, but the lesson here is probably that some people don't
 understand OO well, or they don't want to use it everywhere, or it
 doesn't go well with their mindset, or they need to go faster and they
 want to program in a more C-style, etc.


 
 It's the mindset, apparently.  I have no preference for syntax.  It's
 what's inside that counts IMHO, and with OO you have no idea what's
 inside.
 

Java has OOP only, but D allows other kinds of programming too, so maybe
it may be better to not have a std lib that is fully OOP, so it can be
used when you program differently (like functional-style). Tango doesn't
need to be perfect for everyone, but probably there are ways to modify
its structure enough to make it look good enough for most people :-)


 
 Agreed, but I'm continuing to use Phobos as long as it's better for me,
 and at the moment it still is.
 

 I know very little about Tango still, but I have seen there are lot of
 people that think some changes may be in order before making it the D
 std lib :-)
 

 If you want to understand something in Tango, you can still read the
 source code.




 
 Yes, if I want to understand anything in Tango, I need to study.  I
 already understand Phobos because it's similar to what I already know.
 
 You say that Tango presents better GC and IO?
 
 I couldn't possibly allocate 16 consoles and iterate through them
 without an undefined number of cache misses - because I can't control
 where they exist.
 
 I couldn't possibly define classes and use copy-on-write semantics to
 expand them during runtime; something that was key to my thinking in the
 Walnut 2.x project.
 
 I couldn't possibly be informed about the memory footprint of my
 program, or understand how many mispredicted? branches are taken because
 of the possibly painful multiple-constructor system.  I also cannot
 partially instantiate an object if I only need part of it for some rare
 case.
 
 I can keep going on the limitations of OO.
 
 But essentially the point is that unless it's beautiful inside, I don't
 care how convenient your notation is.  If the insides on which your
 library is built is "don't look!" then I have trouble believing they're
 beautiful unless you have a whole slew (like, hundreds) of benchmarks to
 show me.
 
 Regards,
 Dan


umm, you do realize that Tango is open source? You can look, and make it 
better. This is also true with Phobos though. When I call call a string 
function to std.string.split() how do I know how its beautiful inside? I 
can't it could be the worst splitting algorithm "random split." I would 
have to look at the code in the function, just like I would have to look 
at the code in a class.
Feb 07 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
I think you misunderstood the point of Sebastian and bearophile's posts. 
Structured programming, as I'm sure you know, is about interface over 
implementation. You read the documentation of a function, or class, or 
whatever, which can gauruntee [I spelled that so bad the spell checker 
isn't suggesting the correct one...] a specific interface (here are my 
preconditions and postconditions), because in the vast majority of cases 
you shouldn't care how it's implemented, as long as it works correctly 
and at a reasonable speed. It's not a "don't look" philosophy at all, 
it's a "you shouldn't have to look". That's Tango's philosophy, as well 
as Phobos's, as well as most APIs over the last 20 or so years AFAIK.

If you want to look at the implementation, both Tango and Phobos are 
open source, so go ahead. It's not more difficult or taboo to look at 
Tango's source than it is to do so at Phobos's.

Demanding hundreds of benchmarks is slightly unreasonable IMO; there are 
already some benchmarks (I doubt there will ever be hundreds) showing 
that Tango's IO is faster than Phobos's, and Phobos has adopted the 
Tango GC, so there must be something to that. However, from an 
implementation/algorithmic standpoint, it makes sense that Tango's IO 
model would be faster since it attempts to reduce allocation by 
extensive use of memory slicing.

Your points on memory allocation, in particular, seem founded on 
incorrect assumptions. Kris could tell you a lot better than I could 
(since I don't even use Tango often, let alone develop it), but much of 
the IO model is based on avoiding allocation and GC usage whenever 
possible. While Tango has a couple more explicit "new"s in there, Tango 
does significantly fewer implicit allocations of buffers. This also 
leads to better cache locality.

Finally, while you make many valid points as far as heap-allocated 
memory go, what exactly does that have to do with object-oriented 
programming? D supports stack-allocated classes, and many Phobos 
functions do heap allocation (mainly of dynamic arrays). If you're using 
either library, or really any libraries written for a language with 
built-in garbage collection, it's rather difficult to avoid heap usage 
at all. If that's what you're trying to do, you're probably going to 
have to re-implement much of the functionality yourself anyway.

While I agree that you should use whatever library you're more 
comfortable with and suits your style, I believe you might be 
misinformed about some of the issues you bring up, in particular the 
amount of memory allocations performed in Tango and Phobos, and Tango's 
design philosophy.

Dan wrote:

 bearophile Wrote:
 

 Sebastian Beschke:

 Which is pretty much the point of OO.




 
 The point of OO is to not know what you're doing?  Maybe that's why I'm so
averse.
 

 I agree, but the lesson here is probably that some people don't understand OO
well, or they don't want to use it everywhere, or it doesn't go well with their
mindset, or they need to go faster and they want to program in a more C-style,
etc. 


 
 It's the mindset, apparently.  I have no preference for syntax.  It's what's
inside that counts IMHO, and with OO you have no idea what's inside.
 

 Java has OOP only, but D allows other kinds of programming too, so maybe it
may be better to not have a std lib that is fully OOP, so it can be used when
you program differently (like functional-style). Tango doesn't need to be
perfect for everyone, but probably there are ways to modify its structure
enough to make it look good enough for most people :-)


 
 Agreed, but I'm continuing to use Phobos as long as it's better for me, and at
the moment it still is.
 

 I know very little about Tango still, but I have seen there are lot of people
that think some changes may be in order before making it the D std lib :-)


 If you want to understand something in Tango, you can still read the source
code.




 
 Yes, if I want to understand anything in Tango, I need to study.  I already
understand Phobos because it's similar to what I already know.
 
 You say that Tango presents better GC and IO?
 
 I couldn't possibly allocate 16 consoles and iterate through them without an
undefined number of cache misses - because I can't control where they exist.
 
 I couldn't possibly define classes and use copy-on-write semantics to expand
them during runtime; something that was key to my thinking in the Walnut 2.x
project.
 
 I couldn't possibly be informed about the memory footprint of my program, or
understand how many mispredicted? branches are taken because of the possibly
painful multiple-constructor system.  I also cannot partially instantiate an
object if I only need part of it for some rare case.
 
 I can keep going on the limitations of OO.
 
 But essentially the point is that unless it's beautiful inside, I don't care
how convenient your notation is.  If the insides on which your library is built
is "don't look!" then I have trouble believing they're beautiful unless you
have a whole slew (like, hundreds) of benchmarks to show me.
 
 Regards,
 Dan
Feb 07 2008
parent reply downs <default_357-line yahoo.de> writes:
Robert Fraser wrote:

 Demanding hundreds of benchmarks is slightly unreasonable IMO; there are
 already some benchmarks (I doubt there will ever be hundreds) showing
 that Tango's IO is faster than Phobos's, and Phobos has adopted the
 Tango GC


It has? Boy that would make me happy, but I wasn't aware of it.

Could you post a source, please?

 --downs
Feb 08 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
downs:

 It has? Boy that would make me happy, but I wasn't aware of it.
 Could you post a source, please?


Regarding this topic: recently I have added a "xio" module to my d libs, for
easy to use lazy I/O, it tries to avoid some bugs of the Phobos I/O (I have
found 3 bugs, one simple bug can be seen if you try readline on a 20 MB line,
it blows the stack) and to make it faster (in some common situations it's
almost 3 times faster than Phobos). I may have to test its speed (at reading
lines, for example) against Tango :-)

Bye,
bearophile
Feb 08 2008
prev sibling parent Sean Kelly <sean f4.ca> writes:
downs wrote:

 Robert Fraser wrote:

 Demanding hundreds of benchmarks is slightly unreasonable IMO; there are
 already some benchmarks (I doubt there will ever be hundreds) showing
 that Tango's IO is faster than Phobos's, and Phobos has adopted the
 Tango GC


 
 It has? Boy that would make me happy, but I wasn't aware of it.
 
 Could you post a source, please?


It hasn't, though the GC code Phobos 2.0 is structurally closer to
what's in Tango.  That was a deliberate effort made by Brad to
facilitate future merges.


Sean
Feb 08 2008
prev sibling next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Thu, 07 Feb 2008 07:42:42 +0200, Dan <murpsoft hotmail.com> wrote:


 I found that mildly offensive.  I use Phobos because it's more suited to my
needs [read: better for me].  


I disliked Tango in the past, but the reasons why I disliked it are now mostly
gone. It used to be quite buggy (the first time I used it I got the impression
that most of the code was never tested in real-life scenarios), the syntax was
too verbose (this was reduced by adding shortcuts like static opCall
constructors), and the necessity to use lots of import statements (for which
the tango.group package was added).


 1) I know what it does


I don't understand your point - do you mean, the quality of the documentation,
or the straight-forwardness of the source code? Sure, Tango code is more
organized, and you need to read more to see what something does for sure (until
you understand the general structure of the library), but I don't see a
striking (black vs white) difference otherwise.


 The *only* reason I'd consider switching to tango is if the compiled
algorithms were *noticeably* faster, or tango offered some feature that I
didn't want to spend time figuring out how to implement myself.  I learn things
for the purpose of understanding how they work, but if the algorithm is more or
less the same, I don't care.


It's been shown numerous times in this newsgroup that some Tango components,
like IO and the garbage collector, perform significantly better than the Phobos
implementations. This is quite a reason in itself unless performance is a
non-issue (why are you using D and not some scripting language anyway, then? :)
)

That said, for my last project I've decided to use a mixture of Tango and
Tangobos. Tango is missing some Phobos features like Windows registry access
and std.dateparse (which allows heuristic parsing of an undefined date format),
as well as some minor design flaws (using the Tango library, it's impossible to
enumerate all incl. hidden files in a folder). Doing some things in Tango is
still not a pretty as with Phobos, for example enumeration of files in a
directory. I would have probably successfully completed that project using
Phobos alone, if it wasn't for that DDBI has practically dropped Phobos support.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow gmail.com
Feb 07 2008
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Dan wrote:

 
 I don't like OO things.  They're opague.  I don't understand what they do
inside.


Functions are opaque too, isn't that the point?


Sean
Feb 07 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Dan wrote:

 The *only* reason I'd consider switching to tango is if the compiled
algorithms were *noticeably* faster


IO _is_ noticeably faster in Tango. If I didn't need to learn ML over th 
next 23 hours, I'd slap together a couple tests.
Feb 07 2008
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 07 Feb 2008 00:42:42 -0500, Dan wrote:


 Jesse Phillips Wrote:

 I agree that Tango isn't able to keep up with the rapid changes in D2
 or D3? But, in my opinion I don't think it has to in order to be called
 the standard library. D2 has not been released, it has no obligation to
 provide the same environment as D1.


 
 Yes, but D1 is stable.  I have program Y that assumes Phobos is the
 standard library.  As long as stable compilers are released when Phobos
 is the standard library, those stable D versions will have to stay with
 Phobos.
 
 If you guys want Tango to be the standard library, ship it with the dev
 compiler.
 

The only ones that aren't looking at switching seem to be the
 dead projects.


 
 I found that mildly offensive.  I use Phobos because it's more suited to
 my needs [read: better for me].  The reasons I prefer Phobos are:
 
 1) I know what it does
 2) I understand it's conventions
 
 The *only* reason I'd consider switching to tango is if the compiled
 algorithms were *noticeably* faster, or tango offered some feature that
 I didn't want to spend time figuring out how to implement myself.  I
 learn things for the purpose of understanding how they work, but if the
 algorithm is more or less the same, I don't care.
 
 I don't like OO things.  They're opague.  I don't understand what they
 do inside.
 
 Regards,
 Dan


I'd like to give my own response to this. As I stated before I agree that 
D1 should remain the same. I don't see any reason not to place the Tango/
DMD download on the same page. And I said Tango should take over for D2.

I don't have a quarrel with your chosen style of coding, however it 
sounds as though your reasons are because you do not want to learn a new 
style. This is fine too, but it is not a reason to prevent the switch of 
a standard library. Besides, after having talked with Kris, I believe, he 
says that the object/function ratio of Phobos vs Tango is about the same.

Lastly I don't think you should be offended. I love the C feeling of 
Phobos, I still have yet to really use Tango (reading the book now) I've 
been around since '06. My statements where based on the trends I have 
observed. There are projects that are still developed under Phobos, but 
most of the highly active/highly used projects switch/support both.
Feb 07 2008
parent reply Dan <murpsoft hotmail.com> writes:
 I don't have a quarrel with your chosen style of coding, however it 
 sounds as though your reasons are because you do not want to learn a new 
 style.


Well, not unless it's a noticeable improvement inside.  Since I can't really
understand the algorithms at play, and they're both roughly the same "ratio of
classes to real code", I see no advantages to it; just wasted time learning a
new set of sequences of letters.


 This is fine too, but it is not a reason to prevent the switch of 
 a standard library. Besides, after having talked with Kris, I believe, he 
 says that the object/function ratio of Phobos vs Tango is about the same.


Prevent?  Why cause?


 
 Lastly I don't think you should be offended. I love the C feeling of 
 Phobos, I still have yet to really use Tango (reading the book now) 


I was mildly offended by someone saying that only "dead projects" use Phobos;
like "only cool kids consume our product".


I've 
 been around since '06. My statements where based on the trends I have 
 observed. There are projects that are still developed under Phobos, but 
 most of the highly active/highly used projects switch/support both.


Yeah, I tried once but ultimately realized I was creating two separate programs
from the same source to accomplish the exact same thing; and I found it
unneccessarily(sp?) complicating.

Well, if you guys do decide to switch, I'll live.  It's not like I can't learn
API's and languages.  I'm at something like 80ish and 37.

Regards,
Dan
Feb 07 2008
parent Alexander Panek <alexander.panek brainsware.org> writes:
Dan wrote:

 I don't have a quarrel with your chosen style of coding, however it 
 sounds as though your reasons are because you do not want to learn a new 
 style.


 
 Well, not unless it's a noticeable improvement inside.  Since I can't really
understand the algorithms at play, and they're both roughly the same "ratio of
classes to real code", I see no advantages to it; just wasted time learning a
new set of sequences of letters.
 

 This is fine too, but it is not a reason to prevent the switch of 
 a standard library. Besides, after having talked with Kris, I believe, he 
 says that the object/function ratio of Phobos vs Tango is about the same.


 
 Prevent?  Why cause?


Please read the initial post of that thread. (oh and the vast amount of 
other threads about that topic, too, maybe) Thank you. :P


 Lastly I don't think you should be offended. I love the C feeling of 
 Phobos, I still have yet to really use Tango (reading the book now) 


 
 I was mildly offended by someone saying that only "dead projects" use 
 Phobos; like "only cool kids consume our product".


It seems to me like most of the newer and still evolving projects seem 
to either support Tango or are based on Tango. Nothing to get offended 
by. Also, if that's not the case, Phobos projects must have some backlog 
demand in marketing strategies, eh? ;)
(Really no offense intended)


 I've 
 been around since '06. My statements where based on the trends I have 
 observed. There are projects that are still developed under Phobos, but 
 most of the highly active/highly used projects switch/support both.


 
 Yeah, I tried once but ultimately realized I was creating two separate 
 programs from the same source to accomplish the exact same thing; and I
 found it unneccessarily(sp?) complicating.


What kind of program was that, if I may ask?

Kind regards,
Alex
Feb 07 2008
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-02-06 23:10:46 -0500, Jesse Phillips <jessekphillips gmail.com> said:


 The only ones that aren't looking at switching seem to be the
 dead projects. This to me is a big indicator that Tango should take the
 stand. People are going to avoid using Tango because it is not "the"
 standard library.


I haven't used Tango that much, but each time I look at it it takes 
much more time to find what I need than with Phobos. With Phobos, I 
generally open the std folder, glance at the file, pick the one that 
looks like it has what I need, and find what I want in it (most of the 
time). In tango, this is much more difficult unless you are already 
familiar with the layout of the library.

Case in point: tango.stdc.stringz; why does that deserve its own 
module? There are so much tiny modules in Tango that I find it 
difficult to find what I want. Still tango.stdc.stringz, I wonder why 
the function to convert to a D string is called fromStringz... I can 
understand the function's name, but it just seem silly to not call it 
toString and take advantage of function overloading. In this case I 
find Phobos approach better: string functions are concentrated in one 
easy-to-find place. In Tango, you have tango.stdc.stringz, then you 
have tango.text.convert.<insert your type here>, then you have 
tango.text.Text, tango.text.Ascii, tango.text.Util and so on. Anyone 
can guess where the replace function is (within the last three) without 
looking in each module separately?

Answer: it's in tango.text.Util; tango.text.Text doesn't deal with D 
strings, it's the home of the Text class (with also has a replace 
function, although not the one I was searching for) and 
tango.text.Ascii holds (as one would expect) functions (only four!) 
relating to character case which are restricted to ASCII domain.

There are also a few stylistic things I don't like about tango: 
character case for abbreviations for instance (Ascii instead of ASCII?) 
and the uppercase module names.

Personally, I'd prefer to see Phobos kept as the standard library and 
improved technically to the level Tango is at now.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 07 2008
next sibling parent reply Tim Burrell <tim timburrell.net> writes:
Michel Fortin wrote:

 Personally, I'd prefer to see Phobos kept as the standard library and 
 improved technically to the level Tango is at now.


The problem is, you can't keep Phobos and have it improved technically.
 It's just not going to happen, that's the whole reason this thread was
started!

Walter isn't doing his job when it comes to maintaining Phobos, and he
isn't opening it up to the contributors who are willing to help!

Also, there's _already_ an existing compatibility layer for Tango that
allows you to use the Phobos API with the quality of Tango.

I think we'd all prefer to see Phobos improved technically, but it's
just not happening.  And fact is, we have a dedicated team who have put
together a quality library, that has a full implementation of Phobos
built on top of it (which is also more efficient than Phobos).

That being said, most people do prefer the Tango API over Phobos, so if
the majority of the D community is saying "let's do this!", and given
that there's really no reason not to (ie people who like Phobos can
still use Phobos), AND given that Walter has proven he's not interested
in doing a proper job at maintaining Phobos, it just doesn't make sense
to keep it around.

Tim.
Feb 07 2008
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Tim Burrell wrote:

 I think we'd all prefer to see Phobos improved technically, but it's
 just not happening.  And fact is, we have a dedicated team who have put
 together a quality library, that has a full implementation of Phobos
 built on top of it (which is also more efficient than Phobos).


It's happening, but very slowly. And there are some things that have 
been a step in the wrong direction (std.boxer could handle large 
structs, I think, but std.variant can't handle anything larger than a 
delegate).

Meanwhile, Tango isn't making many mistakes, and it's been correcting 
those it made. And those that Phobos made.
Feb 08 2008
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Tim Burrell wrote:

 Michel Fortin wrote:

 Personally, I'd prefer to see Phobos kept as the standard library and 
 improved technically to the level Tango is at now.


 
 The problem is, you can't keep Phobos and have it improved technically.
  It's just not going to happen, that's the whole reason this thread was
 started!
 
 Walter isn't doing his job when it comes to maintaining Phobos, and he
 isn't opening it up to the contributors who are willing to help!


That isn't true. Phobos is now on dsource, and several of us have been given 
commit access to it. Unfortunately the procedure for commiting changes isn't 
quite clear yet.
I'm working on making the mathematics of Phobos and Tango compatible; hopefully 
we'll end up with a single code base.


 
 Also, there's _already_ an existing compatibility layer for Tango that
 allows you to use the Phobos API with the quality of Tango.
 
 I think we'd all prefer to see Phobos improved technically, but it's
 just not happening.  And fact is, we have a dedicated team who have put
 together a quality library, that has a full implementation of Phobos
 built on top of it (which is also more efficient than Phobos).
 
 That being said, most people do prefer the Tango API over Phobos, so if
 the majority of the D community is saying "let's do this!", and given
 that there's really no reason not to (ie people who like Phobos can
 still use Phobos), AND given that Walter has proven he's not interested
 in doing a proper job at maintaining Phobos, it just doesn't make sense
 to keep it around.
 
 Tim.
Feb 08 2008
parent reply Tim Burrell <tim timburrell.net> writes:
Don Clugston wrote:

 That isn't true. Phobos is now on dsource, and several of us have been given 
 commit access to it. Unfortunately the procedure for commiting changes isn't 
 quite clear yet.
 I'm working on making the mathematics of Phobos and Tango compatible;
hopefully 
 we'll end up with a single code base.


Wow that's great news!  Have you opened a discussion with the Tango devs
yet?  I'm sure they'd be receptive to providing input.
Feb 08 2008
next sibling parent reply jcc7 <technocrat7 gmail.com> writes:
== Quote from Tim Burrell (tim timburrell.net)'s article

 Don Clugston wrote:


...

 I'm working on making the mathematics of Phobos and Tango
 compatible; hopefully we'll end up with a single code base.


 Wow that's great news!  Have you opened a discussion with the Tango
 devs yet?  I'm sure they'd be receptive to providing input.


I was under the impression that Don was one of the Tango devs. ;)
http://www.dsource.org/projects/tango/wiki/Contributors
Feb 08 2008
parent reply Tim Burrell <tim timburrell.net> writes:
jcc7 wrote:

 == Quote from Tim Burrell (tim timburrell.net)'s article

 Don Clugston wrote:


 ...

 I'm working on making the mathematics of Phobos and Tango
 compatible; hopefully we'll end up with a single code base.


 Wow that's great news!  Have you opened a discussion with the Tango
 devs yet?  I'm sure they'd be receptive to providing input.


 
 I was under the impression that Don was one of the Tango devs. ;)
 http://www.dsource.org/projects/tango/wiki/Contributors


Oh... haha... well scratch that then :).

The idea of a single code base is pretty enticing to me.  I was just
trying to get a feel for how plausible it is that it might happen.
Feb 08 2008
next sibling parent Don Clugston <dac nospam.com.au> writes:
Tim Burrell wrote:

 jcc7 wrote:

 == Quote from Tim Burrell (tim timburrell.net)'s article

 Don Clugston wrote:


 ...

 I'm working on making the mathematics of Phobos and Tango
 compatible; hopefully we'll end up with a single code base.


 Wow that's great news!  Have you opened a discussion with the Tango
 devs yet?  I'm sure they'd be receptive to providing input.


 I was under the impression that Don was one of the Tango devs. ;)
 http://www.dsource.org/projects/tango/wiki/Contributors




Yeah, Don and I are in pretty close contact <g>.


 
 Oh... haha... well scratch that then :).
 
 The idea of a single code base is pretty enticing to me.  I was just
 trying to get a feel for how plausible it is that it might happen.


I'm doing my best to make sure it happens. With the I/O stuff, you're dealing 
with two almost completely independent code bases (as I understand it, the key 
difference is that Tango jettisons C style I/O in exchange for performance and 
various other benefits), but most of the other stuff is ultimately the same
code 
(there's a fair bit of Tango code which began life in Phobos).
After all, Phobos isn't really very big -- there's some stuff in there like 
std.openrj which is entirely peripheral.
Feb 08 2008
prev sibling parent Sean Kelly <sean f4.ca> writes:
Tim Burrell wrote:

 jcc7 wrote:

 == Quote from Tim Burrell (tim timburrell.net)'s article

 Don Clugston wrote:


 ...

 I'm working on making the mathematics of Phobos and Tango
 compatible; hopefully we'll end up with a single code base.


 Wow that's great news!  Have you opened a discussion with the Tango
 devs yet?  I'm sure they'd be receptive to providing input.


 I was under the impression that Don was one of the Tango devs. ;)
 http://www.dsource.org/projects/tango/wiki/Contributors


 
 Oh... haha... well scratch that then :).
 
 The idea of a single code base is pretty enticing to me.  I was just
 trying to get a feel for how plausible it is that it might happen.


That's pretty much Tango with Tangobos in a nutshell.  If things were to
flip in the other direction, then portions of tango.core would be an
issue because they are user-visible runtime features.  Maintenance of
this code would need to be addressed, as well as the location where it's
exposed.
 It's less of a problem to run Phobos on the Tango runtime (ie.
Tangobos) because essentially all of Phobos is runtime agnostic, and the
runtime features are exposed in a much more haphazard manner (which
actually makes it easier to safely ignore them).  For example, Phobos
contains a bunch of modules in std that is actually runtime code:
std.array, std.asserterror, std.outofmemory, etc.  The user is really
supposed to actually ignore all of these modules, so there's no reason
to expose them in Tangobos at all.

If you're interested, diff Tangobos with Phobos.  I think you'll find
that the only modules with any changes at all are std.thread and
std.signals.  The rest all works basically without any changes at all.
The opposite would not be true of Tango however, because of the
additional runtime features provided and the structured manner in which
they are exposed.


Sean
Feb 08 2008
prev sibling parent Sean Kelly <sean f4.ca> writes:
Tim Burrell wrote:

 Don Clugston wrote:

 That isn't true. Phobos is now on dsource, and several of us have been given 
 commit access to it. Unfortunately the procedure for commiting changes isn't 
 quite clear yet.
 I'm working on making the mathematics of Phobos and Tango compatible;
hopefully 
 we'll end up with a single code base.


 
 Wow that's great news!  Have you opened a discussion with the Tango devs
 yet?  I'm sure they'd be receptive to providing input.


For what it's worth, I have commit access to Phobos as well.  But As Don
said, the protocol for committing changes isn't entirely clear yet.  My
role with Phobos thus far has just been to approve various changes, and
that's likely how it will continue.  Tango consumes all of my free
coding time.


Sean
Feb 08 2008
prev sibling next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Thu, 07 Feb 2008 15:49:01 +0200, Michel Fortin <michel.fortin michelf.com>
wrote:


 Still tango.stdc.stringz, I wonder why the function to convert to a D string
is called fromStringz... I can understand the function's name, but it just seem
silly to not call it toString and take advantage of function overloading.


Try it. Function overloading across modules just doesn't work.
Even worse, if a function is declared private in one module, it will still
collide with another public function of the same name - I guess that's a
compiler bug.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow gmail.com
Feb 07 2008
prev sibling next sibling parent reply Alexander Panek <alexander.panek lomography.com> writes:
Michel Fortin wrote:

 I haven't used Tango that much, but each time I look at it it takes much 
 more time to find what I need than with Phobos. With Phobos, I generally 
 open the std folder, glance at the file, pick the one that looks like it 
 has what I need, and find what I want in it (most of the time). In 
 tango, this is much more difficult unless you are already familiar with 
 the layout of the library.


There is a book about D+Tango, and it's really a good reference. Apart 
from that, the online documentation is being worked on. It's not so easy 
to keep the documentation up-to-date by automated ddoc generation while 
putting it in a reasonable format right now. That's a lack that is 
known. If you have any ideas how to improve it, they are very welcome.


 Case in point: tango.stdc.stringz; why does that deserve its own module?


Because you just need that functions, sometimes, without anything else 
from tango.stdc .


 There are so much tiny modules in Tango that I find it difficult to find 
 what I want.


That's true. The tango.group packages try to address this. Have you 
looked at them yet? Maybe you can come up with something you'd need 
additionally?


 Still tango.stdc.stringz, I wonder why the function to 
 convert to a D string is called fromStringz... I can understand the 
 function's name, but it just seem silly to not call it toString and take 
 advantage of function overloading. In this case I find Phobos approach 
 better: string functions are concentrated in one easy-to-find place. 


It's not always ideal to have everything in one place. Contextual 
grouping (tango.group) in combination with selective modules is probably 
  better - besides actually /using/ D's namespace/module features.


 In
 Tango, you have tango.stdc.stringz, then you have 
 tango.text.convert.<insert your type here>, then you have 
 tango.text.Text, tango.text.Ascii, tango.text.Util and so on. Anyone can 
 guess where the replace function is (within the last three) without 
 looking in each module separately?
 
 Answer: it's in tango.text.Util; tango.text.Text doesn't deal with D 
 strings, it's the home of the Text class (with also has a replace 
 function, although not the one I was searching for) and tango.text.Ascii 
 holds (as one would expect) functions (only four!) relating to character 
 case which are restricted to ASCII domain.


Where would you put or expected it?


 There are also a few stylistic things I don't like about tango: 
 character case for abbreviations for instance (Ascii instead of ASCII?) 
 and the uppercase module names.


It's a one convention that was chosen in an early stage - one of many, 
where none fits everyone perfectly.
Feb 07 2008
parent reply ElfQT <elf_qt _deletethis_yahoo.com> writes:
Alexander Panek Wrote:


 Michel Fortin wrote:

 I haven't used Tango that much, but each time I look at it it takes much 
 more time to find what I need than with Phobos. With Phobos, I generally 
 open the std folder, glance at the file, pick the one that looks like it 
 has what I need, and find what I want in it (most of the time). In 
 tango, this is much more difficult unless you are already familiar with 
 the layout of the library.


 
 There is a book about D+Tango, and it's really a good reference. Apart 
 from that, the online documentation is being worked on. It's not so easy 
 to keep the documentation up-to-date by automated ddoc generation while 
 putting it in a reasonable format right now. That's a lack that is 
 known. If you have any ideas how to improve it, they are very welcome.
 

 Case in point: tango.stdc.stringz; why does that deserve its own module?


 
 Because you just need that functions, sometimes, without anything else 
 from tango.stdc .
 

 There are so much tiny modules in Tango that I find it difficult to find 
 what I want.


 
 That's true. The tango.group packages try to address this. Have you 
 looked at them yet? Maybe you can come up with something you'd need 
 additionally?
 

 Still tango.stdc.stringz, I wonder why the function to 
 convert to a D string is called fromStringz... I can understand the 
 function's name, but it just seem silly to not call it toString and take 
 advantage of function overloading. In this case I find Phobos approach 
 better: string functions are concentrated in one easy-to-find place. 


 
 It's not always ideal to have everything in one place. Contextual 
 grouping (tango.group) in combination with selective modules is probably 
   better - besides actually /using/ D's namespace/module features.
 
  > In

 Tango, you have tango.stdc.stringz, then you have 
 tango.text.convert.<insert your type here>, then you have 
 tango.text.Text, tango.text.Ascii, tango.text.Util and so on. Anyone can 
 guess where the replace function is (within the last three) without 
 looking in each module separately?
 
 Answer: it's in tango.text.Util; tango.text.Text doesn't deal with D 
 strings, it's the home of the Text class (with also has a replace 
 function, although not the one I was searching for) and tango.text.Ascii 
 holds (as one would expect) functions (only four!) relating to character 
 case which are restricted to ASCII domain.


 
 Where would you put or expected it?
 

 There are also a few stylistic things I don't like about tango: 
 character case for abbreviations for instance (Ascii instead of ASCII?) 
 and the uppercase module names.


 
 It's a one convention that was chosen in an early stage - one of many, 
 where none fits everyone perfectly.


These pains, module-code-separation and documentation can easily be eased with
intellisense/intellihelp in a decent IDE.
Need the code of a tango (or whatever) object or function?: right click on any
expression and select go to definition.
Need help on a tango (or whatever) object or function?: showing tooltip/dynapic
help generated from ddoc-comment in source as you type, or by pressing
ctrl-space (whatever), showing method, parameter, return info, including
overloads...

If this will be possible who will care about how many files contain string
functions?

ElfQT
Feb 07 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
ElfQT wrote:

 These pains, module-code-separation and documentation can easily be eased with
intellisense/intellihelp in a decent IDE.
 Need the code of a tango (or whatever) object or function?: right click on any
expression and select go to definition.
 Need help on a tango (or whatever) object or function?: showing
tooltip/dynapic help generated from ddoc-comment in source as you type, or by
pressing ctrl-space (whatever), showing method, parameter, return info,
including overloads...
 
 If this will be possible who will care about how many files contain string
functions?
 
 ElfQT


It's very possible; all the stuff you mentioned is in Descent. 
Control-click for go-to definition and hover over a function or type to 
see it's (formatted) Ddoc.
Feb 07 2008
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 07 Feb 2008 11:48:36 -0500, ElfQT wrote:


 
 These pains, module-code-separation and documentation can easily be
 eased with intellisense/intellihelp in a decent IDE. Need the code of a
 tango (or whatever) object or function?: right click on any expression
 and select go to definition. Need help on a tango (or whatever) object
 or function?: showing tooltip/dynapic help generated from ddoc-comment
 in source as you type, or by pressing ctrl-space (whatever), showing
 method, parameter, return info, including overloads...
 
 If this will be possible who will care about how many files contain
 string functions?
 
 ElfQT


I think the point was it is harder to find what you want in the 
documentation, not the finding what to import. ie a what do I need search 
versus a where is this search.
Feb 07 2008
prev sibling parent Jussi Jumppanen <jussij zeusedit.com> writes:
ElfQT Wrote:


 These pains, module-code-separation and documentation can easily be eased
 with intellisense/intellihelp in a decent IDE. Need the code of a tango
 (or whatever) object or function?: right click on any expression and
 select go to definition.

 Need help on a tango (or whatever) object or function?: showing
 tooltip/dynapic help generated from ddoc-comment in source as you type,
 or by pressing ctrl-space (whatever), showing method, parameter, return
 info, including overloads...

 If this will be possible who will care about how many files contain
 string functions?




FWIW the Zeus IDE can be easily configured to do exactly this:

  http://www.zeusedit.com/forum/viewtopic.php?p=2543
Feb 07 2008
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Michel Fortin wrote:

 
 Answer: it's in tango.text.Util; tango.text.Text doesn't deal with D
 strings, it's the home of the Text class (with also has a replace
 function, although not the one I was searching for) and tango.text.Ascii
 holds (as one would expect) functions (only four!) relating to character
 case which are restricted to ASCII domain.


tango.text.Text used to be tango.text.String but was changed when we
switched Object.toUtf8 to Object.toString, for obvious reasons.


Sean
Feb 07 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Michel Fortin wrote:

 Personally, I'd prefer to see Phobos kept as the standard library and 
 improved technically to the level Tango is at now.


Not to start another pointless style debate, but there's a particular 
reason the Java style guide (among others) suggests not capitalizing 
well-known abbreviations - it improves readability. After all, would you 
rather see XmlHttpRequest or XMLHTTPRequest?
Feb 07 2008
prev sibling next sibling parent reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Tim Burrell" <tim timburrell.net> wrote in message 
news:fochd0$30te$1 digitalmars.com...

 Hey all,

 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.

 Not to mention that it's confusing for new users to have to deal with
 two standard libraries.  I think it would be a really good thing for the
 language as a whole if there were only one standard library.

 My personal opinion is that Walter should let go of Phobos and adopt
 Tango as the official standard library.  I know there are people out
 there that prefer the Phobos API over Tango's, but I have a feeling that
 if Walter asked the Tango people to maintain the Tangobos base as the
 official standard library for D they would be okay with that.

 It would be a win-win situation for everyone, including Walter.  His
 time would get to be spent more on D itself, as he would likely only
 need to oversee the standard library in terms of input regarding the API
 and patchset accepts.

 The community would gain a huge win because there would only be one
 unified standard library.

 Phobos users would still be able to use the Phobos API but would gain
 the benefits of using an API that they feel they can contribute to, and
 that has a proven track record of being responsive to fixing bugs.
 They'd also gain the ability to use the odd Tango class when desired.

 And Tango users wouldn't have to deal with using a non-standard library
 as the basis for their app, plus the ability to use the odd bit of the
 Phobos API would be nice now and again as well.

 I really feel strongly that a move toward a single standard library is
 the right thing to do for D.  There's very few cons to such a move and a
 great many pros.

 Anyone else have any thoughts on the matter?


If we can get a systemm for accepting submitions to Phobos going, what if we 
made Tango a sort of expansion pack on top of it? I.E. Phobos addresses all 
the basic stuff, and Tango ditches all its standard library-ish code and 
becomes the "extended library" if you will. The way I see it the standard 
library should be fairly comprehensive without going in to actual nitches; 
that ought to be left to whatever expansion pack we put together. Thoughts?

It's good to be back by the way; getting settled at college can take a while 
with classes and the like.

 Tim.
Feb 07 2008
next sibling parent reply Tim Burrell <tim timburrell.net> writes:
Ameer Armaly wrote:

 If we can get a systemm for accepting submitions to Phobos going, what if we 
 made Tango a sort of expansion pack on top of it? I.E. Phobos addresses all 
 the basic stuff, and Tango ditches all its standard library-ish code and 
 becomes the "extended library" if you will. The way I see it the standard 
 library should be fairly comprehensive without going in to actual nitches; 
 that ought to be left to whatever expansion pack we put together. Thoughts?


Not a bad idea!  Personally I'd still like to see the Tango standard 
library stuff as the base -- IMO it's higher quality, and more complete.

That being said, what you suggested would be a great start, and could be 
enough to get Phobos where we need it to be.  Either way, a system for 
getting more people involved with Phobos development would be really good.

The thing is, this is a huge part of the problem right now -- Phobos is 
currently closed, and isn't being maintained.

My original proposition of adopting Tango as the standard library of 
choice was resting on the assumption that Walter isn't really all that 
interested in giving Phobos the attention it deserves (which is fine!). 
  If that's not true (also fine!), then what you suggest is definitely 
something I'd be okay with.

Unfortunately Walter hasn't weighed in on the subject, so it's hard to 
know what to believe.

Come on Walter, let's hear it!  Speak up!
Feb 07 2008
parent "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Tim Burrell" <tim timburrell.net> wrote in message 
news:fog54s$67a$1 digitalmars.com...

 Ameer Armaly wrote:

 If we can get a systemm for accepting submitions to Phobos going, what if 
 we made Tango a sort of expansion pack on top of it? I.E. Phobos 
 addresses all the basic stuff, and Tango ditches all its standard 
 library-ish code and becomes the "extended library" if you will. The way 
 I see it the standard library should be fairly comprehensive without 
 going in to actual nitches; that ought to be left to whatever expansion 
 pack we put together. Thoughts?


 Not a bad idea!  Personally I'd still like to see the Tango standard 
 library stuff as the base -- IMO it's higher quality, and more complete.

 That being said, what you suggested would be a great start, and could be 
 enough to get Phobos where we need it to be.  Either way, a system for 
 getting more people involved with Phobos development would be really good.

 The thing is, this is a huge part of the problem right now -- Phobos is 
 currently closed, and isn't being maintained.

 My original proposition of adopting Tango as the standard library of 
 choice was resting on the assumption that Walter isn't really all that 
 interested in giving Phobos the attention it deserves (which is fine!). If 
 that's not true (also fine!), then what you suggest is definitely 
 something I'd be okay with.

 Unfortunately Walter hasn't weighed in on the subject, so it's hard to 
 know what to believe.

 Come on Walter, let's hear it!  Speak up!


Definitely. Until Walter makes some kind of move we're mostly left to our 
own musings, though I guess we could all just radically break off if we were 
so desperate.
This definitely ought to be a topic at the next D conference; any musings on 
that so far?
Feb 07 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Ameer Armaly wrote:

 "Tim Burrell" <tim timburrell.net> wrote in message 
 news:fochd0$30te$1 digitalmars.com...

 Hey all,

 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.

 Not to mention that it's confusing for new users to have to deal with
 two standard libraries.  I think it would be a really good thing for the
 language as a whole if there were only one standard library.

 My personal opinion is that Walter should let go of Phobos and adopt
 Tango as the official standard library.  I know there are people out
 there that prefer the Phobos API over Tango's, but I have a feeling that
 if Walter asked the Tango people to maintain the Tangobos base as the
 official standard library for D they would be okay with that.

 It would be a win-win situation for everyone, including Walter.  His
 time would get to be spent more on D itself, as he would likely only
 need to oversee the standard library in terms of input regarding the API
 and patchset accepts.

 The community would gain a huge win because there would only be one
 unified standard library.

 Phobos users would still be able to use the Phobos API but would gain
 the benefits of using an API that they feel they can contribute to, and
 that has a proven track record of being responsive to fixing bugs.
 They'd also gain the ability to use the odd Tango class when desired.

 And Tango users wouldn't have to deal with using a non-standard library
 as the basis for their app, plus the ability to use the odd bit of the
 Phobos API would be nice now and again as well.

 I really feel strongly that a move toward a single standard library is
 the right thing to do for D.  There's very few cons to such a move and a
 great many pros.

 Anyone else have any thoughts on the matter?


 If we can get a systemm for accepting submitions to Phobos going, what if we 
 made Tango a sort of expansion pack on top of it? I.E. Phobos addresses all 
 the basic stuff, and Tango ditches all its standard library-ish code and 
 becomes the "extended library" if you will. The way I see it the standard 
 library should be fairly comprehensive without going in to actual nitches; 
 that ought to be left to whatever expansion pack we put together. Thoughts?
 
 It's good to be back by the way; getting settled at college can take a while 
 with classes and the like.

 Tim. 


 
 


Bad thought. Tango's IO model, in particular, is very different and IMO, 
much better/faster. On the other hand, the C feel of Phobos's IO is more 
comfortable for some people, and making that a bunch of wrapper 
functions is no better, since then you have two APIs for one thing.
Feb 07 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Ameer Armaly wrote:

 If we can get a systemm for accepting submitions to Phobos going, what if we 
 made Tango a sort of expansion pack on top of it? I.E. Phobos addresses all 
 the basic stuff, and Tango ditches all its standard library-ish code and 
 becomes the "extended library" if you will. The way I see it the standard 
 library should be fairly comprehensive without going in to actual nitches; 
 that ought to be left to whatever expansion pack we put together. Thoughts?


- Tango's low-level stuff is of higher quality than that of Phobos, 
everyone agrees.
- Most of the time, people are thinking mainly about string manipulation 
stuff and console IO. Tango's IO routines are much faster than those 
used in Phobos.

You want a Phobos-style wrapper around Tango. That's the best you could get.
Feb 07 2008
parent reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:fogrsg$1iri$1 digitalmars.com...

 Ameer Armaly wrote:

 If we can get a systemm for accepting submitions to Phobos going, what if 
 we made Tango a sort of expansion pack on top of it? I.E. Phobos 
 addresses all the basic stuff, and Tango ditches all its standard 
 library-ish code and becomes the "extended library" if you will. The way 
 I see it the standard library should be fairly comprehensive without 
 going in to actual nitches; that ought to be left to whatever expansion 
 pack we put together. Thoughts?


 - Tango's low-level stuff is of higher quality than that of Phobos, 
 everyone agrees.
 - Most of the time, people are thinking mainly about string manipulation 
 stuff and console IO. Tango's IO routines are much faster than those used 
 in Phobos.

 You want a Phobos-style wrapper around Tango. That's the best you could 
 get.


The point is not to divide the actual code as much as it is to divide the 
nitches. Take whatever the given library does best, and decide where it 
should go. If Tango does IO faster, then we should somehow merge that in to 
phobos. If certain parts of Phobos are too specialized, then they ought to 
go in to Tango. The specifics of course are left open to debate.
Feb 08 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Ameer Armaly wrote:

 The point is not to divide the actual code as much as it is to divide the 
 nitches. Take whatever the given library does best, and decide where it 
 should go. If Tango does IO faster, then we should somehow merge that in to 
 phobos. If certain parts of Phobos are too specialized, then they ought to 
 go in to Tango. The specifics of course are left open to debate. 


So you want Phobos to be a small standard library with Tango providing 
everything else that people will commonly use. I don't see the point in 
this, unless Tango starts suffering from its size.
Feb 09 2008
prev sibling next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 06 Feb 2008 10:49:17 -0400, Tim Burrell wrote:


 Hey all,
 
 It seems that even though Phobos is open source, it's difficult for
 people to contribute to.  Patch submissions aren't being accepted as
 readily as they should be, and bugs remain even months after having a
 fix submitted by users.
 
 Not to mention that it's confusing for new users to have to deal with
 two standard libraries.  I think it would be a really good thing for the
 language as a whole if there were only one standard library.
 
 My personal opinion is that Walter should let go of Phobos and adopt
 Tango as the official standard library.  I know there are people out
 there that prefer the Phobos API over Tango's, but I have a feeling that
 if Walter asked the Tango people to maintain the Tangobos base as the
 official standard library for D they would be okay with that.
 
 It would be a win-win situation for everyone, including Walter.  His
 time would get to be spent more on D itself, as he would likely only
 need to oversee the standard library in terms of input regarding the API
 and patchset accepts.
 
 The community would gain a huge win because there would only be one
 unified standard library.
 
 Phobos users would still be able to use the Phobos API but would gain
 the benefits of using an API that they feel they can contribute to, and
 that has a proven track record of being responsive to fixing bugs.
 They'd also gain the ability to use the odd Tango class when desired.
 
 And Tango users wouldn't have to deal with using a non-standard library
 as the basis for their app, plus the ability to use the odd bit of the
 Phobos API would be nice now and again as well.
 
 I really feel strongly that a move toward a single standard library is
 the right thing to do for D.  There's very few cons to such a move and a
 great many pros.
 
 Anyone else have any thoughts on the matter?
 
 Tim.


I would like to express why I think Walter is silent in the matter. The 
standard library would be a big change. This is to say there are a lot of 
people that stick with the library that comes with the compiler. A switch 
of the standard lib would cause a ripple effect that would disturb those 
that don't use Tango. While this is doable it is not something to hastily 
do.

It is quit possible that some time in the future Tangos momentum slows 
and Phobos surpasses as the mainly used library. We don't want to be 
switching back and forth as the community takes a liking to one or the 
other.

There are areas that Tango falls behind in and it would be best to have 
them addressed before such a switch. I think any action should wait for 
the release of D2, but I think the choice as to what will be expected to 
happen should be declared now.
Feb 07 2008
parent Tim Burrell <tim timburrell.net> writes:
Jesse Phillips wrote:

 I would like to express why I think Walter is silent in the matter. The 
 standard library would be a big change. This is to say there are a lot of 
 people that stick with the library that comes with the compiler. A switch 
 of the standard lib would cause a ripple effect that would disturb those 
 that don't use Tango. While this is doable it is not something to hastily 
 do.


You're right a lot of people do stick with the lib that comes with the 
compiler, and that's precisely why this issue is so important.  The fact 
that Phobos isn't being actively maintained is also likely to cause a 
ripple effect -- this is an issue, that if left undealt with, could be 
something that ends up making or breaking D as a mainstream language.

And, don't forget that even if a switch to Tango were to occur, it could 
be done so that it doesn't disturb users of the Phobos API!

Agreed though, that it's not something that should be done hastily, or 
without much consideration.  I have my opinion on the matter, but all I 
really want is to push the issue enough to ensure that Walter knows that 
a good majority of the community believes something needs to happen 
here, and that this is an issue that needs addressing.
Feb 07 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
There are currently several people working on Phobos, so it is far from 
abandoned. For example, last November saw a raft of major additions to it.

What I see as the goal for Phobos/Tango is for there to be a compatible 
core, so that users can mix/match what they need from either library.
Feb 08 2008
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 08 Feb 2008 00:17:38 -0800, Walter Bright wrote:


 There are currently several people working on Phobos, so it is far from 
 abandoned. For example, last November saw a raft of major additions to it.
 
 What I see as the goal for Phobos/Tango is for there to be a compatible 
 core, so that users can mix/match what they need from either library.


Excellent, and thank you.

What is the process for submitting changes now? 

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Feb 08 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:

 On Fri, 08 Feb 2008 00:17:38 -0800, Walter Bright wrote:
 

 There are currently several people working on Phobos, so it is far from 
 abandoned. For example, last November saw a raft of major additions to it.

 What I see as the goal for Phobos/Tango is for there to be a compatible 
 core, so that users can mix/match what they need from either library.


 
 Excellent, and thank you.
 
 What is the process for submitting changes now? 
 


The people currently who can commit changes are:

Walter Bright
Brad Roberts
Andrei Alexandrescu
Sean Kelley
Janice Caron
Don Clugston

Anyone else can propose changes by submitting the patches to bugzilla. 
However, the bar is pretty high for that; submissions must contain the 
following:

1) unittests that prove it works
2) ddoc style documentation (for new functionality)
3) documentation must include sample of use (for new functionality)

If the patches don't include these, please still submit them, but 
they'll tend to get lower priority because someone else has to complete 
them. So, generally, the more thorough the patch is, the speedier it 
will be to get it in.

Also, patches which require a license that is different from the one in 
the module being patched cannot be accepted.
Feb 08 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 The people currently who can commit changes are:
 
 Walter Bright
 Brad Roberts
 Andrei Alexandrescu
 Sean Kelley
 Janice Caron
 Don Clugston
 
 Anyone else can propose changes by submitting the patches to bugzilla. 
 However, the bar is pretty high for that; submissions must contain the 
 following:
 
 1) unittests that prove it works
 2) ddoc style documentation (for new functionality)
 3) documentation must include sample of use (for new functionality)
 
 If the patches don't include these, please still submit them, but 
 they'll tend to get lower priority because someone else has to complete 
 them. So, generally, the more thorough the patch is, the speedier it 
 will be to get it in.
 
 Also, patches which require a license that is different from the one in 
 the module being patched cannot be accepted.


I hope that issues containing incomplete patches or patches with a bad license
get a comment added to them explaining that they're being made lower priority
or are rejected outright.  That helps achieve two things: 1. People won't
complain as hard about incomplete patches not getting accepted in a timely
manner.  2. Those who are really interested in a particular patch will complete
it in order to speed up the acceptance process.
Feb 11 2008
parent downs <default_357-line yahoo.de> writes:
Jason House wrote:

 I hope that issues containing incomplete patches or patches with a bad license
get a comment added to them explaining that they're being made lower priority
or are rejected outright.  That helps achieve two things: 1. People won't
complain as hard about incomplete patches not getting accepted in a timely
manner.  2. Those who are really interested in a particular patch will complete
it in order to speed up the acceptance process.


Oh yes, please. I don't have any problem at all with patches I submit being
rejected for briefly explained reasons.

It's the silently ignoring part that annoys me. :)


 --downs
Feb 12 2008
prev sibling next sibling parent reply Tim Burrell <tim timburrell.net> writes:
Walter Bright wrote:

 There are currently several people working on Phobos, so it is far from 
 abandoned. For example, last November saw a raft of major additions to it.
 
 What I see as the goal for Phobos/Tango is for there to be a compatible 
 core, so that users can mix/match what they need from either library.


Thanks for your input on the matter!

I think that your response will be a bit disappointing to some, me
included.  It doesn't really address those of us who have gone on record
and stated that the current maintenance schedule of Phobos isn't sufficient.

Nor does it address the feeling many of us have of being unable to
contribute to Phobos.

If last November saw major additions, why have patches to know bugs that
were submitted prior to then remained ignored?

I think your idea on having a compatible core for Phobos and Tango is
great, but how do we get there?
Feb 08 2008
next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Tim Burrell wrote:

 Walter Bright wrote:

 There are currently several people working on Phobos, so it is far from 
 abandoned. For example, last November saw a raft of major additions to it.

 What I see as the goal for Phobos/Tango is for there to be a compatible 
 core, so that users can mix/match what they need from either library.


 
 Thanks for your input on the matter!
 
 I think that your response will be a bit disappointing to some, me
 included.  It doesn't really address those of us who have gone on record
 and stated that the current maintenance schedule of Phobos isn't sufficient.
 
 Nor does it address the feeling many of us have of being unable to
 contribute to Phobos.
 
 If last November saw major additions, why have patches to know bugs that
 were submitted prior to then remained ignored?
 
 I think your idea on having a compatible core for Phobos and Tango is
 great, but how do we get there?


I can only second that. Thank you for the comment, anyway!
Feb 08 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Tim Burrell wrote:

 I think that your response will be a bit disappointing to some, me
 included.  It doesn't really address those of us who have gone on record
 and stated that the current maintenance schedule of Phobos isn't sufficient.
 
 Nor does it address the feeling many of us have of being unable to
 contribute to Phobos.
 
 If last November saw major additions, why have patches to know bugs that
 were submitted prior to then remained ignored?
 
 I think your idea on having a compatible core for Phobos and Tango is
 great, but how do we get there?


These are all real issues, and need to be taken care of. I don't know 
what the answer is yet.
Feb 08 2008
prev sibling next sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Walter Bright wrote:


 There are currently several people working on Phobos, so it is far from
 abandoned. For example, last November saw a raft of major additions to it.
 
 What I see as the goal for Phobos/Tango is for there to be a compatible
 core, so that users can mix/match what they need from either library.


Personally, and I think there are many who think like me, a big issue is
that there is no standard API with that solution. There is a unified core
API but the modules on top of it providing higher level functionality won't
be as "standard". This of course does not apply if both phobos and tango is
shipped with the compiler in one package, that would yield a standard that
programmers can rely on beeing pressent on the system the software will be
used on.
Feb 08 2008
prev sibling next sibling parent "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:foh36t$2519$1 digitalmars.com...

 There are currently several people working on Phobos, so it is far from 
 abandoned. For example, last November saw a raft of major additions to it.

 What I see as the goal for Phobos/Tango is for there to be a compatible 
 core, so that users can mix/match what they need from either library.


Could you possibly elaborate on this point? Do you mean for Tango to become 
an extension lib like I proposed earlier,  for there to be some sort of 
shared codebase from which the two branch, or possibly sommething totally 
different I have yet to think about?
Feb 08 2008
prev sibling parent kris <foo bar.com> writes:
Walter Bright Wrote:


 There are currently several people working on Phobos, so it is far from 
 abandoned. For example, last November saw a raft of major additions to it.
 
 What I see as the goal for Phobos/Tango is for there to be a compatible 
 core, so that users can mix/match what they need from either library.



For those who currently use the Tango/Tangobos package, the above may be
causing some confusion. I believe Walter is describing a scenario whereby both
the phobos and Tango API operate atop a common 'runtime' library (the core).
This is what the Tango + Tangobos combination already provides, hence the
potential for confusion.

The distinction, I understand, is that the common core runtime would live
within phobos, rather than reside within Tango as it does today. In short, it
is the same functionality as what you get with Tangobos/Tango, but with the
packaging of the host runtime flipped around. 

At least, this reflects my understanding. Hope it helps to clarify things

- Kris
Feb 08 2008
prev sibling next sibling parent reply Dan <murpsoft hotmail.com> writes:
bearophile Wrote:


 dominik:

 walter did AWHILE ago Bigint implementation 
 for zortech I believe, wouldn't it be nice to make it a part of D, not 
 library per se? Be ti simple BCD implementation, I don't care, but I care 
 for BigInt.


 
 I'd like to have such bignum lib in the std lib. If someone here knows of a
*working* bignum lib, please tell me, because I have tried many but none works.
 
 Muti precision integral values are very useful, not for crypto purposes as
some say, but because they don't overflow, so you can use them without caring
of that *large* class of bugs (a certain percentage, like 10-30%, of all bugs
comes from integral type overflows/underflows). Reducing that cognitive burden
has the side effect of speeding up coding a bit too, because you can focus your
minds on other things.
 Experience shows that on modern CPUs a certain (often large) percentage of the
code doesn't need to be optimized a lot (this is why scripting languages are so
used today), while you can use fixnums in the speed critical sections of the
code.
 Said that, the DMD can grow smarter: it can infer some of the situations where
a bigint doesn't actually needs to be a bigint (silly example: for(bigint i =0;
i < 100; n++) {}) and it can replace them with fixnums :-) This can probably
speed up the code enough, so people will use them in a more relaxed way, and
this will reduce bug count even more :-) I don't know how much easy such bound
inferring is, and how much it can slow down the compiler.
 
 Bye,
 bearophile


And at the same time, I like this idea.  Though, I'd imagine unless you're
trying to calculate pi to the centillionth decimal place there's not really
much need for more than say, 256 bits.  But I'm sure that was once said about
32 bit numbers.

Regards,
Dan
Feb 08 2008
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Dan wrote:

 bearophile Wrote:
 

 dominik:

 walter did AWHILE ago Bigint implementation 
 for zortech I believe, wouldn't it be nice to make it a part of D, not 
 library per se? Be ti simple BCD implementation, I don't care, but I care 
 for BigInt.


 I'd like to have such bignum lib in the std lib. If someone here knows of a
*working* bignum lib, please tell me, because I have tried many but none works.

 Muti precision integral values are very useful, not for crypto purposes as
some say, but because they don't overflow, so you can use them without caring
of that *large* class of bugs (a certain percentage, like 10-30%, of all bugs
comes from integral type overflows/underflows). Reducing that cognitive burden
has the side effect of speeding up coding a bit too, because you can focus your
minds on other things.
 Experience shows that on modern CPUs a certain (often large) percentage of the
code doesn't need to be optimized a lot (this is why scripting languages are so
used today), while you can use fixnums in the speed critical sections of the
code.
 Said that, the DMD can grow smarter: it can infer some of the situations where
a bigint doesn't actually needs to be a bigint (silly example: for(bigint i =0;
i < 100; n++) {}) and it can replace them with fixnums :-) This can probably
speed up the code enough, so people will use them in a more relaxed way, and
this will reduce bug count even more :-) I don't know how much easy such bound
inferring is, and how much it can slow down the compiler.

 Bye,
 bearophile


 
 And at the same time, I like this idea.  Though, I'd imagine unless you're
trying to calculate pi to the centillionth decimal place there's not really
much need for more than say, 256 bits.  But I'm sure that was once said about
32 bit numbers.


In scientific computing, it's probably useful. In most ordinary 
scenarios, you aren't dealing with anything that 64 bits can't handle. 
With most graphics, you're going for speed rather than accuracy, but 
with things like Pixar, you might want large floating point numbers for 
additional accuracy.


 Regards,
 Dan
Feb 08 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 08/02/2008, Dan <murpsoft hotmail.com> wrote:

 And at the same time, I like this idea.  Though, I'd imagine unless you're
trying to calculate pi to the centillionth decimal place


He said integers. Pi is not an integer.
Feb 08 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:

 On 08/02/2008, Dan <murpsoft hotmail.com> wrote:

 And at the same time, I like this idea.  Though, I'd imagine unless you're
trying to calculate pi to the centillionth decimal place


 
 He said integers. Pi is not an integer.


Look up how people compute pi to large numbers of significant figures. 
Hint: they don't use floating point.

--bb
Feb 08 2008
prev sibling parent reply Sjoerd van Leent <svanleent gmail.com> writes:
Walter Bright Wrote:


 What I see as the goal for Phobos/Tango is for there to be a compatible 
 core, so that users can mix/match what they need from either library.


To be frank, I don't see the problem in having two standard libraries. However,
their purpose can be quite different.

The Phobos library to me appears to be minimalist and ideal for those who need
a small runtime library, such as example drivers, embedded systems, thin
clients, etc.

The Tango library on the other hand appears to be much more of a library for
bigger applications, and provides a lot of practical functionality which todays
applications need, such as webservers, database I/O, etc.

This is a logical outcome, because D although being a system language, can be
used in places where VM'd languages are used at the moment but also can be used
for those C applications we need to have the machine going in the first place.

Regards,
Sjoerd
Feb 12 2008
next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Sjoerd van Leent wrote:

 To be frank, I don't see the problem in having two standard libraries.
However, their purpose can be quite different.


To be frank, I don't see how the purpose is different. :)


 The Phobos library to me appears to be minimalist and ideal for those who need
a small runtime library, such as example drivers, embedded systems, thin
clients, etc.


This is not entirely true. The Tango core is very well decoupled from 
the rest of the library, rendering it very useful for exactly those things.


 The Tango library on the other hand appears to be much more of a library for
bigger applications, and provides a lot of practical functionality which todays
applications need, such as webservers, database I/O, etc.


Tango only provides the tools to create such applications. It does not, 
however, include a web server or database bindings/mappers. That's a 
seperate project called DDBI on DSource (http://dsource.org/projects/ddbi/).
Feb 12 2008
parent Kris <foo bar.com> writes:
Alexander Panek Wrote:


 Sjoerd van Leent wrote:

 To be frank, I don't see the problem in having two standard libraries.
However, their purpose can be quite different.


 
 To be frank, I don't see how the purpose is different. :)
 

 The Phobos library to me appears to be minimalist and ideal for those who need
a small runtime library, such as example drivers, embedded systems, thin
clients, etc.


 
 This is not entirely true. The Tango core is very well decoupled from 
 the rest of the library, rendering it very useful for exactly those things.
 

 The Tango library on the other hand appears to be much more of a library for
bigger applications, and provides a lot of practical functionality which todays
applications need, such as webservers, database I/O, etc.


 
 Tango only provides the tools to create such applications. It does not, 
 however, include a web server or database bindings/mappers. That's a 
 seperate project called DDBI on DSource (http://dsource.org/projects/ddbi/).



aye ... and those webserver packages (along with various other server-related
services) reside in the Mango project on dsource. They're built upon Tango, but
not shipped as part of it.
Feb 13 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sjoerd van Leent wrote:

 Walter Bright Wrote:
 

 What I see as the goal for Phobos/Tango is for there to be a compatible 
 core, so that users can mix/match what they need from either library.


 
 To be frank, I don't see the problem in having two standard libraries.
However, their purpose can be quite different.
 
 The Phobos library to me appears to be minimalist and ideal for those who need
a small runtime library, such as example drivers, embedded systems, thin
clients, etc.
 
 The Tango library on the other hand appears to be much more of a library for
bigger applications, and provides a lot of practical functionality which todays
applications need, such as webservers, database I/O, etc.
 
 This is a logical outcome, because D although being a system language, can be
used in places where VM'd languages are used at the moment but also can be used
for those C applications we need to have the machine going in the first place.
 
 Regards,
 Sjoerd


People seem to forget that C++ really has multiple "standard" libraries 
too: the one inherited from C, the C++ native one (STL/iostreams), and 
then Boost.  Then on top of that just about every single GUI toolkit has 
its own set of utility classes because first off templates were 
extremely unreliably when most of the GUI projects were started, and 
second the official standard libraries try so damned hard to be 
platform-neutral that they are often not that useful for getting real 
work done.

So I agree.  There's absolutely no problem with multiple "standard" 
libraries.  People will use what suits them, and the chances of one 
library pleasing everyone are slim in a multi-paradigm language like D.

The main difference in the D situation is that all those various C++ 
libraries can be linked together and used in the same app without 
requiring modification of your compiler's installation.

--bb
Feb 12 2008
next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Wed, 13 Feb 2008 00:44:56 +0900, Bill Baxter wrote:


 Sjoerd van Leent wrote:

 Walter Bright Wrote:
 

 What I see as the goal for Phobos/Tango is for there to be a
 compatible core, so that users can mix/match what they need from
 either library.






I absolutely agree. I see this as a very high priority.


 
 To be frank, I don't see the problem in having two standard libraries.
 However, their purpose can be quite different.
 
 The Phobos library to me appears to be minimalist and ideal for those
 who need a small runtime library, such as example drivers, embedded
 systems, thin clients, etc.
 
 The Tango library on the other hand appears to be much more of a
 library for bigger applications, and provides a lot of practical
 functionality which todays applications need, such as webservers,
 database I/O, etc.
 
 This is a logical outcome, because D although being a system language,
 can be used in places where VM'd languages are used at the moment but
 also can be used for those C applications we need to have the machine
 going in the first place.
 
 Regards,
 Sjoerd


 
 People seem to forget that C++ really has multiple "standard" libraries
 too: the one inherited from C, the C++ native one (STL/iostreams), and
 then Boost.  Then on top of that just about every single GUI toolkit has
 its own set of utility classes because first off templates were
 extremely unreliably when most of the GUI projects were started, and
 second the official standard libraries try so damned hard to be
 platform-neutral that they are often not that useful for getting real
 work done.
 
 So I agree.  There's absolutely no problem with multiple "standard"
 libraries.  People will use what suits them, and the chances of one
 library pleasing everyone are slim in a multi-paradigm language like D.
 
 The main difference in the D situation is that all those various C++
 libraries can be linked together and used in the same app without
 requiring modification of your compiler's installation.


That is indeed the problem, and it needs to be fixed urgently.


 
 --bb
Feb 12 2008
prev sibling parent Jarrod <qwerty ytre.wq> writes:
On Wed, 13 Feb 2008 00:44:56 +0900, Bill Baxter wrote:
 

 People seem to forget that C++ really has multiple "standard" libraries
 too: the one inherited from C, the C++ native one (STL/iostreams), and
 then Boost.  Then on top of that just about every single GUI toolkit has
 its own set of utility classes because first off templates were
 extremely unreliably when most of the GUI projects were started, and
 second the official standard libraries try so damned hard to be
 platform-neutral that they are often not that useful for getting real
 work done.
 
 So I agree.  There's absolutely no problem with multiple "standard"
 libraries.  People will use what suits them, and the chances of one
 library pleasing everyone are slim in a multi-paradigm language like D.
 
 The main difference in the D situation is that all those various C++
 libraries can be linked together and used in the same app without
 requiring modification of your compiler's installation.
 
 --bb


You are correct that C++ has multiple standard libraries, but you neglect 
the key point: They all work together, and for the most part they offer 
complimentary rather than competitive functions (ignoring of course the C 
and C++ standard libs which clearly do clash but for a valid reason)
Furthermore, the overall compilation result of C++ code -does- depend on 
a single specific 'standard' runtime library for entry point/exit 
handling and several other things like signal/exception handling and what 
have you.
Boost also does not replace nor prevent the use of the STL/std, and does 
not offer a lot of functionality provided by the stock standard libraries 
(I'm pretty sure boost does not provide POSIX or system API). I would 
call boost more of a heavily packed utility library.

On the other hand, in the case of Tango and Phobos you have to replace 
one of them to use the other, and their API compete with one another to 
the point of complete redundancy. This is a big difference compared to 
the C++ situation.
Feb 15 2008