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
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
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 reply "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
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 reply "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
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
[...]


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?


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