- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Feb. 1, 2017

[pharo-project/pharo-core] e98b15: 60369

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e98b15066a5da28d95096c3a3d29ba45839a3847 https://github.com/pharo-project/pharo-core/commit/e98b15066a5da28d95096c3a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-01 (Wed, 01 Feb 2017) Changed paths: M Morphic-Widgets-Tabs.package/TabMorph.class/instance/protocol/softRetrieveMorph.st M Nautilus.package/MethodContainsBreakAction.class/instance/order/privateActionIcon.st A Nautilus.package/NautilusUI.class/class/menus behavior/toggleBreakpointIn_.st R Nautilus.package/NautilusUI.class/instance/menus behavior/toggleBreakOnEntryIn_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/toggleBreakpoint.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60368.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60369.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60368.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60369.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-OSEnvironments.package/Win32Environment.class/instance/private/getEnvSize_.st M System-OSEnvironments.package/Win32Environment.class/instance/private/getEnv_buffer_size_.st Log Message: ----------- 60369 18232 Breakpoints cannot be toggled in Nautilus method pane https://pharo.fogbugz.com/f/cases/18232 19641 CantFindOriginError when Source file is missing on Windows https://pharo.fogbugz.com/f/cases/19641 19632 TabMorph should defer only notification about ready morph https://pharo.fogbugz.com/f/cases/19632 http://files.pharo.org/image/60/60369.zip

Feb. 1, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by Torsten Bergmann

>>Great job!!! A dream comes true. >>If there is a working UFFI for ARM then we have a pretty decent stack for IoT times. >Thank's. UFFI works in my simple tests like "LibC system: 'ls'" Did you check out my OSRaspbian project loadable from the catalog? It uses UFFI and is working on Pi. Bye T.

Feb. 1, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by Denis Kudriashov

2017-02-01 9:41 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > I think in the future we need to work out how we can inspect a remote > object while using GT features. A lot of stuff in GT inspector is pretty > useful. But then I assume it is really chatty at the same time making the > remote usage less useful. I know what needs to be done from my point of view. But what exactly missing from your perspective?

Feb. 1, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by Denis Kudriashov

2017-02-01 9:41 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > Great job!!! A dream comes true. If there is a working UFFI for ARM then > we have a pretty decent stack for IoT times. Thank's. UFFI works in my simple tests like "LibC system: 'ls'"

Feb. 1, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by Esteban Lorenzano

> On 1 Feb 2017, at 09:41, Norbert Hartl <norbert(a)hartl.name> wrote: > > Great job!!! A dream comes true. If there is a working UFFI for ARM then we have a pretty decent stack for IoT times. there is not reason why it shouldnât workâ¦ backend is reported to be workingâ¦ but well, you are free to test it :) Esteban >

Feb. 1, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by Norbert Hartl

> Am 30.01.2017 um 13:14 schrieb Norbert Hartl <norbert(a)hartl.name>: > >> >> Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: >> >>> >>> On 30 Jan 2017, at 11:43, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>> >>>> >>>> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >>>> >>>> Hi Sean. >>>> >>>> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: >>>> Have you considered security at all yet? Leaving a port open which allows >>>> arbitrary code to be executed reomotely seems very dangerous... >>>> >>>> Norbert already answer you. I just put little summary. >>>> Currently there is two important issues which must be handled manually: >>>> - security. You can manage it by VPN or SSH >>>> - distributed garbage collection. You need perform "remotePharo disconnect" (or "PrmRemotePharo disconnectAll") at the end of your working session. It cleans server and client from distributed objects. >>>> >>>> Last issue is at high priority in my todo. When I implement it unused distributed objects will be collected automatically like local ones. >>>> Security option can be added too. Seamless design allows to it. Probably It can be simple switch to SecureSocketStream instead of SocketStream. >>> >>> My advize for security is two-fold. The first reason not to apply security features to seamless is that it complicates the code base with a feature that is done better elsewhere. The second reason is that one big reason why this can be unusable is latency. A high latency makes it very hard to use the toolkit. So removing everything adding latency should be avoided. Security is from the image perspective one of those things. >> >> Explicit/manual SSH port forwarding is easy & safe. Doing it deliberately makes you more aware of what you are doing, which is very necessary in this case because of the huge danger involved (giving away full image control). But it will add its own latency (just like TLS would). >> > Right. To make it a bit more concrete. If we use the example of Denis on port 40423 then a simple > > $ ssh -L 40423:localhost:40423 pharmide-server.anydomain.com <http://pharmide-server.anydomain.com/> > > will open a forwarding tunnel so you can connect with the PharmIDE client using > > PrmRemoteIDE connectTo: (TCPAddress ip: #[127 0 0 1] port: 40423) > > and you'll end up connecting to your remote image. > > Unfortunately I couldn't test it because I installed the PharmIDE on my linux machine and it does not work. When starting the image a listening port is opened but 5 seconds later the port closes automatically. Has anyone tested it on a linux machine? > As a followup I need to say that it works now and it works like a charm. I installed one PharmIDE image on my server and did the SSL tunneling. Latency was very good or to say it was only that high that you can notice working on a remote image. I did only small tests but everything was working as expected. I think in the future we need to work out how we can inspect a remote object while using GT features. A lot of stuff in GT inspector is pretty useful. But then I assume it is really chatty at the same time making the remote usage less useful. Great job!!! A dream comes true. If there is a working UFFI for ARM then we have a pretty decent stack for IoT times. Bravo! Norbert > Norbert > >>> thanks again for doing that. >>> >>> Norbert >>> >>>> >>>> Important thing here that I am really satisfied with Seamless design which I made. It was driven by tests which means that it only addresses existing features but allow stable evolution to new functionality. And I thing it is most important property of any system: provide stable way how to evolve. System can be broken and very buggy at some point but if design and tests are stable then system will move. By stable I mean "do not require big changes for any new bug or feature", "always iterative process". >>>> Just want to share these thoughts with you :).

Feb. 1, 2017

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

by Andres Valloud

Martin, On 1/30/17 16:41 , Martin McClure wrote: > IEEE-754 does not define a "sign" operation. ANSI Smalltalk and ISO/IEC > 10967 do, so it makes sense to provide a #sign that conforms to those > standards -- answering -1, 0, or 1. > > IEEE-754 does define an isSignMinus operation, answering true or false, > so it makes sense to provide that operation in addition to the ones > specified by the other standards. Yes on isSignMinus. It may also be useful to define #signBit, and implement #isSignMinus as ^self signBit = 1. These types of messages are very useful for testing the implementation is doing the right thing IEEE-wise (hence VM-primitive-wise), so that it's possible to implement e.g. ISO 10967 with confidence. Andres.

Feb. 1, 2017

Re: [Pharo-dev] Memory leaks

by Torsten Bergmann

Jan. 31, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Denis Kudriashov

2017-01-31 18:53 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > >> * white toolbar (according to theme background color) >> >> >> That doesn't work well. Don't mix styles like this, that is >> confusing. >> >> >> Why? It was by intention. Idea to make toolbar with same color as main >> table panels. And they have default background color >> > > - The whole window uses visible separation, except for the toolbar. > Ok. - It is unclear where the toolbar applies to > - The color and style of the radio buttons differs from other UI elements > - The color of the tabs and tab panel are incorrect, the inactive tabs > take away attention. I always said that UI needs much more work. But my question was to your "don't mix styles". Do you think it looks worse than before? I am not designer and would be very appreciate if somebody paint how it should be.

Jan. 31, 2017