June 2017 - Pharo-dev - lists.pharo.org

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

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