February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14359

by Marcus Denker

14359 ----- Issue 5395: Clean Package PolyMorphSpd http://code.google.com/p/pharo/issues/detail?id=5395 Issue 5394: remove empty Finder package http://code.google.com/p/pharo/issues/detail?id=5394 Issue 5389: isFreeTypeInstalled is not used http://code.google.com/p/pharo/issues/detail?id=5389 Issue 5393: refresh display when exiting emergency evaluator http://code.google.com/p/pharo/issues/detail?id=5393 Issue 5384: remove BlockContext from specialObjectsArray http://code.google.com/p/pharo/issues/detail?id=5384 -- Marcus Denker -- http://marcusdenker.de

Feb. 26, 2012

Re: [Pharo-project] [update 1.4] #14355

by StÃ©phane Ducasse

>> Of course it is always much better if the author of the patch can see >> that it caused some problem than when some other person must later >> investigate what patch of an update has evil side effect. >> >> I hardly need to tell you that it is very demotivating to wait what >> next will break something again (as this week one single update fixed >> one issue and brought the next one). Instead of improving of the >> system we must spend a lot of energy on maintenance. >> >> We definitely must improve the QA process. > > To support my lemmenting I must say that the state of non-failing > kernel jobs lasted only 10 hours. :-) Excellent! :) Seriously it means that we should work on rules checking so that we identify the violations. People used tests for that now as soon as we have small lint we should be able to express architecture rules. Stef

Feb. 26, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by StÃ©phane Ducasse

Hi hannes I tried to understand the purpose of your emails but I could not. - So do you suggest that we all stop Smalltalk and move to javascript? - What is your motivation? - This is good for us to know that but then so what? - Does it help us anyhow to make pharo better? - Did you try to port the code to Squeak? - Do you know if the global handling of coordinates have been changed? We can spend our life looking why other people are doing or we can invent OUR future. Stef > A simple runtime example (runs directly in the web browser), the > JavaScript code (with a short introduction) and the documentation are > all in the three links given in the previous mail. > > Please note that it is a simple implementation of Morphic. The the > code has a neat look and is very readable. > > --Hannes > > > On 2/25/12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> can you send the code that we play with it because I would like to learn how >> you do that. >> >> Stef >> >> On Feb 24, 2012, at 7:02 PM, S Krish wrote: >> >>> I love Pharo's ability to mould/ twist in spare time something that is >>> imminently usable.. >>> >>> Just playing around over an hour plus, I find this tree view grouping >>> more convinient than current browsers in giving a coherent view that >>> easily extends: >>> >>> All editable code text morphs, spreading over to mutliple worlds one >>> can traverse too if needed. or appears on tab anyways for each group. >>> >>> a) Package, Class, Category , Hierarchy levels. >>> >>> b) Senders, implementors .. >>> >>> c) Arbitrary groups of methods if one desires to.. >>> >>> Can also include some class definition info bubble/ reduce noise >>> through some more optimization to make it optimized >>> >>> ... we can have a little customizations too to get a good grip of the >>> whole as well as the part. >>> >>> But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo >>> fragmented view it will still represented. May be each will have >>> little twist of his predilictions and cannot be highly generalized. >>> >>> >>> On 2/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia(a)gmail.com> >>>> wrote: >>>>> On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck >>>>> <marianopeck(a)gmail.com> wrote: >>>>>> Nooo!!! he comes from Java!! he starts with index 0. Kill him!!! ;) >>>>> >>>>> Ooops... Time to get a new identity :) >>>>> >>>>> >>>>> On 23 February 2012 19:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>> wrote: >>>>>> Sure we know. >>>>>> And we also know that it requires effort and lot of people are talking. >>>>> >>>>> I know there's a loooong way to see what CodeBubbles can do, and that >>>>> requires to do a big effort, but imagined that some kind of >>>>> alternative - I'm not sure that CB is **exactly** what I want (sure >>>>> Java-ers want to see **something more** than just a file pimped with >>>>> colours, but Smalltalk **allready has** much more than a text file - >>>>> have real code) - could be very less effort-consuming. Making the >>>>> current browser (Nautilus? - newbie here :) ) pop a new >>>>> Â¿window?Â¿morph? showing a method instead of updating a single pane >>>>> (the current one showing method's source) don't seems to be so "far" >>>>> away to me. >>>>> >>>>> Of course that's my point of view, based on what I imagine that could >>>>> be. I should spend some time to see how it is implemented, and to see >>>>> if it really is that simple, but anyway trust you if you say is a huge >>>>> effort... >>>>> >>>> >>>> Well, popping out a new morph every time you clicking around is easy >>>> part. >>>> The hard part is to make this stuff really consistent and easy to use >>>> for navigation and development. >>>> It requires far more serious work than just spending 2 hours >>>> implementing "bubbling" behavior. >>>> >>>>> >>>>> Cheers :) >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>> <Pharo_CodeBrowser01.JPG> >> >> >> > <morphic.js-screenshot.PNG>

Feb. 26, 2012

Re: [Pharo-project] Monticello and Announcements

by StÃ©phane Ducasse

Ok I will have a look after the exercises (you know physical movements :). Stef On Feb 25, 2012, at 9:13 PM, Benjamin wrote: > Hi guys, > > I just started to add some Announcements in Monticello (see http://code.google.com/p/pharo/issues/detail?id=5392) cause I need them to keep the sync between Nautilus and the system :) > > Could an integrator have a look and see if the version in integrable (cause some cool Nautilus features are pending because of this :) ) please ? > Could someone who knows well Monticello indicates me where to have a look ? > > > Of course any feedbacks, questions, suggestions are welcome :) > > > Ben

Feb. 26, 2012

Re: [Pharo-project] Emergency evaluator refresh problem

by Marcus Denker

On Feb 25, 2012, at 3:44 PM, Marcus Denker wrote: > > On Feb 24, 2012, at 7:46 PM, Usman Bhatti wrote: > >> After exiting from emergency evaluator in pharo, pharo desktop/home is not repainted/refreshed. Is it an issue or a feature? >> > > I think when the evaluator pops up people just don't care about details like that anymore. > (I mean, something *horrible* whent wrong and everyone is happy to just ne able to rescue the image... > refresh then is just not on your mind). > http://code.google.com/p/pharo/issues/detail?id=5393 -- Marcus Denker -- http://marcusdenker.de

Feb. 26, 2012

Re: [Pharo-project] [update 1.4] #14355

by Pavel Krivanek

On Sat, Feb 25, 2012 at 10:45 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Sat, Feb 25, 2012 at 10:13 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Feb 25, 2012, at 5:20 PM, StÃ©phane Ducasse wrote: >>> >>>> Excellent! >>>> Pavel >>>> We should add Pharo Kernel as dependent of the head so that we get immediate feedback like that. >>>> because this is really great. >>>> >>> >>> It already is configured to be build after every update: >>> >>> Â Â Â Â https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ >>> >>> tests, too: >>> >>> Â Â Â Â https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Tests/ >>> >>> Now we need to take action when it breaks... >> >> Of course it is always much better if the author of the patch can see >> that it caused some problem than when some other person must later >> investigate what patch of an update has evil side effect. >> >> I hardly need to tell you that it is very demotivating to wait what >> next will break something again (as this week one single update fixed >> one issue and brought the next one). Instead of improving of the >> system we must spend a lot of energy on maintenance. >> >> We definitely must improve the QA process. > > To support my lemmenting I must say that the state of non-failing > kernel jobs lasted only 10 hours. :-) > > -- Pavel > hmm, this failure of Pharo Kernel Tests has interesting reason. It fails because in the package CompilerTests there is one class (CustomParserTest) that uses customParser. The custom parser class is present in the same package but its definition follows its usage. It seems that it is not related to a single update but it is caused by an accidental order in *.st file from the mcz archive. So it may disappear with the next commit of the CompilerTests package. -- Pavel >> >> -- Pavel >> >> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>>

Feb. 25, 2012

Re: [Pharo-project] [update 1.4] #14355

by Pavel Krivanek

On Sat, Feb 25, 2012 at 10:13 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Feb 25, 2012, at 5:20 PM, StÃ©phane Ducasse wrote: >> >>> Excellent! >>> Pavel >>> We should add Pharo Kernel as dependent of the head so that we get immediate feedback like that. >>> because this is really great. >>> >> >> It already is configured to be build after every update: >> >> Â Â Â Â https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ >> >> tests, too: >> >> Â Â Â Â https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Tests/ >> >> Now we need to take action when it breaks... > > Of course it is always much better if the author of the patch can see > that it caused some problem than when some other person must later > investigate what patch of an update has evil side effect. > > I hardly need to tell you that it is very demotivating to wait what > next will break something again (as this week one single update fixed > one issue and brought the next one). Instead of improving of the > system we must spend a lot of energy on maintenance. > > We definitely must improve the QA process. To support my lemmenting I must say that the state of non-failing kernel jobs lasted only 10 hours. :-) -- Pavel > > -- Pavel > > >> -- >> Marcus Denker -- http://marcusdenker.de >> >>

Feb. 25, 2012

Re: [Pharo-project] [update 1.4] #14356

by Pavel Krivanek

The least we can do is to move such tests to a package that will not be loaded. Something like CompilerToolsNotificationsTests or so... -- Pavel On Sat, Feb 25, 2012 at 3:37 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Ah yes, that was me, since one feature of the Compiler is to insert > notifications into source text editor, this has to be tested. > - does the Compiler insert the right notification ? > - does it insert the notification at the right place ? > > As soon as TextMorph and SmalltalkEditor provide a hook for > evaluating/compiling source, and a callback for notifications they > become inter-dependent. And we'd better write a test documenting the > interdependency. > > Of course, we can replace the TextEditor with a mock up, like the one > in CompilerTest and split the interdependency in two parts. > And then assert on the notifier side that: > - the compiler emit notifications with 1-based insertion point indices > (1 means insert before first character) > (Though I don't like the hardcoded positions in CompilerTest, it's not > readble, but could be changed). > > Right now, the notified side of interdependency is missing, I see no > test asserting that: > - SmalltalkEditor notify:at:in: insert notifications with 1-based indices > > If I change TextEditor insertion points to be 0-based, this will get > unnoticed... > > And this decomposition being less immediate than my simple tests, we > forgot one feature which is to evaluate a sub-selection. > This feature makes the interdependency much more complex > - is notifier aware of sub-selection location ? If yes, does it > provide a location related to beginning of sub-selection of beginning > of text ? > - same for the notified side... > > I'm sure that decomposing the dependency explicitly with tests would > help reducing the complexity... > That was one of my questions: > - what if we change usage of ReadWriteStream on:from:to: in selectionAsStream? > > Since I wrote tests in Squeak and simply ported to Pharo, and since I > missed CompilerTest (which is in Test-Compiler not in CompilerTests, > why the hell having two packages?), we could push refactoring further. > I made a class for testing a pair (Compiler notifying a > SmalltalkEditor), and a subclass for testing another pair (Compiler > notifying nil), but I think Pharo has very new capabilities, like > working with console like I/O, so this is another variant to test, and > maybe in this case splitting interdependency in two is not an > over-engineered feature anymore ;) > > Nicolas > > Le 25 fÃ©vrier 2012 14:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> a Ã©crit : >> Great, The basic Pharo Kernel Jobs can be build again! Leaving aside >> the fact that number of failing tests significantly increased because >> someone made compiler tests dependent on TextMorph (setUpForErrorsIn:) >> :-) >> >> -- Pavel >> >> On Sat, Feb 25, 2012 at 8:43 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> 14356 >>> ----- >>> >>> Issue 5376: Â Â AbstractTool fix removeMethods method >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5376 >>> >>> Issue 5371: Â Â XTableForUnicodeFont is not used anywhere (and an internal class) >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5371 >>> >>> Issue 5372: Â Â Remove old Mac font reading in StrikeFont >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5372 >>> >>> Issue 5370: Â Â AppRegistry class >> #default: dependent on Morphic >>> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5370 >>> >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >> >

Feb. 25, 2012

Re: [Pharo-project] [update 1.4] #14355

by Pavel Krivanek

On Sat, Feb 25, 2012 at 5:28 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 25, 2012, at 5:20 PM, StÃ©phane Ducasse wrote: > >> Excellent! >> Pavel >> We should add Pharo Kernel as dependent of the head so that we get immediate feedback like that. >> because this is really great. >> > > It already is configured to be build after every update: > > Â Â Â Â https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ > > tests, too: > > Â Â Â Â https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Tests/ > > Now we need to take action when it breaks... Of course it is always much better if the author of the patch can see that it caused some problem than when some other person must later investigate what patch of an update has evil side effect. I hardly need to tell you that it is very demotivating to wait what next will break something again (as this week one single update fixed one issue and brought the next one). Instead of improving of the system we must spend a lot of energy on maintenance. We definitely must improve the QA process. -- Pavel > -- > Marcus Denker -- http://marcusdenker.de > >

Feb. 25, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Igor Stasenko

On 25 February 2012 21:48, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > BTW, which version of FF? > well, it updates itself quite frequently nowadays.. i just can tell that it is one of most recent ones. > Yes, it is probably slower that a native Morphic plus VM. I just used Opera. > > The other side of course is that you do not need to deploy anything. > Exciting to have a Morphic experience in a regular web site with a > download of a text file of 213kB. The JavaScript engines get faster > with each browser version. It might be good enough for many cases. > > Jens MÃ¶nig writes that he is working with morphic.js on things like this > http://chirp.scratchr.org/dl/experimental/JsMorphic/nasciturus.html > > So it depends on what to want to use it for. > > My main point however --- I think it is exciting to see a cleanly > written JavaScript port of Morphic. > No doubt. > --Hannes > -- Best regards, Igor Stasenko.

Feb. 25, 2012