- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fix wikipedia article

by Sven Van Caekenberghe

> On 28 Nov 2014, at 16:55, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > Hi guys, > > Just a heads upâ¦ > > This is asking for a fix: > http://en.wikipedia.org/wiki/Pure_(programming_language) > > LISP and Self and Smalltalk people should add their voice there > > Unleash your nerd :) I don't understand, what do you mean ? The page describes some language called Pure that seems to be legit, so what is wrong with that (apart from the name being ambitious, pretentious) ? And there is http://en.wikipedia.org/wiki/Pharo which is OK but needs some love.

Nov. 28, 2014

7350 window drag ghosting while progress bar is moving

by Ben Coman

A while ago I logged an issue "window drag ghosting while progress bar is moving" [1] - but I haven't noticed this for a long time. Before I close it, has anyone had any similar problems with Pharo 4 ? [1] https://pharo.fogbugz.com/default.asp?7350 cheers -ben

Nov. 28, 2014

Fix wikipedia article

by Sebastian Sastre

Hi guys, Just a heads upâ¦ This is asking for a fix: http://en.wikipedia.org/wiki/Pure_(programming_language) <http://en.wikipedia.org/wiki/Pure_(programming_language)> LISP and Self and Smalltalk people should add their voice there Unleash your nerd :)

Nov. 28, 2014

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

by Marcus Denker

On Fri, Nov 28, 2014 at 4:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > 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). > > Hmm... errors found by the test runner on that change. https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/17683//artifact/val… So we will need to check... Marcus

Nov. 28, 2014

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