October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Input problems

by Schwab,Wilhelm K

I just cranked up an old machine and pounded some before and after. I'm sad to say that I do not see much of a change; I had high hopes for this. Please understand that my typing is not perfect, and keyboards might not be also. One truly nutty idea that comes to mind: we might record sound from people's typing and try to pick out how many keys they actually hit. That would not be perfect either, but it could easily turn out to be more objective than my best guess at whether I'm in fact hitting keys and they are not showing up. I am confident that Pharo loses input when under stress. You must think that too or you would not be working on the problem (for which thanks). Before trying sound beyond a basic feasibility test, we should plan what we would do, and decide whether or not it is something we could publish. Some basic thoughts would be that we should capture keyboard events vs. simply edited text - that would prevent problems with the backspace confusing us, and should also tell us what Pharo thinks about the timing of the strikes. The latter should help a lot in aligning the events with sound features; any latencies we uncover might give useful clues too. I _think_ I could find the keypresses in an audio recording; I do some work with wavelets and would hopefully be able to isolate the strikes with thresholding in a suitable scale. Will work for co-authorship :) If anyone is remotely interested and has a microphone already set up, a good starting point would be to send me recordings of a couple of people typing, ideally with a really good touch typist and somebody who struggles a little. If it looks anything like I expect, I can hopefully entice you with a wavelet baed detector and then we would tackle the event capture. Eventually I would envision the usual suspects for the Sprints gathering around preferably an older computer with a shiny new keyboard, but that would happen only when we have a fix and want to compare throughput before and after the fix. I would gladly crunch the acoustic data to the best of my ability. Note that it is preferred to get data sets of an integral power of two in length, which of course couples with sampling frequency (Nyquist offers some suggestions there of course) and duration. Another factor on duration is to record long enough to see a difference. We can work out most of that later, assuming there is interest and we have a fix in hand. I'll stop now :) Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Saturday, October 17, 2009 5:55 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Input problems Hi all, after looking at the different input problems again it seems to me that they might all go back to problems with SharedQueue. Attached is a small change file for all who regularly experience problems with loosing characters while typing or double pastes. Please let me know if after filing in the change set the issues are fixed, less often or unchanged. Thanks Michael

Oct. 17, 2009

[Pharo-project] making all tests green -- ReleaseTest>>testObsoleteClasses (issue 1310)

by Oscar Nierstrasz

When running all the tests, ReleaseTest>>testObsoleteClasses discovers some hundreds of generated classes that are not properly cleaned up. You can also get an inspector on these classes by running: SmalltalkImage current fixObsoleteReferences. (If the result is not empty, an inspector will pop up.) Here are the tests cases responsible for many of these classes: Tests-Traits -- 130 obsolete classes RequiresOriginalTestCase>>testSins creates CAB ... TraitsResource>>setUp creates C1 ... SUnit-Extensions, SUnit-Tests ? ClassFactoryForTestCase>>newName creates ClassForTestToBeDeleted IVsAndClassVarNamesConflictTest>>setUp creates ClassForTestToBeDeleted These sometimes are left as obsolete classes ... Tests-Monticello -- 2 obsolete classes MCFileInTest>> ... creates MCMockClassA MCMockClassG To check this, grab a clean pharo core image, run: SmalltalkImage current fixObsoleteReferences The result should be empty. Then run Tests-Traits (or any of the others) and re-run the expression. You will then see the obsolete classes. Exploring pointers to these classes however does not tell me why they are still hanging around. That's as far as I got. - on

Oct. 17, 2009

[Pharo-project] [update] #10477

by StÃ©phane Ducasse

10477 ----- - Issue 1224: Avoiding uncessary pop up when compiling a method - Issue 1044: MethodContext allInstances loops forever

Oct. 17, 2009

Re: [Pharo-project] Issue 1311: Refactoring scope is broken

by Lukas Renggli

> Bottom line: I am wondering whether Shout is suppressing non-displayable characters that are confusing the RB?? >From what I saw the issues in RB had nothing to do with unprintable characters, but from the question how to parse expressions like #( . ; ^ [ ] { } ). I've changed RB to parse them the same as the Squeak/VW parser does. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 17, 2009

Re: [Pharo-project] _ into := changes based on RB

by StÃ©phane Ducasse

On Oct 17, 2009, at 5:12 PM, Lukas Renggli wrote: > In fact the following script does everything in a pharo core image. In > my case it finds changes in Graphics and System-Hashing: > > ScriptLoader > loadLatestPackage: 'Gofer' from: 'http://source.lukas-renggli.ch/ > flair'. > Gofer new > squeaksource: 'AST'; > addPackage: 'AST' constraint: [ :v | v authorName = 'lr' ]; > load. > Gofer new > squeaksource: 'RefactoringEngine'; > addPackage: 'Refactoring-Core'; > load. > rule := RBUnderscoreAssignmentRule new. > SmalllintChecker runRule: rule onEnvironment: BrowserEnvironment new. > rule changes do: [ :each | each execute ] yes me too :) Stef > > Lukas > > 2009/10/17 Lukas Renggli <renggli(a)gmail.com>: >> It works for me in the latest Pharo with AST-lr.176 and Refactoring- >> Core-lr.59. >> >> With the following snippet you don't need the OB UI: >> >> rule := RBUnderscoreAssignmentRule new. >> SmalllintChecker runRule: rule onEnvironment: BrowserEnvironment >> new. >> rule changes do: [ :each | each execute ] >> >> Lukas >> >> 2009/10/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> ok thanks. >>> let us know after I will run and produce a batch of packages that >>> get := >>> Stef >>> >>> On Oct 17, 2009, at 4:46 PM, Lukas Renggli wrote: >>> >>>> That looks correct. I will try in the latests Pharo and try to >>>> get rid >>>> of these dependencies in the AST package. >>>> >>>> Lukas >>>> >>>> 2009/10/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> lukas I loaded AST like that and >>>>> I get open DNU. >>>>> >>>>> Stef >>>>> >>>>> |instClass installWebTools font codeFont titleFont| >>>>> >>>>> instClass := Smalltalk at: #Installer ifAbsent: [ScriptLoader >>>>> loadLatestPackage: 'Installer-Core' fromSqueaksource: 'Installer'. >>>>> Smalltalk at: #Installer]. >>>>> >>>>> instClass ss >>>>> project: 'AST'; >>>>> install: 'AST-lr'. >>>>> >>>>> instClass ss >>>>> project: 'RefactoringEngine'; >>>>> install: 'Refactoring-Core'. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > 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

Oct. 17, 2009

[Pharo-project] [update] #10476

by StÃ©phane Ducasse

10476 ----- Fix underscores

Oct. 17, 2009

Re: [Pharo-project] Issue 1311: Refactoring scope is broken

by Schwab,Wilhelm K

Lukas, Apologies if this is a waste of time, but my first thought is of something that I have seen thanks to defect 1135 (now closed). When the fonts stopped working, I would frequently see a column of boxes (representing some type of non-printable character??) down the left margin of my code in the browsers. The code in question could have come into Pharo via SIF, which while greatly appreciated for what it is doing for me, is not perfect. The code was exported from Dolphin on Windows; I was probably still doing some of my Pharo work on Windows at that point. So, the offending code crossed dialects and perhaps platforms. Bottom line: I am wondering whether Shout is suppressing non-displayable characters that are confusing the RB?? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Saturday, October 17, 2009 4:14 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 1311: Refactoring scope is broken I'll look into this. Look like a bug in the RBScanner. Cheers, Lukas 2009/10/17 Oscar Nierstrasz <oscar(a)iam.unibe.ch>: > > Take latest pharo1.0-10470-BETAdev09.10.2 (must be a dev image). > > - Select (say) AST-Nodes category (or any other category) > - refactoring scope>super-sends > - Yields: Error: Unknown character in literal array > > The same is observed for self-sends ... Also using the package browser. > According to David Roethlisberger, this should be a problem in RB. Â It > encounters a nil character while parsing all the methods, which > happens when an unknown character is encountered. > > The problem appears to be an unknown character somewhere within > ClosureCompilerTest>>#testInjectIntoDecompilations > > Deleting the body of this method "fixes" the problem :-( > > - on > > > _______________________________________________ > 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

Oct. 17, 2009

Re: [Pharo-project] _ into := changes based on RB

by StÃ©phane Ducasse

Thanks!!!!!!!!!!!!!!!!!!!!!! Stef > It works for me in the latest Pharo with AST-lr.176 and Refactoring- > Core-lr.59. > > With the following snippet you don't need the OB UI: > > rule := RBUnderscoreAssignmentRule new. > SmalllintChecker runRule: rule onEnvironment: BrowserEnvironment new. > rule changes do: [ :each | each execute ] > >

Oct. 17, 2009

Re: [Pharo-project] _ into := changes based on RB

by Lukas Renggli

In fact the following script does everything in a pharo core image. In my case it finds changes in Graphics and System-Hashing: ScriptLoader loadLatestPackage: 'Gofer' from: 'http://source.lukas-renggli.ch/flair'. Gofer new squeaksource: 'AST'; addPackage: 'AST' constraint: [ :v | v authorName = 'lr' ]; load. Gofer new squeaksource: 'RefactoringEngine'; addPackage: 'Refactoring-Core'; load. rule := RBUnderscoreAssignmentRule new. SmalllintChecker runRule: rule onEnvironment: BrowserEnvironment new. rule changes do: [ :each | each execute ] Lukas 2009/10/17 Lukas Renggli <renggli(a)gmail.com>: > It works for me in the latest Pharo with AST-lr.176 and Refactoring-Core-lr.59. > > With the following snippet you don't need the OB UI: > > Â rule := RBUnderscoreAssignmentRule new. > Â SmalllintChecker runRule: rule onEnvironment: BrowserEnvironment new. > Â rule changes do: [ :each | each execute ] > > Lukas > > 2009/10/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> ok thanks. >> let us know after I will run and produce a batch of packages that get := >> Stef >> >> On Oct 17, 2009, at 4:46 PM, Lukas Renggli wrote: >> >>> That looks correct. I will try in the latests Pharo and try to get rid >>> of these dependencies in the AST package. >>> >>> Lukas >>> >>> 2009/10/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> lukas I loaded Â AST like that and >>>> I get open DNU. >>>> >>>> Stef >>>> >>>> |instClass installWebTools font codeFont titleFont| >>>> >>>> instClass := Smalltalk at: #Installer ifAbsent: [ScriptLoader >>>> loadLatestPackage: 'Installer-Core' fromSqueaksource: 'Installer'. >>>> Smalltalk at: #Installer]. >>>> >>>> instClass ss >>>> Â Â Â Â project: 'AST'; >>>> Â Â Â Â install: 'AST-lr'. >>>> >>>> instClass ss >>>> Â Â Â Â project: 'RefactoringEngine'; >>>> Â Â Â Â install: 'Refactoring-Core'. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 17, 2009

Re: [Pharo-project] _ into := changes based on RB

by Lukas Renggli

It works for me in the latest Pharo with AST-lr.176 and Refactoring-Core-lr.59. With the following snippet you don't need the OB UI: rule := RBUnderscoreAssignmentRule new. SmalllintChecker runRule: rule onEnvironment: BrowserEnvironment new. rule changes do: [ :each | each execute ] Lukas 2009/10/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > ok thanks. > let us know after I will run and produce a batch of packages that get := > Stef > > On Oct 17, 2009, at 4:46 PM, Lukas Renggli wrote: > >> That looks correct. I will try in the latests Pharo and try to get rid >> of these dependencies in the AST package. >> >> Lukas >> >> 2009/10/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> lukas I loaded Â AST like that and >>> I get open DNU. >>> >>> Stef >>> >>> |instClass installWebTools font codeFont titleFont| >>> >>> instClass := Smalltalk at: #Installer ifAbsent: [ScriptLoader >>> loadLatestPackage: 'Installer-Core' fromSqueaksource: 'Installer'. >>> Smalltalk at: #Installer]. >>> >>> instClass ss >>> Â Â Â Â project: 'AST'; >>> Â Â Â Â install: 'AST-lr'. >>> >>> instClass ss >>> Â Â Â Â project: 'RefactoringEngine'; >>> Â Â Â Â install: 'Refactoring-Core'. >>> >>> >>> >>> _______________________________________________ >>> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 17, 2009