The Trunk: Tools-eem.999.mcz
Locked
 
|
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]! |
Re: 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
|
Re: The Trunk: Tools-eem.999.mcz
|
|
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
Carpe Squeak!
|
Re: The Trunk: Tools-eem.999.mcz
|
|
On Oct 13, 2020, at 7:30 AM, Thiede, Christoph <[hidden email]> wrote:
|
Re: The Trunk: Tools-eem.999.mcz
|
|
Don't forget to set the default value in ReleaseBuilder class >> #setPreferences. Best, Marcel
|
Re: The Trunk: Tools-eem.999.mcz
|
|
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 |
|
|
> 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. |
Re: The Trunk: Tools-eem.999.mcz
|
|
Hi Tim, On Tue, Oct 13, 2020 at 10:46 AM tim Rowledge <[hidden email]> wrote:
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.
_,,,^..^,,,_ best, Eliot |
Re: The Trunk: Tools-eem.999.mcz
|
|
In reply to this post by marcel.taeumel
Hi Marcel, On Tue, Oct 13, 2020 at 8:00 AM Marcel Taeumel <[hidden email]> wrote:
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, Eliot |
Re: The Trunk: Tools-eem.999.mcz
|
|
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
|
Re: The Trunk: Tools-eem.999.mcz
|
|
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
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |