February 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
February 15, 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
February 15, 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
February 15, 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
February 15, 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
February 15, 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
February 15, 2013
On 2013-02-15 07:44, Dmitry Olshansky wrote:
> 15-Feb-2013 01:49, Jacob Carlborg пишет:
>> On 2013-02-14 21:33, Dmitry Olshansky wrote:
>> [snip]
>>> Regardless I think reducing dependencies is the important for inclusion
>>> of any new component into the "D core".
>>
>> In general I think that the D community should embrace all
>> developers/contributors and existing libraries.
>
> Not talking about your stuff in particular but in general - hell no.
> There is a line between accepting everything just because we can't lose
> the chance (hence current std.xml, std.json and other crappy stuff) and
> accepting decent stuff that was specifically following current Phobos
> idoms, was reviewed, etc. The latter puts quite a strain on the
> contributor and in the end should guarantee the quality of addition (and
> commitment to maintain it).
>
> That being said once package manager is there tested and solid 3-rd
> party libs will flow. (tested & solid simply because of greater exposure
> factor)
>
>> It cannot afford to
>> loose contributions for petty things like this.
>
> I'd say if contributor can't be bothered to follow conventions and deal
> with the constraints imposed, just let him go. Coherency is all
> important in the core part of pretty much anything.

If you want to create a new zip and xml modules even though there already exist perfectly good and working ones, go ahead. I don't want to waste time on that.

-- 
/Jacob Carlborg
February 15, 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
February 15, 2013
15-Feb-2013 12:29, Jacob Carlborg пишет:
> On 2013-02-15 07:29, Dmitry Olshansky wrote:
>
>> It could then the only roadblock is dependency on Tango.
>> The only problem I had with serialization is that it's like using huge
>> module to do the "dump this struct in JSON" kind of thing that's doable
>> in 20-30 lines.
>
> It's not huge. I already had the serialization library available. Not
> using it would be stupid.
> Having 30k+ lines of code just to get the time _is_ huge.

With through unittests being about 50% of the said code...
Plus it's not get the time (nobody stops you from calling gettimeofday of POSIX)
and calendar/timezones stuff is ridiculously hard to get right,
I for one wouldn't try to re-implement it.

That being said I like slim stuff with no baggage and yes, std.datetime is huge.

Dumping anything to JSON and back is an easy task in D, see e.g. this one:
https://github.com/CyberShadow/ae/blob/master/utils/json.d

That's why I asked what _exactly_ of serialization (as in capabilities) is required.

>> In the option b Anyway the comment about porting from Tango still
>> applies.
>
> Just because you guys are too stubborn to include it in the distribution.
>

Nice touch, "you guys" is very assuming.
IMHO (personal opinion) the problems boil down to the fact that Tango:

a) Still has incompatible license-wise
b) Half of it is already doable (if not better) in Phobos
c) Has largely incompatible interface and design
d) Somebody got to maintain it in the official repo too

Of the above I think a) and d) are the key ones.

-- 
Dmitry Olshansky
February 15, 2013
15-Feb-2013 12:47, Jacob Carlborg пишет:
>> I'd say if contributor can't be bothered to follow conventions and deal
>> with the constraints imposed, just let him go. Coherency is all
>> important in the core part of pretty much anything.
>
> If you want to create a new zip and xml modules even though there
> already exist perfectly good and working ones, go ahead.

I'd go for it iff I'm sure I can do better. But that's a re-hash of balance between NIH/from scratch approach vs reuse & tap into somebody else infrastructure.

> I don't want to
> waste time on that.
>

Looks like the key point.

-- 
Dmitry Olshansky