December 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Spock: callbacks and threads

by Schwab,Wilhelm K

Sig, Will Spock have restrictions on which thread invokes a callback? Suppose a library wants to spawn its own thread and invoke a callback from it; would that be possible? As I (partially) understand Eliot's suggestion for making calls on OS threads, the vm would be able to associate each Process with an OS thread; external calls made by a Process would be made on the specified OS thread. That Process, and only that Process, would be blocked during each external call. The first "level" of threaded callbacks that I can envision would be to allow callbacks that come from this associated thread. Does that seem reasonable? It would be great if restrictions are not required, but something tells me they will be necessary. I am being vague in part because I'm over my head here, and because I don't know if the supplier of an evolving library wants to speak yet. The source will be open when they release. Bill

Dec. 6, 2011

[Pharo-project] [COTDC] 91 - WeakOrderedCollection

by DeNigris Sean

Awesome momentum! There are 20 comments waiting to be integrated + some already in from Squeak!!! Continuing in Collections... Today: WeakOrderedCollection Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest

Dec. 6, 2011

[Pharo-project] Proceed Broken!

by Sean P. DeNigris

This is a show stopper... http://code.google.com/p/pharo/issues/detail?id=5062 Pharo1.4a Latest update: #14239 - #14246 Clicking Proceed in the Debugger or PreDebugWindow freezes image. Execution is stuck in MorphicUIManager>>terminateUIProcess, which has a 12/2/2011 timestamp. -- View this message in context: http://forum.world.st/Proceed-Broken-tp4163311p4163311.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 6, 2011

Re: [Pharo-project] pharo on lion

by Sean P. DeNigris

Sean P. DeNigris wrote > > Lion fullscreen apps do not disable the dock/menu bar like Pharo does in > fullscreen. In Lion, fullscreen apps reveal the dock when the mouse cursor > is swiped toward the screen edge while already on the edge, and the menu > bar appears when the top screen edge is hovered over. > I see that it seems to be working correctly in the latest Cocoa VM on Jenkins. I was using the Carbon VM ( yes Esteban, I know, it's legacy ;-) ) -- View this message in context: http://forum.world.st/pharo-on-lion-tp3682819p4163213.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 6, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 90 - TextAlignment

by Sean P. DeNigris

Thanks Laurent! -- View this message in context: http://forum.world.st/Re-Pharo-users-COTDC-90-TextAlignment-tp4156868p41624… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 5, 2011

Re: [Pharo-project] [squeak-dev] could you test the attached?

by StÃ©phane Ducasse

Thanks eliot I added the code to the bug tracker entry. Stef On Dec 5, 2011, at 11:16 PM, Eliot Miranda wrote: > Hi Marcus, > > On Mon, Dec 5, 2011 at 5:58 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > With this change set, we get an error when doing the following: > > In the workspace do a "debug it" on this code: > > Transcript show: Class name > > Thanks very much for this simple test case :) OK, the attached is an improvement. Please as many people test it as possible. > > > then two times "step over" --> Subscript out of bounds error. Without > the change it works. > > On Wed, Nov 16, 2011 at 8:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > > > I've found a bug in ContextPart>>#runUntilErrorOrReturnFrom: that in a > > certain rare circumstance causes the method to peel back too much of the > > stack. This method is used in the debugger (e.g. completeStep: et al) but > > also in Process termination. So it is right at the heart of the system. > > I'm loath to simply commit it I'd really appreciate y'all testing with the > > fix and reporting any changes you see. It does not affect the trunk test > > suite (there is a test, WeakSetInspectorTest, which is unreliable, but apart > > form that no observed effects). So, brave souls, please try with the > > attached and see if you come to grief or not. > > -- > > thanks, > > Eliot > > > > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > > > > -- > best, > Eliot > > <ContextPart-runUntilErrorOrReturnFrom.st>

Dec. 5, 2011

Re: [Pharo-project] [squeak-dev] Re: could you test the attached?

by Eliot Miranda

Hi Marcus, On Mon, Dec 5, 2011 at 5:58 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > With this change set, we get an error when doing the following: > > In the workspace do a "debug it" on this code: > > Transcript show: Class name > Thanks very much for this simple test case :) OK, the attached is an improvement. Please as many people test it as possible. > then two times "step over" --> Subscript out of bounds error. Without > the change it works. > > On Wed, Nov 16, 2011 at 8:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi All, > > > > I've found a bug in ContextPart>>#runUntilErrorOrReturnFrom: that in > a > > certain rare circumstance causes the method to peel back too much of the > > stack. This method is used in the debugger (e.g. completeStep: et al) > but > > also in Process termination. So it is right at the heart of the system. > > I'm loath to simply commit it I'd really appreciate y'all testing with > the > > fix and reporting any changes you see. It does not affect the trunk test > > suite (there is a test, WeakSetInspectorTest, which is unreliable, but > apart > > form that no observed effects). So, brave souls, please try with the > > attached and see if you come to grief or not. > > -- > > thanks, > > Eliot > > > > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > -- best, Eliot

Dec. 5, 2011

[Pharo-project] [COTDC] 93 - AnnouncementSpy

by sean＠clipperadams.com

Collections is fully commented* Can you believe that!? * Actually, that's a (small) lie. There are a few uncommented classes, but they may be removed pending an open issue, so we'll move on. 92 classes done 14 categories done 795 classes remaining Continuing in Announcements... Today: AnnouncementSpy Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 5, 2011

[Pharo-project] Call for Participation Smalltalk Directions

by StÃ©phane Ducasse

Hi guys I encourage you to send article to Smalltalk Directions Stef 19thâ21st March 2012, Biloxi, Mississippi Smalltalk Directions is a refereed symposium that will be co-located with the Smalltalk Industry Conference (STIC) in March 2012. The Smalltalk Directions Symposium will run in parallel with STIC, offering a parallel track of presentations of refereed academic work that will be open to all attendees of STIC. We solicit research papers concerned with the future of the Smalltalk language, forward-looking applications of Smalltalk and Smalltalk-inspired languages, and the core technologies supporting such languages, including but not limited to: 1. Libraries & Frameworks 2. Language extensions and contractions 3. Implementation technologies, such as Virtual machines, compilers, instruction sets, garbage collection 4. Object persistence 5. Distributed objects 6. Program development tools and environments 7. Using Smalltalk to educate future object-oriented programmers 8. Design Patterns in and for Smalltalk 9. Modelling 10. Meta-programming 11. Domain-specific languages implemented in Smalltalk 12. Smalltalk on the web Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm; this site also contains links to useful information on how to write effective submissions. We are working to have accepted papers appear in the ACM Digital library. A special issue of the Journal of Object Technology will be published in conjunction with the symposium. The authors of selected papers will be invited to submit an extended version of their Smalltalk Directions submission to this special issue, which will then conduct its own reviewing precess. Papers must be submitted electronically using EasyChair (https://www.easychair.org/conferences/?conf=smalltalkdirections2) Important Dates Paper submission deadline 6th January 2012 Author notification 4th February 2012 Final version deadline 24th February 2012 Symposium 19thâ 21st March 2012 Organizing Committee Andrew P Black Portland State University, USA black(a)cs.pdx.edu Ralph Johnson University of Illinois, Urbana-Champaign, USA rjohnson(a)illinois.edu Roger Whitney San Diego State University whitney(a)cs.sdsu.edu David West New Mexico Highlands University dmwest(a)nmhu.edu

Dec. 5, 2011

Re: [Pharo-project] [squeak-dev] could you test the attached?

by StÃ©phane Ducasse

On Dec 5, 2011, at 2:58 PM, Marcus Denker wrote: > Hi, > > With this change set, we get an error when doing the following: > > In the workspace do a "debug it" on this code: > > Transcript show: Class name > > then two times "step over" --> Subscript out of bounds error. Without > the change it works. this shows that squeak related fix should be applied with care and that we should understand deeply our system. I'm trying but I'm not happy with my knowledge on certain parts. But since there is little documentation and some abstractions are not aligned, this makes everything more challenging. When I see the senders, I think that it will be delicate to fix Process>>terminate "Stop the process that the receiver represents forever. Unwind to execute pending ensure:/ifCurtailed: blocks before terminating." | ctxt unwindBlock oldList | self isActiveProcess ifTrue: [ ctxt := thisContext. [ ctxt := ctxt findNextUnwindContextUpTo: nil. ctxt isNil ] whileFalse: [ (ctxt tempAt: 2) ifNil: [ ctxt tempAt: 2 put: nil. unwindBlock := ctxt tempAt: 1. thisContext terminateTo: ctxt. unwindBlock value ]]. thisContext terminateTo: nil. self suspend ] ifFalse: [ "Always suspend the process first so it doesn't accidentally get woken up" oldList := self suspend. suspendedContext ifNotNil:[ "Figure out if we are terminating the process while waiting in Semaphore>>critical: In this case, pop the suspendedContext so that we leave the ensure: block inside Semaphore>>critical: without signaling the semaphore." (oldList class == Semaphore and:[ suspendedContext method == (Semaphore compiledMethodAt: #critical:)]) ifTrue:[ suspendedContext := suspendedContext home.]. "If we are terminating a process halfways through an unwind, try to complete that unwind block first." (suspendedContext findNextUnwindContextUpTo: nil) ifNotNil: [ :outer | (suspendedContext findContextSuchThat: [ :c | c closure == (outer tempAt: 1)]) ifNotNil: [ :inner | "This is an unwind block currently under evaluation" suspendedContext runUntilErrorOrReturnFrom: inner ]]. ctxt := self popTo: suspendedContext bottomContext. ctxt == suspendedContext bottomContext ifFalse: [ self debug: ctxt title: 'Unwind error during termination']] ]. Process>>complete: aContext "Run self until aContext is popped or an unhandled error is raised. Return self's new top context, unless an unhandled error was raised then return the signaler context (rather than open a debugger)." | ctxt pair error | ctxt := suspendedContext. suspendedContext := nil. "disable this process while running its stack in active process below" pair := ctxt runUntilErrorOrReturnFrom: aContext. suspendedContext := pair first. error := pair second. error ifNotNil: [^ error signalerContext]. ^ suspendedContext > > On Wed, Nov 16, 2011 at 8:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi All, >> >> I've found a bug in ContextPart>>#runUntilErrorOrReturnFrom: that in a >> certain rare circumstance causes the method to peel back too much of the >> stack. This method is used in the debugger (e.g. completeStep: et al) but >> also in Process termination. So it is right at the heart of the system. >> I'm loath to simply commit it I'd really appreciate y'all testing with the >> fix and reporting any changes you see. It does not affect the trunk test >> suite (there is a test, WeakSetInspectorTest, which is unreliable, but apart >> form that no observed effects). So, brave souls, please try with the >> attached and see if you come to grief or not. >> -- >> thanks, >> Eliot >> > > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de >

Dec. 5, 2011