[vwnc] [7.6] methods with namespace attributes ignore name space imports

hello,

VW 7.6 often decides to create an AnnotatedMethod with a namespace
attribute when filing in / generating code (e.g. UIPainter), imported
namespaces are not visible any more.

e.g.

setup:
- NameSpace Kung
- NameSpace Fu (imports Kung)
- Class Kung.Pow

method defined by UI Painter

Foo.FooBar>>textAspect
   ...
   textAspect := String new asValue.
   ...

now if I try to modify the method:

Foo.FooBar>>textAspect
   ...
   textAspect := Pow singleton quoteOfTheDay asValue.
   ...

...the compiler can't find Pow, even though
- the class is in the namespace Foo which imports Kung
- the method has a hidden __namespace attribute for Foo.

the effect of this is that now I either have to remove the generated
method and paste & accept it (so no attribute is generated, because now
the compiler knows that the class is in Foo), or I have to use a dotted
name (which contradicts the purpose of the default package namespaces).

related issue: the default namespaces for packages are well hidden (have
to inspect all properties), and the attributes are almost invisible
(have to inspect the compiled method).


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> VW 7.6 often decides to create an AnnotatedMethod with a namespace
> attribute when filing in / generating code (e.g. UIPainter), imported
> namespaces are not visible any more.

bugfixed version of the sentence above:

VW 7.6 often decides to create an AnnotatedMethod with a namespace
attribute when filing in / generating code (e.g. UIPainter). In those
methods, imported namespaces are not visible any more.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I don't see this if I do what you're describing. It may be that you need to describe the packages involved and what packages specify a default namespace. Also, is there a current package used for file-in/class generation? If you have e.g. a file-in example or a sequence of steps that reproduces this into a clean image, that would be ideal.

Normally, I would expect file-ins and UIPainter defines of new methods to occur in the package that holds the class definition, in which case they would not be annotated. And if the method has a namespace annotation, I'd definitely expect it to be able to see things visible to that namespace. In fact, in this case, it seems like the class and the package's namespace are the same, so I don't even know what other namespace it would choose to compile in. Can you tell what namespace it's compiling in?

Note that the default namespace appears in the title bar of the browser in {} after the name of the package when the package is selected.

At 09:17 AM 4/26/2008, Holger Kleinsorgen wrote:

hello,

VW 7.6 often decides to create an AnnotatedMethod with a namespace
attribute when filing in / generating code (e.g. UIPainter), imported
namespaces are not visible any more.

e.g.

setup:
- NameSpace Kung
- NameSpace Fu (imports Kung)
- Class Kung.Pow

method defined by UI Painter

Foo.FooBar>>textAspect
   ...
   textAspect := String new asValue.
   ...

now if I try to modify the method:

Foo.FooBar>>textAspect
   ...
   textAspect := Pow singleton quoteOfTheDay asValue.
   ...

...the compiler can't find Pow, even though
- the class is in the namespace Foo which imports Kung
- the method has a hidden __namespace attribute for Foo.

the effect of this is that now I either have to remove the generated
method and paste & accept it (so no attribute is generated, because now
the compiler knows that the class is in Foo), or I have to use a dotted
name (which contradicts the purpose of the default package namespaces).

related issue: the default namespaces for packages are well hidden (have
to inspect all properties), and the attributes are almost invisible
(have to inspect the compiled method).


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Update:

>> ...the compiler can't find Pow, even though
>> - the class is in the namespace Foo which imports Kung
>> - the method has a hidden __namespace attribute for Foo.

I was wrong, the method has a hidden __namespace attribute for
#Smalltalk, which also explains why it cant see the class.

This was caused by the FileOut30 package, which is this why it couldn't
be reproduced in a plain image.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

At 04:38 PM 4/26/2008, Holger Kleinsorgen wrote:

Update:

>> ...the compiler can't find Pow, even though
>> - the class is in the namespace Foo which imports Kung
>> - the method has a hidden __namespace attribute for Foo.

I was wrong, the method has a hidden __namespace attribute for
#Smalltalk, which also explains why it cant see the class.

This was caused by the FileOut30 package, which is this why it couldn't
be reproduced in a plain image.

Thanks. Any idea what it was about FileOut30 that was causing the problem? It'd be nice to fix that.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>> This was caused by the FileOut30 package, which is this why it couldn't
>> be reproduced in a plain image.
>
> Thanks. Any idea what it was about FileOut30 that was causing the problem? It'd be nice to fix that.

FileOut30 has a few issues:

- it sends #nonMeta, which is implemented by Store packages, but Store
is not a prerequisite

- the FilteringFileFormat introduced by FileOut30 has an 'environment'
instVar which is initially set to #Smalltalk.

- FilteringFileFormat>>compile:class:protocol: sends

    aClass
       compile: string
       classified: aProtocol
       notifying: nil
       attributes: nil
       environment: environment

- ClassDescription>>compile:notifying:attributes:selectorBlock:ifFail:
     environment:

uses == to check if the environment is needed:

    aNamespace notNil and: [aNamespace ~~ self environment]

so if a class is defined in a namespace different from #Smalltalk, an
AnnotatedMethod will be generated, although #Smalltalk is visible.
To solve the issue, one of the methods above has to perform a proper
namespace lookup, e.g.

requiredEnvironment := environment notNil
     and: [
        (aClass environment bindingFor: environment name) value
          == environment ])
    ifTrue: [ nil ]
    ifFalse: [ environment ].

(or implement something like GeneralNameSpace>>isVisible: and use this
method)
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

At 03:58 AM 4/28/2008, Holger Kleinsorgen wrote:

>> This was caused by the FileOut30 package, which is this why it couldn't
>> be reproduced in a plain image.
>
> Thanks. Any idea what it was about FileOut30 that was causing the problem? It'd be nice to fix that.

FileOut30 has a few issues:

<snip>

Thanks. Created AR 54275 for that.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dear Holger,
    IIUC you saw this in the fileOut30 with the 7.6 distribution, which
appears to be version 1.21.  The latest version in the Cincom OR is
version 1.37, which has some namespace and visibility related fixes.  Do
you see the same behaviour / wrong behaviour in the latest?

          Yours faithfully
             Niall Ross

Alan Knight wrote:


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Niall Ross schrieb:
> Dear Holger,
>    IIUC you saw this in the fileOut30 with the 7.6 distribution, which
> appears to be version 1.21.  The latest version in the Cincom OR is
> version 1.37, which has some namespace and visibility related fixes.  Do
> you see the same behaviour / wrong behaviour in the latest?

yes
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc