FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Beginnings
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
qbert



Joined: 30 Mar 2004
Posts: 209
Location: Dallas, Texas

PostPosted: Mon Sep 13, 2004 1:29 pm    Post subject: Beginnings Reply with quote

Ok!

So we got a style guide, we have our 'rudder', should we talk about how we want to organize ares ? And then start discussing the existing problems with phobos ?

The ogranizing will need to be set by the board, ill offer my 2 cents.

Since D is multi-paradigm ( procedural,OO,generic ) , i think we should layer ares so that the purists can use the language without delving into a paradigm they are not comfotable with.

Im voting the base ares library should be free functions ( static methods of class or struct is cool w/ me if it reduces import conflicts ), with an OO lib built atop, then DTL ( or some template library ).

I'm not too fond of the hybrid beast that phobos is now, and while i normally use OO, i dont think we should push it on everyone.

Thoughts ?

Charlie


OT:
I think we should add a toString(char [] ) to std.string also, i recently came across this when applying toString to some template code, and since std.string only has toString(char*), i found it was automatically converting ( dangerous! ) , and causing alot of bugs.
Back to top
View user's profile Send private message MSN Messenger
regan



Joined: 21 Jun 2004
Posts: 23

PostPosted: Mon Sep 13, 2004 3:20 pm    Post subject: Re: Beginnings Reply with quote

qbert wrote:
Ok!

So we got a style guide, we have our 'rudder', should we talk about how we want to organize ares ? And then start discussing the existing problems with phobos ?

The ogranizing will need to be set by the board, ill offer my 2 cents.

Since D is multi-paradigm ( procedural,OO,generic ) , i think we should layer ares so that the purists can use the language without delving into a paradigm they are not comfotable with.


I totally agree with the principle of this statement.

qbert wrote:

Im voting the base ares library should be free functions ( static methods of class or struct is cool w/ me if it reduces import conflicts ), with an OO lib built atop, then DTL ( or some template library ).


I worry that this decision might cause the OO lib to be in-efficient, not simply because it is in turn calling free functions (those should be optimised) but because the free function way might necessarily be less efficient due to it's nature.

For example, I work with C on a daily basis, I write my C in an OO style eg..

typedef struct foo {
..
} Foo;

Foo *foo_init(..);
void foo_free(Foo **f);

.. foo_method(Foo *f, ..);
..etc..

if I were to wrap that in a class I would go..

class CFoo {
this() {
f = foo_init(..);
}
~this() {
foo_free(&f);
}
.. method(..) {
return foo_method(f,..);
}
private:
Foo *f;
}

now, the compiler might not be able to optimise that in the same sort of way as a pure OO solution.

or perhaps I am being paranoid?

qbert wrote:

I'm not too fond of the hybrid beast that phobos is now, and while i normally use OO, i dont think we should push it on everyone.


I agree.

qbert wrote:

OT:
I think we should add a toString(char [] ) to std.string also, i recently came across this when applying toString to some template code, and since std.string only has toString(char*), i found it was automatically converting ( dangerous! ) , and causing alot of bugs.


wow, I didn't even realise that was the case.. I'm curious how it caused bugs tho, can you humour me and post an example?

Regan
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Mon Sep 13, 2004 3:26 pm    Post subject: Goals. Reply with quote

So far we have a wealth of discussion here, in the DNG and a few places on the wiki that outline the desires and wishes for an improved phobos namespace. Much more lip service has been given to the desired feature improvements as well.

Now its time to roll everything up into a strong set of goals, suitable for further discussion and assignment.

Exclamation I think the first step is to actually write up (yea, no coding, but it needs to be done) the coding standards and implementation guidelines so we have something to follow. As changes are proposed, they get added so we can all adjust accordingly. This should be placed on the wiki, and later moved to a more permanent home on an ares website (possibly here on dsource?)

Barring that one preliminary (and unfun) task, the rest is design and coding: our favorite!

Exclamation As I see it, there are several functional areas that need to be addressed:
- Core types and classes (e.g. String, Exception and others that get used everywhere else)
- DLL (library management, GC hooking, type libraries and more)
- I/O (including sockets, buffering, streams, etc)
- System (process, thread and GC)
- Containers
- Unicode
- [something else?]

The appropriate namespaces should fall out of these categories quite easily.

Question Also up for debate: should string stand on its own or be made dependent upon a container library for flexibility's sake?

Idea In response to qbert: its a cool idea, but I don't think the entire library needs to be "triple-headed" like you suggest (OO, FF and Generic). I would like to see each library coded with the highest degree of flexibility in mind rather than shoehorn a given type of library into three separate implementation paradigms. However, there are cases where we can double things up to make certain coding tasks easier like FF strings that mimic objects.

Idea Continuing on the previous idea, I think the containers portion of Ares could benefit from using template function sets that mimic the proposed solution for strings. That way, one could freely interoperate with D's arrays and the provided template mechanisms.

Thinking further down the road: After we're done deciding what areas need to be covered, we can then ask our host (Brad) to start the SVN repository so we have somewhere to host our efforts.

The implementation should follow soon thereafter, and we can sort out bugs and design issues as we go. We can always get more organized with tracking tools if the volume of messageboard traffic and emails becomes too much.

So to recap: preliminary (simple) design doc first, flesh out target library areas second, setup SVN repository third, and task implementation in certain sections fourth. Each task adds to the design doc as we go.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
qbert



Joined: 30 Mar 2004
Posts: 209
Location: Dallas, Texas

PostPosted: Mon Sep 13, 2004 3:44 pm    Post subject: Reply with quote

Quote:
For example, I work with C on a daily basis, I write my C in an OO style eg..


Hmm good call , thats what i consider good C style too. Its one of those awful tradeoff decisions that the board has to make Wink.

Quote:
wow, I didn't even realise that was the case.. I'm curious how it caused bugs tho, can you humour me and post an example?


Hmm its been a while, it was for dig-dug, can't find it.

Heres a 'not-likely-to-happen' problem though.


Code:

module foo;

import std.stream;
import std.string;

void main ()
{
        char []  x = "Like ma bell \0 got the ill communication \0";
        stdout.writeLine(toString(x));
        return;
}
Back to top
View user's profile Send private message MSN Messenger
teqdruid



Joined: 11 May 2004
Posts: 390
Location: UMD

PostPosted: Mon Sep 13, 2004 6:44 pm    Post subject: Reply with quote

Quote:
I/O (including sockets, buffering, streams, etc)

I would vote for using Mango's I/O stuff. It relies on some stuff in phobos, but not to much methinks. Perhaps someone should set up a vote for this soon.

Quote:
- Core types and classes (e.g. String, Exception and others that get used everywhere else)

-printf ? or writef?
Back to top
View user's profile Send private message Send e-mail AIM Address
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Sep 14, 2004 7:46 am    Post subject: Reply with quote

Quote:
-printf ? or writef?


Personally, I think that format/writef belongs in the IO tree and printf (and friends) should probably stay in a more legacy-oriented tree; something like "legacy.c" or "legacy.std" or "std.c".
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
teqdruid



Joined: 11 May 2004
Posts: 390
Location: UMD

PostPosted: Tue Sep 14, 2004 1:11 pm    Post subject: Reply with quote

Quote:
printf (and friends) should probably stay in a more legacy-oriented tree; something like "legacy.c" or "legacy.std" or "std.c".


Isn't having legacy and c in the same module name kinda superfluous? How about just the module name "obsolete"?

Although it is kinda useful to have printf in object like it is now... makes debugging easier.

Quote:
Personally, I think that format/writef belongs in the IO tree

I agree. Actually, I think Mango already has this.
Back to top
View user's profile Send private message Send e-mail AIM Address
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Sep 16, 2004 10:35 am    Post subject: Reply with quote

I say leave all the standard C headers in std.c and define the rest elsewhere. It would be nice to provide free functions when possible, but I don't want that to be a development requirement. I would like a small set of io functions however--at least writef/readf. This would allow folks to roll their own i/o classes without needing to follow our design if they don't want to.
Back to top
View user's profile Send private message
qbert



Joined: 30 Mar 2004
Posts: 209
Location: Dallas, Texas

PostPosted: Tue Sep 21, 2004 10:27 am    Post subject: Re: Goals. Reply with quote

pragma wrote:
So to recap: preliminary (simple) design doc first, flesh out target library areas second, setup SVN repository third, and task implementation in certain sections fourth. Each task adds to the design doc as we go.


Ok so we have Lar's design doc, should we start fleshing out ares?

pragma wrote:
Also up for debate: should string stand on its own or be made dependent upon a container library for flexibility's sake?


Hmm. I vote standalone, because we can already have free functions that act like methods on arrays, and I think D's array stuff make it great.

Question What benefit would come from making a container for it ?

Quote:
- Core types and classes (e.g. String, Exception and others that get used everywhere else)
- DLL (library management, GC hooking, type libraries and more)
- I/O (including sockets, buffering, streams, etc)
- System (process, thread and GC)
- Containers
- Unicode


These look good, should we layout the module/package heiarchy ? With a description of the modules functionailty listed under it ?
Back to top
View user's profile Send private message MSN Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Sep 21, 2004 1:56 pm    Post subject: Namespace Reply with quote

To continue the thread, I thought it might be helpful to jump forward to a more complete namespace layout. If this passes muster here, we can then divy up who does what. Smile

Current Phobos Layout (internal and typeinfo trees omitted for brevity)
Code:

crc32
gcstats
object
unittest

etc.loader
etc.c.zlib

std.array
std.asserterror
std.base64
std.boxutil
std.compiler
std.conv
std.ctype
std.date
std.dateparse
std.file
std.format
std.gc
std.intrinsic
std.loader
std.math
std.math2
std.md5
std.mmfile
std.moduleinit
std.outbuffer
std.outofmemory
std.path
std.perf
std.process
std.random
std.recls
std.regexp
std.socket
std.socketstream
std.stdarg
std.stdint
std.stdio
std.stream
std.string
std.switcherr
std.syserror
std.system
std.thread
std.unittest
std.uri
std.utf
std.zip
std.zlib

std.c.math
std.c.process
std.c.stdarg
std.c.stdio
std.c.stdlib
std.c.time
std.c.linux.linux
std.c.linux.linuxextern
std.c.windows.com
std.c.windows.windows

std.windows.iunknown
std.windows.registry



Ares Namespace (proposed refactoring of phobos)
Code:

internal.gcstats       - from phobos root
internal.unittest      - from phobos root
internal.array          - from std.array
internal.asserterror    - from std.asserterror
internal.outofmemory   - from std.outofmemory
internal.moduleinit      - from std.moduleinit
internal.typeinfo.*      - from all of std.typeinfo
internal.*            - from all of internal
internal.gc.*         - from all of internal.gc

std.util.crc32 - from crc32
std.util.recls - from std.recls
std.util.random - from std.random
std.util.perform - from std.perf
std.util.regexp - from std.regexp
std.util.md5   - from std.md5
std.util.zip   - from std.zip
std.util.zlib    - from std.zlib (also replaces etc.c.zlib)

std.library.library       - replaces std.loader (from DSP)
std.library.stub         - from DSP
std.library.libraryCache   - from DSP
std.library.all            - (all of above)

std.system.system      - from std.system
std.system.gc         - from std.gc
std.system.process      - from std.process
std.system.thread      - from std.thread
std.system.concurrent   - possibly contributed from Concurrent at dsource
std.system.error      - replaces std.syserror
std.system.path         - replaces std.path
std.system.all         - (all of above)

std.io.*   - replaces file, format, mmfile, stdio, outbuffer, socket, socketstream, uri and stream (from Mango)
std.io.all

std.type.exception
std.type.base64      - from std.base64
std.type.convert   - from std.conv (needs heavy refactoring for additional types)
std.type.ctype      - from std.ctype
std.type.datetime   - from std.date and std.dateparse
std.type.int      - from std.stdint
std.type.utf      - from std.utf
std.type.string      - from std.string (needs heavy refactoring/rewriting)
std.type.all

std.math.math      - from std.math and std.math2
std.math.all

std.object
std.compiler      - needs versioning for DigitalMars, GCD, DCC and possibly D.NET
std.intrinsic
std.stdarg
std.switcherr

std.c.math
std.c.process
std.c.stdarg
std.c.stdio
std.c.stdlib
std.c.time
std.c.linux.linux
std.c.linux.linuxextern
std.c.windows.com
std.c.windows.win32

std.windows.iunknown
std.windows.registry


A few notes:

This is a proposal, and I welcome (and want) everyone here to shoot it full of holes, tear it down and make it stronger with good feedback.

I feel that the internal tree should be something that could easily be compiled into its own library. That is, it should support the compiler's understanding of D code and remain independent of Ares/Phobos. Also this tree could be retargeted into other minimal libraries suitable for embedded programming, as they would be nice and small.

Also, this is only complete from the perspective of refactoring the current library. There is much more that can be added on top of this.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Tue Sep 21, 2004 2:17 pm    Post subject: Reply with quote

I'm to tired to think clearly, but I don't think std.ctype and std.utf is anywhere close to what is needed for internationalization. I don't know enough about what's good enough, except that the current stuff isn't good enough.
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Sep 21, 2004 2:25 pm    Post subject: Reply with quote

larsivi wrote:
I'm to tired to think clearly, but I don't think std.ctype and std.utf is anywhere close to what is needed for internationalization. I don't know enough about what's good enough, except that the current stuff isn't good enough.


I agree that many of the phobos libs are substandard... that is what this project is for anyway. Smile

When you get a chance, could you post a list of files that you think should be scrubbed from the list? Also, what addtions can you forsee?

Also, I found this on the wiki
http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout

Following this, the linux and windows parts probably shouldn't go under std.c at all since they are not really legacy interfaces. However, I don't agree with the wiki as win32 and win64 should be distinct enough to put them in different files. As it stands, MSVC is organized the same way.

Code:

std.os.linux
std.os.linuxextern
std.os.windows.win32
std.os.windows.win64
std.os.windows.com
std.os.windows.iunknown


Also I think Helmut or someone else on the wiki proposed that the win32 section of phobos be broken down into multiple files... but I haven't a clue where it is.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Tue Sep 21, 2004 4:00 pm    Post subject: Win32 Headers Reply with quote

pragma wrote:
Also I think Helmut or someone else on the wiki proposed that the win32 section of phobos be broken down into multiple files... but I haven't a clue where it is.


I think you're thinking of a couple of my replies to Helmut:
digitalmars.D:10718
digitalmars.D:10756

jcc7 wrote:
I agree with this, but I think there'd be too much code for one file (windows.d is already huge as it is). It should be split into multiple modules:

std.c.windows.commdlg
std.c.windows.ole2
std.c.windows.oleauto
std.c.windows.oleextra
std.c.windows.winbase
std.c.windows.windef
std.c.windows.wingdi
std.c.windows.winnt
std.c.windows.winuser
std.c.windows.wtypes

My basis thesis is: std.c.windows.windows is already a fairly large file (78 kb) and my guess is that it doesn't even contain 50? of the definitions that it should have. I'm basing my guess by looking at the sizes of winbase.d (114 kb), winuser (134 kb), wingdi (123 kb), winnt (134 kb), etc, in the Core32 project. There might be some wasted space in Core32, but not that much. If we keep it all in one file, it's going to get huge. Microsoft doesn't keep them all in one file, why should we?
Back to top
View user's profile Send private message AIM Address
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Tue Sep 21, 2004 4:04 pm    Post subject: Re: Namespace Reply with quote

pragma wrote:
Ares Namespace (proposed refactoring of phobos)
Code:

...
std.switcherr
The only inconsistency that I spotted is that shouldn't std.switcherr become internal.switcherr?

Looks good!
Back to top
View user's profile Send private message AIM Address
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Sep 21, 2004 5:58 pm    Post subject: Re: Namespace Reply with quote

jcc7 wrote:
pragma wrote:
Ares Namespace (proposed refactoring of phobos)
Code:

...
std.switcherr
The only inconsistency that I spotted is that shouldn't std.switcherr become internal.switcherr?

Looks good!


Thanks. So which part would you like to work on? Wink

Actually, switcherr and a few others (outofmemory for example) define both an error class as well as a handler that is linked against by the compiler (presumably).

Code:

class SwitchError : Object;
extern (C) static void _d_switch_error(char[] filename, uint line);


This makes things trickier than just moving the whole file to one source tree. In this case _d_switch_error uses the SwitchError class directly. So you're right, we need to move this to internal, but we should also throw the class definitions into std.exception for now.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group