Hi Greg - I'll reply below.
On 5/28/15, 11:03 AM, "Greg Kreider" <[email protected]> wrote: > >Good morning, > >The questions for today are about the compiler and external >code. > >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)? > >2. Is it possible to provide feedback about optimizations that > can't be done? The idea of using (sub)domains to provably > escape bounds checking for arrays is powerful, for example, > and we would like to see the array accesses where this can't > be shown. I'm going to let somebody else answer this question. > >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); Some notes: 1) To be clear - you put C code inside extern { }, and can use any C thing (such as #include) there. Symbols that are used below will have the appropriate 'extern' stuff generated internally by the compiler. However, this automatic technique can't differentiate between C pointers used as out/inout/ref arguments and pointers to arrays. For that reason, you typically also need to use c_ptrTo() sometimes when working with C code in this way. You can find more about this functionality in README.extern. This will even work with inline C code and result in the inlining... But it won't work with complicated C macros, including any that take arguments. 2) The extern block mechanism solves the problem of needing to update both your C code and the Chapel foreign function interfaces. 3) Since Chapel enums don't define the values as global symbols - you would have to write MyEnum.ENUM_A if the example above were a Chapel enum. I think that might be confusing. Beyond that, you would still have to name the individual enum values even if you could make an 'extern enum' since the Chapel compiler needs to know the names of the values (so that it can make them usable from Chapel code). If your answer here is - "well, it should look at the C code defining the enum" - that is what the extern block functionality does (and more). > >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. For a class, the destructor (written with e.g. proc ~MyClass() { }) will get called when you 'delete' the class instance. Some Chapel things, like arrays, are reference counted. We've for a long time hoped to provide a general wrapper that would allow a user-specified class to be reference counted too, but that hasn't happened yet. If you want something more like mark/sweep garbage collection - or have other opinions on the approach to memory management, I'd be interested in discussing further. There's plenty more to talk about... I just want to keep it simple in the reply here, so I stuck to the facts of what we have now and what we're working on (rather than the discussion of what the language should one day do). Cheers, -michael ------------------------------------------------------------------------------ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
