August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SerialPort - named ports on Linux

by Schwab,Wilhelm K

Dave, It's not obvious to me that Pharo won't take strings, but it looks that way because Squeak 4.1 has tests on type and by-name methods that are not in Pharo. One thought I had was to file the class out of Squeak and into Pharo, perhaps fixing _ vs. := and any other hassles that might arise. Should that work? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] Sent: Monday, August 30, 2010 4:25 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] SerialPort - named ports on Linux On Mon, Aug 30, 2010 at 02:24:37PM -0400, Schwab,Wilhelm K wrote: > Hello all, > > I recalled seeing mention of the Linux vm's now supporting named ports, and I found the code for that, at least in the vm. My understanding gets fuzzy as we enter the plugin and primitives. At a minimum, there are a few ByName methods to be added, and Squeak 4.1 contains open and close methods that test on type (int vs. string) to open or close by name or not as appropriate. > > Is this as simple as gathering the changes and adding them to Pharo, or does it require VMMaker magic? Bill, I don't have a Pharo image handy to check right now, but look at class SerialPort. Methods such as #openPort: should accept either integer (port number) or string (named device) parameters (if not, grab it from a Squeak image). All changes are in the VMs already, so there is nothing to worry about on the VMMaker side. If you need the background on this, it's at http://bugs.squeak.org/view.php?id=7266. Dave _______________________________________________ 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] SerialPort - named ports on Linux

by David T. Lewis

On Mon, Aug 30, 2010 at 02:24:37PM -0400, Schwab,Wilhelm K wrote: > Hello all, > > I recalled seeing mention of the Linux vm's now supporting named ports, and I found the code for that, at least in the vm. My understanding gets fuzzy as we enter the plugin and primitives. At a minimum, there are a few ByName methods to be added, and Squeak 4.1 contains open and close methods that test on type (int vs. string) to open or close by name or not as appropriate. > > Is this as simple as gathering the changes and adding them to Pharo, or does it require VMMaker magic? Bill, I don't have a Pharo image handy to check right now, but look at class SerialPort. Methods such as #openPort: should accept either integer (port number) or string (named device) parameters (if not, grab it from a Squeak image). All changes are in the VMs already, so there is nothing to worry about on the VMMaker side. If you need the background on this, it's at http://bugs.squeak.org/view.php?id=7266. Dave

Aug. 30, 2010

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

by Schwab,Wilhelm K

Your English does not suck as bad as Squeak's sockets framework :) I'm in too. I can't do it all, but I can help and I can certainly set a high bar by ensuring that it works across Linux and Windows and does not lock when the network hardware loses power. Sockets are sufficiently fundamental that we should document how to use them properly AND make Pharo work that way. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] Sent: Monday, August 30, 2010 4:16 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book 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<mailto:guillermopolito@gmail.com>> wrote: On Mon, Aug 30, 2010 at 5:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@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<mailto:Pharo-project@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, Where does one go to sign up? I am not certain that Alien is appropriate or necessary to make a solid socket foundation, but I am certain that the existing code is very sub-optimal and needs a real jolt. If we are serious about fixing it (Linux, Windows and Mac), I am serious about helping. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Monday, August 30, 2010 4:09 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book > 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 _______________________________________________ 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 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