www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - http://dlang.org/bugstats.php

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
We just put together a page that counts the bugs per category. It's 
linked from "Bug tracker" in the navigation panel.

http://dlang.org/bugstats.php

The format is sketchy. Looking forward to your suggestions for improvements.


Andrei
Jan 21 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 01:18:04 Andrei Alexandrescu wrote:
 We just put together a page that counts the bugs per category. It's
 linked from "Bug tracker" in the navigation panel.
 
 http://dlang.org/bugstats.php
 
 The format is sketchy. Looking forward to your suggestions for improvements.

Looks pretty good, though it does take a while to fully load. I'd advise removing the decimal points from the bug counts. You can't have partial bugs, and with 3 decimal places, it starts looking like the European version of the thousands separator. - Jonathan M Davis
Jan 21 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 1/21/2012 11:18 PM, Andrei Alexandrescu wrote:
 We just put together a page that counts the bugs per category. It's linked
from "Bug tracker" in the navigation panel.
 
 http://dlang.org/bugstats.php
 
 The format is sketchy. Looking forward to your suggestions for improvements.
 
 
 Andrei

Please see my comments on that commit. The way you've implemented it about the most expensive way possible for both my server and the dlang.org server.
Jan 21 2012
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
The bugzilla links up the top don't work for me.

Are you inculding dups in the resolved count? 
Jan 21 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/12 1:55 AM, Daniel Murphy wrote:
 The bugzilla links up the top don't work for me.

Do they work now?
 Are you inculding dups in the resolved count?

Everything with the status RESOLVED, so I think so. Andrei
Jan 22 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jfhfaq$e9g$1 digitalmars.com...
 On 1/22/12 1:55 AM, Daniel Murphy wrote:
 The bugzilla links up the top don't work for me.

Do they work now?

Yep.
 Are you inculding dups in the resolved count?

Everything with the status RESOLVED, so I think so.

It's probably best to exclude dups from the graph, they don't say much about progress on the lanugage. Of course this would require deciphering bugzilla's report interface...
Jan 22 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
It might be worth separating bugs that have the Version field set to
lower than 2.000, so we know which bugs are D2-only.
Jan 22 2012
prev sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Monday, 23 January 2012 at 04:09:37 UTC, Daniel Murphy wrote:
 It's probably best to exclude dups from the graph, they don't 
 say much about progress on the lanugage.  Of course this would 
 require deciphering bugzilla's report interface...

That also means the should be excluded from the list of new bugs, I'm not sure how easy it would be to relate them.
Jan 23 2012
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jfgd7b$1a8j$1 digitalmars.com...
 We just put together a page that counts the bugs per category. It's linked 
 from "Bug tracker" in the navigation panel.

 http://dlang.org/bugstats.php

Nice! And just look at that purple line skyrocket! Also nice to see that the distance between new and resolved is increasing.
 The format is sketchy. Looking forward to your suggestions for 
 improvements.

A good, but perhaps obvious, start would be eliminating those ~10 lines of blank wasted space from each category ;)
Jan 22 2012
prev sibling next sibling parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Sun, 22 Jan 2012 08:18:04 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 We just put together a page that counts the bugs per category. It's  
 linked from "Bug tracker" in the navigation panel.

 http://dlang.org/bugstats.php

 The format is sketchy. Looking forward to your suggestions for  
 improvements.

Interesting, indeed. My comments: The dates on the chart look completely random. Perhaps a tick for each month, and text only for each year? 5000.000 is a silly number of bugs, just like 3.1415926535897932 is a silly number of bugs. Get rid of the decimals. The scope should be limited to those not marked Duplicate or Invalid, methinks. Perhaps also Wontfix. While some trends can be seen, it would be interesting to see resolved / new. I expected the links to show a graph for that category, not to list the bugs in that category. While Assigned and Reopened are negligible compared to New, I feel the chart would be more informational by showing Resolved vs Unresolved. The sudden drops in New around September '09 and January '11 seem like a good thing, but it's really only a change of status to Assigned, not to Resolved. Last, this was a fun chart to see, and will likely be more fun the future.
Jan 22 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/12 3:37 PM, Simen Kjærås wrote:
 The dates on the chart look completely random. Perhaps a tick for
 each month, and text only for each year?

 5000.000 is a silly number of bugs, just like 3.1415926535897932
 is a silly number of bugs. Get rid of the decimals.

 The scope should be limited to those not marked Duplicate or Invalid,
 methinks. Perhaps also Wontfix.

 While some trends can be seen, it would be interesting to see
 resolved / new.

 I expected the links to show a graph for that category, not to list
 the bugs in that category.

 While Assigned and Reopened are negligible compared to New, I feel
 the chart would be more informational by showing Resolved vs
 Unresolved. The sudden drops in New around September '09 and
 January '11 seem like a good thing, but it's really only a change
 of status to Assigned, not to Resolved.

Thanks for these thoughts. I should add that I need to defer most of them to others because I have little knowledge of whether and how bugzilla can be controlled. Andrei
Jan 22 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Andrei Alexandrescu wrote:
 We just put together a page that counts the bugs per category. It's
 linked from "Bug tracker" in the navigation panel.

 http://dlang.org/bugstats.php

 The format is sketchy. Looking forward to your suggestions for
 improvements.


 Andrei

In FF there are blank spaces between rows due to iframe's default height. Please change DISPLAY macro to the following: DISPLAY=$(TR $(TD <font color=$3>$(LINK2 http://d.puremagic.com/issues/buglist.cgi?$2, $1)</font>) $(TD <iframe scrolling=no frameborder=0 width="4.8em" height="1.4em" style="width:4.8em;height:1.4em;" vspace="0" hspace="0" marginwidth="0" marginheight="0" src=fetch-issue-cnt.php?$2&format=table&action=wrap&ctype=csv></iframe>))
Jan 22 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/12 6:17 PM, Piotr Szturmaj wrote:
 DISPLAY=$(TR $(TD <font color=$3>$(LINK2
 http://d.puremagic.com/issues/buglist.cgi?$2, $1)</font>) $(TD <iframe
 scrolling=no frameborder=0 width="4.8em" height="1.4em"
 style="width:4.8em;height:1.4em;" vspace="0" hspace="0" marginwidth="0"
 marginheight="0"
 src=fetch-issue-cnt.php?$2&format=table&action=wrap&ctype=csv></iframe>))

Did so. On Chrome things look the same. Is there improvement on other browsers? Thanks, Andrei
Jan 23 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Andrei Alexandrescu wrote:
 On 1/22/12 6:17 PM, Piotr Szturmaj wrote:
 DISPLAY=$(TR $(TD <font color=$3>$(LINK2
 http://d.puremagic.com/issues/buglist.cgi?$2, $1)</font>) $(TD <iframe
 scrolling=no frameborder=0 width="4.8em" height="1.4em"
 style="width:4.8em;height:1.4em;" vspace="0" hspace="0" marginwidth="0"
 marginheight="0"
 src=fetch-issue-cnt.php?$2&format=table&action=wrap&ctype=csv></iframe>))

Did so. On Chrome things look the same. Is there improvement on other browsers?

Yes, it fixed Firefox rendering.
Jan 23 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 01:18:04 Andrei Alexandrescu wrote:
 We just put together a page that counts the bugs per category. It's
 linked from "Bug tracker" in the navigation panel.
 
 http://dlang.org/bugstats.php
 
 The format is sketchy. Looking forward to your suggestions for improvements.

By the way, if you want the page to look 100% consistent, you're going to need to make it so that the boxes that show the bug counts have a white background and black text. As it is, they use whatever the browser defaults to, whereas the rest of the page chooses the colors. So, in any browser that uses its own defaults when the page doesn't specify, the boxes stand out, whereas in browsers which default to black on white, you can't even really tell that the boxes are there. - Jonathan M Davis
Jan 22 2012
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.725.1327294880.16222.digitalmars-d-announce puremagic.com...
 On Sunday, January 22, 2012 01:18:04 Andrei Alexandrescu wrote:
 We just put together a page that counts the bugs per category. It's
 linked from "Bug tracker" in the navigation panel.

 http://dlang.org/bugstats.php

 The format is sketchy. Looking forward to your suggestions for 
 improvements.

By the way, if you want the page to look 100% consistent, you're going to need to make it so that the boxes that show the bug counts have a white background and black text. As it is, they use whatever the browser defaults to, whereas the rest of the page chooses the colors. So, in any browser that uses its own defaults when the page doesn't specify, the boxes stand out, whereas in browsers which default to black on white, you can't even really tell that the boxes are there.

There's a basic, trivial rule of design that needs to be plastered all over the cubicle walls of every software developer on the planet. I've spent years trying to shout it out at every opportinity, but so far I've barely made even a microscopic dent. Here it is: "When you set a foreground or background color: SET THE OTHER ONE TOO!!!" Always. Period. No matter what. In *anything*. Yes, that means YOU, no matter who the "YOU" is!! Either *both* system-default, or *both* application-set: NEVER cross those streams! Never, never, never, never, NEVER! Honestly, it's an absolute *travesty* that any interface APIs, HTML/CSS, etc., ever even *allow* the developer to have one set as system-default and not the other.
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 23, 2012 01:47:23 Nick Sabalausky wrote:
 There's a basic, trivial rule of design that needs to be plastered all over
 the cubicle walls of every software developer on the planet. I've spent
 years trying to shout it out at every opportinity, but so far I've barely
 made even a microscopic dent.
 
 Here it is:
 
 "When you set a foreground or background color: SET THE OTHER ONE TOO!!!"
 
 Always. Period. No matter what. In *anything*. Yes, that means YOU, no
 matter who the "YOU" is!!
 
 Either *both* system-default, or *both* application-set: NEVER cross those
 streams! Never, never, never, never, NEVER!
 
 Honestly, it's an absolute *travesty* that any interface APIs, HTML/CSS,
 etc., ever even *allow* the developer to have one set as system-default and
 not the other.

While I agree with you, that's not the problem here. The problem is that the majority of the page doesn't use the brower's defaults, but the boxes don't. Now, it's quite possible that the boxes are screwed up to the point that one of the two defaults is messed up, but that wasn't my complete. Actually, Konqueror (which is my primary browser) has a long-standing bug that makes it so that if the page doesn't set the foreground and background colors, the system color is used for the background, but black is always used for the foreground. It sucks for me, since I end up with black on darker blue, and it's hard to read (unfortunately, any attempts to report it have been lumped in with the complaints about pages not looking correct when the page sets the colors in some places but not all - which isn't the browsers fault at all - so it continues to remain broken). So, I'm screwed even if neither color was set rather than the web developer screwing up and setting only one of them. - Jonathan M Davis
Jan 22 2012
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
22.01.2012 11:18, Andrei Alexandrescu пишет:
 We just put together a page that counts the bugs per category. It's
 linked from "Bug tracker" in the navigation panel.

 http://dlang.org/bugstats.php

 The format is sketchy. Looking forward to your suggestions for
 improvements.


 Andrei

https://github.com/D-Programming-Language/d-programming-language.org/blob/master/bugstats.php.dd#L24 width="48em" height="18em" Font size is about 14px so these areas for few digits are very big: ~700px x 250px. Opera and Chrome incorrectly displays it as if 1em = 1px. Firefox displays correctly (and ugly) unless you rewrite it into `width="48.0em" height="18.0em"`. So am I missing something? If no, why does Opera, Chrome and Firefox incorrectly display such a simple page? Why does Andrei use `em` in this case instead of px? [OT] Why is that dirty, slow, hard-to-implement, hard-to-understand, and hard-to-write-in (error-prone) HTML used everywhere with it's dirty friend XML?!!! Let's, at least, remove XML support from D as a protest when D will became popular enough! (Sorry, just can't keep it in any more)
Jan 23 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Denis Shelomovskij" <verylonglogin.reg gmail.com> wrote in message 
news:jfj92f$m30$1 digitalmars.com...
 [OT] Why is that dirty, slow, hard-to-implement, hard-to-understand, and 
 hard-to-write-in (error-prone) HTML used everywhere with it's dirty friend 
 XML?!!! Let's, at least, remove XML support from D as a protest when D 
 will became popular enough! (Sorry, just can't keep it in any more)

For at least a few years now, I've dreamt of creating a *sane* alternative to (X)HTML/CSS that's *ACTUALLY DESIGNED* for UIs instead of documents. The idea is to create a normal standard web browser, and then sneak in this new system as an additional feature - which I figure is about the only way it would have so much as a snowball's chance in hell of ever catching on at all. Unfortunately, my pet-project plate already resembles that of a one-trip buffet: Piled up, overflowing and more than one person should ever be able to handle. (I'm hungry...)
Jan 23 2012
next sibling parent reply Mirko Pilger <mirko.pilger gmail.com> writes:
 For at least a few years now, I've dreamt of creating a *sane* alternative
 to (X)HTML/CSS that's *ACTUALLY DESIGNED* for UIs instead of documents.
 [...]
 Unfortunately, my pet-project plate already resembles that of a one-trip
 buffet: Piled up, overflowing and more than one person should ever be able
 to handle.

well, i would love to hear a bit more about your ideas for that *sane alternative*. maybe i'm able to pick some of them up for my personal pet project. private mail is ok, if you don't want to "spam" the ng.
Jan 23 2012
parent "Nick Sabalausky" <a a.a> writes:
"Mirko Pilger" <mirko.pilger gmail.com> wrote in message 
news:jfk9g6$2o22$1 digitalmars.com...
 For at least a few years now, I've dreamt of creating a *sane* 
 alternative
 to (X)HTML/CSS that's *ACTUALLY DESIGNED* for UIs instead of documents.
 [...]
 Unfortunately, my pet-project plate already resembles that of a one-trip
 buffet: Piled up, overflowing and more than one person should ever be 
 able
 to handle.

well, i would love to hear a bit more about your ideas for that *sane alternative*. maybe i'm able to pick some of them up for my personal pet project. private mail is ok, if you don't want to "spam" the ng.

I haven't really had the opportunity to think through any concrete details. But a couple basic thoughts: - It would be one unified language or protocol. None of this flip-flopping between (X)HTML and CSS bullshit. (X)HTML/CSS *could* have facilitated separation of content and styling in one language. They just didn't bother to design it that way. (The Internet's credo is "Why fix what's broken when you can just pile more broken crap on top?") - Controling how it reflows would be a major component. (X)HTML/CSS are garbage at this. Whether they realize it or not, that's ultimately one of the main reasons a lot of sites use those static-layout abominations. GUI desktop software and GUI design programs are big inspirations for this.
Jan 23 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jfjdc3$ttd$1 digitalmars.com...
 "Denis Shelomovskij" <verylonglogin.reg gmail.com> wrote in message 
 news:jfj92f$m30$1 digitalmars.com...
 [OT] Why is that dirty, slow, hard-to-implement, hard-to-understand, and 
 hard-to-write-in (error-prone) HTML used everywhere with it's dirty 
 friend XML?!!! Let's, at least, remove XML support from D as a protest 
 when D will became popular enough! (Sorry, just can't keep it in any 
 more)

For at least a few years now, I've dreamt of creating a *sane* alternative to (X)HTML/CSS that's *ACTUALLY DESIGNED* for UIs instead of documents. The idea is to create a normal standard web browser, and then sneak in this new system as an additional feature - which I figure is about the only way it would have so much as a snowball's chance in hell of ever catching on at all.

I fogot to mention the other half of the plan: In order to prevent death by chicken and egg, there would be a JavaScript module that could be included (and maybe a server-side or developer-side alternative) which would convert the new presentation system to traditional (X)HTML/CSS/JS garbage (It would include special code that disabled itself on browsers like mine which supported the new presentation system natively). That way, any web developer who might be interested in using it could do so without fear of becoming unusable on the majority of browsers. That would make it at least possible for it to develop some level of following. Then, if the developers of the other browsers were smart (which is tenuous, I know), then they'd realize they could support it much better and much more efficiently by including native support. Sanity: 1, (X)HTML/CSS/JS: 0
Jan 23 2012
prev sibling parent %u <noreply example.com> writes:
== Quote from Denis Shelomovskij (verylonglogin.reg gmail.com)'s article
[...]

 width="48em" height="18em"
 Font size is about 14px so these areas for few digits are very big:
 ~700px x 250px. Opera and Chrome incorrectly displays it as if 1em =
 1px. Firefox displays correctly (and ugly) unless you rewrite it into
 `width="48.0em" height="18.0em"`.
 So am I missing something? If no, why does Opera, Chrome and Firefox
 incorrectly display such a simple page?
 Why does Andrei use `em` in this case instead of px?

The HTML attributes width and height are not equivalent to the CSS properties of the same names. The HTML attributes are not meant to hold em values. Undefined behaviour fun is the result. Both of the browers' approaches to handle the situation are sensible. The idea behind using em there is probably to get an iframe that matches the text in height, even if the user agent uses an exotic font-size. However, using an iframe is working against that: The em values refer to the font-size of the context its in, but really you want something proportional to its content. But that's not possible as far as I can tell. Generally, using iframes there is just calling for trouble.
Jan 23 2012