Smalltalk › Cincom › VisualWorks

proposed change

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Stevenson, Dave (contr)

proposed change

Currently, specifying an aspect adaptor in the UIPainter saves the model definition in the spec as a concatenated symbol:

#model: #'someValueModel someAspect’

Unfortunately, the result is that the reference to #someAspect is now dynamic. That is, the concatenated symbol is parsed at run time, but the original source reference in the spec method is not statically identifiable to the refactoring engine (a rename refactoring will not consider the concatenated symbol to be a reference to #someAspect, and the reference will not be changed).

It seems that small changes to the UIPainter, UIBuilder and related code could continue to handle the old style for backward compatability, but use an array for newly generated specs that could be visible to rename refactorings:

#model: #(#someValueModel #someAspect)

A script could also be provided that would convert the old style to the new in existing spec methods, if the user desires. Will Cincom consider such a change?

Stevenson, Dave (contr) <[hidden email]>

Smalltalk Developer

Manufacturing Execution System (MES) / Shop Floor Control
El Segundo, CA

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

Paul Baumann

Re: proposed change

I second that. We use the same pattern everywhere in our code. We have to search all source code for patterns in order to find the true senders. Hidden senders like that are why cleanup happens less frequently than it should. These are the only obscure senders in our code that we could not eliminate without modifying VW.

Paul Baumann

From: [hidden email] [mailto:[hidden email]] On Behalf Of Stevenson, Dave (Contr)
Sent: Thursday, December 09, 2010 12:16
To: [hidden email]
Subject: [vwnc] proposed change

Currently, specifying an aspect adaptor in the UIPainter saves the model definition in the spec as a concatenated symbol:

#model: #'someValueModel someAspect’

#model: #(#someValueModel #someAspect)

A script could also be provided that would convert the old style to the new in existing spec methods, if the user desires. Will Cincom consider such a change?

Stevenson, Dave (contr) <[hidden email]>

Smalltalk Developer

Manufacturing Execution System (MES) / Shop Floor Control
El Segundo, CA

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

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

Thomas Brodt

Re: proposed change

In reply to this post by Stevenson, Dave (contr)

Dave is so right. Every so often we have the same Problem. Especially because lens makes extensive use of it.

So please Count my vote As at least +3 ;-)

Thomas

Am 09.12.2010 um 18:15 schrieb "Stevenson, Dave (Contr)" <[hidden email]>:

Currently, specifying an aspect adaptor in the UIPainter saves the model definition in the spec as a concatenated symbol:
#model: #'someValueModel someAspect’

Unfortunately, the result is that the reference to #someAspect is now dynamic. That is, the concatenated symbol is parsed at run time, but the original source reference in the spec method is not statically identifiable to the refactoring engine (a rename refactoring will not consider the concatenated symbol to be a reference to #someAspect, and the reference will not be changed).

It seems that small changes to the UIPainter, UIBuilder and related code could continue to handle the old style for backward compatability, but use an array for newly generated specs that could be visible to rename refactorings:
#model: #(#someValueModel #someAspect)

A script could also be provided that would convert the old style to the new in existing spec methods, if the user desires. Will Cincom consider such a change?

Stevenson, Dave (contr) <[hidden email]>
Smalltalk Developer
Manufacturing Execution System (MES) / Shop Floor Control
El Segundo, CA

_______________________________________________
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

Joerg Beekmann, DeepCove Labs (YVR)

Re: proposed change

In reply to this post by Stevenson, Dave (contr)

Good idea

From: [hidden email] [mailto:[hidden email]] On Behalf Of Stevenson, Dave (Contr)
Sent: Thursday, December 09, 2010 9:16 AM
To: [hidden email]
Subject: [vwnc] proposed change

Currently, specifying an aspect adaptor in the UIPainter saves the model definition in the spec as a concatenated symbol:

#model: #'someValueModel someAspect’

#model: #(#someValueModel #someAspect)

A script could also be provided that would convert the old style to the new in existing spec methods, if the user desires. Will Cincom consider such a change?

Stevenson, Dave (contr) <[hidden email]>

Smalltalk Developer

Manufacturing Execution System (MES) / Shop Floor Control
El Segundo, CA

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

Reinout Heeck-2

Re: proposed change

In reply to this post by Stevenson, Dave (contr)

At Soops we patched the system ages ago to handle these embedded
references somewhat more gracefully.
It is a must-have to be able to properly navigate your code (senders
of), decide whether code is dead and of course to do refactorings.

+1 to the proposal, with the remark that the system can be made to
handle the current string format more gracefully too.
So it seems that switch-over technology is not really needed if effort
is spent in making the system handle the current format.

What we still haven't patched here is the related problem of finding
references from post-load blocks etc.
So there's another proposal :-)

R
-

--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************

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

Michael Lucas-Smith-2

Re: proposed change

>
> What we still haven't patched here is the related problem of finding
> references from post-load blocks etc.
> So there's another proposal :-)
>

Searchlight searches the blocks on packages for those things.

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

Boris Popov, DeepCove Labs (SNN)

Re: proposed change

That doesn't help rewrite tools or safe-checking during remove, for
example. It'd be best to move those to first-class objects somewhere in
the long term.

-Boris

--
DeepCove Labs Ltd.
+1 (604) 689-0322
4th floor, 595 Howe Street
Vancouver, British Columbia
Canada V6C 2T5
http://tinyurl.com/r7uw4

PacNet Services (Europe) Ltd.
+353 (0)61 714-360
Shannon Airport House, SFZ
County Clare, Ireland
http://tinyurl.com/y952amr

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Michael Lucas-Smith
Sent: 10 December 2010 15:26
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] proposed change

>
> What we still haven't patched here is the related problem of finding
> references from post-load blocks etc.
> So there's another proposal :-)
>

Searchlight searches the blocks on packages for those things.

Michael
_______________________________________________
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

Paul Baumann

Re: proposed change

The change isn't complicated. First add the ability to recognize the literal arrays in addition to the current string form. Then change the windowSpec generation to use the new form when specs are saved. Finally, provide an upgrade script that can be run to resave the existing window specs. The last step is recommended for customers but would be optional.

A "rewrite tools" alternative has the same migration steps but is vastly more complicated than what is needed. I wouldn't want some pie in the sky solution (that takes years and ultimately fails in risk) instead of simply extending the encoding options of one field definition in a literal array.

Paul Baumann

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Boris Popov, DeepCove Labs
Sent: Friday, December 10, 2010 10:30
To: Michael Lucas-Smith; Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] proposed change
Importance: Low

That doesn't help rewrite tools or safe-checking during remove, for
example. It'd be best to move those to first-class objects somewhere in
the long term.

-Boris

--
DeepCove Labs Ltd.
+1 (604) 689-0322
4th floor, 595 Howe Street
Vancouver, British Columbia
Canada V6C 2T5
http://tinyurl.com/r7uw4

PacNet Services (Europe) Ltd.
+353 (0)61 714-360
Shannon Airport House, SFZ
County Clare, Ireland
http://tinyurl.com/y952amr

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Michael Lucas-Smith
Sent: 10 December 2010 15:26
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] proposed change

>
> What we still haven't patched here is the related problem of finding
> references from post-load blocks etc.
> So there's another proposal :-)
>

Searchlight searches the blocks on packages for those things.

Michael
_______________________________________________
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

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

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

Boris Popov, DeepCove Labs (SNN)

Re: proposed change

Paul,

My comment was exclusively related to Michael's note about Searchlight
including code blocks on pundles in its search scope, which is a
separate trail that Reinout had started.

Regards,

-Boris

--
DeepCove Labs Ltd.
+1 (604) 689-0322
4th floor, 595 Howe Street
Vancouver, British Columbia
Canada V6C 2T5
http://tinyurl.com/r7uw4

PacNet Services (Europe) Ltd.
+353 (0)61 714-360
Shannon Airport House, SFZ
County Clare, Ireland
http://tinyurl.com/y952amr

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

-----Original Message-----
From: Paul Baumann [mailto:[hidden email]]
Sent: 10 December 2010 16:21
To: Boris Popov, DeepCove Labs; Michael Lucas-Smith; Reinout Heeck
Cc: [hidden email]
Subject: RE: [vwnc] proposed change

The change isn't complicated. First add the ability to recognize the
literal arrays in addition to the current string form. Then change the
windowSpec generation to use the new form when specs are saved. Finally,
provide an upgrade script that can be run to resave the existing window
specs. The last step is recommended for customers but would be optional.

A "rewrite tools" alternative has the same migration steps but is vastly
more complicated than what is needed. I wouldn't want some pie in the
sky solution (that takes years and ultimately fails in risk) instead of
simply extending the encoding options of one field definition in a
literal array.

Paul Baumann

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov, DeepCove Labs
Sent: Friday, December 10, 2010 10:30
To: Michael Lucas-Smith; Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] proposed change
Importance: Low

That doesn't help rewrite tools or safe-checking during remove, for
example. It'd be best to move those to first-class objects somewhere in
the long term.

-Boris

--
DeepCove Labs Ltd.
+1 (604) 689-0322
4th floor, 595 Howe Street
Vancouver, British Columbia
Canada V6C 2T5
http://tinyurl.com/r7uw4

PacNet Services (Europe) Ltd.
+353 (0)61 714-360
Shannon Airport House, SFZ
County Clare, Ireland
http://tinyurl.com/y952amr

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Michael Lucas-Smith
Sent: 10 December 2010 15:26
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] proposed change

>
> What we still haven't patched here is the related problem of finding
> references from post-load blocks etc.
> So there's another proposal :-)
>

Searchlight searches the blocks on packages for those things.

Michael
_______________________________________________
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

This message may contain confidential information and is intended for
specific recipients unless explicitly noted otherwise. If you have
reason to believe you are not an intended recipient of this message,
please delete it and notify the sender. This message may not represent
the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or
affiliates, and does not constitute a contract or guarantee. Unencrypted
electronic mail is not secure and the recipient of this message is
expected to provide safeguards from viruses and pursue alternate means
of communication where privacy or a binding message is desired.

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

Hildebrant, Richard

Launching VW7.7.1NC Problematic?

Hello,
I just successfully installed vw7.7.1 on my Windows machine and
tried launching my first saved .im file like I always do, by
double-clicking on it. But now a blank window pops up and will not be
dismissed, forcing me to power down the computer and restarting. The
new "Visualworks Projects" launcher seems to work, but I find this tool
fairly limited at this point and does really fit my work flow. Did I
miss the memo, or is there some known problem I'm not aware of?

Any advice/pointers appreciated.

Thanks,
Rick

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

Steven Kelly

Re: Launching VW7.7.1NC Problematic?

[vwnc] Launching VW7.7.1NC Problematic?

I've not seen or heard of any problems, other than with very large images - see Resolution 99000 http://www.cincomsmalltalk.com/ResolutionsApplication/CincomResolutionsPortal.

Make sure your Windows file association for .im points to the 7.7.1 bin\win\VisualWorks.exe, and that the VisualWorks.ini in that directory has the right path for the executables of each VW version.

Steve

From: [hidden email] on behalf of Hildebrant, Richard
Sent: Fri 10/12/2010 23:36
To: [hidden email]
Subject: [vwnc] Launching VW7.7.1NC Problematic?

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

Alan Knight-2

Re: Launching VW7.7.1NC Problematic?

In reply to this post by Hildebrant, Richard

I'd be suspicious that when you double-click on it you're getting an old
version of the VM. Either that or your image was not saved properly. Try
launching it from the command line and seeing if it works properly when
you're specifying the correct VM explicitly. If it works, I'd look at
what your file association is with .im files.

On 2010-12-10 4:36 PM, Hildebrant, Richard wrote:

> Hello,
> I just successfully installed vw7.7.1 on my Windows machine and
> tried launching my first saved .im file like I always do, by
> double-clicking on it. But now a blank window pops up and will not be
> dismissed, forcing me to power down the computer and restarting. The
> new "Visualworks Projects" launcher seems to work, but I find this tool
> fairly limited at this point and does really fit my work flow. Did I
> miss the memo, or is there some known problem I'm not aware of?
>
> Any advice/pointers appreciated.
>
> Thanks,
> Rick
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

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

Paul Baumann

Re: proposed change

In reply to this post by Stevenson, Dave (contr)

Dave Stevenson had proposal this change over three years ago. Yesterday checked VW 7.8 and found it was not implemented as late as that release, so I implemented it today. You can find the code in the Cincom Public Repository as a package named PlbSearchableCompositeAspects. It seems to work fine, but no promises. Look to package comments for details. If you find a problem then please share your fix.

The code provides basic support for composite keys to be stored as arrays. UIBuilder is also made compatible with them. This code does not contain any script to refactor your specs to use arrays. Someone else could probably offer some simple refactoring syntax to accomplish that if you desire. You can specify that you want a composite key to save as an array by putting parenthesis around the message sends; for example, "selectedRow name" would be changed to "(selectedRow name)" when editing the aspect/model field with UIBuilder. If you want a composite key to be saved as an array by default then execute (TypeConverter preferArrayCompositeKeys: true).

If this functionality proves popular then hopefully Cincom will make it part of their product.

Paul Baumann

From: [hidden email] [mailto:[hidden email]] On Behalf Of Stevenson, Dave (Contr)
Sent: Thursday, December 09, 2010 12:16
To: [hidden email]
Subject: [vwnc] proposed change

Currently, specifying an aspect adaptor in the UIPainter saves the model definition in the spec as a concatenated symbol:

#model: #'someValueModel someAspect’

#model: #(#someValueModel #someAspect)

A script could also be provided that would convert the old style to the new in existing spec methods, if the user desires. Will Cincom consider such a change?

Stevenson, Dave (contr) <[hidden email]>

Smalltalk Developer

Manufacturing Execution System (MES) / Shop Floor Control
El Segundo, CA