What is the best way to recognise data that has been deflated with {quad)dr?
Davin, Thank you for your interest in the problem.
We are very keen to exploit the inflate/deflate facility.
It will be quite advantageous for our clients.
However there is a small snag.
A function reads in a file, sometimes it is an old
file and the records are big, other times it is to be a
file with deflated records. Obviously we can
program a header record code on the new files to
tell the function that following records are
deflated but I was hoping for something more
simple.
The ideal would be something like...
("inflate" "state") {quad}dr var
which could return various items of information
or a simple empty vector to indicate that the var's data
was unrecognised by the inflation logic.
Our initial tests show that the {quad}dr defaults are quite
satisfactory in our case.
z <- 'inflate' {quad}dr y ©{grad}{DOMAIN:z<-y}
appears to work OK.
Is it good practice?
That should work satisfactorily. It should be nearly impossible to inflate a non-deflated string.
With the default wrapl-ing, I'm thinking that the first byte of the string is probably always going to be ŒAV[ŒIO+1] (and function listings shouldn't ever be), so you could also just check the first character for a match.
Or, if you're just working with function listings then your first or fifth character is probably always a ’, so you can try checking for that, too.
Does that help?
Davin
Oops - sorry - I misread your note and thought you were reading in only function listings.
Yes, your method of trapping an inflation error should be fine. There will be a small overhead when trying to uncompress non-compressed data records, but I doubt that will be of much concern in your case.
Shouldn't []DR on inflate "push through"?
That is, if the information isn't "deflated", shouldn't []DR just deliver the data as is.
What about 'wrapl' data? I've not tried to 'deflate' 'wrapl' data but would the same apply?
/mas
No, []DR shouldn't pass through uncompressed data. For one thing, you need a way to be able to tell if you've got bad data in the first place, so it can't just ignore it.
Also, []DR includes wrapl-ing as part of it's default process, so you don't even need to deal with it directly.