On Wednesday, 4 December 2013 at 16:50:45 UTC, Dicebot wrote:
> On Wednesday, 4 December 2013 at 16:41:14 UTC, Puming wrote:
>> Other than diet, is there many other CTFE/template heavy parts?
>
> Also vibe.http.rest and vibe.http.form create really lot of template instances because of heavy usage of reflection + code generation. This is one of domains though that can potentially improve a lot by better compiler implementation,
>

>> I hope there would be a non-CTFE version of diet template, similar to regex/CTRegex. If we use the non-CTFE version in dev mode, we would have a better memory & compile time turnaround in dev mode. And in the release mode the diet templates would be optimized with CTFE. Is that a viable approach?
>
> That should be possible and relatively simple (because of CTFE nature a lot of code can be reused). It may considerably impact Diet performance but I can see desire for that in development mode as project size increases. As usual, it is mostly matter of manpower - vibe.d has only one persistent contributor right now and probably 5-8 guys doing occasional pull request, definitely not enough for project of that scale.

There maybe another traditional approach, by converting the .dt diet templates directly into D source code BEFORE the actuall compilation. That is the way many other HTML template systems use, and the performance is fairly good.

The generated D code could be very C like, and does not use much CTFE and templates, so that it doesn't incur a lot of compilation resources.

As as the matter of manpower, I'm very interested in D/Vibe.d, and will learn and try to contribute :-)

I'm currently using Java/Netty&Friends at work. But found D/Vibe.d would be a better solution in the future.

Thanks, it works :-)

So I can modify package.json to let dub know how to use phobos as shared lib.

Can vibe.d also be used as a shared lib?

It would be great if we have a

```
dub --build=shared
```

or something similar.



On Wednesday, 4 December 2013 at 16:53:13 UTC, Dicebot wrote:
> On Wednesday, 4 December 2013 at 16:44:14 UTC, Puming wrote:
>> Thanks, I'll try that :) are there docs about how to use phobos as a shared lib?
>
> $ cat test.d
> import std.stdio;
>
> void main()
> {
> 	writeln("Hello");
> }
>
> $ dmd test.d -defaultlib=libphobos2.so
> $ ls -lah test
> -rwxr-xr-x 1 dicebot users 26K Dec  4 17:51 test
> $ ldd test
> 	linux-vdso.so.1 (0x00007fffc82e7000)
> 	libphobos2.so.0.64 => /usr/lib/libphobos2.so.0.64 (0x00007ffd253e0000)
> 	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007ffd251c2000)
> 	libm.so.6 => /usr/lib/libm.so.6 (0x00007ffd24ebf000)
> 	librt.so.1 => /usr/lib/librt.so.1 (0x00007ffd24cb7000)
> 	libc.so.6 => /usr/lib/libc.so.6 (0x00007ffd2490c000)
> 	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007ffd24708000)
> 	libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007ffd244a3000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007ffd25a4e000)
> 	libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007ffd2427a000)
> 	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007ffd2400d000)
> 	libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007ffd23c05000)
> 	libz.so.1 => /usr/lib/libz.so.1 (0x00007ffd239ef000)
>
> (from my Arch Linux x64 box)

On Thursday, 5 December 2013 at 04:02:58 UTC, Puming wrote:
> There maybe another traditional approach, by converting the .dt diet templates directly into D source code BEFORE the actuall compilation. That is the way many other HTML template systems use, and the performance is fairly good.

It is somewhat complicated by the very tight integration between D handler host and Diet - you can expose D symbols for rendering context to template. It is still possible to do it that way but is likely to require more efforts and effectively will just to the same thing as good JIT-ed CTFE should. I don't like it because it is too effort-demanding for a quick hack and not suitable in the long term by design (one of D goals was to remove reliance on external build steps as much as possible)

On Thursday, 5 December 2013 at 13:49:51 UTC, Dicebot wrote:
> On Thursday, 5 December 2013 at 04:02:58 UTC, Puming wrote:
>> There maybe another traditional approach, by converting the .dt diet templates directly into D source code BEFORE the actuall compilation. That is the way many other HTML template systems use, and the performance is fairly good.
>
> It is somewhat complicated by the very tight integration between D handler host and Diet - you can expose D symbols for rendering context to template. It is still possible to do it that way but is likely to require more efforts and effectively will just to the same thing as good JIT-ed CTFE should. I don't like it because it is too effort-demanding for a quick hack and not suitable in the long term by design (one of D goals was to remove reliance on external build steps as much as possible)

Yes, I agree that for dev mode a pure runtime version would fit more and its implementation could take advantage of many functions in the CTFE version (or is that already possible?)