Da.

We need to step up Phobos development to ten times faster than now. The current rate simply is not enough.

More comment at the end.

The quote below is only a case-in-point. (So do not comment that specific issue here -- it is being discussed in D.learn !! )

===================================

>>>> So, for instance, "c3 a4" is the UTF-8 equivalent of U+00E4, "ä".
>>>> How do I combine the former two into a single "char"?
>>>>
>>>> Say I check if the char received from getc() is greater than 127
>>>> (outside ASCII) and if it is, I store it and the following char
>>>> in two  ubytes. Now what? How do I get a char?
>>>>
>>> dchar std.utf.decode(char[],int)
>>>
>>> even if it can be quite clumsy. A hint is to use:
>>>
>>> std.utf.UTF8stride[c] to get the total number of bytes that are part
>>> of the starting token c.
>>
>> Thanks, that works. What I did was write a short function looking
>> like this:
>
> This only works for a small subset of Unicode...
>
>> dchar myGetchar(Stream s) {
>>     char c = s.getc;
>>
>>     // ASCII
>>     if (c <= 127)
>>         return c;
>>     else {
>>         // UTF-8
>>         char[] str = new char[2];
>>         str[0] = c;
>>         str[1] = s.getc;
>
>
> For a more general implementation, change the last 3 lines to:
>
>         char[6] str;
>                 str[0] = c;
>                 int n = std.utf.UTF8stride[c];
>                 if (n == 0xff)
>                         return cast(dchar)-1;; // corrupt string
>                 for (int i = 1; i < n; i++)
>                         str[i] = s.getc;
>
>>
>>         // dummy var, needed by decode
>>         size_t i = 0;
>>         return decode(str, i);
>>     }
>> }
>>
>> Using that in place of getc() pretty much does the trick.
>>
>> Unfortunately, when reading from files instead of stdin, I still run
>> into the problem of \r\n being converted to \r\r\n. I think
>> I know why, too:
>>
>> '\n' is being converted into \r\n because I'm on a Windows platform.
>> I use the following workaround:
>
>
> Yes. This is another proof that std.stream is lacking functionality.
> Because of this conversion, it is clear that std.stream isn't a binary
> stream, and as such, it ought to be either a utf-8, utf-16 or utf-32
> encoded text stream, and in those cases std.stream.getc should have a
> function returning a dchar, just as the above code.

===================================

We need more brain-cell-hours allocated to Phobos. And we need a transparent way of getting those brain cells working on Phobos.

A suggestion:

Have the Phobos API listed on the web, and let everyone be able to put their name next to any of the items.

A newsgroup (d.D.Phobos on DM, or something else on whatever other site) would be used for communication.

IMPORTANT: newbie friendly instructions on recompiling Phobos after one's changes -- simply _have_ to be available. (Unless they're newbie friendly, then the smaller/easier things never get done cause we all want to do "interesting" stuff, right?) Maybe I should even demand that Walter slightly modify Phobos files (or whatever), so that recompiling it by those new to D becomes a piece-of-cake.(**) It's the new guys who spot most of the crap we're already immune to. (Gurus too would fix things if it's easy enough.)

A Best Practice would be to post one's changes on the newsgroup for peer review. And if well received, only then send them per e-mail to Walter.

(Somehow I feel an SCC repository is unneeded here. Especially since every single change still would be incorporated by a single person (Walter), and also get more or less edited anyhow<g>.)

--------

I WANT TO KEEP THIS SIMPLE, STUPID!

So, only the NG and the API list. Nothing else!
Zero administration. Zero bureaucracy. Zero assigned tasks.
Zero chores.

We need this to be so simple that it actually _works_.

And this is NOT to substitute anything existing. Rather, an additional stream of "success and prosperity". :-D

Ah, almost forgot: the API list should allow anybody to put (and unput) themselves there, even if others are working on the same thing already. (I don't bother explaining this. I'm just telling.)

--------

(**) Going across the country for groceries never happens. Heck, you don't even do that to get laid. Equally, noticing an easy-to-fix bug doesn't make you work for two nights to get Phobos recompilable on your machine.

We want 100 people doing 5 line fixes, because we "already have 5 people doing 100 line fixes".

I totally agree!

> A Best Practice would be to post one's changes on the newsgroup for peer review. And if well received, only then send them per e-mail to Walter.

...and that's the tricky part. There's no guarantee that the fix/add-on will make it into Phobos. Not because it might not be up to some standard, but because it's likely to be overseen. A newsgroup for Phobos might be a way of fixing this.

There's another problem. I don't "get" Phobos. If there's a thought behind it, I don't get it. I read the "philosophy" on the D site, and agree with it, but Phobos still looks like a bunch of random algorithms and patterns. For this reason, I, for one, would much rather submit patches to Ares than to Phobos.

I've already posted my opinion on the whole "standard library" issue: ideally I'd like to remake the .NET framework in D. Or perhaps a transparent way of using it, as was posted before. (I've been working on a tool that uses .NET reflection to dump the .NET classes and interface in .d files, including xml-doc in DDOC format.)

Anyway, I have no doubt Phobos could grow to be a good standard library.

L.

Georg Wrede wrote:
> We need to step up Phobos development to ten times faster than now. The current rate simply is not enough.

> We need more brain-cell-hours allocated to Phobos. And we need a transparent way of getting those brain cells working on Phobos.

> IMPORTANT: newbie friendly instructions on recompiling Phobos after one's changes -- simply _have_ to be available. (Unless they're newbie friendly, then the smaller/easier things never get done cause we all want to do "interesting" stuff, right?) Maybe I should even demand that Walter slightly modify Phobos files (or whatever), so that recompiling it by those new to D becomes a piece-of-cake.(**) It's the new guys who spot most of the crap we're already immune to. (Gurus too would fix things if it's easy enough.)

That's a great, really practical suggestion.
Could someone who has successfully compiled Phobos do this please, and put it into the Wiki? I've never put the time into working out how to do it. I'm sure it's been described several times in newsgroup posts, it's probably just a matter of grabbing them together.

news://news.digitalmars.com:119/e5e96v$2779$1@digitaldaemon.com

Where in the wiki shall I put it?

L.

Lionello Lunesu skrev:
> I totally agree!
> 
<snip>
> I've already posted my opinion on the whole "standard library" issue: ideally I'd like to remake the .NET framework in D. Or perhaps a transparent way of using it, as was posted before. (I've been working on a tool that uses .NET reflection to dump the .NET classes and interface in .d files, including xml-doc in DDOC format.)
> 
If I could decide I would not base any standard library for D on .NET. .NET is way to over complicated, and object oriented  for the sake of oop (Instantiating a Point class with X and Y members is just silly when you have structs), D is way better of taking lessons from the VCL framework that comes with Borland Delphi.

VCL is smaller, uses the "what is best for each task" approach, and D's modules and class-implementation have quite allot in common with how Object Pascal does it.

// Fredrik Olsson

Lionello Lunesu wrote:
> I totally agree!
> 
>> A Best Practice would be to post one's changes on the newsgroup for peer review. And if well received, only then send them per e-mail to Walter.
> 
> 
> ...and that's the tricky part. There's no guarantee that the fix/add-on will make it into Phobos. Not because it might not be up to some standard, but because it's likely to be overseen. A newsgroup for Phobos might be a way of fixing this.
> 
> There's another problem. I don't "get" Phobos. If there's a thought behind it, I don't get it. I read the "philosophy" on the D site, and agree with it, but Phobos still looks like a bunch of random algorithms and patterns. For this reason, I, for one, would much rather submit patches to Ares than to Phobos.
> 
> I've already posted my opinion on the whole "standard library" issue: ideally I'd like to remake the .NET framework in D. Or perhaps a transparent way of using it, as was posted before. (I've been working on a tool that uses .NET reflection to dump the .NET classes and interface in .d files, including xml-doc in DDOC format.)
> 
> Anyway, I have no doubt Phobos could grow to be a good standard library.
> 
> L.

I'm willing to help with this stuff, but it's discouraging when there are 2 competing libraries (Ares and Phobos).  It feels like there is a 50% chance my efforts would be wasted.  I really wish we could merge the good things about both of them, such as going with Ares and then start merging Phobos modules into it, refactoring them as needed.

Lionello Lunesu wrote:
> news://news.digitalmars.com:119/e5e96v$2779$1@digitaldaemon.com
> 
> Where in the wiki shall I put it?
> 
> L.
I just rearranged the front page, creating a 'Contributing to D' section. HowToBuildPhobos belongs next to GdcHacking, (though I'm not sure that either really belong on the front page). The 'IdeaDiscussion' page could use some heavy refactoring, it's a pig's breakfast at the moment. For example, BestPractices belongs on the front page, I think.

In article <e6of1a$3124$1@digitaldaemon.com>, Don Clugston says...
>
>Lionello Lunesu wrote:
>> news://news.digitalmars.com:119/e5e96v$2779$1@digitaldaemon.com
>> 
>> Where in the wiki shall I put it?
>> 
>> L.
>I just rearranged the front page, creating a 'Contributing to D' section. HowToBuildPhobos belongs next to GdcHacking, (though I'm not sure that either really belong on the front page).

He can put it wherever he wants, but here's my suggestions:
HowTo/CompilePhobos
D__Tutorial/CompilingPhobos
CompilingPhobos
Phobos/Compiling

You can create a page by just typing in the URL in your browser, such as: http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/CompilePhobos

Once it has a page, we can put links to it on related pages.

>The 'IdeaDiscussion' page could use some heavy refactoring, it's a pig's >breakfast at the moment. For example, BestPractices belongs on the front page, >I think.

A lot of the pages could use some heavy refactoring.

I moved BestPractices to the front page since I think you're right.

jcc7

First of all, thanks to all the great work which is done from Walter and all the contributors on the dsource projects. I hold you all in high regard.

If I think about a D standard library, I am a bit worried about the separate developments on some projects and the slow progress of the D-libs in common. Every lib is dependent on one person. If this person goes away, the lib falls into a sleep. (see DWT, which I do not know, but the post count on the newsgroup is very low in the past)

At the moment there are
* phobos
* ares
* mango
perhaps more projects which are good for common use in a D standard library.

Wouldn't it be a very good to have them all together in one project on dsource.org? With easy write access in branches for contributors? The maintainers can then merge the changes they decide to take. Perhaps we can divide responsibility for modules or packages to more people.

I think we should take the challenge and go from the one man projects to a bigger project with many voices, more discussions, more test coverage and faster progress.

This should be no critism on any person or project, just an idea which I would wish to happen :)

Frank

> You can create a page by just typing in the URL in your browser, such as:
> http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/CompilePhobos

Done, and that exact spot!
Still, it's a silly story. I mean, the biggest difficulty is the makefile. Building Phobos would be a no-brainer if the makefile would just build out of the box.

Walter, the missing files: are they obsolete, or just not included in the dmd distribution for license issues?

L.