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

Re: [Pharo-project] DuplicatedVariableError: styler is already defined in PluggableTextMorph

by Sven Van Caekenberghe

On 13 Jan 2011, at 09:26, StÃ©phane Ducasse wrote: > Here is the current draft of documentation around metacello. People often complain that there is no doc > but writing doc is also a full time jobwe are trying to address. > > Feedback is welcomed and source is on github. > <Metacello.pdf> > > Symbolic versions are really draft version. > Stef Yeah, I found that too, it looks quite nice. I was justing printing it out this morning to read this evening. And yes, I really appreciate such documentation work, it is very hard work. Thank you, Mariano ! Sven

Jan. 13, 2011

Re: [Pharo-project] Issue 3535 in pharo: I broke SpaceTally in Pharo 1.2

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3535 by stephane.ducasse: I broke SpaceTally in Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3535 in 12300

Jan. 13, 2011

Re: [Pharo-project] [update 1.2] #12297

by Sven Van Caekenberghe

On 13 Jan 2011, at 01:26, Igor Stasenko wrote: > Kewl.. Orange is much much better. > > I modified it a little. Check it out The 'underline' for selected buttons is very nice. I don't see much (or any) difference in the orange. Although I don't really like the blue (it is a bit soft), it matches better with the Pharo logo (and we won't be changing that I think). Sven

Jan. 13, 2011

Re: [Pharo-project] Dirty MC Packages in Pharo-1.1.1-OneClickCogVM

by StÃ©phane Ducasse

why do you need method wrapper in dev? Again this goes with my mail about pushing metacello dsitributions versus pharo-dev+++ Stef On Jan 12, 2011, at 10:15 PM, Mariano Martinez Peck wrote: > yes, that was a hack I had to do becuase at that moment Cog didn't support well objects as methods, used by MethodWrappers, and when running its tests, it crashed. > we wanted to create a quick image so that people could start using cog and help testing it. > > this is not the case anymore in Pharo 1,2 > > so, if someone wants, the real solution is to create a new one click of 1.1.1 (without touching by hand method wrappers) and put new CogVMs. > > cheers > > mariano > > On Wed, Jan 12, 2011 at 8:10 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > 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 > > >

Jan. 13, 2011

Re: [Pharo-project] DuplicatedVariableError: styler is already defined in PluggableTextMorph

by StÃ©phane Ducasse

> There is a fix already submitted to PharoTaskForces. Where what bug entry? > If you download the last version from the metacello config, it should load well :). > > Cheers! > > On Wed, Jan 12, 2011 at 4:05 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > 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 > > >

Jan. 13, 2011

Re: [Pharo-project] DuplicatedVariableError: styler is already defined in PluggableTextMorph

by StÃ©phane Ducasse

Here is the current draft of documentation around metacello. People often complain that there is no doc but writing doc is also a full time jobwe are trying to address. Feedback is welcomed and source is on github. Symbolic versions are really draft version. Stef

Jan. 13, 2011

Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)

by StÃ©phane Ducasse

Martin did you check with squeak? because I have the impression that andreas fixed a bit some code. This is on our (igor) to do for 1.3 or 1.4 or 1.3 if somebody join and help. Noury and luc started to rewrite from scratch the sockets but I do not know the status. Stef On Jan 12, 2011, at 7:13 PM, mkobetic(a)gmail.com wrote: > I started looking at the Socket failures that I can reproduce and I can't wrap my head around the SocketReadingWritingTest>>setUp. Based on what I know about TCP sockets it doesn't make sense to me. AFAIK to get both ends of a connected TCP connection (lacking a socketpair call) I need 3 sockets. A listening socket, a client socket (doing connect) and finally the server socket that comes out as a result of accept on the listener. So I'd expect to see something like this in the setUp: > > | data input output listener socket1 socket2 process sync | > Socket initializeNetwork. > sync := Semaphore new. > listener := Socket newTCP. > listener listenOn: 9999. > process := [ [ socket1 := listener accept ] ensure: [ listener close ]. sync signal ] fork. > socket2 := Socket newTCP. > socket2 connectTo: (NetNameResolver localHostAddress) port: 9999. > sync wait. > output := socket1 reading. > input := socket2 writing. > > Surprisingly, the above doesn't work, while many of the Socket tests seem to pass for me despite my brain telling me that it can't possibly. Can anyone shed some light on this for me ? > > Thanks, > > Martin > >

Jan. 13, 2011

Re: [Pharo-project] [update 1.2] #12297

by StÃ©phane Ducasse

indeed igor this is nice. Doru may be you could take this change for your look? Stef On Jan 13, 2011, at 1:26 AM, Igor Stasenko wrote: > On 12 January 2011 23:17, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 12 Jan 2011, at 22:12, Igor Stasenko wrote: >> >>> Ubuntu changes its skin every single release.. and i am pretty sure >>> that there are >>> books, screencasts, screnshots, tutorials, etc for Ubuntu as well. >>> >>> (btw i think they established really good tradition, because people >>> could quickly distinguish one version from another >>> by simply taking a glance on the screen) >> >> Good point: new look == new version >> >> The compatibility point is also good. >> >> The OS independence point is also good. >> >>> Get used to live in ever changing world :) >>> >>>> you, and all Pharo advanced users can easily change the theme, and you >>>> probbaly even have a script prepare that you run in each clean image to >>>> adapt it to your taste. >>> >>> UIThemeWatery2 beCurrent. >>> >>> be my guest :) http://bit.ly/gi7vb7 >>> >>> >>>> But I think we should make the life easier for new comers. >>>> In addition, it was never discussed in the mailing list such change (at >>>> least I didn't see it). >>>> >>> >>> i agree, it is better to discuss broadly before changing. >>> >>> I like the glamourous theme because it is minimalistic and elegant. >>> Still the colors are a bit wrong as to my taste, especially selection >>> (light blue). >> >> I made my own subclass overriding 3 color constants to orange. >> 'Sven-Glamour-Theme' @ SqueakSource project ADayAtTheBeach. >> > > Kewl.. Orange is much much better. > > I modified it a little. Check it out > >> Sven >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > <GLMUITheme2.st>

Jan. 13, 2011

Re: [Pharo-project] How to bundle an application with icons?

by StÃ©phane Ducasse

I know that fernando was building an infrastructure for icons. But I did not see him recently on the list. Stef On Jan 12, 2011, at 3:50 PM, Dimitry Golubovsky wrote: > 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 >

Jan. 13, 2011

Re: [Pharo-project] Maybe bug in ZnHttpClient

by StÃ©phane Ducasse

Thanks a lot sven. I really like your spirit. Engaging, addressing problems.... so great. Stef On Jan 12, 2011, at 2:10 PM, Sven Van Caekenberghe wrote: > Hello Tony, > > (I am CC'ing the Pharo list) > > On 11 Jan 2011, at 23:48, Tony Fleig wrote: > >> Hi Sven, >> >> At Stef's suggestion I am trying Zinc in place of WebClient in my >> automated testing of my Seaside apps. >> >> I like Zinc better already and I can see that I will need fewer lines >> of code using Zinc than WebClients for my purposes. > > That is great! Thanks for trying Zn and for giving feedback. > > BTW, I really liked your writeup about testing (and I was thinking/hoping all the time, he should be using Zn ;-) > >> That said, I have found I think a bug. >> >> Pharo 1.1.1 Seaside 3.0.3 Zinc latest >> >> In ZnHttpClient>>#method:for:headers:data:limit, if a 302 response is >> received, the Location header field may not contain a complete URL >> (i.e. it may not contain scheme://host:port but only the path). When >> this happens, the next ZnHttpClient>>#openConnection fails in >> NetNameResolver trying to resolve a nil hostname. >> >> This occurs when the server is Seaside. >> >> I have solved this by setting followRedirect to false and handling the >> redirect myself (as I as doing with WebClient anyway.) > > Well, strictly speaking it isn't a bug (the specs say that the Location URL has to be absolute), but you are right: there is common support for relative redirect locations, so I added that (did not yet test it though). > >> Some other observations: >> >> 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 ? > >> 2. The arguments to the settings accessors in ZnUserAgentSettings are >> all anObject. Wouldn't aBoolean and anInteger be more informative >> names (for followRedirect: and redirectLimit: for example)? I was >> stopped when I saw anObject and went perusing the sources to be sure >> that what was wanted was a boolean and not something more complex. > > You're right, proper parameter names are helpful, I changed some of them. > > I went over the ZnUserAgent and ZnClient classes (they were originally written by Matt Kennedy). I made various simplifications and cleanups (most related to newer API) which might help when reading the code. I also made an important change/bugfix regarding query parameters (originally reported by CÃ©dric BÃ©ler I think). > > Thanks again for the feedback, if you have any more questions, feel free to ask them. > > Sven > >> 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.114 >> Author: SvenVanCaekenberghe >> Time: 12 January 2011, 2:03:44 pm >> UUID: e1a49d00-d9f0-4800-8cd7-cb354e86d671 >> Ancestors: Zinc-HTTP-SvenVanCaekenberghe.113 >> >> ZnUserAgent (and ZnClient) now can follow relative redirect locations; >> introduced ZnMultiValueDictionary to allow multiple values to be stored under one key as an array; >> using ZnMultiValueDictionary for queries and headers; >> ZnUrl now uses ZnUtils>>parseQueryFrom: again; >> various simplifications and cleanups which might help when reading the code in ZnUserAgent (and ZnClient); >> ZnUserAgent (and ZnClient) now handle parameter encoding differently > > >

Jan. 13, 2011