digitalmars.D - What's missing from Phobos for Orbit (package manager)
- Jacob Carlborg (69/69) Feb 12 2013 In the thread "Expanding Phobos from a flat hierarchy" there started a
- Steven Schveighoffer (28/45) Feb 12 2013 I want to get this remedied. Won't make it in 2.062, but I want to fini...
- Jacob Carlborg (7/52) Feb 12 2013 I don't need examples of how to implement these functions. I'm asking
- Steven Schveighoffer (10/14) Feb 12 2013 Well, many of those could be implemented in Orbit, especially the trivia...
- Jacob Carlborg (7/15) Feb 12 2013 I would prefer if they were in Phobos, since they are generic and can be...
- Jacob Carlborg (12/20) Feb 12 2013 The original problem was Orbit is using third party libraries which is
- Peter Sommerfeld (9/15) Feb 12 2013 That seems to be a question of priority: If you insist to get the
- Jacob Carlborg (4/11) Feb 12 2013 It's not so much about priority, it's rather about if being accepted at ...
- Walter Bright (3/4) Feb 12 2013 The trivial ones should not be added to Phobos, for example, 'any' being...
- Jacob Carlborg (7/9) Feb 12 2013 This is just an extension to the already existing std.algorithm.any
- Walter Bright (8/15) Feb 13 2013 The any in std.algorithm is defined:
- Jacob Carlborg (9/17) Feb 14 2013 But if you use a predicate that always returns true that would be
- Walter Bright (2/20) Feb 14 2013 I don't understand why one would go around the horn to just check for !e...
- Jacob Carlborg (8/10) Feb 14 2013 I've tried to explain, it shows what the intention is.
- Michel Fortin (12/24) Feb 14 2013 I'd agree it's more readable, but it does not do what I expect when I
- Andrei Alexandrescu (33/41) Feb 14 2013 I understand. Adding functions such as the negation of empty becomes a
- Jacob Carlborg (9/40) Feb 14 2013 Since you mention Ruby below I can say that D/Phobos could have some
- tn (8/21) Feb 14 2013 Yes for a default predicate, BUT I think it should be "a => a"
- Jacob Carlborg (6/11) Feb 14 2013 Right. But the problem with that is that a zero in D is considered false...
- John Colvin (3/16) Feb 14 2013 In python and matlab 0 is false and "any" treats them as such.
- Jacob Carlborg (12/19) Feb 14 2013 How about this, I have another similar function that might be useful in
- Andrei Alexandrescu (4/23) Feb 15 2013 I think this is a fine candidate for a standard function. It does actual...
- SomeDude (8/33) Feb 16 2013 What does isBlank() return with tabs ?
- Jacob Carlborg (5/10) Feb 16 2013 Sure, both does not have to be included.
- Graham Fawcett (18/43) Mar 20 2013 But "present" and "blank" aren't opposites in English.
- Jacob Carlborg (4/9) Mar 21 2013 Then have only isBlank.
- Graham Fawcett (3/14) Mar 21 2013 Agreed, isBlank is a good addition to Phobos.
- Steven Schveighoffer (4/12) Feb 14 2013 Would this work?
- Steven Schveighoffer (6/7) Feb 14 2013 BTW, I noticed 'any' is not listed in the std.algorithm documentation at...
- Jacob Carlborg (9/11) Feb 14 2013 Yes, I already have something similar. Actually I have this:
- John Colvin (6/16) Feb 14 2013 The only purpose of this is to make code more readable, correct?
- Jacob Carlborg (5/9) Feb 14 2013 Yeah, I'm not perfectly satisfied with the name either.
- Steven Schveighoffer (9/19) Feb 14 2013 OK, here is what I suggest:
- Walter Bright (4/24) Feb 14 2013 +1
- Jacob Carlborg (4/6) Feb 14 2013 Yes, so what about the other things, such as xml. Any suggestions?
- Steven Schveighoffer (20/24) Feb 14 2013 No. Clearly using tango xml will not fly.
- Jacob Carlborg (9/28) Feb 15 2013 It's _is_ written in D. I just chose to use libraries that exists and
- Steven Schveighoffer (5/24) Feb 15 2013 That is an overstatement. I'm pretty sure people are interested in havi...
- Jacob Carlborg (6/8) Feb 15 2013 It's been in the review queue for over two years. I've pushed for it a
- Steven Schveighoffer (11/17) Feb 15 2013 This is the last "push" I can find from you:
- Jacob Carlborg (8/17) Feb 15 2013 I have no idea of what's on trello. I take no responsible for who put it...
- Simen Kjaeraas (12/19) Feb 15 2013 It's not listed in the review queue on the wiki:
- Jesse Phillips (3/5) Feb 15 2013 Well than that isn't complete:
- Simen Kjaeraas (5/11) Mar 20 2013 Indeed. I was under the impression all of the old wiki should have
- Jacob Carlborg (5/12) Feb 15 2013 It's been on the old wiki for quite some time:
- Andrei Alexandrescu (26/32) Feb 15 2013 Here's what I think - in order to add things to Phobos and generally the...
- Jacob Carlborg (29/53) Feb 16 2013 Sure I may not have had the best attitude in this discussion. But that
- Simen Kjaeraas (21/40) Mar 20 2013 Please, relax. Trust me, we understand you feel miffed. Your attitude he...
- Jacob Carlborg (7/11) Mar 20 2013 I have removed any Tango dependencies, D1 related code and other code
- Simen Kjaeraas (8/19) Mar 20 2013 I say do the review, make things faster afterwards. There'll always be
- Jacob Carlborg (5/10) Mar 21 2013 I'll do that then. I need to regenerate the docs, then it should be
- Simen Kjaeraas (4/37) Mar 20 2013 Very good. Thank you.
- Simen Kjaeraas (11/17) Mar 20 2013 It's not listed here:
- Simen Kjaeraas (3/9) Mar 20 2013 --
- Dicebot (6/9) Feb 15 2013 Guess why it is close to impossible to get DMD into some Linux
- Steven Schveighoffer (4/12) Feb 15 2013 The issue is not that the source is unavailable, the issue is that the
- Michel Fortin (19/25) Feb 14 2013 I'm not sure why you don't want to continue using Tango. It's no longer
- Jonathan M Davis (8/17) Feb 14 2013 Anyone is free to use Tango in their own apps, just like they're free to...
- Walter Bright (3/9) Feb 14 2013 I agree with Andrei, it's part of that "eat your own dogfood" thing, at ...
- Jacob Carlborg (7/9) Feb 15 2013 Orbit does, it's written in D. Not something I can say about DMD or
- Marco Leise (10/19) Feb 15 2013 Relax, I guess all that meant was: Phobos' quality needs to be
- Steven Schveighoffer (11/26) Feb 15 2013 I think holding off on package distribution management because a tool
- Jacob Carlborg (4/10) Feb 16 2013 Thank you.
- Jacob Carlborg (5/11) Feb 15 2013 Phobos depends on two external libraries, curl and libz. Probably only
- Andrei Alexandrescu (5/18) Feb 15 2013 We have personally contacted the author of curl and the maintainer of
- Jacob Carlborg (5/8) Feb 15 2013 There's no issue in bundling BSD licensed code. That's the whole idea of...
- Jesse Phillips (13/22) Feb 15 2013 To add to this. BSD requires the license be distributed with
- Jacob Carlborg (6/15) Feb 16 2013 Yes. We can also discussion why that library cannot be part of
- Andrei Alexandrescu (12/28) Feb 15 2013 Allow me to qualify this.
- Jacob Carlborg (5/15) Feb 15 2013 The different names are the minor issues. It's rather the XML, zip, net
- Jacob Carlborg (5/7) Feb 15 2013 I do want. Trust me, you have no idea how much I want to continue use
- Andrei Alexandrescu (4/9) Feb 15 2013 This statement is inappropriate. It is factually false, 100% political,
- SomeDude (8/17) Feb 16 2013 I totally agree with Walter, it adds useless cognitive load. I
- Simen Kjaeraas (10/33) Mar 20 2013 n =
- bearophile (19/20) Feb 14 2013 The situation is not that simple. Just a general (not specific)
- Walter Bright (8/11) Feb 14 2013 The trouble is, where do you stop adding trivia? How about this one:
- Marco Leise (5/10) Feb 15 2013 I thought that's _why_ we have ++ and --.
- Simen Kjaeraas (4/12) Mar 20 2013 Indeed. ++++++t is just as readable as the above. :p
- SomeDude (4/12) Feb 16 2013 Yes, it actually makes reading code *harder* for everyone but the
- Walter Bright (4/15) Feb 16 2013 My own experience is it makes it harder for the writer, too :-)
- FG (9/13) Feb 12 2013 You mean: return count != 1 ? x ~ "s" : x;
- qznc (14/28) Feb 12 2013 Do not go down that rabbit hole! Just skim over the following
- John Colvin (5/37) Feb 12 2013 Agreed. It's such an enormous problem, even just in English.
- FG (6/8) Feb 12 2013 I know that. Usually I define my own pluralize for the one or two langua...
- Johannes Pfau (12/21) Feb 13 2013 The gettext approach works quite well: There's no pluralize function.
- Jonathan M Davis (8/22) Feb 12 2013 Actually, given that that's English-specific, I don't know that we'd act...
- Walter Bright (3/4) Feb 12 2013 The existence of UDAs should dramatically affect the design of a seriali...
- Jacob Carlborg (19/21) Feb 12 2013 It didn't dramatically affect my serialization library. I already used a...
- Marco Leise (30/62) Feb 13 2013 I can only tell you what of that list I would have had a use
- Jonathan M Davis (4/7) Feb 13 2013 format now works in CTFE. Format should go the way of the dodo. It's ins...
- FG (2/8) Feb 13 2013 Could you please add this info to std.metastrings' ddoc?
- Jacob Carlborg (4/6) Feb 13 2013 Ok, cool.
- Jacob Carlborg (15/47) Feb 13 2013 I didn't necessarily mean native configuration. I was referring to
- Dmitry Olshansky (6/48) Feb 13 2013 This should never see the light of day. Use plain format from std.string...
- Steven Schveighoffer (5/11) Feb 13 2013 Hm... I think all we need is a public interface to _d_newclass in drunti...
- Jacob Carlborg (4/7) Feb 13 2013 That's what I'm using.
- Jacob Carlborg (5/15) Feb 13 2013 If it's unclear, I already have all of this functionality implemented.
- Regan Heath (14/24) Feb 14 2013 Just a minor point from me. I reckon the functionality you want can and...
- Jacob Carlborg (5/15) Feb 14 2013 Andrei said there's stuff he didn't want at all, like the "dstack"
- Dmitry Olshansky (10/25) Feb 14 2013 I believe that the idea is that any amount of helpers is fine as long as...
- Jacob Carlborg (8/15) Feb 14 2013 I agree that might be the best idea. But that is mostly for the "any"
- Dmitry Olshansky (15/29) Feb 14 2013 Then there are these ways forward IMHO:
- John Colvin (5/9) Feb 14 2013 I personally don't see why orange can't just be included as part
- Jacob Carlborg (4/6) Feb 14 2013 Sure it can. Would that be ok?
- John Colvin (5/11) Feb 14 2013 I would see it as a good test of the library, helping to iron out
- Dmitry Olshansky (8/12) Feb 14 2013 It could then the only roadblock is dependency on Tango.
- Jacob Carlborg (7/12) Feb 15 2013 It's not huge. I already had the serialization library available. Not
- Dmitry Olshansky (21/32) Feb 15 2013 With through unittests being about 50% of the said code...
- Jonathan M Davis (27/46) Feb 15 2013 oable
- Jacob Carlborg (6/17) Feb 15 2013 The easy solution would be to have the tests in its own module, in its
- Jonathan M Davis (18/38) Feb 15 2013 And it would make maintenance harder. I find that it's extremely valuabl...
- Andrei Alexandrescu (13/24) Feb 15 2013 I think this is an unfair characterization.
- Sean Kelly (8/22) Feb 15 2013 .
- Jacob Carlborg (12/17) Feb 16 2013 It does not need to be changed. It just needs to be included in the
- Jacob Carlborg (10/22) Feb 14 2013 It probably can. But I already had a working serializer and it's easy to...
- Dmitry Olshansky (16/24) Feb 14 2013 Not talking about your stuff in particular but in general - hell no.
- sclytrack (7/33) Feb 14 2013 When is D going to officially release with official third party
- Jonathan M Davis (11/16) Feb 15 2013 Why would we ever do that? It's 3rd party stuff, not official. I'm not a...
- Artur Skawina (13/23) Feb 15 2013 One reason why people are asking for such a distribution model is the
- Jacob Carlborg (5/16) Feb 15 2013 Isn't something a company or organization would do and support the whole...
- Andrei Alexandrescu (4/9) Feb 15 2013 I think the whole point of having a package manager was to eliminate
- Jacob Carlborg (6/29) Feb 15 2013 If you want to create a new zip and xml modules even though there
- Dmitry Olshansky (7/14) Feb 15 2013 I'd go for it iff I'm sure I can do better. But that's a re-hash of
- Andrei Alexandrescu (6/27) Feb 15 2013 Sure, as long as the admittance barrier stays high. One the worst things...
- Jonathan M Davis (17/20) Feb 15 2013 We have enough problems when we _do_ review things thoroughly. But added...
- Jacob Carlborg (8/23) Feb 16 2013 I completely agree with that and I don't want to change anything of
- Jonathan M Davis (14/16) Feb 14 2013 There's a big difference between admitting it exists (I don't think that...
- Jacob Carlborg (4/16) Feb 15 2013 This discussion is clearing running in circles.
- Jacob Carlborg (7/9) Feb 14 2013 The thing is that most of this is already present and working in the
- Dicebot (4/12) Feb 14 2013 May I be of help? I'd gladly spent some efforts on improving
- Jacob Carlborg (5/7) Feb 14 2013 I won't stopped you. But I think it's unnecessary since we already have
- Dicebot (6/8) Feb 14 2013 Well, I am one of those who does not like Tango dependencies. If
- Jacob Carlborg (7/11) Feb 15 2013 Rewriting a large part of existing, good and working code just because
- Dicebot (11/22) Feb 15 2013 And it is exactly why I offered help in rewriting some of those,
- Andrei Alexandrescu (4/27) Feb 15 2013 Dicebot, if Jacob allows you to copy his design with a clean-room
- Dicebot (7/11) Feb 15 2013 I don't think I am capable of doing full-scale adaptation for
- Andrej Mitrovic (4/7) Feb 15 2013 Btw std.getopt already has some pull requests open:
- Jacob Carlborg (6/8) Feb 15 2013 There's no need for a clean-room implementation, just take what you can
- Jesse Phillips (11/12) Feb 15 2013 For XML I suggest trying http://www.dsource.org/projects/xmlp/wiki
- Jacob Carlborg (10/18) Feb 16 2013 Since I'm already have a working XML module I don't want to replace it
- nazriel (10/10) Feb 15 2013 As for XML module, we have this shiny candy:
- Jacob Carlborg (7/16) Feb 16 2013 As I said in a previous post:
- nazriel (6/29) Feb 17 2013 I wasn't talkig directly to you. Just putting KXML as an option
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
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 optimalI 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 argumentsI 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 arrayarr[$-1]; arr.back;* map, find and any for associative arraysReally, 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 pluralbasic 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
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: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* std.process - I have not used it myself but I've heard it's not optimalI 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 argumentsI 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 arrayarr[$-1]; arr.back;* map, find and any for associative arraysReally, 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 pluralbasic 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;
Feb 12 2013
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
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
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
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
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
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
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
On 2/12/2013 11:34 PM, Jacob Carlborg wrote:On 2013-02-12 22:35, 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.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++.
Feb 13 2013
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
On 2/14/2013 12:12 AM, Jacob Carlborg wrote:On 2013-02-13 21:19, Walter Bright wrote:I don't understand why one would go around the horn to just check for !empty.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);
Feb 14 2013
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
On 2013-02-14 11:58:12 +0000, Jacob Carlborg <doob me.com> said:On 2013-02-14 10:46, Walter Bright wrote: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/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.
Feb 14 2013
On 2/14/13 6:58 AM, Jacob Carlborg wrote:On 2013-02-14 10:46, Walter Bright 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. 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. AndreiI 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.
Feb 14 2013
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
On Thursday, 14 February 2013 at 19:54:28 UTC, Jacob Carlborg 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).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.
Feb 14 2013
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
On Thursday, 14 February 2013 at 20:28:23 UTC, Jacob Carlborg wrote:On 2013-02-14 21:23, tn wrote:In python and matlab 0 is false and "any" treats them as such.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".
Feb 14 2013
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
On 2/14/13 3:01 PM, Jacob Carlborg wrote:On 2013-02-14 13:42, Andrei Alexandrescu wrote: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. AndreiI 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
Feb 15 2013
On Thursday, 14 February 2013 at 20:01:37 UTC, Jacob Carlborg wrote:On 2013-02-14 13:42, Andrei Alexandrescu wrote: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).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
Feb 16 2013
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
On Thursday, 14 February 2013 at 20:01:37 UTC, Jacob Carlborg wrote:On 2013-02-14 13:42, Andrei Alexandrescu 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." 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. GrahamI 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
Mar 20 2013
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
On Thursday, 21 March 2013 at 07:39:53 UTC, Jacob Carlborg wrote:On 2013-03-20 23:17, Graham Fawcett wrote:Agreed, isBlank is a good addition to Phobos. GrahamBut "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.
Mar 21 2013
On Thu, 14 Feb 2013 06:58:12 -0500, Jacob Carlborg <doob me.com> wrote:On 2013-02-14 10:46, Walter Bright wrote:Would this work? bool any(R)(R r) if(isInputRange!R) { return !r.empty;} -SteveI 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.
Feb 14 2013
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
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
On Thursday, 14 February 2013 at 19:57:25 UTC, Jacob Carlborg wrote:On 2013-02-14 15:28, Steven Schveighoffer wrote: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.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; }
Feb 14 2013
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
On Thu, 14 Feb 2013 14:57:25 -0500, Jacob Carlborg <doob me.com> wrote:On 2013-02-14 15:28, Steven Schveighoffer wrote: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. -SteveWould 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; }
Feb 14 2013
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:Sounds like a good idea.On 2013-02-14 15:28, Steven Schveighoffer wrote:OK, here is what I suggest: 1. put all these "helper" trivial functions inside a module, call it orbithelper.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; }2. If phobos obtains these functions, remove them from orbithelper, and import the correct version.+1The other things, such as xml, I think are more troublesome. This seems like a trivial problem with a trivial solution.Yup.
Feb 14 2013
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
On Thu, 14 Feb 2013 16:38:24 -0500, Jacob Carlborg <doob me.com> wrote:On 2013-02-14 22:00, 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. 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? -SteveThe 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?
Feb 14 2013
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
On Fri, 15 Feb 2013 03:02:09 -0500, Jacob Carlborg <doob me.com> wrote:On 2013-02-14 23:37, Steven Schveighoffer wrote:That is an overstatement. I'm pretty sure people are interested in having serialization in Phobos.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.By dogfood I mean, written against phobos. -Stevestd.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.
Feb 15 2013
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
On Fri, 15 Feb 2013 11:14:56 -0500, Jacob Carlborg <doob me.com> wrote:On 2013-02-15 15:28, 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. 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". -SteveThat 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.
Feb 15 2013
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
On Friday, 15 February 2013 at 16:14:57 UTC, Jacob Carlborg wrote:On 2013-02-15 15:28, Steven Schveighoffer wrote: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.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.
Feb 15 2013
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_QueueWell than that isn't complete: http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue
Feb 15 2013
On 2013-02-15, 19:53, Jesse Phillips wrote:On Friday, 15 February 2013 at 16:54:06 UTC, Simen Kjaeraas wrote: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. -- SimenIt's not listed in the review queue on the wiki: http://wiki.dlang.org/Review_QueueWell than that isn't complete: http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue
Mar 20 2013
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_QueueIt's been on the old wiki for quite some time: http://prowiki.org/wiki4d/wiki.cgi?ReviewQueueWell, 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
On 2/15/13 11:14 AM, Jacob Carlborg wrote:On 2013-02-15 15:28, Steven Schveighoffer wrote: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. AndreiThat 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.
Feb 15 2013
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
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
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
On 2013-03-20, 20:20, Jacob Carlborg wrote:On 2013-03-20 17:31, 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. -- SimenSo 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.
Mar 20 2013
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
On 2013-02-15, 18:20, Andrei Alexandrescu wrote:On 2/15/13 11:14 AM, Jacob Carlborg wrote:Very good. Thank you. -- SimenOn 2013-02-15 15:28, Steven Schveighoffer wrote: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.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.
Mar 20 2013
On 2013-02-15, 17:14, Jacob Carlborg wrote:On 2013-02-15 15:28, Steven Schveighoffer wrote: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. -- SimenThat 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.
Mar 20 2013
On 2013-02-15, 17:14, Jacob Carlborg wrote:On 2013-02-15 15:28, Steven Schveighoffer wrote:-- SimenThat 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.
Mar 20 2013
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
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:The issue is not that the source is unavailable, the issue is that the tool requires libraries that Walter does not want to include. -SteveI 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
On 2013-02-14 21:38:24 +0000, Jacob Carlborg <doob me.com> said:On 2013-02-14 22:00, Steven Schveighoffer wrote: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/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?
Feb 14 2013
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: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 DavisOn 2013-02-14 22:00, Steven Schveighoffer wrote:I'm not sure why you don't want to continue using Tango. It's no longer incompatible with Phobos I think.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?
Feb 14 2013
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
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
Am Fri, 15 Feb 2013 09:23:52 +0100 schrieb Jacob Carlborg <doob me.com>:On 2013-02-15 04:15, Walter Bright wrote: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. -- MarcoI 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.
Feb 15 2013
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: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 :) -SteveAnyone 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 15 2013
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
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
On 2/15/13 3:21 AM, Jacob Carlborg wrote:On 2013-02-15 03:06, Jonathan M Davis 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. AndreiAnyone 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.
Feb 15 2013
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
On Friday, 15 February 2013 at 14:14:43 UTC, Jacob Carlborg wrote:On 2013-02-15 14:53, Andrei Alexandrescu 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. 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.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.
Feb 15 2013
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
On 2/14/13 9:06 PM, Jonathan M Davis wrote:On Thursday, February 14, 2013 17:45:04 Michel Fortin 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. AndreiOn 2013-02-14 21:38:24 +0000, Jacob Carlborg<doob me.com> said: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.On 2013-02-14 22:00, Steven Schveighoffer wrote:I'm not sure why you don't want to continue using Tango. It's no longer incompatible with Phobos I think.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?
Feb 15 2013
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
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
On 2/15/13 3:03 AM, Jacob Carlborg wrote:On 2013-02-14 23:45, Michel Fortin wrote:This statement is inappropriate. It is factually false, 100% political, and flame-baiting. Also I have zero sympathy for posturing as a victim. AndreiI'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.
Feb 15 2013
On Thursday, 14 February 2013 at 11:58:13 UTC, Jacob Carlborg wrote:On 2013-02-14 10:46, Walter Bright wrote: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.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.
Feb 16 2013
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 =t. =function. I think it adds value, that's why I have it. It clearly shows the inten=It's the same reason why I think it's good to have explicit interfaces and =n =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=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
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
On 2/14/2013 12:32 AM, bearophile wrote:Walter Bright: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.The trivial ones should not be added to Phobos,The situation is not that simple.
Feb 14 2013
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
On 2013-02-15, 14:38, Marco Leise wrote:Am Thu, 14 Feb 2013 02:00:20 -0800 schrieb Walter Bright <newshound2 digitalmars.com>:Indeed. ++++++t is just as readable as the above. :p -- SimenThe 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 --.
Mar 20 2013
On Thursday, 14 February 2013 at 10:01:21 UTC, Walter Bright wrote:On 2/14/2013 12:32 AM, bearophile wrote:Yes, it actually makes reading code *harder* for everyone but the writer, because the code ends up lacking consistency.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.
Feb 16 2013
On 2/16/2013 10:35 AM, SomeDude wrote:On Thursday, 14 February 2013 at 10:01:21 UTC, Walter Bright wrote: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.On 2/14/2013 12:32 AM, bearophile wrote:Yes, it actually makes reading code *harder* for everyone but the writer, because the code ends up lacking consistency.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.
Feb 16 2013
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
On Tuesday, 12 February 2013 at 16:38:54 UTC, FG wrote:On 2013-02-12 15:21, Steven Schveighoffer wrote: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.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
On Tuesday, 12 February 2013 at 19:38:56 UTC, qznc wrote:On Tuesday, 12 February 2013 at 16:38:54 UTC, FG wrote: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.On 2013-02-12 15:21, Steven Schveighoffer wrote: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.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
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
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
On Tuesday, February 12, 2013 09:21:08 Steven Schveighoffer wrote: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* pluralize - Takes a string and a count. If the count is greater than 1 it converts the word in the string to pluralbasic 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.
Feb 12 2013
On 2/12/2013 4:38 AM, Jacob Carlborg wrote:* Serialization - Does not existThe existence of UDAs should dramatically affect the design of a serialization library.
Feb 12 2013
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
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:* ConfigurationYes, 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 optimalThe 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 argumentsAll 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* containsstaticIndexOf!(something, Tuple) != -1* fieldsOf - Returns all the fields of the given type* hasField - Returns true if the given type has the given fieldstaticIndexOf!(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 constructorsSo I figure, Object.factory("ClassName") is too limited. I used to just force my code work with that one. -- Marco
Feb 13 2013
On Wednesday, February 13, 2013 09:34:36 Marco Leise wrote:format now works in CTFE. Format should go the way of the dodo. It's insanely inefficient. - Jonathan M Davis* format - A simple formatting function
Feb 13 2013
On 2013-02-13 09:45, Jonathan M Davis wrote:On Wednesday, February 13, 2013 09:34:36 Marco Leise wrote:Could you please add this info to std.metastrings' ddoc?format now works in CTFE. Format should go the way of the dodo. It's insanely inefficient.* format - A simple formatting function
Feb 13 2013
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
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 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.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:* ConfigurationYes, native to the environment (e.g. use \AppData\Roaming on Windows or .config on Linux)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.That's good. But I would really prefer something like "hasField" instead of the above. It clearly shows that's going on.CTFE:I think most of that exists in Phobos or can be constructed in one line of code:* format - A simple formatting function* indexOf* containsstaticIndexOf!(something, Tuple) != -1* fieldsOf - Returns all the fields of the given type* hasField - Returns true if the given type has the given fieldstaticIndexOf!(field, fieldsOf!Type) != -1There's no reason for mixins.* 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.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
13-Feb-2013 12:34, Marco Leise пишет:Am Tue, 12 Feb 2013 13:38:53 +0100 schrieb Jacob Carlborg <doob me.com>: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 OlshanskyI'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:* ConfigurationYes, 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 optimalThe 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 argumentsAll 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
Feb 13 2013
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>: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* newInstance - Returns a new instance based on the class name or ClassInfo. Can handle any class regardless of constructorsSo I figure, Object.factory("ClassName") is too limited. I used to just force my code work with that one.
Feb 13 2013
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
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
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 argumentsJust 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
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
15-Feb-2013 00:03, Jacob Carlborg пишет:On 2013-02-14 13:20, Regan Heath 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. -- Dmitry OlshanskyJust 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.
Feb 14 2013
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
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
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
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
On Thursday, 14 February 2013 at 21:40:41 UTC, Jacob Carlborg wrote:On 2013-02-14 22:21, John Colvin wrote: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.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?
Feb 14 2013
15-Feb-2013 01:40, Jacob Carlborg пишет:On 2013-02-14 22:21, John Colvin 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. In the option b Anyway the comment about porting from Tango still applies. -- Dmitry OlshanskyI 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?
Feb 14 2013
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
15-Feb-2013 12:29, Jacob Carlborg пишет:On 2013-02-15 07:29, Dmitry Olshansky wrote: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.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.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 OlshanskyIn 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.
Feb 15 2013
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:hugeOn 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 =oablemodule to do the "dump this struct in JSON" kind of thing that's d=otin 20-30 lines.=20 It's not huge. I already had the serialization library available. N=yusing 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=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=meis 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
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
On Friday, February 15, 2013 11:10:04 Jacob Carlborg wrote:On 2013-02-15 10:14, Jonathan M Davis wrote: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 DavisTests 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".
Feb 15 2013
On 2/15/13 3:29 AM, Jacob Carlborg wrote:On 2013-02-15 07:29, Dmitry Olshansky wrote: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. AndreiIt 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.
Feb 15 2013
On Feb 15, 2013, at 3:29 AM, Jacob Carlborg <doob me.com> wrote:On 2013-02-15 07:29, Dmitry Olshansky wrote: =20g it would be stupid.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==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
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
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
15-Feb-2013 01:49, Jacob Carlborg пишет:On 2013-02-14 21:33, Dmitry Olshansky wrote: [snip]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)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.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
On Friday, 15 February 2013 at 06:44:57 UTC, Dmitry Olshansky wrote:15-Feb-2013 01:49, Jacob Carlborg пишет: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.On 2013-02-14 21:33, Dmitry Olshansky wrote: [snip]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)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.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.
Feb 14 2013
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
On 02/15/13 09:04, Jonathan M Davis wrote:On Friday, February 15, 2013 08:50:14 sclytrack 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. arturWhen 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
Feb 15 2013
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
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
On 2013-02-15 07:44, Dmitry Olshansky wrote:15-Feb-2013 01:49, Jacob Carlborg пишет: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 CarlborgOn 2013-02-14 21:33, Dmitry Olshansky wrote: [snip]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)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.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.
Feb 15 2013
15-Feb-2013 12:47, Jacob Carlborg пишет: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'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.Looks like the key point. -- Dmitry Olshansky
Feb 15 2013
On 2/14/13 4:49 PM, Jacob Carlborg wrote:On 2013-02-14 21:33, Dmitry Olshansky wrote:We can't do that for the reasons put forward in my previous post.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.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. Andreib) 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.
Feb 15 2013
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
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
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
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
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
On Thursday, 14 February 2013 at 20:04:44 UTC, Jacob Carlborg wrote:On 2013-02-14 13:20, Regan Heath wrote:May I be of help? I'd gladly spent some efforts on improving std.getopt given some official design direction.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.
Feb 14 2013
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
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
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
On Friday, 15 February 2013 at 08:48:56 UTC, Jacob Carlborg wrote:On 2013-02-14 23:15, Dicebot wrote: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.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.
Feb 15 2013
On 2/15/13 4:25 AM, Dicebot wrote:On Friday, 15 February 2013 at 08:48:56 UTC, Jacob Carlborg wrote:Dicebot, if Jacob allows you to copy his design with a clean-room implementation, I think this is a great way going forward. AndreiOn 2013-02-14 23:15, Dicebot wrote: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.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.
Feb 15 2013
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. AndreiI 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
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.getoptBtw 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
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
On Tuesday, 12 February 2013 at 12:38:55 UTC, Jacob Carlborg wrote:* XML - The XML module is slow and has a cumbersome APIFor 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
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
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
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
On Saturday, 16 February 2013 at 15:13:18 UTC, Jacob Carlborg wrote:On 2013-02-15 18:16, nazriel wrote: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.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."
Feb 17 2013