On Wednesday, 19 March 2014 at 15:02:55 UTC, Andrei Alexandrescu wrote:
> On 3/19/14, 7:07 AM, Marco Leise wrote:
>> I wonder if we could finally have that experimental package,
>> call it "ext" or "etc" or whatever that has only one barrier
>> to entry: the intent of the module must pass review.
>
> I think it's time to add an experimental package.
>
> Andrei

I am against it. It gives nothing over dub and creates confusion.

On 3/19/14, 8:45 AM, Dicebot wrote:
> On Wednesday, 19 March 2014 at 15:02:55 UTC, Andrei Alexandrescu wrote:
>> On 3/19/14, 7:07 AM, Marco Leise wrote:
>>> I wonder if we could finally have that experimental package,
>>> call it "ext" or "etc" or whatever that has only one barrier
>>> to entry: the intent of the module must pass review.
>>
>> I think it's time to add an experimental package.
>>
>> Andrei
>
> I am against it. It gives nothing over dub and creates confusion.

Who'd be confused?

Andrei

On Wednesday, 19 March 2014 at 15:58:43 UTC, Andrei Alexandrescu wrote:
> Who'd be confused?
>
> Andrei

Users who see find it in Phobos will be confused about how experimental exactly it is and what to expect from it. Developers will be confused about what is expected from them maintenance-wise starting from this point and what to do with reported bugs / issues.

Don't put stuff which is naturally bleeding edge into scheduled controlled distributions. dub has special category for Phobos proposals, we need to better popularize it.

Am Wed, 19 Mar 2014 16:06:44 +0000
schrieb "Dicebot" <public@dicebot.lv>:

> On Wednesday, 19 March 2014 at 15:58:43 UTC, Andrei Alexandrescu wrote:
> > Who'd be confused?
> >
> > Andrei
> 
> Users who see find it in Phobos will be confused about how experimental exactly it is and what to expect from it. Developers will be confused about what is expected from them maintenance-wise starting from this point and what to do with reported bugs / issues.

Why was that never a problem for OpenGL ?

> Don't put stuff which is naturally bleeding edge into scheduled controlled distributions. dub has special category for Phobos proposals, we need to better popularize it.

That much is true. Last time I checked it wasn't there. Then
again everyone can add categories there. I added two myself.
Everyone can tag their package as Phobos candidate.
But I cannot imagine random packages on dub getting the same
exposure as modules included in Phobos.

They will be auto-tested, the idea has the approval of the community and they are ready to use when you install the compiler.

Personally I avoid dub, so to that end I'm probably biased.

-- 
Marco

On 3/19/14, 9:06 AM, Dicebot wrote:
> On Wednesday, 19 March 2014 at 15:58:43 UTC, Andrei Alexandrescu wrote:
>> Who'd be confused?
>>
>> Andrei
>
> Users who see find it in Phobos will be confused about how experimental
> exactly it is and what to expect from it.  Developers will be confused
> about what is expected from them maintenance-wise starting from this
> point and what to do with reported bugs / issues.
>
> Don't put stuff which is naturally bleeding edge into scheduled
> controlled distributions. dub has special category for Phobos proposals,
> we need to better popularize it.

Ionno. To me "experimental" sounds as informative and self-explanatory as it gets, and puts things up for experimentation with the distribution and without requiring users to take special steps.

Andrei

On Wed, 2014-03-19 at 15:45 +0000, Dicebot wrote:
> On Wednesday, 19 March 2014 at 15:02:55 UTC, Andrei Alexandrescu wrote:
> > On 3/19/14, 7:07 AM, Marco Leise wrote:
> >> I wonder if we could finally have that experimental package, call it "ext" or "etc" or whatever that has only one barrier to entry: the intent of the module must pass review.
> >
> > I think it's time to add an experimental package.
> >
> > Andrei
> 
> I am against it. It gives nothing over dub and creates confusion.

The experimental package was removed from Go once the importing from repositories worked properly. The core had only in it that which had been agreed by the process, nothing experimental. This made everything a lot cleaner.

So I think keeping Phobos with only vetted and approved code is a better solution.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 19 March 2014 at 16:42:43 UTC, Andrei Alexandrescu wrote:
> Ionno. To me "experimental" sounds as informative and self-explanatory as it gets, and puts things up for experimentation with the distribution and without requiring users to take special steps.
>
> Andrei

If it is in Phobos repo, it:
 - floods Phobos notifications / activity list
 - gets bug reports into D bugzilla

..except author does not have direct access to it anymore. And if author decides it is not worth pursuing anymore, unsupported module will still be kept in distribution.

"experimental" by definition implies that author is supposed to tinker about it and it needs rapid edit-feedback cycle. You can't get it if put code out of authors control into Phobos. It will be same problem as with Deimos - stuff just rots there. With only exception that you don't need to change C bindings often, contrary to experimental Phobos modules.

Also different people have different expectation of "experimental" stability. Some may think it is something almost fleshed in stone (it is going to be proposed to Phobos after all!) but with occasional tweaks. In practice it is something that can be completely re-written or even disappear by next Phobos release.

On Wednesday, 19 March 2014 at 16:35:15 UTC, Marco Leise wrote:
>> Users who see find it in Phobos will be confused about how experimental exactly it is and what to expect from it. Developers will be confused about what is expected from them maintenance-wise starting from this point and what to do with reported bugs / issues.
>
> Why was that never a problem for OpenGL ?

I know nothing about OpenGL but it was (and is) huge problem for Java.

>> Don't put stuff which is naturally bleeding edge into scheduled controlled distributions. dub has special category for Phobos proposals, we need to better popularize it.
>
> That much is true. Last time I checked it wasn't there. Then
> again everyone can add categories there. I added two myself.
> Everyone can tag their package as Phobos candidate.

There is no point in implementing moderated category until it is not abused. If it will attract abuse, we will add moderation.

> But I cannot imagine random packages on dub getting the same
> exposure as modules included in Phobos.

The problem is exactly that those are random package right now. Instead those should be cleanly visible in code.dlang.org interface and possibly also linked from dlang.org main page. Linked from distributed Phobos documentation. Everything should beg user to go and try it.

> Personally I avoid dub, so to that end I'm probably biased.

I avoid it too but it is my personal problem to deal with. dub is de-facto standard in D tool chain and I am pretty sure eventually will be distributed with dmd.

On Wednesday, 19 March 2014 at 01:44:16 UTC, bearophile wrote:
> Chris Williams:
>
>> Yeah, several methods work just fine if you change their declaration to isIntegral!T || is(typeof(T) == BigInt). gcd() is one of them.
>>
>> Unfortunately, I don't trust rewriting isIntegral, so this sort of change would need to be on a function-by-function basis.
>
> Don explained me that a GCD on BigInts should use a more efficient algorithm.
>
> Bye,
> bearophile

There's a couple algorithms on the Wikipedia, but when I profiled them on some -very large- values, they all had similar performance times, including the ones that were just a few lines of simple code. It's possible that there's an optimized variant somewhere on the greater internet, but that might take some hunting to track down.

Ultimately, it's probably better to expose functionality in Phobos, even if they're simple implementations. Eventually, some enterprising person will find and implement an optimized version, and in the meantime, everyone has a working, tested version that they didn't have to write nor validate themselves.

On 3/19/14, 10:01 AM, Dicebot wrote:
> I avoid it too but it is my personal problem to deal with. dub is
> de-facto standard in D tool chain and I am pretty sure eventually will
> be distributed with dmd.

It may be time to look into this. Who wants to champion this effort? -- Andrei