Re: [Pharo-dev] About a better filedialog

Preview is indeed not supported. My original idea was to show a regular GTInspector view on the file, but I never got around to implementing it. On Tue, Mar 19, 2019 at 8:36 PM Hilaire wrote: > For DrGeo, when loading a sketch from an arbitrary location, I use the > preview feature of the

Re: [Pharo-dev] About a better filedialog

For DrGeo, when loading a sketch from an arbitrary location,  I use the preview feature of the polymorph File Dialog. I don't see it in this simple replacement of File Dialog. Hilaire Le 18/03/2019 à 20:31, ducasse a écrit : > what do you think? > > https://github.com/Ducasse/file-dialog

[Pharo-dev] [Pharo 8.0] Build #160: 2918-accessesSlot: should use #isAccessedIn: method

There is a new Pharo build available! The status of the build #160 was: SUCCESS. The Pull Request #2919 was integrated: "2918-accessesSlot: should use #isAccessedIn: method" Pull request url: https://github.com/pharo-project/pharo/pull/2919 Issue Url:

Re: [Pharo-dev] About a better filedialog

and there are tests. We should check the UIManager dependency. For now I just make it works in P7 Stef > On 19 Mar 2019, at 09:50, Guillermo Polito wrote: > > YES! > > On Mon, Mar 18, 2019 at 11:13 PM ducasse > wrote: > Yes I had to rename ComposableModel

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

Indeed I do not even know what means initialize in a testCase. Stef > On 19 Mar 2019, at 17:28, Max Leske wrote: > > On 19 Mar 2019, at 16:16, Gabriel Cotelli wrote: > >> If you don't clean up the instance variables, when you have a lot of tests >> and a test runner is still open on the

Re: [Pharo-dev] About a better filedialog

Ah, I probably need to add dependency on the Spec Compat library for P6.1 On Tue, Mar 19, 2019 at 9:50 AM Guillermo Polito wrote: > YES! > > On Mon, Mar 18, 2019 at 11:13 PM ducasse wrote: > >> Yes I had to rename ComposableModel into ComposablePresenter so this is >> probably that >> >> On 18

[Pharo-dev] [Pharo 8.0] Build #159: Also work with Text as label

There is a new Pharo build available! The status of the build #159 was: SUCCESS. The Pull Request #2921 was integrated: "Also work with Text as label" Pull request url: https://github.com/pharo-project/pharo/pull/2921 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url:

[Pharo-dev] [Pharo 8.0] Build #158: 2900-deprecate-whichSelectorsAssign-for-whichSelectorsStoreInto

There is a new Pharo build available! The status of the build #158 was: SUCCESS. The Pull Request #2906 was integrated: "2900-deprecate-whichSelectorsAssign-for-whichSelectorsStoreInto" Pull request url: https://github.com/pharo-project/pharo/pull/2906 Issue Url:

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

On 19 Mar 2019, at 16:16, Gabriel Cotelli wrote: If you don't clean up the instance variables, when you have a lot of tests and a test runner is still open on the results all this garbage is still referenced (because the test results keeps a reference to the original test case instance) and

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

If you don't clean up the instance variables, when you have a lot of tests and a test runner is still open on the results all this garbage is still referenced (because the test results keeps a reference to the original test case instance) and the image keeps growing like crazy. I can tell you for

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

Max Leske wrote > To answer your question: yes that has been the case for a long time. The > same is true for #runCase BTW. Only #setUp is sent after #tearDown (see > #prepareToRunAgain). > > Max That's weird. RunCase sends a setUp, a tearDown and cleanUpInstanceVariables. So the test will be

[Pharo-dev] [Pharo 8.0] Build #157: 2889-baselineOfTelePharoSupport

There is a new Pharo build available! The status of the build #157 was: FAILURE. The Pull Request #2892 was integrated: "2889-baselineOfTelePharoSupport" Pull request url: https://github.com/pharo-project/pharo/pull/2892 Issue Url: https://pharo.fogbugz.com/f/cases/2889 Build Url:

[Pharo-dev] [Pharo 8.0] Build #156: 2901-ClassBuilder-fillFor-should-not-use-classVariablesString

There is a new Pharo build available! The status of the build #156 was: SUCCESS. The Pull Request #2905 was integrated: "2901-ClassBuilder-fillFor-should-not-use-classVariablesString" Pull request url: https://github.com/pharo-project/pharo/pull/2905 Issue Url:

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

> On 19 Mar 2019, at 12:22, Esteban Lorenzano wrote: > > The GitHub criteria is that issue reporters are not the ones that can > distribute/label/recognise the areas of the reported issue, and that should > be done by “admins”. > > I wonder if instead trying to fix the issue, we couldn’t

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

Yes, it can not be completely public or it will be vandalised. > On 19 Mar 2019, at 12:17, Serge Stinckwich wrote: > > but you need to be on the Pharo organization to be able to add/modify card on > the board ? > A+ > > On Tue, Mar 19, 2019 at 11:07 AM Marcus Denker

Re: [Pharo-dev] [Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

Yes point taken, should have mentioned - I will review all mine and close obsolete ones first. Sent from my iPhone > On 19 Mar 2019, at 11:20, Esteban Lorenzano wrote: > > I do not like that tool :) > > PLEASE do not blindly move issues from FogBugz to GitHub, if that would have > been our

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

The GitHub criteria is that issue reporters are not the ones that can distribute/label/recognise the areas of the reported issue, and that should be done by “admins”. I wonder if instead trying to fix the issue, we couldn’t first check if that’s an actual issue? I mean: maybe they have a

Re: [Pharo-dev] [Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

I do not like that tool :) PLEASE do not blindly move issues from FogBugz to GitHub, if that would have been our purpose we would have done it! Migrate the issues that are relevant for you. And for relevant I mean: Just the ones that you actually find in P7-8. Thing is… many of those issues

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

but you need to be on the Pharo organization to be able to add/modify card on the board ? A+ On Tue, Mar 19, 2019 at 11:07 AM Marcus Denker wrote: > Hi, > > it seems that the account / access model of GitHub forces us to move the > boards to the organisation level > (where we can have a user

Re: [Pharo-dev] [Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

Yes - Cyril is a tool meister…. ;) > On 19 Mar 2019, at 10:08, Marcus Denker wrote: > > Hi, > > I think Cyril has some kind of tool? Yes, that might be interesting... > >> On 18 Mar 2019, at 19:26, Tim Mackinnon > > wrote: >> >> Marcus - do we just manually copy over

[Pharo-dev] [Pharo 8.0] Build #155: UndefinedObject should not implement at:put: (or inherit it). This is…

There is a new Pharo build available! The status of the build #155 was: SUCCESS. The Pull Request #2888 was integrated: "UndefinedObject should not implement at:put: (or inherit it). This is…" Pull request url: https://github.com/pharo-project/pharo/pull/2888 Issue Url:

[Pharo-dev] [Pharo 8.0] Build #154: 2776-Hitting-an-undefined-class-gives-a-debugger-with-misleading-message-new-was-sent-to-nil-2

There is a new Pharo build available! The status of the build #154 was: SUCCESS. The Pull Request #2893 was integrated: "2776-Hitting-an-undefined-class-gives-a-debugger-with-misleading-message-new-was-sent-to-nil-2" Pull request url: https://github.com/pharo-project/pharo/pull/2893 Issue

Re: [Pharo-dev] [Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

Hi, I think Cyril has some kind of tool? Yes, that might be interesting... > On 18 Mar 2019, at 19:26, Tim Mackinnon wrote: > > Marcus - do we just manually copy over the title and description (and any > relevant comments) - or is there some tool to do this with? > > Tim > >> On 18 Mar

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

Hi, it seems that the account / access model of GitHub forces us to move the boards to the organisation level (where we can have a user group with write access for the boards). This means I will move them slowly to https://github.com/orgs/pharo-project/projects

Re: [Pharo-dev] About a better filedialog

YES! On Mon, Mar 18, 2019 at 11:13 PM ducasse wrote: > Yes I had to rename ComposableModel into ComposablePresenter so this is > probably that > > On 18 Mar 2019, at 23:09, Peter Uhnak wrote: > > Thanks Stef! > > The build is failing for Pharo 6.1 for some reason (I can't reproduce it >

[Pharo-dev] [Pharo 8.0] Build #153: 2879-removeInstVarNamed-on-MetaClass-needs-to-use-removeSlot-like-the-implementation-on-Class

There is a new Pharo build available! The status of the build #153 was: FAILURE. The Pull Request #2890 was integrated: "2879-removeInstVarNamed-on-MetaClass-needs-to-use-removeSlot-like-the-implementation-on-Class" Pull request url: https://github.com/pharo-project/pharo/pull/2890 Issue

[Pharo-dev] [Pharo 8.0] Build #152: 2891-fix-whichSelectorsRead-and-whichSelectorsStoreInto-for-Slots

There is a new Pharo build available! The status of the build #152 was: SUCCESS. The Pull Request #2894 was integrated: "2891-fix-whichSelectorsRead-and-whichSelectorsStoreInto-for-Slots" Pull request url: https://github.com/pharo-project/pharo/pull/2894 Issue Url: