June 2013 - Pharo-dev - lists.pharo.org

[update 3.0] #30198

by Marcus Denker

30198 ----- 10902 Add FileReference >> contents https://pharo.fogbugz.com/f/cases/10902 10895 DateModel Enhancement: add getter & better class comment https://pharo.fogbugz.com/f/cases/10895 10899 Fix FontSet class>>#fontName https://pharo.fogbugz.com/f/cases/10899 10898 substring refactoring broke freetype loading https://pharo.fogbugz.com/f/cases/10898 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.197… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Graphics-Fonts-MarcusDenker.7… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FreeType-MarcusDenker.619.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Tests-Core-MarcusD… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.170.diff

June 13, 2013

Re: [Pharo-dev] [update 3.0] #30198

by Marcus Denker

On Jun 13, 2013, at 4:31 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Thu, Jun 13, 2013 at 4:22 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> This update was never published as i broke the build (no idea why, we should have a look). > > > I've just found a bug in previous release: > https://pharo.fogbugz.com/f/cases/10903/Bad-use-of-includesSubstring > (and pushed a fix). Could this be related? > could be, but unlikely as this code normally is not calledâ¦ Marcus

June 13, 2013

Re: [Pharo-dev] [update 3.0] #30198

by Damien Cassou

On Thu, Jun 13, 2013 at 4:22 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > This update was never published as i broke the build (no idea why, we should have a look). I've just found a bug in previous release: https://pharo.fogbugz.com/f/cases/10903/Bad-use-of-includesSubstring (and pushed a fix). Could this be related? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 13, 2013

Re: [Pharo-dev] [update 3.0] #30198

by Marcus Denker

This update was never published as i broke the build (no idea why, we should have a look). I have reopened the issue, the next update will be again #198 On Jun 13, 2013, at 9:57 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30198 > ----- > > 6989 Inspect should be silent > https://pharo.fogbugz.com/f/cases/6989 > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1140.diff >

June 13, 2013

Re: [Pharo-dev] [squeak-dev] RE: Trie data structure

by Frank Shearar

On 13 June 2013 15:05, Stephan Eggermont <stephan(a)stack.nl> wrote: > Benoit wrote: >>Here's a simple Trie implementation I'm giving to the Smalltalk community.? It's been tested with Pharo 1.3 but it >should work without any modification on Squeak. > > Nice, thank you. > >>http://endormitoire.wordpress.com/2013/06/13/trie/ >> >>Awaiting your comments/suggestions/complaints/ideas. >> >>I'm planning on porting it to other Smalltalks and the latest Pharos (2.x and 3.x). > > Tests run in Pharo 3.0 And in Squeak 4.5. I don't like that it's in a package called 'Collections-Trie' though: it's certainly an accurate name, but it would make the Collections package dirty. I don't know if Pharo split up its Collections package? frank >>P.S.? I'm providing the fileOuts since I wasn't sure on where to store this code : SmalltalkHub/ss3/elsewhere ? > > Yes. Pick one and commit. Both smalltalkhub and ss3 work fine. Moving to another location is trivial. > > Stephan

June 13, 2013

Re: [Pharo-dev] Trie data structure

by Stephan Eggermont

Benoit wrote: >Here's a simple Trie implementation I'm giving to the Smalltalk community.? It's been tested with Pharo 1.3 but it >should work without any modification on Squeak. Nice, thank you. >http://endormitoire.wordpress.com/2013/06/13/trie/ > >Awaiting your comments/suggestions/complaints/ideas. > >I'm planning on porting it to other Smalltalks and the latest Pharos (2.x and 3.x). Tests run in Pharo 3.0 >P.S.? I'm providing the fileOuts since I wasn't sure on where to store this code : SmalltalkHub/ss3/elsewhere ? Yes. Pick one and commit. Both smalltalkhub and ss3 work fine. Moving to another location is trivial. Stephan

June 13, 2013

Trie data structure

by Benoit St-Jean

Hello everyone, Here's a simple Trie implementation I'm giving to the Smalltalk community.Â It's been tested with Pharo 1.3 but it should work without any modification on Squeak. http://endormitoire.wordpress.com/2013/06/13/trie/ Awaiting your comments/suggestions/complaints/ideas. I'm planning on porting it to other Smalltalks and the latest Pharos (2.x and 3.x). P.S.Â I'm providing the fileOuts since I wasn't sure on where to store this code : SmalltalkHub/ss3/elsewhere ? enjoy! Â ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blogue: endormitoire.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

June 13, 2013

Re: [Pharo-dev] straaannnnge code in SystemWindow>>addMorph:fullFrame:

by Benjamin

I submitted a slice yesterday extracting hardcoded width of splitters for using a theme property. I you want to wrap everything in a container morph, it works pretty well as ing as you do not forget the magic invocation container := Morph new; changeProportionalLayout; yourself Ben On Jun 13, 2013, at 3:05 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 13, 2013, at 2:31 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> Further, the current SystemWindow>>addMorph:fullFrame: assumes thick borders between components, for pane splitters. There used to be an accessor on SystemWindow, allowPaneSplitters:, that could be used to discard pane splitters and their thick borders, but this was ditched. >> >> So if I want a window containing lots of morphs with no splitters and no thick borders how do I do it? > > We will rewrite a part of this code :). > > >> >> a) Should I use a container morph and add this to the SystemWindow? >> >> b) should I add an override to SystemWindow that does what addMorph:fullFrame: (or addMorph:frame:) does without adding the thick borders? >> >> c) should I add back the allowPaneSplitters[:] accessor and modify SystemWindow>>addMorph:fullFrame: to take account of allowPaneSplitters == false? >> >> a) seems the right approach, but when I use either a Morph or a BorderedMorph as my container I don't get things laid out correctly in that morph. Is there a standard container morph that does layout correctly? If so, what is it? >> >> c) is easy to do, but folks have to maintain it (it's no more than a guard around all the frae manipulation in addMorph:fullFrame:). >> >> >> On Wed, Jun 12, 2013 at 3:23 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> On Wed, Jun 12, 2013 at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi All, >> >> in SystemWindow>>addMorph:fullFrame: towards the bottom are the lines: >> >> aMorph adoptPaneColor: self paneColor. >> aMorph borderWidth: 1; borderColor: Color lightGray; color: Color white. >> >> I'm adding a UpdatingThreePhaseButtonMorph checkBox to my window so, via ImageMorph>>colors: >> >> ImageMorph>>color: aColor >> super color: aColor. >> (image depth = 1 and: [aColor isColor]) ifTrue: [ >> image colors: {Color transparent. aColor}. >> self changed] >> >> this has the effect of completely smashing the checkBox's normal image, and setting to white ScriptingSystem formAtKey: #CheckBoxOn, which is what the checkBox uses as its default image. >> >> What business does SystemWindow have of smashing the colour of any morph added to it? Surely this is bogus, no? >> >> I see the regression. Back in 3.9 the method read >> >> (aMorph isKindOf: ImageMorph) ifFalse:[ >> aMorph adoptPaneColor: self paneColor. >> aMorph borderWidth: 2; borderColor: #inset; color: Color transparent] >> >> Unless anyone objects I'll put back this guard. it seems obviously correct (or rather, obviously less broken; the method also includes this priceless gem: >> (aMorph class name = #BrowserCommentTextMorph) ifTrue: >> [aLayoutFrame rightOffset: windowBorderWidth negated. >> aLayoutFrame leftOffset: windowBorderWidth. >> aLayoutFrame bottomOffset: windowBorderWidth negated. >> aLayoutFrame topOffset: (windowBorderWidth negated) + 4]. >> ). >> >> -- >> best, >> Eliot >> >> >> >> -- >> best, >> Eliot >> >> >> >> -- >> best, >> Eliot >

June 13, 2013

Re: [Pharo-dev] straaannnnge code in SystemWindow>>addMorph:fullFrame:

by StÃ©phane Ducasse

On Jun 13, 2013, at 2:31 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Further, the current SystemWindow>>addMorph:fullFrame: assumes thick borders between components, for pane splitters. There used to be an accessor on SystemWindow, allowPaneSplitters:, that could be used to discard pane splitters and their thick borders, but this was ditched. > > So if I want a window containing lots of morphs with no splitters and no thick borders how do I do it? We will rewrite a part of this code :). > > a) Should I use a container morph and add this to the SystemWindow? > > b) should I add an override to SystemWindow that does what addMorph:fullFrame: (or addMorph:frame:) does without adding the thick borders? > > c) should I add back the allowPaneSplitters[:] accessor and modify SystemWindow>>addMorph:fullFrame: to take account of allowPaneSplitters == false? > > a) seems the right approach, but when I use either a Morph or a BorderedMorph as my container I don't get things laid out correctly in that morph. Is there a standard container morph that does layout correctly? If so, what is it? > > c) is easy to do, but folks have to maintain it (it's no more than a guard around all the frae manipulation in addMorph:fullFrame:). > > > On Wed, Jun 12, 2013 at 3:23 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Jun 12, 2013 at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > in SystemWindow>>addMorph:fullFrame: towards the bottom are the lines: > > aMorph adoptPaneColor: self paneColor. > aMorph borderWidth: 1; borderColor: Color lightGray; color: Color white. > > I'm adding a UpdatingThreePhaseButtonMorph checkBox to my window so, via ImageMorph>>colors: > > ImageMorph>>color: aColor > super color: aColor. > (image depth = 1 and: [aColor isColor]) ifTrue: [ > image colors: {Color transparent. aColor}. > self changed] > > this has the effect of completely smashing the checkBox's normal image, and setting to white ScriptingSystem formAtKey: #CheckBoxOn, which is what the checkBox uses as its default image. > > What business does SystemWindow have of smashing the colour of any morph added to it? Surely this is bogus, no? > > I see the regression. Back in 3.9 the method read > > (aMorph isKindOf: ImageMorph) ifFalse:[ > aMorph adoptPaneColor: self paneColor. > aMorph borderWidth: 2; borderColor: #inset; color: Color transparent] > > Unless anyone objects I'll put back this guard. it seems obviously correct (or rather, obviously less broken; the method also includes this priceless gem: > (aMorph class name = #BrowserCommentTextMorph) ifTrue: > [aLayoutFrame rightOffset: windowBorderWidth negated. > aLayoutFrame leftOffset: windowBorderWidth. > aLayoutFrame bottomOffset: windowBorderWidth negated. > aLayoutFrame topOffset: (windowBorderWidth negated) + 4]. > ). > > -- > best, > Eliot > > > > -- > best, > Eliot > > > > -- > best, > Eliot

June 13, 2013

Re: [Pharo-dev] Block Printing in 3.0

by Marcus Denker

On Jun 13, 2013, at 2:23 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Why do we get [...] when Opal is not active? Why can't we keep the old > behavior? > Soon we will switch to Opal, there are just 2 bugs left (that I know of ;-) We where a bit distracted last week so there was no progress on thoseâ¦ soon. Marcus

June 13, 2013