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

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

by Nicolas Cellier

2017-06-02 22:21 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Follow up: it's not enough... > > Program received signal SIGSEGV, Segmentation fault. > 0x000000000051cfc8 in dir_EntryLookup (pathString=0xce7edb0 > "X:\\Smalltalk\\opensmalltalk-vm\\build.win64x64\\pharo.cog.spur\\builddbg\\vm", > pathLength=71, > nameString=0xce81868 "PharoV60.sources", nameStringLength=16, > name=0xfe5aa0 "", nameLength=0xfe5a98, creationDate=0xfe5ba8, > modificationDate=0xfe5a88, > isDirectory=0xfe5ba0, sizeIfFile=0xfe5a90, posixPermissions=0x0, > isSymlink=0x0) at ../../platforms/win32/vm/sqWin32Directory.c:397 > 397 *posixPermissions = 0; > > I'll have to understand why those PharoVM last 2 args are zero... > It looks like FilePlugin did not have the -DPharoVM because the backtrace point at the wrong #ifdef branch: (gdb) bt #0 dir_EntryLookup (pathString=0xc27edb0 "X:\\Smalltalk\\opensmalltalk-vm\\build.win64x64\\pharo.cog.spur\\builddbg\\vm", pathLength=71, nameString=0xc281868 "PharoV60.sources", nameStringLength=16, name=0xfe5aa0 "ryEntry", nameLength=0xfe5a98, creationDate=0xfe5ba8, modificationDate=0xfe5a88, isDirectory=0xfe5ba0, sizeIfFile=0xfe5a90, posixPermissions=0x0, isSymlink=0x0) at ../../platforms/win32/vm/sqWin32Directory.c:379 #1 0x00000000005835a6 in primitiveDirectoryEntry () at ../../src/plugins/FilePlugin/FilePlugin.c:654 #2 0x0000000000442d5e in primitiveExternalCall () at ../../spur64src/vm/gcc3x-cointerp.c:76521 #3 0x000000000040d8ba in interpret () at ../../spur64src/vm/gcc3x-cointerp.c:6373 #4 0x0000000000429046 in enterSmalltalkExecutiveImplementation () at ../../spur64src/vm/gcc3x-cointerp.c:18181 #5 0x00000000004018a8 in interpret () at ../../spur64src/vm/gcc3x-cointerp.c:2678 #6 0x00000000005279a8 in sqMain (argc=1, argv=0x11850f0) at ../../platforms/win32/vm/sqWin32Main.c:1572 #7 0x0000000000527e95 in WinMain (hInst=0x400000, hPrevInstance=0x0, lpCmdLine=0x11f3f32 "", nCmdShow=10) at ../../platforms/win32/vm/sqWin32Main.c:1678 #8 0x00000000004013ed in __tmainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-5.0.2-1/crt/crtexe.c:334 #9 0x00000000004014fb in WinMainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-5.0.2-1/crt/crtexe.c:184 (gdb) up #1 0x00000000005835a6 in primitiveDirectoryEntry () at ../../src/plugins/FilePlugin/FilePlugin.c:654 654 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize, (gdb) list 646,658 646 647 # if PharoVM 648 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize, 649 entryName, &entryNameSize, &createDate, 650 &modifiedDate, &dirFlag, &fileSize, 651 &posixPermissions, &symlinkFlag); 652 653 # else /* PharoVM */ 654 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize, 655 entryName, &entryNameSize, &createDate, 656 &modifiedDate, &dirFlag, &fileSize); 657 658 # endif /* PharoVM */ The backtrace should never be at 654!!! > > 2017-06-02 17:15 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> 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-t >>> est-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] please test download for Pharo 6.0

by Nicolas Cellier

Follow up: it's not enough... Program received signal SIGSEGV, Segmentation fault. 0x000000000051cfc8 in dir_EntryLookup (pathString=0xce7edb0 "X:\\Smalltalk\\opensmalltalk-vm\\build.win64x64\\pharo.cog.spur\\builddbg\\vm", pathLength=71, nameString=0xce81868 "PharoV60.sources", nameStringLength=16, name=0xfe5aa0 "", nameLength=0xfe5a98, creationDate=0xfe5ba8, modificationDate=0xfe5a88, isDirectory=0xfe5ba0, sizeIfFile=0xfe5a90, posixPermissions=0x0, isSymlink=0x0) at ../../platforms/win32/vm/sqWin32Directory.c:397 397 *posixPermissions = 0; I'll have to understand why those PharoVM last 2 args are zero... 2017-06-02 17:15 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > 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-t >> est-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] Do we have better collections design library?

by Stephane Ducasse

Let us start with streams :) On Fri, Jun 2, 2017 at 11:20 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 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 Stephane Ducasse

Excellent! We should add them to the system. On Fri, Jun 2, 2017 at 10:00 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 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] New and richer halt messages

by Stephane Ducasse

I would go for simplicity. If we have a simple way to build then no need for metalink machinery On Fri, Jun 2, 2017 at 9:28 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 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 Stephane Ducasse

We will added back because it is nice indeed. On Fri, Jun 2, 2017 at 8:57 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > 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

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

by Ben Coman

On Fri, Jun 2, 2017 at 9:09 PM, 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. > > But I think we should not wait with the release for that. > In that case maybe we should call 64-bit a technology preview, and push for an early point release that fully passes tests - maybe worth a sprint focus. cheers -ben > > 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-64-bit-Some-Kernel-Tests-Numbers- > fail-to-take-64-bit-into-account > > https://pharo.fogbugz.com/f/cases/20108/CompiledMethod- > isAbstract-fails-on-64-bit > > https://pharo.fogbugz.com/f/cases/20111/Some-Collection- > tests-fail-on-64-bit-because-they-assume-Floats-are-non-immediate > > https://pharo.fogbugz.com/f/cases/20110/AllocationTest- > testOutOfMemorySignal-not-well-suited-to-64-bit > > 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] 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