www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos request for comments

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
What is wrong with Phobos? (this is not a rhetorical question)

In recent threads several people have mentioned phobos isn't ready for 1.0 
(myself included) so I'd like to get the issues out into the open. Some 
recent threads about std.format, std.mmfile and exceptions are the kinds of 
thing I have in mind. General comments like "it sticks" aren't useful but 
more specific comments like "foo is redundant with blah" or "std.what.ever 
has the following bug on Linux" would help narrow down the issues. Gaps in 
functionality that people feel strongly about would also be good to bring 
up.
Apr 05 2005
next sibling parent reply bobef <bobef_member pathlink.com> writes:
It is not cool at all to write std.string.toString(foo) (kinda a long name for
something that should be called atoc or something:) anytime you need to convert
foo to string. It isn't cool to wrap std.string.toString for every type it is
avalable neither...

It sucks when you import new phobos module at some point and all your previous
code won't compile anymore because of conflicts (examples std.string/std.regexp:
split,replace,etc and std.string/std.c.stdlib: atoi)

Functions/classes it provides are not sufficient. I think it should cover  least
standart c lib so we don't need calling any c api directly...

There are some functions (isfile) that chashes if file doesn't exists or some
other condition. I suppose they throw exception or something. But I think this
way: I don't like exceptions (I'm addicted to c error handling :) so when file
doesn't exists it is clear to me that isfile should return false, because
obviously the path is not file if it doesn't exists. So when if don't want to
check if path exists and I just want to know if it is file I call isfile(foo)
and I don't want it to crash. Adding try/catch complicates this simple call
unnecessary... I'm not sure if this point conflicts with D error handling
policy...

In article <d2um1i$2ld2$1 digitaldaemon.com>, Ben Hinkle says...

What is wrong with Phobos? (this is not a rhetorical question)

In recent threads several people have mentioned phobos isn't ready for 1.0 
(myself included) so I'd like to get the issues out into the open. Some 
recent threads about std.format, std.mmfile and exceptions are the kinds of 
thing I have in mind. General comments like "it sticks" aren't useful but 
more specific comments like "foo is redundant with blah" or "std.what.ever 
has the following bug on Linux" would help narrow down the issues. Gaps in 
functionality that people feel strongly about would also be good to bring 
up.
Apr 05 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"bobef" <bobef_member pathlink.com> wrote in message 
news:d2v0f8$5p$1 digitaldaemon.com...

 It is not cool at all to write std.string.toString(foo) (kinda a long name 
 for
 something that should be called atoc or something:) anytime you need to 
 convert
 foo to string. It isn't cool to wrap std.string.toString for every type it 
 is
 avalable neither...


What was std.string.toString clashing with? If it's the Object.toString the 
common technique to get the std.string.toString is to use .toString (note 
the leading "."). That technique should be put in a FAQ. It would be cool if 
we could write foo.toString when the type of foo is a builtin type as well 
as a struct or class. That would avoid D's weak overload rules.


 It sucks when you import new phobos module at some point and all your 
 previous
 code won't compile anymore because of conflicts (examples 
 std.string/std.regexp:
 split,replace,etc and std.string/std.c.stdlib: atoi)


Hmm. I agree that is annoying. And since std.string is imported so often 
these issues will come up fairly often. Maybe we could split up std.string 
into smaller pieces. It imports many modules itself.


 Functions/classes it provides are not sufficient. I think it should cover 
  least
 standart c lib so we don't need calling any c api directly...


Like what in particular would you like to see? I guess I don't mind calling 
the C api when it makes sense but looking at bringing in common functions 
would be a good idea.


 There are some functions (isfile) that chashes if file doesn't exists or 
 some
 other condition. I suppose they throw exception or something. But I think 
 this
 way: I don't like exceptions (I'm addicted to c error handling :) so when 
 file
 doesn't exists it is clear to me that isfile should return false, because
 obviously the path is not file if it doesn't exists. So when if don't want 
 to
 check if path exists and I just want to know if it is file I call 
 isfile(foo)
 and I don't want it to crash. Adding try/catch complicates this simple 
 call
 unnecessary... I'm not sure if this point conflicts with D error handling
 policy...


That seems reasonable to me. One can imagine isfile and isdir returning 
false when the target doesn't exist since indeed the target is not a file or 
directory. Otherwise you have to code it up like (exist(name) && 
isfile(name)) and that takes two GetFileAttributes/stat calls and just seems 
annoying.
Apr 05 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
I think that structure of Apache Portable Runtime
is what any practical application needs.
http://apr.apache.org/docs/apr/modules.html

APR is portable means that it includes definitions of
only "common denominator" for all supported platform.
So do Phobos.

I think that it should be two layers (rings) in the std:
a) "Phobos Core" - low level APR alike set and
b) "Phobos Mantle" - high level abstractions: classes, algorithms
    and templates.

version(Win32) { .... } version(linux) {}
shall be used only in "core" to allow to port all stuff
on various platforms easily.

IMHO of course.

Andrew.
http://terrainformatica.com
Apr 05 2005
next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d2v79t$7c7$1 digitaldaemon.com...

I think that structure of Apache Portable Runtime
 is what any practical application needs.
 http://apr.apache.org/docs/apr/modules.html

 APR is portable means that it includes definitions of
 only "common denominator" for all supported platform.
 So do Phobos.

 I think that it should be two layers (rings) in the std:
 a) "Phobos Core" - low level APR alike set and
 b) "Phobos Mantle" - high level abstractions: classes, algorithms
    and templates.


I like the planet motif :-)
Would they all live in the std package or would I as a user have to import 
std.core.blah and import std.mantle.foo?


 version(Win32) { .... } version(linux) {}
 shall be used only in "core" to allow to port all stuff
 on various platforms easily.


That would be a nice goal. We could actually enforce that by defining Core 
as those packages that have version(OS) statements. I could imagine it could 
get somewhat arbitrary, though.
Apr 05 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Andrew Fedoniouk wrote:

 I think that structure of Apache Portable Runtime
 is what any practical application needs.
 http://apr.apache.org/docs/apr/modules.html
 
 APR is portable means that it includes definitions of
 only "common denominator" for all supported platform.
 So do Phobos.
 
 I think that it should be two layers (rings) in the std:
 a) "Phobos Core" - low level APR alike set and
 b) "Phobos Mantle" - high level abstractions: classes, algorithms
     and templates.
 
 version(Win32) { .... } version(linux) {}
 shall be used only in "core" to allow to port all stuff
 on various platforms easily.
 
 IMHO of course.


I tend to agree here.
Apr 05 2005
prev sibling next sibling parent reply Dawid =?ISO-8859-2?Q?Ci=EA=BFarkiewicz?= <arael fov.pl> writes:
Ben Hinkle wrote:


 What is wrong with Phobos? (this is not a rhetorical question)
 
 In recent threads several people have mentioned phobos isn't ready for 1.0
 (myself included) so I'd like to get the issues out into the open. Some
 recent threads about std.format, std.mmfile and exceptions are the kinds
 of thing I have in mind. General comments like "it sticks" aren't useful
 but more specific comments like "foo is redundant with blah" or
 "std.what.ever has the following bug on Linux" would help narrow down the
 issues. Gaps in functionality that people feel strongly about would also
 be good to bring up.


One naming convention, please.
isalpha() but toString() ?! IMHO Second should be used everywhere .

Remove all kinds of printf/writef using ("%i", ...) and such.

Whole Phobos looks like being only mixed C bindings and few additional
classes. For me overall impression is terrible. Sorry to say so - but I
would gladly see another Phobos - new, totally rewritten, better
documented, where C bindings would be only delivered for convenience.

There are parts of Phobos that I used without bigger problems: Sockets,
Threads. But writing to files for example was one big misunderstanding.
Those read()s and write()s for internal use only ... - are they really
necessary?

Printing in C++ was like:
file << intVar << " some text " << stringVar << floatVar;

in Phobos ... I still don't know good way. Documentation need to be improved
- I don't from where I discovered information about std.stream.stdout . And
more examples would be bless.

I strongly agree with Andrew Fedoniouk: Phobos should be splited in two
parts: high and low level. And one day there must be some kind of STL.

Regards,
-- 
Dawid Ciężarkiewicz | arael
jid: arael fov.pl
Apr 06 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Dawid Ciężarkiewicz" <arael fov.pl> wrote in message 
news:d3188i$2o5p$1 digitaldaemon.com...

 Ben Hinkle wrote:


 What is wrong with Phobos? (this is not a rhetorical question)

 In recent threads several people have mentioned phobos isn't ready for 
 1.0
 (myself included) so I'd like to get the issues out into the open. Some
 recent threads about std.format, std.mmfile and exceptions are the kinds
 of thing I have in mind. General comments like "it sticks" aren't useful
 but more specific comments like "foo is redundant with blah" or
 "std.what.ever has the following bug on Linux" would help narrow down the
 issues. Gaps in functionality that people feel strongly about would also
 be good to bring up.


 One naming convention, please.
 isalpha() but toString() ?! IMHO Second should be used everywhere .


good point.


 Remove all kinds of printf/writef using ("%i", ...) and such.


Where are these? I'm not sure which printf/writef you are referring to. Do 
you mean the various commented-out and/or verion'ed-out debugging printfs?


 Whole Phobos looks like being only mixed C bindings and few additional
 classes. For me overall impression is terrible. Sorry to say so - but I
 would gladly see another Phobos - new, totally rewritten, better
 documented, where C bindings would be only delivered for convenience.

 There are parts of Phobos that I used without bigger problems: Sockets,
 Threads. But writing to files for example was one big misunderstanding.
 Those read()s and write()s for internal use only ... - are they really
 necessary?


Which read/writes are you referring to? Some in std.file or std.stream?


 Printing in C++ was like:
 file << intVar << " some text " << stringVar << floatVar;
 in Phobos ... I still don't know good way.


If file is a Stream then I'd try something like
 file.writef(intVar," some text ", stringVar, floatVar);
or possibly if stringVar can contain % symbols you might need to do
 file.writef(intVar," some text %s", stringVar, floatVar);


 Documentation need to be improved
 - I don't from where I discovered information about std.stream.stdout . 
 And
 more examples would be bless.


Agreed. The documentation is a reference document and has next to zero 
examples. We need either decent tutorials or just introductory explanations 
about what is in each module.


 I strongly agree with Andrew Fedoniouk: Phobos should be splited in two
 parts: high and low level. And one day there must be some kind of STL.

 Regards,
 -- 
 Dawid Ciężarkiewicz | arael
 jid: arael fov.pl
Apr 06 2005
parent reply Dawid =?ISO-8859-2?Q?Ci=EA=BFarkiewicz?= <arael fov.pl> writes:
Ben Hinkle wrote:

 Remove all kinds of printf/writef using ("%i", ...) and such.


 
 Where are these? I'm not sure which printf/writef you are referring to. Do
 you mean the various commented-out and/or verion'ed-out debugging printfs?


No, no. I'm not talking about how is Phobos implemented. That is non of my
business. :D I'm talking about "from end-user-developer point of view". And
such user shouldn't have to look at standard library code.

I mean that Object has static int printf(char* format, ...); member. That
here http://www.digitalmars.com/d/phobos.html  printf still seems to be
default and advised to use way of printing.


 Whole Phobos looks like being only mixed C bindings and few additional
 classes. For me overall impression is terrible. Sorry to say so - but I
 would gladly see another Phobos - new, totally rewritten, better
 documented, where C bindings would be only delivered for convenience.

 There are parts of Phobos that I used without bigger problems: Sockets,
 Threads. But writing to files for example was one big misunderstanding.
 Those read()s and write()s for internal use only ... - are they really
 necessary?


 
 Which read/writes are you referring to? Some in std.file or std.stream?


http://www.digitalmars.com/d/phobos.html sections: "std.outbuffer" and
"std.stream". I can't see way to easily read float or int from text file,
but there are tons of functions that are rather to low level for common
user. Hiding them in documentation that makes first impression may be a
good idea. Of course they should be described in deeper documentation.

Any:
int i,j;
file.scan(i).scan(j);
?

Maybe it's only fault of bad and outdated documentation, but good impression
is worthless even in computer world. :) 


 Printing in C++ was like:
 file << intVar << " some text " << stringVar << floatVar;
 in Phobos ... I still don't know good way.


 
 If file is a Stream then I'd try something like
  file.writef(intVar," some text ", stringVar, floatVar);
 or possibly if stringVar can contain % symbols you might need to do
  file.writef(intVar," some text %s", stringVar, floatVar);


I like that. Thanks.


Another thoughts:
std.time:
d_time begs for being a class. Almost every function takes as a first arg.
d_time t. And the name: d_time reminds me t_size and such ugliness from C. 

std.date:
begs for being a class

std.file:
begs for being a class. And is realized as a class in std.stream. Why to
have both? Some aspects of std.file like isdir() should be moved into class
File and some - like mkdir() - to hmm... std.system or std.filesystem?

std.conv:
Can't this module be merged with std.string ?

etc. etc. etc.

I may be wrong in some aspects, but Phobos need more "class" keyword and lot
of rearanging to make it look like one, monolyth and Object Orinted
standard runtime library.
-- 
Dawid Ciężarkiewicz | arael
jid: arael fov.pl
Apr 06 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 Another thoughts:
 std.time:
 d_time begs for being a class. Almost every function takes as a first arg.
 d_time t. And the name: d_time reminds me t_size and such ugliness from C.


Do you mean std.c.time? That's the C API so there isn't much we can do about 
it. I suppose we can have a std.time with another API if it is significantly 
better.


 std.date:
 begs for being a class


Probably a struct would be better IMO. That way we could reduce naming 
clashes while keeping value/lightweight semantics. With opAdd and other 
arithmetic overloads the usefulness of aliasing d_time with long can be 
preserved. The functions should at least have a consistent naming scheme. 
Half the functions in std.date are CamelCaseWithFirstCaps and half are 
camelCaseWithFirstLower. Plus it looks like lots of the public functions in 
there aren't documented.


 std.file:
 begs for being a class. And is realized as a class in std.stream. Why to
 have both? Some aspects of std.file like isdir() should be moved into 
 class
 File and some - like mkdir() - to hmm... std.system or std.filesystem?

 std.conv:
 Can't this module be merged with std.string ?

 etc. etc. etc.


Reasonable ideas.


 I may be wrong in some aspects, but Phobos need more "class" keyword and 
 lot
 of rearanging to make it look like one, monolyth and Object Orinted
 standard runtime library.


The more suggestions the better!


 -- 
 Dawid Ciężarkiewicz | arael
 jid: arael fov.pl
Apr 06 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 std.date:
 begs for being a class


 Probably a struct would be better IMO.


Heavens to Betsy - there's a Date struct in std.date already but it isn't 
documented and barely has any member functions at all. It seems like a good 
candidate for improvements and/or replacing d_time. One issue is that the 
existing Date is broken down into days, minutes, etc while d_time is a 
single long. I haven't thought about ways to reconcile those two. Plus 
another wrinkle is that std.dateparse is involved. Anyway, I tend to agree 
std.date could use some refactoring and/or documentation.
Apr 06 2005
prev sibling next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 06 Apr 2005 23:34:08 +0200, Dawid Ciężarkiewicz <arael fov.pl>  
wrote:

 Another thoughts:
 std.time:
 d_time begs for being a class. Almost every function takes as a first  
 arg.
 d_time t. And the name: d_time reminds me t_size and such ugliness from  
 C.


Agreed.


 std.date:
 begs for being a class


Agreed.


 std.file:
 begs for being a class. And is realized as a class in std.stream. Why to
 have both? Some aspects of std.file like isdir() should be moved into  
 class
 File and some - like mkdir() - to hmm... std.system or std.filesystem?


Agreed.


 std.conv:
 Can't this module be merged with std.string ?


Agree and Disagree. I think std.string should be split into modules  
focusing on certain tasks. "string" is a big area. Smaller modules focused  
on specific parts and a top module that imports the lot would be how I'd  
like it done.

So std.conv might be std.string.conv and focus on conversion to/from  
strings.

or alternately,
std.conv.string might handle conversions 'to' string
std.conv.int might handle conversions 'to' int
..etc..

The problem being "import std.conv;" won't get the lot, and re-opens the  
debate about this and how best to get "the lot" eg.

import std.conv.all;

--std\conv\all.d]--
import std.conv.a
import std.conv.b
..etc..


 I may be wrong in some aspects, but Phobos need more "class" keyword and  
 lot
 of rearanging to make it look like one, monolyth and Object Orinted
 standard runtime library.


The problem being while I agree with you, I am happy with a mix of OO and  
non-OO, where OO is used where appropriate, "begs for being a class", (as  
in std.time, d_time, etc).

Others want to be "pure OO" (Ant for example) or "pure non-OO" (no names  
spring to mind) and therefore phobos needs to be able to achieve all  
things in both paradigms.

Of course we want to avoid duplicating code/functionality, all that does  
is duplicate bugs and/or create inconsistency between the implementations.

So, where possible I think the OO should be built on the non-OO (provided  
no penalties are incurred) as it's generally agreed that doing it the  
other way round would bring performance penalties to non-OO.

This makes sense right down to the system compatibility layer, which is  
generally implemented in non-OO functions.

It may even be beneficial to emphasize the split in the library, eg.

std.oo.<etc>  <- OO
std.??.<etc>  <- non-OO
or
std.<etc>  <- non-OO

So, std.date would contain non-OO versions doing all the "hard-work" and  
std.oo.date would contain a class that imported and wrapped std.date.

Regan
Apr 06 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Dawid Ciężarkiewicz" <arael fov.pl> wrote in message
news:d31kkg$6mh$1 digitaldaemon.com...

 std.file:
 begs for being a class.


You make some good comments. But this one I have to disagree with. At one
point it was a class, but there seemed to be no point. For example, if I
want to read a file "foo":

    void[] buf = std.file.read("foo");

and I'm done. What purpose would a class provide?
Apr 06 2005
parent Dawid =?ISO-8859-2?Q?Ci=EA=BFarkiewicz?= <arael fov.pl> writes:
Walter wrote:


 
 "Dawid Ciężarkiewicz" <arael fov.pl> wrote in message
 news:d31kkg$6mh$1 digitaldaemon.com...

 std.file:
 begs for being a class.


 
 You make some good comments. But this one I have to disagree with. At one
 point it was a class, but there seemed to be no point. For example, if I
 want to read a file "foo":
 
     void[] buf = std.file.read("foo");
 
 and I'm done. What purpose would a class provide?


Maybe making (static?) member would lead to having both features: having all
functionality in one place (one class) and convenience.

Something like:
 void[] buf = File.MakeArrayFromFile("foo");
or: 
 void[] buf = (new File("foo")).convertToArray();
or:
 just rearranging current modules to have whole "file functionality" in one
place.

I'm just telling what's wrong IMHO - it's much easier than tell what to do
to make things better. :)
-- 
Dawid Ciężarkiewicz | arael
jid: arael fov.pl
Apr 07 2005
prev sibling next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 What is wrong with Phobos? (this is not a rhetorical question)


Something that has always seemed wierd to me is Thread.getThis(). The 
function returns the current thread as a Thread object. The name "getThis" 
seems like a joke - where I come from the phrase "get this" is used to set 
up a punch line in a joke. A better name would be either currentThread() or 
getCurrentThread() and I'd prefer if it wasn't static in Thread since it is 
unlikely to clash and is more readable without the leading Thread prefix. So 
for example today one would write
  Thread t = Thread.getThis();
and I'd prefer something like
  Thread t = getCurrentThread();
Apr 06 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


 What is wrong with Phobos? (this is not a rhetorical question)


MISSING FEATURES

- Phobos doesn't pass with warnings enabled (-Wall -Werror / -w)

- Some parts of the C99 standard library could still be missing ?

- There is no automatically generated documentation, like Doxygen
   (such documentation would also be up-to-date with the sources...)

- There should be three sub-libraries: RunTime, GC, and Phobos
   (or five, if zlib and recls should still be included as well)

- The Phobos documentation is not open nor free (a license issue)

BUILD ISSUES

- There is no .tar.gz version of DMD/Phobos with UNIX line-endings

- The Makefile for Linux (linux.mak) lacks a "make install" target

- The Makefile uses "make" instead of "$(MAKE)" and "$(MAKEFLAGS)"

- There is no "contracts-enabled" version of Phobos, for debugging

BUGS

- Object print/printf has already been beaten to death and patched,
   so I'm not sure that's an issue anymore (but it's still in DMD's ?)

- stdio only does output, and readf/unformat are broken due to lack
   of TypeInfo classes for pointers (i.e. the Mangle hack doesn't work)

- crc32.d / module crc should most likely be in std.crc32, or something

- std.system and std.compiler are not being used (Win NT 4.0 / DMD 0.0)

- std.loader is not very good, and was not even included in libphobos.a

LIMITATIONS

- Phobos is split on operating system (OS) instead of interface (API)
   This makes for a lot of redundancy on the various "Posix" platforms

- DMD Phobos does not recognize platforms other than X86/X86_64, even
   though the GDC Phobos does ? (this also affects the DMD front-end)

- There should be as few differences as possible between the Phobos
   from DMD and the Phobos from GDC, since they use version() anyway ?

- A few files still have licensing issues, see other thread here...
   There is no one single summary of the various copyright holders:

   Copyright (C) 2004-2005 by Digital Mars, www.digitalmars.com
   Copyright (C) 2004 Christopher E. Miller
   Copyright (c) 2001, 2002 Pavel "EvilOne" Minayev

   Copyright (C) 1991-1992, RSA Data Security, Inc. (md5)
   Copyright (C) 1995-2003 Jean-loup Gailly and Mark Adler (zlib)
   Copyright (C) 2002-2004, Synesis Software Pty Ltd. (recls)

EXTERNAL LIBS (etc.c)

- zlib is outdated (1.2.1, versus 1.2.2)
   Should offer a possibility to use the system zlib library instead ?

- etc.c.zlib (zlib.h translation) should be in std.c.zlib

- recls is outdated (1.2.1, versus 1.6.1)
   Maybe the C/C++ implementation of recls is better offered standalone ?

- std.recls's inline "extern(C)" could be in std.c.recls

CONTROVERSY

- "There is too much C stdlib in Phobos"

- "There is too little C++ STL in Phobos"

- "Phobos is not object-oriented enough"

- "The name Phobos is silly for a library"

- "Any changes to Phobos take too long"

- "Too centralized a development model"


Of course, some of my own comments are controversial too of course. :-)

I'm sure there are others, too ? I'm more worried about "bugs" in the
D language specification and in the D reference compiler. As it is now,
those either stop or complicate the development of D standard library ?

Did I mention the lack of a timetable or a roadmap, until a "release" ?
(a problem that it shares with the D language, and the D compiler too)
There is still quite a few organization problems with the D development.

But I thank Walter Bright for creating D, and making it Free Software.

--anders
Apr 07 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d32vm6$1m62$1 digitaldaemon.com...

 Ben Hinkle wrote:


 What is wrong with Phobos? (this is not a rhetorical question)


 MISSING FEATURES

 - Phobos doesn't pass with warnings enabled (-Wall -Werror / -w)


I imagine it fails on int-to-bit conversions and the like?


 - Some parts of the C99 standard library could still be missing ?


Did you have something particular in mind?


 - There is no automatically generated documentation, like Doxygen
   (such documentation would also be up-to-date with the sources...)


It would be nice I suppose - but personally I rather get the API and 
behavior "right" first.


 - There should be three sub-libraries: RunTime, GC, and Phobos
   (or five, if zlib and recls should still be included as well)


Do you mean three put together into phobos.lib/libphobos.a or do you mean 
three libraries? If you mean the former then it already is pretty much the 
case since the gc is in internal/gc/dmgc.lib. Plus I'm not sure what exactly 
distinguishes the RunTime from Phobos since Phobos is "the run-time 
library". Do you mean just the absolute bare minimum to compile void 
main(){}?


 - The Phobos documentation is not open nor free (a license issue)


ok


 BUILD ISSUES

 - There is no .tar.gz version of DMD/Phobos with UNIX line-endings


Doesn't your editor figure this out? Which editor do you use?


 - The Makefile for Linux (linux.mak) lacks a "make install" target


True that would be nice so that you don't have to copy libphobos.a by hand.


 - The Makefile uses "make" instead of "$(MAKE)" and "$(MAKEFLAGS)"

 - There is no "contracts-enabled" version of Phobos, for debugging


This would be nice - any template in Phobos instantiated in user code with 
debugging turned on needs debugging in phobos turned on. So right now to use 
and debug TArrayStream in user code they have to first recompile phobos.


 BUGS

 - Object print/printf has already been beaten to death and patched,
   so I'm not sure that's an issue anymore (but it's still in DMD's ?)


When I was looking at the Exceptions/Errors I noticed that Object.print is 
used in dmain2 to print any uncaught exceptions to stdout before exiting. 
The only case I could think of where it be dangerous to replace print() with 
using toString()  was in outofmemory.d since toString would have to return a 
string and we'd have to be careful we don't use any memory. The answer there 
is that OutOfMemoryException (which currently is called OutOfMemory but 
that's another story) can return a string literal. So, anyway, I agree that 
uses of print() should be replaced with printf() and toString().


 - stdio only does output, and readf/unformat are broken due to lack
   of TypeInfo classes for pointers (i.e. the Mangle hack doesn't work)

 - crc32.d / module crc should most likely be in std.crc32, or something


ok


 - std.system and std.compiler are not being used (Win NT 4.0 / DMD 0.0)


What do you mean by "not being used"? I assume you mean the version info. 
The Endian stuff in std.system is useful. I agree the std.compiler 
hard-coding the list of compilers into enums is not scalable at all - and it 
isn't even up to date :-)


 - std.loader is not very good, and was not even included in libphobos.a

 LIMITATIONS

 - Phobos is split on operating system (OS) instead of interface (API)
   This makes for a lot of redundancy on the various "Posix" platforms

 - DMD Phobos does not recognize platforms other than X86/X86_64, even
   though the GDC Phobos does ? (this also affects the DMD front-end)

 - There should be as few differences as possible between the Phobos
   from DMD and the Phobos from GDC, since they use version() anyway ?

 - A few files still have licensing issues, see other thread here...
   There is no one single summary of the various copyright holders:

   Copyright (C) 2004-2005 by Digital Mars, www.digitalmars.com
   Copyright (C) 2004 Christopher E. Miller
   Copyright (c) 2001, 2002 Pavel "EvilOne" Minayev

   Copyright (C) 1991-1992, RSA Data Security, Inc. (md5)
   Copyright (C) 1995-2003 Jean-loup Gailly and Mark Adler (zlib)
   Copyright (C) 2002-2004, Synesis Software Pty Ltd. (recls)


good stuff. The copyright issues would be good to unify.


 EXTERNAL LIBS (etc.c)

 - zlib is outdated (1.2.1, versus 1.2.2)
   Should offer a possibility to use the system zlib library instead ?

 - etc.c.zlib (zlib.h translation) should be in std.c.zlib

 - recls is outdated (1.2.1, versus 1.6.1)
   Maybe the C/C++ implementation of recls is better offered standalone ?

 - std.recls's inline "extern(C)" could be in std.c.recls

 CONTROVERSY

 - "There is too much C stdlib in Phobos"

 - "There is too little C++ STL in Phobos"

 - "Phobos is not object-oriented enough"

 - "The name Phobos is silly for a library"


Is "phobos" a pointer to a bunch of hobos? :-)


 - "Any changes to Phobos take too long"


I haven't had problems changing std.stream but then I haven't been making 
serious backwards-incompatible changes. I know other changes have either not 
happened or been promised but not appeared. I don't know the details but I 
hope those were due to process problems between Walter and the submitter 
and/or a mismatch of expectations about the focus of Walter's efforts the 
past year or more.


 - "Too centralized a development model"


I'm not that convinced there's been a sustained and public effort by people 
to fix issues in phobos. I'm hoping that by getting the process down we can 
send Walter solid, vetted changes that get in easily.
Knowing if Walter is willing to accept changes to phobos generally along the 
lines in this and other threads would help.


 Of course, some of my own comments are controversial too of course. :-)

 I'm sure there are others, too ? I'm more worried about "bugs" in the
 D language specification and in the D reference compiler. As it is now,
 those either stop or complicate the development of D standard library ?


really? I'm not aware of any bugs that have stopped phobos changes.


 Did I mention the lack of a timetable or a roadmap, until a "release" ?
 (a problem that it shares with the D language, and the D compiler too)
 There is still quite a few organization problems with the D development.


It would make life easier knowing what to expect. It's impossible to tell 
what will come in the next release or the 1.0 release.


 But I thank Walter Bright for creating D, and making it Free Software.


absolutely.


 --anders
Apr 07 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


- Phobos doesn't pass with warnings enabled (-Wall -Werror / -w)


 
 I imagine it fails on int-to-bit conversions and the like?


Yeah, and int calculations to bytes - stuff like that...
(The C warnings are just one: pthread_mutexattr_settype)

I fixed all warnings for DMD 0.118, but since none of
it wen't into DMD 0.120 I won't bother doing so again.


- Some parts of the C99 standard library could still be missing ?


 
 Did you have something particular in mind?


I will run a new diff against Sean Kelly's version, but there was some ?

http://home.f4.ca/sean/d/stdc.zip (haven't checked against DMD recently)


 Do you mean three put together into phobos.lib/libphobos.a or do you mean 
 three libraries? If you mean the former then it already is pretty much the 
 case since the gc is in internal/gc/dmgc.lib. Plus I'm not sure what exactly 
 distinguishes the RunTime from Phobos since Phobos is "the run-time 
 library". Do you mean just the absolute bare minimum to compile void 
 main(){}?


Yes, I meant just like it is being done in the Ares project actually:

http://www.dsource.org/forums/viewtopic.php?t=459


- There is no .tar.gz version of DMD/Phobos with UNIX line-endings


 
 Doesn't your editor figure this out? Which editor do you use?


It does, but I still get an extra meg of Windows cruft with the zip
download and I can't use any automated tools like "patch" and "diff" ?

I've done a small shell script to convert dmd.120.zip into 
dmd-0.120.tar.gz, but it would be simpler if Walter ran it...


- The Makefile for Linux (linux.mak) lacks a "make install" target


 
 True that would be nice so that you don't have to copy libphobos.a by hand.


Installing the library is simple, I meant all the import modules...

(cd dmd/src/phobos; find -name '*.d' | grep -v internal | xargs tar c) |
        (cd $RPM_BUILD_ROOT%{phobosdir}; tar xv)


- There is no "contracts-enabled" version of Phobos, for debugging


 
 This would be nice - any template in Phobos instantiated in user code with 
 debugging turned on needs debugging in phobos turned on. So right now to use 
 and debug TArrayStream in user code they have to first recompile phobos.


Actually, it needs "release turned off", to get the contracts.
Since "debugging turned on" is something else, it's a version...


- std.system and std.compiler are not being used (Win NT 4.0 / DMD 0.0)


 
 What do you mean by "not being used"? I assume you mean the version info. 
 The Endian stuff in std.system is useful. I agree the std.compiler 
 hard-coding the list of compilers into enums is not scalable at all - and it 
 isn't even up to date :-)


That's what I meant: "not up to date". The Endian enum is trivial...


I'm sure there are others, too ? I'm more worried about "bugs" in the
D language specification and in the D reference compiler. As it is now,
those either stop or complicate the development of D standard library ?


 
 really? I'm not aware of any bugs that have stopped phobos changes.


I'm only aware of the various TypeInfo bugs myself, especially pointers.

--anders
Apr 07 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 Ben Hinkle wrote:
 

 - Phobos doesn't pass with warnings enabled (-Wall -Werror / -w)



 I imagine it fails on int-to-bit conversions and the like?


 
 
 Yeah, and int calculations to bytes - stuff like that...
 (The C warnings are just one: pthread_mutexattr_settype)
 
 I fixed all warnings for DMD 0.118, but since none of
 it wen't into DMD 0.120 I won't bother doing so again.


Hey, Anders, don't panic. I bet Walter's been busy with the compiler. I 
wouldn't be surprised if he's saved your warning fixes, and they'd 
appear as soon as he's into Phobos!
Apr 07 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 Hey, Anders, don't panic. I bet Walter's been busy with the compiler. I 
 wouldn't be surprised if he's saved your warning fixes, and they'd 
 appear as soon as he's into Phobos!


I'm not sure whether it's even a goal to have Phobos warning-free ?


The code does tend to look silly, with the cast() and everything.

	ubyte fill = cast(ubyte) (value ? 0xFF : 0);

But the workarounds for the assert and the boolean ops are the worst.

    // returns true if end of stream is reached, false otherwise
-  bit eof() { return position() == size(); }
+  bit eof() { return cast(bit) (position() == size()); }

Of course, it does catch a couple of real bugs - along with the false.

--anders
Apr 07 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 The code does tend to look silly, with the cast() and everything.
 
     ubyte fill = cast(ubyte) (value ? 0xFF : 0);


What if there was a version of malloc that fills with 0xFF instead of 
0x00? It would be handy and fast for both strings and floats.


 But the workarounds for the assert and the boolean ops are the worst.


I've given up talking about the booleans. :-)
Apr 07 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 - Object print/printf has already been beaten to death and patched,
   so I'm not sure that's an issue anymore (but it's still in DMD's ?)


More thoughts on this one. I can see why people want to remove Object.print 
but what's the printf issue? Do people want to remove the printf declaration 
in object.d?
Also, what's the patch you are referring to?
Finally, the documentation for object.d is wrong. printf is not a member 
function of the class Object (among other issues). That needs updating 
together with whatever happens to object.d
Apr 07 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


- Object print/printf has already been beaten to death and patched,
  so I'm not sure that's an issue anymore (but it's still in DMD's ?)


 
 More thoughts on this one. I can see why people want to remove Object.print 
 but what's the printf issue? Do people want to remove the printf declaration 
 in object.d?


It should be moved back to the std.c.stdio module, where it belongs...


 Also, what's the patch you are referring to?


http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170

--anders
Apr 07 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d33pun$2ord$1 digitaldaemon.com...

 Ben Hinkle wrote:


- Object print/printf has already been beaten to death and patched,
  so I'm not sure that's an issue anymore (but it's still in DMD's ?)


 More thoughts on this one. I can see why people want to remove 
 Object.print but what's the printf issue? Do people want to remove the 
 printf declaration in object.d?


 It should be moved back to the std.c.stdio module, where it belongs...


ok. It is unusual to single out a single C function for importing 
everywhere - especially if D also has writef that we are touting as an 
improved printf. But is there an argument for removing it besides 
aesthetics? I'm not arguing that isn't a good reason - I just want to know 
if it's the only reason.


 Also, what's the patch you are referring to?


 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170

 --anders


I think more than just that patch will be required to remove Object.print() 
(at least in dmd-120). Here's the result of grepping for "print(" in 
src/phobos that look like they refer to Object.print:

./internal/dmain2.d:    o.print();
./internal/object.d:    void print()
./internal/object.d:    void print()
./object.d:    void print();
./object.d:    void print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/conv.d:       debug(conv) e.print();
./std/format.d: //ti.print();
./std/loader.d:                x.print();
./std/outofmemory.d:    void print()
./std/switcherr.d:    void print()
./std/thread.d:     o.print();
./std/thread.d:     o.print();
./std/zip.d:    void print()
./std/zip.d:    void print()
Apr 07 2005
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Ben Hinkle wrote:

 "Anders F Björklund" <afb algonet.se> wrote in message 
 news:d33pun$2ord$1 digitaldaemon.com...
 

Ben Hinkle wrote:



- Object print/printf has already been beaten to death and patched,
 so I'm not sure that's an issue anymore (but it's still in DMD's ?)


More thoughts on this one. I can see why people want to remove 
Object.print but what's the printf issue? Do people want to remove the 
printf declaration in object.d?


It should be moved back to the std.c.stdio module, where it belongs...


 
 
 ok. It is unusual to single out a single C function for importing 
 everywhere - especially if D also has writef that we are touting as an 
 improved printf. But is there an argument for removing it besides 
 aesthetics? I'm not arguing that isn't a good reason - I just want to know 
 if it's the only reason.


I've had (probably just cosmetic, but anyway) name clash problems (a 
while ago now) when using a C library that had it's own printf. And I 
where using writef in the D code.

Lars Ivar Igesund
Apr 09 2005
prev sibling parent reply Niko Korhonen <niktheblak hotmail.com> writes:
Ben Hinkle wrote:

 What is wrong with Phobos? (this is not a rhetorical question)


Phobos needs a concise and throughly documented exception hierarchy. I 
currently have to grep the Phobos sources to get a list of possible 
exceptions. And even that is pretty difficult since some of the names 
end with "Exception", some with "Error" and some don't have a 
"exceptionish" name at all.

I would really like to have an exception hierarchy ripped from Java or 
.NET BCL. I particulary yearn for a standard:

   ArgumentException(char[] msg, char[] argName)

Well, actually either that or rework DbC so that:

* contracts throw an InException instead of an AssertError
   like they should

* the InException instance holds the name of the invalid argument
   and a possible description given in the assert statement as such:

   assert (x > 0, "x must be positive");

Since I'm pretty confident that that can't (won't) be done, not even for 
2.0, I just suggest including ArgumentException and friends in Phobos. 
Possibly include even a (.NET BCL'ish) Debug class with methods like

   writeLine(char[] msg);
   assert(bool condition, char[] msg);
   etc...

Oh, and I also hate std.string.toString since it clashes with 
Object.toString all the time. Rename one of them please.
Apr 08 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Niko Korhonen" <niktheblak hotmail.com> wrote in message 
news:d35fvv$1u5b$1 digitaldaemon.com...

 Ben Hinkle wrote:

 What is wrong with Phobos? (this is not a rhetorical question)


 Phobos needs a concise and throughly documented exception hierarchy. I 
 currently have to grep the Phobos sources to get a list of possible 
 exceptions. And even that is pretty difficult since some of the names end 
 with "Exception", some with "Error" and some don't have a "exceptionish" 
 name at all.

 I would really like to have an exception hierarchy ripped from Java or 
 .NET BCL. I particulary yearn for a standard:

   ArgumentException(char[] msg, char[] argName)

 Well, actually either that or rework DbC so that:

 * contracts throw an InException instead of an AssertError
   like they should

 * the InException instance holds the name of the invalid argument
   and a possible description given in the assert statement as such:

   assert (x > 0, "x must be positive");

 Since I'm pretty confident that that can't (won't) be done, not even for 
 2.0, I just suggest including ArgumentException and friends in Phobos.


Good point. Some standard exceptions would help alot. I'm not so sure about 
the DbC suggestion since contracts aren't compiled in release mode but 
presumably one would want argument checking always. I'll start a new thread 
requesting ideas for standard exceptions. I'll include ArgumentException as 
an example.


 Possibly include even a (.NET BCL'ish) Debug class with methods like

   writeLine(char[] msg);
   assert(bool condition, char[] msg);
   etc...


Sounds nice. I'm sure people have rolled their own Debug-like classes (I 
know I did for MinWin to print debug info to a log file).


 Oh, and I also hate std.string.toString since it clashes with 
 Object.toString all the time. Rename one of them please.


I think this is the second time this was suggested. It would be nice to 
rethink the names. Is the .toString solution really that bad?
Apr 08 2005