I agree, that we don't need to print the 'd', but we probably also should accept (and ignore) it when parsing.
Wrt the list wrapper, I think that we've added that to the HTTP API to ensure that we get a valid instance of the data model. So this would be an artifact of the HTTP interface and not part of the result. And I think that we shouldn't simply ignore it on bulkload, as somebody might actually want to load lists (even though I don't know what to load them into right now ...). I think that the 2 options on this are a) add an option to the HTTP interface to not wrap the output sequence in a list and b) add an option to the bulkload to ignore an enclosing list. Right now I prefer b). Thoughts? Cheers, Till > On Aug 19, 2015, at 18:14, Ian Maxon <[email protected]> wrote: > > Interesting. I'm not sure I see the value in the suffix, as the default is > double. > > While we are at it in fixing this, we should remove the outer list wrapper > (or fix the ADM bulkload to accept that as input). Otherwise again, one > can't roundtrip. > > - Ian > >> On Wed, Aug 19, 2015 at 5:53 PM, Taewoo Kim <[email protected]> wrote: >> >> In adm.grammar file, DOUBLE_LITERAL doesn't have information about "d" >> suffix unlike the other numeric cases. This means that, for the real DOUBLE >> values, the output of ADM shouldn't have "d" in it? The ADoublePrinter >> class is printing "d" as suffix when it generates a double output: ps >> .print(ADoubleSerializerDeserializer.getDouble(b, s + 1) + "d"); Which way >> is the correct way? We need to remove "d" suffix? The adm.grammar file >> assumes so. >> >> >> INT_LITERAL = signOrNothing(), digitSequence() >> >> INT8_LITERAL = token(INT_LITERAL), string(i8) >> >> INT16_LITERAL = token(INT_LITERAL), string(i16) >> >> INT32_LITERAL = token(INT_LITERAL), string(i32) >> >> INT64_LITERAL = token(INT_LITERAL), string(i64) >> >> >> @EXPONENT = caseInsensitiveChar(e), signOrNothing(), >> digitSequence() >> >> >> DOUBLE_LITERAL = signOrNothing(), char(.), digitSequence() >> >> DOUBLE_LITERAL = signOrNothing(), digitSequence(), char(.), digitSequence() >> >> DOUBLE_LITERAL = signOrNothing(), digitSequence(), char(.), >> digitSequence(), token(@EXPONENT) >> >> DOUBLE_LITERAL = signOrNothing(), digitSequence(), token(@EXPONENT) >> >> >> FLOAT_LITERAL = token(DOUBLE_LITERAL), caseInsensitiveChar(f) >> >> >> >> Best, >> Taewoo >> >>> On Wed, Aug 19, 2015 at 3:15 PM, Mike Carey <[email protected]> wrote: >>> >>> We definitely need this to work. 😃 >>>> On Aug 19, 2015 9:36 AM, "Ian Maxon" <[email protected]> wrote: >>>> >>>> Yes I am just trying to bulk load from an ADM file that's the result of >>>> querying. It's annoying to have to mangle it with sed or similar, as >> its >>>> about 4GB. >>>> On Aug 19, 2015 2:41 AM, "Chris Hillery" <[email protected]> >> wrote: >>>> >>>>> I noticed that the output wasn't re-parseable as input last week when >>>>> coming up with the proposed JSON serialization. In particular, the >>>> numeric >>>>> suffixes like 0.0d, 15i8, 333333i32, and so on didn't parse as AQL >>>>> (although interestingly 32.5f does). I wasn't aware that it used to >>> work, >>>>> though. It's an odd disconnect between ADM and AQL, at the least. It >>>> sounds >>>>> like you're seeing the same issue when parsing as actual ADM? >>>>> >>>>> Ceej >>>>> aka Chris Hillery >>>>> >>>>>> On Wed, Aug 19, 2015 at 1:43 AM, Ian Maxon <[email protected]> wrote: >>>>>> >>>>>> Hi, >>>>>> Has ADM output from Asterix stopped being round-trippable? I'm >> trying >>>> to >>>>>> load a record I got from dumping from another instance, via the >> REST >>>> API, >>>>>> requesting 'application-x-adm' in the accept header. First I had to >>>>> remove >>>>>> the outer wrapper list that was added a while back, which I suppose >>>> isn't >>>>>> awful, but now it seems like I'm getting more subtle errors. For >>>> example, >>>>>> trying to load a record, and the parse fails once it sees a field >>> like >>>>> this >>>>>> in a record : >>>>>> >>>>>> { ... , "Rank": 0.0d, .... } >>>>>> >>>>>> With: >>>>>> >>>>>> Parse error at (1, 4421) expecting: <DOUBLE_CONS> <DATE_CONS> >>>>>> <DATETIME_CONS> <DURATION_CONS> <DAY_TIME_DURATION_CONS> >>>>>> [AdmLexerException] >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> - Ian >>
