John,
Let me respond to your compilerError() issue.
The actual argument(s) must be compile-time "params". In your example,
'i' would need to be a "param", not "var".
Note that "rank" is usually a param, so you should be able to write:
var A: [...] ...; // A is an array
compilerError("Error: rank=" + A.rank);
A slight variation on your class declaration:
class MyBlockDist {
type policyType;
var policy:policyType;
....
}
would be avoiding 'policyType' and having 'policy' be a generic field:
class MyBlockDist {
var policy;
....
}
In some cases you won't be able to mix instances different
instantiations of MyBlockDist. This may or may not be an issue for you.
If it is, make the 'policy' field be non-generic, its type being the
root of your policy-type class hierarchy:
class MyBlockDist {
var policy:RootPolicy;
....
}
class RootPolicy {...}
class MyFirstPolicy: RootPolicy {...}
class MySecondPolicy: RootPolicy {...}
etc.
Vass
On 01/29/15 14:07, John MacFrenz wrote:
> Thanks, the halt was what I was looking for
>
> I'm encountering some strange bug where my policy objects rank doesn't match
> the distribution's rank though I've double checked they should... Both
> defined as param. I'm trying to get some information via compilerError,
> however printing integer variables doesn't seem to work. For example
>
> var i:int = 3;
> compilerError("Error: "+i);
>
> results in:
>
> error: unresolved call 'compilerError(string)'
> $CHPL_HOME/modules/internal/ChapelBase.chpl:162: note: candidates are:
> compilerError(param x: c_string ...?n, param errorDepth: int)
> $CHPL_HOME/modules/internal/ChapelBase.chpl:166: note:
> compilerError(param x: c_string ...?n)
>
> Replacing compilerError with halt compiles, but of course isn't what I would
> have needed...
>
> As I wrote above, I have a problem where a domain assignment fails because
> incompatible dimensions. In the base class of my policy I have method
> setBoundingBox overridden by MyPolicy. The distribution calls this function.
> If I comment out the assignment and replace it with printed diagnostics the
> dimensions match, so somehow the inheritance confuses the compiler.
>
> I tried the method of not using a base class at all, however it proved it own
> difficulties. Essentially, I need to be able to store the policy in objects,
> and getting classes to store generic object requires a lot of changes. But I
> guess I'll have to go down this route...
>
> So should the following work or do I need something more, or are there
> simpler ways to do this?
>
> class MyBlockDist {
> type policyType;
> var policy:policyType;
> ....
> }
>
> proc MyBlockDist.MyBlockDist (...
> policy,
> policyType = policy.type,
> ...) {
> this.policy = policy;
> ...
> }
>
>
> 29.01.2015, 22:11, "Brad Chamberlain" <[email protected]>:
>>> For now I have defined functions meant to be overridden by user as
>>> functions with empty body. However I'd like to issue some diagnostics if
>>> these empty functions are called, either at compile- or runtime.
>>> Something along the lines of die("message") or exit("message"). I tried
>>> compilerError, but apparently it generates an error regardless whether
>>> the method is overridden or not.
>> Ultimately what we need here is a true notion pure virtual methods in the
>> language, but see the apology below about "naive OOP support".
>>
>> compilerError() is triggered at compile-time any time the compiler tries
>> to resolve that function call, so using it in dynamic dispatch cases is
>> not the right way to go, at least as the compiler is currently implemented
>> (it'll analyze a virtual method whether or not all child classes override
>> it). So typically in these cases, we insert a halt() in the pure virtual
>> method which will result in an execution-time error. Not as ideal as a
>> compile-time error, but our only option I'm aware of until pure virtual
>> methods are supported.
>>
>> -Brad
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Chapel-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-users
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
