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)

When people hear about Ares, their first question is typically about Feature X or in some cases about Phobos compatibility.  And in general my response is that Ares is really mostly useful for people who don't want much in the way of standard library code (it's been used for some kernel development projects, for example) or for those who want a minimal framework to build on.  Mango integrates with Ares and fills essentially all the feature gaps between Ares and Phobos, but doing so requires downloading, installing, and updating a number of different libraries just to match what comes packaged with DMD--it's a large hurdle to overcome.

Another related reason may be community support--Ares has pretty much always been a one-man project, I haven't had the time to maintain it recently, and the project doesn't get many contributors.  It's extremely difficult to maintain interest and participation in community projects over time.  Typically, once the initial "gee whiz" factor wears off, most people go back to their lives and development stagnates.

However, I do think a project, if organized properly, might be able to overcome the problems that previous efforts have had--it's largely a matter of momentum.  Some sort of "official" stamp may ultimately be necessary to allay the fears of general users (who are more concerned with whether a library will be supported and maintained two years from now that with its feature set) and gain broad acceptance, but I don't think this would be necessary at the outset.  Community projects live and die based on community involvement, not endorsements.  Just look at DWT :-P

> Honestly, I don't think this Phobos review process can go on for much longer. Phobos should be hosted on dsource/sourceforge and its latest release should be included with each DMD/GDC release. You'll be one of the few with write rights, of course ;)

Frankly, I'm not certain of the best way to handle Walter's involvement in such a project--I think it would really depend on what appealed to him.  One option would be for him to maintain only the compiler runtime code (and perhaps GC code) separately and coordinate with the community how these interact with the standard library.  Another would be for him to accept patches from the community when necessary.  And yet another would be direct manipulation of the public source tree.  A lot really depends on how the project is structured, how the code is structured, and how Walter likes to work.  Were it me however, I'd probably prefer something more along the lines of my first two suggestions than the last one.  Unless I were just committing bulk updates to the public tree on each compiler release and otherwise maintaining those portions internally.


Sean

Walter Bright wrote:
> Knud Sørensen wrote:
>> clayasaurus wrote:
>>> Knud Sørensen wrote:
>>>
>>>> What about the library contest I suggested long ago ?? Is that a useful idea?
>>>
>>> How about a "Top 10 D libraries" page on digitalmars D where the D community votes for the top 10 libraries each month on the newsgroups and then they get a very special recognition on the digitalmars site?
>>
>> Yes, a monthly competition like this is also a good idea.
>>
>> We have several authors on the list maybe we can get them to donate a copy of one of there books for a first prize.
> 
> 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.

A library contest would be far too much work _both_ for the administrators and for the programmers.

For any non-trivial stuff it would necessarily drag out over months (if not quarters), and get psychologically diluted -- especially knowing that most (not all) of the contestants are of the breed "get quickly enthused and equally quickly disinterested". (Just look at the number of started projects at, say dsource, versus actual progress in most of them.)

A bit more demanding on the "establishment", but a lot more rewarding for our end goal would be to have contests on smaller units! Such would be individual classes, maybe groups of functions, or even very-narrow-purpose libraries. There should also be a separate, on-going series for single functions!!

The administration would be more work, granted. And choosing the contest items would require much more work if we wanted to stay determined on keeping in mind the end-goals and overall progress of the D effort.

---

Just think about it. At the extremes, we could either have a whole-library contest every year, or we could have a singe-function contest every week.

The bias here really ought to be a no-brainer, IMHO.

---

About monetary compensation: if I'm not totatlly wrong, the kind of money we could have available as prize money, probably is trivial anyway. So why not just be in it for the glory? (We might instead have votings, jurys, inteviews of the winners (a la F-1), or something else that folks feel inspiring!)

(I know that Euphoria (http://www.rapideuphoria.com) has "always" had this "toy money, on-going economy" with folks trying to make very nice apps, libraries, or utilities. But look at the booties: even the top grossings are hardly worth the wear on your keyboard. So, at the end of the day, it inevitably has to come down to just pride in workmanship.)

---

Now, if Walter's hint about cash prizes implies outside sponsors, then the question rises, could we use those sponsors more effectively? Like donated programmer-hours, paid advertising of Digital Mars on Google, professional documentation writers... anything!

(( Heck, one of my recurring daydreams is to get Google-Labs or IBM Developer Works interested in D. Against the clout and horsepower they have, I'd even be ready to negotiate some (small part) of Walter's final say in D to them! Both these guys are in an position to gross simply preposterously from using D, and for that publicity I'd be willing to offer them some tidbits of their choosing from the D say. ))

//// Sorry Walter, I know I'm out of line here. But then, if I weren't this kind of person, I'd be doing something "useful" instead of beating an unborn horse here. :-)

On Mon, 16 Oct 2006 13:08:11 -0700, Georg Wrede <georg.wrede@nospam.org> wrote:

>
> Dunno about others, but, IIRC, at the time it felt labourious to use, and non-portable. Thus, such an Official choice was, ehh, depressing.
>


SWT is portable... in a limited sort of way. :P  But all SWT ports to D would be laborious since the internals are so different from each other; each would require a specially crafted automation for each platform to make it feasible (in light of future SWT versions and fixes coming out).  Proof of it's portability, though, appears best demonstrated by the existance of a SWT framework for Pocket PC's.  As a GUI framework, however, SWT seems comprehensive and powerful.  It's just not a well-recognized or an easily learned solution.


>
> When I moved from VIC-20 to Kaypro-II, I had to switch from 6502 assembler to either Z-80 assembler or 8080 assembler. (Both were used "interchangeably" on the Z-80 on the Kaypro. And I didn't want to use both.) In hindsight, I spent so much time dithering between the two, that merely a toss of a coin at the start would have made the end result much happier. The same thing happened with Basic. On the VIC, I only had [a primitive version of] Microsoft Basic, whereas on the Kaypro, I had 2 versions of M$ interpreted Basic, a truly compiled basic ("C-basic"), and a (Java like) compiled but still interpreted Basic ("S-basic"). I couldn't make up my mind. (Today, I'd have used each of them for separate purposes. :-) ) The dithering didn't stop until a friend gave me a stolen copy of Turbo Pascal, v.2. (And yes, I've since repaid my debt to Borland several times beyond my legal obligations!)
>


Ah yes, those were the days. :)  My initial experience with computer languages was with the C64.  There, I moved form BASIC to 6510 assembler and then finally to C.


>>> I encourage, and have encouraged, anyone who wants to do this. Any or  all parts of Phobos can be used as a starting point. The compiler is my  central focus, to enable great libraries to be written.
>
> In the last years I've heard people ask and ask about this all over again. It's almost like people wanted to be asking till they get a no for an answer.
>


Hmmm... good point!  We should have learned by now, no doubt.  :)


>> Thank you for stating that here.  It's very much appreciated, as is all of  your work.  I know you've stated it in so many words before, but sometimes  repitition seems to be the only way to get things across in a newsgroup  where posts quickly get lost in the pile.
>
> By this time somebody simply ought to just go ahead and set up the repository.
> Like Nike: "just do it"!


Absolutely.  That's the only way to go.  Ares was a start.  I'm sure any such effort is not in vain.

-JJR

On Mon, 16 Oct 2006 14:04:02 -0700, Derek Parnell <derek@psyc.ward> 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?
>


I have to agree with this.  Walter can maintain his own Phobos version as necessary to continue his own compiler development and testing, but I really think we're looking for a more "publicly" maintained standard library that is not under strict control by the compiler writer (who has frankly admitted that his emphasis is on the compiler development).

The importance of relinquishing this control is more significant as more compilers are developed for the D language.  I think it's useful and important that all compilers get tested on a non-vendor specific standard library, rather than one that is tightly controlled by a single compiler vendor.  That, I believe, is a huge indicator to the openness of a language.

Note that when I say "public", I don't mean "free for all" standard library submissions.  I think we have to keep the maintenance limited to a few trusted individuals.  But I still think it must be much more open than it is now.  Dsource.org is a good spot for this.  While all this has been discussed to some extent before, I belive that a good groundwork of principles are already set to make this work with a minimum of deliberation and conflict.

Further, each compiler update, whether gdc or dmd, should be able to compile with agreed upon revision of the library before shipping.

-JJR

Jari-Matti Mäkelä wrote:
> Walter has promised to implement some things in 2.0, but suddenly they
> are fully implemented (sans possible bugs) in the next release.

Well, I think it is understandable. Since D is a one-man effort, it would feel downright disgusting to pin down the next two years.

From experience one knows that some of the "unbelievably hard" things to implement may become just simple after a good night's sleep, or after a nice morning shower some other problem might just "come to you" in a flash. Equally, some of the things slated for immediate release might prove intractable at closer look.

If, OTOH, a language (or any major SW project in general) is developed by a large group of developers, then it simply becomes imperative to have roadmaps, timelines, and all that stuff. That simply is the price to pay for coherence of effort and cohesion of the group.

(From the above two paragraphs it is clear that large projects simply have to be less productive per capita _unless_ the management is exceptionally adept and experienced.)



OT:

> 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.

Knud Sørensen wrote:
> Yes, part of it will be a circus, that one of the points of a contest.
> To attract people and show how good D is performing.
> 
> Some libraries might not be serious developed, but I think that the top libraries will be.
> 
> And a few good libraries might be worth all the circus.
> 
> If you look at history many excellent developments have been the
> results of competitions: 
> 
> The X price: we got a private developed spaceship.
> Clay institute millennium problems: Several problems had had more progress
> since the announcement that any other period in time.
> 

Those are good points. Another point is that whenever money gets involved, problems can come up. For example: taxes, 1099's, etc. For another, suppose I feel a submission isn't good enough, but the submitter does, and feels he's been rooked out of the cash. Bitter feelings result.

Georg Wrede wrote:

> 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.

Like this one ? http://gdcmac.sourceforge.net/diffs/

(as usual with auto-generated docs, there's a bunch
of false positives on the "generated on" timestamps)

--anders

Sean Kelly wrote:

> 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 are some other lib differences too, such as the version(Unix)
and std.c.unix.unix that are missing from the DMD library version ?
There's also a lot of similar portability fixes spread out over the
library, including some work for supporting 64-bit in the future...

So in many aspects, GDC GPhobos is a portable version of DMD Phobos.

--anders

Bill Baxter wrote:
> I think a batteries-included distribution would be a great help.
> The current situation makes it more difficult than it needs to be to get going with D.
> 
> A batteries-included version should include

<lots of good stuff deleted>

True.

Currently, the DMD zip seems to be geared towards people who already have been with us for a long time. It looks as if it's taken for granted that any essential libraries are already downloaded on your machine if you want to do any other stuff than just CLI-essentials.

The batteries-included version should be the default. (And only then, maybe, a bare-bones version also available, a la the current zip.)

---

Probably we all here are either too used to D as-is, or simply too savvy or professional to ever notice how actually *huge* the difference between bare-bones and batteries-included is for the expansion velocity of D.

---

Times change. Most of even ourselves don't anymore go to the computer store to find the box, to the next to buy the hard drive, the internet for the monitor, and to a surplus store for the floppy drive.

No, we buy the whole thing ready-made. The $100 we could save with an inordinate amount of work and running, simply isn't worth it anymore.

Today, those shopping for a new programming language don't want to do that kind of legwork either!

-- Especially when the D community (as a whole, inlcuding DM) makes it exceptionally hard for the newcomer to ever get a grasp of what is available and what is outdated and where to start looking in the first place.

Knud Sørensen wrote:
> On Sun, 15 Oct 2006 12:44:03 -0700, Walter Bright wrote:
> 
>> Jari-Matti Mäkelä wrote:
>>> Walter is a true compiler expert, but I think he wants to leave the
>>> development of libraries to those who are more experienced with
>>> different kinds of frameworks. Besides, he already has more than enough
>>> work in extending the language and maintaining the compiler.
>> What I'm mindful of is I endorsed DWT as the official D gui library, which promptly killed it.
> 
> What about the library contest I suggested long ago ?? Is that a useful idea?
> I did never get much feedback on that idea. 
> 
> http://all-technology.com/eigenpolls/dwishlist/index.php?it=59
> 

I worked at a small software company once where the marketing folks decided to have a big contest.  They advertised it software development magazines and everything.  Top prize was supposed to be like $10,000 cash I think.  In the end, when the deadline came, we counted up all the submissions.  One... two.  That's it.  We got *two* submissions. Granted, they were pretty good, but I think in the end the marketing department decided to cancel the contest and gave the two entrants free copies of our software instead.  I was pretty embarrassed for the whole company.

Anyway, this is just to say, my experience with big prize programming contests for niche software has not been good.  And no matter how cool it is, you have to admit D is still pretty niche.

--bb