gnupic@linuxhacker.org

I am always happy to get a bug report.  If you want to sponser a
hackaton, do it. 

The problem isn't knowing were the bugs are.  You only have to run the
testsuite to find them.  I also have an application note test.  It
compiles all the app notes and reports the ones that don't pass.

The problem is the hack that is required to make them work.  Some of
mpasm's features have developed over several years and are not always
consistent with the documentation.  For example, the last time I
checked, #ENDIF was a valid alias for ENDIF, but it could only appear in
column 1. #IFDEF is a valid alias for IFDEF, but can appear anywhere.  I
don't believe either alias is documented.  They are probably legacy
features. Is the different behavior intentional or a bug?

This is just one example.  There are many others.  This one was easy to
fix.  Adding all of these features will turn gpasm into serious
spaghetti code.  In the end, a large effort will be spent and I am not
sure you can argue that gpasm is "better".

I receive very few bug reports.  I am not sure why.  I have read a few
complaints on other lists, but those people never submit bug reports. 
So I have a request.  If you have a feature or bug that you need
resolved, please add it to the trackers on sourceforge.

Colin Kuskie wrote:
> 
> On Mon, May 05, 2003 at 04:15:48PM -0500, Craig Franklin wrote:
> >
> > I do get burned out on gpasm from time to time.  It's not bad, but
> > deriving requirements from mpasm is.  I think we are starting to have
> > diminishing returns with the gpasm bug fixes.  We are 95% there.  The
> > last 5% will take BIG work.
> 
> Maybe we should have a bug-fixing day, or a remote hackathon?  People
> would sit down with their favorite MPLAB reference, see how it works
> in gpasm versus MPLAB, and post the results with:
> 
> 0) Is there a difference?
> 1) Does the difference matter?
> 2) Does the difference make gpasm better than MPLAB?
> 3) Does the difference make gpasm worse  than MPLAB?
> 
> and optional patches.
> 
> Colin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@linuxhacker.org
> For additional commands, e-mail: gnupic-help@linuxhacker.org