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). Great work, thank you all ! Sven

On 31 May 2017, at 16:34, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 31 May 2017, at 16:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 31 May 2017, at 16:18, Esteban Lorenzano <estebanlm@gmail.com> 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)

cheers, Esteban

The Mac links are like

http://files.pharo.org/platform/Pharo6.0-mac.zip http://files.pharo.org/platform/Pharo6.0-64-mac.zip

while the Linux ones are like

http://pharo.org/STAGE.gnu-linux-installation http://pharo.org/STAGE.gnu-linux-installation-64

on that page, are you sure this is correct ?

yes because they point to another page, not to a file (it has been always like that, btw)

Esteban

...

Hi Marcus,

On Jun 1, 2017, at 2:36 AM, Marcus Denker <marcus.denker@inria.fr> wrote:

...

On 31 May 2017, at 17:11, Sven Van Caekenberghe <sven@stfx.eu> 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).

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.

I will look into it for next week, but this is a bit independend of the release..

Marcus

HTH Eliot

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.h... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

EstebanLM wrote

This is because you need to put the vm in /Applications (because is not signed)

That worked. Thanks! ----- Cheers, Sean -- View this message in context: http://forum.world.st/please-test-download-for-Pharo-6-0-tp4948720p4949103.h... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On 31 May 2017, at 16:40, Alexandre Bergel <alexandre.bergel@me.com> wrote:

Hi Esteban,

Thanks for pushing this!

I tried the script: /tmp> curl get.pharo.org/64 <http://get.pharo.org/64> | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 232 100 232 0 0 538 0 --:--:-- --:--:-- --:--:-- 539 bash: line 1: syntax error near unexpected token `newline' bash: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">' /tmp>

I got an error

I said zeroconf will not work yet (is not yet moved) ;) Esteban

Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

...

On May 31, 2017, at 10:18 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:

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

Hi, same as Alexandre here: curl get.pharo.org/64 | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 232 100 232 0 0 425 0 --:--:-- --:--:-- --:--:-- 424 bash: line 1: syntax error near unexpected token `newline' bash: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">' However, no problem with wget -O- get.pharo.org/64 | bash, nor 32 bits. I'm on linux and followed command-line instructions in http://pharo.org/download. Martín On Wed, May 31, 2017 at 11:51 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 31 May 2017, at 16:40, Alexandre Bergel <alexandre.bergel@me.com> wrote:

Hi Esteban,

Thanks for pushing this!

I tried the script: /tmp> curl get.pharo.org/64 | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 232 100 232 0 0 538 0 --:--:-- --:--:-- --:--:-- 539 bash: line 1: syntax error near unexpected token `newline' bash: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">' /tmp>

I got an error

I said zeroconf will not work yet (is not yet moved) ;)

Esteban

Alexandre

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On May 31, 2017, at 10:18 AM, Esteban Lorenzano <estebanlm@gmail.com> 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)

cheers, Esteban

On 31 May 2017, at 17:46, Peter Uhnak <i.uhnak@gmail.com> wrote:

I find the Windows distribution a bit chaotic as all the files (vm, vm libs, image, sources) are in the same folder. Maybe there were issues with using shortcuts? Because then launching the image will also create pharo-local in the folder (and any other file that image writes to imageDirectory), so it could be more chaos for a new user.

yes, it has been like that since some time and we need to change it… but not now for release :)

The linux distro contains sources twice 1) pharo6.0/shared/PharoV60.sources 2) pharo6.0/bin/PharoV60.sources

yeah, that’s also a problem from one-click days… maybe I can fix that/ Esteban

Peter

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 <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

Hi Volkert, Roassal does not work on Pharo 64-bits. The issue here is Athens. When Pharo 6 will be released, we will evaluate the options to make Roassal run on 64 bits. The option I see, is using Pompeii, the backend by Ronie that uses directly OpenGL. This works well on Pharo 64 bits. Someone see another option? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On May 31, 2017, at 12:24 PM, volkert <volkert@nivoba.de> wrote:

Downloaded Linux 64 Bit. Installed Roassal. Run Examples. VM crashed :-( BW, Volkert

Am 31.05.2017 um 17:59 schrieb Esteban Lorenzano:

...

...

On 31 May 2017, at 17:46, Peter Uhnak <i.uhnak@gmail.com> <mailto:i.uhnak@gmail.com> wrote:

I find the Windows distribution a bit chaotic as all the files (vm, vm libs, image, sources) are in the same folder. Maybe there were issues with using shortcuts? Because then launching the image will also create pharo-local in the folder (and any other file that image writes to imageDirectory), so it could be more chaos for a new user. yes, it has been like that since some time and we need to change it… but not now for release :)

...

The linux distro contains sources twice 1) pharo6.0/shared/PharoV60.sources 2) pharo6.0/bin/PharoV60.sources yeah, that’s also a problem from one-click days… maybe I can fix that/

Esteban

...

Peter

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 <http://pharo.org/STAGE.download> <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

I downloaded Windows (32 bit only). Played around and had no visible issues so I ran the tests and got some errors and failures (I don't know whether they're expected): 14425 run, 14342 passes, 29 skipped, 57 expected failures, 17 failures, 9 errors, 0 unexpected passes Failures: MCSnapshotBrowserTest>>#testNoSelection MCWorkingCopyTest>>#testSimpleMerge MCStWriterTest>>#testInitializerDefinition MetacelloRepositorySqueakCommonTestCase>>#testDirectoryRepository MetacelloRepositorySqueakCommonTestCase>>#testAsRepositorySpecFor MCSnapshotTest>>#testCreation MCWorkingCopyTest>>#testOptimizedLoad MCSnapshotBrowserTest>>#testClassSelected ReleaseTest>>#testMethodsWithUnboundGlobals MCSnapshotBrowserTest>>#testCategorySelected MCWorkingCopyTest>>#testRepeatedMerge MCSnapshotBrowserTest>>#testClassSideClassSelected MCPatchTest>>#testPatchContents ZnClientTests>>#testIfFailNotFound MCWorkingCopyTest>>#testSelectiveBackport MCWorkingCopyTest>>#testSnapshotAndLoad GLMRubricTextMorphicTest>>#testPastingUpdatesTextPort Errors: MCPackageTest>>#testUnloadWithAdditionalTracking MCSnapshotBrowserTest>>#testMethodIsCleared MCSnapshotBrowserTest>>#testMethodSelected MCSnapshotBrowserTest>>#testProtocolIsCleared MCSnapshotBrowserTest>>#testProtocolSelected MCStWriterTest>>#testClassMethodDefinition MCStWriterTest>>#testMethodDefinition MCWorkingCopyTest>>#testBackport MCFileInTest>>#testStWriter Best regards! Esteban A. Maringolo 2017-05-31 13:39 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:

But I tested Roassal (and Athens) in 64bits and they were working. What changed?

On 31 May 2017, at 18:33, Alexandre Bergel <alexandre.bergel@me.com> wrote:

Hi Volkert,

Roassal does not work on Pharo 64-bits. The issue here is Athens.

When Pharo 6 will be released, we will evaluate the options to make Roassal run on 64 bits. The option I see, is using Pompeii, the backend by Ronie that uses directly OpenGL. This works well on Pharo 64 bits.

Someone see another option?

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On May 31, 2017, at 12:24 PM, volkert <volkert@nivoba.de> wrote:

Downloaded Linux 64 Bit. Installed Roassal. Run Examples. VM crashed :-(

BW, Volkert

Am 31.05.2017 um 17:59 schrieb Esteban Lorenzano:

On 31 May 2017, at 17:46, Peter Uhnak <i.uhnak@gmail.com> wrote:

I find the Windows distribution a bit chaotic as all the files (vm, vm libs, image, sources) are in the same folder. Maybe there were issues with using shortcuts? Because then launching the image will also create pharo-local in the folder (and any other file that image writes to imageDirectory), so it could be more chaos for a new user.

yes, it has been like that since some time and we need to change it… but not now for release :)

The linux distro contains sources twice 1) pharo6.0/shared/PharoV60.sources 2) pharo6.0/bin/PharoV60.sources

yeah, that’s also a problem from one-click days… maybe I can fix that/

Esteban

Peter

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 <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

I was never aware that Athens was working on 64 bits. Yes, it is crashing... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On May 31, 2017, at 3:07 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 31 May 2017, at 18:39, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:

But I tested Roassal (and Athens) in 64bits and they were working. What changed?

I see that it is crashing. But it was working, I swear it :)

So I need to dig what changed to make it crash now :(

Esteban

...

On 31 May 2017, at 18:33, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote:

...

Hi Volkert,

Roassal does not work on Pharo 64-bits. The issue here is Athens.

When Pharo 6 will be released, we will evaluate the options to make Roassal run on 64 bits. The option I see, is using Pompeii, the backend by Ronie that uses directly OpenGL. This works well on Pharo 64 bits.

Someone see another option?

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

...

On May 31, 2017, at 12:24 PM, volkert <volkert@nivoba.de <mailto:volkert@nivoba.de>> wrote:

Downloaded Linux 64 Bit. Installed Roassal. Run Examples. VM crashed :-( BW, Volkert

Am 31.05.2017 um 17:59 schrieb Esteban Lorenzano:

...

...

On 31 May 2017, at 17:46, Peter Uhnak <i.uhnak@gmail.com> <mailto:i.uhnak@gmail.com> wrote:

I find the Windows distribution a bit chaotic as all the files (vm, vm libs, image, sources) are in the same folder. Maybe there were issues with using shortcuts? Because then launching the image will also create pharo-local in the folder (and any other file that image writes to imageDirectory), so it could be more chaos for a new user. yes, it has been like that since some time and we need to change it… but not now for release :)

...

The linux distro contains sources twice 1) pharo6.0/shared/PharoV60.sources 2) pharo6.0/bin/PharoV60.sources yeah, that’s also a problem from one-click days… maybe I can fix that/

Esteban

...

Peter

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 <http://pharo.org/STAGE.download> <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

On 31 May 2017, at 17:46, Peter Uhnak <i.uhnak@gmail.com> 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

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 <astares@gmx.de> 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" <estebanlm@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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

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" <alexandre.bergel@me.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 <astares@gmx.de[mailto:astares@gmx.de]> 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" <estebanlm@gmail.com[mailto:estebanlm@gmail.com]> An: "Pharo Development List" <pharo-dev@lists.pharo.org[mailto:pharo-dev@lists.pharo.org]> 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

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.h... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.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... 2017-06-02 17:15 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

Hi Henrik, good catch!

platforms/Cross/plugins/FilePlugin/FilePlugin.h says:

sqInt dir_EntryLookup(char *pathString, sqInt pathStringLength, char *nameString, sqInt nameStringLength, /* outputs: */ char *name, sqInt *nameLength, sqInt *creationDate, sqInt *modificationDate, sqInt *isDirectory, squeakFileOffsetType *sizeIfFile, sqInt *posixPermissions, sqInt *isSymlink);

platforms/win32/vm/sqWin32Directory.c says

int dir_EntryLookup(char *pathString, int pathLength, char* nameString, int nameStringLength, /* outputs: */ char *name, int *nameLength, int *creationDate, int *modificationDate, int *isDirectory, squeakFileOffsetType *sizeIfFile, sqInt *posixPermissions, sqInt *isSymlink)

int* and sqInt* are not going to be a good match on 64 bits... But I don't know how the WIN64 Squeak VM could possibly work, because prototypes are equally wrong (just with two parameters less). And the two paramters added by Pharo are correct!!!

Maybe there is another bug, I will modify the easy part and commit ASAP.

In the long term, we shall include the .h containing declarations into the .c implementing the functions and use more agressive -C99 flags forcing the prototypes to be defined.

2017-06-02 14:48 GMT+02:00 Henrik Sperre Johansen < henrik.s.johansen@veloxit.no>:

...

The Windows 64 Pharo VM crashes when loading images*. The Windows 64 Squeak VM runs Pharo images just fine, but lacks some plugins (FT2 from Pharo build works, and can be copied over, SqueakSSL is MiA). Great work!

Cheers, Henry

*Crash occurs when loading sources; Stack backtrace: [0000000000495063] dir_EntryLookup + 0x83 in Pharo.exe

Smalltalk stack dump: 0xb4f568 I WindowsStore(DiskStore)>basicEntryAt: 0x9a711c0: a(n) WindowsStore 0xb4f5b8 I WindowsStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x9a711c0: a(n) WindowsStore 0xb4f610 I WindowsStore(FileSystemStore)>exists: 0x9a711c0: a(n) WindowsStore 0xb4f658 I FileSystem>exists: 0x9a711d8: a(n) FileSystem 0xb4f6a0 I FileReference>exists 0x9a77400: a(n) FileReference 0xb4f6e0 I FileLocator(AbstractFileReference)>exists 0x9a76678: a(n) FileLocator 0xb4f730 M [] in PharoFilesOpener>openSources:forImage: 0xaca7168: a(n) PharoFilesOpener

so I assume it's related to additional functionality in <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> in the Pharo build.

-- View this message in context: http://forum.world.st/please-t est-download-for-Pharo-6-0-tp4948720p4948965.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

2017-06-02 22:35 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

2017-06-02 22:21 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:

...

Follow up: it's not enough...

Program received signal SIGSEGV, Segmentation fault. 0x000000000051cfc8 in dir_EntryLookup (pathString=0xce7edb0 "X:\\Smalltalk\\opensmalltalk-vm\\build.win64x64\\pharo.cog.spur\\builddbg\\vm", pathLength=71, nameString=0xce81868 "PharoV60.sources", nameStringLength=16, name=0xfe5aa0 "", nameLength=0xfe5a98, creationDate=0xfe5ba8, modificationDate=0xfe5a88, isDirectory=0xfe5ba0, sizeIfFile=0xfe5a90, posixPermissions=0x0, isSymlink=0x0) at ../../platforms/win32/vm/sqWin32Directory.c:397 397 *posixPermissions = 0;

I'll have to understand why those PharoVM last 2 args are zero...

It looks like FilePlugin did not have the -DPharoVM because the backtrace point at the wrong #ifdef branch:

(gdb) bt #0 dir_EntryLookup (pathString=0xc27edb0 "X:\\Smalltalk\\opensmalltalk- vm\\build.win64x64\\pharo.cog.spur\\builddbg\\vm", pathLength=71, nameString=0xc281868 "PharoV60.sources", nameStringLength=16, name=0xfe5aa0 "ryEntry", nameLength=0xfe5a98, creationDate=0xfe5ba8, modificationDate=0xfe5a88, isDirectory=0xfe5ba0, sizeIfFile=0xfe5a90, posixPermissions=0x0, isSymlink=0x0) at ../../platforms/win32/vm/sqWin32Directory.c:379 #1 0x00000000005835a6 in primitiveDirectoryEntry () at ../../src/plugins/FilePlugin/FilePlugin.c:654 #2 0x0000000000442d5e in primitiveExternalCall () at ../../spur64src/vm/gcc3x-cointerp.c:76521 #3 0x000000000040d8ba in interpret () at ../../spur64src/vm/gcc3x- cointerp.c:6373 #4 0x0000000000429046 in enterSmalltalkExecutiveImplementation () at ../../spur64src/vm/gcc3x-cointerp.c:18181 #5 0x00000000004018a8 in interpret () at ../../spur64src/vm/gcc3x- cointerp.c:2678 #6 0x00000000005279a8 in sqMain (argc=1, argv=0x11850f0) at ../../platforms/win32/vm/sqWin32Main.c:1572 #7 0x0000000000527e95 in WinMain (hInst=0x400000, hPrevInstance=0x0, lpCmdLine=0x11f3f32 "", nCmdShow=10) at ../../platforms/win32/vm/ sqWin32Main.c:1678 #8 0x00000000004013ed in __tmainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-5.0.2-1/crt/crtexe.c:334 #9 0x00000000004014fb in WinMainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-5.0.2-1/crt/crtexe.c:184

(gdb) up #1 0x00000000005835a6 in primitiveDirectoryEntry () at ../../src/plugins/FilePlugin/FilePlugin.c:654 654 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize,

(gdb) list 646,658 646 647 # if PharoVM 648 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize,

649 entryName, &entryNameSize, &createDate, 650

&modifiedDate, &dirFlag, &fileSize, 651

&posixPermissions, &symlinkFlag); 652 653 # else /* PharoVM */ 654 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize, 655 entryName, &entryNameSize, &createDate, 656 &modifiedDate, &dirFlag, &fileSize); 657 658 # endif /* PharoVM */

The backtrace should never be at 654!!!

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

...

2017-06-02 17:15 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:

...

Hi Henrik, good catch!

platforms/Cross/plugins/FilePlugin/FilePlugin.h says:

sqInt dir_EntryLookup(char *pathString, sqInt pathStringLength, char *nameString, sqInt nameStringLength, /* outputs: */ char *name, sqInt *nameLength, sqInt *creationDate, sqInt *modificationDate, sqInt *isDirectory, squeakFileOffsetType *sizeIfFile, sqInt *posixPermissions, sqInt *isSymlink);

platforms/win32/vm/sqWin32Directory.c says

int dir_EntryLookup(char *pathString, int pathLength, char* nameString, int nameStringLength, /* outputs: */ char *name, int *nameLength, int *creationDate, int *modificationDate, int *isDirectory, squeakFileOffsetType *sizeIfFile, sqInt *posixPermissions, sqInt *isSymlink)

int* and sqInt* are not going to be a good match on 64 bits... But I don't know how the WIN64 Squeak VM could possibly work, because prototypes are equally wrong (just with two parameters less). And the two paramters added by Pharo are correct!!!

Maybe there is another bug, I will modify the easy part and commit ASAP.

In the long term, we shall include the .h containing declarations into the .c implementing the functions and use more agressive -C99 flags forcing the prototypes to be defined.

2017-06-02 14:48 GMT+02:00 Henrik Sperre Johansen < henrik.s.johansen@veloxit.no>:

...

The Windows 64 Pharo VM crashes when loading images*. The Windows 64 Squeak VM runs Pharo images just fine, but lacks some plugins (FT2 from Pharo build works, and can be copied over, SqueakSSL is MiA). Great work!

Cheers, Henry

*Crash occurs when loading sources; Stack backtrace: [0000000000495063] dir_EntryLookup + 0x83 in Pharo.exe

Smalltalk stack dump: 0xb4f568 I WindowsStore(DiskStore)>basicEntryAt: 0x9a711c0: a(n) WindowsStore 0xb4f5b8 I WindowsStore(DiskStore)>nodeAt:ifPresent:ifAbsent: 0x9a711c0: a(n) WindowsStore 0xb4f610 I WindowsStore(FileSystemStore)>exists: 0x9a711c0: a(n) WindowsStore 0xb4f658 I FileSystem>exists: 0x9a711d8: a(n) FileSystem 0xb4f6a0 I FileReference>exists 0x9a77400: a(n) FileReference 0xb4f6e0 I FileLocator(AbstractFileReference)>exists 0x9a76678: a(n) FileLocator 0xb4f730 M [] in PharoFilesOpener>openSources:forImage: 0xaca7168: a(n) PharoFilesOpener

so I assume it's related to additional functionality in <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> in the Pharo build.

-- View this message in context: http://forum.world.st/please-t est-download-for-Pharo-6-0-tp4948720p4948965.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On Sat, Jun 3, 2017 at 5:10 AM, Nicolas Cellier < nicolas.cellier.aka.nice@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 :(

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

2017-06-02 22:50 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:

...

2017-06-02 22:35 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:

...

2017-06-02 22:21 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

...

Follow up: it's not enough...

Program received signal SIGSEGV, Segmentation fault. 0x000000000051cfc8 in dir_EntryLookup (pathString=0xce7edb0 "X:\\Smalltalk\\opensmalltalk-vm\\build.win64x64\\pharo.cog.spur\\builddbg\\vm", pathLength=71, nameString=0xce81868 "PharoV60.sources", nameStringLength=16, name=0xfe5aa0 "", nameLength=0xfe5a98, creationDate=0xfe5ba8, modificationDate=0xfe5a88, isDirectory=0xfe5ba0, sizeIfFile=0xfe5a90, posixPermissions=0x0, isSymlink=0x0) at ../../platforms/win32/vm/sqWin32Directory.c:397 397 *posixPermissions = 0;

I'll have to understand why those PharoVM last 2 args are zero...

It looks like FilePlugin did not have the -DPharoVM because the backtrace point at the wrong #ifdef branch:

(gdb) bt #0 dir_EntryLookup (pathString=0xc27edb0 "X:\\Smalltalk\\opensmalltalk- vm\\build.win64x64\\pharo.cog.spur\\builddbg\\vm", pathLength=71, nameString=0xc281868 "PharoV60.sources", nameStringLength=16, name=0xfe5aa0 "ryEntry", nameLength=0xfe5a98, creationDate=0xfe5ba8, modificationDate=0xfe5a88, isDirectory=0xfe5ba0, sizeIfFile=0xfe5a90, posixPermissions=0x0, isSymlink=0x0) at ../../platforms/win32/vm/sqWin32Directory.c:379 #1 0x00000000005835a6 in primitiveDirectoryEntry () at ../../src/plugins/FilePlugin/FilePlugin.c:654 #2 0x0000000000442d5e in primitiveExternalCall () at ../../spur64src/vm/gcc3x-cointerp.c:76521 #3 0x000000000040d8ba in interpret () at ../../spur64src/vm/gcc3x-coint erp.c:6373 #4 0x0000000000429046 in enterSmalltalkExecutiveImplementation () at ../../spur64src/vm/gcc3x-cointerp.c:18181 #5 0x00000000004018a8 in interpret () at ../../spur64src/vm/gcc3x-coint erp.c:2678 #6 0x00000000005279a8 in sqMain (argc=1, argv=0x11850f0) at ../../platforms/win32/vm/sqWin32Main.c:1572 #7 0x0000000000527e95 in WinMain (hInst=0x400000, hPrevInstance=0x0, lpCmdLine=0x11f3f32 "", nCmdShow=10) at ../../platforms/win32/vm/sqWin 32Main.c:1678 #8 0x00000000004013ed in __tmainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-5.0.2-1/crt/crtexe.c:334 #9 0x00000000004014fb in WinMainCRTStartup () at /usr/src/debug/mingw64-x86_64-runtime-5.0.2-1/crt/crtexe.c:184

(gdb) up #1 0x00000000005835a6 in primitiveDirectoryEntry () at ../../src/plugins/FilePlugin/FilePlugin.c:654 654 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize,

(gdb) list 646,658 646 647 # if PharoVM 648 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize,

649 entryName, &entryNameSize, &createDate, 650

&modifiedDate, &dirFlag, &fileSize, 651

&posixPermissions, &symlinkFlag); 652 653 # else /* PharoVM */ 654 status = dir_EntryLookup(pathNameIndex, pathNameSize, reqNameIndex, reqNameSize, 655 entryName, &entryNameSize, &createDate, 656 &modifiedDate, &dirFlag, &fileSize); 657 658 # endif /* PharoVM */

The backtrace should never be at 654!!!

The LOGD shows that $COGDEFS was not used in plugin compilation, so -DPharoVM=1 is missing from the clang command line

rm -f builddbg/vm/FilePlugin.ignore make -w BUILD=builddbg \ -f /cygdrive/X/Smalltalk/opensmalltalk-vm/build.win64x64/common/Makefile.plugin \ CONFIGURATION=debug TOOLPREFIX=x86_64-w64-mingw32- \ THIRDPARTYOUTDIR=/cygdrive/X/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/x86_64 \ PLATDIR=../../platforms PLUGINSRCDIR=../../src VMSRCDIR=../../spur64src/vm \ LIBNAME=FilePlugin COGDEFS="-DPharoVM=1 -DIMMUTABILITY=1 -DCOGMTVM=0 -DDEBUGVM=1" XDEFS=-DSQUEAK_BUILTIN_PLUGIN \ builddbg/vm/FilePlugin.lib make[2] : on entre dans le répertoire « /cygdrive/X/Smalltalk/opensm alltalk-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@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@veloxit.no>:

...

The Windows 64 Pharo VM crashes when loading images*. The Windows 64 Squeak VM runs Pharo images just fine, but lacks some plugins (FT2 from Pharo build works, and can be copied over, SqueakSSL is MiA). Great work!

Cheers, Henry

*Crash occurs when loading sources; Stack backtrace: [0000000000495063] dir_EntryLookup + 0x83 in Pharo.exe

Smalltalk stack dump: 0xb4f568 I WindowsStore(DiskStore)>basicEntryAt: 0x9a711c0: a(n) WindowsStore 0xb4f5b8 I WindowsStore(DiskStore)>nodeAt :ifPresent:ifAbsent: 0x9a711c0: a(n) WindowsStore 0xb4f610 I WindowsStore(FileSystemStore)>exists: 0x9a711c0: a(n) WindowsStore 0xb4f658 I FileSystem>exists: 0x9a711d8: a(n) FileSystem 0xb4f6a0 I FileReference>exists 0x9a77400: a(n) FileReference 0xb4f6e0 I FileLocator(AbstractFileReference)>exists 0x9a76678: a(n) FileLocator 0xb4f730 M [] in PharoFilesOpener>openSources:forImage: 0xaca7168: a(n) PharoFilesOpener

so I assume it's related to additional functionality in <primitive: 'primitiveDirectoryEntry' module: 'FilePlugin'> in the Pharo build.

-- View this message in context: http://forum.world.st/please-t est-download-for-Pharo-6-0-tp4948720p4948965.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

2017-06-05 13:40 GMT+02:00 Stephane Ducasse <stepharo.self@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@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@gmail.com>:

...

2017-06-02 22:35 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

...

2017-06-02 22:21 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@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@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@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.

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/artifac... Is this a temporary issue? When should I retry for review? Thanks and Regards .. Subbu