Re: my status

[John Darrington]

OK.  My turn:

1. I'm currently looking at extending system files to read/write string
   variables upto 32767 bytes in length, a la SPSS v13/v14.

2. I'll also change the #includes to use explicit paths.

3. When Ben's checked in the error code, I'll look at the gui
   again. Hopefully get the data sheet working with arbitrary length
   casefiles. Ben, some time ago, we discussed a case_reader_clone
   function in the context of implementing RANK.  I think the gui will
   require something similar.  Is this something simple to implement?

4. Might look at RANK again, and then the way will be clear to do
   NPAR.  Also the percentiles implementation in FREQUENCIES and
   EXAMINE could do with attention,  the current implementation is
   particularly nasty.

5. Might have a look at GLM, if Jason doesn't get there first.


I too have got heaps of other deadlines and reponsibilities
..... can't say if any of the above will be completed within finite
time ......

J'


On Sun, Mar 12, 2006 at 07:57:44PM -0800, Ben Pfaff wrote:
     So... I was working on improved error handling.  I am still
     working on this.  Improvement will be major, I hope, when I check
     in the changes.  First, error reporting and error display will be
     separated.  In particular, calling msg() will just assemble the
     message into an error structure, which is then passed to the user
     interface code via function pointer.  Thus, the two UIs can
     display errors in completely different ways while retaining a
     common, convenient interface for the code that wants to report
     the error.
     
     Second, I'm separating the reporting mechanism for errors that
     originate in different ways.  Syntax errors and data errors (SE,
     SW, DE, DW) will continue to be reported with msg().  Other
     errors (IE, IW, etc.) will change to being reported with error()
     or error_at_line().  This is an important change because it lets
     us do something I've wanted to do for a long time: route errors
     and warnings into the listing file (as well as to the console).
     Currently that doesn't work because writing output can cause an
     error in the output driver, which would call msg(), which would
     try to writing output, etc.  There are other solutions but this
     seems particularly clean in multiple ways.
     
     Third, I'm going to improve the way that errors are displayed.
     I want to make it something more like gcc's, so that a typical
     error would look a bit like this:
     
             While reading file included from foo.pspp,
                                included from bar.pspp:
             quux.pspp:123: parsing DESCRIPTIVES procedure:
             quux.pspp:123: Z-score variable name XYZ would be a duplicate name.
     
     In the meantime I've been busy with paper deadlines, and I've
     become distracted with other issues.  In particular, I've been
     thinking about internationalization.  I've been reworking the
     PostScript driver to better support i18n, and I've been thinking
     about how to better support it in PSPP in general.  I'll likely
     check in a new PostScript driver that does a better job, but it's
     hard to say when.  I've been reading the Unicode standard and
     documentation from Adobe and others, trying to learn as much as I
     can about these issues.
     -- 
     Ben Pfaff 
     email: address@hidden
     web: http://benpfaff.org
     
     
     _______________________________________________
     pspp-dev mailing list
     address@hidden
     http://lists.gnu.org/mailman/listinfo/pspp-dev

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature