Re: post qualifier and template constraint limitation, is there a reason ?
On Sunday, 18 January 2015 at 07:47:04 UTC, Walter Bright wrote: On 1/17/2015 5:33 PM, deadalnix wrote: You are basically telling me that consistency matter. If so, we either rollback the class case, or go forward on that one. I don't really know where the class change came from :-( I could write a dfix rule to clean up class declarations. I prefer consistency because it makes creating tools for D easier and because I don't have to explain to people why there's more than one right way to do exactly the same thing.
Re: post qualifier and template constraint limitation, is there a reason ?
On 1/17/2015 5:33 PM, deadalnix wrote: On Sunday, 18 January 2015 at 00:19:47 UTC, Walter Bright wrote: On the other hand, I think having only one way to do it is better for consistency and stylistic reasons. For example, I never liked that: int short unsigned is valid in C. I don't believe it adds value. You are basically telling me that consistency matter. If so, we either rollback the class case, or go forward on that one. I don't really know where the class change came from :-( Considering how many time I ran in both of them, we are better off without.
Re: Eliminate comparison.html?
On 1/17/2015 6:19 PM, Andrei Alexandrescu wrote: On 1/17/15 5:05 PM, MattCoder wrote: And please change that logo: http://dlang.org/images/d3.png is so early 90's. I don't mean anything wrong with that, but I don't think it fit in the current standard. Yah, we got out of teenage years. -- Andrei Come on. http://golang.org/
Re: Please help me with improving dlang.org
On 1/17/15 11:42 PM, DaveG wrote: On Sunday, 18 January 2015 at 04:44:56 UTC, Israel 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. I'm no designer, but I do have some comments. Without consistency it just looks a bunch of parts rather than a singular thing. Some elements have gradients, some don't. Some elements have round corners, some don't. Elements with borders use different widths, some have none. In regards to borders, we engineering types (maybe it's just me) tend to put boxes around stuff to represent discrete units when basic design concepts, like proximity and contrast, may be better suited for the task. I just took a quick pass at it in the browser: Original: https://dl.dropboxusercontent.com/u/114394/D-site/current.png Cleanup: https://dl.dropboxusercontent.com/u/114394/D-site/001.png Cleanup w/o bg: https://dl.dropboxusercontent.com/u/114394/D-site/002.png Think "consistency and subtlety". Good design generally goes unnoticed. Looking good. Could you please do a pull request after mine gets in? Thanks! -- Andrei
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 04:44:56 UTC, Israel 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. I'm no designer, but I do have some comments. Without consistency it just looks a bunch of parts rather than a singular thing. Some elements have gradients, some don't. Some elements have round corners, some don't. Elements with borders use different widths, some have none. In regards to borders, we engineering types (maybe it's just me) tend to put boxes around stuff to represent discrete units when basic design concepts, like proximity and contrast, may be better suited for the task. I just took a quick pass at it in the browser: Original: https://dl.dropboxusercontent.com/u/114394/D-site/current.png Cleanup: https://dl.dropboxusercontent.com/u/114394/D-site/001.png Cleanup w/o bg: https://dl.dropboxusercontent.com/u/114394/D-site/002.png Think "consistency and subtlety". Good design generally goes unnoticed. Too much code, I know its what you want people to see but if the entire length of the website consists of giant blocks of code it just doesnt look as pleasing to the eyes... put all of that code and introduction to D into a subpage called "About"/"Intro to D". have it be the first subpage on the left column. The front page should be updated with new content like your tweets, forum posts, articles from other websites,reddit, etc. maybe under the documentation put a "Getting started" Tutorial? I agree, from a new user perspective all the code might seem like a bit much. It might be a good to have short blurb about "Why D?" or "What is D?" or something. I also like the idea of highlighting some key projects, particularly ones with broad appeal (dub and VisualD come to mind). I would recommend keeping things like blog posts, tweets, etc. out of the the main content (on the side or bottom is fine). External sources usually make no sense to a new user, or are generic press pieces which are unnecessary because the person is already on the site. -Dave
Re: css minification
On 1/17/15 11:23 PM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: I know I am imposing on somebodies else's work here, but compressing resources should really be done. Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei If you do not have spare horsepower for compression, how will you handle twice the load? Not quite getting the logic there. -- Andrei
Re: Please help me with improving dlang.org
On 1/17/15 11:16 PM, Tofu Ninja wrote: On Sunday, 18 January 2015 at 07:11:27 UTC, Tofu Ninja wrote: I think the color and theme of the sub-menus looks a lot better than the colors of the outer-menu. With the harsh red boarder, the outer-menu looks like a red tron grid to me. Yah, I took the design at http://cssmenumaker.com/menu/modern-jquery-accordion-menu and changed a couple of colors essentially at random. I noticed several others have mentioned that the colors could be improved. Who can please try to do something about them? Andrei
Re: css minification
On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: I know I am imposing on somebodies else's work here, but compressing resources should really be done. Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei If you do not have spare horsepower for compression, how will you handle twice the load? I have used vibe.d to fetch gzipped resources, it has all the deflate&inflate stuff, so delivering gzipped resources should be easy as flipping a switch.
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 07:11:27 UTC, Tofu Ninja wrote: I think the color and theme of the sub-menus looks a lot better than the colors of the outer-menu. With the harsh red boarder, the outer-menu looks like a red tron grid to me.
Re: css minification
On Saturday, 17 January 2015 at 20:17:51 UTC, Andrei Alexandrescu wrote: On 1/17/15 12:00 PM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote: On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: In the browser. So that on a reload of the page, the browser, instead of making HTTP calls, uses it's cache. How do we improve that on our side? 2 things: a) Set the proper cache headers in the http response. b) Have a way to bust the cache if you have a new version of an resource. If you have both in-place, you can set the expires header to 1 year in the future. Then bust the cache every time you have a new version of the file. Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it? Yes. Please. But the compression thing takes precedence. Awesome. Don't forget you said this. I won't. Design is a *very* touchy issue. It is basically a matter of choice. Without a definite choice made, I won't waste my time improving it. It's clear that once in a while we need to change the design just because it's old. Also, there are a few VERY obvious design improvements that need be done and would be accepted in a heartbeat, but NOBODY is doing them. If I may suggest, I would split up the site into a couple of sections. One for Introduction/About, one for Docs/Api, one for Blogs, one for Community/Forum. Which is basically what everybody else is doing. Just some random sites: http://facebook.github.io/react/ https://www.dartlang.org/ I'm not an expert in design but I can tell within a second whether I like one. Yet no PR is coming for improving the design. Then why not just make a list of sites that we like. And then design this site like those. It is what all the designers are doing.
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 Personally I don't like it, doesn't look like it matches with the rest of the site. But its totally awesome that something is getting done about the site because it does seem like its getting a little stale. Personally what needs more attention is not the side menu, which I think is fine how it is now IMO, but the front page. It has way more code than what it should. Needs to be a good landing pad that advertises things like dub and visualD, and have quick downloads. Also, what happened to the site redesign that was a big topic of talk a few months back? It seems to have faded out of talk and I haven't really seen any thing done about it.
Can D get on XBone and PS4?
I just stumbled across this article from a year ago, which says the PS4 toolchain is based on llvm/clang: http://www.phoronix.com/scan.php?page=news_item&px=MTU1MTY I know some here were excited about the possibility of getting D on the new consoles since they were switching to x86, but is that really possible? I googled other alternative compiled languages combined with playstation 4 and found... nothing. I don't know if Sony/Microsoft put in legal roadblocks to using anything other than the officially supported languages for game development on their consoles. If not, this could be a good way to differentiate D, especially given the current nogc focus. Perhaps Manu or one of the the other game developers can comment on the feasibility of getting D on the major consoles.
Re: Please help me with improving dlang.org
On 1/17/15 8:57 PM, Kapps wrote: Oh, looks like it's different in Chrome vs Firefox. In Chrome it's a subtle red tint at the bottom, in Firefox it's an extremely bright red covering most of the button. Ugh. No idea where that comes from, but the original http://cssmenumaker.com/menu/modern-jquery-accordion-menu (with different colors) looks the same in both browsers. Any experts in the house? Andrei
Re: Please help me with improving dlang.org
On 1/17/15 9:05 PM, Israel wrote: I would also highly recommend advertising the patootie out of dub. Seriously, Dub is like the bright shining sapphire gem of Ds crown. Dub literally makes any other language look like crap. Good idea. Updated pull request and site. Thanks! -- Andrei
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 04:57:26 UTC, Kapps wrote: On Sunday, 18 January 2015 at 04:32:02 UTC, Kapps 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. Thanks, Andrei While I like the idea of it, and the new menus in general, those gradients are honestly really not nice. Very demanding and looks rather out of place. Something like plain grey or black would be better, not a gradient and not something so pop-out like that red. Oh, looks like it's different in Chrome vs Firefox. In Chrome it's a subtle red tint at the bottom, in Firefox it's an extremely bright red covering most of the button. Looked at it in a webkit browser and you're right, I take back my first comment Andrei. But it does seem messed up on Firefox. https://i.imgur.com/FVb2Q6y.png
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 04:44:56 UTC, Israel 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. Thanks, Andrei Too much code, I know its what you want people to see but if the entire length of the website consists of giant blocks of code it just doesnt look as pleasing to the eyes... put all of that code and introduction to D into a subpage called "About"/"Intro to D". have it be the first subpage on the left column. The front page should be updated with new content like your tweets, forum posts, articles from other websites,reddit, etc. maybe under the documentation put a "Getting started" Tutorial? I would also highly recommend advertising the patootie out of dub. Seriously, Dub is like the bright shining sapphire gem of Ds crown. Dub literally makes any other language look like crap.
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 04:32:02 UTC, Kapps 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. Thanks, Andrei While I like the idea of it, and the new menus in general, those gradients are honestly really not nice. Very demanding and looks rather out of place. Something like plain grey or black would be better, not a gradient and not something so pop-out like that red. Oh, looks like it's different in Chrome vs Firefox. In Chrome it's a subtle red tint at the bottom, in Firefox it's an extremely bright red covering most of the button.
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 Too much code, I know its what you want people to see but if the entire length of the website consists of giant blocks of code it just doesnt look as pleasing to the eyes... put all of that code and introduction to D into a subpage called "About"/"Intro to D". have it be the first subpage on the left column. The front page should be updated with new content like your tweets, forum posts, articles from other websites,reddit, etc. maybe under the documentation put a "Getting started" Tutorial?
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 While I like the idea of it, and the new menus in general, those gradients are honestly really not nice. Very demanding and looks rather out of place. Something like plain grey or black would be better, not a gradient and not something so pop-out like that red.
Question about compiler licensing
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. Thanks a lot, Ryan
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, January 16, 2015 13:41:24 Andrei Alexandrescu via Digitalmars-d
wrote:
> Please help us work the kinks out! Walter will be proceeding with the
> opt-in implementation for quicker pipelining.
>
> http://wiki.dlang.org/DIP25
I would point out that the "Deduction" section has code that won't even
compile, because it uses auto ref on a non-templated function:
auto ref T identity(auto ref T) {
return x; // correct, no need for return
}
I assume that that should be something more like
auto ref T identity(T)(auto ref T) {
return x; // correct, no need for return
}
Or am I misunderstanding the intent of the example? I can certainly fix the
page myself, but I don't want to change it in an incorrect manner, and it's
not my DIP.
In any case, while I haven't been as active on the newsgroup lately as I'd
like and missed all of the previous discussions on this, the DIP doesn't
seem like a bad solution. I am a bit surprised though that you agreed to it
given that in previous discussions you seemed opposed to adding any more
attributes for parameters. It does make for a fairly straightforward
solution though.
- Jonathan M Davis
Re: [unittest] constness
On Saturday, January 17, 2015 00:38:08 Luc Bourhis via Digitalmars-d wrote:
> Testing constness implementation is easy:
>
> const Foo a;
> a.non_const_method(); // <<< compilation fails
>
> but how would I catch that in a unittest?
std.datetime has tests like this for that:
const cdate = Date(1999, 7, 6);
immutable idate = Date(1999, 7, 6);
static assert(!__traits(compiles, cdate.year = 1999));
static assert(!__traits(compiles, idate.year = 1999));
And you can make them one-liners by doing something like
static assert(!__traits(compiles,
{const date = Date(1999, 7, 6); date.year = 1999; }));
though I think that it's probably better to not make them one-liners so that
the part that you want to test is isolated and doesn't test other stuff -
e.g. if the constructor call suddenly stopped compiling in that example for
some reason, the test would still pass, but it wouldn't be because of what
you were trying to test for. Other tests would probably catch it in the case
of the constructor, but still, minimizing what ends up in assertion reduces
the risk of accidentally have the test pass for the wrong reasons -
especially when the assertion is for something _not_ compiling.
- Jonathan M Davis
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 02:55:40 UTC, MattCoder 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? Nice but I changed a bit, so what do you think about this: http://i.imgur.com/AIvcoWl.png ? Matheus. IMO this looks much better.
Re: Eliminate comparison.html?
On Saturday, January 17, 2015 09:32:43 Andrei Alexandrescu via Digitalmars-d wrote: > In https://github.com/D-Programming-Language/dlang.org/pull/778 I'm > proposing replacing > > http://dlang.org/comparison.html > > with > > http://erdani.com/d/comparison.html > > The silly one-column comparison was a vestige of a multi-column > comparison that did more harm than good. I replaced it with a simple > hierarchical list. > > However I wonder if we should eliminate the page altogether, or redo it > completely. Thoughts? The two pages look identical to me, but it looks like that PR was merged, so maybe what I'm seeing is your hierarchical list. But without seeing what was there this morning, I don't know how it compares to what was there before. At first glance, I would have thought that that page was the same that it's been since the other languages were removed from the table. Regardless, while the information there is good, I do think that it looks too much like a comparison table which is missing other languages to compare against. Ideally, we'd find a way to present that list without making it look like a comparison table. Unfortunately, I don't think that I have a good suggestion on how to do that, so I don't think that I'm being very helpful. However, I _do_ think that having a page which presents an easy-to-parse list of common language features and says whether D has them or not is useful and that we should have it. The hard part is figuring out how to display that information cleanly, especially if we don't want to try and explicitly compare D with other specific languages on the page. - Jonathan M Davis
Re: GSOC - Holiday Edition
On Saturday, 3 January 2015 at 03:33:29 UTC, Rikki Cattermole wrote: On 3/01/2015 3:59 p.m., Craig Dillabaugh wrote: On Saturday, 3 January 2015 at 00:15:42 UTC, Rikki Cattermole wrote: On 3/01/2015 4:30 a.m., Craig Dillabaugh wrote: On Thursday, 1 January 2015 at 06:19:14 UTC, Rikki Cattermole wrote: clip 10) Rikki had mentioned a 'Web Development' project, but I don't have enough to post on the project ideas page. Are you still interested in doing this. Yes I am. I don't know what I'm doing in the near future (need a job) so I can't explore this too much. But I know I will be able to mentor for it. Hope that everyone has a great 2015, and I look forward to your feedback. Cheers, Craig It would be great to have you as a mentor, but we definitely need fairly solidly defined projects. Any chance you can come up with something by the end of January. Craig Indeed. I created a list for Cmsed https://github.com/rikkimax/Cmsed/wiki/Road-map#what-does-other-web-service-frameworks-offer Right now it basically comes down to e.g. QR code, bar code, PDF. QR and bar code isn't that hard. Not really a GSOC project. PDF definitely is worthy. PDF is an interesting case, it needs e.g. PostScript support. And preferably image and font loading/exporting. So it might be a good worth while project. As it expands out into numerous other projects. Thanks. Would you like to add something to the Wiki, or would you prefer if I did so. Also, what license are you using? Cheers, Craig When it comes to my open source code bases I have two rules. - If you use it commercially at the very least donate what its worth to you. - For non commercial, as long as I'm not held liable you are free to use it in any way you want. At the very least, get involved e.g. PR's, issues. So liberal licenses like MIT, BSD. Which are compatible with e.g. BOOST. Please do write up a skeleton for me on the wiki. I can pad it out. Will help to keep things consistent. 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)
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 layout looks pretty bad on a mobile device you kind of expect it to be properly responsive these days. That might be one thing to get fixed.
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? Nice but I changed a bit, so what do you think about this: http://i.imgur.com/AIvcoWl.png ? Matheus.
Re: Please help me with improving dlang.org
On Sat, Jan 17, 2015 at 06:18:17PM -0800, Andrei Alexandrescu via Digitalmars-d 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? Yes! > 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. [...] Too busy with std.algorithm, sorry. I managed to split it into 5 parts, but having some trouble with some circular dependencies that's causing std.algorithm.mutation to not work properly... but this belongs in a different discussion. T -- Once the bikeshed is up for painting, the rainbow won't suffice. -- Andrei Alexandrescu
Re: Eliminate comparison.html?
On 1/17/15 6:36 PM, MattCoder wrote: On Sunday, 18 January 2015 at 02:33:24 UTC, MattCoder wrote: PS: I hope Walter don't mind! :) *Doesn't Either is correct in some vernacular :o). -- Andrei
Re: Please help me with improving dlang.org
On 1/17/15 6:30 PM, weaselcat wrote: On Sunday, 18 January 2015 at 02:18:16 UTC, Andrei Alexandrescu wrote: What do you all think? colors feel very geocities-like :) I'm not a designer so I couldn't give any color tips, but I like the functionality of the new design. Thanks! Yah, that coral-red is a bit sudden. I want something more subdued, Mars soil-like. -- Andrei
Re: Eliminate comparison.html?
On Sunday, 18 January 2015 at 02:33:24 UTC, MattCoder wrote: PS: I hope Walter don't mind! :) *Doesn't Matheus.
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 02:18:16 UTC, Andrei Alexandrescu wrote: What do you all think? colors feel very geocities-like :) I'm not a designer so I couldn't give any color tips, but I like the functionality of the new design.
Re: Eliminate comparison.html?
On Sunday, 18 January 2015 at 01:13:53 UTC, H. S. Teoh via Digitalmars-d wrote: Maybe it can be replaced with one of the frames from: http://eusebeia.dyndns.org/~hsteoh/tmp/mascot.png :-) Well I can see a pattern there: http://i.imgur.com/k0FpgIn.png PS: I hope Walter don't mind! :) Matheus.
Re: Please help me with improving dlang.org
On Sat, 17 Jan 2015 18:18:17 -0800 Andrei Alexandrescu via Digitalmars-d 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. as you wrote "What do you all think?", i will tell you my impressions too. somehow it's not looking better at all. the new sidebar is looking like... like something that's alien to the site. it's very contrast, which distracts from the main container, and screams: "read me! read me! I TOLD YOU TO READ ME!" old sidebar was almost unnoticable, which is good for supporting site element. but new one looks like it's one of the main things on the site, maybe even the most important one. it's white background sends a signal "i'm The Content!" but maybe i'm just too old for today's modern sites. for me, most of them are designed for anything but presenting me the actual content and just get out of my way while i'm reading. i was never able to understand why current D site considered "old-fashioned" in the meaning of "being old-fashioned is bad". thank you for reading this old man's rant. signature.asc Description: PGP signature
Re: css minification
On Sunday, 18 January 2015 at 02:11:13 UTC, Andrei Alexandrescu
wrote:
Who's "you"? :o) -- Andrei
I'd do it myself, but after spending 30 minutes tonight trying
and failing to get the website to build on my computer again
tonight, I'm out of time.
It really isn't hard though with access to the html and .htaccess
or something.
I just slapped this on my this-week-in-d local thingy:
.htaccess:
RewriteEngine on
RewriteCond %{HTTP:Accept-Encoding} \b(x-)?gzip\b
RewriteCond %{REQUEST_FILENAME}.gz -s
RewriteRule ^(.+) $1.gz [L]
ForceType text/css
Header set Content-Encoding gzip
ForceType text/javascript
Header set Content-Encoding gzip
ForceType application/rss+xml
Header set Content-Encoding gzip
ExpiresActive on
ExpiresDefault "access plus 1 days"
Then ran
$ for i in *.html *.css *.rss *.js; do gzip "$i"; zcat "$i.gz" >
"$i"; done;
(gzip replaces the original file so i just uncompressed it again
after zipping with zcat. idk if there's a better way, the man
page didn't give a quick answer so i just did it his way)
and the headers look good now. So like if that can be done on
dlang.org too it should hopefully do the trick.
Please help me with improving dlang.org
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
Re: Eliminate comparison.html?
On 1/17/15 5:05 PM, MattCoder wrote: On Saturday, 17 January 2015 at 18:04:24 UTC, Andrei Alexandrescu wrote: I think http://dlang.org/overview.html is long in the tooth and needs a rewrite or replacement. It's not appropriate for D at this moment, e.g. questions like "Why D?" etc. don't need answered anymore. And please change that logo: http://dlang.org/images/d3.png is so early 90's. I don't mean anything wrong with that, but I don't think it fit in the current standard. Matheus. Yah, we got out of teenage years. -- Andrei
Re: css minification
On 1/17/15 4:22 PM, Adam D. Ruppe wrote: On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Doing it on demand might be a mistake here, but we can also pre-compress the files since it is a static site. You just run gzip on the files then serve them up with the proper headers. Who's "you"? :o) -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 18 January 2015 at 07:20, Walter Bright via Digitalmars-d 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'. *sigh* Don't get me started on auto-ref again. We'll need some sort of traits to detect the return-ref case.
Re: post qualifier and template constraint limitation, is there a reason ?
On Sunday, 18 January 2015 at 00:19:47 UTC, Walter Bright wrote: On the other hand, I think having only one way to do it is better for consistency and stylistic reasons. For example, I never liked that: int short unsigned is valid in C. I don't believe it adds value. You are basically telling me that consistency matter. If so, we either rollback the class case, or go forward on that one. Considering how many time I ran in both of them, we are better off without.
Re: Eliminate comparison.html?
On Sun, 18 Jan 2015 01:05:25 + MattCoder via Digitalmars-d wrote: > On Saturday, 17 January 2015 at 18:04:24 UTC, Andrei Alexandrescu > wrote: > > I think http://dlang.org/overview.html is long in the tooth and > > needs a rewrite or replacement. It's not appropriate for D at > > this moment, e.g. questions like "Why D?" etc. don't need > > answered anymore. > > And please change that logo: http://dlang.org/images/d3.png is so > early 90's. I don't mean anything wrong with that, but I don't > think it fit in the current standard. it's fsckin' great! oh, no, not another "modern" plastic shit or android-like chimera... it's lighthearted and promises that journey with D will be full of fun and entertainment. signature.asc Description: PGP signature
Re: Eliminate comparison.html?
On Sun, Jan 18, 2015 at 01:05:25AM +, MattCoder via Digitalmars-d wrote: > On Saturday, 17 January 2015 at 18:04:24 UTC, Andrei Alexandrescu wrote: > >I think http://dlang.org/overview.html is long in the tooth and needs > >a rewrite or replacement. It's not appropriate for D at this moment, > >e.g. questions like "Why D?" etc. don't need answered anymore. > > And please change that logo: http://dlang.org/images/d3.png is so > early 90's. I don't mean anything wrong with that, but I don't think > it fit in the current standard. Maybe it can be replaced with one of the frames from: http://eusebeia.dyndns.org/~hsteoh/tmp/mascot.png :-) I made that model in povray, btw, so if need be I can render new poses as necessary. T -- Don't throw out the baby with the bathwater. Use your hands...
Re: Eliminate comparison.html?
On Saturday, 17 January 2015 at 18:04:24 UTC, Andrei Alexandrescu wrote: I think http://dlang.org/overview.html is long in the tooth and needs a rewrite or replacement. It's not appropriate for D at this moment, e.g. questions like "Why D?" etc. don't need answered anymore. And please change that logo: http://dlang.org/images/d3.png is so early 90's. I don't mean anything wrong with that, but I don't think it fit in the current standard. Matheus.
Re: dlang.org should do it in style
On Saturday, 17 January 2015 at 22:27:08 UTC, H. S. Teoh via Digitalmars-d wrote: Also, I am skeptical of a single style that will work for both desktop and mobile browsers. Isn't that what mobile stylesheets are for? We can have the same content, but we shouldn't break the desktop layout or make it look laughably spaced out just for the sake of mobile devices. Let the mobile devices have their own stylesheet. Sure, but for what I see adding: "min-width:1024px;" (or what unit you want) on body will NOT break the site on desktop and will make the site more readable on mobile. Ideally you would want a stylesheet for mobile, but this would take more time than adding a single line in the current stylesheet. Matheus.
Re: css minification
On second thought this way works better: http://stackoverflow.com/questions/7509501/how-to-configure-mod-deflate-to-serve-gzipped-assets-prepared-with-assetsprecom though that's some ugly configuration, I hate apache. But I just tested that locally and it all worked from a variety of user agents. All I had to do was gzip the file and also keep a copy of the uncompressed version to server to the (very few btw... but popular - curl, by default, is one of them) UAs that don't handle receiving gzipped info.
Re: dlang.org should do it in style
On 1/17/15 3:18 PM, H. S. Teoh via Digitalmars-d wrote: On Sat, Jan 17, 2015 at 02:36:03PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 1/17/15 2:24 PM, H. S. Teoh via Digitalmars-d wrote: [...] I rather that we use font-based metrics (e.g. 40em) instead of pixel sizes. That way the layout won't break or look horrible if the user changes the default font sizes (e.g. for special needs, etc.) or doesn't maximize his browser window. But that's just my opinion. Also, I am skeptical of a single style that will work for both desktop and mobile browsers. Isn't that what mobile stylesheets are for? We can have the same content, but we shouldn't break the desktop layout or make it look laughably spaced out just for the sake of mobile devices. Let the mobile devices have their own stylesheet. Could you please run some experiments and see where they take us? -- Andrei I'm busy working on splitting up std.algorithm into more manageable chunks... currently I can't even run the unittests on my machine anymore because it eats up all available RAM. So far I've managed to successfully extricate the set operations into their own submodule (and pass unittests!). So yeah... too busy to look into web stuff atm. Thanks! I filed https://issues.dlang.org/show_bug.cgi?id=13997, who can get into it? -- Andrei
Re: css minification
On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Doing it on demand might be a mistake here, but we can also pre-compress the files since it is a static site. You just run gzip on the files then serve them up with the proper headers. here's a thing about doing it in apache http://stackoverflow.com/questions/75482/how-can-i-pre-compress-files-with-mod-deflate-in-apache-2-x Also, how would this work if we switch to vibe.d? -- Andrei I don't know about vibe, but it is trivially simple in HTTP, so if it isn't supported there, it is probably a three (ish) line change. Caching is the same deal btw, just set the right header and you'll get a huge improvement. "Cache-control: max-age=36000" will cache it for ten hours, without even needing to change the urls. (Changing urls is nice because you can set it to cache forever and still get instantly visible updates to the user by changing the url, but we'd probably be fine with a cache update lag and it is simpler that way.) ETags are set right now and that does some caching, it could be improved further by adding the max-age bit tho. This is an apache config of some sort too. http://stackoverflow.com/questions/16750757/apache-set-max-age-or-expires-in-htaccess-for-directory though I don't agree it should be one year unless we're using different urls, we should do hours or days, but that's how it is done.
Re: post qualifier and template constraint limitation, is there a reason ?
On 1/17/2015 4:06 PM, deadalnix wrote:
Because I can never remember which one it is and run into the wrong case 50% of
the time. I'd assume that I'm not the only one, but, as I have done for ages, do
not consider this as an issue big enough to complain. This is the kind of thing
that drain you productivity minute by minute.
Kind of like
class C(T) : B if(...) {} vs class C(T) if(...) : B {}
That Brian mentioned in his DConf talk. It is just another instance of the same
problem. Only one used to be accepted, but now both are valid. It looks like to
me like another instance of the same problem.
On the other hand, I think having only one way to do it is better for
consistency and stylistic reasons.
For example, I never liked that:
int short unsigned
is valid in C. I don't believe it adds value.
Re: post qualifier and template constraint limitation, is there a reason ?
On Saturday, 17 January 2015 at 21:15:53 UTC, Walter Bright wrote:
On 1/17/2015 8:56 AM, deadalnix wrote:
On Saturday, 17 January 2015 at 10:05:29 UTC, Walter Bright
wrote:
On 1/17/2015 12:33 AM, deadalnix 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 ?
There was no known reason to.
Is that possible to make it work then ? Should I open a bug ?
Sure, but you'll need a rationale that is better than "why not"
:-)
Because I can never remember which one it is and run into the
wrong case 50% of the time. I'd assume that I'm not the only one,
but, as I have done for ages, do not consider this as an issue
big enough to complain. This is the kind of thing that drain you
productivity minute by minute.
Kind of like
class C(T) : B if(...) {} vs class C(T) if(...) : B {}
That Brian mentioned in his DConf talk. It is just another
instance of the same problem. Only one used to be accepted, but
now both are valid. It looks like to me like another instance of
the same problem.
Re: dlang.org should do it in style
On Sat, Jan 17, 2015 at 02:36:03PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > On 1/17/15 2:24 PM, H. S. Teoh via Digitalmars-d wrote: [...] > >I rather that we use font-based metrics (e.g. 40em) instead of pixel > >sizes. That way the layout won't break or look horrible if the user > >changes the default font sizes (e.g. for special needs, etc.) or > >doesn't maximize his browser window. > > > >But that's just my opinion. > > > >Also, I am skeptical of a single style that will work for both > >desktop and mobile browsers. Isn't that what mobile stylesheets are > >for? We can have the same content, but we shouldn't break the desktop > >layout or make it look laughably spaced out just for the sake of > >mobile devices. Let the mobile devices have their own stylesheet. > > Could you please run some experiments and see where they take us? -- > Andrei I'm busy working on splitting up std.algorithm into more manageable chunks... currently I can't even run the unittests on my machine anymore because it eats up all available RAM. So far I've managed to successfully extricate the set operations into their own submodule (and pass unittests!). So yeah... too busy to look into web stuff atm. T -- PNP = Plug 'N' Pray
Re: dlang.org should do it in style
On Sat, Jan 17, 2015 at 02:24:48PM -0800, H. S. Teoh via Digitalmars-d wrote: > Also, I am skeptical of a single style that will work for both desktop > and mobile browsers. Isn't that what mobile stylesheets are for? If you do your html and style right in the first place, it will be mostly the same. At most you might reposition a sidebar or something.
Re: dlang.org should do it in style
On 1/17/15 2:24 PM, H. S. Teoh via Digitalmars-d wrote: On Sat, Jan 17, 2015 at 08:04:56PM +, MattCoder via Digitalmars-d wrote: On Saturday, 17 January 2015 at 19:35:01 UTC, Andrei Alexandrescu wrote: A tested PR would be great. Who can take this? -- Andrei A last note about this: using "width:1024px" will fix the mobile "wrap-text" problem, but the site will look like this on higher resolutions: http://i.imgur.com/MZSmn87.png (Look the space on the left and right). So another solution would trying to set "min-width:1024px" on body tag, so the site will continue to be the same as is today even on higher resolutions, and I'm pretty sure this will correct the problem above on mobile devices. If anyone change I'd be glad to test. PS: I'm assuming 1024 pixels because it's used as minimum standard these days. [...] I rather that we use font-based metrics (e.g. 40em) instead of pixel sizes. That way the layout won't break or look horrible if the user changes the default font sizes (e.g. for special needs, etc.) or doesn't maximize his browser window. But that's just my opinion. Also, I am skeptical of a single style that will work for both desktop and mobile browsers. Isn't that what mobile stylesheets are for? We can have the same content, but we shouldn't break the desktop layout or make it look laughably spaced out just for the sake of mobile devices. Let the mobile devices have their own stylesheet. Could you please run some experiments and see where they take us? -- Andrei
Re: Eliminate comparison.html?
On 1/17/2015 10:04 AM, Andrei Alexandrescu wrote: On 1/17/15 9:51 AM, Mathias LANG wrote: On Saturday, 17 January 2015 at 17:32:43 UTC, Andrei Alexandrescu wrote: In https://github.com/D-Programming-Language/dlang.org/pull/778 I'm proposing replacing http://dlang.org/comparison.html with http://erdani.com/d/comparison.html The silly one-column comparison was a vestige of a multi-column comparison that did more harm than good. I replaced it with a simple hierarchical list. However I wonder if we should eliminate the page altogether, or redo it completely. Thoughts? Andrei http://dlang.org/features2.html - http://dlang.org/D1toD2.html Maybe a good step for 2015 is to get ride of those. Agreed. Walter? Yes. Regarding comparison, it feels a bit redundant with overview. However, your version is way easyier to "parse" than the wall of text in overview. IMO, adding the missing links would make it a suitable replacement. I think http://dlang.org/overview.html is long in the tooth and needs a rewrite or replacement. It's not appropriate for D at this moment, e.g. questions like "Why D?" etc. don't need answered anymore. Yes, it's an embarrassment at the moment.
Re: css minification
On Sat, Jan 17, 2015 at 12:52:29PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > >I know I am imposing on somebodies else's work here, but compressing > >resources should really be done. > > Our webmaster got back. He said compression is more CPU work and on a > fat pipe (which we do have) that may make things actually worse. Also, > how would this work if we switch to vibe.d? -- Andrei +1 for dogfooding! T -- Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.
Re: dlang.org should do it in style
On Sat, Jan 17, 2015 at 08:04:56PM +, MattCoder via Digitalmars-d wrote: > On Saturday, 17 January 2015 at 19:35:01 UTC, Andrei Alexandrescu wrote: > >A tested PR would be great. Who can take this? -- Andrei > > A last note about this: using "width:1024px" will fix the mobile > "wrap-text" problem, but the site will look like this on higher > resolutions: http://i.imgur.com/MZSmn87.png (Look the space on the > left and right). > > So another solution would trying to set "min-width:1024px" on body > tag, so the site will continue to be the same as is today even on > higher resolutions, and I'm pretty sure this will correct the problem > above on mobile devices. If anyone change I'd be glad to test. > > PS: I'm assuming 1024 pixels because it's used as minimum standard > these days. [...] I rather that we use font-based metrics (e.g. 40em) instead of pixel sizes. That way the layout won't break or look horrible if the user changes the default font sizes (e.g. for special needs, etc.) or doesn't maximize his browser window. But that's just my opinion. Also, I am skeptical of a single style that will work for both desktop and mobile browsers. Isn't that what mobile stylesheets are for? We can have the same content, but we shouldn't break the desktop layout or make it look laughably spaced out just for the sake of mobile devices. Let the mobile devices have their own stylesheet. T -- Shin: (n.) A device for finding furniture in the dark.
Re: Variadic templates - D section on wikipedia
On Saturday, 17 January 2015 at 11:34:25 UTC, Douglas Peterson wrote: https://en.wikipedia.org/wiki/Variadic_template Isn't it a pity that the first language supporting them hasn't even a section over there ? I invite any expert interested into the task to write the missing D section. https://www.youtube.com/watch?v=nbun2G6FjLY :(
Re: post qualifier and template constraint limitation, is there a reason ?
Walter Bright:
Sure, but you'll need a rationale that is better than "why not"
:-)
Often in a language it's a good idea to have only one way to do
something. To have two places to put those attributes generates
the question: where do you want to put them? And it's a question
that wastes time. In Python you don't have "wars" regarding where
to put the { } because there is just one way to format code and
indentations... and it's a good way.
Bye,
bearophile
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
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'.
Re: post qualifier and template constraint limitation, is there a reason ?
On 1/17/2015 8:56 AM, deadalnix wrote:
On Saturday, 17 January 2015 at 10:05:29 UTC, Walter Bright wrote:
On 1/17/2015 12:33 AM, deadalnix 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 ?
There was no known reason to.
Is that possible to make it work then ? Should I open a bug ?
Sure, but you'll need a rationale that is better than "why not" :-)
Re: css minification
I know I am imposing on somebodies else's work here, but compressing resources should really be done. Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei It seems to me that once this DIP is implemented, it should be safe to allow taking an rvalue by reference in safe code as long as it is not annotated with `return`. Is this correct?
Re: css minification
On 1/17/15 12:00 PM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote: On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: I'm not an expert or an ideologist in the area. It was added by others who obviously have a different opinion from yours. Well, then they should use http://zeptojs.com/ Of course. :o) why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min. I'm working with our webmaster to create accounts for a few folks. For now you may want to send me what needs to be done and I'll take it with him. N.B. I vaguely recall I've tried that once but it was not possible for obscure reasons. I do not know the obscure reasons, but it should be as simple as: nano /etc/apache2/mods-enabled/deflate.conf # these are known to be safe with MSIE 6 AddOutputFilterByType DEFLATE text/html text/plain text/xml # everything else may cause problems with MSIE 6 AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/javacript application/ecmascript AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/json I know I am imposing on somebodies else's work here, but compressing resources should really be done. Forwarded to our webmaster, thanks. Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers. Where should these be cached? I don't understand. In the browser. So that on a reload of the page, the browser, instead of making HTTP calls, uses it's cache. How do we improve that on our side? Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for. Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it? Yes. Please. But the compression thing takes precedence. Awesome. Don't forget you said this. regex to select comments: /(\/\*[^(*\/)]+\*\/)/g regex to select whitespace: /(\s+)/g and then delete those. Tested PR or by the end of the day this will slide into obsolescence. Design is a *very* touchy issue. It is basically a matter of choice. Without a definite choice made, I won't waste my time improving it. It's clear that once in a while we need to change the design just because it's old. Also, there are a few VERY obvious design improvements that need be done and would be accepted in a heartbeat, but NOBODY is doing them. I'm not an expert in design but I can tell within a second whether I like one. Yet no PR is coming for improving the design. The choice is very simple: keep it like it is, do what everybody else is doing False choice. Andrei
Re: dlang.org should do it in style
On Saturday, 17 January 2015 at 19:35:01 UTC, Andrei Alexandrescu wrote: A tested PR would be great. Who can take this? -- Andrei A last note about this: using "width:1024px" will fix the mobile "wrap-text" problem, but the site will look like this on higher resolutions: http://i.imgur.com/MZSmn87.png (Look the space on the left and right). So another solution would trying to set "min-width:1024px" on body tag, so the site will continue to be the same as is today even on higher resolutions, and I'm pretty sure this will correct the problem above on mobile devices. If anyone change I'd be glad to test. PS: I'm assuming 1024 pixels because it's used as minimum standard these days. Matheus.
Re: css minification
On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote: On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: A seasoned JS programmer can rewrite that stuff in about 6kb, if not less. Great. You forgot to link to your pull request :o). Wait, one step back. I was still in assessment mode. I haven't committed to doing anything. jQuery is the enabler of all bad habits; best to remove it quickly, if only because of principles. If you really got addicted to that horse*@&#, try zepto. I'm not an expert or an ideologist in the area. It was added by others who obviously have a different opinion from yours. Well, then they should use http://zeptojs.com/ why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min. I'm working with our webmaster to create accounts for a few folks. For now you may want to send me what needs to be done and I'll take it with him. N.B. I vaguely recall I've tried that once but it was not possible for obscure reasons. I do not know the obscure reasons, but it should be as simple as: nano /etc/apache2/mods-enabled/deflate.conf # these are known to be safe with MSIE 6 AddOutputFilterByType DEFLATE text/html text/plain text/xml # everything else may cause problems with MSIE 6 AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/javacript application/ecmascript AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/json I know I am imposing on somebodies else's work here, but compressing resources should really be done. Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers. Where should these be cached? I don't understand. In the browser. So that on a reload of the page, the browser, instead of making HTTP calls, uses it's cache. Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for. Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it? Yes. Please. But the compression thing takes precedence. While there are some other optimizations to be made - like putting that twitter stream js at the bottom of the page - the point is this: If I wanted to optimize this website, minifying style.css would be the last thing on my list. Yah, the problem is everything on your list is hypothetical and not done, whereas css minimization is actual and done. Big difference. Very big difference. True. If you can get a 4% difference by minimizing CSS, just do it. I am just saying you can do a lot better. Plus, I think with all the expertise around here, most of us who do web development, did this at one stage or the other. Besides, minimizing CSS is tantamount to removing comments and whitespace. Like Adam Ruppe said, a regex program in D can accomplish that; no need to use a online service. It probably takes you more time to integrate the online service than to write the D program including the regex. Then do it. regex to select comments: /(\/\*[^(*\/)]+\*\/)/g regex to select whitespace: /(\s+)/g and then delete those. I know css minimizers do more, but if comments and whitespace is your issue, this does the trick. Being among this group of knowledgeable programmers it amazes me this site is still pre 2000. I for one, am required to use Lynx just because my eyes can't stand the design. Then improve it. Design is a *very* touchy issue. It is basically a matter of choice. Without a definite choice made, I won't waste my time improving it. The choice is very simple: keep it like it is, do what everybody else is doing
Re: dlang.org should do it in style
On 1/17/15 10:39 AM, MattCoder wrote: On Saturday, 17 January 2015 at 17:59:07 UTC, Andrei Alexandrescu wrote: In fact yesterday I was showing the main page for a friend on his smartphone (Moto G), and the code example at main page looks awful, since it's all wrapped on mobile. Here is an example what I'm talking about: http://i.imgur.com/9JYNVNk.png To make a website look good on a mobile device, one needs to do work to make the website look good on a mobile device. Indeed! But, if the "body" had a "width" setted this wouldn't occur. For example, adding "width: 1024px" on body in style.css it will now be fine to see on mobile. Matheus. A tested PR would be great. Who can take this? -- Andrei
Is there major problem to implement 13995 ?
Context: https://issues.dlang.org/show_bug.cgi?id=13995 This is a recurring and VERY annoying problem. Basically, you'll run continuously into it if you manipulate bitfields. Is there any major technical problem in DMD that would prevent to change the behavior ?
Re: dlang.org should do it in style
On Saturday, 17 January 2015 at 17:59:07 UTC, Andrei Alexandrescu wrote: In fact yesterday I was showing the main page for a friend on his smartphone (Moto G), and the code example at main page looks awful, since it's all wrapped on mobile. Here is an example what I'm talking about: http://i.imgur.com/9JYNVNk.png To make a website look good on a mobile device, one needs to do work to make the website look good on a mobile device. Indeed! But, if the "body" had a "width" setted this wouldn't occur. For example, adding "width: 1024px" on body in style.css it will now be fine to see on mobile. Matheus.
Re: post qualifier and template constraint limitation, is there a reason ?
On Sat, 17 Jan 2015 17:34:21 + deadalnix via Digitalmars-d wrote: > On Saturday, 17 January 2015 at 17:08:12 UTC, ketmar via > Digitalmars-d wrote: > > sure i have. i made alot of patches to the parser, so i know > > how it > > is written. to make this work parser need to be changed not > > less than > > to accept '@' before `pure`, `nothrow` and so on, and this > > change was > > rejected due to added complexity for supporting it by devteam. > > > I'm sorry but this is not a good reason. It would be failry easy > to add this in SDC's parser, so now what ? it tells nothing about > the feature and everything about DMD's parser. this was one of the good reasons to reject `@pure` syntax, so i can't see why it's not a good reason to reject OP's syntax. > > as for "will not be used" -- you can use google to count > > requests for > > this feature. the numbers will show you how much people miss it. > > > > i have no habit of writing tales from the faery world, you know. > > Absence of information is not information. i don't think that you are right here. but i'm not in the right mood to argue. signature.asc Description: PGP signature
Re: Variadic templates - D section on wikipedia
On 1/17/15 10:08 AM, Mathias LANG wrote: On Saturday, 17 January 2015 at 17:42:08 UTC, Andrei Alexandrescu wrote: On 1/17/15 3:34 AM, Douglas Peterson wrote: https://en.wikipedia.org/wiki/Variadic_template Isn't it a pity that the first language supporting them hasn't even a section over there ? I invite any expert interested into the task to write the missing D section. Good idea. I created https://issues.dlang.org/show_bug.cgi?id=13994 to track this. Any takers? -- Andrei Yes. Though it would be nice (but not necessary) to have your input on https://github.com/D-Programming-Language/phobos/pull/2687 first. Does that do a lot of moving stuff to a separate module? I have to say that after porting a bunch of code from 2.065 to 2.067.1 at work, I'm less keen about renaming stuff than I used to. Andrei
Re: css minification
On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: On Friday, 16 January 2015 at 17:40:40 UTC, Andrei Alexandrescu wrote: I just added https://github.com/D-Programming-Language/dlang.org/pull/770, which generates minified css files. This is because in the near future css files will become heftier (more documentation comments, more detailed styles etc). The disadvantage is that now one needs to be online to generate documentation. Thoughts? Andrei I have taken a look at http://dlang.org and assessed some of the improvements to be made. I will probably step on someones toes, sorry, but that is just because I have big feet. Fantastic. A lot of people have already said this, but minification is the last thing on the list. Measurements contradict that. Anyhow my point was one line of code reduces all site traffic by 5% - they call that a good day. My browser needs to parse 299kb to display the page. Javascript alone takes up 210kb of that. 131kb of that is uncompressed. 33kb is jQuery and 33kb is widget.js. That widget.js thing is probably because of the twitter stream on the right. A seasoned JS programmer can rewrite that stuff in about 6kb, if not less. Great. You forgot to link to your pull request :o). jQuery is the enabler of all bad habits; best to remove it quickly, if only because of principles. If you really got addicted to that horse*@&#, try zepto. I'm not an expert or an ideologist in the area. It was added by others who obviously have a different opinion from yours. But codemirror-compressed.js and run.js are by far the worst contenders and should be addressed as first. You can bring down loading times to half (yes, you read that correctly, you can cut 150kb). Besides, do you really need 100+kb of codemirror JS? What is it even doing? Even if you really need it, why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min. I'm working with our webmaster to create accounts for a few folks. For now you may want to send me what needs to be done and I'll take it with him. N.B. I vaguely recall I've tried that once but it was not possible for obscure reasons. Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers. These are the files that are referenced by http://dlang.org and are not using caching (nor compression!): dlang.org/ codemirror.css style.css print.css codemirror-compressed.js run-main-website.js run.js search-left.gif search-button.gif dlogo.png gradient-red.jpg search-bg.gif Where should these be cached? I don't understand. Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for. Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it? While there are some other optimizations to be made - like putting that twitter stream js at the bottom of the page - the point is this: If I wanted to optimize this website, minifying style.css would be the last thing on my list. Yah, the problem is everything on your list is hypothetical and not done, whereas css minimization is actual and done. Big difference. Very big difference. Besides, minimizing CSS is tantamount to removing comments and whitespace. Like Adam Ruppe said, a regex program in D can accomplish that; no need to use a online service. It probably takes you more time to integrate the online service than to write the D program including the regex. Then do it. At the end of the day, watching `mb-downloaded per resource per total` tells you nothing. What only matter is the time it takes for users to enter `http://dlang.org` in the browser, up until the time they get to see something they can click on. Agreed. Being among this group of knowledgeable programmers it amazes me this site is still pre 2000. I for one, am required to use Lynx just because my eyes can't stand the design. Then improve it. OT: And lets be honest here, why the hell do we even use apache+php and not D+vibe.d? I just rewrote my companies corporate website in under 4 hours. Granted, it is a simple one. But this community should be able to rewrite this site in D in under a week, right? I wish. Andrei
Re: [WORK] Backtick dat code?
On 16/01/15 21:58, Vladimir Panteleev via Digitalmars-d wrote:
On Friday, 16 January 2015 at 20:50:22 UTC, Andrei Alexandrescu wrote:
Now that Adam's work on transforming `code` into $(D code) is in, who'd want
to write the glorious sed --in-place expression that transforms Phobos? Or
should we just leave it for future code and occasional refactoring? -- Andrei
Does it support things like: `log n$(SUBSCRIPT c)` ?
Great to hear that Adam's feature landed :-)
Along similar lines, it would be really nice if there were some way in Ddoc of
indicating, "This next bit of ddoc contains no macros nor any Ddoc special
characters and should be taken literally as is."
I don't know if this fits with the design, but suppose that ``something`` were
to be taken as "something should be interpreted literally as-is". So then,
```this_bit_of_code() { ... }``` would be interpreted as code that internally
contains no Ddoc macros or special characters, while ``this would be
literally-interpreted text`` and `this_code() { $(B can_contain;) ddoc_macros; }`.
Re: Variadic templates - D section on wikipedia
On Saturday, 17 January 2015 at 17:42:08 UTC, Andrei Alexandrescu wrote: On 1/17/15 3:34 AM, Douglas Peterson wrote: https://en.wikipedia.org/wiki/Variadic_template Isn't it a pity that the first language supporting them hasn't even a section over there ? I invite any expert interested into the task to write the missing D section. Good idea. I created https://issues.dlang.org/show_bug.cgi?id=13994 to track this. Any takers? -- Andrei Yes. Though it would be nice (but not necessary) to have your input on https://github.com/D-Programming-Language/phobos/pull/2687 first.
Re: css minification
On Friday, 16 January 2015 at 17:40:40 UTC, Andrei Alexandrescu wrote: I just added https://github.com/D-Programming-Language/dlang.org/pull/770, which generates minified css files. This is because in the near future css files will become heftier (more documentation comments, more detailed styles etc). The disadvantage is that now one needs to be online to generate documentation. Thoughts? Andrei I have taken a look at http://dlang.org and assessed some of the improvements to be made. I will probably step on someones toes, sorry, but that is just because I have big feet. A lot of people have already said this, but minification is the last thing on the list. My browser needs to parse 299kb to display the page. Javascript alone takes up 210kb of that. 131kb of that is uncompressed. 33kb is jQuery and 33kb is widget.js. That widget.js thing is probably because of the twitter stream on the right. A seasoned JS programmer can rewrite that stuff in about 6kb, if not less. jQuery is the enabler of all bad habits; best to remove it quickly, if only because of principles. If you really got addicted to that horse*@&#, try zepto. But codemirror-compressed.js and run.js are by far the worst contenders and should be addressed as first. You can bring down loading times to half (yes, you read that correctly, you can cut 150kb). Besides, do you really need 100+kb of codemirror JS? What is it even doing? Even if you really need it, why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min. Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers. These are the files that are referenced by http://dlang.org and are not using caching (nor compression!): dlang.org/ codemirror.css style.css print.css codemirror-compressed.js run-main-website.js run.js search-left.gif search-button.gif dlogo.png gradient-red.jpg search-bg.gif Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for. While there are some other optimizations to be made - like putting that twitter stream js at the bottom of the page - the point is this: If I wanted to optimize this website, minifying style.css would be the last thing on my list. Besides, minimizing CSS is tantamount to removing comments and whitespace. Like Adam Ruppe said, a regex program in D can accomplish that; no need to use a online service. It probably takes you more time to integrate the online service than to write the D program including the regex. At the end of the day, watching `mb-downloaded per resource per total` tells you nothing. What only matter is the time it takes for users to enter `http://dlang.org` in the browser, up until the time they get to see something they can click on. Being among this group of knowledgeable programmers it amazes me this site is still pre 2000. I for one, am required to use Lynx just because my eyes can't stand the design. OT: And lets be honest here, why the hell do we even use apache+php and not D+vibe.d? I just rewrote my companies corporate website in under 4 hours. Granted, it is a simple one. But this community should be able to rewrite this site in D in under a week, right?
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Saturday, 17 January 2015 at 17:08:42 UTC, Marc Schütz wrote: On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic 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. I'm very interested in that! I think the `return` notation is a good idea, and can maybe be reused in a more complete `scope` proposal. A downside is that it only applies to the return value, but not to other `out` and `ref` parameters. But the `!` syntax can work here, too. Yup. In fact, my DIP is partly inspired the 'scope!' syntax suggestion in your DIP.
Re: Eliminate comparison.html?
On 1/17/15 9:51 AM, Mathias LANG wrote: On Saturday, 17 January 2015 at 17:32:43 UTC, Andrei Alexandrescu wrote: In https://github.com/D-Programming-Language/dlang.org/pull/778 I'm proposing replacing http://dlang.org/comparison.html with http://erdani.com/d/comparison.html The silly one-column comparison was a vestige of a multi-column comparison that did more harm than good. I replaced it with a simple hierarchical list. However I wonder if we should eliminate the page altogether, or redo it completely. Thoughts? Andrei http://dlang.org/features2.html - http://dlang.org/D1toD2.html Maybe a good step for 2015 is to get ride of those. Agreed. Walter? Regarding comparison, it feels a bit redundant with overview. However, your version is way easyier to "parse" than the wall of text in overview. IMO, adding the missing links would make it a suitable replacement. I think http://dlang.org/overview.html is long in the tooth and needs a rewrite or replacement. It's not appropriate for D at this moment, e.g. questions like "Why D?" etc. don't need answered anymore. Andrei
Re: dlang.org should do it in style
On 1/17/15 8:32 AM, MattCoder wrote: On Saturday, 17 January 2015 at 15:28:57 UTC, Mathias LANG wrote: http://w0rp.com:8010/ I don't know about others but for me the layout above looks more attractive than the actual one. I agree. In fact yesterday I was showing the main page for a friend on his smartphone (Moto G), and the code example at main page looks awful, since it's all wrapped on mobile. Here is an example what I'm talking about: http://i.imgur.com/9JYNVNk.png To make a website look good on a mobile device, one needs to do work to make the website look good on a mobile device. Andrei
Re: css minification
On 1/17/15 8:44 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
On Friday, 16 January 2015 at 22:32:07 UTC, Steven Schveighoffer wrote:
On 1/16/15 5:23 PM, Andrei Alexandrescu wrote:
On 1/16/15 1:44 PM, Steven Schveighoffer wrote:
On an embedded product we have with a dead-simple web server, there is
terrible network performance. Adding gzip support saved way more than
minification ever could. But the best performance improvement was to
add
caching support to the server. Both the browser and the server have to
cooperate there.
Pretty cool. The problem I'm having right now is the following pattern:
1. I have a mini-idea that takes me minutes to implement and turns the
ratchet in the right direction.
At the cost of adding dependencies for builds, and requiring builds be
done with Internet access. I don't think it's out of line to ask that
if we are going to add extra build requirements, we should make sure
it's really making decent progress.
Why do we need an external services?
cat style.css |
tr '\n' ' ' |
sed 's/\/\*[^*]*\*\///g' |
sed 's/\s\+/ /g' |
sed 's/ \?\([(){},;]\) \?/\1/g
Strictly speaking, this is overzealous (e.g. it also operates inside
strings), and I didn't even test it, but it will probably work for
almost all cases. The current main CSS file of dlang.org (style.css)
shrinks from 14757 to 11720 bytes, a reduction of ~21%.
But even writing a compressor in D should be trivial, as you'd only need
a lexer.
Would be a nice tools/ thing. Wanna do it/ --- Andrei
Re: dlang.org should do it in style
On 1/17/15 7:28 AM, Mathias LANG wrote: Quick question: how's the website synced ATM ? Is it some post-commit hook, manual, cron job ? make rebase -j && make clean && make rsync -j make clean is a complete bear. All - please make dub generation better. The redesign use a Vibe.d webserver. I'm wondering whether this is a possibility for dlang.org. I think it is. I will explore that with our webmaster. But beware - the least productive thing right now is yet another project I need to work on. Andrei
Re: css minification
On 1/17/15 4:58 AM, Mengu wrote: don't know if it's already said but if you are using nginx, We use Apache as far as I know. there's a plugin for minification and builtin support for compressing html pages or static assets. therefore, nobody needs a third-party dependency for building the docs. Opt-in is fine. Please review and pull: https://github.com/D-Programming-Language/dlang.org/pull/770 Andrei
Re: Eliminate comparison.html?
On Saturday, 17 January 2015 at 17:32:43 UTC, Andrei Alexandrescu wrote: In https://github.com/D-Programming-Language/dlang.org/pull/778 I'm proposing replacing http://dlang.org/comparison.html with http://erdani.com/d/comparison.html The silly one-column comparison was a vestige of a multi-column comparison that did more harm than good. I replaced it with a simple hierarchical list. However I wonder if we should eliminate the page altogether, or redo it completely. Thoughts? Andrei http://dlang.org/features2.html - http://dlang.org/D1toD2.html Maybe a good step for 2015 is to get ride of those. Regarding comparison, it feels a bit redundant with overview. However, your version is way easyier to "parse" than the wall of text in overview. IMO, adding the missing links would make it a suitable replacement.
Re: dlang.org page is missing
On 01/16/2015 09:15 PM, ketmar via Digitalmars-d wrote: > Hello. > > there is a link in side menu: "download&tools->debugger". it leads to > http://dlang.org/debugger.html which is missing. > There's a debugger.html in the dlang.org repository, so it looks to me like something on the uploading end. -- Paul O'Neil Github / IRC: todayman
Re: Variadic templates - D section on wikipedia
On 1/17/15 3:34 AM, Douglas Peterson wrote: https://en.wikipedia.org/wiki/Variadic_template Isn't it a pity that the first language supporting them hasn't even a section over there ? I invite any expert interested into the task to write the missing D section. Good idea. I created https://issues.dlang.org/show_bug.cgi?id=13994 to track this. Any takers? -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/17/15 4:40 AM, Manu via Digitalmars-d wrote: I guess we'll need another annoying __traits or something so I can pipe that information into my mixins that deal with ref mess... Yes. -- Andrei
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On 1/17/15 3:56 AM, Jacob Carlborg wrote: On 2015-01-17 00:01, Andrei Alexandrescu wrote: On 1/16/15 2:52 PM, Daniel Kozak wrote: P.S. I like this DIP, but I do not like way how things are done :( Please participate to improving how things are done. How can we do that when you're just saying things like "Time to move forward", "it's a judgement call", "lets do it" and then just merges Walter's pull requests? I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- Andrei
Re: post qualifier and template constraint limitation, is there a reason ?
On Saturday, 17 January 2015 at 17:08:12 UTC, ketmar via Digitalmars-d wrote: sure i have. i made alot of patches to the parser, so i know how it is written. to make this work parser need to be changed not less than to accept '@' before `pure`, `nothrow` and so on, and this change was rejected due to added complexity for supporting it by devteam. I'm sorry but this is not a good reason. It would be failry easy to add this in SDC's parser, so now what ? it tells nothing about the feature and everything about DMD's parser. as for "will not be used" -- you can use google to count requests for this feature. the numbers will show you how much people miss it. i have no habit of writing tales from the faery world, you know. Absence of information is not information.
Re:
On 1/17/15 1:29 AM, Jacob Carlborg wrote:
On 2015-01-17 09:22, Andrei Alexandrescu wrote:
Hello,
I was looking at
http://css-tricks.com/examples/CleanCode/Beautiful-HTML.png, which
includes an interesting comment: "ID applied to body to allow for unique
page styling without any additional markup."
That sounds pretty interesting, so I plan to add id="$(TITLE)" to the
tag of all dlang.org. Does anyone know how exactly that works?
The idea is that you have a unique ID attached to the body tag. This
needs to not only be unique in the given page but also among all pages.
The easiest is probably to use the URL of the current page, replace
slashes with dash or underscore. Something like this:
For the page http://dlang.org/spec.html
...
Then in the CSS you can add special styling for a given page, like this:
// custom styling for the "spec" page
body#spec {
background-color: black;
}
// custom styling for the "lex" page
body#lex {
background-color: white;
}
In the above examples "spec" should match the URL of the current page.
Thanks! See http://goo.gl/aHeZmQ where I've added the page title as the
ID. Sadly that doesn't work for titles that contain whitespace (quite a
few), see
http://stackoverflow.com/questions/5688200/can-i-use-white-spaces-in-the-name-attribute-of-an-html-element.
I think we need a ddoc macro REPLACE such that e.g. $(REPLACE a, A, b,
B, abC) yields ABC. That would also help things like ddoc -> json
generation.
The idea is that you can tweak the styling for a given page, not give it
a completely new look. Or to style elements that are not present on
other pages.
This technique is only useful when you're using the same CSS style sheet
for all your pages, which you should.
I don't know if there's an easy way to get the URL in Ddoc. It's easy
using server side software.
For now I guess we can implement REPLACE and fix the ID with Javascript.
Andrei
Eliminate comparison.html?
In https://github.com/D-Programming-Language/dlang.org/pull/778 I'm proposing replacing http://dlang.org/comparison.html with http://erdani.com/d/comparison.html The silly one-column comparison was a vestige of a multi-column comparison that did more harm than good. I replaced it with a simple hierarchical list. However I wonder if we should eliminate the page altogether, or redo it completely. Thoughts? Andrei
Re:
On 1/17/15 2:16 AM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 08:22:19 UTC, Andrei Alexandrescu wrote: Hello, I was looking at http://css-tricks.com/examples/CleanCode/Beautiful-HTML.png, which includes an interesting comment: "ID applied to body to allow for unique page styling without any additional markup." That sounds pretty interesting, so I plan to add id="$(TITLE)" to the tag of all dlang.org. Does anyone know how exactly that works? Thanks, Andrei What would be the benefit? Applying styles per page seems like a lot of workload for only one page. What if you want those styles to be applied on another page? Seems messy to me. It's good to have the capability of styling some pages slightly differently. I think that's rather obvious. -- Andrei
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: On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote: Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 Andrei 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. I'm very interested in that! I think the `return` notation is a good idea, and can maybe be reused in a more complete `scope` proposal. A downside is that it only applies to the return value, but not to other `out` and `ref` parameters. But the `!` syntax can work here, too.
Re: post qualifier and template constraint limitation, is there a reason ?
On Sat, 17 Jan 2015 16:55:31 +
deadalnix via Digitalmars-d wrote:
> On Saturday, 17 January 2015 at 16:02:16 UTC, ketmar via
> Digitalmars-d wrote:
> > On Sat, 17 Jan 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 ?
> > the first is easier to parse, and i it's looking better. the
> > second is
> > just unnecessary code in parser and will not be used in the
> > wild to the
> > extent that justifies increased complexity.
>
> You obviously have data to back your point, both in term of
> readability, use in the wild and complexity added in the parser.
> Because if you don't, you have no point whatsoever and should
> probably not be posting.
sure i have. i made alot of patches to the parser, so i know how it
is written. to make this work parser need to be changed not less than
to accept '@' before `pure`, `nothrow` and so on, and this change was
rejected due to added complexity for supporting it by devteam.
as for "will not be used" -- you can use google to count requests for
this feature. the numbers will show you how much people miss it.
i have no habit of writing tales from the faery world, you know.
signature.asc
Description: PGP signature
Re: http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
On Saturday, 17 January 2015 at 01:51:25 UTC, Steven
Schveighoffer wrote:
On 1/16/15 8:18 PM, Andrei Alexandrescu wrote:
On 1/16/15 4:56 PM, Steven Schveighoffer wrote:
On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:
On 1/16/15 2:52 PM, Daniel Kozak wrote:
Why DIP says: Last Modified: 2015-01-11
but from history I see lots of changing after that date?
I wish that were automated.
Well, it does include last modified automatically at the
bottom of the
page. Is it worth keeping that manual entry?
I tried to see if there was a way to reference that, but it's
not
possible from what I can tell.
Then I'd say just yank it. Apparently you can with an
extension:
http://www.mediawiki.org/wiki/Extension:LastModified
I figured it out, thanks in part to your link :)
{{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY}}
They HAVE to be capitalized (that took me a while to figure
out).
That's not necessarily a good change. The date should reflect
only when the actual content changes, but not e.g. when someone
adds a category, and probably neither for small changes like a
fixed typo.
DIP70
I've now created DIP70 for this issue: http://wiki.dlang.org/DIP70 Maybe a more sophisticated linking mechanism will make DIP70 unnecessary, but it should fuel the discussion nonetheless. Also, the wiki refused all of my attempts to insert the following links, saying they were non-canonical, despite my following the instructions on the help page: LINK1 (this thread): http://forum.dlang.org/thread/vlzwhhymkjgckgyox...@forum.dlang.org LINK2 (Dicebot's proposal): http://forum.dlang.org/post/otejdbgnhmyvbyaxa...@forum.dlang.org Please edit the wiki to correct this if you can.
Re: post qualifier and template constraint limitation, is there a reason ?
On Saturday, 17 January 2015 at 10:05:29 UTC, Walter Bright wrote:
On 1/17/2015 12:33 AM, deadalnix 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 ?
There was no known reason to.
Is that possible to make it work then ? Should I open a bug ?
Re: post qualifier and template constraint limitation, is there a reason ?
On Saturday, 17 January 2015 at 16:02:16 UTC, ketmar via
Digitalmars-d wrote:
On Sat, 17 Jan 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 ?
the first is easier to parse, and i it's looking better. the
second is
just unnecessary code in parser and will not be used in the
wild to the
extent that justifies increased complexity.
You obviously have data to back your point, both in term of
readability, use in the wild and complexity added in the parser.
Because if you don't, you have no point whatsoever and should
probably not be posting.
Re: Cross compiler for embedded microcontrollers ?
Thank you both Mike and Timo for clearing these things up. :) (I had the impression that multilib replaced glibcc, not the other way round - but clearly that's not what it was about). I've spent around 3 years on getting my toolchain working (!) -This is because I'm on a PowerPC based Mac. I can't just run some "do-it-for-you" script that other people uses for their toolchains; they all fail. So I had to do everything the hard way. I have multilib working, but I don't have it working with a toolchain that includes GDC. My toolchain is still alpha, and it will not work on Mac Pro with clang, but it might be useful for people wanting alternatives to the other toolchains. So hereby the first public reference to it: http://toolchain.gpio.dk/ Caveat: I may be experimentally changing it while you're viewing it, so you may get real annoyed with me, if you're in the middle of a build, and I've been messing with the Web-page and making draft-changes there. The original purpose of the page was to have a step-by-step guide for myself. Note: Although it's "prepared" for gdc, there's no steps (currently) for a successful build of gcc with gdc. But I do believe that one day, there will be a lot of people using D for embedded instead of C, as it's a far more suitable language for small devices.
Re: css minification
Another cheap addition, down to 11577 bytes:
cat style.css |
tr '\n' ' ' |
sed 's/\/\*[^*]*\*\///g' |
sed 's/\s\+/ /g' |
sed 's/ \?\([(){},;]\) \?/\1/g |
sed 's/;}/}/g'
Re: css minification
On Friday, 16 January 2015 at 22:02:27 UTC, Kiith-Sa wrote: Also, -1 for CSS minification, if I'll ever want to make any CSS contibutions I'll start by looking at the CSS in the browser. You'd use the DOM inspectors in this case, no? They don't care about the formatting of the CSS file.
Re: css minification
On Friday, 16 January 2015 at 22:32:07 UTC, Steven Schveighoffer
wrote:
On 1/16/15 5:23 PM, Andrei Alexandrescu wrote:
On 1/16/15 1:44 PM, Steven Schveighoffer wrote:
On an embedded product we have with a dead-simple web server,
there is
terrible network performance. Adding gzip support saved way
more than
minification ever could. But the best performance improvement
was to add
caching support to the server. Both the browser and the
server have to
cooperate there.
Pretty cool. The problem I'm having right now is the following
pattern:
1. I have a mini-idea that takes me minutes to implement and
turns the
ratchet in the right direction.
At the cost of adding dependencies for builds, and requiring
builds be done with Internet access. I don't think it's out of
line to ask that if we are going to add extra build
requirements, we should make sure it's really making decent
progress.
Why do we need an external services?
cat style.css |
tr '\n' ' ' |
sed 's/\/\*[^*]*\*\///g' |
sed 's/\s\+/ /g' |
sed 's/ \?\([(){},;]\) \?/\1/g
Strictly speaking, this is overzealous (e.g. it also operates
inside strings), and I didn't even test it, but it will probably
work for almost all cases. The current main CSS file of dlang.org
(style.css) shrinks from 14757 to 11720 bytes, a reduction of
~21%.
But even writing a compressor in D should be trivial, as you'd
only need a lexer.
2. I post it here in the hope that others will build upon or
come with
better ideas.
3. I get feedback here that essentially demonstrates me that
if I spent
some hours or days on a small research project on a better
idea, it
would yield better results.
I think you misunderstand. We are not saying "do a research
project", it takes seconds to gzip 2 files (the minified and
not minified) and see the size difference. If it's
super-significant, let's go for it! If you send me the minified
file, I can test it for you.
There doesn't need to be any research, but all the suggestions
that have been provided have NOT required extra tools or
dependencies. That is a significant difference.
-Steve
Re: dlang.org should do it in style
On Saturday, 17 January 2015 at 15:28:57 UTC, Mathias LANG wrote: http://w0rp.com:8010/ I don't know about others but for me the layout above looks more attractive than the actual one. In fact yesterday I was showing the main page for a friend on his smartphone (Moto G), and the code example at main page looks awful, since it's all wrapped on mobile. Here is an example what I'm talking about: http://i.imgur.com/9JYNVNk.png Matheus.
Re: post qualifier and template constraint limitation, is there a reason ?
On Sat, 17 Jan 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 ?
the first is easier to parse, and i it's looking better. the second is
just unnecessary code in parser and will not be used in the wild to the
extent that justifies increased complexity.
signature.asc
Description: PGP signature
