On Fri, Oct 30, 2015 at 12:55 PM, Michael Ferguson <mfergu...@cray.com> wrote:
> Hi - > > On 10/30/15, 12:45 PM, "Hui Zhang" <wayne.huizh...@gmail.com> wrote: > > >Hello, Michael > > > > > >Okay....that makes a lot more sense now > > > > > >In my case, as your example, I need a nice stack trace when a sample fell > >on that "writeln", but now it'll give me something like this (assume file > >is user.chpl, forall is on line > > #1): > > > >wrap_coforall_fn (user.chpl : 1) -> coforall_fn (ChapelRange.chpl: 2) -> > >writeln (..) > > > >I expected it to be something like: > > > >wrap_coforall_fn(user.chpl: 1) -> coforall_fn(user.chpl: 2) -> writeln(..) > > > > > >So if the filename is internal modules, then it'll be difficult for me > >to transfer data along the stack since my previous analysis only > >concerns about user code... > > I don't think it's philosophically wrong for the compiler to include > these internal module line numbers. Can you arrange for your tool to > ignore them somehow? > > Yea, I need to find a work-round > > > > > >Another question: why the line# of the frame I got is "correct"(right > >line# in the user code, here '2') when the file/module is internal module > >? > > That just looks like a bug to me. > You suppose it to be a bug in the compiler or my tool ? > > -michael > > -- Best regards Hui Zhang
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list Chapel-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/chapel-developers
