After a last minute path type redesign, the state of the new vibe-core package now finally feels ready for the first official release. The library is in a pretty good shape, with the notable exception that sockets are not yet implemented on Windows in the new eventcore abstraction layer. This will be tackled ASAP, but is independent from vibe-core itself in terms of code dependencies.

Change logs for vibe.d 0.8.0 (over 0.7.31) and vibe-core 1.0.0 (over vibe-d:core) respectively can be reviewed on GitHub:

https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
https://github.com/vibe-d/vibe-core/blob/master/CHANGELOG.md

Testing can be done by selecting the "vibe-core" configuration of the ":core" sub module:

    // dub.sdl:
    dependency "vibe-d:core" version="~>0.8.0-rc"
    subConfiguration "vibe-d:core" "vibe-core"

    // dub.json:
    "dependencies": {
        "vibe-d:core": "~>0.8.0-rc"
    },
    "subConfigurations": {
        "vibe-d:core": "vibe-core"
    }

The final release is scheduled for Monday unless any regressions come up until them.

On Thursday, 22 June 2017 at 08:55:06 UTC, Sönke Ludwig wrote:
> After a last minute path type redesign, the state of the new vibe-core package now finally feels ready for the first official release. The library is in a pretty good shape, with the notable exception that sockets are not yet implemented on Windows in the new eventcore abstraction layer. This will be tackled ASAP, but is independent from vibe-core itself in terms of code dependencies.
>
> [...]

Thw Websocket api seem a little low-level (unclear) compared to the feel of http server. I'm not sure if its on purpose or could use some future api design/abstraction.

Vibe.d is really great.

Am 22.06.2017 um 20:52 schrieb aberba:
> On Thursday, 22 June 2017 at 08:55:06 UTC, Sönke Ludwig wrote:
>> After a last minute path type redesign, the state of the new vibe-core package now finally feels ready for the first official release. The library is in a pretty good shape, with the notable exception that sockets are not yet implemented on Windows in the new eventcore abstraction layer. This will be tackled ASAP, but is independent from vibe-core itself in terms of code dependencies.
>>
>> [...]
> 
> Thw Websocket api seem a little low-level (unclear) compared to the feel of http server. I'm not sure if its on purpose or could use some future api design/abstraction.
> 
> Vibe.d is really great.

Agreed, there are several places in there that can be improved or made more consistent. The HTTP package (including WebSockets) is the next big part that is up for a complete redesign, also (finally) including HTTP/2 support. Since I'm really busy with another project I can't state a reliable schedule for this, but I'll try to start in the near future and will also to try to involve interested people in the design/development process as early as that makes sense.

Am 22.06.2017 um 10:55 schrieb Sönke Ludwig:
> After a last minute path type redesign, the state of the new vibe-core
> package now finally feels ready for the first official release. The
> library is in a pretty good shape, with the notable exception that
> sockets are not yet implemented on Windows in the new eventcore
> abstraction layer. This will be tackled ASAP, but is independent from
> vibe-core itself in terms of code dependencies.
>
> Change logs for vibe.d 0.8.0 (over 0.7.31) and vibe-core 1.0.0 (over
> vibe-d:core) respectively can be reviewed on GitHub:
>
> https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
> https://github.com/vibe-d/vibe-core/blob/master/CHANGELOG.md
>
> Testing can be done by selecting the "vibe-core" configuration of the
> ":core" sub module:
>
>     // dub.sdl:
>     dependency "vibe-d:core" version="~>0.8.0-rc"
>     subConfiguration "vibe-d:core" "vibe-core"
>
>     // dub.json:
>     "dependencies": {
>         "vibe-d:core": "~>0.8.0-rc"
>     },
>     "subConfigurations": {
>         "vibe-d:core": "vibe-core"
>     }
>
> The final release is scheduled for Monday unless any regressions come up
> until them.

There have been some minor fixes and vibe.d 0.8.0-rc.2 and vibe-core 1.0.0-rc.2 have been tagged. The final release is rescheduled for Monday, July the 3rd.

On Tuesday, 27 June 2017 at 09:20:40 UTC, Sönke Ludwig wrote:
> Am 22.06.2017 um 10:55 schrieb Sönke Ludwig:
> There have been some minor fixes and vibe.d 0.8.0-rc.2 and vibe-core 1.0.0-rc.2 have been tagged. The final release is rescheduled for Monday, July the 3rd.

It seems there is an issue with the dmd 2.075.0-b1 and rc.2

vibe-d:utils 0.8.0-rc.2: building configuration "library"...
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\utils\hashmap.d(258,45): Error: function vibe.utils.hashmap.HashMap!(void*, uint, DefaultHashMapTraits!(void*)).HashMap.AW (IAllocator a) is not callable using argument types (shared(ISharedAllocator))
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(199,21): Error: template instance vibe.utils.hashmap.HashMap!(void*, uint, DefaultHashMapTraits!(void*)).HashMap.opIndexAssign!uint error instantiating
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(199,21): Error: function 'vibe.utils.hashmap.HashMap!(void*, uint, DefaultHashMapTraits!(void*)).HashMap.opIndexAssign!uint.opIndexAssign' is not nothrow
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(194,9): Error: nothrow function 'vibe.internal.memory_legacy.DebugAllocator.alloc' may throw
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(218,21): Error: function 'vibe.utils.hashmap.HashMap!(void*, uint, DefaultHashMapTraits!(void*)).HashMap.opIndexAssign!uint.opIndexAssign' is not nothrow
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(208,9): Error: nothrow function 'vibe.internal.memory_legacy.DebugAllocator.realloc' may throw
dmd failed with exit code 1.

Does not occur with 2.074.

Kind regards
André

On Wednesday, 28 June 2017 at 08:37:40 UTC, Andre Pany wrote:
> On Tuesday, 27 June 2017 at 09:20:40 UTC, Sönke Ludwig wrote:
>> Am 22.06.2017 um 10:55 schrieb Sönke Ludwig:
>> There have been some minor fixes and vibe.d 0.8.0-rc.2 and vibe-core 1.0.0-rc.2 have been tagged. The final release is rescheduled for Monday, July the 3rd.
>

Still not able to use it for this [1] ...
Works fine in Vibe 0.7.31 with libevent ...

/Paolo

[1] https://github.com/rejectedsoftware/vibe.d/issues/1757

Building on DMD 2.075.0-b1, as well as https://github.com/rejectedsoftware/vibe.d/issues/1757 have been fixed and the third release candidate has been tagged. The new release date is Wednesday the 5th of July.

Are you planning/Did you consider to support wildcards in @path attribure when using registerWebInterface?

Am 01.07.2017 um 21:33 schrieb tetyys:
> Are you planning/Did you consider to support wildcards in @path attribure when using registerWebInterface?

@path takes a string that is passed as-is to URLRouter, so it supports the limited trailing wildcard ("/foo/*"), as well as the path segment placeholders ("/foo/:bar/"). Arbitrary wildcards are definitely a natural generalization and should also be implemented one day.

Only the implementation is a little bit complicated, because they need to be transformed into the same DFA representation that is used to match placeholders, including mixtures of the two and the appropriate fallbacks if there are multiple partial matches on the way to a full match.

So in the end, because I didn't have a need for this so far and because of the relatively high implementation cost, I don't currently have this on the radar.

On Thursday, 22 June 2017 at 20:59:51 UTC, Sönke Ludwig wrote:
> Am 22.06.2017 um 20:52 schrieb aberba:
>> [...]
>
> Agreed, there are several places in there that can be improved or made more consistent. The HTTP package (including WebSockets) is the next big part that is up for a complete redesign, also (finally) including HTTP/2 support. Since I'm really busy with another project I can't state a reliable schedule for this, but I'll try to start in the near future and will also to try to involve interested people in the design/development process as early as that makes sense.

I can help... How can I contribute?