Re: http://dlang.org/bugstats.php
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)
Re: http://dlang.org/bugstats.php
== Quote from Denis Shelomovskij (verylonglogin@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.
Re: http://dlang.org/bugstats.php
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.
Re: http://dlang.org/bugstats.php
Nick Sabalausky a@a.a wrote in message news:jfjdc3$ttd$1...@digitalmars.com... Denis Shelomovskij verylonglogin@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
Re: http://dlang.org/bugstats.php
Mirko Pilger mirko.pil...@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.
Re: http://dlang.org/bugstats.php
Andrei Alexandrescu seewebsiteforem...@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 ;)
Re: http://dlang.org/bugstats.php
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
Re: http://dlang.org/bugstats.php
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?$2format=tableaction=wrapctype=csv/iframe))
Re: http://dlang.org/bugstats.php
Andrei Alexandrescu seewebsiteforem...@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...
Re: http://dlang.org/bugstats.php
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
Re: http://dlang.org/bugstats.php
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.725.1327294880.16222.digitalmars-d-annou...@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.
Re: http://dlang.org/bugstats.php
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
Re: http://dlang.org/bugstats.php
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.
Re: http://dlang.org/bugstats.php
The bugzilla links up the top don't work for me. Are you inculding dups in the resolved count?
