- Pharo-dev - lists.pharo.org

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

by Levente Uzonyi

(sorry, pine can't quote your mail correctly...) On Mon, 30 Aug 2010, Miguel Enrique CobÃ¡ MartÃnez wrote: > El lun, 30-08-2010 a las 13:06 +0200, Levente Uzonyi escribiÃ³: > > What I get from Andreas' words is that he's willing to make it open source > if it won't be forked. "This is plain wrong, You CAN'T make something open source and at the same time hope that nobody will fork it. The possibility of forking is one of the main liberties granted by the free and open source software. If Andreas doesn't want anyone to fork then by definition can't be open source." Maybe he'll be happy if you give your word that you won't fork it. "As I said before, a way to avoid forking in an open source project is to be open and accepting code from contributors. Not accepting good code for bad reasons is what leads to forking. " Sometimes you have to ignore/fix contributions. For example: - ProcessWrapper on SqueakSource had 2 new package versions which totally broke the package. I asked the contributor why he did the changes, but I got no response in a few days, so I just removed the versions. - PostgresV3 had a contribution, someone fixed a bug. The fix was a simple one-liner, but ignored the (untold) fact that PostgresV3 is meant to be fast, therefore critical methods are optimized by hand. So I had to rewrite to keep up with our goal. "I, and I think, every Pharo user, are ok with the package being controlled by Andreas, as long as the patches are accepted and not rejected for bad reasons (like having the package part of pharo core: that is our problem, if there are issues by having it part of pharo core we'll solve them, without bothering Andreas because they are Pharo specific. But he can't also, by the same Open source nature, restrict the uses of the code)." I don't think the problem was that the package is part of PharoCore. I think the problem was that Andreas wasn't asked about the inclusion and the package was forked and maintained in PharoCore. Levente "We all, greatly respect and admire his technical ability, that has never been denied. But his public interactions has more than one burned a lot of people, and this no-license issue is becoming one of them. We don't want tramps like that of the missing license. When the code was announced it was a public encourage to use it and test it, but we as community went to happy and without checking the license it was included in pharo. That was our error. So please, Andreas, if you want WebClient to be open source please do it, Pharo will use it and send you patches. If not say it too, and we'll find an alternative for this. Cheers -- 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 "

Aug. 30, 2010

[Pharo-project] UbiquiTalk running in Pharo 1.1

by Sean P. DeNigris

I haven't done much with it, and there are some deprecation warnings, but it's running. In the attached screenshot, the "host 2" entry in the "Detected Hosts" window is the Squeak 4.1 image running on the right. http://forum.world.st/file/n2400767/Screen_shot_2010-08-30_at_August_30%2C_… Screen_shot_2010-08-30_at_August_30%2C_2010_5.47.42_PM.png Load it with: Gofer new squeaksource: 'KomHttpServer'; package: 'DynamicBindings'; load. Gofer new squeaksource: 'KomHttpServer'; package: 'KomServices'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'rST'; load. Gofer new squeaksource: 'OSProcess'; package: 'OSProcess'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Platform.pharo'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Cache'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-GUI'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Utilities'; load. "requires Utilities" Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Kernel'; load. "requires Kernel" Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Plugins'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-PDA'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Property Editors'; load. Gofer new squeaksource: 'SPDProjectUpdates'; package: 'UbiquiTalk-Tests'; load. "requires platform" Gofer new squeaksource: 'UbiquiTalk'; package: 'UTAllServices'; load. Sean -- View this message in context: http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2400767.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 30, 2010

Re: [Pharo-project] Pharo-project Digest, Vol 28, Issue 282

by James Ladd

Hi Eliot, I cant use those thinks because im not in Smalltalk at the time, im in Java on the JVM. (Did someone say 'challenge') I thought about the store question in the shower this morning and I think it means take the top of the stack but dont pop it. Please let me know if Im wrong? Rgs, James. > Hi James, > > perhaps you could use the implementations of > ContextPart pushRemoteTemp:inVectorAt: popIntoRemoteTemp:inVectorAt: > storeIntoRemoteTemp:inVectorAt: > (& Interpreter pushRemoteTemp:inVectorAt: popIntoRemoteTemp:inVectorAt: if > you have them to hand) as the spec and check the documentation. The intent > is that k..k is the index of the temp containing the remote vector and j..j > is the index in the remote temp vector. > > cheers > Eliot >

Aug. 30, 2010

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

by Levente Uzonyi

On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > This mailing-list is a public space. There are web archives all over the places and > people can post without been in it. I want to avoid personal emails exchange. > Now what should we run after him? Because the set up is like that no? > Because I'm extremely busy so nobody has the luxury not to be not busy still I spent > my morning trying to communicate. Just CC him. Levente > > > Stef > _______________________________________________ > 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

This mailing-list is a public space. There are web archives all over the places and people can post without been in it. I want to avoid personal emails exchange. Now what should we run after him? Because the set up is like that no? Because I'm extremely busy so nobody has the luxury not to be not busy still I spent my morning trying to communicate. Stef

Aug. 30, 2010

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

by Nicolas Cellier

2010/8/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > 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. > Sure, one thing is to remove WebClient and fulfill Andreas request. One other is to refuse to open discussion and engage a rewrite immediately. >> 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. > You don't have to shout in the desert. Just mail Andreas, he claimed not being informed. > >> 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. > The past is the past. Maybe there were clumsyness from both sides... I can't know. One thing is sure, without communication, no possible agreement. >> >> 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 > Certainly, you don't have to convince me :). You might have to convince Andreas (I don't see him in copy). Maybe let another Pharoer negotiate... cheers Nicolas > > _______________________________________________ > 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 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