Lars Ivar Igesund wrote:
> Bill Baxter wrote:
> 
>> Mike Parker wrote:
>>> Sean Kelly wrote:
>>>> Mike Parker wrote:
>>>>> Walter Bright wrote:
>>>>>> I've thought about cash prizes and contests. I just had the nagging
>>>>>> feeling that the result would be a circus rather than serious
>>>>>> development.
>>>>> What about bounties?
>> Getting some Google summer-of-coders might be good too.
>> Where there any proposals for D this last time around?
>>
>> --bb
> 
> afaik, only formally organized projects may apply, although it is somewhat
> unclear to me what constitutes formal in this respect.
> 

I'm pretty sure D is formally organized enough to count.
There may be some application process to qualify as a mentor, though.


--bb

Derek Parnell wrote:
> On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:
> 
>> I'm happy to merge things in, but am reluctant to do so without reviewing the diffs line by line.
> 
> Actually, when I wrote "take Phobos", I really meant "take Phobos". You
> would no longer have *the* sole controlling vote on what goes in or goes
> out of phobos, nor would you have sole control over when new libraries were
> released for general consumptuion. They would in fact be released
> asynchonously from DMD. There would be 'beta' versions around for trying
> our stuff and official releases for people who just needed a standard
> library. Are you willing to give up control of Phobos?
> 

Wait, now I don't get it. If you meant that Walter was not to have control of it, and in fact it(the lib) wouldn't even be bundled or synchronous with DMD, then wouldn't that make it an alternative lib, like Ares, which is something that can be made now?

(When I said I would like to some more community development in Phobos, I really meant *Phobos*, the stdlib that is official, comes with D/DMD, is Walter approved,etc.)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Sean Kelly wrote:
> Lionello Lunesu wrote:
>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:eh0hgs$q8h$1@digitaldaemon.com...
>>
>>> I'm happy to merge things in, but am reluctant to do so without reviewing the diffs line by line.
>>
>> That's what we have now. I think it's time for you to let go of Phobos. 
> 
> It's a bit more complicated than that, since Phobos includes a bunch of compiler runtime code used by DMD.  This is also why GDC has a separate GPhobos where the only substantive difference is this runtime code.
> 
>> There can't be a community lead standard library from which you take patches to include into DMD's distribution.
> 
> Sure there can.
> 
>  > We'd end up with another Ares.
> 
> I think Ares isn't used widely for two (or perhaps three) reasons:
> 
> * Visibility
> * Features
> * Endorsement (maybe)
> 

Speaking of Ares, there is something I've wanted to have clarified, which is apropos to this discussion:
My issue with Ares, is actually one of objective/purpose. The goal of Ares is stated to be an alternative to Phobos, but my question is how much of an alternative?
Is it meant as a general, encompassing alternative to Phobos, targeted to the general (D) programmer populace, or is it a specific alternative, where it aims to deal with some issues you (and some more coders) have with Phobos, but not go further than that? Because a standard lib is a wide and ranged collection of code, and all modules and aspects of it need to be well-considered.
I don't think I'm being too clear with my point here, so I'll take a look at Ares and try to give a more concrete example.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Lionello Lunesu wrote:
>>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:eh0hgs$q8h$1@digitaldaemon.com...
>>>
>>>> I'm happy to merge things in, but am reluctant to do so without reviewing the diffs line by line.
>>>
>>> That's what we have now. I think it's time for you to let go of Phobos. 
>>
>> It's a bit more complicated than that, since Phobos includes a bunch of compiler runtime code used by DMD.  This is also why GDC has a separate GPhobos where the only substantive difference is this runtime code.
>>
>>> There can't be a community lead standard library from which you take patches to include into DMD's distribution.
>>
>> Sure there can.
>>
>>  > We'd end up with another Ares.
>>
>> I think Ares isn't used widely for two (or perhaps three) reasons:
>>
>> * Visibility
>> * Features
>> * Endorsement (maybe)
>>
> 
> Speaking of Ares, there is something I've wanted to have clarified, which is apropos to this discussion:
> My issue with Ares, is actually one of objective/purpose. The goal of Ares is stated to be an alternative to Phobos, but my question is how much of an alternative?
> Is it meant as a general, encompassing alternative to Phobos, targeted to the general (D) programmer populace, or is it a specific alternative, where it aims to deal with some issues you (and some more coders) have with Phobos, but not go further than that? Because a standard lib is a wide and ranged collection of code, and all modules and aspects of it need to be well-considered.

It's original aim was to be a complete replacement, but a lack of community participation changed the focus a bit.  Ares is now really just a minimal framework on top of which a standard library may be built.  And progress there has stalled a bit in the past few months because I've been too busy with other things.  However, I do have some redesign ideas in mind that should hopefully bear fruit before too terribly long.  And these are intended both to address deficiencies in the original design and to hopefully make for the beginnings of a better library.


Sean

Georg Wrede wrote:
>> It's a
>> bit hard to keep track of things unless one regularly reads the NG. The
>> worst thing is that whenever something "big" happens, something like
>> 5-10 threads with 1000+ messages pops out of nowhere. It takes a week to
>> realize what's going on :-I
> 
> My feelings exactly. Stay here 18 hours per day and nothing happens. Get out of town for 2 days, and all of a sudden you find 500 unread messages.
> 
> But what bugs me even more is that I continually keep finding "already old" things that have surreptitiously been fixed or implemented in D, and by still asking for them here I just make a fool of myself. No help rereading the entire HTML documentation tree and all the posts here between every release. Seems like the only way to do this is to implement a diff system that goes through the whole dmd tree between each and every release. At times it really is frustrating.

Yes, and that's simple actually, I've been doing that since the latest 10 revisions or so. Just put the spec under SVN, and on a new release unpack dmd and do:
  svn diff > dmdXXX.txt
  svn commit -m dmdXXX
plus run 1 or 2 regexps on dmdXXX.txt to eliminate some trivial stuff, like the last updated stamps.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bill Baxter wrote:
> Lars Ivar Igesund wrote:
> 
>> Bill Baxter wrote:
>>
>>> Mike Parker wrote:
>>>
>>>> Sean Kelly wrote:
>>>>
>>>>> Mike Parker wrote:
>>>>>
>>>>>> Walter Bright wrote:
>>>>>>
>>>>>>> I've thought about cash prizes and contests. I just had the nagging
>>>>>>> feeling that the result would be a circus rather than serious
>>>>>>> development.
>>>>>>
>>>>>> What about bounties?
>>>
>>> Getting some Google summer-of-coders might be good too.
>>> Where there any proposals for D this last time around?
>>>
>>> --bb
>>
>>
>> afaik, only formally organized projects may apply, although it is somewhat
>> unclear to me what constitutes formal in this respect.
>>
> 
> I'm pretty sure D is formally organized enough to count.
> There may be some application process to qualify as a mentor, though.
> 
> 
> --bb

It'd be nice if someone would apply for mentorship for summer of code '07.  You don't have much to lose.  I was looking at the summer of code in 2006 as a student and didn't see any D projects on there, but I was probably too late anyways.  If someone were to be a mentor for 2007 with a D project, I would seriously look at doing that.  That $4500 stipend is mighty appealing at my current pay level of nothing with the studentacious employment potential of a mcjob.

So... who wants an extra developer next summer? :)

Chad J > wrote:
> Bill Baxter wrote:
>> Lars Ivar Igesund wrote:
>>
>>> Bill Baxter wrote:
>>>
>>>> Mike Parker wrote:
>>>>
>>>>> Sean Kelly wrote:
>>>>>
>>>>>> Mike Parker wrote:
>>>>>>
>>>>>>> Walter Bright wrote:
>>>>>>>
>>>>>>>> I've thought about cash prizes and contests. I just had the nagging
>>>>>>>> feeling that the result would be a circus rather than serious
>>>>>>>> development.
>>>>>>>
>>>>>>> What about bounties?
>>>>
>>>> Getting some Google summer-of-coders might be good too.
>>>> Where there any proposals for D this last time around?
>>>>
>>>> --bb
>>>
>>>
>>> afaik, only formally organized projects may apply, although it is somewhat
>>> unclear to me what constitutes formal in this respect.
>>>
>>
>> I'm pretty sure D is formally organized enough to count.
>> There may be some application process to qualify as a mentor, though.
>>
>>
>> --bb
> 
> It'd be nice if someone would apply for mentorship for summer of code '07.  You don't have much to lose.  I was looking at the summer of code in 2006 as a student and didn't see any D projects on there, but I was probably too late anyways.  If someone were to be a mentor for 2007 with a D project, I would seriously look at doing that.  That $4500 stipend is mighty appealing at my current pay level of nothing with the studentacious employment potential of a mcjob.
> 
> So... who wants an extra developer next summer? :)

Hehe, I tried to apply last summer but got rejected. I will try harder next summer though, I bet my application just wasn't detailed and exciting enough to stand out.

hi Chad

I plan to start an open source D project very soon,
so maybe next summer there will be a opportunity.


>> 
>> --bb
> 
> It'd be nice if someone would apply for mentorship for summer of code '07.  You don't have much to lose.  I was looking at the summer of code in 2006 as a student and didn't see any D projects on there, but I was probably too late anyways.  If someone were to be a mentor for 2007 with a D project, I would seriously look at doing that.  That $4500 stipend is mighty appealing at my current pay level of nothing with the studentacious employment potential of a mcjob.
> 
> So... who wants an extra developer next summer? :)

Bill Baxter wrote:
> Mike Parker wrote:
>> Sean Kelly wrote:
>>> Mike Parker wrote:
>>>> Walter Bright wrote:
>>>>>
>>>>> I've thought about cash prizes and contests. I just had the nagging feeling that the result would be a circus rather than serious development.
>>>>
>>>> What about bounties? 
> 
> Getting some Google summer-of-coders might be good too.
> Where there any proposals for D this last time around?
> 
> --bb

Actually there where (one mine), but it was ineligible to participate.
The reason was: proposals must be submitted under the respective mentor
organizations, and if there is no mentor organization for the proposal,
it can be submitted to Google. However this year's SoC (unlike the
previous one) such applications without mentor organization must have a
high "academic research focus", and when I found that out it was too
late for new mentor organizations to sign up (one representing D was needed). :(
I think it's an opportunity that should not be missed next year.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Kristian wrote:
> So maybe we should have contents on APIs first. When we got the base  structure right, we can make competitions on parts (e.g. functions,  classes) that should be efficient, or hard to implement. Bulk (trivial)  stuff can be implemented outside the competitions later. Also, API  implementations should include documentation.

I think an API competition should definitely be in two stages:

 - compete on the most useful and best spec
 - then compete on the most elegant implementations of the winning spec