What's your favorite year end method?

[Donald Allen]

On Dec 17, 2007 4:20 PM, Josh Sled <jsled at asynchronous.org> wrote:
> Andrew Sackville-West <ajswest at mindspring.com> writes:
> > I don't want to speak for jsled, but he has talked a couple of times
> > about starting a next generation reporting system. He's even sketched
> > in some beginning design ideas (see -devel archives). The point is to
> > maintain the current reporting strucutre and keep it functioning while
> > a new structure gets put in place. This is no small task.
>
> Yup.
>
> > I don't think anyone is married to Scheme. jsled wants to move the
> > option generation back into C and then any swig-ified language can be
> > used to generate reports. If I remember correctly, you are parsing the
>
> To expand a bit more on this, the options are one place where we serialize
> data not as XML or text, but as scheme expressions.  As such, we strongly
> need a runtime dependency on guile to evaluate them, which makes it hard to
> drop scheme as a requirement down the road.
>
> Said another way: even if all the reports were re-written in something else
> tomorrow, we'd *still* need a scheme interpreter for the one-time task to
> evaluate the options at data-load time.
>
> My thought about the sequencing here is to – in the next release that would
> contain this code – get those serialized options and reports "converted" into
> a more generic data-only format, then we have the freedom to change the
> report implementation in any future release.
>
> (The other option is to just say "sorry, no historical saved- or open-reports
> are supported" in that hypothetical next version.   I've not ruled this out,
> but I don't think it'll be incrementally more work to actually be nice about
> it.)

But it sounds from what you are saying that "being nice" would require
an extra release cycle, and thus delay things a bit. I'm not taking a
position one way or another at this point, just trying to be sure I
understand what the tradeoffs are.

/Don


>
>
> As for the reports themselves, I don't think I want to leave it up to
> "any swig-ified language", so much as have the community pick a single
> preferred language, at least for the distributed set of reports.  The
> motivation against leaving it open-ended is distribution-packager/maintenance
> burden of depending now not on guile+slib, but on *all* of
> {perl,python,ruby,haskell,guile+slib,…} for the menagerie of reports that
> were contributed.
>
> --
> ...jsled
> http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>