www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - vibe.d 0.7.24 released

reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
A new vibe.d release is out. Apart from support for the 2.068 D 
frontend, some of the major changes are:

  - The vibe.web.web module adds support for convenient WebSocket routes
  - Renamed "SSL" to "TLS" (with compatibility aliases, of course)
  - Json.opDispatch and Bson.opDispatch are scheduled for deprecation

There are a lots of additional changes and bug fixes listed in the 
change log:
http://vibed.org/blog/posts/vibe-release-0.7.24

Homepage: http://vibed.org/
DUB package: http://code.dlang.org/packages/vibe-d
GitHub: https://github.com/rejectedsoftware/vibe.d
Aug 10 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 10 August 2015 at 17:27:56 UTC, Sönke Ludwig wrote:

  - Json.opDispatch and Bson.opDispatch are scheduled for 
 deprecation


What was your reason for doing that? I find they are kinda 
convenient but also have a way of messing with compile time duck 
typing so I restrict it.... but overall, I still think they're 
kinda cool.
Aug 10 2015
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 10.08.2015 um 19:32 schrieb Adam D. Ruppe:

 On Monday, 10 August 2015 at 17:27:56 UTC, Sönke Ludwig wrote:

  - Json.opDispatch and Bson.opDispatch are scheduled for deprecation


 What was your reason for doing that? I find they are kinda convenient
 but also have a way of messing with compile time duck typing so I
 restrict it.... but overall, I still think they're kinda cool.


The main technical reason was CT reflections issues (the particular case 
was that they had always been erroneously recognized as input ranges) 
and the fact that any API change involving the Json struct would 
potentially be a silently breaking change. Another thing that I 
personally always felt was that the syntax had the effect of 
unconsciously hiding bugs, because it *looks* like static field access, 
so your brain thinks that the compiler checks for things like spelling 
mistakes.

My idea for solving this was to provide the basic Json type as pure 
abstraction for the data format, with standard D semantics (opIndex 
field access), while providing a separate type that transparently 
converts to/from the Json type and has all of the dynamic typing 
goodness (i.e. jsvar). So the difference would just be that it's an 
explicit request by the developer (that even saves on keystrokes if the 
type is just called "var") to enter the dynamic world and things get a 
little more obvious to the reader/reviewer.
Aug 10 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 10 August 2015 at 18:23:25 UTC, Sönke Ludwig wrote:

 The main technical reason was CT reflections issues (the 
 particular case was that they had always been erroneously 
 recognized as input ranges) and the fact that any API change 
 involving the Json struct would potentially be a silently 
 breaking change. Another thing that I personally always felt 
 was that the syntax had the effect of unconsciously hiding 
 bugs, because it *looks* like static field access, so your 
 brain thinks that the compiler checks for things like spelling 
 mistakes.


Aye, good points.


Ideally, I'd love to see statically defined structs for 
everything with easy to/from serialization. The serialization 
part is easy - the trickier part is getting the right struct 
definition.

I started working on an analyzer thing that takes a real world 
data sample and creates a struct from it. Actually, my main 
reason for doing that was reverse engineering a third party API - 
reading a struct definition is easier than reading json IMO - but 
it'd have nice benefits for these too.

Most "dynamic" types really are static, you just don't always 
know the layout at compile time. But with a bit of ahead-of-time 
analyzers of the data, we can basically bridge that without 
needing a whole lot of extra work.
Aug 11 2015
parent Rory McGuire via Digitalmars-d-announce writes:
On Tue, Aug 11, 2015 at 3:48 PM, Adam D. Ruppe via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 ...
 Most "dynamic" types really are static, you just don't always know the
 layout at compile time. But with a bit of ahead-of-time analyzers of the
 data, we can basically bridge that without needing a whole lot of extra
 work.

 I had made an object similar to your jsvar, now I just use your  jsvar for


all my REST api needs because it works basically like javascript which is
great for consuming the data from the apis I use. You could use it to do
the basic discovery and then generate a vibe/std json struct from there.

Its great to have the more rigid JSON features in vibe.d too, they each
have their place.
Aug 12 2015
prev sibling parent reply "Misu" <misugi-pwnu live.fr> writes:
On Monday, 10 August 2015 at 17:27:56 UTC, Sönke Ludwig wrote:

 A new vibe.d release is out. Apart from support for the 2.068 D 
 frontend, some of the major changes are:

  - The vibe.web.web module adds support for convenient 
 WebSocket routes
  - Renamed "SSL" to "TLS" (with compatibility aliases, of 
 course)
  - Json.opDispatch and Bson.opDispatch are scheduled for 
 deprecation

 There are a lots of additional changes and bug fixes listed in 
 the change log:
 http://vibed.org/blog/posts/vibe-release-0.7.24

 Homepage: http://vibed.org/
 DUB package: http://code.dlang.org/packages/vibe-d
 GitHub: https://github.com/rejectedsoftware/vibe.d


Thanks for the work. vibe.d is awesome
Aug 11 2015
parent reply "Suliman" <evermind live.ru> writes:
I can't understand why I can't build vibed with 2.068

C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core\drive
s\libevent2.d(631): Error: '_d_monitorenter' is not nothrow
C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core\drive
s\libevent2.d(631): Error: '_d_monitorexit' is not nothrow
C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core\drive
s\libevent2.d(622): Error: function 'vibe.core.drivers.libevent2.Libevent
2ManualEvent.emit' is nothrow yet may throw


I wrote in dub.json:

"vibe-d": "0.7.24"

but it's downloading "0.7.23" version.

After command dub upgrade I am getting:

D:\code\httpApp>dub upgrade
Upgrading project in D:\code\httpApp
Error executing command upgrade:
Root package httpapp contains reference to invalid package vibe-d
Aug 11 2015
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 11.08.2015 um 15:28 schrieb Suliman:

 I can't understand why I can't build vibed with 2.068

 C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core\drivers\libevent2.d(631):
 Error: '_d_monitorenter' is not nothrow
 C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core\drivers\libevent2.d(631):
 Error: '_d_monitorexit' is not nothrow
 C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core\drivers\libevent2.d(622):
 Error: function 'vibe.core.drivers.libevent2.Libevent 2ManualEvent.emit'
 is nothrow yet may throw


 I wrote in dub.json:

 "vibe-d": "0.7.24"

 but it's downloading "0.7.23" version.

 After command dub upgrade I am getting:

 D:\code\httpApp>dub upgrade
 Upgrading project in D:\code\httpApp
 Error executing command upgrade:
 Root package httpapp contains reference to invalid package vibe-d


That's probably due to an annoying side effect of the metadata cache. 
Try to rerun after doing "dub clean-caches".
Aug 11 2015
parent reply "Suliman" <evermind live.ru> writes:
I still can't get 0.7.24. My config is:

"dependencies": {
"vibe-d": "0.7.24"
},

D:\code\httpApp>dub clean-caches

D:\code\httpApp>dub build
Fetching vibe-d 0.7.23 (getting selected version)...
Placing vibe-d 0.7.23 to 
C:\Users\bubenkov_di\AppData\Roaming\dub\packages\...
Selected package vibe-d 0.7.23 does not match the dependency 
specification 0.7.2
4 in package httpapp. Need to "dub upgrade"?
Selected package libasync 0.7.5 does not match the dependency 
specification 0.7.
1 in package vibe-d. Need to "dub upgrade"?
Building vibe-d 0.7.23 configuration "libevent", build type debug.
Running dmd...
C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core
\drivers\libevent2.d(631): Error: '_d_monitorenter' is not nothrow
C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core
\drivers\libevent2.d(631): Error: '_d_monitorexit' is not nothrow
C:\Users\bubenkov_di\AppData\Roaming\dub\packages\vibe-d-0.7.23\source\vibe\core
\drivers\libevent2.d(622): Error: function 
'vibe.core.drivers.libevent2.Libevent
2ManualEvent.emit' is nothrow yet may throw
Aug 11 2015
next sibling parent "wobbles" <grogan.colin gmail.com> writes:
On Tuesday, 11 August 2015 at 14:14:10 UTC, Suliman wrote:

 I still can't get 0.7.24. My config is:

 "dependencies": {
 "vibe-d": "0.7.24"
 },

 [...]


Try going to your packages directory and actually deleting the 
0.7.23 folder?
(Remember, backup!)
Aug 11 2015
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 11.08.2015 um 16:14 schrieb Suliman:

 I still can't get 0.7.24. My config is:

 "dependencies": {
 "vibe-d": "0.7.24"
 },

 D:\code\httpApp>dub clean-caches

 D:\code\httpApp>dub build
 (...)
 C:\Users\bubenkov_di\AppData\Roaming\dub\packages\...
 Selected package vibe-d 0.7.23 does not match the dependency
 specification 0.7.24 in package httpapp. Need to "dub upgrade"?


Did you try to run "dub upgrade" again after the clean-caches? This is 
necessary, because dub.selections.json is supposed to be able to 
manually override dependency specifications in dub.json.
Aug 11 2015
next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Tuesday, 11 August 2015 at 16:11:29 UTC, Sönke Ludwig wrote:

 Did you try to run "dub upgrade" again after the clean-caches? 
 This is necessary, because dub.selections.json is supposed to 
 be able to manually override dependency specifications in 
 dub.json.


I have a script called dubrenew.sh

----------8<-------------


rm dub.selections.json
dub clean-caches

----------8<-------------

Works every time (dub upgrade can be used alternatively to 
deleting dub.selections.json)
Aug 12 2015
parent "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 12 August 2015 at 09:42:20 UTC, ponce wrote:

 I have a script called dubrenew.sh

 ----------8<-------------


 rm dub.selections.json
 dub clean-caches

 ----------8<-------------

 Works every time (dub upgrade can be used alternatively to 
 deleting dub.selections.json)


Maybe dub upgrade should call dub clean-caches.
Aug 12 2015
prev sibling parent "Suliman" <evermind live.ru> writes:
Did you try to run "dub upgrade"


Thanks! It's work!
Aug 12 2015