Re: [GNC-dev] Import roadmap

[Brian Rater]

It needed more thought and experiment, but isolating data structures to the
individual classes would still be the best way to go if they can be
provided with a simple interface to read and write basic data types to/from
whatever our backend structure(s) would be while hiding those details.
Whether or not a simple interface could be created to allow classes to
read/write to a backend with a hidden structure was what I still needed to
look into,  but ran out of time.  There are undoubtedly going to be many
design questions like this moving forward.


On Sun, Feb 4, 2024, 11:37 PM john  wrote:

> Those XML changes sound like the wrong direction. XML code needs to stay
> in libgnucash/backend, not get mixed in with engine/QOF, especially since
> the long-range plan is to turn XML into a backup format with SQL being the
> primary storage and data access mechanism.
>
> I understand the reluctance to cause a regression, but no matter how you
> go about it you're going to be writing new code. Unlike a C -> C++
> conversion you can't do a function at a time with Scheme -> C++, nor can
> you use the same tests for both the old and new code. If you wire into the
> existing C import code you'll at least avoid creating bugs in those parts
> of the process.
>
> Regards,
> John Ralls
>
>
>
>
> On Feb 4, 2024, at 16:50, Brian Rater  wrote:
>
> Great.  Thank you for the insights.  Before I got overwhelmed with work
> and other commitments last year, I was experimenting with a set of base
> classes that would replace the lower level qof infrastructure.  As part of
> that, I was also looking at an alternative xml concept where xml provided
> some fundamental utilities, but each class such as book and transaction
> would use those to read and write themselves.  This keeps the data
> structures contained in the class itself rather than xml w needing to know
> about engine class data structures.  That effort did not progress far
> enough to bring up for discussion here or do a development branch pr,
> however.
>
> I’m comfortable with redesigning and rearchitecting, but I am planning to
> go cautiously with import/QIF as it sounds like a lot people use that and
> the format is not well defined.  I don’t want to introduce new bugs.
>
> On Sun, Feb 4, 2024 at 6:50 PM John Ralls  wrote:
>
>>
>>
>> > On Feb 4, 2024, at 12:11 PM, Brian Rater  wrote:
>> >
>> > I've been looking at the import code and documentation and I'm wondering
>> > what the overall plan and path is.  It looks like there is a "generic"
>> > implementation in the top level directory which has utilities that are
>> > being converted to C++.  I can see the importers making some calls into
>> > this.  What is the plan and where are we at?
>> >
>> > In particular, what needs to happen with QIF, which is still written in
>> > guile?
>> >
>> > I'm asking because I'm looking for a task to work on.  My particular
>> > passion is writing C++ classes to replace legacy code along with adding
>> > tests and documentation.  I've been reading over the source code and
>> > following the development list for several months, but I've had limited
>> > bandwidth until recently to make contributions.
>> >
>> > I've been looking at converting Import/QIF to C++ because it is written
>> in
>> > guile (higher priority than converting the C code in my opinion), is
>> fairly
>> > self contained, and the only alternative guile conversion code is
>> reports,
>> > which is way too large in scope for where I am.  Converting QIF has
>> > drawbacks such as needing extensive testing, and having limited existing
>> > tests for regression testing, however.
>> >
>> > My current thought is to directly translate the existing algorithms and
>> not
>> > use the generic import to minimize introducing bugs, but others have
>> > probably put more thought into how to handle this.
>> >
>> > So I'm looking for some direction either on what the end goal is and
>> how to
>> > achieve it, or direction to leave QIF alone for now and work on some
>> other
>> > area of the codebase (suggestions welcome).
>> >
>>
>> Hi Brian,
>>
>> Welcome to GnuCash.
>>
>> Rewriting the QIF importer to C++ is a reasonable task if that's what
>> motivates you. It's not on the roadmap in more than the most generic "get
>> rid of Guile" sense, but it does seem like a good project to take on. It's
>> as good a legacy conversion project as any at thi

Re: [GNC-dev] Import roadmap

[Brian Rater]

Great.  Thank you for the insights.  Before I got overwhelmed with work and
other commitments last year, I was experimenting with a set of base classes
that would replace the lower level qof infrastructure.  As part of that, I
was also looking at an alternative xml concept where xml provided some
fundamental utilities, but each class such as book and transaction would
use those to read and write themselves.  This keeps the data structures
contained in the class itself rather than xml needing to know about engine
class data structures.  That effort did not progress far enough to bring up
for discussion here or do a development branch pr, however.

I’m comfortable with redesigning and rearchitecting, but I am planning to
go cautiously with import/QIF as it sounds like a lot people use that and
the format is not well defined.  I don’t want to introduce new bugs.

On Sun, Feb 4, 2024 at 6:50 PM John Ralls  wrote:

>
>
> > On Feb 4, 2024, at 12:11 PM, Brian Rater  wrote:
> >
> > I've been looking at the import code and documentation and I'm wondering
> > what the overall plan and path is.  It looks like there is a "generic"
> > implementation in the top level directory which has utilities that are
> > being converted to C++.  I can see the importers making some calls into
> > this.  What is the plan and where are we at?
> >
> > In particular, what needs to happen with QIF, which is still written in
> > guile?
> >
> > I'm asking because I'm looking for a task to work on.  My particular
> > passion is writing C++ classes to replace legacy code along with adding
> > tests and documentation.  I've been reading over the source code and
> > following the development list for several months, but I've had limited
> > bandwidth until recently to make contributions.
> >
> > I've been looking at converting Import/QIF to C++ because it is written
> in
> > guile (higher priority than converting the C code in my opinion), is
> fairly
> > self contained, and the only alternative guile conversion code is
> reports,
> > which is way too large in scope for where I am.  Converting QIF has
> > drawbacks such as needing extensive testing, and having limited existing
> > tests for regression testing, however.
> >
> > My current thought is to directly translate the existing algorithms and
> not
> > use the generic import to minimize introducing bugs, but others have
> > probably put more thought into how to handle this.
> >
> > So I'm looking for some direction either on what the end goal is and how
> to
> > achieve it, or direction to leave QIF alone for now and work on some
> other
> > area of the codebase (suggestions welcome).
> >
>
> Hi Brian,
>
> Welcome to GnuCash.
>
> Rewriting the QIF importer to C++ is a reasonable task if that's what
> motivates you. It's not on the roadmap in more than the most generic "get
> rid of Guile" sense, but it does seem like a good project to take on. It's
> as good a legacy conversion project as any at this point. The rest are kind
> of blocked by the XML->in-memory SQL DB so that we can lose QOFQuery and
> stop creating huge linked lists of every object in the book. That's
> design-and-implement rather than rewrite an existing design so maybe not
> something you'd be passionate about.
>
> IMO it would be better to rewrite the QIF parser and transaction creator
> into C++ and then wire it in to the "generic" infrastructure so that it
> presents the same user experience as other imports.
> I'm not sure how well that fits with your passion either, but I'm also not
> convinced that it makes sense to reimplement functional algorithms as OO
> classes. I reimplemented the Scheme report options system into C++ a couple
> of years ago and it turned out to be a largely start-from-scratch redesign.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Import roadmap

[Brian Rater]

I've been looking at the import code and documentation and I'm wondering
what the overall plan and path is.  It looks like there is a "generic"
implementation in the top level directory which has utilities that are
being converted to C++.  I can see the importers making some calls into
this.  What is the plan and where are we at?

In particular, what needs to happen with QIF, which is still written in
guile?

I'm asking because I'm looking for a task to work on.  My particular
passion is writing C++ classes to replace legacy code along with adding
tests and documentation.  I've been reading over the source code and
following the development list for several months, but I've had limited
bandwidth until recently to make contributions.

I've been looking at converting Import/QIF to C++ because it is written in
guile (higher priority than converting the C code in my opinion), is fairly
self contained, and the only alternative guile conversion code is reports,
which is way too large in scope for where I am.  Converting QIF has
drawbacks such as needing extensive testing, and having limited existing
tests for regression testing, however.

My current thought is to directly translate the existing algorithms and not
use the generic import to minimize introducing bugs, but others have
probably put more thought into how to handle this.

So I'm looking for some direction either on what the end goal is and how to
achieve it, or direction to leave QIF alone for now and work on some other
area of the codebase (suggestions welcome).
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Git branches

[Brian Rater]

Future?

On Thu, Mar 23, 2023 at 8:57 PM John Ralls  wrote:

> We're 3 days away from releasing 5.0 and so 4 days away from shuffling the
> branches. Absent any objections I intend to rename the current "master" to
> "stable" and make it the default branch on Github. Bugfixes and
> minor-to-medium features can go to stable. I'll rename maint to
> archive/maint so that nobody is tempted to commit to it any more.
>
> We have a little time to discuss the medium-to-major branch name. We don't
> need it until someone has a medium-to-major feature branch to merge in.
> While "unstable" is the logical opposite of "stable" it's also shares too
> many letters, though unlike "main" and "maint" at least the extra letters
> are upfront so you're less likely to get bitten by completion. I'm inclined
> toward "development". "devel" would be OK if spell-check didn't keep trying
> to turn it into "level".
>
> Regards,
> John Ralls
>
>
> > On Nov 18, 2022, at 9:08 AM, john  wrote:
> >
> > We could pinch from Debian and use stable, testing, and unstable, where
> testing is the alpha/beta pre-major-release weeklies.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On Nov 18, 2022, at 7:55 AM, Geert Janssens 
> wrote:
> >>
> >> I'm fine with just doing the simple name change for our two primary
> branches as it's the option of least effort.
> >>
> >> I'd rather have a different name than "main" though. It's a bit
> ambiguous and like "master" suggesting this branch is somehow more
> important than the other long-term branch "maint". I'd rather have names
> that help guide contributors to the right branch to work from. I don't
> think there's a silver bullet here though, but some names may give more of
> a hint than others. Some suggestions:
> >>
> >> * "current" vs "future" as shorthands for "current-release-series" or
> "future-release-series"
> >> * "maintenance" ("maint") vs "development" ("devel")
> >> * "stable" vs "development"
> >>
> >> That said, I'm also very interested in the single branch model as
> alternative. Discussion on that is for another message.
> >>
> >> Regards,
> >>
> >> Geert
> >>
> >> Op maandag 14 november 2022 20:59:26 CET schreef john:
>  On Nov 14, 2022, at 11:11 AM, Alex Aycinena 
>  wrote:
> 
>  how about a simple change, like calling it 'main' rather than
>  'master' and keeping the existing pattern for branches.
> >>>
> >>> That would be OK as long as long as the two names aren't similar. main
> and
> >>> stable would be OK; with main and maint one is far too likely to do
> >>> something to the wrong branch.
> >>>
> >>> Regards,
> >>> John Ralls
> >>>
> >>> ___
> >>> 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
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel