www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's missing from Phobos for Orbit (package manager)

reply Jacob Carlborg <doob me.com> writes:
In the thread "Expanding Phobos from a flat hierarchy" there started a 
discussion about package managers. Of course I mentioned the package 
manager I'm working on, Orbit. Unfortunately people weren't very happy 
with the third party dependencies. So I compiled a list of what's 
missing from Phobos, but I never got an answer to that post in the 
thread. I have now repeated the list below of what Orbit needs that 
don't exist in Phobos. I hope I have better luck here.

Repeated message:

I've compiled a list below of things used in Orbit (directly or 
indirectly) that Phobos is lacking in. Please tell me if I'm wrong:

* DStack - Is a library for helping structuring applications. It includes:
   * Handling of command line arguments
   * Components
   * Commands
   * Starting and initializing of the application
   * Configuration
I plan to add more stuff here when needed

* Serialization - Does not exist
* ConfigMap -  Does not exist. An associative array with opDispatch 
added to it. Allows to do things like:

auto config = ConfigMap();
config.foo = "asd";
config.bar.foo.baz = "foobar";

assert(config.foo == "asd");

* XML - The XML module is slow and has a cumbersome API

* Zip - I don't exactly remember what was wrong here. It either didn't 
work or I had to reimplement a lot of functionality already available in 
Tango.

* Net - std.curl is probably a good module but it wasn't available when 
I started. I also adds another dependency.

* std.process - I have not used it myself but I've heard it's not optimal

* std.getopt - Doesn't support the following:
   * Required arguments
   * Restricting the values of a given argument
   * No way to automatically create a help/usage list out of the arguments
   * Handling positional arguments
   * No support for commands/action. That is "git commit", "commit" 
would be the command/action
   * Handle multiple command lines
   * Validation of the arguments

Various convince functions:

* any - Opposite of empty
* last - Returns the last element of an array
* map, find and any for associative arrays
* Utility functions for handling UDA's

* isBlank - Check if a value if blank. If it's a string it's blank if 
it's only contains whitespace. If it you can call .empty return that. If 
it's a value type it's not empty. If it's a reference type and it's null 
it's empty

* isPresent - The opposite of isBlank

* pluralize - Takes a string and a count. If the count is greater than 1 
it converts the word in the string to plural

CTFE:

* format - A simple formatting function
* indexOf
* contains
* hasField - Returns true if the given type has the given field
* fieldsOf - Returns all the fields of the given type
* TypeOfField - Returns the type of a field
* nameOfFieldAt - Returns the name of the field at the given position
* set/getValueOfField - Sets/gets the value of a field
* newInstance - Returns a new instance based on the class name or 
ClassInfo. Can handle any class regardless of constructors

* A couple of traits

In the end it's all about what's working.

Original message: 
http://forum.dlang.org/thread/ugmacrokqghrrwpfovam forum.dlang.org?page=6#post-kf15td:24v63:241:40digitalmars.com

-- 
/Jacob Carlborg
Feb 12 2013
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
Some answers:

On Tue, 12 Feb 2013 07:38:53 -0500, Jacob Carlborg <doob me.com> wrote:

 * std.process - I have not used it myself but I've heard it's not optimal
I want to get this remedied. Won't make it in 2.062, but I want to finish this in the next month.
 * std.getopt - Doesn't support the following:
    * Required arguments
    * Restricting the values of a given argument
    * No way to automatically create a help/usage list out of the  
 arguments
    * Handling positional arguments
    * No support for commands/action. That is "git commit", "commit"  
 would be the command/action
    * Handle multiple command lines
    * Validation of the arguments
I know std.getopt doesn't support all these, but couldn't you support them externally? I mean, let getopt assign the values, then perform the logic based on what you got? You have to write the logic anyway. I suppose one of the missing pieces here is whether an option was present or not. All you get is the result. You can handle the command before handling the options, as long as you require the command to be the first parameter.
 Various convince functions:

 * any - Opposite of empty
!empty
 * last - Returns the last element of an array
arr[$-1]; arr.back;
 * map, find and any for associative arrays
Really, we need an AA range...
 * pluralize - Takes a string and a count. If the count is greater than 1  
 it converts the word in the string to plural
basic version: string pluralize(string x, int count) { return count > 1 ? x ~ "s" : x; } Now, you probably would need a simple mechanism to do the different plural forms. Sometimes 'es' must be added, sometimes 'y' must be changed to 'ies', etc. But that should be a simple switch statement. The switch statement would select a different ending, and a prefix count based on the current ending. Then the return would be: return count > 1 ? x[0..pcount] ~ ending : x; -Steve
Feb 12 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-12 15:21, Steven Schveighoffer wrote:
 Some answers:

 On Tue, 12 Feb 2013 07:38:53 -0500, Jacob Carlborg <doob me.com> wrote:

 * std.process - I have not used it myself but I've heard it's not optimal
I want to get this remedied. Won't make it in 2.062, but I want to finish this in the next month.
 * std.getopt - Doesn't support the following:
    * Required arguments
    * Restricting the values of a given argument
    * No way to automatically create a help/usage list out of the
 arguments
    * Handling positional arguments
    * No support for commands/action. That is "git commit", "commit"
 would be the command/action
    * Handle multiple command lines
    * Validation of the arguments
I know std.getopt doesn't support all these, but couldn't you support them externally? I mean, let getopt assign the values, then perform the logic based on what you got? You have to write the logic anyway. I suppose one of the missing pieces here is whether an option was present or not. All you get is the result. You can handle the command before handling the options, as long as you require the command to be the first parameter.
 Various convince functions:

 * any - Opposite of empty
!empty
 * last - Returns the last element of an array
arr[$-1]; arr.back;
 * map, find and any for associative arrays
Really, we need an AA range...
 * pluralize - Takes a string and a count. If the count is greater than
 1 it converts the word in the string to plural
basic version: string pluralize(string x, int count) { return count > 1 ? x ~ "s" : x; } Now, you probably would need a simple mechanism to do the different plural forms. Sometimes 'es' must be added, sometimes 'y' must be changed to 'ies', etc. But that should be a simple switch statement. The switch statement would select a different ending, and a prefix count based on the current ending. Then the return would be: return count > 1 ? x[0..pcount] ~ ending : x;
I don't need examples of how to implement these functions. I'm asking what of these could we add to Phobos. I already have all the functionality in place. I'm trying to estimate the cost of moving these to Phobos, if it's worth porting Orbit to only use Phobos. -- /Jacob Carlborg
Feb 12 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 12 Feb 2013 09:38:45 -0500, Jacob Carlborg <doob me.com> wrote:

 I don't need examples of how to implement these functions. I'm asking  
 what of these could we add to Phobos. I already have all the  
 functionality in place. I'm trying to estimate the cost of moving these  
 to Phobos, if it's worth porting Orbit to only use Phobos.
Well, many of those could be implemented in Orbit, especially the trivial ones. The way it was worded, I thought you needed those to be in phobos or have an implementation provided before you could start the port. It did sound a little strange ;) Some of them are not trivial, and I understand those (e.g. std.process and std.xml), but things like !empty I think would not need a special implementation in phobos for you to be able to port. -Steve
Feb 12 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-12 15:53, Steven Schveighoffer wrote:

 Well, many of those could be implemented in Orbit, especially the
 trivial ones.

 The way it was worded, I thought you needed those to be in phobos or
 have an implementation provided before you could start the port.  It did
 sound a little strange ;)
I would prefer if they were in Phobos, since they are generic and can be used by any application.
 Some of them are not trivial, and I understand those (e.g. std.process
 and std.xml), but things like !empty I think would not need a special
 implementation in phobos for you to be able to port.
I moved this functionality out of Orbit into one of my own libraries because it's generic and can be used by any application. -- /Jacob Carlborg
Feb 12 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-12 15:53, Steven Schveighoffer wrote:

 Well, many of those could be implemented in Orbit, especially the
 trivial ones.

 The way it was worded, I thought you needed those to be in phobos or
 have an implementation provided before you could start the port.  It did
 sound a little strange ;)

 Some of them are not trivial, and I understand those (e.g. std.process
 and std.xml), but things like !empty I think would not need a special
 implementation in phobos for you to be able to port.
The original problem was Orbit is using third party libraries which is not acceptable if Orbit is to be included in the official distribution. This is according to Andrei and Jonathan. The question then is: Which of the needed functionality can be moved to Phobos and which can not be? I would like to avoid rewriting large parts of the code that is already working perfectly fine. I also don't think it's good to include large part of library code in Orbit, i.e. a serialization library. -- /Jacob Carlborg
Feb 12 2013
parent reply "Peter Sommerfeld" <noreply rubrica.at> writes:
Jacob Carlborg wrote:
 The question then is: Which of the needed functionality can be moved to  
 Phobos and which can not be?
  I would like to avoid rewriting large parts of the code that is already  
 working perfectly fine.
  I also don't think it's good to include large part of library code in  
 Orbit, i.e. a serialization library.
That seems to be a question of priority: If you insist to get the dependencies into phobos first it will take some time until that happens, may be never or parts of it only. A solution for now seems to be to pack the dependencies into Orbit and later push parts of it into phobos. That will establish an API which defines the d-package manager, provided it is accepted by Walter and Andre. Your decision... Peter
Feb 12 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-12 17:53, Peter Sommerfeld wrote:

 That seems to be a question of priority: If you insist to get the
 dependencies into phobos first it will take some time until that
 happens, may be never or parts of it only.

 A solution for now seems to be to pack the dependencies into Orbit
 and later push parts of it into phobos. That will establish an API
 which defines the d-package manager, provided it is accepted by
 Walter and Andre. Your decision...
It's not so much about priority, it's rather about if being accepted at all. -- /Jacob Carlborg
Feb 12 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/12/2013 6:53 AM, Steven Schveighoffer wrote:
 Well, many of those could be implemented in Orbit, especially the trivial ones.
The trivial ones should not be added to Phobos, for example, 'any' being defined as '!empty'. Such things add cognitive load but no value.
Feb 12 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-12 22:35, Walter Bright wrote:

 The trivial ones should not be added to Phobos, for example, 'any' being
 defined as '!empty'. Such things add cognitive load but no value.
This is just an extension to the already existing std.algorithm.any function. I think it adds value, that's why I have it. It clearly shows the intent. It's the same reason why I think it's good to have explicit interfaces and abstract classes in opposite of how it works in C++. -- /Jacob Carlborg
Feb 12 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/12/2013 11:34 PM, Jacob Carlborg wrote:
 On 2013-02-12 22:35, Walter Bright wrote:

 The trivial ones should not be added to Phobos, for example, 'any' being
 defined as '!empty'. Such things add cognitive load but no value.
This is just an extension to the already existing std.algorithm.any function. I think it adds value, that's why I have it. It clearly shows the intent. It's the same reason why I think it's good to have explicit interfaces and abstract classes in opposite of how it works in C++.
The any in std.algorithm is defined: -------------- bool any(alias pred, Range)(Range range); Returns true if and only if a value v satisfying the predicate pred can be found in the forward range range. Performs Ο(r.length) evaluations of pred. -------------- I see that as very different from !empty.
Feb 13 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-13 21:19, Walter Bright wrote:

 The any in std.algorithm is defined:

 --------------
 bool any(alias pred, Range)(Range range);

 Returns true if and only if a value v satisfying the predicate pred can
 be found in the forward range range. Performs Ο(r.length) evaluations of
 pred.
 --------------

 I see that as very different from !empty.
But if you use a predicate that always returns true that would be basically the same. At least for arrays. int[] a = []; assert(a.any!(e => true) == false); int[] b = [3, 4, 5]; assert(b.any!(e => true) == true); -- /Jacob Carlborg
Feb 14 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/14/2013 12:12 AM, Jacob Carlborg wrote:
 On 2013-02-13 21:19, Walter Bright wrote:

 The any in std.algorithm is defined:

 --------------
 bool any(alias pred, Range)(Range range);

 Returns true if and only if a value v satisfying the predicate pred can
 be found in the forward range range. Performs Ο(r.length) evaluations of
 pred.
 --------------

 I see that as very different from !empty.
But if you use a predicate that always returns true that would be basically the same. At least for arrays. int[] a = []; assert(a.any!(e => true) == false); int[] b = [3, 4, 5]; assert(b.any!(e => true) == true);
I don't understand why one would go around the horn to just check for !empty.
Feb 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 10:46, Walter Bright wrote:

 I don't understand why one would go around the horn to just check for
 !empty.
I've tried to explain, it shows what the intention is. Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any". It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed. -- /Jacob Carlborg
Feb 14 2013
next sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-02-14 11:58:12 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-02-14 10:46, Walter Bright wrote:
 
 I don't understand why one would go around the horn to just check for
 !empty.
I've tried to explain, it shows what the intention is. Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any". It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed.
I'd agree it's more readable, but it does not do what I expect when I read it: to me 'any' sounds like an accessor that would take an item at an unspecified position in a container (likely the less costly to get); std.container defines 'removeAny' following that line. The correct name would be 'hasAny'. In this case I think it'd be much better if the language just translated "if (str)" to something equivalent to "if (!str.empty)". -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Feb 14 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/14/13 6:58 AM, Jacob Carlborg wrote:
 On 2013-02-14 10:46, Walter Bright wrote:

 I don't understand why one would go around the horn to just check for
 !empty.
I've tried to explain, it shows what the intention is. Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any". It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed.
I understand. Adding functions such as the negation of empty becomes a judgment call. Phobos does have quite a few simple functions that could be easily achieved through expression composition (e.g. trim) or statement composition (e.g. enforce). So again it's all a matter of judgment. Walter and I don't consider the negation of empty as useful enough to receive a name. There's been a talk (discussed on reddit) on Ruby by a prominent member of that community. At a point the talk addressed the awesomeness of "unless" (the negation of "if") - the presence of that near-useless device was seen as a human touch in a world of cold logic. I found the argument rather weak, unless we consider creating clutter and wasting means part of the human touch. Besides, as often happens with such constructs, there are pitfalls and subsequent dos and donts about "unless" that more than undo whatever utility and expressiveness it may have. The first two hits for https://www.google.com/search?q=ruby%20unless describe "unless, the abused ruby conditional" and "making sense of ruby's unless". Turns out "unless" should not be used with "else" or at the beginning of a statement. Perl also has "unless", and after years of experience the Perl Best Practices guide http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf curtly says: "Don’t use unless or until at all." If Perl shuns a keyword, that's bound to say something. D has "any" (previously an overload of "canFind") as an algorithm that finds whether at least one element of a range satisfies a condition, otherwise writable as "!r.find!(a => condition).empty". The convenience/mechanics/generality of the construct was enough justification to add the algorithm. To claim that D already has the negation of empty because one can write "r.any(a => true)" is, in my opinion, an ill-posed argument. Andrei
Feb 14 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 13:42, Andrei Alexandrescu wrote:

 I understand. Adding functions such as the negation of empty becomes a
 judgment call.

 Phobos does have quite a few simple functions that could be easily
 achieved through expression composition (e.g. trim) or statement
 composition (e.g. enforce). So again it's all a matter of judgment.

 Walter and I don't consider the negation of empty as useful enough to
 receive a name.
Since you mention Ruby below I can say that D/Phobos could have some more of these convenience methods. Especially if we would like to consider D usable as a scripting language.
 There's been a talk (discussed on reddit) on Ruby by a prominent member
 of that community. At a point the talk addressed the awesomeness of
 "unless" (the negation of "if") - the presence of that near-useless
 device was seen as a human touch in a world of cold logic. I found the
 argument rather weak, unless we consider creating clutter and wasting
 means part of the human touch.

 Besides, as often happens with such constructs, there are pitfalls and
 subsequent dos and donts about "unless" that more than undo whatever
 utility and expressiveness it may have. The first two hits for
 https://www.google.com/search?q=ruby%20unless describe "unless, the
 abused ruby conditional" and "making sense of ruby's unless". Turns out
 "unless" should not be used with "else" or at the beginning of a statement.

 Perl also has "unless", and after years of experience the Perl Best
 Practices guide
 http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf
 curtly says: "Don’t use unless or until at all." If Perl shuns a
 keyword, that's bound to say something.
"unless" is kind of a useless keyword. I can tell you that I have used "any" a lot more than I have used "unless".
 D has "any" (previously an overload of "canFind") as an algorithm that
 finds whether at least one element of a range satisfies a condition,
 otherwise writable as "!r.find!(a => condition).empty". The
 convenience/mechanics/generality of the construct was enough
 justification to add the algorithm. To claim that D already has the
 negation of empty because one can write "r.any(a => true)" is, in my
 opinion, an ill-posed argument.
I just thought that we could add a default predicate to the "any" function. -- /Jacob Carlborg
Feb 14 2013
parent reply "tn" <no email.com> writes:
On Thursday, 14 February 2013 at 19:54:28 UTC, Jacob Carlborg 
wrote:
 D has "any" (previously an overload of "canFind") as an 
 algorithm that
 finds whether at least one element of a range satisfies a 
 condition,
 otherwise writable as "!r.find!(a => condition).empty". The
 convenience/mechanics/generality of the construct was enough
 justification to add the algorithm. To claim that D already 
 has the
 negation of empty because one can write "r.any(a => true)" is, 
 in my
 opinion, an ill-posed argument.
I just thought that we could add a default predicate to the "any" function.
Yes for a default predicate, BUT I think it should be "a => a" (that is, identity function) instead of "a => true". Same default predicate should be applied to "all" function as well. This way the behavior with boolean ranges would match the behavior of "any" and "all" at least in Python and Matlab (and apparently also Ruby).
Feb 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 21:23, tn wrote:

 Yes for a default predicate, BUT I think it should be "a => a" (that is,
 identity function) instead of "a => true". Same default predicate should
 be applied to "all" function as well. This way the behavior with boolean
 ranges would match the behavior of "any" and "all" at least in Python
 and Matlab (and apparently also Ruby).
Right. But the problem with that is that a zero in D is considered false wheres in Ruby it's true. The only things that are false in Ruby is "nil" and "false". -- /Jacob Carlborg
Feb 14 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 14 February 2013 at 20:28:23 UTC, Jacob Carlborg 
wrote:
 On 2013-02-14 21:23, tn wrote:

 Yes for a default predicate, BUT I think it should be "a => a" 
 (that is,
 identity function) instead of "a => true". Same default 
 predicate should
 be applied to "all" function as well. This way the behavior 
 with boolean
 ranges would match the behavior of "any" and "all" at least in 
 Python
 and Matlab (and apparently also Ruby).
Right. But the problem with that is that a zero in D is considered false wheres in Ruby it's true. The only things that are false in Ruby is "nil" and "false".
In python and matlab 0 is false and "any" treats them as such.
Feb 14 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 13:42, Andrei Alexandrescu wrote:

 I understand. Adding functions such as the negation of empty becomes a
 judgment call.

 Phobos does have quite a few simple functions that could be easily
 achieved through expression composition (e.g. trim) or statement
 composition (e.g. enforce). So again it's all a matter of judgment.

 Walter and I don't consider the negation of empty as useful enough to
 receive a name.
How about this, I have another similar function that might be useful in Phobos as well. "isBlank" and "isPresent". "isPresent" is just the opposite of "isBlank". "isBlank" works like this: * If it's a string - it's considered blank if it's empty or only contains white space * If you can call "empty" on it - return the result * If it's a reference type and it's null - return true * Otherwise return false -- /Jacob Carlborg
Feb 14 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/14/13 3:01 PM, Jacob Carlborg wrote:
 On 2013-02-14 13:42, Andrei Alexandrescu wrote:

 I understand. Adding functions such as the negation of empty becomes a
 judgment call.

 Phobos does have quite a few simple functions that could be easily
 achieved through expression composition (e.g. trim) or statement
 composition (e.g. enforce). So again it's all a matter of judgment.

 Walter and I don't consider the negation of empty as useful enough to
 receive a name.
How about this, I have another similar function that might be useful in Phobos as well. "isBlank" and "isPresent". "isPresent" is just the opposite of "isBlank". "isBlank" works like this: * If it's a string - it's considered blank if it's empty or only contains white space * If you can call "empty" on it - return the result * If it's a reference type and it's null - return true * Otherwise return false
I think this is a fine candidate for a standard function. It does actual work, is useful, and can't be trivially achieved with inline code. Andrei
Feb 15 2013
prev sibling next sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 14 February 2013 at 20:01:37 UTC, Jacob Carlborg 
wrote:
 On 2013-02-14 13:42, Andrei Alexandrescu wrote:

 I understand. Adding functions such as the negation of empty 
 becomes a
 judgment call.

 Phobos does have quite a few simple functions that could be 
 easily
 achieved through expression composition (e.g. trim) or 
 statement
 composition (e.g. enforce). So again it's all a matter of 
 judgment.

 Walter and I don't consider the negation of empty as useful 
 enough to
 receive a name.
How about this, I have another similar function that might be useful in Phobos as well. "isBlank" and "isPresent". "isPresent" is just the opposite of "isBlank". "isBlank" works like this: * If it's a string - it's considered blank if it's empty or only contains white space * If you can call "empty" on it - return the result * If it's a reference type and it's null - return true * Otherwise return false
What does isBlank() return with tabs ? I don't like having two functions doing the same thing, so isBlank() may be useful, isPresent() only adds cognitive overload and mere chaos to the code base (because someone is going to use both at the same time in the same function, making the code harder to understand).
Feb 16 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-16 19:23, SomeDude wrote:

 What does isBlank() return with tabs ?
Tabs are considered whitespace so it would return "true".
 I don't like having two functions doing the same thing, so isBlank() may
 be useful, isPresent() only adds cognitive overload and mere chaos to
 the code base (because someone is going to use both at the same time in
 the same function, making the code harder to understand).
Sure, both does not have to be included. -- /Jacob Carlborg
Feb 16 2013
prev sibling parent reply "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Thursday, 14 February 2013 at 20:01:37 UTC, Jacob Carlborg 
wrote:
 On 2013-02-14 13:42, Andrei Alexandrescu wrote:

 I understand. Adding functions such as the negation of empty 
 becomes a
 judgment call.

 Phobos does have quite a few simple functions that could be 
 easily
 achieved through expression composition (e.g. trim) or 
 statement
 composition (e.g. enforce). So again it's all a matter of 
 judgment.

 Walter and I don't consider the negation of empty as useful 
 enough to
 receive a name.
How about this, I have another similar function that might be useful in Phobos as well. "isBlank" and "isPresent". "isPresent" is just the opposite of "isBlank".
But "present" and "blank" aren't opposites in English. "isNonBlank" or "isNotBlank" are opposites of "isBlank", but "isPresent" would be the opposite of "isAbsent." It seems almost meaningless in the context of a string predicate --- If I saw it in code, I would guess it meant "not a null reference." Similarly with "any" vs. "empty." I would think that "any" is synonymous with "some" and therefore should be the opposite of either "none" or "all" (leaning toward "all," given the commonality of some/all predicates in other languages, and the exists/forall concepts in predicate logic). Regardless of their name, I would not like to see functions like these in Phobos. It's already challenging enough to keep the signature of the larger Phobos modules in one's head. Adding functions like these just adds noise... expressions like (!s.empty) are perfectly readable. Graham
 "isBlank" works like this:

 * If it's a string - it's considered blank if it's empty or 
 only contains white space

 * If you can call "empty" on it - return the result

 * If it's a reference type and it's null - return true

 * Otherwise return false
Mar 20 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-20 23:17, Graham Fawcett wrote:

 But "present" and "blank" aren't opposites in English. "isNonBlank" or
 "isNotBlank" are opposites of "isBlank", but "isPresent" would be the
 opposite of "isAbsent." It seems almost meaningless in the context of a
 string predicate --- If I saw it in code, I would guess it meant "not a
 null reference."
Then have only isBlank. -- /Jacob Carlborg
Mar 21 2013
parent "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Thursday, 21 March 2013 at 07:39:53 UTC, Jacob Carlborg wrote:
 On 2013-03-20 23:17, Graham Fawcett wrote:

 But "present" and "blank" aren't opposites in English. 
 "isNonBlank" or
 "isNotBlank" are opposites of "isBlank", but "isPresent" would 
 be the
 opposite of "isAbsent." It seems almost meaningless in the 
 context of a
 string predicate --- If I saw it in code, I would guess it 
 meant "not a
 null reference."
Then have only isBlank.
Agreed, isBlank is a good addition to Phobos. Graham
Mar 21 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Feb 2013 06:58:12 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-14 10:46, Walter Bright wrote:

 I don't understand why one would go around the horn to just check for
 !empty.
I've tried to explain, it shows what the intention is. Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any". It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed.
Would this work? bool any(R)(R r) if(isInputRange!R) { return !r.empty;} -Steve
Feb 14 2013
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Feb 2013 09:28:25 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 bool any(R)(R r) if(isInputRange!R) { return !r.empty;}
BTW, I noticed 'any' is not listed in the std.algorithm documentation at the top, even though it is in the docs. Is that a bug with DDoc, or just bad maintenance? -Steve
Feb 14 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 15:28, Steven Schveighoffer wrote:

 Would this work?

 bool any(R)(R r) if(isInputRange!R) { return !r.empty;}
Yes, I already have something similar. Actually I have this: property bool any (T) (T value) if (__traits(compiles, { bool a = value.empty; })) { return !value.empty; } -- /Jacob Carlborg
Feb 14 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 14 February 2013 at 19:57:25 UTC, Jacob Carlborg 
wrote:
 On 2013-02-14 15:28, Steven Schveighoffer wrote:

 Would this work?

 bool any(R)(R r) if(isInputRange!R) { return !r.empty;}
Yes, I already have something similar. Actually I have this: property bool any (T) (T value) if (__traits(compiles, { bool a = value.empty; })) { return !value.empty; }
The only purpose of this is to make code more readable, correct? (The few extra keystrokes to write !a.empty seem negligable). It fails at that, because "any" means something different to a lot of people, creating confusion as opposed to clarity.
Feb 14 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-14 21:05, John Colvin wrote:

 The only purpose of this is to make code more readable, correct?
Yes, exactly.
 (The few extra keystrokes to write !a.empty seem negligable).

 It fails at that, because "any" means something different to a lot of
 people, creating confusion as opposed to clarity.
Yeah, I'm not perfectly satisfied with the name either. -- /Jacob Carlborg
Feb 14 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Feb 2013 14:57:25 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-14 15:28, Steven Schveighoffer wrote:

 Would this work?

 bool any(R)(R r) if(isInputRange!R) { return !r.empty;}
Yes, I already have something similar. Actually I have this: property bool any (T) (T value) if (__traits(compiles, { bool a = value.empty; })) { return !value.empty; }
OK, here is what I suggest: 1. put all these "helper" trivial functions inside a module, call it orbithelper. 2. If phobos obtains these functions, remove them from orbithelper, and import the correct version. The other things, such as xml, I think are more troublesome. This seems like a trivial problem with a trivial solution. -Steve
Feb 14 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/14/2013 1:00 PM, Steven Schveighoffer wrote:
 On Thu, 14 Feb 2013 14:57:25 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-14 15:28, Steven Schveighoffer wrote:

 Would this work?

 bool any(R)(R r) if(isInputRange!R) { return !r.empty;}
Yes, I already have something similar. Actually I have this: property bool any (T) (T value) if (__traits(compiles, { bool a = value.empty; })) { return !value.empty; }
OK, here is what I suggest: 1. put all these "helper" trivial functions inside a module, call it orbithelper.
Sounds like a good idea.
 2. If phobos obtains these functions, remove them from orbithelper, and import
 the correct version.
+1
 The other things, such as xml, I think are more troublesome.  This seems like a
 trivial problem with a trivial solution.
Yup.
Feb 14 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 22:00, Steven Schveighoffer wrote:

 The other things, such as xml, I think are more troublesome.  This seems
 like a trivial problem with a trivial solution.
Yes, so what about the other things, such as xml. Any suggestions? -- /Jacob Carlborg
Feb 14 2013
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Feb 2013 16:38:24 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-14 22:00, Steven Schveighoffer wrote:

 The other things, such as xml, I think are more troublesome.  This seems
 like a trivial problem with a trivial solution.
Yes, so what about the other things, such as xml. Any suggestions?
No. Clearly using tango xml will not fly. We need a new xml library. For many reasons, besides this tool. I also think serialization is something we should have in phobos, regardless of Orbit's requirements. std.process should be remedied soon (it's nearing review). The others, I'm not sure. What about this as a possible ongoing solution: Step 1. Include orbit in BINARY form on the distribution, keep it in its own project wherever it lives now. Dogfood be damned... Step 2. Port as much as possible to Phobos. As libraries become available, try to port it over to the new library. Utopian step. Include Orbit and source in distribution, without external dependencies. I don't see why dmd distribution needs to include the source for all the tools it uses. I frequently never touch the source of dmd distribution, I just use the compiled binaries. This might be kind of viewed like DMD. It has parts in it that are ASM, that Walter is slowly porting to C++. Why can't we use that same model? -Steve
Feb 14 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 23:37, Steven Schveighoffer wrote:

 No.  Clearly using tango xml will not fly.

 We need a new xml library.  For many reasons, besides this tool.

 I also think serialization is something we should have in phobos,
 regardless of Orbit's requirements.
I've tried that, nobody was interested.
 std.process should be remedied soon (it's nearing review).

 The others, I'm not sure.

 What about this as a possible ongoing solution:

 Step 1. Include orbit in BINARY form on the distribution, keep it in its
 own project wherever it lives now.  Dogfood be damned...
It's _is_ written in D. I just chose to use libraries that exists and works. BTW, probably around half of what's included in the DMD distribution is not written in D at all.
 Step 2. Port as much as possible to Phobos.  As libraries become
 available, try to port it over to the new library.
 Utopian step. Include Orbit and source in distribution, without external
 dependencies.
That could work.
 I don't see why dmd distribution needs to include the source for all the
 tools it uses.  I frequently never touch the source of dmd distribution,
 I just use the compiled binaries.
Me too.
 This might be kind of viewed like DMD.  It has parts in it that are ASM,
 that Walter is slowly porting to C++.  Why can't we use that same model?

 -Steve
-- /Jacob Carlborg
Feb 15 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 15 Feb 2013 03:02:09 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-14 23:37, Steven Schveighoffer wrote:

 No.  Clearly using tango xml will not fly.

 We need a new xml library.  For many reasons, besides this tool.

 I also think serialization is something we should have in phobos,
 regardless of Orbit's requirements.
I've tried that, nobody was interested.
That is an overstatement. I'm pretty sure people are interested in having serialization in Phobos.
 std.process should be remedied soon (it's nearing review).

 The others, I'm not sure.

 What about this as a possible ongoing solution:

 Step 1. Include orbit in BINARY form on the distribution, keep it in its
 own project wherever it lives now.  Dogfood be damned...
It's _is_ written in D. I just chose to use libraries that exists and works. BTW, probably around half of what's included in the DMD distribution is not written in D at all.
By dogfood I mean, written against phobos. -Steve
Feb 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 15:28, Steven Schveighoffer wrote:

 That is an overstatement.  I'm pretty sure people are interested in
 having serialization in Phobos.
It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now. -- /Jacob Carlborg
Feb 15 2013
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 15 Feb 2013 11:14:56 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-15 15:28, Steven Schveighoffer wrote:

 That is an overstatement.  I'm pretty sure people are interested in
 having serialization in Phobos.
It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now.
This is the last "push" I can find from you: http://forum.dlang.org/post/jcmp6s$1cs5$1 digitalmars.com Doesn't sound ready. On trello, it's still listed as "in development." I'm pretty sure nobody is using that, though. If you have given up, I suppose there is no point in asking if you are still interested in having it reviewed, but it sure doesn't sound like it was ever "in" the review queue. Quite possible I missed the message that says "OK, can we review orange? it is ready". -Steve
Feb 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 17:38, Steven Schveighoffer wrote:

 This is the last "push" I can find from you:

 http://forum.dlang.org/post/jcmp6s$1cs5$1 digitalmars.com

 Doesn't sound ready.
That was 1+ year ago. It does build with DMD 2.061 and all tests pass.
 On trello, it's still listed as "in development."  I'm pretty sure
 nobody is using that, though.
I have no idea of what's on trello. I take no responsible for who put it there.
 If you have given up, I suppose there is no point in asking if you are
 still interested in having it reviewed, but it sure doesn't sound like
 it was ever "in" the review queue.  Quite possible I missed the message
 that says "OK, can we review orange? it is ready".
If there are actually people interested in reviewing I'm all for it but I have not seen any trace of that. -- /Jacob Carlborg
Feb 15 2013
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Friday, 15 February 2013 at 16:14:57 UTC, Jacob Carlborg wrote:
 On 2013-02-15 15:28, Steven Schveighoffer wrote:

 That is an overstatement.  I'm pretty sure people are 
 interested in
 having serialization in Phobos.
It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now.
It's not listed in the review queue on the wiki: http://wiki.dlang.org/Review_Queue Well, it is now, since I added it. Also relabeled it std.serialization, because I think std.orange (or just orange) might be a tad too opaque for newcomers. Mayhap I shouldn't have added it (there should be a wiki page about this), but done is done. If I can figure out what's required to be a review manager, I guess I could shoulder that burden too.
Feb 15 2013
next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Friday, 15 February 2013 at 16:54:06 UTC, Simen Kjaeraas wrote:
 It's not listed in the review queue on the wiki:

 http://wiki.dlang.org/Review_Queue
Well than that isn't complete: http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue
Feb 15 2013
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-02-15, 19:53, Jesse Phillips wrote:

 On Friday, 15 February 2013 at 16:54:06 UTC, Simen Kjaeraas wrote:
 It's not listed in the review queue on the wiki:

 http://wiki.dlang.org/Review_Queue
Well than that isn't complete: http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue
Indeed. I was under the impression all of the old wiki should have been migrated, but that is apparently not the truth. It is now, though. -- Simen
Mar 20 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 17:54, Simen Kjaeraas wrote:

 It's not listed in the review queue on the wiki:

 http://wiki.dlang.org/Review_Queue
It's been on the old wiki for quite some time: http://prowiki.org/wiki4d/wiki.cgi?ReviewQueue
 Well, it is now, since I added it. Also relabeled it std.serialization,
 because I think std.orange (or just orange) might be a tad too opaque
 for newcomers. Mayhap I shouldn't have added it (there should be a wiki
 page about this), but done is done. If I can figure out what's required
 to be a review manager, I guess I could shoulder that burden too.
-- /Jacob Carlborg
Feb 15 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/13 11:14 AM, Jacob Carlborg wrote:
 On 2013-02-15 15:28, Steven Schveighoffer wrote:

 That is an overstatement. I'm pretty sure people are interested in
 having serialization in Phobos.
It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now.
Here's what I think - in order to add things to Phobos and generally the standard distribution you must revamp your entire attitude. I have a lot of sympathy because years ago I was in the exact position. I'd written the Loki library for C++ that included many components deserving inclusion in C++'s standard library. As a first step I asked for Loki to be included in Boost. The attempt was met with interest but it soon became obvious that I'd need to go through a difficult review and make quite extensive adaptations and changes to the library in order to be considered. My attitude was "take it or leave it" and that just didn't work (and in retrospect, for the better). Part of the proposal was a policy-based smart pointer that was superior in every way I could think of to other candidates. Yet the proposers of those candidates were willing to go through the hard work of improving and streamlining their proposals, to the point they got into Boost and ultimately into the standard. With time the relative deficiencies of that proposal was reduced by adding more kinds of smart pointers, so in the end it all got where it is today. In contrast, I was busy with my Ph.D. research so I didn't have the time to file away all rough edges. That was a good lesson to learn. Applied to the situation of today, to get anything into the D programming language requires determination, humility, and willingness to take criticism and convert it positively. I think assuming that Orbit is a great finalized design that others fail to appreciate is definitely the wrong starting point. The right starting point is asking for feedback, integrate it, and ask again, all in a loop. Andrei
Feb 15 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 18:20, Andrei Alexandrescu wrote:

 Here's what I think - in order to add things to Phobos and generally the
 standard distribution you must revamp your entire attitude.
Sure I may not have had the best attitude in this discussion. But that has nothing to do with me trying to get Orange into Phobos several years ago.
 I have a lot of sympathy because years ago I was in the exact position.
 I'd written the Loki library for C++ that included many components
 deserving inclusion in C++'s standard library. As a first step I asked
 for Loki to be included in Boost. The attempt was met with interest but
 it soon became obvious that I'd need to go through a difficult review
 and make quite extensive adaptations and changes to the library in order
 to be considered. My attitude was "take it or leave it" and that just
 didn't work (and in retrospect, for the better).
 Part of the proposal was a policy-based smart pointer that was superior
 in every way I could think of to other candidates. Yet the proposers of
 those candidates were willing to go through the hard work of improving
 and streamlining their proposals, to the point they got into Boost and
 ultimately into the standard. With time the relative deficiencies of
 that proposal was reduced by adding more kinds of smart pointers, so in
 the end it all got where it is today. In contrast, I was busy with my
 Ph.D. research so I didn't have the time to file away all rough edges.

 That was a good lesson to learn. Applied to the situation of today, to
 get anything into the D programming language requires determination,
 humility, and willingness to take criticism and convert it positively. I
 think assuming that Orbit is a great finalized design that others fail
 to appreciate is definitely the wrong starting point. The right starting
 point is asking for feedback, integrate it, and ask again, all in a loop.
Well lucky you. I haven't even got a proper review for Orange. I got some comments and feedback but no formal review. Saying something that I don't want to change anything is plain wrong. I got feedback that slices weren't properly deserialized and that it could be problems if the serializer was templated on the archive. That caused me to completely refactor the library, mostly internal. I also got the suggestion to allow to set a serializer for a type both for a given instance of the serializer and globally. This also got implemented. The only thing I haven't implemented that got suggested is support for versions. I haven't done that because I think that this doesn't need direct support because that can be handled by performing custom serialization of a type. The only thing that could have caused problem is that it also supports D1/Tango. But I have said from day one that if it gets accepted I will remove any traces of D1 and Tango. Most of the code is completely independent of D1/Tango and the code which has dependencies is very local that has nothing to do with the actual design of the serializer. About Orbit. I started this thread to try and estimated the cost of refactoring Orbit to fit into Phobos/the D distribution. I started with a list, "this is what Orbit uses that does not exist in Phobos. What can we move to Phobos and what cannot be moved to Phobos. What can we do about the rest.". Then the discussion turned into something else. -- /Jacob Carlborg
Feb 16 2013
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-02-16, 15:42, Jacob Carlborg wrote:

 Well lucky you.
Please, relax. Trust me, we understand you feel miffed. Your attitude here is hurting your case, and that's unnecessary.
 I haven't even got a proper review for Orange. I got some comments and  
 feedback but no formal review.
In December 2011[1] there was a push for review, where you basically said it's not ready yet, referring to a September post[2] asking for a pre-review. Is this all activity there has been? This happened during christmas, which might explain a lack of responses. I understand you want to be sure it'll be included before you do the work that's necessary for it to be included, but there's a bit of chicken-and- egg here. And trust me, we want to see serialization in Phobos. You're close. Have faith (and that comes from an atheist :p).
 Saying something that I don't want to change anything is plain wrong. I  
 got feedback that slices weren't properly deserialized and that it could  
 be problems if the serializer was templated on the archive. That caused  
 me to completely refactor the library, mostly internal.

 I also got the suggestion to allow to set a serializer for a type both  
 for a given instance of the serializer and globally. This also got  
 implemented.

 The only thing I haven't implemented that got suggested is support for  
 versions. I haven't done that because I think that this doesn't need  
 direct support because that can be handled by performing custom  
 serialization of a type.

 The only thing that could have caused problem is that it also supports  
 D1/Tango. But I have said from day one that if it gets accepted I will  
 remove any traces of D1 and Tango. Most of the code is completely  
 independent of D1/Tango and the code which has dependencies is very  
 local that has nothing to do with the actual design of the serializer.
So it's ready for a review now, not just a pre-review? Then tell us. Get a review manager to read through it. Badger him to post it for review. Yup, it's more work than sitting around hoping it will happen, but it has a much higher chance of success. [1]: http://forum.dlang.org/thread/j62f5p$1h07$1 digitalmars.com [2]: http://forum.dlang.org/thread/irscfdwwkapwghfouhom dfeed.kimsufi.thecybershadow.net -- Simen
Mar 20 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-20 17:31, Simen Kjaeraas wrote:

 So it's ready for a review now, not just a pre-review? Then tell us.
 Get a review manager to read through it. Badger him to post it for review.
 Yup, it's more work than sitting around hoping it will happen, but it has
 a much higher chance of success.
I have removed any Tango dependencies, D1 related code and other code that wasn't really necessary. But I'm going to see if I can make the serialization of arrays faster first. Or I should just ask for a review to get help with that. -- /Jacob Carlborg
Mar 20 2013
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-03-20, 20:20, Jacob Carlborg wrote:

 On 2013-03-20 17:31, Simen Kjaeraas wrote:

 So it's ready for a review now, not just a pre-review? Then tell us.
 Get a review manager to read through it. Badger him to post it for  
 review.
 Yup, it's more work than sitting around hoping it will happen, but it  
 has
 a much higher chance of success.
I have removed any Tango dependencies, D1 related code and other code that wasn't really necessary. But I'm going to see if I can make the serialization of arrays faster first. Or I should just ask for a review to get help with that.
I say do the review, make things faster afterwards. There'll always be stuff you can do better, and it's not really harder to do after a review. Plus, that will get it into Phobos faster. Sorry about necroing the thread, btw. My mail client ferked up and hadn't sent mails for a few weeks. -- Simen
Mar 20 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-20 21:18, Simen Kjaeraas wrote:

 I say do the review, make things faster afterwards. There'll always
 be stuff you can do better, and it's not really harder to do after a
 review. Plus, that will get it into Phobos faster.

 Sorry about necroing the thread, btw. My mail client ferked up and
 hadn't sent mails for a few weeks.
I'll do that then. I need to regenerate the docs, then it should be good to go. -- /Jacob Carlborg
Mar 21 2013
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-02-15, 18:20, Andrei Alexandrescu wrote:

 On 2/15/13 11:14 AM, Jacob Carlborg wrote:
 On 2013-02-15 15:28, Steven Schveighoffer wrote:

 That is an overstatement. I'm pretty sure people are interested in
 having serialization in Phobos.
It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now.
Here's what I think - in order to add things to Phobos and generally the standard distribution you must revamp your entire attitude. I have a lot of sympathy because years ago I was in the exact position. I'd written the Loki library for C++ that included many components deserving inclusion in C++'s standard library. As a first step I asked for Loki to be included in Boost. The attempt was met with interest but it soon became obvious that I'd need to go through a difficult review and make quite extensive adaptations and changes to the library in order to be considered. My attitude was "take it or leave it" and that just didn't work (and in retrospect, for the better). Part of the proposal was a policy-based smart pointer that was superior in every way I could think of to other candidates. Yet the proposers of those candidates were willing to go through the hard work of improving and streamlining their proposals, to the point they got into Boost and ultimately into the standard. With time the relative deficiencies of that proposal was reduced by adding more kinds of smart pointers, so in the end it all got where it is today. In contrast, I was busy with my Ph.D. research so I didn't have the time to file away all rough edges. That was a good lesson to learn. Applied to the situation of today, to get anything into the D programming language requires determination, humility, and willingness to take criticism and convert it positively. I think assuming that Orbit is a great finalized design that others fail to appreciate is definitely the wrong starting point. The right starting point is asking for feedback, integrate it, and ask again, all in a loop.
Very good. Thank you. -- Simen
Mar 20 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-02-15, 17:14, Jacob Carlborg wrote:

 On 2013-02-15 15:28, Steven Schveighoffer wrote:

 That is an overstatement.  I'm pretty sure people are interested in
 having serialization in Phobos.
It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now.
It's not listed here: http://wiki.dlang.org/Review_Queue I'm not sure about the intricacies of adding something to the list (this should probably be in the wiki somewhere), so I took the liberty of adding it. If nobody else steps up, I guess I'll have to pretend to be a sensible human and act like a review manager too. Labeled it std.serialization, because I think std.orange might be a tad opaque to newcomers. -- Simen
Mar 20 2013
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-02-15, 17:14, Jacob Carlborg wrote:

 On 2013-02-15 15:28, Steven Schveighoffer wrote:

 That is an overstatement.  I'm pretty sure people are interested in
 having serialization in Phobos.
It's been in the review queue for over two years. I've pushed for it a couple of times to get it reviewed but got no answers. I've basically given up now.
-- Simen
Mar 20 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 14 February 2013 at 22:37:31 UTC, Steven 
Schveighoffer wrote:
 I don't see why dmd distribution needs to include the source 
 for all the tools it uses.  I frequently never touch the source 
 of dmd distribution, I just use the compiled binaries.
Guess why it is close to impossible to get DMD into some Linux distro repositories. If source for official tools won't be available, then gdc and ldc will become rather screwed, too. Not an option.
Feb 15 2013
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 15 Feb 2013 04:17:32 -0500, Dicebot <m.strashun gmail.com> wrote:

 On Thursday, 14 February 2013 at 22:37:31 UTC, Steven Schveighoffer  
 wrote:
 I don't see why dmd distribution needs to include the source for all  
 the tools it uses.  I frequently never touch the source of dmd  
 distribution, I just use the compiled binaries.
Guess why it is close to impossible to get DMD into some Linux distro repositories. If source for official tools won't be available, then gdc and ldc will become rather screwed, too. Not an option.
The issue is not that the source is unavailable, the issue is that the tool requires libraries that Walter does not want to include. -Steve
Feb 15 2013
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-02-14 21:38:24 +0000, Jacob Carlborg <doob me.com> said:

 On 2013-02-14 22:00, Steven Schveighoffer wrote:
 
 The other things, such as xml, I think are more troublesome.  This seems
 like a trivial problem with a trivial solution.
Yes, so what about the other things, such as xml. Any suggestions?
I'm not sure why you don't want to continue using Tango. It's no longer incompatible with Phobos I think. Anyway, you might like this old thing: http://michelf.ca/docs/d/mfr-xml-2010-10-19.zip http://michelf.ca/docs/d/mfr/xml.html http://michelf.ca/docs/d/mfr/xmltok.html I wrote that a few years ago. I don't intend to put more work in it (I have no use for it). I made an incomplete proof of concept for a buffered input range once for it, but I don't think that's part of the package above. If someone want to improve those modules and republish them, feel free. Boost license and all. (And if you have an impression of déjà-vu, it's because I posted almost the same thing to this newsgroup sometime in 2011.) -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Feb 14 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, February 14, 2013 17:45:04 Michel Fortin wrote:
 On 2013-02-14 21:38:24 +0000, Jacob Carlborg <doob me.com> said:
 On 2013-02-14 22:00, Steven Schveighoffer wrote:
 The other things, such as xml, I think are more troublesome. This seems
 like a trivial problem with a trivial solution.
Yes, so what about the other things, such as xml. Any suggestions?
I'm not sure why you don't want to continue using Tango. It's no longer incompatible with Phobos I think.
Anyone is free to use Tango in their own apps, just like they're free to use any 3rd party library. The problem is that Andrei doesn't want anything to be "official" unless it only depends on official stuff (I don't know how Walter feels about that). So, if Orbit is to be D's official package manager (and presumably be in the D-Programming-Language group on github), it can't depend on any libraries other than D's standard library and its own internal libraries. - Jonathan M Davis
Feb 14 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/14/2013 6:06 PM, Jonathan M Davis wrote:
 Anyone is free to use Tango in their own apps, just like they're free to use
 any 3rd party library. The problem is that Andrei doesn't want anything to be
 "official" unless it only depends on official stuff (I don't know how Walter
feels
 about that). So, if Orbit is to be D's official package manager (and presumably
 be in the D-Programming-Language group on github), it can't depend on any
 libraries other than D's standard library and its own internal libraries.
I agree with Andrei, it's part of that "eat your own dogfood" thing, at least for "official" stuff.
Feb 14 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 04:15, Walter Bright wrote:

 I agree with Andrei, it's part of that "eat your own dogfood" thing, at
 least for "official" stuff.
Orbit does, it's written in D. Not something I can say about DMD or probably half of what's included in the DMD distribution. Just because I don't want to create my own XML or Zip library it's not "eat your own dogfood"? That's kind of extreme. -- /Jacob Carlborg
Feb 15 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 15 Feb 2013 09:23:52 +0100
schrieb Jacob Carlborg <doob me.com>:

 On 2013-02-15 04:15, Walter Bright wrote:
 
 I agree with Andrei, it's part of that "eat your own dogfood" thing, at
 least for "official" stuff.
Orbit does, it's written in D. Not something I can say about DMD or probably half of what's included in the DMD distribution. Just because I don't want to create my own XML or Zip library it's not "eat your own dogfood"? That's kind of extreme.
Relax, I guess all that meant was: Phobos' quality needs to be improved to the point that you don't have to look for other solutions. Maybe it also means that in the long run Phobos inevitably grows to support more advanced official tools, probably with graphical user interfaces. -- Marco
Feb 15 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 Feb 2013 22:15:14 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 2/14/2013 6:06 PM, Jonathan M Davis wrote:
 Anyone is free to use Tango in their own apps, just like they're free  
 to use
 any 3rd party library. The problem is that Andrei doesn't want anything  
 to be
 "official" unless it only depends on official stuff (I don't know how  
 Walter feels
 about that). So, if Orbit is to be D's official package manager (and  
 presumably
 be in the D-Programming-Language group on github), it can't depend on  
 any
 libraries other than D's standard library and its own internal  
 libraries.
I agree with Andrei, it's part of that "eat your own dogfood" thing, at least for "official" stuff.
I think holding off on package distribution management because a tool doesn't work exclusively with phobos does not sit well with the goal of practicality. Imagine if we required the compiler to be written in D before it was "official". Include the tool, work on the dogfood later. Note that most of the dependencies are built-in to the tool, not external libs. BTW, I just got a dog, and I call this statement into question, dogs eat freaking anything :) -Steve
Feb 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 15:34, Steven Schveighoffer wrote:

 I think holding off on package distribution management because a tool
 doesn't work exclusively with phobos does not sit well with the goal of
 practicality.  Imagine if we required the compiler to be written in D
 before it was "official".

 Include the tool, work on the dogfood later.  Note that most of the
 dependencies are built-in to the tool, not external libs.
Thank you. -- /Jacob Carlborg
Feb 16 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 03:06, Jonathan M Davis wrote:

 Anyone is free to use Tango in their own apps, just like they're free to use
 any 3rd party library. The problem is that Andrei doesn't want anything to be
 "official" unless it only depends on official stuff (I don't know how Walter
feels
 about that). So, if Orbit is to be D's official package manager (and presumably
 be in the D-Programming-Language group on github), it can't depend on any
 libraries other than D's standard library and its own internal libraries.
Phobos depends on two external libraries, curl and libz. Probably only half of what's included in the DMD distribution is written in D. -- /Jacob Carlborg
Feb 15 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/13 3:21 AM, Jacob Carlborg wrote:
 On 2013-02-15 03:06, Jonathan M Davis wrote:

 Anyone is free to use Tango in their own apps, just like they're free
 to use
 any 3rd party library. The problem is that Andrei doesn't want
 anything to be
 "official" unless it only depends on official stuff (I don't know how
 Walter feels
 about that). So, if Orbit is to be D's official package manager (and
 presumably
 be in the D-Programming-Language group on github), it can't depend on any
 libraries other than D's standard library and its own internal libraries.
Phobos depends on two external libraries, curl and libz. Probably only half of what's included in the DMD distribution is written in D.
We have personally contacted the author of curl and the maintainer of libz to make sure there are no licensing or other issues with bundling their code with the D distribution. Andrei
Feb 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 14:53, Andrei Alexandrescu wrote:

 We have personally contacted the author of curl and the maintainer of
 libz to make sure there are no licensing or other issues with bundling
 their code with the D distribution.
There's no issue in bundling BSD licensed code. That's the whole idea of open and free software. To be able to freely distribute the code. -- /Jacob Carlborg
Feb 15 2013
parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Friday, 15 February 2013 at 14:14:43 UTC, Jacob Carlborg wrote:
 On 2013-02-15 14:53, Andrei Alexandrescu wrote:

 We have personally contacted the author of curl and the 
 maintainer of
 libz to make sure there are no licensing or other issues with 
 bundling
 their code with the D distribution.
There's no issue in bundling BSD licensed code. That's the whole idea of open and free software. To be able to freely distribute the code.
To add to this. BSD requires the license be distributed with Binary forms, Boost explicitly does not. That is their real difference. This is something Walter wants to avoid with the standard library (I agree) but for utility programs it is unimportant since they can be used to build the binary and since they are not distributed with the created binary there is no need to distribute the BSD license. So the discussion for the library Orbit uses should remain related on how much trouble there will be from having an official program use a library not part of d-programming-language/tools and friends.
Feb 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 19:48, Jesse Phillips wrote:

 To add to this. BSD requires the license be distributed with Binary
 forms, Boost explicitly does not. That is their real difference.

 This is something Walter wants to avoid with the standard library (I
 agree) but for utility programs it is unimportant since they can be used
 to build the binary and since they are not distributed with the created
 binary there is no need to distribute the BSD license.
Exactly. This won't affect anything built with the DMD compiler and Phobos.
 So the discussion for the library Orbit uses should remain related on
 how much trouble there will be from having an official program use a
 library not part of d-programming-language/tools and friends.
Yes. We can also discussion why that library cannot be part of d-programming-language/tools and friends. -- /Jacob Carlborg
Feb 16 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/14/13 9:06 PM, Jonathan M Davis wrote:
 On Thursday, February 14, 2013 17:45:04 Michel Fortin wrote:
 On 2013-02-14 21:38:24 +0000, Jacob Carlborg<doob me.com>  said:
 On 2013-02-14 22:00, Steven Schveighoffer wrote:
 The other things, such as xml, I think are more troublesome. This seems
 like a trivial problem with a trivial solution.
Yes, so what about the other things, such as xml. Any suggestions?
I'm not sure why you don't want to continue using Tango. It's no longer incompatible with Phobos I think.
Anyone is free to use Tango in their own apps, just like they're free to use any 3rd party library. The problem is that Andrei doesn't want anything to be "official" unless it only depends on official stuff (I don't know how Walter feels about that). So, if Orbit is to be D's official package manager (and presumably be in the D-Programming-Language group on github), it can't depend on any libraries other than D's standard library and its own internal libraries.
Allow me to qualify this. Tango is a fine library, and it's great that the whole issue of Tango vs. Phobos has been settled by allowing the two to coexist in the same app. That being said, when discussing things to be added to the official canon, there are two aspects to be thought of. First, there's the whole licensing issue - if we start distributing code with heterogeneous licenses we create only headaches for our users. Second, it's about the story we put forward: if the standard library offers some functionality but its own satellite packages redo it from scratch with slightly different names, that's just not good. Andrei
Feb 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 14:35, Andrei Alexandrescu wrote:

 Allow me to qualify this.

 Tango is a fine library, and it's great that the whole issue of Tango
 vs. Phobos has been settled by allowing the two to coexist in the same app.

 That being said, when discussing things to be added to the official
 canon, there are two aspects to be thought of. First, there's the whole
 licensing issue - if we start distributing code with heterogeneous
 licenses we create only headaches for our users. Second, it's about the
 story we put forward: if the standard library offers some functionality
 but its own satellite packages redo it from scratch with slightly
 different names, that's just not good.
The different names are the minor issues. It's rather the XML, zip, net and argument parsing modules that is the problem. -- /Jacob Carlborg
Feb 15 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 23:45, Michel Fortin wrote:

 I'm not sure why you don't want to continue using Tango. It's no longer
 incompatible with Phobos I think.
I do want. Trust me, you have no idea how much I want to continue use it. But nobody else wants to use it. Tango is basically officially banned. -- /Jacob Carlborg
Feb 15 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/13 3:03 AM, Jacob Carlborg wrote:
 On 2013-02-14 23:45, Michel Fortin wrote:

 I'm not sure why you don't want to continue using Tango. It's no longer
 incompatible with Phobos I think.
I do want. Trust me, you have no idea how much I want to continue use it. But nobody else wants to use it. Tango is basically officially banned.
This statement is inappropriate. It is factually false, 100% political, and flame-baiting. Also I have zero sympathy for posturing as a victim. Andrei
Feb 15 2013
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 14 February 2013 at 11:58:13 UTC, Jacob Carlborg 
wrote:
 On 2013-02-14 10:46, Walter Bright wrote:

 I don't understand why one would go around the horn to just 
 check for
 !empty.
I've tried to explain, it shows what the intention is. Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any". It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed.
I totally agree with Walter, it adds useless cognitive load. I thoroughly hate it. I would need to have to look at the doc to know what any means, while !empty, everyone already knows it. And I don't want D to be another Perl, where one can write the same thing in ten different manners, so that it's impossible to recognize patterns or a common style.
Feb 16 2013
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-02-13, 21:19, Walter Bright wrote:

 On 2/12/2013 11:34 PM, Jacob Carlborg wrote:
 On 2013-02-12 22:35, Walter Bright wrote:

 The trivial ones should not be added to Phobos, for example, 'any'  =
 being
 defined as '!empty'. Such things add cognitive load but no value.
This is just an extension to the already existing std.algorithm.any =
 function. I
 think it adds value, that's why I have it. It clearly shows the inten=
t. =
 It's the
 same reason why I think it's good to have explicit interfaces and  =
 abstract
 classes in opposite of how it works in C++.
The any in std.algorithm is defined: -------------- bool any(alias pred, Range)(Range range); Returns true if and only if a value v satisfying the predicate pred ca=
n =
 be found in the forward range range. Performs =CE=9F(r.length) evaluat=
ions of =
 pred.
 --------------

 I see that as very different from !empty.
With one, it works as what is already in std.algorithm. Without, it work= s like Jacob describes. -- = Simen
Mar 20 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 The trivial ones should not be added to Phobos,
The situation is not that simple. Just a general (not specific) note on this topic: Haskell has a standard module named "Prelude" that is usually loaded automatically at the start. It contains several commonly useful functions, types and constants: http://www.haskell.org/onlinereport/standard-prelude.html You can think of lot of the stuff you see in the Prelude as "trivial", like concatMap, that is just one line of very simple code (plus a first optional line that gives its type): concatMap :: (a -> [b]) -> [a] -> [b] concatMap f = concat . map f Yet I think most Haskell programmers think it's a good idea to keep that stuff there. concatMap becomes a "chunk" so it reduces the thinking load of the programmer. And in some libraries there are "alternative" versions of concatMap that work on different types, like "packed" vectorized sequences, that are faster, but with the the same usage for the programmer. Bye, bearophile
Feb 14 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/14/2013 12:32 AM, bearophile wrote:
 Walter Bright:

 The trivial ones should not be added to Phobos,
The situation is not that simple.
The trouble is, where do you stop adding trivia? How about this one: T addThree(T t) { return t + 3; } ? A good interface design has the *minimum* number of functions out of which anything else can be built. Functions that are recombinations of other functions in the same interface do not belong in that interface. It's tempting to create kitchen sink abstractions, but they really are a bad idea.
Feb 14 2013
next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 14 Feb 2013 02:00:20 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:

 The trouble is, where do you stop adding trivia? How about this one:
 
     T addThree(T t) { return t + 3; }
 
 ?
I thought that's _why_ we have ++ and --. -- Marco
Feb 15 2013
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-02-15, 14:38, Marco Leise wrote:

 Am Thu, 14 Feb 2013 02:00:20 -0800
 schrieb Walter Bright <newshound2 digitalmars.com>:

 The trouble is, where do you stop adding trivia? How about this one:

     T addThree(T t) { return t + 3; }

 ?
I thought that's _why_ we have ++ and --.
Indeed. ++++++t is just as readable as the above. :p -- Simen
Mar 20 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 14 February 2013 at 10:01:21 UTC, Walter Bright 
wrote:
 On 2/14/2013 12:32 AM, bearophile wrote:
 Walter Bright:
A good interface design has the *minimum* number of functions out of which anything else can be built. Functions that are recombinations of other functions in the same interface do not belong in that interface. It's tempting to create kitchen sink abstractions, but they really are a bad idea.
Yes, it actually makes reading code *harder* for everyone but the writer, because the code ends up lacking consistency.
Feb 16 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/16/2013 10:35 AM, SomeDude wrote:
 On Thursday, 14 February 2013 at 10:01:21 UTC, Walter Bright wrote:
 On 2/14/2013 12:32 AM, bearophile wrote:
 Walter Bright:
A good interface design has the *minimum* number of functions out of which anything else can be built. Functions that are recombinations of other functions in the same interface do not belong in that interface. It's tempting to create kitchen sink abstractions, but they really are a bad idea.
Yes, it actually makes reading code *harder* for everyone but the writer, because the code ends up lacking consistency.
My own experience is it makes it harder for the writer, too :-) Also, it often takes several iterations to discover just what the right minimum set is. Nobody gets it right the first time.
Feb 16 2013
prev sibling next sibling parent reply FG <home fgda.pl> writes:
On 2013-02-12 15:21, Steven Schveighoffer wrote:
 string pluralize(string x, int count)
 {
     return count > 1 ? x ~ "s" : x;
 }
You mean: return count != 1 ? x ~ "s" : x; For special cases there could be a third optional argument: string pluralize(int count, string sng, string pl="") { return count == 1 ? sng : pl.length ? pl : sng ~ "s"; } writeln(pluralize(2, "cat")); writeln(pluralize(2, "radius", "radii")); That's for simple English-only pluralization, before we jump into translations.
Feb 12 2013
parent reply "qznc" <qznc go.to> writes:
On Tuesday, 12 February 2013 at 16:38:54 UTC, FG wrote:
 On 2013-02-12 15:21, Steven Schveighoffer wrote:
 string pluralize(string x, int count)
 {
    return count > 1 ? x ~ "s" : x;
 }
You mean: return count != 1 ? x ~ "s" : x; For special cases there could be a third optional argument: string pluralize(int count, string sng, string pl="") { return count == 1 ? sng : pl.length ? pl : sng ~ "s"; } writeln(pluralize(2, "cat")); writeln(pluralize(2, "radius", "radii")); That's for simple English-only pluralization, before we jump into translations.
Do not go down that rabbit hole! Just skim over the following links to get an idea how complicated this becomes. https://developer.mozilla.org/en/docs/Localization_and_Plurals http://doc.qt.digia.com/qq/qq19-plurals.html I am not sure, if any internationalization stuff should be in std. No matter how you do it, it will be too simple for some and too over-engineered for others. There will always be multiple solutions on different levels of power and applications have to choose, which suits them best. My advice: If you find your self wanting that, try to rephrase first. For example, instead of "there are %d cat(s)" output "number of cats: %d". It will be much easier to internationalize.
Feb 12 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 12 February 2013 at 19:38:56 UTC, qznc wrote:
 On Tuesday, 12 February 2013 at 16:38:54 UTC, FG wrote:
 On 2013-02-12 15:21, Steven Schveighoffer wrote:
 string pluralize(string x, int count)
 {
   return count > 1 ? x ~ "s" : x;
 }
You mean: return count != 1 ? x ~ "s" : x; For special cases there could be a third optional argument: string pluralize(int count, string sng, string pl="") { return count == 1 ? sng : pl.length ? pl : sng ~ "s"; } writeln(pluralize(2, "cat")); writeln(pluralize(2, "radius", "radii")); That's for simple English-only pluralization, before we jump into translations.
Do not go down that rabbit hole! Just skim over the following links to get an idea how complicated this becomes. https://developer.mozilla.org/en/docs/Localization_and_Plurals http://doc.qt.digia.com/qq/qq19-plurals.html I am not sure, if any internationalization stuff should be in std. No matter how you do it, it will be too simple for some and too over-engineered for others. There will always be multiple solutions on different levels of power and applications have to choose, which suits them best. My advice: If you find your self wanting that, try to rephrase first. For example, instead of "there are %d cat(s)" output "number of cats: %d". It will be much easier to internationalize.
Agreed. It's such an enormous problem, even just in English. You're much better off creating a special tool that satisfies your own needs for the specific set of words that you need pluralisin.
Feb 12 2013
prev sibling next sibling parent FG <home fgda.pl> writes:
On 2013-02-12 20:38, qznc wrote:
 Do not go down that rabbit hole! Just skim over the following links to get an
 idea how complicated this becomes.
I know that. Usually I define my own pluralize for the one or two languages I use. Good enough solution when you don't need to have your software translated into all possible languages. Last chat we had about i18n and making our own flavor of gettext ended up with the statement that apparently we need keyword arguments in writefln format strings first... so I decided to rest my case. ;)
Feb 12 2013
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 12 Feb 2013 20:38:54 +0100
schrieb "qznc" <qznc go.to>:

 
 There will always be multiple solutions on different levels of 
 power and applications have to choose, which suits them best.
 
 My advice: If you find your self wanting that, try to rephrase 
 first.
 
 For example, instead of "there are %d cat(s)" output "number of 
 cats: %d". It will be much easier to internationalize.
The gettext approach works quite well: There's no pluralize function. Instead you pass a singular and plural form and a number: ngettext(string singular, string plural, int num). Of course this works only for english strings, but that's what you use in your source code: writefln("Have %s %s", num, ngettext("message", "messages", num)); Other languages are handled transparently in the translation process: The translator can specify as many plural forms as necessary. A language specific formula then determines the correct plural form: http://translate.sourceforge.net/wiki/l10n/pluralforms
Feb 13 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, February 12, 2013 09:21:08 Steven Schveighoffer wrote:
 * pluralize - Takes a string and a count. If the count is greater than 1
 it converts the word in the string to plural
basic version: string pluralize(string x, int count) { return count > 1 ? x ~ "s" : x; } Now, you probably would need a simple mechanism to do the different plural forms. Sometimes 'es' must be added, sometimes 'y' must be changed to 'ies', etc. But that should be a simple switch statement. The switch statement would select a different ending, and a prefix count based on the current ending.
Actually, given that that's English-specific, I don't know that we'd actually want that. I think that we do have a few English-specific items in Phobos, but for the most part, that really belongs in internationalization of some variety. But maybe it would be okay to add. If not, given how simple it is, if Orbit really needs it, I wouldn't think that it would be a big deal for it to just include it internally. - Jonathan M Davis
Feb 12 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/12/2013 4:38 AM, Jacob Carlborg wrote:
 * Serialization - Does not exist
The existence of UDAs should dramatically affect the design of a serialization library.
Feb 12 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-12 22:40, Walter Bright wrote:

 The existence of UDAs should dramatically affect the design of a
 serialization library.
It didn't dramatically affect my serialization library. I already used a poor man's implementation of UDAs, perhaps that's why. Without UDA: class Foo { int a; int b; mixin NonSerialized!(b); } With UDA: class Foo { int a; nonSerialized int b; } The UDAs just add some syntax sugar. -- /Jacob Carlborg
Feb 12 2013
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 12 Feb 2013 13:38:53 +0100
schrieb Jacob Carlborg <doob me.com>:

 I've compiled a list below of things used in Orbit (directly or 
 indirectly) that Phobos is lacking in. Please tell me if I'm wrong:
I can only tell you what of that list I would have had a use for myself in the past:
    * Configuration
Yes, native to the environment (e.g. use \AppData\Roaming on Windows or .config on Linux)
 * ConfigMap -  Does not exist. An associative array with opDispatch 
 added to it. Allows to do things like:
 
 auto config = ConfigMap();
 config.foo = "asd";
 config.bar.foo.baz = "foobar";
 
 assert(config.foo == "asd");
I loaded an .INI template at CT (with default values and type inference) and created nested structs from that. Was fun to do in D. No matter what the implementation is, this is useful.
 * std.process - I have not used it myself but I've heard it's not optimal
The biggest shortcoming is that you cannot do IPC with it, as it doesn't give you two-way pipes to the child process. Again, that's useful and IIRC was in the std.process replacement.
 * std.getopt - Doesn't support the following:
    * Required arguments
    * Restricting the values of a given argument
    * No way to automatically create a help/usage list out of the arguments
    * Handling positional arguments
    * No support for commands/action. That is "git commit", "commit" 
 would be the command/action
    * Handle multiple command lines
    * Validation of the arguments
All of that except "action" and "multiple command lines". Validation is probably too complex to include at the spot. I mean, sometimes you need to validate the combination of all options, so you can just as well write a separate function.
 CTFE:
I think most of that exists in Phobos or can be constructed in one line of code:
 * format - A simple formatting function
 * indexOf
 * contains
staticIndexOf!(something, Tuple) != -1
 * fieldsOf - Returns all the fields of the given type
 * hasField - Returns true if the given type has the given field
staticIndexOf!(field, fieldsOf!Type) != -1
 * TypeOfField - Returns the type of a field
 * nameOfFieldAt - Returns the name of the field at the given position
 * set/getValueOfField - Sets/gets the value of a field
:( No idea... at least without mixins.
 * newInstance - Returns a new instance based on the class name or 
 ClassInfo. Can handle any class regardless of constructors
So I figure, Object.factory("ClassName") is too limited. I used to just force my code work with that one. -- Marco
Feb 13 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, February 13, 2013 09:34:36 Marco Leise wrote:
 * format - A simple formatting function
format now works in CTFE. Format should go the way of the dodo. It's insanely inefficient. - Jonathan M Davis
Feb 13 2013
next sibling parent FG <home fgda.pl> writes:
On 2013-02-13 09:45, Jonathan M Davis wrote:
 On Wednesday, February 13, 2013 09:34:36 Marco Leise wrote:
 * format - A simple formatting function
format now works in CTFE. Format should go the way of the dodo. It's insanely inefficient.
Could you please add this info to std.metastrings' ddoc?
Feb 13 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-13 09:45, Jonathan M Davis wrote:

 format now works in CTFE. Format should go the way of the dodo. It's insanely
 inefficient.
Ok, cool. -- /Jacob Carlborg
Feb 13 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-13 09:34, Marco Leise wrote:
 Am Tue, 12 Feb 2013 13:38:53 +0100
 schrieb Jacob Carlborg <doob me.com>:

 I've compiled a list below of things used in Orbit (directly or
 indirectly) that Phobos is lacking in. Please tell me if I'm wrong:
I can only tell you what of that list I would have had a use for myself in the past:
     * Configuration
Yes, native to the environment (e.g. use \AppData\Roaming on Windows or .config on Linux)
I didn't necessarily mean native configuration. I was referring to configuration internally for the application. But it could be useful to save to disk as well.
 All of that except "action" and "multiple command lines".
 Validation is probably too complex to include at the spot. I
 mean, sometimes you need to validate the combination of all
 options, so you can just as well write a separate function.
I would I do that when I only need so simple validation? Like that an argument is required. The arguments parser in Tango can handle validation.
 CTFE:
I think most of that exists in Phobos or can be constructed in one line of code:
 * format - A simple formatting function
 * indexOf
 * contains
staticIndexOf!(something, Tuple) != -1
 * fieldsOf - Returns all the fields of the given type
 * hasField - Returns true if the given type has the given field
staticIndexOf!(field, fieldsOf!Type) != -1
That's good. But I would really prefer something like "hasField" instead of the above. It clearly shows that's going on.
 * TypeOfField - Returns the type of a field
 * nameOfFieldAt - Returns the name of the field at the given position
 * set/getValueOfField - Sets/gets the value of a field
:( No idea... at least without mixins.
There's no reason for mixins.
 So I figure, Object.factory("ClassName") is too limited. I
 used to just force my code work with that one.
Yes, it's too limited. Object.factory will only work for classes with a default constructor or a constructor which doesn't take any arguments. If it's unclear, I already have all of this functionality implemented. It's just not in Phobos. -- /Jacob Carlborg
Feb 13 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
13-Feb-2013 12:34, Marco Leise пишет:
 Am Tue, 12 Feb 2013 13:38:53 +0100
 schrieb Jacob Carlborg <doob me.com>:

 I've compiled a list below of things used in Orbit (directly or
 indirectly) that Phobos is lacking in. Please tell me if I'm wrong:
I can only tell you what of that list I would have had a use for myself in the past:
     * Configuration
Yes, native to the environment (e.g. use \AppData\Roaming on Windows or .config on Linux)
 * ConfigMap -  Does not exist. An associative array with opDispatch
 added to it. Allows to do things like:

 auto config = ConfigMap();
 config.foo = "asd";
 config.bar.foo.baz = "foobar";

 assert(config.foo == "asd");
I loaded an .INI template at CT (with default values and type inference) and created nested structs from that. Was fun to do in D. No matter what the implementation is, this is useful.
 * std.process - I have not used it myself but I've heard it's not optimal
The biggest shortcoming is that you cannot do IPC with it, as it doesn't give you two-way pipes to the child process. Again, that's useful and IIRC was in the std.process replacement.
 * std.getopt - Doesn't support the following:
     * Required arguments
     * Restricting the values of a given argument
     * No way to automatically create a help/usage list out of the arguments
     * Handling positional arguments
     * No support for commands/action. That is "git commit", "commit"
 would be the command/action
     * Handle multiple command lines
     * Validation of the arguments
All of that except "action" and "multiple command lines". Validation is probably too complex to include at the spot. I mean, sometimes you need to validate the combination of all options, so you can just as well write a separate function.
 CTFE:
I think most of that exists in Phobos or can be constructed in one line of code:
 * format - A simple formatting function
This should never see the light of day. Use plain format from std.string it works with CTFE and many, many times faster. In fact the whole metastrings should be obliterated. -- Dmitry Olshansky
Feb 13 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 13 Feb 2013 03:34:36 -0500, Marco Leise <Marco.Leise gmx.de> wrote:

 Am Tue, 12 Feb 2013 13:38:53 +0100
 schrieb Jacob Carlborg <doob me.com>:
 * newInstance - Returns a new instance based on the class name or
 ClassInfo. Can handle any class regardless of constructors
So I figure, Object.factory("ClassName") is too limited. I used to just force my code work with that one.
Hm... I think all we need is a public interface to _d_newclass in druntime: extern (C) Object _d_newclass(const ClassInfo ci) In fact, it is pretty much public, since it's extern(C). -Steve
Feb 13 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-13 20:39, Steven Schveighoffer wrote:

 Hm... I think all we need is a public interface to _d_newclass in druntime:

 extern (C) Object _d_newclass(const ClassInfo ci)

 In fact, it is pretty much public, since it's extern(C).
That's what I'm using. -- /Jacob Carlborg
Feb 13 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-12 13:38, Jacob Carlborg wrote:
 In the thread "Expanding Phobos from a flat hierarchy" there started a
 discussion about package managers. Of course I mentioned the package
 manager I'm working on, Orbit. Unfortunately people weren't very happy
 with the third party dependencies. So I compiled a list of what's
 missing from Phobos, but I never got an answer to that post in the
 thread. I have now repeated the list below of what Orbit needs that
 don't exist in Phobos. I hope I have better luck here.

 Repeated message:

 I've compiled a list below of things used in Orbit (directly or
 indirectly) that Phobos is lacking in. Please tell me if I'm wrong:
If it's unclear, I already have all of this functionality implemented. It's just not in Phobos. -- /Jacob Carlborg
Feb 13 2013
prev sibling next sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 12 Feb 2013 12:38:53 -0000, Jacob Carlborg <doob me.com> wrote:
 * std.getopt - Doesn't support the following:
    * Required arguments
    * Restricting the values of a given argument
    * No way to automatically create a help/usage list out of the  
 arguments
    * Handling positional arguments
    * No support for commands/action. That is "git commit", "commit"  
 would be the command/action
    * Handle multiple command lines
    * Validation of the arguments
Just a minor point from me. I reckon the functionality you want can and should be built on top of std.getopt. As others have said you could either do this first and get it submitted to phobos, and then work on the other issues and getting Orbit itself in there.. or you can build this functionality into a module within Orbit and then work on getting that extracted as a separate module in phobos. The former delays ppl being able to use Orbit, the latter means more work down the line to refactor Orbit - tho hopefully this will just be an import declaration change, tho it may also include a slight API change if ppl are unhappy with the existing one. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Feb 14 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 13:20, Regan Heath wrote:

 Just a minor point from me.  I reckon the functionality you want can and
 should be built on top of std.getopt.

 As others have said you could either do this first and get it submitted
 to phobos, and then work on the other issues and getting Orbit itself in
 there.. or you can build this functionality into a module within Orbit
 and then work on getting that extracted as a separate module in phobos.

 The former delays ppl being able to use Orbit, the latter means more
 work down the line to refactor Orbit - tho hopefully this will just be
 an import declaration change, tho it may also include a slight API
 change if ppl are unhappy with the existing one.
Andrei said there's stuff he didn't want at all, like the "dstack" library. I don't know if he means in Phobos or in Orbit at all. -- /Jacob Carlborg
Feb 14 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Feb-2013 00:03, Jacob Carlborg пишет:
 On 2013-02-14 13:20, Regan Heath wrote:

 Just a minor point from me.  I reckon the functionality you want can and
 should be built on top of std.getopt.

 As others have said you could either do this first and get it submitted
 to phobos, and then work on the other issues and getting Orbit itself in
 there.. or you can build this functionality into a module within Orbit
 and then work on getting that extracted as a separate module in phobos.

 The former delays ppl being able to use Orbit, the latter means more
 work down the line to refactor Orbit - tho hopefully this will just be
 an import declaration change, tho it may also include a slight API
 change if ppl are unhappy with the existing one.
Andrei said there's stuff he didn't want at all, like the "dstack" library. I don't know if he means in Phobos or in Orbit at all.
I believe that the idea is that any amount of helpers is fine as long as they are private and don't obfuscate code. Phobos contains a lot tiny helpers that _might_ be useful but not exposed because of dubious general utility and potentially confusing names. As far pushing good primitives into Phobos, it'd better be done one step at time and decoupled of the actual inclusion of Orbit (if we can agree on it being included) into say tools repo and being bundled with DMD. -- Dmitry Olshansky
Feb 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 21:14, Dmitry Olshansky wrote:

 I believe that the idea is that any amount of helpers is fine as long as
 they are private and don't obfuscate code. Phobos contains a lot tiny
 helpers that _might_ be useful but not exposed because of dubious
 general utility and potentially confusing names.

 As far pushing good primitives into Phobos, it'd better be done one step
 at time and decoupled of the actual inclusion of Orbit (if we can agree
 on it being included) into say tools repo and being bundled with DMD.
I agree that might be the best idea. But that is mostly for the "any" function and similar smaller utility functions. The bigger problems are like the serialization modules. Sure they could be put directly in Orbit as well. But I still got dependencies on Tango for stuff like XML, Zip, net and argument parsing. -- /Jacob Carlborg
Feb 14 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Feb-2013 00:18, Jacob Carlborg пишет:
 On 2013-02-14 21:14, Dmitry Olshansky wrote:

 I believe that the idea is that any amount of helpers is fine as long as
 they are private and don't obfuscate code. Phobos contains a lot tiny
 helpers that _might_ be useful but not exposed because of dubious
 general utility and potentially confusing names.

 As far pushing good primitives into Phobos, it'd better be done one step
 at time and decoupled of the actual inclusion of Orbit (if we can agree
 on it being included) into say tools repo and being bundled with DMD.
 I agree that might be the best idea. But that is mostly for the "any"
 function and similar smaller utility functions. The bigger problems are
 like the serialization modules. Sure they could be put directly in Orbit
 as well. But I still got dependencies on Tango for stuff like XML, Zip,
 net and argument parsing.
Then there are these ways forward IMHO: a) Admit that tango for D2 exists (easy) and bundle it with DMD (the hard/not likely/inconvenient part) b) Agree that we need to port it and issue a call to port/re-write required facilities for Orbit on top of phobos/curl. This means pulls against Orbit repo not phobos BTW. c) Forget about Orbit and try something else, like Dub? About serialization (that seems the biggest roadblock) - what exactly does Orbit need it for? Maybe it can be decoupled and/or easily re-written by hand until Orange or similar stuff gets into Phobos. Regardless I think reducing dependencies is the important for inclusion of any new component into the "D core". -- Dmitry Olshansky
Feb 14 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 14 February 2013 at 20:33:35 UTC, Dmitry Olshansky 
wrote:
 About serialization (that seems the biggest roadblock) - what 
 exactly does Orbit need it for? Maybe it can be decoupled 
 and/or easily re-written by hand until Orange or similar stuff 
 gets into Phobos.
I personally don't see why orange can't just be included as part of orbit. It's written and maintained by the same person after all.
Feb 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 22:21, John Colvin wrote:

 I personally don't see why orange can't just be included as part of
 orbit. It's written and maintained by the same person after all.
Sure it can. Would that be ok? -- /Jacob Carlborg
Feb 14 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 14 February 2013 at 21:40:41 UTC, Jacob Carlborg 
wrote:
 On 2013-02-14 22:21, John Colvin wrote:

 I personally don't see why orange can't just be included as 
 part of
 orbit. It's written and maintained by the same person after 
 all.
Sure it can. Would that be ok?
I would see it as a good test of the library, helping to iron out issues before perhaps being included in phobos in future. Seems like everyone wins.
Feb 14 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Feb-2013 01:40, Jacob Carlborg пишет:
 On 2013-02-14 22:21, John Colvin wrote:

 I personally don't see why orange can't just be included as part of
 orbit. It's written and maintained by the same person after all.
Sure it can. Would that be ok?
It could then the only roadblock is dependency on Tango. The only problem I had with serialization is that it's like using huge module to do the "dump this struct in JSON" kind of thing that's doable in 20-30 lines. In the option b Anyway the comment about porting from Tango still applies. -- Dmitry Olshansky
Feb 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 07:29, Dmitry Olshansky wrote:

 It could then the only roadblock is dependency on Tango.
 The only problem I had with serialization is that it's like using huge
 module to do the "dump this struct in JSON" kind of thing that's doable
 in 20-30 lines.
It's not huge. I already had the serialization library available. Not using it would be stupid. Having 30k+ lines of code just to get the time _is_ huge.
 In the option b Anyway the comment about porting from Tango still applies.
Just because you guys are too stubborn to include it in the distribution. -- /Jacob Carlborg
Feb 15 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Feb-2013 12:29, Jacob Carlborg пишет:
 On 2013-02-15 07:29, Dmitry Olshansky wrote:

 It could then the only roadblock is dependency on Tango.
 The only problem I had with serialization is that it's like using huge
 module to do the "dump this struct in JSON" kind of thing that's doable
 in 20-30 lines.
It's not huge. I already had the serialization library available. Not using it would be stupid. Having 30k+ lines of code just to get the time _is_ huge.
With through unittests being about 50% of the said code... Plus it's not get the time (nobody stops you from calling gettimeofday of POSIX) and calendar/timezones stuff is ridiculously hard to get right, I for one wouldn't try to re-implement it. That being said I like slim stuff with no baggage and yes, std.datetime is huge. Dumping anything to JSON and back is an easy task in D, see e.g. this one: https://github.com/CyberShadow/ae/blob/master/utils/json.d That's why I asked what _exactly_ of serialization (as in capabilities) is required.
 In the option b Anyway the comment about porting from Tango still
 applies.
Just because you guys are too stubborn to include it in the distribution.
Nice touch, "you guys" is very assuming. IMHO (personal opinion) the problems boil down to the fact that Tango: a) Still has incompatible license-wise b) Half of it is already doable (if not better) in Phobos c) Has largely incompatible interface and design d) Somebody got to maintain it in the official repo too Of the above I think a) and d) are the key ones. -- Dmitry Olshansky
Feb 15 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 15, 2013 13:03:04 Dmitry Olshansky wrote:
 15-Feb-2013 12:29, Jacob Carlborg =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 On 2013-02-15 07:29, Dmitry Olshansky wrote:
 It could then the only roadblock is dependency on Tango.
 The only problem I had with serialization is that it's like using =
huge
 module to do the "dump this struct in JSON" kind of thing that's d=
oable
 in 20-30 lines.
=20 It's not huge. I already had the serialization library available. N=
ot
 using it would be stupid.
 Having 30k+ lines of code just to get the time _is_ huge.
=20 With through unittests being about 50% of the said code... Plus it's not get the time (nobody stops you from calling gettimeofda=
y
 of POSIX)
 and calendar/timezones stuff is ridiculously hard to get right,
 I for one wouldn't try to re-implement it.
=20
 That being said I like slim stuff with no baggage and yes, std.dateti=
me
 is huge.
Tests are over half of it, and the documentation is probably around hal= f of=20 what's left after that, and those tests are critical. As simple as much= of the=20 code is, it's ridiculously easy to get stuff wrong when it comes to cor= ner=20 cases. And it's doing a _lot_ more than getting the time. So, for the m= ost=20 part, I think that it merits being as large as it is. It's the fact tha= t it's=20 all in one module that's the problem (and it was actually split in my o= riginal=20 proposal, but I split it badly, and I was told to put it back together = again.=20 It also changed quite a lot over the course of the review). I _would_ like to split it up though. But I'm not going to do it until = some=20 variant of DIP 15 or 16 is implemented so that it can be split up in pl= ace=20 without breaking any code. - Jonathan M Davis
Feb 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 10:14, Jonathan M Davis wrote:

 Tests are over half of it, and the documentation is probably around half of
 what's left after that, and those tests are critical. As simple as much of the
 code is, it's ridiculously easy to get stuff wrong when it comes to corner
 cases. And it's doing a _lot_ more than getting the time. So, for the most
 part, I think that it merits being as large as it is. It's the fact that it's
 all in one module that's the problem (and it was actually split in my original
 proposal, but I split it badly, and I was told to put it back together again.
 It also changed quite a lot over the course of the review).

 I _would_ like to split it up though. But I'm not going to do it until some
 variant of DIP 15 or 16 is implemented so that it can be split up in place
 without breaking any code.
The easy solution would be to have the tests in its own module, in its own directory structure. But that's a no no since apparently "tests in D are supposed to be inline". -- /Jacob Carlborg
Feb 15 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 15, 2013 11:10:04 Jacob Carlborg wrote:
 On 2013-02-15 10:14, Jonathan M Davis wrote:
 Tests are over half of it, and the documentation is probably around half
 of
 what's left after that, and those tests are critical. As simple as much of
 the code is, it's ridiculously easy to get stuff wrong when it comes to
 corner cases. And it's doing a _lot_ more than getting the time. So, for
 the most part, I think that it merits being as large as it is. It's the
 fact that it's all in one module that's the problem (and it was actually
 split in my original proposal, but I split it badly, and I was told to
 put it back together again. It also changed quite a lot over the course
 of the review).
 
 I _would_ like to split it up though. But I'm not going to do it until
 some
 variant of DIP 15 or 16 is implemented so that it can be split up in place
 without breaking any code.
The easy solution would be to have the tests in its own module, in its own directory structure. But that's a no no since apparently "tests in D are supposed to be inline".
And it would make maintenance harder. I find that it's extremely valuable to have the tests right after the functions that they're testing. It's extremely annoying that you can't generally do that with templated types (because then the tests are instantiated with the template). I'd hate to put the tests separate from the functions that they're testing. And I don't find that the size of the file is really a problem. The problem is the size of the generated documentation. _That's_ what really needs to be split up, and if the generated docs were to be split without changing std/datetime.d, that would solve 95% of the problem. Having the various types organized into sub-modules would help somewhat with maintainence, but not a lot. I use vim's search capabilities for finding everything in source code normally anyway. Scrolling is way too slow in comparison even for small modules. I know that you like the idea of separating the tests from the code, and maybe that works well for you, but that just doesn't work well for me. I very much like the fact that the normal place to put unit tests in D is right after the function being tested. - Jonathan M Davis
Feb 15 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/13 3:29 AM, Jacob Carlborg wrote:
 On 2013-02-15 07:29, Dmitry Olshansky wrote:

 It could then the only roadblock is dependency on Tango.
 The only problem I had with serialization is that it's like using huge
 module to do the "dump this struct in JSON" kind of thing that's doable
 in 20-30 lines.
It's not huge. I already had the serialization library available. Not using it would be stupid. Having 30k+ lines of code just to get the time _is_ huge.
 In the option b Anyway the comment about porting from Tango still
 applies.
Just because you guys are too stubborn to include it in the distribution.
I think this is an unfair characterization. My understanding of your position is as follows. You have code that's working just fine. It uses this and that library here and there - more or less intensively, but that's the way it always is with libraries. Since it's there and is working, you'd want to take the path of least resistance to including it in the standard distribution. That's an understandable position to be having. It also will not lead to the inclusion of your code as part of the standard distribution for simple and objective reasons: licensing and overlapping functionality. I understand this can be frustrating, but it should give no reason to adopt posturing and attribute fault without reason. Andrei
Feb 15 2013
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Feb 15, 2013, at 3:29 AM, Jacob Carlborg <doob me.com> wrote:

 On 2013-02-15 07:29, Dmitry Olshansky wrote:
=20
 It could then the only roadblock is dependency on Tango.
 The only problem I had with serialization is that it's like using huge
 module to do the "dump this struct in JSON" kind of thing that's doable
 in 20-30 lines.
=20 It's not huge. I already had the serialization library available. Not usin=
g it would be stupid.
=20
 Having 30k+ lines of code just to get the time _is_ huge.
=20
 In the option b Anyway the comment about porting from Tango still applies=
.
=20
 Just because you guys are too stubborn to include it in the distribution.
Tango is distributed under an incompatible license. A license that unfortuna= tely can't be changed because many of the Tango authors are MIA. There's not= hing political involved. And if the dependency is just on a JSON module, tha= t's easy to resolve. We have a new std.json module in the queue anyway, don'= t we?=
Feb 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 16:22, Sean Kelly wrote:

 Tango is distributed under an incompatible license. A license that
unfortunately can't be changed
 because many of the Tango authors are MIA.
It does not need to be changed. It just needs to be included in the distribution of DMD. Nothing that uses DMD or Phobos will be affected. Well, that's actually only necessary if the source code of Orbit itself is included with DMD. Apparently the source code for RDMD is not included.
 There's nothing political involved. And if the dependency is
 just on a JSON module, that's easy to resolve.
The large dependencies it has are: XML, net, ZIP and argument parsing. Then there are some utility functions, but they are the least of the problem.
 We have a new std.json module in the queue anyway, don't we?
That's another problem. In Tango there is working code right now, not possibly some time in the future. -- /Jacob Carlborg
Feb 16 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 21:33, Dmitry Olshansky wrote:

 Then there are these ways forward IMHO:
 a) Admit that tango for D2 exists (easy) and bundle it with DMD (the
 hard/not likely/inconvenient part)
Yeah, that would be the easy and IMHO the best solution.
 b) Agree that we need to port it and issue a call to port/re-write
 required facilities for Orbit on top of phobos/curl. This means pulls
 against Orbit repo not phobos BTW.
 c) Forget about Orbit and try something else, like Dub?

 About serialization (that seems the biggest roadblock) - what exactly
 does Orbit need it for? Maybe it can be decoupled and/or easily
 re-written by hand until Orange or similar stuff gets into Phobos.
It probably can. But I already had a working serializer and it's easy to just to "serialize(data)" instead of doing it manually. It uses the serializer for saving an index to disk.
 Regardless I think reducing dependencies is the important for inclusion
 of any new component into the "D core".
In general I think that the D community should embrace all developers/contributors and existing libraries. It cannot afford to loose contributions for petty things like this. -- /Jacob Carlborg
Feb 14 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Feb-2013 01:49, Jacob Carlborg пишет:
 On 2013-02-14 21:33, Dmitry Olshansky wrote:
 [snip]
 Regardless I think reducing dependencies is the important for inclusion
 of any new component into the "D core".
In general I think that the D community should embrace all developers/contributors and existing libraries.
Not talking about your stuff in particular but in general - hell no. There is a line between accepting everything just because we can't lose the chance (hence current std.xml, std.json and other crappy stuff) and accepting decent stuff that was specifically following current Phobos idoms, was reviewed, etc. The latter puts quite a strain on the contributor and in the end should guarantee the quality of addition (and commitment to maintain it). That being said once package manager is there tested and solid 3-rd party libs will flow. (tested & solid simply because of greater exposure factor)
 It cannot afford to
 loose contributions for petty things like this.
I'd say if contributor can't be bothered to follow conventions and deal with the constraints imposed, just let him go. Coherency is all important in the core part of pretty much anything. -- Dmitry Olshansky
Feb 14 2013
next sibling parent reply "sclytrack" <sclytrack third.com> writes:
On Friday, 15 February 2013 at 06:44:57 UTC, Dmitry Olshansky 
wrote:
 15-Feb-2013 01:49, Jacob Carlborg пишет:
 On 2013-02-14 21:33, Dmitry Olshansky wrote:
 [snip]
 Regardless I think reducing dependencies is the important for 
 inclusion
 of any new component into the "D core".
In general I think that the D community should embrace all developers/contributors and existing libraries.
Not talking about your stuff in particular but in general - hell no. There is a line between accepting everything just because we can't lose the chance (hence current std.xml, std.json and other crappy stuff) and accepting decent stuff that was specifically following current Phobos idoms, was reviewed, etc. The latter puts quite a strain on the contributor and in the end should guarantee the quality of addition (and commitment to maintain it). That being said once package manager is there tested and solid 3-rd party libs will flow. (tested & solid simply because of greater exposure factor)
 It cannot afford to
 loose contributions for petty things like this.
I'd say if contributor can't be bothered to follow conventions and deal with the constraints imposed, just let him go. Coherency is all important in the core part of pretty much anything.
When is D going to officially release with official third party libraries? Like synchronized with the release of dmd and bundled together in a huge (as large as possible) compressed file. Like Derelict, Gtkd, Qtd, Vibe, Apache Thrift. I mean not included in phobos but included in the release.
Feb 14 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 15, 2013 08:50:14 sclytrack wrote:
 When is D going to officially release with official third party
 libraries? Like synchronized with the release of dmd and bundled
 together in a huge (as large as possible) compressed file. Like
 Derelict, Gtkd, Qtd, Vibe, Apache Thrift. I mean not included in
 phobos but included in the release.
Why would we ever do that? It's 3rd party stuff, not official. I'm not aware of _any_ language that does anything like that. And why would you want releases of 3rd party libraries to be tied to the compiler? Not to mention, there are already plenty of complaints about the size of the dmd releases (in particular, people want the OSes to be split out instead of all being in the same zip file), so why would we be looking to make it even larger? Once we have an official package manager (and this whole thread is about a potential candidate for that), you'd use the package manager to get stuff like that anyway, not the installer for the compiler and standard library. - Jonathan M Davis
Feb 15 2013
prev sibling next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 02/15/13 09:04, Jonathan M Davis wrote:
 On Friday, February 15, 2013 08:50:14 sclytrack wrote:
 When is D going to officially release with official third party
 libraries? Like synchronized with the release of dmd and bundled
 together in a huge (as large as possible) compressed file. Like
 Derelict, Gtkd, Qtd, Vibe, Apache Thrift. I mean not included in
 phobos but included in the release.
Why would we ever do that? It's 3rd party stuff, not official. I'm not aware of _any_ language that does anything like that. And why would you want releases of 3rd party libraries to be tied to the compiler? Not to mention, there are
One reason why people are asking for such a distribution model is the "stability" of D. IOW, both the language and compiler capabilities change so often that you can't expect version X of the compiler to work with version Y of some library. Even for reasonably close releases of these projects, like libs published less than ~ a year after the compiler. Recent examples: '=>'-lambdas, UDAs and many smaller changes. It only takes one library that uses a newer feature and you have to upgrade the compiler, which can be problematic for various reasons, including some /other/ used libs failing after such upgrade. Figuring out a working set of tools and libs can be hard, and require maintaining local changes to several external projects/libs. artur
Feb 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 13:17, Artur Skawina wrote:

 One reason why people are asking for such a distribution model is the
 "stability" of D. IOW, both the language and compiler capabilities change
 so often that you can't expect version X of the compiler to work with
 version Y of some library. Even for reasonably close releases of these
 projects, like libs published less than ~ a year after the compiler.
 Recent examples: '=>'-lambdas, UDAs and many smaller changes. It only
 takes one library that uses a newer feature and you have to upgrade
 the compiler, which can be problematic for various reasons, including
 some /other/ used libs failing after such upgrade. Figuring out a working
 set of tools and libs can be hard, and require maintaining local changes
 to several external projects/libs.
Isn't something a company or organization would do and support the whole package. -- /Jacob Carlborg
Feb 15 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/13 2:50 AM, sclytrack wrote:
 When is D going to officially release with official third party
 libraries? Like synchronized with the release of dmd and bundled
 together in a huge (as large as possible) compressed file. Like
 Derelict, Gtkd, Qtd, Vibe, Apache Thrift. I mean not included in phobos
 but included in the release.
I think the whole point of having a package manager was to eliminate this necessity. Andrei
Feb 15 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 07:44, Dmitry Olshansky wrote:
 15-Feb-2013 01:49, Jacob Carlborg пишет:
 On 2013-02-14 21:33, Dmitry Olshansky wrote:
 [snip]
 Regardless I think reducing dependencies is the important for inclusion
 of any new component into the "D core".
In general I think that the D community should embrace all developers/contributors and existing libraries.
Not talking about your stuff in particular but in general - hell no. There is a line between accepting everything just because we can't lose the chance (hence current std.xml, std.json and other crappy stuff) and accepting decent stuff that was specifically following current Phobos idoms, was reviewed, etc. The latter puts quite a strain on the contributor and in the end should guarantee the quality of addition (and commitment to maintain it). That being said once package manager is there tested and solid 3-rd party libs will flow. (tested & solid simply because of greater exposure factor)
 It cannot afford to
 loose contributions for petty things like this.
I'd say if contributor can't be bothered to follow conventions and deal with the constraints imposed, just let him go. Coherency is all important in the core part of pretty much anything.
If you want to create a new zip and xml modules even though there already exist perfectly good and working ones, go ahead. I don't want to waste time on that. -- /Jacob Carlborg
Feb 15 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Feb-2013 12:47, Jacob Carlborg пишет:
 I'd say if contributor can't be bothered to follow conventions and deal
 with the constraints imposed, just let him go. Coherency is all
 important in the core part of pretty much anything.
If you want to create a new zip and xml modules even though there already exist perfectly good and working ones, go ahead.
I'd go for it iff I'm sure I can do better. But that's a re-hash of balance between NIH/from scratch approach vs reuse & tap into somebody else infrastructure.
 I don't want to
 waste time on that.
Looks like the key point. -- Dmitry Olshansky
Feb 15 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/14/13 4:49 PM, Jacob Carlborg wrote:
 On 2013-02-14 21:33, Dmitry Olshansky wrote:

 Then there are these ways forward IMHO:
 a) Admit that tango for D2 exists (easy) and bundle it with DMD (the
 hard/not likely/inconvenient part)
Yeah, that would be the easy and IMHO the best solution.
We can't do that for the reasons put forward in my previous post.
 b) Agree that we need to port it and issue a call to port/re-write
 required facilities for Orbit on top of phobos/curl. This means pulls
 against Orbit repo not phobos BTW.
 c) Forget about Orbit and try something else, like Dub?

 About serialization (that seems the biggest roadblock) - what exactly
 does Orbit need it for? Maybe it can be decoupled and/or easily
 re-written by hand until Orange or similar stuff gets into Phobos.
It probably can. But I already had a working serializer and it's easy to just to "serialize(data)" instead of doing it manually. It uses the serializer for saving an index to disk.
 Regardless I think reducing dependencies is the important for inclusion
 of any new component into the "D core".
In general I think that the D community should embrace all developers/contributors and existing libraries. It cannot afford to loose contributions for petty things like this.
Sure, as long as the admittance barrier stays high. One the worst things we've done was to allow contributions to the standard library without due review. Andrei
Feb 15 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, February 15, 2013 08:46:39 Andrei Alexandrescu wrote:
 Sure, as long as the admittance barrier stays high. One the worst things
 we've done was to allow contributions to the standard library without
 due review.
We have enough problems when we _do_ review things thoroughly. But added the review process was one of the best things that we've done. The code quality of submissions has improved considerably. And as the writer of the first module to go through the process (std.datetime), I can testify that it helped considerably in improving it. What we ended up with was actually quite different in a number of places from what was originally implemented, and it's far better for it. The main thing that we may want to do differently in the future is to give new modules more of an incubation period where they're distributed with Phobos but are clearly marked as still being experimental so that we can make further modifications when they start actually getting used and issues crop up. And then after a few releases, we actually start treat its API as being as close to frozen as the rest of Phobos is. But regardless, we certainly don't want to lower the bar of admission. It's what's going to ensure that Phobos is a solid standard library. - Jonathan M Davis
Feb 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 21:25, Jonathan M Davis wrote:

 We have enough problems when we _do_ review things thoroughly. But added the
 review process was one of the best things that we've done. The code quality of
 submissions has improved considerably. And as the writer of the first module to
 go through the process (std.datetime), I can testify that it helped
 considerably in improving it. What we ended up with was actually quite
 different in a number of places from what was originally implemented, and it's
 far better for it.

 The main thing that we may want to do differently in the future is to give new
 modules more of an incubation period where they're distributed with Phobos but
 are clearly marked as still being experimental so that we can make further
 modifications when they start actually getting used and issues crop up. And
 then after a few releases, we actually start treat its API as being as close
 to frozen as the rest of Phobos is. But regardless, we certainly don't want to
 lower the bar of admission. It's what's going to ensure that Phobos is a solid
 standard library.
I completely agree with that and I don't want to change anything of that. I just want you to broaden your minds a bit. Like why a third party library cannot be included. BTW, have any of the tools in the tools repository been through a review process? I'm not saying that they should or shouldn't, just asking. -- /Jacob Carlborg
Feb 16 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, February 15, 2013 00:33:34 Dmitry Olshansky wrote:
 a) Admit that tango for D2 exists (easy) and bundle it with DMD (the
 hard/not likely/inconvenient part)
There's a big difference between admitting it exists (I don't think that anyone denies that it does) and treating it as part of the standard library. And I wouldn't expect it to ever be treated as part of the standard library no matter how good it is, just like no other 3rd party library is going to be treated as if it were part of the standard library. The closest that there is to that is when we link against C stuff (like curl), and we don't even do a lot of that. The only way that 3rd party stuff is going to be part of the standard library is if it's actually integrated intto the standard library just like everything  else in there has been, and that puts certain requirements on the API (e.g. range-based) and the license (i.e. Boost), both of which Tango fails at. It's perfectly fine to do things differently in a 3rd party library but not in the standard library. - Jonathan M Davis
Feb 14 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 03:07, Jonathan M Davis wrote:

 There's a big difference between admitting it exists (I don't think that anyone
 denies that it does) and treating it as part of the standard library. And I
 wouldn't expect it to ever be treated as part of the standard library no
 matter how good it is, just like no other 3rd party library is going to be
 treated as if it were part of the standard library. The closest that there is
 to that is when we link against C stuff (like curl), and we don't even do a lot
 of that. The only way that 3rd party stuff is going to be part of the standard
 library is if it's actually integrated intto the standard library just like
 everything  else in there has been, and that puts certain requirements on the
 API (e.g. range-based) and the license (i.e. Boost), both of which Tango fails
 at. It's perfectly fine to do things differently in a 3rd party library but not
 in the standard library.
This discussion is clearing running in circles. -- /Jacob Carlborg
Feb 15 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 13:20, Regan Heath wrote:

 Just a minor point from me.  I reckon the functionality you want can and
 should be built on top of std.getopt.
The thing is that most of this is already present and working in the argument parser in Tango. The rest I've added myself. I don't feel too enthusiastic about redoing half of the work that's already been done in Tango. -- /Jacob Carlborg
Feb 14 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 14 February 2013 at 20:04:44 UTC, Jacob Carlborg 
wrote:
 On 2013-02-14 13:20, Regan Heath wrote:

 Just a minor point from me.  I reckon the functionality you 
 want can and
 should be built on top of std.getopt.
The thing is that most of this is already present and working in the argument parser in Tango. The rest I've added myself. I don't feel too enthusiastic about redoing half of the work that's already been done in Tango.
May I be of help? I'd gladly spent some efforts on improving std.getopt given some official design direction.
Feb 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 21:41, Dicebot wrote:

 May I be of help? I'd gladly spent some efforts on improving std.getopt
 given some official design direction.
I won't stopped you. But I think it's unnecessary since we already have code that is working perfectly fine. -- /Jacob Carlborg
Feb 14 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 14 February 2013 at 21:50:46 UTC, Jacob Carlborg
wrote:
 I won't stopped you. But I think it's unnecessary since we 
 already have code that is working perfectly fine.
Well, I am one of those who does not like Tango dependencies. If something important is missing in standard option module, it needs to be added and I I'll gladly volunteer for that. But adding Tango stuff to Phobos as is - big no-no for me.
Feb 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-14 23:15, Dicebot wrote:

 Well, I am one of those who does not like Tango dependencies. If
 something important is missing in standard option module, it
 needs to be added and I I'll gladly volunteer for that. But
 adding Tango stuff to Phobos as is - big no-no for me.
Rewriting a large part of existing, good and working code just because of some political issue (or what it is) is a big, bit no-no for _me_. So I guess we can drop this discussion now. It's only running in circles now. -- /Jacob Carlborg
Feb 15 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Friday, 15 February 2013 at 08:48:56 UTC, Jacob Carlborg wrote:
 On 2013-02-14 23:15, Dicebot wrote:

 Well, I am one of those who does not like Tango dependencies. 
 If
 something important is missing in standard option module, it
 needs to be added and I I'll gladly volunteer for that. But
 adding Tango stuff to Phobos as is - big no-no for me.
Rewriting a large part of existing, good and working code just because of some political issue (or what it is) is a big, bit no-no for _me_. So I guess we can drop this discussion now. It's only running in circles now.
And it is exactly why I offered help in rewriting some of those, as someone more interested in improving Phobos. If all this discussion is only about convincing to get some parts of Tango into official distribution as-is - I doubt it will be going anywhere and dropping is the right thing. Also it is not exactly a political issue. Tango style and design is considerably different from Phobos and mixing so different stuff in one distribution is the road to PHP hell. Much worse than any reimplementation (more like "refactoring" in practice) efforts. Just my 5 cents.
Feb 15 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/13 4:25 AM, Dicebot wrote:
 On Friday, 15 February 2013 at 08:48:56 UTC, Jacob Carlborg wrote:
 On 2013-02-14 23:15, Dicebot wrote:

 Well, I am one of those who does not like Tango dependencies. If
 something important is missing in standard option module, it
 needs to be added and I I'll gladly volunteer for that. But
 adding Tango stuff to Phobos as is - big no-no for me.
Rewriting a large part of existing, good and working code just because of some political issue (or what it is) is a big, bit no-no for _me_. So I guess we can drop this discussion now. It's only running in circles now.
And it is exactly why I offered help in rewriting some of those, as someone more interested in improving Phobos. If all this discussion is only about convincing to get some parts of Tango into official distribution as-is - I doubt it will be going anywhere and dropping is the right thing. Also it is not exactly a political issue. Tango style and design is considerably different from Phobos and mixing so different stuff in one distribution is the road to PHP hell. Much worse than any reimplementation (more like "refactoring" in practice) efforts. Just my 5 cents.
Dicebot, if Jacob allows you to copy his design with a clean-room implementation, I think this is a great way going forward. Andrei
Feb 15 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Friday, 15 February 2013 at 14:03:02 UTC, Andrei Alexandrescu 
wrote:
 Dicebot, if Jacob allows you to copy his design with a 
 clean-room implementation, I think this is a great way going 
 forward.

 Andrei
I don't think I am capable of doing full-scale adaptation for Orbit but I could have made a pull request improvements for some module API's he has found lacking, like std.getopt . Whenever Orbit will actually make it, those enhancement should be worth doing anyway.
Feb 15 2013
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/15/13, Dicebot <m.strashun gmail.com> wrote:
 I don't think I am capable of doing full-scale adaptation for
 Orbit but I could have made a pull request improvements for some
 module API's he has found lacking, like std.getopt
Btw std.getopt already has some pull requests open: https://github.com/D-Programming-Language/phobos/pull/1050 https://github.com/D-Programming-Language/phobos/pull/1030
Feb 15 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 15:03, Andrei Alexandrescu wrote:

 Dicebot, if Jacob allows you to copy his design with a clean-room
 implementation, I think this is a great way going forward.
There's no need for a clean-room implementation, just take what you can and replace what's depending on Tango. It's all Boost licensed. -- /Jacob Carlborg
Feb 15 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Tuesday, 12 February 2013 at 12:38:55 UTC, Jacob Carlborg 
wrote:

 * XML - The XML module is slow and has a cumbersome API
For XML I suggest trying http://www.dsource.org/projects/xmlp/wiki I tend not to like working in XML and this library doesn't change that, but if someone is interested in getting XML added to Phobos I highly suggest using this and writing bugs for improvements so that we can get a library that is satisfactory into Phobos. As for serialization I wouldn't say no one is interested: http://wiki.dlang.org/Review_Queue Personally I'm just not in a good position to review and give feedback.
Feb 15 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-15 17:56, Jesse Phillips wrote:

 For XML I suggest trying http://www.dsource.org/projects/xmlp/wiki
 I tend not to like working in XML and this library doesn't change that,
 but if someone is interested in getting XML added to Phobos I highly
 suggest using this and writing bugs for improvements so that we can get
 a library that is satisfactory into Phobos.
Since I'm already have a working XML module I don't want to replace it with anything else without knowing it is/will be included into Phobos. If I'm going to replace a module I don't want to do it more than once.
 As for serialization I wouldn't say no one is interested:
 http://wiki.dlang.org/Review_Queue
 Personally I'm just not in a good position to review and give feedback.
Anyone should be able to contribute with suggestions for how the API should look like and work as long as they have any interest (possibly even without interest) in the module. Also verifying that the documentation is good enough. -- /Jacob Carlborg
Feb 16 2013
prev sibling parent reply "nazriel" <spam dzfl.pl> writes:
As for XML module, we have this shiny candy:

http://opticron.no-ip.org/svn/branches/libdxml2/xml.d

 From what author says it is semi phobos ready.
Already supports up to BidirectionalRanges.

Author got a bit tired of fighting ranges, so if somebody could 
help, probably we could get it into phobos quite quick.

As a side note, I have used it in several projects already, and I 
am really happy with this (libdjson is also worth a note: 
http://opticron.no-ip.org/svn/branches/libdjson/json.d)

Regards
Feb 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-15 18:16, nazriel wrote:
 As for XML module, we have this shiny candy:

 http://opticron.no-ip.org/svn/branches/libdxml2/xml.d

  From what author says it is semi phobos ready.
 Already supports up to BidirectionalRanges.

 Author got a bit tired of fighting ranges, so if somebody could help,
 probably we could get it into phobos quite quick.

 As a side note, I have used it in several projects already, and I am
 really happy with this (libdjson is also worth a note:
 http://opticron.no-ip.org/svn/branches/libdjson/json.d)
As I said in a previous post: "Since I'm already have a working XML module I don't want to replace it with anything else without knowing it is/will be included into Phobos. If I'm going to replace a module I don't want to do it more than once." -- /Jacob Carlborg
Feb 16 2013
parent "nazriel" <spam dzfl.pl> writes:
On Saturday, 16 February 2013 at 15:13:18 UTC, Jacob Carlborg 
wrote:
 On 2013-02-15 18:16, nazriel wrote:
 As for XML module, we have this shiny candy:

 http://opticron.no-ip.org/svn/branches/libdxml2/xml.d

 From what author says it is semi phobos ready.
 Already supports up to BidirectionalRanges.

 Author got a bit tired of fighting ranges, so if somebody 
 could help,
 probably we could get it into phobos quite quick.

 As a side note, I have used it in several projects already, 
 and I am
 really happy with this (libdjson is also worth a note:
 http://opticron.no-ip.org/svn/branches/libdjson/json.d)
As I said in a previous post: "Since I'm already have a working XML module I don't want to replace it with anything else without knowing it is/will be included into Phobos. If I'm going to replace a module I don't want to do it more than once."
I wasn't talkig directly to you. Just putting KXML as an option for new std.xml I agree that switching to kxml at this point would be totally pointless for you.
Feb 17 2013