www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phango

reply "Janice Caron" <caron800 googlemail.com> writes:
I've started to like Tango, now that I've got bits of it working with Phobos :-)

With a bit of kludging, I've persuaded all of the examples in the
"console" and "text" directories to build with Phobos using DMD 2.007.
Of the examples files, only "properties.d" needed to be tweaked
slightly - and that was just to replace "char[]" with "string".

I think I'll attack the "conduits" folder next.

Anyway, someone tell me - does Tango have containers? If so, are there
any examples of use in the "examples" folder of the Tango download? I
couldn't find any.
Nov 15 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.70.1195164582.2338.digitalmars-d puremagic.com...
 I've started to like Tango, now that I've got bits of it working with 
 Phobos :-)

 With a bit of kludging, I've persuaded all of the examples in the
 "console" and "text" directories to build with Phobos using DMD 2.007.
 Of the examples files, only "properties.d" needed to be tweaked
 slightly - and that was just to replace "char[]" with "string".

 I think I'll attack the "conduits" folder next.

 Anyway, someone tell me - does Tango have containers? If so, are there
 any examples of use in the "examples" folder of the Tango download? I
 couldn't find any.

http://www.dsource.org/projects/tango/docs/current/ is useful indeed. Yes, there are containers, in tango.util.collection.
Nov 15 2007
parent Frank Benoit <keinfarbton googlemail.com> writes:
 I don't want docs, I want example source code. I want something I can
 compile, with tests to prove it's all working. Is there not a
 test-suite handy?

http://www.dsource.org/projects/tango/wiki/ChapterStorage and all the snippets are here examples/manual/chapterStorage.d
Nov 15 2007
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Janice Caron" wrote
 I've started to like Tango, now that I've got bits of it working with 
 Phobos :-)

 With a bit of kludging, I've persuaded all of the examples in the
 "console" and "text" directories to build with Phobos using DMD 2.007.
 Of the examples files, only "properties.d" needed to be tweaked
 slightly - and that was just to replace "char[]" with "string".

Just an FYI, some of us are working on a D 2.x compatible version of Tango. Basically the hard part is adding const. It's not release-ready yet, but I'm hoping once Walter has fixed const, we should be able to finish the port. Of course, it does not use Phobos... But hopefully that problem will be solved soon also. -Steve
Nov 15 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
I thought we agreed that this should be called "Phandango".  :-)

--bb
Nov 16 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Janice Caron wrote:
 On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:

 Just curious: why don't you use Tango and the freestanding functions of
 Phobos

Lot of reasons. (1) If an engine ain't broke, don't fix it.

Not to plug the Tango engine, but it does actually fix a number of bugs which are listed in the D bug tracker and have not been fixed in Phobos.
 (2) I like D2.007, and I'll be switching to D2.008 the day it comes out.
 
 (3) I hate Tango, stylisticly. I hate the mixed case module names, and
 the mixed case global variable names (e.g. Stdout). I want everything
 to look and feel like Phobos.

I'm not a huge fan of the mixed case global variable names either, but it does help them stand out, which I think is the point. The mixed case module names help make multi-word names more readable and also help distinguish from directories, which is an advantage in such a large library. The C module names have been left lowercase to match the original C names and to provide a visual distinction between the API layer and Tango.
 (4) Walter has been doing this for seven years or whatever, and has
 earned my greatest respect. Ripping out the innards of D scares the
 shit out of me - and not only that, I see no reason why I should have
 to.

For what it's worth, the Tango core is based on Ares, which began as a project perhaps four years ago (I've lost track). So the Tango runtime isn't perhaps quite as new as it may seem.
 This way, I get to use the latest cutting-edge version of D, I can
 make all the module names lowercase (yes, that matters!), and though
 things like Stdout(x).newline compile and run, I don't have to use
 them - I'll be able to throw in nicer looking functions that do the
 same thing.

This is what wrapper functions are for, in my opinion. But then Tango was created because of a dissatisfaction with Phobos, so I can't really object to a dissatisfaction with Tango ;-) Sean
Nov 16 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Janice Caron wrote:
 (3) I hate Tango, stylisticly. I hate the mixed case module names, and
 the mixed case global variable names (e.g. Stdout). I want everything
 to look and feel like Phobos.

I'm not a huge fan of the mixed case global variable names either, but it does help them stand out, which I think is the point.

Mixed case package/module names are avoided because there needs to be a 1:1 correspondence between file names and package/module names, and not all file systems are case sensitive (like FAT32 and NTFS, for a couple widely used examples).
Nov 18 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Sean Kelly wrote:
 Janice Caron wrote:
 (3) I hate Tango, stylisticly. I hate the mixed case module names, and
 the mixed case global variable names (e.g. Stdout). I want everything
 to look and feel like Phobos.

I'm not a huge fan of the mixed case global variable names either, but it does help them stand out, which I think is the point.

Mixed case package/module names are avoided because there needs to be a 1:1 correspondence between file names and package/module names, and not all file systems are case sensitive (like FAT32 and NTFS, for a couple widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and thus you need to be aware of which case you use in either case, rendering the argument moot. Early on in D history, I encountered several cases of modules being saved on Windows, then not working on Linux with their intended module names due to this. And this can only happen if the Windows programmer typed in a file name with upper case letters, even though the module name was all lower case. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Nov 18 2007
parent reply torhu <no spam.invalid> writes:
Lars Ivar Igesund wrote:
  >> Mixed case package/module names are avoided because there needs to be a
 1:1 correspondence between file names and package/module names, and not
 all file systems are case sensitive (like FAT32 and NTFS, for a couple
 widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and thus you need to be aware of which case you use in either case, rendering the argument moot. Early on in D history, I encountered several cases of modules being saved on Windows, then not working on Linux with their intended module names due to this. And this can only happen if the Windows programmer typed in a file name with upper case letters, even though the module name was all lower case.

I believe Walter's point is that "all package and module names are lower case" is a simple rule that will help us avoid this problem, given that everyone does their best to adhere to the rule. I don't know how much it matters, since I've never run into the problem myself. But I just tried it, and it shouldn't be hard to track down the problem based on the compiler's error messages. Not a big deal either way, it seems.
Nov 18 2007
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
torhu wrote:

 Lars Ivar Igesund wrote:
   >> Mixed case package/module names are avoided because there needs to be
   >> a
 1:1 correspondence between file names and package/module names, and not
 all file systems are case sensitive (like FAT32 and NTFS, for a couple
 widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and thus you need to be aware of which case you use in either case, rendering the argument moot. Early on in D history, I encountered several cases of modules being saved on Windows, then not working on Linux with their intended module names due to this. And this can only happen if the Windows programmer typed in a file name with upper case letters, even though the module name was all lower case.

I believe Walter's point is that "all package and module names are lower case" is a simple rule that will help us avoid this problem, given that everyone does their best to adhere to the rule. I don't know how much it matters, since I've never run into the problem myself. But I just tried it, and it shouldn't be hard to track down the problem based on the compiler's error messages. Not a big deal either way, it seems.

Yes, I see his point. My point is that there is no difference from having that as a rule, and CamelCased module names as a rule :) In both cases you need to adhere to it. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Nov 18 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
torhu wrote:
 Lars Ivar Igesund wrote:
  >> Mixed case package/module names are avoided because there needs to be a
 1:1 correspondence between file names and package/module names, and not
 all file systems are case sensitive (like FAT32 and NTFS, for a couple
 widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and thus you need to be aware of which case you use in either case, rendering the argument moot. Early on in D history, I encountered several cases of modules being saved on Windows, then not working on Linux with their intended module names due to this. And this can only happen if the Windows programmer typed in a file name with upper case letters, even though the module name was all lower case.

I believe Walter's point is that "all package and module names are lower case" is a simple rule that will help us avoid this problem, given that everyone does their best to adhere to the rule. I don't know how much it matters, since I've never run into the problem myself. But I just tried it, and it shouldn't be hard to track down the problem based on the compiler's error messages. Not a big deal either way, it seems.

There is another issue. Often a module has basically only one main class in it. If the main class is called Foo, and that's all that's in the module, some version of "Foo" is the logical name for the package too. But then if you use fully qualified names you end up with Package.Foo.Foo when referring to the class in the module, which just look *so* silly that it's easy to forget the second Foo. But package.foo.Foo looks more reasonable, since it's clear the second to last "foo" is not a class name. --bb
Nov 18 2007
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Baxter wrote:

 torhu wrote:
 Lars Ivar Igesund wrote:
  >> Mixed case package/module names are avoided because there needs to be
  >> a
 1:1 correspondence between file names and package/module names, and not
 all file systems are case sensitive (like FAT32 and NTFS, for a couple
 widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and thus you need to be aware of which case you use in either case, rendering the argument moot. Early on in D history, I encountered several cases of modules being saved on Windows, then not working on Linux with their intended module names due to this. And this can only happen if the Windows programmer typed in a file name with upper case letters, even though the module name was all lower case.

I believe Walter's point is that "all package and module names are lower case" is a simple rule that will help us avoid this problem, given that everyone does their best to adhere to the rule. I don't know how much it matters, since I've never run into the problem myself. But I just tried it, and it shouldn't be hard to track down the problem based on the compiler's error messages. Not a big deal either way, it seems.

There is another issue. Often a module has basically only one main class in it. If the main class is called Foo, and that's all that's in the module, some version of "Foo" is the logical name for the package too. But then if you use fully qualified names you end up with Package.Foo.Foo when referring to the class in the module, which just look *so* silly that it's easy to forget the second Foo. But package.foo.Foo looks more reasonable, since it's clear the second to last "foo" is not a class name. --bb

Using fully qualified class names are very seldom necessary in D, I find using renaming imports are much more useful. I'd like to turn your argument the other way round: If you do import package.Foo; then it make a lot of sense that you can just use your class Foo. I understand that this may have been uncommon for those coming from C, but I know of several C++ libraries (Object oriented) using header files with capitalized names, Qt and Coin3D (Open Inventor) comes to mind. Qt wasn't always this way, but changed with version 4. OI I think always did this, and it is 15+ years old. Indeed, its top level package is "Inventor"! FWIW, I think SGI and TrollTech is two of very few companies that have created truly good library API's in C++. I could of course also pull in Java and C# as examples, but those are weirdly enough disregarded in this debate. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Nov 18 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Lars Ivar Igesund wrote:
 Bill Baxter wrote:
 
 torhu wrote:
 Lars Ivar Igesund wrote:
  >> Mixed case package/module names are avoided because there needs to be
  >> a
 1:1 correspondence between file names and package/module names, and not
 all file systems are case sensitive (like FAT32 and NTFS, for a couple
 widely used examples).

thus you need to be aware of which case you use in either case, rendering the argument moot. Early on in D history, I encountered several cases of modules being saved on Windows, then not working on Linux with their intended module names due to this. And this can only happen if the Windows programmer typed in a file name with upper case letters, even though the module name was all lower case.

case" is a simple rule that will help us avoid this problem, given that everyone does their best to adhere to the rule. I don't know how much it matters, since I've never run into the problem myself. But I just tried it, and it shouldn't be hard to track down the problem based on the compiler's error messages. Not a big deal either way, it seems.

class in it. If the main class is called Foo, and that's all that's in the module, some version of "Foo" is the logical name for the package too. But then if you use fully qualified names you end up with Package.Foo.Foo when referring to the class in the module, which just look *so* silly that it's easy to forget the second Foo. But package.foo.Foo looks more reasonable, since it's clear the second to last "foo" is not a class name. --bb

Using fully qualified class names are very seldom necessary in D, I find using renaming imports are much more useful.

Ok, but then the most obvious name for the renamed import is the last component of the dot-separated module name: import Foo = Package.Name.Too.Long.Foo; ... Foo.Foo Of course you could rename the module lower-case 'foo', but you could also just have named it in lowercase from the beginning. Or you could come up with some other convention. But anyway, I agree that in Tango the package names are so long that static import is impractical. But for other libraries that's not the case, and I think what a lot of people are after here is a convention that's universally applicable. I use static import all the time in my code because Phobos' flatter naming works well with that, and my own code also is usually only 1 or 2 levels deep. But I also use renamed and selective imports too, depending how much stuff I plan to use from the module. [As an aside I really wish I could do renamed and selective importing on one line, like import mod=some.long.module : Foo, Bar; ] Saying "don't use static import" isn't a very strong argument for the Tango naming convention in my opinion.
 I'd like to turn your argument
 the other way round: If you do
 
 import package.Foo;
 
 then it make a lot of sense that you can just use your class Foo. 

If that were the only way to do imports in D, then that would make a lot of sense. But we also have static, renamed, and selective imports and their use should be encouraged. They help keep the top-level namespace clean, and help make code more readable by specifying explicitly where symbols are coming from.
 I
 understand that this may have been uncommon for those coming from C, but I
 know of several C++ libraries (Object oriented) using header files with
 capitalized names, Qt and Coin3D (Open Inventor) comes to mind. Qt wasn't
 always this way, but changed with version 4. OI I think always did this,
 and it is 15+ years old. Indeed, its top level package is "Inventor"!
 FWIW, I think SGI and TrollTech is two of very few companies that have
 created truly good library API's in C++.

The comparison with C++ is not valid because in C++ namespaces and file names are decoupled. So in C++ something like #include<Package/SubPackage/ClassName.h> will generally put the ClassName into the Package::SubPackage namespace. Or sometimes just the Package namespace. I've never seen anyone create a Package::SubPackage::ClassName namespace to enclose a class called ClassName. But in D you don't have a choice. The full path always becomes part of the namespace.
 I could of course also pull in Java and C# as examples, but those are
 weirdly enough disregarded in this debate.

I don't remember enough about how Java imports worked to comment, and I've never touched C#. --bb
Nov 18 2007
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Baxter wrote:

 Lars Ivar Igesund wrote:
 
 Using fully qualified class names are very seldom necessary in D, I find
 using renaming imports are much more useful.

Ok, but then the most obvious name for the renamed import is the last component of the dot-separated module name: import Foo = Package.Name.Too.Long.Foo; ... Foo.Foo Of course you could rename the module lower-case 'foo', but you could also just have named it in lowercase from the beginning. Or you could come up with some other convention. But anyway, I agree that in Tango the package names are so long that static import is impractical. But for other libraries that's not the case, and I think what a lot of people are after here is a convention that's universally applicable. I use static import all the time in my code because Phobos' flatter naming works well with that, and my own code also is usually only 1 or 2 levels deep. But I also use renamed and selective imports too, depending how much stuff I plan to use from the module. [As an aside I really wish I could do renamed and selective importing on one line, like import mod=some.long.module : Foo, Bar; ]

I think it does? At least I think the spec allows it.
 
 Saying "don't use static import" isn't a very strong argument for the
 Tango naming convention in my opinion.

Never liked static imports :P The static keyword is probably part of that :)
 
 I'd like to turn your argument
 the other way round: If you do
 
 import package.Foo;
 
 then it make a lot of sense that you can just use your class Foo.

If that were the only way to do imports in D, then that would make a lot of sense. But we also have static, renamed, and selective imports and their use should be encouraged. They help keep the top-level namespace clean, and help make code more readable by specifying explicitly where symbols are coming from.
 I
 understand that this may have been uncommon for those coming from C, but
 I know of several C++ libraries (Object oriented) using header files with
 capitalized names, Qt and Coin3D (Open Inventor) comes to mind. Qt wasn't
 always this way, but changed with version 4. OI I think always did this,
 and it is 15+ years old. Indeed, its top level package is "Inventor"!
 FWIW, I think SGI and TrollTech is two of very few companies that have
 created truly good library API's in C++.

The comparison with C++ is not valid because in C++ namespaces and file names are decoupled. So in C++ something like #include<Package/SubPackage/ClassName.h> will generally put the ClassName into the Package::SubPackage namespace. Or sometimes just the Package namespace. I've never seen anyone create a Package::SubPackage::ClassName namespace to enclose a class called ClassName. But in D you don't have a choice. The full path always becomes part of the namespace.
 I could of course also pull in Java and C# as examples, but those are
 weirdly enough disregarded in this debate.

I don't remember enough about how Java imports worked to comment, and I've never touched C#.

I'll withdraw C# from the discussion, as I don't know all aspects well enough. Java however requires module names to equal class names, whether they are lowercased or CamelCased. I may agree that such comparisons possibly aren't entirely applicable though, considering modules in D are much more important than in those languages. They are encapsulated entities themselves after all. Which, if used as such, would imply that casing should be the same as for classes and structs. I'll accept this match to end with a remis though, so I can stop posting about this :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Nov 18 2007
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
It is interesting to see how such a trivial thing as the capitalization 
of module names can lead to a much more involved discussion than any of 
Tango's technical merits ever have (possibly with one exception). It is 
somewhat like making a choice between two equipment manufacturers from 
the colors they use on the buttons. But form and style seems to be of 
undervalued importance, and maybe there is more to this issue than it 
appears. Either way, I cannot refrain from writing something about it 
too. :)

Lars Ivar Igesund wrote:

 Using fully qualified class names are very seldom necessary in D, I find
 using renaming imports are much more useful. I'd like to turn your argument
 the other way round: If you do
 
 import package.Foo;
 
 then it make a lot of sense that you can just use your class Foo. 

What says that the module package.Foo contains a class named Foo? Most of my own modules contain no classes at all, and many that do contain more than one class. I know that (with different qualifiers), that is true for Tango as well. I wouldn't encourage module renaming, at least not without guidelines for how things should be renamed. Lots of people making up their own custom abbreviations for the same long module names can't lead to something good. I am personally quite fond of using FQN (fully qualified names) in certain situations, but names such as tango.util.collection.iterator.InterleavingIterator.InterleavingIterator make that a tad inconvenient. :) Three design choices in Tango seem to be: * deep rather than shallow package hierarchy * descriptive rather than abbreviated package names * highly fragmented modules In some ways, I tend to feel those three points are misdirected, or at least taken a bit too far. What are the reasons for dividing things into modules? First and foremost, functionally independent parts should be separated so that one can be replaced or used independent of the others. Secondly, there are some issues with compile times and object file sizes, and the third reason is convenience for the implementors. The reasons mentioned are in descending order of importance. A library should always be designed for its users, rather than for its implementers. We humans, psychologically, tend not to be very hierarchical in our categorization of the world. There is a basic level of categorization that is the one most readily named and first learned (bird, cat, car). The function of a categorization should be to provide the maximum amount of information with the least amount of cognitive effort. The more fine grained a categorization is, the more cognitive effort is needed. The conclusion is that it would be cognitively advantageous to only separate library entities into different modules if there is a relevant reason to do so (for the purposes at hand). I believe shallow hierarchies generally are better than deep, and also that there should be a functional rather than logical separation between packages. So, instead of: tango.util.collection.iterator.InterleavingIterator couldn't there just be: tango.collection.iterators or perhaps even: tango.collection An interesting parallel is the taxonomy of plants and animals from the 18th century. The Linnaean taxonomy is a highly hierarchical classification, where for instance the common snowdrop is classified as: Plantae.Magnoliophyta.Liliopsida.Asparagales.Amaryllidaceae. Galanthus.nivalis But such names were considered too unwieldy to use in full, so a concise binomial nomenclature was used as a supplement. The same snowdrop as above in binomials is just: Galanthus.nivalis Regarding capitalized module names: As far as I see it, there are entities (functions, classes, etc) and modules (std.string, tango.text.convert.Format). I don't really see the point of making a distinction between modules and packages, and therefore can't really see a point in capitalizing the last part of the module name only. But on the other hand, there is a precedent in the binomials above -- only the other way around. :)
 I could of course also pull in Java and C# as examples, but those are
 weirdly enough disregarded in this debate.

Not so weird for Java at least (I don't know C# well enough to comment). Java (more or less) forces file names to be identical to the sole public class in them. There are no modules in java, just classes, and since classes are capitalized, so are the file names. To end, I think it speaks very highly of Tango that the only issues being actively debated are the purely stylistic ones. -- Oskar
Nov 18 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Oskar Linde wrote:
 To end, I think it speaks very highly of Tango that the only issues 
 being actively debated are the purely stylistic ones.

It's normal for easily understood issues to get a lot more comments than the ones that need more work to grok. However, silence is the worst case <g>. It means nobody has even looked at it.
Nov 19 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
David Wilson wrote:
 On 11/19/07, Walter Bright <newshound1 digitalmars.com> wrote:
 Oskar Linde wrote:
 To end, I think it speaks very highly of Tango that the only issues
 being actively debated are the purely stylistic ones.

the ones that need more work to grok.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING

Spot on.
Nov 19 2007
prev sibling parent Matti Niemenmaa <see_signature for.real.address> writes:
Oskar Linde wrote:
 I believe shallow hierarchies generally are better than deep, and also
 that there should be a functional rather than logical separation between
 packages.
 
 So, instead of:
 
 tango.util.collection.iterator.InterleavingIterator
 
 couldn't there just be:
 
 tango.collection.iterators
 
 or perhaps even:
 
 tango.collection

One problem with shoving all iterators into one module is the way the protection specifiers work in D. As you probably know, private and co are module-level. This means that InterleavingIterator and TropicalJungleIterator, while completely distinct, can access each other's privates! The fact that they are in different modules thus accentuates their independence of each other. If protection specifiers worked as they do in C++ (and, as a matter of fact, in just about every other language I know of that implements such a feature), then a "tango.collection.iterators" package would make more sense. As it is, putting two classes into the same module suggests that they are tightly coupled and, at least to me, that they do access each other's private members. Plus, especially a general-purpose module such as "tango.collection" would grow to thousands of lines in length. This would make it a pain to code in, but there are also issues for the user. For instance, the automatically generated DDoc would also be exceedingly long and would have to manually be separated into coherent parts. I do agree that the "tango.util.collection" package should be just "tango.collection", though. :-) -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Nov 20 2007
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
I actuallBill Baxter wrote:
 torhu wrote:
 Lars Ivar Igesund wrote:
  >> Mixed case package/module names are avoided because there needs to 
 be a
 1:1 correspondence between file names and package/module names, and not
 all file systems are case sensitive (like FAT32 and NTFS, for a couple
 widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and thus you need to be aware of which case you use in either case, rendering the argument moot. Early on in D history, I encountered several cases of modules being saved on Windows, then not working on Linux with their intended module names due to this. And this can only happen if the Windows programmer typed in a file name with upper case letters, even though the module name was all lower case.

I believe Walter's point is that "all package and module names are lower case" is a simple rule that will help us avoid this problem, given that everyone does their best to adhere to the rule. I don't know how much it matters, since I've never run into the problem myself. But I just tried it, and it shouldn't be hard to track down the problem based on the compiler's error messages. Not a big deal either way, it seems.

There is another issue. Often a module has basically only one main class in it. If the main class is called Foo, and that's all that's in the module, some version of "Foo" is the logical name for the package too. But then if you use fully qualified names you end up with Package.Foo.Foo when referring to the class in the module, which just look *so* silly that it's easy to forget the second Foo. But package.foo.Foo looks more reasonable, since it's clear the second to last "foo" is not a class name.

I actually think both package.foo.Foo and package.Foo.Foo look bizarre. I've always disliked this part of D. In that light, I think it really is more a shortcoming of the way D does namespaces. Tango just tries to work around this (for good or bad... there's seems little choice in the matter: I believe tango developers and others haggled over this and other issues long and hard in the past: it wasn't an easy decision). I'm not sure what might be a good solution to these problems without "fixing" D. Maybe a more C++ style (horrors!! did I say that?!) would be useful in differentiating module namespace from class? I'm not sure... but that would mean a another D spec change: such as package.foo::Foo as a reference to class Foo (or whatever other symbol one wants to specify) or package.foo:: as an implied reference to whatever symbol has the same name as module name... in this case "foo". If module name "Foo" is capitalized, therefore, the class or symbol with "Foo" would be selected. Just some thoughts, John
Nov 18 2007
parent reply Don Clugston <dac nospam.com.au> writes:
John Reimer wrote:
 

John, it's great to see you back! I feared you were gone forever. - Don.
Nov 20 2007
parent reply John Reimer <terminal.node gmail.com> writes:
Don Clugston wrote:
 John Reimer wrote:

John, it's great to see you back! I feared you were gone forever. - Don.

Don, You are too kind. :-) I almost figured I was gone for good too, but it's hard to stay away from the techy side of life for too long... and D is smack in the center of it. Life has been very busy, especially because I'm now apprenticing in log home construction (www.pioneerloghomesofbc.com) ... a welcome change from paramedic work (yes, a very unusual change in employment yet fascinating, nonetheless; it's great to have the opportunity to pick up these kind of skills). Anyway, due to winter finally setting in, my work hours are shorter. Thus, I've managed a time-slice for D lurking again among other things (and hopefully a continuation of some documentation effort). :-D It's great to see the rapid growth that's been happening around D. Looks like you have been as creative and productive as ever. ;-) More exciting things to come from your end, I can only imagine. Great to hear from you too, Don. :-) Take care, John
Nov 20 2007
parent reply John Reimer <terminal.node gmail.com> writes:
John Reimer wrote:
 Don Clugston wrote:
 John Reimer wrote:

John, it's great to see you back! I feared you were gone forever. - Don.

Don, You are too kind. :-) I almost figured I was gone for good too, but it's hard to stay away from the techy side of life for too long... and D is smack in the center of it. Life has been very busy, especially because I'm now apprenticing in log home construction (www.pioneerloghomesofbc.com) ... a welcome change from paramedic work (yes, a very unusual change in employment yet fascinating, nonetheless; it's great to have the opportunity to pick up these kind of skills). Anyway, due to winter finally setting in, my work hours are shorter. Thus, I've managed a time-slice for D lurking again among other things (and hopefully a continuation of some documentation effort). :-D It's great to see the rapid growth that's been happening around D. Looks like you have been as creative and productive as ever. ;-) More exciting things to come from your end, I can only imagine. Great to hear from you too, Don. :-) Take care, John

*sigh* Looking over this thread, I am reminded of the major reason that I left in the first place (of course, I was partly responsible for it last time). :-( Human nature is so ugly.
Nov 21 2007
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
John Reimer wrote:
 John Reimer wrote:
 Don Clugston wrote:
 John Reimer wrote:

John, it's great to see you back! I feared you were gone forever. - Don.

Don, You are too kind. :-) I almost figured I was gone for good too, but it's hard to stay away from the techy side of life for too long... and D is smack in the center of it. Life has been very busy, especially because I'm now apprenticing in log home construction (www.pioneerloghomesofbc.com) ... a welcome change from paramedic work (yes, a very unusual change in employment yet fascinating, nonetheless; it's great to have the opportunity to pick up these kind of skills). Anyway, due to winter finally setting in, my work hours are shorter. Thus, I've managed a time-slice for D lurking again among other things (and hopefully a continuation of some documentation effort). :-D It's great to see the rapid growth that's been happening around D. Looks like you have been as creative and productive as ever. ;-) More exciting things to come from your end, I can only imagine. Great to hear from you too, Don. :-) Take care, John

*sigh* Looking over this thread, I am reminded of the major reason that I left in the first place (of course, I was partly responsible for it last time). :-( Human nature is so ugly.

Indeed. Your brief exit message on Tango was painful to read. "Bad advertisement for D" as you deleted your name. Ouch. Especially since it was a post by you (on a C++ ng I think) that made me give D a chance in the first place. That's why I'm here. -Don.
Nov 21 2007
parent reply Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 John Reimer wrote:
 Human nature is so ugly.

Indeed. Your brief exit message on Tango was painful to read. "Bad advertisement for D" as you deleted your name. Ouch. Especially since it was a post by you (on a C++ ng I think) that made me give D a chance in the first place. That's why I'm here.

Yup. John has always been a valuable member of the D community. I was very disappointed to see him leave, though I can understand why one would not want to deal with the drama. Sean
Nov 21 2007
parent "Kris" <foo bar.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
 Don Clugston wrote:
 John Reimer wrote:
 Human nature is so ugly.

Indeed. Your brief exit message on Tango was painful to read. "Bad advertisement for D" as you deleted your name. Ouch. Especially since it was a post by you (on a C++ ng I think) that made me give D a chance in the first place. That's why I'm here.

Yup. John has always been a valuable member of the D community. I was very disappointed to see him leave, though I can understand why one would not want to deal with the drama.

Yeah, I fully agree. Good to see him back here!
Nov 21 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
John Reimer wrote:
 
 *sigh*
 
 Looking over this thread, I am reminded of the major reason that I left 
 in the first place (of course, I was partly responsible for it last 
 time). :-(
 
 Human nature is so ugly.

Fortunately, with usenet, not being a part of the discussion is as simple as "mark all read." Sean
Nov 21 2007
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Janice Caron wrote:
 (3) I hate Tango, stylisticly. I hate the mixed case module names, and
 the mixed case global variable names (e.g. Stdout). I want everything
 to look and feel like Phobos.

I'm not a huge fan of the mixed case global variable names either, but it does help them stand out, which I think is the point.

Mixed case package/module names are avoided because there needs to be a 1:1 correspondence between file names and package/module names, and not all file systems are case sensitive (like FAT32 and NTFS, for a couple widely used examples).

The only way to solve this is to have the DMD frontend do case-insensitive matching of imports. As it stands, I should be able to say 'import STD.STDIO;' on Windows/ntfs and have it work, but have it fail when using ext3. (I don't have a copy of Windows, so I can't check; and I don't feel like making a case-insensitive fs on my machine right now. I don't think you put in an explicit check for accurate case, since if you typed in a command line 'cd phobos/StD/', Windows might update the case of the folder name.) This would have a minor benefit of allowing people using tango to write 'import tango.io.stdout;', but using a standard convention also works decently. It's just that different projects use different conventions, and I can't use both in my project because of the case insensitive file systems.
Nov 18 2007
parent Matti Niemenmaa <see_signature for.real.address> writes:
Christopher Wright wrote:
 Walter Bright wrote:
 Mixed case package/module names are avoided because there needs to be
 a 1:1 correspondence between file names and package/module names, and
 not all file systems are case sensitive (like FAT32 and NTFS, for a
 couple widely used examples).

The only way to solve this is to have the DMD frontend do case-insensitive matching of imports. As it stands, I should be able to say 'import STD.STDIO;' on Windows/ntfs and have it work, but have it fail when using ext3. (I don't have a copy of Windows, so I can't check; and I don't feel like making a case-insensitive fs on my machine right now. I don't think you put in an explicit check for accurate case, since if you typed in a command line 'cd phobos/StD/', Windows might update the case of the folder name.) This would have a minor benefit of allowing people using tango to write 'import tango.io.stdout;', but using a standard convention also works decently. It's just that different projects use different conventions, and I can't use both in my project because of the case insensitive file systems.

import StD.sTdIo; void main() { writefln("hello world"); } Compiles and runs on Windows. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Nov 18 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Janice Caron wrote:
 On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
 
 As said - you could as well put the Phobos sources into Tango's std
 folder and *tweak* those.

As I mentioned, I did not copy tango's std folder at all. I am doing without it.

So do you have a /std directory at all? I would hope so, or some portions of Tango won't work. The instrinsic functions, for example, must have a mangled name that begins with "std". This is unfortunate, but what can you do. Sean
Nov 16 2007
parent Sean Kelly <sean f4.ca> writes:
Janice Caron wrote:
 On 11/16/07, Sean Kelly <sean f4.ca> wrote:
 
 As I mentioned, I did not copy tango's std folder at all. I am doing
 without it.


I have Phobos's std directory. It is completely unchanged and intact. (And obviously it will be updated the moment D2.008 comes along).

Oh, that's fine then. The /std directory included with Tango just contains cleaned-up copies of the Phobos files Tango needs. Sean
Nov 16 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 "Janice Caron" wrote
 I've started to like Tango, now that I've got bits of it working with 
 Phobos :-)

 With a bit of kludging, I've persuaded all of the examples in the
 "console" and "text" directories to build with Phobos using DMD 2.007.
 Of the examples files, only "properties.d" needed to be tweaked
 slightly - and that was just to replace "char[]" with "string".

Just an FYI, some of us are working on a D 2.x compatible version of Tango. Basically the hard part is adding const. It's not release-ready yet, but I'm hoping once Walter has fixed const, we should be able to finish the port. Of course, it does not use Phobos... But hopefully that problem will be solved soon also.

The const stuff is changing significantly (for the much better, I hope), so be prepared to do another pass over it if you are adapting it to const. I've found the necessary changes to the source to be simple to do (and they are flagged by the compiler), so it shouldn't be a problem.
Nov 18 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/15/07, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 Just an FYI, some of us are working on a D 2.x compatible version of Tango.

Yeah, well that's kind of what I did. I took the source in the "tango" dir (i.e. not the "std" dir, not "object.d"), and then did foreach(example) while(does not compile) fix_first_error()
 Basically the hard part is adding const.

I noticed. I liberally added const and invariant everywhere I could get away with it. It takes some fine tuning to get it right. D strings are invariant now, so I had to throw in some idups in places where I couldn't prove to myself that the original was actually unique. I also changed toUtf to toString, and changed all the module names to lowercase.
 It's not release-ready yet, but I'm hoping once Walter has fixed const, we
 should be able to finish the port.

I'm working with 2.007. I assume it will be not too hard to upgrade.
 Of course, it does not use Phobos...

Mine does. I specifically do not use Tango's object.d, nor anything in Tango's std. I'm importing phobos and my bastardised version of Tango simultaneously. It's actually quite fun.
Nov 15 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/15/07, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:
 Anyway, someone tell me - does Tango have containers? If so, are there
 any examples of use in the "examples" folder of the Tango download? I
 couldn't find any.

http://www.dsource.org/projects/tango/docs/current/ is useful indeed. Yes, there are containers, in tango.util.collection.

I don't want docs, I want example source code. I want something I can compile, with tests to prove it's all working. Is there not a test-suite handy?
Nov 15 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/15/07, Frank Benoit <keinfarbton googlemail.com> wrote:
 and all the snippets are here

 examples/manual/chapterStorage.d

That's what I was looking for! Great! :-) The folder name ("manual") didn't really make it obvious what was in it. Guess I'll attack that one next.
Nov 15 2007
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Thu, 15 Nov 2007 23:09:55 +0000
"Janice Caron" <caron800 googlemail.com> wrote:
 Of course, it does not use Phobos...

Mine does. I specifically do not use Tango's object.d, nor anything in Tango's std. I'm importing phobos and my bastardised version of Tango simultaneously.

Actually, the core of Tango is in tango.core - the std/ folder is just there because DMD requires the intrinsic module to be there, IIRC. Just curious: why don't you use Tango and the freestanding functions of Phobos (AFAIK most of them interface with C, anyways - which can be done in Tango, too, of course)? I suppose that would be less work to achieve the same goal (oh, and btw, you'll have a less buggy runtime.. /me hides.) Kind regards -- Alexander Panek <alexander.panek brainsware.org>
Nov 15 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
 Actually, the core of Tango is in tango.core

Yeah, I've tweaked my copies of several of files in core already.
 - the std/ folder is just
 there because DMD requires the intrinsic module to be there, IIRC.

I didn't understand that, but hey ho. In any case, the original Phobos std is still there in my case.
 Just curious: why don't you use Tango and the freestanding functions of
 Phobos

Lot of reasons. (1) If an engine ain't broke, don't fix it. (2) I like D2.007, and I'll be switching to D2.008 the day it comes out. (3) I hate Tango, stylisticly. I hate the mixed case module names, and the mixed case global variable names (e.g. Stdout). I want everything to look and feel like Phobos. (4) Walter has been doing this for seven years or whatever, and has earned my greatest respect. Ripping out the innards of D scares the shit out of me - and not only that, I see no reason why I should have to. This way, I get to use the latest cutting-edge version of D, I can make all the module names lowercase (yes, that matters!), and though things like Stdout(x).newline compile and run, I don't have to use them - I'll be able to throw in nicer looking functions that do the same thing.
Nov 16 2007
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Fri, 16 Nov 2007 08:17:42 +0000
"Janice Caron" <caron800 googlemail.com> wrote:

 On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
 Actually, the core of Tango is in tango.core

Yeah, I've tweaked my copies of several of files in core already.

My apologies - ... tweaked?
 - the std/ folder is just
 there because DMD requires the intrinsic module to be there, IIRC.

I didn't understand that, but hey ho. In any case, the original Phobos std is still there in my case.

As said - you could as well put the Phobos sources into Tango's std folder and *tweak* those.
 Just curious: why don't you use Tango and the freestanding
 functions of Phobos

Lot of reasons. (1) If an engine ain't broke, don't fix it.

I think there are people who definitely wouldn't agree on that. But I am not in the qualified position to argue about that.
 (3) I hate Tango, stylisticly. I hate the mixed case module names, and
 the mixed case global variable names (e.g. Stdout). I want everything
 to look and feel like Phobos.

No comment on that.
 (4) Walter has been doing this for seven years or whatever, and has
 earned my greatest respect. Ripping out the innards of D scares the
 shit out of me - and not only that, I see no reason why I should have
 to.

It scares you? Why?
 This way, I get to use the latest cutting-edge version of D, I can
 make all the module names lowercase (yes, that matters!), and though
 things like Stdout(x).newline compile and run, I don't have to use
 them - I'll be able to throw in nicer looking functions that do the
 same thing.

You know, there's still printf in tango.stdc.stdio ..... just in case. :P -- Alexander Panek <alexander.panek brainsware.org>
Nov 16 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/16/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:
 I thought we agreed that this should be called "Phandango".  :-)

Well, there isn't really an "it". I was actually getting this working just for me. I wasn't planning on uploading it anywhere because the /real/ Tango is being made Phobos compatible, as I understand it, and we should all just wait for that. Anyone who's impatient could do what I did, I guess, or maybe I could show my source anyway, but I make no claims that it's in any way "official". As for the name, it is the work of /seconds/ to search and replace, and name it anything you want.
Nov 16 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
 On Fri, 16 Nov 2007 08:17:42 +0000
 "Janice Caron" <caron800 googlemail.com> wrote:

 On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
 Actually, the core of Tango is in tango.core

Yeah, I've tweaked my copies of several of files in core already.

My apologies - ... tweaked?

Well yeah. As I said at the start of this thread, what I did was: foreach(example) while(does not compile) fix_first_error() So if the compiler tells me that A won't cast to B because of some invariant issue or some-such, then I modified the source in the offending file. If that happened to be tango.core (actually I renamed it phango.core to avoid confusion) then so be it.
 As said - you could as well put the Phobos sources into Tango's std
 folder and *tweak* those.

As I mentioned, I did not copy tango's std folder at all. I am doing without it. I am not interested in messing around with D's standard library (Phobos) in any way. In fact, I sometimes have had to call on its services (e.g. std.contracts.assumeUnique()) to get things to compile.
 It scares you? Why?

Because it might stop something upon which I already rely from working
 You know, there's still printf in tango.stdc.stdio ..... just in

True. But that's not really an issue for what I'm doing. If I can be bothered, I might find a way to add cout.writefln() and stdout.writefln() or whatever, to give me Phobos syntax with Tango's streams. But right now I've still got Phobos's writef() and writefln() functions at my disposal, so I'm perfectly happy. Besides ... printf()? Now there's a function that really should be deprecated!
Nov 16 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/15/07, Janice Caron <caron800 googlemail.com> wrote:
 examples/manual/chapterStorage.d

That's what I was looking for! Great! :-) The folder name ("manual") didn't really make it obvious what was in it. Guess I'll attack that one next.

That was easy! Obviously, chapterstorage.d was not written for D2+, so I had to change all the char[]s into strings in that file. Anyway, all I had to do was change char[] into string in the source files, except in toUpper and toLower, and guess what - it compiled without complaint, and runs perfectly. Woo hoo!
Nov 16 2007
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Fri, 16 Nov 2007 12:46:24 +0000
"Janice Caron" <caron800 googlemail.com> wrote:

 Obviously, chapterstorage.d was not written for D2+, so I had to
 change all the char[]s into strings in that file.

As you might know already or at least have guessed - since there's an experimental Tango /branch/ for D 2.x -, Tango is D 1.x only, right now. So it'd be pretty weird to write the reference manual of Tango for D 2.x. :) -- Alexander Panek <alexander.panek brainsware.org>
Nov 16 2007
prev sibling next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
I dunno if you'd consider this a bug in tango.io.filepath.parse(), but
the example program filepathname.d looks like this:

    void main(){
        Cout ((new FilePath(r"d:\path\foo.bat")).name).newline;
        Cout ((new FilePath(r"d:\path.two\bar")).name).newline;
        Cout ((new FilePath("/home/user.name/bar.")).name).newline;
        Cout ((new FilePath(r"d:\path.two\bar")).name).newline;
        Cout ((new FilePath("/home/user/.resource")).name).newline;
    }

And (on Windows) emits the following output - at least, on my ported version:

    foo
    bar
    /home/user.name/bar
    bar
    /home/user/

I think I understand what's going on here. The slash in the third and
fifth examples is being (incorrectly) regarded as a component
character, instead of a path separator, so it thinks "/home/user/" is
the file part and "resource" the extension.

Yes, I know there's a flag in the constructor which converts "\" to
"/", and that that flag wasn't set in this example, BUT...

In Windows, "\" and "/" are BOTH acceptable as file separators. As far
as fopen() is concerned, they are interchangable. If you open
"/home/user/.resource" you'll get exactly the same file as had you
opened "\home\user\.resource".

This isn't true in a Windows (Command Prompt) shell, however, even
there, "/" is not a valid character for use in filenames. In fact, all
of the characters \ / : * ? " < > and | are prohibited from being used
in filenames.

I feel that the filepath.parse routine really should understand how
pathnames actually work on Windows. Sure, if the native flag is set,
then convert / to \. But even if that doesn't happen, parse() should
recognise both \ and / as pathname separators, and should throw an
exception if an illegal character is used in a pathname.

If there are no objections, I plan to "fix" this in my local copy, and
I can certainly post the fix for you, in case you should want to
incorporate it into the real Tango.
Nov 16 2007
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Janice Caron" wrote
I dunno if you'd consider this a bug in tango.io.filepath.parse(), but
 the example program filepathname.d looks like this:
 ...

Register at dsource: http://www.dsource.org/forums/profile.php?mode=register File a ticket on tango: http://www.dsource.org/projects/tango/newticket. It's actually a pretty nice system, and the developers are very responsive. -Steve
Nov 16 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 11/16/07, Sean Kelly <sean f4.ca> wrote:

 As I mentioned, I did not copy tango's std folder at all. I am doing
 without it.

So do you have a /std directory at all?

I have Phobos's std directory. It is completely unchanged and intact. (And obviously it will be updated the moment D2.008 comes along).
 I would hope so, or some
 portions of Tango won't work.

Given that I have (a now modified copy of) the source code, and the power and ability to change it. I can make anything work.
 The instrinsic functions, for example,
 must have a mangled name that begins with "std".

None of the examples I've got working have given me this problem so far, but I'm fair sure that if something doesn't work, I can just change the source until it does.
Nov 16 2007
prev sibling parent "David Wilson" <dw botanicus.net> writes:
On 11/19/07, Walter Bright <newshound1 digitalmars.com> wrote:
 Oskar Linde wrote:
 To end, I think it speaks very highly of Tango that the only issues
 being actively debated are the purely stylistic ones.

It's normal for easily understood issues to get a lot more comments than the ones that need more work to grok.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING
 However, silence is the worst case <g>. It means nobody has even looked
 at it.

Nov 19 2007