- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11072

by StÃ©phane Ducasse

11072 ----- - Issue 1437: Bitmap #decompress:fromByteArray:at: not wellformed - Issue 1252: Transparency Artifact - Issue 1363: should use selectorsDo: instead of selectors do:

Dec. 5, 2009

Re: [Pharo-project] StandardWindow Layout Help

by StÃ©phane Ducasse

hi rob in the latest 1.1 you can have a look at SettingBrowser has an example. in botsinc book image there is the code of a minibrowser you can also take as example. open | window | Cursor wait showWhile: [window := StandardWindow new model: self. window title: self windowTitle. self buildWindowIn: window. window themeChanged. window openInWorld. ^ window] buildWindowIn: aWindow | statusView toolBar treeMorph toolBarY gap localGap menuBar menuBarY | treeMorph := self treeMorphIn: aWindow. statusView := self statusViewIn: aWindow. toolBar := self toolBarIn: aWindow. menuBar := self menuBarIn: aWindow. menuBar submorphs ifEmpty: [menuBarY := 0] ifNotEmpty: [menuBarY := menuBar minExtent y. aWindow addMorph: menuBar fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0) offsets: (0 @ 0 corner: 0 @ menuBarY))]. localGap := 5. gap := localGap + menuBarY. toolBarY := toolBar minExtent y + gap. aWindow addMorph: toolBar fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0) offsets: (0 @ (gap ) corner: 0 @ (toolBarY + localGap))). aWindow addMorph: treeMorph fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0.99) offsets: (0 @ (toolBarY + localGap + localGap) corner: 0 @ 100 negated)). aWindow addMorph: statusView fullFrame: (LayoutFrame fractions: (0 @ 0.99 corner: 1 @ 1) offsets: (0 @ 100 negated corner: 0 @ 0)). ^ aWindow On Dec 5, 2009, at 10:45 PM, Rob Rothwell wrote: > I just can't seem to figure this out from the UITheme examples. > > Can anyone give me some general pointers on building a plain old Window? I know there isn't a UI builder, but how do you control the placement of the child controls you create in the window? > > For example, the following will create a StandardWindow and add a button to it (in the upper left corner). Do you control placement [of the button] with LayoutFrame? How do you use LayoutFrame? > > | win btnOk | > > win := StandardWindow new. > btnOk := win newButtonFor: nil action: #ok getEnabled: nil label: 'Ok' help: nil. > win addMorph: btnOk . > win themeChanged; openInWorld. > > Thank you. I am finally trying to understand how to build some typical applications without a GUI builder... > > Take care, > > Rob > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 5, 2009

[Pharo-project] StandardWindow Layout Help

by Rob Rothwell

I just can't seem to figure this out from the UITheme examples. Can anyone give me some general pointers on building a plain old Window? I know there isn't a UI builder, but how do you control the placement of the child controls you create in the window? For example, the following will create a StandardWindow and add a button to it (in the upper left corner). Do you control placement [of the button] with LayoutFrame? How do you use LayoutFrame? | win btnOk | win := StandardWindow new. btnOk := win newButtonFor: nil action: #ok getEnabled: nil label: 'Ok' help: nil. win addMorph: btnOk . win themeChanged; openInWorld. Thank you. I am finally trying to understand how to build some typical applications without a GUI builder... Take care, Rob

Dec. 5, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by StÃ©phane Ducasse

when I see the complexity of the code full of project and morph conditional I imagine that the primary idea beind imageSegment got damaged. Now imageSegment is probably difficult to control too. Stef On Dec 5, 2009, at 9:41 PM, John M McIntosh wrote: > I should relate our experience with segments in Sophie was not helpful. > > We attempted to segment off our font menu since it was expensive to build, and really > only needed to be changed if the fonts on the machine changed. > Since the image was read only we would startup, build the font menu then > image segment that off. > > On a restart we just read the segment in, confirmed the machine didn't have font files changed. > This worked well in the *lab*. > > But when we push it to the public we started getting email about machines crashing. > Tim and I were just unable to determine why... But it was always related to the point > where it read the image segment, sometimes it would crash (rarely) mostly not. > > We backed that out, and settled with a image segment that really just stored forms of > each font face for the menu. That *seemed* to work ok > > > On 2009-12-05, at 6:53 AM, StÃ©phane Ducasse wrote: > >> Excellent! >> We need really cool and well tested imageSegments without etoy and project refs everywhere. >> Let us know up to date. >> >> >> On Dec 5, 2009, at 3:17 AM, Sheridan Mahoney wrote: >> >>> >>> Great! The other person helping me is Martin McClure, and Mariano contacted >>> me just yesterday to start collaborating, so looks like there are 3 of us >>> now >>> hooked on ImageSegment.... >>> >>> -- Sheri >>> >>> >>> >>> Adrian Lienhard wrote: >>>> >>>> Hi Sheri, >>>> >>>> Sounds ok to make new: raise an exception if you adjust the tests (and >>>> any code that exists in the image using new: (but I assume there is >>>> none)). >>>> >>>> However, the actual reason why you get multiple same symbols after >>>> loading a segment likely is unrelated to ByteSymbol class>>new:. I >>>> guess it is because when creating the segment you do not hold onto >>>> these symbols. Like this they do not get into the outPointers ref >>>> stream but in the bytearray. When installing the segment again, with >>>> same symbols existing in the image already, then you get duplicates. >>>> >>>> The "right way" to do this is to strongly hold onto all symbols when >>>> creating a segment. See #createSegmentFrom:. You can reproduce this >>>> problem by commenting out the first line of #createSegmentFrom: and >>>> running #testSymbols. >>>> >>>> Let us know how it goes... >>>> >>>> BTW, Mariano is also writing ImageSegment tests, so maybe you want to >>>> join forces (or maybe he already is the colleague you mentioned?). >>>> >>>> Cheers, >>>> Adrian >>>> >>>> On Dec 3, 2009, at 23:10 , StÃ©phane Ducasse wrote: >>>> >>>>>> From: Sheridan Mahoney <sheridan(a)sheridan-mahoney.com> >>>>>> Date: December 3, 2009 11:04:19 PM GMT+01:00 >>>>>> To: pharo-project-bounces(a)lists.gforge.inria.fr >>>>>> Subject: Re: getting rid of Symbol >> new: ? >>>>>> Reply-To: sheridan(a)sheridan-mahoney.com >>>>>> >>>>>> >>>>>> A colleague and I are investigating the ImageSegment class and its >>>>>> methods, we came across an issue I would like to get external >>>>>> opinions on. Newbie alert, BTW (at least one of us, no names >>>>>> mentioned...). Also, this is not a problem that will affect many >>>>>> users, but it is familiarizing us with the check-in process, >>>>>> slices, etc. While working on ImageSegment tests, we discovered a >>>>>> problem on trying to load segments that had Symbols in the root >>>>>> array. It is possible to create 2 ByteSymbols with the same >>>>>> sequence of characters. :( In trying to track down how this is >>>>>> possible, we came across a side issue, that ByteSymbol new: had >>>>>> the capacity to create multiple new ByteSymbols with the same >>>>>> number of nil characters (as in, initialized with nil). We want to >>>>>> dissallow Symbol new: , which would cause people to use one of >>>>>> the nicer methods for Symbol/ByteSymbol creation (namely, one which >>>>>> checks that the sequence of characters doesn't already exist, as >>>>>> part of the creation process). We have a fix we want to check in, >>>>>> but currently it breaks a test case in the SymbolTest class, which >>>>>> is checking that new: works. We also changed the intern: >>>>>> method on the class side of Symbol to use basicNew: instead >>>>>> of new: . Are there reasons to keep 'Symbol new:' , that >>>>>> outweigh the reasons to get rid of it? >>>>>> Many thanks, >>>>>> and Cheers, >>>>>> Sheri Mahoney >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> >>> -- >>> View this message in context: http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4116203.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 5, 2009

[Pharo-project] Fwd: Issue 1298 in pharo: CrLfFileStream not properly initialized on Mac OS

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo(a)googlecode.com > Date: December 5, 2009 9:56:30 PM GMT+01:00 > To: stephane.ducasse(a)gmail.com > Subject: Re: Issue 1298 in pharo: CrLfFileStream not properly initialized on Mac OS > > > Comment #2 on issue 1298 by nicolas.cellier.aka.nice: CrLfFileStream not properly initialized on Mac OS > http://code.google.com/p/pharo/issues/detail?id=1298 > > 1) I don't like to see these getSystemAttribute: 1001 spreaded like a plague. We have > clear messages that perfectly insulate these cryptic secret codes. > 2) As I changed these getSystemAttribute: senders recently in trunk, I think I saw > more subtle things like testing for 'Darwin' or something... Aren't OS-X linefeed > based ? (I don't own a Mac...) > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

Dec. 5, 2009

[Pharo-project] Fwd: why OOP needs tails recursion article

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: December 5, 2009 9:55:14 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: why OOP needs tails recursion article > > Hi Steph, > > can you forward my response to the Pharo list? I guess I do need to join the Pharo list :/ > > Eliot (from under an avalanche of email) > > On Sat, Dec 5, 2009 at 12:32 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sat, Dec 5, 2009 at 2:00 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > http://lambda-the-ultimate.org/node/3702 > > > I want to return to the implementation and optimization implications of this later. But Steele's post refers to William Cook's excellent paper On understanding data abstraction, revisited. Onward! Essays, 2009 ACM OOPSLA. SIGPLAN Notices 44, 10 (Oct. 2009), 557-572. There's a freely available draft version. The quote I want to emphasise is > > The extensibility of objects does not depend upon inheritance, but rather is an inherent property of object interfaces. > > The paper proves this point eloquently and concisely. The implication is that isKindOf: is <shout>BROKEN</shout>. In the absence of something better isSomeInterface to query whether an object implements some interface SomeInterface is acceptable. isKindOf: (and the horror I found the other day isKindOf:orKindOf: (you see why it exists and where it leads?)) is not and should be expunged. > > My weekend rant. > > best, > Eliot >

Dec. 5, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by John M McIntosh

I should relate our experience with segments in Sophie was not helpful. We attempted to segment off our font menu since it was expensive to build, and really only needed to be changed if the fonts on the machine changed. Since the image was read only we would startup, build the font menu then image segment that off. On a restart we just read the segment in, confirmed the machine didn't have font files changed. This worked well in the *lab*. But when we push it to the public we started getting email about machines crashing. Tim and I were just unable to determine why... But it was always related to the point where it read the image segment, sometimes it would crash (rarely) mostly not. We backed that out, and settled with a image segment that really just stored forms of each font face for the menu. That *seemed* to work ok On 2009-12-05, at 6:53 AM, StÃ©phane Ducasse wrote: > Excellent! > We need really cool and well tested imageSegments without etoy and project refs everywhere. > Let us know up to date. > > > On Dec 5, 2009, at 3:17 AM, Sheridan Mahoney wrote: > >> >> Great! The other person helping me is Martin McClure, and Mariano contacted >> me just yesterday to start collaborating, so looks like there are 3 of us >> now >> hooked on ImageSegment.... >> >> -- Sheri >> >> >> >> Adrian Lienhard wrote: >>> >>> Hi Sheri, >>> >>> Sounds ok to make new: raise an exception if you adjust the tests (and >>> any code that exists in the image using new: (but I assume there is >>> none)). >>> >>> However, the actual reason why you get multiple same symbols after >>> loading a segment likely is unrelated to ByteSymbol class>>new:. I >>> guess it is because when creating the segment you do not hold onto >>> these symbols. Like this they do not get into the outPointers ref >>> stream but in the bytearray. When installing the segment again, with >>> same symbols existing in the image already, then you get duplicates. >>> >>> The "right way" to do this is to strongly hold onto all symbols when >>> creating a segment. See #createSegmentFrom:. You can reproduce this >>> problem by commenting out the first line of #createSegmentFrom: and >>> running #testSymbols. >>> >>> Let us know how it goes... >>> >>> BTW, Mariano is also writing ImageSegment tests, so maybe you want to >>> join forces (or maybe he already is the colleague you mentioned?). >>> >>> Cheers, >>> Adrian >>> >>> On Dec 3, 2009, at 23:10 , StÃ©phane Ducasse wrote: >>> >>>>> From: Sheridan Mahoney <sheridan(a)sheridan-mahoney.com> >>>>> Date: December 3, 2009 11:04:19 PM GMT+01:00 >>>>> To: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> Subject: Re: getting rid of Symbol >> new: ? >>>>> Reply-To: sheridan(a)sheridan-mahoney.com >>>>> >>>>> >>>>> A colleague and I are investigating the ImageSegment class and its >>>>> methods, we came across an issue I would like to get external >>>>> opinions on. Newbie alert, BTW (at least one of us, no names >>>>> mentioned...). Also, this is not a problem that will affect many >>>>> users, but it is familiarizing us with the check-in process, >>>>> slices, etc. While working on ImageSegment tests, we discovered a >>>>> problem on trying to load segments that had Symbols in the root >>>>> array. It is possible to create 2 ByteSymbols with the same >>>>> sequence of characters. :( In trying to track down how this is >>>>> possible, we came across a side issue, that ByteSymbol new: had >>>>> the capacity to create multiple new ByteSymbols with the same >>>>> number of nil characters (as in, initialized with nil). We want to >>>>> dissallow Symbol new: , which would cause people to use one of >>>>> the nicer methods for Symbol/ByteSymbol creation (namely, one which >>>>> checks that the sequence of characters doesn't already exist, as >>>>> part of the creation process). We have a fix we want to check in, >>>>> but currently it breaks a test case in the SymbolTest class, which >>>>> is checking that new: works. We also changed the intern: >>>>> method on the class side of Symbol to use basicNew: instead >>>>> of new: . Are there reasons to keep 'Symbol new:' , that >>>>> outweigh the reasons to get rid of it? >>>>> Many thanks, >>>>> and Cheers, >>>>> Sheri Mahoney >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> -- >> View this message in context: http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4116203.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 5, 2009

Re: [Pharo-project] asBit

by Ralph Boland

> I currently writing a code which looks like: > > a := some numeric expression + (someBoolean ifTrue: [1] ifFalse: [0]). > > And i get somewhat tired repeating the same pattern in multiple places. > So, i thinking , maybe #asBit convenience method could be useful? > > True>>asBit > Â ^ 1 > False>>asBit > Â ^ 0 > > so, then, in case of need like above, we could write much shorter expressions: > a := some numeric expression + someBoolean asBit. > > And its much less error prone comparing to #ifTrue:ifFalse:, since i > found its relatively easy to make a mess (swapping 1 with 0), > especially, when you having negations in expression, because once you see: > > (someBoolean not ifTrue: [1] ifFalse: [0]) > > you always tempted to write it as: > > (someBoolean ifTrue: [0] ifFalse: [1]). > > or as: > > (someBoolean ifFalse: [1] ifTrue: [0]). > > but once you start playing with it, its very easy to shoot into own > feet if you are not careful. > > But if we could add #asBit, then we could write: > > someBoolean not asBit > > which is much more: > a) concise & cleaner > b) error proof > > > -- > Best regards, > Igor Stasenko AKA sig. I use "someBoolean card" for this where card stands for cardinality. The cardinality of false is 0 and of true is 1. Method "card" can also be used for other classes of object that have cardinal values associated with them. Regards, Ralph Boland -- Volume * Density = Mass. Volume / Density = Intelligence. The latter equation explains the essentially equal intelligence of men and woman and the capabilities of some commonly used operating systems.

Dec. 5, 2009

Re: [Pharo-project] squeak VM 5.0

by John M McIntosh

On 2009-12-05, at 6:38 AM, Laval Jannik wrote: > Hi John, > > Ok, I thried this: > - file in the updated System-Tracer (attached) > > I modified some references to Smalltalk to SmalltalkImage current, but not all. > - run it > ok, it runs and generate a new image. > This is done in a 4.2.2VM runing with rosetta. > > Now, when I try to load the new image, VM open a white window (this is not bad :) ) > But I don't know what I can do with this, there is no message. > > So, I tried also with a pharo10259 and a Squeak 3.10 and I have the same error. > > Do you have an idea of the bug ? Yes > > I modified some references to Smalltalk to SmalltalkImage current, but not all. *all* references have to be checked You get a DNU at startup time, dead... SystemTracer2>>processStartup See usage of Smalltalk hacking a bit more gets you to -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 5, 2009

Re: [Pharo-project] SmallDictionary>>removeAll or >>empty?

by Nicolas Cellier

Lukas is speaking of default Collection>>removeAll which has few chances to work. But subclasses do a better job, that's why I did not bother... Cheers Nicolas 2009/12/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this is strange since I recall nicolas or somebody proposing a real removalAll. > So I would have thought it would work. > > Stef > > On Dec 5, 2009, at 5:49 PM, Lukas Renggli wrote: > >> SmallDictionary comes from the refactoring engine. It is a highly >> optimized dictionary originally intended for parse-tree matching. The >> method #empty does not make sense outside that context. >> >> The method #removeAll is implemented in Collection. I don't think that >> this implementation can ever work in any concrete collection >> implementation, because it modifies the collection while iterating >> over it (lint would know that). Most classes override it with >> something sensible though. >> >> Lukas >> >> 2009/12/5 Simon Denier <Simon.Denier(a)inria.fr>: >>> Stupid question: how do I remove all entities from a SmallDictionary >>> >>> Let's take: >>> d := SmallDictionary new. >>> d add: $d -> 4. >>> d add: $e -> 5. >>> d >>> >>> If I do >>> d empty >>> >>> then d size = 0 and d do: behaves as if there is nothing >>> BUT someone can still perform >>> d at: $d -> 5 >>> >>> If I do >>> d removeAll >>> >>> I get a MessageNotUnderstood: SmallInteger>>key >>> because #removeAll inherited from Collection expects a different >>> structure >>> >>> -- >>> Â Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 5, 2009