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

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

by Denis Kudriashov

2017-01-30 13:36 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-01-30 13:14 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > >> 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? > > > I am working on it. It happens when server starts from command line. > Probably I do something wrong in my TCPServer implementation. > Zinc server works fine. So I have example where there is no problems. > Ok. It is fixed now. Just load stable version. Reason was related to my post about two listener sockets. TCPServer is registered on startup list and it recreates listener socket when image resumes. >From command line it happens twice. First instance is created from command line handler which registers it on startup list. But when command line is evaluated Pharo start process startup list which lead to duplicated socket creation. Now TCPServer handles it properly.

Jan. 30, 2017

Two listener sockets on same port

by Denis Kudriashov

Hi, I remember in past there was some reports about it. And now I was a victim of this problem which is very difficult to debug. Pharo allows to start two listener sockets on same port. You will not see any error. State of both sockets will be identical. "socket isValid, socket status" will be always correct for both instances. You can play with sockets with following code: (socket := Socket newTCP) setOption: 'TCP_NODELAY' value: 1; setOption: 'SO_SNDBUF' value: 4096; setOption: 'SO_RCVBUF' value: 4096. socket listenOn: 40424 backlogSize: 32. When many listener sockets are created. Only first will receive connections. So first server will work. But others will not with no way to know why. But more dramatical scenario is when first socket becomes collected as garbage which will destroy it. In this case You will be completely confusing why your single instance in image is not working. Such case is of course some bug in how you manage sockets. But that's the problem: It is now impossible to debug such cases. Can we fix it? Is it possible to signal error when socket is not really listen? Best regards, Denis

Jan. 30, 2017

Pharo 6 release status

by Pavel Krivanek

Hi all, as announced, for the Pharo 6 release we set milestone of almost all low priority issues to "Later". If you feel that some of the postponed issues you reported are important and needs to be fixed before the release, please change the milestone back to Pharo 6. All issues where it was possible to decide were tagged as ExistedInPharo5 or NewInPharo6. The priority of most of the cases tagged as ExistedInPharo5 were decreased to priority "Fix if time". If you think think that some of these issues must be fixed for the next release, please increase their priority. Otherwise such issues will be marked as "Later" before the release. If you have a lot of subscribed issues, sorry for the noise in your inbox. We have now 153 open issues for Pharo 6. 48 issues are now with priority "Must fix" or higher. We hope in release date on the 1st of April. Cheers, -- Pavel

Jan. 30, 2017

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

by Dimitris Chloupis

Also I think its fair that the guy that wrote the code to pick the name, its his baby afterall, whether he is paid for it or not. He earned that right. On Mon, Jan 30, 2017 at 6:06 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Just for the record, the name does not matter > > As a matter of fact if you want the name to really sell the library/ tools > then the last thing you want is a name that makes any logical sense > > You have much better chance to catch attention with "Pink Elephant" than > "Pharo Remote tools" or whatever > > illogical names monopolise the software market > > Python > Ruby on Rails > Django > Blender > Unreal > Unity > Javascript > Java > C > C++ > Windows > MacOS > > and so on > > Developers choose to name their projects the craziest names and wisely so > > the name is there to catch attention, not to make sense or come up top on > google search. > > In the end what it matters is the code itself. > > Ruby On Rails did not become populary because we love ruby stones or we > love go "too...tooooooo" on rails ... its popular because the library has > been very useful to many people. > > And the name itself guarantees that it wont come up top in google search > because it has nothing unique about it. > > The rest is just marketing ;) >

Jan. 30, 2017

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

by Dimitris Chloupis

Just for the record, the name does not matter As a matter of fact if you want the name to really sell the library/ tools then the last thing you want is a name that makes any logical sense You have much better chance to catch attention with "Pink Elephant" than "Pharo Remote tools" or whatever illogical names monopolise the software market Python Ruby on Rails Django Blender Unreal Unity Javascript Java C C++ Windows MacOS and so on Developers choose to name their projects the craziest names and wisely so the name is there to catch attention, not to make sense or come up top on google search. In the end what it matters is the code itself. Ruby On Rails did not become populary because we love ruby stones or we love go "too...tooooooo" on rails ... its popular because the library has been very useful to many people. And the name itself guarantees that it wont come up top in google search because it has nothing unique about it. The rest is just marketing ;)

Jan. 30, 2017

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

by Norbert Hartl

> Am 30.01.2017 um 16:21 schrieb Ben Coman <btc(a)openinworld.com>: > > On Mon, Jan 30, 2017 at 9:32 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> Am 30.01.2017 um 14:21 schrieb Ben Coman <btc(a)openinworld.com>: >>> >>> But I agree with Stef. My very first impression when I read the ANN >>> subject line was of a pharmaceutical/medical app. Maybe a slight >>> contraction to "PharIDE", which in common usage would probably become >>> "pharide". Only 6k googs is not too bad. >>> >>> btw, what is the "m" for in PharmIDE ? > > On Mon, Jan 30, 2017 at 9:25 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> 2017-01-30 14:21 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> >>> btw, what is the "m" for in PharmIDE ? >> >> >> First it is like farm. >> Seconds it is Pharo Remote IDE > > >> >> It is not an acronym per se but a variation of farm. So it is pharo farm. PharIDE just kills it. In this case something else would be better. > > Instead you get Far-IDE. > > But I do like the "farm" association. So perhaps... > * Pharrem > which *sounds* like "farm" said real-slow like a farmer's drawl, > while avoiding the pharmaceutical association. > > The two R's avoid it sounding like "fa-Rem". > > The "rem" part associates more easily with "remote" than when the "e" > is dropped. > We are talking about a technology for distributed stuff. I assume that anyone working in that area associates the term farm with a lot of things to manage. And that is what it does. If they are old enough the might even get the ph-pun (like in phreaking [1]). Maybe that is the reason I like it. Putting a lot of meaning in a term has most of the time no outcome because people cannot see the meaning you've put in. Recognizable terms are indeed a plus because it is just seeing it and knowing it from somewhere else. Or you could (like Brad said) use a clear name that describes what it does. The problem here is that you cannot find it on the net among those other things that describe clearly the same. And I'm against cool fantasy names like we have to many in pharo. They just produce confusion. And that is my last mail on this topic. I knew it was wrong participating in that thread :) Norbert [1] https://de.wikipedia.org/wiki/Phreaking <https://de.wikipedia.org/wiki/Phreaking> > cheers -ben > >> >> Norbert >> >>> >>> cheers -ben >>> >>> On Mon, Jan 30, 2017 at 9:15 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>> Like it too FWIW. >>>> >>>> Phil >>>> >>>> On Mon, Jan 30, 2017 at 12:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>> wrote: >>>>> >>>>> >>>>> 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] Any idea for a cool name for the remote tool suite?

by Ben Coman

On Mon, Jan 30, 2017 at 9:32 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Am 30.01.2017 um 14:21 schrieb Ben Coman <btc(a)openinworld.com>: >> >> But I agree with Stef. My very first impression when I read the ANN >> subject line was of a pharmaceutical/medical app. Maybe a slight >> contraction to "PharIDE", which in common usage would probably become >> "pharide". Only 6k googs is not too bad. >> >> btw, what is the "m" for in PharmIDE ? On Mon, Jan 30, 2017 at 9:25 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-01-30 14:21 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> btw, what is the "m" for in PharmIDE ? > > > First it is like farm. > Seconds it is Pharo Remote IDE > > It is not an acronym per se but a variation of farm. So it is pharo farm. PharIDE just kills it. In this case something else would be better. Instead you get Far-IDE. But I do like the "farm" association. So perhaps... * Pharrem which *sounds* like "farm" said real-slow like a farmer's drawl, while avoiding the pharmaceutical association. The two R's avoid it sounding like "fa-Rem". The "rem" part associates more easily with "remote" than when the "e" is dropped. cheers -ben > > Norbert > >> >> cheers -ben >> >> On Mon, Jan 30, 2017 at 9:15 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>> Like it too FWIW. >>> >>> Phil >>> >>> On Mon, Jan 30, 2017 at 12:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>>> >>>> >>>> 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] Any idea for a cool name for the remote tool suite?

by Esteban A. Maringolo

+1 to simple names. Pharo Remote. No accronym involved, no lookup to know what it means. A remote it also a noun, i.e. something you use to control your TV remotely :D If you want more details... Pharo Remote Toolkit. Tools is too abstract, toolkit is a set of tools meant to work together o a particular kind of task.. Best regards, Esteban A. Maringolo 2017-01-30 12:08 GMT-03:00 Volkert <volkert(a)nivoba.de>: > +100 > > > On 30.01.2017 15:31, Brad Selfridge wrote: > > I'm not a big fan of cryptic names. I already think there are way too many > in Pharo. You look at the names and have no idea what they do. Why not call > it what it is: "Pharo Remote IDE" or "RemoteIDE". It's simple and it tells > the user EXACTLY what it is without digging into some obscure document, (or > no document at all). > > > -- > Brad Selfridge > bsselfridge(a)gmail.com > > > > On 01/30/2017 08:25 AM, Denis Kudriashov wrote: > > > 2017-01-30 14:21 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> btw, what is the "m" for in PharmIDE ? > > > First it is like farm. > Seconds it is Pharo Remote IDE > > >

Jan. 30, 2017

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

by Volkert

+100 On 30.01.2017 15:31, Brad Selfridge wrote: > > I'm not a big fan of cryptic names. I already think there are way too > many in Pharo. You look at the names and have no idea what they do. > Why not call it what it is: "Pharo Remote IDE" or "RemoteIDE". It's > simple and it tells the user EXACTLY what it is without digging into > some obscure document, (or no document at all). > > > -- > Brad Selfridge > bsselfridge(a)gmail.com > > > On 01/30/2017 08:25 AM, Denis Kudriashov wrote: >> >> 2017-01-30 14:21 GMT+01:00 Ben Coman <btc(a)openinworld.com >> <mailto:btc@openinworld.com>>: >> >> btw, what is the "m" for in PharmIDE ? >> >> >> First it is like farm. >> Seconds it is *Pha*ro *R*e*m*ote IDE >

Jan. 30, 2017

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

by Denis Kudriashov

2017-01-30 15:45 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > 2017-01-30 14:16 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > How can we start PharmIDE server so that it binds to localhost only on > the server? > > > > I do not know if it is possible from Pharo. Anybody know example with > "Socket newTCP"? > > With "external OS tools" you can always hide port from outside world. > Try to google it. > > It is in your image already ! > > See ZnServer>>#bindingAddress: and ZnSingleThrededServer>># > initializeServerSocket > > In use in ZnServerTests>>#testEchoLocalInterface > > You will understand immediately, it is quite easy. > > Remember that once you start like that, you will only be able to connect > locally. Thank's Sven. I will add suitable method to start Pharm server

Jan. 30, 2017