Despite it's name, this release should be considered a beta release. PR #1268[1] will potentially still make it in, but otherwise only bug fixing will happen at this point. As with the previous versions, the final release will happen at the same time as DMD 2.069.0. Please use the chance to test for any remaining issues (simply run `dub upgrade --prerelease` on your project(s)).

Changes in this release:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

[1]: https://github.com/rejectedsoftware/vibe.d/pull/1268

On Tuesday, 13 October 2015 at 07:38:33 UTC, Sönke Ludwig wrote:
> Despite it's name, this release should be considered a beta release. PR #1268[1] will potentially still make it in, but otherwise only bug fixing will happen at this point. As with the previous versions, the final release will happen at the same time as DMD 2.069.0. Please use the chance to test for any remaining issues (simply run `dub upgrade --prerelease` on your project(s)).
>
> Changes in this release:
> https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
>
> [1]: https://github.com/rejectedsoftware/vibe.d/pull/1268

Trying out the new JS interface generation on a little toy project I'm getting:

  this.vote = function(winner, loser, on_error) {
    var url = "http://127.0.0.1:8008/vote";
    var postbody = {
      "winner": toRestString(winner),
      "loser": toRestString(loser),
    };
    var xhr = new XMLHttpRequest();
    xhr.open('PUT', url, true);
    xhr.onload = function () { if (this.status >= 400) { if (on_error) on_error(JSON.parse(this.responseText)); else console.log(this.responseText); } else on_result(JSON.parse(this.responseText)); };
    xhr.setRequestHeader('Content-Type', 'application/json');
    xhr.send(JSON.stringify(postbody));
  }

The on_result was never defined before use.

The interface method looks like this:

    @property void vote(int winner, int loser);

Really cool feature though.

On Wednesday, 14 October 2015 at 06:23:38 UTC, Brad Anderson wrote:
> [snip]
> The interface method looks like this:
>
>     @property void vote(int winner, int loser);

Actually: void vote(int winner, int loser);

On Wednesday, 14 October 2015 at 06:29:03 UTC, Brad Anderson wrote:
> [snip]

https://github.com/rejectedsoftware/vibe.d/pull/1293

On Wednesday, 14 October 2015 at 06:50:18 UTC, Colden Cullen wrote:
> On Wednesday, 14 October 2015 at 06:29:03 UTC, Brad Anderson wrote:
>> [snip]
>
> https://github.com/rejectedsoftware/vibe.d/pull/1293

Great!

Am 13.10.2015 um 09:38 schrieb Sönke Ludwig:
> Despite it's name, this release should be considered a beta release. PR
> #1268[1] will potentially still make it in, but otherwise only bug
> fixing will happen at this point. As with the previous versions, the
> final release will happen at the same time as DMD 2.069.0. Please use
> the chance to test for any remaining issues (simply run `dub upgrade
> --prerelease` on your project(s)).
>
> Changes in this release:
> https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
>
> [1]: https://github.com/rejectedsoftware/vibe.d/pull/1268

The official first beta has now been tagged and includes fixes for the issues found in the last alpha. REST collections didn't make it for this release, but the new TaskReadWriteMutex did.

Am 13.10.2015 um 09:38 schrieb Sönke Ludwig:
> Despite it's name, this release should be considered a beta release. PR
> #1268[1] will potentially still make it in, but otherwise only bug
> fixing will happen at this point. As with the previous versions, the
> final release will happen at the same time as DMD 2.069.0. Please use
> the chance to test for any remaining issues (simply run `dub upgrade
> --prerelease` on your project(s)).
>
> Changes in this release:
> https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
>
> [1]: https://github.com/rejectedsoftware/vibe.d/pull/1268

First release candidate has been tagged and contains some additional libasync driver fixes. It doesn't compile with the current DMD 2.069.0-rc1, but is supposed to do so on the upcoming 2.069.0-rc2.

On Wednesday, 14 October 2015 at 06:23:38 UTC, Brad Anderson wrote:
> Trying out the new JS interface generation on a little toy project I'm getting:
>
> [...]
>
> Really cool feature though.

I really have to say I fail to see any value in that JS interface generation feature. The idea is nice, but it needs adapters to common ajax libraries, instead of homegrown stuff.

Am 30.10.2015 um 17:16 schrieb Sebastiaan Koppe:
> On Wednesday, 14 October 2015 at 06:23:38 UTC, Brad Anderson wrote:
>> Trying out the new JS interface generation on a little toy project I'm
>> getting:
>>
>> [...]
>>
>> Really cool feature though.
>
> I really have to say I fail to see any value in that JS interface
> generation feature. The idea is nice, but it needs adapters to common
> ajax libraries, instead of homegrown stuff.

Well, you can always call normal JS functions from any framework, even if that doesn't exploit the full potential. This was mainly meant as a proof-of-concept implementation that works universally, but I agree that specialized implementations would be the logical next step.

On Friday, 30 October 2015 at 16:16:11 UTC, Sebastiaan Koppe wrote:
> On Wednesday, 14 October 2015 at 06:23:38 UTC, Brad Anderson wrote:
>> Trying out the new JS interface generation on a little toy project I'm getting:
>>
>> [...]
>>
>> Really cool feature though.
>
> I really have to say I fail to see any value in that JS interface generation feature. The idea is nice, but it needs adapters to common ajax libraries, instead of homegrown stuff.

I'm not really a web developer. Do you have any examples of what you mean?