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

May I be of help? I'd gladly spent some efforts on improving std.getopt given some official design direction.

On Thu, 14 Feb 2013 14:57:25 -0500, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-14 15:28, Steven Schveighoffer wrote:
>
>> Would this work?
>>
>> bool any(R)(R r) if(isInputRange!R) { return !r.empty;}
>
> Yes, I already have something similar. Actually I have this:
>
> @property bool any (T) (T value) if (__traits(compiles, { bool a = value.empty; }))
> {
>      return !value.empty;
> }

OK, here is what I suggest:

1. put all these "helper" trivial functions inside a module, call it orbithelper.
2. If phobos obtains these functions, remove them from orbithelper, and import the correct version.

The other things, such as xml, I think are more troublesome.  This seems like a trivial problem with a trivial solution.

-Steve

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

In python and matlab 0 is false and "any" treats them as such.

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.

On 2/14/2013 1:00 PM, Steven Schveighoffer wrote:
> On Thu, 14 Feb 2013 14:57:25 -0500, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2013-02-14 15:28, Steven Schveighoffer wrote:
>>
>>> Would this work?
>>>
>>> bool any(R)(R r) if(isInputRange!R) { return !r.empty;}
>>
>> Yes, I already have something similar. Actually I have this:
>>
>> @property bool any (T) (T value) if (__traits(compiles, { bool a =
>> value.empty; }))
>> {
>>      return !value.empty;
>> }
>
> OK, here is what I suggest:
>
> 1. put all these "helper" trivial functions inside a module, call it orbithelper.

Sounds like a good idea.

> 2. If phobos obtains these functions, remove them from orbithelper, and import
> the correct version.

+1

> The other things, such as xml, I think are more troublesome.  This seems like a
> trivial problem with a trivial solution.

Yup.

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

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

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

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

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

I would see it as a good test of the library, helping to iron out issues before perhaps being included in phobos in future. Seems like everyone wins.