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

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

Re: [Pharo-project] Host window events

by Igor Stasenko

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.

Nov. 19, 2008

[Pharo-project] Re: [squeak-dev] Sparkle automatic update framework for Squeak OS-X

by Igor Stasenko

2008/11/19 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > With some funding help from Impara I built a plugin to enable the use of > Sparkle to receive update information about the macintosh carbon VM. > This lets you auto-update your Squeak based application by pushing update > notifications via rss to users. > Numerous one-click squeak based apps come to mind... > > Based on feedback and experience reports at some point I will consider if > this should be part of the mainstream Squeak Carbon VM. > > http://www.squeaksource.com/Sparkle.html > > Which contains the plugin source, the class based interface, and of course > SUnits. > > A 1.0.0 plugin can be found via the usual places in the experimental > directory as > SparklePlugin.1.0.0.bundle.zip > > http://www.smalltalkconsulting.com/squeak.html > That's very nice. Is there any analoguous frameworks for different platforms e.g. Windoze & Linux. I could help with making a windows port of it. There's a couple of things which regularily auto-update themselves on windoze: FireFox and Flash player. It would be nice to have it for squeak as well. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > -- Best regards, Igor Stasenko AKA sig.

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Gary Chambers

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. As far a Polymorph goes, I'd be happy to adapt to whatever scheme you decide :-) 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 4:52 PM Subject: Re: [Pharo-project] Host window events > My vision, how things should happen , is following: > > EventSensor checks an event type in it's newly acqured raw event buffer > from VM. > Then it dispatching an event handling in following way: > > eventClass := (eventTypes at: (rawEvent at: EventType "1"). > event := (eventClass from: rawEvent). "Translate raw event into nice > XXXXEvent instance" > event handle. "dispatch event" > > Now, if event type is window event, eventClass would be, lets say > HostWindowEvent. > And in #handle it does following: > > hostWindow := self window. > hostWindow subscriber handle: self. > > Here the main question, should HostWindow have a notion of > subscriber(s) (as part of its state), > or maybe there should be more generic way to wire a subscriber(s) with > particular HostWindow instance, but without need in managing > subscribers by HostWindow itself. > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > 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