Re: http://dlang.org/bugstats.php
"Mirko Pilger" 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
"Nick Sabalausky" wrote in message news:jfjdc3$ttd$1...@digitalmars.com... > "Denis Shelomovskij" 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
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.
Re: http://dlang.org/bugstats.php
Andrei Alexandrescu wrote: On 1/22/12 6:17 PM, Piotr Szturmaj wrote: DISPLAY=$(TR $(TD $(LINK2 http://d.puremagic.com/issues/buglist.cgi?$2, $1)) $(TD )) Did so. On Chrome things look the same. Is there improvement on other browsers? Yes, it fixed Firefox rendering.
Re: http://dlang.org/bugstats.php
On 1/22/12 6:17 PM, Piotr Szturmaj wrote: DISPLAY=$(TR $(TD $(LINK2 http://d.puremagic.com/issues/buglist.cgi?$2, $1)) $(TD )) Did so. On Chrome things look the same. Is there improvement on other browsers? Thanks, Andrei
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
== 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
"Denis Shelomovskij" 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...)
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
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
"Jonathan M Davis" 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 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
"Andrei Alexandrescu" 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
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 $(LINK2 http://d.puremagic.com/issues/buglist.cgi?$2, $1)) $(TD 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>))
Re: http://dlang.org/bugstats.php
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
Re: http://dlang.org/bugstats.php
On Sun, 22 Jan 2012 08:18:04 +0100, 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. 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.
Re: http://dlang.org/bugstats.php
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.
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 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
The bugzilla links up the top don't work for me. Are you inculding dups in the resolved count?
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
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
http://dlang.org/bugstats.php
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