- Pharo-dev - lists.pharo.org

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

by Ben Coman

On Fri, Jun 2, 2017 at 8: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. > This is what I touching on here.. http://forum.world.st/Accessing-effectiveProcess-from-a-primitive-td4919094… cheers -ben

June 2, 2017

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

by Nicolas Cellier

Hi Henrik, good catch! platforms/Cross/plugins/FilePlugin/FilePlugin.h says: sqInt dir_EntryLookup(char *pathString, sqInt pathStringLength, char *nameString, sqInt nameStringLength, /* outputs: */ char *name, sqInt *nameLength, sqInt *creationDate, sqInt *modificationDate, sqInt *isDirectory, squeakFileOffsetType *sizeIfFile, sqInt *posixPermissions, sqInt *isSymlink); platforms/win32/vm/sqWin32Directory.c says int dir_EntryLookup(char *pathString, int pathLength, char* nameString, int nameStringLength, /* outputs: */ char *name, int *nameLength, int *creationDate, int *modificationDate, int *isDirectory, squeakFileOffsetType *sizeIfFile, sqInt *posixPermissions, sqInt *isSymlink) int* and sqInt* are not going to be a good match on 64 bits... But I don't know how the WIN64 Squeak VM could possibly work, because prototypes are equally wrong (just with two parameters less). And the two paramters added by Pharo are correct!!! Maybe there is another bug, I will modify the easy part and commit ASAP. In the long term, we shall include the .h containing declarations into the .c implementing the functions and use more agressive -C99 flags forcing the prototypes to be defined. 2017-06-02 14:48 GMT+02:00 Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no>: > The Windows 64 Pharo VM crashes when loading images*. > The Windows 64 Squeak VM runs Pharo images just fine, but lacks some > plugins > (FT2 from Pharo build works, and can be copied over, SqueakSSL is MiA). > Great work! > > Cheers, > Henry > > *Crash occurs when loading sources; > Stack backtrace: > [0000000000495063] dir_EntryLookup + 0x83 in Pharo.exe > > Smalltalk stack dump: > 0xb4f568 I WindowsStore(DiskStore)>basicEntryAt: 0x9a711c0: a(n) > WindowsStore > 0xb4f5b8 I WindowsStore(DiskStore)>nodeAt:ifPresent:ifAbsent: > 0x9a711c0: a(n) WindowsStore > 0xb4f610 I WindowsStore(FileSystemStore)>exists: 0x9a711c0: a(n) > WindowsStore > 0xb4f658 I FileSystem>exists: 0x9a711d8: a(n) FileSystem > 0xb4f6a0 I FileReference>exists 0x9a77400: a(n) FileReference > 0xb4f6e0 I FileLocator(AbstractFileReference)>exists 0x9a76678: > a(n) FileLocator > 0xb4f730 M [] in PharoFilesOpener>openSources:forImage: > 0xaca7168: > a(n) PharoFilesOpener > > so I assume it's related to additional functionality in > <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> in the Pharo > build. > > > > > -- > View this message in context: http://forum.world.st/please- > test-download-for-Pharo-6-0-tp4948720p4948965.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

June 2, 2017

Re: [Pharo-dev] State of Pharo 6 64-bit ?

by Sven Van Caekenberghe

> On 2 Jun 2017, at 15:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The first thing we need is an automatic test run for 64 bitâ¦ > > https://ci.inria.fr/pharo/ > > has just 32bit (win, linux, mac). It needs to have 64bit, too. Yes, of course we need that. But I am pretty sure that it won't even complete a whole test run without crashing. > But I think we should not wait with the release for that. If that is true, 64-bit is not a real release, but a preview/beta. Is that what we want ? It feels as if we are that too far off, but maybe Esteban is in a better position to comment. >> On 2 Jun 2017, at 14:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> I am wondering a bit about the state of Pharo 6 64-bit. >> >> On one hand the current RC seems to work really well on macOS (for me), it is stable and clean. >> >> Is the goal to ship this variant as a real finished version ? >> >> If so, I think must make it pass as much unit tests as possible. >> >> >> I filed a couple of issues related to that: >> >> https://pharo.fogbugz.com/f/cases/20102/SmallInteger-digitAt-not-ready-for-… >> >> https://pharo.fogbugz.com/f/cases/20108/CompiledMethod-isAbstract-fails-on-… >> >> https://pharo.fogbugz.com/f/cases/20111/Some-Collection-tests-fail-on-64-bi… >> >> https://pharo.fogbugz.com/f/cases/20110/AllocationTest-testOutOfMemorySigna… >> >> The first one has a fix. Fixes must be done carefully, since the same image must be able to run on both 32 and 64 bit. >> >> >> I also noticed that a couple of Compiler tests are failing. Now, obviously the compiler works good enough since it can load code, so this is probably also something minor/weird/unexpected. About 51 tests fail (in MethodMapTests, OCBytecodeHGeneratorTest and OCNewCompilerWithChangesFunctionalTests). Should I create an issue ? >> >> Sven >> >> >

June 2, 2017

Re: [Pharo-dev] State of Pharo 6 64-bit ?

by Marcus Denker

The first thing we need is an automatic test run for 64 bitâ¦ https://ci.inria.fr/pharo/ <https://ci.inria.fr/pharo/> has just 32bit (win, linux, mac). It needs to have 64bit, too. But I think we should not wait with the release for that. > On 2 Jun 2017, at 14:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > I am wondering a bit about the state of Pharo 6 64-bit. > > On one hand the current RC seems to work really well on macOS (for me), it is stable and clean. > > Is the goal to ship this variant as a real finished version ? > > If so, I think must make it pass as much unit tests as possible. > > > I filed a couple of issues related to that: > > https://pharo.fogbugz.com/f/cases/20102/SmallInteger-digitAt-not-ready-for-… > > https://pharo.fogbugz.com/f/cases/20108/CompiledMethod-isAbstract-fails-on-… > > https://pharo.fogbugz.com/f/cases/20111/Some-Collection-tests-fail-on-64-bi… > > https://pharo.fogbugz.com/f/cases/20110/AllocationTest-testOutOfMemorySigna… > > The first one has a fix. Fixes must be done carefully, since the same image must be able to run on both 32 and 64 bit. > > > I also noticed that a couple of Compiler tests are failing. Now, obviously the compiler works good enough since it can load code, so this is probably also something minor/weird/unexpected. About 51 tests fail (in MethodMapTests, OCBytecodeHGeneratorTest and OCNewCompilerWithChangesFunctionalTests). Should I create an issue ? > > Sven > >

June 2, 2017

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

by Henrik Sperre Johansen

The Windows 64 Pharo VM crashes when loading images*. The Windows 64 Squeak VM runs Pharo images just fine, but lacks some plugins (FT2 from Pharo build works, and can be copied over, SqueakSSL is MiA). Great work! Cheers, Henry *Crash occurs when loading sources; Stack backtrace: [0000000000495063] dir_EntryLookup + 0x83 in Pharo.exe Smalltalk stack dump: 0xb4f568 I WindowsStore(DiskStore)>basicEntryAt: 0x9a711c0: a(n) WindowsStore 0xb4f5b8 I WindowsStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x9a711c0: a(n) WindowsStore 0xb4f610 I WindowsStore(FileSystemStore)>exists: 0x9a711c0: a(n) WindowsStore 0xb4f658 I FileSystem>exists: 0x9a711d8: a(n) FileSystem 0xb4f6a0 I FileReference>exists 0x9a77400: a(n) FileReference 0xb4f6e0 I FileLocator(AbstractFileReference)>exists 0x9a76678: a(n) FileLocator 0xb4f730 M [] in PharoFilesOpener>openSources:forImage: 0xaca7168: a(n) PharoFilesOpener so I assume it's related to additional functionality in <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> in the Pharo build. -- View this message in context: http://forum.world.st/please-test-download-for-Pharo-6-0-tp4948720p4948965.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 2, 2017

State of Pharo 6 64-bit ?

by Sven Van Caekenberghe

Hi, I am wondering a bit about the state of Pharo 6 64-bit. On one hand the current RC seems to work really well on macOS (for me), it is stable and clean. Is the goal to ship this variant as a real finished version ? If so, I think must make it pass as much unit tests as possible. I filed a couple of issues related to that: https://pharo.fogbugz.com/f/cases/20102/SmallInteger-digitAt-not-ready-for-… https://pharo.fogbugz.com/f/cases/20108/CompiledMethod-isAbstract-fails-on-… https://pharo.fogbugz.com/f/cases/20111/Some-Collection-tests-fail-on-64-bi… https://pharo.fogbugz.com/f/cases/20110/AllocationTest-testOutOfMemorySigna… The first one has a fix. Fixes must be done carefully, since the same image must be able to run on both 32 and 64 bit. I also noticed that a couple of Compiler tests are failing. Now, obviously the compiler works good enough since it can load code, so this is probably also something minor/weird/unexpected. About 51 tests fail (in MethodMapTests, OCBytecodeHGeneratorTest and OCNewCompilerWithChangesFunctionalTests). Should I create an issue ? Sven

June 2, 2017

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

by Sven Van Caekenberghe

> On 31 May 2017, at 17:46, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > The linux distro contains sources twice > 1) pharo6.0/shared/PharoV60.sources > 2) pharo6.0/bin/PharoV60.sources The macOS one-click version also contain PharoV60.source twice, in both: Contents/MacOS Contents/Resources

June 2, 2017

Do we have better collections design library?

by Denis Kudriashov

Hi. I just found that there is no WeakIdentityValueDictionary. But we have WeakValueDictionary, WeakKeyDictionary, WeakIdentityKeyDictionary. And to implement missing class I need to copy overrides from IdentityDictionary. And weak key dictionaries are implemented same way by duplicating code. And generally identity collections are not much different from equal collections but they still duplicate a lot of code with little difference: #hash or #identityHash, #= or #==. So I am wondering do we have alternative implementation with proper design? There are wishes to replace streams by XSteams. What about collections? Best regards, Denis

June 2, 2017

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

by Denis Kudriashov

2017-06-02 9:26 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 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. And you are able to do it right now with following scripts: - haltOnlyInTest > self haltIf: [ CurrentExecutionEnvironment value isKindOf: TestExecutionEnvironment] > - haltOnlyOutOfTest self haltIf: [ CurrentExecutionEnvironment value isKindOf: DefaultExecutionEnvironment]

June 2, 2017

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

by Sven Van Caekenberghe

Done: https://pharo.fogbugz.com/f/cases/20103/Minor-glitch-in-source-code-diff-to… > On 2 Jun 2017, at 08:11, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > 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: > > <Screen Shot 2017-06-01 at 12.01.38.png> > > 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