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

[pharo-project/pharo-core]

by GitHub

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

March 31, 2017

[pharo-project/pharo-core] 839d82: 60456

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 839d825ccfba83c774e31db09257c19b49552131 https://github.com/pharo-project/pharo-core/commit/839d825ccfba83c774e31db0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-31 (Fri, 31 Mar 2017) Changed paths: M Athens-Cairo.package/AthensCairoSurface.class/class/surface plugin callbacks/createShowSurfaceFn.st M Athens-Cairo.package/AthensCairoSurface.class/class/surface plugin callbacks/createUnlockSurfaceFn.st M Athens-Cairo.package/SQSurfaceDispatch.class/instance/accessing structure variables/showSurfaceFn_.st M Athens-Cairo.package/SQSurfaceDispatch.class/instance/accessing structure variables/unlockSurfaceFn_.st M Morphic-Widgets-FastTable.package/FTSelectionStrategy.class/instance/private/toggleRowIndex_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60455.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60456.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60455.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60456.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60456 19888 FastTable should not reset highlighting rows when selection is changed https://pharo.fogbugz.com/f/cases/19888 19887 cairo surface does not need to set lock/show surface callbacks https://pharo.fogbugz.com/f/cases/19887 http://files.pharo.org/image/60/60456.zip

March 31, 2017

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

by Stephane Ducasse

To me a datasource should deliver data and not UI elements. On Thu, Mar 30, 2017 at 12:43 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > 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 31, 2017

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

by Eliot Miranda

On Thu, Mar 30, 2017 at 8:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alistair, > > On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> 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/32f321583c6 >> 9ca27e61ffaff6decc2a3e4b6ca5e >> >> 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)? >> > > The issue is that delays are recognized by periodically checking the time > against the next delay expiry. It is the heartbeat thread that causes > JITed Smalltalk code to break out of its execution to check for events, > including the next delay expiry. So if the heartbeat is at the same > priority as the JITed Smalltalk code, and the Smalltalk code is in tight > enough a loop (one that does not provoke a GC, does not do any process > switches) the heartbeat thread will not run and the delay expiry will never > be tested for. > Something like the following should run forever if the heartbeat has the same priority as the VM thread (and should be tried in a headless configuration too): [| infiniteLoop | infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + (sum even ifTrue: [1] ifFalse: [-1])]] newProcess. infiniteLoop resume. Processor activeProcess priority: Processor activePriority + 1. (Delay forSeconds: 1) wait. infiniteLoop terminate. Processor activeProcess priority: Processor activePriority - 1] timeToRun 1001 Also, a change was made to the travis test setup in: >> >> https://github.com/pharo-project/pharo-vm/commit/5418a415e92 >> 97f601f6d57ee732fd7fd942da08c >> >> The comment is: "No need to raise rtprio limit anymore" >> >> From your comments above, this doesn't seem accurate. >> > > Right. What seems to occur is that certain linux distress don't require a > conf file to allow raising the priority of a thread. Remember that rtprio > is not the issue. We only require that the heartbeat thread has higher > priority than the VM thread. > > >> 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 VM should (& I believe already does) print an error if the attempt to > raise the heartbeat thread priority fails. My underatanding is that the > positive change is simply not to exit if the attempt fails. > > > >> >> >> > 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 >> > > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot

March 31, 2017

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

by Eliot Miranda

On Thu, Mar 30, 2017 at 6:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Thu, Mar 30, 2017 at 8:03 PM, 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/32f >> 321583c69ca27e61ffaff6decc2a3e4b6ca5e >> > >> > 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. >> > > its internal clock and handle events. > > >> For best operation, this thread should run > > > >> at real-time priority, >> > > at a higher priority. > > (Real-time priority is something else.) > > >> however the VM was unable to change the priority. The effect is that >> > > >> the clock may experience some jitter. > > To avoid clock jitter, please >> > > 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 <<EOF | sudo tee /etc/security/limits.d/VNAME.conf >> * hard rtprio 2 VNAME >> * soft rtprio 2 VNAME >> EOF >> > > and report to the mail list whether this improves behaviour. > What Ben says. Exactly right on all points. > > >> >> 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 -ben > > >> >> 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? >> > >> > >> >> > -- _,,,^..^,,,_ best, Eliot

March 31, 2017

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

by Eliot Miranda

Hi Alistair, On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > 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/ > 32f321583c69ca27e61ffaff6decc2a3e4b6ca5e > > 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)? > The issue is that delays are recognized by periodically checking the time against the next delay expiry. It is the heartbeat thread that causes JITed Smalltalk code to break out of its execution to check for events, including the next delay expiry. So if the heartbeat is at the same priority as the JITed Smalltalk code, and the Smalltalk code is in tight enough a loop (one that does not provoke a GC, does not do any process switches) the heartbeat thread will not run and the delay expiry will never be tested for. > > Also, a change was made to the travis test setup in: > > https://github.com/pharo-project/pharo-vm/commit/ > 5418a415e9297f601f6d57ee732fd7fd942da08c > > The comment is: "No need to raise rtprio limit anymore" > > From your comments above, this doesn't seem accurate. > Right. What seems to occur is that certain linux distress don't require a conf file to allow raising the priority of a thread. Remember that rtprio is not the issue. We only require that the heartbeat thread has higher priority than the VM thread. > 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 VM should (& I believe already does) print an error if the attempt to raise the heartbeat thread priority fails. My underatanding is that the positive change is simply not to exit if the attempt fails. > > > > 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 > _,,,^..^,,,_ best, Eliot

March 31, 2017

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

by Ben Coman

On Thu, Mar 30, 2017 at 8:03 PM, 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/ > 32f321583c69ca27e61ffaff6decc2a3e4b6ca5e > > > > 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. > its internal clock and handle events. > For best operation, this thread should run > at real-time priority, > at a higher priority. (Real-time priority is something else.) > however the VM was unable to change the priority. The effect is that > > the clock may experience some jitter. To avoid clock jitter, please > 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 <<EOF | sudo tee /etc/security/limits.d/VNAME.conf > * hard rtprio 2 VNAME > * soft rtprio 2 VNAME > EOF > and report to the mail list whether this improves behaviour. > > 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 -ben > > 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 31, 2017

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

by Ben Coman

On Fri, Mar 31, 2017 at 12:15 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > _,,,^..^,,,_ (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. > > "may" is fairly broad term and presumptive at this stage. While the *static* priority of the heartbeat and interpreter threads is the same, the heartbeat-thread mostly sleeps, so its *dynamic* priority will be higher than the interpreter thread. This is even more so when the interpreter-thread is compute intensive. This behaviour is (maybe) Linux specific, but its only Linux that has a problem raising the heartbeat-thread priority. So the threaded-heartbeat "should not" have more jitter than before, but I'm still meaning to confirm this by experiment with a minimal C-lang thread code example. However I speculate that in a heavily loaded system, the itimer-heartbeat may have *slightly* better jitter than even a high-priority-heartbeat-thread, since IIUC signal handling preempts even higher priority threads. But most modern systems operate <20% CPU. Specific experiments would be needed to comment further, but I'd hazard to guess the itimer-heartbeat might only be an advantage for audio on heavily loaded systems. Not your common Pharo system. In balance against itimer conflicts with OSProcess and third-party C libraries, the threaded-heartbeat seems preferable (if all the above remains true in practice). Although I'm reading some stuff that may also resolve the timer-heartbeat issues. cheers -ben > 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. > Good point. We can make use of our good friend hyphen... threaded-heatbeat & heartbeat-thread. cheers -ben > > An exit may be appropriate in some > cases, but for most users the above warning is sufficient. > > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ > 32f321583c69ca27e61ffaff6decc2a3e4b6ca5e > > 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 31, 2017

Re: [Pharo-dev] Path>>/ and ..

by Alistair Grant

On 29 March 2017 at 16:20, Damien Pollet <damien.pollet(a)gmail.com> wrote: > On 29 March 2017 at 14:02, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Except that ".." is treated as a special case at the moment in >> Path class>>addParentElementTo:, which is why #resolve: does the right >> thing (well, at least in my opinion :-)). > > > Well, not according to shell commands : > ls ./nonexistentdirectory/.. â cannot access, no such file or directory > > So we have a divergence between FileSystem, where .. means "cancel the last > path segment, syntactically, without even checking the actual files and > directories" and the behavior of the shell command (and thus of the > underlying system call, I guess) which attempts to actually resolve each > segment and fails because it cannot go and look inside nonexistentdirectory > for the entry named '..' > > This becomes important with symbolic links : try ls ./somesymlink/.. and > you'll see that you don't get the contents of $PWD but of the parent of the > symlink's destination. > >> >> I'm having trouble understanding the Path class comments, however: >> >> "#* and #/ are mnemonic to . and / >> whose arguments should be string file- or directory names, not >> fragments of Unix path notation intended to be parsed." >> >> seems to imply that segments should not contain the delimiter (/), and >> the current implementation leaves the delimiter in the segment. > > > Yes. The point is, if you have an API that tries to be clever and guesses > what you meant (e.g. you could pass '../foo/bar' as a path element, it might > be convenient most of the time, but you lose control of what you mean: the > API, because it interprets the strings you pass, will make it difficult or > impossible to express some paths. For instance, on my current filesystem, I > can create a file named foo\bar. I'm guessing that's impossible on Windowsâ¦ > It also leads to quoting, escaping, case sensitivity and such problems (try > writing shell scripts that are robust to file names with spacesâ¦) > > The alternative is to have an API that does what you tell it to, no more, no > less. It should consider that if you pass a string with special characters, > you meant to have those characters in the result. Maybe that's impossible on > some filesystems, and raises an error, but the API will not decide to do > something different than you asked. Good point, I'd forgotten about symlinks. I did a little investigation, and Python and Java don't bother about checking whether the path exists or if there are symlinks present. There are warnings in the documentation. Bash provides realpath and readlink, but there are flags to indicate whether to check that the path actually exists or not. At the moment, Pharo is a bit inconsistent: '/a/b/c' asFileReference / '../d' "File @ /a/b/c/../d" '/a/b/c/../d' asFileReference "File @ /a/b/d" Perhaps FileReference and Path could be modified so that references to the parent directory are kept by default, but there are canonicalize methods that remove them: #canonicalizeFollow - the path must exist and symlinks are followed #canonicalize - don't check for file existance or follow symlinks I would still modify Path>>/ so that segments don't contain directory separators, i.e. currently: '/a/b/c' asFileReference / '../d' "Path / 'a' / 'b' / 'c' / '../d'" would become: '/a/b/c' asFileReference / '../d' "Path / 'a' / 'b' / 'c' / '..' / 'd'" (Notice that the second version has an additional segment). What does everyone think? Thanks, Alistair

March 30, 2017

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

by Alistair Grant

Hi Eliot, On 30 March 2017 at 18:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > 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? Interesting, which OS are you running? It fails on Ubuntu 16.04 (I just tried it again, using bash) and ARCH linux for me (in the past). > > Also isn't a nicer alternative is just to say > su > cat ... > ? This assumes that you can log in as the root account. It's disabled in lots of distributions (and considered poor form to enable it). Of course, my version assumes that sudo is installed and configured, but, at least within the Linux community, I think it is a reasonable assumption. Cheers, Alistair

March 30, 2017