Hi,
Present were Erik, Peter, Steve, Frank, and Jonah.
The issue [1] about parameter ranges, quotes ect were discussed, and as conclusion Steve is to commit everything. Warnings will output for now, Kranc should be fixed soon, and quotes around ranges will be deprecated as soon as possible.
Frank is working on providing shell-script support functions for external libraries to arrive at a better handling of external libraries. Hold off with changes on those, or coordinate with him please.
Steve has been working on read/write directives in Cactus, and will continue to do so over the summer. Contact him if you are interested in that.
Frank
On 1 Jun 2015, at 17:29, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
Present were Erik, Peter, Steve, Frank, and Jonah.
The issue [1] about parameter ranges, quotes ect were discussed, and as conclusion Steve is to commit everything. Warnings will output for now, Kranc should be fixed soon, and quotes around ranges will be deprecated as soon as possible.
But not disallowed, right? I don't want old Kranc-generated thorns to fail to compile and need to be regenerated. Unless it is hard to keep the support for the quotes, I would allow it (and preferably not with a ton of warnings).
Frank is working on providing shell-script support functions for external libraries to arrive at a better handling of external libraries. Hold off with changes on those, or coordinate with him please.
There is a ticket (https://trac.einsteintoolkit.org/ticket/1175) and a wiki page (https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_external...) related to this from a while ago.
On Tue, Jun 02, 2015 at 02:19:59PM +0200, Ian Hinder wrote:
But not disallowed, right?
Not disallowed right now. They would generate warnings. At some point we will disallow it.
I don't want old Kranc-generated thorns to fail to compile and need to be regenerated.
Isn't one of the main points of Kranc-generated thorns that you can easily regenerate them? I would worry more if we would have tens of hand-written thorns with these.
Frank is working on providing shell-script support functions for
There is a ticket (https://trac.einsteintoolkit.org/ticket/1175) and a wiki page (https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_external...) related to this from a while ago.
Good point. However, I don't plan to overhaul the current system right now. I only want to homogenize it a bit - which in turn should make it easier later to implement all the changes proposed there.
Specifically: I am only looking into the "factoring out common code" section, and also not all of that (e.g., I leave building to the scripts, as this usually needs special treatment for each library).
Frank
On 2 Jun 2015, at 16:16, Frank Löffler knarf@cct.lsu.edu wrote:
On Tue, Jun 02, 2015 at 02:19:59PM +0200, Ian Hinder wrote:
But not disallowed, right?
Not disallowed right now. They would generate warnings. At some point we will disallow it.
I don't want old Kranc-generated thorns to fail to compile and need to be regenerated.
Isn't one of the main points of Kranc-generated thorns that you can easily regenerate them? I would worry more if we would have tens of hand-written thorns with these.
Indeed. If you (still) have access to Mathematica. I just don't see the point of deliberately breaking backward compatibility, even in the case where the old behaviour was not in agreement with the documentation. What is the benefit of doing this?
Frank is working on providing shell-script support functions for
There is a ticket (https://trac.einsteintoolkit.org/ticket/1175) and a wiki page (https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_external...) related to this from a while ago.
Good point. However, I don't plan to overhaul the current system right now. I only want to homogenize it a bit - which in turn should make it easier later to implement all the changes proposed there.
OK, that is good in any case. I guess you can one-by-one pull out common functions into a library of bash functions or something.
Specifically: I am only looking into the "factoring out common code" section, and also not all of that (e.g., I leave building to the scripts, as this usually needs special treatment for each library).
Yes, I had the same thought when reading the wiki page; building is really something that should be customised by the thorn. On the other hand, I think some of the thorns have their own "build.sh" script, and it might make sense for the Cactus library shell function to handle the standard options etc, and call the thorn's build script, rather than having the configure script call the build script (or contain the build commands) in the top-level. But you'll probably get a good feel for the right thing to do as you're doing it.
On Tue, Jun 02, 2015 at 04:44:46PM +0200, Ian Hinder wrote:
Indeed. If you (still) have access to Mathematica.
How many thorns are we talking about? If you don't intent to regenerate them, maybe this could be done once, by a script?
I just don't see the point of deliberately breaking backward compatibility, even in the case where the old behaviour was not in agreement with the documentation. What is the benefit of doing this?
It prevents new code from using this. Old thorns cannot be expected to work forever with a changing framework. Leaving old stuff in for ever usually makes code unmaintainable, although I don't know how severe it would be in this case. We didn't intent to make this go away immediately, more like marking it deprecated and generating a warning now, and removing it from a release in a year at the earliest.
OK, that is good in any case. I guess you can one-by-one pull out common functions into a library of bash functions or something.
That's the hope, right.
Yes, I had the same thought when reading the wiki page; building is really something that should be customised by the thorn. On the other hand, I think some of the thorns have their own "build.sh" script, and it might make sense for the Cactus library shell function to handle the standard options etc, and call the thorn's build script, rather than having the configure script call the build script (or contain the build commands) in the top-level. But you'll probably get a good feel for the right thing to do as you're doing it.
Ideally, the build script should only build (since that presumably can be done in parallel with other things). But before that, a library would need to be unpacked and configured, and that's also something that requires some individual treatment.
Frank
On 2 Jun 2015, at 16:59, Frank Löffler knarf@cct.lsu.edu wrote:
On Tue, Jun 02, 2015 at 04:44:46PM +0200, Ian Hinder wrote:
Indeed. If you (still) have access to Mathematica.
How many thorns are we talking about? If you don't intent to regenerate them, maybe this could be done once, by a script?
That's not what I'm getting at; we can of course fix all the ET Kranc-generated thorns to keep up with the ever-changing flesh. It's a matter of policy regarding backward compatibility.
I just don't see the point of deliberately breaking backward compatibility, even in the case where the old behaviour was not in agreement with the documentation. What is the benefit of doing this?
It prevents new code from using this. Old thorns cannot be expected to work forever with a changing framework.
I disagree completely. Cactus should be a stable platform on which you can build application thorns. New versions of this platform should still be able to run old code. Especially in this case, where there is no benefit to the change apart from discouraging new thorns using the old way. I think a warning should be enough.
Leaving old stuff in for ever usually makes code unmaintainable, although I don't know how severe it would be in this case. We didn't intent to make this go away immediately, more like marking it deprecated and generating a warning now, and removing it from a release in a year at the earliest.
Usually this sort of change is very annoying. In isolation, you can just say "it's a simple change, why are you complaining?" But when trying to resurrect an old thorn, it's unlikely that this is the only problem you're going to have, and each one makes life harder. I agree that leaving in a huge amount of backward-compatibility code can make the code harder to maintain, which is why in the ticket I said that it could be removed if that were the case. But I don't think that is the case here, and I don't see a benefit to removing the code.
Hello all,
Indeed. If you (still) have access to Mathematica. I just don't see the point of deliberately breaking backward compatibility, even in the case where the old behaviour was not in agreement with the documentation. What is the benefit of doing this?
I would have very much liked to be able to make this behaviour an error, however I think for the flesh, we will need to support this behaviour for quite a while even after we fix Kranc. Note that this particular issue can easily be fixed by users by modifying the Kranc generated files even when one does not have access to Mathematica anymore (or not at all) so that the cost of breaking things is low (since we are not actually removing functionality).
I would certainly think that we want the warning (and lots of them) as well if we hope that this will ever go away, since otherwise the thorns never get fixed, as evidenced by the fact that the Kranc ticket still exists. Only not having this in the documentation is not enough it seems since the possibility of using quotes was never documented (and only works for doubles, not for integers) and yet was used.
Yours, Roland
users@lists.einsteintoolkit.org
-
Frank Loeffler -
Frank Löffler
-
Ian Hinder -
Roland Haas