On Friday, February 15, 2013 13:03:04 Dmitry Olshansky wrote:
> 15-Feb-2013 12:29, Jacob Carlborg пишет:
> > On 2013-02-15 07:29, Dmitry Olshansky wrote:
> >> It could then the only roadblock is dependency on Tango.
> >> The only problem I had with serialization is that it's like using huge
> >> module to do the "dump this struct in JSON" kind of thing that's doable
> >> in 20-30 lines.
> > 
> > It's not huge. I already had the serialization library available. Not
> > using it would be stupid.
> > Having 30k+ lines of code just to get the time _is_ huge.
> 
> With through unittests being about 50% of the said code...
> Plus it's not get the time (nobody stops you from calling gettimeofday
> of POSIX)
> and calendar/timezones stuff is ridiculously hard to get right,
> I for one wouldn't try to re-implement it.
> 
> That being said I like slim stuff with no baggage and yes, std.datetime is huge.

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.

- Jonathan M Davis

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.

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

And it is exactly why I offered help in rewriting some of those, as someone more interested in improving Phobos. If all this discussion is only about convincing to get some parts of Tango into official distribution as-is - I doubt it will be going anywhere and dropping is the right thing.

Also it is not exactly a political issue. Tango style and design is considerably different from Phobos and mixing so different stuff in one distribution is the road to PHP hell. Much worse than any reimplementation (more like "refactoring" in practice) efforts. Just my 5 cents.

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

On Friday, February 15, 2013 11:10:04 Jacob Carlborg wrote:
> On 2013-02-15 10:14, Jonathan M Davis wrote:
> > Tests are over half of it, and the documentation is probably around half
> > of
> > what's left after that, and those tests are critical. As simple as much of
> > the code is, it's ridiculously easy to get stuff wrong when it comes to
> > corner cases. And it's doing a _lot_ more than getting the time. So, for
> > the most part, I think that it merits being as large as it is. It's the
> > fact that it's all in one module that's the problem (and it was actually
> > split in my original proposal, but I split it badly, and I was told to
> > put it back together again. It also changed quite a lot over the course
> > of the review).
> > 
> > I _would_ like to split it up though. But I'm not going to do it until
> > some
> > variant of DIP 15 or 16 is implemented so that it can be split up in place
> > without breaking any code.
> 
> The easy solution would be to have the tests in its own module, in its own directory structure. But that's a no no since apparently "tests in D are supposed to be inline".

And it would make maintenance harder. I find that it's extremely valuable to have the tests right after the functions that they're testing. It's extremely annoying that you can't generally do that with templated types (because then the tests are instantiated with the template). I'd hate to put the tests separate from the functions that they're testing. And I don't find that the size of the file is really a problem. The problem is the size of the generated documentation. _That's_ what really needs to be split up, and if the generated docs were to be split without changing std/datetime.d, that would solve 95% of the problem. Having the various types organized into sub-modules would help somewhat with maintainence, but not a lot. I use vim's search capabilities for finding everything in source code normally anyway. Scrolling is way too slow in comparison even for small modules.

I know that you like the idea of separating the tests from the code, and maybe that works well for you, but that just doesn't work well for me. I very much like the fact that the normal place to put unit tests in D is right after the function being tested.

- Jonathan M Davis

On 02/15/13 09:04, Jonathan M Davis wrote:
> On Friday, February 15, 2013 08:50:14 sclytrack wrote:
>> When is D going to officially release with official third party libraries? Like synchronized with the release of dmd and bundled together in a huge (as large as possible) compressed file. Like Derelict, Gtkd, Qtd, Vibe, Apache Thrift. I mean not included in phobos but included in the release.
> 
> Why would we ever do that? It's 3rd party stuff, not official. I'm not aware of _any_ language that does anything like that. And why would you want releases of 3rd party libraries to be tied to the compiler? Not to mention, there are

One reason why people are asking for such a distribution model is the
"stability" of D. IOW, both the language and compiler capabilities change
so often that you can't expect version X of the compiler to work with
version Y of some library. Even for reasonably close releases of these
projects, like libs published less than ~ a year after the compiler.
Recent examples: '=>'-lambdas, UDAs and many smaller changes. It only
takes one library that uses a newer feature and you have to upgrade
the compiler, which can be problematic for various reasons, including
some /other/ used libs failing after such upgrade. Figuring out a working
set of tools and libs can be hard, and require maintaining local changes
to several external projects/libs.

artur

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

On 2/14/13 9:06 PM, Jonathan M Davis wrote:
> On Thursday, February 14, 2013 17:45:04 Michel Fortin wrote:
>> On 2013-02-14 21:38:24 +0000, Jacob Carlborg<doob@me.com>  said:
>>> On 2013-02-14 22:00, Steven Schveighoffer wrote:
>>>> The other things, such as xml, I think are more troublesome. This seems
>>>> like a trivial problem with a trivial solution.
>>>
>>> Yes, so what about the other things, such as xml. Any suggestions?
>>
>> I'm not sure why you don't want to continue using Tango. It's no longer
>> incompatible with Phobos I think.
>
> Anyone is free to use Tango in their own apps, just like they're free to use
> any 3rd party library. The problem is that Andrei doesn't want anything to be
> "official" unless it only depends on official stuff (I don't know how Walter feels
> about that). So, if Orbit is to be D's official package manager (and presumably
> be in the D-Programming-Language group on github), it can't depend on any
> libraries other than D's standard library and its own internal libraries.

Allow me to qualify this.

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

That being said, when discussing things to be added to the official canon, there are two aspects to be thought of. First, there's the whole licensing issue - if we start distributing code with heterogeneous licenses we create only headaches for our users. Second, it's about the story we put forward: if the standard library offers some functionality but its own satellite packages redo it from scratch with slightly different names, that's just not good.


Andrei

Am Fri, 15 Feb 2013 09:23:52 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2013-02-15 04:15, Walter Bright wrote:
> 
> > I agree with Andrei, it's part of that "eat your own dogfood" thing, at least for "official" stuff.
> 
> Orbit does, it's written in D. Not something I can say about DMD or probably half of what's included in the DMD distribution. Just because I don't want to create my own XML or Zip library it's not "eat your own dogfood"? That's kind of extreme.

Relax, I guess all that meant was: Phobos' quality needs to be
improved to the point that you don't have to look for other
solutions.
Maybe it also means that in the long run Phobos inevitably
grows to support more advanced official tools, probably with
graphical user interfaces.

-- 
Marco

On 2/14/13 3:01 PM, Jacob Carlborg wrote:
> On 2013-02-14 13:42, Andrei Alexandrescu wrote:
>
>> I understand. Adding functions such as the negation of empty becomes a
>> judgment call.
>>
>> Phobos does have quite a few simple functions that could be easily
>> achieved through expression composition (e.g. trim) or statement
>> composition (e.g. enforce). So again it's all a matter of judgment.
>>
>> Walter and I don't consider the negation of empty as useful enough to
>> receive a name.
>
> How about this, I have another similar function that might be useful in
> Phobos as well.
>
> "isBlank" and "isPresent". "isPresent" is just the opposite of "isBlank".
>
> "isBlank" works like this:
>
> * If it's a string - it's considered blank if it's empty or only
> contains white space
>
> * If you can call "empty" on it - return the result
>
> * If it's a reference type and it's null - return true
>
> * Otherwise return false

I think this is a fine candidate for a standard function. It does actual work, is useful, and can't be trivially achieved with inline code.

Andrei