- Pharo-dev - lists.pharo.org

last time I had insomnia...

by Esteban Lorenzano

so, I spend some time doing this: Gofer it smalltalkhubUser: 'estebanlm' project: 'IconsForPharo'; package: 'Polymorph-Icons-Idea'; load. ThemeIcons current: IdeaUIThemeIcons new. AbstractNautilusUI resetIconCaches. (you will need to reopen all your windows) The coolness of this icons set is that they work very fine with Dark Theme too :) Pharo3DarkTheme installFullTheme. It is still incomplete, but thatâs mostly because: a) I need to work for real now :) b) I need to catch up with latest icons from GTools guys Enjoy :) Screenshots:

April 28, 2015

Re: [Pharo-dev] Collecting user data

by Tommaso Dal Sasso

+1 for me. Having a centralized way of managing data submission would simplify things a lot for people collecting data, but also for users who could check in one place all the kind of data they send. Tommaso On 28/04/15 14:31, Andrei Chis wrote: > Yes, some level of unification would be nice, especially for the part > about users agreeing to send usage data and persisting that setting. > Also at least two general levels of details about what data is being > send that tools should follow would help (full anonymous vs. include > class names/method names ?). > Last but not least, a single entry point for sending that data over the > network would help. > > How data is collected/stored will differ from tool to tool, but agreeing > on the previous aspects would make it much easier to collect data. > > Cheers, > Andrei > > On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > > On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com > <mailto:yuriy.tymchuk@me.com>> wrote: > > > > Hi guys, > > > > from time to time we have to collect a usage data in order to > improve our tools. For example Iâd like to collect data in future > about how do you treat code critics: do they occur, do you outfox > them, do you mark them as false positives? If we had answers to > these questions, we could really make good and helpful critics. > > > > For now I know that there are 3 projects which collect data: > > - GTSpotter > > - Shoreline > > - DFlow (not in image by default). > > > > Should I make 4th data collection for QualityAssistant? Or maybe > we can do some unification? > > > > I would love unification! > > Itâs not only good for the researchers, but even for the user: I do > not want to decide 5 times to give data to research, > but I want to decide it onceâ¦ > > Marcus > > >

April 28, 2015

Re: [Pharo-dev] Collecting user data

by Andrei Chis

Yes, some level of unification would be nice, especially for the part about users agreeing to send usage data and persisting that setting. Also at least two general levels of details about what data is being send that tools should follow would help (full anonymous vs. include class names/method names ?). Last but not least, a single entry point for sending that data over the network would help. How data is collected/stored will differ from tool to tool, but agreeing on the previous aspects would make it much easier to collect data. Cheers, Andrei On Tue, Apr 28, 2015 at 1:18 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > Hi guys, > > > > from time to time we have to collect a usage data in order to improve > our tools. For example Iâd like to collect data in future about how do you > treat code critics: do they occur, do you outfox them, do you mark them as > false positives? If we had answers to these questions, we could really make > good and helpful critics. > > > > For now I know that there are 3 projects which collect data: > > - GTSpotter > > - Shoreline > > - DFlow (not in image by default). > > > > Should I make 4th data collection for QualityAssistant? Or maybe we can > do some unification? > > > > I would love unification! > > Itâs not only good for the researchers, but even for the user: I do not > want to decide 5 times to give data to research, > but I want to decide it onceâ¦ > > Marcus > > >

April 28, 2015

Re: [Pharo-dev] sometimes Shout changes the selection during styling

by Andrei Chis

I made an issue: https://pharo.fogbugz.com/f/cases/15422/SHTextStyler-styleInBackgroundProce… Then do we add waitTimeoutSeconds:ifSignalled:ifTimedOut: to the Semaphore class? On Mon, Apr 27, 2015 at 6:33 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > That would work for me. Styling the text if the process doing the styling > did not finish or is stuck does not feel as the right thing to do. > > On Mon, Apr 27, 2015 at 6:25 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Mon, Apr 27, 2015 at 8:41 PM, Andrei Chis <chisvasileandrei(a)gmail.com> >> wrote: >> >>> Hi, >>> >>> In the glamour debugger that we use in moose we are now having the >>> following problem: >>> - the selection of a PluggableTextMorph is, quite randomly , changed >>> during styling. >>> >>> If I revert the fix for issue 15240 >>> <https://pharo.fogbugz.com/f/cases/15240> then it works ok. >>> Also if I change in SHTextStyler>>#styleInBackgroundProcess: from >>> >>> sem waitTimeoutSeconds: 5. >>> view ifNotNil: [ view stylerStyledInBackground: text ] >>> >>> to: >>> >>> (sem waitTimeoutSeconds: 5) ifFalse: [ >>> view ifNotNil: [ view stylerStyledInBackground: text ] ] >>> >>> it works ok. In the second snippet we only do the styling if the styler >>> completed. >>> >>> >>> If I look at the senders of styleInBackgroundProcess: there is another >>> strange issue. >>> First PluggableTextMorph>>#setText: calls either style: >>> or styleInBackgroundProcess:, depending in the size of the text. >>> Then, PluggableTextMorph>>#setText: >>> calls PluggableTextMorph>>#setTextBasic:, which calls >>> PluggableTextMorph>>#hasUnacceptedEdits: which in turn >>> calls again styleInBackgroundProcess:. >>> So when you set the text if the size of the text is small Shout will try >>> to style the text with and without a background process. If you call >>> hasUnacceptedEdits: >>> manually when initializing the morph then three processes will be >>> started for doing the styling. >>> >>> Removing the calls to styleInBackgroundProcess: from >>> PluggableTextMorph>>#hasUnacceptedEdits: and >>> PluggableTextMorph>>#basicHasUnacceptedEdits:. >>> also solves the problem with the changing selection. >>> >>> Cheers, >>> Andrei >>> >> >> Perhaps we should have... >> >> sem >> waitTimeoutSeconds: 5 >> ifSignalled: [ view ifNotNil: [ view stylerStyledInBackground: >> text ] ] >> ifTimedOut: [ "do nothing" ]. >> >> cheers -ben >> > >

April 28, 2015

[pharo-project/pharo-core] 33103f: 50016

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 33103f3872a122c77a9e9ea9be3cb790e92bc73a https://github.com/pharo-project/pharo-core/commit/33103f3872a122c77a9e9ea9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-28 (Tue, 28 Apr 2015) Changed paths: M Collections-Sequenceable.package/Interval.class/instance/accessing/indexOf_startingAt_ifAbsent_.st A Deprecated50.package/StartupLoader.class/README.md A Deprecated50.package/StartupLoader.class/class/acessing/default.st A Deprecated50.package/StartupLoader.class/definition.st A Deprecated50.package/StartupLoader.class/instance/acessing/contents.st A Deprecated50.package/StartupLoader.class/instance/initialization/initialExtent.st A Deprecated50.package/StartupLoader.class/instance/initialization/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script624.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script625.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50015.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50016.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHRBTextStyler.class/instance/visiting rb nodes/visitMethodNode_.st M SmartSuggestions.package/SugsBrowseClassReferences.class/instance/as yet unclassified/execute.st Log Message: ----------- 50016 15421 fix offset in SHRBTextStyler https://pharo.fogbugz.com/f/cases/15421 15300 MNU: Association>>adaptToNumber:andSend: https://pharo.fogbugz.com/f/cases/15300 15398 Deprecated StartupLoader should present migration instructions https://pharo.fogbugz.com/f/cases/15398 15405 Suggestion menu SystemNavigation(Object)>>doesNotUnderstand: #browseClassRefsOf: https://pharo.fogbugz.com/f/cases/15405 http://files.pharo.org/image/50/50016.zip

April 28, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50016 Home: https://github.com/pharo-project/pharo-core

April 28, 2015

Re: [Pharo-dev] Are these changes good enough

by Marcus Denker

> I will add an issue for Pharo5 and itegrate there first for testing. > Done and integrated. > (And later we can use this as an example for the new reflective features of Pharo5â¦ > Right now this is implemented with a simple compiled method wrapper, which we can > replace with a meta-link on the method later). > This will then allow us to even do it not just for methods, but per AST-Node, too. Marcus

April 28, 2015

Re: [Pharo-dev] Collecting user data

by Marcus Denker

> On 28 Apr 2015, at 11:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi guys, > > from time to time we have to collect a usage data in order to improve our tools. For example Iâd like to collect data in future about how do you treat code critics: do they occur, do you outfox them, do you mark them as false positives? If we had answers to these questions, we could really make good and helpful critics. > > For now I know that there are 3 projects which collect data: > - GTSpotter > - Shoreline > - DFlow (not in image by default). > > Should I make 4th data collection for QualityAssistant? Or maybe we can do some unification? > I would love unification! Itâs not only good for the researchers, but even for the user: I do not want to decide 5 times to give data to research, but I want to decide it onceâ¦ Marcus

April 28, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50015 Home: https://github.com/pharo-project/pharo-core

April 28, 2015

[pharo-project/pharo-core] 8abfe4: 50015

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8abfe4eb7b84262637dd24ef77e6ebb2d947cba8 https://github.com/pharo-project/pharo-core/commit/8abfe4eb7b84262637dd24ef… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-28 (Tue, 28 Apr 2015) Changed paths: M Polymorph-Widgets.package/UITheme.class/class/installing/installFullTheme.st M SUnit-UI.package/TestRunner.class/instance/accessing-ui/buttons.st M SUnit-UI.package/TestRunner.class/instance/actions/collectCoverageFor_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script623.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script624.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50014.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50015.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TClass.class/instance/instance variables/removeInstVarNamed_.st Log Message: ----------- 50015 15420 Forward port 15417 TestRunner does not offer the RunCoverage functionality https://pharo.fogbugz.com/f/cases/15420 15419 Pharo3Theme installFullTheme background is too dark https://pharo.fogbugz.com/f/cases/15419 15424 #removeInstVarNamed: should just call #removeSlot: https://pharo.fogbugz.com/f/cases/15424 http://files.pharo.org/image/50/50015.zip

April 28, 2015