Re: [Pharo-dev] About a better filedialog

[Peter Uhnak]

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 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
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-dev] About a better filedialog

[Hilaire]

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

-- 
Dr. Geo
http://drgeo.eu

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

[ci-pharo-ci-jenkins2]

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: https://pharo.fogbugz.com/f/cases/backstop
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/160/

Re: [Pharo-dev] About a better filedialog

[ducasse]

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 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 
>> locally), but I can look at that during the weekend...
>> 
>> Peter
>> 
>> On Mon, Mar 18, 2019 at 9:23 PM ducasse > > wrote:
>> Alex 
>> 
>> Have a look at the one I propose and play with it. 
>> Let me know what you think.
>> 
>> Stef
>> 
>>> On 18 Mar 2019, at 21:20, Alexandre Bergel >> > wrote:
>>> 
>>> 
>>> From: Alexandre Bergel >> >
>>> Subject: Re: [Pharo-dev] About a better filedialog
>>> Date: 18 March 2019 at 21:20:35 CET
>>> To: Pharo Development List >> >
>>> 
>>> 
>>> I do not have time to personally work on this. But yes, having a better 
>>> file dialog would be fantastic
>>> 
>>> Alexandre
>>> 
 On Mar 18, 2019, at 4:31 PM, ducasse >>> > wrote:
 
 Hi guys 
 
 I did a pass (ported to P7, tonel, some little fixes) on the file-dialog 
 developed by Peter Uhnak and I think that it would be good to propose it 
 by default in the image. 
 what do you think?
 
https://github.com/Ducasse/file-dialog 
 
 
 I would also like that the filedialog remembers the last list of visited 
 directory. (I will see if I can add this). 
 When Spec2 is out I would like to port it to Spec2. 
 
 Does anybody want to help? Because it would be super nice and I’m full 
 with cleaning textEditor and pluggableTextMorph. 
 
 Stef
 
 
 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13

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

[ducasse]

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 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
>> my experience that in our case it gets easily to GB-sized images, and the
>> GC is not very happy with this.
> 
> Indeed.
> 
>> 
>> On Tue, Mar 19, 2019 at 12:04 PM Attila Magyar  wrote:
>> 
>>> 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 executed with uninitialized
>>> instance variables at the second time. Why do we need to clean up the
>>> instance variables? Or why don't we reinitialize them before running the
>>> test?
> 
> I understand your grief. My solution: never use #initalize in tests, use 
> #setUp to initialize instance variables.
> 
> Max
> 
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html 
>>> 

Re: [Pharo-dev] About a better filedialog

[Peter Uhnak]

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 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
>> locally), but I can look at that during the weekend...
>>
>> Peter
>>
>> On Mon, Mar 18, 2019 at 9:23 PM ducasse  wrote:
>>
>>> Alex
>>>
>>> Have a look at the one I propose and play with it.
>>> Let me know what you think.
>>>
>>> Stef
>>>
>>> On 18 Mar 2019, at 21:20, Alexandre Bergel 
>>> wrote:
>>>
>>>
>>> *From: *Alexandre Bergel 
>>> *Subject: **Re: [Pharo-dev] About a better filedialog*
>>> *Date: *18 March 2019 at 21:20:35 CET
>>> *To: *Pharo Development List 
>>>
>>>
>>> I do not have time to personally work on this. But yes, having a better
>>> file dialog would be fantastic
>>>
>>> Alexandre
>>>
>>> On Mar 18, 2019, at 4:31 PM, ducasse  wrote:
>>>
>>> Hi guys
>>>
>>> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog
>>> developed by Peter Uhnak and I think that it would be good to propose it by
>>> default in the image.
>>> what do you think?
>>>
>>> https://github.com/Ducasse/file-dialog
>>>
>>> I would also like that the filedialog remembers the last list of visited
>>> directory. (I will see if I can add this).
>>> When Spec2 is out I would like to port it to Spec2.
>>>
>>> Does anybody want to help? Because it would be super nice and I’m full
>>> with cleaning textEditor and pluggableTextMorph.
>>>
>>> Stef
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>

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

[ci-pharo-ci-jenkins2]

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: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/159/

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

[ci-pharo-ci-jenkins2]

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: https://pharo.fogbugz.com/f/cases/2900
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/158/

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

[Max Leske]

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 the image keeps growing like crazy. I can tell you 
for
my experience that in our case it gets easily to GB-sized images, and 
the

GC is not very happy with this.


Indeed.



On Tue, Mar 19, 2019 at 12:04 PM Attila Magyar  
wrote:



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 executed with 
uninitialized

instance variables at the second time. Why do we need to clean up the
instance variables? Or why don't we reinitialize them before running 
the

test?


I understand your grief. My solution: never use #initalize in tests, use 
#setUp to initialize instance variables.


Max





--
Sent from: 
http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

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

[Gabriel Cotelli]

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
my experience that in our case it gets easily to GB-sized images, and the
GC is not very happy with this.

On Tue, Mar 19, 2019 at 12:04 PM Attila Magyar  wrote:

> 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 executed with uninitialized
> instance variables at the second time. Why do we need to clean up the
> instance variables? Or why don't we reinitialize them before running the
> test?
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

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

[Attila Magyar]

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 executed with uninitialized
instance variables at the second time. Why do we need to clean up the
instance variables? Or why don't we reinitialize them before running the
test?



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

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

[ci-pharo-ci-jenkins2]

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: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/157/

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

[ci-pharo-ci-jenkins2]

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: https://pharo.fogbugz.com/f/cases/2901
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/156/

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

[Marcus Denker]

> 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 first check if 
> that’s an actual issue? I mean: maybe they have a point and we shouldn’t ask 
> people to know what area of effect is the problem they are reporting.
> 

Does it make sense to have boards if only I use them? For sure not…

e.g. Steven wants to use the Reflectivity board. I now added to to the 
organisation instead, created a Team for Kanban boards, added him there and now 
he can edit

https://github.com/orgs/pharo-project/projects/7

> Esteban
> 
>> On 19 Mar 2019, at 11:06, 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 group with write access for the boards).
>> 
>> This means I will move them slowly to
>> 
>>  https://github.com/orgs/pharo-project/projects 
>> 
>> 
>> So lets treat all this as a test… as soon as it is really working I will 
>> send another mail.
>> 
>>> On 18 Mar 2019, at 08:27, Marcus Denker >> > wrote:
>>> 
>>> Hi,
>>> 
>>> We enabled the GitHub “Projects” feature for the pharo repo:
>>> 
>>> https://github.com/pharo-project/pharo/projects 
>>> 
>>> 
>>> 
>>> The idea is that one can add as many “Kanban” style boards as one wants.
>>> issues and pull requests can be added, as well as simple cards that are not 
>>> yet issues.
>>> 
>>> This is quite nice as an issue tracker gets very confusing and overwhelming 
>>> as soon as there
>>> are >500 issues.
>>> 
>>> With these boards, we can create “views” on this sea of issues. 
>>> 
>>> I created for now:
>>> 
>>> -> some board related to specific parts of the system (e.g. Traits or 
>>> Reflectivity)
>>> example: https://github.com/pharo-project/pharo/projects/11 
>>> 
>>> -> "Pharo7 Backporting”   
>>> https://github.com/pharo-project/pharo/projects/12 
>>> 
>>> -> "Simple Issues for Beginners”  
>>>  https://github.com/pharo-project/pharo/projects/14
>>> Here the feature to be able to put things that are not yet 
>>> issue tracker entries seems very useful
>>> 
>>> 
>>> I think this can be quite nice… we should add more Projects as soon as we 
>>> find that they make sense
>>> and should move issues there.
>>> 
>>> Marcus
>> 
> 

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

[Marcus Denker]

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  > 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 group with write access for the boards).
> 
> This means I will move them slowly to
> 
>   https://github.com/orgs/pharo-project/projects 
> 
> 
> So lets treat all this as a test… as soon as it is really working I will send 
> another mail.
> 
>> On 18 Mar 2019, at 08:27, Marcus Denker > > wrote:
>> 
>> Hi,
>> 
>> We enabled the GitHub “Projects” feature for the pharo repo:
>> 
>>  https://github.com/pharo-project/pharo/projects 
>> 
>> 
>> 
>> The idea is that one can add as many “Kanban” style boards as one wants.
>> issues and pull requests can be added, as well as simple cards that are not 
>> yet issues.
>> 
>> This is quite nice as an issue tracker gets very confusing and overwhelming 
>> as soon as there
>> are >500 issues.
>> 
>> With these boards, we can create “views” on this sea of issues. 
>> 
>> I created for now:
>> 
>>  -> some board related to specific parts of the system (e.g. Traits or 
>> Reflectivity)
>>  example: https://github.com/pharo-project/pharo/projects/11 
>> 
>>  -> "Pharo7 Backporting”   
>>  https://github.com/pharo-project/pharo/projects/12 
>> 
>>  -> "Simple Issues for Beginners”  
>>   https://github.com/pharo-project/pharo/projects/14 
>> 
>> Here the feature to be able to put things that are not yet issue 
>> tracker entries seems very useful
>> 
>> 
>> I think this can be quite nice… we should add more Projects as soon as we 
>> find that they make sense
>> and should move issues there.
>> 
>>  Marcus
> 
> 
> 
> -- 
> Serge Stinckwic​h​
> Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO)
> ​Sorbonne University (SU)
> French National Research Institute for Sustainable Development (IRD)​
> U​niversity of Yaoundé I​, Cameroun
> "Programs must be written for people to read, and only incidentally for 
> machines to execute."
> https://twitter.com/SergeStinckwich 
> ​

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

[Tim Mackinnon]

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 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 are no longer relevant (because of many 
> things).
> 
> Esteban
> 
>> On 19 Mar 2019, at 12:12, Tim Mackinnon  wrote:
>> 
>> 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 the title and description (and any 
 relevant comments) - or is there some tool to do this with?
 
 Tim
 
> On 18 Mar 2019, at 07:38, Marcus Denker  wrote:
> 
> Hi,
> 
> We should all look at the old issues:
> 
>   https://pharo.fogbugz.com/f/filters/57/All-newest-first
> 
> and move them to the new one:
> 
>   https://github.com/pharo-project/pharo/issues
> 
> instead of moving them automatically, we should take the chance to
> clean up.
> 
> Please check, first for the issues that *you* added:
> 
>   -> is it still relevant?
>   ->if yes: add a new issue on GitHub 
>   ->close this issue, there is now an explicit “moved to GitHub” state.
> 
> 
>   Marcus
 
>>> 
>> 
> 

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

[Esteban Lorenzano]

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 point and we shouldn’t ask people to 
know what area of effect is the problem they are reporting.

Esteban

> On 19 Mar 2019, at 11:06, 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 group with write access for the boards).
> 
> This means I will move them slowly to
> 
>   https://github.com/orgs/pharo-project/projects 
> 
> 
> So lets treat all this as a test… as soon as it is really working I will send 
> another mail.
> 
>> On 18 Mar 2019, at 08:27, Marcus Denker > > wrote:
>> 
>> Hi,
>> 
>> We enabled the GitHub “Projects” feature for the pharo repo:
>> 
>>  https://github.com/pharo-project/pharo/projects 
>> 
>> 
>> 
>> The idea is that one can add as many “Kanban” style boards as one wants.
>> issues and pull requests can be added, as well as simple cards that are not 
>> yet issues.
>> 
>> This is quite nice as an issue tracker gets very confusing and overwhelming 
>> as soon as there
>> are >500 issues.
>> 
>> With these boards, we can create “views” on this sea of issues. 
>> 
>> I created for now:
>> 
>>  -> some board related to specific parts of the system (e.g. Traits or 
>> Reflectivity)
>>  example: https://github.com/pharo-project/pharo/projects/11
>>  -> "Pharo7 Backporting”   
>>  https://github.com/pharo-project/pharo/projects/12
>>  -> "Simple Issues for Beginners”  
>>   https://github.com/pharo-project/pharo/projects/14
>> Here the feature to be able to put things that are not yet issue 
>> tracker entries seems very useful
>> 
>> 
>> I think this can be quite nice… we should add more Projects as soon as we 
>> find that they make sense
>> and should move issues there.
>> 
>>  Marcus
> 

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

[Esteban Lorenzano]

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 are no longer relevant (because of many things).

Esteban

> On 19 Mar 2019, at 12:12, Tim Mackinnon  wrote:
> 
> 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 the title and description (and any 
>>> relevant comments) - or is there some tool to do this with?
>>> 
>>> Tim
>>> 
 On 18 Mar 2019, at 07:38, Marcus Denker >>> > wrote:
 
 Hi,
 
 We should all look at the old issues:
 
https://pharo.fogbugz.com/f/filters/57/All-newest-first 
 
 
 and move them to the new one:
 
https://github.com/pharo-project/pharo/issues 
 
 
 instead of moving them automatically, we should take the chance to
 clean up.
 
 Please check, first for the issues that *you* added:
 
-> is it still relevant?
->if yes: add a new issue on GitHub 
->close this issue, there is now an explicit “moved to GitHub” state.
 
 
Marcus
>>> 
>> 
> 

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

[Serge Stinckwich]

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 group with write access for the boards).
>
> This means I will move them slowly to
>
> https://github.com/orgs/pharo-project/projects
>
> So lets treat all this as a test… as soon as it is really working I will
> send another mail.
>
> On 18 Mar 2019, at 08:27, Marcus Denker  wrote:
>
> Hi,
>
> We enabled the GitHub “Projects” feature for the pharo repo:
>
> https://github.com/pharo-project/pharo/projects
>
>
> The idea is that one can add as many “Kanban” style boards as one wants.
> issues and pull requests can be added, as well as simple cards that are
> not yet issues.
>
> This is quite nice as an issue tracker gets very confusing and
> overwhelming as soon as there
> are >500 issues.
>
> With these boards, we can create “views” on this sea of issues.
>
> I created for now:
>
> -> some board related to specific parts of the system (e.g. Traits or
> Reflectivity)
> example: https://github.com/pharo-project/pharo/projects/11
> -> "Pharo7 Backporting”
> https://github.com/pharo-project/pharo/projects/12
> -> "Simple Issues for Beginners”
> https://github.com/pharo-project/pharo/projects/14
> Here the feature to be able to put things that are not yet
> issue tracker entries seems very useful
>
>
> I think this can be quite nice… we should add more Projects as soon as we
> find that they make sense
> and should move issues there.
>
> Marcus
>
>
>

-- 
Serge Stinckwic
​h​

Int. Research Unit
 on Modelling/Simulation of Complex Systems (UMMISCO)
​Sorbonne University
 (SU)
French National Research Institute for Sustainable Development (IRD)​
U
​niversity of Yaoundé I​, Cameroun
"Programs must be written for people to read, and only incidentally for
machines to execute."
https://twitter.com/SergeStinckwich
​

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

[Tim Mackinnon]

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 the title and description (and any 
>> relevant comments) - or is there some tool to do this with?
>> 
>> Tim
>> 
>>> On 18 Mar 2019, at 07:38, Marcus Denker >> > wrote:
>>> 
>>> Hi,
>>> 
>>> We should all look at the old issues:
>>> 
>>> https://pharo.fogbugz.com/f/filters/57/All-newest-first 
>>> 
>>> 
>>> and move them to the new one:
>>> 
>>> https://github.com/pharo-project/pharo/issues 
>>> 
>>> 
>>> instead of moving them automatically, we should take the chance to
>>> clean up.
>>> 
>>> Please check, first for the issues that *you* added:
>>> 
>>> -> is it still relevant?
>>> ->if yes: add a new issue on GitHub 
>>> ->close this issue, there is now an explicit “moved to GitHub” state.
>>> 
>>> 
>>> Marcus
>> 
> 

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

[ci-pharo-ci-jenkins2]

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: https://pharo.fogbugz.com/f/cases/2795
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/155/

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

[ci-pharo-ci-jenkins2]

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 Url: https://pharo.fogbugz.com/f/cases/2776
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/154/

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

[Marcus Denker]

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 2019, at 07:38, Marcus Denker > > wrote:
>> 
>> Hi,
>> 
>> We should all look at the old issues:
>> 
>>  https://pharo.fogbugz.com/f/filters/57/All-newest-first 
>> 
>> 
>> and move them to the new one:
>> 
>>  https://github.com/pharo-project/pharo/issues 
>> 
>> 
>> instead of moving them automatically, we should take the chance to
>> clean up.
>> 
>> Please check, first for the issues that *you* added:
>> 
>>  -> is it still relevant?
>>  ->if yes: add a new issue on GitHub 
>>  ->close this issue, there is now an explicit “moved to GitHub” state.
>> 
>> 
>>  Marcus
> 

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

[Marcus Denker]

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 


So lets treat all this as a test… as soon as it is really working I will send 
another mail.

> On 18 Mar 2019, at 08:27, Marcus Denker  wrote:
> 
> Hi,
> 
> We enabled the GitHub “Projects” feature for the pharo repo:
> 
>   https://github.com/pharo-project/pharo/projects
> 
> 
> The idea is that one can add as many “Kanban” style boards as one wants.
> issues and pull requests can be added, as well as simple cards that are not 
> yet issues.
> 
> This is quite nice as an issue tracker gets very confusing and overwhelming 
> as soon as there
> are >500 issues.
> 
> With these boards, we can create “views” on this sea of issues. 
> 
> I created for now:
> 
>   -> some board related to specific parts of the system (e.g. Traits or 
> Reflectivity)
>   example: https://github.com/pharo-project/pharo/projects/11
>   -> "Pharo7 Backporting”   
>   https://github.com/pharo-project/pharo/projects/12
>   -> "Simple Issues for Beginners”  
>https://github.com/pharo-project/pharo/projects/14
> Here the feature to be able to put things that are not yet issue 
> tracker entries seems very useful
> 
> 
> I think this can be quite nice… we should add more Projects as soon as we 
> find that they make sense
> and should move issues there.
> 
>   Marcus

Re: [Pharo-dev] About a better filedialog

[Guillermo Polito]

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
> locally), but I can look at that during the weekend...
>
> Peter
>
> On Mon, Mar 18, 2019 at 9:23 PM ducasse  wrote:
>
>> Alex
>>
>> Have a look at the one I propose and play with it.
>> Let me know what you think.
>>
>> Stef
>>
>> On 18 Mar 2019, at 21:20, Alexandre Bergel 
>> wrote:
>>
>>
>> *From: *Alexandre Bergel 
>> *Subject: **Re: [Pharo-dev] About a better filedialog*
>> *Date: *18 March 2019 at 21:20:35 CET
>> *To: *Pharo Development List 
>>
>>
>> I do not have time to personally work on this. But yes, having a better
>> file dialog would be fantastic
>>
>> Alexandre
>>
>> On Mar 18, 2019, at 4:31 PM, ducasse  wrote:
>>
>> Hi guys
>>
>> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog
>> developed by Peter Uhnak and I think that it would be good to propose it by
>> default in the image.
>> what do you think?
>>
>> https://github.com/Ducasse/file-dialog
>>
>> I would also like that the filedialog remembers the last list of visited
>> directory. (I will see if I can add this).
>> When Spec2 is out I would like to port it to Spec2.
>>
>> Does anybody want to help? Because it would be super nice and I’m full
>> with cleaning textEditor and pluggableTextMorph.
>>
>> Stef
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

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

[ci-pharo-ci-jenkins2]

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 Url: https://pharo.fogbugz.com/f/cases/2879
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/153/

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

[ci-pharo-ci-jenkins2]

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: https://pharo.fogbugz.com/f/cases/2891
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/152/