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
