March 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New Cog VMs available

by ClÃ©ment Bera

2016-03-01 13:15 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi Eliot, > > Since I cannot compile the VM on my own, I tried yours (compilation error > as I mentioned in one of my previous emails). I tried yours, but I am not > sure which VM to try. I downloaded CogPharoSpur64.app-16.08.3632.tar but I > cannot open an image. Any reason why? > Hi Alex, I am pretty sure Eliot will answer when he gets up, I answer now so you have a quicker answer. Let me explain what the file name CogPharoSpur64.app-16.08.3632.tar means: 'Cog' => VM with the jit (*not* interpreter only VM or Sista VM) 'Pharo' => for Pharo (*not* for Newspeak or Squeak) 'Spur' => Spur memory manager (*not* the SqueakV3 memory manager) '64' => 64 bits VM (*not* a 32 bits VM) '.app -16.08.3632.tar' => suffix and version number So my guess is that you are trying to run a 32 bits image with a 64 bits VM. 64 bits VM run only 64 bits images such as the ones available here <http://www.mirandabanda.org/files/Cog/SpurImages/>. Assuming you want to open a 32 bits image, you can try: CogPharoSpur.app-16.08.3632.tgz (It does not have '64' in its name so it's 32 bits) Now you might miss some libraries that might not be present in this build. Tell us if you can successfully run Roassal. If one wants to know more about the internal names, one can read the HowToBuild file from the build repository which explains that very well. Clement > Alexandre > > > > On Feb 25, 2016, at 9:46 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > > > On Thu, Feb 25, 2016 at 9:29 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3632. > > > > These include 64-bit VMs whose Smalltalk execution and FFI are > functional. However, their SocketPlugin is more than somewhat broken. > Executing the SocketPlugin tests results in a hard lockup, at least on Mac > OS X. This is my next focus for 64-bits. > > > > It turns out that the 64-bit socket issues are Mac OS only. The linux > 64-bit VMs seem to be fine. The problems are to do with socket reuse > and/or broadcast (SO_REUSEADDR, SO_REUSEPORT & SO_BROADCAST). > > > > ------------------------------------------------------------------------ > > CogVM binaries as per VMMaker.oscog-eem.1700/r3632 > > > > General: > > Fix serious bug in jitted perform: primitive. Thanks to Stephane > Rollandin > > for finding and to Levente Uzoni for diagnosing the bug. If the argument > > count is one greater than the max number of register arguments (2 in > Spur, > > hence perform:with:with:) then the code to remove the receiver and > arguments > > from the stack neglects to remove the receiver and selector. > > > > Spur: > > Fix special selector arithmetic and comparison in the 64-bit Cogit. My > original > > code for genJumpNotSmallIntegersIn:andScratchReg: merely jumped if the > tags > > differed, hence not jumping if both arguments were SmallFloat64s (or both > > Characters). The new code requires an additional scratch register; > > hence add genJumpNotSmallIntegersIn:andScratch:scratch:. > > > > Fix bug in markAndTraceWeaklingsFrom:. Fields of weaklings may be > immediate > > so must use followOopField:ofObject: not followObjField:ofObject:. > > > > Fix > https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s… > . > > > > When weaklings (and when ephemerons) are scan-marked forwarders must be > coped > > with. > > > > 64-bit VMs: > > Fix a bug in printHex: for 64-bits (faulty arithmetic). > > > > ThreadedFFIPlugin: > > Fix the remaining 64-bit issues in the ThreadedFFIPlugin. The > X64SysVFFIPlugin > > now passes the test suite. Hence include the FFI plugin in 64-bit VMs. > > > > Make the SqueakFFIPrims plugin internal in the Mac pharo builds. > > > > Mac VMs: > > Have the Mac OS X build install Localizable.strings. Add versions for > > Newspeak, Pharo and Squeak. Rename the key to SelectImagePanePrompt. > > Temporarily disable the Serial plugin in the Pharo Mac VM until we can > track > > down the relevant platforms/iOS support for the Pharo extensions. > > > > Fix argument access on the iOS platform (Mac OS VMs). > > > > _,,,^..^,,,_ > > best, Eliot > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

March 1, 2016

Re: [Pharo-dev] error: cannot find OpenSSL or Libgcrypt when creating the VM on OSX

by Esteban Lorenzano

you have a dependency conflict. but most probably you do not need those plugins. Why do you want to build VM by your own? In any case, you can just remove those dependencies for you buildâ¦ after if you need it you can check what conflicts: buildMacOSX32 "Build with freetype, cairo, osprocess" PharoSpur32OSXConfig new generationType: generationType; addExternalPlugins: #( FT2Plugin ); addInternalPlugins: #( UnixOSProcessPlugin ); addThirdpartyLibraries: #( 'cairo' âlibgit2â 'libssh2' 'libsdl2'); generateSources; generate. you can remove all the third party libraries section. Esteban > On 28 Feb 2016, at 22:32, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Here is the trace of the build.sh > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > checking for _FILE_OFFSET_BITS value needed for large files... no > checking for ld used by GCC... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld > checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no > checking for shared library run path origin... done > checking for libssl... no > checking for libgcrypt... no > configure: error: cannot find OpenSSL or Libgcrypt, > try --with-libssl-prefix=PATH or --with-libgcrypt-prefix=PATH > make[2]: *** [thirdParty/libssh2/src/libssh2-stamp/libssh2-configure] Error 1 > make[1]: *** [thirdParty/libssh2/CMakeFiles/libssh2.dir/all] Error 2 > make: *** [all] Error 2 > ~/Desktop/VM_TMP/pharo-vm/build> brew install OpenSSL > Warning: openssl-1.0.2a-1 already installed > ~/Desktop/VM_TMP/pharo-vm/build> brew install Libgcrypt > ==> Downloading ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.bz2 > Already downloaded: /Library/Caches/Homebrew/libgcrypt-1.6.3.tar.bz2 > ==> ./configure --disable-silent-rules --prefix=/usr/local/Cellar/libgcrypt/1.6. > ==> make > ==> make check > > Please report to http://bugs.gnupg.org > ====================================== > make[2]: *** [check-TESTS] Error 1 > make[1]: *** [check-am] Error 2 > make: *** [check-recursive] Error 1 > > READ THIS: https://git.io/brew-troubleshooting > > ~/Desktop/VM_TMP/pharo-vm/build> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > > > ~/Desktop/VM_TMP/pharo-vm/build> gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 > Apple LLVM version 7.0.2 (clang-700.1.81) > Target: x86_64-apple-darwin15.2.0 > Thread model: posix > ~/Desktop/VM_TMP/pharo-vm/build> > > > > No idea whatâs going onâ¦ > Help :-) > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

March 1, 2016

Re: [Pharo-dev] New Cog VMs available

by Esteban Lorenzano

> On 01 Mar 2016, at 13:43, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > I am a bit lost. Do we have a 64bits support? If yes, then why do we still have some 32 bits images? we don't > > Alexandre > >> On Mar 1, 2016, at 1:19 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 01-03-16 13:15, Alexandre Bergel wrote: >>> Since I cannot compile the VM on my own, I tried yours (compilation error as I mentioned in one of my previous emails). I tried yours, but I am not sure which VM to try. >>> I downloaded CogPharoSpur64.app-16.08.3632.tar but I cannot open an image. Any reason why? >> >> You need a 64 bit pharo image for that. >> >> Stephan >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

March 1, 2016

Re: [Pharo-dev] New Cog VMs available

by Alexandre Bergel

I am a bit lost. Do we have a 64bits support? If yes, then why do we still have some 32 bits images? Alexandre > On Mar 1, 2016, at 1:19 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 01-03-16 13:15, Alexandre Bergel wrote: >> Since I cannot compile the VM on my own, I tried yours (compilation error as I mentioned in one of my previous emails). I tried yours, but I am not sure which VM to try. > >I downloaded CogPharoSpur64.app-16.08.3632.tar but I cannot open an image. Any reason why? > > You need a 64 bit pharo image for that. > > Stephan > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 1, 2016

Re: [Pharo-dev] New Cog VMs available

by Stephan Eggermont

On 01-03-16 13:15, Alexandre Bergel wrote: > Since I cannot compile the VM on my own, I tried yours (compilation error as I mentioned in one of my previous emails). I tried yours, but I am not sure which VM to try. >I downloaded CogPharoSpur64.app-16.08.3632.tar but I cannot open an image. Any reason why? You need a 64 bit pharo image for that. Stephan

March 1, 2016

Re: [Pharo-dev] New Cog VMs available

by Alexandre Bergel

Hi Eliot, Since I cannot compile the VM on my own, I tried yours (compilation error as I mentioned in one of my previous emails). I tried yours, but I am not sure which VM to try. I downloaded CogPharoSpur64.app-16.08.3632.tar but I cannot open an image. Any reason why? Alexandre > On Feb 25, 2016, at 9:46 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Feb 25, 2016 at 9:29 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3632. > > These include 64-bit VMs whose Smalltalk execution and FFI are functional. However, their SocketPlugin is more than somewhat broken. Executing the SocketPlugin tests results in a hard lockup, at least on Mac OS X. This is my next focus for 64-bits. > > It turns out that the 64-bit socket issues are Mac OS only. The linux 64-bit VMs seem to be fine. The problems are to do with socket reuse and/or broadcast (SO_REUSEADDR, SO_REUSEPORT & SO_BROADCAST). > > ------------------------------------------------------------------------ > CogVM binaries as per VMMaker.oscog-eem.1700/r3632 > > General: > Fix serious bug in jitted perform: primitive. Thanks to Stephane Rollandin > for finding and to Levente Uzoni for diagnosing the bug. If the argument > count is one greater than the max number of register arguments (2 in Spur, > hence perform:with:with:) then the code to remove the receiver and arguments > from the stack neglects to remove the receiver and selector. > > Spur: > Fix special selector arithmetic and comparison in the 64-bit Cogit. My original > code for genJumpNotSmallIntegersIn:andScratchReg: merely jumped if the tags > differed, hence not jumping if both arguments were SmallFloat64s (or both > Characters). The new code requires an additional scratch register; > hence add genJumpNotSmallIntegersIn:andScratch:scratch:. > > Fix bug in markAndTraceWeaklingsFrom:. Fields of weaklings may be immediate > so must use followOopField:ofObject: not followObjField:ofObject:. > > Fix https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…. > > When weaklings (and when ephemerons) are scan-marked forwarders must be coped > with. > > 64-bit VMs: > Fix a bug in printHex: for 64-bits (faulty arithmetic). > > ThreadedFFIPlugin: > Fix the remaining 64-bit issues in the ThreadedFFIPlugin. The X64SysVFFIPlugin > now passes the test suite. Hence include the FFI plugin in 64-bit VMs. > > Make the SqueakFFIPrims plugin internal in the Mac pharo builds. > > Mac VMs: > Have the Mac OS X build install Localizable.strings. Add versions for > Newspeak, Pharo and Squeak. Rename the key to SelectImagePanePrompt. > Temporarily disable the Serial plugin in the Pharo Mac VM until we can track > down the relevant platforms/iOS support for the Pharo extensions. > > Fix argument access on the iOS platform (Mac OS VMs). > > _,,,^..^,,,_ > best, Eliot > > > > -- > _,,,^..^,,,_ > best, Eliot -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 1, 2016

Re: [Pharo-dev] Spotter changes broke CodePanel

by Stephan Eggermont

17729

March 1, 2016

Pharo Days 2016 Pre-Registration

by Sven Van Caekenberghe

Hi, The Pharo Days 2016 are at the end of this month. We are really looking forward to seeing as many of you as possible. The official registration is not yet online, but we need attendance numbers to plan ahead. We therefor ask you to complete the following Doodle if you plan on coming: http://doodle.com/poll/rsc86cqzxbgwr9tr There are 3 time slots: first day, social diner on the first evening, and second day. The schedule and list of talks is not yet final, but a draft is already available: http://pharodays2016.pharo.org At least one slot is not yet defined, feel free to make a suggestion for a topic you would find interesting. In the afternoon, you have the opportunity to do informal, demo style presentations of your work to small groups. Regards, The Pharo Board

March 1, 2016

Re: [Pharo-dev] Spotter changes broke CodePanel

by Stephan Eggermont

On 01-03-16 11:39, Stephan Eggermont wrote: > An easy way to reproduce is: > > GTSpotterMorph new > extent: (World width / 3.25 @ (World height / 2.25)) > asIntegerPoint; > spotterModel: GTSpotter new; > openCenteredInWorld Reverting GTSpotter>>initialize solves it. Stephan

March 1, 2016

Re: [Pharo-dev] removing of TestReviver

by stepharo

Go go go :) Le 26/2/16 16:50, Pavel Krivanek a Ã©crit : > Hi, > > TestReviver that is a part of HudsonBuildTools20 and it is a tool that > can process Fuel files generated by CI server. It is an UI tool > dependent on Spec so it adds some mess to headless images without GUI > that need to use HudsonBuildTools for SUnit reports. > I propose to remove it from the standard image and move it to a > separate SmalltalkHub project. It is not used directly in Pharo and > will be easy to load it from the Catalog by people who need such > functionality. > > Cheers, > -- Pavel

March 1, 2016