#631 closed defect (fixed)
pslib <-> SDRS API convergance
| Reported by: | jhoblitt | Owned by: | |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | types | Version: | 0.9.0 |
| Severity: | blocker | Keywords: | |
| Cc: |
Description
I'd like to start this process by fixing the low hanging fruit first:
psFitsMoveLast [ inconsistent ]
spec :
bool psFitsMoveLast(
psFits * fits);
code :
bool psFitsMoveLast(
const psFits * fits);
The HDU cursor is being moved so this really shouldn't be a constant
psFitsUpdateImage [ inconsistent ]
spec :
bool psFitsUpdateImage(
psFits * fits,
const psImage * input,
int x0,
int y0,
int z);
code :
bool psFitsUpdateImage(
psFits * fits,
const psImage * input,
psRegion region,
int z);
psRegion is overkill here.
psImageSlice [ inconsistent ]
psVector *psImageSlice(
psVector * out,
psPixels * coords,
const psImage * input,
const psImage * mask,
psMaskType maskVal,
psRegion region,
psImageCutDirection direction,
const psStats * stats);
code :
psVector *psImageSlice(
psVector * out,
psVector * coords,
const psImage * input,
const psImage * mask,
psMaskType maskVal,
psRegion region,
psImageCutDirection direction,
const psStats * stats);
cords should be of type psPixels
psImageTransform [ inconsistent ]
spec :
psImage *psImageTransform(
psImage * output,
psPixels blankPixels,
const psImage * input,
const psImage * inputMask,
psMaskType inputMaskVal,
const psPlaneTransform * outToIn,
psRegion region,
const psPixels * pixels,
psImageInterpolateMode mode,
double exposedValue);
code :
psImage *psImageTransform(
psImage * output,
psArray * blankPixels,
const psImage * input,
const psImage * inputMask,
psMaskType inputMaskVal,
const psPlaneTransform * outToIn,
psRegion region,
const psPixels * pixels,
psImageInterpolateMode mode,
double exposedValue);
blankPixels should be psPixels
psMinimizeChi2Powell [ inconsistent ]
spec :
bool psMinimizeChi2Powell(
psMinimization * min,
psVector * params,
psMinConstrain * constrain,
const psArray * coords,
const psVector * value,
const psVector * error,
psMinimizeChi2PowellFunc model);
code :
bool psMinimizeChi2Powell(
psMinimization * min,
psVector * params,
const psVector * paramMask,
const psArray * coords,
const psVector * value,
const psVector * error,
psMinimizeChi2PowellFunc model);
Replace const psVector * paramMask with psMinConstrain * constrain.
psMinimizeLMChi2 [ inconsistent ]
spec :
bool psMinimizeLMChi2(
psMinimization * min,
psImage * covar,
psVector * params,
psMinConstrain * constrain,
const psArray * x,
const psVector * y,
const psVector * yWt,
psMinimizeLMChi2Func func);
code :
bool psMinimizeLMChi2(
psMinimization * min,
psImage * covar,
psVector * params,
const psVector * paramMask,
const psArray * x,
const psVector * y,
const psVector * yErr,
psMinimizeLMChi2Func func);
same change as psMinimizeChi2Powell()
psPlaneDistortAlloc [ inconsistent ]
spec :
psPlaneDistort *psPlaneDistortAlloc(
int order1,
int order2,
int order3,
int order4);
code :
psPlaneDistort *psPlaneDistortAlloc(
int n1,
int n2,
int n3,
int n4);
We prefer order[1-4] over n[1-4].
psPlaneTransformAlloc [ inconsistent ]
spec :
psPlaneTransform *psPlaneTransformAlloc(
int order1,
int order2);
code :
psPlaneTransform *psPlaneTransformAlloc(
int n1,
int n2);
same as psPlaneDistortAlloc()
psPolynomial1DAlloc [ inconsistent ]
spec :
psPolynomial1D *psPolynomial1DAlloc(
psPolynomialType type,
unsigned int nX);
code :
psPolynomial1D *psPolynomial1DAlloc(
unsigned int n,
psPolynomialType type);
Is there a good reason not to use psPolynomialType?
psSpline1DAlloc [ inconsistent ]
spec :
psSpline1D *psSpline1DAlloc(
unsigned int n,
unsigned int order,
float min,
float max);
code :
psSpline1D *psSpline1DAlloc(
);
psSpline1DAlloc() does not appear to be implimented correctly.
psImage [ inconsistent ]
spec :
typedef struct psImage {
psMathType type;
const int numCols;
const int numRows;
int col0;
int row0;
union {
psS8 S8;
psS16 S16;
psS32 S32;
psS64 S64;
psU8 U8;
psU16 U16;
psU32 U32;
psU64 U64;
psF32 F32;
psF64 F64;
psC32 C32;
psC64 C64;
psPtr V;
} data;
const struct psImage *parent;
psPtr p_rawDataBuffer;
psArray *children;
void *lock;
} psImage;
code :
typedef struct psImage {
const psMathType type;
const int numCols;
const int numRows;
int col0;
int row0;
union {
psS8 S8;
psS16 S16;
psS32 S32;
psS64 S64;
psU8 U8;
psU16 U16;
psU32 U32;
psU64 U64;
psF32 F32;
psF64 F64;
psC32 C32;
psC64 C64;
psPtr *V;
} data;
const struct psImage *parent;
psPtr p_rawDataBuffer;
psArray *children;
void *lock;
} psImage;
Please make type const
psList [ inconsistent ]
spec :
typedef struct {
long n;
psListElem *head;
psListElem *tail;
psArray *iterators;
void *lock;
} psList;
code :
typedef struct {
long n;
psListElem *head;
psListElem *tail;
psArray *iterators;
pthread_mutex_t p_lock;
void *lock;
} psList;
Please remove p_lock. it is redudant with lock.
Change History (7)
comment:1 by , 20 years ago
| Owner: | changed from to |
|---|
comment:2 by , 20 years ago
comment:3 by , 20 years ago
I've modified the definition of psImage in the SDRS to match the implimentation.
I don't understand what you meant when you referred to a "system lock" and I
can't find a requirement for it. Please remove the p_lock memeber from psList.
comment:4 by , 20 years ago
| Cc: | added |
|---|---|
| Severity: | normal → blocker |
This bug needs to be resolved before the next release of pslib.
comment:5 by , 20 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Most of the api-delta changes have been made now. This bug is generally fixed
or out-of date at this point.

We are actually aware of all these tasks and they have been in gforge already.
Some have been done already and a few have been scheduled. A couple may not
actually be valid either.
In psImage, it says to make type const. It is const in the code, it is NOT
const in the spec now. Also, we have discussed this a bit in the past, but the
psPtr V in psImage should be psPtr *V as it is in the code. This avoids some
issues in using psImages in certain functions.
For psList, we felt the best thing to do with the lock situation was to leave
the p_lock in place as a system lock and give the user access to the void *lock
for any additional locking needs. Thus I don't think it's actually redundant
here, but if you really don't like it we can take a closer look at it.