Hi Michael,
I have official Contrib. privs now, so I'll see about adding some bugs.
On Tue, May 5, 2015 at 5:35 AM, Michael Ferguson <mfergu...@cray.com> wrote:
> Hi -
>
> I had reported bugs to do with nested records/classes that seem
> similar to your problems here - those are
> in test/users/ferguson/nested and were fixed last August by Tom H.
>
> I think that you're running into a related but different problem.
> It would be good to file your example (or even better several variants
> of it) in the test system as a .future bug. Are you able to do so?
> (see doc/developer/bestPractices/ContributorInfo.rst if you
> haven't already)
>
> I agree with Brad that you shouldn't need to add an 'outer' argument;
> however the program still fails to compile if I remove that
> constructor. Many simple variations of this program fail:
> * removing constructor
> * moving array declaration to variable in a method
> * commenting out 'key' and/or 'value' from the record
>
> -michael
>
> On 5/5/15, 2:07 AM, "Brad Chamberlain" <br...@cray.com> wrote:
>
> >Hi Brian --
> >
> >
> >Just to get a response to you quickly -- I suspect that you're doing
> >anything inherently wrong or off-base, but are just nudging up against
> >the limit to which our current constructor and nesting features work well
> >together. You may have seen elsewhere
> > that our constructor design and implementation are currently in flux and
> >on the way to a healthier implementation which should hopefully fix up
> >things like this.
> >
> >
> >The main part that surprised me looking at your code was the implication
> >that the compiler required you to add an 'outer' argument, which is
> >something I think of as being what it should be adding implicitly in the
> >case of nested stuff, when needed. The
> > other thing I would experiment with, if I weren't going to bed, is
> >whether making the class and record non-generic simplifies things at all.
> >
> >
> >The fact that de-nesting them makes things work is what makes me
> >suspicious that it's our problem rather than yours. But nested records
> >and classes do tend to throw me for a loop sometimes, especially this
> >late in the evening...
> >
> >
> >-Brad
> >
> >
> >
> >
> >________________________________________
> >From: Brian Guarraci [br...@ops5.com]
> >Sent: Monday, May 04, 2015 9:17 PM
> >To: chapel-developers@lists.sourceforge.net
> >Subject: [Chapel-developers] nested classes
> >
> >
> >Hi,
> >
> >
> >I've run into a strange error while using I felt was a natural use of
> >nested records. Below is a snippet. It tries to use the parameterized
> >types to create an nested record which is then entries in a hash.
> >There's a few errors when I compile and eventually
> > the only way to get it to work was to pull ValueType and TableEntry up
> >into the top-level of the module. Any ideas? I didn't see much on this
> >in the spec.
> >
> >
> >Thanks!
> >Brian
> >
> >
> >/*
> >test/nested_class.chpl:22: error: unresolved type specifier
> >'LockFreeHash(uint(32)).TableEntry'
> >test/nested_class.chpl:13: note: candidates are: TableEntry(_mt: _MT,
> >outer)
> >*/
> >module LockFreeHash {
> >
> > type KeyType = uint(32);
> >
> >
> > class LockFreeHash {
> > type ValueType = uint(32);
> > var hashSize: uint(32) = 1024*1024;
> >
> >
> > record TableEntry {
> > var key: atomic KeyType;
> > var value: atomic ValueType;
> >
> >
> > // test/nested_class.chpl:18: error: constructor for class
> >'TableEntry' requires a generic argument called 'outer'
> > proc TableEntry(outer: LockFreeHash) {
> > key.write(0);
> > }
> > }
> >
> >
> > var array: [0..hashSize-1] TableEntry;
> >
> >
> > // removed methods
> > }
> >}
> >
> >
> >
> >
> >
>
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Chapel-developers mailing list
Chapel-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/chapel-developers
