February 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.
February 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:
>
>> The other things, such as xml, I think are more troublesome.  This seems
>> like a trivial problem with a trivial solution.
>
> Yes, so what about the other things, such as xml. Any suggestions?
>

No.  Clearly using tango xml will not fly.

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

I also think serialization is something we should have in phobos, regardless of Orbit's requirements.

std.process should be remedied soon (it's nearing review).

The others, I'm not sure.

What about this as a possible ongoing solution:

Step 1. Include orbit in BINARY form on the distribution, keep it in its own project wherever it lives now.  Dogfood be damned...
Step 2. Port as much as possible to Phobos.  As libraries become available, try to port it over to the new library.
Utopian step. Include Orbit and source in distribution, without external dependencies.

I don't see why dmd distribution needs to include the source for all the tools it uses.  I frequently never touch the source of dmd distribution, I just use the compiled binaries.

This might be kind of viewed like DMD.  It has parts in it that are ASM, that Walter is slowly porting to C++.  Why can't we use that same model?

-Steve
February 14, 2013
On 2013-02-14 21:38:24 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-02-14 22:00, Steven Schveighoffer wrote:
> 
>> The other things, such as xml, I think are more troublesome.  This seems
>> like a trivial problem with a trivial solution.
> 
> Yes, so what about the other things, such as xml. Any suggestions?

I'm not sure why you don't want to continue using Tango. It's no longer incompatible with Phobos I think.

Anyway, you might like this old thing:

http://michelf.ca/docs/d/mfr-xml-2010-10-19.zip

http://michelf.ca/docs/d/mfr/xml.html
http://michelf.ca/docs/d/mfr/xmltok.html

I wrote that a few years ago. I don't intend to put more work in it
(I have no use for it). I made an incomplete proof of concept for a
buffered input range once for it, but I don't think that's part of the
package above.

If someone want to improve those modules and republish them, feel free.
Boost license and all.

(And if you have an impression of déjà-vu, it's because I posted almost the same thing to this newsgroup sometime in 2011.)

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

February 15, 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:
> > On 2013-02-14 22:00, Steven Schveighoffer wrote:
> >> The other things, such as xml, I think are more troublesome. This seems like a trivial problem with a trivial solution.
> > 
> > Yes, so what about the other things, such as xml. Any suggestions?
> 
> I'm not sure why you don't want to continue using Tango. It's no longer incompatible with Phobos I think.

Anyone is free to use Tango in their own apps, just like they're free to use any 3rd party library. The problem is that Andrei doesn't want anything to be "official" unless it only depends on official stuff (I don't know how Walter feels about that). So, if Orbit is to be D's official package manager (and presumably be in the D-Programming-Language group on github), it can't depend on any libraries other than D's standard library and its own internal libraries.

- Jonathan M Davis
February 15, 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
February 15, 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.

February 15, 2013
15-Feb-2013 01:40, Jacob Carlborg пишет:
> On 2013-02-14 22:21, John Colvin wrote:
>
>> I personally don't see why orange can't just be included as part of
>> orbit. It's written and maintained by the same person after all.
>
> Sure it can. Would that be ok?
>

It could then the only roadblock is dependency on Tango.
The only problem I had with serialization is that it's like using huge module to do the "dump this struct in JSON" kind of thing that's doable in 20-30 lines.

In the option b Anyway the comment about porting from Tango still applies.

-- 
Dmitry Olshansky
February 15, 2013
15-Feb-2013 01:49, Jacob Carlborg пишет:
> On 2013-02-14 21:33, Dmitry Olshansky wrote:
> [snip]
>> Regardless I think reducing dependencies is the important for inclusion
>> of any new component into the "D core".
>
> In general I think that the D community should embrace all
> developers/contributors and existing libraries.

Not talking about your stuff in particular but in general - hell no. There is a line between accepting everything just because we can't lose the chance (hence current std.xml, std.json and other crappy stuff) and accepting decent stuff that was specifically following current Phobos idoms, was reviewed, etc. The latter puts quite a strain on the contributor and in the end should guarantee the quality of addition (and commitment to maintain it).

That being said once package manager is there tested and solid 3-rd party libs will flow. (tested & solid simply because of greater exposure factor)

> It cannot afford to
> loose contributions for petty things like this.

I'd say if contributor can't be bothered to follow conventions and deal with the constraints imposed, just let him go. Coherency is all important in the core part of pretty much anything.

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


When is D going to officially release with official third party libraries? Like synchronized with the release of dmd and bundled together in a huge (as large as possible) compressed file. Like Derelict, Gtkd, Qtd, Vibe, Apache Thrift. I mean not included in phobos but included in the release.

February 15, 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