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

Re: [Pharo-project] [Moose-dev] Re: Redirect compiler warnings to file

by StÃ©phane Ducasse

I hope that Opal will pay attention to such a point. Stef >> Indeed, that's one way it works. It seems like Encoder typically generates this kind of message (Undeclared and shadowed variable) in a few places.

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] Redirect compiler warnings to file

by StÃ©phane Ducasse

This is why I would like to have a real log infrastructure in place because Transcript does not really scale. Stef On Sep 5, 2010, at 8:52 PM, Simon Denier wrote: > Hi > > When loading large chunks of code (like Moose), some warnings appear in the Transcript. The problem is the Transcript has a limited size and that with all information dumped into, the first one get lost before we can take a look at them. > > Does anyone know a way to capture/redirect the Transcript output to a file, or the output from Compiler (maybe using the requestor parameter?) > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Sept. 5, 2010

[Pharo-project] UDP Broadcast Problems on Mac

by Philippe Marschall

Hi I have some code that listens to UDP broadcasts. It works on Linux but on the Mac it never receives anything (the first element in the array is zero *sigh*). This is with Pharo 1.1 and Cog but also happens on Pharo 1.0 without Cog. The code looks more or less like this: socket := Socket newUDP. socket setPort: 23364. buffer := String new: 65507. [ socket isValid ] whileTrue: [ | datagramm | datagramm := socket receiveUDPDataInto: buffer ] The broadcast happens to 224.0.1.105 on port 23364, tcpdump picks up the packes on lo0. I could provide tcpdump output or steps to set up sever that sends the broadcasts. Cheers Philippe

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] Re: Redirect compiler warnings to file

by Simon Denier

On 5 sept. 2010, at 20:55, NicolÃ¡s Paez wrote: > Up to what I saw, the class the writes to the Transcript is : UndeclaredVariableWarning>>defaultAction. > But it is possible some other classes do the same. Indeed, that's one way it works. It seems like Encoder typically generates this kind of message (Undeclared and shadowed variable) in a few places. > > Saludos! > Nico. > blog: nicopaez.wordpress.com > > > On Sun, Sep 5, 2010 at 8:52 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > Hi > > When loading large chunks of code (like Moose), some warnings appear in the Transcript. The problem is the Transcript has a limited size and that with all information dumped into, the first one get lost before we can take a look at them. > > Does anyone know a way to capture/redirect the Transcript output to a file, or the output from Compiler (maybe using the requestor parameter?) > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] Redirect compiler warnings to file

by NicolÃ¡s Paez

Up to what I saw, the class the writes to the Transcript is : UndeclaredVariableWarning>>defaultAction. But it is possible some other classes do the same. Saludos! Nico. blog: nicopaez.wordpress.com On Sun, Sep 5, 2010 at 8:52 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > Hi > > When loading large chunks of code (like Moose), some warnings appear in the > Transcript. The problem is the Transcript has a limited size and that with > all information dumped into, the first one get lost before we can take a > look at them. > > Does anyone know a way to capture/redirect the Transcript output to a file, > or the output from Compiler (maybe using the requestor parameter?) > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

Sept. 5, 2010

[Pharo-project] Redirect compiler warnings to file

by Simon Denier

Hi When loading large chunks of code (like Moose), some warnings appear in the Transcript. The problem is the Transcript has a limited size and that with all information dumped into, the first one get lost before we can take a look at them. Does anyone know a way to capture/redirect the Transcript output to a file, or the output from Compiler (maybe using the requestor parameter?) -- Simon

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Tudor Girba

Hi Stef, I am not sure what you are referring to (and I am not sure you are looking at the right screenshot). There is blue/lightblue to focus you on what is the current selection (tab, button, selected text). I did not use it for embellishments because that is much harder to get right, and I really wanted to get as much as possible with only 2 base colors and 2-3 shades. Cheers, Doru On 5 Sep 2010, at 19:10, StÃ©phane Ducasse wrote: > tx > Doru don;t you want to put a bit of blue in the look instead of all > this grey. > > Stef > > On Sep 5, 2010, at 11:23 AM, Sven Van Caekenberghe wrote: > >> >> On 05 Sep 2010, at 09:54, StÃ©phane Ducasse wrote: >> >>> screenshots PLEASE! >> >> http://homepage.mac.com/svc/Screenshots/ >> Screenshot-20100905T111347.png >> >> Doru, >> >> I made the #baseSelectionColor almost black (I didn't like the >> blue, de gustibus non est disputandum ;-) by overwriting it: >> >> baseSelectionColor >> ^ "Color r: 0.38 g: 0.64 b: 0.88" Color darkGray muchDarker >> >> I could subclass as well I guess, or you could make it into a >> variable with a setter, what do you think ? >> >> Anyway, very well done, it feels very fast, which was a goal I >> presume. >> >> Sven >> >> PS: the name is a nice pun too! >> _______________________________________________ >> 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 -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Tudor Girba

Hi Stephan, Is this for Pro or for Glamorous? Cheers, Doru On 5 Sep 2010, at 20:24, Stephan Eggermont wrote: > Sven wrote: >> Sorry: if you switch to the Pro theme > > The example basic controls shows the following issues: > - Default button looks smaller because the blue > border is (imperfectly) written over the black outline. > - Selected Disabled Button is unreadable. The contrast > between the gray text and the blue background is too low. > It could be improved by using outline style. > - The gradient is blue is much stronger than that in black. > I would say the black needs more lights. The buttons > contrast too much with the light gray background. > - The disabled checkbox misses a line at the top > - Borders of button, checkbox and radiobutton should > look similarly sharp. Now the button looks sharp, > while the others look blurry. The same goes for > drop lists, normal lists and text editor. > - Vertical spacing between the radiobuttons is inconsistent. > - Text Entry looks like it has more height when disabled. > This is due to the top gradient of the non-disabled one. > - Disabled slider handle is too dark. > - Backgound color for Text Entry, Slider, List (s) and > Text editor should be the same for disabled state. > The same goes for disabled text foreground color. > Why has disabled drop list a different text color than > a disabled text entry? > - Lists should have the same corner as text entry. > - Drop list button has the V a-symmetrical. > - Difference between normal list and disabled list > is too small. > - The border between scroll bar buttons and light gray > background is not enough pronounced. > > Stephan > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Stephan Eggermont

Sven wrote: > Sorry: if you switch to the Pro theme The example basic controls shows the following issues: - Default button looks smaller because the blue border is (imperfectly) written over the black outline. - Selected Disabled Button is unreadable. The contrast between the gray text and the blue background is too low. It could be improved by using outline style. - The gradient is blue is much stronger than that in black. I would say the black needs more lights. The buttons contrast too much with the light gray background. - The disabled checkbox misses a line at the top - Borders of button, checkbox and radiobutton should look similarly sharp. Now the button looks sharp, while the others look blurry. The same goes for drop lists, normal lists and text editor. - Vertical spacing between the radiobuttons is inconsistent. - Text Entry looks like it has more height when disabled. This is due to the top gradient of the non-disabled one. - Disabled slider handle is too dark. - Backgound color for Text Entry, Slider, List (s) and Text editor should be the same for disabled state. The same goes for disabled text foreground color. Why has disabled drop list a different text color than a disabled text entry? - Lists should have the same corner as text entry. - Drop list button has the V a-symmetrical. - Difference between normal list and disabled list is too small. - The border between scroll bar buttons and light gray background is not enough pronounced. Stephan

Sept. 5, 2010

[Pharo-project] Key bindings bug in Windows

by Stanislav Paskalev

Hi, using the 1.1 image, whenever I type shift+"Ð¾" (Cyrillic/Bulgarian letter O) on Windows, instead creating a character, it looks like it's recognized as shift+upper arrow - it moves a line above selecting text. (it works fine when I type it in say notepad, also works ok when pasted into Pharo) If I remember correctly - this didn't happen when I was using Pharo under debian, so it's probably a platform issue. Regards, Stanislav Paskalev

Sept. 5, 2010