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

Re: [Pharo-project] The video about Athens

by Sean P. DeNigris

Igor Stasenko wrote > > this is strange. calling this function should simply work, since it > belongs to VM plugin. > Can you send me a stack trace? > Even stranger... now it's working! Maybe I just needed to restart after loading cairo... Looks *really* coooool!! Thanks. Sean -- View this message in context: http://forum.world.st/The-video-about-Athens-tp4571100p4578012.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 22, 2012

Re: [Pharo-project] Unresponsive 1.4 image

by Sean P. DeNigris

Sean P. DeNigris wrote > > Opening a browser got much slower the bigger I made my fonts, esp. the > code font it seemed... Opened issue http://code.google.com/p/pharo/issues/detail?id=5656 ... this seems like a different problem than the freezing... Sean -- View this message in context: http://forum.world.st/Unresponsive-1-4-image-tp4574693p4577994.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 22, 2012

Re: [Pharo-project] The video about Athens

by Igor Stasenko

On 21 April 2012 14:03, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sean P. DeNigris wrote >> >> I get Generic failure >> Â Â fnSpec: #(#bool #ioRegisterSurface #(#ulong #aCairoSurfaceHandle #, >> #void #* #sqSurfaceDispatchPtr #, #int #* #idHolder)) >> Â Â module: #SurfacePlugin >> Â Â errorCode: 1 >> > > Igor, I guess you didn't run into this on Mac... any ideas why it's still > not working? > this is strange. calling this function should simply work, since it belongs to VM plugin. Can you send me a stack trace? > Sean > > -- > View this message in context: http://forum.world.st/The-video-about-Athens-tp4571100p4576317.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 22, 2012

[Pharo-project] Kernel jobs for 2.0

by Pavel Krivanek

Hi, I created Kernel jobs for the version 2.0. It uses separate set of scripts so new big changes will not break 1.4. https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/ Now is pointless to run them because 2.0 repository doesn't include all packages. Some things that should be done: - start Trello board for 2.0 ;-) - the package Deprecated 14 should be replaced by Deprecated20. - integrate basic Fuel packages (Fuel, FuelMetalevel, FuelPackageLoader + tests) -- Pavel

April 22, 2012

Re: [Pharo-project] Suggestion: introducing a fixme/issue/todo pragma

by StÃ©phane Ducasse

we use self flag: #fixMe you can then query either #fixMe or flag: and yes this is a good idea to mark things and create bug entries. Stef On Apr 22, 2012, at 11:18 AM, phil(a)highoctane.be wrote: > While looking around in the image, I am in need of knowing where I found thngs that either puzzle me or are "wrong" (well, a code smell). > > What I do is that I put pragmas in there like this (not that this sample is meant to be representative) > > privCleanTextConstants > <fixme> > TextConstants TextSharedInformation removeKey: #DefaultTextStyle. > TextConstants TextSharedInformation removeKey: #DefaultMultiStyle. > TextConstants TextSharedInformation removeKey: #DefaultFixedTextStyle. > TextConstants TextSharedInformation removeKey: StrikeFont defaultFontKey. > > Smalltalk allClasses select: [:c | c sharedPools includes: TextConstants] thenDo: [:c | c compileAll ]. > > And I can then find back the things with: > > pc := (PragmaCollector filter: [:prg | prg keyword = 'fixme']) reset. > pc collected size. "(Print It: 1)" > pc collected explore. > > And then finding back the Class and Method Name > > Building upon that, why not do what is done in other environments (well, I've got that in PHP, Java, ...) and use: > > <todo:do this and that> or plain <todo> > <fixme: this and that> or plain <fixme> > <issue:issue#> > > And have a specific tool to help the navigation (explore is fine for a moment but...) > > This would allow us to have an idea on the technical debt inside the system, broken down by areas if we start leveraging Packages. > > What I do not know is how much stress this would put on the system. Are pragmas eating a lot or a just markers? > > Phil >

April 22, 2012

Re: [Pharo-project] [squeak-dev] Re: [ANN] Physical Etoys 2.0 released!

by Ben Coman

April 22, 2012

[Pharo-project] Suggestion: introducing a fixme/issue/todo pragma

by phil＠highoctane.be

While looking around in the image, I am in need of knowing where I found thngs that either puzzle me or are "wrong" (well, a code smell). What I do is that I put pragmas in there like this (not that this sample is meant to be representative) privCleanTextConstants <fixme> TextConstants TextSharedInformation removeKey: #DefaultTextStyle. TextConstants TextSharedInformation removeKey: #DefaultMultiStyle. TextConstants TextSharedInformation removeKey: #DefaultFixedTextStyle. TextConstants TextSharedInformation removeKey: StrikeFont defaultFontKey. Smalltalk allClasses select: [:c | c sharedPools includes: TextConstants] thenDo: [:c | c compileAll ]. And I can then find back the things with: pc := (PragmaCollector filter: [:prg | prg keyword = 'fixme']) reset. pc collected size. "(Print It: 1)" pc collected explore. And then finding back the Class and Method Name Building upon that, why not do what is done in other environments (well, I've got that in PHP, Java, ...) and use: <todo:do this and that> or plain <todo> <fixme: this and that> or plain <fixme> <issue:issue#> And have a specific tool to help the navigation (explore is fine for a moment but...) This would allow us to have an idea on the technical debt inside the system, broken down by areas if we start leveraging Packages. What I do not know is how much stress this would put on the system. Are pragmas eating a lot or a just markers? Phil

April 22, 2012

Re: [Pharo-project] Unresponsive 1.4 image

by phil＠highoctane.be

http://code.google.com/p/pharo/issues/detail?id=5654 2012/4/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > So much for people with accessibility issues (like me). > > > > Strike fonts have a future... I was playing with Cuis 4 and there seems > to be no problem with big font in there. Nor speed. > > May be this is just a problem with the cache size. > Open a bug entry so that we do not forget. > > > Stef > > > Damn. > > > > 2012/4/22 Sean P. DeNigris <sean(a)clipperadams.com> > > > > Sean P. DeNigris wrote > > > > > > small -> 212 msec > > > huge -> 1491 msec > > > > > > > I should've also mentioned: > > very large -> 232 msec > > huge, but code font at 18pt > > - 241 msec > > - **GCs**... incr 17 totalling 27ms (12.0% uptime), avg 2.0ms > > - 8.3% {19ms} NautilusWindow(Morph)>>fullBounds > > very large, but code font at 24pt > > - 1551 msec > > - **GCs**... incr 174 totalling 383ms (25.0% uptime), avg 2.0ms > > - 59.5% {923ms} NautilusWindow(Morph)>>doLayoutIn: > > > > So having a "huge" i.e. 24pt code font is definitely one of the issues... > > > > -- > > View this message in context: > http://forum.world.st/Unresponsive-1-4-image-tp4574693p4577286.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > -- > > Philippe Back > > "Helping you hit the top 3 outcomes you really want to achieve" > > > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > > http://philippeback.be > > > > High Octane SPRL > > rue cour Boisacq 101 > > 1301 Bierges > > > > > -- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges

April 22, 2012

Re: [Pharo-project] Unresponsive 1.4 image

by StÃ©phane Ducasse

> So much for people with accessibility issues (like me). > > Strike fonts have a future... I was playing with Cuis 4 and there seems to be no problem with big font in there. Nor speed. May be this is just a problem with the cache size. Open a bug entry so that we do not forget. Stef > Damn. > > 2012/4/22 Sean P. DeNigris <sean(a)clipperadams.com> > > Sean P. DeNigris wrote > > > > small -> 212 msec > > huge -> 1491 msec > > > > I should've also mentioned: > very large -> 232 msec > huge, but code font at 18pt > - 241 msec > - **GCs**... incr 17 totalling 27ms (12.0% uptime), avg 2.0ms > - 8.3% {19ms} NautilusWindow(Morph)>>fullBounds > very large, but code font at 24pt > - 1551 msec > - **GCs**... incr 174 totalling 383ms (25.0% uptime), avg 2.0ms > - 59.5% {923ms} NautilusWindow(Morph)>>doLayoutIn: > > So having a "huge" i.e. 24pt code font is definitely one of the issues... > > -- > View this message in context: http://forum.world.st/Unresponsive-1-4-image-tp4574693p4577286.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges >

April 22, 2012

Re: [Pharo-project] System announcements and MC

by StÃ©phane Ducasse

I di not check (just wake up) but the announcement of system announcement are normally just wrapping the systemChangeNotifier. We will start to work on removing SystemChangeNotifier. So there are probably cases that were not well covered by systemNotifier or some bugs inside. Stef On Apr 22, 2012, at 1:34 AM, Sean P. DeNigris wrote: > I subscribed to the ClassModifiedClassDefinition announcement to be notified > when an inst var is added to a class, but I get notifications when MC is > loading things. This seems like a very different type of event than when one > manually adds an inst var via the browser, but I don't see a way to tell > which is happening based on the contextual info the announcement gives me. > > Sean > > -- > View this message in context: http://forum.world.st/System-announcements-and-MC-tp4577351p4577351.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 22, 2012