- Pharo-dev - lists.pharo.org

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by StÃ©phane Ducasse

On Aug 30, 2010, at 9:57 PM, Nicolas Cellier wrote: > Hi Pharoers, > I'm happy to read mail from Torsten, Igor and Miguel, thank you guys > that's constructive. > Andreas expressed his point very well, and i don't think it is > hostile, maybe a bit sarcastic or disenchanted, but overall he keeps > the door opened. > The first thing to do is to cool down, relax and think. > The second thing to do is engaging discussion with Andreas. > > Of course, the license is of prime importance, not having a license is > a showstopper. > If license is too restrictive then Andreas will probably fail to reach > his goals... > There will be de facto full rewrite rather than forks, but the net > result will be the same: failure to share packages/libraries. why? because if there is a rewrite it will be MIT. > That's why I personnally don't find Andreas defensive position a good strategy. > Neither the attitude in response... > It's like you're happy to throw his work away at first occasion > without even trying to negociate. Oh no. I do not want that people bash us as people stealing work of other people. Read my mail on webClient. > Bad vibrations. Writing all these mails is even more for me. > Before you engage in this (war)path, please, please, discuss. > And remind this saying "il ne faut pas confondre vitesse et prÃ©cipitation". > If no agreement is found then, ok, you'll get a license to carry on. So far we talk in the desert. Loading WebClient is one line. So this is as easy as to remove. > After the license problem, there is the technical compatibility problem. > Discussions about cross fork compatibility, compatibility layers or > libraries (a la GREASE) will have to occur anyway, be it about Andreas > library or from any other author. So you'll have to take time to > discuss. Don't consider this as lost time. These discussions are > considered necessary when they regularly happens in Pharo mailing > list, aren't they ? It shouldn't be that hard to convince Andreas to > change things like and:and:and:. For squeakToUtf8, I don't know, maybe > provide some automated rewrite rules, and produce an automated Pharo > version ? I already suggested that. Now there is an important point. Infrastructure code should be supported, accessible to the community. We got burned with graphics andreas' onwership in the past. And yes we learned from that. > > Please, discuss, argue, explain why you consider certain constructions > as bad style. Propose alternatives (be constructive - remember > coopetition ?). > I consider being unable to explain one's own choice as a weakness. > Don't be weak. > Come-on guys, despite Levente's cutting remark, you're not inferior to > squeakers ;) (and you don't have to answer to that stupid conclusion). I will let people decide as I did for the inclusion of webClient and we will rewrite one if necessary and it will be MIT. This will be the same for the equivalent of SqueakSSL we will try as much as possible to offer an infrastructure that let people control their life and make money. Our goal is to have a core that could be bootstrap so to have many packages as external as possible now I thought that it would help people to have webClient and also help us to remove this ugly network package. I should have know before the other HTTPClient library and we will not be here losing our time. Stef

Aug. 30, 2010

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Guillermo Polito

My english sucks :P. It's "How can I help with that?" xD On Mon, Aug 30, 2010 at 5:15 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > > On Mon, Aug 30, 2010 at 5:09 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> > Stef, Noury, >> > >> > Thanks for doing this, and for the preview! >> > >> > Sometimes being a good friend means getting tough, and it's time for >> that. You are doing a great job of writing up how to create poorly designed >> socket applications. They are poorly designed because of what we inherit >> from Squeak. Servers should not listen for a time period; they need to >> listen until told otherwise, and trigger events (notifications if preferred) >> when a client tries to connect, at which point a dedicated process accepts >> the connection - that process more or less is the server. Clients should >> try to connect and read until told otherwise, either by a watchdog thread or >> by a user. Nothing should block in either case except the calling Smalltalk >> Process. If a client program does not hang because of a non-responsive >> server, an interacting user has the opportunity to hit a cancel button and >> put an end to wasted effort, or a watchdog can run and similarly #erminate >> the offending thread. >> >> John pointed us to a kind of socket that raises events on data. >> Our problem is that we do not have manpower for that. >> >> > IMHO, we should not direct energy at documenting the current state of >> sockets; we should do the few remaining things to get something that really >> works. At the same time, we should try as much as possible to allow IrDA >> and OpenSSL to appear as options. >> >> Noury and luc started to rewrite sockets using Alien and people can help. >> Nothing will happen magically :) >> >> How should I help with that (a little)? > > Cheers, > Guille > >> >> > >> > Bill >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Aug. 30, 2010

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Guillermo Polito

On Mon, Aug 30, 2010 at 5:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > Stef, Noury, > > > > Thanks for doing this, and for the preview! > > > > Sometimes being a good friend means getting tough, and it's time for > that. You are doing a great job of writing up how to create poorly designed > socket applications. They are poorly designed because of what we inherit > from Squeak. Servers should not listen for a time period; they need to > listen until told otherwise, and trigger events (notifications if preferred) > when a client tries to connect, at which point a dedicated process accepts > the connection - that process more or less is the server. Clients should > try to connect and read until told otherwise, either by a watchdog thread or > by a user. Nothing should block in either case except the calling Smalltalk > Process. If a client program does not hang because of a non-responsive > server, an interacting user has the opportunity to hit a cancel button and > put an end to wasted effort, or a watchdog can run and similarly #erminate > the offending thread. > > John pointed us to a kind of socket that raises events on data. > Our problem is that we do not have manpower for that. > > > IMHO, we should not direct energy at documenting the current state of > sockets; we should do the few remaining things to get something that really > works. At the same time, we should try as much as possible to allow IrDA > and OpenSSL to appear as options. > > Noury and luc started to rewrite sockets using Alien and people can help. > Nothing will happen magically :) > > How should I help with that (a little)? Cheers, Guille > > > > > Bill > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by StÃ©phane Ducasse

> Stef, Noury, > > Thanks for doing this, and for the preview! > > Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. John pointed us to a kind of socket that raises events on data. Our problem is that we do not have manpower for that. > IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Noury and luc started to rewrite sockets using Alien and people can help. Nothing will happen magically :) > > Bill

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by Nicolas Cellier

2010/8/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote: > >> so what did you do? >> >> I see that the file got removed... Â I will submit a bug issue for that with the file attached. >> >> The *real* problem is that you cannot remove it either! It does _not_ want to go away! > > Oops! A bad spirit in pharo :) > Any person able to understand MultiDisplayScanner arcanes wouldn't see any magic in this. But I really wonder whether a single person can manage such complexity... Henrik ? Nicolas > > For me just resizing the window made it disappeared. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Nicolas Cellier

Hi Pharoers, I'm happy to read mail from Torsten, Igor and Miguel, thank you guys that's constructive. Andreas expressed his point very well, and i don't think it is hostile, maybe a bit sarcastic or disenchanted, but overall he keeps the door opened. The first thing to do is to cool down, relax and think. The second thing to do is engaging discussion with Andreas. Of course, the license is of prime importance, not having a license is a showstopper. If license is too restrictive then Andreas will probably fail to reach his goals... There will be de facto full rewrite rather than forks, but the net result will be the same: failure to share packages/libraries. That's why I personnally don't find Andreas defensive position a good strategy. Neither the attitude in response... It's like you're happy to throw his work away at first occasion without even trying to negociate. Bad vibrations. Before you engage in this (war)path, please, please, discuss. And remind this saying "il ne faut pas confondre vitesse et prÃ©cipitation". If no agreement is found then, ok, you'll get a license to carry on. After the license problem, there is the technical compatibility problem. Discussions about cross fork compatibility, compatibility layers or libraries (a la GREASE) will have to occur anyway, be it about Andreas library or from any other author. So you'll have to take time to discuss. Don't consider this as lost time. These discussions are considered necessary when they regularly happens in Pharo mailing list, aren't they ? It shouldn't be that hard to convince Andreas to change things like and:and:and:. For squeakToUtf8, I don't know, maybe provide some automated rewrite rules, and produce an automated Pharo version ? Please, discuss, argue, explain why you consider certain constructions as bad style. Propose alternatives (be constructive - remember coopetition ?). I consider being unable to explain one's own choice as a weakness. Don't be weak. Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Nicolas 2010/8/30 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > 2010/8/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> >> >> El lun, 30-08-2010 a las 18:25 +0300, Igor Stasenko escribiÃ³: >> > My 2 cents about WebClient. >> > >> > - it should be an (un)loadable external package, and i am fully agree >> > with Andreas on this point. >> > It is tempting to integrate it into image, do some tweaks here and >> > there and then ship it within a monolitic image. >> > But then, from maintainer's point of view, it is quite hard to keep >> > developing it and improving, since it may break >> > things in random places over multiple forks etc etc, and then who will >> > be accused in such breakage? - a maintainer. >> >> Of course not, we, the ones using it as part of our core image are the >> ones responsible of the correct functioning in our image. It would be >> childish to run crying to Andreas that it break our image because we are >> taking the decision of integrating it in the core image. Now, this of >> course doesn't apply to core functionality or that breaks the contract >> the code offers to its clients. That type of API changes will be >> discussed with Andreas and if no solution found, the pharo developers >> will found a workaround so that is remains working correctly. >> > > Agree with Miguel. It is the smae situation as Gofer.Â Lukas is the main > developer of Gofer but we (pharo developers) maintain it. When a message is > removed or renamed for example, we take care about its senders, for all > packages, included Gofer. And we are the responsible, not Lukas. > >> >> What I don't understand is why such imposition to the way of use the >> software. If it decided to have an open source license he can't restrict >> the uses of the software. This is a real open source implications. >> >> >> > >> > It is good to have a person, who personally responsible for >> > maintaining a package, or even if by a group of people, >> > it should use a separate repository for developing it. >> > >> > Otherwise, if you integrate it into image, by doing that you: >> > Â - losing a maintainer , who willingly contributing to this project >> > Â - in same turn, must take own responsibility for maintaining it, >> > which means extra work for you, whenever you having >> > Â problems with it. >> >> Of course, that is the point. Nobody expects otherwise. >> >> > >> > We should learn how to integrate things without intimately tying >> > everything with a single bloated image. >> >> Isn't as we are integrating moose or seaside in the core image is a >> basic infrastructure thing, a http client, that every modern language in >> the current times includes in their core libraries (java, ruby, lisp). >> >> > And WebClient could be right thing for learning that (Seaside too ;). >> > >> >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Schwab,Wilhelm K

Stef, Noury, Thanks for doing this, and for the preview! Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Bill ________________________________________ From: stephane ducasse [stephane.ducasse(a)free.fr] Sent: Monday, August 30, 2010 2:50 PM To: Schwab,Wilhelm K Subject: Fwd: [Pharo-project] Sockets in Pharo CollaborActive Book Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Date: August 29, 2010 11:09:50 PM GMT+02:00 > To: DeNigris Sean <sean(a)clipperadams.com> > Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book >

Aug. 30, 2010

[Pharo-project] Squeaksource default license (was Re: WebClient-Core port to Pharo 1.1 final)

by DeNigris Sean

<quote author="Torsten Bergmann"> Maybe the license should be a required field in Squeaksource for any new project. </quote> Yes! /And/ *default to MIT.* Even though in this case Andreas chose other-than MIT on purpose, how many projects are not MIT simply because the default is a choice other than "the one most valuable to the community." Let's use this opportunity to improve for the future :) Sean

Aug. 30, 2010

Re: [Pharo-project] Inter-image communication

by Sean P. DeNigris

While some of the suggestions (AMQP, STOMP) were over my head, I'm in the process of getting UbiquiTalk to work and already have rST going. But, for my use case i.e. sending remote commands between (only) two images on the same machine, why not just send the commands as strings over a socket, and evaluate them with the compiler? Obviously there's no security, but since it's in-house only... A proof-of-concept is below: Server image: server := Socket newTCP. server listenOn: 8081. server waitForConnectionFor: 600. server sendData: 'Workspace open' Client image: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8081. Compiler evaluate: client receiveData. Add a loop and we're all set. Sean -- View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2400616.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Douglas Brebner

On 30/08/2010 12:06, Levente Uzonyi wrote: > On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > >> >> Now >> - since the license is unclear >> - since the license of the contributors is unclear >> we will not use it as an infrastructural assets for Pharo. I imagine >> that Seaside will not use it either. > > Well, we are about to use it for Seaside. > Is that legal? IANAL but it was my understanding that if code has no licence it means that noone but the author has any right to do anything with it whatsoever. Not to download it, use it or even read it. That's why licences explicitly grant you rights, because otherwise you have /none/.

Aug. 30, 2010