Squeak-dev March 2010

squeak-dev@lists.squeakfoundation.org

158 participants
767 discussions

Regarding backwards compatibility
by Ken G. Brown 02 Mar '10

02 Mar '10

The current discussion about SmalltalkImage current vs Smalltalk etc., has reminded me of a previous discussion of a few years few years ago on vm-dev. I had run across the following very confusing naming conventions while attempting to compile a vm and I posted some comments: >I was rooting around everywhere learning where things happened and it being the first time through, I was initially confused by the following: > >internal plugin B3DEnginePlugin generated as Squeak3D >internal plugin BalloonEnginePlugin generated as B2DPlugin >internal plugin BitBltSimulation generated as BitBltPlugin >internal plugin DSAPlugin generated as DSAPrims >internal plugin DeflatePlugin generated as ZipPlugin >internal plugin FFIPlugin generated as SqueakFFIPrims >internal plugin KlattSynthesizerPlugin generated as Klatt >internal plugin LargeIntegersPlugin generated as LargeIntegers I was told more or less that it was because of backwards compatibility that this ongoing source of confusion is allowed to continue. I responded in part with the following: At 7:45 PM -0600 5/6/07, Ken G. Brown apparently wrote: > It seems to me that back compatibility is most often a big anchor on moving forward. Those that want/need back compatibility are always free to stay in the past with whatever version they last had. In the long term, if compromises are always made in the direction of back compatibility, I think that the overall quality of the system is of course, 'compromised'. > >Similarly, if decisions are always made in the direction of 'the simplest thing that could possibly work', in the long run you end up with bunch of stuff that perhaps only 'simply' works. This 'simplest thing' idea is great for prototyping or testing out ideas, but one needs to always remember to go back and clean up after. > >Perhaps a better rule of thumb is 'doing the best thing in the best possible way'. The semantics can be argued forever tho. > >And since I seem to be on a roll here, if you always buy cheap tools, in the long run you end up surrounded with a bunch of cheap junk that when you really need to get a job done, the tool either breaks or does a crappy job. > >And if you always patch things instead of repairing properly, pretty soon you are surrounded with patched stuff everywhere, all on the verge of failure. > >Yeah, yeah, I know, need to define 'repair properly', 'best thing', 'best possible way', etc. I think that backwards compatibility should take second or third place in the current discussions about SmalltalkImage current vs Smalltalk. I am of course not advocating breaking things for frivolous reasons, especially if there are good alternatives available. However, for important decisions moving forward, I AM advocating 'doing the best thing in the best possible way', to the best of our abilities. Ken G. Brown

1 0

Parsing problem in trunk image
by Chris Muller 02 Mar '10

02 Mar '10

BlockNode comments appear to be getting cascaded into all child BlockNodes. To see an example, open the method: BlockNode>>#printOn:indent: Shift + Yellow-click in the code pane, select "pretty print". Notice how the comment: "If >0 temps and >1 statement, put all statements on separate lines" is now repeated within each of the ifTrue:ifFalse: blocks?! It looks like the problem is related to the fact that the parse tree has the comment in each of those sub-nodes, so it therefore gets printed three times. This bug is painful for me, I use pretty print constantly to make the computer to format my code for me so I type fast and sloppy. Who broke this?

2 1

[OT] Squeak
by Alexander Lazarević 02 Mar '10

02 Mar '10

Sometimes I wish Squeak would feel like this again [1] :D [1] http://www.youtube.com/watch?v=qybUFnY7Y8w

2 1

[Election] 11 candidates! One more day for candidates
by Göran Krampe 02 Mar '10

02 Mar '10

Hi all! Really nice to see that a few brave souls :) stepped up and we now have a whopping 11 candidates to choose among. That is a good number! A few remarks: - Tomorrow will be the day when I finalize the list of candidates. So hurry up if you want to be a candidate! - If you want to participate in the election you need to get onto the voters list, UNLESS you voted last year, then you are already on. See header "Voter list" on: http://wiki.squeak.org/squeak/6150 - From tomorrow we enter the "Continued campaigning period" until the 10th where the actual election starts! regards, Göran

1 0

unsaved changes indicator
by radoslav hodnicak 02 Mar '10

02 Mar '10

Which update introduced the orange triangle in the window corner instead of the red outline? It doesn't really work for me 'cause that one corner might be covered by other windows and the visual clue is lost. What was wrong with the red outline anyway? rado

7 9

The Trunk: Tools-laza.197.mcz
by commits＠source.squeak.org 02 Mar '10

02 Mar '10

Alexander Lazarević uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-laza.197.mcz ==================== Summary ==================== Name: Tools-laza.197 Author: laza Time: 2 March 2010, 9:38:57.497 am UUID: daad2fed-9081-1e4d-9d3f-2dc663758af6 Ancestors: Tools-dtl.196 Removed the source button from the debugger, because any selection (but tiles -> error) only showed an emtpy code pane. =============== Diff against Tools-dtl.196 =============== Item was added: + ----- Method: Debugger>>addCodeProvenanceButtonTo:using: (in category 'toolbuilder') ----- + addCodeProvenanceButtonTo: panelSpec using: builder + "No thanks!!"! Item was changed: ----- Method: CodeHolder>>buildOptionalButtonsWith: (in category 'toolbuilder') ----- buildOptionalButtonsWith: builder | panelSpec | panelSpec := builder pluggablePanelSpec new. panelSpec children: OrderedCollection new. self optionalButtonPairs do:[:spec| | buttonSpec | buttonSpec := builder pluggableActionButtonSpec new. buttonSpec model: self. buttonSpec label: spec first. buttonSpec action: spec second. spec second == #methodHierarchy ifTrue:[ buttonSpec color: #inheritanceButtonColor. ]. spec size > 2 ifTrue:[buttonSpec help: spec third]. panelSpec children add: buttonSpec. ]. "What to show" + self addCodeProvenanceButtonTo: panelSpec using: builder. - panelSpec children add: (self buildCodeProvenanceButtonWith: builder). panelSpec layout: #horizontal. "buttons" ^panelSpec! Item was added: + ----- Method: CodeHolder>>addCodeProvenanceButtonTo:using: (in category 'toolbuilder') ----- + addCodeProvenanceButtonTo: panelSpec using: builder + panelSpec children add: (self buildCodeProvenanceButtonWith: builder)!

1 0

Re: [squeak-dev] IMPORTANT: Election candidates!
by Gary Dunn 02 Mar '10

02 Mar '10

On Mon, 01 Mar 2010 11:52:51 +0100 Goran Krampe <goran(a)krampe.se> wrote: > Now, people - please step forward as candidates or please express your > feelings about my thoughts above. > I'll step foward even though I still feel like a newb compared to many of you. I have a demanding full time IT job as well as other interests in music, cycling, and old cars. After all that I run the Open Slate Project. My interest in Squeak is to make it the software platform for Open Slate. I admit I still have much to learn, and am willing to help in whatever way I can. -- Gary Dunn, Honolulu osp(a)aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from a Newton 2100 via Mail V

2 1

[ANN] FunSqueak was updated
by Edgar J. De Cleene 02 Mar '10

02 Mar '10

As I said this morning the check of the image was fine, so I put into the ftp. http://ftp.squeak.org/various_images/FunSqueak/FunSqueak3.11-9553-alpha.zip Fixed the troubles with sources the drag and drop of project and the dictionary keys problem. Into the image 3.6 Games, The mixed curves project (Jerome) Rompecabezas Mathmorphs and MorphicWrappers IRC Scamper For the next week I study how to put Stéphane Rollandin muO amazing project Edgar

3 4

IMPORTANT: Election candidates!
by Göran Krampe 02 Mar '10

02 Mar '10

Hi all! As you know we have an ongoing campaigning period for the Election 2010 that ends on the 3rd of march! This means time is short and AFAIK (unless I missed someone, please tell me) we have 6 candidates for 7 seats! Unless we get more than 7 candidates there are three scenarios: - Go through with the election process (to see how they rate against each other) anyway. Kinda pointless. - Skip the rest of the election and just take the 6 we have! - Lower the number of seats in the board and go through with the election. ...ehm, or something else really clever. :) Now, people - please step forward as candidates or please express your feelings about my thoughts above. regards, Göran

5 17

The Trunk: Morphic-ar.369.mcz
by commits＠source.squeak.org 02 Mar '10

02 Mar '10

Andreas Raab uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-ar.369.mcz ==================== Summary ==================== Name: Morphic-ar.369 Author: ar Time: 1 March 2010, 10:01:12.336 pm UUID: 375d76a2-472e-aa4c-9550-87bdfad95737 Ancestors: Morphic-tfel.367, Morphic-ar.368 Merging Morphic-tfel.367 Do not apply gradients on menus more than once. This fixes a bug where submenus got increasingly whiter with gradient menus activated after opening and closing them several times. (Without closing the parent menu) =============== Diff against Morphic-ar.368 =============== Item was changed: ----- Method: MenuMorph>>updateColor (in category 'control') ----- updateColor | fill title | Preferences gradientMenu ifFalse: [^ self]. + (self fillStyle == self color) not + ifTrue: [^ self]. "Don't apply the gradient more than once" "" fill := GradientFillStyle ramp: {0.0 -> Color white. 1 -> self color}. "" fill radial: false; origin: self topLeft; direction: 0 @ self height. "" self fillStyle: fill. " update the title color" title := self allMorphs detect: [:each | each hasProperty: #titleString] ifNone: [^ self]. "" fill := GradientFillStyle ramp: {0.0 -> title color twiceLighter. 1 -> title color twiceDarker}. "" fill origin: title topLeft; direction: title width @ 0. "" title fillStyle: fill!

1 0

Jump to page: