Re: Release D 2.078.0
On Wednesday, 10 January 2018 at 21:42:38 UTC, Nathan S. wrote: When I remove the "inline" option the build + test time becomes <10 seconds. So the weirdly slow part is related to inlining. filed so we don't forget: https://issues.dlang.org/show_bug.cgi?id=18221
Re: Release D 2.078.0
On Wednesday, 10 January 2018 at 21:32:55 UTC, Nathan S. wrote: On my mac laptop running DMD 2.078.0, building and running the mir-algorithm unittests takes 8 seconds normally but takes ~3 minutes 49 seconds with dub options "releaseMode", "optimize", "inline", "noBoundsCheck". When I remove the "inline" option the build + test time becomes <10 seconds. So the weirdly slow part is related to inlining.
Re: Release D 2.078.0
DMD64 2.078.0 on Linux and macOS is taking wildly longer to build and run unittests for mir-algorithm. The extra time appears to be related to release mode optimizations. Build logs: https://travis-ci.org/libmir/mir-algorithm/builds/324052159 DMD 2.077.1 for linux32: 3 min 20 sec DMD 2.077.1 for linux64: 3 min 16 sec DMD 2.077.1 for mac64: 5 min 4 sec DMD 2.078.0-rc.1 for linux32: 13 min 30 sec DMD 2.078.0-rc.1 for linux64: 9 min 39 sec DMD 2.078.0-rc.1 for mac64: 10 min 56 sec, then the job was aborted The above tests all include a non-release build and a release build. On my mac laptop running DMD 2.078.0, building and running the mir-algorithm unittests takes 8 seconds normally but takes ~3 minutes 49 seconds with dub options "releaseMode", "optimize", "inline", "noBoundsCheck". I don't see any new compiler optimizations in the changelog. Any idea of what could be causing this?
Re: [howto] Serve ddox documentation on github.io deployed by Travis CI
On Wednesday, 10 January 2018 at 02:59:38 UTC, Martin Nowak wrote: I've changed my blueprint project accordingly https://github.com/MartinNowak/bloom/blob/1e2c2729a2618962e596d68635c5e7e46def2189/.travis.yml. I included a link to bloom at the bottom of the howto.
Re: [howto] Serve ddox documentation on github.io deployed by Travis CI
On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote: I don't know if I am being paranoid but it's been said that GitHub tokens give access to all repositories and just pasting an unencrypted token in some web interface is a security risk. For a howto I figured the safer route is better. [1] https://gist.github.com/vidavidorra/548ffbcdae99d752da02 For clarity: following the howto [2] you do the encryption locally and limit access to the repository in question. [2] https://gist.github.com/veelo/f7668510bad2e8c9212ab66104541fcc
Re: [howto] Serve ddox documentation on github.io deployed by Travis CI
On Wednesday, 10 January 2018 at 02:59:38 UTC, Martin Nowak wrote: [...] Also adding the token in Travis' settings page instead in the yaml makes things easier. Yes it does make it easier. But I chose not to because of comments on [1] (notably by ilg-ul). I don't know if I am being paranoid but it's been said that GitHub tokens give access to all repositories and just pasting an unencrypted token in some web interface is a security risk. For a howto I figured the safer route is better. [1] https://gist.github.com/vidavidorra/548ffbcdae99d752da02 Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering? This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
