On Wed, May 21, 2014 at 2:58 PM, Eugenio Gianniti <address@hidden> wrote:
Dear Marco, and all,
I attach the ufl.m function I have previously mentioned for review.
Thanks, really good job.
I still have to edit something, namely on line 45 a check for the .ufl file extension is performed with a case insensitive matching, but I should ensure with a couple more instructions that the lower case version is used, as in the functions that compile the
.oct files for the problem at hand.
You should also check that we are not overwriting an existing file.
In this case it should error out complaining about the existing file and leaving it as it is, I would say. It is probably useful to add another command to delete a file and start from scratch, something like:
>> ufl clear filename
or
>> ufl rm filename
Do you agree?
There is also an issue due to a bug present in the stable version currently distributed, but solved in the development version. I also attach script.m, containing basically the Poisson.ufl of the homonymous example, but with ufl in first position. I noticed
that my function works as I expect with the simpler lines, but Octave errors out when trying to execute the second and the ninth (I added comments to highlight those lines). This happens only in the stable release, on the other hand the development version
goes on without complaining. Here is the error:
>> script
parse error near line 2 of file /Users/eugenio/tests/script.m
syntax error
>>> ufl element = FiniteElement("Lagrange", triangle, 1)
How should I proceed with respect to this behaviour?
I don't have the stable version so I don't know how to reproduce it.
However it could be the "," as it is present only in this two lines.
But, as it has been fixed in the development version, probably someone here in the list can explain this behaviour.
I am not really worried by this bug per se, in any case it has been solved in the development code, but my doubts are mainly:
1) Should I look for the relevant bug report in the bug tracker and point out that this needs to be fixed also in the stable release? Or maybe just ask when it is scheduled to be included in it?
2) Should I create a new branch to hold changesets related to this functionality, so that it does not make its way to the released package until the stable release of Octave allows it to work properly? I do not know what is the calendar you have
in mind for fem-fenics releases, nor the main Octave’s, but it could be useful should the necessity arise.
Eugenio
|