That was the code path I was looking for in my previous reply. And indeed
while copying a transaction goes through scheme code it's not the engine
itself requiring it. So something to clean up eventually, but probably not
blocking for a companion app.
Geert
Op zaterdag 27 april 2019 18:24:00 CEST schreef John Ralls:
> Right, engine-interface.scm is one of several files of helper code to make
> it easier or more idiomatic to write scheme code using the engine. They're
> not in the path if one uses the engine API from Scheme. Contrast that with
> using an options dialog from C: That goes through the Scheme options code
> in app-utils to be written to the book's slots via kvp-scm.cpp.
>
> Regards,
> John Ralls
>
> > On Apr 27, 2019, at 7:53 AM, Christopher Lam
> > wrote:
> >
> > I've managed to enter some guile code from the register: "Transaction >
> > Copy Transaction" will copy the current transaction into an scm object via
> > functions in engine-interface.scm, called from split-register.c, and I
> > presume this scm object is read back to paste later on. Ditto Transaction
> > >
> > Duplicate Transaction.
> >
> >
> > On Sat, 27 Apr 2019 at 14:29, Geert Janssens
> >
> > wrote:
> >> Op zaterdag 27 april 2019 16:05:42 CEST schreef John Ralls:
> On Apr 26, 2019, at 10:55 PM, Geert Janssens <
> >>
> >> geert.gnuc...@kobaltwit.be>
> >>
> wrote:>
>
> Op zaterdag 27 april 2019 01:01:38 CEST schreef John Ralls:
> > What Geert meant is that our current engine code *isn't* particularly
> > portable, though I think that since it compiles OK on MacOS it
> >>
> >> shouldn't
> >>
> > have too much trouble with iOS either. It's a mix of C and C++ and the
> > main
> > dependencies are Boost and Gnome Glib; the XML file backend also
> >>
> >> depends
> >>
> > on
> > libxml2 and the SQL backend depends on libdbi.
> >
> > The public mirror for our git repository is at
> > https://github.com/gnucash/gnucash. Note that the stable branch is
> > "maint".
> > Doxygen API docs are at https://code.gnucash.org/docs/MAINT.
> >
> > Regards,
> > John Ralls
>
> The devil is in the details... The engine code currently still depends
> >>
> >> on
> >>
> guile as well, which is a scripting language. Doesn't Apple impose
> restrictions on that ?
> I currently don't have a full overview of where guile is used in the
> engine
> code. I know the option system is heavily dependent on it, but that's
> primarily used by the report system.
> >>>
> >>> There's no guile in the backends, and only a little in engine, core
> >>
> >> utils,
> >>
> >>> and gnc-module for facilitating the wrappers. App-utils is heavy with
> >>> scheme but that's to support application features like options and the
> >>> financial functions for scheduled transactions, and price-quote is
> >>
> >> scheme.
> >>
> >>> I think John's team can set up a build of just engine and the backends
> >>
> >> they
> >>
> >>> want to support without swigging and so without guile. That should be
> >>> enough for a companion project similar to GfA.
> >>>
> >>> Regards,
> >>> John Ralls
> >>
> >> I'm glad to hear that. I have a vague recollection of tracing some
> >> transaction
> >> code in the past and ending up in guile. That may have been cleaned up by
> >> now.
> >>
> >> Regards,
> >>
> >> Geert
> >>
> >>
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
