Re: [Gnucash-changes] Eliminate a double free of memory.

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: On Gnucash, G2, and Architecture

Derek Atkins
Chris Shoemaker <[hidden email]> writes:

> BTW, my mini-projects at the moment are 1) looking at what's needed to
> remove GnomeCanvas from the register.  2) looking at what's needed to
> move the execution entry-point from guile to a C main.  But more 1)
> than 2).

I think the simplest way to achieve #2 is to build our own
"/usr/bin/guile" interpreter.  We could even build the various runtime
paths into the binary.  As our binary would use the same libguile as
the rest of the code, it would separate us from the issue of
/usr/bin/guile changing out from under us..  It would also be a start
at fixing the problem as a whole, but it would be an easy first step.

Granted, if we don't expect a guile 1.7 or 1.8 anytime soon then it
might not be an issue.

I'm concerned that your #1 mini-project would cause a lot of code
churn and introduce a lot of potential bugs in the short term.  But
please come up with a design document before you start and we'll see
what you plan to do.  It might be worthwhile to _just fix this_ if the
risk is low and the timeframe is short.  Otherwise I'd prefer to wait
until after the 1.10 release.

And yes, I'm considering g2 to be 1.10, not 2.0.  The file format
hasn't changed, the functionality hasn't (majorly) changed.  And I'd
like to wait until we get the new DB code before moving to "2.0".

> -chris

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: On Gnucash, G2, and Architecture

Chris Shoemaker
On Wed, Jun 08, 2005 at 08:34:10AM -0400, Derek Atkins wrote:

> Chris Shoemaker <[hidden email]> writes:
>
> > BTW, my mini-projects at the moment are 1) looking at what's needed to
> > remove GnomeCanvas from the register.  2) looking at what's needed to
> > move the execution entry-point from guile to a C main.  But more 1)
> > than 2).
>
> I think the simplest way to achieve #2 is to build our own
> "/usr/bin/guile" interpreter.  We could even build the various runtime
> paths into the binary.  As our binary would use the same libguile as
> the rest of the code, it would separate us from the issue of
> /usr/bin/guile changing out from under us..  It would also be a start
> at fixing the problem as a whole, but it would be an easy first step.
>
> Granted, if we don't expect a guile 1.7 or 1.8 anytime soon then it
> might not be an issue.

I really don't understand the whole issue well enough to respond
meaningfully at this time, but if I look into #2, I'll come back
and reread this.

>
> I'm concerned that your #1 mini-project would cause a lot of code
> churn and introduce a lot of potential bugs in the short term.  But
> please come up with a design document before you start and we'll see
> what you plan to do.  It might be worthwhile to _just fix this_ if the
> risk is low and the timeframe is short.  Otherwise I'd prefer to wait
> until after the 1.10 release.

You're right.  Converting the register is not something you'd want to
do right before releasing g2.  Right now, I'm still investigating the
feasibility of using GncTreeView and GtkTreeModel to make a register.
Initially, there are several things that make this very attractive, but
there are also 3 or 4 issues that may be show-stoppers.  If I convince
myself that it is indeed feasible, I'll whip up a prototype demo.  In
any case, there's no way that this investigation should impede g2
progress.

-chris

>
> And yes, I'm considering g2 to be 1.10, not 2.0.  The file format
> hasn't changed, the functionality hasn't (majorly) changed.  And I'd
> like to wait until we get the new DB code before moving to "2.0".
>
> > -chris
>
> -derek
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: On Gnucash, G2, and Architecture

Derek Atkins
Chris Shoemaker <[hidden email]> writes:

> On Wed, Jun 08, 2005 at 08:34:10AM -0400, Derek Atkins wrote:
>> Chris Shoemaker <[hidden email]> writes:
>>
>> > BTW, my mini-projects at the moment are 1) looking at what's needed to
>> > remove GnomeCanvas from the register.  2) looking at what's needed to
>> > move the execution entry-point from guile to a C main.  But more 1)
>> > than 2).
>>
>> I think the simplest way to achieve #2 is to build our own
>> "/usr/bin/guile" interpreter.  We could even build the various runtime
>> paths into the binary.  As our binary would use the same libguile as
>> the rest of the code, it would separate us from the issue of
>> /usr/bin/guile changing out from under us..  It would also be a start
>> at fixing the problem as a whole, but it would be an easy first step.
>>
>> Granted, if we don't expect a guile 1.7 or 1.8 anytime soon then it
>> might not be an issue.
>
> I really don't understand the whole issue well enough to respond
> meaningfully at this time, but if I look into #2, I'll come back
> and reread this.

Find about 30 minutes where we can sit on IRC and I'll happily give
you all the gorey details.  The short answer is that guile-1.3.4,
guile-1.4, and guile-1.6 all have different libguile sonames, and they
are incompatible.  However there is only one /usr/bin/guile.  The
Gnucash "modules" are compiled against some particular version of
guile and link against that version of libguile.  If /usr/bin/guile is
NOT that particular version of guile (you may have multiple libguile's
installed) then Boom!

>> I'm concerned that your #1 mini-project would cause a lot of code
>> churn and introduce a lot of potential bugs in the short term.  But
>> please come up with a design document before you start and we'll see
>> what you plan to do.  It might be worthwhile to _just fix this_ if the
>> risk is low and the timeframe is short.  Otherwise I'd prefer to wait
>> until after the 1.10 release.
>
> You're right.  Converting the register is not something you'd want to
> do right before releasing g2.  Right now, I'm still investigating the
> feasibility of using GncTreeView and GtkTreeModel to make a register.
> Initially, there are several things that make this very attractive, but
> there are also 3 or 4 issues that may be show-stoppers.  If I convince
> myself that it is indeed feasible, I'll whip up a prototype demo.  In
> any case, there's no way that this investigation should impede g2
> progress.

Cool.  I'm definitely keen in seeing the register code cleaned up.  It
would be nice if the amount of code required to build a _particular_
register was fairly small.

However I'd still rather see you spend your energies helping us get g2
out the door ;)

> -chris

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
123