September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] I'm confused about Process>>isTerminated

by Eliot Miranda

Hi Max, On Tue, Sep 16, 2014 at 11:05 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi > > As always when I want to check if a process has died I get very confused > by #isTerminated and Iâm wondering if I just donât get how itâs supposed to > work or if there are others that share my confusion. > > Old implementation: > > isTerminated > > self isActiveProcess ifTrue: [^ false]. > ^suspendedContext isNil > or: ["If the suspendedContext is the bottomContext it is the > block in Process>>newProcess. > If so, and the pc is greater than the startpc, the bock > has alrteady sent and returned > from value and there is nothing more to do." > suspendedContext isBottomContext > and: [ suspendedContext pc > suspendedContext startpc ] ] > > > Pharo 4 implementation: > > isTerminated > self isActiveProcess ifTrue: [^ false]. > ^suspendedContext isNil > or: ["If the suspendedContext is the bottomContext it is the > block in Process>>newProcess. > If so, and the pc is greater than the startpc, the bock > has alrteady sent and returned > from value and there is nothing more to do.â > suspendedContext isBottomContext > and: [ suspendedContext isDead not > â<âââââââââââââââââââââââââ new" > and: [ suspendedContext pc > suspendedContext startpc ] ] ] > > > The old implementation would break if the suspended context was dead (i.e. > the pc was nil) because the send of #> would produce an MNU. > The new implementation doesnât fix that, even though it looks like it at > first glance: if the pc is nil, the #> send will still happen -> MNU. > Off the top of my head it would seem that it should be isDead or: [] not isDead not and: isTerminated self isActiveProcess ifTrue: [^ false]. ^suspendedContext isNil or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. If so, and the pc is greater than the startpc, the bock has alrteady sent and returned from value and there is nothing more to do.â suspendedContext isBottomContext and: [ suspendedContext isDead or: [ suspendedContext pc > suspendedContext startpc ] ] ] > isDead > ^ pc isNil > and maybe (suspendedContext pc ifNil: [true] ifNotNil: [:pc| pc > suspendedContext startpc]) is more obvious. Anyway, neither implementation will reliably tell me if the process has > been terminated: > - an inactive process will be suspended when #terminate is sent and report > that it has not been terminated (#isSuspended -> true, #isTerminated -> > false) > except that it *hasn't* been terminated, it is merely in the process of termination. It isn't terminated until all unwind blocks have run, right? > - a properly terminated process will raise an MNU (although apparently not > alwaysâ¦?) > but that's a bug the change I suggested will fix. > - all the states in between: no clue > > I would like to know two things: > 1. how can I check if a process has already *received* a #terminate? (I > would then assume that the process will die eventually) > I don't think you can without putting a critical section around terminate and adding some process-specific variable that is set when you send terminate. termination is not instantaneous (unwind blocks have to be run), so it is potentially interruptible. > 2. how can I check if a process is *actually* dead? (in case a âhalf deadâ > process will still unwind or whatever) > see above. > > What would be necessary to make those tests (or better ones) possible > (rewrite the whole process implementation?)? > > > Cheers, > Max > -- best, Eliot

Sept. 16, 2014

I'm confused about Process>>isTerminated

by Max Leske

Hi As always when I want to check if a process has died I get very confused by #isTerminated and Iâm wondering if I just donât get how itâs supposed to work or if there are others that share my confusion. Old implementation: isTerminated self isActiveProcess ifTrue: [^ false]. ^suspendedContext isNil or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. If so, and the pc is greater than the startpc, the bock has alrteady sent and returned from value and there is nothing more to do." suspendedContext isBottomContext and: [ suspendedContext pc > suspendedContext startpc ] ] Pharo 4 implementation: isTerminated self isActiveProcess ifTrue: [^ false]. ^suspendedContext isNil or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess. If so, and the pc is greater than the startpc, the bock has alrteady sent and returned from value and there is nothing more to do.â suspendedContext isBottomContext and: [ suspendedContext isDead not â<âââââââââââââââââââââââââ new" and: [ suspendedContext pc > suspendedContext startpc ] ] ] The old implementation would break if the suspended context was dead (i.e. the pc was nil) because the send of #> would produce an MNU. The new implementation doesnât fix that, even though it looks like it at first glance: if the pc is nil, the #> send will still happen -> MNU. isDead ^ pc isNil Anyway, neither implementation will reliably tell me if the process has been terminated: - an inactive process will be suspended when #terminate is sent and report that it has not been terminated (#isSuspended -> true, #isTerminated -> false) - a properly terminated process will raise an MNU (although apparently not alwaysâ¦?) - all the states in between: no clue I would like to know two things: 1. how can I check if a process has already *received* a #terminate? (I would then assume that the process will die eventually) 2. how can I check if a process is *actually* dead? (in case a âhalf deadâ process will still unwind or whatever) What would be necessary to make those tests (or better ones) possible (rewrite the whole process implementation?)? Cheers, Max

Sept. 16, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Sebastian Sastre

On Sep 15, 2014, at 3:54 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > The native windows contain morphs, but anything, including MVC, can be present. This provides native Win32 Windows (doing other platforms is merely work) /and/ the ability to snapshot and bring back up windows on a different platform (e.g. open in win32, snapshot and bring up in Squeak/Pharo Morphic windows, or vice verse), and the ability to do this dynamically. Is anyone motivated to port the Newspeak code back to Squeak/Pharo? Well, a while ago in the business list Iâve raised the idea that making Pharo able to do native OS windows would help it to gain market space (as in the opposite of staying at the margins of it). So, Iâd be very positively curious about being able to use Pharo to do multiplatform native apps sebastian o/

Sept. 16, 2014

Re: [Pharo-dev] DateModel not working in 3.0

by Sean P. DeNigris

Sean P. DeNigris wrote > Will someone please review... Ready to integrate in 3.0 - merges and passes manual test ----- Cheers, Sean -- View this message in context: http://forum.world.st/DateModel-not-working-in-3-0-tp4778355p4778420.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014

extracting data from PDFs - do we have anything that does that kinda thing?

by Paul DeBruicker

Hi - I'm specifically interested in something like pdf2table (http://ieg.ifs.tuwien.ac.at/projects/pdf2table/) Thanks in advance Paul

Sept. 16, 2014

Re: [Pharo-dev] XMLDomParser Changes in Pharo 3.0?

by Sean P. DeNigris

Sean P. DeNigris wrote > the library still seems to download all the DTDs that it's never going to > use, which takes quite a long time for nothing. > > What are my options? Apparently, the magic message is "parser resolvesExternalEntities: false". ----- Cheers, Sean -- View this message in context: http://forum.world.st/XMLDomParser-Changes-in-Pharo-3-0-tp4778401p4778413.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014

Re: [Pharo-dev] Has someone ever built a "sort block generator"

by Esteban A. Maringolo

Nicolas: 2014-08-01 17:50 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> http://objology.blogspot.no/2010/11/tag-sortfunctions-redux.html >> >> Donât think anyoneâs ported it to Pharo yet though. > +1 > > Note that I have a public experimental port to Pharo in SmalltalkHub that I > already announced once (in > http://smalltalkhub.com/#!/~nice/NiceVMExperiments but I can't tell exactly > the package name TagSortFunction or something like that, the web interface > of SmalltalkHub is currently showing me a debugger with nil does not > understand #data). > Yes, I know VM-experiments is not the right place for such package, but at > the time I didn't find where to create a new project... I decided to embrace you initial port and also made some enhancements to TAGSortFunctions. I added the current features: * Support of MAElementDescription conversion to SortFunction (in addition to block and unary symbol support) * Collation of nil elements, deciding whether to put nil at the end or beginning of the result. (similar to the ORDER BY column [NULLS FIRST|LAST] semantics of SQL). Unit tests for the above described features. All the added features preserve the original behavior of the sort functions, so nil collation must be "enabled" explicitly by sending #undefinedFirst/#undefinedLast to the sort function, otherwise it will fail if you attempt to compare an object with nil. I would like to move this to a specific repository in STHub with its own Metacello config (Magritte support is packaged separately). Do you agree with this? Regards! Esteban A. Maringolo

Sept. 16, 2014

Re: [Pharo-dev] TestCoverage magic?

by Yuriy Tymchuk

Hi Alex, thanks. > On 16 Sep 2014, at 17:57, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi Yuriy, > > We put quite some work on Hapao, a test code coverage for Pharo. > I am preparing an announcement... > > Cheers, > Alexandre > > On Sep 15, 2014, at 11:53 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Hi everyone, >> >> Iâm trying to understand how current coverage works and executing "TestCoverage new" returns nilâ¦ and "TestCoverage class>>#on:â sends #initializeOn: to that nil. >> >> Iâll be very thankful for explanation. >> Uko > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Sept. 16, 2014

Re: [Pharo-dev] XMLDomParser Changes in Pharo 3.0?

by Sean P. DeNigris

Sean P. DeNigris wrote > processing DTDs Additionally, #entityURIFromRelative:andBase: interprets relative URLs like 'xhtml-lat1.ent' as file paths, leading to results like "XMLFileIOException: File @ ~/Squeak/http:/www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent (line 28) (line 3)" ----- Cheers, Sean -- View this message in context: http://forum.world.st/XMLDomParser-Changes-in-Pharo-3-0-tp4778401p4778405.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014

XMLDomParser Changes in Pharo 3.0?

by Sean P. DeNigris

XMLDOMParser parse: (FileLocator imageDirectory / 'hocr_sample.html') contents. In Pharo #20623, the above works fine, but in #30856 it spins "forever" processing DTDs. Investigation further, "parser isValidating: false" is supposed to disable DTD validation, but the library still seems to download all the DTDs that it's never going to use, which takes quite a long time for nothing. What are my options? Is there an XML version prior to DTD implementation that works in 3.0? ----- Cheers, Sean -- View this message in context: http://forum.world.st/XMLDomParser-Changes-in-Pharo-3-0-tp4778401.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 16, 2014