- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GSoC Week 3 update - Enhancing Pharo Command Line

by Ben Coman

On Thu, Jun 1, 2017 at 5:06 PM, Rajula Vineet <Vineet.Reddy(a)iiitb.org> wrote: > Hi all, > > It has been about three weeks, I started working on my GSoC project. The > first task I am working on is the new implementation for Current Working > Directory. I have written the new implementation. Currently, I am testing > the new code. Will soon share the work here. > Meanwhile, for the week three, I have written a blog post > <https://vineetreddy.wordpress.com/2017/05/29/cross-platform-with-pharo/> > on OSPlatfrom. Please do take a look and give your feedback. > > Thanks, > Rajula > > > Hi Rajula, Great to see an article on this subject. Probably its at a good level for pharo-users mail list as well, so I've copied there. Don't worry about the limited response. Many in pharo-dev probably know this subject well. It is still good to have it laid out like you did for newcomers to google when they need to know. cheers -ben

June 6, 2017

FTs now support single and multi-cells selection

by Elhamer

Hello everyone, You can now select single or multiple cells in FTs, for that you need to set the selectionMode to #column I made a short video to illustrate that: https://vimeo.com/220251050 There are a few things to note here: - The default selection mode is set to #row. - A reference to the fasttable needs to be passed the FTCellMorphs in the DataSource. - For multi-cell selection, the command key stroke on macOS is mapped to the Alt gr key in Windows, this doesn't seem right but this is what the "event commandKeyPressed" returns. You can find an example in the Examples sub package in the Morphic-Widgets-Fasttable package: âexampleTable6â |table ds| ds:=FTSampleDataSource new:10. table := FTTableMorph new extent: 500@500; selectionMode: #column; addColumn: (FTColumn id: 'column1'); addColumn: (FTColumn id: 'column2'); addColumn: (FTColumn id: 'column3'); dataSource: ds; selectRowIndex: 1; showFirstRowSelection; beMultipleSelection; onAnnouncement: FTSelectionChanged do: [ :ann | ('rows selected: ', (ann newSelectedRowIndexes asString)) crLog ]; onAnnouncement: FTCellStrongSelectionChanged do: [ :ann | |index morph ed | index := ann selectedCellIndex. morph := table visibleCellMorphAtIndex: index. ed := RubFloatingEditorBuilder new customizeEditorWith: [ :editor | editor scrollbarsShowNever. editor bounds: (morph bounds insetBy: (Margin left: -2 top: 0 right: 0 bottom: 0 )) ]; withEditedContentsDo: [ :editedContents | (ds elements at: index first) instVarAt:index second put: editedContents asString. table refresh]. ed openEditorWithContents: ((ds elements at: index first) instVarAt: index second). ]; yourself. table openInWindow. You can load the new package either from Smalltalkhub <http://smalltalkhub.com/#!/~ElhamerOussama/FastTableOptimizations/> or from Github <https://github.com/SamTheDev/Morphic-Widgets-FastTable> Your feedback is most welcome ð Regards, Elhamer Oussama. -- View this message in context: http://forum.world.st/FTs-now-support-single-and-multi-cells-selection-tp49… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 5, 2017

Re: [Pharo-dev] GSoC Week 3 update - Enhancing Pharo Command Line

by Stephane Ducasse

Thanks for the update. Keep pushing this. On Thu, Jun 1, 2017 at 11:06 AM, Rajula Vineet <Vineet.Reddy(a)iiitb.org> wrote: > Hi all, > > It has been about three weeks, I started working on my GSoC project. The > first task I am working on is the new implementation for Current Working > Directory. I have written the new implementation. Currently, I am testing > the new code. Will soon share the work here. Meanwhile, for the week three, > I have written a blog post > <https://vineetreddy.wordpress.com/2017/05/29/cross-platform-with-pharo/> > on OSPlatfrom. Please do take a look and give your feedback. > > Thanks, > Rajula > > > > -- > View this message in context: http://forum.world.st/GSoC-Week-3-update-Enhancing-Pharo-Command-Line-tp494… > 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

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