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

Re: [Pharo-dev] [Seaside] [ANN] Pharo 6.0 released!

by Martin Dias

Congratulations! :-D MartÃn ps: I'll report in another email a small issue with curl and zeroconf for 64 bits On Tue, Jun 6, 2017 at 12:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Dear World, > > The time has come for Pharo 6.0! > > Pharo is a pure object-oriented programming language and a powerful > environment, focused on simplicity and immediate feedback. > > This is our most significant release yet. Here are some highlights: > > - Pharo is now provided in 64-bit version in Linux and OSX and brings even > better performance and stability (beware, 64bits version is a new > technology and a small amount of tests is still failing) > - A new code changes management system named Epicea for easier reviewing > and recovering of your code easily > - Integrated support for Git through an easy-to-use tool for repositories > and commits management named Iceberg (as a preview for Pharo 6, it will be > the default in Pharo 7) > - The unified foreign function interface (UnifiedFFI) for interfacing with > the outside world is significantly improved > - The PharoVM is now part of OpenSmalltalk initiative > - Introduction of object immutability, alternative bytecode sets and block > closures independent of outer context > - Pharo can now be bootstrapped from source code managed by Git > - Pharo modularity is improved > - Pharo is faster > - The Dark Theme was improved and set as default color theme of Pharo > > > These are just the more prominent highlights, but the details are just as > important. We have closed 1474 issues in Pharo 6.0 (a more complete > changelog can be found at https://github.com/pharo-proje > ct/pharo-changelogs/blob/master/Pharo60ChangeLogs.md). > > While the technical improvements are significant (starting the transition > to 64bits is a remarkable achievement), still the most impressive fact is > that the new code that got in the main Pharo 6.0 image was contributed by > more than 80 people. > > Pharo is more than code. It is an exciting project involving energetic > people. We thank all the contributors of this release: > > Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, > Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard > Pieber, Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, > Dale Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, > Dirk Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan > Donahue, Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo > Polito, Gustavo Santos, Henrik Johansen, Henrik Nergaard, Hilaire > Fernandes, Holger Hans, Jan Kurs, Jan van de Sandt, Johan Fabry, Juraj > Kubelka, K. K. Subramaniam, Ken Causey, Kris Gybels, Lionel Akue, Luc > Fabresse, Lucas Godoy, Marcus Denker, Mariano Martinez Peck, Marion > Noirbent, Martin Dias, Max Leske, Maxime Roelandt, Merwan Ouddane, Matteo > Bellotto, Miguel Campusano, Milton Mamani, Myroslava Romaniuk, Nicolai > Hess, Nicolas Cellier, Nicolas Passerini, Norbert Hartl, Offray Luna, Pablo > Tesone, Paul De Bruicker, Pavel Krivanek, Peter Uhnak, Philippe Back, Roger > Stebler, Ronie Salgado, Sean DeNigris, Serge Stinckwich, Skip Lentz, Sophie > Kaleba, Stefan Reichhart, Stephan Eggermont, Stephane Ducasse, Sven Van > Caekenberghe, Thibault Arloing, Thibault Arloing, Thibault Raffaillac, > Thierry Goubier, Thomas Heniart, Tommaso Dal Sasso, Torsten Bergmann, Tudor > Girba, Udo Schneider, Valentin Ryckewaert, Vincent Blondeau, Werner > Kassens, Yuriy Tymchuk > > (If you contributed with Pharo 6.0 development in any way and we missed > your name, please send us a mail and we will add you). > > Enjoy! > > The Pharo Team > > Try Pharo: http://pharo.org/download > Learn Pharo: http://pharo.org/documentation > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > >

June 6, 2017

Re: [Pharo-dev] OSProcess behaves wrong on Mac OS Sierra - Pharo 6

by Eliot Miranda

Hi Cyrille, > On Jun 6, 2017, at 7:21 AM, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: > > Hello, > > I am running a Pharo 6 image (Latest update: #60498) on a mac sierra machine (10.12.1). > I loaded version 4.6.4 of OSProcess (which is the one loaded with stable version of CommandShell project). > > I expected these methods to tell that I am running on a "mac unix" system: > > OSProcess class >> isNonUnixMac > OSProcess class >> isUnix > OSProcess class >> isUnixMac > > But they all answer that i am running on a "non unix mac" system. > > Problem seems to come from the following check to decide if a mac platform is "unix mac" : > > (self platformName = 'Mac OS') and: [numericOsVersion >= 1000] > > In my case, numericOsVersion is '10.12.1' asInteger, which gives 10 => "non unix" I broke this last week by changing getSystemAttribute: 1002 to answer e.g. '10.12.1' instead of '1095' which the old code (Mac call Gestalt IIRC) always returned. I fixed it today by changing getSystemAttribute: 1002 to answer e.g. '1012.1' instead of '10.12.1', so '1012.1' asNumber >= 1000 once again. Apologies for the inconvenience. The next VMs which are built automatically should be fixed. > -- > Cyrille Delaunay _,,,^..^,,,_ (phone)

June 6, 2017

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

by Henrik Nergaard

A simple way of having a "onlyMe" type is to throw another type of error and wrap the code execution with an #on:do: catching and resuming Halt. Here is an example: ----------------------------------------------- | cls | cls := Halt subclass: #CustomHalt. cls class compile: 'onlyCustomHaltDuring: aBlock aBlock on: Halt - CustomHalt do: [ :ex | ex resume ] '. cls class compile: 'example self onlyCustomHaltDuring: [ 0 crLog. Halt now. 1 crLog. Halt once. 2 crLog. CustomHalt now. 3 crLog. ] '. cls example ----------------------------------------------- Best regards, Henrik ________________________________ Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Stephane Ducasse <stepharo.self(a)gmail.com> Sendt: 5. juni 2017 20:57:43 Til: Pharo Development List Emne: Re: [Pharo-dev] New and richer halt messages 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 6, 2017

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

by Stephan Eggermont

On 02/06/17 23:10, Nicolas Cellier 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. Thanks, I appreciate it. > 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 :( I'll take a look at work tomorrow. Stephan

June 6, 2017

Re: [Pharo-dev] [ Pillar ] Plumbing travis + github => pdf delivered to you

by Denis Kudriashov

Perfect! 2017-06-06 20:48 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Thanks Damien Pollet now we have a new pdf inside git hub each time you > commit. > > Here are two examples > - https://github.com/SquareBracketAssociates/Booklet-Smacc/releases > - https://github.com/SquareBracketAssociates/Booklet-Glorp/releases > > I'm going to do that for all the booklets and books :) > > Stef > >

June 6, 2017

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

by Nicolas Cellier

2017-06-05 13:40 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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 > > Hi Stef, Just test! Run the Pharo test on WIN64 VM in CI server, and report the differences with other OSes. Verify packaging of Win64 VM and include it in pharo distribution, not just linux and mac. No test, no progress > 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.html > >>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at > >>>>>> Nabble.com. > >>>>>> > >>>>> > >>>> > >>> > >> > > > >

June 6, 2017

Re: [Pharo-dev] [ Pillar ] Plumbing travis + github => pdf delivered to you

by Esteban A. Maringolo

Excellent! Thank you Damien! Esteban A. Maringolo 2017-06-06 15:48 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Thanks Damien Pollet now we have a new pdf inside git hub each time you commit. > > Here are two examples > - https://github.com/SquareBracketAssociates/Booklet-Smacc/releases > - https://github.com/SquareBracketAssociates/Booklet-Glorp/releases > > I'm going to do that for all the booklets and books :) > > Stef >

June 6, 2017

Re: [Pharo-dev] [Seaside] [ANN] Pharo 6.0 released!

by Denis Kudriashov

Congrats! What the status of Pharo 7? When integrations will be started? 2017-06-06 17:11 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Dear World, > > The time has come for Pharo 6.0! > > Pharo is a pure object-oriented programming language and a powerful > environment, focused on simplicity and immediate feedback. > > This is our most significant release yet. Here are some highlights: > > - Pharo is now provided in 64-bit version in Linux and OSX and brings even > better performance and stability (beware, 64bits version is a new > technology and a small amount of tests is still failing) > - A new code changes management system named Epicea for easier reviewing > and recovering of your code easily > - Integrated support for Git through an easy-to-use tool for repositories > and commits management named Iceberg (as a preview for Pharo 6, it will be > the default in Pharo 7) > - The unified foreign function interface (UnifiedFFI) for interfacing with > the outside world is significantly improved > - The PharoVM is now part of OpenSmalltalk initiative > - Introduction of object immutability, alternative bytecode sets and block > closures independent of outer context > - Pharo can now be bootstrapped from source code managed by Git > - Pharo modularity is improved > - Pharo is faster > - The Dark Theme was improved and set as default color theme of Pharo > > > These are just the more prominent highlights, but the details are just as > important. We have closed 1474 issues in Pharo 6.0 (a more complete > changelog can be found at https://github.com/pharo- > project/pharo-changelogs/blob/master/Pharo60ChangeLogs.md). > > While the technical improvements are significant (starting the transition > to 64bits is a remarkable achievement), still the most impressive fact is > that the new code that got in the main Pharo 6.0 image was contributed by > more than 80 people. > > Pharo is more than code. It is an exciting project involving energetic > people. We thank all the contributors of this release: > > Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, > Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard > Pieber, Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, > Dale Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, > Dirk Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan > Donahue, Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo > Polito, Gustavo Santos, Henrik Johansen, Henrik Nergaard, Hilaire > Fernandes, Holger Hans, Jan Kurs, Jan van de Sandt, Johan Fabry, Juraj > Kubelka, K. K. Subramaniam, Ken Causey, Kris Gybels, Lionel Akue, Luc > Fabresse, Lucas Godoy, Marcus Denker, Mariano Martinez Peck, Marion > Noirbent, Martin Dias, Max Leske, Maxime Roelandt, Merwan Ouddane, Matteo > Bellotto, Miguel Campusano, Milton Mamani, Myroslava Romaniuk, Nicolai > Hess, Nicolas Cellier, Nicolas Passerini, Norbert Hartl, Offray Luna, Pablo > Tesone, Paul De Bruicker, Pavel Krivanek, Peter Uhnak, Philippe Back, Roger > Stebler, Ronie Salgado, Sean DeNigris, Serge Stinckwich, Skip Lentz, Sophie > Kaleba, Stefan Reichhart, Stephan Eggermont, Stephane Ducasse, Sven Van > Caekenberghe, Thibault Arloing, Thibault Arloing, Thibault Raffaillac, > Thierry Goubier, Thomas Heniart, Tommaso Dal Sasso, Torsten Bergmann, Tudor > Girba, Udo Schneider, Valentin Ryckewaert, Vincent Blondeau, Werner > Kassens, Yuriy Tymchuk > > (If you contributed with Pharo 6.0 development in any way and we missed > your name, please send us a mail and we will add you). > > Enjoy! > > The Pharo Team > > Try Pharo: http://pharo.org/download > Learn Pharo: http://pharo.org/documentation > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > >

June 6, 2017

Re: [Pharo-dev] OSProcess behaves wrong on Mac OS Sierra - Pharo 6

by Stephane Ducasse

thanks cyril Can you open a bug entry? On Tue, Jun 6, 2017 at 4:21 PM, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: > Hello, > > I am running a Pharo 6 image (Latest update: #60498) on a mac sierra machine > (10.12.1). > I loaded version 4.6.4 of OSProcess (which is the one loaded with stable > version of CommandShell project). > > I expected these methods to tell that I am running on a "mac unix" system: > > OSProcess class >> isNonUnixMac > OSProcess class >> isUnix > OSProcess class >> isUnixMac > > But they all answer that i am running on a "non unix mac" system. > > Problem seems to come from the following check to decide if a mac platform > is "unix mac" : > > (self platformName = 'Mac OS') and: [numericOsVersion >= 1000] > > In my case, numericOsVersion is '10.12.1' asInteger, which gives 10 => "non > unix" > > > > -- > Cyrille Delaunay

June 6, 2017

[ Pillar ] Plumbing travis + github => pdf delivered to you

by Stephane Ducasse

Thanks Damien Pollet now we have a new pdf inside git hub each time you commit. Here are two examples - https://github.com/SquareBracketAssociates/Booklet-Smacc/releases - https://github.com/SquareBracketAssociates/Booklet-Glorp/releases I'm going to do that for all the booklets and books :) Stef

June 6, 2017