Squeak-dev August 2004

squeak-dev@lists.squeakfoundation.org

154 participants
394 discussions

[Reminder] ESUG conference Early Registration
by Noury Bouraqadi 02 Aug '04

02 Aug '04

Hi, I would like to remind you that the dead-line for early registration to the 12th ESUG Conference is approaching. http://www.esug.org/conferences/twelfthsmalltalkjointevent2004/registration/ Regards, Noury -- ------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Ecole des Mines de Douai - Dept. G.I.P http://csl.ensm-douai.fr/noury European Smalltalk Users Group http://www.esug.org Squeak: an Open Source Smalltalk http://www.squeak.org ------------------------------------------

1 0

Harvesting Party Friday August 6th 05:00 GMT
by Ken Causey 02 Aug '04

02 Aug '04

Just a reminder that the next Harvesting Party will take place between 05:00 (5 AM) and 09:00 (9 AM) GMT Friday August 6th, 2004. As usual we will meet in #squeak on irc.freenode.net. More information about the #squeak IRC channel can be found at http://people.squeakfoundation.org/article/7.html Information about the Harvesting Party idea can be found at http://people.squeakfoundation.org/article/29.html If you have the time please attend and work toward the future of Squeak. The next seven parties are scheduled for 09:00 (09:00 AM) GMT Tuesday August 10, 2004 13:00 (01:00 PM) GMT Saturday August 14, 2004 17:00 (05:00 PM) GMT Wednesday August 18, 2004 21:00 (09:00 PM) GMT Sunday August 22, 2004 01:00 (01:00 AM) GMT Friday August 27, 2004 05:00 (05:00 AM) GMT Tuesday August 31, 2004 09:00 (09:00 AM) GMT Saturday September 04, 2004

1 0

[Bug] ClickState Recursion (request for help)
by Peace Jerome 02 Aug '04

02 Aug '04

Dear Joshua Gargus Hi. I have been trying to learn squeak. Recently I have been reading the code in MouseClickState event handling. The original version of this has your initials on it and was written/added in Sept 2001. The routine that calls it for action is HandMorph>>handleEvent; and that was written six months earlier. MouseClickState>>handleEvent:from: is nonrecursive except at one point where it is processing the first mouseup. There it calls handleEvent: with a copy of the mouseup event after firing the click selector. I've check with a diagnostic and this is definitely a recursive call. The same mouseup comes thru a second time (the click state has changed. And the recursive event glides thru without causing anymore changes.) The recursive call releases it back to handleEvent with the true flag. It is processed to completion. When handleEvent exits the remaining unrecursed event is released back to handleEvent with the original false flag. Furthur processing is not done and handleEvent releases back to its original caller. I do not believe this is what was actually intended. But I do not understand what the actual intention was either. Changing the code so that instead of self click. aHand handleEvent: copiedEvt . ^false we have just: self click. ^true would seem to do the trick as far as the post processing results are concerned. So if there is a difference then it would have to be in what happens before clickstate is checked a second time. >From the rest of the method, it would be the most logical way to have coded it. So obvious that the fact that it was not is curious. Was there something click was supposed to change such as mouse focus that would make the recurssion useful? If click does not change mouse focus then you have the same old listeners to mouse up being fired twice. Which would explain a few things. So I am trying to track down the history and the folklore on ClickState to see what I'm missing. Any help would be appreciated. Here is the diagnostics in text: 'From Squeak3.8alpha of ''17 July 2004'' [latest update: #5976] on 1 August 2004 at 12:18:18 pm'! "Change Set: ClickStateDiagnostics-wiz Date: 1 August 2004 Author: Jerome Peace (wiz) wiz 8/1/2004 12:17 ClickStateDiagnostic tools to explore what Clickstate is doing. This changeset limits itself to the looking routines. I've set up a subclass of MouseClickState to and a history iVar and a PastHistory cVar. The former stores all the events ClickState is called with; the latter the past ClickStates instances. MouseClickState did not have to be patched. HandMorph is patched to attach the hooks. Also HandMorph class now has accessors to EventStats. This is very useful for seeing just what actually passed thru clickstate. It does not show the actions of clickstate though they can mostly be arrived at by inference. I use the method name #preserve to have an instance save itself in its Past History. The method has been added to Object as a nop to avoid objections from nil and other non approriate classes. The subclass and preserve technique is a pattern that could be used to observe other instances. Third attempt. wiz 7/29/2004 10:29 Added a size limit to PastHistory. No sense causing out of space crashes. Second attempt at ClickTestTools. This is a first pass at tools to examine in MouseClickState. I made a nosy subclass of MouseClickState which copys the events as they are sent to a history collection. The states objects themselves are preserved in a classVar ordered collection with the idea of them being explored and reset e.g. (WizClickStage resetPastHistory explore) . HandMorph class was modified to give access to the eventStats that handleEvent stores. (HandMorph eventStatsReset explore). HandMorph was modified to use and preserve my clickstate subclass. "! MouseClickState subclass: #WizClickState instanceVariableNames: 'history' classVariableNames: 'PastHistory' poolDictionaries: '' category: 'Morphic-Kernel'! !WizClickState commentStamp: '<historical>' prior: 0! I am a nosy click state subclass. I collect a history of events passed to my super. "WizClickState resetPastHistory explore." Structure: history OrderedCollection or nil -- collects event sent to clickstate PastHistory OrderedCollection or nil -- collects clickstates as they are reset. Use me as a microscope to check what MouseClickState will do.! !Object methodsFor: '*ClickTest' stamp: 'wiz 7/29/2004 02:22'! preserve "Subclass WizClickState redifines. Just ignore here." ^ self! ! !HandMorph methodsFor: 'double click support' stamp: 'wiz 7/29/2004 01:15'! resetClickState "Reset the double-click detection state to normal (i.e., not waiting for a double-click). " mouseClickState preserve. mouseClickState := nil! ! !HandMorph methodsFor: 'double click support' stamp: 'wiz 7/29/2004 00:58'! waitForClicksOrDrag: aMorph event: evt selectors: clickAndDragSelectors threshold: threshold "Wait for mouse button and movement events, informing aMorph about events interesting to it via callbacks. This message is typically sent to the Hand by aMorph when it first receives a mouse-down event. The callback methods, named in clickAndDragSelectors and passed a copy of evt, are: 1 (click) sent when the mouse button goes up within doubleClickTime. 2 (doubleClick) sent when the mouse goes up, down, and up again all within DoubleClickTime. 3 (doubleClickTimeout) sent when the mouse does not have a doubleClick within DoubleClickTime. 4 (startDrag) sent when the mouse moves more than threshold pixels from evt's position within DoubleClickTime. Note that mouseMove: and mouseUp: events are not sent to aMorph until it becomes the mouse focus, which is typically done by aMorph in its click:, doubleClick:, or drag: methods. " mouseClickState := WizClickState new client: aMorph click: clickAndDragSelectors first dblClick: clickAndDragSelectors second dblClickTime: DoubleClickTime dblClickTimeout: clickAndDragSelectors third drag: clickAndDragSelectors fourth threshold: threshold event: evt! ! !HandMorph class methodsFor: 'accessing' stamp: 'wiz 7/28/2004 00:08'! eventStats ^ EventStats! ! !HandMorph class methodsFor: 'accessing' stamp: 'wiz 8/1/2004 11:54'! eventStatsReset | oldStats | "HandMorph eventStatsReset explore" oldStats _ EventStats. EventStats _ nil . ^oldStats! ! !WizClickState methodsFor: 'access' stamp: 'wiz 7/29/2004 00:43'! history ^ history ! ! !WizClickState methodsFor: 'access' stamp: 'wiz 7/29/2004 01:09'! pastHistory ^ PastHistory! ! !WizClickState methodsFor: 'access' stamp: 'wiz 7/29/2004 10:05'! preserve (PastHistory ifNil: [PastHistory := OrderedCollection new]) size < 100 ifTrue: [PastHistory add: self] .! ! !WizClickState methodsFor: 'access' stamp: 'wiz 7/29/2004 02:41'! resetPastHistory self class resetPastHistory! ! !WizClickState methodsFor: 'event handling' stamp: 'wiz 7/29/2004 00:46'! handleEvent: evt from: aHand (history ifNil: [history := OrderedCollection new]) add: evt. ^ super handleEvent: evt from: aHand ! ! !WizClickState class methodsFor: 'accessing' stamp: 'wiz 7/29/2004 02:39'! pastHistory ^ PastHistory! ! !WizClickState class methodsFor: 'accessing' stamp: 'wiz 7/29/2004 02:44'! resetPastHistory "WizClickState resetPastHistory explore." | oldPastHistory | oldPastHistory := PastHistory. PastHistory := nil. ^ oldPastHistory! ! Attached is the changeset with the diagnostic routines for examining ClickStates and the events that flow thru them. Yours in service, --Jerome Peace __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

1 0

[BUG]
by tomkoenig＠mindspring.com 02 Aug '04

02 Aug '04

The error report: 1 August 2004 11:17:41 pm VM: Win32 - a SmalltalkImage Image: Squeak3.8alpha [latest update: #5976] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\Documents and Settings\Thomas Koenig\Desktop\Squeak Trusted Dir C:\Documents and Settings\Thomas Koenig\Desktop\Squeak\Thomas Koenig Untrusted Dir C:\My Squeak\Thomas Koenig Rectangle>>rightCenter Receiver: 100@100 corner: 200@200 Arguments and temporary variables: Receiver's instance variables: origin: 100@100 corner: 200@200 DecentReviewerNPBugReportTest>>setUp Receiver: DecentReviewerNPBugReportTest>>#testSend Arguments and temporary variables: Receiver's instance variables: testSelector: #testSend aDecentReviewerNotePad: a DecentReviewerNotePad aCrashDmp: AttachmentResource aMethodContext: Rectangle>>rightCenter [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} Arguments and temporary variables: BlockContext>>ensure: Receiver: [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} Arguments and temporary variables: aBlock: [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self tearDown]...etc... returnValue: nil b: nil Receiver's instance variables: sender: BlockContext>>ensure: pc: 28 stackp: 0 nargs: 0 startpc: 26 home: DecentReviewerNPBugReportTest(TestCase)>>runCase --- The full stack --- Rectangle>>rightCenter DecentReviewerNPBugReportTest>>setUp [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} BlockContext>>ensure: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BlockContext>>sunitEnsure: DecentReviewerNPBugReportTest(TestCase)>>runCase [] in TestResult>>runCase: {[aTestCase runCase. true]} BlockContext>>on:do: BlockContext>>sunitOn:do: [] in TestResult>>runCase: {[[aTestCase runCase. true] sunitOn: self class failure do: [:signal | ...]} BlockContext>>on:do: BlockContext>>sunitOn:do: TestResult>>runCase: DecentReviewerNPBugReportTest(TestCase)>>run: [] in TestSuite>>run: {[:each | self sunitChanged: each. each run: aResult]} OrderedCollection>>do: TestSuite>>run: [] in TestSuite>>run {[self run: result]} BlockContext>>ensure: BlockContext>>sunitEnsure: TestSuite>>run [] in TestRunner>>runSuite: {[result := suite run]} BlockContext>>ensure: [] in TestRunner>>runSuite: {[[result := suite run] ensure: [running := nil. suite removeDependent: ...]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]}

1 0

[OT] Anyone ever going to stop this?
by Michael Rueger 01 Aug '04

01 Aug '04

Hi all, I always thought certain patents are bulls..., but this comes pretty close to patenting the "expansion and contraction of biological tissue as a means to acquire bio-chemical energy supply and exhaust exchange" And it sounds a lot like what Exobox did quite a few years ago. If only John Edwards was right: Hope is on the way (OK, for those not "blessed" with US TV coverage, it's from his (vice president hopeful) democratic convention speech) Michael ------- http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p… Organizing and displaying photographs based on time Abstract A technique is provided for organizing and displaying digital photographs based on time. The technique includes inputting data representing a photograph and storing the data as a photograph image file. The technique then identifies the manner in which the photograph image file stores time information (such as date and time of day). For instance, the technique determines whether the time information is digitally encoded in the image file, or whether it is embedded within the image data itself. The technique next includes extracting the time information from the photograph image file using a technique appropriate to the identified manner in which the time information is stored, to produce extracted time information. The photographs are then inserted into a time sequence based on the extracted time information, and presented on a calendar display at a location representative of the chronological placement of the photograph within the time sequence.

5 5

[BUG] Package Browser does not display extensions
by Stéphane Rollandin 01 Aug '04

01 Aug '04

in OmniBrowser 1.0a3, I can not see the extensions in the Package Browser. only selecting the '-- all --' category does display methods, but it actually display all methods, not the extension ones as one would expect. it seems that this is unrelated to the bug I describe in another mail Stef

3 4

Protocols
by Marcin Tustin 01 Aug '04

01 Aug '04

I've seen the term "protocol" bandied about in documentation, and I understand it to refer to the entire set of methods exported by a class. Is there a corresponding language-feature that aggregates sets of methods (or just their interfaces) such that they can be added to a class, like a mixin

3 2

[ENH] 'where' in LanguageEditor
by Yoshiki Ohshima 01 Aug '04

01 Aug '04

The 'where' function in LanguageEditor can be smarter. -- Yoshiki

2 2

REMINDER: Harvesting Party Monday August 2nd 01:00 GMT
by Ken Causey 01 Aug '04

01 Aug '04

Just a reminder that the next Harvesting Party will take place between 01:00 (1 AM) and 05:00 (5 AM) GMT Monday August 2nd, 2004. As usual we will meet in #squeak on irc.freenode.net. More information about the #squeak IRC channel can be found at http://people.squeakfoundation.org/article/7.html Information about the Harvesting Party idea can be found at http://people.squeakfoundation.org/article/29.html If you have the time please attend and work toward the future of Squeak. The next seven parties are scheduled for 05:00 (05:00 AM) GMT Friday August 06, 2004 09:00 (09:00 AM) GMT Tuesday August 10, 2004 13:00 (01:00 PM) GMT Saturday August 14, 2004 17:00 (05:00 PM) GMT Wednesday August 18, 2004 21:00 (09:00 PM) GMT Sunday August 22, 2004 01:00 (01:00 AM) GMT Friday August 27, 2004 05:00 (05:00 AM) GMT Tuesday August 31, 2004

3 2

[FIX] TTCFontFallbackPatch
by Yoshiki Ohshima 01 Aug '04

01 Aug '04

A preliminary version of fall back mechanism for TT. -- Yoshiki

1 0

Jump to page: