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
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
next sibling parent 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

# python trac/contrib/bugzilla2trac.py 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
prev sibling 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

# python trac/contrib/bugzilla2trac.py 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 next sibling parent 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
prev sibling 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.

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.


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 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
prev sibling next sibling parent 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
prev sibling next sibling 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 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 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
prev sibling next sibling parent 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
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 next sibling parent 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
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 "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 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.


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.


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 next sibling 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
next sibling parent 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
prev sibling 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 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
prev sibling 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 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