- Pharo-dev - lists.pharo.org

[Pharo-project] User Interrupt Broken?!

by Sean P. DeNigris

Has anyone else noticed this? Open a fresh 2.0482 latest and hit Cmd-. a bunch of times. If the debugger opens on the first, close it and keep pressing the shortcut. Most presses seem to do nothing. -- View this message in context: http://forum.world.st/User-Interrupt-Broken-tp4664619.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013

Re: [Pharo-project] Closing unresolved issues

by Sean P. DeNigris

StÃ©phane Ducasse wrote > The problem is what do we do if we have many bugs with nobody looking at > them. Maybe a good compromise would be a status like "Stale", where we can exclude them from searches if we want, but they are still being tracked? -- View this message in context: http://forum.world.st/Closing-unresolved-issues-tp4664420p4664618.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013

Re: [Pharo-project] DocTest

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > I am attending a python lecture and discovered DocTest[1], and I was > wondering if such a tool exists for Pharo ? :) I've been dreaming about, and doing experiments around, this for quite a while... could be so much better in st because we can create custom UI tools instead of text files... -- View this message in context: http://forum.world.st/DocTest-tp4664547p4664617.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013

Re: [Pharo-project] Object>>#name

by Gary Chambers

+1 to removal... Regards, Gary ----- Original Message ----- From: "Sean P. DeNigris" <sean(a)clipperadams.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, January 22, 2013 5:02 PM Subject: Re: [Pharo-project] Object>>#name > Sven Van Caekenberghe-2 wrote >> Many people have hit the fact that Object implements #name, which then >> seems to conflict with some other class where one would really like to >> use >> name as an instance variable and thus accessor. > > Yes, I've been bitten by this a few times. When developing through the > debugger, it's confusing when the thing fails silently instead of > prompting > to create the method. > > > Sven Van Caekenberghe-2 wrote >> Turns out that it seems that Object>>#name is actually not used >> (anymore). > > There are lots of senders... I guess they're sending Class>>#name or > another > message. I say ditch it, but wait until 3.0... > > > > -- > View this message in context: > http://forum.world.st/Object-name-tp4664573p4664583.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 22, 2013

Re: [Pharo-project] Object>>#name

by StÃ©phane Ducasse

> Sven Van Caekenberghe-2 wrote >> Many people have hit the fact that Object implements #name, which then >> seems to conflict with some other class where one would really like to use >> name as an instance variable and thus accessor. > > Yes, I've been bitten by this a few times. When developing through the > debugger, it's confusing when the thing fails silently instead of prompting > to create the method. > > > Sven Van Caekenberghe-2 wrote >> Turns out that it seems that Object>>#name is actually not used (anymore). > > There are lots of senders... I guess they're sending Class>>#name or another > message. I say ditch it, but wait until 3.0â¦ + 1 Open a bug entry for 3.0 Stef > > > > -- > View this message in context: http://forum.world.st/Object-name-tp4664573p4664583.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 22, 2013

Re: [Pharo-project] What are the messages where we should always have a super send?

by StÃ©phane Ducasse

On Jan 22, 2013, at 7:19 AM, Jan Vrany wrote: > Hi, > > On 19/01/13 10:16, StÃ©phane Ducasse wrote: >> Hi jan >> >> do you have an example of such tagging? > > Look at > > RBTranslateLiteralsInMenusRule class>>tagsBasic, > RBNilOrEmptyCollectionReplaceRule, > RBMethodSourceContainsLinefeedRule, > RBTempsReadBeforeWrittenRile > RBLawOfDemeterRule > RBContainsNamespaceIdentifiersRule > > at > > http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ > > Some comment on tagging > > http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RB… Ok It is a good idea. What is the license of the changes you did? And sorry but we do not want to have author in comment for the moment :) > Could you please give me a pointer where newest Lint for Pharo > lives? For now it lives in Pharo20. Once we migrate for real to smalltalkHub I want to have subprojects for RB, SmallLint. We tried for while to have none disruptive changes by putting changes as extensions of code critics but it does not work for cleaning the rules. Stef > > > Cheers, Jan > > > >> Right now we are also thinking that we want three kinds of rules >> - 1 whose result is either zero because there is no problem or zero because we flag the false positives >> - 2 more fuzzy one where we should have flase positive defined per package >> - 3 more statistical rules (long methods, large number of instance variables) >> >> We are checking how we can find decent threshold values not generating thousands of warnings and >> also if we want to embed false positives for them too. May be they are just good for trend analysis and >> when you want to spot ugly code but you do not care to have them under your nose systematically. >> >> For the rules I'm also changing the implementation to make sure that we can customized the list of selectors, thresholds â¦. >> without having to recompile a method. This way people will be able to use their own conventions. >> >> Stef >> >> On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote: >> >>> Hi Stef, >>> >>> while massaging SmallLint rules, you should also have look at >>> Smalltalk/X version of SmallLint [1] as we have ported >>> Pharo version and improved some rules. I have also added >>> a tagging system. That's useful for some rules are only >>> good if you want to ensure portable code, some are simply >>> broken and some stupid, etc. Having them properly classified >>> would help us all. >>> >>> Tell me once you finish your ride, I'll merge changes back :-) >>> >>> Jan >>> >>> [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ >>> >>> to checkout issue: >>> >>> cvs -d :pserver:cvs@cvs.smalltalk-x.de:/cvs/stx co stx/goodies/refactoryBrowser/lint/ >>> >>> >>> On 18/01/13 17:06, StÃ©phane Ducasse wrote: >>>> Hi >>>> >>>> While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a >>>> super send. >>>> >>>> Here is the current list: >>>> >>>> ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) >>>> >>>> >>>> and I'm cleaning the list because there are VW elements such as postBuildWith: >>>> but do we have some other to add? >>>> >>>> Stef >>>> >>>> >>>> >>> >>> >> >> >> > >

Jan. 22, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by Mariano Martinez Peck

On Tue, Jan 22, 2013 at 1:19 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > yeah, I declare my self guilty for having that incredibly ugly idea... :) > > heheheheh :) As you see (and I thanked in the email) Esteban has been helping me here. And then he will merge and integrate :) > On Jan 21, 2013, at 3:35 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Sat, Jan 19, 2013 at 1:08 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > >> Mariano Martinez Peck wrote >> > thanks Square [i] International <http://www.square-i.net/> >> > ... headless support will be included in the official Pharo >> > VM and will be, therefore, accessible to everybody. >> >> Yes, thank you, thank you!! I've been using Pharo for Jenkins build >> scripts, >> and it was really disruptive to see the image pop up every time a job >> started. >> >> As to the flag limitation, I think for now I'll have two copies of the VM >> - >> a headful one, which will be the default on my Mac, and one with the >> headless flag set, that gets explicitly launched by Jenkins... not >> perfect, >> but a HUGE step!! >> > > Yes, that's the easiest way. > I spent *a lot* of time trying to find another way, but they all failed. > There is one possibility that should work but it is too hacky for me: > very at the beginning of the VM (before starting Cocoa) read the > arguments. If "-headless" is present, then programmatically set/write the > flag in the Info.plist. If it it not, do nothing (or set it to false). But > modifying the file on startup looks hacky to me. I prefer the user to > manually set it. > > >> Cheers, >> Sean >> >> >> >> -- >> View this message in context: >> http://forum.world.st/ANN-Headless-support-for-Cog-Cocoa-VM-tp4664137p46642… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Jan. 22, 2013

Re: [Pharo-project] [Issue Tracker] Status

by Sean P. DeNigris

FixToInclude: http://code.google.com/p/pharo/issues/detail?id=7207 -- View this message in context: http://forum.world.st/Issue-Tracker-Status-tp4664590p4664606.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013

Re: [Pharo-project] Closing unresolved issues

by StÃ©phane Ducasse

Thanks for your feedback. Sean and I understand your frustration. The problem is what do we do if we have many bugs with nobody looking at them. > For example... > Issue 5656: Large fonts make tools slow > http://code.google.com/p/pharo/issues/detail?id=5656 > > This issue has not been resolved, but the issue was closed, leading to this > experience... > - I just upgraded a project to 2.0 > - I notice that the UI is very slow - a simple Spec dialog window with a few > text fields and buttons takes ~4 seconds to open > - I check the issue tracker because I remember I reported the bug already, > but I don't find it in the open issues > - I waste time because I think it must be something else > - I finally expand my search through the issues and find my report was > closed as invalid > > I'm not saying that this is wrong, just that I don't understand and want to > share another perspective and come to the best solution... What benefit are > we getting from closing these that is significant enough to justify this > kind of experience (I'm sure I'm not the only one). > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/Closing-unresolved-issues-tp4664420.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 22, 2013

Re: [Pharo-project] Fonts in Pharo By Example

by StÃ©phane Ducasse

On Jan 21, 2013, at 11:57 AM, Sean P. DeNigris wrote: > It would be great to have a section in PBE2 about fonts. I find them very > confusing - TrueType, FreeType, Logical, etc. Understanding how they're > handled in Pharo requires background knowledge, and an overview and a few > specific examples could really do some good. If somebody explain it It would be great. I always wanted to read something on fonts but unfortunately I feel a bit alone on the writing side This is why I love the attitude of sven to produce doc. Stef > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 22, 2013