I've just been bitten by the change in the way clear works in Stata. The change happened in transition from version 9 to 10.
In v9, the implementation of clear apparently calls mata: mata clear, while in Stata 10 it does not. (This change has been documented and explained in multiple places). I certainly prefer the behavior in 10. However I struggle to understand what happens when clear is called from Mata itself.
Consider the following (example) code (works fine in v10):
All the commands are present in v9, so it is possible to downgrade the version requirement to 9. However the code does not work then (even when executed in v13):
and it comes as a complete surprise that the fbufget() encounters an error. This happens because the function survives the clear and continues executing, but all the local variables vanish (fh and C are no longer available). This is rather illogical. If the scope of clear is limited to the internal scope of the stata() statement, then the Mata locals should not be affected, if not then the procedure should terminate (since there are no more statements to execute after Mata has been cleared).
For most recent version 13 just replace "clear" with "mata mata clear" in the code of testbug().
The logic of Stata programs was that the program may not drop itself (and hence ironically the clear program always survives clear). This seems to apply to Mata as well. But in Stata the program that attempts to drop itself does not ruin its own locals, while in Mata this is apparently the case.
While in my case "drop *" can be introduced to avoid the problem, it might not be as straightforward in other situations. I wish I knew about this problem earlier.
While the above is more of a caution for other developers, on a practical side, I'd like to know whether destructors are executed on all objects on "mata mata clear" and whether all (mata) files are closed. If the mata files are not closed, but the handlers are lost, then it is alarming. Since I couldn't find an equivalent of file close _all in Mata, I am using the following Stata code to make sure Mata does not exhaust the file handlers:
Thank you, Sergiy Radyakin
In v9, the implementation of clear apparently calls mata: mata clear, while in Stata 10 it does not. (This change has been documented and explained in multiple places). I certainly prefer the behavior in 10. However I struggle to understand what happens when clear is called from Mata itself.
Consider the following (example) code (works fine in v10):
Code:
version 10.0 mata void function testbug() { fh=fopen("http://www.google.com","r") C=bufio() fbufget(C,fh,"%12s") stata("clear") fbufget(C,fh,"%12s") fclose(fh) } end mata testbug() //eof
Code:
. mata testbug() <!doctype ht fread(): 3601 invalid file handle fbufget(): - function returned error testbug(): - function returned error <istmt>: - function returned error
For most recent version 13 just replace "clear" with "mata mata clear" in the code of testbug().
The logic of Stata programs was that the program may not drop itself (and hence ironically the clear program always survives clear). This seems to apply to Mata as well. But in Stata the program that attempts to drop itself does not ruin its own locals, while in Mata this is apparently the case.
While in my case "drop *" can be introduced to avoid the problem, it might not be as straightforward in other situations. I wish I knew about this problem earlier.
While the above is more of a caution for other developers, on a practical side, I'd like to know whether destructors are executed on all objects on "mata mata clear" and whether all (mata) files are closed. If the mata files are not closed, but the handlers are lost, then it is alarming. Since I couldn't find an equivalent of file close _all in Mata, I am using the following Stata code to make sure Mata does not exhaust the file handlers:
Code:
forval i=0/128 { capture mata fclose(`i') }