Re: problem with edn

On 23/08/13 10:49, Jim wrote: I do regret not having checked whether Java serialization preserves the metadata or not .I plan to do it this afternoon. If it does ,I've got 2 perfectly working ways to achieve what I want, with no extra dependencies added... I finally got the chance to check w

Re: problem with edn

This brings an interesting twist... I am used to build polyglot solutions, our project has been a mix of Java, Ruby and Clojure for a year and a half and prior to that I would mix languages in a project on the fly. However I am not in a mood these days to sacrifice features available in Clojur

Re: problem with edn

Hi Kawas, well it is in a sense a client API as I've developed a mini-library for writing board-games and I am using it myself for my chess, checkers, tictactoe etc. The serialization bit is part of the library and not of the games themselves and that's why it should be uniform across games. I

Re: problem with edn

Hello Jim, As we know now, that you need data serialization to freeze your chess game and you're not writing any client API :) Have you consider libraries like : - Carbonite - Deep Freeze - Nippy

Re: problem with edn

You're right Meikel, I should have not used the term "hack". It is indeed just a solution to serialize data and meta data to edn. As long as you need it, and know how to read it back, I see no misuse. My point was rather on meta data that are not part of the solution domain. If I keep technical

Re: problem with edn

Hi Luc, Le jeudi 22 août 2013 21:19:00 UTC+2, Luc a écrit : > > > > Metadata is part of the Clojure environment and part of the value domain > it handles. > Why should it not be transmitted along with the value ? > If the receiver is not written in Clojure it may be questionable an > probably

Re: problem with edn

Hi, Am Donnerstag, 22. August 2013 17:46:42 UTC+2 schrieb kawas: > > This is indeed a hack and not a best practice > > I disagree. As long as you own the type (or write an application which is self-contained) you are free to define how it is printed. user=> (java.util.Date.) #inst "2013-08-23T07

Re: problem with edn

::meta would be better, to ensure against clashing with a key that a Foo might happen to use. On Thu, Aug 22, 2013 at 7:00 AM, Meikel Brandmeyer (kotarak) wrote: > Hi, > > Am Donnerstag, 22. August 2013 11:32:37 UTC+2 schrieb Jim foo.bar: > >> Oh wow! I shouldn't have turned my computer off ye

Re: problem with edn

I disagree... strongly. The value domain I am referring to is the one covered by your application, customized metadata is of little value elsewhere obviously. In typed languages the container defines a lot about what can be done with a value and what is forbidden. Nobody would try to rely on the

Re: problem with edn

On Aug 22, 2013 2:19 PM, "Softaddicts" wrote: > > > > > > Jim, > > > This is indeed a hack and not a best practice, maybe you're not using the > right tool for your problem... > > > - If you want to exchange data (think values), you should not be in need of > keeping types and meta data > > Metada

Re: problem with edn

> Jim, > > This is indeed a hack and not a best practice, maybe you're not using the > > > right tool for your problem... > > - If you want to exchange data (think values), you should not be in need of > > > keeping types and meta data Metadata is part of the Clojure environment and part of t

Re: problem with edn

all I'm trying to do is to provide a uniform mechanism to save/load game-states across my 2D board-games. Everything works just fine without that trick for most games but chess is peculiar (or my implementation is peculiar if you like) because in order to implement castling/enpassant moves with

Re: problem with edn

Jim, This is indeed a hack and not a best practice, maybe you're not using the right tool for your problem... - If you want to exchange data (think values), you should not be in need of keeping types and meta data when you exchange data in json, for example, you're not providing object class

Re: problem with edn

On Aug 22, 2013 6:25 AM, "Jim" wrote: > this is funny! I thought about this approach but I originally considered it to be a clever hack rather than the official way to do this... If you need some data persisted or sent over the wire, then it should probably be considered part of a value, and mayb

Re: problem with edn

Hi Meikel, this is funny! I thought about this approach but I originally considered it to be a clever hack rather than the official way to do this...Since I can't test it yet with my record , I hope you don't mind me asking another question... there is no need for print-dup bound to true he

Re: problem with edn

Hi, Am Donnerstag, 22. August 2013 11:32:37 UTC+2 schrieb Jim foo.bar: > > Oh wow! I shouldn't have turned my computer off yesterday evening!!! > there were many suggestions to try out... :) > > Ok let's see...I've got a record with meta-data let's call it FOO and its > instance MFOO: > > user=

Re: problem with edn

Oh wow! I shouldn't have turned my computer off yesterday evening!!! there were many suggestions to try out... :) Ok let's see...I've got a record with meta-data let's call it FOO and its instance MFOO: user=> (defrecord FOO [a b c]) user.FOO user=> (def MFOO (with-meta (FOO. 1 2 3) {:x fals

Re: problem with edn

In fact never user *print-dup* when using edn to read back data *print-dup* will output type and meta information that will not play well with edn user=> (binding [*print-dup* true] (pr-str (sorted-map :z 5 :a 1))) "#=(clojure.lang.PersistentTreeMap/create {:a 1, :z 5})" This "#=" with rais

Re: problem with edn

Never had time to play with edn and custom readers but they are funny :) Use *print-dup* if you need to... just know how to custom read it : user=> (edn/read-string {:readers {'user.Foo map->Foo}} "#user.Foo{:a 1 :b 2 :c 3}") #user.Foo{:a 1, :b 2, :c 3} user=> (edn/read-string {:readers {

Re: problem with edn

By the way *print-dup* is the problem, maybe you should not use it :) Spot the difference : user=> (binding [*print-dup* true] (prn (->Foo 1 2 3))) #user.Foo[1, 2, 3] user=> (binding [*print-dup* false] (prn (->Foo 1 2 3))) #user.Foo{:a 1, :b 2, :c 3} cheers Le mercredi 21 août 2013 19:

Re: problem with edn

Hi, Maybe you should provide a custom reader for your record. See answer on this question http://stackoverflow.com/questions/17991565/clojure-defrecord-serialization-classnotfoundexception regards, Le mercredi 21 août 2013 19:55:59 UTC+2, Jim foo.bar a écrit : > > Hi everyone, > > I am trying

problem with edn

Hi everyone, I am trying to serialise a record with edn. I think I am using all the good practices but I get a weird error...I am using these simple functions: (defn data->string "Writes the object b on a file f on disk as a string." [b f] (io! (with-open [w (clojure.java.io/writer f)] (bind