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

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Denis Kudriashov

2017-01-30 12:04 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > Hi, > > I really enjoy how motivated people get when it is about finding a name :) > > I don't agree PharmIDE is a bad name. > I also like my original name :)

Jan. 30, 2017

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

by Denis Kudriashov

2017-01-30 11:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 30 Jan 2017, at 11:43, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> > >> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > >> > >> Hi Sean. > >> > >> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean(a)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). Yes, I agree with you. That's why it is not in priority. But generally I think It would be nice option

Jan. 30, 2017

[pharo-project/pharo-core]

by GitHub

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

Jan. 30, 2017

[pharo-project/pharo-core] f08ede: 60364

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: f08edef898f658d88cd130dfebeedc3affde965b https://github.com/pharo-project/pharo-core/commit/f08edef898f658d88cd130df… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-30 (Mon, 30 Jan 2017) Changed paths: M AST-Core.package/RBParseTreeSearcher.class/class/instance creation/getterMethod_.st M Announcements-Core.package/Announcement.class/README.md M Morphic-Widgets-FastTable.package/FTFilterFunction.class/instance/updating/filter.st M Morphic-Widgets-FastTable.package/FTMultipleSelection.class/instance/private/selectAppendingRowIndex_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/click_.st R Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/private/commandOrCrontrolKeyPressed_.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/private/isYellowButtonReallyPressed_.st M Refactoring-Core.package/RBCreateAccessorsForVariableRefactoring.class/instance/testing/usesAssignmentOf_in_classVariable_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60363.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60364.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60363.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60364.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60364 19277 FastTable not support deselection while command click is used on multiple selection https://pharo.fogbugz.com/f/cases/19277 18880 Autogenerating accessors should be less naive https://pharo.fogbugz.com/f/cases/18880 19371 Doc: Main announcement classes could point to the tutorial in help browser https://pharo.fogbugz.com/f/cases/19371 19543 FTPluggableIconListMorphAdaptor does not update selection after filtering https://pharo.fogbugz.com/f/cases/19543 http://files.pharo.org/image/60/60364.zip

Jan. 30, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Norbert Hartl

Hi, I really enjoy how motivated people get when it is about finding a name :) I don't agree PharmIDE is a bad name. Farming is a well known term when it comes to server installations (server farm) or other distributed stuff. So as it is not your context you get another impression. People that are in the context (e.g. me ;) ) might think different. So while I agree it has a medicinal taste I like the name and I think we could coin the term more sincere for projects around pharo based farms. So my gut feeling says that keeping the IDE could make sense. The term cloud is burnt so CloudIDE is maybe not good. A successor of this would be SwarmIDE if we need something that is still a bit trendy. But PharmIDE has its uniqueness and that is a surplus. Ok, I must confess I named some things for distributed infrastrature also with the prefix Pharm :) Norbert > Am 29.01.2017 um 15:14 schrieb stepharong <stepharong(a)free.fr>: > > Hi guys > > Since we will push the remote tools (videos/web...) I would like to get some ideas for a cool name. > Any ideas? > > Because Pharmide (looks like medicine or chemical product). > Since I vaguely remember some german Pharmide made me think about Fern(sehen) but this is not a good name. > > Stef > > > -- >

Jan. 30, 2017

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

by Sven Van Caekenberghe

> On 30 Jan 2017, at 11:43, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> Hi Sean. >> >> 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean(a)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). > 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 :).

Jan. 30, 2017

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

by Norbert Hartl

> Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <dionisiydk(a)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. 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 :).

Jan. 30, 2017

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

by Denis Kudriashov

Hi Sean. 2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <sean(a)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. 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 :).

Jan. 30, 2017

Working with critiques in Calypso

by Yuriy Tymchuk

Hi everyone, this question is mainly for Denis, but others may be also interested to participate. So Iâd really like to switch to Calypso, but I use Nautilus to eat my own dog food (the critiques). Calypso already adds critiques for methods, but it misses the ones for classes and packages. The point is that you can use anObject annotateRubricText: textModel. And anObject can be anything: a method, or a class, or a package (or theoretically any other object object). Iâve tried to expand highlighting to classes and methods in Nautilus, but it looks like a complete hell. In Calypso itâs much better, but maybe from the experience of the main developer, the styling can be pulled up somewhere higher in the hierarchy. Now it turns out that the bottom plugin is actually useful, as you can get the idea about the issue without having to power or do some other actions. Will it be possible to have some king of a plugin like that in Calypso. And simultaneously is it possible to have a changeable height? Because usually you donât have more than 1-2 critiques, and often you donât have any, so it does not make any sense to occupy so much space with an empty list. (sadly in Nautilus I cannot shrink the plugin dynamically). Cheers. Uko

Jan. 30, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Guillaume Larcheveque

Marionnetist 2017-01-30 10:34 GMT+01:00 James Ladd <ladd.james(a)gmail.com>: > Try > https://www.penn.museum/documents/education/pennmuseum_egypt_previsit_ > combined.pdf > > Flail looks like a good candidate . > > Sent from my Commodore 64 > > On 30 Jan 2017, at 11:06 am, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sun, Jan 29, 2017 at 10:14 PM, stepharong <stepharong(a)free.fr> wrote: > >> Hi guys >> >> Since we will push the remote tools (videos/web...) I would like to get >> some ideas for a cool name. >> Any ideas? >> >> Because Pharmide (looks like medicine or chemical product). >> Since I vaguely remember some german Pharmide made me think about >> Fern(sehen) but this is not a good name. >> >> >> > For a change, I'm lacking original ideas :P > But of other suggestions, I like... > > > Phresnel from Fresnel lenses [1] used in lighthouses to be visible over > greater distances > Good googability and a *great* fit for Pharo's lighthouse theme. > There is one competing project https://github.com/lobid/Phresnel > but it looks abandoned and ranks low in searches. > > > PharoAfar > Except its a bit of a tongue twist and I'd shorten it to Pharofar, and > maybe Pharophar. > far = at, to, or by a great distance > > > Pharoscope from Pharo + Telescope > Related terms: borescope, oscilloscope, spectroscope. > > So far Phresnel is my phavorite. > > cheers -ben > > -- *Guillaume Larcheveque*

Jan. 30, 2017