- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Do we have better collections design library?

by Eliot Miranda

Hi Denis, On Fri, Jun 2, 2017 at 2: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? > The StrongTalk team reimplemented their Collections hierarchy to have much better modularity because their VM did the necessary inlining to create the efficient versions on the fly. This is what Scorch/Sista supports. Perhaps we should wait until it arrives, perhaps not, but certainly what you propose is a good idea whose time has almost come. > There are wishes to replace streams by XSteams. What about collections? > > Best regards, > Denis > -- _,,,^..^,,,_ best, Eliot

June 2, 2017

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

by Nicolas Cellier

This is now fixed, you just have to wait for appveyor to finish its job. Guys, I have pushed Win64 VM including the Pharo flavour. It works well in Squeak but I'm not a Pharo user (or very casual). All I'm asking for weeks or even months is a little feedback... So this evening, when I see that the 64 bits image does not even start and that I got absolutely no feedback except this late one of Henrik (Thank you thank you thank you Henrik), I feel sad. Helping Pharo is not very rewarding :( 2017-06-02 22:50 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-06-02 22:35 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-06-02 22:21 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.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-coint >> erp.c:6373 >> #4 0x0000000000429046 in enterSmalltalkExecutiveImplementation () at >> ../../spur64src/vm/gcc3x-cointerp.c:18181 >> #5 0x00000000004018a8 in interpret () at ../../spur64src/vm/gcc3x-coint >> erp.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/sqWin >> 32Main.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!!! >> >> >> > > The LOGD shows that $COGDEFS was not used in plugin compilation, so > -DPharoVM=1 is missing from the clang command line > > rm -f builddbg/vm/FilePlugin.ignore > make -w BUILD=builddbg \ > -f /cygdrive/X/Smalltalk/opensmalltalk-vm/build. > win64x64/common/Makefile.plugin \ > CONFIGURATION=debug TOOLPREFIX=x86_64-w64-mingw32- \ > THIRDPARTYOUTDIR=/cygdrive/X/Smalltalk/opensmalltalk-vm/. > thirdparty-cache/windows/x86_64 \ > PLATDIR=../../platforms PLUGINSRCDIR=../../src > VMSRCDIR=../../spur64src/vm \ > LIBNAME=FilePlugin COGDEFS="-DPharoVM=1 -DIMMUTABILITY=1 > -DCOGMTVM=0 -DDEBUGVM=1" XDEFS=-DSQUEAK_BUILTIN_PLUGIN \ > builddbg/vm/FilePlugin.lib > make[2] : on entre dans le rÃ©pertoire Â« /cygdrive/X/Smalltalk/ > opensmalltalk-vm/build.win64x64/pharo.cog.spur Â» > x86_64-w64-mingw32-clang -x c -MT builddbg/FilePlugin/FilePlugin.o -MMD > -MP -MF deps/FilePlugin.Td -fdeclspec -msse2 -ggdb2 -m64 -mdll -mno-rtd > -mms-bitfields -O0 -fno-omit-frame-pointer -D_MT -fno-builtin-printf > -fno-builtin-putchar -fno-builtin-fprintf -Wall -Wno-unused-variable > -Wno-unknown-pragmas -Wno-unused-label -Wno-unused-function -I. > -I../../spur64src/vm -I../../platforms/win32/vm -I../../platforms/Cross/vm > -I../../src/plugins/FilePlugin -I../../platforms/win32/plugins/FilePlugin > -I../../platforms/Cross/plugins/FilePlugin -D_WIN32_WINNT=0x0501 > -DWINVER=0x0501 -DWIN64=1 -DWIN32_FILE_SUPPORT -DNO_ISNAN -DNO_SERVICE > -DNO_STD_FILE_SUPPORT -DLSB_FIRST -DVM_NAME=\"\" -DSQUEAK_BUILTIN_PLUGIN > -c ../../src/plugins/FilePlugin/FilePlugin.c -o builddbg/FilePlugin/ > FilePlugin.o > clang-3.9: warning: argument unused during compilation: '-mdll' > sed '/^$/d' <deps/FilePlugin.Td | sed '/^.*:$/d' | sed 's/ [^ ]*:/:/' | > sed 's/^build[^/]*/$(BUILD)/' > deps/FilePlugin.d; rm deps/FilePlugin.Td; > touch -r ../../src/plugins/FilePlugin/FilePlugin.c deps/FilePlugin.d > x86_64-w64-mingw32-clang -x c -MT builddbg/FilePlugin/sqWin32FilePrims.o > -MMD -MP -MF deps/sqWin32FilePrims.Td -fdeclspec -msse2 -ggdb2 -m64 -mdll > -mno-rtd -mms-bitfields -O0 -fno-omit-frame-pointer -D_MT > -fno-builtin-printf -fno-builtin-putchar -fno-builtin-fprintf -Wall > -Wno-unused-variable -Wno-unknown-pragmas -Wno-unused-label > -Wno-unused-function -I. -I../../spur64src/vm -I../../platforms/win32/vm > -I../../platforms/Cross/vm -I../../src/plugins/FilePlugin > -I../../platforms/win32/plugins/FilePlugin -I../../platforms/Cross/plugins/FilePlugin > -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -DWIN64=1 -DWIN32_FILE_SUPPORT > -DNO_ISNAN -DNO_SERVICE -DNO_STD_FILE_SUPPORT -DLSB_FIRST -DVM_NAME=\"\" > -DSQUEAK_BUILTIN_PLUGIN -c ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c > -o builddbg/FilePlugin/sqWin32FilePrims.o > > $ grep -r COGDEFS ../common > ../common/Makefile: LIBNAME=$(*F) COGDEFS="$(COGDEFS)" > XDEFS=-DSQUEAK_BUILTIN_PLUGIN \ > ../common/Makefile: COGDEFS="$(COGDEFS)" LIBNAME=$(*F) > $(OBJDIR)/$(*F).dll > ../common/Makefile.tools:COGDEFS:= $(COGDEFS) -DCOGMTVM=1 > -DDEBUGVM=$(DEBUGVM) > ../common/Makefile.tools:COGDEFS:= $(COGDEFS) -DCOGMTVM=0 > -DDEBUGVM=$(DEBUGVM) > ../common/Makefile.tools:DEFS:= $(COGDEFS) $(WINVER) -DWIN64=1 > -DWIN32_FILE_SUPPORT -DNO_ISNAN \ > > COGDEFS is used in DEFS, but DEFS is overriden in ../common/Makefile.plugin > > $ grep -r '\<DEFS\>' ../common > ../common/Makefile: $(CC) -o $(OBJDIR)/version.o $(CFLAGS) $(INCLUDES) > $(DEFS) -c $(WIN32DIR)/version.c > ../common/Makefile: $(CC) -o $(OBJDIR)/version.o $(CFLAGS) $(INCLUDES) > $(DEFS) -c $(WIN32DIR)/version.c > ../common/Makefile.plugin:DEFS:= $(WINVER) -DWIN64=1 > -DWIN32_FILE_SUPPORT -DNO_ISNAN \ > ../common/Makefile.rules:ALLFLAGS = $(DEPFLAGS) $(CFLAGS) $(INCLUDES) > $(DEFS) > ../common/Makefile.tools:DEFS:= $(COGDEFS) $(WINVER) -DWIN64=1 > -DWIN32_FILE_SUPPORT -DNO_ISNAN \ > > After a diff with build.win32x86, it appears that the WIN32 version > directly append $(COGDEFS) to the CFLAGS, so I will commit a fix and retry > ASAP > > >>> 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] please test download for Pharo 6.0

by Nicolas Cellier

2017-06-02 22:35 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-06-02 22:21 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > 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!!! > > > The LOGD shows that $COGDEFS was not used in plugin compilation, so -DPharoVM=1 is missing from the clang command line rm -f builddbg/vm/FilePlugin.ignore make -w BUILD=builddbg \ -f /cygdrive/X/Smalltalk/opensmalltalk-vm/build.win64x64/common/Makefile.plugin \ CONFIGURATION=debug TOOLPREFIX=x86_64-w64-mingw32- \ THIRDPARTYOUTDIR=/cygdrive/X/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/x86_64 \ PLATDIR=../../platforms PLUGINSRCDIR=../../src VMSRCDIR=../../spur64src/vm \ LIBNAME=FilePlugin COGDEFS="-DPharoVM=1 -DIMMUTABILITY=1 -DCOGMTVM=0 -DDEBUGVM=1" XDEFS=-DSQUEAK_BUILTIN_PLUGIN \ builddbg/vm/FilePlugin.lib make[2] : on entre dans le rÃ©pertoire Â« /cygdrive/X/Smalltalk/opensmalltalk-vm/build.win64x64/pharo.cog.spur Â» x86_64-w64-mingw32-clang -x c -MT builddbg/FilePlugin/FilePlugin.o -MMD -MP -MF deps/FilePlugin.Td -fdeclspec -msse2 -ggdb2 -m64 -mdll -mno-rtd -mms-bitfields -O0 -fno-omit-frame-pointer -D_MT -fno-builtin-printf -fno-builtin-putchar -fno-builtin-fprintf -Wall -Wno-unused-variable -Wno-unknown-pragmas -Wno-unused-label -Wno-unused-function -I. -I../../spur64src/vm -I../../platforms/win32/vm -I../../platforms/Cross/vm -I../../src/plugins/FilePlugin -I../../platforms/win32/plugins/FilePlugin -I../../platforms/Cross/plugins/FilePlugin -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -DWIN64=1 -DWIN32_FILE_SUPPORT -DNO_ISNAN -DNO_SERVICE -DNO_STD_FILE_SUPPORT -DLSB_FIRST -DVM_NAME=\"\" -DSQUEAK_BUILTIN_PLUGIN -c ../../src/plugins/FilePlugin/FilePlugin.c -o builddbg/FilePlugin/FilePlugin.o clang-3.9: warning: argument unused during compilation: '-mdll' sed '/^$/d' <deps/FilePlugin.Td | sed '/^.*:$/d' | sed 's/ [^ ]*:/:/' | sed 's/^build[^/]*/$(BUILD)/' > deps/FilePlugin.d; rm deps/FilePlugin.Td; touch -r ../../src/plugins/FilePlugin/FilePlugin.c deps/FilePlugin.d x86_64-w64-mingw32-clang -x c -MT builddbg/FilePlugin/sqWin32FilePrims.o -MMD -MP -MF deps/sqWin32FilePrims.Td -fdeclspec -msse2 -ggdb2 -m64 -mdll -mno-rtd -mms-bitfields -O0 -fno-omit-frame-pointer -D_MT -fno-builtin-printf -fno-builtin-putchar -fno-builtin-fprintf -Wall -Wno-unused-variable -Wno-unknown-pragmas -Wno-unused-label -Wno-unused-function -I. -I../../spur64src/vm -I../../platforms/win32/vm -I../../platforms/Cross/vm -I../../src/plugins/FilePlugin -I../../platforms/win32/plugins/FilePlugin -I../../platforms/Cross/plugins/FilePlugin -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -DWIN64=1 -DWIN32_FILE_SUPPORT -DNO_ISNAN -DNO_SERVICE -DNO_STD_FILE_SUPPORT -DLSB_FIRST -DVM_NAME=\"\" -DSQUEAK_BUILTIN_PLUGIN -c ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c -o builddbg/FilePlugin/sqWin32FilePrims.o $ grep -r COGDEFS ../common ../common/Makefile: LIBNAME=$(*F) COGDEFS="$(COGDEFS)" XDEFS=-DSQUEAK_BUILTIN_PLUGIN \ ../common/Makefile: COGDEFS="$(COGDEFS)" LIBNAME=$(*F) $(OBJDIR)/$(*F).dll ../common/Makefile.tools:COGDEFS:= $(COGDEFS) -DCOGMTVM=1 -DDEBUGVM=$(DEBUGVM) ../common/Makefile.tools:COGDEFS:= $(COGDEFS) -DCOGMTVM=0 -DDEBUGVM=$(DEBUGVM) ../common/Makefile.tools:DEFS:= $(COGDEFS) $(WINVER) -DWIN64=1 -DWIN32_FILE_SUPPORT -DNO_ISNAN \ COGDEFS is used in DEFS, but DEFS is overriden in ../common/Makefile.plugin $ grep -r '\<DEFS\>' ../common ../common/Makefile: $(CC) -o $(OBJDIR)/version.o $(CFLAGS) $(INCLUDES) $(DEFS) -c $(WIN32DIR)/version.c ../common/Makefile: $(CC) -o $(OBJDIR)/version.o $(CFLAGS) $(INCLUDES) $(DEFS) -c $(WIN32DIR)/version.c ../common/Makefile.plugin:DEFS:= $(WINVER) -DWIN64=1 -DWIN32_FILE_SUPPORT -DNO_ISNAN \ ../common/Makefile.rules:ALLFLAGS = $(DEPFLAGS) $(CFLAGS) $(INCLUDES) $(DEFS) ../common/Makefile.tools:DEFS:= $(COGDEFS) $(WINVER) -DWIN64=1 -DWIN32_FILE_SUPPORT -DNO_ISNAN \ After a diff with build.win32x86, it appears that the WIN32 version directly append $(COGDEFS) to the CFLAGS, so I will commit a fix and retry ASAP >> 2017-06-02 17:15 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.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

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