www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Phobos is now on dsource

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.dsource.org/projects/phobos

Thanks to Brad Roberts for doing the organizational work, and Brad 
Anderson for hosting.
Nov 26 2007
next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
On Mon, 26 Nov 2007 00:16:43 -0800
Walter Bright <newshound1 digitalmars.com> wrote:


 
 http://www.dsource.org/projects/phobos
 
 Thanks to Brad Roberts for doing the organizational work, and Brad 
 Anderson for hosting.


Now that it's on dsource, maybe you should try and make use of Trac's
features? Like milestones'n tickets and such. I suppose this would help
monitoring the progress of Phobos and also make future plans more
transparent to non-developers.

Anyways: good to see this change! This lets dsource stand in a very
bright light as the hoster of the standard runtime library
repository.. great! :)

-- 
Alexander Panek <alexander.panek brainsware.org>
Nov 26 2007
parent reply Brad Roberts <braddr puremagic.com> writes:
On Mon, 26 Nov 2007, Alexander Panek wrote:


 On Mon, 26 Nov 2007 00:16:43 -0800
 Walter Bright <newshound1 digitalmars.com> wrote:
 

 
 http://www.dsource.org/projects/phobos
 
 Thanks to Brad Roberts for doing the organizational work, and Brad 
 Anderson for hosting.


 
 Now that it's on dsource, maybe you should try and make use of Trac's
 features? Like milestones'n tickets and such. I suppose this would help
 monitoring the progress of Phobos and also make future plans more
 transparent to non-developers.


For the short term (and quite possibly long term), I don't expect to use 
dsource for much more than it's svn repository.  There's already the d 
bugzilla instance which is doing a perfectly good job.  The wiki nodes at 
wiki4d are also doing a decent enough job, though if there's sufficient 
demand I can see moving them to dsource.


 Anyways: good to see this change! This lets dsource stand in a very
 bright light as the hoster of the standard runtime library
 repository.. great! :)


Next stop, DMD.  One day Walter will submit to my will! <ahem, sorry, got 
carried away there a bit>

Later,
Brad
Nov 26 2007
next sibling parent reply Alexander Panek <alexander.panek lomography.com> writes:
On Mon, 26 Nov 2007 11:07:40 -0800 (PST)
Brad Roberts <braddr puremagic.com> wrote:


 For the short term (and quite possibly long term), I don't expect to
 use dsource for much more than it's svn repository.  There's already
 the d bugzilla instance which is doing a perfectly good job. 


Fair enough, but Trac is way easier to use than bugzilla. And, the
probably more weighing point: it interfaces with the underlying source
control in such a way that tickets can be associated to changesets and
revisions. I think this is one very big advantage over bugzilla. That
way it would even be possible to submit patches in tickets and see
how they've been applied, etc.

That said: Tango uses Trac's ticketing system extensively and I suppose
without it, it would be a Big Ball of Mud to organize.


 The wiki nodes at 
 wiki4d are also doing a decent enough job, though if there's
 sufficient demand I can see moving them to dsource.


I agree. (read as: "me too")


 Next stop, DMD.  One day Walter will submit to my will! <ahem, sorry,
 got carried away there a bit>


Haha - sounds good to me. Tell us when you have an initial import!

--
Alexander Panek <alexander.panek brainsware.org>
Nov 26 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Alexander Panek wrote:

 On Mon, 26 Nov 2007 11:07:40 -0800 (PST)
 Brad Roberts <braddr puremagic.com> wrote:
 

 For the short term (and quite possibly long term), I don't expect to
 use dsource for much more than it's svn repository.  There's already
 the d bugzilla instance which is doing a perfectly good job. 


 
 Fair enough, but Trac is way easier to use than bugzilla. And, the
 probably more weighing point: it interfaces with the underlying source
 control in such a way that tickets can be associated to changesets and
 revisions. I think this is one very big advantage over bugzilla. That
 way it would even be possible to submit patches in tickets and see
 how they've been applied, etc.


That may be, but you have to weigh that benefit against the cost of 
having the bug database split across two trackers and/or migrating all 
the existing bugzilla entries over to trac.

--bb
Nov 26 2007
parent reply Brad Anderson <brad dsource.org> writes:
Bill Baxter wrote:

 Alexander Panek wrote:

 On Mon, 26 Nov 2007 11:07:40 -0800 (PST)
 Brad Roberts <braddr puremagic.com> wrote:


 For the short term (and quite possibly long term), I don't expect to
 use dsource for much more than it's svn repository.  There's already
 the d bugzilla instance which is doing a perfectly good job. 


 Fair enough, but Trac is way easier to use than bugzilla. And, the
 probably more weighing point: it interfaces with the underlying source
 control in such a way that tickets can be associated to changesets and
 revisions. I think this is one very big advantage over bugzilla. That
 way it would even be possible to submit patches in tickets and see
 how they've been applied, etc.


 
 That may be, but you have to weigh that benefit against the cost of 
 having the bug database split across two trackers and/or migrating all 
 the existing bugzilla entries over to trac.
 
 --bb




Let me know if you would like to run this script on the existing BZ 
database and port existing bugs over.  It isn't quite that simple, of 
course, but I've done it at a previous job.

Also, I'm sure we could work something out as far as NG notifications.

All of this being said, I would rather use my time in Dec, Jan, which is 
historically very active DSource work, for completing the new version of 
the site in general, as I discussed at the conference.  Plus, finishing 
off Mercurial support (we are very close), and adding git support.

Cheers,
BA
Dec 01 2007
parent Brad Roberts <braddr puremagic.com> writes:
Brad Anderson wrote:

 Bill Baxter wrote:

 Alexander Panek wrote:

 On Mon, 26 Nov 2007 11:07:40 -0800 (PST)
 Brad Roberts <braddr puremagic.com> wrote:


 For the short term (and quite possibly long term), I don't expect to
 use dsource for much more than it's svn repository.  There's already
 the d bugzilla instance which is doing a perfectly good job. 


 Fair enough, but Trac is way easier to use than bugzilla. And, the
 probably more weighing point: it interfaces with the underlying source
 control in such a way that tickets can be associated to changesets and
 revisions. I think this is one very big advantage over bugzilla. That
 way it would even be possible to submit patches in tickets and see
 how they've been applied, etc.


 That may be, but you have to weigh that benefit against the cost of 
 having the bug database split across two trackers and/or migrating all 
 the existing bugzilla entries over to trac.

 --bb


 

 
 Let me know if you would like to run this script on the existing BZ 
 database and port existing bugs over.  It isn't quite that simple, of 
 course, but I've done it at a previous job.
 
 Also, I'm sure we could work something out as far as NG notifications.
 
 All of this being said, I would rather use my time in Dec, Jan, which is 
 historically very active DSource work, for completing the new version of 
 the site in general, as I discussed at the conference.  Plus, finishing 
 off Mercurial support (we are very close), and adding git support.
 
 Cheers,
 BA


No, please don't.  I want to continue using the existing bugzilla instance.
Dec 01 2007
prev sibling parent reply BCS <BCS pathlink.com> writes:
Alexander Panek wrote:

 On Mon, 26 Nov 2007 11:07:40 -0800 (PST)
 Brad Roberts <braddr puremagic.com> wrote:



For the short term (and quite possibly long term), I don't expect to
use dsource for much more than it's svn repository.  There's already
the d bugzilla instance which is doing a perfectly good job.



 Fair enough, but Trac is way easier to use than bugzilla. And, the
 probably more weighing point: it interfaces with the underlying source
 control in such a way that tickets can be associated to changesets and
 revisions. I think this is one very big advantage over bugzilla. That
 way it would even be possible to submit patches in tickets and see
 how they've been applied, etc.

 That said: Tango uses Trac's ticketing system extensively and I suppose
 without it, it would be a Big Ball of Mud to organize.


Does Trac's ticket system have a way to interface with the NG? I ask 
because if it doesn't then they will be effectively opaque to me. In 
other words, if they can't post updates the the NG I, and probably many 
others, will be out of the loop.

(Do not point out how easy it is to keep tabs of them on the forum or 
web page or what not. I don't use them, I'm not going to use them unless 
they can address a hole boatload of concerns. I haven't heard any 
suggestion they will.)
Nov 26 2007
parent reply Alexander Panek <alexander.panek lomography.com> writes:
On Mon, 26 Nov 2007 16:20:05 -0800
BCS <BCS pathlink.com> wrote:


 Does Trac's ticket system have a way to interface with the NG? I ask 
 because if it doesn't then they will be effectively opaque to me. In 
 other words, if they can't post updates the the NG I, and probably
 many others, will be out of the loop.


I'm not sure this would work out of the box, but I suppose there's
either a plugin, or it should be rather easy to implement this in Python
and let it run as a plugin. I suppose Brad Anderson (I hope I got the
names right this time) knows this better than me.


 (Do not point out how easy it is to keep tabs of them on the forum or 
 web page or what not. I don't use them, I'm not going to use them
 unless they can address a hole boatload of concerns. I haven't heard
 any suggestion they will.)


In any case: is this what the d.D.bugs newsgroup is about? Can you also
reply on the NG and bugzilla tracks it automatically as response in the
tracker?

--
Alexander Panek <alexander.panek brainsware.org>
Nov 26 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Alexander,


 On Mon, 26 Nov 2007 16:20:05 -0800

 In any case: is this what the d.D.bugs newsgroup is about? Can you
 also reply on the NG and bugzilla tracks it automatically as response
 in the tracker?
 


yes, but I usualy try to add the comment directly.


 --
 Alexander Panek <alexander.panek brainsware.org>
Nov 27 2007
parent Alexander Panek <alexander.panek lomography.com> writes:
On Tue, 27 Nov 2007 18:45:38 +0000 (UTC)
BCS <ao pathlink.com> wrote:


 Reply to Alexander,
 

 On Mon, 26 Nov 2007 16:20:05 -0800

 In any case: is this what the d.D.bugs newsgroup is about? Can you
 also reply on the NG and bugzilla tracks it automatically as response
 in the tracker?


 yes, but I usualy try to add the comment directly.


Aah, I see. Well, that's a killer feature, definitely. :)

--
Alexander Panek <alexander.panek brainsware.org>
Nov 27 2007
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el 26 de noviembre a las 11:07 me escribiste:

 On Mon, 26 Nov 2007, Alexander Panek wrote:
 

 On Mon, 26 Nov 2007 00:16:43 -0800
 Walter Bright <newshound1 digitalmars.com> wrote:
 

 
 http://www.dsource.org/projects/phobos
 
 Thanks to Brad Roberts for doing the organizational work, and Brad 
 Anderson for hosting.


 
 Now that it's on dsource, maybe you should try and make use of Trac's
 features? Like milestones'n tickets and such. I suppose this would help
 monitoring the progress of Phobos and also make future plans more
 transparent to non-developers.


 
 For the short term (and quite possibly long term), I don't expect to use 


Any reason to not use git[1]? At least I saw Walter posting[2] to its mailing
list, which made me thought that he were using (or planning to use) it for
internal development...

[1] http://git.or.cz/
[2] http://kerneltrap.org/mailarchive/git/2007/9/7/257355

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Relax.
I'll need some information first.
Just the basic facts.
Can you show me where it hurts?
Nov 26 2007
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On Mon, 26 Nov 2007, Leandro Lucarella wrote:


 Brad Roberts, el 26 de noviembre a las 11:07 me escribiste:

 On Mon, 26 Nov 2007, Alexander Panek wrote:
 

 On Mon, 26 Nov 2007 00:16:43 -0800
 Walter Bright <newshound1 digitalmars.com> wrote:
 

 
 http://www.dsource.org/projects/phobos
 
 Thanks to Brad Roberts for doing the organizational work, and Brad 
 Anderson for hosting.


 
 Now that it's on dsource, maybe you should try and make use of Trac's
 features? Like milestones'n tickets and such. I suppose this would help
 monitoring the progress of Phobos and also make future plans more
 transparent to non-developers.


 
 For the short term (and quite possibly long term), I don't expect to use 


 
 Any reason to not use git[1]? At least I saw Walter posting[2] to its mailing
 list, which made me thought that he were using (or planning to use) it for
 internal development...


Two reasons:

1) dsource doesn't (yet) support git and using the community standard site 
is and was important to me.

2) git comes with an even higher learning curve than svn does.  While I 
like what I see with git (been playing with and using it for various 
personal project since it's inception), it's not ready for the teeming 
masses, and by that I mean Walter.

3) Walter's post was D advertising, not him using it.

Later,
Brad
Nov 26 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Brad Roberts wrote:

 On Mon, 26 Nov 2007, Leandro Lucarella wrote:
 

 Brad Roberts, el 26 de noviembre a las 11:07 me escribiste:

 On Mon, 26 Nov 2007, Alexander Panek wrote:


 On Mon, 26 Nov 2007 00:16:43 -0800
 Walter Bright <newshound1 digitalmars.com> wrote:


 http://www.dsource.org/projects/phobos

 Thanks to Brad Roberts for doing the organizational work, and Brad 
 Anderson for hosting.


 Now that it's on dsource, maybe you should try and make use of Trac's
 features? Like milestones'n tickets and such. I suppose this would help
 monitoring the progress of Phobos and also make future plans more
 transparent to non-developers.


 For the short term (and quite possibly long term), I don't expect to use 


 Any reason to not use git[1]? At least I saw Walter posting[2] to its mailing
 list, which made me thought that he were using (or planning to use) it for
 internal development...


 
 Two reasons:
 
 1) dsource doesn't (yet) support git and using the community standard site 
 is and was important to me.
 
 2) git comes with an even higher learning curve than svn does.  While I 
 like what I see with git (been playing with and using it for various 
 personal project since it's inception), it's not ready for the teeming 
 masses, and by that I mean Walter.
 
 3) Walter's post was D advertising, not him using it.


4) git is not ready for Windows yet.  Apparently there are people 
working on making it usable, but it's definitely no where near the 
standards set by the SVN GUIs on Windows.  Monotone or Mercurial seem to 
be much better off in cross-platform support, but none of the new gen of 
scms are really up to the level of SVN or CVS yet for usability and 
ubiquity.

--bb
Nov 26 2007
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Awesome news! Who is going to maintain it, and will we have some 
roadmap? I would gladly contribute to this project myself.

Kind regards

Dejan
Nov 26 2007
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Dejan Lekic Wrote:


 
 Awesome news! Who is going to maintain it, and will we have some 
 roadmap? I would gladly contribute to this project myself.



Dare I even ask what the coding standards will be?  There's been a lot of
discussion lately about differing styles between phobos and tango.

How will casual contributions be handled?  Free repository access?  Moderated
patch submission?  If it's the latter, who will be the moderator and apply the
patches?
Nov 26 2007
next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
I assumed later at the very begining. That is why I asked who is going to
maintain the project (should have formulated my question differently, i admit).
Nov 26 2007
prev sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
Jason House wrote:

 Dejan Lekic Wrote:
 

 Awesome news! Who is going to maintain it, and will we have some 
 roadmap? I would gladly contribute to this project myself.


 
 
 Dare I even ask what the coding standards will be?  There's been a lot of
discussion lately about differing styles between phobos and tango.
 
 How will casual contributions be handled?  Free repository access?  Moderated
patch submission?  If it's the latter, who will be the moderator and apply the
patches?


I'm guessing Brad Roberts will handle the patches and the tickets.
Nov 26 2007
parent Brad Roberts <braddr puremagic.com> writes:
On Mon, 26 Nov 2007, Clay Smith wrote:


 Jason House wrote:

 Dejan Lekic Wrote:
 

 Awesome news! Who is going to maintain it, and will we have some roadmap?
 I would gladly contribute to this project myself.


 
 
 Dare I even ask what the coding standards will be?  There's been a lot of
 discussion lately about differing styles between phobos and tango.
 
 How will casual contributions be handled?  Free repository access?
 Moderated patch submission?  If it's the latter, who will be the moderator
 and apply the patches?


 
 I'm guessing Brad Roberts will handle the patches and the tickets.


I'm more of a catalyst.  I'll get some things done as I can, but I 
wouldn't call myself the new phobos owner.  Andrei has been handling 
several tickets, I've handled several, Walter's handled several.  See my 
other responses on this topic as well.

Later,
Brad
Nov 26 2007
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On Mon, 26 Nov 2007, Dejan Lekic wrote:


 Awesome news! Who is going to maintain it, and will we have some roadmap? I
 would gladly contribute to this project myself.


You could before almost as easily as now.  The best way to contribute is 
attaching patches to bugs in the standard D bugzilla instance:

   http://d.puremagic.com/issues/

As always, the more complete the patch the better.  The only difference is 
now you can get the source via svn rather than from the .zip.  The source 
and build system are exactly the same.

Later,
Brad
Nov 26 2007
parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el 26 de noviembre a las 10:37 me escribiste:

 As always, the more complete the patch the better.  The only difference is 
 now you can get the source via svn rather than from the .zip.  The source 
 and build system are exactly the same.


But know you can keep track of teh changes and follow the development.
IMHO that's a *huge* step and I'm glad you took it =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
There is no pain you are receding
A distant ship, smoke on the horizon.
You are only coming through in waves.
Your lips move but I can't hear what you're saying.
Nov 26 2007
prev sibling next sibling parent Clay Smith <clayasaurus gmail.com> writes:
Walter Bright wrote:

 
 http://www.dsource.org/projects/phobos
 
 Thanks to Brad Roberts for doing the organizational work, and Brad 
 Anderson for hosting.


I think this is a very positive step forward for Phobos.

Now, if the D community could play a more active role in Phobos 
development, then we're really on to something. :)
Nov 26 2007
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
I honestly hope Phobos will remain what it is - a simple, core library, 
and I hope it will not "evolve" into a huge framework of JAVA API, or 
.NET 2 size.

I would gladly see Phobos remain as the core, and emerging of some 
higher-level, huge library (framework) on top of it, with all modern 
features of frameworks mentioned above.

Kind regards

Dejan Lekic
Nov 26 2007
next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
On Tue, 27 Nov 2007 02:05:56 +0000
Dejan Lekic <dejan.lekic gmail.com> wrote:


 I honestly hope Phobos will remain what it is - a simple, core
 library, and I hope it will not "evolve" into a huge framework of
 JAVA API, or .NET 2 size.


I'm not sure what the cause of this "fear" is?

-- 
Alexander Panek <alexander.panek brainsware.org>
Nov 27 2007
parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Alexander Panek wrote:


 I honestly hope Phobos will remain what it is - a simple, core
 library, and I hope it will not "evolve" into a huge framework of
 JAVA API, or .NET 2 size.


 
 I'm not sure what the cause of this "fear" is?


A large standard library bulks up the language (where by "language" I
mean the actual programming language plus its standard library
facilities). Such bulk is undesirable in places where it isn't needed,
such as embedded systems or other small scale environments. Since D
wants to be a systems programming language a huge, expansive *standard*
library seems incompatible with that positioning. At least it does to me.

Of course huge, expansive add-on libraries are a good thing to have as
well. I could even imagine a two-tiered standard library (core +
additional optional components). So I agree with the OP that a
relatively small core library is nice.

Peter
Nov 27 2007
next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Tue, 27 Nov 2007 06:52:50 -0500
"Peter C. Chapin" <pchapin sover.net> wrote:


 Alexander Panek wrote:
 

 I honestly hope Phobos will remain what it is - a simple, core
 library, and I hope it will not "evolve" into a huge framework of
 JAVA API, or .NET 2 size.


 
 I'm not sure what the cause of this "fear" is?


 
 A large standard library bulks up the language (where by "language" I
 mean the actual programming language plus its standard library
 facilities). Such bulk is undesirable in places where it isn't needed,
 such as embedded systems or other small scale environments. Since D
 wants to be a systems programming language a huge, expansive
 *standard* library seems incompatible with that positioning. At least
 it does to me.


That doesn't quite answer my question, let me rephrase: why do you
think Phobos will ever be developed in that direction?

-- 
Alexander Panek <alexander.panek brainsware.org>
Nov 27 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Peter C. Chapin wrote:

 Alexander Panek wrote:
 

 I honestly hope Phobos will remain what it is - a simple, core
 library, and I hope it will not "evolve" into a huge framework of
 JAVA API, or .NET 2 size.


 I'm not sure what the cause of this "fear" is?


 
 A large standard library bulks up the language (where by "language" I
 mean the actual programming language plus its standard library
 facilities). Such bulk is undesirable in places where it isn't needed,
 such as embedded systems or other small scale environments. Since D
 wants to be a systems programming language a huge, expansive *standard*
 library seems incompatible with that positioning. At least it does to me.


Ironically, this is exactly who Tango was designed the way it is.  The 
runtime can be distributed entirely separate from the user code, and the 
user code is rarely inter-dependent either.  In my opinion, this grants 
the best of both worlds.  Embedded programmers can toss all the code 
they don't need or don't want to port, but it's still available to those 
with more modest demands.


Sean
Nov 27 2007
next sibling parent "Kris" <foo bar.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:fihf60$2m70$1 digitalmars.com...

 Peter C. Chapin wrote:

 Alexander Panek wrote:


 I honestly hope Phobos will remain what it is - a simple, core
 library, and I hope it will not "evolve" into a huge framework of
 JAVA API, or .NET 2 size.


 I'm not sure what the cause of this "fear" is?


 A large standard library bulks up the language (where by "language" I
 mean the actual programming language plus its standard library
 facilities). Such bulk is undesirable in places where it isn't needed,
 such as embedded systems or other small scale environments. Since D
 wants to be a systems programming language a huge, expansive *standard*
 library seems incompatible with that positioning. At least it does to me.


 Ironically, this is exactly who Tango was designed the way it is.  The 
 runtime can be distributed entirely separate from the user code, and the 
 user code is rarely inter-dependent either.  In my opinion, this grants 
 the best of both worlds.  Embedded programmers can toss all the code they 
 don't need or don't want to port, but it's still available to those with 
 more modest demands.


Yes indeed. It was one of the very early decisions, and guided lots of 
subsequent discussion and/or partitioning of Tango functionality :)
Nov 27 2007
prev sibling parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Sean Kelly wrote:


 Ironically, this is exactly who Tango was designed the way it is.  The
 runtime can be distributed entirely separate from the user code, and the
 user code is rarely inter-dependent either.  In my opinion, this grants
 the best of both worlds.  Embedded programmers can toss all the code
 they don't need or don't want to port, but it's still available to those
 with more modest demands.


That's a nice approach, of course. Still... if Tango was standard and if
a third party was building a fresh implementation of D, it would be
"necessary" to provide the entire library (in order to conform to the
standard) even if the intended audience only wanted a fraction of it.

The C standard distinguishes between "hosted" and "freestanding"
implementations as one way of handling this issue. I guess this is the
same as the two-tiered approach I mentioned earlier.

Still, as was mentioned elsewhere, since D is garbage collected
targetting extremely small machines such as 8 bit microcontrollers with
16K of RAM (for example) is probably not in D's future anyway. Thus
standard library size might not be that big a deal for it.

Peter
Nov 29 2007
parent Sean Kelly <sean f4.ca> writes:
Peter C. Chapin wrote:

 
 Still, as was mentioned elsewhere, since D is garbage collected
 targetting extremely small machines such as 8 bit microcontrollers with
 16K of RAM (for example) is probably not in D's future anyway. Thus
 standard library size might not be that big a deal for it.


D doesn't have to be garbage collected, though I suppose not doing so 
may violate the standard.  The Tango tree, for example, includes a stub 
GC that simply calls malloc and free and performs no actual collection. 
  My motivation for creating this GC was to provide an example for 
kernel developers and the like, who may well not want to use an actual 
garbage collector in their code.

Kernel and embedded development were the primary user-oriented 
motivation for making not only a modular library but a modular runtime 
as well.  Targeting a system that doesn't support preemptive 
multitasking?  Just stub out threading support.  etc.  The Tango runtime 
actually consists of three entirely separate libraries that are bundled 
together for convenience, but they can be replaced individually as well 
if the user actually cares to go that route.


Sean

P.S. I apologize for talking about Tango in a Phobos thread.  This is 
one aspect of Tango's design most people don't seem aware of and I 
wanted to address it.
Nov 29 2007
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Peter C. Chapin wrote:

 A large standard library bulks up the language (where by "language" I
 mean the actual programming language plus its standard library
 facilities). Such bulk is undesirable in places where it isn't needed,
 such as embedded systems or other small scale environments.


Then why does Java thrive in such environments, i.e. cell phones, etc.? 
(okay, J2ME is a bit smaller than J2SE, but it's a far cry bigger than 
the C stdlib)

IMHO, the bigger the standard library, the better in most cases. 
Standard library code is well-reviewed and tested, so you can generally 
count on it more than 3rd party libraries, open source or not. Arguably 
more importantly, having a standard way of doing things makes code more 
consistent, reducing incompatibilities and portability issues. Further, 
if everyone knows the standard library (or a piece of it), a new 
developer can join the team and be instantly familiar with how to craft 
their code, and what the existing code does, without reading extensive 
documentation.
Nov 27 2007
next sibling parent renoX <renosky free.fr> writes:
Robert Fraser a écrit :

 Peter C. Chapin wrote:

 A large standard library bulks up the language (where by "language" I
 mean the actual programming language plus its standard library
 facilities). Such bulk is undesirable in places where it isn't needed,
 such as embedded systems or other small scale environments.


 
 Then why does Java thrive in such environments, i.e. cell phones, etc.? 
 (okay, J2ME is a bit smaller than J2SE, but it's a far cry bigger than 
 the C stdlib)
 
 IMHO, the bigger the standard library, the better in most cases. 
 Standard library code is well-reviewed and tested, so you can generally 
 count on it more than 3rd party libraries, open source or not. Arguably 
 more importantly, having a standard way of doing things makes code more 
 consistent, reducing incompatibilities and portability issues. Further, 
 if everyone knows the standard library (or a piece of it), a new 
 developer can join the team and be instantly familiar with how to craft 
 their code, and what the existing code does, without reading extensive 
 documentation.


Agreed. The bigger (in scope) the standard library will be, the better: 
Java and Perl success are directly linked to the breadth of their 
'standard library'.

For embedded purpose: D itself is not suitable to 16bit CPU, so it'd be 
at least 32bit CPU, and the current standard library with its GC usage 
is already not suited either to very small memory targets.

So for embedded targets where D can be useful I think that a standard 
library the size of Java's one would be ok.

I hope that many parts of Tango will be added to Phobos but being 
carefully made coherent with Phobos 'style'.

renoX
Nov 27 2007
prev sibling parent "Peter C. Chapin" <pchapin sover.net> writes:
Robert Fraser wrote:


 IMHO, the bigger the standard library, the better in most cases.
 Standard library code is well-reviewed and tested, so you can generally
 count on it more than 3rd party libraries, open source or not. Arguably
 more importantly, having a standard way of doing things makes code more
 consistent, reducing incompatibilities and portability issues. Further,
 if everyone knows the standard library (or a piece of it), a new
 developer can join the team and be instantly familiar with how to craft
 their code, and what the existing code does, without reading extensive
 documentation.


These arguments are undeniable, but taken to the extreme there are
problems. First, when specifying a standard library one runs the risk of
making a mistake and standardizing a poor design. Then everyone is stuck
with the error "forever." With a large library the probability of this
happening is greater. Then, of course specialized applications need
specialized methods. Thus attempting to put everything in the world into
a standard library results in lots of things that only a few people
really want to use. This just bulks up the standard for no particular
reason and makes life needlessly difficult for implementors (resulting
in fewer implementations that also have lower quality than would
otherwise be the case). Finally, standardization tends to inhibit
innovation; new library ideas might be left unexplored if the standard
has already claimed too much territory.

All that said, the trend today is for large standard libraries and
experience shows that they are helpful. However, I believe there is a
limit. It is not necessarily the case that bigger is better.

Peter
Nov 29 2007
prev sibling parent janderson <askme me.com> writes:
Dejan Lekic wrote:

 
 I honestly hope Phobos will remain what it is - a simple, core library, 
 and I hope it will not "evolve" into a huge framework of JAVA API, or 
 .NET 2 size.
 
 I would gladly see Phobos remain as the core, and emerging of some 
 higher-level, huge library (framework) on top of it, with all modern 
 features of frameworks mentioned above.
 
 Kind regards
 
 Dejan Lekic


I think we need Phobos Lite and Phobos (Which is Phobos Lite + 
components).  I wouldn't want to discourage making Phobos huge because 
that simply means its more useful for more people.

-Joel
Dec 01 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:

 
 http://www.dsource.org/projects/phobos
 
 Thanks to Brad Roberts for doing the organizational work, and Brad 
 Anderson for hosting.


Good news! I'm glad we are moving in the right direction. There is 
likely still a lot to go, but changes such as these are better made in 
small increments anyways.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 27 2007