• downs <default_357-line yahoo.de> Jul 18 2007
• Clay Smith <clayasaurus gmail.com> Jul 18 2007
• downs <default_357-line yahoo.de> Jul 18 2007
• Steve Teale <steve.teale britseyeview.com> Jul 18 2007
• Steve Teale <steve.teale britseyeview.com> Jul 18 2007
• Tristam MacDonald <swiftcoder gmail.com> Jul 18 2007
• "Chris Miller" <chris dprogramming.com> Jul 18 2007
• downs <default_357-line yahoo.de> Jul 19 2007
• Regan Heath <regan netmail.co.nz> Jul 19 2007
• downs <default_357-line yahoo.de> Jul 19 2007
• Nicolai Waniek <no.spam thank.you.com> Jul 19 2007
• janderson <askme me.com> Jul 21 2007
• Walter Bright <newshound1 digitalmars.com> Jul 23 2007
• TomD <t_demmer NOSPAM.web.de> Jul 23 2007
• janderson <askme me.com> Jul 23 2007

downs <default_357-line yahoo.de> writes:

I don't like Tango. Going by looks and usability alone, I'd far prefer to use
Phobos. However, 
sometimes I run into trouble with Phobos, like sockets being broken in
interesting ways, the 
connect function not being synchronized, lack of templates in std.string .. I'm
sure many of you 
have had similar experiences.
Those are not unbelievably complex and hard issues (like, for example, Macros)
but mostly rather 
trivial things that could be fixed with a few lines of code.
So I really have to ask - why are these issues not being fixed? Why is it that
in a post-1.0 
project, which should be largely bug-free and feature complete, I still have to
debug the _standard 
library_?
When writing code, there are a few basic assumptions that you have to make for
the sake of 
efficiency, like what your tools are telling you is correct. That the standard
library works as 
advertised is one of those assumptions. Why is it, that in a post-1.0 project,
important parts of 
the GC, like generationalCollect, even though they are explicitly mentioned in
the documentation, 
remain unimplemented?
I really like D, and I also like Phobos. I think it would be sad if people who
don't even 
particularly _like_ Tango would be pushed towards using it by problems that
could have been solved.
  --downs

PS: In a similar vein, some people have observed that longstanding bugs seem to
be getting less 
attention these days. Perhaps it would be .. wise, before going off and adding
new features which 
in turn introduce new bugs, to fix the old ones first?

Clay Smith <clayasaurus gmail.com> writes:

downs wrote:
 I don't like Tango. Going by looks and usability alone, I'd far prefer 
 to use Phobos. However, sometimes I run into trouble with Phobos, like 
 sockets being broken in interesting ways, the connect function not being 
 synchronized, lack of templates in std.string .. I'm sure many of you 
 have had similar experiences.
 Those are not unbelievably complex and hard issues (like, for example, 
 Macros) but mostly rather trivial things that could be fixed with a few 
 lines of code.
 So I really have to ask - why are these issues not being fixed? Why is 
 it that in a post-1.0 project, which should be largely bug-free and 
 feature complete, I still have to debug the _standard library_?
 When writing code, there are a few basic assumptions that you have to 
 make for the sake of efficiency, like what your tools are telling you is 
 correct. That the standard library works as advertised is one of those 
 assumptions. Why is it, that in a post-1.0 project, important parts of 
 the GC, like generationalCollect, even though they are explicitly 
 mentioned in the documentation, remain unimplemented?
 I really like D, and I also like Phobos. I think it would be sad if 
 people who don't even particularly _like_ Tango would be pushed towards 
 using it by problems that could have been solved.
  --downs
 
 PS: In a similar vein, some people have observed that longstanding bugs 
 seem to be getting less attention these days. Perhaps it would be .. 
 wise, before going off and adding new features which in turn introduce 
 new bugs, to fix the old ones first?


I'd rather have Walter work on compiler bugs than standard library issues.

I think the best solution would be for Walter to put phobos in an SVN 
and give 1 or 2 trusted D community members commit access so they can 
merge user patches etc. while Walter simply concentrates on the compiler.

downs <default_357-line yahoo.de> writes:

Clay Smith wrote:
 I'd rather have Walter work on compiler bugs than standard library issues.
 


recognizable as a compiler problem.
On the other hand, when hunting for the cause of a lone segfault it can take
one quite a while to 
figure out that it actually happens in the standard library (it took me a few
hours ^^ )
 I think the best solution would be for Walter to put phobos in an SVN 
 and give 1 or 2 trusted D community members commit access so they can 
 merge user patches etc. while Walter simply concentrates on the compiler.
 

Steve Teale <steve.teale britseyeview.com> writes:

Clay Smith Wrote:

 downs wrote:
 I don't like Tango. Going by looks and usability alone, I'd far prefer 
 to use Phobos. However, sometimes I run into trouble with Phobos, like 
 sockets being broken in interesting ways, the connect function not being 
 synchronized, lack of templates in std.string .. I'm sure many of you 
 have had similar experiences.
 Those are not unbelievably complex and hard issues (like, for example, 
 Macros) but mostly rather trivial things that could be fixed with a few 
 lines of code.
 So I really have to ask - why are these issues not being fixed? Why is 
 it that in a post-1.0 project, which should be largely bug-free and 
 feature complete, I still have to debug the _standard library_?
 When writing code, there are a few basic assumptions that you have to 
 make for the sake of efficiency, like what your tools are telling you is 
 correct. That the standard library works as advertised is one of those 
 assumptions. Why is it, that in a post-1.0 project, important parts of 
 the GC, like generationalCollect, even though they are explicitly 
 mentioned in the documentation, remain unimplemented?
 I really like D, and I also like Phobos. I think it would be sad if 
 people who don't even particularly _like_ Tango would be pushed towards 
 using it by problems that could have been solved.
  --downs
 
 PS: In a similar vein, some people have observed that longstanding bugs 
 seem to be getting less attention these days. Perhaps it would be .. 
 wise, before going off and adding new features which in turn introduce 
 new bugs, to fix the old ones first?


 I'd rather have Walter work on compiler bugs than standard library issues.
 
 I think the best solution would be for Walter to put phobos in an SVN 
 and give 1 or 2 trusted D community members commit access so they can 
 merge user patches etc. while Walter simply concentrates on the compiler.
 
 
 
 



I believe there is a groundswell in this direction, including making the two
libraries compatible.  It may get attention at the conference, but that is no
reason why those of us who feel this way should not continue to make a noise
about it.  The time is right!

Steve Teale <steve.teale britseyeview.com> writes:

Clay Smith Wrote:

 downs wrote:
 I don't like Tango. Going by looks and usability alone, I'd far prefer 
 to use Phobos. However, sometimes I run into trouble with Phobos, like 
 sockets being broken in interesting ways, the connect function not being 
 synchronized, lack of templates in std.string .. I'm sure many of you 
 have had similar experiences.
 Those are not unbelievably complex and hard issues (like, for example, 
 Macros) but mostly rather trivial things that could be fixed with a few 
 lines of code.
 So I really have to ask - why are these issues not being fixed? Why is 
 it that in a post-1.0 project, which should be largely bug-free and 
 feature complete, I still have to debug the _standard library_?
 When writing code, there are a few basic assumptions that you have to 
 make for the sake of efficiency, like what your tools are telling you is 
 correct. That the standard library works as advertised is one of those 
 assumptions. Why is it, that in a post-1.0 project, important parts of 
 the GC, like generationalCollect, even though they are explicitly 
 mentioned in the documentation, remain unimplemented?
 I really like D, and I also like Phobos. I think it would be sad if 
 people who don't even particularly _like_ Tango would be pushed towards 
 using it by problems that could have been solved.
  --downs
 
 PS: In a similar vein, some people have observed that longstanding bugs 
 seem to be getting less attention these days. Perhaps it would be .. 
 wise, before going off and adding new features which in turn introduce 
 new bugs, to fix the old ones first?


 I'd rather have Walter work on compiler bugs than standard library issues.
 
 I think the best solution would be for Walter to put phobos in an SVN 
 and give 1 or 2 trusted D community members commit access so they can 
 merge user patches etc. while Walter simply concentrates on the compiler.
 
 
 
 



I believe there is a groundswell in this direction, including making the two
libraries compatible.  It may get attention at the conference, but that is no
reason why those of us who feel this way should not continue to make a noise
about it.  The time is right!

Tristam MacDonald <swiftcoder gmail.com> writes:

There should be a groundswell!
How can a language be ready for prime time when there are 2 competing and
non-compatible std libraries? Especially when the official one is broken and
the community one doesn't having full support from the compiler implementor
(synchronized support for other mutex implementations, etc.)?

Steve Teale Wrote:
 Clay Smith Wrote:
 
 downs wrote:
 I don't like Tango. Going by looks and usability alone, I'd far prefer 
 to use Phobos. However, sometimes I run into trouble with Phobos, like 
 sockets being broken in interesting ways, the connect function not being 
 synchronized, lack of templates in std.string .. I'm sure many of you 
 have had similar experiences.
 Those are not unbelievably complex and hard issues (like, for example, 
 Macros) but mostly rather trivial things that could be fixed with a few 
 lines of code.
 So I really have to ask - why are these issues not being fixed? Why is 
 it that in a post-1.0 project, which should be largely bug-free and 
 feature complete, I still have to debug the _standard library_?
 When writing code, there are a few basic assumptions that you have to 
 make for the sake of efficiency, like what your tools are telling you is 
 correct. That the standard library works as advertised is one of those 
 assumptions. Why is it, that in a post-1.0 project, important parts of 
 the GC, like generationalCollect, even though they are explicitly 
 mentioned in the documentation, remain unimplemented?
 I really like D, and I also like Phobos. I think it would be sad if 
 people who don't even particularly _like_ Tango would be pushed towards 
 using it by problems that could have been solved.
  --downs
 
 PS: In a similar vein, some people have observed that longstanding bugs 
 seem to be getting less attention these days. Perhaps it would be .. 
 wise, before going off and adding new features which in turn introduce 
 new bugs, to fix the old ones first?


 I'd rather have Walter work on compiler bugs than standard library issues.
 
 I think the best solution would be for Walter to put phobos in an SVN 
 and give 1 or 2 trusted D community members commit access so they can 
 merge user patches etc. while Walter simply concentrates on the compiler.
 
 
 
 


 
 I believe there is a groundswell in this direction, including making the two
libraries compatible.  It may get attention at the conference, but that is no
reason why those of us who feel this way should not continue to make a noise
about it.  The time is right!
 

"Chris Miller" <chris dprogramming.com> writes:

On Wed, 18 Jul 2007 10:00:48 -0400, downs <default_357-line yahoo.de>  
wrote:

 I don't like Tango. Going by looks and usability alone, I'd far prefer  
 to use Phobos. However, sometimes I run into trouble with Phobos, like  
 sockets being broken in interesting ways, the connect function not being  
 synchronized, lack of templates in std.string .. I'm sure many of you  
 have had similar experiences.


How are sockets broken in interesting ways, and why would connect need to  
be synchronized? It's mostly just directly calling the BSD sockets  
interface.

downs <default_357-line yahoo.de> writes:

Chris Miller wrote:
 On Wed, 18 Jul 2007 10:00:48 -0400, downs <default_357-line yahoo.de>  
 wrote:
 
 I don't like Tango. Going by looks and usability alone, I'd far 
 prefer  to use Phobos. However, sometimes I run into trouble with 
 Phobos, like  sockets being broken in interesting ways, the connect 
 function not being  synchronized, lack of templates in std.string .. 
 I'm sure many of you  have had similar experiences.


 
 How are sockets broken in interesting ways, and why would connect need 
 to  be synchronized? It's mostly just directly calling the BSD sockets  
 interface.


your system, but it caused a segfault on my Win32 and it causes a segfault on
my Linux.
I'm pretty sure I debugged it once and traced it back to sock.connect not using
threadsafe 
functions. I don't have the specifics though. I can dig them out again if you
want, but my gdb is 
currently broken.
  --downs

Regan Heath <regan netmail.co.nz> writes:

downs wrote:
 Chris Miller wrote:
 On Wed, 18 Jul 2007 10:00:48 -0400, downs <default_357-line yahoo.de>  
 wrote:

 I don't like Tango. Going by looks and usability alone, I'd far 
 prefer  to use Phobos. However, sometimes I run into trouble with 
 Phobos, like  sockets being broken in interesting ways, the connect 
 function not being  synchronized, lack of templates in std.string .. 
 I'm sure many of you  have had similar experiences.



 How are sockets broken in interesting ways, and why would connect need 
 to  be synchronized? It's mostly just directly calling the BSD 
 sockets  interface.


 rapidly? I don't know about your system, but it caused a segfault on my 
 Win32 and it causes a segfault on my Linux.
 I'm pretty sure I debugged it once and traced it back to sock.connect 
 not using threadsafe functions. I don't have the specifics though. I can 
 dig them out again if you want, but my gdb is currently broken.
  --downs


connect just calls BSD connect and I don't recall that being 
thread-unsafe, however calls to gethostname are, I think.

Regan

downs <default_357-line yahoo.de> writes:

Regan Heath wrote:
 downs wrote:
 
 Chris Miller wrote:

 On Wed, 18 Jul 2007 10:00:48 -0400, downs 
 <default_357-line yahoo.de>  wrote:

 I don't like Tango. Going by looks and usability alone, I'd far 
 prefer  to use Phobos. However, sometimes I run into trouble with 
 Phobos, like  sockets being broken in interesting ways, the connect 
 function not being  synchronized, lack of templates in std.string .. 
 I'm sure many of you  have had similar experiences.




 How are sockets broken in interesting ways, and why would connect 
 need to  be synchronized? It's mostly just directly calling the BSD 
 sockets  interface.


 Have you ever tried connecting to multiple sites in multiple threads 
 rapidly? I don't know about your system, but it caused a segfault on 
 my Win32 and it causes a segfault on my Linux.
 I'm pretty sure I debugged it once and traced it back to sock.connect 
 not using threadsafe functions. I don't have the specifics though. I 
 can dig them out again if you want, but my gdb is currently broken.
  --downs


 
 connect just calls BSD connect and I don't recall that being 
 thread-unsafe, however calls to gethostname are, I think.
 
 Regan


My point, however, still stands. ^^

Nicolai Waniek <no.spam thank.you.com> writes:

I fully agree with you, but am looking forward to the results of the D
conference. Hopefully, no I'm very confident that some good decisions will be
made then.


-- 
.71
nicolai dot waniek at sphere71 dot com

janderson <askme me.com> writes:

downs wrote:
 I don't like Tango. Going by looks and usability alone, I'd far prefer 
 to use Phobos. However, sometimes I run into trouble with Phobos, like 
 sockets being broken in interesting ways, the connect function not being 
 synchronized, lack of templates in std.string .. I'm sure many of you 
 have had similar experiences.
 Those are not unbelievably complex and hard issues (like, for example, 
 Macros) but mostly rather trivial things that could be fixed with a few 
 lines of code.
 So I really have to ask - why are these issues not being fixed? Why is 
 it that in a post-1.0 project, which should be largely bug-free and 
 feature complete, I still have to debug the _standard library_?
 When writing code, there are a few basic assumptions that you have to 
 make for the sake of efficiency, like what your tools are telling you is 
 correct. That the standard library works as advertised is one of those 
 assumptions. Why is it, that in a post-1.0 project, important parts of 
 the GC, like generationalCollect, even though they are explicitly 
 mentioned in the documentation, remain unimplemented?
 I really like D, and I also like Phobos. I think it would be sad if 
 people who don't even particularly _like_ Tango would be pushed towards 
 using it by problems that could have been solved.
  --downs
 
 PS: In a similar vein, some people have observed that longstanding bugs 
 seem to be getting less attention these days. Perhaps it would be .. 
 wise, before going off and adding new features which in turn introduce 
 new bugs, to fix the old ones first?


Maybe the community should just make a branch of Phobos 
(Phobos.Community).  Go though all the submissions to bugzilla and add 
them.  Perhaps the person adding the fix could be a different person 
that summited it so the code get some review.  Walter could then come 
along once and a while and merge it into his branch which is much 
quicker then adding single fixes at a time (alternatively he could keep 
fixing Phobos bugs as he already is).

Walter Bright <newshound1 digitalmars.com> writes:

janderson wrote:
 Maybe the community should just make a branch of Phobos 
 (Phobos.Community).  Go though all the submissions to bugzilla and add 
 them.


I'm going to do a little rant here, so please indulge me for a moment. 
Many of the submitted patches are well done, and they aren't put in 
phobos because I haven't gotten off of my lazy arse and put them in yet.

But some are of the form "I don't know how it works, here's a patch that 
might work but I haven't tried it." Those kind of patches are not helpful.

A good patch has the following attributes:

1) It's done based on a good understanding of how the module works and 
how it should work.

2) It's been tried and found to work. Saying it "seems" to work isn't 
good enough, and leaves me with the thought that the engineering of the 
patch will have to be completely redone.

3) Unit tests are included to independently verify that it does, indeed, 
work and solve the bug.

4) The -cov switch was used to verify that all lines of the patch were 
executed by the unit tests.

Do I consistently live up to this standard 100%? Nope, and shame on me 
for not. And every time I don't, I get burned.

TomD <t_demmer NOSPAM.web.de> writes:

Walter Bright Wrote:

[...]
 
 A good patch has the following attributes:
 
 1) It's done based on a good understanding of how the module works and 
 how it should work.
 
 2) It's been tried and found to work. Saying it "seems" to work isn't 
 good enough, and leaves me with the thought that the engineering of the 
 patch will have to be completely redone.
 
 3) Unit tests are included to independently verify that it does, indeed, 
 work and solve the bug.
 
 4) The -cov switch was used to verify that all lines of the patch were 
 executed by the unit tests.
 
 Do I consistently live up to this standard 100%? Nope, and shame on me 
 for not. And every time I don't, I get burned.


Fair enough. Maybe these guidelines should be put somewhere prominently
on the bugs&issues area. (3) and especially (4) slipped my mind.

Ciao
Tom

janderson <askme me.com> writes:

Walter Bright wrote:
 janderson wrote:
 Maybe the community should just make a branch of Phobos 
 (Phobos.Community).  Go though all the submissions to bugzilla and add 
 them.


 I'm going to do a little rant here, so please indulge me for a moment. 
 Many of the submitted patches are well done, and they aren't put in 
 phobos because I haven't gotten off of my lazy arse and put them in yet.
 
 But some are of the form "I don't know how it works, here's a patch that 
 might work but I haven't tried it." Those kind of patches are not helpful.
 
 A good patch has the following attributes:
 
 1) It's done based on a good understanding of how the module works and 
 how it should work.
 
 2) It's been tried and found to work. Saying it "seems" to work isn't 
 good enough, and leaves me with the thought that the engineering of the 
 patch will have to be completely redone.
 
 3) Unit tests are included to independently verify that it does, indeed, 
 work and solve the bug.
 
 4) The -cov switch was used to verify that all lines of the patch were 
 executed by the unit tests.
 
 Do I consistently live up to this standard 100%? Nope, and shame on me 
 for not. And every time I don't, I get burned.


A good point.

Maybe the community could somehow help you find the better ones by 
voting/reviewing (using the attributes you just outlines).  Also ones 
that are not up to standard could me marked as so (by anyone), so either 
the original person or another can improve it.  I'm imagining each 
bug-fix being handed to Walter on a sliver spoon, reviewed and improved 
by many people.  Chances are people area more likely to improve their 
contributions if they know they are not up to scratch.

I guess its difficult to motivate people (or to find people who have 
time for that sort of thing).  One way to help this is to have good 
documentation on Bugzilia about how to contribute to the effort.

Another would be to have regular weekly positing of all the bugzilla bug 
(or perhaps the top 10) to this newsgroup to remind people to review and 
improve them. ie "Please review these top 10 Phobos bugs and improve 
them so Walter can take them off the list. ect..."

Just a thought.