Squeak-dev June 2013

squeak-dev@lists.squeakfoundation.org

45 participants
215 discussions

The Trunk: Tests-fbs.223.mcz
by commits＠source.squeak.org 22 Jun '13

22 Jun '13

Frank Shearar uploaded a new version of Tests to project The Trunk: http://source.squeak.org/trunk/Tests-fbs.223.mcz ==================== Summary ==================== Name: Tests-fbs.223 Author: fbs Time: 22 June 2013, 9:27:23.106 pm UUID: 1071830c-df03-470d-8967-9ddca73e3753 Ancestors: Tests-fbs.222 Test for reported Decompiler bug http://bugs.squeak.org/view.php?id=7771 Marked as an expected failure because we don't know when/if we'll fix this edge case. =============== Diff against Tests-fbs.222 =============== Item was added: + ----- Method: DecompilerTests>>expectedFailures (in category 'testing') ----- + expectedFailures + ^ #(testDecompileUnreachableParameter)! Item was added: + ----- Method: DecompilerTests>>testDecompileUnreachableParameter (in category 'tests') ----- + testDecompileUnreachableParameter + "DecompilerTests new testDecompileUnreachableParameter" + "The call to #value: is unreachable because both blocks in the #ifTrue:ifFalse: send force a return." + self shouldnt: [[self value: (true ifTrue: [^true] ifFalse: [^false])] decompile] raise: Error.!

1 0

Re: [squeak-dev] The Trunk: Tools-eem.471.mcz
by Chris Muller 22 Jun '13

22 Jun '13

This would seem to change the capability that a browser can have the same message in the list more than once. Is this to support some functionality? Or just a "clean up"? On Fri, Jun 14, 2013 at 3:55 PM, <commits(a)source.squeak.org> wrote: > Eliot Miranda uploaded a new version of Tools to project The Trunk: > http://source.squeak.org/trunk/Tools-eem.471.mcz > > ==================== Summary ==================== > > Name: Tools-eem.471 > Author: eem > Time: 14 June 2013, 1:55:19.221 pm > UUID: f14f2736-5c49-41d5-ab67-fddee7e61176 > Ancestors: Tools-fbs.470 > > Update multi-window browser switching now browsers no > longer use integer indices, and instead use the relevant > symbols themselves. > > =============== Diff against Tools-fbs.470 =============== > > Item was changed: > ----- Method: Browser>>restoreToCategory:className:protocol:selector:mode:meta: (in category 'multi-window support') ----- > restoreToCategory: category className: className protocol: protocol selector: selector mode: editMode meta: metaBool > + selectedSystemCategory := nil. "forces recomputation in selectSystemCategory:" > self selectSystemCategory: category. > + self selectClassNamed: className. > - self classListIndex: (self classListIndexOf: className). > self metaClassIndicated: metaBool. > + self selectMessageCategoryNamed: protocol. > + self selectMessageNamed: selector. > - self messageCategoryListIndex: (self messageCategoryList indexOf: protocol). > - self messageListIndex: (self messageList indexOf: selector). > editSelection := editMode. > self > contentsChanged; > decorateButtons! > >

3 3

Closing old tickets (was Re: [squeak-dev] The Trunk: Files-tpr.123.mcz)
by Frank Shearar 22 Jun '13

22 Jun '13

On 22 June 2013 12:56, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 22 Jun 2013, Frank Shearar wrote: > >> On 22 June 2013 01:40, <commits(a)source.squeak.org> wrote: >>> >>> tim Rowledge uploaded a new version of Files to project The Trunk: >>> http://source.squeak.org/trunk/Files-tpr.123.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Files-tpr.123 >>> Author: tpr >>> Time: 21 June 2013, 5:40:33.465 pm >>> UUID: b3983780-394c-464b-8924-b70282415bfe >>> Ancestors: Files-fbs.122 >>> >>> Fix bug reported in mantis ttp://bugs.squeak.org/view.php?id=7740 >>> FileTestUrl should now pass >>> >>> =============== Diff against Files-fbs.122 =============== >> >> >> >> Gold star to Tim! Actual bug reports! This is how it should be done! > > > Almost :). The status should be resolved, not closed. We used to close the > resolved issues after a new release (and that's when we used to change the > version tag to an actual version number from "trunk", because "trunk" is > intended to be used for issues in the current trunk). I think this hasn't > happened yet with the 4.4 release. This is true. So we should close all 'trunk' tickets with update dates before 31 December 2012 (the date we released 4.4). Sound good? frank > Levente > > >> (Also, in case that sounds patronising I really don't mean it to be. I >> mean it in the "yay, someone's doing exactly the right thing" tone of >> voice, and I believe in telling people when they do the right thing.) >> >> Regarding your note in the ticket, we won't have a tag for 4.5 because >> "4.5" means "bugs in the released 4.5". Since 4.5 hasn't been >> released, bugs in the current trunk just get the "trunk" label. >> >> frank >> >> >

1 0

Re: [squeak-dev] The Trunk: Files-tpr.123.mcz
by Frank Shearar 22 Jun '13

22 Jun '13

On 22 June 2013 01:40, <commits(a)source.squeak.org> wrote: > tim Rowledge uploaded a new version of Files to project The Trunk: > http://source.squeak.org/trunk/Files-tpr.123.mcz > > ==================== Summary ==================== > > Name: Files-tpr.123 > Author: tpr > Time: 21 June 2013, 5:40:33.465 pm > UUID: b3983780-394c-464b-8924-b70282415bfe > Ancestors: Files-fbs.122 > > Fix bug reported in mantis ttp://bugs.squeak.org/view.php?id=7740 > FileTestUrl should now pass > > =============== Diff against Files-fbs.122 =============== Gold star to Tim! Actual bug reports! This is how it should be done! (Also, in case that sounds patronising I really don't mean it to be. I mean it in the "yay, someone's doing exactly the right thing" tone of voice, and I believe in telling people when they do the right thing.) Regarding your note in the ticket, we won't have a tag for 4.5 because "4.5" means "bugs in the released 4.5". Since 4.5 hasn't been released, bugs in the current trunk just get the "trunk" label. frank

2 1

The Trunk: Files-tpr.123.mcz
by commits＠source.squeak.org 22 Jun '13

22 Jun '13

tim Rowledge uploaded a new version of Files to project The Trunk: http://source.squeak.org/trunk/Files-tpr.123.mcz ==================== Summary ==================== Name: Files-tpr.123 Author: tpr Time: 21 June 2013, 5:40:33.465 pm UUID: b3983780-394c-464b-8924-b70282415bfe Ancestors: Files-fbs.122 Fix bug reported in mantis ttp://bugs.squeak.org/view.php?id=7740 FileTestUrl should now pass =============== Diff against Files-fbs.122 =============== Item was changed: ----- Method: AcornFileDirectory>>pathParts (in category 'path access') ----- pathParts "Return the path from the root of the file system to this directory as an array of directory names. This version tries to cope with the RISC OS' strange filename formatting; filesystem::discname/$/path/to/file where the $ needs to be considered part of the filingsystem-discname atom." | pathList | pathList := super pathParts. (pathList indexOf: '$') = 2 ifTrue: ["if the second atom is root ($) then stick $ on the first atom and drop the second. Yuck" + ^ pathList species - ^ Array streamContents: [:a | a nextPut: (pathList at: 1), '/$'. 3 to: pathList size do: [:i | a nextPut: (pathList at: i)]]]. ^ pathList!

1 0

Smalltalk development tools in Scratch
by H. Hirzel 22 Jun '13

22 Jun '13

> > Treat me like a beginner. I have two targets: > > 1. I want to document the source code of Scratch. > > 2. I want to modify Scratch. > > ... > You change code using browsers in Smalltalk itself. It's not a good idea > to > try to change code in the files. .... > You create new classes using a Smalltalk browser. While you could use a > file and file in the file it's not a good idea to change code in files. > > > > Squeak by Example [8] talks about a 'hierarchy browser' which is easy to > find with the files provided with it. Is there a similar kind of thing to > explore Scratch objects? If yes, how to get to it. If no, how do can I > trace > the hierarchy of inheritance objects used to make Scratch. Yes, you can 'get behind the scenes in Scratch' by using a 'rabbit hole' as Markus Gaelli wrote http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-January/168424.… "You know that you can "shift click" into the top half of the R of SCRATCH on the top left of Scratch -- then open the rabbit hole via "turn fill screen off"... The thread in January 2013 started by Stephane Rollandin asking http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-January/168401.… <citation> Hello, I'm currently studying the Scratch code. The image I have (the BYOB 1.3 image) has a Smalltalk version of 'MIT Squeak 0.9.4 (June 1, 2003)'. How could I find the original corresponding base Squeak image (that is, the same image without Scratch code) ? Stef </citation> HTH --Hannes

5 7

Re: [squeak-dev] The Trunk: Morphic-eem.658.mcz
by Chris Muller 22 Jun '13

22 Jun '13

Why do you want to disable pane-splitters? On Thu, Jun 13, 2013 at 5:54 PM, <commits(a)source.squeak.org> wrote: > Eliot Miranda uploaded a new version of Morphic to project The Trunk: > http://source.squeak.org/trunk/Morphic-eem.658.mcz > > ==================== Summary ==================== > > Name: Morphic-eem.658 > Author: eem > Time: 13 June 2013, 3:54:13.852 pm > UUID: faf57af4-504d-42f3-b7fa-afd6fed1608d > Ancestors: Morphic-eem.657 > > Allow creartion of windows without pane splitters via an > #allowPaneSplitters property that defaults to true. i.e. to > disable pane splitters use > win setProperty: #allowPaneSplitters toValue: false > Get PluggableTextMorph>>doIt to answer its result. > > =============== Diff against Morphic-eem.657 =============== > > Item was changed: > ----- Method: PluggableTextMorph>>doIt (in category 'menu commands') ----- > doIt > + ^self handleEdit: [textMorph editor evaluateSelection]! > - self handleEdit: [textMorph editor evaluateSelection]! > > Item was changed: > ----- Method: SystemWindow>>addMorph:fullFrame: (in category 'panes') ----- > addMorph: aMorph fullFrame: aLayoutFrame > + "Add aMorph according to aLayoutFrame." > + | windowBorderWidth | > - > - | left right bottom top windowBorderWidth | > windowBorderWidth := self class borderWidth. > + "If the property #allowPaneSplitters is set to false, do *not* inset morphs by the borderWidth > + to make room for splitters. This allows windows with non-traditional contents to avoid their > + component morphs from being clipped. Do *NOT* remove this code please!! Just because > + there may be no setters of allowPaneSplitters to false in the image doesn't mean they're not > + out there. Thanks!! eem 6/13/2013" > + (self valueOfProperty: #allowPaneSplitters ifAbsent: [true]) ifTrue: > + [| left right bottom top | > > + left := aLayoutFrame leftOffset ifNil: [0]. > + right := aLayoutFrame rightOffset ifNil: [0]. > - left := aLayoutFrame leftOffset ifNil: [0]. > - right := aLayoutFrame rightOffset ifNil: [0]. > > + bottom := aLayoutFrame bottomOffset ifNil: [0]. > + top := aLayoutFrame topOffset ifNil: [0]. > + > + aLayoutFrame rightFraction = 1 ifTrue: [aLayoutFrame rightOffset: right - windowBorderWidth]. > + aLayoutFrame leftFraction = 0 > + ifTrue: [aLayoutFrame leftOffset: left + windowBorderWidth] > + ifFalse: [aLayoutFrame leftOffset: left + ProportionalSplitterMorph splitterWidth]. > - bottom := aLayoutFrame bottomOffset ifNil: [0]. > - top := aLayoutFrame topOffset ifNil: [0]. > - > - aLayoutFrame rightFraction = 1 ifTrue: [aLayoutFrame rightOffset: right - windowBorderWidth]. > - aLayoutFrame leftFraction = 0 > - ifTrue: [aLayoutFrame leftOffset: left + windowBorderWidth] > - ifFalse: [aLayoutFrame leftOffset: left + ProportionalSplitterMorph splitterWidth]. > > + aLayoutFrame bottomFraction = 1 ifTrue: [aLayoutFrame bottomOffset: bottom - windowBorderWidth]. > + aLayoutFrame topFraction = 0 > + ifTrue: [aLayoutFrame topOffset: top + windowBorderWidth] > + ifFalse: [aLayoutFrame topOffset: top + ProportionalSplitterMorph splitterWidth]]. > + > + "this code should not be here!!!! As of 6/13/2013 there aren't even any users of BrowserCommentTextMorph." > - aLayoutFrame bottomFraction = 1 ifTrue: [aLayoutFrame bottomOffset: bottom - windowBorderWidth]. > - aLayoutFrame topFraction = 0 > - ifTrue: [aLayoutFrame topOffset: top + windowBorderWidth] > - ifFalse: [aLayoutFrame topOffset: top + ProportionalSplitterMorph splitterWidth]. > - > (aMorph class name = #BrowserCommentTextMorph) ifTrue: > [aLayoutFrame rightOffset: windowBorderWidth negated. > aLayoutFrame leftOffset: windowBorderWidth. > aLayoutFrame bottomOffset: windowBorderWidth negated. > aLayoutFrame topOffset: (windowBorderWidth negated) + 4]. > > super addMorph: aMorph fullFrame: aLayoutFrame. > > paneMorphs := paneMorphs copyReplaceFrom: 1 to: 0 with: (Array with: aMorph). > aMorph isImageMorph ifFalse: > [aMorph adoptPaneColor: self paneColor. > aMorph borderWidth: 1; borderColor: Color lightGray; color: Color white]. > Preferences scrollBarsOnRight ifTrue:"reorder panes so flop-out right-side scrollbar is visible" > [self addMorphBack: aMorph]. > > self addPaneSplitters! > >

1 0

Understanding Smalltalk for Modifying Scratch (Squeak version)
by Darius Clarke 21 Jun '13

21 Jun '13

Hi Azka, Thank you for helping us improve Scratch. :) Perhaps I can guide you into the Smalltalk way of thinking and how different it is from the usual application development paradigm and workflow. Imagine you're a Java developer and you use Eclipse for your IDE. Imagine you keep your source code in a SVN or similar repository which runs on a database server. Imagine your development team keeps your entire setup ... Eclips, SVN, repository, application data, operating system, and configurations, in an Virtual Operating System ram-memory-space-image-in-a-file which VirtualBox, or VMWare can run ... so there is no "installation" to get one's environment running. The VirtualBox ram-memory-space-image-in-a-file has a "snapshot" to a single disk file of all the applications installed an running. In the setup described above, one simple takes an VirtualBox snapshot ram-memory-space-image-in-a-file and starts it with VirtualBox. This has the Eclipse IDE, the application running in Eclipse, and the SVN server running all at the same time from the moment the VirtualBox image snapshot was taken. One just continues to make changes to the code in Eclipse and the running application in Eclipse immediately reflects those changes. In (almost) all Smalltalk distributions, the Smalltalk development environment has everything mentioned above, and works like everything mentioned above. The squeak.exe application is like the VirtualBox application which runs snapshot saved ram-memory-space-image-in-a-file. The squeak.image file is like the ram-memory-space-image-in-a-file which has Eclipse and the developer's application all running all the time. The .source file is like the SVN repository in a database. You'd never, never edit the SVN source code database file directly, even if in theory you could. It'd ruin the versioning and indexing among other problems. The .changes file is like the SVN repository database journaling file. It's just there for emergency recovery reasons. Not to be edited directly either. Making snapshots of the ram-memory-space-image-in-a-file is like selecting "save" or "save as" in the Squeak World menu to create a new .image file. Once the squeak.exe (in Windows, or the Linux, or OS X equivalent virtual machine app) is running the .image file, one uses the World Menu (like clicking on the Smalltalk desktop background to bring up the menu, this might be disabled in the scratch version) one can select the Browser menu option to start the Hierarchal Browser (Smalltalk's Eclipse IDE equivalent running in the app). Edit the code in the Hierarchal Browser with each method save, automatically saves it in the .changes file. Everything else automatically gets save when the .image is saved from within the Smalltalk running environment. This means you can't use your favorite text editor to edit Smalltalk code. One must use the built-in Hierarchal Browser. However, all the source code for running the Hierarchal Browser is in the Hierarchal Browser itself, so you can edit the behavior of the IDE any way you like to add your favorite IDE features ... in real time. It's all one running app. There's no separate programs for the IDE or viewing graphics or editing text or playing music or animating a game. It's all one app, running in one memory space. So, every "application" can see every other "applications" classes, instances, and field values. A Vulcan mind meld of all applications into each other. That's Smalltalk. Does this help? Cheers, Darius _________________ On Fri, Jun 21, 2013 at 4:57 AM, Azka Niazi <azka.akn(a)live.com> wrote: > Thanks for the feedback Ron and Chris, but I have some more questions now. > > 1. I am sorry I didn't fully understand what did you mean by "act as > storage space for the code you write in Smalltalk". Also please specify > whether by Smalltalk you meant Smalltalk-80 (i.e. Squeak) or did you mean > Smalltalk only. As in is there a custom to refer to Squeak as Smalltalk. > Doesn't it create am > >

1 0

Read-only test morph ?
by Stéphane Rollandin 21 Jun '13

21 Jun '13

Hello, Is there a simple way to make a PluggableTextMorph (or a similar beast) read-only ? Stef

2 2

<LargePositiveInteger>>BitAnd:> method not needed
by Ralph Boland 21 Jun '13

21 Jun '13

I am using Squeak 3.11. I assume the same results apply to Squeak 4.4. If not, my apologies. In Squeak if I evaluate: 1) ((2 << 256) bitAnd: (2 << 128)) ==> 0 2) ((2 << 256) bitAnd: (2 << 128)) class ==> SmallInteger 3) (2 << 128) ==> 680564733841876926926749214863536422912 4) ((2 << 128) bitAnd: (2 << 128)) ==> 680564733841876926926749214863536422912 This all looks correct and I care because I need to do <bitAnd:> of some largePositiveIntegers. But <LargePositiveInteger>>BitAnd:> is: "Primitive. Answer an Integer whose bits are the logical AND of the receiver's bits and those of the argument. Fail if the receiver or argument is greater than 32 bits. See Object documentation whatIsAPrimitive." <primitive: 14> self halt. "I ADDED THE HALT" ^ super bitAnd: anInteger The way I see it <LargePositiveInteger>>BitAnd:> is always going to fail and thus invoke its super version (<LargePositiveInteger>>BitAnd:>) and this is what I see when I run the code; i.e. I hit the halt. So why have <LargePositiveInteger>>BitAnd:> method at all? Ditto for the other bit operations. Ralph Boland

3 3

← Newer
1
...
6
7
8
9
10
11
12
...
22
Older →

Jump to page: