Hello again. I updated vibe.d at new version. I get this HTTP error 500
(my app doesn't crash):
Error description: std.variant.VariantException@std/variant.d(1237):
Variant: attempting to use incompatible types object.TypeInfo and
immutable(char)[] ---------------- .
I think that has something to do with the session storage i get the
error when a session starts.
Do i miss something that i had to change/update for the new version?
Thank you for any advice.
Am 10.01.2014 13:59, schrieb YiannisOSC:
Hello again. I updated vibe.d at new version. I get this HTTP error 500
(my app doesn't crash):Error description: std.variant.VariantException@std/variant.d(1237):
Variant: attempting to use incompatible types object.TypeInfo and
immutable(char)[] ---------------- .I think that has something to do with the session storage i get the
error when a session starts.Do i miss something that i had to change/update for the new version?
Thank you for any advice.
Can you try to get a stack trace for that error? My own projects seem to
work fine so far, so I can't really investigate it closer. But I've just
committed a small change that might fix this, although the error
message doesn't fit 100%. It fixes a possible error when a non-existing
key in a session is requested.
But the changes in Session for arbitrary types were generally supposed
to be fully backwards compatible, so this is a bug no matter what.
On 10/01/14 14:48 , Sönke Ludwig wrote:
Am 10.01.2014 13:59, schrieb YiannisOSC:
Hello again. I updated vibe.d at new version. I get this HTTP error 500
(my app doesn't crash):Error description: std.variant.VariantException@std/variant.d(1237):
Variant: attempting to use incompatible types object.TypeInfo and
immutable(char)[] ---------------- .I think that has something to do with the session storage i get the
error when a session starts.Do i miss something that i had to change/update for the new version?
Thank you for any advice.
Can you try to get a stack trace for that error? My own projects seem to
work fine so far, so I can't really investigate it closer. But I've just
committed a small change that might fix this, although the error
message doesn't fit 100%. It fixes a possible error when a non-existing
key in a session is requested.But the changes in
Sessionfor arbitrary types were generally supposed
to be fully backwards compatible, so this is a bug no matter what.
yes it works now! it was exactly this i was checking if a session key
was there so to proceed with log in.
Thank you!
