Ignoring hxSerialize

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Ignoring hxSerialize

Simon Krajewski
  Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Thanks!
Simon

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Juraj Kirchheim
I supposethe  hxSerialize comes from the class, not from the object
itself, thus from its prototype.

See this for prototype based object orientation:
http://en.wikipedia.org/wiki/Prototype-based_programming
See neko builtins $objsetproto and $objgetproto for accessing an
object's prototype: http://nekovm.org/doc/view/builtins

When the actual object doesn't have the property, then the lookup is
performed on its prototype, which is why Reflect.hasField yields false
(because the object doesn't have this property), but a value will be
returned, because the prototype has it.

So no, there is no easy way to do this. However, I do not quite
understand, why you want to add the desired behaviour in a centralized
fashion. Whatever it is, you want to achieve, I believe it is easier
and cleaner to let the objects in question take care of this
theirselves by prodiving whatever behaviour you want in their
hxSerialze method.
Depending on what you're trying to do, you may be wanting to use the
default serialization. In that case you should subclass serializer and
add this method:

        public function serializeInstance(v) {
                #if flash9
                        serializeClassFields(v, Type.getClass(v));
                #else
                        serializeFields(v);
                #end
        }

And then your hxSerializes looks like

   function hxSerialize( s : CustomSerializer ) {
        if (conditionForCustom)
               customSerialization();
        else
               s.serializeInstance(this);
    }

greetz
back2dos

On Sat, Dec 11, 2010 at 11:02 PM, Simon Krajewski <[hidden email]> wrote:

>
>  Hi list,
>
> is there any convenient way of temporarily "ignoring" hxSerialize (neko specific if necessary) for a specific object? I tried using Reflect.deleteField, but even though Reflect.hasField returns false, the v.hxSerialize != null test done in haxe.Serializer still is true. Setting v.hxSerialize = null doesn't work because the field then gets serialized and the Unserializer is confused.
>
> Being able to do this would allow very easy reference marshalling, where objects only serialize their ID after an initial full transmission to a client
>
> Thanks!
> Simon
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Nicolas Cannasse
In reply to this post by Simon Krajewski
Le 11/12/2010 23:02, Simon Krajewski a écrit :

> Hi list,
>
> is there any convenient way of temporarily "ignoring" hxSerialize (neko
> specific if necessary) for a specific object? I tried using
> Reflect.deleteField, but even though Reflect.hasField returns false, the
> v.hxSerialize != null test done in haxe.Serializer still is true.
> Setting v.hxSerialize = null doesn't work because the field then gets
> serialized and the Unserializer is confused.
>
> Being able to do this would allow very easy reference marshalling, where
> objects only serialize their ID after an initial full transmission to a
> client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Simon Krajewski
In reply to this post by Juraj Kirchheim
  Hello Juraj,

thank you for your reply! Subclassing Serializer was my first idea too,
but I am using this for remoting and haxe.Serializer is hardcoded into
SocketProtocol. I thought modifying the std lib would be evil, so I was
looking for another way to do this. Also it's not completely the
standard serialization because "C" was already added to the buffer
instead of "c", which means I need a custom Unserializer too (which is
also hardcoded into SocketProtocol).

Overall, somehow temporarily removing the hxSerialize method seemed to
be the easiest solution, but I suppose I should look into extending
Serializer and Unserializer for something clean.

Thanks!
Simon

Am 14.12.2010 14:47, schrieb Juraj Kirchheim:

> I supposethe  hxSerialize comes from the class, not from the object
> itself, thus from its prototype.
>
> See this for prototype based object orientation:
> http://en.wikipedia.org/wiki/Prototype-based_programming
> See neko builtins $objsetproto and $objgetproto for accessing an
> object's prototype: http://nekovm.org/doc/view/builtins
>
> When the actual object doesn't have the property, then the lookup is
> performed on its prototype, which is why Reflect.hasField yields false
> (because the object doesn't have this property), but a value will be
> returned, because the prototype has it.
>
> So no, there is no easy way to do this. However, I do not quite
> understand, why you want to add the desired behaviour in a centralized
> fashion. Whatever it is, you want to achieve, I believe it is easier
> and cleaner to let the objects in question take care of this
> theirselves by prodiving whatever behaviour you want in their
> hxSerialze method.
> Depending on what you're trying to do, you may be wanting to use the
> default serialization. In that case you should subclass serializer and
> add this method:
>
> public function serializeInstance(v) {
> #if flash9
> serializeClassFields(v, Type.getClass(v));
> #else
> serializeFields(v);
> #end
> }
>
> And then your hxSerializes looks like
>
>     function hxSerialize( s : CustomSerializer ) {
>          if (conditionForCustom)
>                 customSerialization();
>          else
>                 s.serializeInstance(this);
>      }
>
> greetz
> back2dos
>
> On Sat, Dec 11, 2010 at 11:02 PM, Simon Krajewski<[hidden email]>  wrote:
>>   Hi list,
>>
>> is there any convenient way of temporarily "ignoring" hxSerialize (neko specific if necessary) for a specific object? I tried using Reflect.deleteField, but even though Reflect.hasField returns false, the v.hxSerialize != null test done in haxe.Serializer still is true. Setting v.hxSerialize = null doesn't work because the field then gets serialized and the Unserializer is confused.
>>
>> Being able to do this would allow very easy reference marshalling, where objects only serialize their ID after an initial full transmission to a client
>>
>> Thanks!
>> Simon
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Simon Krajewski
In reply to this post by Nicolas Cannasse
  Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but
haxe.SocketProtocol creates a new one for each send call. I wanted to
serialize as reference (class name + id) by default and only under a
certain condition (i.e. when the client requests it) transmit the full
object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:

> Le 11/12/2010 23:02, Simon Krajewski a écrit :
>> Hi list,
>>
>> is there any convenient way of temporarily "ignoring" hxSerialize (neko
>> specific if necessary) for a specific object? I tried using
>> Reflect.deleteField, but even though Reflect.hasField returns false, the
>> v.hxSerialize != null test done in haxe.Serializer still is true.
>> Setting v.hxSerialize = null doesn't work because the field then gets
>> serialized and the Unserializer is confused.
>>
>> Being able to do this would allow very easy reference marshalling, where
>> objects only serialize their ID after an initial full transmission to a
>> client
>
> Try using haxe.Serializer.USE_CACHE = true for that.
>
> Nicolas
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Simon Krajewski
  By the way: Wouldn't it make sense to have a Serializer and
Unserializer instance as member of SocketProtocol? Instead of creating
new ones for each send/request, the Unserializer gets its buffer set
when a new request comes in and the Serializer just flushes its buffer
when sending something. This way they maintain their cache throughout
the lifetime of a socket connection and quite possibly save a lot of
transmitted data.

It took me five minutes to try this and it seems to work perfectly, but
I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

>  Hi Nicolas,
>
> the cache works on a single instance of haxe.Serializer, but
> haxe.SocketProtocol creates a new one for each send call. I wanted to
> serialize as reference (class name + id) by default and only under a
> certain condition (i.e. when the client requests it) transmit the full
> object.
>
> Regards
> Simon
>
> Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
>> Le 11/12/2010 23:02, Simon Krajewski a écrit :
>>> Hi list,
>>>
>>> is there any convenient way of temporarily "ignoring" hxSerialize (neko
>>> specific if necessary) for a specific object? I tried using
>>> Reflect.deleteField, but even though Reflect.hasField returns false,
>>> the
>>> v.hxSerialize != null test done in haxe.Serializer still is true.
>>> Setting v.hxSerialize = null doesn't work because the field then gets
>>> serialized and the Unserializer is confused.
>>>
>>> Being able to do this would allow very easy reference marshalling,
>>> where
>>> objects only serialize their ID after an initial full transmission to a
>>> client
>>
>> Try using haxe.Serializer.USE_CACHE = true for that.
>>
>> Nicolas
>>
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Cauê W.
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Simon Krajewski
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Cauê W.
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Simon Krajewski
I had a look at your ObjectHash class and integrated a slight modification (allowing push/pop) into my hacked Serializer/Unserializer classes (though I couldn't subclass it properly on flash platform, there seem to be typing issues when subclassing TypedDictionary). Now the only remaining problem is your obj.___id___ stuff because the Serializer actually serializes it, causing the Unserializer to be confused and "unable to create property ___id___" on flash platform. For now I just made the Serializer ignore fields starting with ___.

Other than that it's just beautiful, each socket maintains its own instances of Serializer and Unserializer and everything gets sent by reference after an initial full transmission.

Thanks for this great class!
Simon

Am 15.12.2010 17:37, schrieb Cauê Waneck:
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Ignoring hxSerialize

Cauê W.
hmmm maybe I could try making the "propertyIsEnumerable" or something like that.. .I don't know if there is something like that for neko, though!

Anyway, I am very happy that it's working, Simon! : ) I've always wanted to do that with the Serializer

2010/12/15 Simon Krajewski <[hidden email]>
I had a look at your ObjectHash class and integrated a slight modification (allowing push/pop) into my hacked Serializer/Unserializer classes (though I couldn't subclass it properly on flash platform, there seem to be typing issues when subclassing TypedDictionary). Now the only remaining problem is your obj.___id___ stuff because the Serializer actually serializes it, causing the Unserializer to be confused and "unable to create property ___id___" on flash platform. For now I just made the Serializer ignore fields starting with ___.

Other than that it's just beautiful, each socket maintains its own instances of Serializer and Unserializer and everything gets sent by reference after an initial full transmission.

Thanks for this great class!
Simon

Am 15.12.2010 17:37, schrieb Cauê Waneck:
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: ObjectHash

Simon Krajewski
Late follow up with a problem I encountered:

        var hh = new haxe.ObjectHash<Dynamic, Int>();
        hh.set("Test", 1);
        trace(hh.exists("Test"));

This will return true on flash, but false on neko. I think the hash should check for value equality in case of String keys, not reference equality. For now I solved this by adding a Hash<Int> member that saves the oid of set String instances and is checked by the getObjectId() method.

Simon

Am 15.12.2010 21:11, schrieb Cauê Waneck:
hmmm maybe I could try making the "propertyIsEnumerable" or something like that.. .I don't know if there is something like that for neko, though!

Anyway, I am very happy that it's working, Simon! : ) I've always wanted to do that with the Serializer

2010/12/15 Simon Krajewski <[hidden email]>
I had a look at your ObjectHash class and integrated a slight modification (allowing push/pop) into my hacked Serializer/Unserializer classes (though I couldn't subclass it properly on flash platform, there seem to be typing issues when subclassing TypedDictionary). Now the only remaining problem is your obj.___id___ stuff because the Serializer actually serializes it, causing the Unserializer to be confused and "unable to create property ___id___" on flash platform. For now I just made the Serializer ignore fields starting with ___.

Other than that it's just beautiful, each socket maintains its own instances of Serializer and Unserializer and everything gets sent by reference after an initial full transmission.

Thanks for this great class!
Simon

Am 15.12.2010 17:37, schrieb Cauê Waneck:
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: ObjectHash

Pimm Hogeling
I would like to point out that if this test always returns false, I'd be fine with that, too. As long as we document this.

On 17 January 2011 11:45, Simon Krajewski <[hidden email]> wrote:
Late follow up with a problem I encountered:

        var hh = new haxe.ObjectHash<Dynamic, Int>();
        hh.set("Test", 1);
        trace(hh.exists("Test"));

This will return true on flash, but false on neko. I think the hash should check for value equality in case of String keys, not reference equality. For now I solved this by adding a Hash<Int> member that saves the oid of set String instances and is checked by the getObjectId() method.

Simon

Am 15.12.2010 21:11, schrieb Cauê Waneck:
hmmm maybe I could try making the "propertyIsEnumerable" or something like that.. .I don't know if there is something like that for neko, though!

Anyway, I am very happy that it's working, Simon! : ) I've always wanted to do that with the Serializer

2010/12/15 Simon Krajewski <[hidden email]>
I had a look at your ObjectHash class and integrated a slight modification (allowing push/pop) into my hacked Serializer/Unserializer classes (though I couldn't subclass it properly on flash platform, there seem to be typing issues when subclassing TypedDictionary). Now the only remaining problem is your obj.___id___ stuff because the Serializer actually serializes it, causing the Unserializer to be confused and "unable to create property ___id___" on flash platform. For now I just made the Serializer ignore fields starting with ___.

Other than that it's just beautiful, each socket maintains its own instances of Serializer and Unserializer and everything gets sent by reference after an initial full transmission.

Thanks for this great class!
Simon

Am 15.12.2010 17:37, schrieb Cauê Waneck:
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: ObjectHash

Simon Krajewski
It's a viable concept known from Java and such. The problem here is that different target platforms handle it in a different way. Also I think anything labeled "Hash" should compare key String values, not their references.

Having said that: How DO you actually compare string values when targetting neko?

Am 17.01.2011 13:59, schrieb Pimm Hogeling:
I would like to point out that if this test always returns false, I'd be fine with that, too. As long as we document this.

On 17 January 2011 11:45, Simon Krajewski <[hidden email]> wrote:
Late follow up with a problem I encountered:

        var hh = new haxe.ObjectHash<Dynamic, Int>();
        hh.set("Test", 1);
        trace(hh.exists("Test"));

This will return true on flash, but false on neko. I think the hash should check for value equality in case of String keys, not reference equality. For now I solved this by adding a Hash<Int> member that saves the oid of set String instances and is checked by the getObjectId() method.

Simon

Am 15.12.2010 21:11, schrieb Cauê Waneck:
hmmm maybe I could try making the "propertyIsEnumerable" or something like that.. .I don't know if there is something like that for neko, though!

Anyway, I am very happy that it's working, Simon! : ) I've always wanted to do that with the Serializer

2010/12/15 Simon Krajewski <[hidden email]>
I had a look at your ObjectHash class and integrated a slight modification (allowing push/pop) into my hacked Serializer/Unserializer classes (though I couldn't subclass it properly on flash platform, there seem to be typing issues when subclassing TypedDictionary). Now the only remaining problem is your obj.___id___ stuff because the Serializer actually serializes it, causing the Unserializer to be confused and "unable to create property ___id___" on flash platform. For now I just made the Serializer ignore fields starting with ___.

Other than that it's just beautiful, each socket maintains its own instances of Serializer and Unserializer and everything gets sent by reference after an initial full transmission.

Thanks for this great class!
Simon

Am 15.12.2010 17:37, schrieb Cauê Waneck:
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: ObjectHash

John A. De Goes
In reply to this post by Simon Krajewski

Stax has a Map<K, V> class which works with any key and value types. It also provides many advanced functions not found in simple hash data structures.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 3:45 AM, Simon Krajewski wrote:

Late follow up with a problem I encountered:

        var hh = new haxe.ObjectHash<Dynamic, Int>();
        hh.set("Test", 1);
        trace(hh.exists("Test"));

This will return true on flash, but false on neko. I think the hash should check for value equality in case of String keys, not reference equality. For now I solved this by adding a Hash<Int> member that saves the oid of set String instances and is checked by the getObjectId() method.

Simon

Am 15.12.2010 21:11, schrieb Cauê Waneck:
hmmm maybe I could try making the "propertyIsEnumerable" or something like that.. .I don't know if there is something like that for neko, though!

Anyway, I am very happy that it's working, Simon! : ) I've always wanted to do that with the Serializer

2010/12/15 Simon Krajewski <[hidden email]>
I had a look at your ObjectHash class and integrated a slight modification (allowing push/pop) into my hacked Serializer/Unserializer classes (though I couldn't subclass it properly on flash platform, there seem to be typing issues when subclassing TypedDictionary). Now the only remaining problem is your obj.___id___ stuff because the Serializer actually serializes it, causing the Unserializer to be confused and "unable to create property ___id___" on flash platform. For now I just made the Serializer ignore fields starting with ___.

Other than that it's just beautiful, each socket maintains its own instances of Serializer and Unserializer and everything gets sent by reference after an initial full transmission.

Thanks for this great class!
Simon

Am 15.12.2010 17:37, schrieb Cauê Waneck:
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Stax

Simon Krajewski
It's rather embarassing to ask this, but what am I supposed to do with the files downloaded from github? I take it Stax is an alternative to haxe/std, so by adding it to the -cp I obviously still get code completion of haxe/std stuff in FlashDevelop. Actually replacing haxe/std yields a "Standard library not found" error.

Trying to compile stax.hxproj with haxe r3611 dies with
src/test/haxe/PreludeTest.hx:452: characters 20-41 : Metadata should be constant

Commenting that out and running the test gives
testReflectiveOrderForDynamicComparableDescendingClass: 3 tests, 1 pass, 2 failures
line 144: expected true
line 145: expected true

So yeah, your release should really have some WhatToDoWithThis.txt for people like me!

Simon

Am 17.01.2011 17:25, schrieb John A. De Goes:

Stax has a Map<K, V> class which works with any key and value types. It also provides many advanced functions not found in simple hash data structures.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: ObjectHash

Simon Krajewski
In reply to this post by John A. De Goes
It's rather embarassing to ask this, but what am I supposed to do with the files downloaded from github? I take it Stax is an alternative to haxe/std, so by adding it to the -cp I obviously still get code completion of haxe/std stuff in FlashDevelop. Actually replacing haxe/std yields a "Standard library not found" error.

Trying to compile stax.hxproj with haxe r3611 dies with
src/test/haxe/PreludeTest.hx:452: characters 20-41 : Metadata should be constant

Commenting that out and running the test gives
testReflectiveOrderForDynamicComparableDescendingClass: 3 tests, 1 pass, 2 failures
line 144: expected true
line 145: expected true

So yeah, your release should really have some WhatToDoWithThis.txt for people like me!

Simon

Am 17.01.2011 17:25, schrieb John A. De Goes:

Stax has a Map<K, V> class which works with any key and value types. It also provides many advanced functions not found in simple hash data structures.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 3:45 AM, Simon Krajewski wrote:

Late follow up with a problem I encountered:

        var hh = new haxe.ObjectHash<Dynamic, Int>();
        hh.set("Test", 1);
        trace(hh.exists("Test"));

This will return true on flash, but false on neko. I think the hash should check for value equality in case of String keys, not reference equality. For now I solved this by adding a Hash<Int> member that saves the oid of set String instances and is checked by the getObjectId() method.

Simon

Am 15.12.2010 21:11, schrieb Cauê Waneck:
hmmm maybe I could try making the "propertyIsEnumerable" or something like that.. .I don't know if there is something like that for neko, though!

Anyway, I am very happy that it's working, Simon! : ) I've always wanted to do that with the Serializer

2010/12/15 Simon Krajewski <[hidden email]>
I had a look at your ObjectHash class and integrated a slight modification (allowing push/pop) into my hacked Serializer/Unserializer classes (though I couldn't subclass it properly on flash platform, there seem to be typing issues when subclassing TypedDictionary). Now the only remaining problem is your obj.___id___ stuff because the Serializer actually serializes it, causing the Unserializer to be confused and "unable to create property ___id___" on flash platform. For now I just made the Serializer ignore fields starting with ___.

Other than that it's just beautiful, each socket maintains its own instances of Serializer and Unserializer and everything gets sent by reference after an initial full transmission.

Thanks for this great class!
Simon

Am 15.12.2010 17:37, schrieb Cauê Waneck:
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: ObjectHash

John A. De Goes

You should not replace the standard library. Just add the "/src/main/haxe" to the classpath. Then you can import whatever files you want to use (surely Prelude and PreludeExtensions).

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 10:26 AM, Simon Krajewski wrote:

It's rather embarassing to ask this, but what am I supposed to do with the files downloaded from github? I take it Stax is an alternative to haxe/std, so by adding it to the -cp I obviously still get code completion of haxe/std stuff in FlashDevelop. Actually replacing haxe/std yields a "Standard library not found" error.

Trying to compile stax.hxproj with haxe r3611 dies with
src/test/haxe/PreludeTest.hx:452: characters 20-41 : Metadata should be constant

Commenting that out and running the test gives
testReflectiveOrderForDynamicComparableDescendingClass: 3 tests, 1 pass, 2 failures
line 144: expected true
line 145: expected true

So yeah, your release should really have some WhatToDoWithThis.txt for people like me!

Simon

Am 17.01.2011 17:25, schrieb John A. De Goes:

Stax has a Map<K, V> class which works with any key and value types. It also provides many advanced functions not found in simple hash data structures.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Jan 17, 2011, at 3:45 AM, Simon Krajewski wrote:

Late follow up with a problem I encountered:

        var hh = new haxe.ObjectHash<Dynamic, Int>();
        hh.set("Test", 1);
        trace(hh.exists("Test"));

This will return true on flash, but false on neko. I think the hash should check for value equality in case of String keys, not reference equality. For now I solved this by adding a Hash<Int> member that saves the oid of set String instances and is checked by the getObjectId() method.

Simon

Am 15.12.2010 21:11, schrieb Cauê Waneck:
hmmm maybe I could try making the "propertyIsEnumerable" or something like that.. .I don't know if there is something like that for neko, though!

Anyway, I am very happy that it's working, Simon! : ) I've always wanted to do that with the Serializer

2010/12/15 Simon Krajewski <[hidden email]>
I had a look at your ObjectHash class and integrated a slight modification (allowing push/pop) into my hacked Serializer/Unserializer classes (though I couldn't subclass it properly on flash platform, there seem to be typing issues when subclassing TypedDictionary). Now the only remaining problem is your obj.___id___ stuff because the Serializer actually serializes it, causing the Unserializer to be confused and "unable to create property ___id___" on flash platform. For now I just made the Serializer ignore fields starting with ___.

Other than that it's just beautiful, each socket maintains its own instances of Serializer and Unserializer and everything gets sent by reference after an initial full transmission.

Thanks for this great class!
Simon

Am 15.12.2010 17:37, schrieb Cauê Waneck:
I wouldn't depend so much on this though.... You don't know at which point one platform thinks the connection is lost, etc... I don't know, I wouldn't rely 100% on that...

2010/12/15 Simon Krajewski <[hidden email]>
I agree about the cache implementation, that Array surely isn't designed to grow huge. I don't understand the connection loss issue though. If I reconnect, I get a new Socket -> new SocketProtocol -> new Serializer/Unserializer instances -> new caches, so everything should just be sent normally again.

Regards
Simon

Am 15.12.2010 16:22, schrieb Cauê Waneck:
the possible side effects might be if the connection is lost or something, the caches might not match completely. Maybe by creating a unique " session "  id that you send between the two.

Also the caches MUST be reimplemented using an object hash, like the one I posted on the list some time ago. An object hash works across all platforms, and it goes from O(n) to O(1) the complexity of looking for cache hits : )

2010/12/15 Simon Krajewski <[hidden email]>
 By the way: Wouldn't it make sense to have a Serializer and Unserializer instance as member of SocketProtocol? Instead of creating new ones for each send/request, the Unserializer gets its buffer set when a new request comes in and the Serializer just flushes its buffer when sending something. This way they maintain their cache throughout the lifetime of a socket connection and quite possibly save a lot of transmitted data.

It took me five minutes to try this and it seems to work perfectly, but I'm not sure about possible side effects.

Regards
Simon

Am 14.12.2010 15:33, schrieb Simon Krajewski:

 Hi Nicolas,

the cache works on a single instance of haxe.Serializer, but haxe.SocketProtocol creates a new one for each send call. I wanted to serialize as reference (class name + id) by default and only under a certain condition (i.e. when the client requests it) transmit the full object.

Regards
Simon

Am 14.12.2010 15:11, schrieb Nicolas Cannasse:
Le 11/12/2010 23:02, Simon Krajewski a écrit :
Hi list,

is there any convenient way of temporarily "ignoring" hxSerialize (neko
specific if necessary) for a specific object? I tried using
Reflect.deleteField, but even though Reflect.hasField returns false, the
v.hxSerialize != null test done in haxe.Serializer still is true.
Setting v.hxSerialize = null doesn't work because the field then gets
serialized and the Unserializer is confused.

Being able to do this would allow very easy reference marshalling, where
objects only serialize their ID after an initial full transmission to a
client

Try using haxe.Serializer.USE_CACHE = true for that.

Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org