[Users] Piraha in the Flesh

[Ian Hinder]

On 21 Feb 2013, at 00:57, Steven R. Brandt <sbrandt at cct.lsu.edu> wrote:

> On 02/06/2013 06:37 PM, Steven R. Brandt wrote:
> I haven't heard a lot of feedback about this feature yet, but I thought 
> I'd mention a recent improvement.
> 
> Piraha allows array notation in parameter files so that instead of 
> writing this:
> 
>     CarpetRegrid2::radius_1[1]  =  10
>     CarpetRegrid2::radius_1[2]  =   5
> 
> you can write this:
>     CarpetRegrid2::radius_1 = [10,5]
> 
> The nice thing about having a parser is that the various features 
> combine, so you can also write this:
>     CarpetRegrid2::radius_1 = [
>         2+2*4 # This should be 10
>         ,5]

I support the use of Piraha in the flesh for its parsing.  It should be used for parsing the CCL files during the CST, and parsing the parameter file at runtime.  I see that Piraha is written in C++, so we would have to relax the restriction that the flesh can only contain C code.  I have not yet looked at the code.

One important aspect is error messages.  How well does Piraha currently report input errors to the user?  Are they easy to understand?  I have found piraha error messages to be a little confusing in the past :)

>> I've hacked a version of Cactus to use Piraha for parameter parsing. 
>> Please take a look:
>> 
>> https://svn.cactuscode.org/flesh/branches/with_piraha
>> 
>> This version is able to run the ET testsuite.
>> 
>> This version can understand the variables $parfile, $ENV{name}, and 
>> $pi (which is 3.14...). Variables can be standalone, or be substituted 
>> from inside strings.
>> 
>> It can understand mathematical expressions including grouping, order 
>> of operation, and a few functions (sin, cos, tan, exp, sqrt). Other 
>> parameters from the parameter file are available for use in 
>> mathematical expressions.
>> 
>> Some debug printing is in place so you can get an idea of what's going 
>> on.

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder