- Pharo-dev - lists.pharo.org

[Pharo-project] About Uppercase for class instance variable

by StÃ©phane Ducasse

Hi I would like to know if you encountered class instance variable with starting uppercase letter? I hate that practice. Stef

Nov. 20, 2008

Re: [Pharo-project] Process stuck in 10156+OB?

by Simon Denier

It works for me, thanks John, it's cool to have this feeling of integration with mac os On 20 nov. 08, at 00:03, John M McIntosh wrote: > Ok, I think the fix is below, someone can field test it? > > I did write an Sunit > > The idea is that we want to change (x) to /X which means it's cmd > key x > But also handle the case of ( ) and (() which are aren't allowed by > the api we are using. > Also we change ';' '^' '!' '<' '/' to ' ' and if '(' doesn't > follow the proper patter of (*) then it becomes a space too. > > testCharacterChanging > | testString item shouldBe resultingString where | > #(';' '^' '!' '<' '/' '(' ) > do: [:c | #('*' '* ' '* ' '**' '** ' '** ' > ')' '*)' '* )' '* )' '**)' '** )' '** )' > ')' '*)' '*X)' '*XX)' '**)' '**X)' '**XX)' > '))' '*))' '*X))' '*XX))' '**))' '**X))' '**XX))' > '(' '*(' '*X(' '*XX(' '**)' '**X(' '**XX(' > '((' '*((' '*X((' '*XX((' '**((' '**X((' '**XX((' > ) > do: [:template | > testString := template copyReplaceAll: '*' with: c. > testString > permutationsDo: [:mixedUp | > item := mixedUp copy. > shouldBe := self calculateShouldBeFrom: item using: c. > resultingString := self modifySqueakMenu: item copy. > self should: [shouldBe = resultingString]. > (where := resultingString indexOf: $/) > 0 > ifTrue: [self should: [(mixedUp at: where) = $(]. > self should: [(mixedUp at: where+2) = $)]. > self should: [(mixedUp at: where+1) asUppercase = > (resultingString at: where+1)]]]]] > > where calculateShouldBeFrom: using: runs off and guess at the > proper string with a different algorithm, > an exercise for the user... > > > Fix is below. > > > modifySqueakMenu: aString > | results fixIndex middleCharacter | > results := aString. > results replaceAll: $; with: Character space. > results replaceAll: $^ with: Character space. > results replaceAll: $! with: Character space. > results replaceAll: $< with: Character space. > results replaceAll: $/ with: Character space. > fixIndex := results indexOf: $(. > [fixIndex > 0] > whileTrue: [ > [(results at: fixIndex + 2) = $) > ifTrue: [middleCharacter := results at: fixIndex + 1. > (middleCharacter = Character space or: [middleCharacter = $(]) > ifTrue: [results at: fixIndex put: Character space] > ifFalse: [results at: fixIndex put: $/.]. > results at: fixIndex + 1 put: middleCharacter asUppercase. > results at: fixIndex + 2 put: Character space] > ifFalse: [results at: fixIndex put: Character space]] > ifError: [results at: fixIndex put: Character space]. > fixIndex := results indexOf: $(]. > ^ results > > > On 19-Nov-08, at 1:45 AM, John M McIntosh wrote: > >> Ya it's my bug, however it's way too late tonight for me to tackle >> it. >> The problem is that if the menu contains (x) and we attempt to >> convert that into a macintosh menu the older os-9 menu logic >> has specialized meanings for character strings of the form (x) so >> we attempt to fix it. >> >> http://developer.apple.com/documentation/mac/Toolbox/Toolbox-144.html >> >> >> I think in this case the morphic menus use (x) to mean x is a >> command key, but that would disable the menu on the macintosh. >> >> So I was fixing up usages of (x) >> >> Obviously not correctly since it fails on strings of the form (x1...) > > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > 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 > -- Simon

Nov. 20, 2008

[Pharo-project] About browsers

by StÃ©phane Ducasse

I have another question why are we forced to click on a method category to define one? We could click on the class and paste a method body then select a category... This is another illustration that the UI of Smalltalk browser is full of modes. I would really like to see an IDE where we limit the number of modes. For example it would be great to maximize the number of shortcut that are transparent = that are not linked to a pane. right now apple-F is linked to look for a class in the class category. but this would be great to have it working anywhere. apple-w to close a window only work on the pasteUpMorph I'm sure that there are a lot more of such case. I went over the shortcut list and lot of them are not working and it would be good to check and rethink them. Stef PS: David the inheritance pane is now working extremely well. It is really cool to be able to double click on it to see the new inheritance tree and the switch between the smart group selection and the package view is really great. Really this is getting really really smooth. I really have to pay attention to notice that it is working well. Also the fact that I can type an word and get the classes, methods in a smart group is great. I start to go really fast with your browser.

Nov. 20, 2008

Re: [Pharo-project] Event history question

by Michael Rueger

Igor Stasenko wrote: > If i remember correctly, an interrupt semaphore is used to awake a > process which watching for interrupts. > And indeed, when key combination matching an interrupt key code, > it calls setInterruptPending(), which is then eventually leads to > signaling a semaphore which registered as interrupt semaphore. > You can't handle it on image side, because you may not have chance to > get to it (if there's another process running on same or higher > priority than event ticker process). > While in VM, regardless what image does, it periodically checks for > interrupts, and during handling OS events, it checks if an interrupt > key pressed, and if so, then signals the semaphore. > At least, this is how it looks on Win32. The question really was if it is in the VM but rather if it (still) should be in the VM. After some discussions with John I'm pretty sure we can remove the interrupt semaphore code from the VM. For now that would mean that the image code still referring to it should/can be removed. Michael

Nov. 20, 2008

Re: [Pharo-project] Event history question

by Igor Stasenko

2008/11/20 Michael Rueger <m.rueger(a)acm.org>: > Hi all, > > the event handling rewrite slowly starts to work :-) > I'm currently fighting the parts where polling is used (like moving a > window), but more on that later. > > The question I have is about user interrupt handling. I'm a bit confused and > don't remember the history there: > was there first an interrupt semaphore that then was abandoned or was it > introduced but then not supported on some platforms? > > Or phrased differently: > do we want user interrupt go through an interrupt semaphore or rather handle > it on the image side? > If i remember correctly, an interrupt semaphore is used to awake a process which watching for interrupts. And indeed, when key combination matching an interrupt key code, it calls setInterruptPending(), which is then eventually leads to signaling a semaphore which registered as interrupt semaphore. You can't handle it on image side, because you may not have chance to get to it (if there's another process running on same or higher priority than event ticker process). While in VM, regardless what image does, it periodically checks for interrupts, and during handling OS events, it checks if an interrupt key pressed, and if so, then signals the semaphore. At least, this is how it looks on Win32. > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 20, 2008

Re: [Pharo-project] Process stuck in 10156+OB?

by John M McIntosh

Ok, I think the fix is below, someone can field test it? I did write an Sunit The idea is that we want to change (x) to /X which means it's cmd key x But also handle the case of ( ) and (() which are aren't allowed by the api we are using. Also we change ';' '^' '!' '<' '/' to ' ' and if '(' doesn't follow the proper patter of (*) then it becomes a space too. testCharacterChanging | testString item shouldBe resultingString where | #(';' '^' '!' '<' '/' '(' ) do: [:c | #('*' '* ' '* ' '**' '** ' '** ' ')' '*)' '* )' '* )' '**)' '** )' '** )' ')' '*)' '*X)' '*XX)' '**)' '**X)' '**XX)' '))' '*))' '*X))' '*XX))' '**))' '**X))' '**XX))' '(' '*(' '*X(' '*XX(' '**)' '**X(' '**XX(' '((' '*((' '*X((' '*XX((' '**((' '**X((' '**XX((' ) do: [:template | testString := template copyReplaceAll: '*' with: c. testString permutationsDo: [:mixedUp | item := mixedUp copy. shouldBe := self calculateShouldBeFrom: item using: c. resultingString := self modifySqueakMenu: item copy. self should: [shouldBe = resultingString]. (where := resultingString indexOf: $/) > 0 ifTrue: [self should: [(mixedUp at: where) = $(]. self should: [(mixedUp at: where+2) = $)]. self should: [(mixedUp at: where+1) asUppercase = (resultingString at: where+1)]]]]] where calculateShouldBeFrom: using: runs off and guess at the proper string with a different algorithm, an exercise for the user... Fix is below. modifySqueakMenu: aString | results fixIndex middleCharacter | results := aString. results replaceAll: $; with: Character space. results replaceAll: $^ with: Character space. results replaceAll: $! with: Character space. results replaceAll: $< with: Character space. results replaceAll: $/ with: Character space. fixIndex := results indexOf: $(. [fixIndex > 0] whileTrue: [ [(results at: fixIndex + 2) = $) ifTrue: [middleCharacter := results at: fixIndex + 1. (middleCharacter = Character space or: [middleCharacter = $(]) ifTrue: [results at: fixIndex put: Character space] ifFalse: [results at: fixIndex put: $/.]. results at: fixIndex + 1 put: middleCharacter asUppercase. results at: fixIndex + 2 put: Character space] ifFalse: [results at: fixIndex put: Character space]] ifError: [results at: fixIndex put: Character space]. fixIndex := results indexOf: $(]. ^ results On 19-Nov-08, at 1:45 AM, John M McIntosh wrote: > Ya it's my bug, however it's way too late tonight for me to tackle it. > The problem is that if the menu contains (x) and we attempt to > convert that into a macintosh menu the older os-9 menu logic > has specialized meanings for character strings of the form (x) so we > attempt to fix it. > > http://developer.apple.com/documentation/mac/Toolbox/Toolbox-144.html > > > I think in this case the morphic menus use (x) to mean x is a > command key, but that would disable the menu on the macintosh. > > So I was fixing up usages of (x) > > Obviously not correctly since it fails on strings of the form (x1...) -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 19, 2008

[Pharo-project] Event history question

by Michael Rueger

Hi all, the event handling rewrite slowly starts to work :-) I'm currently fighting the parts where polling is used (like moving a window), but more on that later. The question I have is about user interrupt handling. I'm a bit confused and don't remember the history there: was there first an interrupt semaphore that then was abandoned or was it introduced but then not supported on some platforms? Or phrased differently: do we want user interrupt go through an interrupt semaphore or rather handle it on the image side? Michael

Nov. 19, 2008

[Pharo-project] SUnit: history support and OB icons

by Simon Denier

Hi all Just to notify a new enhancement to review in the PharoInbox. SLICE-Issue338-SUnitHistoryAndIcons-simon_denier.2 Short doc: Add: - support history for test runs as well as progression filter to show test in progression, regression - support icons in OB to show the current state of a test: passed, failed, progressed, regressed... History support: - whenever some test cases run from the TestRunner, their results are stored in a class side variable TestResult class>>History - contextual menu for history in TestRunner>>error pane: 1) History: access submenu to TestRunner instance history: can save and show progress between results ran in the same TestRunner; lost when this particular instance of TestRunner is closed 2) Store results as progress reference: create/update a lastStoredRun method on the class side of each TestCase which have just been run, containing the results 3) Show progress: make a diff between the last run and the lastStoredRun, showing progress or regress in tests (new passed, new failures, new errors) The idea is that whenever you are satisfied with the current results of some of your tests, you can save this state as a reference point with the 'Store results...' action. This reference point can be compared with subsequent test results to show your progression or regression. Test results are stored in a class side variable some are kept local to your image. Reference results are stored in a special method for each TestCase, so that they are saved with their package and can be used as a common reference for package developers. So a good practice is to store the latest test results as reference before committing your changes. Icons support: OB Package browser now has icons for test methods in TestCase subclasses: - green circle: test has passed in the last run - red circle: test has failed - half green/half red circle: state unknown, test has no history or test has changed since last run - (no icon): test has raised an error - upside green arrow: test has progressed since last reference run - downside blue triangle: test has regressed since last reference run A test is in progression if it goes from error or failure to passed state. A test is in regression if it goes from passed to error or failure state. The last two icons have other meanings with methods not related to test, so we should change them whenever someone has better icons. Authors: Alexandre Bergel, Simon Denier, David RÃ¶thlisberger -- Simon

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Gary Chambers

Lol. Do a clean job from your perspective... the evil morphs will adapt and be assimilated. Resistance is futile! Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 5:17 PM Subject: Re: [Pharo-project] Host window events > 2008/11/19 Gary Chambers <gazzaguru2(a)btinternet.com>: >> It seems, for Morphic, a world is the best mapping to a host window >> (would >> subscribe to relevant events). >> >> Sadly, a lot of Morphic relies on the "main" world, still, worth >> investigating. >> Certainly a *lot* more work to map a SystemWindow to a host window for a >> general case. >> > > Yeah, just yesterday, i thought about things like #openInNewHostWindow > instead of #openInWorld, > but that's really will be tough task :) > I'm currently focused on low-level things. > >> As far a Polymorph goes, I'd be happy to adapt to whatever scheme you >> decide >> :-) > > How cruel you are! :) > Okay, i'll try to make it in own way and then put it on the desk for > people's overview. > >> >> Regards, Gary. >> > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 19, 2008

Re: [Pharo-project] Process stuck in 10156+OB?

by John M McIntosh

Morning on the west coast of Canada, let me write up a few SUnits... On 19-Nov-08, at 1:45 AM, John M McIntosh wrote: > Ya it's my bug, however it's way too late tonight for me to tackle it. > The problem is that if the menu contains (x) and we attempt to > convert that into a macintosh menu the older os-9 menu logic > has specialized meanings for character strings of the form (x) so we > attempt to fix it. > > http://developer.apple.com/documentation/mac/Toolbox/Toolbox-144.html > > > I think in this case the morphic menus use (x) to mean x is a > command key, but that would disable the menu on the macintosh. > > So I was fixing up usages of (x) > > Obviously not correctly since it fails on strings of the form (x1...) > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 19, 2008