RejectedSoftware Forums

Am 04.10.2016 um 22:34 schrieb Empty soul:

Vibe.d has a slow design process due to having to recompile everything when making even the minutest changes.

Is there a way, when a dt is changed to just recompile that dt without having to recompile the whole web server?

Not directly, but the latest RC (0.7.30-rc.1) can cache the compiled
Diet templates, which can speed up the compilation process considerably.
See
https://github.com/rejectedsoftware/diet-ng/#experimental-html-template-caching.
One thing that hopefully obsoletes this is the ongoing work in DMD's
CTFE interpreter, which is expected to bring huge compile-time improvements.

There is also a pull request for DUB that adds a "watch" command,
which automatically rebuilds and restarts the application whenever a
source file changes. Together with the template caching and a permanent
session storage, this is almost as good as using an interpreted language.

On Fri, 07 Oct 2016 21:46:20 GMT, Empty soul wrote:

On Fri, 7 Oct 2016 21:40:32 +0200, Sönke Ludwig wrote:

Am 04.10.2016 um 22:34 schrieb Empty soul:

Vibe.d has a slow design process due to having to recompile everything when making even the minutest changes.

Is there a way, when a dt is changed to just recompile that dt without having to recompile the whole web server?

Not directly, but the latest RC (0.7.30-rc.1) can cache the compiled
Diet templates, which can speed up the compilation process considerably.
See
https://github.com/rejectedsoftware/diet-ng/#experimental-html-template-caching.
One thing that hopefully obsoletes this is the ongoing work in DMD's
CTFE interpreter, which is expected to bring huge compile-time improvements.

There is also a [pull request][1] for DUB that adds a "watch" command,
which automatically rebuilds and restarts the application whenever a
source file changes. Together with the template caching and a permanent
session storage, this is almost as good as using an interpreted language.

[1]: https://github.com/dlang/dub/pull/446

Ok, do you have any TOA for the watch command? I think the thing that is slowing dub down is checking for updates.

running dub stalls for a few seconds then shows

vibe-d:utils 0.7.29: target for configuration "library" is up to date.
vibe-d:data 0.7.29: target for configuration "library" is up to date.
vibe-d:core 0.7.29: target for configuration "libevent" is up to date.
vibe-d:http 0.7.29: target for configuration "library" is up to date.
vibe-d:diet 0.7.29: target for configuration "library" is up to date.
vibe-d:mail 0.7.29: target for configuration "library" is up to date.
vibe-d:mongodb 0.7.29: target for configuration "library" is up to date.
vibe-d:redis 0.7.29: target for configuration "library" is up to date.
vibe-d:web 0.7.29: target for configuration "library" is up to date.
vibe-d 0.7.29: target for configuration "libevent" is up to date.

Of course, I don't think it should check for updates all the time(once a week maybe?).

"up to date" in this case just means that the binary is not older than the source files from which the package is built. It requires scanning through the source folder, but this is usually very fast. My guess is that the actual time is mainly spent in dependency resolution and local package enumeration. This should be much faster in a release build, but currently the release build crashes for some reason.

But the watch command could usually skip both steps, too, so it should indeed help here. So the current PR still needs to be refactored and extended a bit to be solid in terms of functionality, and it lacks a Windows implementation (can be copied from vibe.d's win32 driver). The ETA largely depends on how much time either Martin or another contributor can devote for it. I would also try to have a go, but I also have a ton of high priority stuff still on my list.

On Tue, 25 Oct 2016 12:46:49 GMT, dannyw wrote:

On Sat, 15 Oct 2016 12:36:57 GMT, Sönke Ludwig wrote:

On Fri, 07 Oct 2016 21:46:20 GMT, Empty soul wrote:

On Fri, 7 Oct 2016 21:40:32 +0200, Sönke Ludwig wrote:

Am 04.10.2016 um 22:34 schrieb Empty soul:

Vibe.d has a slow design process due to having to recompile everything when making even the minutest changes.

Is there a way, when a dt is changed to just recompile that dt without having to recompile the whole web server?

Not directly, but the latest RC (0.7.30-rc.1) can cache the compiled
Diet templates, which can speed up the compilation process considerably.
See
https://github.com/rejectedsoftware/diet-ng/#experimental-html-template-caching.
One thing that hopefully obsoletes this is the ongoing work in DMD's
CTFE interpreter, which is expected to bring huge compile-time improvements.

There is also a [pull request][1] for DUB that adds a "watch" command,
which automatically rebuilds and restarts the application whenever a
source file changes. Together with the template caching and a permanent
session storage, this is almost as good as using an interpreted language.

[1]: https://github.com/dlang/dub/pull/446

Ok, do you have any TOA for the watch command? I think the thing that is slowing dub down is checking for updates.

running dub stalls for a few seconds then shows

vibe-d:utils 0.7.29: target for configuration "library" is up to date.
vibe-d:data 0.7.29: target for configuration "library" is up to date.
vibe-d:core 0.7.29: target for configuration "libevent" is up to date.
vibe-d:http 0.7.29: target for configuration "library" is up to date.
vibe-d:diet 0.7.29: target for configuration "library" is up to date.
vibe-d:mail 0.7.29: target for configuration "library" is up to date.
vibe-d:mongodb 0.7.29: target for configuration "library" is up to date.
vibe-d:redis 0.7.29: target for configuration "library" is up to date.
vibe-d:web 0.7.29: target for configuration "library" is up to date.
vibe-d 0.7.29: target for configuration "libevent" is up to date.

Of course, I don't think it should check for updates all the time(once a week maybe?).

"up to date" in this case just means that the binary is not older than the source files from which the package is built. It requires scanning through the source folder, but this is usually very fast. My guess is that the actual time is mainly spent in dependency resolution and local package enumeration. This should be much faster in a release build, but currently the release build crashes for some reason.

But the watch command could usually skip both steps, too, so it should indeed help here. So the current PR still needs to be refactored and extended a bit to be solid in terms of functionality, and it lacks a Windows implementation (can be copied from vibe.d's win32 driver). The ETA largely depends on how much time either Martin or another contributor can devote for it. I would also try to have a go, but I also have a ton of high priority stuff still on my list.

I think what he is wanting can be done with:

dub --nodeps

In order to improve the development speed, specially when changing html templates, we built vayne: https://code.dlang.org/packages/vayne

This uses a template language close to mustache and allows you to do changes to your templates without having to recompile or even restart your webserver.