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 

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 

 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

 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

 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