Smalltalk › Cincom › VisualWorks

how to find dotted named undeclareds

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Christian Haider

how to find dotted named undeclareds

I just learned something unexpected: undeclared dotted names are not recognized as undeclareds.

I tried this code:

testUndeclareds

| list |

lowercaseUndeclared := nil.

list := Array

with: Undeclared1

with: UndeclaredNamespace.Undeclared2

with: Graphics.Undeclared3.

^list

The names “lowercaseUndeclared” and “Undeclared1” are recognized as undeclareds and can be found in the Undeclared namespace.

However, non-resolving dotted names, being in a known or unknown namespace, are not recognized.

The browser warns about a not defined variable (with the option to correct it), but loading the code as source, parcel or from store gives no warning.

The code critic does not detect this neither.

So, does anybody know an easy way to find such undeclareds?

(The need occurrs f.ex. when removing a package namespace or renaming a namespace)

BTW, this behavior has been in VisualWorks for some time (I checked 7.6 to 7.8). 7.6 had a transcript message about undeclared “soft links”.

Cheers,

Christian

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

Boris Popov, DeepCove Labs (SNN)

Re: how to find dotted named undeclareds

It’s a known issue, AR 49017 it seems,

http://osdir.com/ml/lang.smalltalk.vwnc/2005-03/msg00193.html

http://osdir.com/ml/lang.smalltalk.vwnc/2005-03/msg00186.html

-Boris

From: [hidden email] [mailto:[hidden email]] On Behalf Of Christian Haider
Sent: 31 May 2011 02:40
To: [hidden email]
Subject: [vwnc] how to find dotted named undeclareds

I just learned something unexpected: undeclared dotted names are not recognized as undeclareds.

I tried this code:

testUndeclareds

| list |

lowercaseUndeclared := nil.

list := Array

with: Undeclared1

with: UndeclaredNamespace.Undeclared2

with: Graphics.Undeclared3.

^list

The names “lowercaseUndeclared” and “Undeclared1” are recognized as undeclareds and can be found in the Undeclared namespace.

However, non-resolving dotted names, being in a known or unknown namespace, are not recognized.

The browser warns about a not defined variable (with the option to correct it), but loading the code as source, parcel or from store gives no warning.

The code critic does not detect this neither.

So, does anybody know an easy way to find such undeclareds?

(The need occurrs f.ex. when removing a package namespace or renaming a namespace)

BTW, this behavior has been in VisualWorks for some time (I checked 7.6 to 7.8). 7.6 had a transcript message about undeclared “soft links”.

Cheers,

Christian

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

Christian Haider

Re: how to find dotted named undeclareds

In reply to this post by Christian Haider

Cool. Thanks.

Indeed an old issue (6 years). Any news on the subject, anyone?

Christian

Von: Boris Popov, DeepCove Labs [mailto:[hidden email]]
Gesendet: Dienstag, 31. Mai 2011 09:01
An: Christian Haider; [hidden email]
Betreff: RE: [vwnc] how to find dotted named undeclareds

It’s a known issue, AR 49017 it seems,

http://osdir.com/ml/lang.smalltalk.vwnc/2005-03/msg00193.html

http://osdir.com/ml/lang.smalltalk.vwnc/2005-03/msg00186.html

-Boris

From: [hidden email] [mailto:[hidden email]] On Behalf Of Christian Haider
Sent: 31 May 2011 02:40
To: [hidden email]
Subject: [vwnc] how to find dotted named undeclareds

I just learned something unexpected: undeclared dotted names are not recognized as undeclareds.

I tried this code:

testUndeclareds

| list |

lowercaseUndeclared := nil.

list := Array

with: Undeclared1

with: UndeclaredNamespace.Undeclared2

with: Graphics.Undeclared3.

^list

The names “lowercaseUndeclared” and “Undeclared1” are recognized as undeclareds and can be found in the Undeclared namespace.

However, non-resolving dotted names, being in a known or unknown namespace, are not recognized.

The browser warns about a not defined variable (with the option to correct it), but loading the code as source, parcel or from store gives no warning.

The code critic does not detect this neither.

So, does anybody know an easy way to find such undeclareds?

(The need occurrs f.ex. when removing a package namespace or renaming a namespace)

BTW, this behavior has been in VisualWorks for some time (I checked 7.6 to 7.8). 7.6 had a transcript message about undeclared “soft links”.

Cheers,

Christian

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

Karsten Kusche

Re: how to find dotted named undeclareds

Christian,

the GHUndeclaredBrowser will show you these undeclared bindings. To use it, load GHTools, go to the Launcher->Tools->GHUndeclaredBrowser, then in the "Undeclared" Menu choose "Find Undeclared BindingReferences..."

It'll take a moment to analyze your image, but it'll list the undeclared bindings.

Kind Regards

Karsten

Karsten Kusche - Dipl. Inf. - [hidden email]

Georg Heeg eK - Köthen

Handelsregister: Amtsgericht Dortmund A 12812

Am Dienstag, 31. Mai 2011 um 09:07 schrieb Christian Haider:

Cool. Thanks.

Indeed an old issue (6 years). Any news on the subject, anyone?

Christian
Von: Boris Popov, DeepCove Labs [[hidden email]]
Gesendet: Dienstag, 31. Mai 2011 09:01
An: Christian Haider; [hidden email]
Betreff: RE: [vwnc] how to find dotted named undeclareds

It’s a known issue, AR 49017 it seems,

http://osdir.com/ml/lang.smalltalk.vwnc/2005-03/msg00193.html
http://osdir.com/ml/lang.smalltalk.vwnc/2005-03/msg00186.html

-Boris

From: [hidden email] [[hidden email]] On Behalf Of Christian Haider
Sent: 31 May 2011 02:40
To: [hidden email]
Subject: [vwnc] how to find dotted named undeclareds

I just learned something unexpected: undeclared dotted names are not recognized as undeclareds.
I tried this code:

testUndeclareds
                | list |
                lowercaseUndeclared := nil.
                list := Array
                               with: Undeclared1
                               with: UndeclaredNamespace.Undeclared2
                               with: Graphics.Undeclared3.
                ^list

The names “lowercaseUndeclared” and “Undeclared1” are recognized as undeclareds and can be found in the Undeclared namespace.
However, non-resolving dotted names, being in a known or unknown namespace, are not recognized.
The browser warns about a not defined variable (with the option to correct it), but loading the code as source, parcel or from store gives no warning.
The code critic does not detect this neither.

So, does anybody know an easy way to find such undeclareds?
(The need occurrs f.ex. when removing a package namespace or renaming a namespace)

BTW, this behavior has been in VisualWorks for some time (I checked 7.6 to 7.8). 7.6 had a transcript message about undeclared “soft links”.

Cheers,
                Christian
_______________________________________________
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

Roland Wagener

Re: how to find dotted named undeclareds

In reply to this post by Christian Haider

Hi Everybody

when using VW7.7.1 or 7.8, the GHUndeclaredBrowser provides a menu for
this: 'Undeclareds->Find Undeclared BindingReferences ...'

The search may take some time, that is why we didn't include it into the
'normal' lookup for Undeclareds. The underlying implementation is using
a CodeCritics rule.

Greetings from Dortmund

Roland
--
Roland Wagener * Senior Consultant * [hidden email]
Tel: x49-231-9 75 99-26 Fax: x49-231-9 75 99-20
Georg Heeg eK Dortmund
Handelsregister: Amtsgericht Dortmund A 12812

Am 31.05.11 08:39, schrieb Christian Haider:

> I just learned something unexpected: undeclared dotted names are not
> recognized as undeclareds.
>
> I tried this code:
>
> testUndeclareds
>
> | list |
>
> lowercaseUndeclared := nil.
>
> list := Array
>
> with: Undeclared1
>
> with: UndeclaredNamespace.Undeclared2
>
> with: Graphics.Undeclared3.
>
> ^list
>
> The names “lowercaseUndeclared” and “Undeclared1” are recognized as
> undeclareds and can be found in the Undeclared namespace.
>
> However, non-resolving dotted names, being in a known or unknown
> namespace, are not recognized.
>
> The browser warns about a not defined variable (with the option to
> correct it), but loading the code as source, parcel or from store gives
> no warning.
>
> The code critic does not detect this neither.
>
> So, does anybody know an easy way to find such undeclareds?
>
> (The need occurrs f.ex. when removing a package namespace or renaming a
> namespace)
>
> BTW, this behavior has been in VisualWorks for some time (I checked 7.6
> to 7.8). 7.6 had a transcript message about undeclared “soft links”.
>
> Cheers,
>
> Christian
>
>
>
> _______________________________________________
> 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

Niall Ross

Re: how to find dotted named undeclareds

In reply to this post by Christian Haider

Dear Christian,

> Indeed an old issue (6 years). Any news on the subject, anyone?

For this cycle, I'm looking at improving some Undeclared issues, e.g.
61320 "Purging Undeclared populates it with dangling references in
uninstalled code", also the problem with Undeclared dotted references.

> I just learned something unexpected

Yes indeed: not being shown Undeclareds in namespaces violates the
principle of least surprise. The code dialog for declaring them also
differs from standard, and that is a related issue. One of the things I
want to understand is why these discrepancies existed in the first place
- are they unresolved artefacts of the introduction of namespaces or was
there an intentional motivation?

Meanwhile, the GHUndeclaredBrowser in the Heeg tools is useful. (Note
that Roland's reference to the GHUndeclaredBrowser workaround being slow
is just a remark about its implementation using a CodeCritics rule; it
is not connected to a possible motivation.)

There is a valid argument you should structure your code to avoid
needing explicit dotted references as much as possible - but of course
there are always both exceptional and "temporary" cases where you must.

Yours faithfully
Niall Ross

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

Christian Haider

Re: how to find dotted named undeclareds

In reply to this post by Christian Haider

Thanks Niall!

In the meantime I created menu picks for packages and bundles.
I also want to integrate this in my build process (checking after loading a pundle or parcel). In these cases I always start with a pundle, so the performance is not really an issue, because I don't scan the whole image.

I use the MethodCollector code from the original post which Boris found - that's fast enough for me.

Cheers,
Christian

> -----Ursprüngliche Nachricht-----
> Von: Niall Ross [mailto:[hidden email]]
> Gesendet: Mittwoch, 1. Juni 2011 16:31
> An: Christian Haider
> Cc: [hidden email]
> Betreff: Re: [vwnc] how to find dotted named undeclareds
>
> Dear Christian,
>
> > Indeed an old issue (6 years). Any news on the subject, anyone?
>
> For this cycle, I'm looking at improving some Undeclared issues, e.g.
> 61320 "Purging Undeclared populates it with dangling references in
> uninstalled code", also the problem with Undeclared dotted references.
>
> > I just learned something unexpected
>
> Yes indeed: not being shown Undeclareds in namespaces violates the
> principle of least surprise. The code dialog for declaring them also differs
> from standard, and that is a related issue. One of the things I want to
> understand is why these discrepancies existed in the first place
> - are they unresolved artefacts of the introduction of namespaces or was
> there an intentional motivation?
>
> Meanwhile, the GHUndeclaredBrowser in the Heeg tools is useful. (Note
> that Roland's reference to the GHUndeclaredBrowser workaround being
> slow is just a remark about its implementation using a CodeCritics rule; it is
> not connected to a possible motivation.)
>
> There is a valid argument you should structure your code to avoid needing
> explicit dotted references as much as possible - but of course there are
> always both exceptional and "temporary" cases where you must.
>
> Yours faithfully
> Niall Ross
>
>

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

Christian Haider

Re: how to find dotted named undeclareds

In reply to this post by Christian Haider

What the heck :-)
I just published that menu pick as RBFindDottedUndeclareds to the public store.

Cheers,
Christian

> -----Ursprüngliche Nachricht-----
> Von: [hidden email] [mailto:[hidden email]] Im
> Auftrag von Christian Haider
> Gesendet: Mittwoch, 1. Juni 2011 19:31
> An: Niall Ross
> Cc: [hidden email]
> Betreff: Re: [vwnc] how to find dotted named undeclareds
>
> Thanks Niall!
>
> In the meantime I created menu picks for packages and bundles.
> I also want to integrate this in my build process (checking after loading a
> pundle or parcel). In these cases I always start with a pundle, so the
> performance is not really an issue, because I don't scan the whole image.
>
> I use the MethodCollector code from the original post which Boris found -
> that's fast enough for me.
>
> Cheers,
> Christian
>
> > -----Ursprüngliche Nachricht-----
> > Von: Niall Ross [mailto:[hidden email]]
> > Gesendet: Mittwoch, 1. Juni 2011 16:31
> > An: Christian Haider
> > Cc: [hidden email]
> > Betreff: Re: [vwnc] how to find dotted named undeclareds
> >
> > Dear Christian,
> >
> > > Indeed an old issue (6 years). Any news on the subject, anyone?
> >
> > For this cycle, I'm looking at improving some Undeclared issues, e.g.
> > 61320 "Purging Undeclared populates it with dangling references in
> > uninstalled code", also the problem with Undeclared dotted references.
> >
> > > I just learned something unexpected
> >
> > Yes indeed: not being shown Undeclareds in namespaces violates the
> > principle of least surprise. The code dialog for declaring them also
> > differs from standard, and that is a related issue. One of the things
> > I want to understand is why these discrepancies existed in the first
> > place
> > - are they unresolved artefacts of the introduction of namespaces or
> > was there an intentional motivation?
> >
> > Meanwhile, the GHUndeclaredBrowser in the Heeg tools is useful. (Note
> > that Roland's reference to the GHUndeclaredBrowser workaround being
> > slow is just a remark about its implementation using a CodeCritics
> > rule; it is not connected to a possible motivation.)
> >
> > There is a valid argument you should structure your code to avoid
> > needing explicit dotted references as much as possible - but of course
> > there are always both exceptional and "temporary" cases where you must.
> >
> > Yours faithfully
> > Niall Ross
> >
> >
>
>
> _______________________________________________
> 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

Boris Popov, DeepCove Labs (SNN)

Re: how to find dotted named undeclareds

Now, this assumes that someone remembers to check it manually once in a while, eh? We'd simply added a test case to our suite that checks our pundles for (non)presence of undeclareds.

testUndeclaredBindings

| bundle mc filter results |
bundle := Store.Registry bundleNamed: 'Raven'.
mc := MethodCollector new.
filter := (mc methodsSelect:
[:m |
(m isKindOf: CompiledMethod) and: [((m allLiterals select: [:literal | literal isBindingReference]) reject: [:ref | ref isDefined]) notEmpty]])
& (mc methodsSelect: [:m | bundle includesMethod: (Store.MethodDescriptor fromSelector: m selector class: m mclass)]).
results := mc select: filter.
results ifNotEmpty:
[mc
openListBrowserOn: results
label: 'methods with undeclared references in Raven as detected by #testUndeclaredBindings'
initialSelection: filter initialSelection].
self assert: results isEmpty.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Christian Haider
Sent: 01 June 2011 13:37
To: Niall Ross
Cc: [hidden email]
Subject: Re: [vwnc] how to find dotted named undeclareds

What the heck :-)
I just published that menu pick as RBFindDottedUndeclareds to the public store.

Cheers,
Christian

> -----Ursprüngliche Nachricht-----
> Von: [hidden email] [mailto:[hidden email]] Im
> Auftrag von Christian Haider
> Gesendet: Mittwoch, 1. Juni 2011 19:31
> An: Niall Ross
> Cc: [hidden email]
> Betreff: Re: [vwnc] how to find dotted named undeclareds
>
> Thanks Niall!
>
> In the meantime I created menu picks for packages and bundles.
> I also want to integrate this in my build process (checking after
> loading a pundle or parcel). In these cases I always start with a
> pundle, so the performance is not really an issue, because I don't scan the whole image.
>
> I use the MethodCollector code from the original post which Boris
> found - that's fast enough for me.
>
> Cheers,
> Christian
>
> > -----Ursprüngliche Nachricht-----
> > Von: Niall Ross [mailto:[hidden email]]
> > Gesendet: Mittwoch, 1. Juni 2011 16:31
> > An: Christian Haider
> > Cc: [hidden email]
> > Betreff: Re: [vwnc] how to find dotted named undeclareds
> >
> > Dear Christian,
> >
> > > Indeed an old issue (6 years). Any news on the subject, anyone?
> >
> > For this cycle, I'm looking at improving some Undeclared issues, e.g.
> > 61320 "Purging Undeclared populates it with dangling references in
> > uninstalled code", also the problem with Undeclared dotted references.
> >
> > > I just learned something unexpected
> >
> > Yes indeed: not being shown Undeclareds in namespaces violates the
> > principle of least surprise. The code dialog for declaring them
> > also differs from standard, and that is a related issue. One of the
> > things I want to understand is why these discrepancies existed in
> > the first place
> > - are they unresolved artefacts of the introduction of namespaces or
> > was there an intentional motivation?
> >
> > Meanwhile, the GHUndeclaredBrowser in the Heeg tools is useful.
> > (Note that Roland's reference to the GHUndeclaredBrowser workaround
> > being slow is just a remark about its implementation using a
> > CodeCritics rule; it is not connected to a possible motivation.)
> >
> > There is a valid argument you should structure your code to avoid
> > needing explicit dotted references as much as possible - but of
> > course there are always both exceptional and "temporary" cases where you must.
> >
> > Yours faithfully
> > Niall Ross
> >
> >
>
>
> _______________________________________________
> 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

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