www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Humble request Walter: Could you _please_ fix phobos already?

reply 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?
Jul 18 2007
next sibling parent reply 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.
Jul 18 2007
next sibling parent 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.
 

Jul 18 2007
prev sibling next sibling parent 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!
Jul 18 2007
prev sibling parent reply 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!
Jul 18 2007
parent 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!

Jul 18 2007
prev sibling next sibling parent reply "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.
Jul 18 2007
parent reply 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
Jul 19 2007
parent reply 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
Jul 19 2007
parent 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. ^^
Jul 19 2007
prev sibling next sibling parent 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
Jul 19 2007
prev sibling parent reply 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).
Jul 21 2007
parent reply 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.
Jul 23 2007
next sibling parent 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
Jul 23 2007
prev sibling parent 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.
Jul 23 2007