www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - STEP UP PHOBOS DEVELOPMENT 10 FOLD

reply Georg Wrede <georg.wrede nospam.org> writes:
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".
Jun 13 2006
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
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.
Jun 13 2006
next sibling parent Fredrik Olsson <peylow gmail.com> writes:
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
Jun 13 2006
prev sibling next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
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.
Jun 13 2006
prev sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
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.




I agree on that point.
 

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


Agreed.


 
 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.


Maybe Walther should say what's his vision on what should be in the scope of
Phobos.

There're different approaches possible:

1) Minimalistic C/C++ like - std lib contains only small set of necessary
things. Everything else is available through 3rd party libs.

2) Maximalistic Java/.NET like - std lib contains lots of stuff.

-- 
AKhropov
Jun 16 2006
next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Andrei Khropov wrote:

 
 There're different approaches possible:
 
 1) Minimalistic C/C++ like - std lib contains only small set of necessary
 things. Everything else is available through 3rd party libs.
 
 2) Maximalistic Java/.NET like - std lib contains lots of stuff.
 


This has always been bugging me.  What are the reasons to do a 
minimalistic lib, besides us not having to write so much stuff?
Jun 16 2006
next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 17 Jun 2006 11:18:02 +1000, Chad J  
<gamerChad _spamIsBad_gmail.com> wrote:


 Andrei Khropov wrote:

  There're different approaches possible:
  1) Minimalistic C/C++ like - std lib contains only small set of  
 necessary
 things. Everything else is available through 3rd party libs.
  2) Maximalistic Java/.NET like - std lib contains lots of stuff.


 This has always been bugging me.  What are the reasons to do a  
 minimalistic lib, besides us not having to write so much stuff?


The more you have to more you have to look after. Walter is only one  
person and doesn't command a team of maintenance staff. Even though Phobos  
is open source, it is not managed very well from a collabaration point of  
view. Each submission is still hand managed by Walter for inclusion.

-- 
Derek Parnell
Melbourne, Australia
Jun 16 2006
prev sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Chad J wrote:


 Andrei Khropov wrote:

 
 There're different approaches possible:
 
 1) Minimalistic C/C++ like - std lib contains only small set of necessary
 things. Everything else is available through 3rd party libs.
 
 2) Maximalistic Java/.NET like - std lib contains lots of stuff.
 


 
 This has always been bugging me.  What are the reasons to do a minimalistic
 lib, besides us not having to write so much stuff?


I think it's a philosophical question:

With a maximalistic lib there is usually "one true way" to write something
(DB,GUI etc.).

with C++ -like approach you are encouraged to choose among different
realizations (i.e. for GUI you may choose among wxWidgets, Gtk+, Qt, MFC ...)
but in this case code is less portable and less consistent (it's incompatible
between projects).

Most modern languages tend to use maximalistic approach.

-- 
AKhropov
Jun 17 2006
prev sibling parent Sean Fritz <Sean_member pathlink.com> writes:
In article <e6vg3s$ll4$1 digitaldaemon.com>, Andrei Khropov says...


 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.


Maybe Walther should say what's his vision on what should be in the scope of
Phobos.

There're different approaches possible:

1) Minimalistic C/C++ like - std lib contains only small set of necessary
things. Everything else is available through 3rd party libs.

2) Maximalistic Java/.NET like - std lib contains lots of stuff.


I think it's quite clear as a Java/.Net developer that extensive (perhaps
excessive) library support is a large part of the popularity.  It seems like a
good idea for new languages trying to be popular to provide similar libraries.

Sean

-- 
AKhropov
Jun 18 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
Jun 13 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
news://news.digitalmars.com:119/e5e96v$2779$1 digitaldaemon.com

Where in the wiki shall I put it?

L.
Jun 13 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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.
Jun 14 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
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
Jun 14 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
 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.
Jun 15 2006
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Lionello Lunesu wrote:

 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.


There's always the third alternative: "oops; didn't notice they were
missing" :)

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Jun 15 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:


 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.


Also, having a "make install" target would help with Linux packaging...

Currently it all have to be pieced together with cp and chmod, and then
copy all the Phobos import modules with something like a "double tar" :

     (cd dmd/src/phobos; find -name '*.d' | xargs tar c) | \
          (cd "$(DESTDIR)$(prefix)/lib/phobos"; tar xo)

All the needed commands should be in the previously offered Linux SRPMS.

--anders
Jun 15 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 Lionello Lunesu wrote:
 

 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.


 
 
 Also, having a "make install" target would help with Linux packaging...
 
 Currently it all have to be pieced together with cp and chmod, and then
 copy all the Phobos import modules with something like a "double tar" :
 
     (cd dmd/src/phobos; find -name '*.d' | xargs tar c) | \
          (cd "$(DESTDIR)$(prefix)/lib/phobos"; tar xo)
 
 All the needed commands should be in the previously offered Linux SRPMS.


What if a shell script for that was included right in the DMD.ZIP itself?
Jun 15 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 Also, having a "make install" target would help with Linux packaging...


 
 What if a shell script for that was included right in the DMD.ZIP itself?


Make install basically runs a shell script, but that was the idea yes.

Usually you do something like:
./configure && make
sudo make install

--anders
Jun 15 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 Georg Wrede wrote:
 

 Also, having a "make install" target would help with Linux packaging...



 What if a shell script for that was included right in the DMD.ZIP itself?


 
 
 Make install basically runs a shell script, but that was the idea yes.
 
 Usually you do something like:
 ./configure && make
 sudo make install


Exactly.

(My point being that Walter doesn't have the time to study shell scripts 
or makefiles, so a ready-made one should be given to him.)

Incidentally, should that script be in dmd/bin or dmd/src?
(My vote: src.)
Jun 15 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 Exactly.
 
 (My point being that Walter doesn't have the time to study shell scripts 
 or makefiles, so a ready-made one should be given to him.)


There has been several written. But Walter doesn't like ready packages ?

Partly I can understand where he is coming from on that; if the user
unpacks and installs the software themselves, they know where it went
and that it isn't doing anything "extra" - like install malware etc...

It's just that it is a hassle to type those commands, and then amplified
when wanting to upgrade or uninstall ? Thus, I prefer using RPM instead.
I could duplicate all the steps that I used, but it's in the "dmd.spec"

Not everyone uses RPM, but it's easy to adapt to a .deb or .ebuild too ?


 Incidentally, should that script be in dmd/bin or dmd/src?
 (My vote: src.)


I think it should be something like "dmd/install.sh", in that case...
(since DMD doesn't come with the complete sources to "bin", in "src")



install -d /usr/local/bin
install -p -m 0755 bin/dmd bin/obj2asm bin/dumpobj \
                   /usr/local/bin

install -d /usr/local/man/man1
install -p -m 0644 man/man1/dmd.1 man/man1/obj2asm.1 \
                    man/man1/dumpobj.1 /usr/local/man/man1

install -d /usr/local/lib
install -p -m 0644 lib/libphobos.a /usr/local/lib

install -d /usr/local/lib/phobos
(cd src/phobos; find -name '*.d' | xargs tar c) | \
                    (cd /usr/local/lib/phobos; tar xv)
cat > /etc/dmd.conf <<__EOF__
[Environment]
DFLAGS="-I/usr/local/lib/phobos"
__EOF__

Something to that effect. Would install DMD and Phobos to /usr/local ?
Where "/usr/local" should probably be written as "${DESTDIR}$prefix":

DESTDIR=
prefix=/usr/local

Or even use $(bindir) and $(libdir), and default those to use $(prefix)

bindir=$prefix/bin
libdir=$prefix/lib

Walter can use as much or as little of it as he wants, I'm doing GDC....
(no use in doing more packages for DMD, since they can't be distributed)

--anders
Jun 15 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Lionello Lunesu wrote:

 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.


None of the above.
This is just hilarious -- I wrote them!! You can download them from the 
'mathextra' project on dsource. I had no idea they were in phobos.lib, 
but it explains why I've had some really weird linking errors...

etc.gamma is actually mentioned in the docs for std.math.gamma, so it's 
clearly supposed to be included. But 'realtest.d' contains the first 
lines of D that I ever wrote (It started life as "hello world"). The 
first line of it is a comment that it's not intended to be part of a 
standard library. I'm stunned to discover that it's been in phobos all 
this time. Guess I better tidy it up.
Jun 16 2006
next sibling parent Don Clugston <dac nospam.com.au> writes:
Don Clugston wrote:

 Lionello Lunesu wrote:

 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.


 
 None of the above.
 This is just hilarious -- I wrote them!! You can download them from the 
 'mathextra' project on dsource. I had no idea they were in phobos.lib, 
 but it explains why I've had some really weird linking errors...
 
 etc.gamma is actually mentioned in the docs for std.math.gamma, so it's 
 clearly supposed to be included. But 'realtest.d' contains the first 
 lines of D that I ever wrote (It started life as "hello world"). The 
 first line of it is a comment that it's not intended to be part of a 
 standard library. I'm stunned to discover that it's been in phobos all 
 this time. Guess I better tidy it up.


I just added this issue to bugzilla. BTW, thanks for the instructions -- 
very helpful.
Jun 16 2006
prev sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
 I'm stunned to discover that it's been in phobos all this time. Guess I 
 better tidy it up.


realtest.d:
/** Helper functions for unit tests involving real numbers
 *
 * Not intended for inclusion in a standard library.
 */

LOL!

L.
Jun 17 2006
prev sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
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
Jun 14 2006
parent reply Dejan Lekic <dejan nu6.org> writes:
I can only speak in my name - I will not use any "standard" D library other
than Phobos, and my own libraries. Phobos is open-source, Mr. Bright is
very much open person, and he will incorporate any sane change into Phobos.

Kind regards

Dejan Lekic
Jun 15 2006
next sibling parent Frank Benoit <keinfarbton nospam.xyz> writes:
Dejan Lekic schrieb:

 Phobos is open-source, Mr. Bright is
 very much open person, and he will incorporate any sane change into Phobos.


Yes.

One good argument for java is its great library, which is allways
available, in every installation. A library dealing also with encodings,
file systems, xml parsing, template containers, synchronization classes,
logging and so on can only be an advantage.

Perhaps, with giving away some responsibility, Walter can get more time
for working on dmd 1.0
Jun 15 2006
prev sibling parent reply Brad Anderson <brad dsource.org> writes:
Dejan Lekic wrote:

 I can only speak in my name - I will not use any "standard" D library other
 than Phobos, and my own libraries. Phobos is open-source, Mr. Bright is
 very much open person, and he will incorporate any sane change into Phobos.


I'm going to have to disagree with you here.  Not on your choice of lib, but
on Walter's commitment to Phobos.  He has repeatedly said that his focus is on
the language spec and the DMD reference compiler, and always seeks
contributions / prods the guys who are active for the library content.  So,
while the D Language shines and the spec is solving all the C++ issues as
noted in another recent post, Phobos, well, is part of D's overall
lack-of-libraries issue.  It is interesting to note how good Phobos is, given
its place in W's priority list - probably just another testament to his skill.

Scaling D, however, will take more than just Walter, and I don't think I'd get
a lot of disagreement.  There are insane amounts of great code in Ares and
Mango which go largely unused because we haven't had the stampede yet.  These
libs speak to the skill of Sean & Kris, and all the testers/documenters
they've had hanging around their libs.  The fact that they're actively
developing those libs should be encouraging to all of us, as the chief
complaint I hear in the NG is lack of libs.

Surely Walter doing compiler/spec things and Sean/Kris doing lib dev, Derek
cranking out a new Build, {insert name here} working on a new version of
{insert project here} is better than a one-man show?  And if a new lib ever
comes around that is better/more complete than Phobos, won't you be compelled
to take it for a spin?

BA
Jun 16 2006
parent John Reimer <terminal.node gmail.com> writes:
Brad Anderson wrote:

 Dejan Lekic wrote:

 I can only speak in my name - I will not use any "standard" D library other
 than Phobos, and my own libraries. Phobos is open-source, Mr. Bright is
 very much open person, and he will incorporate any sane change into Phobos.


 
 I'm going to have to disagree with you here.  Not on your choice of lib, but
 on Walter's commitment to Phobos.  He has repeatedly said that his focus is on
 the language spec and the DMD reference compiler, and always seeks
 contributions / prods the guys who are active for the library content.  So,
 while the D Language shines and the spec is solving all the C++ issues as
 noted in another recent post, Phobos, well, is part of D's overall
 lack-of-libraries issue.  It is interesting to note how good Phobos is, given
 its place in W's priority list - probably just another testament to his skill.
 
 Scaling D, however, will take more than just Walter, and I don't think I'd get
 a lot of disagreement.  There are insane amounts of great code in Ares and
 Mango which go largely unused because we haven't had the stampede yet.  These
 libs speak to the skill of Sean & Kris, and all the testers/documenters
 they've had hanging around their libs.  The fact that they're actively
 developing those libs should be encouraging to all of us, as the chief
 complaint I hear in the NG is lack of libs.
 
 Surely Walter doing compiler/spec things and Sean/Kris doing lib dev, Derek
 cranking out a new Build, {insert name here} working on a new version of
 {insert project here} is better than a one-man show?  And if a new lib ever
 comes around that is better/more complete than Phobos, won't you be compelled
 to take it for a spin?
 
 BA



Well said!

-JJR
Jun 16 2006