Hi Brian -
We have support for that kind of JSON thing using writef.
writef("%ht\n", myrecord);
would print it out in a way you could paste into Chapel code
and
writef("%jt\n", myrecord);
will print it out in JSON format.
Note that both of these features don't work right in all cases yet
(tuples, arrays, ...).
I'd also like to create a serialization format that allows cycles,
but JSON doesn't do that even...
Another issue (right now) is that while you can supply your own
readThis/writeThis/readWriteThis method for a custom record, you
can't use readf/writef within it.
Cheers,
-michael
On 5/27/15, 10:04 AM, "Brian Guarraci" <[email protected]> wrote:
>Hi Michael,
>
>
>This strategy seems to imply an implicit serialization schema. It may be
>interesting to allow for a default schema as you suggest but also to
>provide another way to specify the serialization / deserialization
>methods? When I look at your example, my
> mind translates it to JSON as:
>
>
>{
> a: "hello world",
> b: "second string"
>}
>
>
>so I wonder if it makes sense to generalize the approach.
>
>On Wed, May 27, 2015 at 6:54 AM, Michael Ferguson
><[email protected]> wrote:
>
>Hi Chapel Developers -
>
>I'd like to be able to write and then read an array/record/whatever and
>expect it to work, but there are problems if the object contains strings.
>I'm proposing a change to the I/O behavior to fix this problem.
>
>How did we get here? If you do:
>
> writeln("hello world\n");
>
>you (naturally?) expect "hello world" to print without quotes:
>
> hello world
>
>but then if you were reading that input and you did this:
>
> var s: string;
> readln(s);
>
>s would contain only "hello", because the default string reading rule
>is to read one word only. Even if that were not the case, we wouldn't
>know when we reached the end of the string since it is not delimited
>in any way. (and making writeln print the quotes by default interferes
>with things like writeln("a = ", a) ).
>
>When we get to a record, these choices are no longer reasonable.
>
>For example, if I have
>
> record R { a: string, b: string }
> writeln(new R("hello world", "second string"));
>
>it will output
>
> (a = hello world, b = second string)
>
>and there's pretty much no way that the corresponding readln would work
>(what if the string contains commas or parenthesis?). I believe that
>the current code will only be able to read 1-word strings in records...
>
>So, I'd like to propose the following change in I/O behavior:
>
> - writeln(string) and readln(string) continue to work the way they do
> - write/writeln/read/readln of any aggregate
>(record/class/array/tuple/etc)
> will switch the string formatting to double-quoted strings that would
> work in Chapel source code, so the second record example above would
> now output
>
> (a = "hello world", b = "second string")
>
>
>Any objections?
>
>-michael
>
>
>--------------------------------------------------------------------------
>----
>_______________________________________________
>Chapel-developers mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
>
>
>
>
>
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
