I64 suffix is completely optional. The current INT64 printer does not print the "i64" suffix. However, the ADM grammar still support it. That is, if the ADM parser sees an INT or INT64 value, it interprets the value as INT64 value.
Best, Taewoo On Thu, Aug 20, 2015 at 12:44 AM, Mike Carey <[email protected]> wrote: > I was going to make the same comment about the i64 suffix. > > > On 8/19/15 6:14 PM, Ian Maxon 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 >>>>>>> >>>>>>> >
