Re: [Pharo-users] Unable to compile myself Pharo
On Fri, 7 Dec 2018 at 01:09, Alexandre Garreau wrote: > I didn’t find on the README enough informations (about which dir to use > and what to do once inside), but found some on a random blog on the web > [0], and now built it but it seems it only installed executable binary > stuff under the name of “squeak”, is this normal? are you sure it’s not > related to the “squeak-vm” debian package? > > [0] > https://pharoweekly.wordpress.com/2017/02/23/building-pharo-vm-as-simple-as/ Very sorry to add to your frustration. I only just followed that link to check which instructions you were using. Those instructions are deprecated (can anyone edit that page? or publish an updated one?) Please try... $ git clone g...@github.com:OpenSmalltalk/opensmalltalk-vm.git $ cd opensmalltalk-vm/build.linux64x64/pharo.cog.spur/build $ ./mvm Note this is the tip of development. Alternatively you could find the commit hash from the stable VM and check that out. Then try image pharo64.zip from http://files.pharo.org/get-files/70/ HTH cheers -ben P.S. @esteban, could we get a tag in opensmalltalk-vm repo to mark Pharo's stable VM build. A branch "pharo-stable" would facilitate one more step above ```git checkout pharo-stable``` to provide a smoother path for people wanting to compile the VM for the first time. This branch would fast-forward along the mainline when Pharo's next stable VM is determined. (I expect "squeak-stable" would also be useful to have) A tag "pharo-stable-20180618" would provide a permanent record for someone is using one of those stable-VMs in production who needs to branch off that point to apply a hot fix. Also, when it comes to the Pharo 7 Release, identical matching tags " pharo-release-7.0" in both opensmalltalk/opensmalltalk-vm and pharo-project/pharo would be useful.
Re: [Pharo-users] Unable to compile myself Pharo
Okay, now I ran it some stuff seems to be more okay, but it still segfaults: Segmentation fault Tue Dec 11 01:09:56 2018 /usr/local/lib/squeak/5.0-201812101325/squeak Pharo VM version: 5.0-201812101325 Tue Dec 11 00:52:05 CET 2018 gcc 6.3.0 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-eem.2488 uuid: 3d088675-fa5c-452e-8063-001ff1d4ab81 Dec 11 2018 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2482 uuid: 7df020b4-6565-4768-9e4a-75bc5464ed95 Dec 11 2018 Revision: VM: 201812101325 galex-...@portable.galex-713.eu:doc/comp/src/pharo/opensmalltalk-vm Date: Mon Dec 10 14:25:06 2018 CommitHash: 14b6d3645 Plugins: 201812101325 galex-...@portable.galex-713.eu:doc/comp/src/pharo/opensmalltalk-vm Build host: Linux portable.galex-713.eu 4.9.0-8-686-pae #1 SMP Debian 4.9.130-2 (2018-10-27) i686 GNU/Linux plugin path: /usr/local/bin/../lib/squeak/5.0-201812101325 [default: /usr/local/lib/squeak/5.0-201812101325/] C stack backtrace & registers: eax 0xbf9683a4 ebx 0xbf9682c0 ecx 0xbf968358 edx 0xbf96830c edi 0xbf968190 esi 0xbf968190 ebp 0xbf968228 esp 0xbf968274 eip 0xbf968488 *[0xbf968488] /usr/local/bin/../lib/squeak/5.0-201812101325/squeak(+0x1df91)[0x4e1f91] /usr/local/bin/../lib/squeak/5.0-201812101325/squeak(+0x1fe1e)[0x4e3e1e] linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xb7790d10] /lib/i386-linux-gnu/libc.so.6(+0x75d91)[0xb74aad91] /lib/i386-linux-gnu/libc.so.6(getenv+0x1c)[0xb7462f5c] /usr/local/bin/../lib/squeak/5.0-201812101325/squeak(+0xca537)[0x58e537] /usr/local/bin/../lib/squeak/5.0-201812101325/squeak(+0x5b39a)[0x51f39a] /usr/local/bin/../lib/squeak/5.0-201812101325/squeak(+0x5ca8c)[0x520a8c] /usr/local/bin/../lib/squeak/5.0-201812101325/squeak(ceSendsupertonumArgs+0x2a4)[0x523034] [0x120008d] [0x1201128] [0x243a2f3] [0x4231f0b] [0x422938e] [0x4229344] [0x42293c8] [0x126e725] [0x120888c] [0x1201128] [0x126e4d6] [0x1229639] [0x1201128] [0x122964c] [0x12294f6] [0x121f74b] [0x12059c5] [0x121f6fb] [0x12010f8] /usr/local/bin/../lib/squeak/5.0-201812101325/squeak(+0x10edc8)[0x5d2dc8] Smalltalk stack dump: 0xbf9722c0 M UnixEnvironment>getRawEnvironmentVariableViaFFI: 0x150ae30: a(n) UnixEnvironment 0xbf9722f0 I FFICalloutAPI>function:module: 0x150ce10: a(n) FFICalloutAPI 0xbf972318 I UnixEnvironment(Object)>ffiCall:module: 0x150ae30: a(n) UnixEnvironment 0xbf972340 I UnixEnvironment>getRawEnvironmentVariableViaFFI: 0x150ae30: a(n) UnixEnvironment 0xbf972368 I UnixEnvironment>getRawEnvironmentVariable: 0x150ae30: a(n) UnixEnvironment 0xbf97238c I UnixEnvironment>getEnvironmentVariable:withEncoding: 0x150ae30: a(n) UnixEnvironment 0xbf9723b4 I UnixEnvironment>getEnvironmentVariable: 0x150ae30: a(n) UnixEnvironment 0xbf9723d4 M [] in UnixResolver(PlatformResolver)>directoryFromEnvVariableNamed:or: 0x142cff0: a(n) UnixResolver 0xbf9723ec M BlockClosure>on:do: 0x150a978: a(n) BlockClosure 0xbf972418 I UnixResolver(PlatformResolver)>directoryFromEnvVariableNamed:or: 0x142cff0: a(n) UnixResolver 0xbf972438 M UnixResolver>preferences 0x142cff0: a(n) UnixResolver 0xbf972450 M UnixResolver(FileSystemResolver)>resolve: 0x142cff0: a(n) UnixResolver 0xbf972474 I SystemResolver(FileSystemResolver)>unknownOrigin: 0x142cbc0: a(n) SystemResolver 0xbf972490 M SystemResolver(FileSystemResolver)>resolve: 0x142cbc0: a(n) SystemResolver 0xbf9724b0 M InteractiveResolver>unknownOrigin: 0x142cb80: a(n) InteractiveResolver 0xbf9724d0 M [] in InteractiveResolver>resolve: 0x142cb80: a(n) InteractiveResolver 0xbf9724ec M IdentityDictionary(Dictionary)>at:ifAbsent: 0x142cb90: a(n) IdentityDictionary 0xbf97250c M InteractiveResolver>resolve: 0x142cb80: a(n) InteractiveResolver 0xbf96e2d4 M FileLocator>resolve 0x150a7f0: a(n) FileLocator 0xbf96e2f4 I FileLocator>asFileReference 0x150a7f0: a(n) FileLocator 0xbf96e314 I PhLSettingBrowser class>preferencesFile 0x41dd830: a(n) PhLSettingBrowser class 0xbf96e334 I PhLSettingBrowser class>launcherStartUp 0x41dd830: a(n) PhLSettingBrowser class 0xbf96e34c M [] in PhLStartupManager class>startUp 0x41e80c8: a(n) PhLStartupManager class 0xbf96e370 M SortedCollection(OrderedCollection)>do: 0x4205a68: a(n) SortedCollection 0xbf96e394 I PhLStartupManager class>startUp 0x41e80c8: a(n) PhLStartupManager class 0xbf96e3ac M PhLStartupManager class(Behavior)>startUp: 0x41e80c8: a(n) PhLStartupManager class 0xbf96e3c8 M ClassSessionHandler>startup: 0x4205a48: a(n) ClassSessionHandler 0xbf96e3e8 M [] in WorkingSession>runStartup: 0x1392490: a(n) WorkingSession 0xbf96e40c M [] in WorkingSession>runList:do: 0x1392490: a(n) WorkingSession 0xbf96e424 M BlockClosure>on:do: 0x15055a8: a(n) BlockClosure 0xbf96e448 M [] in WorkingSession>runList:do: 0x1392490: a(n) WorkingSession 0xbf96e46c M Array(SequenceableCollection)>do: 0x1392678: a(n) Array 0xbf96e490 I WorkingSession>runList:do: 0x1392490: a(n) WorkingSession 0xbf96e4b8 I WorkingSession>runStartup: 0x1392490: a(n) WorkingSession 0xbf96e4dc I WorkingSession>start: 0x1392490: a(n)
Re: [Pharo-users] Unable to compile myself Pharo
That sounds normal. "No stash" is not an error. You should see new files in directory ".git/hooks" which help give correct date to built VM to avoid "to old" message. btw, make sure you match your 32/64-bitness between VM and Image. cheers -ben On Tue, 11 Dec 2018 at 00:51, Alexandre Garreau wrote: > Le 07/12/2018 à 02h25, Ben Coman a écrit : > >> On Fri, 7 Dec 2018 at 01:43, Alexandre Garreau >> wrote: >> >>> I built the VM and when running the Pharo.image file got with curl by >>> the site, it runs but warns the VM is too old for this image (strangely, >>> since I built the git version), >>> >> That warning can occur if you didn't run "scripts/updateSCCSVersions" >> once on your fresh clone (as described in the repo README, but its a common >> miss) >> >> I recloned and did it, and it doesn’t seem it did something, as it pretty > quickly ended with only that output: > > galex-713@portable:~/doc/comp/src/pharo/opensmalltalk-vm$ LCALL=C > scripts/updateSCCSVersions No stash found. >
Re: [Pharo-users] Unable to compile myself Pharo
Le 07/12/2018 à 02h25, Ben Coman a écrit : > On Fri, 7 Dec 2018 at 01:43, Alexandre Garreau > wrote: > >> I built the VM and when running the Pharo.image file got with curl by >> the site, it runs but warns the VM is too old for this image (strangely, >> since I built the git version), > > > That warning can occur if you didn't run "scripts/updateSCCSVersions" once > on your fresh clone > (as described in the repo README, but its a common miss) I recloned and did it, and it doesn’t seem it did something, as it pretty quickly ended with only that output: galex-713@portable:~/doc/comp/src/pharo/opensmalltalk-vm$ LC_ALL=C scripts/updateSCCSVersions No stash found.
Re: [Pharo-users] Unable to compile myself Pharo
On Fri, 7 Dec 2018 at 01:43, Alexandre Garreau wrote: > I built the VM and when running the Pharo.image file got with curl by > the site, it runs but warns the VM is too old for this image (strangely, > since I built the git version), That warning can occur if you didn't run "scripts/updateSCCSVersions" once on your fresh clone (as described in the repo README, but its a common miss) > and when trying to run the one sitting > in the pharo-launcher archive (PharoLauncher.image), it segfaults (is > this normal? can that be easily fixed, or…?): > Its not normal. Try updateSCCSVersions first and then we'll see if there is still a problem to sort out. > > > Segmentation fault Thu Dec 6 18:41:41 2018 > > > /usr/local/lib/squeak/5.0-/squeak > Pharo VM version: 5.0- Thu Dec 6 17:09:52 CET 2018 gcc 6.3.0 [Production > Spur VM] > Built from: CoInterpreter VMMaker.oscog-eem.2488 uuid: > 3d088675-fa5c-452e-8063-001ff1d4ab81 Dec 6 2018 > With: StackToRegisterMappingCogit VMMaker.oscog-eem.2482 uuid: > 7df020b4-6565-4768-9e4a-75bc5464ed95 Dec 6 2018 > Revision: VM: Date: CommitHash: Plugins: > ^^^ these fields are blank - I think updateSCCSVersions provides them. cheers -ben > Build host: Linux portable.galex-713.eu 4.9.0-8-686-pae #1 SMP Debian > 4.9.130-2 (2018-10-27) i686 GNU/Linux > plugin path: /usr/local/bin/../lib/squeak/5.0- [default: > /usr/local/lib/squeak/5.0-/] > >
Re: [Pharo-users] Unable to compile myself Pharo
I built the VM and when running the Pharo.image file got with curl by the site, it runs but warns the VM is too old for this image (strangely, since I built the git version), and when trying to run the one sitting in the pharo-launcher archive (PharoLauncher.image), it segfaults (is this normal? can that be easily fixed, or…?): Segmentation fault Thu Dec 6 18:41:41 2018 /usr/local/lib/squeak/5.0-/squeak Pharo VM version: 5.0- Thu Dec 6 17:09:52 CET 2018 gcc 6.3.0 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-eem.2488 uuid: 3d088675-fa5c-452e-8063-001ff1d4ab81 Dec 6 2018 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2482 uuid: 7df020b4-6565-4768-9e4a-75bc5464ed95 Dec 6 2018 Revision: VM: Date: CommitHash: Plugins: Build host: Linux portable.galex-713.eu 4.9.0-8-686-pae #1 SMP Debian 4.9.130-2 (2018-10-27) i686 GNU/Linux plugin path: /usr/local/bin/../lib/squeak/5.0- [default: /usr/local/lib/squeak/5.0-/] C stack backtrace & registers: eax 0xbf7c9964 ebx 0xbf7c9880 ecx 0xbf7c9918 edx 0xbf7c98cc edi 0xbf7c9750 esi 0xbf7c9750 ebp 0xbf7c97e8 esp 0xbf7c9834 eip 0xbf7c9a48 *[0xbf7c9a48] /usr/local/bin/../lib/squeak/5.0-/squeak(+0x1df61)[0x4c5f61] /usr/local/bin/../lib/squeak/5.0-/squeak(+0x1fdee)[0x4c7dee] linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xb77b8d10] /lib/i386-linux-gnu/libc.so.6(+0x75d91)[0xb74d2d91] /lib/i386-linux-gnu/libc.so.6(getenv+0x1c)[0xb748af5c] /usr/local/bin/../lib/squeak/5.0-/squeak(+0xca507)[0x572507] /usr/local/bin/../lib/squeak/5.0-/squeak(+0x5b36a)[0x50336a] /usr/local/bin/../lib/squeak/5.0-/squeak(+0x5ca5c)[0x504a5c] /usr/local/bin/../lib/squeak/5.0-/squeak(ceSendsupertonumArgs+0x2a4)[0x507004] [0x140008d] [0x1401128] [0x263a2f3] [0x4431f0b] [0x442938e] [0x4429344] [0x44293c8] [0x14f1ae5] [0x140888c] [0x1401128] [0x14f1896] [0x14b72a1] [0x1401128] [0x14b72b4] [0x14b715e] [0x14b5403] [0x14059c5] [0x14b53b3] [0x14010f8] /usr/local/bin/../lib/squeak/5.0-/squeak(+0x10f1a8)[0x5b71a8] Smalltalk stack dump: 0xbf7d4880 M UnixEnvironment>getRawEnvironmentVariableViaFFI: 0x171d248: a(n) UnixEnvironment 0xbf7d48b0 I FFICalloutAPI>function:module: 0x171f228: a(n) FFICalloutAPI 0xbf7d48d8 I UnixEnvironment(Object)>ffiCall:module: 0x171d248: a(n) UnixEnvironment 0xbf7d4900 I UnixEnvironment>getRawEnvironmentVariableViaFFI: 0x171d248: a(n) UnixEnvironment 0xbf7d4928 I UnixEnvironment>getRawEnvironmentVariable: 0x171d248: a(n) UnixEnvironment 0xbf7d494c I UnixEnvironment>getEnvironmentVariable:withEncoding: 0x171d248: a(n) UnixEnvironment 0xbf7d4974 I UnixEnvironment>getEnvironmentVariable: 0x171d248: a(n) UnixEnvironment 0xbf7d4994 M [] in UnixResolver(PlatformResolver)>directoryFromEnvVariableNamed:or: 0x15054b8: a(n) UnixResolver 0xbf7d49ac M BlockClosure>on:do: 0x171cd90: a(n) BlockClosure 0xbf7d49d8 I UnixResolver(PlatformResolver)>directoryFromEnvVariableNamed:or: 0x15054b8: a(n) UnixResolver 0xbf7d49f8 M UnixResolver>preferences 0x15054b8: a(n) UnixResolver 0xbf7d4a10 M UnixResolver(FileSystemResolver)>resolve: 0x15054b8: a(n) UnixResolver 0xbf7d4a34 I SystemResolver(FileSystemResolver)>unknownOrigin: 0x1503078: a(n) SystemResolver 0xbf7d4a50 M SystemResolver(FileSystemResolver)>resolve: 0x1503078: a(n) SystemResolver 0xbf7d4a70 M InteractiveResolver>unknownOrigin: 0x1500168: a(n) InteractiveResolver 0xbf7d4a90 M [] in InteractiveResolver>resolve: 0x1500168: a(n) InteractiveResolver 0xbf7d4aac M IdentityDictionary(Dictionary)>at:ifAbsent: 0x1503088: a(n) IdentityDictionary 0xbf7d4acc M InteractiveResolver>resolve: 0x1500168: a(n) InteractiveResolver 0xbf7cf894 M FileLocator>resolve 0x171cc08: a(n) FileLocator 0xbf7cf8b4 I FileLocator>asFileReference 0x171cc08: a(n) FileLocator 0xbf7cf8d4 I PhLSettingBrowser class>preferencesFile 0x43dd830: a(n) PhLSettingBrowser class 0xbf7cf8f4 I PhLSettingBrowser class>launcherStartUp 0x43dd830: a(n) PhLSettingBrowser class 0xbf7cf90c M [] in PhLStartupManager class>startUp 0x43e80c8: a(n) PhLStartupManager class 0xbf7cf930 M SortedCollection(OrderedCollection)>do: 0x4405a68: a(n) SortedCollection 0xbf7cf954 I PhLStartupManager class>startUp 0x43e80c8: a(n) PhLStartupManager class 0xbf7cf96c M PhLStartupManager class(Behavior)>startUp: 0x43e80c8: a(n) PhLStartupManager class 0xbf7cf988 M ClassSessionHandler>startup: 0x4405a48: a(n) ClassSessionHandler 0xbf7cf9a8 M [] in WorkingSession>runStartup: 0x150: a(n) WorkingSession 0xbf7cf9cc M [] in WorkingSession>runList:do: 0x150: a(n) WorkingSession 0xbf7cf9e4 M BlockClosure>on:do: 0x17179c0: a(n) BlockClosure 0xbf7cfa08 M [] in WorkingSession>runList:do: 0x150: a(n) WorkingSession 0xbf7cfa2c M Array(SequenceableCollection)>do: 0x15013c0: a(n) Array 0xbf7cfa50 I WorkingSession>runList:do: 0x150: a(n) WorkingSession 0xbf7cfa78 I WorkingSession>runStartup: 0x150: a(n) WorkingSession 0xbf7cfa9c I WorkingSession>start: 0x150: a(n) WorkingSession 0xbf7cfac8 I SessionManager>snapshot:andQuit: 0x3508d80:
Re: [Pharo-users] Unable to compile myself Pharo
I didn’t find on the README enough informations (about which dir to use and what to do once inside), but found some on a random blog on the web [0], and now built it but it seems it only installed executable binary stuff under the name of “squeak”, is this normal? are you sure it’s not related to the “squeak-vm” debian package? [0] https://pharoweekly.wordpress.com/2017/02/23/building-pharo-vm-as-simple-as/
Re: [Pharo-users] Unable to compile myself Pharo
On Sat, Dec 01, 2018 at 07:37:12PM +0100, Alexandre Garreau wrote: > > https://github.com/OpenSmalltalk/opensmalltalk-vm > > Wait if it’s the same than for squeak… knowing there’s a “squeak-vm” > package in debian that claim to be able to run several images… could it > be that it could be used to run pharo? Unlikely. OpenSmalltalk VM's single source code base is used to build VMs for several different Smalltalk-like languages. Pierce
Re: [Pharo-users] Unable to compile myself Pharo
On Sat, 1 Dec 2018 at 02:19, Alexandre Garreau wrote: > Hi, > > I tried to compile itself because I’m usually uncomfortable with using > binaries downloaded from the internet whose sources couldn’t be checked > afterwards. I don’t know the status of Pharo regarding Deterministic > Builds, but I have come anyway to become more comfortable in trusting > what comes from the distro I use and only that… > > But I saw the bootstrap process involve redownloading a binary image > anyway… I’d have just prefered to recompile it to be sure, as I’m > usually more comfortable with this idea. Normally compiling a new > language is —though long— not that difficult. > Traditional Smalltalk systems don't do a bootstrap. Indeed its conceivable(?) that there exist some objects floating around in Images distributed by vendors today that were created in the 1980s. In spite of the advantages of the Image concept saving the whole system state, it does impact reproducability, and is one of the common criticisms of Smalltalk. Pharo has put a lot of effort into producing a bootstrap system run by CI every commit, but there may still be some rough edges when used outside the CI. You sound like you may have already looked into these, but anyway you may get some hints from... * https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1427/consoleFull * https://github.com/pharo-project/pharo/blob/development/Jenkinsfile cheers -ben
Re: [Pharo-users] Unable to compile myself Pharo
Le 01/12/2018 à 09h34, Pierce Ng a écrit : > On Fri, Nov 30, 2018 at 07:15:22PM +0100, Alexandre Garreau wrote: >> But I saw the bootstrap process involve redownloading a binary image >> anyway… I’d have just prefered to recompile it to be sure, as I’m >> usually more comfortable with this idea. Normally compiling a new >> language is —though long— not that difficult. > > For Pharo (and relatives like Squeak and Cuis) there are two parts: VM > and image. To build your own VM, follow the README's instructions for > the OpenSmalltalk VM: > > https://github.com/OpenSmalltalk/opensmalltalk-vm Wait if it’s the same than for squeak… knowing there’s a “squeak-vm” package in debian that claim to be able to run several images… could it be that it could be used to run pharo?
Re: [Pharo-users] Unable to compile myself Pharo
On Fri, Nov 30, 2018 at 07:15:22PM +0100, Alexandre Garreau wrote: > But I saw the bootstrap process involve redownloading a binary image > anyway… I’d have just prefered to recompile it to be sure, as I’m > usually more comfortable with this idea. Normally compiling a new > language is —though long— not that difficult. For Pharo (and relatives like Squeak and Cuis) there are two parts: VM and image. To build your own VM, follow the README's instructions for the OpenSmalltalk VM: https://github.com/OpenSmalltalk/opensmalltalk-vm As for building your own images, for now, I suggest to use the standard downloadable images. Pierce
Re: [Pharo-users] Unable to compile myself Pharo
Hi, I tried to compile itself because I’m usually incomfortable with using binaries downloaded from the internet whose sources couldn’t be checked afterwards. I don’t know the status of Pharo regarding Deterministic Builds, but I have come anyway to become more comfortable in trusting what comes from the distro I use and only that… But I saw the bootstrap process involve redownloading a binary image anyway… I’d have just prefered to recompile it to be sure, as I’m usually more comfortable with this idea. Normally compiling a new language is —though long— not that difficult. So maybe that could help debugging stuff that might be improved? I guess that error is not supposed to happen right? PS: sorry for the late answer, I didn’t see answers at first, mails were only sent to the list and I’m often more used to have answers to me be cc to myself. I guess the usage is different here.
Re: [Pharo-users] Unable to compile myself Pharo
Hi Alexandre, as Cédrick said there is no need to generate a new image from scratch. Pharo is basically divided in two parts an image (that is the one that it is generated by the process you want to run) and a virtual machine to run the image. The image is multi-OS you can download a 32 bits image and run it in any of the supported operating systems. Usually the VM will run in different OSs, there is a VM for Mac OS, one for Windows and one for Unix(es). The VM came in 32 and 64 bits flavors. You should try to run the pre built version of the pack. And again using the Pharo Launcher will be the simpler option. Cheers, Pablo On Wed, Nov 28, 2018 at 1:02 PM Cédrick Béler wrote: > Hi Alexandre, > > Do you really want to « bootstrap » an image ? You don’t need to (just use > an official image). > > Try here, either through the launcher or the curl command line: > > https://pharo.org/download (Linux for thé launcher or at the end of the > page from the command line. > > HTH, > > Cedrick > > Envoyé de mon iPhone > > Le 28 nov. 2018 à 11:23, Garreau, Alexandre a > écrit : > > Le 28/11/2018 à 11h17, Garreau, Alexandre a écrit : > > This VM uses a separate heartbeat thread to update its internal clock > > and handle events. For best operation, this thread should run at a > > higher priority, however the VM was unable to change the priority. The > > effect is that heavily loaded systems may experience some latency > > issues. If this occurs, please create the appropriate configuration > > file in /etc/security/limits.d/ as shown below: > > > cat < > * hardrtprio 2 > > * softrtprio 2 > > END > > > and report to the pharo mailing list whether this improves behaviour. > > > Btw changing this didn’t improve anything until then, since build still > fails (but the error disappeared). > > Sorry to clutter with a second mail. > > -- Pablo Tesone. teso...@gmail.com
Re: [Pharo-users] Unable to compile myself Pharo
Hi Alexandre, Do you really want to « bootstrap » an image ? You don’t need to (just use an official image). Try here, either through the launcher or the curl command line: https://pharo.org/download (Linux for thé launcher or at the end of the page from the command line. HTH, Cedrick Envoyé de mon iPhone > Le 28 nov. 2018 à 11:23, Garreau, Alexandre a écrit : > >> Le 28/11/2018 à 11h17, Garreau, Alexandre a écrit : >> This VM uses a separate heartbeat thread to update its internal clock >> and handle events. For best operation, this thread should run at a >> higher priority, however the VM was unable to change the priority. The >> effect is that heavily loaded systems may experience some latency >> issues. If this occurs, please create the appropriate configuration >> file in /etc/security/limits.d/ as shown below: >> >> cat <> * hardrtprio 2 >> * softrtprio 2 >> END >> >> and report to the pharo mailing list whether this improves behaviour. > > Btw changing this didn’t improve anything until then, since build still > fails (but the error disappeared). > > Sorry to clutter with a second mail. >
Re: [Pharo-users] Unable to compile myself Pharo
Le 28/11/2018 à 11h17, Garreau, Alexandre a écrit : > This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat < * hardrtprio 2 > * softrtprio 2 > END > > and report to the pharo mailing list whether this improves behaviour. Btw changing this didn’t improve anything until then, since build still fails (but the error disappeared). Sorry to clutter with a second mail.
