www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Merging Tangobos into Tango

reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
It seams the Phobos 1.0 vs Tango 1.0 isn't going to be fixed and we'll 
have to wait for D 2 for a solution for this problem.

Would the Tango developers consider merging Tangobos into current Tango 
in order to have a standard solution to the problem? (instead of one 
that's marked as temporary).

Thanks
Oct 09 2007
parent reply "Kris" <foo bar.com> writes:
 Would the Tango developers consider merging Tangobos into current Tango in 
 order to have a standard solution to the problem?


Merging Tangobos into Tango would appear to make only a minor difference 
when one can simply downloading Tangobos instead? So it's not clear what 
real benefit that would bring? However, it tends to imply the Tango folks 
would have to maintain that relationship "long-term" ... we already have 
more than enough on our plate as it is :)

This does raise two items of interest: what does that "maintain" word mean 
with regard to Tango, and what does a PhanTango 'merger' actually mean to 
people ...

1.
------
We're always open to new and interesting functionality in Tango, but what's 
needed more than that is a commitment from the contributing author to 
potentially maintain that contribution (at least in the short term).

In addition, the dsource project tango.scrapple is becoming populated with 
all kinds of Tango related goodies, so that's an alternate home for 
compatible code. This is a like a sort of holding-tank for code that could 
make it into the library proper, but is being tried on first, by the 
community, to see if it fits. Still, that code needs to be maintained also 
(as/if needed).

Speaking of which, the owners of these packages obviously do maintain them: 
http://dsource.org/projects/tango/wiki/TangoUsers

In short, a key aspect of the Tango and related functionality is an implicit 
"commitment to maintain".  This has not been an issue for library 
contributions made thus far, however, the whole 'commitment' aspect is quite 
relevant to the topic at hand: e.g. Tangobos


2.
------ 
What it is that people *really* want out of the compatibility effort? To my 
knowledge nobody from the NG has articulated that yet, though the assertion 
has thus far been "the runtime, and object.d". The latter would provide 
compatibility for 'toString' and the GC, but there's a slew of other items 
to consider.

We had expected to try and make the Exception hierarchy of Tango support the 
(much smaller) set of phobos exceptions, for a start. But what about 
Threads? Tango threading is quite different in both extent and 
implementation, and also supports Fibers. Taking all those into 
consideration (which we have) would provide a rudimentary level of 
compatibility, somewhat similar to Tangobos. Then there's the import-path to 
consider, which is quite different between Tango and Phobos.

Moving along  we could consider high-impact items such as I/O. Yet, such 
things are much more difficult to make compatible ... are those the kind of 
things people expect also?

So perhaps the big question here is this: how, and to what depth, do people 
wish for a level of compatibility?  For example, how much value is there if 
this code is portable:







but this code is not:










and this code is not:








You might feel these are trivial differences and, indeed, those examples are 
deliberately chosen as superficially similar. As you might imagine, it 
becomes progressively harder to mask such differences the deeper one digs. 
Some have suggested essentially 'mounting' the Phobos API on top of the 
Tango model. That would work fine for almost everything but, again, it's a 
question of manpower and a long-term maintenance commitment (if someone is 
willing to take that on then, please, do stand up)


Comments?
Oct 09 2007
parent reply BCS <ao pathlink.com> writes:
Reply to kris,


 What it is that people *really* want out of the compatibility effort?


I like the idea of having piles of cool functionality in Tango, but sometime 
I just want a free function that have a four line description than I can 
understand without having to think about it. What I would love to see is 
to have a tango.lite that have most of the more common (non-broken) parts 
of phobos in it. And I'm talking edit a pile of import names and your working 
compatibility.

Anyway, that's my 1.5 cents (25% discount for low quality thinking)
Oct 09 2007
next sibling parent "Kris" <foo bar.com> writes:
Reply to BCS:

FWIW, free-function style is already in the works


"BCS" <ao pathlink.com> wrote in message 
news:ce0a33432466c8c9d8d41a82e95e news.digitalmars.com...

 Reply to kris,


 What it is that people *really* want out of the compatibility effort?


 I like the idea of having piles of cool functionality in Tango, but 
 sometime I just want a free function that have a four line description 
 than I can understand without having to think about it. What I would love 
 to see is to have a tango.lite that have most of the more common 
 (non-broken) parts of phobos in it. And I'm talking edit a pile of import 
 names and your working compatibility.

 Anyway, that's my 1.5 cents (25% discount for low quality thinking)
Oct 09 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
BCS wrote:

 Reply to kris,
 

 What it is that people *really* want out of the compatibility effort?


 
 I like the idea of having piles of cool functionality in Tango, but 
 sometime I just want a free function that have a four line description 
 than I can understand without having to think about it. What I would 
 love to see is to have a tango.lite that have most of the more common 
 (non-broken) parts of phobos in it.


Seems to me, that there are actually TWO phobos-es (phobi ?).
There's "core phobos", (std.file, etc) which has the basic i/o.
There's also "complete phobos" which includes some disorganised stuff which has 
far more limited appeal (std.openrj, std.base64, std.uri, etc).
Seems to me that when people talk about phobos-vs-tango, it's core phobos which 
has the biggest appeal, and the extended phobos which is most disliked.
Could phobos be trimmed down to this core set?
(Make the extended phobos be available as a separate download, or at least 
clearly distinguished?)
Oct 09 2007
next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Don Clugston wrote:

 Seems to me, that there are actually TWO phobos-es (phobi ?).
 There's "core phobos", (std.file, etc) which has the basic i/o.
 There's also "complete phobos" which includes some disorganised stuff 
 which has far more limited appeal (std.openrj, std.base64, std.uri, etc).
 Seems to me that when people talk about phobos-vs-tango, it's core 
 phobos which has the biggest appeal, and the extended phobos which is 
 most disliked.
 Could phobos be trimmed down to this core set?
 (Make the extended phobos be available as a separate download, or at 
 least clearly distinguished?)


I like that idea. This way a compatibility between Tango and the Phobos 
core would be easier to achieve, I suppose. Higher level stuff (like you 
said: std.openrj, std.base64, etc.) could as well be based on a 
compatibility layer that defines a standard interface for Threads, I/O & 
co that applies for both, Phobos' core and Tango's core.

This could even open the possibility for other runtime libraries (on top 
of that layer) or runtime library replacements (GC, Threads, .. like 
Tango now) without losing compatibility.
Oct 10 2007
prev sibling parent reply Aarti_pl <aarti interia.pl> writes:
Don Clugston pisze:

 Seems to me, that there are actually TWO phobos-es (phobi ?).
 There's "core phobos", (std.file, etc) which has the basic i/o.
 There's also "complete phobos" which includes some disorganised stuff 
 which has far more limited appeal (std.openrj, std.base64, std.uri, etc).
 Seems to me that when people talk about phobos-vs-tango, it's core 
 phobos which has the biggest appeal, and the extended phobos which is 
 most disliked.
 Could phobos be trimmed down to this core set?
 (Make the extended phobos be available as a separate download, or at 
 least clearly distinguished?)



I was thinking about something similar also...

Having in mind that there will be (unfortunately long) process of 
allowing Phobos & Tango coexist together I was thinking about 
positioning both libraries in a D landscape.

---

As I see there is demand among people for two kind of libraries:

- library for lower level stuff, which should be fast, simple, small, 
easy to learn and use. Possible applications: embedded devices, quick 
hacks, scripting, game's engines, kernel programming etc.

- library for higher level stuff, which gives flexibility, encapsulation 
and easy way to work in big teams. Possible applications: desktop 
programs, advanced networking, distributed computing etc.

---

That said, I see good place for both libraries here Phobos and Tango:
- Phobos should do lower level stuff. Functionalities in Phobos which 
belongs to second group should be dropped from it.
- Tango should do higher level stuff. Functionalities in Tango which 
belongs to first group should be dropped from it.

There will be also probably few areas where functionality will be 
duplicated (e.g. writef() vc. Cout()), but I don't think it will be a 
problem for anyone.

---

In such a scenario Tango could be also delivered packaged with compiler, 
but it would be not necessary to use it for writing simple applications 
(no code in Phobos calls Tango). When someone needs higher level 
functionality she can use Tango. When using Tango, probably Phobos will 
be necessary also (Tango libraries can call Phobos).

To sum up:
1. Runtime (from Tango) - one library
2. Lower level stuff Phobos - second library
3. Higher level stuff Tango - third library

Everything mentioned above packed with compiler in easily installable 
packages for Windows/Linux/MacOs. :-)

Best Regards
Marcin Kuszczak
(aarti_pl - www.zapytajmnie.com)
Oct 10 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Aarti_pl wrote:


 Don Clugston pisze:

 Seems to me, that there are actually TWO phobos-es (phobi ?).
 There's "core phobos", (std.file, etc) which has the basic i/o.
 There's also "complete phobos" which includes some disorganised stuff
 which has far more limited appeal (std.openrj, std.base64, std.uri, etc).
 Seems to me that when people talk about phobos-vs-tango, it's core
 phobos which has the biggest appeal, and the extended phobos which is
 most disliked.
 Could phobos be trimmed down to this core set?
 (Make the extended phobos be available as a separate download, or at
 least clearly distinguished?)


 
 
 I was thinking about something similar also...
 
 Having in mind that there will be (unfortunately long) process of
 allowing Phobos & Tango coexist together I was thinking about
 positioning both libraries in a D landscape.
 
 ---
 
 As I see there is demand among people for two kind of libraries:
 
 - library for lower level stuff, which should be fast, simple, small,
 easy to learn and use. Possible applications: embedded devices, quick
 hacks, scripting, game's engines, kernel programming etc.
 
 - library for higher level stuff, which gives flexibility, encapsulation
 and easy way to work in big teams. Possible applications: desktop
 programs, advanced networking, distributed computing etc.


I highly disagree with the notion that there is any kind of sharp
distinction between those two groups.


 
 ---
 
 That said, I see good place for both libraries here Phobos and Tango:
 - Phobos should do lower level stuff. Functionalities in Phobos which
 belongs to second group should be dropped from it.
 - Tango should do higher level stuff. Functionalities in Tango which
 belongs to first group should be dropped from it.


If both Phobos and Tango is part of the standard library, it would make
sense to clean out duplicate functionality, but regarding what is there
today, I would still use the "low-level" functionality of Tango, not
Phobos. Biased, yes, but for a reason.


 ---
 
 In such a scenario Tango could be also delivered packaged with compiler,
 but it would be not necessary to use it for writing simple applications
 (no code in Phobos calls Tango). When someone needs higher level
 functionality she can use Tango. When using Tango, probably Phobos will
 be necessary also (Tango libraries can call Phobos).
 
 To sum up:
 1. Runtime (from Tango) - one library
 2. Lower level stuff Phobos - second library
 3. Higher level stuff Tango - third library
 
 Everything mentioned above packed with compiler in easily installable
 packages for Windows/Linux/MacOs. :-)


If you do a s/Phobos/Tango on your 3 points above, you have correctly
summarized Tango :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 10 2007
parent reply Aarti_pl <aarti interia.pl> writes:
Lars Ivar Igesund pisze:

 Aarti_pl wrote:
 

 Having in mind that there will be (unfortunately long) process of
 allowing Phobos & Tango coexist together I was thinking about
 positioning both libraries in a D landscape.

 ---

 As I see there is demand among people for two kind of libraries:

 - library for lower level stuff, which should be fast, simple, small,
 easy to learn and use. Possible applications: embedded devices, quick
 hacks, scripting, game's engines, kernel programming etc.

 - library for higher level stuff, which gives flexibility, encapsulation
 and easy way to work in big teams. Possible applications: desktop
 programs, advanced networking, distributed computing etc.


 
 I highly disagree with the notion that there is any kind of sharp
 distinction between those two groups.
 


True. I didn't say that there is sharp distinction. :-)



 That said, I see good place for both libraries here Phobos and Tango:
 - Phobos should do lower level stuff. Functionalities in Phobos which
 belongs to second group should be dropped from it.
 - Tango should do higher level stuff. Functionalities in Tango which
 belongs to first group should be dropped from it.


 
 If both Phobos and Tango is part of the standard library, it would make
 sense to clean out duplicate functionality, but regarding what is there
 today, I would still use the "low-level" functionality of Tango, not
 Phobos. Biased, yes, but for a reason.


Yes, but having overlapping functionality in both library would not be 
so bad. Especially when you could "merge" both libraries and allow to 
use them together. There is clearly a need for both style libraries, as 
there were quite a few votes supporting Phobos style.

And Walter is not willing to drop Phobos in favor of Tango. (Probably 
just because he is supporting Phobos like style of standard library :-D)


 ---

 In such a scenario Tango could be also delivered packaged with compiler,
 but it would be not necessary to use it for writing simple applications
 (no code in Phobos calls Tango). When someone needs higher level
 functionality she can use Tango. When using Tango, probably Phobos will
 be necessary also (Tango libraries can call Phobos).

 To sum up:
 1. Runtime (from Tango) - one library
 2. Lower level stuff Phobos - second library
 3. Higher level stuff Tango - third library

 Everything mentioned above packed with compiler in easily installable
 packages for Windows/Linux/MacOs. :-)


 
 If you do a s/Phobos/Tango on your 3 points above, you have correctly
 summarized Tango :)
 


:-)

Probably few modules from Tango core could find its home in Phobos. You 
wrote also about free functions in Tango - it's basically style 
characterizing Phobos, so they could be also part of Phobos.

BR
Marcin Kuszczak
(aarti_pl - www.zapytajmnie.com)
Oct 10 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Aarti_pl wrote:
 

 That said, I see good place for both libraries here Phobos and Tango:
 - Phobos should do lower level stuff. Functionalities in Phobos which
 belongs to second group should be dropped from it.
 - Tango should do higher level stuff. Functionalities in Tango which
 belongs to first group should be dropped from it.


 
 If both Phobos and Tango is part of the standard library, it would make
 sense to clean out duplicate functionality, but regarding what is there
 today, I would still use the "low-level" functionality of Tango, not
 Phobos. Biased, yes, but for a reason.


 
 Yes, but having overlapping functionality in both library would not be
 so bad. Especially when you could "merge" both libraries and allow to
 use them together. There is clearly a need for both style libraries, as
 there were quite a few votes supporting Phobos style.


Even if Tango has a different "style" than Phobos, that has never been the
reason for Tango existing. Any such need (need for certain style) should be
pretty artificial. API style shouldn't really matter when choosing a
library until the point where it clearly is the only true difference and/or
it really inhibits the usage, whether due to being badly designed or
because it don't fit with other packages used.


 
 And Walter is not willing to drop Phobos in favor of Tango. (Probably
 just because he is supporting Phobos like style of standard library :-D)


Afaik, style is not at all the reasoning behind any such decision, even if
Phobos' style probably is Walter's preference.


 

 ---

 In such a scenario Tango could be also delivered packaged with compiler,
 but it would be not necessary to use it for writing simple applications
 (no code in Phobos calls Tango). When someone needs higher level
 functionality she can use Tango. When using Tango, probably Phobos will
 be necessary also (Tango libraries can call Phobos).

 To sum up:
 1. Runtime (from Tango) - one library
 2. Lower level stuff Phobos - second library
 3. Higher level stuff Tango - third library

 Everything mentioned above packed with compiler in easily installable
 packages for Windows/Linux/MacOs. :-)


 
 If you do a s/Phobos/Tango on your 3 points above, you have correctly
 summarized Tango :)
 


 
 :-)
 
 Probably few modules from Tango core could find its home in Phobos. You
 wrote also about free functions in Tango - it's basically style
 characterizing Phobos, so they could be also part of Phobos.


The differences between Tango and Phobos is so much more than the style,
still that seems to be the only thing people focus on when choosing Phobos
ahead of Tango. The style reason is for some a reason to choose Tango ahead
of Phobos, but it is usually different things (like performance, stability,
support, etc). This is the reason for me not thinking that your proposed
approach above immediately is a smart move.

To clarify, the non-runtime part of Tango is likely to continue to exist
forever (the forever of software and programming languages at least),
because to me and at least a few others, there is no need for Phobos. One
needs to assume that Tango and Phobos run on a common or compatible
runtime, for the following to be true, so let's assume that;

Why would anyone use any amount of time and effort to keep Tango code in
Phobos synced with the original in Tango, when all you need to do is
download Tango in addition to Phobos? Having some modules from Tango in
Phobos, then downloading Tango (because you may also want to use some
higher level features) could then result in breakage if Tango contains
unsynced changes to the stuff in Phobos (note that this don't have to be
public API changes if there are any kind of dependencies between Tango
modules in Phobos). There are also other issues with such a setup related
to mantainance, bugfixing and support in general for the code

So in my view, any kind of merger is first (and possibly only) about runtime
compatibility. If one is to merge everything in some way, it may, for
mantainance reasons (less core functionality to mantain, but a lot of work
to do the initial wrap), make sense to build one of the API's on top of the
other. Building for instance Tango IO on top of Phobos don't make sense
though (at least to me), as it would degrade performance. Doing the
opposite, would probably create other subtle differences due to Phobos' IO
going via the C runtime.  

Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 10 2007
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Lars Ivar Igesund wrote:
..

 Why would anyone use any amount of time and effort to keep Tango code in
 Phobos synced with the original in Tango, when all you need to do is
 download Tango in addition to Phobos? Having some modules from Tango in
 Phobos, then downloading Tango (because you may also want to use some
 higher level features) could then result in breakage if Tango contains
 unsynced changes to the stuff in Phobos (note that this don't have to be
 public API changes if there are any kind of dependencies between Tango
 modules in Phobos). There are also other issues with such a setup related
 to mantainance, bugfixing and support in general for the code
 
 So in my view, any kind of merger is first (and possibly only) about runtime
 compatibility. If one is to merge everything in some way, it may, for
 mantainance reasons (less core functionality to mantain, but a lot of work
 to do the initial wrap), make sense to build one of the API's on top of the
 other. Building for instance Tango IO on top of Phobos don't make sense
 though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to Phobos' IO
 going via the C runtime.  


I agree with this stance. To make it explicit, I think compatibility is 
first and foremost needed to enable Tango users to link to Phobos 
libraries and vice versa (imo). To me, the most minimal to make this 
possible is also the most desirable. Granted, tangobos can be used for 
this purpose, though a more formal solution in the long run might 
inspire more confidence.

Not really on topic, but related: it would be nice for Phobos to be 
enriched with whatever improvements Tango have made to important parts 
such as the runtime design and the threads implementation.
Oct 10 2007
prev sibling next sibling parent reply Aarti_pl <aarti interia.pl> writes:
Reply to Lars Ivar Igesund:

-----------

I decided to skip discussion before, as it seems you misinterpreted a 
little bit my intentions.

I am all for merging libraries, and just thinking about the best way to 
do it.

 From earlier discussions it seems that:
1. Runtime will be merged.
2. Other fundamental incompatibilities will be ironed out: 
Exception/Error, toString/toUtf8

That's ok.

After that point it will be possible to write programs, which will work 
on same runtime and use Tango as normal extension library.

But IMHO there will be still somewhat strange situation where 2 
libraries will pretend to be kind of standard. That will be not so bad 
as situation which we have currently. But with some coordination between 
Tango and Phobos it is possible to transform such a situation into real 
advantage.

Basically I am saying following:
1. Both libraries should be packed together with compiler (e.g. DMD). 
 From user point of view it will be one standard library logically 
divided into 2 parts.

2. They will still live in their own namespaces: Phobos = std, Tango = 
tango.

3. As I said in previous posts:

- Phobos should do lower level stuff. Functionalities in Phobos
which belongs to second group should be dropped from it. Library 
characteristics: for lower level stuff, which should be fast, simple, 
small, easy to learn and use. Possible applications: embedded devices, 
quick hacks, scripting, game's engines, kernel programming etc. Style of 
library: free functions, simple classes, consts...

- Tango should do higher level stuff. Functionalities in Tango which 
belongs to first group should be dropped (transferred to Phobos) from 
it. Library characterisctics: for higher level stuff, which gives 
flexibility, encapsulation and easy way to work in big teams. Possible 
applications: desktop programs, advanced networking, distributed 
computing etc. Style of library: classes, inheritance, interfaces...

- It is not necessary that Tango will relay on Phobos functionality, but 
it should be possible to make such dependencies.

- There will be probably overlapping *functionality* (not same 
classes/functions!) in both libraries. I am thinking e.g. about issue 
with writef and Cout - in this case I think both ways of doing output 
have strong supporters.

4. It seems that Phobos will also "live forever", so alternative is that 
  you will have whole Tango, and whole Phobos side by side, while it 
would be much better to have both libraries profiled a little bit. If 
such profiling will not happen, duplication of code will be much bigger, 
as anyone using Tango will be able also to use high-level stuff from 
Phobos, which probably is also in Tango.

I hope it clears my opinion a little bit. These are just few thoughts. 
That said I think it could be quite difficult to coordinate such a big 
projects as Tango and Phobos. But for sure it would be better for users...

Best Regards
Marcin Kuszczak
(aarti_pl - www.zapytajmnie.com)
Oct 10 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Aarti_pl wrote:


 Reply to Lars Ivar Igesund:
 
 -----------
 
 I decided to skip discussion before, as it seems you misinterpreted a
 little bit my intentions.


I don't think I did, at least this post didn't give me any other view on
what you are saying. My problem is probably that you seem to imply that
Phobos is better suited for what you call low-level functionality, whereas
I think Tango is _at least_ equally well suited, and unlike Phobos, very
well integrated with the higher level aspects of Tango (or the other way
round). Thus I am of the opinion that if you use the higher level
functionality of Tango, then you generally should also use the lower level
functionality of Tango. There is no code in Tango that would benefit from
being built on top of Phobos (as Kris said elsewhere in the thread),
although there may be code there that may serve as a basis or inspiration
for implementations in Tango. Indeed, there are modules present in both.
These are generally fairly standalone modules though. 

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 10 2007
parent reply Marcin Kuszczak <aarti_nospam please_interia.pl> writes:
Lars Ivar Igesund wrote:


 Aarti_pl wrote:
 

 Reply to Lars Ivar Igesund:
 
 -----------
 
 I decided to skip discussion before, as it seems you misinterpreted a
 little bit my intentions.


 
 I don't think I did, at least this post didn't give me any other view on
 what you are saying. My problem is probably that you seem to imply that
 Phobos is better suited for what you call low-level functionality, whereas
 I think Tango is _at least_ equally well suited, and unlike Phobos, very
 well integrated with the higher level aspects of Tango (or the other way
 round). Thus I am of the opinion that if you use the higher level
 functionality of Tango, then you generally should also use the lower level
 functionality of Tango. There is no code in Tango that would benefit from
 being built on top of Phobos (as Kris said elsewhere in the thread),
 although there may be code there that may serve as a basis or inspiration
 for implementations in Tango. Indeed, there are modules present in both.
 These are generally fairly standalone modules though.
 


Thanks, I understand clearly (I hope) your point now.

But I rather would like to accent that currently it seems, that you will
have no choice: Tango *OR* Phobos. Phobos will stay, and because of that
there will be people who will use both: Tango *AND* Phobs. 

Both libraries are addressed to same target audience - they compete with
each other. IMHO this kind of competition in standard libraries is not best
thing for *D community* (I am not trying to advocate Tango or Phobos). Some
people will use only Phobos, some only Tango, but I think that most will
use few modules from Tango and few from Phobos. This will cause big mess
because of duplicated functionality in both libraries.

Imagine big development team which work on single program. You will find
everything in it, nevertheless of design rules. One will use Tango net
package and another one std.socket.

Dividing responsibilities between Phobos and Tango would be *Good Thing
(tm)*. That was my main message, and I tried to suggest that setting some
kind of usage policies for Tango and for Phobos would help community in
general.

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why... I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Oct 10 2007
parent reply "Kris" <foo bar.com> writes:
"Marcin Kuszczak" <aarti_nospam please_interia.pl> wrote in message


 usage policies for Tango and for Phobos would help community in
 general.


Speaking of which, Tango exists to /help/ both the community and D progress. 
It wasn't written for a giggle or a lark, and has been a truly expensive 
proposition (in various ways) for several of those involved <g>

When you step away from the hobbyist level, D would get nowhere fast without 
a broad and cohesive library. Tango is designed to be an answer to that, is 
generally delivering at this stage, and is set to blossom in the very near 
future (wait and see). A number of people feel that something (perhaps 
intangible?) is missing and we're trying to get a handle on that, while at 
the same time trying to figure out what people really expect from a 
phantango merger. What's important to me is this: if a merger does /not/ 
resolve the pain-points, then it would a worthless and expensive exercise.

To qualify that we need to identify those pain points. That's what this 
thread is about, and I'd like everyone to toss something in the bucket. I 
mean, there are people here who claim to really dislike Tango. It would be 
really helpful if those folks could/would also chime in with what their 
specific dislikes are?  Without that, we're kinda running around in the dark 
bumping into each other ...
Oct 10 2007
parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Kris wrote:


 A number of people feel that something (perhaps 
 intangible?) is missing and we're trying to get a handle on that, while at 
 the same time trying to figure out what people really expect from a 
 phantango merger.


The main issue from my point of view is compatibility. Right now, as I
understand it, if I build a D library on top of Phobos or Tango I
exclude users of the other run time system from using my library. This
state of affairs in THE pain point. You don't have this situation in any
other well established language (that I know of), and it greatly
inhibits my inclination toward building D libraries.

I actually don't care about features, style, or documentation because I
shouldn't have to care. I should be able to use a single interface to a
run time system and know that my work can be used by "anyone" else
(barring special purpose configurations).

For example, if I write a library in C++ I can use the facilities
described by the C++ standard and know that everyone else will have
those facilities available. If I need a third party library X, I can
document that dependency and reasonably ask my users to also provide X
without disrupting whatever else they are doing. Because of the Phobos
vs Tango business D is not like this, and that is the one and only
problem from my point of view.

Peter
Oct 11 2007
parent "Kris" <foo bar.com> writes:
Yes, thank you!

This is a really important point because, supposing the Runtime was 
compatible, Peter still would likely not be able to do what he wants 
(because the I/O would still be different, for example). His point is 
exactly why we're trying to get a handle on what people want/expect.

- Kris


"Peter C. Chapin" <pchapin sover.net> wrote in message 
news:fel1gp$v1j$1 digitalmars.com...

 Kris wrote:


 A number of people feel that something (perhaps
 intangible?) is missing and we're trying to get a handle on that, while 
 at
 the same time trying to figure out what people really expect from a
 phantango merger.


 The main issue from my point of view is compatibility. Right now, as I
 understand it, if I build a D library on top of Phobos or Tango I
 exclude users of the other run time system from using my library. This
 state of affairs in THE pain point. You don't have this situation in any
 other well established language (that I know of), and it greatly
 inhibits my inclination toward building D libraries.

 I actually don't care about features, style, or documentation because I
 shouldn't have to care. I should be able to use a single interface to a
 run time system and know that my work can be used by "anyone" else
 (barring special purpose configurations).

 For example, if I write a library in C++ I can use the facilities
 described by the C++ standard and know that everyone else will have
 those facilities available. If I need a third party library X, I can
 document that dependency and reasonably ask my users to also provide X
 without disrupting whatever else they are doing. Because of the Phobos
 vs Tango business D is not like this, and that is the one and only
 problem from my point of view.

 Peter
Oct 11 2007
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:


 So in my view, any kind of merger is first (and possibly only) about runtime
 compatibility. If one is to merge everything in some way, it may, for
 mantainance reasons (less core functionality to mantain, but a lot of work
 to do the initial wrap), make sense to build one of the API's on top of the
 other. Building for instance Tango IO on top of Phobos don't make sense
 though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to Phobos' IO
 going via the C runtime.  
 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango


A question: is it a good thing that Phobos depends on the c runtime? I'm 
not sure but won't it be better if the future merged D standard library 
wouldn't need the c runtime at all? (less dependencies and maybe better 
performance?)
Oct 10 2007
next sibling parent reply BCS <BCS pathlink.com> writes:
Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 

 So in my view, any kind of merger is first (and possibly only) about 
 runtime
 compatibility. If one is to merge everything in some way, it may, for
 mantainance reasons (less core functionality to mantain, but a lot of 
 work
 to do the initial wrap), make sense to build one of the API's on top 
 of the
 other. Building for instance Tango IO on top of Phobos don't make sense
 though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to 
 Phobos' IO
 going via the C runtime. 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango


 
 
 A question: is it a good thing that Phobos depends on the c runtime? I'm 
 not sure but won't it be better if the future merged D standard library 
 wouldn't need the c runtime at all? (less dependencies and maybe better 
 performance?)


at a bare minimum, you will need the OS system call API. That (on most 
systems) is C. You can't completely divorce your self from C and there 
is a lot of good low level "paint on the metal" C code out there. D is 
not going to do better than that stuff so why not just use it.
Oct 10 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
BCS wrote:


 Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 

 So in my view, any kind of merger is first (and possibly only) about
 runtime
 compatibility. If one is to merge everything in some way, it may, for
 mantainance reasons (less core functionality to mantain, but a lot of
 work
 to do the initial wrap), make sense to build one of the API's on top
 of the
 other. Building for instance Tango IO on top of Phobos don't make sense
 though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to
 Phobos' IO
 going via the C runtime.
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango


 
 
 A question: is it a good thing that Phobos depends on the c runtime? I'm
 not sure but won't it be better if the future merged D standard library
 wouldn't need the c runtime at all? (less dependencies and maybe better
 performance?)


 
 at a bare minimum, you will need the OS system call API. That (on most
 systems) is C. You can't completely divorce your self from C and there
 is a lot of good low level "paint on the metal" C code out there. D is
 not going to do better than that stuff so why not just use it.


Performance wise, Tango is doing better than the C runtime (or at least the
combination of Phobos+C runtime) for the testcases we know of. That the OS
uses C as an interface to it's syscalls is not a relevant point in this
dicussion.

Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 11 2007
parent "Kris" <foo bar.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:fekm1g$8f4$1 digitalmars.com...


 Performance wise, Tango is doing better than the C runtime (or at least 
 the
 combination of Phobos+C runtime) for the testcases we know of. That the OS
 uses C as an interface to it's syscalls is not a relevant point in this
 dicussion.


earlier tests indicate that D+Tango was (in some cases) twice as fast as the 
equivalent C program on Win32. You can only make so much out of that, but 
it's still useful to know.
Oct 11 2007
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Yigal Chripun wrote:


 Lars Ivar Igesund wrote:
 

 So in my view, any kind of merger is first (and possibly only) about
 runtime compatibility. If one is to merge everything in some way, it may,
 for mantainance reasons (less core functionality to mantain, but a lot of
 work to do the initial wrap), make sense to build one of the API's on top
 of the other. Building for instance Tango IO on top of Phobos don't make
 sense though (at least to me), as it would degrade performance. Doing the
 opposite, would probably create other subtle differences due to Phobos'
 IO going via the C runtime.
 
 Lars Ivar Igesund
 blog at http://larsivi.net
 DSource, #d.tango & #D: larsivi
 Dancing the Tango


 
 A question: is it a good thing that Phobos depends on the c runtime? I'm
 not sure but won't it be better if the future merged D standard library
 wouldn't need the c runtime at all? (less dependencies and maybe better
 performance?)


Tango don't depend on the C runtime for those exact reasons, however there
may be reasons for using it if interoperability with C libraries is an
issue at some level.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 11 2007
prev sibling parent reply "Kris" <foo bar.com> writes:
"Aarti_pl" <aarti interia.pl> wrote in message 
news:fei899$1a6c$1 digitalmars.com...

 As I see there is demand among people for two kind of libraries:

 - library for lower level stuff, which should be fast, simple, small, easy 
 to learn and use. Possible applications: embedded devices, quick hacks, 
 scripting, game's engines, kernel programming etc.


That's Tango :)



 - library for higher level stuff, which gives flexibility, encapsulation 
 and easy way to work in big teams. Possible applications: desktop 
 programs, advanced networking, distributed computing etc.



That's Tango :)




 That said, I see good place for both libraries here Phobos and Tango:
 - Phobos should do lower level stuff. Functionalities in Phobos which 
 belongs to second group should be dropped from it.


And that's where the misconception comes in. The benefits in the high level 
of Tango are often based upon the capabilities in the "lower" levels. Which 
is why the earlier question had been posed about Tango I/O. You don't get 
Tango without the I/O package, because that is one of the definitive 
differences between the two libraries. In short, there's nothing in Phobos 
that Tango would benefit from. When it comes to I/O, for example, Tango 
seriously outperforms every other library we've bothered to test. When it 
comes to string processing, the same is true. This is due to the design of 
Tango.



 - Tango should do higher level stuff. Functionalities in Tango which 
 belongs to first group should be dropped from it.


Tango did not evolve in a vacuum ... it took all the things that were 
"wrong" with phobos and fixed them, so you can't revert some of that and 
hope to gain anything useful :)




 To sum up:
 1. Runtime (from Tango) - one library
 2. Lower level stuff Phobos - second library
 3. Higher level stuff Tango - third library



You're talking about Tango, all by itself  :)

Perhaps another way to ask these questions might be this:  what type/style 
of phobos functionlaity would you like to see in Tango?  BCS hinted at this 
early on, and it would be useful to hear more of that ...

- Kris
Oct 10 2007
next sibling parent reply 0ffh <spam frankhirsch.net> writes:
Kris wrote:

 Perhaps another way to ask these questions might be this:  what type/style 
 of phobos functionlaity would you like to see in Tango?  BCS hinted at this 
 early on, and it would be useful to hear more of that ...


What I like most about Phobos is it's ease-of-use and it's style.
I know you are already working on stand-alone functions in Tango,
and it's a good thing to do, IMHO. :)

Regards, Frank
Oct 10 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
0ffh wrote:


 Kris wrote:

 Perhaps another way to ask these questions might be this:  what
 type/style
 of phobos functionlaity would you like to see in Tango?  BCS hinted at
 this early on, and it would be useful to hear more of that ...


 
 What I like most about Phobos is it's ease-of-use and it's style.


That you like the style is a fair point, but as I mentioned elsewhere, I
think that generally should be a secondary consideration. ease-of-use
however should be much more important. So my question is, does Phobos'
style make it easier for you to use? Is this due to free standing
functions, or because Phobos has few modules to search through? If the
latter, would a different type of docs, showing where to find functionality
in Tango, be of help?


 I know you are already working on stand-alone functions in Tango,
 and it's a good thing to do, IMHO. :)


It is not as if such functions are non-existant in Tango, so which exact
functionality do you think is better expressed through free standing
functions rather than objects? The answers of others shows that this
usually is wanted for objects where you often need only one operation on
the given object, even if others are available. This don't remove the fact
that an object (class) equally often is a useful abstraction, and when that
is established, free standing functions usually should be implemented as
wrappers around each method on the object, rather than the object being
implemented via free standing functions. This is why Tango looks as it does
today; we have avoided wrappers of our own code if possible, because they
degrade orthogonality of the API, and add more code to maintain. Whether we
have been to strict in enforcing that stance, is an open question.


 
 Regards, Frank


-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 10 2007
parent reply BCS <BCS pathlink.com> writes:
Lars Ivar Igesund wrote:

 0ffh wrote:
 
 

Kris wrote:


Perhaps another way to ask these questions might be this:  what
type/style
of phobos functionlaity would you like to see in Tango?  BCS hinted at
this early on, and it would be useful to hear more of that ...


What I like most about Phobos is it's ease-of-use and it's style.


 
 
 That you like the style is a fair point, but as I mentioned elsewhere, I
 think that generally should be a secondary consideration. ease-of-use
 however should be much more important. So my question is, does Phobos'
 style make it easier for you to use? Is this due to free standing
 functions, or because Phobos has few modules to search through? If the
 latter, would a different type of docs, showing where to find functionality
 in Tango, be of help?
 


I think that style and ease of use are tightly linked. In Phobos, if you 
want to write to the screen you use writef and it dumps a pile of stuff 
to the screen. In tango (from what I've seen) you get a reference to an 
object and then run a big sequence of chained calls. In some cases, the 
tango way has something going for it, but in others, Just get the ___ 
out of my way and put "bla bla bla" on the screen. I don't care if it's 
less flexible, because I just want to print.

This may be a bit overreacting but it's similar for Phobos's streams and 
whatever Tango has. Last time I had time to try to learn tango's IO, I 
spent about 2 hours trying to get my head around how the heck it worked 
and still I couldn't figure it out (this might have been a side effect 
of me trying to get a 500 ft. overview of how the whole thing works and 
not just a cookbook do ABC to get XYZ understanding). In Phobos, there 
are streams, you can read from them with a few dozen methods and write 
to them with about the same. Everything you need to know you can get in 
about 5 screens of web page that is mostly a list of nearly identical 
functions.



 

I know you are already working on stand-alone functions in Tango,
and it's a good thing to do, IMHO. :)


 
 
 It is not as if such functions are non-existant in Tango, so which exact
 functionality do you think is better expressed through free standing
 functions rather than objects? The answers of others shows that this
 usually is wanted for objects where you often need only one operation on
 the given object, even if others are available. This don't remove the fact
 that an object (class) equally often is a useful abstraction, and when that
 is established, free standing functions usually should be implemented as
 wrappers around each method on the object, rather than the object being
 implemented via free standing functions. This is why Tango looks as it does
 today; we have avoided wrappers of our own code if possible, because they
 degrade orthogonality of the API, and add more code to maintain. Whether we
 have been to strict in enforcing that stance, is an open question.
 


Where the "OO is god" (oops, make that "good") stance puts me off is 
where it get in my way with things like (random example) RegEx. I don't 
want to new of an object and fill in all the members (etc, etc) just to 
run one regex match and then drop the object. I'd love to have both a 
RegEx class then compiles to some sort of fast state machine and a free 
function that does an on the fly interpretation.

Before you even say it; That is a totally impractical way to do it. Why 
have two totally independent code bases doing (almost) exactly the same 
thing? At this point I'm just stating what I think would be ideal, not 
what I expect to get.


I know that's all a bit disjointed, but I hope it shows something of my 
reservations of switching to Tango.


 

Regards, Frank
Oct 10 2007
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
BCS wrote:

 
 Where the "OO is god" (oops, make that "good") stance puts me off is 
 where it get in my way with things like (random example) RegEx. I don't 
 want to new of an object and fill in all the members (etc, etc) just to 
 run one regex match and then drop the object. I'd love to have both a 
 RegEx class then compiles to some sort of fast state machine and a free 
 function that does an on the fly interpretation.
 
 Before you even say it; That is a totally impractical way to do it. Why 
 have two totally independent code bases doing (almost) exactly the same 
 thing? At this point I'm just stating what I think would be ideal, not 
 what I expect to get.
 
 
 I know that's all a bit disjointed, but I hope it shows something of my 
 reservations of switching to Tango.
 


if i understand you correctly what you ask for is an implementation of 
regEx as in Ruby.
Ruby is totally OOP and RegEx is OOP based so we have classes an such to 
represent the expression and the results, etc..
on top of it it implement an interface wich allows you to use regEx as 
you would normally expect (like in perl. for example you can use literal 
expressions like /pattern/).  most of the time people use that. you can 
use the underlying classes if you want but that of course is more 
verbose (and probably most of the time is not needed).
This is much better than two code bases, it gives us the benefits of 
both styles and i think that's what lars suggests.
the only thing left to do is figure out how a similar structure could be 
implemented in D.
Oct 10 2007
parent BCS <BCS pathlink.com> writes:
Yigal Chripun wrote:

 BCS wrote:
 

 Where the "OO is god" (oops, make that "good") stance puts me off is 
 where it get in my way with things like (random example) RegEx. I 
 don't want to new of an object and fill in all the members (etc, etc) 
 just to run one regex match and then drop the object. I'd love to have 
 both a RegEx class then compiles to some sort of fast state machine 
 and a free function that does an on the fly interpretation.

 Before you even say it; That is a totally impractical way to do it. 
 Why have two totally independent code bases doing (almost) exactly the 
 same thing? At this point I'm just stating what I think would be 
 ideal, not what I expect to get.


 I know that's all a bit disjointed, but I hope it shows something of 
 my reservations of switching to Tango.


 
 if i understand you correctly what you ask for is an implementation of 
 regEx as in Ruby.
 Ruby is totally OOP and RegEx is OOP based so we have classes an such to 
 represent the expression and the results, etc..
 on top of it it implement an interface wich allows you to use regEx as 
 you would normally expect (like in perl. for example you can use literal 
 expressions like /pattern/).  most of the time people use that. you can 
 use the underlying classes if you want but that of course is more 
 verbose (and probably most of the time is not needed).
 This is much better than two code bases, it gives us the benefits of 
 both styles and i think that's what lars suggests.
 the only thing left to do is figure out how a similar structure could be 
 implemented in D.


Actually what I want (and don't expect to get) is two independent 
implementation of RegEx. One would be OO the other would not share code 
with the OO version.

The point is that the OO version will probably have a RegEx compiler in 
the constructor that has a time and memory cost on the assumption that 
you will use the RegEx several times and the improved match performance 
will recoup that.

OTOH the free function one would not compile the RegEx. Rather it would 
interpret the string it's self and compare it to the text /as/ it reads 
though the pattern. The assumption here bing that many regex are simple 
and used once and that the fastest way to match them is to avoid 
overhead like the plague.

again I'm not arguing for this, just stating one case where "style" 
makes a difference
Oct 10 2007
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Generally I think you make a comment on an uninformed basis, but I'll try to
put you straight :)

BCS wrote:


 Lars Ivar Igesund wrote:

 0ffh wrote:
 
 

Kris wrote:


Perhaps another way to ask these questions might be this:  what
type/style
of phobos functionlaity would you like to see in Tango?  BCS hinted at
this early on, and it would be useful to hear more of that ...


What I like most about Phobos is it's ease-of-use and it's style.


 
 
 That you like the style is a fair point, but as I mentioned elsewhere, I
 think that generally should be a secondary consideration. ease-of-use
 however should be much more important. So my question is, does Phobos'
 style make it easier for you to use? Is this due to free standing
 functions, or because Phobos has few modules to search through? If the
 latter, would a different type of docs, showing where to find
 functionality in Tango, be of help?
 


 
 I think that style and ease of use are tightly linked. In Phobos, if you
 want to write to the screen you use writef and it dumps a pile of stuff
 to the screen. In tango (from what I've seen) you get a reference to an
 object and then run a big sequence of chained calls. In some cases, the
 tango way has something going for it, but in others, Just get the ___
 out of my way and put "bla bla bla" on the screen. I don't care if it's
 less flexible, because I just want to print.


How on earth is

Cout("somestring"); more "complex" than writef (write actually)?

You can use chained calls with Tango, but you don't have to, and generally
you won't. So Tango is probably both flexible _and_ able to do just do what
you want?


 
 This may be a bit overreacting but it's similar for Phobos's streams and
 whatever Tango has. Last time I had time to try to learn tango's IO, I
 spent about 2 hours trying to get my head around how the heck it worked
 and still I couldn't figure it out (this might have been a side effect
 of me trying to get a 500 ft. overview of how the whole thing works and
 not just a cookbook do ABC to get XYZ understanding). In Phobos, there
 are streams, you can read from them with a few dozen methods and write
 to them with about the same. Everything you need to know you can get in
 about 5 screens of web page that is mostly a list of nearly identical
 functions.


Tango's IO system is indeed flexible, and to some complex to learn. With the
fairly new stream abstractions, it should be no more difficult than Phobos'
though, and indeed, in Tango they are integrated such that you can chain
streams using them as filters and more.


 
 

 

I know you are already working on stand-alone functions in Tango,
and it's a good thing to do, IMHO. :)


 
 
 It is not as if such functions are non-existant in Tango, so which exact
 functionality do you think is better expressed through free standing
 functions rather than objects? The answers of others shows that this
 usually is wanted for objects where you often need only one operation on
 the given object, even if others are available. This don't remove the
 fact that an object (class) equally often is a useful abstraction, and
 when that is established, free standing functions usually should be
 implemented as wrappers around each method on the object, rather than the
 object being implemented via free standing functions. This is why Tango
 looks as it does today; we have avoided wrappers of our own code if
 possible, because they degrade orthogonality of the API, and add more
 code to maintain. Whether we have been to strict in enforcing that
 stance, is an open question.
 


 
 Where the "OO is god" (oops, make that "good") stance puts me off is
 where it get in my way with things like (random example) RegEx. I don't
 want to new of an object and fill in all the members (etc, etc) just to
 run one regex match and then drop the object. I'd love to have both a
 RegEx class then compiles to some sort of fast state machine and a free
 function that does an on the fly interpretation.


I highly doubt this is a good example from Tango considering Tango and
Phobos currently share Regex implementation?


 I know that's all a bit disjointed, but I hope it shows something of my
 reservations of switching to Tango.


It mostly shows that you are making decisions on an uninformed and outdated
basis :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 11 2007
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Lars Ivar Igesund wrote:


 Generally I think you make a comment on an uninformed basis, but I'll try
 to put you straight :)


Just noted that the post elsewhere in the thread was much more useful :)
Thanks!

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 11 2007
prev sibling next sibling parent reply "Anders Bergh" <anders1 gmail.com> writes:
On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:

 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?


Upper-case "C"...

Anders
Oct 11 2007
parent reply Sean Kelly <sean f4.ca> writes:
Anders Bergh wrote:

 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:

 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?


 
 Upper-case "C"...


I don't like that either :-)  I think it's an artifact of earlier design 
iterations.


Sean
Oct 11 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
Sean Kelly wrote:

 Anders Bergh wrote:

 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:

 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?


 Upper-case "C"...


 
 I don't like that either :-)  I think it's an artifact of earlier design 
 iterations.
 
 
 Sean


Then you could add "alias Cout cout", I guess. Anything preventing that?
Oct 11 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Christopher,


 Sean Kelly wrote:
 

 Anders Bergh wrote:
 

 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 

 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?
 


 Upper-case "C"...
 


 I don't like that either :-)  I think it's an artifact of earlier
 design iterations.
 
 Sean
 


 Then you could add "alias Cout cout", I guess. Anything preventing
 that?
 


have you over used:

#define BEGIN {
#define END }


? <G>
Oct 11 2007
prev sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Christopher Wright wrote:

 Sean Kelly wrote:

 Anders Bergh wrote:

 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:

 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?


 Upper-case "C"...


 I don't like that either :-)  I think it's an artifact of earlier 
 design iterations.


 Sean


 
 Then you could add "alias Cout cout", I guess. Anything preventing that?


afaik, you can't import aliases.  So that alias would only apply to the 
file it's in, not to the user file importing it.

You could just ...rename it... ;)

I would actually appreciate a library willing to modify and deprecate 
stuff to get rid of old idiosyncrasies.
Oct 11 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Chad,


 Christopher Wright wrote:
 

 Sean Kelly wrote:
 

 Anders Bergh wrote:
 

 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:
 

 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?
 


 Upper-case "C"...
 


 I don't like that either :-)  I think it's an artifact of earlier
 design iterations.
 
 Sean
 


 Then you could add "alias Cout cout", I guess. Anything preventing
 that?
 


 afaik, you can't import aliases.  So that alias would only apply to
 the file it's in, not to the user file importing it.
 
 You could just ...rename it... ;)
 
 I would actually appreciate a library willing to modify and deprecate
 stuff to get rid of old idiosyncrasies.
 


I think you can uses aliases in other files.
Oct 11 2007
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
BCS wrote:

 
 I think you can uses aliases in other files.
 
 


I just tested it, and apparently I'm wrong.

In fact, I'm glad I'm wrong.

I think I know what the snag was now.  Something to the opposite effect. 
  Aliases can't be hidden at a module level, even by private.

// imp.d
private alias int Foo;

// main.d
import imp;

void main()
{
   Foo bar = 3;
}

// Compiles and runs.

Interestingly, aliases can be hidden by placing them in other 
constructs.  Just change imp.d to the following:
//imp.d
private struct Baz
{
   alias int Foo;
   Foo member;
}

Then the desired compile failure happens.  Even so, it can be 
circumvented by writing Baz.Foo in main().  Given this cursory 
inspection, it seems that there is no way to completely hide aliases. 
I'm not sure how I feel about that.
Oct 11 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Chad J wrote:

 BCS wrote:

 I think you can uses aliases in other files.


 
 I just tested it, and apparently I'm wrong.
 
 In fact, I'm glad I'm wrong.
 
 I think I know what the snag was now.  Something to the opposite effect. 
  Aliases can't be hidden at a module level, even by private.
 
 // imp.d
 private alias int Foo;
 
 // main.d
 import imp;
 
 void main()
 {
   Foo bar = 3;
 }
 
 // Compiles and runs.
 
 Interestingly, aliases can be hidden by placing them in other 
 constructs.  Just change imp.d to the following:
 //imp.d
 private struct Baz
 {
   alias int Foo;
   Foo member;
 }
 
 Then the desired compile failure happens.  Even so, it can be 
 circumvented by writing Baz.Foo in main().  Given this cursory 
 inspection, it seems that there is no way to completely hide aliases. 
 I'm not sure how I feel about that.


I'm very sure how I feel about that.  It's a bug.

Anyone know if it's been filed?

--bb
Oct 11 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Chad J wrote:

 Christopher Wright wrote:

 Sean Kelly wrote:

 Anders Bergh wrote:

 On 10/11/07, Lars Ivar Igesund <larsivar igesund.net> wrote:

 How on earth is

 Cout("somestring"); more "complex" than writef (write actually)?


 Upper-case "C"...


 I don't like that either :-)  I think it's an artifact of earlier 
 design iterations.


 Then you could add "alias Cout cout", I guess. Anything preventing that?


 
 afaik, you can't import aliases.  So that alias would only apply to the 
 file it's in, not to the user file importing it.
 
 You could just ...rename it... ;)
 
 I would actually appreciate a library willing to modify and deprecate 
 stuff to get rid of old idiosyncrasies.


Kris explained this one to me.  Global singletons are declared in 
CamelCase to both identify them and to reduce the chance of collisions 
with local variables.  But I don't like that it's inconsistent with 
other variable declarations and I'm not sure name collisions would be an 
issue anyway.  So YMMV.  As an aside though, if the CamelCase convention 
were dropped, we may need a different name for Stdout, since it would 
collide with the C symbol of the same name.


Sean
Oct 11 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 Kris explained this one to me.  Global singletons are declared in 
 CamelCase to both identify them and to reduce the chance of collisions 
 with local variables.


Just use one letter variable names for locals, and you're golden :-)
Oct 11 2007
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Lars Ivar Igesund wrote:

 
 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?
 


ooo, something I have issue with...

Cout doesn't do formatting.
Stdout doesn't do formatting.

So
writefln("number: %d", number);
becomes
Stdout.formatln("number: {0}", number);
Why doesn't plain Stdout do this?

Oh, and even if it did,
Stdout("number: {0}", number);
would not insert a newline.

I have to use
Stdout("number: {0}", number).newline;
instead, which is again more typing.  I have to type this stuff a lot, 
so I'd like it to be easy.

It would be really nice to have
Stdout("number: {0}", number).nl; // .nl for "newline" or .ln for "line"
as a start.  Shorthand is useful in some cases.

It would be straight awesome to have
Stdout("Point(op1[{0},{1},{2}],",x,y,z)("op2[{0},{1},{2}])",t,u,v).nl;
It also scales nicely.  You don't need to understand the above line to 
write a simple Stdout("Hello world!");.

As I understand it, Cout is a bit more lightweight or somesuch, so I 
don't really have any issues with it, other than that maybe it should be 
hidden away as something only experienced tango users should play with 
as a means of optimizing their programs.

Text output seems easy enough to generalize, so in that case just stick 
to one /single/ canonical way of doing it that works really well and 
scales.
Oct 11 2007
parent BCS <ao pathlink.com> writes:
Reply to Chad,


 Lars Ivar Igesund wrote:
 

 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?
 


 ooo, something I have issue with...
 
 Cout doesn't do formatting.
 Stdout doesn't do formatting.
 So
 writefln("number: %d", number);
 becomes
 Stdout.formatln("number: {0}", number);
 Why doesn't plain Stdout do this?
 Oh, and even if it did,
 Stdout("number: {0}", number);
 would not insert a newline.
 I have to use
 Stdout("number: {0}", number).newline;
 instead, which is again more typing.  I have to type this stuff a lot,
 so I'd like it to be easy.
 It would be really nice to have
 Stdout("number: {0}", number).nl; // .nl for "newline" or .ln for
 "line"
 as a start.  Shorthand is useful in some cases.
 It would be straight awesome to have
 Stdout("Point(op1[{0},{1},{2}],",x,y,z)("op2[{0},{1},{2}])",t,u,v).nl;
 It also scales nicely.  You don't need to understand the above line to
 write a simple Stdout("Hello world!");.
 
 As I understand it, Cout is a bit more lightweight or somesuch, so I
 don't really have any issues with it, other than that maybe it should
 be hidden away as something only experienced tango users should play
 with as a means of optimizing their programs.
 
 Text output seems easy enough to generalize, so in that case just
 stick to one /single/ canonical way of doing it that works really well
 and scales.
 


gneralIdea.votes++;

Give the chained calls overload with formatting directives
Oct 11 2007
prev sibling parent reply BCS <ao pathlink.com> writes:
Reply to Lars,


 Generally I think you make a comment on an uninformed basis, but I'll
 try to put you straight :)
 
 BCS wrote:
 

 I think that style and ease of use are tightly linked. In Phobos, if
 you want to write to the screen you use writef and it dumps a pile of
 stuff to the screen. In tango (from what I've seen) you get a
 reference to an object and then run a big sequence of chained calls.
 In some cases, the tango way has something going for it, but in
 others, Just get the ___ out of my way and put "bla bla bla" on the
 screen. I don't care if it's less flexible, because I just want to
 print.
 


 How on earth is
 
 Cout("somestring"); more "complex" than writef (write actually)?


it isn't, but what about

writef("hello %s, how did you like your %d, %s?", name, count, product);

vs.

Cout("hello ")(name)(", how did you like your ")(count)(", ")(product)("?");

The first is one (static) function call, the other is 7 (virtual) function 
calls, to 3 different functions. If you don't see a difference in complexity, 
then you are measuring something different than me.

Note: there may be a better way to do that, but I don't know what it is.
 

 You can use chained calls with Tango, but you don't have to, and
 generally you won't. So Tango is probably both flexible _and_ able to
 do just do what you want?
 


I'm a cycle snob. How hard it is to code, how hard it is to get it to do 
what I want and *how long it takes to run* are of equal importance to me. 
With tango's use of chained calls (not exactly free from a performance
standpoint) 
is a small minus in my book.


 Tango's IO system is indeed flexible, and to some complex to learn.
 With the fairly new stream abstractions, it should be no more
 difficult than Phobos' though, and indeed, in Tango they are
 integrated such that you can chain streams using them as filters and
 more.


please don't waste your time here explaining to me how it work. Please do 
put the same amount of time into improving the docs so that everyone can 
get the benefit.
 

 Where the "OO is god" (oops, make that "good") stance puts me off is
 where it get in my way with things like (random example) RegEx. I
 don't want to new of an object and fill in all the members (etc, etc)
 just to run one regex match and then drop the object. I'd love to
 have both a RegEx class then compiles to some sort of fast state
 machine and a free function that does an on the fly interpretation.
 


 I highly doubt this is a good example from Tango considering Tango and
 Phobos currently share Regex implementation?
 


Well, I'm not to fond of it as part of phobos ether. My point was an example 
of where "style" is more than a secondary concern.


 I know that's all a bit disjointed, but I hope it shows something of
 my reservations of switching to Tango.
 


 It mostly shows that you are making decisions on an 
 uninformed and


wrong*


 outdated 


correct


 basis :)


If these thing have changed, I'm happy for Tango. Don't get me wrong, I want 
to use Tango, It's just that the benefit has yet to outweigh the cost,
primarily 
as a result of a dwindling supply of my available time.



* it is not uninformed because I knew it is outdated. Also, the decisions 
you mention are "tango /was/ to complex for me to learn /in the time I had/" 
and "I don't have time to figure out Tango now". Even with world class docs, 
I wouldn't have the time now. One of my jobs might be going into a project 
In D and that would let me /make/ the time to figure it out. But at this 
point, I booked for most of the time I'm awake
Oct 11 2007
parent reply "Kris" <foo bar.com> writes:
"BCS" <ao pathlink.com> wrote in message

[snip]


 I'm a cycle snob. How hard it is to code, how hard it is to get it to do 
 what I want and *how long it takes to run* are of equal importance to me. 
 With tango's use of chained calls (not exactly free from a performance 
 standpoint) is a small minus in my book.


This is worth discussing, since I'm sometimes a cycle-snob also :)

Chained calls actually cost /less/, since the dispatch is decided at 
compile-time rather than runtime. In other words, chained-calls don't have 
to go through a big switch statement to figure out the type and dispatch 
based upon that. Thus, purely from a runtime cycle-count, chained calls 
really /are/ more efficient (for the kind of thing we are talking about). 
This is one of the reasons why Tango uses chained calls in some aspects of 
the IO model.

:p
Oct 11 2007
parent reply BCS <ao pathlink.com> writes:
Reply to kris,


 "BCS" <ao pathlink.com> wrote in message
 
 [snip]
 

 I'm a cycle snob. How hard it is to code, how hard it is to get it to
 do what I want and *how long it takes to run* are of equal importance
 to me. With tango's use of chained calls (not exactly free from a
 performance standpoint) is a small minus in my book.
 


 This is worth discussing, since I'm sometimes a cycle-snob also :)
 
 Chained calls actually cost /less/, since the dispatch is decided at
 compile-time rather than runtime. In other words, chained-calls don't
 have to go through a big switch statement to figure out the type and
 dispatch based upon that. Thus, purely from a runtime cycle-count,
 chained calls really /are/ more efficient (for the kind of thing we
 are talking about). This is one of the reasons why Tango uses chained
 calls in some aspects of the IO model.
 
 :p
 


interesting. I would say this indicates a defect in something. Either the 
implementation of switch or the TypeInfo stuff. The number of different choices 
that writef has to chouse from is only around a dozen or so. I would expect 
that the compiler should be able to get that switch down to a few ops and 
a table lookup.

BTW how does DMD implement switches for integers? some sort of perfect hash 
generator and a table lookup?
Oct 11 2007
parent Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
BCS wrote:

 Reply to kris,



 Chained calls actually cost /less/, since the dispatch is decided at
 compile-time rather than runtime. In other words, chained-calls don't
 have to go through a big switch statement to figure out the type and
 dispatch based upon that. Thus, purely from a runtime cycle-count,
 chained calls really /are/ more efficient (for the kind of thing we
 are talking about). This is one of the reasons why Tango uses chained
 calls in some aspects of the IO model.
 
 :p
 


 
 interesting. I would say this indicates a defect in something. Either the
 implementation of switch or the TypeInfo stuff. The number of different
 choices that writef has to chouse from is only around a dozen or so. I
 would expect that the compiler should be able to get that switch down to a
 few ops and a table lookup.
 
 BTW how does DMD implement switches for integers? some sort of perfect
 hash generator and a table lookup?


I think Kris was pointing out that the runtime needs to parse the format
string, but with chained calls there is a possibility to statically
dispatch in many cases - of course e.g. OOP polymorphism still needs normal
runtime lookups.
Oct 13 2007
prev sibling parent reply "Kris" <foo bar.com> writes:
"0ffh" <spam frankhirsch.net> wrote in message 
news:fej1ad$30el$1 digitalmars.com...

 Kris wrote:

 Perhaps another way to ask these questions might be this:  what 
 type/style of phobos functionlaity would you like to see in Tango?  BCS 
 hinted at this early on, and it would be useful to hear more of that ...


 What I like most about Phobos is it's ease-of-use and it's style.
 I know you are already working on stand-alone functions in Tango,
 and it's a good thing to do, IMHO. :)

 Regards, Frank



Thanks, Frank. If you could be specific about some of those, it would help 
notably ... can you provide an example or two, please?
Oct 10 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kris wrote:

 "0ffh" <spam frankhirsch.net> wrote in message 
 news:fej1ad$30el$1 digitalmars.com...

 Kris wrote:

 Perhaps another way to ask these questions might be this:  what 
 type/style of phobos functionlaity would you like to see in Tango?  BCS 
 hinted at this early on, and it would be useful to hear more of that ...


 What I like most about Phobos is it's ease-of-use and it's style.
 I know you are already working on stand-alone functions in Tango,
 and it's a good thing to do, IMHO. :)

 Regards, Frank


 
 
 Thanks, Frank. If you could be specific about some of those, it would help 
 notably ... can you provide an example or two, please? 


Ideally, tango would just be a library I could import like any other. 
But assuming that's not going to happen, here's what I think could make 
the schism easier to deal with.

*** Convenience functions ***

Here's a list of things I actually use frequently in phobos, ordered 
roughly by frequency of use:

std.stdio : writef,writefln
std.string : format
std.math
std.conv
std.regexp
std.path
std.stream : BufferedFile
std.file : exists,isFile,isDir

If there were equivalently easy-to-use versions of those in Tango, that 
would cover my uses.  And maybe there are already for some, but i see 
for example that std.path is replaced by a cumbersome OO interface, and 
std.conv has no recommended equivalent.
[http://www.dsource.org/projects/tango/wiki/PhobosTangoMigration]

Anyway, to use anything beyond those few up there (and even some of 
those) I have to look up what the API is on the web page.

BUT one advantage of Phobos there, is that I can find anything I need 
pretty quickly with that list of modules on the left hand side of the 
Phobos page.

*** Better API documentation ***

In contrast, the closest thing with Tango seems to be the Tango API 
Index (http://www.dsource.org/projects/tango/docs/current/) which has a 
huge list of names of everything in Tango, much of which is 
implementation detail users shouldn't be mucking with.   So it's hard to 
find the thing you're looking for if you just want to know how to open a 
file.

I think a simplified module index that omits things users won't 
generally need would help on that front.  And a one-line description 
next to each link wouldn't hurt either.  Topical groupings might help 
too.  Like have a list of every module related to "Text Processing" 
"Networking".  The categories in the reference manual might be a good 
place to start.

Another Tango doc gripe is that the modules don't have any useful 
module-level descriptions.  Look at phobos' std.conv for comparison: 
http://www.digitalmars.com/d/1.0/phobos/std_conv.html
The page starts off with a useful description of what std.conv is for. 
Given that, I can quickly tell if std.conv is the right module for the 
job or not (as in it provides atoi and atol type conversions, rather 
than being a module for doing temperature conversions or image 
convolutions or something).  Other modules in Phobos are even better, 
like std.boxer, giving both a quick overview *and* a few basic usage 
examples.

*** Easier switching back and forth ***

It seems that installing Tango itself is pretty easy now, at least if 
you have dsss installed, but AFAIK that renders all your phobos-based 
libs useless.  Tango should do two things to make switching back and 
forth easier.
1) Tanogobos should be a part of the default install
2) A solution for tango-phobos switching should be installed by default. 
  I don't care how it's done but I think it should come in two flavors:
   a) a per-shell transient method for changing the default
   b) a global per-installation (or per-user if there's some way to get 
that) method.

As someone who still has a lot of code written that depends on Phobos, I 
want to know that I can go back and forth between Phobos and Tango 
easily.  Right now if I want to install Tango and still use Phobos 
occasionally, I have to choose between three different fiddly techniques 
(http://www.dsource.org/projects/tango/wiki/PhobosTangoCooperation). 
The web page gives no reason to prefer one method over another, so that 
means I have to read all three and understand how they work well enough 
to determine which method is the best for me.  Something like this 
should just happen automatically as a part of installing Tango.

If I'm going to write a library that depends on Tango, I want to be able 
to say to potential users that all they have to do to use it is:

"""
    1) Install tango (dsss net install tango).
    2) Type the command "set_dlibrary tango"[*] at a command prompt.
and later
    3) if you need to go back to Phobos type "set_dlibrary phobos"[*]

[*] To make the switch persistent use "set_dlibrary -p"
"""

Achieving this level of simplicity probably requires some cooperation 
from Walter.  But it seems utterly attainable.  Unlike merging the runtimes.

--bb
Oct 10 2007
next sibling parent "Kris" <foo bar.com> writes:
Nice! Thanks for this. Some comments inline:


"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:fek90r$2e9o$1 digitalmars.com...

 Kris wrote:

 "0ffh" <spam frankhirsch.net> wrote in message 
 news:fej1ad$30el$1 digitalmars.com...

 Kris wrote:

 Perhaps another way to ask these questions might be this:  what 
 type/style of phobos functionlaity would you like to see in Tango?  BCS 
 hinted at this early on, and it would be useful to hear more of that 
 ...


 What I like most about Phobos is it's ease-of-use and it's style.
 I know you are already working on stand-alone functions in Tango,
 and it's a good thing to do, IMHO. :)

 Regards, Frank



 Thanks, Frank. If you could be specific about some of those, it would 
 help notably ... can you provide an example or two, please?


 Ideally, tango would just be a library I could import like any other. But 
 assuming that's not going to happen, here's what I think could make the 
 schism easier to deal with.

 *** Convenience functions ***

 Here's a list of things I actually use frequently in phobos, ordered 
 roughly by frequency of use:

 std.stdio : writef,writefln
 std.string : format
 std.math
 std.conv
 std.regexp
 std.path
 std.stream : BufferedFile
 std.file : exists,isFile,isDir

 If there were equivalently easy-to-use versions of those in Tango, that 
 would cover my uses.  And maybe there are already for some, but i see for 
 example that std.path is replaced by a cumbersome OO interface, and


the OO of this particular item is very often much cheaper regarding the heap 
(which is why it is OO), and it has changed quite a bit recently. I just 
wish we had struct ctors in D v1 ...



 std.conv has no recommended equivalent.
 [http://www.dsource.org/projects/tango/wiki/PhobosTangoMigration]


Unfortunately, that page is woefully out of date :(

I'll just touch briefly on some the packages you mentioned:

- tango.math is all free-function, I think?
- regexp is no different than phobos that I know of
- I'd imagine std.conv is handled by the (free-function) modules in 
tango.text.convert ?
- the equivalent of a 'format' function is probably covered by 
tango.text.convert.Format module


 Anyway, to use anything beyond those few up there (and even some of those) 
 I have to look up what the API is on the web page.

 BUT one advantage of Phobos there, is that I can find anything I need 
 pretty quickly with that list of modules on the left hand side of the 
 Phobos page.


agreed



 *** Better API documentation ***

 In contrast, the closest thing with Tango seems to be the Tango API Index 
 (http://www.dsource.org/projects/tango/docs/current/) which has a huge 
 list of names of everything in Tango, much of which is implementation 
 detail users shouldn't be mucking with.   So it's hard to find the thing 
 you're looking for if you just want to know how to open a file.


Very good point. There's something in the works to address that specific 
issue.



 I think a simplified module index that omits things users won't generally 
 need would help on that front.  And a one-line description next to each 
 link wouldn't hurt either.  Topical groupings might help too.  Like have a 
 list of every module related to "Text Processing" "Networking".  The 
 categories in the reference manual might be a good place to start.


Yes; topical groupings (perhaps by package) would be much better. In tango, 
each package tends to address a specific need, so that might work out.


 Another Tango doc gripe is that the modules don't have any useful 
 module-level descriptions.  Look at phobos' std.conv for comparison: 
 http://www.digitalmars.com/d/1.0/phobos/std_conv.html
 The page starts off with a useful description of what std.conv is for. 
 Given that, I can quickly tell if std.conv is the right module for the job 
 or not (as in it provides atoi and atol type conversions, rather than 
 being a module for doing temperature conversions or image convolutions or 
 something).  Other modules in Phobos are even better, like std.boxer, 
 giving both a quick overview *and* a few basic usage examples.


Another solid point


 *** Easier switching back and forth ***

 It seems that installing Tango itself is pretty easy now, at least if


Is this linux? I think Win32 has certainly been easy for a long time, but 
the linux packaging has never had a true 'installer' or whatever since 
nobody in the linux world can agree on what that should be :)

Any suggestions there?


 you have dsss installed, but AFAIK that renders all your phobos-based libs 
 useless.  Tango should do two things to make switching back and forth 
 easier.
 1) Tanogobos should be a part of the default install


That may happen, if we can avoid the maintenance concerns


 2) A solution for tango-phobos switching should be installed by default. I 
 don't care how it's done but I think it should come in two flavors:
   a) a per-shell transient method for changing the default
   b) a global per-installation (or per-user if there's some way to get 
 that) method.


Aye



 As someone who still has a lot of code written that depends on Phobos, I 
 want to know that I can go back and forth between Phobos and Tango easily. 
 Right now if I want to install Tango and still use Phobos occasionally, I 
 have to choose between three different fiddly techniques 
 (http://www.dsource.org/projects/tango/wiki/PhobosTangoCooperation). The 
 web page gives no reason to prefer one method over another, so that means 
 I have to read all three and understand how they work well enough to 
 determine which method is the best for me.  Something like this should 
 just happen automatically as a part of installing Tango.


That would be great!


 If I'm going to write a library that depends on Tango, I want to be able 
 to say to potential users that all they have to do to use it is:

 """
    1) Install tango (dsss net install tango).
    2) Type the command "set_dlibrary tango"[*] at a command prompt.
 and later
    3) if you need to go back to Phobos type "set_dlibrary phobos"[*]

 [*] To make the switch persistent use "set_dlibrary -p"
 """


We need a volunteer to write this <g>



 Achieving this level of simplicity probably requires some cooperation from 
 Walter.  But it seems utterly attainable.  Unlike merging the runtimes.


All good and valid points, and taken note of. Thanks for making the effort
Oct 10 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
I'd say a bunch here but most of it would just echo Bill. A few points though:

I have a project that uses only selective imports and has a filter in the 
build script to list the imported symbols. here is the list

File
FileMode
MemoryStream
ReadException
SeekPos
Stream
pow
toString
toUTF16
toUTF8
writef

Just for reference...

Another thing. as far as docs go. Tango could use some work. What I ant to 
see is, for each sub system, a overview of what it is, how it works (500 
ft overview of the whole sub-system) and how to use it. Ideally, this would 
all fit on one screen so two, maybe three paragraphs. As an example I'll 
use the IO stuff (the lack of this exact kind of docs for the IO subsystem 
is one of the *primary reasons* I don't use Tango [*HINT HINT HINT* flashing 
red 48pt font]): what I'd want would be a description of what the parts are, 
and how they fit together. Here is an example of the type of overview I would 
want:

 "a Foo is a source or sink for data like a file or network connection. A 
Baz is a pass though filter that does something to it like compression or 
encryption. A Bar is a near side end for interfacing with IO, it allows you 
to format data, wright raw data, read data, parse data, etc. If you want 
to do something like multiplex many data paths over one, you will need to 
implement the Baz interface."

That would be a good start. Then go into a bit more detail about what each 
part is expected to do.
Oct 10 2007
parent reply "Kris" <foo bar.com> writes:
"BCS" <ao pathlink.com> wrote in message 
news:ce0a33432476f8c9d9a29608a586 news.digitalmars.com...

 I'd say a bunch here but most of it would just echo Bill. A few points 
 though:

 I have a project that uses only selective imports and has a filter in the 
 build script to list the imported symbols. here is the list

 File
 FileMode
 MemoryStream
 ReadException
 SeekPos
 Stream
 pow
 toString
 toUTF16
 toUTF8
 writef


That's useful. Cheers!



 Just for reference...

 Another thing. as far as docs go. Tango could use some work. What I ant to 
 see is, for each sub system, a overview of what it is, how it works (500 
 ft overview of the whole sub-system) and how to use it. Ideally, this 
 would all fit on one screen so two, maybe three paragraphs. As an example 
 I'll use the IO stuff (the lack of this exact kind of docs for the IO 
 subsystem is one of the *primary reasons* I don't use Tango [*HINT HINT 
 HINT* flashing red 48pt font]):


Duly noted :)



 what I'd want would be a description of what the parts are, and how they 
 fit together. Here is an example of the type of overview I would want:

 "a Foo is a source or sink for data like a file or network connection. A 
 Baz is a pass though filter that does something to it like compression or 
 encryption. A Bar is a near side end for interfacing with IO, it allows 
 you to format data, wright raw data, read data, parse data, etc. If you 
 want to do something like multiplex many data paths over one, you will 
 need to implement the Baz interface."

 That would be a good start. Then go into a bit more detail about what each 
 part is expected to do.


That's great. Succinct and to the point. You want a job? :p

Seriously though, you're absolutely right. Thanks
Oct 10 2007
parent reply BCS <ao pathlink.com> writes:
Reply to kris,


 "BCS" <ao pathlink.com> wrote in message


 [*HINT HINT HINT* flashing red 48pt font]):
 


 Duly noted :)
 


I was hopeing I wouldn't need to get out the fog horn <G>


 


 That's great. Succinct and to the point. You want a job? :p


If you will check the history of Tango you will find my name under the heading 
of "came on to do docs and didn't do any". Mostly that was an artifact of 
me being over committed at the time. And it just so happens that a still 
am. :-b
Oct 10 2007
parent "Kris" <foo bar.com> writes:
"BCS" <ao pathlink.com> wrote in message


 If you will check the history of Tango you will find my name under the 
 heading of "came on to do docs and didn't do any". Mostly that was an 
 artifact of me being over committed at the time. And it just so happens 
 that a still am. :-b


lol ... any time you want to jump in, please, be our guest! The door is 
always open :)
Oct 10 2007
prev sibling parent Michael Hewitt <dlangassist gmail.com> writes:
Everyone,

I'm sure what I'm about to say is both naive and obvious, but hopefully it 
will be helpful nonetheless.  As an experienced C++ programmer and new D 
programmer who is considering using D as our primary development language, 
I come at this from a very simple perspective.  I don't really think in terms 
of Phobos and Tango.  I think in terms of the D runtime (aka Phobos) and 
other useful D libraries.  Tango seems like it might have some useful OO 
functionality, but since it is not compatible with the D runtime, I am unable 
to use it.

Bill and Benjamin's lists seem good to me, but even if Tango supported non-OO 
versions of these, I still am inclined toward my admittedly simplistic attitude 
of starting with "the D runtime".  Thus, until Tango either is "the D runtime" 
(i.e. Phobos is deprecated), or is compatible with "the D runtime", I am 
unlikely to use it.  One other comment is that the C-ish flavor of the D 
runtime (e.g. stdio) is quite palatable to new D programmers coming from 
C/C++, of whom there are bound to be many in the future if D is successful. 
 Another comment is that two competing, incompatible runtime libraries is 
a detriment to attracting new programmers to D.

I hope this is helpful.  I don't mean to start a war; I'm just providing 
insight from the perspective of a new D programmer coming from C/C++.

- Mike
Oct 11 2007
prev sibling parent reply Marcin Kuszczak <aarti_nospam please_interia.pl> writes:
Kris wrote:



 And that's where the misconception comes in. The benefits in the high
 level of Tango are often based upon the capabilities in the "lower"
 levels. Which is why the earlier question had been posed about Tango I/O.
 You don't get Tango without the I/O package, because that is one of the
 definitive differences between the two libraries. In short, there's
 nothing in Phobos that Tango would benefit from. When it comes to I/O, for
 example, Tango seriously outperforms every other library we've bothered to
 test. When it comes to string processing, the same is true. This is due to
 the design of Tango.
 


I don't want to drop Tango IO. :-)

Probably I express myself not enough clear with my idea. It would be great
if you could comment on my replay to Larsivi:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960

Thanks!

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why... I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------
Oct 10 2007
parent reply "Kris" <foo bar.com> writes:
"Marcin Kuszczak" <aarti_nospam please_interia.pl> wrote in message 
news:fejdk1$pvv$1 digitalmars.com...

 Kris wrote:



 And that's where the misconception comes in. The benefits in the high
 level of Tango are often based upon the capabilities in the "lower"
 levels. Which is why the earlier question had been posed about Tango I/O.
 You don't get Tango without the I/O package, because that is one of the
 definitive differences between the two libraries. In short, there's
 nothing in Phobos that Tango would benefit from. When it comes to I/O, 
 for
 example, Tango seriously outperforms every other library we've bothered 
 to
 test. When it comes to string processing, the same is true. This is due 
 to
 the design of Tango.


 I don't want to drop Tango IO. :-)

 Probably I express myself not enough clear with my idea. It would be great
 if you could comment on my replay to Larsivi:

 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960

 Thanks!



Sure; the quick and easy answer it this: Tango is also a better /low-level/ 
library than Phobos. Really, it is :)   If you want to get a thin library up 
and running on a cell phone or whatever, Tango would totally be the right 
choice. Why? Because the team went to great effort to make the library (a) 
decoupled and (b) layered.  Not only is the so-called Runtime isolated and 
is even packaged separately, but the middle and upper layers have limited 
interdependencies amongst them.

It's not Utopia, since there are always tradeoffs to make. For example, the 
Tango logging package was previously distinct from the string formatting 
package, so you didn't pay the price of the dependency unless *you* wanted 
it. Well, recently, that changed because the benefit of coupling the two 
outweighed the isolation benefit. That's a fair example of a trade-off that 
was somewhat on the fence to begin with, and finally decided which side it 
wanted to be on :)

Elsewhere we use a small set of interfaces to decouple the implementation of 
modules, such that (a) implementation can be plugged in and (b) the 
implementation modules themselves do not import each other; and are fully 
decoupled. Altogether, this makes Tango a very good choice as a 
mobile/modular library to target any kind of environment ... it was 
/designed/ as such from the beginning, and enjoyed a reasonably long 
gestation period to explore the various tradeoffs. What's missing from 
Tango, I understand, is something that's more familiar for those who prefer 
a free-function model? If so, then I think those folks will find incremental 
changes in Tango that are moving in that direction. In addition, I promised 
some folk at the D conference that model would be exposed somehow ... so it 
is, and will continue to happen :)

This is what prompted the earlier question: "what pieces of phobos would 
folks really like to see in Tango?". Or rephrased, What is it /about/ parts 
of phobos that some people prefer? I'm getting a good indication that 
certainly some people prefer the free-function aspect? I'd really like to 
hear more about that, particularly some specifics :)

I'm asking these questions because nobody has answered the questions posed 
in the origin of this thread. So instead, this is an exploration of a 
potentially different approach to a merge.

What sayeth thou?
Oct 10 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
Kris wrote:

 "Marcin Kuszczak" <aarti_nospam please_interia.pl> wrote in message 
 news:fejdk1$pvv$1 digitalmars.com...

 Kris wrote:



 And that's where the misconception comes in. The benefits in the high
 level of Tango are often based upon the capabilities in the "lower"
 levels. Which is why the earlier question had been posed about Tango I/O.
 You don't get Tango without the I/O package, because that is one of the
 definitive differences between the two libraries. In short, there's
 nothing in Phobos that Tango would benefit from. When it comes to I/O, 
 for
 example, Tango seriously outperforms every other library we've bothered 
 to
 test. When it comes to string processing, the same is true. This is due 
 to
 the design of Tango.


 I don't want to drop Tango IO. :-)

 Probably I express myself not enough clear with my idea. It would be great
 if you could comment on my replay to Larsivi:

 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=59960

 Thanks!


 
 
 Sure; the quick and easy answer it this: Tango is also a better /low-level/ 
 library than Phobos. Really, it is :)   If you want to get a thin library up 
 and running on a cell phone or whatever, Tango would totally be the right 
 choice. Why? Because the team went to great effort to make the library (a) 
 decoupled and (b) layered.  Not only is the so-called Runtime isolated and 
 is even packaged separately, but the middle and upper layers have limited 
 interdependencies amongst them.
 
 It's not Utopia, since there are always tradeoffs to make. For example, the 
 Tango logging package was previously distinct from the string formatting 
 package, so you didn't pay the price of the dependency unless *you* wanted 
 it. Well, recently, that changed because the benefit of coupling the two 
 outweighed the isolation benefit. That's a fair example of a trade-off that 
 was somewhat on the fence to begin with, and finally decided which side it 
 wanted to be on :)
 
 Elsewhere we use a small set of interfaces to decouple the implementation of 
 modules, such that (a) implementation can be plugged in and (b) the 
 implementation modules themselves do not import each other; and are fully 
 decoupled. Altogether, this makes Tango a very good choice as a 
 mobile/modular library to target any kind of environment ... it was 
 /designed/ as such from the beginning, and enjoyed a reasonably long 
 gestation period to explore the various tradeoffs. What's missing from 
 Tango, I understand, is something that's more familiar for those who prefer 
 a free-function model? If so, then I think those folks will find incremental 
 changes in Tango that are moving in that direction. In addition, I promised 
 some folk at the D conference that model would be exposed somehow ... so it 
 is, and will continue to happen :)
 
 This is what prompted the earlier question: "what pieces of phobos would 
 folks really like to see in Tango?". Or rephrased, What is it /about/ parts 
 of phobos that some people prefer? I'm getting a good indication that 
 certainly some people prefer the free-function aspect? I'd really like to 
 hear more about that, particularly some specifics :)
 
 I'm asking these questions because nobody has answered the questions posed 
 in the origin of this thread. So instead, this is an exploration of a 
 potentially different approach to a merge.
 
 What sayeth thou? 


I don't care about free functions versus objects, but I care about the 
amount of typing I have to do. And it seems that object names are about 
as long as function names, and method names are about as long as 
function names, so using an object-oriented interface involves twice as 
much typing.

If you had "alias formatln fln" in Print, for instance, I could just write:
Stdout.fln("whatever");

That's about a three character penalty above writefln, which I wouldn't 
notice. The current seven-character penalty is slightly annoying.

I don't like instantiating objects in order to do a simple test:
if (new FilePath(path).exists && !new FilePath(path).isFolder) {
    // do stuff
}

versus:
if (Path.exists(path) && Path.isFolder(path)) {
    // do stuff
}

Personally, I like having these singletons as a matter of organization. 
I could use static imports instead, though.
Oct 11 2007
parent reply "Kris" <foo bar.com> writes:
"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:fel8ir$1crd$1 digitalmars.com...

 I don't care about free functions versus objects, but I care about the 
 amount of typing I have to do. And it seems that object names are about as 
 long as function names, and method names are about as long as function 
 names, so using an object-oriented interface involves twice as much 
 typing.

 If you had "alias formatln fln" in Print, for instance, I could just 
 write:
 Stdout.fln("whatever");

 That's about a three character penalty above writefln, which I wouldn't 
 notice. The current seven-character penalty is slightly annoying.


Noted, and thank you



 I don't like instantiating objects in order to do a simple test:
 if (new FilePath(path).exists && !new FilePath(path).isFolder) {
    // do stuff
 }

 versus:
 if (Path.exists(path) && Path.isFolder(path)) {
    // do stuff
 }


This is definately a pain point I've heard often. The approach in Tango 
would be something like:

auto path = FilePath ("some path");
 if (path.exists && !path.isFolder) {
    // do stuff

That's not so bad, is it? But yeah, I'd really like to hear more about this 
one in particular, because it seems to be a litmus test in some ways. 
Thanks!
.
Oct 11 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to kris,


 "Christopher Wright" <dhasenan gmail.com> wrote in message
 news:fel8ir$1crd$1 digitalmars.com...
 

 I don't care about free functions versus objects, but I care about
 the amount of typing I have to do. And it seems that object names are
 about as long as function names, and method names are about as long
 as function names, so using an object-oriented interface involves
 twice as much typing.
 
 If you had "alias formatln fln" in Print, for instance, I could just
 write:
 Stdout.fln("whatever");
 That's about a three character penalty above writefln, which I
 wouldn't notice. The current seven-character penalty is slightly
 annoying.
 


 Noted, and thank you
 

 I don't like instantiating objects in order to do a simple test:
 if (new FilePath(path).exists && !new FilePath(path).isFolder) {
 // do stuff
 }
 versus:
 if (Path.exists(path) && Path.isFolder(path)) {
 // do stuff
 }


 This is definately a pain point I've heard often. The approach in
 Tango would be something like:
 
 auto path = FilePath ("some path");
 if (path.exists && !path.isFolder) {
 // do stuff
 That's not so bad, is it? But yeah, I'd really like to hear more about
 this
 one in particular, because it seems to be a litmus test in some ways.
 Thanks!
 .


with opImplicitCast you could get:

if (new FilePath(path).exists(path).isFolder(path))


using somthing like this:

class FilePath
{
    struct Sub
    {
        FilePath fp;
        bool val = true;
        Sub Predicate(...)
        {
           auto ret = *this;
           ret.val &= test;
           return ret;
        }
        bool opImplictCast(){return val;}
    }
    Sub opImplictCast(){Sub ret; ret.fp = this; return ret;}
}
Oct 11 2007
prev sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Kris wrote:

 "Christopher Wright" <dhasenan gmail.com> wrote in message 
 news:fel8ir$1crd$1 digitalmars.com...

 I don't care about free functions versus objects, but I care about the 
 amount of typing I have to do. And it seems that object names are about as 
 long as function names, and method names are about as long as function 
 names, so using an object-oriented interface involves twice as much 
 typing.

 If you had "alias formatln fln" in Print, for instance, I could just 
 write:
 Stdout.fln("whatever");

 That's about a three character penalty above writefln, which I wouldn't 
 notice. The current seven-character penalty is slightly annoying.


 
 Noted, and thank you
 
 

 I don't like instantiating objects in order to do a simple test:
 if (new FilePath(path).exists && !new FilePath(path).isFolder) {
    // do stuff
 }

 versus:
 if (Path.exists(path) && Path.isFolder(path)) {
    // do stuff
 }


 
 This is definately a pain point I've heard often. The approach in Tango 
 would be something like:
 
 auto path = FilePath ("some path");
  if (path.exists && !path.isFolder) {
     // do stuff
 
 That's not so bad, is it? 


Well.. if we make the assumption that isFolder will return false if is 
doesn't exist all you're really asking is:

if (isFolder("some path")) {

and if that is the extent of it then the free function is more 
appropriate, it's quicker, easier, involves no heap allocation, etc.

In a more complicated situation I would argue for the class but that's 
the point I'm trying to make, in some situations one is more appropriate 
than the other.

Regan

p.s. to my mind the amount of typing involved isn't really important as 
copy+paste has been my friend for a long time and auto-completion almost 
as long.
Oct 11 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Regan,



 
 p.s. to my mind the amount of typing involved isn't really important
 as copy+paste has been my friend for a long time and auto-completion
 almost as long.
 


as a bit of an aside: the amount of text it take to do something effect how 
much of a function I can put on my screen at any given time.
Oct 11 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
BCS wrote:

 as a bit of an aside: the amount of text it take to do something effect 
 how much of a function I can put on my screen at any given time.


No, no!
Even with a verbose standard library, your functions should always fit 
on one screen of text, except in a few extreme cases.

Or so the gods of test-driven development tell me.

I just don't want carpal tunnel before my time, so that means either 
praying for a more succinct naming convention in the stdlib, or getting 
Jetbrains to support D.
Oct 11 2007
parent BCS <ao pathlink.com> writes:
Reply to Christopher,


 BCS wrote:
 

 as a bit of an aside: the amount of text it take to do something
 effect how much of a function I can put on my screen at any given
 time.
 


 No, no!
 Even with a verbose standard library, your functions should always fit
 on one screen of text, except in a few extreme cases.
 Or so the gods of test-driven development tell me.


I'll grant you that, but sometime it just isn't worth it. (I have a function 
that is just a page and a half of switch statement with one or two ops per 
case. Yes that may be an indication of bad design but the alternatives that 
come to mind are worse)

If you lay out your code correctly and the function are short enough you 
can often get several related function on the screen at once. Also if the 
function is shorter (and does the same stuff) than I can put more comments 
at the top and still be able to see it all. A third thing is that I can read 
it faster with shorter names (less pan time for my eye-balls and less noise 
to filter). If you want to be really nit picky, it also should compile a 
bit faster.


 
 I just don't want carpal tunnel before my time, so that means either
 praying for a more succinct naming convention in the stdlib, or
 getting Jetbrains to support D.
Oct 11 2007
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Regan Heath wrote:

 
 p.s. to my mind the amount of typing involved isn't really important as 
 copy+paste has been my friend for a long time and auto-completion almost 
 as long.


It'd be the same for me if I could have like 8 things copied at once, 
but I can't.  I might be able to fix that, but it seems like I shouldn't 
have to.  So in essence I have more important things to spend my 
copy+paste on than Stdout.etcetcetc().

Code completion doesn't exist for me.  I still don't know where to find 
that lightweight, highly configurable, slick, IDE for D that runs on 
both Windows and Linux.  Until then, it's all about the ATEs.  Descent 
is tempting, but I don't like having to wait for my editor to open.
Oct 11 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chad J wrote:

 Descent 
 is tempting, but I don't like having to wait for my editor to open.


Easily fixed. Just don't close it :P.
Oct 11 2007
next sibling parent "Kris" <foo bar.com> writes:
Was gonna say the same thing :)


"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:femfo2$uig$1 digitalmars.com...

 Chad J wrote:

 Descent is tempting, but I don't like having to wait for my editor to 
 open.


 Easily fixed. Just don't close it :P.
Oct 11 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Frits van Bommel wrote:

 Chad J wrote:

 Descent is tempting, but I don't like having to wait for my editor to 
 open.


 
 Easily fixed. Just don't close it :P.


Any idea what's wrong with Eclipse? Why is the startup so unbelievably slow?
Seems to be about 25,000 million clock cycles!
(Is this typical of Java apps? It's the almost the only Java app I've ever
used).
What on earth is it doing? (Genuine question, not a flame).
Oct 12 2007
parent reply "Kris" <foo bar.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message news:fen7rf$17r7>


 Any idea what's wrong with Eclipse? Why is the startup so unbelievably 
 slow?
 Seems to be about 25,000 million clock cycles!
 (Is this typical of Java apps? It's the almost the only Java app I've ever 
 used).
 What on earth is it doing? (Genuine question, not a flame).



inspecting your licenses, Don :)
Oct 12 2007
parent Sean Kelly <sean f4.ca> writes:
Kris wrote:

 "Don Clugston" <dac nospam.com.au> wrote in message news:fen7rf$17r7>
 

 Any idea what's wrong with Eclipse? Why is the startup so unbelievably 
 slow?
 Seems to be about 25,000 million clock cycles!
 (Is this typical of Java apps? It's the almost the only Java app I've ever 
 used).
 What on earth is it doing? (Genuine question, not a flame).


 
 
 inspecting your licenses, Don :) 


Licenses!? We ain't got no licenses. We don't need no licenses! I don't 
have to show Eclipse any stinking licenses!!


Sean
Oct 12 2007
prev sibling parent "Kris" <foo bar.com> writes:
"Regan Heath" <regan netmail.co.nz> wrote in message 
news:felol1$2fte$1 digitalmars.com...

 Kris wrote:

 "Christopher Wright" <dhasenan gmail.com> wrote in message 
 news:fel8ir$1crd$1 digitalmars.com...

 I don't care about free functions versus objects, but I care about the 
 amount of typing I have to do. And it seems that object names are about 
 as long as function names, and method names are about as long as 
 function names, so using an object-oriented interface involves twice as 
 much typing.

 If you had "alias formatln fln" in Print, for instance, I could just 
 write:
 Stdout.fln("whatever");

 That's about a three character penalty above writefln, which I wouldn't 
 notice. The current seven-character penalty is slightly annoying.


 Noted, and thank you



 I don't like instantiating objects in order to do a simple test:
 if (new FilePath(path).exists && !new FilePath(path).isFolder) {
    // do stuff
 }

 versus:
 if (Path.exists(path) && Path.isFolder(path)) {
    // do stuff
 }


 This is definately a pain point I've heard often. The approach in Tango 
 would be something like:

 auto path = FilePath ("some path");
  if (path.exists && !path.isFolder) {
     // do stuff

 That's not so bad, is it?


 Well.. if we make the assumption that isFolder will return false if is 
 doesn't exist all you're really asking is:

 if (isFolder("some path")) {

 and if that is the extent of it then the free function is more 
 appropriate, it's quicker, easier, involves no heap allocation, etc.

 In a more complicated situation I would argue for the class but that's the 
 point I'm trying to make, in some situations one is more appropriate than 
 the other.

 Regan

 p.s. to my mind the amount of typing involved isn't really important as 
 copy+paste has been my friend for a long time and auto-completion almost 
 as long.



Point taken ... I was actually doing copy/paste myself, using the OP's 
example :)
Oct 11 2007