Re: Please help me with improving dlang.org
On 2015-01-19 03:22, Andrei Alexandrescu wrote: OK, the current attempt has no gradient at all. Probably too flat? -- No, not really. But now the top menu item looks out of place. And the bottom border of the menu ... doesn't look right. I would guess you can just remove it. Although I still like the old design better. But the collapsible menu might be a good idea. -- /Jacob Carlborg
Bug with nested static class referencing?
Greetings
I hit what looks like a probable DMD bug. When I reduced with help from
dustmite I get something like this. Can someone tell me if this is a bug or
am I doing something illegal?
class A {
B.BB b;
}
class B: A {
static class BB {}
}
When I compile I get:
test.d(2): Error: no property 'BB' for type 'test.B'
test.d(2): Error: B.BB is used as a type
Regards
- Puneet
Re: The ugly truth about ddoc
On 01/18/2015 06:18 PM, Andrei Alexandrescu wrote: A general plea about ddoc: Please don't change its behavior; a whole book depends on how it behaves. :) There were silent changes in the past, which made me find workarounds and change the way I use ddoc. Ali
Re: [DRAFT] This Week in D - Jan 18
On Monday, 19 January 2015 at 01:42:58 UTC, Adam D. Ruppe wrote: Anyone like to do a quick proofread of the next edition of This Week in D? http://arsdnet.net/this-week-in-d/jan-18.html Do NOT post this publically yet - it is just a draft, I want to do the broad public release/announcement either later tonight or first thing tomorrow morning. Refresh it btw to get new CSS, I made a minor change on the link color, see if you like the plain better. Also btw this is static content served with pre-gzip. We should use that technique on the D site too! s/demonstrats/demonstrates
Re: Please help me with improving dlang.org
On 1/18/15 8:57 PM, Adam D. Ruppe wrote: On Monday, 19 January 2015 at 04:18:02 UTC, Andrei Alexandrescu wrote: Wati, what resizing stuff? -- Andrei Resize the browser and the sidebars disappear when there's no longer enough room to reasonably fit them. It is important for readability on mobile so a really good thing to have (for the people who use the mobile browsers). Where is that implemented? Is there a pull request? -- Andrei
Re: Please help me with improving dlang.org
On Monday, 19 January 2015 at 04:18:02 UTC, Andrei Alexandrescu wrote: Wati, what resizing stuff? -- Andrei Resize the browser and the sidebars disappear when there's no longer enough room to reasonably fit them. It is important for readability on mobile so a really good thing to have (for the people who use the mobile browsers).
Re: [DRAFT] This Week in D - Jan 18
Under statistics, both links say "bugs fixed" On Monday, 19 January 2015 at 01:42:58 UTC, Adam D. Ruppe wrote: Anyone like to do a quick proofread of the next edition of This Week in D? http://arsdnet.net/this-week-in-d/jan-18.html Do NOT post this publically yet - it is just a draft, I want to do the broad public release/announcement either later tonight or first thing tomorrow morning. Refresh it btw to get new CSS, I made a minor change on the link color, see if you like the plain better. Also btw this is static content served with pre-gzip. We should use that technique on the D site too!
Re: Can D get on XBone and PS4?
On 19/01/2015 5:13 p.m., Manu via Digitalmars-d wrote: On 19 January 2015 at 09:50, Rikki Cattermole via Digitalmars-d wrote: On 19/01/2015 12:47 p.m., Manu via Digitalmars-d wrote: On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d wrote: On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote: On 18 January 2015 at 19:56, Joakim via Digitalmars-d wrote: On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote: At Remedy, we ran D code on xbone with no opposition from MS. For xbone, we wanted to maintain compatibility with the rest of our MSVC code, which meant we needed to produce COFF output that the MSVC linker accepts. Walter implemented DMD-Win64 with these requirements in mind. PS4 should be easier using LDC, but I don't know if Sony would take issue with this. I expect them to take less issue than MS, so I'd give good odd's that they'd be fine with it. Short answer, D works on modern consoles just fine, and there were no political blocks for us. GC is a demonstrated problem; avoid it. DMD's codegen is also a problem; it uses x87 to perform operations, despite the fact the x64 ABI uses SSE regs for float passing. That results in a lot of register switching, and poor float performance as a result. As an (awkward) workaround, you can use explicit SSE intrinsics to keep working in XMM, but I haven't tested the optimiser's quality in that case, and the std library obviously doesn't do that. Thanks for the detailed answer. Sounds like the only thing holding D back is someone putting in the effort to integrate it with the console runtime and APIs. It's not going to be me, as I haven't owned a console or even played a console game in a decade. Yes, I know I'm an old fogey. :) I don't think there's any particularly compelling reason to make runtime calls from D. You can link C/C++ and D code together just fine. If you're a gamedev, there's a very high chance that you already have an engine (presumably C/C++) in place. You'll need to bind the engine api, not the OS api. Trouble with the console OS api's are that they're protected by NDA; it would probably be pretty dubious to release any such foreign language binding here, so each studio would have to do that work themselves... unless it were posted on the official dev forums or something. $ dub add-local . Could be rather useful here! I don't know what that means? You don't need to register packages of the dub repository for dub to be able to use a package. In this case its registered locally instead. In terms of NDA's, can definitely be used to make e.g. wrappers of bindings private and then use them to publically distribute the usage of them. ...I don't follow. Because of an NDA's, we may not be able to release bindings to the native API's but we can release wrapper interfaces. So long as they are not one for one. Atleast theoretically. Assuming the bindings/wrapper implementation is distributed via official means e.g. a forum which is non public and approved of. Dub could be used, as the build manager for any projects using the bindings. As long as when the bindings/wrappers are released, they are built as dub packages. Once downloaded they merely need to be added as a local package into dub. Ensuring NDA and the ability to public publically engines and such.
Re: while(...){ ... }else ...
On Sunday, 18 January 2015 at 18:16:47 UTC, Marc Schütz wrote:
Unfortunately, this would break existing code:
if(some_condition)
while(some_other_condition) {
// ...
}
else
// ...
Currently, the `else` branch belongs to the `if`; with your
proposal, it would belong to the `while`.
An `else` always attaches to the closest construct where it can
be accepted; AFAICS, this cannot be changed without making the
language grammar context-sensitive (it would require parsing
`while` inside an `if` differently from other `while`s).
Compiler have simplification of CFG passes that makes this
feature irrelevant in practice.
Re: The ugly truth about ddoc
On 1/18/15 7:28 PM, Mike wrote: On Monday, 19 January 2015 at 03:02:37 UTC, Andrei Alexandrescu wrote: Destroy!!! What's not working? -- Andrei For starters, simple, accurate instructions in dlang.org's Readme.md file. Mike "There's a bug report for that." https://issues.dlang.org/show_bug.cgi?id=14006 That's a separate issue. I'm referring to problems like this: https://issues.dlang.org/show_bug.cgi?id=13436 The instructions are absent in readme.md and wrong or broken in contributing.md. So, you might be wondering, why don't I fix it. Answer, because I don't know what it should be. This should be fixed by someone who already knows the build process, so others who don't know have a something working to start with, and can eventually inherit the maintenance and knowledge so they, themselves, can pass it on to others. Agreed. If there's anything to add, add to 13436. -- Andrei
Re: post qualifier and template constraint limitation, is there a reason ?
On Monday, 19 January 2015 at 03:57:14 UTC, Walter Bright wrote: No. Constraints belong after the template declaration, not embedded in the template's implementation. Furthermore, there's no useful purpose to enabling style wars and then requiring people to put one way in their coding standard document. IMO style is the role of the formater. Prompting the programmer with "don't write this, write that instead" only crate reaction à la "If you know what I meant, why don't you compile that you asshole ?"
Re: Please help me with improving dlang.org
On 1/18/15 7:18 PM, Adam D. Ruppe wrote: On Monday, 19 January 2015 at 03:06:35 UTC, Andrei Alexandrescu wrote: On 1/18/15 6:50 PM, DaveG wrote: https://dl.dropboxusercontent.com/u/114394/D-site/redesign/index.html All - what do you think of dropping the background image and use the DaveG's telluric background for menu? I like it, and also the resizing stuff covers what I did so if his changes go through, I can close my PR too. That's a win. Wati, what resizing stuff? -- Andrei
Re: Can D get on XBone and PS4?
On 19 January 2015 at 09:50, Rikki Cattermole via Digitalmars-d wrote: > On 19/01/2015 12:47 p.m., Manu via Digitalmars-d wrote: >> >> On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d >> >> wrote: >>> >>> On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote: On 18 January 2015 at 19:56, Joakim via Digitalmars-d wrote: > > > On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d > wrote: >> >> >> >> At Remedy, we ran D code on xbone with no opposition from MS. >> For xbone, we wanted to maintain compatibility with the rest of our >> MSVC code, which meant we needed to produce COFF output that the MSVC >> linker accepts. Walter implemented DMD-Win64 with these requirements >> in mind. >> PS4 should be easier using LDC, but I don't know if Sony would take >> issue with this. I expect them to take less issue than MS, so I'd give >> good odd's that they'd be fine with it. >> >> Short answer, D works on modern consoles just fine, and there were no >> political blocks for us. GC is a demonstrated problem; avoid it. DMD's >> codegen is also a problem; it uses x87 to perform operations, despite >> the fact the x64 ABI uses SSE regs for float passing. That results in >> a lot of register switching, and poor float performance as a result. >> As an (awkward) workaround, you can use explicit SSE intrinsics to >> keep working in XMM, but I haven't tested the optimiser's quality in >> that case, and the std library obviously doesn't do that. > > > > > Thanks for the detailed answer. Sounds like the only thing holding D > back > is someone putting in the effort to integrate it with the console > runtime > and APIs. It's not going to be me, as I haven't owned a console or > even > played a console game in a decade. Yes, I know I'm an old fogey. :) I don't think there's any particularly compelling reason to make runtime calls from D. You can link C/C++ and D code together just fine. If you're a gamedev, there's a very high chance that you already have an engine (presumably C/C++) in place. You'll need to bind the engine api, not the OS api. Trouble with the console OS api's are that they're protected by NDA; it would probably be pretty dubious to release any such foreign language binding here, so each studio would have to do that work themselves... unless it were posted on the official dev forums or something. >>> >>> >>> >>> $ dub add-local . >>> Could be rather useful here! >> >> >> I don't know what that means? > > > You don't need to register packages of the dub repository for dub to be able > to use a package. In this case its registered locally instead. > In terms of NDA's, can definitely be used to make e.g. wrappers of bindings > private and then use them to publically distribute the usage of them. ...I don't follow.
Trivial Issue (Must be fixed my committers)
Simple spelling error, but can't be fixed by a pull request. https://issues.dlang.org/show_bug.cgi?id=9118 Mike
Re: post qualifier and template constraint limitation, is there a reason ?
On 1/18/2015 7:07 PM, deadalnix wrote: On Monday, 19 January 2015 at 02:24:00 UTC, Walter Bright wrote: On 1/18/2015 12:46 AM, Brian Schott wrote: On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright wrote: Sounds like a good idea. If I wasn't clear, I think that class change was a mistake. Now that I see from that pull request that the ugly syntax was the original, I'm not so sure. The dfix feature I'm planning is to convert class A if (B) : C to class A : C if (B) The other way around. Consider: class A(T) : C!(args), D!(more args), E!(lots of stuff) if (B) the 'if' becomes significantly separated from A. That's exactly why I thing both should be allowed. No. Constraints belong after the template declaration, not embedded in the template's implementation. Furthermore, there's no useful purpose to enabling style wars and then requiring people to put one way in their coding standard document.
Re: Idea: featuring forum content on dlang.org?
On Monday, 19 January 2015 at 02:34:32 UTC, Andrei Alexandrescu wrote: With all this discussion on more dynamic content on dlang.org, I sat down (figuratively; I've been on a hike today) and thought - what is dynamic about D? So it hit me like a hammer: * Forum discussions (this!) * github traffic * bugzilla traffic * more recently, Adam's weekly newsletter. We already have twitter which is nice. Adding some of the above to the homepage would be awesome. What do you all think? Andrei Great idea. In my opinion, priority should be given to answering the question "what are people doing with D?" Announcements of the latest additions and updates for Dub, plus links to posts like house hunting with D, all make a good impression.
Re: Please help me with improving dlang.org
On 19/01/2015 4:49 p.m., Walter Bright wrote: On 1/18/2015 6:07 PM, Rikki Cattermole wrote: When you have a headache and not in a really good head space it can hurt. Hope you feel better soon. I am slowly, thanks. Really I just need to start working getting Cmsed and friends back into good shape for GSOC.
Re: Please help me with improving dlang.org
On 1/18/2015 6:07 PM, Rikki Cattermole wrote: When you have a headache and not in a really good head space it can hurt. Hope you feel better soon.
Re: Idea: featuring forum content on dlang.org?
On Monday, 19 January 2015 at 02:34:32 UTC, Andrei Alexandrescu wrote: With all this discussion on more dynamic content on dlang.org, I sat down (figuratively; I've been on a hike today) and thought - what is dynamic about D? So it hit me like a hammer: * Forum discussions (this!) * github traffic * bugzilla traffic * more recently, Adam's weekly newsletter. We already have twitter which is nice. Adding some of the above to the homepage would be awesome. What do you all think? Andrei Absolutely. Don't let anything note worthy go unmissed. Let D developers know that D is constantly changing things around the world and not just the forums. Add content from other websites, articles, etc. Just let people know that D isn't dead. And that the front of the page proves it.
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 03:02:37 UTC, Andrei Alexandrescu wrote: Destroy!!! What's not working? -- Andrei For starters, simple, accurate instructions in dlang.org's Readme.md file. Mike "There's a bug report for that." https://issues.dlang.org/show_bug.cgi?id=14006 That's a separate issue. I'm referring to problems like this: https://issues.dlang.org/show_bug.cgi?id=13436 The instructions are absent in readme.md and wrong or broken in contributing.md. So, you might be wondering, why don't I fix it. Answer, because I don't know what it should be. This should be fixed by someone who already knows the build process, so others who don't know have a something working to start with, and can eventually inherit the maintenance and knowledge so they, themselves, can pass it on to others. Mike
Re: Please help me with improving dlang.org
On Monday, 19 January 2015 at 03:06:35 UTC, Andrei Alexandrescu wrote: On 1/18/15 6:50 PM, DaveG wrote: https://dl.dropboxusercontent.com/u/114394/D-site/redesign/index.html All - what do you think of dropping the background image and use the DaveG's telluric background for menu? I like it, and also the resizing stuff covers what I did so if his changes go through, I can close my PR too. That's a win.
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 03:01:44 UTC, Andrei Alexandrescu
wrote:
No personal aspect to this. What hex colors did you use? --
background-color: #6E6E6E;
And I cleaned:
#cssmenu > ul > li > a {
font-size: 14px;
display: block;
background:
url("http://erdani.com/d/images/xpattern.png.pagespeed.ic.QEXJsY5pYW.png";)
repeat scroll left top transparent;
border-right: 1px solid #893A28;
border-width: medium 1px 1px;
border-style: none solid solid;
border-color: -moz-use-text-color #893A28 #893A28;
-moz-border-top-colors: none;
-moz-border-right-colors: none;
-moz-border-bottom-colors: none;
-moz-border-left-colors: none;
border-image: none;
color: #FFF;
text-shadow: 0px -1px 1px #751D0C;
}
to
#cssmenu > ul > li > a {
font-size: 14px;
display: block;
color: #FFF;
text-shadow: 0px -1px 1px #751D0C;
}
Matheus.
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: TL;DR: I've uploaded new menu colors at http://erdani.com/d/, this time aiming for a more martian red ethos. Please let me know. == So I was looking at the css today (original at http://paste.ofcode.org/fHGT24YASrWu3rnMYLdm4C taken from the zip at http://cssmenumaker.com/menu/modern-jquery-accordion-menu) and it was quite unwieldy to experiment with. For example, the same color appears hardcoded in a number of places; whenever changing one I'd need to change all, or miss some important instances (as it happened with my first experiment). I'm sure experts must have tools for allowing things like variables and macros for css creation. Indeed there are a number of CSS editors that features things like variables, substitutions, and code generations, but most come at a cost and require quite some involvement. So I slapped something much simpler together using... ddoc. 1. I aded this at the top of the original file: Ddoc and then this at the bottom: Macros: DDOC=$(BODY) DDOC_COMMENT=/*$0*/ ESCAPES=//>/ /&/&/ then saved the file as cssmenu.css.dd. Now I suddenly had a file compilable with ddoc, which produced itself (sans the heading and the macros). Here's the cmdline: dmd -c -o- -Dfweb/css/cssmenu.css css/cssmenu.css.dd It's a bit of a bummer that I need to define three unintuitive macros to get idempotent generation, but I guess that's that. We should document that somewhere. 2. Now the fun begins. Now with macros I could define things like variables and even functions, and change all by changing one. Cool! So I started looking for all colors in the document and converted them to macros. After a short time I had http://paste.ofcode.org/3agBQ3t6C3UJsqMfRe4GeQL working. With that in hand, it was trivially easy to test different colors and see how they impact the look. The result is as I mentioned at http://erdani.com/d. I trust you'll hate the colors but maybe not the hack. So, may I add a pull request of this without anyone having an apoplexy attack? When we pass the site for styling we can pass the generated css. Andrei Red colour is hard to work with generally. It takes too much attention. It goes well with white and grey colours. Though, here is some colours for you to try: https://color.adobe.com/create/color-wheel/?base=2&rule=Custom&selected=4&name=My%20Color%20Theme&mode=rgb&rgbvalues=0.7,0.22200669464295397,0.1097099201844362,0.6268360119554587,1,0.5314703422197685,0.125290070947203,1,0.4581047763190884,0.13626074345941347,0.4015373174033305,0.8,0.3049403467128378,0.4400712229615978,0.7&swatchOrder=0,1,2,3,4 I know it is hard to accept change though, for more professional look, many changes would require on the site. This is an example for Phobos documentation: http://php.net/manual/en/function.shm-attach.php We could use Open Sans font as well maybe from Google Fonts. I mostly write CSS, JS, HTML by hand instead of using frameworks. So, I am sorry if the tools in the hand are not giving enough flexibility.
Re: The ugly truth about ddoc
On 1/18/15 7:12 PM, Ary Borenszweig wrote: On 1/18/15 11:18 PM, Andrei Alexandrescu wrote: TL;DR: I've uploaded new menu colors at http://erdani.com/d/, this time aiming for a more martian red ethos. Please let me know. == So I was looking at the css today (original at http://paste.ofcode.org/fHGT24YASrWu3rnMYLdm4C taken from the zip at http://cssmenumaker.com/menu/modern-jquery-accordion-menu) and it was quite unwieldy to experiment with. For example, the same color appears hardcoded in a number of places; whenever changing one I'd need to change all, or miss some important instances (as it happened with my first experiment). I'm sure experts must have tools for allowing things like variables and macros for css creation. Sass (http://sass-lang.com/) and Less (http://lesscss.org/) comes to my mind. Any decent web framework comes with support for them. Yah. The ones I found were paid. My point is ddoc was there and fit the job perfectly well. I think you will eventually find that ddoc is turing-complete and will implement one of the above transpilers in it. It's not, but irony gotten :o). And css minification isn't just about gzip. It's also about removing whitespace and compacting stuff. Can you code a ddoc macro for that? This is a confusion - css minification is a separate topic altogether; I got to it as a drive-by optimization and many people here thought I need to spend the next quarter on traffic improvements. To answer: it is not possible to do that with ddoc macros. Andrei
Re: [DRAFT] This Week in D - Jan 18
On Monday, 19 January 2015 at 01:42:58 UTC, Adam D. Ruppe wrote:
Anyone like to do a quick proofread of the next edition of This
Week in D?
float divideBy(float divisor, float dividend) {
return dividend / dividend; <-- not a very interesting
mathematical operation here!
Re: The ugly truth about ddoc
On 1/18/15 11:18 PM, Andrei Alexandrescu wrote: TL;DR: I've uploaded new menu colors at http://erdani.com/d/, this time aiming for a more martian red ethos. Please let me know. == So I was looking at the css today (original at http://paste.ofcode.org/fHGT24YASrWu3rnMYLdm4C taken from the zip at http://cssmenumaker.com/menu/modern-jquery-accordion-menu) and it was quite unwieldy to experiment with. For example, the same color appears hardcoded in a number of places; whenever changing one I'd need to change all, or miss some important instances (as it happened with my first experiment). I'm sure experts must have tools for allowing things like variables and macros for css creation. Sass (http://sass-lang.com/) and Less (http://lesscss.org/) comes to my mind. Any decent web framework comes with support for them. I think you will eventually find that ddoc is turing-complete and will implement one of the above transpilers in it. And css minification isn't just about gzip. It's also about removing whitespace and compacting stuff. Can you code a ddoc macro for that?
Re: post qualifier and template constraint limitation, is there a reason ?
On Monday, 19 January 2015 at 02:24:00 UTC, Walter Bright wrote: On 1/18/2015 12:46 AM, Brian Schott wrote: On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright wrote: Sounds like a good idea. If I wasn't clear, I think that class change was a mistake. Now that I see from that pull request that the ugly syntax was the original, I'm not so sure. The dfix feature I'm planning is to convert class A if (B) : C to class A : C if (B) The other way around. Consider: class A(T) : C!(args), D!(more args), E!(lots of stuff) if (B) the 'if' becomes significantly separated from A. That's exactly why I thing both should be allowed.
Re: Please help me with improving dlang.org
On Monday, 19 January 2015 at 02:22:33 UTC, Andrei Alexandrescu wrote: On 1/18/15 11:43 AM, Jacob Carlborg wrote: On 2015-01-18 17:21, Andrei Alexandrescu wrote: Suggestions on how to make it better? -- Andrei Something flat (i.e. no gradient) or with less difference between the colors in the gradient. OK, the current attempt has no gradient at all. Probably too flat? -- Andrei Much better in my opinion.
Re: Please help me with improving dlang.org
On 1/18/15 6:50 PM, DaveG wrote: Here's where I'm at. The menus don't use javascript (except when the screen gets so small it needs a button to open the navigation, the button uses js). It scales with screen size and should work on mobile (untested) - I changed doctype to html5 and added metatags for mobile. https://dl.dropboxusercontent.com/u/114394/D-site/redesign/index.html I think I know why no javascript. Currently the *.js files are loaded from /js/, i.e. absolute path. Change that to relative path and it'll work. All - what do you think of dropping the background image and use the DaveG's telluric background for menu? Andrei
Re: Please help me with improving dlang.org
On Monday, 19 January 2015 at 02:10:06 UTC, Mike wrote: On Monday, 19 January 2015 at 02:00:52 UTC, Andrei Alexandrescu wrote: 2) Aside from the documentation generated from the source code, why does the website need to be "built"? IMO a static website like dlang.org shouldn't need any additional tools other than a browser and an image editor. I may explore some options later, but only after 1) is done. The short answer is because there's no robust inclusion and code reuse solution at HTML level. Would it be a horrible idea to render DDoc in javascript? Answer, yes! vibe.d is where it's at. Mike
Re: Idea: featuring forum content on dlang.org?
On 1/18/15 6:47 PM, MattCoder wrote: On Monday, 19 January 2015 at 02:34:32 UTC, Andrei Alexandrescu wrote: With all this discussion on more dynamic content on dlang.org, I sat down (figuratively; I've been on a hike today) and thought - what is dynamic about D? Are you becoming a web-developer? :) We already have twitter which is nice. Adding some of the above to the homepage would be awesome. What do you all think? Yes, it could be nice, but you do you have in mind? Put for example the last 10 posts of the forum on the main page? Something like that. Or maybe the last 10 topics because it's easy the last 10 posts are on the same (inane) topic. Brainstorming mode!! -- Andrei
Re: The ugly truth about ddoc
On 1/18/15 6:46 PM, Mike wrote: On Monday, 19 January 2015 at 02:36:35 UTC, Andrei Alexandrescu wrote: My only real complaint about the ddoc site is that the build process is pure evil. I can second that. I haven't tried in the past week, but I've been unable to build the site, stopping the doc pulls I wanted to make in their tracks. Destroy!!! What's not working? -- Andrei For starters, simple, accurate instructions in dlang.org's Readme.md file. Mike "There's a bug report for that." https://issues.dlang.org/show_bug.cgi?id=14006 Andrei
Re: The ugly truth about ddoc
On 1/18/15 6:43 PM, MattCoder wrote: On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: TL;DR: I've uploaded new menu colors at http://erdani.com/d/, this time aiming for a more martian red ethos. Please let me know. Well I'd prefer less red-ish: http://i.imgur.com/AIvcoWl.png But you know this is a personal thing, and if you looking for martian aspect so you're ok. Anyway this menu is better than your previous one. :) No personal aspect to this. What hex colors did you use? -- Andrei
Re: Please help me with improving dlang.org
On Monday, 19 January 2015 at 02:21:41 UTC, Andrei Alexandrescu wrote: On 1/18/15 11:15 AM, Adam D. Ruppe wrote: On Sunday, 18 January 2015 at 17:56:41 UTC, aldanor wrote: And yet another thing you gain with (most) frameworks is having access to the original SASS/LESS. I think that's a con, actually. My biggest problem with contributing to the dlang website is that I have to do it blind - it won't make on my computer. I agree about SASS and other tools. There are so many now you have to learn all of them (or none, in my case). Many years ago I wrote primitive script to do what SASS eventually did for CSS. The added features were nice, but barley justified the added complexity and build process. As soon as I joined a team I abandoned it completely. They can be useful particularly for larger/long-term projects, but it's a steep upfront cost and is particularly frustrating for people who just need to make minor changes. This has been a continuous source of annoyance for me. Seems like whenever I turn my back the site build gets broken. I was worried about that, but I actually had no problem. I'm on Windows. I cloned your better-menus, had dub build dpl-docs.exe, and ran the win32 makefile. Here's where I'm at. The menus don't use javascript (except when the screen gets so small it needs a button to open the navigation, the button uses js). It scales with screen size and should work on mobile (untested) - I changed doctype to html5 and added metatags for mobile. https://dl.dropboxusercontent.com/u/114394/D-site/redesign/index.html
Re: Idea: featuring forum content on dlang.org?
On Monday, 19 January 2015 at 02:34:32 UTC, Andrei Alexandrescu wrote: With all this discussion on more dynamic content on dlang.org, I sat down (figuratively; I've been on a hike today) and thought - what is dynamic about D? Are you becoming a web-developer? :) We already have twitter which is nice. Adding some of the above to the homepage would be awesome. What do you all think? Yes, it could be nice, but you do you have in mind? Put for example the last 10 posts of the forum on the main page? Matheus.
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 02:36:35 UTC, Andrei Alexandrescu wrote: On 1/18/15 6:32 PM, Meta wrote: On Monday, 19 January 2015 at 02:25:23 UTC, Adam D. Ruppe wrote: On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: I'm sure experts must have tools for allowing things like variables and macros for css creation. My css macro expander (http://code.dlang.org/packages/cssexpand) was in part inspired by ddoc actually, so this is no surprise to me... My only real complaint about the ddoc site is that the build process is pure evil. I can second that. I haven't tried in the past week, but I've been unable to build the site, stopping the doc pulls I wanted to make in their tracks. Destroy!!! What's not working? -- Andrei It's late now, but I'll try building tomorrow and see what doesn't work.
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 02:36:35 UTC, Andrei Alexandrescu wrote: My only real complaint about the ddoc site is that the build process is pure evil. I can second that. I haven't tried in the past week, but I've been unable to build the site, stopping the doc pulls I wanted to make in their tracks. Destroy!!! What's not working? -- Andrei For starters, simple, accurate instructions in dlang.org's Readme.md file. Mike
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: TL;DR: I've uploaded new menu colors at http://erdani.com/d/, this time aiming for a more martian red ethos. Please let me know. Well I'd prefer less red-ish: http://i.imgur.com/AIvcoWl.png But you know this is a personal thing, and if you looking for martian aspect so you're ok. Anyway this menu is better than your previous one. :) Matheus.
Re: Please help me with improving dlang.org
On 1/18/15 6:37 PM, MattCoder wrote: On Monday, 19 January 2015 at 02:19:30 UTC, Andrei Alexandrescu wrote: On 1/18/15 6:09 PM, MattCoder wrote: On Monday, 19 January 2015 at 01:41:04 UTC, Andrei Alexandrescu wrote: Content discussion to follow soon. -- Andrei As I asked in another Topic without any answer, I wasn't able to find (or at least is not easily visible) anything related to "CONTRIBUTE" even on sitemap. I think there should be a button for this on the main site. Great idea. Could you please put that in bugzilla, it's important and shouldn't be forgotten. -- Andrei My first time using bugzilla: https://issues.dlang.org/show_bug.cgi?id=14006 Please could anyone tell if I did right? Yes. Next step: fix it! :o) -- Andrei
Re: The ugly truth about ddoc
On 1/18/15 6:25 PM, Adam D. Ruppe wrote: On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: I'm sure experts must have tools for allowing things like variables and macros for css creation. My css macro expander (http://code.dlang.org/packages/cssexpand) was in part inspired by ddoc actually, so this is no surprise to me... Awesome. My only real complaint about the ddoc site is that the build process is pure evil. Let's angelize it. Speak up. What's the matter? Andrei
Re: Please help me with improving dlang.org
On Monday, 19 January 2015 at 02:19:30 UTC, Andrei Alexandrescu wrote: On 1/18/15 6:09 PM, MattCoder wrote: On Monday, 19 January 2015 at 01:41:04 UTC, Andrei Alexandrescu wrote: Content discussion to follow soon. -- Andrei As I asked in another Topic without any answer, I wasn't able to find (or at least is not easily visible) anything related to "CONTRIBUTE" even on sitemap. I think there should be a button for this on the main site. Great idea. Could you please put that in bugzilla, it's important and shouldn't be forgotten. -- Andrei My first time using bugzilla: https://issues.dlang.org/show_bug.cgi?id=14006 Please could anyone tell if I did right? Matheus.
Re: The ugly truth about ddoc
On 1/18/15 6:32 PM, Meta wrote: On Monday, 19 January 2015 at 02:25:23 UTC, Adam D. Ruppe wrote: On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: I'm sure experts must have tools for allowing things like variables and macros for css creation. My css macro expander (http://code.dlang.org/packages/cssexpand) was in part inspired by ddoc actually, so this is no surprise to me... My only real complaint about the ddoc site is that the build process is pure evil. I can second that. I haven't tried in the past week, but I've been unable to build the site, stopping the doc pulls I wanted to make in their tracks. Destroy!!! What's not working? -- Andrei
Idea: featuring forum content on dlang.org?
With all this discussion on more dynamic content on dlang.org, I sat down (figuratively; I've been on a hike today) and thought - what is dynamic about D? So it hit me like a hammer: * Forum discussions (this!) * github traffic * bugzilla traffic * more recently, Adam's weekly newsletter. We already have twitter which is nice. Adding some of the above to the homepage would be awesome. What do you all think? Andrei
Re: The ugly truth about ddoc
On 1/18/2015 6:18 PM, Andrei Alexandrescu wrote: TL;DR: I've uploaded new menu colors at http://erdani.com/d/, this time aiming for a more martian red ethos. Please let me know. Nobody likes my taste in color, so I'll not pass judgement! == So I was looking at the css today (original at http://paste.ofcode.org/fHGT24YASrWu3rnMYLdm4C taken from the zip at http://cssmenumaker.com/menu/modern-jquery-accordion-menu) and it was quite unwieldy to experiment with. For example, the same color appears hardcoded in a number of places; whenever changing one I'd need to change all, or miss some important instances (as it happened with my first experiment). I'm sure experts must have tools for allowing things like variables and macros for css creation. Indeed there are a number of CSS editors that features things like variables, substitutions, and code generations, but most come at a cost and require quite some involvement. So I slapped something much simpler together using... ddoc. 1. I aded this at the top of the original file: Ddoc and then this at the bottom: Macros: DDOC=$(BODY) DDOC_COMMENT=/*$0*/ ESCAPES=//>/ /&/&/ then saved the file as cssmenu.css.dd. Now I suddenly had a file compilable with ddoc, which produced itself (sans the heading and the macros). Here's the cmdline: dmd -c -o- -Dfweb/css/cssmenu.css css/cssmenu.css.dd It's a bit of a bummer that I need to define three unintuitive macros to get idempotent generation, but I guess that's that. We should document that somewhere. Yes, very nice. 2. Now the fun begins. Now with macros I could define things like variables and even functions, and change all by changing one. Cool! So I started looking for all colors in the document and converted them to macros. After a short time I had http://paste.ofcode.org/3agBQ3t6C3UJsqMfRe4GeQL working. With that in hand, it was trivially easy to test different colors and see how they impact the look. The result is as I mentioned at http://erdani.com/d. I trust you'll hate the colors but maybe not the hack. Consider me meh on the colors but love the hack! So, may I add a pull request of this without anyone having an apoplexy attack? When we pass the site for styling we can pass the generated css. Damn the torpedos, full speed ahead!
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 02:25:23 UTC, Adam D. Ruppe wrote: On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: I'm sure experts must have tools for allowing things like variables and macros for css creation. My css macro expander (http://code.dlang.org/packages/cssexpand) was in part inspired by ddoc actually, so this is no surprise to me... My only real complaint about the ddoc site is that the build process is pure evil. I can second that. I haven't tried in the past week, but I've been unable to build the site, stopping the doc pulls I wanted to make in their tracks.
Re: Use proper frameworks for building dlang.org
On 1/18/15 10:49 AM, Jacob Carlborg wrote: On 2015-01-18 18:23, Andrei Alexandrescu wrote: Heheh, way to use Archuduke's Ferdinand assassination :o). I'm sorry Jacob but this one is really out there. DDoc has nothing with this, and to the extent it does it actually helps. No it has not, but other strange solutions you're coming up with for CSS minification and gzip. So now minification and gzipping are the culprit? I don't quite understand. I'm not going to touch the code for the web site as long as it's written in Ddoc. Simple as that. I understand. Now there are a couple of issues here worth mentioning. 1. Technical arguments are good, but this sounds a bit like an ideological position. I'd have difficulty resonating with that. 2. We all know from math that negating the hypothesis doesn't necessarily lead to negating the conclusion :o). So if we switch to Rails there's no guarantee you will contribute after all; or it's possible you will, just not a lot, and then it's me holding the bag. 3. This rigidity doesn't quite bode well. Simply put, if you led a project, would you want to pave the way to work with a guy with a similar stance? Andrei
Re: [DRAFT] This Week in D - Jan 18
On 1/18/15 5:42 PM, Adam D. Ruppe wrote: Anyone like to do a quick proofread of the next edition of This Week in D? http://arsdnet.net/this-week-in-d/jan-18.html * Unclear which week you're referring to - past or upcoming? Use "this week" and "next week" - right now you use "this week" for both. * http://www.meetup.com/D-Lang-Sillicon-Valley/events/219413448/ may be mentioned * Styling needs work :o). Andrei
Re: post qualifier and template constraint limitation, is there a reason ?
On 1/18/2015 12:16 AM, Daniel Murphy wrote: "Walter Bright" wrote in message news:m9fodo$18lu$1...@digitalmars.com... I don't really know where the class change came from :-( https://github.com/D-Programming-Language/dmd/pull/1227 Thanks for digging it up. I see I missed that one.
Re: The ugly truth about ddoc
On Monday, 19 January 2015 at 02:18:32 UTC, Andrei Alexandrescu wrote: I'm sure experts must have tools for allowing things like variables and macros for css creation. My css macro expander (http://code.dlang.org/packages/cssexpand) was in part inspired by ddoc actually, so this is no surprise to me... My only real complaint about the ddoc site is that the build process is pure evil.
Re: post qualifier and template constraint limitation, is there a reason ?
On 1/18/2015 12:46 AM, Brian Schott wrote: On Sunday, 18 January 2015 at 08:40:19 UTC, Walter Bright wrote: Sounds like a good idea. If I wasn't clear, I think that class change was a mistake. Now that I see from that pull request that the ugly syntax was the original, I'm not so sure. The dfix feature I'm planning is to convert class A if (B) : C to class A : C if (B) The other way around. Consider: class A(T) : C!(args), D!(more args), E!(lots of stuff) if (B) the 'if' becomes significantly separated from A.
Re: Please help me with improving dlang.org
On 1/18/15 11:15 AM, Adam D. Ruppe wrote: On Sunday, 18 January 2015 at 17:56:41 UTC, aldanor wrote: And yet another thing you gain with (most) frameworks is having access to the original SASS/LESS. I think that's a con, actually. My biggest problem with contributing to the dlang website is that I have to do it blind - it won't make on my computer. This has been a continuous source of annoyance for me. Seems like whenever I turn my back the site build gets broken. Right now I have it working smoothly, but I know of a few potential issues. Could you please reply here with your problem(s) and I'll get a robust solution in place? Thanks, Andrei
Re: Please help me with improving dlang.org
On 1/18/15 11:43 AM, Jacob Carlborg wrote: On 2015-01-18 17:21, Andrei Alexandrescu wrote: Suggestions on how to make it better? -- Andrei Something flat (i.e. no gradient) or with less difference between the colors in the gradient. OK, the current attempt has no gradient at all. Probably too flat? -- Andrei
Re: Please help me with improving dlang.org
On 1/18/15 6:09 PM, MattCoder wrote: On Monday, 19 January 2015 at 01:41:04 UTC, Andrei Alexandrescu wrote: Content discussion to follow soon. -- Andrei As I asked in another Topic without any answer, I wasn't able to find (or at least is not easily visible) anything related to "CONTRIBUTE" even on sitemap. I think there should be a button for this on the main site. Great idea. Could you please put that in bugzilla, it's important and shouldn't be forgotten. -- Andrei
The ugly truth about ddoc
TL;DR: I've uploaded new menu colors at http://erdani.com/d/, this time aiming for a more martian red ethos. Please let me know. == So I was looking at the css today (original at http://paste.ofcode.org/fHGT24YASrWu3rnMYLdm4C taken from the zip at http://cssmenumaker.com/menu/modern-jquery-accordion-menu) and it was quite unwieldy to experiment with. For example, the same color appears hardcoded in a number of places; whenever changing one I'd need to change all, or miss some important instances (as it happened with my first experiment). I'm sure experts must have tools for allowing things like variables and macros for css creation. Indeed there are a number of CSS editors that features things like variables, substitutions, and code generations, but most come at a cost and require quite some involvement. So I slapped something much simpler together using... ddoc. 1. I aded this at the top of the original file: Ddoc and then this at the bottom: Macros: DDOC=$(BODY) DDOC_COMMENT=/*$0*/ ESCAPES=//>/ /&/&/ then saved the file as cssmenu.css.dd. Now I suddenly had a file compilable with ddoc, which produced itself (sans the heading and the macros). Here's the cmdline: dmd -c -o- -Dfweb/css/cssmenu.css css/cssmenu.css.dd It's a bit of a bummer that I need to define three unintuitive macros to get idempotent generation, but I guess that's that. We should document that somewhere. 2. Now the fun begins. Now with macros I could define things like variables and even functions, and change all by changing one. Cool! So I started looking for all colors in the document and converted them to macros. After a short time I had http://paste.ofcode.org/3agBQ3t6C3UJsqMfRe4GeQL working. With that in hand, it was trivially easy to test different colors and see how they impact the look. The result is as I mentioned at http://erdani.com/d. I trust you'll hate the colors but maybe not the hack. So, may I add a pull request of this without anyone having an apoplexy attack? When we pass the site for styling we can pass the generated css. Andrei
Re: Please help me with improving dlang.org
On Monday, 19 January 2015 at 02:00:52 UTC, Andrei Alexandrescu wrote: 2) Aside from the documentation generated from the source code, why does the website need to be "built"? IMO a static website like dlang.org shouldn't need any additional tools other than a browser and an image editor. I may explore some options later, but only after 1) is done. The short answer is because there's no robust inclusion and code reuse solution at HTML level. Would it be a horrible idea to render DDoc in javascript? Mike
Re: Please help me with improving dlang.org
On 19/01/2015 2:07 p.m., Walter Bright wrote: On 1/18/2015 1:41 AM, Rikki Cattermole wrote: On 18/01/2015 10:40 p.m., Tofu Ninja wrote: On Sunday, 18 January 2015 at 08:42:30 UTC, Walter Bright wrote: Me like. And I do like the spidery red lines in particular. The red lines were what I particularly disliked, looks old and unclean to me. Also that contrast is awful on the eyes! How can a 1 pixel wide line be awful on the eyes? When you have a headache and not in a really good head space it can hurt.
Re: Please help me with improving dlang.org
On Monday, 19 January 2015 at 01:41:04 UTC, Andrei Alexandrescu wrote: Content discussion to follow soon. -- Andrei As I asked in another Topic without any answer, I wasn't able to find (or at least is not easily visible) anything related to "CONTRIBUTE" even on sitemap. I think there should be a button for this on the main site. Matheus.
Re: Please help me with improving dlang.org
On 1/18/15 4:57 PM, Mike wrote: On Sunday, 18 January 2015 at 02:18:16 UTC, Andrei Alexandrescu wrote: I took the better part of today working on this: https://github.com/D-Programming-Language/dlang.org/pull/780. See demo at http://erdani.com/d/. What do you all think? Is it an improvement over what we have now? I'd appreciate your help with reviewing and pulling this, and also with improving the colors (which I'm terrible at) and page tracking as mentioned in the pull request. What are your primary concerns with the website? I think it would help to know what you are trying to achieve. Good point. 1. The site design/styling is old. Simply changing it is now necessary just as a refresher. 2. Of course, we'd also like things to be better. The chaotic navigation menu on the left was something I long wished to replace with a more modern on. 3. Part of my effort is to replace all manual html ad-hoc styles with styles in the css. That is invisible right now but will become very useful when we pass the site for improvement to a specialist. Personally, although dlang.org isn't particularly pretty, I think its fine. It's the unmaintained and unfinished content that's the real problem, not the aesthetics. I've made a number of PRs to move "unofficial" content to the wiki so it could be better maintained there, and if not maintained, at least appear less official. Thanks! I believe dlang.org's lack of maintenance is partially due to the issues mentioned below. I've tried to do some improvements on dlang.org, and its a PITA. If it were made more convenient, there would be greater participation from me, and likely others. So, I offer the following suggestion: 1) Modify the build scripts and the instructions on dlang.org so that it's abundantly clear how to fork, modify, build, verify, submit PRs without having read verbose instructions and without having to clone and build dmd, druntime, phobos, and other repositories just to get an html page to verify an edit. I would do this myself, but an important prerequisite to updating build scripts and documentation is knowledge, which I have yet to possess. But someone in this community knows. We definitely need to get that working. There are a couple of blocking issues (like the interference of local configuration files on the site build) but I trust we'll get over them soon. 2) Aside from the documentation generated from the source code, why does the website need to be "built"? IMO a static website like dlang.org shouldn't need any additional tools other than a browser and an image editor. I may explore some options later, but only after 1) is done. The short answer is because there's no robust inclusion and code reuse solution at HTML level. Andrei
[DRAFT] This Week in D - Jan 18
Anyone like to do a quick proofread of the next edition of This Week in D? http://arsdnet.net/this-week-in-d/jan-18.html Do NOT post this publically yet - it is just a draft, I want to do the broad public release/announcement either later tonight or first thing tomorrow morning. Refresh it btw to get new CSS, I made a minor change on the link color, see if you like the plain better. Also btw this is static content served with pre-gzip. We should use that technique on the D site too!
Re: Please help me with improving dlang.org
On 1/18/15 3:36 PM, Zach the Mystic wrote: I like the buttons with the dark red gradients on the left. Although the button titles don't seem professional to me, the buttons do. I'm personally interested in seeing the "story" of D told better. I have more of a conscious opinion of the words of the front page than I do of the look-and-feel. Are the words up for discussion here, or just the look-and-feel for now? Content discussion to follow soon. -- Andrei
Re: post qualifier and template constraint limitation, is there a reason ?
On Saturday, January 17, 2015 08:33:49 deadalnix via Digitalmars-d wrote:
> This is accepted :
> auto fun(T)(T T) inout if(...) { ... }
>
> This is not :
> auto fun(T)(T T) if(...) inout { ... }
>
> Is there a reason ?
Well, inout is part of the signature. It's debatable as to whether the
template constraint is, particularly when you consider that what you're
really dealing with is
template fun(T)
if(...)
{
auto fun(T t) inout {...}
}
just with a shorter syntax. And I'd guess that you have trouble remembering
whether the inout goes primarily due to your coding style. I don't think
that I _ever_ put the template constraint on the same line as the signature,
so I've never had any trouble remembering where the function attributes go
in comparison to the template constraint, and it would never have occurred
to me that anyone would have a problem with that.
But in general, I think that having multiple ways to do the same thing needs
a good reason, especially when it means adding a new way to do something,
and I think that the fact that the template constraint isn't really part of
the function signature is a good reason not to allow the function attributes
after it.
- Jonathan M Davis
Re: Please help me with improving dlang.org
On 1/18/2015 1:41 AM, Rikki Cattermole wrote: On 18/01/2015 10:40 p.m., Tofu Ninja wrote: On Sunday, 18 January 2015 at 08:42:30 UTC, Walter Bright wrote: Me like. And I do like the spidery red lines in particular. The red lines were what I particularly disliked, looks old and unclean to me. Also that contrast is awful on the eyes! How can a 1 pixel wide line be awful on the eyes?
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/18/2015 8:34 AM, Andrei Alexandrescu wrote: On 1/18/15 5:44 AM, Jacob Carlborg wrote: On 2015-01-17 18:43, Andrei Alexandrescu wrote: I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- Andrei I'm not sure who made the proposal but Walter created the pull request. Walter and I made the proposal. Could you explain exactly what your problem is. It's also based on Marc Schütz's earlier proposal.
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 02:18:16 UTC, Andrei Alexandrescu wrote: I took the better part of today working on this: https://github.com/D-Programming-Language/dlang.org/pull/780. See demo at http://erdani.com/d/. What do you all think? Is it an improvement over what we have now? I'd appreciate your help with reviewing and pulling this, and also with improving the colors (which I'm terrible at) and page tracking as mentioned in the pull request. What are your primary concerns with the website? I think it would help to know what you are trying to achieve. Personally, although dlang.org isn't particularly pretty, I think its fine. It's the unmaintained and unfinished content that's the real problem, not the aesthetics. I've made a number of PRs to move "unofficial" content to the wiki so it could be better maintained there, and if not maintained, at least appear less official. I believe dlang.org's lack of maintenance is partially due to the issues mentioned below. I've tried to do some improvements on dlang.org, and its a PITA. If it were made more convenient, there would be greater participation from me, and likely others. So, I offer the following suggestion: 1) Modify the build scripts and the instructions on dlang.org so that it's abundantly clear how to fork, modify, build, verify, submit PRs without having read verbose instructions and without having to clone and build dmd, druntime, phobos, and other repositories just to get an html page to verify an edit. I would do this myself, but an important prerequisite to updating build scripts and documentation is knowledge, which I have yet to possess. But someone in this community knows. 2) Aside from the documentation generated from the source code, why does the website need to be "built"? IMO a static website like dlang.org shouldn't need any additional tools other than a browser and an image editor. I may explore some options later, but only after 1) is done. Mike
Re: Please help me with improving dlang.org
On Sun, 18 Jan 2015 23:47:30 + MattCoder via Digitalmars-d wrote: > On Sunday, 18 January 2015 at 21:27:25 UTC, NVolcz wrote: > > Googles pagespeed also gives some nice guidelines: > > https://developers.google.com/speed/pagespeed/insights/?url=dlang.org > > Nice and for image processing/compression I'd like to recommend > this free tool (Win/Linux/Mac): > > http://advsys.net/ken/utils.htm#pngoutkziplicense there are also "optipng" and "advpng". the last comes with MAME, i believe, and using google's zopfli library to squeeze out even more bytes in exchange of big processing times. signature.asc Description: PGP signature
Re: Can D get on XBone and PS4?
On 19/01/2015 12:47 p.m., Manu via Digitalmars-d wrote: On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d wrote: On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote: On 18 January 2015 at 19:56, Joakim via Digitalmars-d wrote: On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote: At Remedy, we ran D code on xbone with no opposition from MS. For xbone, we wanted to maintain compatibility with the rest of our MSVC code, which meant we needed to produce COFF output that the MSVC linker accepts. Walter implemented DMD-Win64 with these requirements in mind. PS4 should be easier using LDC, but I don't know if Sony would take issue with this. I expect them to take less issue than MS, so I'd give good odd's that they'd be fine with it. Short answer, D works on modern consoles just fine, and there were no political blocks for us. GC is a demonstrated problem; avoid it. DMD's codegen is also a problem; it uses x87 to perform operations, despite the fact the x64 ABI uses SSE regs for float passing. That results in a lot of register switching, and poor float performance as a result. As an (awkward) workaround, you can use explicit SSE intrinsics to keep working in XMM, but I haven't tested the optimiser's quality in that case, and the std library obviously doesn't do that. Thanks for the detailed answer. Sounds like the only thing holding D back is someone putting in the effort to integrate it with the console runtime and APIs. It's not going to be me, as I haven't owned a console or even played a console game in a decade. Yes, I know I'm an old fogey. :) I don't think there's any particularly compelling reason to make runtime calls from D. You can link C/C++ and D code together just fine. If you're a gamedev, there's a very high chance that you already have an engine (presumably C/C++) in place. You'll need to bind the engine api, not the OS api. Trouble with the console OS api's are that they're protected by NDA; it would probably be pretty dubious to release any such foreign language binding here, so each studio would have to do that work themselves... unless it were posted on the official dev forums or something. $ dub add-local . Could be rather useful here! I don't know what that means? You don't need to register packages of the dub repository for dub to be able to use a package. In this case its registered locally instead. In terms of NDA's, can definitely be used to make e.g. wrappers of bindings private and then use them to publically distribute the usage of them.
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 21:27:25 UTC, NVolcz wrote: Googles pagespeed also gives some nice guidelines: https://developers.google.com/speed/pagespeed/insights/?url=dlang.org Nice and for image processing/compression I'd like to recommend this free tool (Win/Linux/Mac): http://advsys.net/ken/utils.htm#pngoutkziplicense Matheus.
Re: Can D get on XBone and PS4?
On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d wrote: > On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote: >> >> On 18 January 2015 at 19:56, Joakim via Digitalmars-d >> wrote: >>> >>> On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote: At Remedy, we ran D code on xbone with no opposition from MS. For xbone, we wanted to maintain compatibility with the rest of our MSVC code, which meant we needed to produce COFF output that the MSVC linker accepts. Walter implemented DMD-Win64 with these requirements in mind. PS4 should be easier using LDC, but I don't know if Sony would take issue with this. I expect them to take less issue than MS, so I'd give good odd's that they'd be fine with it. Short answer, D works on modern consoles just fine, and there were no political blocks for us. GC is a demonstrated problem; avoid it. DMD's codegen is also a problem; it uses x87 to perform operations, despite the fact the x64 ABI uses SSE regs for float passing. That results in a lot of register switching, and poor float performance as a result. As an (awkward) workaround, you can use explicit SSE intrinsics to keep working in XMM, but I haven't tested the optimiser's quality in that case, and the std library obviously doesn't do that. >>> >>> >>> >>> Thanks for the detailed answer. Sounds like the only thing holding D >>> back >>> is someone putting in the effort to integrate it with the console runtime >>> and APIs. It's not going to be me, as I haven't owned a console or even >>> played a console game in a decade. Yes, I know I'm an old fogey. :) >> >> >> I don't think there's any particularly compelling reason to make >> runtime calls from D. You can link C/C++ and D code together just >> fine. If you're a gamedev, there's a very high chance that you already >> have an engine (presumably C/C++) in place. You'll need to bind the >> engine api, not the OS api. >> Trouble with the console OS api's are that they're protected by NDA; >> it would probably be pretty dubious to release any such foreign >> language binding here, so each studio would have to do that work >> themselves... unless it were posted on the official dev forums or >> something. > > > $ dub add-local . > Could be rather useful here! I don't know what that means?
Re: Can D get on XBone and PS4?
On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote: On 18 January 2015 at 19:56, Joakim via Digitalmars-d wrote: On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote: At Remedy, we ran D code on xbone with no opposition from MS. For xbone, we wanted to maintain compatibility with the rest of our MSVC code, which meant we needed to produce COFF output that the MSVC linker accepts. Walter implemented DMD-Win64 with these requirements in mind. PS4 should be easier using LDC, but I don't know if Sony would take issue with this. I expect them to take less issue than MS, so I'd give good odd's that they'd be fine with it. Short answer, D works on modern consoles just fine, and there were no political blocks for us. GC is a demonstrated problem; avoid it. DMD's codegen is also a problem; it uses x87 to perform operations, despite the fact the x64 ABI uses SSE regs for float passing. That results in a lot of register switching, and poor float performance as a result. As an (awkward) workaround, you can use explicit SSE intrinsics to keep working in XMM, but I haven't tested the optimiser's quality in that case, and the std library obviously doesn't do that. Thanks for the detailed answer. Sounds like the only thing holding D back is someone putting in the effort to integrate it with the console runtime and APIs. It's not going to be me, as I haven't owned a console or even played a console game in a decade. Yes, I know I'm an old fogey. :) I don't think there's any particularly compelling reason to make runtime calls from D. You can link C/C++ and D code together just fine. If you're a gamedev, there's a very high chance that you already have an engine (presumably C/C++) in place. You'll need to bind the engine api, not the OS api. Trouble with the console OS api's are that they're protected by NDA; it would probably be pretty dubious to release any such foreign language binding here, so each studio would have to do that work themselves... unless it were posted on the official dev forums or something. $ dub add-local . Could be rather useful here! If I had to say there was one thing holding D back, it's Win64 support in LLVM. We really need LDC for comprehensive gamedev. DMD is okay for game-logic and script-like code, but the codegen isn't good enough to do really hot work. Win64 is almost there in LLVM, the only thing missing that I know of is CV8 debuginfo. Without that, we can't debug... which is like, really important >_<
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic wrote: I'm working on an article/DIP which actually goes further than the new DIP25, but is nonetheless completely compatible with it. I'll have the article in a day or two. Here it is: http://forum.dlang.org/thread/xjhvpmjrlwhhgeqyo...@forum.dlang.org
Re: Please help me with improving dlang.org
I like the buttons with the dark red gradients on the left. Although the button titles don't seem professional to me, the buttons do. I'm personally interested in seeing the "story" of D told better. I have more of a conscious opinion of the words of the front page than I do of the look-and-feel. Are the words up for discussion here, or just the look-and-feel for now?
Re: Can D get on XBone and PS4?
On 18 January 2015 at 19:56, Joakim via Digitalmars-d wrote: > On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote: >> >> At Remedy, we ran D code on xbone with no opposition from MS. >> For xbone, we wanted to maintain compatibility with the rest of our >> MSVC code, which meant we needed to produce COFF output that the MSVC >> linker accepts. Walter implemented DMD-Win64 with these requirements >> in mind. >> PS4 should be easier using LDC, but I don't know if Sony would take >> issue with this. I expect them to take less issue than MS, so I'd give >> good odd's that they'd be fine with it. >> >> Short answer, D works on modern consoles just fine, and there were no >> political blocks for us. GC is a demonstrated problem; avoid it. DMD's >> codegen is also a problem; it uses x87 to perform operations, despite >> the fact the x64 ABI uses SSE regs for float passing. That results in >> a lot of register switching, and poor float performance as a result. >> As an (awkward) workaround, you can use explicit SSE intrinsics to >> keep working in XMM, but I haven't tested the optimiser's quality in >> that case, and the std library obviously doesn't do that. > > > Thanks for the detailed answer. Sounds like the only thing holding D back > is someone putting in the effort to integrate it with the console runtime > and APIs. It's not going to be me, as I haven't owned a console or even > played a console game in a decade. Yes, I know I'm an old fogey. :) I don't think there's any particularly compelling reason to make runtime calls from D. You can link C/C++ and D code together just fine. If you're a gamedev, there's a very high chance that you already have an engine (presumably C/C++) in place. You'll need to bind the engine api, not the OS api. Trouble with the console OS api's are that they're protected by NDA; it would probably be pretty dubious to release any such foreign language binding here, so each studio would have to do that work themselves... unless it were posted on the official dev forums or something. If I had to say there was one thing holding D back, it's Win64 support in LLVM. We really need LDC for comprehensive gamedev. DMD is okay for game-logic and script-like code, but the codegen isn't good enough to do really hot work. Win64 is almost there in LLVM, the only thing missing that I know of is CV8 debuginfo. Without that, we can't debug... which is like, really important >_<
Re: while(...){ ... }else ...
On Sun, 18 Jan 2015 23:20:43 + Jens Bauer via Digitalmars-d wrote: > -A rejection will not stop me from making another proposal, > though - in fact, I do have one more. ;) sure, you're welcome! this one is not so good, but another one may be brilliant. and even if it will not be so brilliant... you always can make a third one. and fourth. and so on. ;-) signature.asc Description: PGP signature
Re: GSOC - Holiday Edition
On 19/01/2015 12:29 p.m., CraigDillabaugh wrote: On Sunday, 18 January 2015 at 09:09:19 UTC, Rikki Cattermole wrote: Rikki. I've updated the Wiki to include a Cmsed entry: http://wiki.dlang.org/GSOC_2015_Ideas#Cmsed Please have a look and fill it out a bit more. Also, I added a stub for your bio - you may want to update (and possibly correct) it :o) Fun fact, we have more cows now then sheep. Sorry to disappoint. No way! Well, I learned something new. You will have to work that into your Bio. Thanks. Craig I think I did pretty good with how it is right now. So I think I'll leave that part out.
Re: while(...){ ... }else ...
On Sun, 18 Jan 2015 23:16:11 +
Jens Bauer via Digitalmars-d wrote:
> I'd like to give an example on a different use of the same
> feature:
>
> while(length--)
> {
> *d++ = *s++;
> }
> if(length == -1) /* the programmer will need to know the value
> of length here. */
> {
> /* handle case where length was exactly 0, it's now -1 */
> }
>
> would become:
>
> while(length--)
> {
> *d++ = *s++;
> }
> otherwise
> {
> /* handle case where length was exactly 0, it's now -1 */
> }
>
first sample is just a bad code, but second sample is a kind of cypher.
there is no sense in doing such microoptimisations, as decent modern
compiler is able to do dataflow analysis and cse. and both samples are
bad, 'cause they violates the rule "check first, then process".
did you profile your code and found that such loops are real
bottlenecks? i bet they aren't. yet they less readable than clearly
spelled preconditions.
this is microoptimisation in the sake of microoptimisation, it wins
almost nothing and hurts code readability.
all in all it's one of that things that looks nice, but makes more
problems than they are able to solve. that's why language design is
hard: nicely looking features can have many unforseen consequences. ;-)
signature.asc
Description: PGP signature
Re: GSOC - Holiday Edition
On Sunday, 18 January 2015 at 09:09:19 UTC, Rikki Cattermole wrote: Rikki. I've updated the Wiki to include a Cmsed entry: http://wiki.dlang.org/GSOC_2015_Ideas#Cmsed Please have a look and fill it out a bit more. Also, I added a stub for your bio - you may want to update (and possibly correct) it :o) Fun fact, we have more cows now then sheep. Sorry to disappoint. No way! Well, I learned something new. You will have to work that into your Bio. Thanks. Craig
Re: while(...){ ... }else ...
On Sunday, 18 January 2015 at 22:54:16 UTC, Jens Bauer wrote:
On Sunday, 18 January 2015 at 16:03:24 UTC, MattCoder wrote:
On Sunday, 18 January 2015 at 15:52:24 UTC, Jens Bauer wrote:
...
First check: Is it a number; if so, get the entire number... If
not, try the second check: is it a token; if so, get the entire
token, otherwise let us know that it's something unknown (but
only if we're debugging).
Alright I see the purpose about: "while(){}else(){}", but
unfortunately D doesn't have this.
Anyway looking at your first post, I'd like to suggest a way to
improve your code:
/*
Create a "type check" function/method... you named it returning a
defined type */
import std.string;
type checkType(sometype s){
if(isNumeric(s)){
return TYPE_NUMBER;
}
// Check using regex for A..Z, a..z and '_'
return TYPE_TOKEN;
return TYPE_UNDEFINED;
}
// And then somewhere in your code you could do this:
...
{
switch(checkType(s)){
case TYPE_NUMBER : doNumberThing(s); break;
case TYPE_TOKEN : doTokenThing(s); break;
default : checkDebug();
}
}
It's not what you proposed earlier, but I think it can make
things easier.
Matheus.
Re: while(...){ ... }else ...
On Sunday, 18 January 2015 at 23:06:27 UTC, ketmar via Digitalmars-d wrote: it will introduce a new keyword, and it will break any code which using "otherwise" as identifier. as far as i can tell this (introducing new keyword) is one of the hardest thing to do, 'cause Walter will reject it without second thought (and he will be perfectly right). That's OK with me. I'm not discouraged. Now I no longer have to go and think about this. I'd rather show someone the idea and getting it rejected, than keeping it to myself and often regret that I never said anything. -A rejection will not stop me from making another proposal, though - in fact, I do have one more. ;)
Re: while(...){ ... }else ...
I'd like to give an example on a different use of the same
feature:
while(length--)
{
*d++ = *s++;
}
if(length == -1) /* the programmer will need to know the value
of length here. */
{
/* handle case where length was exactly 0, it's now -1 */
}
would become:
while(length--)
{
*d++ = *s++;
}
otherwise
{
/* handle case where length was exactly 0, it's now -1 */
}
---
A pseudo-assembly language version of a normal while-loop:
bra wstart /* this usually cost (something like) a
clock-cycle to start */
while:
copy.b s+,d+
wstart:
sub length,#1
bcc while
wend:
---
Different version of the above:
sub length,#1
bcs wend
while:
copy.b s+,d+
sub length,#1
bcc while
wend:
---
A pseudo-assembly language version of the 'otherwise' while-loop:
sub length,#1
bcs otherwise
while:
copy.b s+,d+
sub length,#1
bcc while
bra wend
otherwise:
/* handle zero-length */
wend:
-These are not real good examples, though. However, they do show
that the compiler would know that it can safely optimize the
expression-test, and almost for free get the 'otherwise', which
would cost only little extra CPU-time.
Re: while(...){ ... }else ...
On Sun, 18 Jan 2015 22:56:23 +
Jens Bauer via Digitalmars-d wrote:
> On Sunday, 18 January 2015 at 18:16:47 UTC, Marc Schütz wrote:
> > Unfortunately, this would break existing code:
>
> That is absolutely correct. Good catch. I did not think of that
> particular case.
>
> However... What if the 'else', which "belongs" to while, is named
> differently, for instance ...
>
> while(expression1)
> {
> }
> otherwise if(expression2)
> {
> }
>
> I know otherwise is a longer word, but it would not clash with
> existing code.
it will introduce a new keyword, and it will break any code which using
"otherwise" as identifier. as far as i can tell this (introducing new
keyword) is one of the hardest thing to do, 'cause Walter will reject
it without second thought (and he will be perfectly right).
signature.asc
Description: PGP signature
Re: while(...){ ... }else ...
"Jens Bauer" wrote:
> On Sunday, 18 January 2015 at 18:16:47 UTC, Marc Schütz wrote:
>> Unfortunately, this would break existing code:
>
> That is absolutely correct. Good catch. I did not think of that particular
> case.
>
> However... What if the 'else', which "belongs" to while, is named
> differently, for instance ...
>
> while(expression1)
> {
> }
> otherwise if(expression2)
> {
> }
>
> I know otherwise is a longer word, but it would not clash with existing code.
The short answer is we are not considering such a feature. Thanks.
Re: while(...){ ... }else ...
On Sunday, 18 January 2015 at 18:16:47 UTC, Marc Schütz wrote:
Unfortunately, this would break existing code:
That is absolutely correct. Good catch. I did not think of that
particular case.
However... What if the 'else', which "belongs" to while, is named
differently, for instance ...
while(expression1)
{
}
otherwise if(expression2)
{
}
I know otherwise is a longer word, but it would not clash with
existing code.
Re: while(...){ ... }else ...
On Sunday, 18 January 2015 at 16:03:24 UTC, MattCoder wrote: On Sunday, 18 January 2015 at 15:52:24 UTC, Jens Bauer wrote: Maybe I misunderstood your question, but what you think about this way: ... It's close, but the result would be different. The while is a combined if+while, where the first test of the while would be the 'if'. In the while(1) example, the character 'c' would perhaps be a number the first time. On the second iteration, the character would be allowed to be a letter. However, in the original 'proposal', the loops would be 'tighter'; the kind would be found first, and then the 'width' of that kind second, and when the end of the kind was reached, the while-block would be exited. So in other words: First check: Is it a number; if so, get the entire number... If not, try the second check: is it a token; if so, get the entire token, otherwise let us know that it's something unknown (but only if we're debugging).
Re: DIP71: 'noscope' and 'out!param' attributes
On Sunday, 18 January 2015 at 19:05:37 UTC, Marc Schütz wrote:
Some random comments:
I like that it applies to all kinds of references, not just
`ref`. Do you want it to apply to structures with reference
members, too? What about value types in general?
I have some thoughts about `ref` that I will say at a different
time.
I think any structure with a reference member must be treated
like a reference type.
Value types with no references will certainly never require these
attributes. I'm not sure if it should be an error to add them or
not. Probably not.
About `out!`: I think this should be placed next to the
escaping parameter for consistency (i.e. `out!p2 T* p1` in your
example), because all other annotations are already at the
parameters that escape.
I would disagree here. Consistency for its own sake isn't
convincing. The outgoing parameter (p2) will probably be less
cluttered and further to the right, enhancing overall
readability. But more importantly, only the users of p2 will need
to know that it's special (i.e., that its scope is restricted to
that of p1). The relevant information is kept close to the place
it is required. Makes sense?
Instead of `noscope`, I suggest `static`, because that's
already a keyword and will not clash with existing code. (Note
that this can the apply to `this`, and `static` then needs to
be placed behind the function to distinguish it from a static
method declaration, where it appears in front.)
Interesting suggestion! You might be right. I should tell you how
I got to `noscope`. There's a fourth way a reference can escape,
which clouded my thinking such that I didn't include it in the
DIP, because it wasn't technically necessary. But now, I'm trying
to figure it out again. In particular, let's call it escaping by
heap.
T** fun(return T* t) {
T** u = new T*;
*u = t;
return u;
}
T** gun() {
T v;
T* w = &v;
return fun(w); // no good, despite heap allocation
}
I had thought that a new heap variable was the equivalent of a
global variable, because both have infinite lifetime. Hence,
`noscope` rather than `global`, for example, or `heap`. But now
I'm realizing that when a reference parameter (i.e. `t` above)
escapes either by return or by mutable parameter, the escape must
*always* be considered to have the same scope as the calling
parameter. The `new T*` in `fun()` may be a heap variable, but it
points to a stack variable in `gun()` just the same and thus must
be treated by `gun()` as such.
Nevertheless, as I think further, I realize that there's nothing
wrong with passing a heap variable *to* a `noscope` parameter,
because it's not unsafe for the static data segment to point to
the heap, as they are coordinated by the garbage collector.
Therefore, the reason to use `noscope` would be to indicate that
anything which has not been allocated on the stack may be
*passed* to the function, while calling it `static` would merely
indicate where the parameter might be copied *to* once inside the
function. As far as adding a new keyword, I think it depends on
the keyword. `noscope` isn't so bad because it fits into the
`throw/nothrow` pattern already. I think the most important
question is whether anyone is normally tempted to use the keyword
as a variable name. I consider the `body` keyword, for example,
regrettable. But do you think anyone will shed a tear for
`noscope`? I'm not worried about it.
How does this proposal interact with `scope`? It seems you want
the compiler to track lifetimes for all reference parameters,
even those not marked as `scope`. At least your example doesn't
use `scope`.
You're right. In my head there is a scheme for doing this. I'll
present it in due time.
Apart from that, I'll have to think about a few things. For
example, I don't know yet whether and how a safe owning type/RC
can be implemented with this.
I don't either. I am pretty sure, however, that this will not
harm the effort. All these attributes do is give the compiler
more information to work with. In the back of my mind, I'm always
thinking @systems programmers can always @trust whatever doesn't
work for them, although I still can't think of any use cases for
violating these principles.
Re: Question about compiler licensing
On Sunday, 18 January 2015 at 10:32:16 UTC, Ryan wrote: On Sunday, 18 January 2015 at 08:48:34 UTC, Walter Bright wrote: On 1/17/2015 7:54 PM, Ryan wrote: Hello, I tried to contact Digital Mars by email but the contact page does not work nor do most of the other forums for me. Maybe I am using them wrong? Anyway, I downloaded the Digital Mars C/C++ compiler and fell in love with it because of how light weight it is (not 300+ MB!). I am working on a project which needs to be able to compile c/c++ code so I felt this compiler would be a great fit. However it says I need to request a license? How do I go about doing this? My project is commercial, but I am obviously not just reselling the compiler as my own. You already have a license to ship code compiled with the compiler. An additional license would only be needed if you wanted to ship the compiler itself. If you need that, I can get you very reasonable terms. Yes I am looking to ship the compiler itself, thanks. What are the terms? Thanks a bunch, Ryan
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 02:18:16 UTC, Andrei Alexandrescu wrote: I took the better part of today working on this: https://github.com/D-Programming-Language/dlang.org/pull/780. See demo at http://erdani.com/d/. What do you all think? Is it an improvement over what we have now? I'd appreciate your help with reviewing and pulling this, and also with improving the colors (which I'm terrible at) and page tracking as mentioned in the pull request. Thanks, Andrei The sidebar colors does look... I liked the old menus better. It was a bit old school but it still looked good (like the reddit menus). The only bad thing about the old menus is that there is to many links Responsive design is missing. I think we could get some of it for free if we used a framework like bootstrap (rust uses it). Many different styles on different sections. It feels like I'm redirected all around the web. E.x code.dlang.org vs. dlang.org. Shouldn't all this be under the same site? Maybe we should give some indication that some links are not part of dlang.org. Googles pagespeed also gives some nice guidelines: https://developers.google.com/speed/pagespeed/insights/?url=dlang.org Best regards, NVolcz
Re: Thanks to p0nce for a nicer DConf logo!
On Sunday, 18 January 2015 at 19:45:10 UTC, ponce wrote: On Sunday, 18 January 2015 at 19:39:38 UTC, Andrei Alexandrescu wrote: Take a look: http://dconf.org/2015/index.html. PR: https://github.com/D-Programming-Language/dconf.org/pull/37. -- Andrei :) By the way I finds DDoc suprinsingly apt for a static site generator. Markdown is great for writing content but without macros, no reuse. looks way cooler. thanks.
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Saturday, 17 January 2015 at 21:21:05 UTC, Walter Bright wrote: On 1/17/2015 4:40 AM, Manu via Digitalmars-d wrote: So when handling ref-related edge cases, do we now have to handle 3 cases? not-ref, ref, and return-ref right? How do I know if some argument is return-ref? I guess we'll need another annoying __traits or something so I can pipe that information into my mixins that deal with ref mess... Or have your mixins generate templates, which will infer 'return'. On that ref issue, I just have to duplicate a bunch of code so it can work for classes and struct alike. There is no way to make something conditionally ref.
Re: The Redmonk programming language rankings 2015
On Sunday, 18 January 2015 at 20:45:09 UTC, MattCoder wrote: Unfortunately no D this time... YET! I forgot to add: Compared with 2014 D grew: 2014 - http://sogrady-media.redmonk.com/sogrady/files/2014/01/lang-rank-114-wm-e1390419878523.png 2015 - http://sogrady-media.redmonk.com/sogrady/files/2015/01/lang.rank_.plot_.q1151-e1421252765953.png Matheus.
The Redmonk programming language rankings 2015
There you go: http://www.reddit.com/r/programming/comments/2su31i/the_redmonk_programming_language_rankings_january/ Unfortunately no D this time... YET! Matheus.
Re: Thanks to p0nce for a nicer DConf logo!
On Sunday, 18 January 2015 at 19:39:38 UTC, Andrei Alexandrescu wrote: Take a look: http://dconf.org/2015/index.html. PR: https://github.com/D-Programming-Language/dconf.org/pull/37. -- Andrei it looks great !
Re: Please help me with improving dlang.org
On 2015-01-18 17:23, Andrei Alexandrescu wrote: Can we ditch the twitter div on mobile? (Pull request would be nice, thanks.) -- Andrei Adam has already created that: https://github.com/D-Programming-Language/dlang.org/pull/779 -- /Jacob Carlborg
Re: Thanks to p0nce for a nicer DConf logo!
On Sunday, 18 January 2015 at 19:39:38 UTC, Andrei Alexandrescu wrote: Take a look: http://dconf.org/2015/index.html. PR: https://github.com/D-Programming-Language/dconf.org/pull/37. -- Andrei :) By the way I finds DDoc suprinsingly apt for a static site generator. Markdown is great for writing content but without macros, no reuse.
Re: Please help me with improving dlang.org
On 2015-01-18 17:21, Andrei Alexandrescu wrote: Suggestions on how to make it better? -- Andrei Something flat (i.e. no gradient) or with less difference between the colors in the gradient. -- /Jacob Carlborg
Re: DMD, Wine and MinGW
and i found what is wrong here. ah, not exactly *what* is wrong, but *where* it goes mad: it's "root/async.c". i don't know what Wine did wrong there, but it keep crashing in that threaded reader. and *sometimes* it works. i turned that messy thingy off, and voila! dmd.exe is not crashing under Wine anymore. how that thing is supposed to work at all? ah, anyway, burn it with fire! let the holy cleansing flame purify it! p.s. can we have a command line switch to turn that abomination off? p.p.s. can i haz cheezburger?
Thanks to p0nce for a nicer DConf logo!
Take a look: http://dconf.org/2015/index.html. PR: https://github.com/D-Programming-Language/dconf.org/pull/37. -- Andrei
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 17:58:57 UTC, Mengu wrote: if i may, i'll go and straightly ask a very great designer friend of mine to help us out. he'll either design a new interface for us or help us make this one better. let me know your call. BTW I'll write the css myself if some designer wants to send me a .png file of what they want the site to look like. (I shouldn't be promising this given the million other things I have to do, but writing css isn't really that hard compared to coming up with the visual design) Tough I think the site is basically ok looking right now and just a few minor tweaks would be nice... which is why I wrote them myself. I encourage others to do the same, just open a pull request and we can hash it out over some concrete code.
Re: Use proper frameworks for building dlang.org
On Sunday, 18 January 2015 at 18:49:43 UTC, Jacob Carlborg wrote: No it has not, but other strange solutions you're coming up with for CSS minification and gzip. That's just a server config issue and can be fixed with 15 lines of .htaccess and like three lines of shell. I posted a solution last night, and the only reason I didn't implement it on the live server is I don't have access to it and don't know the procedure to get stuff up there through a middle man...
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 17:56:41 UTC, aldanor wrote: And yet another thing you gain with (most) frameworks is having access to the original SASS/LESS. I think that's a con, actually. My biggest problem with contributing to the dlang website is that I have to do it blind - it won't make on my computer. The last thing we need is to make that process even more complicated with even more dependencies.
Re: DIP71: 'noscope' and 'out!param' attributes
Some random comments: I like that it applies to all kinds of references, not just `ref`. Do you want it to apply to structures with reference members, too? What about value types in general? About `out!`: I think this should be placed next to the escaping parameter for consistency (i.e. `out!p2 T* p1` in your example), because all other annotations are already at the parameters that escape. Instead of `noscope`, I suggest `static`, because that's already a keyword and will not clash with existing code. (Note that this can the apply to `this`, and `static` then needs to be placed behind the function to distinguish it from a static method declaration, where it appears in front.) It's a really interesting idea to mark distinguish the different ways of escaping. This might have further implications, in particular in relation to purity. How does this proposal interact with `scope`? It seems you want the compiler to track lifetimes for all reference parameters, even those not marked as `scope`. At least your example doesn't use `scope`. Apart from that, I'll have to think about a few things. For example, I don't know yet whether and how a safe owning type/RC can be implemented with this.
