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

[pharo-project/pharo-core] 1d7edd: 60479

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 1d7edd94bbc490de294a068fca16e42829b8ca1c https://github.com/pharo-project/pharo-core/commit/1d7edd94bbc490de294a068f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-05-03 (Wed, 03 May 2017) Changed paths: M GT-Debugger.package/GTDebuggerInspector.class/instance/building/compose.st M GT-Inspector.package/GTSimpleMethodsBrowser.class/instance/building/sourceOf_for_in_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60478.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60479.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60478.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60479.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-OSEnvironments.package/OSEnvironment.class/instance/accessing/getEnv_.st A System-OSEnvironments.package/OSEnvironment.class/instance/accessing/unsetEnv_.st A System-OSEnvironments.package/OSEnvironment.class/instance/private/getEnvViaFFI_.st R System-OSEnvironments.package/OSEnvironment.class/instance/private/getEnv_.st R System-OSEnvironments.package/OSEnvironment.class/instance/private/unsetEnv_.st A System-OSEnvironments.package/Win32Environment.class/instance/accessing/unsetEnv_.st A System-OSEnvironments.package/Win32Environment.class/instance/private/getEnvViaFFI_.st R System-OSEnvironments.package/Win32Environment.class/instance/private/getEnv_.st R System-OSEnvironments.package/Win32Environment.class/instance/private/unsetEnv_.st Log Message: ----------- 60479 20011 OSEnvironment>>getEnv: needs to use a primitive https://pharo.fogbugz.com/f/cases/20011 19936 The code presentation in the Meta tab cuts the scrollbar at the bottom https://pharo.fogbugz.com/f/cases/19936 19897 Problem with presentations containing tabulators in the inspector from the debugger https://pharo.fogbugz.com/f/cases/19897 http://files.pharo.org/image/60/60479.zip

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Esteban Lorenzano

execute Smalltalk vm version in playground > On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: > > Hi, > > how do I discover? > > I tried with Pharo.exe --version but this shows nothing. > > Conversely, with PharoConsole here is what I obtain. > > >C:\pharo6\PharoConsole.exe --version > Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 > VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ > Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > > > > > On 2017-05-03 10:36, Esteban Lorenzano wrote: >> Hi, >> which vm version are you using? >> Esteban >>> On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >>> >>> Hello, >>> >>> I'm on Pharo 6 (32 bit)/Windows 10 (64 bit). >>> >>> I'm trying to load and use the (32 bit) JVM DLL into a running Pharo image via the UFFI. >>> >>> Everything works correctly, including JVM method invocations, except when trying to set the minimum and maximum JVM heap size by passing the -Xms<size> and -Xmx<size> options upon JVM creation. With these options, Pharo simply crashes without leaving any trace. >>> >>> Apparently, memory management requests from the JVM interfere with Pharo's own memory management. >>> >>> Please note that we successfully use the same mechanism for both VisualWorks (32 bit)/Windows 10 (64 bit) and Gemstone 64 bit/Linux, so it seems it has to do with a Pharo limitation somehow. >>> >>> Further, I couldn't find any documentation on how to increase Pharo's working set. >>> >>> So the questions are: >>> * What is the most probable cause of the crash described above? >>> * Where is there more doc about Pharo's memory configuration settings? >>> >>> Greetings >>> Raffaello >>> >>> > >

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Raffaello Giulietti

Hi, how do I discover? I tried with Pharo.exe --version but this shows nothing. Conversely, with PharoConsole here is what I obtain. >C:\pharo6\PharoConsole.exe --version Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ On 2017-05-03 10:36, Esteban Lorenzano wrote: > Hi, > > which vm version are you using? > > Esteban > >> On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >> >> Hello, >> >> I'm on Pharo 6 (32 bit)/Windows 10 (64 bit). >> >> I'm trying to load and use the (32 bit) JVM DLL into a running Pharo image via the UFFI. >> >> Everything works correctly, including JVM method invocations, except when trying to set the minimum and maximum JVM heap size by passing the -Xms<size> and -Xmx<size> options upon JVM creation. With these options, Pharo simply crashes without leaving any trace. >> >> Apparently, memory management requests from the JVM interfere with Pharo's own memory management. >> >> Please note that we successfully use the same mechanism for both VisualWorks (32 bit)/Windows 10 (64 bit) and Gemstone 64 bit/Linux, so it seems it has to do with a Pharo limitation somehow. >> >> Further, I couldn't find any documentation on how to increase Pharo's working set. >> >> So the questions are: >> * What is the most probable cause of the crash described above? >> * Where is there more doc about Pharo's memory configuration settings? >> >> Greetings >> Raffaello >> >> > >

May 3, 2017

Re: [Pharo-dev] resizing the windows sometimes blocks the image

by ClÃ©ment Bera

Hi Try resizing the window and clicking inside it a couple times. It usually refreshes the surface correctly and avoids the need to force quit. I think it happens to other people too, it seems it's exclusive to Mac OS X. Best, On Wed, May 3, 2017 at 10:23 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > With the latest moose image based on Pharo 6 and vm (32 bit) sometimes > when I resize the main window or enter full screen mode on MacOS the window > becomes totally white and does not recover:[image: Inline image 1] > I need to force quit the image. Also this happens not that often and > quite randomly. > > Does this happen to anybody else or it's just me? > > Cheers, > Andrei >

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Esteban Lorenzano

Hi, which vm version are you using? Esteban > On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: > > Hello, > > I'm on Pharo 6 (32 bit)/Windows 10 (64 bit). > > I'm trying to load and use the (32 bit) JVM DLL into a running Pharo image via the UFFI. > > Everything works correctly, including JVM method invocations, except when trying to set the minimum and maximum JVM heap size by passing the -Xms<size> and -Xmx<size> options upon JVM creation. With these options, Pharo simply crashes without leaving any trace. > > Apparently, memory management requests from the JVM interfere with Pharo's own memory management. > > Please note that we successfully use the same mechanism for both VisualWorks (32 bit)/Windows 10 (64 bit) and Gemstone 64 bit/Linux, so it seems it has to do with a Pharo limitation somehow. > > Further, I couldn't find any documentation on how to increase Pharo's working set. > > So the questions are: > * What is the most probable cause of the crash described above? > * Where is there more doc about Pharo's memory configuration settings? > > Greetings > Raffaello > >

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Raffaello Giulietti

Unfortunately, as I just discovered, older versions of Pharo do not support UFFI. I don't have the time (nor a real interest) in backporting the code to an older pre-Spur VM which has probably reached its EOL just for the sake of experimentation. It would probably take hours to understand the older FFI model and to adapt the code for no real advantage. The current Pharo VM seems to support only the --memory option: I tried with 1 and 2 GiB, nothing changes in the misbehavior. I also tried the two heap-related JVM options in isolation, unsuccessfully. Just for information, the current values for the options are -Xms16m and -Xmx512m, meaning that the JVM heap should start with 16 MiB and grow to a maximum size of 512 MiB, both of which are rather modest values even for a 32 bit process. Besides, they work in VisualWorks (32 bit). The StackOverflow page indicated below is from year 2010, during the age of Java 6. The JVM has undergone major changes since then, including memory management, so I'm not sure the discussion there is relevant for Java 8, the release we are targeting as of today. But even if it were, I still cannot understand the crash in Pharo. On 2017-05-03 06:36, Ben Coman wrote: > > > On Wed, May 3, 2017 at 12:30 AM, Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>> wrote: > > Could you check how it works with Pharo5 which was based on prespur > CogVM? > > > Note, Pharo 5 Release was a Spur VM. > Try using... > http://files.pharo.org/get-files/50-preSpur/ > http://files.pharo.org/image/50-preSpur/50495.zip > > or even Pharo 4. > > cheers -ben > > > 2017-05-02 16:36 GMT+02:00 Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>>: > > Hello, > > I'm on Pharo 6 (32 bit)/Windows 10 (64 bit). > > I'm trying to load and use the (32 bit) JVM DLL into a running > Pharo image via the UFFI. > > Everything works correctly, including JVM method invocations, > except when trying to set the minimum and maximum JVM heap size > by passing the -Xms<size> and -Xmx<size> options upon JVM > creation. With these options, Pharo simply crashes without > leaving any trace. > > > Can you isolate whether the problem is either one of those, or it > happens with both, and if there is some cutoff where it works? Also, > perhaps try limiting heap being used by Pharo > --memory <size>[mk] use fixed heap size (added to image size) > --mmap <size>[mk] limit dynamic heap size (default: 1024m) > [out 2G on 32-bit) > --maxoldspace <size>[mk] set max size of old space memory to bytes > (disclaimer, I'm not too knowledgeable on these, just pulled them > from --help) > > Also consider that heap needs to be contiguous... > **http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-32bit-vs-64bit > cheers -ben > > > Apparently, memory management requests from the JVM interfere > with Pharo's own memory management. > > Please note that we successfully use the same mechanism for both > VisualWorks (32 bit)/Windows 10 (64 bit) and Gemstone 64 > bit/Linux, so it seems it has to do with a Pharo limitation somehow. > > Further, I couldn't find any documentation on how to increase > Pharo's working set. > > So the questions are: > * What is the most probable cause of the crash described above? > * Where is there more doc about Pharo's memory configuration > settings? > > Greetings > Raffaello > > > >

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Denis Kudriashov

Also good news that image drag and drop into latest VM works fine again 2017-05-03 10:10 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > I know, but cannot wait for promotingâ¦ is âstable enoughâ. > Alsoâ¦ problem is not present on other flavours so I guess is an image > problem. Guille worked a bit on it but we need to review some more. > > Esteban > > > On 3 May 2017, at 10:03, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > Black screen on startup is still there on Mac Sierra 32 bits VM > > 2017-05-03 9:43 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> in 15min, I will promote latest VM to stable VM. >> The new stable VM has a lot of bugfixes, notably: >> >> - compactor works >> - Cairo and Surface plugin now can coexist (and it does not crashes) >> - lot of other small things >> >> cheers, >> Esteban >> >> > >

May 3, 2017

resizing the windows sometimes blocks the image

by Andrei Chis

Hi, With the latest moose image based on Pharo 6 and vm (32 bit) sometimes when I resize the main window or enter full screen mode on MacOS the window becomes totally white and does not recover:[image: Inline image 1] I need to force quit the image. Also this happens not that often and quite randomly. Does this happen to anybody else or it's just me? Cheers, Andrei

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Esteban Lorenzano

I know, but cannot wait for promotingâ¦ is âstable enoughâ. Alsoâ¦ problem is not present on other flavours so I guess is an image problem. Guille worked a bit on it but we need to review some more. Esteban > On 3 May 2017, at 10:03, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > Black screen on startup is still there on Mac Sierra 32 bits VM > > 2017-05-03 9:43 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > in 15min, I will promote latest VM to stable VM. > The new stable VM has a lot of bugfixes, notably: > > - compactor works > - Cairo and Surface plugin now can coexist (and it does not crashes) > - lot of other small things > > cheers, > Esteban > >

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Denis Kudriashov

Hi. Black screen on startup is still there on Mac Sierra 32 bits VM 2017-05-03 9:43 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > in 15min, I will promote latest VM to stable VM. > The new stable VM has a lot of bugfixes, notably: > > - compactor works > - Cairo and Surface plugin now can coexist (and it does not crashes) > - lot of other small things > > cheers, > Esteban > >

May 3, 2017