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: [Gnucash-changes] Eliminate a double free of memory.

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

> Thanks for explaining.  I haven't looked at the details, but shouldn't
> destroy signal handler just generate the right CM event, and then the
> CM close handler for the cw structure actually frees cw.  I thought
> that was the intended use of the CM.

Actually, no, the CM is intended to trigger events when DATA OBJECTS
change, not when Windows change.  When a Data Object is destroyed it
signals a CM Close which should cause the window to get destroyed.
This is to handle things like you having an Account Window open and
then you decide to delete the account from the account tree.

So the Component Manager acts on Data Objects, which is exactly what
it's doing. When the CM sends a close event it triggers the gtk
destroy event.  The gtk destroy is what clears all the memory.

You never NEED to trigger a CM close.  You just need to gracefully
handle it.

> -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: [Gnucash-changes] Eliminate a double free of memory.

Chris Shoemaker
In reply to this post by Derek Atkins
On Fri, Jun 03, 2005 at 09:14:19AM -0400, Derek Atkins wrote:
> Quoting Chris Shoemaker <[hidden email]>:
>
<snip>

>
> I really don't think there's a bug here...  There was a use-after-free but it
> was from the context, not the widget.  Hampton fixed that.  I really don't
> think we need to re-architect the rest of the code.  It works just fine, and
> all the rest of gnucash uses this same model:
>
> CM close callback tells the widget to destroy itself
> Gtk Destroy callback frees the context and clears the references.
>
> So I don't think we need to do anything.  What we've got works just fine (modulo
> the bug that hampton fixed already).

It's better to design out a bug than to patch it out.  The existing
pattern is bad for many reasons.

1) It's an abuse of the documented gtk destroy api, which is only
suppose to break references, NOT free anything.  (Freeing is handled
by finalize, and only when refcount = 0.)

2) High coupling: currently, the destroy handler takes the cw as
user-data and can pillage all the fields of the cw struct before
finally freeing something that doesn't even depend on the dialog.  In
the correct usage of destroy, it should only receive the component_id
through userdata -- just enough to break external references, no more,
no less -- low coupling.

3) Low cohesion: currently, the destroy handler for the dialog has to
know tons about the cw struct and about the CM, including CM
unregistration.  Likewise, the close handler has to know about all the
side-effects of the destroy handler.  In a high cohesion design, the
destroy handler only has to know how to break the single external
reference, and the close callback rightly accesses the data fields for
the component that generated the event.  The close handler doesn't
have to know any more about the destroy signal than what I can read in
the GTK docs: it breaks refs.

BTW, I'm _really_ not a design nazi.  I just _look_ like one next to
you.  :) You seem to think that anything in GC that works must be a good
design.  You might try being a bit more open-minded about proposals
for design improvements, especially coming from people who've proven a
willingness to code, and especially when those proposals don't require
any action on your part.  

If you think a proposal is really bad, try to make _constructive_
recommendations for improvement, (GC can always be improved, you know)
and not be so disparaging.  I'm seeing that this "we've always done it
that way; we do that everywhere; it works; we don't need to change
anything... etc." attitude is a disturbing and recurring pattern.

Maybe being more honest about GC's design, ehm, weaknesses, would
encourage more developer participation.

Just a thought.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

David Hampton-2
On Fri, 2005-06-03 at 11:11 -0400, Chris Shoemaker wrote:
> On Fri, Jun 03, 2005 at 09:14:19AM -0400, Derek Atkins wrote:
> > So I don't think we need to do anything.  What we've got works just fine (modulo
> > the bug that hampton fixed already).
>
> It's better to design out a bug than to patch it out.

Normally I would agree with you.  In this particular case, I tried to do
that three years ago and ended up throwing up my hands and declaring
that I had better things to do.

> 1) It's an abuse of the documented gtk destroy api, which is only
> suppose to break references, NOT free anything.

We're reading the documentation differently.

    Because these references are released, calling gtk_object_destroy()
    should result in FREEING ALL MEMORY ASSOCIATED WITH AN OBJECT,
    unless some buggy code fails to release its references in response
    to the "destroy" signal.

Emphasis mine.  This begs the question of whether the gnucash data
structure that is intimately tied to the dialog is considered memory
associated with an object.  As an object implementor, I'd say no.  As a
gnucash developer, I'd say yes, since the majority of the fields in the
data structure point to widgets within the dialog, and all of these
pointers will be invalidated when the dialog is destroyed.

> (Freeing is handled by finalize, and only when refcount = 0.)

Finalize is not a signal, its a gobject class virtual function.  Its
only available to object implementors, not code that uses objects that
were implemented elsewhere.  If you want to use finalize here then
you'll need to subclass a GtkWindow.

> BTW, I'm _really_ not a design nazi.  I just _look_ like one next to
> you.  :) You seem to think that anything in GC that works must be a good
> design.

That's unfair Chris.  I don't think I've ever heard Derek say that its a
good design, only that it works so why change it.

> You might try being a bit more open-minded about proposals
> for design improvements, especially coming from people who've proven a
> willingness to code,

Also unfair.  I'd say Derek's probably the main person who has kept this
project going for the last couple of years.

> and especially when those proposals don't require
> any action on your part.  

Not true.  It needs to be evaluated to see if its a good design, whether
it will work in gnucash, etc.   Derek's already pointed out a potential
timing issue neither of us saw.

> If you think a proposal is really bad, try to make _constructive_
> recommendations for improvement, (GC can always be improved, you know)
> and not be so disparaging.  I'm seeing that this "we've always done it
> that way; we do that everywhere; it works; we don't need to change
> anything... etc." attitude is a disturbing and recurring pattern.

Lets see.  Derek did the following:

1) Pointed out that events may be turned off in the CM so that the close
function is called long after the gtk_widget_destroy function has
finished.  I had completely forgotten it might do that and was assuming
all the calls were synchronous.

2) Pointed out that other windows/dialogs have the same code.  My guess
would be that they all do.

3) Stated that he doesn't think its a bug, and that we don't need to re-
architect the code.

The first is a crucial point for designing a solution.  The second is
pointing out the scale of the problem.  The third is his viewpoint on
the issue.  You've clearly taken offense that he doesn't agree with you
that this is a heinous design issue that needs to be fixed immediately.

While I agree that this component manager/gtk interaction code isn't the
best written code, its served it purpose over the last five years.  I
think there are more important things to fix and ideas to implement, but
if this is what you want to work on, more power to you.  Its not a
simple problem.  I don't know if your idea of hanging onto an extra ref
on the dialog will work, because I don't know how the window manager
tells gnucash to destroy the dialog.  If this communication results in a
call to g_object_unref, then you'll never get the destroy callback
because the refcount will now never go to zero.  If it results in a
direct call to gtk_widget_destroy, does the ref really give you
anything.  If the destroy function has already run to completion then
all the child widgets are gone, all you have left is a pointer to an
empty GtkWindow object, and all the other pointers in the data structure
are still invalid because the widgets they point to are gone.

I can't speak for Derek, but I'm willing to look at any changes you
propose for this area.  They just have to be thoroughly tested (e.g.
normal close, window manager close, CM close, application killed, etc.)
before I will spend much time on them.  I'm still overwhelmed with gtk2
changes/cleanups, and I've barely even cracked the new "Human Interface
Guidelines" document.

> Maybe being more honest about GC's design, ehm, weaknesses, would
> encourage more developer participation.

Sure, gnucash has design weaknesses.  I'm not sure this should be
considered a big one.  I'd be more concerned about the code paths that
have multiple nested calls from C to Scheme to C, or the fact that half
of the startup logic is in Scheme, or that the register is one giant
hairy mess of a Gnome Canvas studded with hand drawn boxes linked to an
off-screen GtkEntry with some of the most twisted and tortured logic
I've seen.  I'm sure I can come up with more.

> Just a thought.

My two bits.

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Chris Shoemaker
On Fri, Jun 03, 2005 at 02:16:46PM -0400, David Hampton wrote:

> On Fri, 2005-06-03 at 11:11 -0400, Chris Shoemaker wrote:
> > On Fri, Jun 03, 2005 at 09:14:19AM -0400, Derek Atkins wrote:
> > > So I don't think we need to do anything.  What we've got works just fine (modulo
> > > the bug that hampton fixed already).
> >
> > It's better to design out a bug than to patch it out.
>
> Normally I would agree with you.  In this particular case, I tried to do
> that three years ago and ended up throwing up my hands and declaring
> that I had better things to do.

I can sympathize.

>
> > 1) It's an abuse of the documented gtk destroy api, which is only
> > suppose to break references, NOT free anything.
>
> We're reading the documentation differently.
>
>     Because these references are released, calling gtk_object_destroy()
>     should result in FREEING ALL MEMORY ASSOCIATED WITH AN OBJECT,
>     unless some buggy code fails to release its references in response
>     to the "destroy" signal.
>
> Emphasis mine.  This begs the question of whether the gnucash data
> structure that is intimately tied to the dialog is considered memory
> associated with an object.  As an object implementor, I'd say no.  As a
> gnucash developer, I'd say yes, since the majority of the fields in the
> data structure point to widgets within the dialog, and all of these
> pointers will be invalidated when the dialog is destroyed.

That question is not really relevant.  "should result in" is correct,
but it means indirectly as a result of ref count dropping to 0.  Look
at the api docs for the gtk_object_destroy() function:

    Emits the "destroy" signal notifying all reference holders that
    they should release the GtkObject... The memory for the object
    itself won't be deleted until its reference count actually drops to 0;
    gtk_object_destroy() MERELY ASKS reference holders to RELEASE THEIR
    REFERENCES, IT DOES NOT FREE THE OBJECT.

Emphasis mine.  It's not very ambiguous.

>
> > (Freeing is handled by finalize, and only when refcount = 0.)
>
> Finalize is not a signal, its a gobject class virtual function.  Its
> only available to object implementors, not code that uses objects that
> were implemented elsewhere.  If you want to use finalize here then
> you'll need to subclass a GtkWindow.

That's right, because we don't have to worry about finalization.  It
will happen automatically when refcount == 0.  All we have to do
correctly is call object_ref when we save a reference to the dialog,
(and unref when we release, of course.)

>
> > BTW, I'm _really_ not a design nazi.  I just _look_ like one next to
> > you.  :) You seem to think that anything in GC that works must be a good
> > design.
>
> That's unfair Chris.  I don't think I've ever heard Derek say that its a
> good design, only that it works so why change it.

I certainly don't mean to be unfair, and I apologize if Derek thinks I
was.  Derek didn't say it was a good design, but it's pretty hard to
get him to say anything in GC is a _bad_ design.  I really think that
he's just spent so long with GC code, that almost everything there
looks reasonable to him, even stuff that, IMHO, isn't very reasonable.

>
> > You might try being a bit more open-minded about proposals
> > for design improvements, especially coming from people who've proven a
> > willingness to code,
>
> Also unfair.  I'd say Derek's probably the main person who has kept this
> project going for the last couple of years.

Granted.

<snip>

>
> Lets see.  Derek did the following:
>
> 1) Pointed out that events may be turned off in the CM so that the close
> function is called long after the gtk_widget_destroy function has
> finished.  I had completely forgotten it might do that and was assuming
> all the calls were synchronous.
>
> 2) Pointed out that other windows/dialogs have the same code.  My guess
> would be that they all do.
>
> 3) Stated that he doesn't think its a bug, and that we don't need to re-
> architect the code.
>
> The first is a crucial point for designing a solution.  The second is
> pointing out the scale of the problem.  The third is his viewpoint on
> the issue.  

All good points.

> You've clearly taken offense that he doesn't agree with you
> that this is a heinous design issue that needs to be fixed immediately.

That's not really true.  "Offense" is too strong; It'd be more
accurate to say that I'm "concerned" that he doesn't agree with me
that this is a design issue _at_all_, and furthermore, (actually this
is more of the real concern:) that this is just one example
representative of a rather long list of (IMO) design "weaknesses"
about which we disagree.  


>
> While I agree that this component manager/gtk interaction code isn't the
> best written code, its served it purpose over the last five years.  I
> think there are more important things to fix and ideas to implement, but
> if this is what you want to work on, more power to you.  

That's a refreshing attitude.

<snip comments on ref holding>

>
> I can't speak for Derek, but I'm willing to look at any changes you
> propose for this area.  They just have to be thoroughly tested (e.g.
> normal close, window manager close, CM close, application killed, etc.)
> before I will spend much time on them.  I'm still overwhelmed with gtk2
> changes/cleanups, and I've barely even cracked the new "Human Interface
> Guidelines" document.
>
> > Maybe being more honest about GC's design, ehm, weaknesses, would
> > encourage more developer participation.
>
> Sure, gnucash has design weaknesses.  I'm not sure this should be
> considered a big one.  I'd be more concerned about the code paths that
> have multiple nested calls from C to Scheme to C, or the fact that half
> of the startup logic is in Scheme, or that the register is one giant
> hairy mess of a Gnome Canvas studded with hand drawn boxes linked to an
> off-screen GtkEntry with some of the most twisted and tortured logic
> I've seen.  I'm sure I can come up with more.

Agreed on all counts.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

On Gnucash, G2, and Architecture (was Re: [Gnucash-changes] Eliminate a double free of memory.)

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

>> > It's better to design out a bug than to patch it out.
>>
>> Normally I would agree with you.  In this particular case, I tried to do
>> that three years ago and ended up throwing up my hands and declaring
>> that I had better things to do.
>
> I can sympathize.

For the record, I looked at this a long time ago as well.  At the time
I concluded that all destruction of data should happen in the GTK
"destroy" callback, because not all dialogs use the component manager.
This way all dialogs are consistent.  You see, all of them DO use
gtk. :)

This means that all the component manager callback needs to do it
destroy the widget (call gtk_widget_destroy() on the dialog) and
return.

Consistency is a good thing.

>> > BTW, I'm _really_ not a design nazi.  I just _look_ like one next to
>> > you.  :) You seem to think that anything in GC that works must be a good
>> > design.
>>
>> That's unfair Chris.  I don't think I've ever heard Derek say that its a
>> good design, only that it works so why change it.
>
> I certainly don't mean to be unfair, and I apologize if Derek thinks I
> was.  Derek didn't say it was a good design, but it's pretty hard to
> get him to say anything in GC is a _bad_ design.  I really think that
> he's just spent so long with GC code, that almost everything there
> looks reasonable to him, even stuff that, IMHO, isn't very reasonable.

Um, you clearly haven't read my posts over the last, oh, five years.
I'm always the FIRST to stand up and list the things wrong with gnucash.
David listed a few.  A few more on my list:

  - the half-assed modularization effort
  - the poor distinction between shared library and loadable module
  - the fact that gnucash is fragile in the face of "/usr/bin/guile"
    changing versions
  - too much logic in the UI
  - too many "gpointer" apis without real runtime type checking
    (it would be better to have compile-time type checking, but
    that's even HARDER is C).

I *AM* an architecture purist, even if you haven't been able to
notice.  On the other hand, I'm also a realist, and truly believe that
"The Perfect is the enemy of The Good".  I'd much rather have
something less than perfect but still "good enough" and get it out the
door than not have anything (because I haven't reached that nirvana of
"perfect").

I think David hit the nail on the head when he said that we need to
get the g2 port out the door and there are many real issues now that
need to be fixed, places where the code crashes or just plain doesn't
work...  And THOSE are IMHO orders of magnitude more important to
fix/replace/repair than replacing code that might not be
architecturally pure but still happen to work just fine.

In an idea world with unlimited resources, sure, I'd LOVE to
completely re-architect gnucash from the ground up.  I'd probably go
with C++ and Qt as my building blocks, but that's just a side note.
We don't live in an idea world, and we don't have unlimited resources.
Therefore, we need to take the resources we have and apply them in the
most beneficial way.

Which do you think is more beneficial to the project in the next six
months:

a) Taking a piece of code that might be architecturally questionable
   but doesn't crash, doesn't corrupt data, and doesn't cause any
   visual problems and spend time to fix the architecture and rototill
   the code to change how it works?

 or

b) Take some code that causes the program to crash, corrupts data, or
   visually misbehaves and spend the time to fix those issues?

>> You've clearly taken offense that he doesn't agree with you
>> that this is a heinous design issue that needs to be fixed immediately.
>
> That's not really true.  "Offense" is too strong; It'd be more
> accurate to say that I'm "concerned" that he doesn't agree with me
> that this is a design issue _at_all_, and furthermore, (actually this
> is more of the real concern:) that this is just one example
> representative of a rather long list of (IMO) design "weaknesses"
> about which we disagree.  

In the grand scheme of things (or at least the grand scheme of gnucash
[no pun intended]) I don't think this is a heinous architectural flaw.
I can certainly point out a half dozen or more significantly more
heinous archictectural flaws in gnucash.

Yes, you and I certainly disagree on the magnitude of the issue.  I
tend to focus on what I consider the larger ones, those that have
caused lots of user pain and angst over time; those that represent
potential problems going forward.  I listed a few of them earlier.
Feel free to look at my posts over the last five years for a bunch of
other complaints.  Also take a look at bugzilla for a list of users'
complaints :)

Frankly, I want to spend my time gaining the most bang for my buck.  I
don't want to spend 10 hours writing code that will save me 20 minutes
every five years; I want to spend 20 hours writing code that will save
me from answering 5 user help emails every day.

>> I can't speak for Derek, but I'm willing to look at any changes you
>> propose for this area.  They just have to be thoroughly tested (e.g.
>> normal close, window manager close, CM close, application killed, etc.)
>> before I will spend much time on them.  I'm still overwhelmed with gtk2
>> changes/cleanups, and I've barely even cracked the new "Human Interface
>> Guidelines" document.

Personally I'd rather see you work on fixing code that's actually
broken (read: doesn't work, causes crashes, causes data corruption,
etc.) than spending time re-architecting code that works, albeit in a
weird way.  Do I think the current code is the best possible way it
could be done?  Hell no!  Could it be done better?  Hell yea!

But honestly..  How does changing the CM/Gtk interaction help us
release the g2 port any sooner?  Shouldn't we make getting the g2 port
out the door our #1 concern?

Assuming you answer "yes" to my final question (and I really hope you
DO answer "yes")...  what do you feel are the steps necessary to get
the g2 port "finished" and out the door?  What do YOU think is missing
or still needs to be done before it's ready to package up and pass on
to users?

-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: [Gnucash-changes] Eliminate a double free of memory.

David Hampton-2
In reply to this post by Chris Shoemaker
On Fri, 2005-06-03 at 15:24 -0400, Chris Shoemaker wrote:

> On Fri, Jun 03, 2005 at 02:16:46PM -0400, David Hampton wrote:
> > On Fri, 2005-06-03 at 11:11 -0400, Chris Shoemaker wrote:
> >
> > > 1) It's an abuse of the documented gtk destroy api, which is only
> > > suppose to break references, NOT free anything.
> >
> > We're reading the documentation differently.
> >
> >     Because these references are released, calling gtk_object_destroy()
> >     should result in FREEING ALL MEMORY ASSOCIATED WITH AN OBJECT,
> >     unless some buggy code fails to release its references in response
> >     to the "destroy" signal.
> >
> > Emphasis mine.  This begs the question of whether the gnucash data
> > structure that is intimately tied to the dialog is considered memory
> > associated with an object.  As an object implementor, I'd say no.  As a
> > gnucash developer, I'd say yes, since the majority of the fields in the
> > data structure point to widgets within the dialog, and all of these
> > pointers will be invalidated when the dialog is destroyed.
>
> That question is not really relevant.  "should result in" is correct,
> but it means indirectly as a result of ref count dropping to 0.  Look
> at the api docs for the gtk_object_destroy() function:
>
>     Emits the "destroy" signal notifying all reference holders that
>     they should release the GtkObject... The memory for the object
>     itself won't be deleted until its reference count actually drops to 0;
>     gtk_object_destroy() MERELY ASKS reference holders to RELEASE THEIR
>     REFERENCES, IT DOES NOT FREE THE OBJECT.
>
> Emphasis mine.  It's not very ambiguous.

Lovely.  We're reading different parts of the same GtkObject
documentation and coming away with different interpretations.  

I'm trying to follow the execution through the gtk/glib sources, but I'm
not at all clear on how it works through.  As I see it the following
happens:

  gtk_object_destroy calls
    g_object_run_dispose calls
      g_object_ref (object)
        G_OBJECT_GET_CLASS (object)->dispose (object);
        gtk_window_dispose
          gtk_widget_dispose
            gtk_widget_unrealize
            gtk_object_dispose
              g_signal_emit (object, object_signals[DESTROY], 0);
                anything connected to destroy
                gtk_window_destroy
                  gtk_container_destroy
                    DESTROY ANY OBJECTS IN THIS CONTAINER
                    gtk_widget_real_destroy
                     gtk_object_real_destroy
                       g_signal_handlers_destroy (object);
                anything connected "after" to destroy
              g_object_real_dispose
                g_signal_handlers_destroy
      g_object_unref (object);

As far as I can tell, you'll still have the GtkWindow object itself
after the call to gtk_object_destroy finishes, but it will no longer
contain any child objects.  Remember every child widget holds a
reference on its parent, so if all reference holders must release their
references, then all child widgets must be removed.  While this
technically meets the statement that the memory of the object passed in
is not freed, its not really useful.  (The statement in the
documentation says nothing of what happens to contained objects.)  This
is the difference between calling g_object_unref knowing that the object
will eventually be destroyed when its refcount goes to zero, and
explicitly asking for the object to be destroyed by calling
gtk_object_destroy.   Please let me know if I'm reading the code wrong.
The signal code is a pain to parse.

> > You've clearly taken offense that he doesn't agree with you
> > that this is a heinous design issue that needs to be fixed immediately.
>
> That's not really true.  "Offense" is too strong; It'd be more
> accurate to say that I'm "concerned" that he doesn't agree with me
> that this is a design issue _at_all_, and furthermore, (actually this
> is more of the real concern:) that this is just one example
> representative of a rather long list of (IMO) design "weaknesses"
> about which we disagree.  

I can't speak for Derek, but my guess would be that you two have very
different thresholds of what's important and what's not.  

David



_______________________________________________
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 (was Re: [Gnucash-changes] Eliminate a double free of memory.)

Chris Shoemaker
In reply to this post by Derek Atkins
On Fri, Jun 03, 2005 at 04:31:03PM -0400, Derek Atkins wrote:
<snip>

> Um, you clearly haven't read my posts over the last, oh, five years.
> I'm always the FIRST to stand up and list the things wrong with gnucash.
> David listed a few.  A few more on my list:
>
>   - the half-assed modularization effort
>   - the poor distinction between shared library and loadable module
>   - the fact that gnucash is fragile in the face of "/usr/bin/guile"
>     changing versions
>   - too much logic in the UI
>   - too many "gpointer" apis without real runtime type checking
>     (it would be better to have compile-time type checking, but
>     that's even HARDER is C).
>
> I *AM* an architecture purist, even if you haven't been able to
> notice.  On the other hand, I'm also a realist, and truly believe that
> "The Perfect is the enemy of The Good".  I'd much rather have
> something less than perfect but still "good enough" and get it out the
> door than not have anything (because I haven't reached that nirvana of
> "perfect").
>
> I think David hit the nail on the head when he said that we need to
> get the g2 port out the door and there are many real issues now that
> need to be fixed, places where the code crashes or just plain doesn't
> work...  And THOSE are IMHO orders of magnitude more important to
> fix/replace/repair than replacing code that might not be
> architecturally pure but still happen to work just fine.
>
> In an idea world with unlimited resources, sure, I'd LOVE to
> completely re-architect gnucash from the ground up.  I'd probably go
> with C++ and Qt as my building blocks, but that's just a side note.
> We don't live in an idea world, and we don't have unlimited resources.
> Therefore, we need to take the resources we have and apply them in the
> most beneficial way.
>
> Which do you think is more beneficial to the project in the next six
> months:
>
> a) Taking a piece of code that might be architecturally questionable
>    but doesn't crash, doesn't corrupt data, and doesn't cause any
>    visual problems and spend time to fix the architecture and rototill
>    the code to change how it works?
>
>  or
>
> b) Take some code that causes the program to crash, corrupts data, or
>    visually misbehaves and spend the time to fix those issues?

        I honestly don't know.  I know the question was rhetorical,
but I think the answer really depends on many factors.  IMO, having a
g2 port that works as well and 1.x, but is equally (un)maintainable is
only of _marginal_ benefit.  (And I'm not sure even 6 months will find
us there.)  IMO, 95% of the benefit of the g2 port is the potential
for improving maintainability.  ** That benefit is not realized by the
quickest fixes, but by the design fixes. **

        You and I really do have very different interests regarding
GC.  I realize that the next 6 months are very important to you.  I'm
much more concerned about where GC will be in 36 months than 6.  I
figure, in 6 months, 1.x will still be an option.  In 36 months, it
won't be, and neither will g2 if it develops at anywhere near the rate
it has in the past 24 months.  Call me alarmist if you want, but I
think GC is "on the brink."  Its survival is no gaurantee.  IMO, its
survival depends on architectural improvements far more than fixing
visual misbehavior or program crashes.  Why?  

** Because the universe of developers willing and able to fix program
crashes is determined by the architecture, but the (very small) universe
of developers willing and able to fix the architecture has almost
*nothing* to do with the program's usability. **

<snip>
> In the grand scheme of things (or at least the grand scheme of gnucash
> [no pun intended]) I don't think this is a heinous architectural flaw.
> I can certainly point out a half dozen or more significantly more
> heinous archictectural flaws in gnucash.

I would agree.

<snip>
> Personally I'd rather see you work on fixing code that's actually
> broken (read: doesn't work, causes crashes, causes data corruption,
> etc.) than spending time re-architecting code that works, albeit in a
> weird way.  Do I think the current code is the best possible way it
> could be done?  Hell no!  Could it be done better?  Hell yea!
>
> But honestly..  How does changing the CM/Gtk interaction help us
> release the g2 port any sooner?  Shouldn't we make getting the g2 port
> out the door our #1 concern?

I think that should be *somebody's* #1 concern.  But I also think, for
the reasons above, that if that's *everybody's* #1 concern, then in 12
months, GC will still have the equivalent of < 1 full-time developer,
and it will be obsoleted within another 18-24 months.

I think *somebody's* #1 concern should be making the architectural
changes that will attract more developers.  I know you're said that
you don't really care about attracting new developers, and that we
have a few really good devs now.  Nevertheless, IMO, attracting more
devs is essential to GC's survival.

I also recognize that my prioritization is a minority view, but I
don't think it's necessarily bad that different devs have different
priorities.

>
> Assuming you answer "yes" to my final question (and I really hope you
> DO answer "yes")...  

Was that a qualified "yes"?  :)

> what do you feel are the steps necessary to get
> the g2 port "finished" and out the door?  What do YOU think is missing
> or still needs to be done before it's ready to package up and pass on
> to users?

I don't know.  As a user, the register misbehavior really bothers me.
As a dev, the register code insanity bothers me even more.  :)

-chris
_______________________________________________
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 (was Re: [Gnucash-changes] Eliminate a double free of memory.)

Chris Shoemaker
In reply to this post by Derek Atkins
On Fri, Jun 03, 2005 at 04:31:03PM -0400, Derek Atkins wrote:

> Chris Shoemaker <[hidden email]> writes:
>
> >> > It's better to design out a bug than to patch it out.
> >>
> >> Normally I would agree with you.  In this particular case, I tried to do
> >> that three years ago and ended up throwing up my hands and declaring
> >> that I had better things to do.
> >
> > I can sympathize.
>
> For the record, I looked at this a long time ago as well.  At the time
> I concluded that all destruction of data should happen in the GTK
> "destroy" callback, because not all dialogs use the component manager.
> This way all dialogs are consistent.  You see, all of them DO use
> gtk. :)
>
> This means that all the component manager callback needs to do it
> destroy the widget (call gtk_widget_destroy() on the dialog) and
> return.
>
> Consistency is a good thing.

BTW, FTR, there are some examples of better usage in the tree. E.g. I
just ran across gnc-ledger-display.c:

The CM close handler is:
static void close_handler (gpointer user_data)
{
  GNCLedgerDisplay *ld = user_data;

  if (!ld) return;

  gnc_unregister_gui_component (ld->component_id);

  if (ld->destroy) ld->destroy (ld);

  gnc_split_register_destroy (ld->reg);
  ld->reg = NULL;

  xaccFreeQuery (ld->query);
  ld->query = NULL;

  g_free (ld);
}

Notice how the component frees its own mem after unregistering with CM
and calling destroy on the register.

The register destroy is:
void gnc_split_register_destroy (SplitRegister *reg)
{
  if (!reg) return;

  gnc_split_register_cleanup (reg); // This grabs state and commits the split.

  gnc_table_destroy (reg->table);
  reg->table = NULL;

  /* free the memory itself */
  g_free (reg);
}

Notice how the register destroy doesn't know anything about the ledger
object.  Children of g_object are refcounted so they shouldn't do the
g_free step, but it's correct for the SplitRegister struct, since it's
not refcounted.

-chris
_______________________________________________
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
In reply to this post by Chris Shoemaker
Chris,

Chris Shoemaker <[hidden email]> writes:

>> Which do you think is more beneficial to the project in the next six
>> months:
>>
>> a) Taking a piece of code that might be architecturally questionable
>>    but doesn't crash, doesn't corrupt data, and doesn't cause any
>>    visual problems and spend time to fix the architecture and rototill
>>    the code to change how it works?
>>
>>  or
>>
>> b) Take some code that causes the program to crash, corrupts data, or
>>    visually misbehaves and spend the time to fix those issues?
>
>         I honestly don't know.  I know the question was rhetorical,
> but I think the answer really depends on many factors.  IMO, having a
> g2 port that works as well and 1.x, but is equally (un)maintainable is
> only of _marginal_ benefit.  (And I'm not sure even 6 months will find
> us there.)  IMO, 95% of the benefit of the g2 port is the potential
> for improving maintainability.  ** That benefit is not realized by the
> quickest fixes, but by the design fixes. **

See, I don't think it's of marginal benefit to get g2 into the hands
of the users even if it only works as well as 1.8.  Indeed, currently
the g2 port does NOT work as well as 1.8!  I think just getting it up
to 1.8's level is sufficient to make users happy and extend the life
of the project.

I don't know if 6 months will find us there.  If we keep rewriting
working code then it certainly wont.  But if we focus on actual bugs,
so we CAN bring g2 up to the 1.8 working level, then I think it's
possible to complete in 6 months.

We've got GoG working, that was a major issue.  Now we just need to
make sure all the dialogs work, all the signals are attached, etc.
Sure, it sounds like busywork, but we're at the _end_ of the dev cycle
here and that's always busywork.  Once we release we can open up to
major restructuring.  But now is not the time to do it.

>         You and I really do have very different interests regarding
> GC.  I realize that the next 6 months are very important to you.  I'm
> much more concerned about where GC will be in 36 months than 6.  I
> figure, in 6 months, 1.x will still be an option.  In 36 months, it
> won't be, and neither will g2 if it develops at anywhere near the rate
> it has in the past 24 months.  Call me alarmist if you want, but I
> think GC is "on the brink."  Its survival is no gaurantee.  IMO, its
> survival depends on architectural improvements far more than fixing
> visual misbehavior or program crashes.  Why?  

Actually, I don't think you're behind alarmist enough!  I'm also
concerned about where gnucash will be in 36 months, but if we don't
get the g2 release out SOON I don't think there will even BE a gnucash
in 36 months.  Gnucash has already started dropping out of distros.
We've been out of slackware for years (I think 1.6 was packaged, but
I'm fairly sure 1.8 never was).  We got dropped from RHEL 3.  I think
we're in FC4 but I suspect we'll get dropped from FC5.  Debian has
considered dropping it.  Fink has considered dropping it...

Seriously, if we don't get g2 out the door _THIS YEAR_ I don't think
there will be a gnucash in 36 months for you to primp and preen.

Keep in mind that we also need a good 3 months after "feature freeze"
in order to stabilize the release.  At least that's how long it took
to get 1.8 out the door.  There was a good 3 months of bi-weekly
releases to get alpha tested, build tested, and into user's hands.  So
even if we think it'll be another 6 months of developer work to
"finish" g2, that means 9 months until 1.10 actually hits the streets.
We're already late; that puts us into March 2006!

> ** Because the universe of developers willing and able to fix program
> crashes is determined by the architecture, but the (very small) universe
> of developers willing and able to fix the architecture has almost
> *nothing* to do with the program's usability. **
>
> <snip>
>> In the grand scheme of things (or at least the grand scheme of gnucash
>> [no pun intended]) I don't think this is a heinous architectural flaw.
>> I can certainly point out a half dozen or more significantly more
>> heinous archictectural flaws in gnucash.
>
> I would agree.

Then why spend time on it _now_?  I'm not saying not to spend time on
it.  I'm just saying that it shouldn't be a priority _now_.  Help us
get g2 out the door so we can ensure gnucash's survival.  _THEN_ feel
free to really start ripping away.

Have you ever worked in a ground-up startup?  I mean REALLY ground up?
Where it was you and one or two other guys trying to make the business
happen?  Where you've got $100,000 and you need to make that last
until you've got a product?  In that environment you can't waste time
rewriting working code to build something you don't need until
two-years down the road; you need to work on getting the product
shipped, which means hacking on the non-working code.  Rewrites can
wait until you get the product shipped and you get the next round of
funding.

This is where I feel gnucash is _right now_.  Sure, I am _thinking_
about where I want gnucash to be in 36 months..  But I'm worrying
about where gnucash will be in 6-12, because no g2 release in that
timeframe means no gnucash.

> I think that should be *somebody's* #1 concern.  But I also think, for
> the reasons above, that if that's *everybody's* #1 concern, then in 12
> months, GC will still have the equivalent of < 1 full-time developer,
> and it will be obsoleted within another 18-24 months.

Gnucash is a team effort, even if it's only loosely associated.  We
have to work together to get gnucash out the door.  We have to make
forward progress, not continually re-working everyone's steps.

> I think *somebody's* #1 concern should be making the architectural
> changes that will attract more developers.  I know you're said that
> you don't really care about attracting new developers, and that we
> have a few really good devs now.  Nevertheless, IMO, attracting more
> devs is essential to GC's survival.

I care about attracting developers who can work within the gnucash
framework.  I don't care about major gnucash restructuring just to
attract new developers.  Restructuring and rearchitecting because it's
the right thing to do is certainly warranted... When the time is
right.

Right now is not that time.  I've even given up on my qif-importer
re-write because I think it's more important to finish the g2 port
than the finish the re-write.  Why?  What's there _works_.  Yes, there
are some bugs.  Yes, it's hard to maintain.  Yes, it NEEDS to be
re-written...  But it's more important to COMPLETE THE TASK and get g2
out the door.

Gnucash's survival is not hinged on whether the qif importer is
re-written, or if the gtk/cm interaction is architecturally "pure".
It's purely hinged on getting g2 released.

We _ARE_ that small startup, trying to get that product out the door
in order to get more funding.  (Well, there's no funding here, but the
analogy still holds if you equate time with money ;)

After 1.8 was released we had a lot of time on our hands to ponder
major changes.  QOF, for example, was a major rearchitecting of the
engine, and IMHO a fairly decent step forward.  But _now_ is not the
time to create a new QOF.  Now is the time to get g2 out the door.
Once g2 is released, once we have 1.10.0 in the hands of the people...
THEN will it be time for you to go off and create your masterpiece,
create the next QOF.

I applaud your effort to fix that.  I even encourage it, but not right
now.  I ask that you hold that energy until we get g2 out the door.  I
implore upon you to help us get g2 out the door; after g2 is released
I encourage you to run free and wild rebuilding whatever floats your
boat!

> I also recognize that my prioritization is a minority view, but I
> don't think it's necessarily bad that different devs have different
> priorities.

I agree, but I think it's bad right now that devs aren't concerned
about getting g2 out the door.  At least it feels to me that you don't
care about getting g2 released.  Please tell me I'm wrong!  But it
sounds like you'd rather rebuild working code now than wait until
after g2 to re-work it.

>> Assuming you answer "yes" to my final question (and I really hope you
>> DO answer "yes")...  
>
> Was that a qualified "yes"?  :)
>
>> what do you feel are the steps necessary to get
>> the g2 port "finished" and out the door?  What do YOU think is missing
>> or still needs to be done before it's ready to package up and pass on
>> to users?
>
> I don't know.  As a user, the register misbehavior really bothers me.
> As a dev, the register code insanity bothers me even more.  :)

Oh, I agree..  I'd LOVE to see the register re-written, and lots of
other code fixed, cleaned up, or rearchitected.  But again, I think
that's an "after the first g2 release" task.  It's better to spend a
couple days to get what's there now working and get g2 out sooner,
than spend a month rewriting and push out the release.  If we do that
for every bug in the database we'll never finish.

The more we push out the release, the closer we are to being
irrelevant.

> -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

Josh Sled
On Tue, 2005-06-07 at 09:54 -0400, Derek Atkins wrote:

> Then why spend time on it _now_?  I'm not saying not to spend time on
> it.  I'm just saying that it shouldn't be a priority _now_.  Help us
> get g2 out the door so we can ensure gnucash's survival.  _THEN_ feel
> free to really start ripping away.

I'm in strong agreement with you, Chris ... I think some major changes
and simplifications are needed to make GnuCash and it's developers more
nimble, and to attract more patches and active devs.

I'm also in strong agreement with Derek, here.  The _biggest_ change we
need to make right now ... the single most important thing that will
make it impossible to attract users, let alone devs, is the dependency
on gtk/gnome1.

It only complicates things to make any other changes before the G2 port
and the next release, especially now that the G2 port is as far along as
it is.

Personally, I'd be willing to forgo all the in-dev code (book-closing,
lots, budgeting and DB-backend) in order to get the next release out the
door, in order to unblock starting those other changes.

...jsled

--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
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
Quoting Josh Sled <[hidden email]>:

> Personally, I'd be willing to forgo all the in-dev code (book-closing,
> lots, budgeting and DB-backend) in order to get the next release out the
> door, in order to unblock starting those other changes.

I've already given up on the DB backend for the first g2 release..  I think
book-closing is already there, but I'm not sure.  I also think lots are there,
but I'm not sure, either.  Budgetting I'm willing to forego, but I'm also
willing to get it in if that finishes "on time".

-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
In reply to this post by Derek Atkins

It sounds like we agree there's a problem.  But we disagree somewhat
on the analysis of the problem, and therefore the solution.

On Tue, Jun 07, 2005 at 09:54:48AM -0400, Derek Atkins wrote:

> Chris,
>
> Chris Shoemaker <[hidden email]> writes:
>
> >> Which do you think is more beneficial to the project in the next six
> >> months:
> >>
> >> a) Taking a piece of code that might be architecturally questionable
> >>    but doesn't crash, doesn't corrupt data, and doesn't cause any
> >>    visual problems and spend time to fix the architecture and rototill
> >>    the code to change how it works?
> >>
> >>  or
> >>
> >> b) Take some code that causes the program to crash, corrupts data, or
> >>    visually misbehaves and spend the time to fix those issues?
> >
> >         I honestly don't know.  I know the question was rhetorical,
> > but I think the answer really depends on many factors.  IMO, having a
> > g2 port that works as well and 1.x, but is equally (un)maintainable is
> > only of _marginal_ benefit.  (And I'm not sure even 6 months will find
> > us there.)  IMO, 95% of the benefit of the g2 port is the potential
> > for improving maintainability.  ** That benefit is not realized by the
> > quickest fixes, but by the design fixes. **
>
> See, I don't think it's of marginal benefit to get g2 into the hands
> of the users even if it only works as well as 1.8.  Indeed, currently
> the g2 port does NOT work as well as 1.8!  I think just getting it up
> to 1.8's level is sufficient to make users happy and extend the life
> of the project.

If it only works as well as 1.x, why are users going to be any more
pleased with g2 than 1.x?  Do you think the average user knows and
cares what libraries their acct package uses?

>
> I don't know if 6 months will find us there.  If we keep rewriting
> working code then it certainly wont.  But if we focus on actual bugs,
> so we CAN bring g2 up to the 1.8 working level, then I think it's
> possible to complete in 6 months.
>
> We've got GoG working, that was a major issue.  Now we just need to
> make sure all the dialogs work, all the signals are attached, etc.
> Sure, it sounds like busywork, but we're at the _end_ of the dev cycle
> here and that's always busywork.  Once we release we can open up to
> major restructuring.  But now is not the time to do it.
>
> >         You and I really do have very different interests regarding
> > GC.  I realize that the next 6 months are very important to you.  I'm
> > much more concerned about where GC will be in 36 months than 6.  I
> > figure, in 6 months, 1.x will still be an option.  In 36 months, it
> > won't be, and neither will g2 if it develops at anywhere near the rate
> > it has in the past 24 months.  Call me alarmist if you want, but I
> > think GC is "on the brink."  Its survival is no gaurantee.  IMO, its
> > survival depends on architectural improvements far more than fixing
> > visual misbehavior or program crashes.  Why?  
>
> Actually, I don't think you're behind alarmist enough!  I'm also
> concerned about where gnucash will be in 36 months, but if we don't
> get the g2 release out SOON I don't think there will even BE a gnucash
> in 36 months.  Gnucash has already started dropping out of distros.
> We've been out of slackware for years (I think 1.6 was packaged, but
> I'm fairly sure 1.8 never was).  We got dropped from RHEL 3.  I think
> we're in FC4 but I suspect we'll get dropped from FC5.  Debian has
> considered dropping it.  Fink has considered dropping it...
>
> Seriously, if we don't get g2 out the door _THIS YEAR_ I don't think
> there will be a gnucash in 36 months for you to primp and preen.

Ok, I think I'm starting to see where we disagree.  You think that the
survival of GC depends on maintaining *users*.  Therefore, dropping
out of distros is death because it leads to fewer users.  Therefore, a
quick g2 turn-around is #1 priority since it will keep users.  I guess
you'd say that popularity (more users) will lead to higher quality.  I
can see the reasoning, but I disagree with the premise.

I think that the survival of GC depends on maintaining (nay,
*gaining*) *developers*.  A growing user-base is an incidental
consequence of a high-quality program, which is determined by
developer labor quantity and quality, which is a function of the
condition of the code-base.

IMO, dropping out of distros is NoBigDeal.  Packages drop in and out
of distros all the time.  Being in distros is no end in itself; it's
merely an *indicator* of the real problem (which is a BigDeal) -
poorly maintained code.  I'm not so concerned about popularity
(user-base) or which distros we're in.  I think *quality* has to come
first, and if it does, users will come.

>
> Keep in mind that we also need a good 3 months after "feature freeze"
> in order to stabilize the release.  At least that's how long it took
> to get 1.8 out the door.  There was a good 3 months of bi-weekly
> releases to get alpha tested, build tested, and into user's hands.  So
> even if we think it'll be another 6 months of developer work to
> "finish" g2, that means 9 months until 1.10 actually hits the streets.
> We're already late; that puts us into March 2006!

Which is after FC5, isn't it?

>
> > ** Because the universe of developers willing and able to fix program
> > crashes is determined by the architecture, but the (very small) universe
> > of developers willing and able to fix the architecture has almost
> > *nothing* to do with the program's usability. **

Did you have any thoughts about this?  This is kind of central to my thesis.

> >
> > <snip>
> >> In the grand scheme of things (or at least the grand scheme of gnucash
> >> [no pun intended]) I don't think this is a heinous architectural flaw.
> >> I can certainly point out a half dozen or more significantly more
> >> heinous archictectural flaws in gnucash.
> >
> > I would agree.
>
> Then why spend time on it _now_?  I'm not saying not to spend time on
> it.  I'm just saying that it shouldn't be a priority _now_.  Help us
> get g2 out the door so we can ensure gnucash's survival.  _THEN_ feel
> free to really start ripping away.
>
> Have you ever worked in a ground-up startup?  I mean REALLY ground up?
> Where it was you and one or two other guys trying to make the business
> happen?  Where you've got $100,000 and you need to make that last
> until you've got a product?  In that environment you can't waste time
> rewriting working code to build something you don't need until
> two-years down the road; you need to work on getting the product
> shipped, which means hacking on the non-working code.  Rewrites can
> wait until you get the product shipped and you get the next round of
> funding.


I think your analogy breaks down at one crucial point.  In that
environment, time-to-market is more important because of its influence
on market-share via mind-share.

The *linux* app. market is not so much like that.  Market-share
follows quality much more closely than time-to-market.  Look at how
quick we are to abandon the tried-and-true when the new program is a
little nicer.

>
> This is where I feel gnucash is _right now_.  Sure, I am _thinking_
> about where I want gnucash to be in 36 months..  But I'm worrying
> about where gnucash will be in 6-12, because no g2 release in that
> timeframe means no gnucash.

I'm not sure about that last sentence.  Say 1.x was EOL'ed, and g2
wasn't ready yet.  Does that mean no gnucash?  Not necessarily in an
ultimate sense.  You could consider g2 as a "new release" of a new
program.  The fact that there wouldn't be any maintained,
production-ready gnucash in the interim would be regrettable, but I
don't think it would necessarily mean the end for the code-base.

>
> > I think that should be *somebody's* #1 concern.  But I also think, for
> > the reasons above, that if that's *everybody's* #1 concern, then in 12
> > months, GC will still have the equivalent of < 1 full-time developer,
> > and it will be obsoleted within another 18-24 months.
>
> Gnucash is a team effort, even if it's only loosely associated.  We
> have to work together to get gnucash out the door.  We have to make
> forward progress, not continually re-working everyone's steps.
>
> > I think *somebody's* #1 concern should be making the architectural
> > changes that will attract more developers.  I know you're said that
> > you don't really care about attracting new developers, and that we
> > have a few really good devs now.  Nevertheless, IMO, attracting more
> > devs is essential to GC's survival.
>
> I care about attracting developers who can work within the gnucash
> framework.  I don't care about major gnucash restructuring just to
> attract new developers.  Restructuring and rearchitecting because it's
> the right thing to do is certainly warranted... When the time is
> right.

Hypothetically, if in 3 months, g2 was stable, feature equal to 1.x,
but had no major code-restructure, do you think that new developers
would suddenly be attracted to GC?  I don't think so.  

>
> Right now is not that time.  I've even given up on my qif-importer
> re-write because I think it's more important to finish the g2 port
> than the finish the re-write.  Why?  What's there _works_.  Yes, there
> are some bugs.  Yes, it's hard to maintain.  Yes, it NEEDS to be
> re-written...  But it's more important to COMPLETE THE TASK and get g2
> out the door.
>
> Gnucash's survival is not hinged on whether the qif importer is
> re-written, or if the gtk/cm interaction is architecturally "pure".
> It's purely hinged on getting g2 released.

Ok, yes, you clearly believe that GC's survival depends on releasing
g2.  But why?  It gets more users?

>
> We _ARE_ that small startup, trying to get that product out the door
> in order to get more funding.  (Well, there's no funding here, but the
> analogy still holds if you equate time with money ;)

Releasing g2 gets us more time?  We don't need time -- we need
developers.

>
> After 1.8 was released we had a lot of time on our hands to ponder
> major changes.  QOF, for example, was a major rearchitecting of the
> engine, and IMHO a fairly decent step forward.  But _now_ is not the
> time to create a new QOF.  Now is the time to get g2 out the door.
> Once g2 is released, once we have 1.10.0 in the hands of the people...
> THEN will it be time for you to go off and create your masterpiece,
> create the next QOF.
>
> I applaud your effort to fix that.  I even encourage it, but not right
> now.  I ask that you hold that energy until we get g2 out the door.  I
> implore upon you to help us get g2 out the door; after g2 is released
> I encourage you to run free and wild rebuilding whatever floats your
> boat!
>
> > I also recognize that my prioritization is a minority view, but I
> > don't think it's necessarily bad that different devs have different
> > priorities.
>
> I agree, but I think it's bad right now that devs aren't concerned
> about getting g2 out the door.  At least it feels to me that you don't
> care about getting g2 released.  Please tell me I'm wrong!  But it
> sounds like you'd rather rebuild working code now than wait until
> after g2 to re-work it.

I'm sorry I can't tell you what you want to hear.  IMO, attracting
devs is more important than releasing g2.  As for cause and effect,
the former can cause the latter, but the latter will not help the
former.

>
> >> Assuming you answer "yes" to my final question (and I really hope you
> >> DO answer "yes")...  
> >
> > Was that a qualified "yes"?  :)
> >
> >> what do you feel are the steps necessary to get
> >> the g2 port "finished" and out the door?  What do YOU think is missing
> >> or still needs to be done before it's ready to package up and pass on
> >> to users?
> >
> > I don't know.  As a user, the register misbehavior really bothers me.
> > As a dev, the register code insanity bothers me even more.  :)

Just a clarification about *why* the code bothers me more than the
GUI: When I see the register misbehave, I think "Well, I guess I can't
use this for data-entry *right*now*."  When I see the code, I think
"Yikes!  There's a very real possibility this code will *never* be
fixed.  Its complexity may already exceed its value."

>
> Oh, I agree..  I'd LOVE to see the register re-written, and lots of
> other code fixed, cleaned up, or rearchitected.  But again, I think
> that's an "after the first g2 release" task.  It's better to spend a
> couple days to get what's there now working and get g2 out sooner,
> than spend a month rewriting and push out the release.  If we do that
> for every bug in the database we'll never finish.
>
> The more we push out the release, the closer we are to being
> irrelevant.
>
> > -chris
>
> -derek
>
-chris
_______________________________________________
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
In reply to this post by Derek Atkins
On Tue, Jun 07, 2005 at 10:22:53AM -0400, Derek Atkins wrote:

> Quoting Josh Sled <[hidden email]>:
>
> > Personally, I'd be willing to forgo all the in-dev code (book-closing,
> > lots, budgeting and DB-backend) in order to get the next release out the
> > door, in order to unblock starting those other changes.
>
> I've already given up on the DB backend for the first g2 release..  I think
> book-closing is already there, but I'm not sure.  I also think lots are there,
> but I'm not sure, either.  Budgetting I'm willing to forego, but I'm also
> willing to get it in if that finishes "on time".

Regarding Budgeting: I've been pretty pleased with the state of my
patchset for a couple months now.  The budget system seems stable and
doesn't seem to be missing any essential features.  I'd been holding
off pushing them because they involve more "rearchitecting" than I
think you're comfortable with.  E.g.  Recurrences are intended to
be a much simpler replacement for FreqSpec.

If you'd like, I can email the patchset to -patches.

One TODO is that I haven't looked into what's necessary to make
budgets work with qof-merge stuff.

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).

-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

Josh Sled
In reply to this post by Chris Shoemaker
On Tue, 2005-06-07 at 11:18 -0400, Chris Shoemaker wrote:

> If it only works as well as 1.x, why are users going to be any more
> pleased with g2 than 1.x?  Do you think the average user knows and
> cares what libraries their acct package uses?

No, but they do care that they can package-management-install it and get
it up and running in a spare evening.  That capability is being
threatened.


> I think that the survival of GC depends on maintaining (nay,
> *gaining*) *developers*.  A growing user-base is an incidental
> consequence of a high-quality program, which is determined by
> developer labor quantity and quality, which is a function of the
> condition of the code-base.

The best developers are those that are users, and decide to "upgrade" to
being devs ... either with a small patch or more active development
involvement.


> I'm sorry I can't tell you what you want to hear.  IMO, attracting
> devs is more important than releasing g2.  As for cause and effect,
> the former can cause the latter, but the latter will not help the
> former.

Attracting more devs is more important than releasing G2, but releasing
G2 will allow a larger user-base, which *will* attract more devs.
They're both important.

But with respect to "major architectural changes", the largest and
highest-value one to be made right now is dropping the gnome1
dependencies.  Moreover, since we've already started doing it, we should
_finish_ it before starting new projects to prevent cross-contamination.
More moreover, we *can* do another release without any new features, but
*not* without finishing the G2 port.

...jsled

--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
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

Dan Widyono
In reply to this post by Chris Shoemaker
> If it only works as well as 1.x, why are users going to be any more
> pleased with g2 than 1.x?  Do you think the average user knows and
> cares what libraries their acct package uses?

No, but they care what libraries are included with their plug-and-play
distribution (where said distro's maintainers *do* care what libs are used by
whatever acct package they choose to support).  If said distro decides to
stop supporting gnome1, gc is gone also unless there's a new gc version which
doesn't require gnome1.

> Ok, I think I'm starting to see where we disagree.  You think that the
> survival of GC depends on maintaining *users*.

I believe they're also talking about developers.  I, for one, would like to
see a stable, used version of g2 out there, such that my coding (if I could
program worth a damn) would continue to be used, seen, and therefore tested
by current users.

> The *linux* app. market is not so much like that.  Market-share
> follows quality much more closely than time-to-market.  Look at how
> quick we are to abandon the tried-and-true when the new program is a
> little nicer.

This does not match what I hear from regular users (non-computer-savvy).
They follow whatever their distro vendor provides for the most part.  "The
distro doesn't have an accounting package?  Woops, I can't use Linux then.
Back to Windows."

Dan W.
_______________________________________________
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

Christian Stimming
In reply to this post by Chris Shoemaker
Chris Shoemaker schrieb:

>>I agree, but I think it's bad right now that devs aren't concerned
>>about getting g2 out the door.  At least it feels to me that you don't
>>care about getting g2 released.  Please tell me I'm wrong!  But it
>>sounds like you'd rather rebuild working code now than wait until
>>after g2 to re-work it.
>
> I'm sorry I can't tell you what you want to hear.  IMO, attracting
> devs is more important than releasing g2.  As for cause and effect,
> the former can cause the latter, but the latter will not help the
> former.

We've really seen many different seasons of developers that get
attracted and leave again. IMHO it really doesn't depend much on the
internal code quality. Instead, the question should be whether a
developer can *quickly* start with "scratching his itch" (instead of
cleaning up other bit-rotted code), and that depends much more on
up-to-date GUI library dependencies as it does on internal design
patterns that aren't touched by 90% of the new developers anyway.

Now I can surely understand your priorities here, if scratching _your_
personal itch unfortunately means you have to deal with some of the
worse portions of the gnucash code. However, in the overall project we
have to remember the respect for each other's working areas, namely not
to break the other's areas only because you're right into your own
project. There would need to be a large consensus that these fundamental
changes would help for the overall project *right now*. It seems this
consensus is not there for some of your proposed changes -- which, as I
fully understand, doesn't make you happy.

However, I fully support the priority of getting G2 up and running,
because that's really becoming more and more vital -- any of those
hypothetical "more developers" really expect an (almost) up-to-date GUI
library or they won't come here in the first place. Our competitor
KMyMoney is catching up quite quickly, and they fully benefit from their
choice of GUI toolkit. In other words, quite soon a developer with some
"personal itch" will have the free choice in terms of existing features
between gnucash and kmymoney, and if gnucash at that time will still be
stuck in five-year-old GUI dependencies, then most probably a developer
will just pick the other project and happily use their qt3/kde
dependencies. It's really not all the internal code, but it's the whole
context of the internal code *plus* the necessary dependencies.

Go G2 go!

(I'll probably join again on the coding side after my LinuxTag talk end
of June... or maybe some "more developers" get attracted to the project
because of the talk... :-)

Christian
_______________________________________________
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

Herbert Thoma
In reply to this post by Chris Shoemaker
Chris Shoemaker wrote:
<...>

>>See, I don't think it's of marginal benefit to get g2 into the hands
>>of the users even if it only works as well as 1.8.  Indeed, currently
>>the g2 port does NOT work as well as 1.8!  I think just getting it up
>>to 1.8's level is sufficient to make users happy and extend the life
>>of the project.
>
>
> If it only works as well as 1.x, why are users going to be any more
> pleased with g2 than 1.x?  Do you think the average user knows and
> cares what libraries their acct package uses?
>

Speaking as a user: Yes, I don't care which libs CnuCash depends on.
I have some 5 years of finacial data in my datafile and I want an
application to maintain it. I personally even don't care if GnuCash
is packaged in my distribution because I compile from cvs anyway.

Speaking as a developer: Not only GnuCash bitrots, gnome1 bitrots, too.
Guppi is not part of SUSE and it is annoying to build that myself (And
it gets more complicated with each new version of SUSE ...). Distros
may drop more vital parts of gnome1 or may drop gnome1 alltogether.
I am pretty sure that you won't attract new developers if they have
to build an entire ancient version of gnome first regardless how
nice and clean the architecture is ...

  Herbert.
--
Herbert Thoma
Group Manager Video
Multimedia Realtime Systems Department
Fraunhofer IIS
Am Wolfsmantel 33, 91058 Erlangen, Germany
Phone: +49-9131-776-323
Fax:   +49-9131-776-399
email: [hidden email]
www: http://www.iis.fhg.de/
_______________________________________________
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
In reply to this post by Josh Sled
On Tue, Jun 07, 2005 at 11:39:08AM -0400, Josh Sled wrote:
> On Tue, 2005-06-07 at 11:18 -0400, Chris Shoemaker wrote:
>
> > If it only works as well as 1.x, why are users going to be any more
> > pleased with g2 than 1.x?  Do you think the average user knows and
> > cares what libraries their acct package uses?
>
> No, but they do care that they can package-management-install it and get
> it up and running in a spare evening.  That capability is being
> threatened.

Good point.  Users will be annoyed if GC becomes more difficult to
install.

>
>
> > I think that the survival of GC depends on maintaining (nay,
> > *gaining*) *developers*.  A growing user-base is an incidental
> > consequence of a high-quality program, which is determined by
> > developer labor quantity and quality, which is a function of the
> > condition of the code-base.
>
> The best developers are those that are users, and decide to "upgrade" to
> being devs ... either with a small patch or more active development
> involvement.
>
>
> > I'm sorry I can't tell you what you want to hear.  IMO, attracting
> > devs is more important than releasing g2.  As for cause and effect,
> > the former can cause the latter, but the latter will not help the
> > former.
>
> Attracting more devs is more important than releasing G2, but releasing
> G2 will allow a larger user-base, which *will* attract more devs.
> They're both important.

I agree that they're both important and I agree that a larger
user-base leads to more *potential* developers.  However, I think that
the number of developers that successfully grok the code-base and make
non-trivial contributions, is NOT LINEARLY CORRELATED with the number
of would-be users-turned-dev who check-out the CVS to see if they can
scratch their itch.  Therefore, I don't believe releasing g2 will
increase devs of the first type.  Instead, I believe the number of
would-be users-turned-dev who become contributing devs is directly
correlated with the ease of grokking the code-base.


Basically I'm saying: what's the problem with GC now?  It's not lack
of popularity; it's not lack of users; it's not absence from distros.
It's lack of devs, which is, I believe, caused by the complexity of
the code-base.  Releasing G2 would be great, but after releasing G2,
the answer to the question "Ok, what's the problem with GC, *now*?"
would be exactly the same.  And so would the solution.

>
> But with respect to "major architectural changes", the largest and
> highest-value one to be made right now is dropping the gnome1
> dependencies.  Moreover, since we've already started doing it, we should
> _finish_ it before starting new projects to prevent cross-contamination.
> More moreover, we *can* do another release without any new features, but
> *not* without finishing the G2 port.

Just FTR, I think new features are pretty low on the priority list.

-chris
_______________________________________________
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
In reply to this post by Christian Stimming
On Tue, Jun 07, 2005 at 05:49:19PM +0200, Christian Stimming wrote:

> Chris Shoemaker schrieb:
> >>I agree, but I think it's bad right now that devs aren't concerned
> >>about getting g2 out the door.  At least it feels to me that you don't
> >>care about getting g2 released.  Please tell me I'm wrong!  But it
> >>sounds like you'd rather rebuild working code now than wait until
> >>after g2 to re-work it.
> >
> >I'm sorry I can't tell you what you want to hear.  IMO, attracting
> >devs is more important than releasing g2.  As for cause and effect,
> >the former can cause the latter, but the latter will not help the
> >former.
>
> We've really seen many different seasons of developers that get
> attracted and leave again. IMHO it really doesn't depend much on the
> internal code quality. Instead, the question should be whether a
> developer can *quickly* start with "scratching his itch" (instead of
> cleaning up other bit-rotted code), and that depends much more on
> up-to-date GUI library dependencies as it does on internal design
> patterns that aren't touched by 90% of the new developers anyway.

Really?!  I think you're exactly right about the question being how
quickly the itch can be scratched.

But, in my experience, I don't think GUI dependence on gtk1 instead of
gtk2 slowed me down much, if at all.  OTOH, understanding the options
system well enough to make a report options dialog offer a selection
of existing budgets took me, oh, an embarrassingly long time. :-)

>
> Now I can surely understand your priorities here, if scratching _your_
> personal itch unfortunately means you have to deal with some of the
> worse portions of the gnucash code. However, in the overall project we
> have to remember the respect for each other's working areas, namely not
> to break the other's areas only because you're right into your own
> project. There would need to be a large consensus that these fundamental
> changes would help for the overall project *right now*. It seems this
> consensus is not there for some of your proposed changes -- which, as I
> fully understand, doesn't make you happy.

Just FTR, I certainly don't advocate anything that would impede
other's progress toward releasing g2.  The lack of consensus about the
best course of action doesn't really bother me as much as it might
sound like.  I'm not trying to convince anyone to abandon releasing g2
as their highest priority.  I'd love to see a stable g2 released --
it's a worthy goal.  I'm just explaining why that's not *my* highest
priority.

>
> However, I fully support the priority of getting G2 up and running,
> because that's really becoming more and more vital -- any of those
> hypothetical "more developers" really expect an (almost) up-to-date GUI
> library or they won't come here in the first place. Our competitor
> KMyMoney is catching up quite quickly, and they fully benefit from their
> choice of GUI toolkit. In other words, quite soon a developer with some
> "personal itch" will have the free choice in terms of existing features
> between gnucash and kmymoney, and if gnucash at that time will still be
> stuck in five-year-old GUI dependencies, then most probably a developer
> will just pick the other project and happily use their qt3/kde
> dependencies. It's really not all the internal code, but it's the whole
> context of the internal code *plus* the necessary dependencies.
>
> Go G2 go!

Amen!

-chris
_______________________________________________
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

Andrew Sackville-West
In reply to this post by Dan Widyono

I've been lurking in this conversation as its very muchout of my world,
though very interesting... my .02 below...

Dan Widyono wrote:
>>I  <<snip>>
>
> This does not match what I hear from regular users (non-computer-savvy).
> They follow whatever their distro vendor provides for the most part.  "The
> distro doesn't have an accounting package?  Woops, I can't use Linux then.
> Back to Windows."

I am a fairly computer savvy user in that I've coded in the past, have
some understanding of how computers really work and use computers
instead of being used by them. So. I stayed out of linux for at least 5
years because I hadn't run across gnucash or any other accounting
package that was useable for my business. So yes, a lot of regular users
need a package like this, they need it to work, and if its dropped from
distros, they will stay away. IMHO.

Andrew
>
> Dan W.
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
123