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

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

by Stephane Ducasse

Could be but I like to have message too. Relying too much on tools is good but when suddently do not have tools because you are in a minimal kernel then having 3 extra messages should like a good win win situation. Stef On Mon, Jun 5, 2017 at 4:06 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Jun 5, 2017 at 5:01 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >>> >>> About >>> Halt only does not convey anything to me. >>> Halt onlyMe means clearly what is it >> >> >> To me it seems strange/awkward that code in one method will change global >> debugging state, >> and it would feel better via direct UI action to add a metalink (IIUC how >> that would work.) >> Plus also a global GUI tool to manage breakpoints/metalinks would be good. >> >> Yes but when you need you need it. >> Else what is the alternative: >> - remove all the halt during the execution. >> - execute yours >> - put back the halt if something wrong happens. >> >> or >> - create manually a global. >> - rewrite all your halt to depend on this global >> - turn on and off the global to get the desired effects... > > > or hypothetically something like... right-click code and menu select "break > here, disable others" > > cheers -ben > >> >> Tedious, cumbersome and boring. >> We can do better. >> >> >> >> >> >> On Mon, Jun 5, 2017 at 4:09 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> >>> On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>> >>>> What we should consider is that well packaged methods can be in Object. >>>> The problem is when method in Object are used everywhere and that they >>>> have nothing to do there. >>>> >>>> About >>>> Halt only does not convey anything to me. >>>> Halt onlyMe means clearly what is it >>> >>> >>> To me it seems strange/awkward that code in one method will change global >>> debugging state, >>> and it would feel better via direct UI action to add a metalink (IIUC how >>> that would work.) >>> Plus also a global GUI tool to manage breakpoints/metalinks would be >>> good. >>> >>> >>>> >>>> For the >>>> Halt ifTest >>>> Halt ifNotTest >>>> >>>> Why not. But I would prefer to be really clear. >>>> I would prefer >>>> >>>> Halt ifInsideTest >>>> Halt ifOutsideTest >>> >>> >>> These sound good. >>> cheers -ben >>> >>>> >>>> >>>> Because we are not about a couple of characters. >>>> >>>> Stef >>>> >>>> >>>> >>>> On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. >>>> <cyril.ferlicot(a)gmail.com> wrote: >>>>> >>>>> Le 04/06/2017 Ã 11:40, Peter Uhnak a Ã©crit : >>>>> > But then I wouldn't be able to write 1halt. :( >>>>> > >>>>> > Peter >>>>> > >>>>> >>>>> You can still add some startup script :) >>>>> >>>>> I have one compiling a "h" method in object calling halt to be able to >>>>> write "1h" :) >>>>> >>>>> -- >>>>> Cyril Ferlicot >>>>> https://ferlicot.fr >>>>> >>>>> http://www.synectique.eu >>>>> 2 rue Jacques PrÃ©vert 01, >>>>> 59650 Villeneuve d'ascq France >>>>> >>>> >>> >> >

June 5, 2017

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

by Ben Coman

On Mon, Jun 5, 2017 at 5:01 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > About >> Halt only does not convey anything to me. >> Halt onlyMe means clearly what is it >> > > To me it seems strange/awkward that code in one method will change global > debugging state, > and it would feel better via direct UI action to add a metalink (IIUC how > that would work.) > Plus also a global GUI tool to manage breakpoints/metalinks would be good. > > Yes but when you need you need it. > Else what is the alternative: > - remove all the halt during the execution. > - execute yours > - put back the halt if something wrong happens. > > or > - create manually a global. > - rewrite all your halt to depend on this global > - turn on and off the global to get the desired effects... > or hypothetically something like... right-click code and menu select "break here, disable others" cheers -ben > Tedious, cumbersome and boring. > We can do better. > > > > > > On Mon, Jun 5, 2017 at 4:09 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse <stepharo.self(a)gmail.com >> > wrote: >> >>> What we should consider is that well packaged methods can be in Object. >>> The problem is when method in Object are used everywhere and that they >>> have nothing to do there. >>> >>> About >>> Halt only does not convey anything to me. >>> Halt onlyMe means clearly what is it >>> >> >> To me it seems strange/awkward that code in one method will change global >> debugging state, >> and it would feel better via direct UI action to add a metalink (IIUC how >> that would work.) >> Plus also a global GUI tool to manage breakpoints/metalinks would be good. >> >> >> >>> For the >>> Halt ifTest >>> Halt ifNotTest >>> >>> Why not. But I would prefer to be really clear. >>> I would prefer >>> >>> Halt ifInsideTest >>> Halt ifOutsideTest >>> >> >> These sound good. >> cheers -ben >> >> >>> >>> Because we are not about a couple of characters. >>> >>> Stef >>> >>> >>> >>> On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. < >>> cyril.ferlicot(a)gmail.com> wrote: >>> >>>> Le 04/06/2017 Ã 11:40, Peter Uhnak a Ã©crit : >>>> > But then I wouldn't be able to write 1halt. :( >>>> > >>>> > Peter >>>> > >>>> >>>> You can still add some startup script :) >>>> >>>> I have one compiling a "h" method in object calling halt to be able to >>>> write "1h" :) >>>> >>>> -- >>>> Cyril Ferlicot >>>> https://ferlicot.fr >>>> >>>> http://www.synectique.eu >>>> 2 rue Jacques PrÃ©vert 01, >>>> 59650 Villeneuve d'ascq France >>>> >>>> >>> >> >

June 5, 2017

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

by Stephane Ducasse

Hi nicolas I do not have a windows OS or machine to test. If you let me know what I should take and try I can ask from students to try. But most of the people in our team is on linux or mac. Stef On Fri, Jun 2, 2017 at 11:10 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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(a)gmail.com>: >>> >>> >>> >>> 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!!! >>> >>> >> >> >> 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-test-download-for-Pharo-6-0-tp4948720p4948965.… >>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>> Nabble.com. >>>>>> >>>>> >>>> >>> >> >

June 5, 2017

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

by Stephane Ducasse

> > About > Halt only does not convey anything to me. > Halt onlyMe means clearly what is it > To me it seems strange/awkward that code in one method will change global debugging state, and it would feel better via direct UI action to add a metalink (IIUC how that would work.) Plus also a global GUI tool to manage breakpoints/metalinks would be good. Yes but when you need you need it. Else what is the alternative: - remove all the halt during the execution. - execute yours - put back the halt if something wrong happens. or - create manually a global. - rewrite all your halt to depend on this global - turn on and off the global to get the desired effects... Tedious, cumbersome and boring. We can do better. On Mon, Jun 5, 2017 at 4:09 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> What we should consider is that well packaged methods can be in Object. >> The problem is when method in Object are used everywhere and that they >> have nothing to do there. >> >> About >> Halt only does not convey anything to me. >> Halt onlyMe means clearly what is it >> > > To me it seems strange/awkward that code in one method will change global > debugging state, > and it would feel better via direct UI action to add a metalink (IIUC how > that would work.) > Plus also a global GUI tool to manage breakpoints/metalinks would be good. > > > >> For the >> Halt ifTest >> Halt ifNotTest >> >> Why not. But I would prefer to be really clear. >> I would prefer >> >> Halt ifInsideTest >> Halt ifOutsideTest >> > > These sound good. > cheers -ben > > >> >> Because we are not about a couple of characters. >> >> Stef >> >> >> >> On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. < >> cyril.ferlicot(a)gmail.com> wrote: >> >>> Le 04/06/2017 Ã 11:40, Peter Uhnak a Ã©crit : >>> > But then I wouldn't be able to write 1halt. :( >>> > >>> > Peter >>> > >>> >>> You can still add some startup script :) >>> >>> I have one compiling a "h" method in object calling halt to be able to >>> write "1h" :) >>> >>> -- >>> Cyril Ferlicot >>> https://ferlicot.fr >>> >>> http://www.synectique.eu >>> 2 rue Jacques PrÃ©vert 01, >>> 59650 Villeneuve d'ascq France >>> >>> >> >

June 5, 2017

Esteban's ChangeLog week of 29 May 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 29 May 2017 to 4 June 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=29/5/2017&to=4/6/2017 ChangeLog ========= 1 June 2017: ------------ * ... and now I fixed the problem with real files/symlinks in distribution, it will be fixed in next build. Turns out it was a problem with the cache of travis for opensmalltalk-vm :) * Problem in Athens 64bits was with font treatment: Someone was using an +uint+ instead a +void *+ to pass a pointer. Of course, this was working fine on 32bits (because sizeof is the same) but is completely wrong on 64bits. Anyway, I found it and fixed it on [case: 20099](https://pharo.fogbugz.com/f/cases/20099) * Yesterday after we ask for final testing we spotted two new blocking issues for release: * Athens was not working on 64bits * Distribution packaging were duplicating files insted copying symlink So, I deferred the release (once again) to next tuesday. 31 May 2017: ------------ * I promoted new stables for [PharoVM](http://files.pharo.org/get-files/60) . This should fix the black-screen problem on mac and the problem of fast-typing also on mac (but latest still needs some test) 30 May 2017: ------------ * I checked a couple of issues on [iceberg](https://github.com/pharo-vcs/iceberg). Still warming up but I got to solve at least [one issue](https://github.com/pharo-vcs/iceberg/issues/361), around correctly dealing with bad user.name and user.mail properties :) * I updated the scripts for creating platform distributions to build also 64bits versions, now you have also a distribution for 64bits on [mac](http://files.pharo.org/platform/Pharo6.0-64-mac.zip) and on [linux](http://files.pharo.org/platform/Pharo6.0-64-linux.zip). * Back from holidays, I just restored the CI building for Pharo to green :P Now, to do that release! cheers! Esteban

June 5, 2017

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

by Ben Coman

On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > What we should consider is that well packaged methods can be in Object. > The problem is when method in Object are used everywhere and that they > have nothing to do there. > > About > Halt only does not convey anything to me. > Halt onlyMe means clearly what is it > To me it seems strange/awkward that code in one method will change global debugging state, and it would feel better via direct UI action to add a metalink (IIUC how that would work.) Plus also a global GUI tool to manage breakpoints/metalinks would be good. > For the > Halt ifTest > Halt ifNotTest > > Why not. But I would prefer to be really clear. > I would prefer > > Halt ifInsideTest > Halt ifOutsideTest > These sound good. cheers -ben > > Because we are not about a couple of characters. > > Stef > > > > On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. < > cyril.ferlicot(a)gmail.com> wrote: > >> Le 04/06/2017 Ã 11:40, Peter Uhnak a Ã©crit : >> > But then I wouldn't be able to write 1halt. :( >> > >> > Peter >> > >> >> You can still add some startup script :) >> >> I have one compiling a "h" method in object calling halt to be able to >> write "1h" :) >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> >> >

June 5, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Ben Coman

Besides other action, in parallel perhaps the first step would be displaying a QA tip? cheers -ben On Mon, Jun 5, 2017 at 3:26 AM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 04/06/2017 Ã 18:20, Eliot Miranda a Ã©crit : > > Hi Cyril, > > > > Hi Eliot, > > > > > As Minty points out, this unintuitive behaviour exists fur a reason and > there is a work around. > > > > SUnit is a community wide package existing in all the dialects of > Smalltalk I'm aware of. If you change the semantics then every time a test > suite is exchanged it will need to be rewritten, and by someone who > understands the divergence, otherwise the test suite won't work as intended. > > > > Is is worth diverging from a community wide standard when there is a > rationale for the design and there is a work around? > > > > When I discovered this behaviour I was really surprised by it. > (apparently I am not the only one) And if I did not checked the number > of tests I think I would have never know that my tests are not executed > in all the hierarchy. > > Also, abstract tests classes is something I use a lot since I am in the > community. Now I know that I'll need to change many of the projects I > contributed to in order to activate all the tests I wanted. And I think > a lot of newcomers will not know this behaviour because it is counter > intuitive. IMO, it goes against the principle of inheritance. > > > > Is it puss bow to seek a wider consensus and see what e.g. the > VisualWorks, VisualAge and GemStone communities think? > > > > For this problem I would like to see all the smalltalks using SUnit > change this behaviour. I really do not want to break compatibility and I > think this change is important for the usability of SUnit. I don't have > much contact with other smalltalk communities but I would be happy if we > can seek a consensus. > > If you have an idea of the best way to communicate with all the > communities on this subject I would like to hear it. > > > Is it possible that better documenting the work around would be better? > > > > Personally I think that even with a good documentation, this is not the > kind of thing everyone will remember. But this is only my opinion. :) > > > > > _,,,^..^,,,_ (phone) > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

June 5, 2017

Re: [Pharo-dev] Abstract test classes are not managed well in SUnit

by Nicolas Cellier

2017-06-04 21:28 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > Le 04/06/2017 Ã 21:26, Cyril Ferlicot D. a Ã©crit : > > For this problem I would like to see all the smalltalks using SUnit > > change this behaviour. I really do not want to break compatibility and I > > think this change is important for the usability of SUnit. I don't have > > much contact with other smalltalk communities but I would be happy if we > > can seek a consensus. > > > > If you have an idea of the best way to communicate with all the > > communities on this subject I would like to hear it. > > > > Maybe we can talk about it at ESUG? > > It can be interesting to measure instead of throwing 99% figures like I did ;) Here is a small snippet and result in Squeak trunk: | testAll testLocal superIsAbstractOrTestSelectorIsEmpty superclassIsAbstract selectorsIsEmpty selectorsIsEmptyButNotAbstract | testAll := Set new. testLocal := Set new. superIsAbstractOrTestSelectorIsEmpty := Set new. superclassIsAbstract := Set new. selectorsIsEmpty := Set new. selectorsIsEmptyButNotAbstract := Set new. TestCase allSubclassesDo: [:c | c superclass = TestCase ifFalse: [ (c superclass isAbstract or: [c testSelectors isEmpty]) ifTrue: [superIsAbstractOrTestSelectorIsEmpty add: c]. c superclass isAbstract ifTrue: [superclassIsAbstract add: c] ifFalse: [c testSelectors isEmpty ifTrue: [selectorsIsEmptyButNotAbstract add: c]]. c testSelectors isEmpty ifTrue: [selectorsIsEmpty add: c]. c shouldInheritSelectors ifTrue: [testAll add: c] ifFalse: [testLocal add: c]]]. {testAll size. superIsAbstractOrTestSelectorIsEmpty size. superclassIsAbstract size. selectorsIsEmptyButNotAbstract size. selectorsIsEmpty size. testLocal size}. #(143 142 129 13 17 22) So 143 classes want to inherit - 129 because superclass isAbstract, - 13 because testSelectors isEmpty, - 1 for another reason - override of shouldInheritSelectors, for which we should write a snippet too 22 don't want to inherit But here are the 22 in Squeak: (testLocal collect: #name) sorted -> #(#ChangeHooksTest #ClassTraitTest #MessageTraceTest #MethodHighlightingTests #MorphBugs #MorphicEventDispatcherTests #MorphicEventFilterTests #MorphicEventTests #PolygonMorphTest #PureBehaviorTest #StickynessBugz #SystemChangeErrorHandling #SystemChangeNotifierTest #TestNewParagraphFix #TextAnchorTest #TextEmphasisTest #TextFontChangeTest #TraitCompositionTest #TraitFileOutTest #TraitMethodDescriptionTest #TraitSystemTest #TraitTest) and their superclass ((testLocal collect: #superclass) collect: #name) sorted -> #(#ClosureCompilerTest #HashAndEqualsTestCase #MessageSetTest #MorphTest #MorphicUIManagerTest #SystemChangeTestRoot #TestParagraphFix #TraitsTestCase #UserInputEventTests) Let's see; - TraitsTestCase is not abstract, but defines no test! So it is kind of abstract. TraitsTestCase subclasses size -> 7, 15 remain out of 22 - same for SystemChangeTestRoot, 4 subclasses, 11 remain out of 22. - same for UserInputEventTests. 3 subclasses less, 8 remaining out of 22. - TestNewParagraphFix does redefine all super test as ^super test... A lack of knowledge visibly. 7 remaining out of 22. - HashAndEqualsTestCase is not abstract, has tests, but the tested prototypes are empty! So it is yet another abstract class in disguise. But this time, some subclasses won't testHash nor testEquality except if they redefine it, is it a bug? That's 3 subclasses with not empty selectors, so 4 remaining out of 22 The others might be correct, so 161 ou of 165 should inherit... Not 99%, only near 98%. That would be 4 (super)classes requiring implementation of a shouldInheritSelectors ^false. That's too much, so let's analyze further. Maybe MethodHighlightingTests does not need to inherit from ClosureCompilerTest... (no inst var in super, and no super method used). That 1 less. MorphBugs and PolygonMorphTest don't need to be a subclass (it's just for classifying). There is no specific setUp, and tests could go upward. That's 2 less. Same for StickynessBugz. 1 less. After an easy refactoring, nothing in Squeak trunk would really require a shouldInheritSelectors ^false. It would be interesting to replay the snippet in Pharo, and in 3rd party applications too. That's good elements for opening a discussion. -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

June 4, 2017

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

by Stephane Ducasse

What we should consider is that well packaged methods can be in Object. The problem is when method in Object are used everywhere and that they have nothing to do there. About Halt only does not convey anything to me. Halt onlyMe means clearly what is it For the Halt ifTest Halt ifNotTest Why not. But I would prefer to be really clear. I would prefer Halt ifInsideTest Halt ifOutsideTest Because we are not about a couple of characters. Stef On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 04/06/2017 Ã 11:40, Peter Uhnak a Ã©crit : > > But then I wouldn't be able to write 1halt. :( > > > > Peter > > > > You can still add some startup script :) > > I have one compiling a "h" method in object calling halt to be able to > write "1h" :) > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

June 4, 2017

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

by Stephane Ducasse

Lack of manpower :) We should have put a good engineer on it for 3-4 months. More important stuff to do. Now I have the code. And we are about to release a better trait implementation with state. So if people want to play and redesign a collection library I'm really supporting the idea. Stef On Sun, Jun 4, 2017 at 10:10 PM, webwarrior <reg(a)webwarrior.ws> wrote: > Denis Kudriashov wrote > > 2017-06-04 19:32 GMT+02:00 webwarrior < > > > reg@ > > > >: > > > >> I think design deficiencies of Pharo collections can be addressed with > >> traits. > >> > > > > There was some work around it: > > https://hal.inria.fr/inria-00511902/file/main.pdf. > > (funny that it it was named Bloc ) > > Why has it been abandoned? > > > > -- > View this message in context: http://forum.world.st/Do-we- > have-better-collections-design-library-tp4948936p4949274.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

June 4, 2017