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: Native GTK2 D Bindings
The function names should be converted to camelCase. and a README. gdc does cross module inlining if you pass all modules to it at once.
Re: Native GTK2 D Bindings
On 01/23/12 00:16, Trass3r wrote: The function names should be converted to camelCase. No. I named it native for a reason. The method names are not manipulated in any way - they come directly from GTK. I could *add* all kind of aliases, including camelCased ones, but why would anyone want to use those? gdc does cross module inlining if you pass all modules to it at once. As i mentioned in the README; but that's not really a solution. For me, LTO works for all apps using these bindings, but i added that footnote so that i could write zero-cost and not have people complain that the calls are not going directly to the PLT (as they do in C). :) artur
Re: Native GTK2 D Bindings
No. I named it native for a reason. The method names are not manipulated in any way - they come directly from GTK. I could *add* all kind of aliases, including camelCased ones, but why would anyone want to use those? Cause those C names with underscores are just crappy. gdc does cross module inlining if you pass all modules to it at once. As i mentioned in the README; but that's not really a solution. No, in there you claim gdc didn't support cross module inlining.
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: Native GTK2 D Bindings
Artur Skawina: So far, a sample D GTK app looks like this: http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk3.d Anything I could change API-wise to improve things, that doesn't require language changes? The convention for D classes/structs/enums is CamelCase, while functions and methods are the same but start with a lowercase. This line of code seems an example for people that like named arguments in D: gtk.init(null,null); Such lines of code contains a bad cast: set_title(cast(char*)Hello World!); but.signal_connect!button-press-event(bpress_cb, cast(void*)label); I think toStringz shouldn't return a const pointer: str0 = cast(char*)toStringz(display_string); Bye, bearophile
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: Native GTK2 D Bindings
On 01/23/12 03:17, bearophile wrote: Artur Skawina: So far, a sample D GTK app looks like this: http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk3.d Anything I could change API-wise to improve things, that doesn't require language changes? The convention for D classes/structs/enums is CamelCase, while functions and methods are the same but start with a lowercase. There is no such thing as a language mandated identifier naming convention. If you think otherwise - make the compiler enforce it. :) This line of code seems an example for people that like named arguments in D: gtk.init(null,null); This has nothing to do with named arguments, it's gtk wanting to parse and modify the C argv[], which i didn't want to rebuild in these examples. /* void gtk_init(/*inout*/ int* argc, /*inout*/ char*** argv=null);*/ A function which handles the argv conversion both ways would be a good idea. On the list. Thanks. Such lines of code contains a bad cast: set_title(cast(char*)Hello World!); If you had seen the glib code i was initially testing with... :) Unfortunately the immutable-strings don't mix well with non-D APIs, especially, like in this case, when practically all const annotations are lost in translation (the GIR files are already missing them). Initially, i wanted to add a cstring type which would handle all the casts and zero-termination transparently, but then decided to see how things will work without that kind of magic. Not only would most strings have to be duped, but an extra reference to the copies would be needed, in case the string escaped. Requiring explicit casts for most strings is ugly, but not something that can be fixed both safely and cheaply. For a GUI toolkit the amount of casts needed may be acceptable. [1] I did remove the glib-using code from the repo because it made D look bad... but.signal_connect!button-press-event(bpress_cb, cast(void*)label); Here label is really an opaque (void*) that gets passed to the callback. I don't see a way to get rid of the cast, while improving type safety... I think toStringz shouldn't return a const pointer: str0 = cast(char*)toStringz(display_string); (immutable(char)*) C APIs are not exactly common. :) IOW i think you're right. Bye, bearophile Thanks, artur [1] Yes, this *will* cause bugs. But what's the alternative? A strongly typed C-string type would help catching most non-zero-terminated strings, but would need casts too (eg when initialized from literals) and still not help with the escaping references (libraries keeping the pointer around internally).
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
