The Trunk: Tools-eem.999.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Tools-eem.999.mcz

commits-2
Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.999.mcz

==================== Summary ====================

Name: Tools-eem.999
Author: eem
Time: 12 October 2020, 11:00:17.202907 am
UUID: 53fd9116-3cf5-43db-ad0d-150e7f41efd3
Ancestors: Tools-mt.998

Add a preference for automatic variable declaration in a Workspace (true by default).  Many people love this feature; I hate it :-)

=============== Diff against Tools-mt.998 ===============

Item was changed:
  StringHolder subclass: #Workspace
  instanceVariableNames: 'bindings acceptDroppedMorphs acceptAction mustDeclareVariables shouldStyle environment'
+ classVariableNames: 'DeclareVariablesAutomatically LookupPools ShouldStyle'
- classVariableNames: 'LookupPools ShouldStyle'
  poolDictionaries: ''
  category: 'Tools-Base'!
 
  !Workspace commentStamp: 'fbs 6/2/2012 20:46' prior: 0!
  A Workspace is a text area plus a lot of support for executable code.  It is a great place to execute top-level commands to compute something useful, and it is a great place to develop bits of a program before those bits get put into class methods.
 
  To open a new workspace, execute:
 
  Workspace open
 
 
  A workspace can have its own variables, called "workspace variables", to hold intermediate results.  For example, if you type into a workspace "x := 5" and do-it, then later you could type in "y := x * 2" and y would become 10.
 
  Additionally, in Morphic, a workspace can gain access to morphs that are on the screen.  If acceptDroppedMorphs is turned on, then whenever a morph is dropped on the workspace, a variable will be created which references that morph.  This functionality is toggled with the window-wide menu of a workspace.
 
 
  The instance variables of this class are:
 
  bindings  -  holds the workspace variables for this workspace
 
  acceptDroppedMorphs - whether dropped morphs should create new variables!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically (in category 'preferences') -----
+ declareVariablesAutomatically
+ <preference: 'Automatically declare variables in Workspaces'
+ category: 'browsing'
+ description: 'If true, workspaces automatically create variables.'
+ type: #Boolean>
+ ^DeclareVariablesAutomatically ifNil: [true]!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically: (in category 'preferences') -----
+ declareVariablesAutomatically: aBoolean
+ DeclareVariablesAutomatically := aBoolean!

Item was changed:
  ----- Method: Workspace>>initialize (in category 'initialize-release') -----
  initialize
 
  super initialize.
  self initializeBindings.
  acceptDroppedMorphs := false.
+ mustDeclareVariables := self class declareVariablesAutomatically not.
+ environment := Environment current!
- mustDeclareVariables := false.
- environment := Environment current.!

Item was changed:
  ----- Method: Workspace>>mustDeclareVariableWording (in category 'variable declarations') -----
  mustDeclareVariableWording
 
+ ^(mustDeclareVariables
+ ifFalse: ['<yes> automatically create variable declaration']
+ ifTrue: ['<no> automatically create variable declaration']) translated!
- ^ mustDeclareVariables not
- ifTrue: ['<yes> automatically create variable declaration' translated]
- ifFalse: ['<no> automatically create variable declaration' translated]!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

marcel.taeumel
Huh? Why should anybody want to turn this off? It should always be possible to evaluate "x := 5" and then use "x" in a Workspace. It would be really cumbersome if one always had to evaluate the entire workspace and also write those || declarations on the top. Please ... :-(

Please elaborate. Why does this feature hinders your working habits? You can always evaluate the entire workspace. This just seems like a preference that would annoy people if not set correctly. Why do you want to prevent "x := 5" evaluation. I don't understand. Why can that be dangerous?

-1 for such a preference. But I could live with it. ;-)

Best,
Marcel

Am 12.10.2020 20:00:28 schrieb [hidden email] <[hidden email]>:

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.999.mcz

==================== Summary ====================

Name: Tools-eem.999
Author: eem
Time: 12 October 2020, 11:00:17.202907 am
UUID: 53fd9116-3cf5-43db-ad0d-150e7f41efd3
Ancestors: Tools-mt.998

Add a preference for automatic variable declaration in a Workspace (true by default). Many people love this feature; I hate it :-)

=============== Diff against Tools-mt.998 ===============

Item was changed:
StringHolder subclass: #Workspace
instanceVariableNames: 'bindings acceptDroppedMorphs acceptAction mustDeclareVariables shouldStyle environment'
+ classVariableNames: 'DeclareVariablesAutomatically LookupPools ShouldStyle'
- classVariableNames: 'LookupPools ShouldStyle'
poolDictionaries: ''
category: 'Tools-Base'!

!Workspace commentStamp: 'fbs 6/2/2012 20:46' prior: 0!
A Workspace is a text area plus a lot of support for executable code. It is a great place to execute top-level commands to compute something useful, and it is a great place to develop bits of a program before those bits get put into class methods.

To open a new workspace, execute:

Workspace open


A workspace can have its own variables, called "workspace variables", to hold intermediate results. For example, if you type into a workspace "x := 5" and do-it, then later you could type in "y := x * 2" and y would become 10.

Additionally, in Morphic, a workspace can gain access to morphs that are on the screen. If acceptDroppedMorphs is turned on, then whenever a morph is dropped on the workspace, a variable will be created which references that morph. This functionality is toggled with the window-wide menu of a workspace.


The instance variables of this class are:

bindings - holds the workspace variables for this workspace

acceptDroppedMorphs - whether dropped morphs should create new variables!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically (in category 'preferences') -----
+ declareVariablesAutomatically
+
+ category: 'browsing'
+ description: 'If true, workspaces automatically create variables.'
+ type: #Boolean>
+ ^DeclareVariablesAutomatically ifNil: [true]!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically: (in category 'preferences') -----
+ declareVariablesAutomatically: aBoolean
+ DeclareVariablesAutomatically := aBoolean!

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
+ mustDeclareVariables := self class declareVariablesAutomatically not.
+ environment := Environment current!
- mustDeclareVariables := false.
- environment := Environment current.!

Item was changed:
----- Method: Workspace>>mustDeclareVariableWording (in category 'variable declarations') -----
mustDeclareVariableWording

+ ^(mustDeclareVariables
+ ifFalse: [' automatically create variable declaration']
+ ifTrue: [' automatically create variable declaration']) translated!
- ^ mustDeclareVariables not
- ifTrue: [' automatically create variable declaration' translated]
- ifFalse: [' automatically create variable declaration' translated]!




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

Christoph Thiede

Personally, I neither need nor dislike such a preference, but actually, I turned mustDeclareVariables off a small number of times for a single workspace in past. The reason was that if you use a workspace to prepare some "production" code, it beguiles you into missing some variable declarations, in particular inside of blocks, making you overlooking any unintended closure/process interconnections that do not work in actual production. I often fill a workspace with several snippets that I plan to compile into different methods. The workspace bindings add a global namespace between these snippets that does not always exist when compiling the methods at different places.


Also, one might consider it as inconvenient that every mistyped doit creates a new binding but you cannot remove this binding again without opening the window menu which interrupts the usual scripting workflow ...


However, I don't see the harm of such a preference, and I welcome adding a reasonable number of preferences whenever this can help anyone of the community to make Squeak even more convenient for yourself. We don't need to integrate every preference into the wizard, though :-)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 13. Oktober 2020 15:22:48
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: Tools-eem.999.mcz
 
Huh? Why should anybody want to turn this off? It should always be possible to evaluate "x := 5" and then use "x" in a Workspace. It would be really cumbersome if one always had to evaluate the entire workspace and also write those || declarations on the top. Please ... :-(

Please elaborate. Why does this feature hinders your working habits? You can always evaluate the entire workspace. This just seems like a preference that would annoy people if not set correctly. Why do you want to prevent "x := 5" evaluation. I don't understand. Why can that be dangerous?

-1 for such a preference. But I could live with it. ;-)

Best,
Marcel

Am 12.10.2020 20:00:28 schrieb [hidden email] <[hidden email]>:

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.999.mcz

==================== Summary ====================

Name: Tools-eem.999
Author: eem
Time: 12 October 2020, 11:00:17.202907 am
UUID: 53fd9116-3cf5-43db-ad0d-150e7f41efd3
Ancestors: Tools-mt.998

Add a preference for automatic variable declaration in a Workspace (true by default). Many people love this feature; I hate it :-)

=============== Diff against Tools-mt.998 ===============

Item was changed:
StringHolder subclass: #Workspace
instanceVariableNames: 'bindings acceptDroppedMorphs acceptAction mustDeclareVariables shouldStyle environment'
+ classVariableNames: 'DeclareVariablesAutomatically LookupPools ShouldStyle'
- classVariableNames: 'LookupPools ShouldStyle'
poolDictionaries: ''
category: 'Tools-Base'!

!Workspace commentStamp: 'fbs 6/2/2012 20:46' prior: 0!
A Workspace is a text area plus a lot of support for executable code. It is a great place to execute top-level commands to compute something useful, and it is a great place to develop bits of a program before those bits get put into class methods.

To open a new workspace, execute:

Workspace open


A workspace can have its own variables, called "workspace variables", to hold intermediate results. For example, if you type into a workspace "x := 5" and do-it, then later you could type in "y := x * 2" and y would become 10.

Additionally, in Morphic, a workspace can gain access to morphs that are on the screen. If acceptDroppedMorphs is turned on, then whenever a morph is dropped on the workspace, a variable will be created which references that morph. This functionality is toggled with the window-wide menu of a workspace.


The instance variables of this class are:

bindings - holds the workspace variables for this workspace

acceptDroppedMorphs - whether dropped morphs should create new variables!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically (in category 'preferences') -----
+ declareVariablesAutomatically
+
+ category: 'browsing'
+ description: 'If true, workspaces automatically create variables.'
+ type: #Boolean>
+ ^DeclareVariablesAutomatically ifNil: [true]!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically: (in category 'preferences') -----
+ declareVariablesAutomatically: aBoolean
+ DeclareVariablesAutomatically := aBoolean!

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
+ mustDeclareVariables := self class declareVariablesAutomatically not.
+ environment := Environment current!
- mustDeclareVariables := false.
- environment := Environment current.!

Item was changed:
----- Method: Workspace>>mustDeclareVariableWording (in category 'variable declarations') -----
mustDeclareVariableWording

+ ^(mustDeclareVariables
+ ifFalse: [' automatically create variable declaration']
+ ifTrue: [' automatically create variable declaration']) translated!
- ^ mustDeclareVariables not
- ifTrue: [' automatically create variable declaration' translated]
- ifFalse: [' automatically create variable declaration' translated]!




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

Eliot Miranda-2


On Oct 13, 2020, at 7:30 AM, Thiede, Christoph <[hidden email]> wrote:



Personally, I neither need nor dislike such a preference, but actually, I turned mustDeclareVariables off a small number of times for a single workspace in past. The reason was that if you use a workspace to prepare some "production" code, it beguiles you into missing some variable declarations, in particular inside of blocks, making you overlooking any unintended closure/process interconnections that do not work in actual production. I often fill a workspace with several snippets that I plan to compile into different methods. The workspace bindings add a global namespace between these snippets that does not always exist when compiling the methods at different places.


Also, one might consider it as inconvenient that every mistyped doit creates a new binding but you cannot remove this binding again without opening the window menu which interrupts the usual scripting workflow ...


However, I don't see the harm of such a preference, and I welcome adding a reasonable number of preferences whenever this can help anyone of the community to make Squeak even more convenient for yourself. We don't need to integrate every preference into the wizard, though :-)


+3 :-).

Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 13. Oktober 2020 15:22:48
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: Tools-eem.999.mcz
 
Huh? Why should anybody want to turn this off? It should always be possible to evaluate "x := 5" and then use "x" in a Workspace. It would be really cumbersome if one always had to evaluate the entire workspace and also write those || declarations on the top. Please ... :-(

Please elaborate. Why does this feature hinders your working habits? You can always evaluate the entire workspace. This just seems like a preference that would annoy people if not set correctly. Why do you want to prevent "x := 5" evaluation. I don't understand. Why can that be dangerous?

-1 for such a preference. But I could live with it. ;-)

Best,
Marcel

Am 12.10.2020 20:00:28 schrieb [hidden email] <[hidden email]>:

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.999.mcz

==================== Summary ====================

Name: Tools-eem.999
Author: eem
Time: 12 October 2020, 11:00:17.202907 am
UUID: 53fd9116-3cf5-43db-ad0d-150e7f41efd3
Ancestors: Tools-mt.998

Add a preference for automatic variable declaration in a Workspace (true by default). Many people love this feature; I hate it :-)

=============== Diff against Tools-mt.998 ===============

Item was changed:
StringHolder subclass: #Workspace
instanceVariableNames: 'bindings acceptDroppedMorphs acceptAction mustDeclareVariables shouldStyle environment'
+ classVariableNames: 'DeclareVariablesAutomatically LookupPools ShouldStyle'
- classVariableNames: 'LookupPools ShouldStyle'
poolDictionaries: ''
category: 'Tools-Base'!

!Workspace commentStamp: 'fbs 6/2/2012 20:46' prior: 0!
A Workspace is a text area plus a lot of support for executable code. It is a great place to execute top-level commands to compute something useful, and it is a great place to develop bits of a program before those bits get put into class methods.

To open a new workspace, execute:

Workspace open


A workspace can have its own variables, called "workspace variables", to hold intermediate results. For example, if you type into a workspace "x := 5" and do-it, then later you could type in "y := x * 2" and y would become 10.

Additionally, in Morphic, a workspace can gain access to morphs that are on the screen. If acceptDroppedMorphs is turned on, then whenever a morph is dropped on the workspace, a variable will be created which references that morph. This functionality is toggled with the window-wide menu of a workspace.


The instance variables of this class are:

bindings - holds the workspace variables for this workspace

acceptDroppedMorphs - whether dropped morphs should create new variables!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically (in category 'preferences') -----
+ declareVariablesAutomatically
+
+ category: 'browsing'
+ description: 'If true, workspaces automatically create variables.'
+ type: #Boolean>
+ ^DeclareVariablesAutomatically ifNil: [true]!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically: (in category 'preferences') -----
+ declareVariablesAutomatically: aBoolean
+ DeclareVariablesAutomatically := aBoolean!

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
+ mustDeclareVariables := self class declareVariablesAutomatically not.
+ environment := Environment current!
- mustDeclareVariables := false.
- environment := Environment current.!

Item was changed:
----- Method: Workspace>>mustDeclareVariableWording (in category 'variable declarations') -----
mustDeclareVariableWording

+ ^(mustDeclareVariables
+ ifFalse: [' automatically create variable declaration']
+ ifTrue: [' automatically create variable declaration']) translated!
- ^ mustDeclareVariables not
- ifTrue: [' automatically create variable declaration' translated]
- ifFalse: [' automatically create variable declaration' translated]!





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

marcel.taeumel
Don't forget to set the default value in ReleaseBuilder class >> #setPreferences.

Best,
Marcel

Am 13.10.2020 16:58:48 schrieb Eliot Miranda <[hidden email]>:



On Oct 13, 2020, at 7:30 AM, Thiede, Christoph <[hidden email]> wrote:



Personally, I neither need nor dislike such a preference, but actually, I turned mustDeclareVariables off a small number of times for a single workspace in past. The reason was that if you use a workspace to prepare some "production" code, it beguiles you into missing some variable declarations, in particular inside of blocks, making you overlooking any unintended closure/process interconnections that do not work in actual production. I often fill a workspace with several snippets that I plan to compile into different methods. The workspace bindings add a global namespace between these snippets that does not always exist when compiling the methods at different places.


Also, one might consider it as inconvenient that every mistyped doit creates a new binding but you cannot remove this binding again without opening the window menu which interrupts the usual scripting workflow ...


However, I don't see the harm of such a preference, and I welcome adding a reasonable number of preferences whenever this can help anyone of the community to make Squeak even more convenient for yourself. We don't need to integrate every preference into the wizard, though :-)


+3 :-).

Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 13. Oktober 2020 15:22:48
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: Tools-eem.999.mcz
 
Huh? Why should anybody want to turn this off? It should always be possible to evaluate "x := 5" and then use "x" in a Workspace. It would be really cumbersome if one always had to evaluate the entire workspace and also write those || declarations on the top. Please ... :-(

Please elaborate. Why does this feature hinders your working habits? You can always evaluate the entire workspace. This just seems like a preference that would annoy people if not set correctly. Why do you want to prevent "x := 5" evaluation. I don't understand. Why can that be dangerous?

-1 for such a preference. But I could live with it. ;-)

Best,
Marcel

Am 12.10.2020 20:00:28 schrieb [hidden email] <[hidden email]>:

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.999.mcz

==================== Summary ====================

Name: Tools-eem.999
Author: eem
Time: 12 October 2020, 11:00:17.202907 am
UUID: 53fd9116-3cf5-43db-ad0d-150e7f41efd3
Ancestors: Tools-mt.998

Add a preference for automatic variable declaration in a Workspace (true by default). Many people love this feature; I hate it :-)

=============== Diff against Tools-mt.998 ===============

Item was changed:
StringHolder subclass: #Workspace
instanceVariableNames: 'bindings acceptDroppedMorphs acceptAction mustDeclareVariables shouldStyle environment'
+ classVariableNames: 'DeclareVariablesAutomatically LookupPools ShouldStyle'
- classVariableNames: 'LookupPools ShouldStyle'
poolDictionaries: ''
category: 'Tools-Base'!

!Workspace commentStamp: 'fbs 6/2/2012 20:46' prior: 0!
A Workspace is a text area plus a lot of support for executable code. It is a great place to execute top-level commands to compute something useful, and it is a great place to develop bits of a program before those bits get put into class methods.

To open a new workspace, execute:

Workspace open


A workspace can have its own variables, called "workspace variables", to hold intermediate results. For example, if you type into a workspace "x := 5" and do-it, then later you could type in "y := x * 2" and y would become 10.

Additionally, in Morphic, a workspace can gain access to morphs that are on the screen. If acceptDroppedMorphs is turned on, then whenever a morph is dropped on the workspace, a variable will be created which references that morph. This functionality is toggled with the window-wide menu of a workspace.


The instance variables of this class are:

bindings - holds the workspace variables for this workspace

acceptDroppedMorphs - whether dropped morphs should create new variables!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically (in category 'preferences') -----
+ declareVariablesAutomatically
+
+ category: 'browsing'
+ description: 'If true, workspaces automatically create variables.'
+ type: #Boolean>
+ ^DeclareVariablesAutomatically ifNil: [true]!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically: (in category 'preferences') -----
+ declareVariablesAutomatically: aBoolean
+ DeclareVariablesAutomatically := aBoolean!

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
+ mustDeclareVariables := self class declareVariablesAutomatically not.
+ environment := Environment current!
- mustDeclareVariables := false.
- environment := Environment current.!

Item was changed:
----- Method: Workspace>>mustDeclareVariableWording (in category 'variable declarations') -----
mustDeclareVariableWording

+ ^(mustDeclareVariables
+ ifFalse: [' automatically create variable declaration']
+ ifTrue: [' automatically create variable declaration']) translated!
- ^ mustDeclareVariables not
- ifTrue: [' automatically create variable declaration' translated]
- ifFalse: [' automatically create variable declaration' translated]!





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

Stéphane Rollandin
In reply to this post by Eliot Miranda-2
I guess each of us has his own way to use a workspace. After all, it is
where one "works", and everybody works differently. So, that several
(even many) preferences may be needed is not a problem here IMO.

Stef

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

timrowledge


> On 2020-10-13, at 8:23 AM, Stéphane Rollandin <[hidden email]> wrote:
>
> I guess each of us has his own way to use a workspace. After all, it is where one "works", and everybody works differently. So, that several (even many) preferences may be needed is not a problem here IMO.
Yah.

I hate having syntax colouring in workspaces (I'm not a huge fan of it anywhere). Workspaces are not only chunks of code; they're note taking spaces. My rambling English notes do not get handled all that well.

{Now I'll admit that the idea of extending Shout to do spell/grammar checking for plain text might be interesting for non-code stuff. We did some very simple spellcheck stuff for the Sophie Project around '05 that was quite helpful - the biggest issue was getting a source of the spellcheck library. Mac's have it built in, unix has a gazillion competing and confusing systems, Windwos required you to buy Office.}

I don't like workspaces remembering variable names because it leaves values attached to names in a way that confuses.

Imagine a workspace with
"
|foo|
foo := 4.
{more stuff}


foo := somethingElse.


foo  wibble
"
Depending on whether you select the |foo| you may get very different results if you repeat evaluate various lines. I find that annoying.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Canis meus id comedit = My dog ate it.



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

Eliot Miranda-2
Hi Tim,

On Tue, Oct 13, 2020 at 10:46 AM tim Rowledge <[hidden email]> wrote:


> On 2020-10-13, at 8:23 AM, Stéphane Rollandin <[hidden email]> wrote:
>
> I guess each of us has his own way to use a workspace. After all, it is where one "works", and everybody works differently. So, that several (even many) preferences may be needed is not a problem here IMO.
Yah.

I hate having syntax colouring in workspaces (I'm not a huge fan of it anywhere). Workspaces are not only chunks of code; they're note taking spaces. My rambling English notes do not get handled all that well.

{Now I'll admit that the idea of extending Shout to do spell/grammar checking for plain text might be interesting for non-code stuff. We did some very simple spellcheck stuff for the Sophie Project around '05 that was quite helpful - the biggest issue was getting a source of the spellcheck library. Mac's have it built in, unix has a gazillion competing and confusing systems, Windwos required you to buy Office.}

I don't like workspaces remembering variable names because it leaves values attached to names in a way that confuses.

Imagine a workspace with
"
|foo|
foo := 4.
{more stuff}


foo := somethingElse.


foo  wibble
"
Depending on whether you select the |foo| you may get very different results if you repeat evaluate various lines. I find that annoying.

My hack for handling more than one doit in a workspace is to include each one in a block.  So I have, e.g.

[| cos |
cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit "SimpleStackBasedCogit"
ObjectMemory Spur32BitCoMemoryManager
MULTIPLEBYTECODESETS true), 
{#ISA. Cogit choose32BitISA}.
cos openOn: 'spurreader.image'.
cos openAsMorph; halt; run].

[| sis |
sis := StackInterpreterSimulator newWithOptions: #(ObjectMemory Spur32BitMemoryManager).
sis openOn: 'spurreader.image'.
sis openAsMorph; run].

Of course this doesn't solve the issue of having a syntax error in an earlier doit turn everything following red, but it does allow one to have as many "sub doits" with their own temps as one wants.



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Canis meus id comedit = My dog ate it.





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

Eliot Miranda-2
In reply to this post by marcel.taeumel
Hi Marcel,

On Tue, Oct 13, 2020 at 8:00 AM Marcel Taeumel <[hidden email]> wrote:
Don't forget to set the default value in ReleaseBuilder class >> #setPreferences.

If the default is unchanged, and the default value is nil, why do we have to make the setting explicit in ReleaseBuilder?  isn't there a case for having ReleaseBuilder e.g. examine all preferences stored in class vars, and simply set these class vars to nil?

Best,
Marcel

Am 13.10.2020 16:58:48 schrieb Eliot Miranda <[hidden email]>:



On Oct 13, 2020, at 7:30 AM, Thiede, Christoph <[hidden email]> wrote:



Personally, I neither need nor dislike such a preference, but actually, I turned mustDeclareVariables off a small number of times for a single workspace in past. The reason was that if you use a workspace to prepare some "production" code, it beguiles you into missing some variable declarations, in particular inside of blocks, making you overlooking any unintended closure/process interconnections that do not work in actual production. I often fill a workspace with several snippets that I plan to compile into different methods. The workspace bindings add a global namespace between these snippets that does not always exist when compiling the methods at different places.


Also, one might consider it as inconvenient that every mistyped doit creates a new binding but you cannot remove this binding again without opening the window menu which interrupts the usual scripting workflow ...


However, I don't see the harm of such a preference, and I welcome adding a reasonable number of preferences whenever this can help anyone of the community to make Squeak even more convenient for yourself. We don't need to integrate every preference into the wizard, though :-)


+3 :-).

Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 13. Oktober 2020 15:22:48
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: Tools-eem.999.mcz
 
Huh? Why should anybody want to turn this off? It should always be possible to evaluate "x := 5" and then use "x" in a Workspace. It would be really cumbersome if one always had to evaluate the entire workspace and also write those || declarations on the top. Please ... :-(

Please elaborate. Why does this feature hinders your working habits? You can always evaluate the entire workspace. This just seems like a preference that would annoy people if not set correctly. Why do you want to prevent "x := 5" evaluation. I don't understand. Why can that be dangerous?

-1 for such a preference. But I could live with it. ;-)

Best,
Marcel

Am 12.10.2020 20:00:28 schrieb [hidden email] <[hidden email]>:

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.999.mcz

==================== Summary ====================

Name: Tools-eem.999
Author: eem
Time: 12 October 2020, 11:00:17.202907 am
UUID: 53fd9116-3cf5-43db-ad0d-150e7f41efd3
Ancestors: Tools-mt.998

Add a preference for automatic variable declaration in a Workspace (true by default). Many people love this feature; I hate it :-)

=============== Diff against Tools-mt.998 ===============

Item was changed:
StringHolder subclass: #Workspace
instanceVariableNames: 'bindings acceptDroppedMorphs acceptAction mustDeclareVariables shouldStyle environment'
+ classVariableNames: 'DeclareVariablesAutomatically LookupPools ShouldStyle'
- classVariableNames: 'LookupPools ShouldStyle'
poolDictionaries: ''
category: 'Tools-Base'!

!Workspace commentStamp: 'fbs 6/2/2012 20:46' prior: 0!
A Workspace is a text area plus a lot of support for executable code. It is a great place to execute top-level commands to compute something useful, and it is a great place to develop bits of a program before those bits get put into class methods.

To open a new workspace, execute:

Workspace open


A workspace can have its own variables, called "workspace variables", to hold intermediate results. For example, if you type into a workspace "x := 5" and do-it, then later you could type in "y := x * 2" and y would become 10.

Additionally, in Morphic, a workspace can gain access to morphs that are on the screen. If acceptDroppedMorphs is turned on, then whenever a morph is dropped on the workspace, a variable will be created which references that morph. This functionality is toggled with the window-wide menu of a workspace.


The instance variables of this class are:

bindings - holds the workspace variables for this workspace

acceptDroppedMorphs - whether dropped morphs should create new variables!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically (in category 'preferences') -----
+ declareVariablesAutomatically
+
+ category: 'browsing'
+ description: 'If true, workspaces automatically create variables.'
+ type: #Boolean>
+ ^DeclareVariablesAutomatically ifNil: [true]!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically: (in category 'preferences') -----
+ declareVariablesAutomatically: aBoolean
+ DeclareVariablesAutomatically := aBoolean!

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
+ mustDeclareVariables := self class declareVariablesAutomatically not.
+ environment := Environment current!
- mustDeclareVariables := false.
- environment := Environment current.!

Item was changed:
----- Method: Workspace>>mustDeclareVariableWording (in category 'variable declarations') -----
mustDeclareVariableWording

+ ^(mustDeclareVariables
+ ifFalse: [' automatically create variable declaration']
+ ifTrue: [' automatically create variable declaration']) translated!
- ^ mustDeclareVariables not
- ifTrue: [' automatically create variable declaration' translated]
- ifFalse: [' automatically create variable declaration' translated]!






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

marcel.taeumel
Hi Eliot.

> why do we have to make the setting explicit in ReleaseBuilder

The alternative would be to implement #cleanUp(:) and clear out that variable. Sure. Your call :-)

Best,
Marcel

Am 13.10.2020 22:23:36 schrieb Eliot Miranda <[hidden email]>:

Hi Marcel,

On Tue, Oct 13, 2020 at 8:00 AM Marcel Taeumel <[hidden email]> wrote:
Don't forget to set the default value in ReleaseBuilder class >> #setPreferences.

If the default is unchanged, and the default value is nil, why do we have to make the setting explicit in ReleaseBuilder?  isn't there a case for having ReleaseBuilder e.g. examine all preferences stored in class vars, and simply set these class vars to nil?

Best,
Marcel

Am 13.10.2020 16:58:48 schrieb Eliot Miranda <[hidden email]>:



On Oct 13, 2020, at 7:30 AM, Thiede, Christoph <[hidden email]> wrote:



Personally, I neither need nor dislike such a preference, but actually, I turned mustDeclareVariables off a small number of times for a single workspace in past. The reason was that if you use a workspace to prepare some "production" code, it beguiles you into missing some variable declarations, in particular inside of blocks, making you overlooking any unintended closure/process interconnections that do not work in actual production. I often fill a workspace with several snippets that I plan to compile into different methods. The workspace bindings add a global namespace between these snippets that does not always exist when compiling the methods at different places.


Also, one might consider it as inconvenient that every mistyped doit creates a new binding but you cannot remove this binding again without opening the window menu which interrupts the usual scripting workflow ...


However, I don't see the harm of such a preference, and I welcome adding a reasonable number of preferences whenever this can help anyone of the community to make Squeak even more convenient for yourself. We don't need to integrate every preference into the wizard, though :-)


+3 :-).

Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 13. Oktober 2020 15:22:48
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: Tools-eem.999.mcz
 
Huh? Why should anybody want to turn this off? It should always be possible to evaluate "x := 5" and then use "x" in a Workspace. It would be really cumbersome if one always had to evaluate the entire workspace and also write those || declarations on the top. Please ... :-(

Please elaborate. Why does this feature hinders your working habits? You can always evaluate the entire workspace. This just seems like a preference that would annoy people if not set correctly. Why do you want to prevent "x := 5" evaluation. I don't understand. Why can that be dangerous?

-1 for such a preference. But I could live with it. ;-)

Best,
Marcel

Am 12.10.2020 20:00:28 schrieb [hidden email] <[hidden email]>:

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.999.mcz

==================== Summary ====================

Name: Tools-eem.999
Author: eem
Time: 12 October 2020, 11:00:17.202907 am
UUID: 53fd9116-3cf5-43db-ad0d-150e7f41efd3
Ancestors: Tools-mt.998

Add a preference for automatic variable declaration in a Workspace (true by default). Many people love this feature; I hate it :-)

=============== Diff against Tools-mt.998 ===============

Item was changed:
StringHolder subclass: #Workspace
instanceVariableNames: 'bindings acceptDroppedMorphs acceptAction mustDeclareVariables shouldStyle environment'
+ classVariableNames: 'DeclareVariablesAutomatically LookupPools ShouldStyle'
- classVariableNames: 'LookupPools ShouldStyle'
poolDictionaries: ''
category: 'Tools-Base'!

!Workspace commentStamp: 'fbs 6/2/2012 20:46' prior: 0!
A Workspace is a text area plus a lot of support for executable code. It is a great place to execute top-level commands to compute something useful, and it is a great place to develop bits of a program before those bits get put into class methods.

To open a new workspace, execute:

Workspace open


A workspace can have its own variables, called "workspace variables", to hold intermediate results. For example, if you type into a workspace "x := 5" and do-it, then later you could type in "y := x * 2" and y would become 10.

Additionally, in Morphic, a workspace can gain access to morphs that are on the screen. If acceptDroppedMorphs is turned on, then whenever a morph is dropped on the workspace, a variable will be created which references that morph. This functionality is toggled with the window-wide menu of a workspace.


The instance variables of this class are:

bindings - holds the workspace variables for this workspace

acceptDroppedMorphs - whether dropped morphs should create new variables!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically (in category 'preferences') -----
+ declareVariablesAutomatically
+
+ category: 'browsing'
+ description: 'If true, workspaces automatically create variables.'
+ type: #Boolean>
+ ^DeclareVariablesAutomatically ifNil: [true]!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically: (in category 'preferences') -----
+ declareVariablesAutomatically: aBoolean
+ DeclareVariablesAutomatically := aBoolean!

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
+ mustDeclareVariables := self class declareVariablesAutomatically not.
+ environment := Environment current!
- mustDeclareVariables := false.
- environment := Environment current.!

Item was changed:
----- Method: Workspace>>mustDeclareVariableWording (in category 'variable declarations') -----
mustDeclareVariableWording

+ ^(mustDeclareVariables
+ ifFalse: [' automatically create variable declaration']
+ ifTrue: [' automatically create variable declaration']) translated!
- ^ mustDeclareVariables not
- ifTrue: [' automatically create variable declaration' translated]
- ifFalse: [' automatically create variable declaration' translated]!






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-eem.999.mcz

marcel.taeumel
HI Eliot.

isn't there a case for having ReleaseBuilder e.g. examine all preferences stored in class vars, and simply set these class vars to nil?

Sorry, I hit "send" to soon. Yes, your proposal sounds better. I will add that to the ReleaseBuilder.

Best,
Marcel

Am 14.10.2020 15:06:28 schrieb Marcel Taeumel <[hidden email]>:

Hi Eliot.

> why do we have to make the setting explicit in ReleaseBuilder

The alternative would be to implement #cleanUp(:) and clear out that variable. Sure. Your call :-)

Best,
Marcel

Am 13.10.2020 22:23:36 schrieb Eliot Miranda <[hidden email]>:

Hi Marcel,

On Tue, Oct 13, 2020 at 8:00 AM Marcel Taeumel <[hidden email]> wrote:
Don't forget to set the default value in ReleaseBuilder class >> #setPreferences.

If the default is unchanged, and the default value is nil, why do we have to make the setting explicit in ReleaseBuilder?  isn't there a case for having ReleaseBuilder e.g. examine all preferences stored in class vars, and simply set these class vars to nil?

Best,
Marcel

Am 13.10.2020 16:58:48 schrieb Eliot Miranda <[hidden email]>:



On Oct 13, 2020, at 7:30 AM, Thiede, Christoph <[hidden email]> wrote:



Personally, I neither need nor dislike such a preference, but actually, I turned mustDeclareVariables off a small number of times for a single workspace in past. The reason was that if you use a workspace to prepare some "production" code, it beguiles you into missing some variable declarations, in particular inside of blocks, making you overlooking any unintended closure/process interconnections that do not work in actual production. I often fill a workspace with several snippets that I plan to compile into different methods. The workspace bindings add a global namespace between these snippets that does not always exist when compiling the methods at different places.


Also, one might consider it as inconvenient that every mistyped doit creates a new binding but you cannot remove this binding again without opening the window menu which interrupts the usual scripting workflow ...


However, I don't see the harm of such a preference, and I welcome adding a reasonable number of preferences whenever this can help anyone of the community to make Squeak even more convenient for yourself. We don't need to integrate every preference into the wizard, though :-)


+3 :-).

Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 13. Oktober 2020 15:22:48
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: Tools-eem.999.mcz
 
Huh? Why should anybody want to turn this off? It should always be possible to evaluate "x := 5" and then use "x" in a Workspace. It would be really cumbersome if one always had to evaluate the entire workspace and also write those || declarations on the top. Please ... :-(

Please elaborate. Why does this feature hinders your working habits? You can always evaluate the entire workspace. This just seems like a preference that would annoy people if not set correctly. Why do you want to prevent "x := 5" evaluation. I don't understand. Why can that be dangerous?

-1 for such a preference. But I could live with it. ;-)

Best,
Marcel

Am 12.10.2020 20:00:28 schrieb [hidden email] <[hidden email]>:

Eliot Miranda uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-eem.999.mcz

==================== Summary ====================

Name: Tools-eem.999
Author: eem
Time: 12 October 2020, 11:00:17.202907 am
UUID: 53fd9116-3cf5-43db-ad0d-150e7f41efd3
Ancestors: Tools-mt.998

Add a preference for automatic variable declaration in a Workspace (true by default). Many people love this feature; I hate it :-)

=============== Diff against Tools-mt.998 ===============

Item was changed:
StringHolder subclass: #Workspace
instanceVariableNames: 'bindings acceptDroppedMorphs acceptAction mustDeclareVariables shouldStyle environment'
+ classVariableNames: 'DeclareVariablesAutomatically LookupPools ShouldStyle'
- classVariableNames: 'LookupPools ShouldStyle'
poolDictionaries: ''
category: 'Tools-Base'!

!Workspace commentStamp: 'fbs 6/2/2012 20:46' prior: 0!
A Workspace is a text area plus a lot of support for executable code. It is a great place to execute top-level commands to compute something useful, and it is a great place to develop bits of a program before those bits get put into class methods.

To open a new workspace, execute:

Workspace open


A workspace can have its own variables, called "workspace variables", to hold intermediate results. For example, if you type into a workspace "x := 5" and do-it, then later you could type in "y := x * 2" and y would become 10.

Additionally, in Morphic, a workspace can gain access to morphs that are on the screen. If acceptDroppedMorphs is turned on, then whenever a morph is dropped on the workspace, a variable will be created which references that morph. This functionality is toggled with the window-wide menu of a workspace.


The instance variables of this class are:

bindings - holds the workspace variables for this workspace

acceptDroppedMorphs - whether dropped morphs should create new variables!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically (in category 'preferences') -----
+ declareVariablesAutomatically
+
+ category: 'browsing'
+ description: 'If true, workspaces automatically create variables.'
+ type: #Boolean>
+ ^DeclareVariablesAutomatically ifNil: [true]!

Item was added:
+ ----- Method: Workspace class>>declareVariablesAutomatically: (in category 'preferences') -----
+ declareVariablesAutomatically: aBoolean
+ DeclareVariablesAutomatically := aBoolean!

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
+ mustDeclareVariables := self class declareVariablesAutomatically not.
+ environment := Environment current!
- mustDeclareVariables := false.
- environment := Environment current.!

Item was changed:
----- Method: Workspace>>mustDeclareVariableWording (in category 'variable declarations') -----
mustDeclareVariableWording

+ ^(mustDeclareVariables
+ ifFalse: [' automatically create variable declaration']
+ ifTrue: [' automatically create variable declaration']) translated!
- ^ mustDeclareVariables not
- ifTrue: [' automatically create variable declaration' translated]
- ifFalse: [' automatically create variable declaration' translated]!






--
_,,,^..^,,,_
best, Eliot