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

Re: [Pharo-dev] Iceberg with SSH on Linux

by Eliot Miranda

Hi Alistair, > On Mar 30, 2017, at 5:03 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> On 30 March 2017 at 11:58, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Yes, the same priority. See: >> >> The VM may have issues with clock jitter due to the heartbeat thread >> not running at elevated priority. An exit may be appropriate in some >> cases, but for most users the above warning is sufficient. >> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/32f321583c69ca27e6… >> >> Cheers, >> -- Pavel > > From looking at the code, my understanding is that the VM attempts to > elevate the priority of the heartbeat thread, if the elevation fails, > the old behaviour was to exit with a message. The new behaviour is to > just warn the user (with a message to stderr) and continue. > > Assuming I've read the code correctly, there's a bug that needs to be > fixed: the cat statement won't work as sudo doesn't apply to file > redirection; and I've suggested some more informative text: Are you sure? Many people, myself included, have used the sudo version successfully in the past. I think I see what you mean; if sudo is a.command then the shell that invokes it is not running as superuser and it sets up the pipe. But perhaps there's behind-the-scenes magic in the shell (I've used bash) that makes it work? Also isn't a nicer alternative is just to say su cat ... ? > > -- > This VM uses a separate heartbeat thread to update the internal clock. > For best operation, this thread should run at real-time priority, > however the VM was unable to change the priority. The effect is that > the clock may experience some jitter. To avoid clock jitter, please > create the appropriate configuration file in /etc/security/limits.d/ > as shown below: > > cat <<EOF | sudo tee /etc/security/limits.d/VNAME.conf > * hard rtprio 2 VNAME > * soft rtprio 2 VNAME > EOF > > You will need to logout and back in for the changes to take affect. > -- > > If there's no disagreement or better suggestion, I'll submit a pull > request (probably in a couple of days). > > Cheers, > Alistair > > > > >> 2017-03-30 11:51 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>> >>> 2017-03-29 20:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>> >>>> Hi, >>>> >>>> I want to let you know that the SSH (git@...) support in Iceberg on Linux >>>> VM now works with the latest threaded VM (get.pharo.org/vmTLatest60) The >>>> threaded VM now runs without root priviledges nor special configuration of >>>> the system. >>> >>> >>> And what the logic now? Heartbeat and VM are in same priory? >> >> >

March 30, 2017

Re: [Pharo-dev] Iceberg with SSH on Linux

by Alistair Grant

Hi Eliot, On 30 March 2017 at 18:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: >> >> Yes, the same priority. See: >> >> The VM may have issues with clock jitter due to the heartbeat thread >> not running at elevated priority. > > > It better /not/ be. This is wrong. The heartbeat thread /must/ run at a > higher priority for the VM not to lock up when it becomes compute bound. I > thought the resolution was that the VM /will/ try and raise the priority if > the heartbeat thread but will /not/ exit if it fails. This is /very/ > different from not trying to raise the priority at all. As Esteban wrote, the vm is trying to raise the priority. You can see the change at: https://github.com/pharo-project/pharo-vm/commit/32f321583c69ca27e61ffaff6d… I'd like to just make sure I understand your comment correctly: Are you saying that the VM will lock up if it gets in to, e.g., an endless loop, so that Ctrl-. fails to interrupt. Or is it more serious than that? Can the VM become locked up for just a long running process (I guess it will be locked while the process is running, but will eventually go back to normal once the process completes)? Also, a change was made to the travis test setup in: https://github.com/pharo-project/pharo-vm/commit/5418a415e9297f601f6d57ee73… The comment is: "No need to raise rtprio limit anymore" >From your comments above, this doesn't seem accurate. I'm in the middle of adding some details to the text that is printed out by the threaded heartbeat vm, and from what you're saying, maybe we should add some more warnings. > The resolution I thought we had reached means that if correctly installed > the VM can work correctly, and will continue to work correctly if and when > linux removes the annoyance of the conf files. The resolution you describe > Pavel (I hope inaccurately) means the threaded heartbeat VM will never work > correctly. Thanks, Alistair

March 30, 2017

Re: [Pharo-dev] Iceberg with SSH on Linux

by Esteban Lorenzano

> On 30 Mar 2017, at 18:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > _,,,^..^,,,_ (phone) > > On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > >> Yes, the same priority. See: >> >> The VM may have issues with clock jitter due to the heartbeat thread >> not running at elevated priority. > > It better /not/ be. This is wrong. The heartbeat thread /must/ run at a higher priority for the VM not to lock up when it becomes compute bound. I thought the resolution was that the VM /will/ try and raise the priority if the heartbeat thread but will /not/ exit if it fails. This is /very/ different from not trying to raise the priority at all. > > The resolution I thought we had reached means that if correctly installed the VM can work correctly, and will continue to work correctly if and when linux removes the annoyance of the conf files. The resolution you describe Pavel (I hope inaccurately) means the threaded heartbeat VM will never work correctly. this is like this :) > > One other thing. I know threaded heartbeat is verbose, but I would really appreciate it if we could reserve "threaded vm" to mean a vm that multiplexes Smalltalk processes above native threads, even if not concurrently. This is the threaded ffi plan which we have a good chance of realizing this year. + 1000 Esteban > >> An exit may be appropriate in some >> cases, but for most users the above warning is sufficient. >> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/32f321583c69ca27e6… <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/32f321583c69ca27e6…> >> >> Cheers, >> -- Pavel >> >> 2017-03-30 11:51 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> >> 2017-03-29 20:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: >> Hi, >> >> I want to let you know that the SSH (git@...) support in Iceberg on Linux VM now works with the latest threaded VM (get.pharo.org/vmTLatest60 <http://get.pharo.org/vmTLatest60>). The threaded VM now runs without root priviledges nor special configuration of the system. >> >> And what the logic now? Heartbeat and VM are in same priory? >>

March 30, 2017

Re: [Pharo-dev] Iceberg with SSH on Linux

by Eliot Miranda

_,,,^..^,,,_ (phone) > On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Yes, the same priority. See: > > The VM may have issues with clock jitter due to the heartbeat thread > not running at elevated priority. It better /not/ be. This is wrong. The heartbeat thread /must/ run at a higher priority for the VM not to lock up when it becomes compute bound. I thought the resolution was that the VM /will/ try and raise the priority if the heartbeat thread but will /not/ exit if it fails. This is /very/ different from not trying to raise the priority at all. The resolution I thought we had reached means that if correctly installed the VM can work correctly, and will continue to work correctly if and when linux removes the annoyance of the conf files. The resolution you describe Pavel (I hope inaccurately) means the threaded heartbeat VM will never work correctly. One other thing. I know threaded heartbeat is verbose, but I would really appreciate it if we could reserve "threaded vm" to mean a vm that multiplexes Smalltalk processes above native threads, even if not concurrently. This is the threaded ffi plan which we have a good chance of realizing this year. > An exit may be appropriate in some > cases, but for most users the above warning is sufficient. > > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/32f321583c69ca27e6… > > Cheers, > -- Pavel > > 2017-03-30 11:51 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> 2017-03-29 20:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> Hi, >>> >>> I want to let you know that the SSH (git@...) support in Iceberg on Linux VM now works with the latest threaded VM (get.pharo.org/vmTLatest60) The threaded VM now runs without root priviledges nor special configuration of the system. >> >> And what the logic now? Heartbeat and VM are in same priory? >

March 30, 2017

LatestVM has socket related problem

by Denis Kudriashov

Hi. Following script works fine on stable Mac 32 VM but failed on latest: (server := Socket newTCP) setOption: 'TCP_NODELAY' value: 1; setOption: 'SO_SNDBUF' value: 4096; setOption: 'SO_RCVBUF' value: 4096. server listenOn: 40423 backlogSize: 32. serverProcess := [connectedSocket := server waitForAcceptFor: 2000] fork. 100 milliSeconds wait. socket := Socket newTCP. socket connectTo: #[127 0 0 1] port: 40423 waitForConnectionFor: 10. 200 milliSeconds wait. clientStream := SocketStream on: socket. clientProcess := [clientStream sendCommand: 'test'] fork. serverStream := SocketStream on: connectedSocket. serverProcess := [result := serverStream nextLine] fork. I open issue 19892 <https://pharo.fogbugz.com/f/cases/19892/Socket-problem-with-LatestVM>

March 30, 2017

Re: [Pharo-dev] Iceberg with SSH on Linux

by Denis Kudriashov

2017-03-30 14:03 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > From looking at the code, my understanding is that the VM attempts to > elevate the priority of the heartbeat thread, if the elevation fails, > the old behaviour was to exit with a message. The new behaviour is to > just warn the user (with a message to stderr) and continue. Great!

March 30, 2017

Re: [Pharo-dev] Iceberg with SSH on Linux

by Alistair Grant

On 30 March 2017 at 11:58, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Yes, the same priority. See: > > The VM may have issues with clock jitter due to the heartbeat thread > not running at elevated priority. An exit may be appropriate in some > cases, but for most users the above warning is sufficient. > > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/32f321583c69ca27e6… > > Cheers, > -- Pavel >From looking at the code, my understanding is that the VM attempts to elevate the priority of the heartbeat thread, if the elevation fails, the old behaviour was to exit with a message. The new behaviour is to just warn the user (with a message to stderr) and continue. Assuming I've read the code correctly, there's a bug that needs to be fixed: the cat statement won't work as sudo doesn't apply to file redirection; and I've suggested some more informative text: -- This VM uses a separate heartbeat thread to update the internal clock. For best operation, this thread should run at real-time priority, however the VM was unable to change the priority. The effect is that the clock may experience some jitter. To avoid clock jitter, please create the appropriate configuration file in /etc/security/limits.d/ as shown below: cat <<EOF | sudo tee /etc/security/limits.d/VNAME.conf * hard rtprio 2 VNAME * soft rtprio 2 VNAME EOF You will need to logout and back in for the changes to take affect. -- If there's no disagreement or better suggestion, I'll submit a pull request (probably in a couple of days). Cheers, Alistair > 2017-03-30 11:51 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> >> 2017-03-29 20:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> >>> Hi, >>> >>> I want to let you know that the SSH (git@...) support in Iceberg on Linux >>> VM now works with the latest threaded VM (get.pharo.org/vmTLatest60) The >>> threaded VM now runs without root priviledges nor special configuration of >>> the system. >> >> >> And what the logic now? Heartbeat and VM are in same priory? > >

March 30, 2017

Re: [Pharo-dev] [Gsoc] [FastTable improvements] [Features request]

by Denis Kudriashov

Hi Elhamer, 2017-03-29 18:00 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > - Support to automatically resize columns to fix the content > What I want first is ability to setup "spaceFill resizing" for columns. It will improve current tools immediately. For example in MessageBrowser all columns are fixed (there is no other possibility). And columns are not increased when window is expanded. So you always need to resize columns manually to see long content.

March 30, 2017

Re: [Pharo-dev] [Gsoc] [FastTable improvements] [Features request]

by Stephan Eggermont

On 29/03/17 17:53, Stephane Ducasse wrote: > What I do not like is that a source is a Morph and not a domain object. > To me there is something wrong. I do not understand why we will have to > rewrite source objects > to get fast table in another UI. What exactly do you mean by a source is a Morph? The FTDataSource is just a helper object returning widgets for the cells, and they happen to be Morphs. Looks like a clean interface to me. What am I missing? Stephan

March 30, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60455 Home: https://github.com/pharo-project/pharo-core

March 30, 2017