- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New and richer halt messages

by Esteban Lorenzano

> On 2 Jun 2017, at 09:28, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-06-02 8:52 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: > For example I would like to have > > - haltOnlyInTest > - haltOnlyOutOfTest > - haltOnlyMe that when I use this one disables all the other halt in the system. > > Another question: do we really want new halt messages or it is better to extend breakpoints based on metalinks? I would go for metalinks. Esteban

June 2, 2017

Re: [Pharo-dev] New and richer halt messages

by Denis Kudriashov

2017-06-02 8:52 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > For example I would like to have > > - haltOnlyInTest > - haltOnlyOutOfTest > - haltOnlyMe that when I use this one disables all the other halt in the > system. > Another question: do we really want new halt messages or it is better to extend breakpoints based on metalinks?

June 2, 2017

Re: [Pharo-dev] New and richer halt messages

by Denis Kudriashov

Hi 2017-06-02 8:52 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > - haltOnlyInTest > - haltOnlyOutOfTest > With process specific variable CurrentExecutionEnvironment it should be very easy to implement. Halt will be delegated to DefaultExecutionEnvironment or TestExecutionEnvironment depending on current value.

June 2, 2017

Re: [Pharo-dev] DebugSession: no exception raised when stepping out of the execution?

by Stephane Ducasse

Thanks eliot. I really think that pushing the debugger to the next level is an exciting perspective and I'm super happy that thomas accepted my crazy topics. Stef On Fri, Jun 2, 2017 at 2:08 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Guille, > > On Wed, May 31, 2017 at 12:48 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> >> On Mon, May 29, 2017 at 6:07 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >>> Hi Thomas, >>> >>> >>> On May 29, 2017, at 7:41 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> >>> On Mon, May 29, 2017 at 9:34 PM, <tdupriez(a)ens-paris-saclay.fr> wrote: >>> >>> [...] >> >>> >>>> Here is my example code. Beware, running it will freeze the VM. >>>> >>>> | program process context debugSession | >>>> program := [1+2]. >>>> process := program newProcess. >>>> context := process suspendedContext. >>>> debugSession := process newDebugSessionNamed: 'StepIntoForever' >>>> startedAt: context. >>>> [ true ] whileTrue: [ debugSession stepInto ]. >>>> >>>> [...] >> >> >>> In particular, your use of stepInto: will soon step into the process >>> termination code. See newProcess. You have to stop simulating before you >>> stop the current process by mistake. >>> >>> >> Yes, I explained yesterday to Thomas that this would end up terminating >> the UIProcess where the debugger is running on, instead of terminating the >> process that is being debugged. But, it looks like a bug... >> >> It would make sense to me that "Processor activeContext" yields the >> debugged context in the simulated code instead of the real active context. >> And I believe that this change should not break any existing code. >> >> Actually, thinking a bit more about this, similar problems may happen if >> we try to execute in the debugger Semaphore code in the debugger. So >> probably, in general terms, the debugger should handle specially all code >> that messes up with the Process machinery. >> > > Alas is isn't possible to implement this directly in the execution > simulation machinery because of things like this: > > Context>>runUntilErrorOrReturnFrom: > Context>>jump > > Context>>jump uses the simulation machinery to advance execution, so the > execution simulation machinery has to simulate exactly. Context>>runUntilErrorOrReturnFrom: > uses Context>>jump and is used in the exception delivery process. > > I expect the process state changing primitives can apply to > effectiveProcess. So in Context>>doPrimitive:method:receiver:args:see > > "Mutex>>primitiveEnterCriticalSection > Mutex>>primitiveTestAndSetOwnershipOfCriticalSection" > (primitiveIndex = 186 or: [primitiveIndex = 187]) ifTrue: > [| effective | > effective := Processor activeProcess effectiveProcess. > "active == effective" > value := primitiveIndex = 186 > ifTrue: [receiver primitiveEnterCriticalSectionOnBehalfOf: effective] > ifFalse: [receiver primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf: > effective]. > ^(self isPrimFailToken: value) > ifTrue: [value] > ifFalse: [self push: value]]. > > > We would have to have similar code for suspend and resume primitives. I > don't see how this mechanism solves the issues with wait and signal > though. They need to be handleable as per primitiveEnterCriticalSectionOnBehalfOf: > etc. We would have to modify the VM and add signalOnBehalfOf: and > waitOnBehalfOf:. There might be a bug tail here because I fear that the > system depends on these being 0 argument primitives to avoid stack growth > on signal/wait. > > -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > > > -- > _,,,^..^,,,_ > best, Eliot >

June 2, 2017

Re: [Pharo-dev] New and richer halt messages

by Peter Uhnak

Also why was haltIfShiftPressed removed? (in favor of haltIf: [ Sensor shiftPressed ], which is harder to write, remember, and without autocompletion). Peter On Fri, Jun 02, 2017 at 08:52:39AM +0200, Stephane Ducasse wrote: > I would love to have better halt messages. > > For example I would like to have > > - haltOnlyInTest > - haltOnlyOutOfTest > - haltOnlyMe that when I use this one disables all the other halt in the > system. > > Marcus it would be nice to brainstorm on these to improve our halt > vocabulary. > Stef

June 2, 2017

New and richer halt messages

by Stephane Ducasse

I would love to have better halt messages. For example I would like to have - haltOnlyInTest - haltOnlyOutOfTest - haltOnlyMe that when I use this one disables all the other halt in the system. Marcus it would be nice to brainstorm on these to improve our halt vocabulary. Stef

June 2, 2017

Re: [Pharo-dev] please test download for Pharo 6.0

by Marcus Denker

>>> >> >> I am looking into signingâ¦ but as we did not have it for Pharo5, it should not hold up the release. >> >> The /Applications thing is related to signing, too. (the container, we should ship it with a signed .dmg). > > If possible please include the code in opensmalltalk/vm. There are good starting points: > > In {build.macos32x86,build.macos64x64}/newspeak.cog.spur/installer is code that builds the newspeak .dmg, but does not sign it. There's a Makefile. > > In {build.macos32x86,build.macos64x64}/common/Makefile.app is code to sign an .app bundle using codesign. The certificate to use is indicated via an environment variable as described in {build.macos32x86,build.macos64x64}/HowToBuild. > Ok, I will checkâ¦ first I will do it as part of a additional build queue step, then see how to move it upstream to the VM build. Marcus

June 2, 2017

Re: [Pharo-dev] Minor glitch in source code diff tool

by Stephane Ducasse

Hi sven Yes please. Stef On Thu, Jun 1, 2017 at 12:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It seems there is a minor glitch in the source code diff tool: > > > The first difference is marked (coloured) OK, each next one is one > character position more off. > > This is in the latest 6.0 RC image. > > Should I create an issue ? > > Sven > >

June 2, 2017

Re: [Pharo-dev] DebugSession: no exception raised when stepping out of the execution?

by Eliot Miranda

Hi Guille, On Wed, May 31, 2017 at 12:48 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > > > On Mon, May 29, 2017 at 6:07 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Thomas, >> >> >> On May 29, 2017, at 7:41 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Mon, May 29, 2017 at 9:34 PM, <tdupriez(a)ens-paris-saclay.fr> wrote: >> >> [...] > >> >>> Here is my example code. Beware, running it will freeze the VM. >>> >>> | program process context debugSession | >>> program := [1+2]. >>> process := program newProcess. >>> context := process suspendedContext. >>> debugSession := process newDebugSessionNamed: 'StepIntoForever' >>> startedAt: context. >>> [ true ] whileTrue: [ debugSession stepInto ]. >>> >>> [...] > > >> In particular, your use of stepInto: will soon step into the process >> termination code. See newProcess. You have to stop simulating before you >> stop the current process by mistake. >> >> > Yes, I explained yesterday to Thomas that this would end up terminating > the UIProcess where the debugger is running on, instead of terminating the > process that is being debugged. But, it looks like a bug... > > It would make sense to me that "Processor activeContext" yields the > debugged context in the simulated code instead of the real active context. > And I believe that this change should not break any existing code. > > Actually, thinking a bit more about this, similar problems may happen if > we try to execute in the debugger Semaphore code in the debugger. So > probably, in general terms, the debugger should handle specially all code > that messes up with the Process machinery. > Alas is isn't possible to implement this directly in the execution simulation machinery because of things like this: Context>>runUntilErrorOrReturnFrom: Context>>jump Context>>jump uses the simulation machinery to advance execution, so the execution simulation machinery has to simulate exactly. Context>>runUntilErrorOrReturnFrom: uses Context>>jump and is used in the exception delivery process. I expect the process state changing primitives can apply to effectiveProcess. So in Context>>doPrimitive:method:receiver:args:see "Mutex>>primitiveEnterCriticalSection Mutex>>primitiveTestAndSetOwnershipOfCriticalSection" (primitiveIndex = 186 or: [primitiveIndex = 187]) ifTrue: [| effective | effective := Processor activeProcess effectiveProcess. "active == effective" value := primitiveIndex = 186 ifTrue: [receiver primitiveEnterCriticalSectionOnBehalfOf: effective] ifFalse: [receiver primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf: effective]. ^(self isPrimFailToken: value) ifTrue: [value] ifFalse: [self push: value]]. We would have to have similar code for suspend and resume primitives. I don't see how this mechanism solves the issues with wait and signal though. They need to be handleable as per primitiveEnterCriticalSectionOnBehalfOf: etc. We would have to modify the VM and add signalOnBehalfOf: and waitOnBehalfOf:. There might be a bug tail here because I fear that the system depends on these being 0 argument primitives to avoid stack growth on signal/wait. -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- _,,,^..^,,,_ best, Eliot

June 2, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Tudor Girba

Hi, > On Jun 1, 2017, at 7:23 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > What is in bintray now is the same as vm latest :) Do I understand correctly that: curl get.pharo.org/vmLatest60 | bash will get the VM with the fix? Doru > On 1 Jun 2017, at 18:30, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Tobias has commited a fix in cog branch a few days ago. >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f07ffbedcc184391e… >> So could you try latest Vm from bintray and report? >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f07ffbedcc184391e… >> >> >> 2017-06-01 16:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> Hi, >> >> I am not sure what is the status with this issue, but it seems clear that there exists a problem, so I opened an issue to accumulate the different opinions: >> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 >> >> Cheers, >> Doru >> >> >> >> > On May 29, 2017, at 9:53 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > ---------- Forwarded message ---------- >> > From: Tobias Pape <Das.Linux(a)gmx.de> >> > Date: Mon, May 29, 2017 at 12:09 AM >> > Subject: Re: [Vm-dev] multiple crashes on macOS Sierra >> > To: John McIntosh <johnmci(a)smalltalkconsulting.com> >> > Cc: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> >> > >> > >> > >> > Hi John, all >> > >> > >> > > On 28.05.2017, at 22:12, John McIntosh <johnmci(a)smalltalkconsulting.com> wrote: >> > > >> > > At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) Tobias added >> > > >> > > >> > > NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) >> > > location:[theEvent locationInWindow] >> > > modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) >> > > timestamp:[theEvent timestamp] >> > > windowNumber:[theEvent windowNumber] >> > > context:nil >> > > characters:@"" >> > > charactersIgnoringModifiers:@"" >> > > isARepeat:NO >> > > keyCode:[theEvent keyCode]]); >> > > >> > > in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent >> > >> > That's correct. >> > >> > > >> > > However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/… >> > > >> > > + (NSEvent *)keyEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag keyCode:(unsigned short)code; >> > >> > Well, I have not found a reference to how this relates to autorelease (the Apple docs are becoming increasingly useless these days :() >> > I read this https://developer.apple.com/reference/appkit/nsevent/1533943-keyeventwithty… >> > and the header /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h and although autorelase pops up somewhere in the file, it does not somewhere near the declaration. >> > I read through the code an found quite a few AUTORELEASEOBJ() around object creation and (apparently wrongly) thought I would need that here. >> > >> > >> > I now understand that I should only autorelease alloc/inited stuff. >> > >> > So you may be right here. >> > >> > Fixed in 0f07ffbed >> > >> > Best regards >> > -Tobias >> > >> > > >> > > If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. >> > >> > [snip] >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> >> >> -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

June 1, 2017