Avogadro 0.6 - time for another release!

Hi,

I thnk we are well past due for a new release. I also think we have added far
too many new features between releases and our next release should be
numbered 0.6 to signify that we are certainly approaching a stable and very
useful cross-platform molecular editor.

I just made a post about the new orbital support I got in over the weekend,
http://blog.cryos.net/archives/173-Avogadro-New-Orbital-Support-and-Gaussian-Cube-Format.html
I hope people like the screenshots, I am really pleased with it but there is
still more to do. Surface support and orbitals were two major features we
felt were lacking before we got to 1.0. I think the last big one is scripting
support to be honest.

So bearing in mind I would love to get another release out within two weeks
what do people feel we need to get in before that release? What are the major
bugs that need fixing and small features we should finish or try to
implement? I think it is important that we get wider testing of Avogadro by
making regular releases and I think bumping our version number also signifies
our rapid progress and approach of a stable release.

I propose that we release Avogadro 0.6 on 29 February as we have so few 29ths
in February. So get in your requests, file your blocker bugs and lets get a
release ready!

Thanks,

Marcus

It all sounds good.

My concern is stability. Not just crashing but functionality. Here is off the top of my head.

  • draw tool operation. Undo and redo are not at the best with replacing the whole molecule. Personally I’d like to serialize the PrimitiveList class so the selective rendering is restored in the engines when the whole molecule gets replaced.

  • surfaces and orbitals are good?

  • general bug fixes. We’ve been adding a LOT of functionality and totally pumps me up for the release but there are a LOT of open bugs. There are probably a lot that need fixing. The auto-opt tool is creating and destroying a thread at each step. Something is wrong in the code. Run it in gdb to see. Anyways this is just one example. I’m fearing there are some other similar problems.

  • do we want to move extensions to libavogadro? If we don’t I’d like to see Extensions take a text stream rather than a QMessageBox or whatever they’re taking now.

  • optimization still gives ‘nan’ values and man, that is annoying! Anyway we can fix this? This goes back to open bugs and my next point.

  • Anything that makes the molecule disappear NEEDS to be fixed before release.

But with all that said, there is nothing like a release to really expose our bugs. I’d just like to see a lot of the bugs that we have reported get fixed before a release. We need a feature freeze or make a branch again. Also, I’m not going to have time to make a windows release by that date.

As for a 1.0 I really think we need our own format. Most of it (I think) can be done using a filter on QSettings which is really what I think we should do for most of it since I’ve already implemented that for the engines. But again I need to serialize that data for the engines at some point. I haven’t thought about it too much but as always I want to reduce functions in the Engine, Tools, Extensions class.

Also, if we’re seriously thinking about maintaining ABI compatibility I am cautious to take our time because I think we have a good API but we rely so heavily on plugins (virtual functions) that those will need to be solid. I think we’re very close but its somewhat scary to say our plugin API is solid. If we’re not thinking ABI compat then I’m ok with releasing everyday.


Donald

-----Original Message-----
From: “Marcus D. Hanwell” marcus@cryos.net

Date: Tue, 19 Feb 2008 21:16:18
To:avogadro-devel@lists.sourceforge.net
Subject: [Avogadro-devel] Avogadro 0.6 - time for another release!

Hi,

I thnk we are well past due for a new release. I also think we have added far
too many new features between releases and our next release should be
numbered 0.6 to signify that we are certainly approaching a stable and very
useful cross-platform molecular editor.

I just made a post about the new orbital support I got in over the weekend,
http://blog.cryos.net/archives/173-Avogadro-New-Orbital-Support-and-Gaussian-Cube-Format.html
I hope people like the screenshots, I am really pleased with it but there is
still more to do. Surface support and orbitals were two major features we
felt were lacking before we got to 1.0. I think the last big one is scripting
support to be honest.

So bearing in mind I would love to get another release out within two weeks
what do people feel we need to get in before that release? What are the major
bugs that need fixing and small features we should finish or try to
implement? I think it is important that we get wider testing of Avogadro by
making regular releases and I think bumping our version number also signifies
our rapid progress and approach of a stable release.

I propose that we release Avogadro 0.6 on 29 February as we have so few 29ths
in February. So get in your requests, file your blocker bugs and lets get a
release ready!

Thanks,

Marcus


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

My concern is stability. Not just crashing but functionality.
Here is off the top of my head.

Well, this is certainly a good point. We’re reaching a point where we
do want to discuss “polish,” which definitely includes bug-fixing.

  • draw tool operation.

I’m thrilled that we have the auto-add hydrogens finished. I think
it’s got a bunch of bugs still. If you find something, please report it.

  • do we want to move extensions to libavogadro? If we don’t I’d
    like to see Extensions take a text stream rather than a QMessageBox
    or whatever they’re taking now.

Let’s mark that for a 1.0 issue. My vote is to move some extensions to
libavogadro.

  • optimization still gives ‘nan’ values and man, that is annoying!
    Anyway we can fix this? This goes back to open bugs and my next
    point.

This is an Open Babel issue. I just committed a fix to the optimizer
that absolutely positively prevents ‘nan’ values. (i.e., it only
accepts numbers which meet isfinite() – no infinity, no NaN).

If you find anything which causes a molecule to disappear, please
report a bug immediately to me. But make sure you’re running SVN trunk
of Open Babel first.

Also, I’m not going to have time to make a windows release by that
date.

Can you itemize exactly what you do to build on Windows? Then someone
else can pick up the build.

As for a 1.0…

Personally, I’d rather table discussion on “1.0” for now. (I’d mention
some user interface issues.) Let’s get some bugs fixed and get what
we’ve got out the door. At that point, we can definitely figure out
what, when, how, … for a full 1.0 release. I think we’re very close.

Cheers,
-Geoff

Moin

I couldn’t agree more. I will update OpenBabel tomorrow and test Avogadro on two machines. I tested yesterday and it seems the last crash I reported has been fixed. At least I was unable to crash Avo yesterday.

I presented Avogadro 0.2.0 to some colleagues and they really liked Avgadro. I also demoed some 0.3/0.6 stuff. Especially the molecule contruction feature and the rich database of .cml files (chem-file.sf.net) are big things for chemistry teachers.
One negative feedback was that it is way to difficult to find the installer for Avogadro on our homepage. They told me we need a big button with “Download Avogadro” on it at the toppage of our Wiki.

Carsten

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Moin

Also, I’m not going to have time to make a windows release by that
date.

Can you itemize exactly what you do to build on Windows? Then someone
else can pick up the build.

As I now have a Windows Vista machine I could do that. Only problem: I have no clue how to do it.

There is no shell on Windows, so I guess I need some kind of grafical UI for gcc like DevC++? I didn’t touch Windows for several years and only once compiled something using DevC++ and wxWidgets. So if you are giving me pointer how to do it I will try.

Carsten

GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

There are directions on the wiki for building in Windows as I think
someone else was considering working on the Windows build:

http://avogadro.sourceforge.net/wiki/Building:Development_Version#Windows_Visual_Studio_2005

(Wed, Feb 20, 2008 at 08:45:37AM +0100) Carsten Niehaus CNiehaus@gmx.de:

Moin

Also, I’m not going to have time to make a windows release by that
date.

Can you itemize exactly what you do to build on Windows? Then someone
else can pick up the build.

As I now have a Windows Vista machine I could do that. Only problem: I have no clue how to do it.

There is no shell on Windows, so I guess I need some kind of grafical UI for gcc like DevC++? I didn’t touch Windows for several years and only once compiled something using DevC++ and wxWidgets. So if you are giving me pointer how to do it I will try.

Carsten

GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

On Tuesday 19 February 2008 23:17:09 Donald Ephraim Curtis wrote:

It all sounds good.

My concern is stability. Not just crashing but functionality. Here is
off the top of my head.

  • surfaces and orbitals are good?

I think we have worked out most of the kinks, there are still some
improvements I want to get in but I figured that a week and a half would give
us time to get those in.

  • general bug fixes. We’ve been adding a LOT of functionality and totally
    pumps me up for the release but there are a LOT of open bugs. There are
    probably a lot that need fixing. The auto-opt tool is creating and
    destroying a thread at each step. Something is wrong in the code. Run it in
    gdb to see. Anyways this is just one example. I’m fearing there are some
    other similar problems.

I will be working on getting our bug count down and I think a release will
help to focus people on getting the bugs squashed. I think we are in good
shape for a release and it will be good to get wider testing. We could always
do a bug fix release afterwards - it would be good to start doing that a
little more and may be increase the frequency of the releases we make.

  • do we want to move extensions to libavogadro? If we don’t I’d like to
    see Extensions take a text stream rather than a QMessageBox or whatever
    they’re taking now.

I think it would be good to move them but I also think that could wait until
after our next release.

  • Anything that makes the molecule disappear NEEDS to be fixed before
    release.

I think we are getting a lot better there but we will certainly have to track
these issues down and fix them.

But with all that said, there is nothing like a release to really expose
our bugs. I’d just like to see a lot of the bugs that we have reported get
fixed before a release. We need a feature freeze or make a branch again.
Also, I’m not going to have time to make a windows release by that date.

I am sure we will be able to get something done. We have some VMs around here
too. Even if it is not built the same day we should be able to get something
out shortly afterwards.

As for a 1.0 I really think we need our own format. Most of it (I think)
can be done using a filter on QSettings which is really what I think we
should do for most of it since I’ve already implemented that for the
engines. But again I need to serialize that data for the engines at some
point. I haven’t thought about it too much but as always I want to reduce
functions in the Engine, Tools, Extensions class.

I think this is definitely going to be a good next step and there are quite a
few people I have talked to who would like to see this.

Also, if we’re seriously thinking about maintaining ABI compatibility I am
cautious to take our time because I think we have a good API but we rely so
heavily on plugins (virtual functions) that those will need to be solid. I
think we’re very close but its somewhat scary to say our plugin API is
solid. If we’re not thinking ABI compat then I’m ok with releasing
everyday.

If we want Kalzium to use libavogadro then we are going to have to maintain
ABI stability too. If necessary I could use a new internal snapshot for 4.1
aqnd port it to use that. I do agree that we need to take our time before we
lock down our API/ABI but it would be good to be able to go with the 4.1
schedule if that is feasible.

If nothing else I think we need to get another release out soon so that people
can check out the new features we have added, report bugs and test on
different systems etc.

Thanks,

Marcus

On Wed, Feb 20, 2008 at 5:17 AM, Donald Ephraim Curtis
d@milkbox.net wrote:

It all sounds good.

My concern is stability. Not just crashing but functionality. Here is off the top of my head.

  • draw tool operation. Undo and redo are not at the best with replacing the whole molecule. Personally I’d like to serialize the PrimitiveList class so the selective rendering is restored in the engines when the whole molecule gets replaced.

I tried this and it doesn’t work. You allready added the atom to the
molecule when you call AddAtomDrawCommand. So the
AddAtomDrawCommand::redo() doesn’t always create the atom. So copying
the molecule doesn’t undo the action. But we shouldn’t use indices,
it’s probably better to hold a pointer to the bond/atom itself, adding
and deleting the hydrogens causes the indices to change.

  • surfaces and orbitals are good?

The VDWSurface function still needs to move to it’s own thread.

  • general bug fixes. We’ve been adding a LOT of functionality and totally pumps me up for the release but there are a LOT of open bugs. There are probably a lot that need fixing. The auto-opt tool is creating and destroying a thread at each step. Something is wrong in the code. Run it in gdb to see. Anyways this is just one example. I’m fearing there are some other similar problems.

I’ll try to fix the AutoOpt tool. It now correctly handles cases where
the Seup() fails (used to crash), this is also displayed now.

  • do we want to move extensions to libavogadro? If we don’t I’d like to see Extensions take a text stream rather than a QMessageBox or whatever they’re taking now.

  • optimization still gives ‘nan’ values and man, that is annoying! Anyway we can fix this? This goes back to open bugs and my next point.

  • Anything that makes the molecule disappear NEEDS to be fixed before release.

But with all that said, there is nothing like a release to really expose our bugs. I’d just like to see a lot of the bugs that we have reported get fixed before a release. We need a feature freeze or make a branch again. Also, I’m not going to have time to make a windows release by that date.

As for a 1.0 I really think we need our own format. Most of it (I think) can be done using a filter on QSettings which is really what I think we should do for most of it since I’ve already implemented that for the engines. But again I need to serialize that data for the engines at some point. I haven’t thought about it too much but as always I want to reduce functions in the Engine, Tools, Extensions class.

Also, if we’re seriously thinking about maintaining ABI compatibility I am cautious to take our time because I think we have a good API but we rely so heavily on plugins (virtual functions) that those will need to be solid. I think we’re very close but its somewhat scary to say our plugin API is solid. If we’re not thinking ABI compat then I’m ok with releasing everyday.


Donald

-----Original Message-----
From: “Marcus D. Hanwell” mhanwell@gmail.com

Date: Tue, 19 Feb 2008 21:16:18
To:avogadro-devel@lists.sourceforge.net
Subject: [Avogadro-devel] Avogadro 0.6 - time for another release!

Hi,

I thnk we are well past due for a new release. I also think we have added far
too many new features between releases and our next release should be
numbered 0.6 to signify that we are certainly approaching a stable and very
useful cross-platform molecular editor.

I just made a post about the new orbital support I got in over the weekend,
http://blog.cryos.net/archives/173-Avogadro-New-Orbital-Support-and-Gaussian-Cube-Format.html
I hope people like the screenshots, I am really pleased with it but there is
still more to do. Surface support and orbitals were two major features we
felt were lacking before we got to 1.0. I think the last big one is scripting
support to be honest.

So bearing in mind I would love to get another release out within two weeks
what do people feel we need to get in before that release? What are the major
bugs that need fixing and small features we should finish or try to
implement? I think it is important that we get wider testing of Avogadro by
making regular releases and I think bumping our version number also signifies
our rapid progress and approach of a stable release.

I propose that we release Avogadro 0.6 on 29 February as we have so few 29ths
in February. So get in your requests, file your blocker bugs and lets get a
release ready!

Thanks,

Marcus


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

(Wed, Feb 20, 2008 at 08:48:08PM +0100) Tim Vandermeersch tim.vandermeersch@gmail.com:

On Wed, Feb 20, 2008 at 5:17 AM, Donald Ephraim Curtis
d@milkbox.net wrote:

It all sounds good.

My concern is stability. Not just crashing but functionality. Here is off the top of my head.

  • draw tool operation. Undo and redo are not at the best with replacing the whole molecule. Personally I’d like to serialize the PrimitiveList class so the selective rendering is restored in the engines when the whole molecule gets replaced.

I tried this and it doesn’t work. You allready added the atom to the
molecule when you call AddAtomDrawCommand. So the
AddAtomDrawCommand::redo() doesn’t always create the atom. So copying
the molecule doesn’t undo the action. But we shouldn’t use indices,
it’s probably better to hold a pointer to the bond/atom itself, adding
and deleting the hydrogens causes the indices to change.

I’m not sure of the current implementation but I understand that when
you re-adjust the hydrogens you get different index numbers. However,
when drawing atoms we can do this:

Save the engine state (serialized by indices) and copy the molecule.

Then, do everything that you did before to add the new atom and updated
the hydrogens.

On an undo we go back to the original molecule state and restore the
engine states. The only problem right now is that there is no way to
say “Engine1 has atoms 3,4,5,9,15”. We CAN do indices if we do the undo
correctly. That is, as long as after undoing, the state of the molecule
is the same as it was previously, then the serialized data should be
fine. We have to make some guarantee about states when working with
this undo/redo stuff. Undo should always take us back to the state we
were in “EXACTLY” as it was.


Donald

I think I found a better way to handle the adjust hydrogens feature,
we can give it its ow AdjustHydrogensDrawCommand, we can then sequence
it with the other commands, this way the undo/redo will work again
without problems. I’m trying this out now and let you know how far I
get.

On Wed, Feb 20, 2008 at 9:09 PM, Donald Ephraim Curtis
d@milkbox.net wrote:

(Wed, Feb 20, 2008 at 08:48:08PM +0100) Tim Vandermeersch tim.vandermeersch@gmail.com:

On Wed, Feb 20, 2008 at 5:17 AM, Donald Ephraim Curtis
d@milkbox.net wrote:

It all sounds good.

My concern is stability. Not just crashing but functionality. Here is off the top of my head.

  • draw tool operation. Undo and redo are not at the best with replacing the whole molecule. Personally I’d like to serialize the PrimitiveList class so the selective rendering is restored in the engines when the whole molecule gets replaced.

I tried this and it doesn’t work. You allready added the atom to the
molecule when you call AddAtomDrawCommand. So the
AddAtomDrawCommand::redo() doesn’t always create the atom. So copying
the molecule doesn’t undo the action. But we shouldn’t use indices,
it’s probably better to hold a pointer to the bond/atom itself, adding
and deleting the hydrogens causes the indices to change.

I’m not sure of the current implementation but I understand that when
you re-adjust the hydrogens you get different index numbers. However,
when drawing atoms we can do this:

Save the engine state (serialized by indices) and copy the molecule.

Then, do everything that you did before to add the new atom and updated
the hydrogens.

On an undo we go back to the original molecule state and restore the
engine states. The only problem right now is that there is no way to
say “Engine1 has atoms 3,4,5,9,15”. We CAN do indices if we do the undo
correctly. That is, as long as after undoing, the state of the molecule
is the same as it was previously, then the serialized data should be
fine. We have to make some guarantee about states when working with
this undo/redo stuff. Undo should always take us back to the state we
were in “EXACTLY” as it was.


Donald