www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ready for testing: vibe.d 0.7.26-alpha.3

reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
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
Oct 13 2015
next sibling parent reply Brad Anderson <eco gnuk.net> writes:
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.
Oct 13 2015
next sibling parent reply Brad Anderson <eco gnuk.net> writes:
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);
Oct 13 2015
parent reply Colden Cullen <ColdenCullen gmail.com> writes:
On Wednesday, 14 October 2015 at 06:29:03 UTC, Brad Anderson 
wrote:
 [snip]
https://github.com/rejectedsoftware/vibe.d/pull/1293
Oct 13 2015
parent Brad Anderson <eco gnuk.net> writes:
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!
Oct 13 2015
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Oct 30 2015
next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
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.
Oct 30 2015
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
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?
Oct 30 2015
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 30 October 2015 at 21:03:21 UTC, Brad Anderson wrote:
 On Friday, 30 October 2015 at 16:16:11 UTC, Sebastiaan Koppe
 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?
In frontend development people are likely to use the same framework/library they used last time, in order to speed up development. Besides know-how, most of that stuff is battle-tested. There are lots of quirks with ajax and getting everything right takes time. Take for instance the variety of errors (that nobody seems to check on): bad request, exception on server, cors errors, wrong response type, connection timeout (server down), no internet. (I live in China and the great firewall leaves a lot of websites in a half working state. There are only a few sites that catch these failures and notify the user, everything else just freezes.) I personally am a big fan of React and RxJS, so if I do anything with ajax, it's convenient to use ajax extensions for RxJS, since I am using it anyway. So, given that it takes time to develop your own ajax lib, and people already use frameworks/libraries that have good ajax support, it makes no sense to develop your own. Instead, what you want to do is generate code that uses one of those libraries. Here is an example of how an ajax call looks like using RxDom, an extension for RxJS: ``` import RxDom from 'rx-dom'; module.exports={ status: () => { return RxDom.DOM.ajax( { url:"/api/v1/status", method:"GET", responseType:"json" }).pluck('response'); }, //.... } ```
Oct 30 2015
next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Saturday, 31 October 2015 at 03:07:35 UTC, Sebastiaan Koppe 
wrote:
 In frontend development people are likely to use the same 
 framework/library they used last time, in order to speed up 
 development. Besides know-how, most of that stuff is 
 battle-tested.

 [...]
Very interesting. Thanks for answering.
Oct 31 2015
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Saturday, 31 October 2015 at 07:57:06 UTC, Brad Anderson wrote:
 On Saturday, 31 October 2015 at 03:07:35 UTC, Sebastiaan Koppe 
 wrote:
 In frontend development people are likely to use the same 
 framework/library they used last time, in order to speed up 
 development. Besides know-how, most of that stuff is 
 battle-tested.

 [...]
Very interesting. Thanks for answering.
The other thing is that you want to tap into their workflow. Every frontend developer uses npm and every project starts with tools like grunt or gulp, browserify or webpack, + a dozen others. What these tools do is support their development - every time they save a file their code gets linted, cross-compiled from es6/7 or coffeescript down to javascript, sourcemaps get created, everything gets concatenated, and sometimes hot loaded into their browser so they don't have to press F5. For production these tools do similar work but often uglify and apply some cache-busting techniques as well. For css the tools are similar, but they operate on less or sass files. This all means that the js interface that gets generated by vibe needs to be integrated into their gulp/grunt workflow, which basically means generation the interface at compile time.
Oct 31 2015
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 31 October 2015 at 03:07:35 UTC, Sebastiaan Koppe 
wrote:
 On Friday, 30 October 2015 at 21:03:21 UTC, Brad Anderson wrote:
 On Friday, 30 October 2015 at 16:16:11 UTC, Sebastiaan Koppe
 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?
In frontend development people are likely to use the same framework/library they used last time, in order to speed up development. Besides know-how, most of that stuff is battle-tested.
Keep in mind that javascript frameworks die after ~2 years.
 Instead, what you want to do is generate code that uses one of 
 those libraries. Here is an example of how an ajax call looks
Browsers are now providing promises/futures for fetching data: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise
Nov 01 2015
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Sunday, 1 November 2015 at 19:44:12 UTC, Ola Fosheim Grøstad 
wrote:
 Keep in mind that javascript frameworks die after ~2 years.
They may die young, but every framework is an improvement upon the last. So in a way the reasoning and principles behind them continue. In that sense it follows the development pattern everything with computers does: Cool Idea -> Everybody Happy -> It Sucks -> Complete Rewrite
 Browsers are now providing promises/futures for fetching data:

 https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
 https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise
Yep, that would be another target. And while it is a nice development, promises and futures don't even come close to the power of RxJS or BaconJS. https://github.com/Reactive-Extensions/RxJS http://baconjs.github.io/
Nov 01 2015
prev sibling next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
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.
Oct 20 2015
prev sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
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.
Oct 30 2015