443 tests in 35 groups
282 successes
161 failures
Cool. What’s your sense of what these data tell us about the state of
the processor?
I broke disambiguation and collapsing while implementing localized
dates and all the new name related stuff. But I started working on
those issues which are the main obstacles to the next release.
ps2: to run it with the darcs version, after installing citeproc-hs,
edit test/test_basic.hs to point to the test/machines/ subdirectory
and run:
runhaskell test/test_basic.hs
or
runhaskell test/test_basic.hs name nameattr nameorder
ps3: Bruce: installing hs-bibutils, the haskell bindings to bibutils,
should be now really easy (no need to install bibutils, patch it or
whatever). citeproc-hs comes with bibutils support by default now.
Awesome!
So this is only for the darcs version; right?
When are you planning to push out a new release?
the new and simplified hs-bibutils has been already released. I would
like to have the next CSL-1.0 (almost) compatible citeproc-hs out
before the 15th of June. That requires the new disambiguation and
collapsing code, the footnote related variables, and the new Pandoc
API to support local citation modifications (author-only, suppress
author and the rest). Not that much. Moreover tomorrow morning I’ll
deliver my last lecture for the present academic year…
Andrea
I think that separating the test-suite from citeproc-js and tagging it
together with the schema and the specification would be a step forward
(right know name ordering are different from CSL-1.0 specification,
for instance).
Andrea, everyone,
I’ve separated the non-standard and standard test fixtures in the test
suite, and moved the latter to a separate repository, here:
http://bitbucket.org/fbennett/citeproc-test
There are almost certainly still some citeproc-js-isms among the
tests. If folks call them to my attention as you come across them, I
can move them from the standard set to my local supplementary test
bundle. Apart from that small request, please treat this as a
community resource. The current location is just a holding zone; it
might make sense to move the canonical repository over to Bruce’s
account, so it can be housed together with the schema and docs.
Thanks Frank for your work. I’ll submit the new tests I’ll be writing,
or any correction I’ll think to propose, as patches to that
repository.
That would be great! I can’t tell you how glad I am that you’re
working with the suite. As the test repository is not yet formally
tied to the schema and specification, feel free to push in changes at
will. If any issues turn up for discussion, we can log them in the
bitbucket tracker.
About the citeproc-js-isms: actually I’m considering citeproc-js as
the reference implementation and I’m planning to expose an API which
should be modeled on citeproc-js’s API. In other words, citeproc-hs
could share with citeproc-js the input, citation-items and the
citations JSON data format (input and citation-items are already
supported).
Are you planning to support the dynamic plugin API as well (the format
used in CITATIONS blocks, as opposed to CITATION-ITEMS)? It might not
be suitable to your environment, if citeproc-hs will always be doing
batch processing of cites, but in citeproc-js it’s the only way I have
(I think) of tracking cite positions for back-references.
I wonder whether it could be useful to add a testsuite for covering
extensions that may be expected in a style processor. I would do my
best to support it.
Good idea. When the core tests have settled down, let’s do talk about
how to divide up the extra bits and pieces.
Andrea
ps: this is a run of the testsuite with my tree (should be the same
with the public repository).
443 tests in 35 groups
282 successes
161 failures
Great Jumping Jehosephat! I’ll have another go at installing haskell
sometime soon so I can watch the show.
The plan is to support the CITATIONS block as soon as possible. I
didn’t write the code yet just because translating the JSON
representation needs some manual intervention which is quite tedious
and time demanding. I’m actually using a similar way to represent
positions and so the job is not going to be difficult.
This could be another reason for standardizing the JSON datatypes used
in the tests.
Andrea
Sorry, my fault: “this could be another reason for” referred to my
plan to support CITATIONS: since both citeproc-js and citeproc-hs use
the same input data types we could have some way of collaboratively
extend it when needed - that could be the meaning of maintaining a
common specification.
But the way you understood it is indeed another (minor) issue. I
solved with some explicit casting, especially for bool values, by
processing the JSON data before reading it. This way I can easily
translate JSON into a Haskell type.
Andrea