Re: Mobile App STACK4 with a D backend
On 2013-12-22 05:38, extrawurst wrote: Hello fellow Dlers ;) about a week ago I released the multiplayer version of my android app STACK4 (https://play.google.com/store/apps/details?id=com.Extrawurst.FIR). The app itself is using the free unity3d engine (C#) for the frontend but, after quite a journey, the backend was developed using D and the awesome vibe.d framework. While I am preparing a pretty detailed article about why it was a journey to the point of using D and how using D worked out in the end I would ask everyone who has access to an android device to test the app and give me feedback about every kind of problem you may encounter! Cause apparently the ordanary android customer just downloads and throws a 1-star rating at you without telling you why the hell they are disappointed with it :( Cheers, Stephan Works great on my S4 against AI (damned AI beats me every time). Haven't tried on-line game play yet. Looking forward to your write up.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 27 December 2013 at 16:40:57 UTC, Alexander Bothe wrote: Hi everyone, Despite I released the big completion engine refactoring half a week ago I'd still like to announce it over here as well. There's been a complete completion engine overhaul (i.e. the part that matches the currently selected code part against the abstract symbol node in the AST and furthermore prepares the resolution of that node) and several performance improvements concerning parsing code & code completion. The full release note: http://mono-d.alexanderbothe.com/huge-completion-engine-refactoring-less-internal-clutter-v0-5-5-5/ Completion bugs/issues/requests: https://github.com/aBothe/D_Parser/issues Non-completion related stuff: https://github.com/aBothe/Mono-D/issues Cheers, Alex I must admit, that you do lots of awsome work on this IDE (plugin). But still it is quiet bad. After clean install I am not able to run even basic hello world. Ok I can uninstall gnome-terminal and install xterm. After that I can run basic terminal apps, but not debug them :(. Maybe it would be better to stop adding new features and try to make it more stable.
Re: Temple: Compile time, embedded D templates
On Thursday, 2 January 2014 at 10:59:27 UTC, Jacob Carlborg wrote: On 2014-01-02 02:12, Dylan Knutson wrote: It didn't before, because of how the semantics of eRuby syntax works, but now it does! It seemed like an important thing to support... Here's an example mimicking a subset of Rails' `form_for` helper: [Snip] Nice. Do you have any concept of safe vs unsafe strings? No, but that's been on the to-do list. I feel like safe vs. unsafe strings are tied heavily with the escaping of unsafe strings, which is specific to a language, so I think the best way to go about this is to provide: - A way to define custom "string" types (like a struct wrapping a string tracking if it's safe or not) - Callbacks for processing all of the string-ey things written to the output buffer, to decide if something should be escaped or not.
Re: Delight
On Thursday, 25 September 2008 at 14:00:30 UTC, bearophile wrote: D1 + Tango with a different Python-inspired syntax; close to my ideal language: http://delight.sourceforge.net/ There are just few things I don't like, but they are generally minor, and maybe the author can change some of them still. Bye, bearophile Thank you for telling that it has "Python-inspired" syntax, so I save myself time by avoiding the project...
Re: D is back on TIOBE top 20
On Thursday, 2 January 2014 at 10:33:53 UTC, Namespace wrote: On Thursday, 2 January 2014 at 10:30:34 UTC, Dejan Lekic wrote: I know this does not say much, especially considering that TransactSQL is declared "language of the year" on TIOBE. :) Anyway, good to see that D is gaining popularity. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://forum.dlang.org/thread/mmqokwtboeqjhbsxq...@forum.dlang.org #22 was not good enough. :) Being in the first 20 is what matters as new programmers who visit TIOBE out of curiousity may become interested in D when they see it in the list. Everything below 20 is more/less invisible to the common visitor there...
Re: Temple: Compile time, embedded D templates
On 2014-01-02 02:12, Dylan Knutson wrote: It didn't before, because of how the semantics of eRuby syntax works, but now it does! It seemed like an important thing to support... Here's an example mimicking a subset of Rails' `form_for` helper: [Snip] Nice. Do you have any concept of safe vs unsafe strings? -- /Jacob Carlborg
Re: D is back on TIOBE top 20
On Thursday, 2 January 2014 at 10:30:34 UTC, Dejan Lekic wrote: I know this does not say much, especially considering that TransactSQL is declared "language of the year" on TIOBE. :) Anyway, good to see that D is gaining popularity. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://forum.dlang.org/thread/mmqokwtboeqjhbsxq...@forum.dlang.org
D is back on TIOBE top 20
I know this does not say much, especially considering that TransactSQL is declared "language of the year" on TIOBE. :) Anyway, good to see that D is gaining popularity. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Re: Temple: Compile time, embedded D templates
On Thursday, 2 January 2014 at 06:59:04 UTC, yazd wrote:
How much of this is done at compile-time?
Strictly speaking, just the generation of the code that writes
the template to the output buffer. E.g, the code above simulating
the Rails form helper would be lowered to code approximately
equivalent to this (but with more fluff to add line numbers, and
expose some needed hooks for the context):
```
void Temple(OutputStream __buff, TempleContext __context = null)
{
//...
//struct FormHelper, etc
//...
// The actual rendering into a buffer code
auto __buff_tmp_0 = form_for("/shorten", "", (f) {
__buff.put("Shorten a URL: ");
__buff.put(to!string( f.field_for("url") ));
__buff.put(to!string( f.submit("Shorten URL") ));
});
__buff.put(__buff_tmp_0);
auto __buff_tmp_1 = form_for("/person", "person", (f) {
__buff.put("Name: ");
__buff.put(to!string( f.field_for("name") ));
__buff.put("Age: ");
__buff.put(to!string( f.field_for("age") ));
__buff.put("DOB: ");
__buff.put(to!string( f.field_for("date_of_birth", "date") ));
__buff.put(to!string( f.submit ));
});
__buff.put(__buff_tmp_1);
}
```
I would guess that
the code is compiled but it is evaluated on each render. Is
that correct? Is there a way to force compile-time evaluation
of at least part of the template which does not depend on a
runtime value?
Yes, generated templates themselves can be executed with CTFE
(just had to make a small modification to ArrayOutputAppender,
which has been pushed), as long as they don't take a context. The
reason for this is that std.variant.Variant isn't CTFEable,
because it uses memcpy in opAssign. I'd consider that a Phobos
bug; perhaps there is a way to make std.variant CTFE compatible?
That'd allow for a much wider (and more useful) range of
templates to be evaluated at compile time.
Anyways, here's a working compile time evaluated, compile time
generated template:
```
string templeToString(TempleFuncType* func, TempleContext context
= null)
{
auto accum = new AppenderOutputStream;
(*func)(accum, context);
return accum.data;
}
unittest
{
alias render = Temple!q{
<% if(true) { %>
Bort
<% } else { %>
No bort!
<% } %>
<% auto a = capture(() { %>
inside a capture block
<% }); %>
Before capture
<%= a %>
After capture
};
const result = templeToString(&render);
static assert(isSameRender(result, `
Bort
Before capture
inside a capture block
After capture
`));
}
```
