please test download for Pharo 6.0
Locked
123
123
 
|
> as I wrote: Windows.
> So 32 bits, there is no 64 bits Pharo VM for Windows yet (maybe with Pharo 7). Sorry, I did not checked... > BTW: thanks for the tech-talk. Was to late to join but I liked the video and PDF. Thanks :-) Alexandre > > Thanks > T. > > Gesendet: Mittwoch, 31. Mai 2017 um 23:19 Uhr > Von: "Alexandre Bergel" <[hidden email]> > An: "Pharo Development List" <[hidden email]> > Betreff: Re: [Pharo-dev] please test download for Pharo 6.0 > > Have you tried Pharo 32 or 64 bits? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On May 31, 2017, at 1:56 PM, Torsten Bergmann <[hidden email][mailto:[hidden email]]> wrote: > > Hi Esteban, > > I tried on a fresh Windows setup. What I tried: > - general image browsing, mousing around > - loading OS-Windows and run all my test to verify UFFI works fine > - loading Roassal and checked some examples > - switching FreeType on and using some non-standard TTF fonts > - retrieved contents from an HTTPS location using ZnEasy to verify SSL connections > - loaded and verified some packages like Teapot, WebBrowser, ... > > > anything worked fine. > > But using the console version > > PharoConsole.exe Pharo60.image --list > > or other command line options did not work in a shell. It opens the UI always instead of printing > something to stdout. Dont know if command line/stdout is now already supposed to work in Pharo 6 > (if not the PharoConsole.exe would not make sense to include yet). > > Also when git is not installed and one creates a repository it gives an error due to directory > creation - but this is a specific issue for Iceberg. > > Thanks > T. > > > > > Gesendet: Mittwoch, 31. Mai 2017 um 16:18 Uhr > Von: "Esteban Lorenzano" <[hidden email][mailto:[hidden email]]> > An: "Pharo Development List" <[hidden email][mailto:[hidden email]]> > Betreff: [Pharo-dev] please test download for Pharo 6.0 > > Hello, > > we are getting ready for release. > please take a minute to review: > > http://pharo.org/STAGE.download[http://pharo.org/STAGE.download] > > (notice that zerconf download will not work because it is not yet moved… so #stable will download current stable version which is 5.0) > > cheers, > Esteban > |
Re: please test download for Pharo 6.0
|
|
In reply to this post by Torsten Bergmann
2017-05-31 23:54 GMT+02:00 Torsten Bergmann <[hidden email]>: Hi Alexandre, If you're adventurous, there is still https://bintray.com/opensmalltalk/vm/cog/201705310241#files Please report back. BTW: thanks for the tech-talk. Was to late to join but I liked the video and PDF. |
Re: please test download for Pharo 6.0
|
|
In reply to this post by EstebanLM
Hi Esteban,
On Wed, May 31, 2017 at 04:18:19PM +0200, Esteban Lorenzano wrote: > Hello, > > we are getting ready for release. > please take a minute to review: > > http://pharo.org/STAGE.download > > (notice that zerconf download will not work because it is not yet moved? so # > stable will download current stable version which is 5.0) Under Pharo7 it says the vm and sources are the same as "Pharo5". Should this be "Pharo 6"? On the Linux download page (http://pharo.org/STAGE.gnu-linux-installation): Ubuntu 12.04 is no longer supported, so I think we can remove that text. I'd also change the order, so that the newer OS versions are described first. If you can point me to the sources, I'm happy to make a pull request. It also looks like the itimer heartbeat is the default on linux, is that correct? Thanks! Alistair |
|
|
In reply to this post by EstebanLM
On Wednesday 31 May 2017 07:48 PM, Esteban Lorenzano wrote:
> Hello, > > we are getting ready for release. > please take a minute to review: > > http://pharo.org/STAGE.download Quick feedback on Pharo linux/x86_64 on Ubuntu 16.04/64b. I feel the Welcome page should point to HelpBrowser open instead of referring pharo.org because Pharo has a built-in help browser but not a WWW browser. The very first page should not lead to people to switch to a different app for help. Using help keeps people within the env and also leads them to learn how to create tutorials etc. In Welcome/changelog/second item, Epicea is misspelled as Epica. Same doc, suggest renaming section heading for consistency - s/Tools/Tools related/ and s/Network/Network related/ "Learn Pharo Smalltalk" and "Explore Pharo Environment" dups references to books. The former could be merged into the latter to drive home the point that language and env are tightly coupled. Also, merge "More Documentation" into "Getting help" and keep all web references together. I can send in a pull request for these changes if it helps. I tried to run: $ ./pharo-vm/pharo --nodisplay pharo-vm/shared/Pharo*.image eval 3+4 and got a usage error. The problem is that the pharo-vm/pharo script does not take into account option arguments and has other issues too. This works: $ ./pharo/bin/pharo --nodisplay pharo-vm/shared/Pharo*.image eval 3+4 HTH .. Subbu |
Re: please test download for Pharo 6.0
|
|
In reply to this post by Sven Van Caekenberghe-2
> On 31 May 2017, at 17:11, Sven Van Caekenberghe <[hidden email]> wrote: > > OK, I quickly tested the Mac 32 and 64 bit versions, installing some code, running unit tests, clicking around. Both are working perfectly. > > The Pharo Welcome window with the clickable coloured links and the tabs is particularly nice. > > The need to move to /Applications is just one thing, you also have to allow the app to actually run (with my settings, by right clicking on it, and giving permission; but even then it stops the first time and only runs the second time; no big deal for me but it might be confusing for others). > I am looking into signing… but as we did not have it for Pharo5, it should not hold up the release. The /Applications thing is related to signing, too. (the container, we should ship it with a signed .dmg). I will look into it for next week, but this is a bit independend of the release.. Marcus |
Re: please test download for Pharo 6.0
|
Administrator
|
In reply to this post by Sven Van Caekenberghe-2
Both above give the same result I described in http://forum.world.st/Launcher-and-Pharo-6-Errors-on-Mac-td4947652.html Namely: On image start, I get "PrimitiveFailed: primitive #createDirectory: in MacStore failed" for /private/var/folders/fv/8j408sn92bb59k5ggw8cd3kc0000gn/T/AppTranslocation/4EF86F92-66D6-4944-8B30-FBCD96118FCC/d/Pharo.app/Contents/Resources/pharo-local
Cheers,
Sean |
|
|
This is because you need to put the vm in /Applications (because is not signed)
We will fix that, but not just now :) > On 1 Jun 2017, at 18:29, Sean P. DeNigris <[hidden email]> wrote: > > Sven Van Caekenberghe-2 wrote >> http://files.pharo.org/platform/Pharo6.0-mac.zip >> http://files.pharo.org/platform/Pharo6.0-64-mac.zip > > Both above give the same result I described in > http://forum.world.st/Launcher-and-Pharo-6-Errors-on-Mac-td4947652.html > > Namely: On image start, I get "PrimitiveFailed: primitive #createDirectory: > in MacStore failed" for > /private/var/folders/fv/8j408sn92bb59k5ggw8cd3kc0000gn/T/AppTranslocation/4EF86F92-66D6-4944-8B30-FBCD96118FCC/d/Pharo.app/Contents/Resources/pharo-local > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/please-test-download-for-Pharo-6-0-tp4948720p4948852.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Re: please test download for Pharo 6.0
|
|
In reply to this post by Marcus Denker-4
>>> >> >> I am looking into signing… but as we did not have it for Pharo5, it should not hold up the release. >> >> The /Applications thing is related to signing, too. (the container, we should ship it with a signed .dmg). > > If possible please include the code in opensmalltalk/vm. There are good starting points: > > In {build.macos32x86,build.macos64x64}/newspeak.cog.spur/installer is code that builds the newspeak .dmg, but does not sign it. There's a Makefile. > > In {build.macos32x86,build.macos64x64}/common/Makefile.app is code to sign an .app bundle using codesign. The certificate to use is indicated via an environment variable as described in {build.macos32x86,build.macos64x64}/HowToBuild. > Ok, I will check… first I will do it as part of a additional build queue step, then see how to move it upstream to the VM build. Marcus |
Re: please test download for Pharo 6.0
|
|
In reply to this post by Peter Uhnak
> On 31 May 2017, at 17:46, Peter Uhnak <[hidden email]> wrote: > > The linux distro contains sources twice > 1) pharo6.0/shared/PharoV60.sources > 2) pharo6.0/bin/PharoV60.sources The macOS one-click version also contain PharoV60.source twice, in both: Contents/MacOS Contents/Resources |
Re: please test download for Pharo 6.0
|
|
In reply to this post by Nicolas Cellier
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. |
Re: please test download for Pharo 6.0
|
|
Hi Henrik, good catch!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 <[hidden email]>: The Windows 64 Pharo VM crashes when loading images*. |
Re: please test download for Pharo 6.0
|
|
Follow up: it's not enough... I'll have to understand why those PharoVM last 2 args are zero...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; 2017-06-02 17:15 GMT+02:00 Nicolas Cellier <[hidden email]>:
|
Re: please test download for Pharo 6.0
|
|
2017-06-02 22:21 GMT+02:00 Nicolas Cellier <[hidden email]>:
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!!!
|
Re: please test download for Pharo 6.0
|
|
2017-06-02 22:35 GMT+02:00 Nicolas Cellier <[hidden email]>:
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
|
Re: please test download for Pharo 6.0
|
|
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... Helping Pharo is not very rewarding :( 2017-06-02 22:50 GMT+02:00 Nicolas Cellier <[hidden email]>:
|
Re: please test download for Pharo 6.0
|
Administrator
|
In reply to this post by EstebanLM
That worked. Thanks!
Cheers,
Sean |
|
|
In reply to this post by Nicolas Cellier
On Sat, Jun 3, 2017 at 5:10 AM, Nicolas Cellier <[hidden email]> wrote:
My great thanks Nicolas. With this latest 64-bit progress, I've decided to retire my 32-bit Linux laptop and try Windows 10 (to play with the Linux subsystem). So I'll be in a position to test it out soon. cheers -ben
|
Re: please test download for Pharo 6.0
|
Administrator
|
In reply to this post by Sven Van Caekenberghe-2
Launcher seems to be missing them altogether. I notices my temps were decompiled in Pharo 6 images until I downloaded them separately and installed to MacOS...
Cheers,
Sean |
|
|
In reply to this post by K K Subbu
> On Wednesday 31 May 2017 07:48 PM, Esteban Lorenzano wrote:
> Hello, > > we are getting ready for release. > please take a minute to review: > > http://pharo.org/STAGE.download I uploaded some fixes for review after clearing them through testrunner. But Validation builds failed because of network timeouts, e.g: [ ConnectionTimedOut signal: 'Cannot connect to ', (NetNameResolver stringFromAddress: hostAddress) , ':', port asString ] in Socket as in https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator-simple/15867/artifact/report.html Is this a temporary issue? When should I retry for review? Thanks and Regards .. Subbu |
Re: please test download for Pharo 6.0
|
|
In reply to this post by Nicolas Cellier
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 <[hidden email]> 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 > <[hidden email]>: >> >> >> >> 2017-06-02 22:35 GMT+02:00 Nicolas Cellier >> <[hidden email]>: >>> >>> >>> >>> 2017-06-02 22:21 GMT+02:00 Nicolas Cellier >>> <[hidden email]>: >>>> >>>> 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 >>>> <[hidden email]>: >>>>> >>>>> 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 >>>>> <[hidden email]>: >>>>>> >>>>>> 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. >>>>>> >>>>> >>>> >>> >> > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |