November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Re: IdentitySet>>collect:

by Sven Van Caekenberghe

> On 28 Nov 2014, at 15:35, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 27 Nov 2014, at 08:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 26 Nov 2014, at 19:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi All, >>> >>> IdentitySet>>collect: answers a Set, not an IdentitySet. Anyone else agree this is a serious bug? Anyone else disagree? >>> >>> WTF?? >>> >>> (IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] a Set(1.0 2 3) >> >> Yes, I would say so. I think we fixed some others like that already (not 100% sure) >> >> I added an issue tracker entry >> >> 14535 IdentitySet>>collect: answers a Set, not an IdentitySet. >> https://pharo.fogbugz.com/f/cases/14535 >> > > #collect: directly uses Set in Set>>#collect, I committed a fix (to the issue tracker, to be reviewed) > to use âself speciesâ instead (plus the example from above as a test in IdentitySetTest). > > Marcus I think that is the most logical thing to do, it is what I would expect. I know others have cases where that is not really what you want (some of Set's subclasses are pretty special), but it is still a good default, while #collect:as: can be used for all other cases (and subclasses can override #species again if they want). Sven

Nov. 28, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Thierry Goubier

2014-11-28 14:40 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > kilon alios wrote: > >> I forgot to add that git comes with excellent gui clients that are far >> more powerful and elegant that what Pharo offers currently . >> > > We started late. We had tools reasonably suited for our needs which we > were comfortable with. I think/hope that once libgit is "released" in > Pharo and the wider community becomes more familiar with it, it stimulates > us to develop tools to rival the others. Tools that non-Smalltalkers also > find useful, and when they want to add a feature, they are motivated to > learn Pharo. I think this is a small additional benefit of tighter > integration of git in Pharo. > But underlying this is the hypothesis that you will be able to master the complexity of git from within Pharo, which is ambitious. Given how complex git is and the use cases around it, I personaly do not underestimate that task. I do know that, probably, if git gets totally integrated within Pharo, it will not fit my professional use case and I will have to resort to something else[*]. In the same way that people who knows and use git (and github) everyday do prefer to stay with FileTree and command line git (and external tools) than switch to GitFileTree (which is a plain automation layer above FileTree and git). We are now at four attempts[**] at writing git support for Pharo in no less than three or four years, with two dead, one working for two platforms out of three and one under development for already a while. This shows that we need a bit of humility in promising the perfect git integration and tools. Thierry [*] But it will fit the Pharo team use case perfectly well ;) [**] I'm finding new ones on github while searching: https://github.com/JumpIntoSqueak/metacello-git https://github.com/timfel/gitocello https://github.com/theseion/fs-git https://github.com/theseion/LibGit https://github.com/theseion/LibGit2-bindings > > cheers -ben > >

Nov. 28, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by kilon alios

> > > "We started late. We had tools reasonably suited for our needs which we were comfortable with. I think/hope that once libgit is "released" in Pharo and the wider community becomes more familiar with it, it stimulates us to develop tools to rival the others. Tools that non-Smalltalkers also find useful, and when they want to add a feature, they are motivated to learn Pharo. I think this is a small additional benefit of tighter integration of git in Pharo. cheers -ben" Even if Smalltalkhub improves and solves these problems, Github will still run circles around it. Sure some pharoers want to stick inside the image because they want to avoid the pain to learn something new or because hey aspire of all inclusive smalltalk enviroment. But I dont want to be like the kid that press his face on the windows of a candy store, salivating for the candy I cannot have. There is a lot of cool technology around us really great and it will be a pity if Pharo does not take advantage of it. Git and Github is only a small part of the story. My belief and this is a belief I put in practice with my project Ephestos is that Pharo can be an excellent candidate as a glue enviroment , an enviroment that can bring all modern very powerful technologies together. I find a pharo enviroment that allows me to control the outside software with ease far more tempting than a Pharo enviroment that allow me to control with ease only itself. For me this is also what made Python so popular as a language. We all have seen the 80s drawing with the baloon leaving the island but even in 2014 even Pharo feels like an island some times. Fortunately this changes and we see more and more a more modern smalltalk and a more modern Pharo. I believe in Pharo and in its success and this is why I love contribute to it.

Nov. 28, 2014

Re: [Pharo-dev] IdentitySet>>collect:

by Marcus Denker

> On 27 Nov 2014, at 08:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 26 Nov 2014, at 19:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi All, >> >> IdentitySet>>collect: answers a Set, not an IdentitySet. Anyone else agree this is a serious bug? Anyone else disagree? >> >> WTF?? >> >> (IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] a Set(1.0 2 3) > > Yes, I would say so. I think we fixed some others like that already (not 100% sure) > > I added an issue tracker entry > > 14535 IdentitySet>>collect: answers a Set, not an IdentitySet. > https://pharo.fogbugz.com/f/cases/14535 > #collect: directly uses Set in Set>>#collect, I committed a fix (to the issue tracker, to be reviewed) to use âself speciesâ instead (plus the example from above as a test in IdentitySetTest). Marcus

Nov. 28, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Ben Coman

kilon alios wrote: > I forgot to add that git comes with excellent gui clients that are far > more powerful and elegant that what Pharo offers currently . We started late. We had tools reasonably suited for our needs which we were comfortable with. I think/hope that once libgit is "released" in Pharo and the wider community becomes more familiar with it, it stimulates us to develop tools to rival the others. Tools that non-Smalltalkers also find useful, and when they want to add a feature, they are motivated to learn Pharo. I think this is a small additional benefit of tighter integration of git in Pharo. cheers -ben

Nov. 28, 2014

Re: [Pharo-dev] Problem with input of localized characters by Michal

by Ben Coman

This sounds like it was in the middle of a conversation offlist :) lb wrote: > Hiï¿½ï¿½Michal > I used Pharo 3 or 4 and happened to the similar problem, l found: (Pls > notice the Bold Part) > > HandMorph>>generateKeyboardEvent: evtBuf > "Generate the appropriate mouse event for the given raw event buffer" > > | buttons modifiers type pressType stamp charCode keyValue keyEvent | > stamp := evtBuf second. > stamp = 0 ifTrue: [stamp := Time millisecondClockValue]. > pressType := evtBuf fourth. > pressType = EventKeyDown > ifTrue: [ > type := #keyDown. > lastKeyScanCode := evtBuf third]. > pressType = EventKeyUp ifTrue: [type := #keyUp]. > pressType = EventKeyChar ifTrue: [ > type := #keystroke]. > modifiers := evtBuf fifth. > buttons := modifiers bitShift: 3. > keyValue := evtBuf third. > charCode := evtBuf sixth. > > * "Adjustments to provide consistent key value data for different VM's :* > * - charCode always contains unicode code point.* > * - keyValue contains 0 if input is outside legacy range "* > * "If there is no unicode data in the event, assume keyValue contains a > correct (<256) Unicode codepoint, and use that"* > * (charCode isNil* > * or: [charCode = 0])* > * ifTrue: [charCode := keyValue].* > * "If charCode is not single-byte, we definately have Unicode input. Nil > keyValue to avoid garbage values from some VMs." * > * charCode > 255 ifTrue: [keyValue := 0].* > > type = #keystroke > ifTrue: [combinedChar > ifNil: [ > | peekedEvent | > peekedEvent := Sensor peekEvent. > (peekedEvent notNil > and: [peekedEvent fourth = EventKeyDown]) > ifTrue: [ > (CombinedChar isCompositionCharacter: charCode) > ifTrue: [ > combinedChar := CombinedChar new. > combinedChar simpleAdd: charCode asCharacter. > (combinedChar combinesWith: peekedEvent third asCharacter) > ifTrue: [^nil]. > ]]] > ifNotNil: [ > (combinedChar simpleAdd: charCode asCharacter) > ifTrue: [charCode := combinedChar combined charCode]. > combinedChar := nil]]. > self flag: #fixme. > "This piece of code handles the creation of scrolling events. When a > scroll is done by the user, the VM forwards a keystroke event with the > up/down key. So we reconvert it to a MouseWheelEvent in that case." > > (type = #keystroke and: [(buttons anyMask: 16) > and: [charCode = 30 or: [charCode = 31]]]) > ifTrue: [^MouseWheelEvent new > setType: #mouseWheel > position: lastMouseEvent cursorPoint > direction: (charCode = 30 ifTrue: [#up] ifFalse: [#down]) > buttons: buttons > hand: self > stamp: stamp]. > keyEvent := KeyboardEvent new > setType: type > buttons: buttons > position: self position > keyValue: keyValue > charCode: charCode > hand: self > stamp: stamp. > keyEvent scanCode: lastKeyScanCode. > ^keyEvent > > > > MayBe it works. > > Have a fun! > > BingLiang > >

Nov. 28, 2014

Re: [Pharo-dev] editing the default window size of glamour inspector

by Tudor Girba

Thanks. Doru On Fri, Nov 28, 2014 at 9:59 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > 2014-11-25 8:35 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Ok. Can you open a ticket about finding a solution for custom Inspector >> window size? >> > > Done: > > > https://pharo.fogbugz.com/f/cases/14541/Editing-the-default-inspector-windo… > > Thanks Doru > >> >> Doru >> >> On Mon, Nov 24, 2014 at 3:54 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> >>> >>> >>> 2014-11-24 13:11 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> >>>> Hi, >>>> >>>> Sorry for not replying earlier. Thanks Nicolai for picking this one up. >>>> I missed the initial mail. >>>> >>>> The initialExtent does not make sense for presentation, and anyway, you >>>> would not want to change an inspector when you are inside a flow. If I >>>> understand correctly, Clement would want that when he spawns an inspector >>>> window on a new object, to set the window size to something else. >>>> >>>> The idea of having a gtInitialWindowExtent is intriguing, but it won't >>>> really work. The problem is that an object can have associated >>>> presentations in several external packages, so defining the initial extent >>>> in one of them might not work for the other ones. >>>> >>>> But, I was more thinking of a different mechanism that remembers the >>>> size of the inspector every time you change it, and have the next window >>>> take that size into account. I am even considering having this size cached >>>> by the class of the object (not sure yet if that makes sense). What do you >>>> think? >>>> >>> >>> Hello Doru, >>> >>> If we have a mechanism to remember the last size of the inspector per >>> class, it would be nice to provide in addition APIs to change this value. >>> Perhaps I could put on a start-up script something like: >>> MyClass initialInspectorSize: 1000@1000. >>> >>> My issue is that on specific classes the inspector shows a big roassal >>> visualization. When I inspect in a new window one of these objects, I need >>> each time to enlarge the window to see the full visualization. If the >>> previous size is saved or I can set the size somehow, it's fine for me. >>> >>> Cheers, >>> >>> Clement >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Mon, Nov 24, 2014 at 12:57 PM, Nicolai Hess <nicolaihess(a)web.de> >>>> wrote: >>>> >>>>> 2014-11-12 15:14 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>> >>>>>> Hello, >>>>>> >>>>>> I would like for specific objects to change the default window size >>>>>> of the glamour inspector (Basically a bigger window will be opened by >>>>>> default for these objects). This is because I extended my inspectors to >>>>>> provide roassal visualization that are quite large. >>>>>> >>>>>> How can I do it ? >>>>>> >>>>>> For example I would like something like that: >>>>>> >>>>>> MyObject>>#gtInitialWindowExtent >>>>>> < gtInitialWindowExtent > >>>>>> ^ 800@1000 >>>>>> >>>>>> Clement >>>>>> >>>>>> >>>>> >>>>> I think this is not doable. >>>>> You can change the method with the inspector pragma to be called with >>>>> the context (inspector instance) >>>>> >>>>> gtInspectorItemsIn: composite inContext: aGTInspector >>>>> <gtInspectorPresentationOrder: 30> >>>>> >>>>> instead of >>>>> >>>>> gtInspectorItemsIn: composite >>>>> <gtInspectorPresentationOrder: 30> >>>>> >>>>> this way you have access to the glamour inspector. Unfortunately it >>>>> does not have any >>>>> window extent property. >>>>> >>>>> Maybe we can move the initialExtent property from GLMBrowser up to >>>>> GLMPresentation? >>>>> That way it would be accessible and usable for this aGTInspector >>>>> argument. >>>>> >>>>> >>>>> >>>>> Nicolai >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 28, 2014

Re: [Pharo-dev] Problem with input of localized characters by Michal

by lb

Hiï¼Michal I used Pharo 3 or 4 in Windows and happened to the similar problem, l found: (Notice the Bold Part) HandMorph>>generateKeyboardEvent: evtBuf "Generate the appropriate mouse event for the given raw event buffer" | buttons modifiers type pressType stamp charCode keyValue keyEvent | stamp := evtBuf second. stamp = 0 ifTrue: [stamp := Time millisecondClockValue]. pressType := evtBuf fourth. pressType = EventKeyDown ifTrue: [ type := #keyDown. lastKeyScanCode := evtBuf third]. pressType = EventKeyUp ifTrue: [type := #keyUp]. pressType = EventKeyChar ifTrue: [ type := #keystroke]. modifiers := evtBuf fifth. buttons := modifiers bitShift: 3. keyValue := evtBuf third. charCode := evtBuf sixth. "Adjustments to provide consistent key value data for different VM's : - charCode always contains unicode code point. - keyValue contains 0 if input is outside legacy range " "If there is no unicode data in the event, assume keyValue contains a correct (<256) Unicode codepoint, and use that" (charCode isNil or: [charCode = 0]) ifTrue: [charCode := keyValue]. "If charCode is not single-byte, we definately have Unicode input. Nil keyValue to avoid garbage values from some VMs." charCode > 255 ifTrue: [keyValue := 0]. type = #keystroke ifTrue: [combinedChar ifNil: [ | peekedEvent | peekedEvent := Sensor peekEvent. (peekedEvent notNil and: [peekedEvent fourth = EventKeyDown]) ifTrue: [ (CombinedChar isCompositionCharacter: charCode) ifTrue: [ combinedChar := CombinedChar new. combinedChar simpleAdd: charCode asCharacter. (combinedChar combinesWith: peekedEvent third asCharacter) ifTrue: [^nil]. ]]] ifNotNil: [ (combinedChar simpleAdd: charCode asCharacter) ifTrue: [charCode := combinedChar combined charCode]. combinedChar := nil]]. self flag: #fixme. "This piece of code handles the creation of scrolling events. When a scroll is done by the user, the VM forwards a keystroke event with the up/down key. So we reconvert it to a MouseWheelEvent in that case." (type = #keystroke and: [(buttons anyMask: 16) and: [charCode = 30 or: [charCode = 31]]]) ifTrue: [^MouseWheelEvent new setType: #mouseWheel position: lastMouseEvent cursorPoint direction: (charCode = 30 ifTrue: [#up] ifFalse: [#down]) buttons: buttons hand: self stamp: stamp]. keyEvent := KeyboardEvent new setType: type buttons: buttons position: self position keyValue: keyValue charCode: charCode hand: self stamp: stamp. keyEvent scanCode: lastKeyScanCode. ^keyEvent MayBe it works. Have a fun! BingLiang

Nov. 28, 2014

Problem with input of localized characters by Michal

by lb

Hiï¼Michal I used Pharo 3 or 4 and happened to the similar problem, l found: (Pls notice the Bold Part) HandMorph>>generateKeyboardEvent: evtBuf "Generate the appropriate mouse event for the given raw event buffer" | buttons modifiers type pressType stamp charCode keyValue keyEvent | stamp := evtBuf second. stamp = 0 ifTrue: [stamp := Time millisecondClockValue]. pressType := evtBuf fourth. pressType = EventKeyDown ifTrue: [ type := #keyDown. lastKeyScanCode := evtBuf third]. pressType = EventKeyUp ifTrue: [type := #keyUp]. pressType = EventKeyChar ifTrue: [ type := #keystroke]. modifiers := evtBuf fifth. buttons := modifiers bitShift: 3. keyValue := evtBuf third. charCode := evtBuf sixth. "Adjustments to provide consistent key value data for different VM's : - charCode always contains unicode code point. - keyValue contains 0 if input is outside legacy range " "If there is no unicode data in the event, assume keyValue contains a correct (<256) Unicode codepoint, and use that" (charCode isNil or: [charCode = 0]) ifTrue: [charCode := keyValue]. "If charCode is not single-byte, we definately have Unicode input. Nil keyValue to avoid garbage values from some VMs." charCode > 255 ifTrue: [keyValue := 0]. type = #keystroke ifTrue: [combinedChar ifNil: [ | peekedEvent | peekedEvent := Sensor peekEvent. (peekedEvent notNil and: [peekedEvent fourth = EventKeyDown]) ifTrue: [ (CombinedChar isCompositionCharacter: charCode) ifTrue: [ combinedChar := CombinedChar new. combinedChar simpleAdd: charCode asCharacter. (combinedChar combinesWith: peekedEvent third asCharacter) ifTrue: [^nil]. ]]] ifNotNil: [ (combinedChar simpleAdd: charCode asCharacter) ifTrue: [charCode := combinedChar combined charCode]. combinedChar := nil]]. self flag: #fixme. "This piece of code handles the creation of scrolling events. When a scroll is done by the user, the VM forwards a keystroke event with the up/down key. So we reconvert it to a MouseWheelEvent in that case." (type = #keystroke and: [(buttons anyMask: 16) and: [charCode = 30 or: [charCode = 31]]]) ifTrue: [^MouseWheelEvent new setType: #mouseWheel position: lastMouseEvent cursorPoint direction: (charCode = 30 ifTrue: [#up] ifFalse: [#down]) buttons: buttons hand: self stamp: stamp]. keyEvent := KeyboardEvent new setType: type buttons: buttons position: self position keyValue: keyValue charCode: charCode hand: self stamp: stamp. keyEvent scanCode: lastKeyScanCode. ^keyEvent MayBe it works. Have a fun! BingLiang

Nov. 28, 2014

Reï¼Problem with input of localized characters

by lb

Hiï¼Michal I used Pharo 3 or 4 and happened to simmilar problem, l found: (Pls notice the Bold Part) HandMorph>>generateKeyboardEvent: evtBuf "Generate the appropriate mouse event for the given raw event buffer" | buttons modifiers type pressType stamp charCode keyValue keyEvent | stamp := evtBuf second. stamp = 0 ifTrue: [stamp := Time millisecondClockValue]. pressType := evtBuf fourth. pressType = EventKeyDown ifTrue: [ type := #keyDown. lastKeyScanCode := evtBuf third]. pressType = EventKeyUp ifTrue: [type := #keyUp]. pressType = EventKeyChar ifTrue: [ type := #keystroke]. modifiers := evtBuf fifth. buttons := modifiers bitShift: 3. keyValue := evtBuf third. charCode := evtBuf sixth. "Adjustments to provide consistent key value data for different VM's : - charCode always contains unicode code point. - keyValue contains 0 if input is outside legacy range " "If there is no unicode data in the event, assume keyValue contains a correct (<256) Unicode codepoint, and use that" (charCode isNil or: [charCode = 0]) ifTrue: [charCode := keyValue]. "If charCode is not single-byte, we definately have Unicode input. Nil keyValue to avoid garbage values from some VMs." charCode > 255 ifTrue: [keyValue := 0]. type = #keystroke ifTrue: [combinedChar ifNil: [ | peekedEvent | peekedEvent := Sensor peekEvent. (peekedEvent notNil and: [peekedEvent fourth = EventKeyDown]) ifTrue: [ (CombinedChar isCompositionCharacter: charCode) ifTrue: [ combinedChar := CombinedChar new. combinedChar simpleAdd: charCode asCharacter. (combinedChar combinesWith: peekedEvent third asCharacter) ifTrue: [^nil]. ]]] ifNotNil: [ (combinedChar simpleAdd: charCode asCharacter) ifTrue: [charCode := combinedChar combined charCode]. combinedChar := nil]]. self flag: #fixme. "This piece of code handles the creation of scrolling events. When a scroll is done by the user, the VM forwards a keystroke event with the up/down key. So we reconvert it to a MouseWheelEvent in that case." (type = #keystroke and: [(buttons anyMask: 16) and: [charCode = 30 or: [charCode = 31]]]) ifTrue: [^MouseWheelEvent new setType: #mouseWheel position: lastMouseEvent cursorPoint direction: (charCode = 30 ifTrue: [#up] ifFalse: [#down]) buttons: buttons hand: self stamp: stamp]. keyEvent := KeyboardEvent new setType: type buttons: buttons position: self position keyValue: keyValue charCode: charCode hand: self stamp: stamp. keyEvent scanCode: lastKeyScanCode. ^keyEvent MayBe it woks. Have a fun! BingLiang

Nov. 28, 2014