Hi Michael,
>>
>> 1. It seems that the compiler is aggressive about not touching
>> dead code, with some basic syntax checking being done but
>> uncalled functions otherwise ignored. We've run test compiles
>> on modules that come up clean, only to find simple errors
>> when the module actually gets used; this has also happened
>> with procedures within a file that aren't called. Is there
>> a way to run the compiler to check everything in a file?
>> (As an example the file
>> proc unused(i : int) : bool { return i; }
>> writeln("ignoring used");
>> /* unused(1); */
>> does not generate a compiler error until the call is
>> uncommented.)
>
> This is a feature meant to enable rapid prototyping.
> I expect that as Chapel modules gain the ability to specify
> which functions are 'public' and which are 'private' - that
> we will start checking public functions whether or not they
> are used. That's just my personal expectation though...
>
> I'm curious if you would prefer Chapel to always type
> check non-generic functions even if they are not used?
> (even private ones)?
>
Yes, if not "always" then to have a compiler flag to do the
checking is fine. Just so that compile-time errors don't
show up far in the future. (Although I guess this is a way
to detect code paths that aren't covered by a test bench ...)
>>
>> 3. It it possible to tie external enumerations in C into
>> Chapel enums, rather than using 'extern const' for each
>> member?
>> ex. In C,
>> enum clrplane { CLR_GREY = 0x10, CLR_R = 0x01,
>> CLR_G = 0x02, CLR_B = 0x08 };
>> requires
>> extern const CLR_GREY : int(32);
>> extern const CLR_R : int(32);
>> extern const CLR_G : int(32);
>> extern const CLR_B : int(32);
>> and it would be better to not have to do this (if only
>> because if the C enum changes you have to remember to
>> add a constant).
>
> You could use the extern block mechanism, if you have Chapel
> built with LLVM. For example (this example is in our test suite):
>
> extern {
> typedef enum {
> ENUM_A = 1,
> ENUM_B = 0,
> ENUM_C = -1
> } MyEnum;
> }
>
> var x:MyEnum = ENUM_A;
>
> writeln(x);
>
OK, we've been using GCC so far so this wasn't an option.
There's already quite a bit of parsing of the C header (we're
using the link between a Chapel class and the C
typedef struct _name { } name construct to access PNG images
that were read in C), and it seemed that a similar link but
for enums would be nice to have.
Fully qualifying the enum name isn't a problem, by the way.
>>
>> 4. Is a user-defined class destructor called by the garbage
>> collector? We tried putting some clean-up code for
>> allocations C-side in one but it never triggered.
>
> Chapel doesn't have a garbage collector like e.g. Java does,
> but we intend to support C++ style 'RAII'. That means that
> you can wrap an allocated pointer with a record, write a
> record destructor that frees the memory, and expect that
> the Chapel compiler will free the memory. This works sometimes
> now... and we're actively working on cleaning that up.
>
'Garbage collector' was my misunderstanding then; I really
meant to ask about what happens when Chapel is done with a
class or record and if there was a hook for user code when
it is freed.
Just saw the answer about the OOM question, which answers this.
And just to be clear: there is no automatic delete called by
the runtime when a class variable moves out of scope - you
have to do it manually.
That's a surprise (given that there's no other need to manage
memory in Chapel) and explains a few things we've seen - and
probably a couple latent leaks.
Is there a reason why the destructor couldn't be called for a
purely local class instance, such as this case? Anyway, here's
a vote for some form of reference counting classes (which for
our application is good enough, but we don't have much
experience to say anything concrete about garbage collection vs.
reference counting!)
Thanks for the comments,
Greg
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
