- Pharo-dev - lists.pharo.org

[Pharo-project] DuplicatedVariableError: styler is already defined in PluggableTextMorph
by Sven Van Caekenberghe Jan. 13, 2011

Jan. 13, 2011

When trying to do: Gofer new renggli: 'omnibrowser'; package: 'OmniBrowser'; package: 'OB-Standard'; package: 'OB-Morphic'; package: 'OB-Shout'; package: 'OB-Refactory'; package: 'OB-Regex'; package: 'OB-SUnitIntegration'; load (Part of the build scripts of LR's builder scripting package) I get the following error: DuplicatedVariableError: styler is already defined in PluggableTextMorph while loading the definitiion of OBPluggableTextMorphWithShout in PharoCore 1.2 #12294. I have seen some things flying around on the mailinglist related indirectly to this issue. Is there a solution ? Thx, Sven

3 8

[Pharo-project] about text selection colors in 1.2
by Alain Plantec Jan. 13, 2011

Jan. 13, 2011

Hi all, A friend of mine told me that it was very difficult for him to see the difference between the green and the blue colors. (Color blindness...) So, I would suggest to change the secondary selection color (green) to another color. What do you think ? which color ? Cheers Alain

5 7

[Pharo-project] [update 1.2] #12297
by Torsten Bergmann Jan. 13, 2011

Jan. 13, 2011

Stef wrote: >indeed igor this is nice. >Doru may be you could take this change for your look? Do you really think this orange is an improvement? See attached comparision. Do we want to go back to colorfull "toy" style a la Squeak? UI always depends on personal style but we should take care to keep it looking professional. We should really hire a designer! Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

6 6

[Pharo-project] Fwd: Zinc HTTP Components: Zinc-HTTP-SvenVanCaekenberghe.116.mcz
by Sven Van Caekenberghe Jan. 13, 2011

Jan. 13, 2011

Thanks, Tony, for reporting this! Sven Begin forwarded message: > From: squeak-dev-noreply(a)lists.squeakfoundation.org > Date: 13 Jan 2011 14:39:04 GMT+01:00 > To: sven(a)beta9.be, arturus(a)gmail.com > Subject: [SPAM] Zinc HTTP Components: Zinc-HTTP-SvenVanCaekenberghe.116.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > Sven Van Caekenberghe uploaded a new version of Zinc-HTTP to project Zinc HTTP Components: > http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenbergh… > > ==================== Summary ==================== > > Name: Zinc-HTTP-SvenVanCaekenberghe.116 > Author: SvenVanCaekenberghe > Time: 13 January 2011, 1:39:01 pm > UUID: a102bbdc-8185-41b0-afa2-4d0af8f2557a > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.115 > > changed the redirect behavior for POST/PUT requests: the common practice is to turn these into GET request, see ZnUserAgent>>#method:for:headers:data:imit: and ZnUserAgent>>#prepareRedirect: On 12 Jan 2011, at 20:34, Tony Fleig wrote: > My interpretation of what is intended by 303 is that server is saying > that the resource requested by the POST has been found (or generated) > and may be obtained by GETting the URI in the Location header field. > > This is in fact what happens all the time in Seaside. The POST request > performs the callbacks, essentially changing the server state, and > returns 302. The client then does a GET to retrieve a page that > reflects the changed server state. Seaside should probably return 303 > to be in compliance with the spec, but pre HTTP 1.1 browsers may not > recognize 303, so I guess that's why it is like it is. > > I think the 303 required behavior is clear. ZnHttpClient should do a > GET after receiving a 303 response. 302 is less clear because of the > incorrect behavior of most browsers. For 302 I suppose a setting would > make sense to allow either the common browser behavior or the strict > interpretation of the specification behavior. > > Regards, > TF > > RFC 2616 Excerpt: > > 10.3.3 302 Found > > The requested resource resides temporarily under a different URI. > Since the redirection might be altered on occasion, the client SHOULD > continue to use the Request-URI for future requests. This response > is only cacheable if indicated by a Cache-Control or Expires header > field. > > The temporary URI SHOULD be given by the Location field in the > response. Unless the request method was HEAD, the entity of the > response SHOULD contain a short hypertext note with a hyperlink to > the new URI(s). > > If the 302 status code is received in response to a request other > than GET or HEAD, the user agent MUST NOT automatically redirect the > request unless it can be confirmed by the user, since this might > change the conditions under which the request was issued. > > Note: RFC 1945 and RFC 2068 specify that the client is not allowed > to change the method on the redirected request. However, most > existing user agent implementations treat 302 as if it were a 303 > response, performing a GET on the Location field-value regardless > of the original request method. The status codes 303 and 307 have > been added for servers that wish to make unambiguously clear which > kind of reaction is expected of the client. > > 10.3.4 303 See Other > > The response to the request can be found under a different URI and > SHOULD be retrieved using a GET method on that resource. This method > exists primarily to allow the output of a POST-activated script to > redirect the user agent to a selected resource. The new URI is not a > substitute reference for the originally requested resource. The 303 > response MUST NOT be cached, but the response to the second > (redirected) request might be cacheable. > > The different URI SHOULD be given by the Location field in the > response. Unless the request method was HEAD, the entity of the > response SHOULD contain a short hypertext note with a hyperlink to > the new URI(s). > > Note: Many pre-HTTP/1.1 user agents do not understand the 303 > status. When interoperability with such clients is a concern, the > 302 status code may be used instead, since most user agents react > to a 302 response as described here for 303. > > On Wed, Jan 12, 2011 at 10:44 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 12 Jan 2011, at 19:03, Tony Fleig wrote: >> >>> Oops. >>> >>> My reply escaped before I was finished. >>> >>>>> 1. It is my understanding that many browsers respond to a 302/303 >>>>> response from a POST with a following GET to the address specified in >>>>> the 302/303 Location header rather than repeating the POST with its >>>>> payload as is done in ZnHttpClient. (See >>>>> http://en.wikipedia.org/wiki/HTTP_303) >>>> >>>> I'll have to study/think about that for a while, it depends on what the specs says. It doesn't make much sense for an automated client to do a GET I think. What would you suggest ? >>> >>> RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) says >>> >>> 10.3.4 303 See Other >>> >>> The response to the request can be found under a different URI and >>> SHOULD be retrieved using a GET method on that resource. >>> >>> so I think we should do a GET ;) . >>> >>> Regards, >>> TF >> >> OK, it is in the spec then but only for 303 ? >> >> But suppose you programmatically try to POST something somewhere and the server tells you to do that on another URL, if you then GET that URL, you haven't fullfilled the original goal of posting something somewhere. As a human, you will probably see another form and start over. >> >> Anyway I think it is an edge case (unless you have a real usecase), we could maybe make it an option/setting ? >> >> Sven >> >

1 0

[Pharo-project] [update 1.2] #12297
by Torsten Bergmann Jan. 13, 2011

Jan. 13, 2011

Tudor Girba >I tried to start from zero and add a new variable (e.g., color) only when I >could not distinguish something If that is true then why do you use the additional blue for activated buttons instead of using a gray one: lightSelectionColor ^ Color gray in your original theme - you can distinguish buttons already using the gray-style gradient (see attached example). However ... all of this is very specific to a particular persons view of the world. As you said you've choosen blue since it is the color of Moose... Bye T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

2 1

Re: [Pharo-project] [Seaside] Re: html parser
by Tudor Girba Jan. 13, 2011

Jan. 13, 2011

Thanks. Doru On 13 Jan 2011, at 10:55, Francois Stephany wrote: > Soup ? > http://www.squeaksource.com/Soup > >> Is there a robust html parser in Pharo? As I understand, there would be one in VW called TwoFlowers, but I do not know the license. > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- www.tudorgirba.com "Don't give to get. Just give."

2 1

[Pharo-project] Dirty MC Packages in Pharo-1.1.1-OneClickCogVM
by Sven Van Caekenberghe Jan. 13, 2011

Jan. 13, 2011

Yesterday I downloaded Pharo-1.1.1-OneClickCogVM from https://gforge.inria.fr/frs/download.php/27524/Pharo-1.1.1-OneClickCogVM.zip and I noticed it has two dirty MC packages (MethodWrappers and Tests). This is probably a glitch, but not nice and confusion for beginners. Sven

4 3

[Pharo-project] How to bundle an application with icons?
by Dimitry Golubovsky Jan. 13, 2011

Jan. 13, 2011

Hi, Suppose I need to bundle a Pharo application (a package) I am developing with some custom icons: is there any "standard"/ agreed-upon method to do that in Pharo? For example the MenuIcons class includes byte strings (automatically I assume) converted from some external PNG files that show up as icons with menu items: which tool can be used to create a class with set of icons for an arbitrary application? If I want to reuse icons for standard actions in my application, which is the proper way to access menu icons other than to directly access these stored images? Thanks. PS Other than the "by example" books (both Squeak and Pharo) which give some basics of building GUI for applications, are there any general guidelines for GUI building in these systems? -- Dimitry Golubovsky Anywhere on the Web

3 3

[Pharo-project] Xtreams up to date
by mkobetic＠gmail.com Jan. 13, 2011

Jan. 13, 2011

Hope it's OK to cross-post this, I figured there might be interested people on both sides. I finished the updates of the Xtreams port to match the VW version, so everything (that is available) should work as advertised in the documentation (http://code.google.com/p/xtreams/) Besides the implementation updates this last round of changes includes: * repackaging to match the docs and VW better, the dialect specific parts are now (mostly) gathered in Xtreams-Support * there is now a Gofer expression on the project page (http://www.squeaksource.com/Xtreams.html) to help people loading it, it shouldn't be hard to keep it up to date it shouldn't change very much * the source code is now identical between the dialects as much as possible, to help keeping it up to date. * one significant API change is that we renamed XTIncomplete to Incomplete to make code that uses Xtreams more portable. This is the only class that is very prominent in the API and hard to avoid in any sufficiently complex application, hopefully this is acceptable. I don't anticipate any significant changes in the port for next little while. I'd like to play with Squeak FFI next to see if I can bring the cryptographic streams from Xtreams-Xtras over and then see what it would take to get Xtreams-SSH2 running on Squeak and how it would perform. If you're curious how it went on VW side, I wrote about that in a blog post here: http://www.cincomsmalltalk.com/userblogs/cst/blogView. If you find bugs or issues, feel free to file an issue on the google project page (http://code.google.com/p/xtreams/issues/list) I'm monitoring both of these lists now as well and will try to answer any questions promptly. Cheers! Martin

3 2

Jan. 13, 2011

- Issue 3537: Addinf inst average size to SpaceTally. Thanks Mariano Martinez-Peck. - Issue 3530: New pass on RML + new tool for inspecting Senders. Thanks Benjamin van Ryseghem.

1 0