April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pool dictionary cause problems to load package from monticello

by Mariano Martinez Peck

YEs, what Guille mentions is from GlorpTest from VW. Do you know if in VW they still use PoolDictionaries instead of shared pools? thanks On Sat, Apr 16, 2011 at 10:14 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > You should use a SharedPool > Have a look at what we did for TextConstant. > PoolDictionaries are not stored as dictionary in Squeak since ages. > > Stef > > On Apr 16, 2011, at 10:06 PM, Guillermo Polito wrote: > > > Hi! > > > > I have a class who has a pool dictionary defined as > > > > ... subclass: #MyClass > > instanceVariableNames: '' > > classVariableNames: '' > > poolDictionaries: 'MyPoolDict' > > .. > > > > And when I load that class from monticello, he warns me with > > > > This package depends on the following classes: > > "MyPoolDict" > > You must resolve these dependencies before you will be able to load these > definitions: > > > > If before loading the package I declare a global named MyPoolDict it > loads well... > > > > Of course, I can put a preload in a metacello configuration to declare > the global, but it sucks :). > > > > Can anyone point me in the right direction? (or maybe it's a bug... :/) > > > > Thanks! > > Guille > > > -- Mariano http://marianopeck.wordpress.com

April 16, 2011

Re: [Pharo-project] Issue 3573 in pharo: Failing Test: CompiledMethodTest.testPerformInSuperclassCanExecutelongMethodWithTemps

by pharo＠googlecode.com

Comment #2 on issue 3573 by marcus.d...(a)gmail.com: Failing Test: CompiledMethodTest.testPerformInSuperclassCanExecutelongMethodWithTemps http://code.google.com/p/pharo/issues/detail?id=3573 This test checks for a VM bug. I think we should not have it in the image, but instead have an issue with the test attached.

April 16, 2011

Re: [Pharo-project] Pool dictionary cause problems to load package from monticello

by Guillermo Polito

Thanks Stef for the quick response :)! I'll try and comment later! Thanks On Sat, Apr 16, 2011 at 10:14 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > You should use a SharedPool > Have a look at what we did for TextConstant. > PoolDictionaries are not stored as dictionary in Squeak since ages. > > Stef > > On Apr 16, 2011, at 10:06 PM, Guillermo Polito wrote: > > > Hi! > > > > I have a class who has a pool dictionary defined as > > > > ... subclass: #MyClass > > instanceVariableNames: '' > > classVariableNames: '' > > poolDictionaries: 'MyPoolDict' > > .. > > > > And when I load that class from monticello, he warns me with > > > > This package depends on the following classes: > > "MyPoolDict" > > You must resolve these dependencies before you will be able to load these > definitions: > > > > If before loading the package I declare a global named MyPoolDict it > loads well... > > > > Of course, I can put a preload in a metacello configuration to declare > the global, but it sucks :). > > > > Can anyone point me in the right direction? (or maybe it's a bug... :/) > > > > Thanks! > > Guille > > >

April 16, 2011

Re: [Pharo-project] Pool dictionary cause problems to load package from monticello

by StÃ©phane Ducasse

You should use a SharedPool Have a look at what we did for TextConstant. PoolDictionaries are not stored as dictionary in Squeak since ages. Stef On Apr 16, 2011, at 10:06 PM, Guillermo Polito wrote: > Hi! > > I have a class who has a pool dictionary defined as > > ... subclass: #MyClass > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: 'MyPoolDict' > .. > > And when I load that class from monticello, he warns me with > > This package depends on the following classes: > "MyPoolDict" > You must resolve these dependencies before you will be able to load these definitions: > > If before loading the package I declare a global named MyPoolDict it loads well... > > Of course, I can put a preload in a metacello configuration to declare the global, but it sucks :). > > Can anyone point me in the right direction? (or maybe it's a bug... :/) > > Thanks! > Guille

April 16, 2011

[Pharo-project] Pool dictionary cause problems to load package from monticello

by Guillermo Polito

Hi! I have a class who has a pool dictionary defined as ... subclass: #MyClass instanceVariableNames: '' classVariableNames: '' poolDictionaries: 'MyPoolDict' .. And when I load that class from monticello, he warns me with * This package depends on the following classes: "MyPoolDict" You must resolve these dependencies before you will be able to load these definitions: * If before loading the package I declare a global named MyPoolDict it loads well... Of course, I can put a preload in a metacello configuration to declare the global, but it sucks :). Can anyone point me in the right direction? (or maybe it's a bug... :/) Thanks! Guille

April 16, 2011

Re: [Pharo-project] Status of WebClient for Pharo?

by StÃ©phane Ducasse

I heard some rumors (private mails) telling me that you are right :) Stef On Apr 16, 2011, at 7:51 PM, Jan van de Sandt wrote: > Hello Friedrich, > > I used WebClient and SqueakSSL om Pharo 1.1 a few months ago. WebClient works but SqueakSSL had some problems. It didn't work with some hosts (like Yahoo) and some features were missing on OSX. > > Now I use Zinc HTTP as a web client on Pharo. For SSL support I use stunnel. This needs some setup but works very well [1]. > > Jan. > > [1] http://blog.doit.st/2011/02/23/cloudforksso-on-pharo-with-stunnel/ > > On Sat, Apr 16, 2011 at 6:56 PM, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > Dear Pharo developers, can you tell me about the status of WebClient in > Pharo. (well and if you know it would be nice to know if SqueakSSL is > "working", or "working in principal" or "not working.) > > Or do you have other suggestions for accessing the diverse Web services > with Pharo? > > Regards > Friedrich > >

April 16, 2011

Re: [Pharo-project] About Zinc to replace HTTPClient

by StÃ©phane Ducasse

On Apr 16, 2011, at 7:44 PM, Jan van de Sandt wrote: > Hello, > > Yes, CloudforkSSO has support for OAuth1, AOuth2 and OpenID. Cloudfork uses Zinc as HTTP client library. Works very well. Excellent news. Thanks for the information. > > Indeed, SSL is not supported directly. But using stunnel [1] is a good workaround for this. > > Jan. > > [1] http://blog.doit.st/2011/02/23/cloudforksso-on-pharo-with-stunnel/ > > > > On Sat, Apr 16, 2011 at 5:37 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 16.04.2011 um 15:13 schrieb GermÃ¡n Arduino: > > > I would like to know exactly what features will provide Zn and which not. > > > What do you mean with features? > > > As I remember form the past was not planned to support for example > > https, which prevent to use OAuth and OpenID, very needed to develop > > any interaction against any modern web site. > > > Zinc is http handling components. Https is just a http request over a transparently initiated SSL connection. So if you have SSL you have https. It is not the duty of an http component to support SSL. A url handler needs to integrate existing SSL. > As far as I remember the cloudfork guys have OAuth running. So they must have SSL. So it shouldn't be to hard to do the same with zinc. Just exchange the http handling routines. > > Norbert > > > 2011/4/16 Norbert Hartl <norbert(a)hartl.name>: > >> > >> Am 15.04.2011 um 22:12 schrieb StÃ©phane Ducasse: > >> > >>> Hi guys > >>> > >>> we discuss with sven about strategies to get a better infrastructure and the HTTP level. > >>> Sven would like to have feedback on Zinc before pushing it in Pharo :) > >>> So can you let us know. What we could do it to have it in a preview in 1.3 > >>> then in 1.4 remove HTTPClient (or friend). > >> > >> This is really good. To me (meaning IMHO) it is one of the most missing functionalities in pharo. Zinc is really great and so much better than _anything_ in pharo that pretends to do HTTP. I would like to see it that we don't talk about HTTP but about proper MIME based communication. I think the very core that is in there is the structured and flexible mime media handling and communication. And this is not only true for HTTP but also for email. > >> I would like to see that Zinc creeping into the image bringing the mime stuff along. Than the mime stuff should break loose of the Zinc components and should replace the mime handling that is in the image. Than we have it for http and for mail sending and for every other transport protocol you can imagine. > >> And now that Paul ported zinc to gemstone you can develop good http handlers that are easily ported to gemstone. What a wonderful world! > >> And seaside? Well, if the current http adaptors are much faster than zinc than there should be shortcut path through zinc that allows fast handling of the minimal stuff seaside needs. The same problem goes for the WARequest stuff. Using zinc you can get access to the mime parts. Now WARequest is a strange request object that contains a dictionary for request parameters and a raw message body. If only compatibility is important than a zinc to old WARequest handling is needed. But I would like to see the mime based handling to be the "normal" way of doing and not vice versa. But I can see that it must be a special treatment as seaside is ported to so many platforms that don't have zinc. Probably one reasone more to extract the mime stuff. It might be a promininent candidate other platforms adopt. > >> > >> my two cents, > >> > >> Norbert > >> > >> > >> > > > > >

April 16, 2011

Re: [Pharo-project] About Zinc to replace HTTPClient

by StÃ©phane Ducasse

On Apr 16, 2011, at 5:45 PM, Norbert Hartl wrote: > > Am 16.04.2011 um 15:52 schrieb Mariano Martinez Peck: > >> I have a couple of question, not about Zn but the process: >> >> 1) Stef, you are talking about just to put Zn in the image or REPLACE all uses of HTTP to use Zn? > > I would hope so. I think it would be easy to provide a facade with the current API that uses Zinc. I do not think that we need such facade. >> 2) It may be difficult to replace that since Monticello use it -> be carfeul ! > > If I remember correctly Sven has tested monticello from an early stage on. And it seems to be a reliable thing to use. Sven uses it dialy for MC. >> 3) How are you going to depreacate HTTP? > > What do you mean? The HTTP classes in Network-Protocols or http the protocol) :) > >> 4) Does Zn mantains the same API as HTTP ? what happen with external packages? will the API change? >> > I don't like the current API at all and I'm glad Zinc is different. But for legacy purposes a facade should be easy to implement that resembles the existing one. which legacy :) ? > On the long run some of the calls should vanish and only the httpGet: and friends should survive to offer a really really easy and basic access to http. exactly. Let us move on. Stef > > my 2 cents, > > Norbert > >> Cheers >> >> Mariano >> >> On Sat, Apr 16, 2011 at 3:13 PM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: >> I would like to know exactly what features will provide Zn and which not. >> >> As I remember form the past was not planned to support for example >> https, which prevent to use OAuth and OpenID, very needed to develop >> any interaction against any modern web site. >> >> Cheers. >> GermÃ¡n. >> >> >> 2011/4/16 Norbert Hartl <norbert(a)hartl.name>: >> > >> > Am 15.04.2011 um 22:12 schrieb StÃ©phane Ducasse: >> > >> >> Hi guys >> >> >> >> we discuss with sven about strategies to get a better infrastructure and the HTTP level. >> >> Sven would like to have feedback on Zinc before pushing it in Pharo :) >> >> So can you let us know. What we could do it to have it in a preview in 1.3 >> >> then in 1.4 remove HTTPClient (or friend). >> > >> > This is really good. To me (meaning IMHO) it is one of the most missing functionalities in pharo. Zinc is really great and so much better than _anything_ in pharo that pretends to do HTTP. I would like to see it that we don't talk about HTTP but about proper MIME based communication. I think the very core that is in there is the structured and flexible mime media handling and communication. And this is not only true for HTTP but also for email. >> > I would like to see that Zinc creeping into the image bringing the mime stuff along. Than the mime stuff should break loose of the Zinc components and should replace the mime handling that is in the image. Than we have it for http and for mail sending and for every other transport protocol you can imagine. >> > And now that Paul ported zinc to gemstone you can develop good http handlers that are easily ported to gemstone. What a wonderful world! >> > And seaside? Well, if the current http adaptors are much faster than zinc than there should be shortcut path through zinc that allows fast handling of the minimal stuff seaside needs. The same problem goes for the WARequest stuff. Using zinc you can get access to the mime parts. Now WARequest is a strange request object that contains a dictionary for request parameters and a raw message body. If only compatibility is important than a zinc to old WARequest handling is needed. But I would like to see the mime based handling to be the "normal" way of doing and not vice versa. But I can see that it must be a special treatment as seaside is ported to so many platforms that don't have zinc. Probably one reasone more to extract the mime stuff. It might be a promininent candidate other platforms adopt. >> > >> > my two cents, >> > >> > Norbert >> > >> > >> > >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

April 16, 2011

Re: [Pharo-project] About Zinc to replace HTTPClient

by StÃ©phane Ducasse

On Apr 16, 2011, at 3:52 PM, Mariano Martinez Peck wrote: > I have a couple of question, not about Zn but the process: > > 1) Stef, you are talking about just to put Zn in the image or REPLACE all uses of HTTP to use Zn? what would be the point? Key a crappy implementation? For what purpose > 2) It may be difficult to replace that since Monticello use it -> be carfeul ! No sven already use it since months for that > 3) How are you going to depreacate HTTP? ? Simply. Fixing all the clients. > 4) Does Zn mantains the same API as HTTP ? Why should it be? > what happen with external packages? They will have time to migrate. > will the API change? probably since the current one is plain bad. > > Cheers > > Mariano > > On Sat, Apr 16, 2011 at 3:13 PM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > I would like to know exactly what features will provide Zn and which not. > > As I remember form the past was not planned to support for example > https, which prevent to use OAuth and OpenID, very needed to develop > any interaction against any modern web site. > > Cheers. > GermÃ¡n. > > > 2011/4/16 Norbert Hartl <norbert(a)hartl.name>: > > > > Am 15.04.2011 um 22:12 schrieb StÃ©phane Ducasse: > > > >> Hi guys > >> > >> we discuss with sven about strategies to get a better infrastructure and the HTTP level. > >> Sven would like to have feedback on Zinc before pushing it in Pharo :) > >> So can you let us know. What we could do it to have it in a preview in 1.3 > >> then in 1.4 remove HTTPClient (or friend). > > > > This is really good. To me (meaning IMHO) it is one of the most missing functionalities in pharo. Zinc is really great and so much better than _anything_ in pharo that pretends to do HTTP. I would like to see it that we don't talk about HTTP but about proper MIME based communication. I think the very core that is in there is the structured and flexible mime media handling and communication. And this is not only true for HTTP but also for email. > > I would like to see that Zinc creeping into the image bringing the mime stuff along. Than the mime stuff should break loose of the Zinc components and should replace the mime handling that is in the image. Than we have it for http and for mail sending and for every other transport protocol you can imagine. > > And now that Paul ported zinc to gemstone you can develop good http handlers that are easily ported to gemstone. What a wonderful world! > > And seaside? Well, if the current http adaptors are much faster than zinc than there should be shortcut path through zinc that allows fast handling of the minimal stuff seaside needs. The same problem goes for the WARequest stuff. Using zinc you can get access to the mime parts. Now WARequest is a strange request object that contains a dictionary for request parameters and a raw message body. If only compatibility is important than a zinc to old WARequest handling is needed. But I would like to see the mime based handling to be the "normal" way of doing and not vice versa. But I can see that it must be a special treatment as seaside is ported to so many platforms that don't have zinc. Probably one reasone more to extract the mime stuff. It might be a promininent candidate other platforms adopt. > > > > my two cents, > > > > Norbert > > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

April 16, 2011

Re: [Pharo-project] Issue 3387 in pharo: Package name should not contain crptic characters

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #9 on issue 3387 by marcus.d...(a)gmail.com: Package name should not contain crptic characters http://code.google.com/p/pharo/issues/detail?id=3387 (No comment was entered for this change.)

April 16, 2011