www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Issue with rendering dlang.org/library

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Per the screenshot at http://i.imgur.com/6lY57L6.png, the entire 
/library/ and /library-prerelease/ part of the website is not rendering 
properly at least in Chrome and Firefox on OSX.

Folks, there needs to be some visual testing with each pull request. 
This is one of the places where automated testing is rather difficult.

Also, the cycle of reporting back such issues should be a lot faster.

In related news, I don't know how to rebuild documentation with dub. If 
I run "make clean" followed by "make dpl-docs", it mentions something 
about things being up to date and recommends using --force to rebuild. 
How can things be up to date after "make clean"?

Anyhow I followed the advice and ran this by hand:

../dub-0.9.22/bin/dub build --force --root=dpl-docs 
--compiler=/tmp/.stable_dmd-2.066.1/dmd2/osx/bin/dmd

This time the tool output some other messages and still did not build 
the docs.

In switching to dub we're hoping there'd be improvement in the quality 
of website and a better build process. Please assist me in making that 
happen.


Thanks,

Andrei
Feb 14 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/02/2015 9:46 p.m., Andrei Alexandrescu wrote:
 Per the screenshot at http://i.imgur.com/6lY57L6.png, the entire
 /library/ and /library-prerelease/ part of the website is not rendering
 properly at least in Chrome and Firefox on OSX.

 Folks, there needs to be some visual testing with each pull request.
 This is one of the places where automated testing is rather difficult.

 Also, the cycle of reporting back such issues should be a lot faster.

 In related news, I don't know how to rebuild documentation with dub. If
 I run "make clean" followed by "make dpl-docs", it mentions something
 about things being up to date and recommends using --force to rebuild.
 How can things be up to date after "make clean"?

 Anyhow I followed the advice and ran this by hand:

 ../dub-0.9.22/bin/dub build --force --root=dpl-docs
 --compiler=/tmp/.stable_dmd-2.066.1/dmd2/osx/bin/dmd

 This time the tool output some other messages and still did not build
 the docs.

 In switching to dub we're hoping there'd be improvement in the quality
 of website and a better build process. Please assist me in making that
 happen.


 Thanks,

 Andrei
It might be wise to start setting up some form or web site testing. Like PhantomJS[0]. I personally haven't had the chance to use it yet. But it can create images from web pages it views and more importantly it's headless (no gui display required). I don't know how doable, but set it up to so it would auto submit the images to the github PR would be awesome. No excuse not to review the changes. [0] http://phantomjs.org/
Feb 14 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 14 February 2015 at 09:04:55 UTC, Rikki Cattermole 
wrote:

 It might be wise to start setting up some form or web site 
 testing.
 Like PhantomJS[0].
Can you write a PhantomJS test that checks whether a web page "looks broken"?
Feb 14 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/02/2015 10:48 p.m., Vladimir Panteleev wrote:
 On Saturday, 14 February 2015 at 09:04:55 UTC, Rikki Cattermole wrote:

 It might be wise to start setting up some form or web site testing.
 Like PhantomJS[0].
Can you write a PhantomJS test that checks whether a web page "looks broken"?
Anyone with DOM + javascript experience could. But it would be more of a set of unit tests then anything else. Design related stuff, its probably easier to just add the images to the PR so that humans can review it manually. Worse case scenario is nobody can say, it was pulled and its broken! Its PR'er's fault! No, it was whoever reviewed + pulled it as well for not checking those images. In PhantomJS you have full access to execute javascript and hence modify the DOM from within the host V8 engine. http://phantomjs.org/headless-testing.html
Feb 14 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 14 February 2015 at 10:08:16 UTC, Rikki Cattermole 
wrote:
 Anyone with DOM + javascript experience could. But it would be 
 more of a set of unit tests then anything else.
No, you have missed my point. without an AI, it is impossible to write a general test to check that the webpage "looks broken". Unless your plan is to check whether each image is aligned as it is expected to, in which case you need to add a test for each element of the DOM, and update the tests for each minor case. And what has been gained through that? There is nothing syntactically or semantically wrong with the DDox page. It is as valid as before the dlang.org overhaul. The problem is that it is using an old HTML layout with a new CSS file.
 Design related stuff, its probably easier to just add the 
 images to the PR so that humans can review it manually.
Have you been following the dlang.org github repository? Screenshots HAVE accompanied most PRs which change the website visually. The problem is that nobody considered DDox. And why should they? It would be unfair to force every contributor to also familiarize themselves with Ddox, Diet templates, and other components necessary. Especially with the build process being as broken as it is now (see my other post). If I plan to make the forum and wiki use the same templates, would it be fair that I demand that everyone changing the website layout to also integrate and test their changes for the forum and wiki?
 Worse case scenario is nobody can say, it was pulled and its 
 broken! Its PR'er's fault! No, it was whoever reviewed + pulled 
 it as well for not checking those images.
So now every reviewer and contributor has to know not just CSS, JS and HTML, but also Diet.d and Phantom unit testing. Way to raise the contribution bar!
 In PhantomJS you have full access to execute javascript and 
 hence modify the DOM from within the host V8 engine.
 http://phantomjs.org/headless-testing.html
I am well familiar with PhantomJS, I just don't see how it applies. The answer here is to make DDox as transparent as possible - make it stop using its own templating language and use the one we already use for everything else - HTML, PDF, Mobi, CHM - DDoc. If it can be divorced from Dub, as fragile as it is now, even better - the build process is complicated enough already. And there needs to be someone around to maintain it, you can't just create something and drop the maintenance burden on everyone else.
Feb 14 2015
parent "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Saturday, 14 February 2015 at 10:25:52 UTC, Vladimir Panteleev 
wrote:
 make it stop using its own templating language and use the one 
 we already use for everything else - HTML, PDF, Mobi, CHM - 
 DDoc.
DDoc isn't a good tool to generate webpages. For the simple reason that a webpage needs to be dynamic, i.e. handle stuff that isn't known while generating documentation. If I would run a D project that needed online documentation I would either have ddoc generate an intermediate structure or directly generate partial diet templates. I just do not see why ddoc needs to general html pages. What about single responsibility?
Feb 18 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-02-14 10:48, Vladimir Panteleev wrote:

 Can you write a PhantomJS test that checks whether a web page "looks
 broken"?
No, the only thing one can do is take screenshots and look at them manually or compare them with a previous state if similar. -- /Jacob Carlborg
Feb 14 2015
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 14 February 2015 at 09:04:55 UTC, Rikki Cattermole 
wrote:
 I don't know how doable, but set it up to so it would auto 
 submit the images to the github PR would be awesome.
That would be nice. Currently people have to do this by hand. This doesn't even need to have screenshots or use PhantomJS, it can just link to a generated copy of the docs. Automatic HTML validation would be nice too, although we do generate non-validating HTML in a few places that are not easily fixable.
Feb 14 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-02-14 10:04, Rikki Cattermole wrote:

 It might be wise to start setting up some form or web site testing.
 Like PhantomJS[0].
PhantomJS will only cover the WebKit engine. I guess it's better than nothing. For other browser engines there's a service called Saucelabs [1] that supports a lot of different browsers, platforms and versions. [1] https://saucelabs.com/ -- /Jacob Carlborg
Feb 14 2015
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 14 February 2015 at 08:46:58 UTC, Andrei 
Alexandrescu wrote:
 Per the screenshot at http://i.imgur.com/6lY57L6.png, the 
 entire /library/ and /library-prerelease/ part of the website 
 is not rendering properly at least in Chrome and Firefox on OSX.
All looks fine to me on up-to-date chrome, FF and safari. OS X 10.10
Feb 14 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 14 February 2015 at 10:46:07 UTC, John Colvin wrote:
 On Saturday, 14 February 2015 at 08:46:58 UTC, Andrei 
 Alexandrescu wrote:
 Per the screenshot at http://i.imgur.com/6lY57L6.png, the 
 entire /library/ and /library-prerelease/ part of the website 
 is not rendering properly at least in Chrome and Firefox on 
 OSX.
All looks fine to me on up-to-date chrome, FF and safari. OS X 10.10
That's impossible. Is your browser cache stale? Try pressing Ctrl+F5. Are you looking at the correct page? http://dlang.org/library/ The problem is with the upper-left corner.
Feb 14 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 14 February 2015 at 11:08:18 UTC, Vladimir Panteleev 
wrote:
 On Saturday, 14 February 2015 at 10:46:07 UTC, John Colvin 
 wrote:
 On Saturday, 14 February 2015 at 08:46:58 UTC, Andrei 
 Alexandrescu wrote:
 Per the screenshot at http://i.imgur.com/6lY57L6.png, the 
 entire /library/ and /library-prerelease/ part of the website 
 is not rendering properly at least in Chrome and Firefox on 
 OSX.
All looks fine to me on up-to-date chrome, FF and safari. OS X 10.10
That's impossible. Is your browser cache stale? Try pressing Ctrl+F5. Are you looking at the correct page? http://dlang.org/library/ The problem is with the upper-left corner.
My mistake, I was looking at the old documentation http://dlang.org/phobos/
Feb 14 2015
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 14.02.2015 um 09:46 schrieb Andrei Alexandrescu:
 Per the screenshot at http://i.imgur.com/6lY57L6.png, the entire
 /library/ and /library-prerelease/ part of the website is not rendering
 properly at least in Chrome and Firefox on OSX.

 Folks, there needs to be some visual testing with each pull request.
 This is one of the places where automated testing is rather difficult.

 Also, the cycle of reporting back such issues should be a lot faster.

 In related news, I don't know how to rebuild documentation with dub. If
 I run "make clean" followed by "make dpl-docs", it mentions something
 about things being up to date and recommends using --force to rebuild.
 How can things be up to date after "make clean"?
It's just the wrong make target. "apidocs-prerelease" and "apidocs-release" are the right ones. "dpl-docs" is only the utility executable that transforms the JSON documentation into HTML. The tool itself is managed by DUB, which is why "make clean" doesn't cause a rebuild, but we could add the proper "dub clean" command to the "clean" make target to fix that. I'll open a PR.
Feb 14 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/14/15 5:19 AM, Sönke Ludwig wrote:
 Am 14.02.2015 um 09:46 schrieb Andrei Alexandrescu:
 Per the screenshot at http://i.imgur.com/6lY57L6.png, the entire
 /library/ and /library-prerelease/ part of the website is not rendering
 properly at least in Chrome and Firefox on OSX.

 Folks, there needs to be some visual testing with each pull request.
 This is one of the places where automated testing is rather difficult.

 Also, the cycle of reporting back such issues should be a lot faster.

 In related news, I don't know how to rebuild documentation with dub. If
 I run "make clean" followed by "make dpl-docs", it mentions something
 about things being up to date and recommends using --force to rebuild.
 How can things be up to date after "make clean"?
It's just the wrong make target. "apidocs-prerelease" and "apidocs-release" are the right ones. "dpl-docs" is only the utility executable that transforms the JSON documentation into HTML. The tool itself is managed by DUB, which is why "make clean" doesn't cause a rebuild, but we could add the proper "dub clean" command to the "clean" make target to fix that. I'll open a PR.
Thanks! While I got a slide of your time, any chance you could take a look at https://issues.dlang.org/show_bug.cgi?id=14180? Right now I essentially need to temporarily hide my dmd rig just to build the docs. -- Andrei
Feb 14 2015