Re: [Pharo-dev] Playground do-it-and-go alternative name

[Jigyasa Grover]

Ben
Seems to be a nice idea :)


On Sun, Mar 29, 2015 at 11:37 AM, Ben Coman  wrote:

> Just sharing a passing thought... Given that we have "Play"ground, an
> alternative name for  might be  - except it competes
> with  for the most obvious shortcut.  A further alternative may be
> ".
>
> cheers -ben
>

[Pharo-dev] Playground do-it-and-go alternative name

[Ben Coman]

Just sharing a passing thought... Given that we have "Play"ground, an
alternative name for  might be  - except it competes
with  for the most obvious shortcut.  A further alternative may be
".

cheers -ben

Re: [Pharo-dev] Existing

[Ben Coman]

On Sat, Mar 28, 2015 at 5:00 AM, Sean P. DeNigris 
wrote:

> Torsten Bergmann wrote
> >  1. use
> > 
> >  as agreed in October for exampleXXX methods/example methods with
> > different selectors
> >   and use
> > 
> >  for the instance returning methods that I proposed (including a
> > changeset)
> >   Stef said it would be OK for him
> >
> >2. use
> > 
> >  and
> > 
> >  as Kilon suggested
> >
> >3. use
> > 
> >  for code examples and
> > 
> >  for the GT extension as Andreas/Christophe suggested
> >
> >  4. use
> > 
> >
>
> Isn't it amazing that we all care so much about Pharo and each other and
> still create a mess sometimes :) But then we always clean it up! I liked
> your quoting Pharo zen. I should probably do that more when I get annoyed.
>
> I wasn't going to weigh in because it seemed like it would definitely be
> pushed to 5.0, but since the discussion is still ongoing. And that's good
> because:
> 1) as T. said, if we introduce something for a year it will be much harder
> to change once people are using it
> 2) and, as a pragma rename for example code, there seems to be limited
> risk/work involved (should be easily re-writable no?)
>
> From a native English perspective, for GT I think only #exampleInstance (or
> almost-as-good #sampleInstance) both sound natural and clearly reveal the
> intention. For the other "play button variety", #example is fine, but
> #exampleCode or #sampleCode would be more explicit in light of the two
> distinct usages now. For simplicity, maybe they should mirror each other
> i.e. (exampleInstance & exampleCode) | (sampleInstance & sampleCode).
>
> Anyway my 2c
>
>
With  in dispute and concern with locking in semantics for Pharo
4, it might be pragmatic for both sides to back away from  for the
Pharo 4 release to mirrored pragmas  & .  It
will be easier to discuss semantics in Pharo 5 for a new  rather
than modifying and existing one.  It should be no trouble to carry forward
 &  for a while before they are "maybe"
deprecated.

To add a further 2c, I wonder if Pharo 5 might consider parameterising
:
*  or  or 
*  or  or 

then you might even have 

@Doru,  Sorry I had used a few caps to emphasise some phrases.  I didn't
consider it shouting unless I typed caps for the whole paragraph.  I'll
amend how I do this.

cheers -ben

[Pharo-dev] spotters horizontal categorylist

[Nicolai Hess]

Somehow we lost this horizontal categorylist, was this intended?

See the attached screenshot:
this is in pharo 40500, the list on top
Classes - Menu
and the list on the bottom
Implementors - Pragmas - Global variables
are showing titles for the categories that are not in the visible area.


With a more recent versions,
there is no horzintal list.


nicolai

Re: [Pharo-dev] [Moose-dev] moose at the breathing code conference

[Alexandre Bergel]

Looks like a fantastic conference program. I wish I could be there…

Alexandre


> On Mar 28, 2015, at 6:21 PM, Tudor Girba  wrote:
> 
> Hi,
> 
> My talk on Moose was accepted at the Breathing Code conference to be held on 
> May 5 in Frankfurt:
> http://breathing-code.de/program.html#data-analysis-moose
> 
> It's an interesting setup that fits both Pharo and Moose like a glove.
> 
> However, this being the first edition of the conference, the organizers are a 
> bit in trouble as there are not enough registrations. They need to reach 35 
> participants until April 1, and they urge people to spread the word.
> 
> Now, I kindly ask you to spread the word the best you can about this 
> conference.
> 
> Cheers,
> Doru
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"
> ___
> Moose-dev mailing list
> moose-...@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Improving communication and roadmap

[Alexandre Bergel]

>Merwane will work on 3D and event touch

Glad to hear this! I guess this is related to what Pierre will do with the 
events. 
It would be great that Merwane will sync with us on this. What does he plan to 
do? Will he worked on top of Woden? Can we get in touch about this?

Cheers,
Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Existing

[Tudor Girba]

Hi Torsten,

Thanks for this mail. Indeed, mail is a poor medium and both the writer and
the reader has to exercise more patience which does not always happen.
There were two things that got to me: too long emails, and the overuse of
capital letters. The latter one feels like shouting, and the long emails
were just too time consuming in a rather stressful situation of meeting the
deadline. And at the end, it led to longer responses that included points
that were not addressed.

Replying to the current mail takes more time than I have now. I will reply,
but later.

Cheers,
Doru



On Fri, Mar 27, 2015 at 7:07 PM, Torsten Bergmann  wrote:

> Hi Tudor,
>
> Disclaimer: this mail is not intended to heat this up once again or insult
> you. It is meant to bring some
> more light into the darkness: we all can only decide on what we read and
> the actions that we see
> from others, sometimes a lot is not known from the other participants side.
>
> Exactly because of this let me tell you my side of the story:
>
> The discussion from October [1] between you and Stef happened in a thread
> "structuring widget examples"
> that I personally missed and did not follow.
>
> At around the same time I extended Nautilus so that (additionally to other
> clickable method icons one
> can also click on #exampleXXX and initialize method icons. We have around
> 140 of such exampleXXX methods
> in the image, also in many external packages (like Bloc). These exampleXXX
> methods are used to demonstrate
> Smalltalk/Pharo code and are a valuable source to learn from.
>
> When I announced this "click to run exampleXXX" feature on the list in
> October 2014 you welcomed and
> supported that idea [2]. I also heard the first time that we have an
> overlap in interest in making "examples"
> more visible in one way or the other. So we discussed about this solely in
> the context of example methods
> and I was as that time unaware of other GT related work in this regard.
> In this discussion you mentioned that being dependendent on the selector
> naming convention for the examples
> is not good and therefore you suggested that I extend my slice to use the
>  pragma for these
> clickable code examples.
>
> Lets repeat: what I defend here the whole time was your very own idea, not
> mine as one can read in the list
>  archive [2].
>
> I supported your opinion because it was and still is an improvement! The
> pragma  that you suggested to me
> for the traditional Smalltalk class side exampleXXX methods fitted
> perfectly also namewise and therefore got
> integrated as a valuable addition into the image.
>
> We shared the common view that using the  pragma is a cleaner way
> to mark "example methods".
> Anything was fine and I also happily used this pragma also in own external
> packages. I also wanted to go
> through all the example methods in the image to mark them with the
>  pragma and additionally provide
> an example browser for newbees based on the pragma as mentioned in the
> thread. But I was too busy to do it.
>
> So the simple reason for the low number of pragma usage in the standard
> image is that I had not yet time
> to do this. It was also not a pressuring task because #exampleXXX where
> clickable and the pragma infrastructure
> was in place to mark all other exampleXXX selectors or selectors like
> #niceExampleToTryOut. So it could be
> used at any point in time later.
>
> CI builds were green and the sun was shining for all of us...
>
> I was unaware (at that time) of one important thing and this discussion
> here and your mails now made
> it more clear:
> Stef asked you also back in October to use  instead of
>  and you followed this - but on
> the other hand and also in October you suggested to me to use exactly the
> same pragma .
> At that time nobody seem to have been aware of this upcoming name
> collision that was introduced with
> Stefs request to you for GT on one side and your suggestion to me for
> getting independent from exampleXXX
> on the other side.
>
> So in parallel you worked on a feature to "display sample instances" for a
> class in a new inspector tab ("e.g.")
> - for that the meaning behind the pragma marked methods was to return
> instances. You added more and more methods tagged
> with  on Character, String, ... to return samples like $a or 42.
>
> GT is one of the packages that is hosted "externally" and get
> resynchronized into Pharo from time to time using Configs.
> The image included the  pragma logic for the click action in
> Nautilus. And with each new integration of
> next GT versions into the standard Pharo image more and more 
> marked methods came in providing objects/instances.
>
> So it seems it was only a matter of time that this unfortunate "double
> usage" of the pragma showed their
> effects: Nicolai Hess wondered this week about a "useless play icon" in
> Nautilus and created issue #15225 four
> days ago [3] because when you execute a method that just returns an
> instance 

Re: [Pharo-dev] Pharo sprint on Friday, 3rd April

[stepharo]

Le 28/3/15 08:49, Marcus Denker a écrit :

On 27 Mar 2015, at 22:04, Hilaire  wrote:

Le 27/03/2015 17:11, Jean-Christophe Bach a écrit :

Hi Pharoers,

This email as a reminder for the next Pharo sprint: it will be next
Friday (3rd April) at Inria Lille.
You can also join us on the IRC channel (#pharo on irc.freenode.net
server). During the sprint, we will try to synchronize local and remote
Pharo sprinters.

JC

Hi,

Is there any Pharo related things to prepare in advance if one wants to
attempt remotely through IRC channel?


- try to connect before to check that IRC works
- we try to have some issues tagged with “sprint” on the issue tracker..
   but this time it will be focused on bugs for Pharo4, I guess.


but there will be not enough bugs.


This means having a look at the issue tracker to find some issue that are
interesting to work on could be an idea.

Maybe a trello board could be used to sync for the remote sprinters.

Marcus

[Pharo-dev] moose at the breathing code conference

[Tudor Girba]

Hi,

My talk on Moose was accepted at the Breathing Code conference to be held
on May 5 in Frankfurt:
http://breathing-code.de/program.html#data-analysis-moose

It's an interesting setup that fits both Pharo and Moose like a glove.

However, this being the first edition of the conference, the organizers are
a bit in trouble as there are not enough registrations. They need to reach
35 participants until April 1, and they urge people to spread the word.

Now, I kindly ask you to spread the word the best you can about this
conference.

Cheers,
Doru

-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Improving communication and roadmap

[Sean P. DeNigris]

> the advantage of a roadmap is that allows people that can agree on principle 
> on a specific kind of approach can work together as a team towards a common 
> goal under the same project.
Yes! For example, with event handling, it's not so much that I didn't want to 
offer a cool alternative, but that in the limited time I have to work on it, 
I'd prefer to benefit from the extensive research and design decisions that no 
doubt have already been done as others have looked at the problem, instead of 
starting from scratch. Plus, there are plenty of other areas to occupy me that 
are not being worked on AFAIK.

Also, it would also be a great way to document design decisions, both to align 
us now, and also for the future. One of the things that I often feel holding me 
back is that I have no idea what the design decisions were, and so fear that 
something important (e.g. flexibility, future extension, etc) may be lost by 
cleaning and simplifying. For example, when we created distinct WorldMorphs vs. 
PasteUpMorphs, we lost the ability to promote PasteUps to act as the world. How 
important was that? IDK. But I only realized after because the design was IMHO 
a bit unclear and AFAICT undocumented.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Improving-communication-and-roadmap-tp4815705p4815790.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Delay refactorign status

[Ben Coman]

I have updated the Delay Refactoring working roadmap per Pharo 4 status.
https://github.com/bencoman/pharo-workingRoadmaps/blob/master/DelayRefactoring.md

I'm note sure what form release notes will take for Pharo 4, but perhaps it
may be some use to condense for them.

cheers -ben

Re: [Pharo-dev] Improving communication and roadmap

[Sven Van Caekenberghe]

> On 28 Mar 2015, at 16:05, Tudor Girba  wrote:
> 
> I think the fear that someone else might do something similar should not stop 
> action.
> 
> Having multiple solutions to choose from is a good thing :)

+1

We need options, backups, alternatives, it is a free world, and nothing is set 
in stone.

> Cheers,
> Doru
> 
> On Sat, Mar 28, 2015 at 2:32 PM, Sean P. DeNigris  
> wrote:
> stepharo wrote
> > So I would like to propose that we share a kind of board of announce on
> > what people are doing.
> 
> Thank you! This is great. I've also been hesitant to work on certain things
> (e.g. cleaning up Morphic events) because I didn't want to unintentionally
> overlap with someone else's work.
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/Improving-communication-and-roadmap-tp4815705p4815753.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 
> 
> 
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"

Re: [Pharo-dev] Improving communication and roadmap

[kilon alios]

the advantage of a roadmap is that allows people that can agree on
principle on a specific kind of approach can work together as a team
towards a common goal under the same project.

People who cant find someone else to agree with them, or dont like the
existing solutions can always follow their own path and create their own
code. On other hand those kind of people can also benefit from a roadmap
because a roadmap is always an attractive force for contributors.

When I (used here generally not just to refer to me) know what your
intention is with this code in the future , I will be far more willing to
help you out if our goals are common. If not then roadmap can still be
useful if I dont want our two projects , mine and yours to overlap.

So a roadmap is a win win situation.

And I dont even need to go into the advantages of planning ahead.

On Sat, Mar 28, 2015 at 5:05 PM, Tudor Girba  wrote:

> I think the fear that someone else might do something similar should not
> stop action.
>
> Having multiple solutions to choose from is a good thing :)
>
> Cheers,
> Doru
>
> On Sat, Mar 28, 2015 at 2:32 PM, Sean P. DeNigris 
> wrote:
>
>> stepharo wrote
>> > So I would like to propose that we share a kind of board of announce on
>> > what people are doing.
>>
>> Thank you! This is great. I've also been hesitant to work on certain
>> things
>> (e.g. cleaning up Morphic events) because I didn't want to unintentionally
>> overlap with someone else's work.
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> View this message in context:
>> http://forum.world.st/Improving-communication-and-roadmap-tp4815705p4815753.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Improving communication and roadmap

[Tudor Girba]

I think the fear that someone else might do something similar should not
stop action.

Having multiple solutions to choose from is a good thing :)

Cheers,
Doru

On Sat, Mar 28, 2015 at 2:32 PM, Sean P. DeNigris 
wrote:

> stepharo wrote
> > So I would like to propose that we share a kind of board of announce on
> > what people are doing.
>
> Thank you! This is great. I've also been hesitant to work on certain things
> (e.g. cleaning up Morphic events) because I didn't want to unintentionally
> overlap with someone else's work.
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Improving-communication-and-roadmap-tp4815705p4815753.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Improving communication and roadmap

[Tudor Girba]

Hi Stef,

On Sat, Mar 28, 2015 at 8:52 AM, stepharo  wrote:

> Hi guys
>
> I have a general comments.
> Doru in a recent email you complain that people may (and it was not the
> case) think that GT was out of Pharo.


I did not complain. I just noticed how several times there it was argued
that something is imposed from GT onto Pharo and that because  is
in a certain way only in GT it somehow plays a secondary importance. This
implies that collectively, we reason about GT as being separate from Pharo.



> Now I think that the group does not mention clearly enough his plans.

And in general groups (like rmod too).
>

We worked only on the things we announced since the PharoDays in January:
- Spotter
- Inspector/Playground
- Chatter


For example, we just get that there is a support for code critics.
>

You just get the news because it just happened days before the announcement
of Uko. And this was not following a big master plan. It was a mere couple
of hours of playing around with implementing more examples of how to use
Spotter by Stefan Reichhart (the newest GT team member).

Please look back, and you will notice that every significant feature that
is released comes with a prominent description on
http://humane-assessment.com. And along the way we also describe examples
of how to use GT. I honestly do not know how to provide more.


About the Quality Assistant of Yuriy I have been discussing regularly with
> him to make sure that I
> would not launch something that would compete with him and that I do not
> pay a student for
> something in concurrence.

I discussed with Alberto student that should work on improving Ecompletion
> and I change the topic of
> a guy coming to work with us.
>
So I would like to propose that we share a kind of board of announce on
> what people are doing.
> For example starting 1 of april
> Franck will work on improving pretty printing
> Merwane will work on 3D and event touch
> Thomas will work on code review
> Cyril will work on pillar improvements
> Kevin on decompiler
> Julien on remote environment or new collection
>

That is welcome information, which was indeed opaque until now.

On Tuesday we will organize a working session in Bern on the Pharo IDE with
exactly the goal of supporting more exchange.



> So what do you think. For me I think that this is important.
> Because I would like to lower frustration.
>

What is the concrete proposal? To send emails here when we know we are
switching topics? We did that regarding GT and it seems to not be enough.
What else is needed?

Cheers,
Doru

-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Improving communication and roadmap

[Sean P. DeNigris]

stepharo wrote
> So I would like to propose that we share a kind of board of announce on 
> what people are doing.

Thank you! This is great. I've also been hesitant to work on certain things
(e.g. cleaning up Morphic events) because I didn't want to unintentionally
overlap with someone else's work.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Improving-communication-and-roadmap-tp4815705p4815753.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

[stepharo]

Le 27/3/15 22:02, Sean P. DeNigris a écrit :

EstebanLM wrote

Sean DeNigris
Sean De Nigris

I'm on there twice... maybe once for working and once for complaining ha ha


probably :)


;) Sorry, couldn't resist.
b.t.w. the first spelling is the correct one.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/collecting-Pharo-4-0-Contributors-tp4814792p4815671.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] [pharo-project/pharo-core] 5042a3: 40586

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 5042a31c358f3a7e7a4019335b963c0df15a9555
  
https://github.com/pharo-project/pharo-core/commit/5042a31c358f3a7e7a4019335b963c0df15a9555
  Author: Jenkins Build Server 
  Date:   2015-03-28 (Sat, 28 Mar 2015)

  Changed paths:
A HelpSystem-Core.package/HelpBrowser.class/instance/actions/next.st
A HelpSystem-Core.package/HelpBrowser.class/instance/actions/previous.st
M 
HelpSystem-Core.package/HelpBrowser.class/instance/events/onItemClicked_.st
M HelpSystem-Core.package/HelpBrowser.class/instance/ui/initWindow.st
A HelpSystem-Core.package/HelpBrowser.class/instance/ui/menu.st
A 
HelpSystem-Core.package/HelpBrowser.class/instance/ui/shoutMorphFillMenu_.st
M ProfStef-Core.package/LessonView.class/instance/gui/menu.st
A ProfStef-Core.package/LessonView.class/instance/testing/isOpenInWindow.st
M 
ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/doingVSPrinting.st
A 
ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/inspecting.st
M 
ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/printing.st
M ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/theEnd.st
M 
ProfStef-Core.package/PharoSyntaxTutorial.class/instance/tutorial/tutorial.st
A ProfStef-Core.package/PharoTutorial.class/class/zen/aboutPharoZen.st
M 
ProfStef-Core.package/PharoTutorial.class/class/zen/openPharoZenWorkspace.st
A 
ProfStef-Core.package/PharoTutorial.class/instance/accessing/helpBrowserWindow.st
M ProfStef-Core.package/PharoTutorial.class/instance/navigating/next.st
M ProfStef-Core.package/PharoTutorial.class/instance/navigating/previous.st
A 
ProfStef-Tests.package/MockLessonView.class/instance/testing/isOpenInWindow.st
A 
SUnit-Core.package/TAssertable.class/instance/asserting/assertCollection_hasSameElements_.st
A 
SUnit-Core.package/TestAsserter.class/instance/private/comparingCollectionBetween_and_.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script585.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script586.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40585.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40586.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
Shout.package/SHTextStyler.class/instance/styling/styleInBackgroundProcess_.st

  Log Message:
  ---
  40586
13201 Hard to start a tutorial in Pharo
https://pharo.fogbugz.com/f/cases/13201

15240 Stuck SHTextStyler semaphores
https://pharo.fogbugz.com/f/cases/15240

15238 Add an assertion to check if a collection has same elements as another 
collection
https://pharo.fogbugz.com/f/cases/15238

http://files.pharo.org/image/40/40586.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

Re: [Pharo-dev] Pharo sprint on Friday, 3rd April

[Marcus Denker]

> 
> This means having a look at the issue tracker to find some issue that are
> interesting to work on could be an idea.
> 
> Maybe a trello board could be used to sync for the remote sprinters.
> 

https://trello.com/b/OQ2k210W 

It is public for viewing, for editing I think we need to add people.

Marcus

[Pharo-dev] Improving communication and roadmap

[stepharo]

Hi guys

I have a general comments.
Doru in a recent email you complain that people may (and it was not the 
case) think that GT was out of Pharo.

Now I think that the group does not mention clearly enough his plans.
And in general groups (like rmod too).


For example, we just get that there is a support for code critics.
About the Quality Assistant of Yuriy I have been discussing regularly 
with him to make sure that I
would not launch something that would compete with him and that I do not 
pay a student for

something in concurrence.
I discussed with Alberto student that should work on improving 
Ecompletion and I change the topic of

a guy coming to work with us.

So I would like to propose that we share a kind of board of announce on 
what people are doing.

For example starting 1 of april
Franck will work on improving pretty printing
Merwane will work on 3D and event touch
Thomas will work on code review
Cyril will work on pillar improvements
Kevin on decompiler
Julien on remote environment or new collection

So what do you think. For me I think that this is important.
Because I would like to lower frustration.

Stef

Re: [Pharo-dev] Pharo sprint on Friday, 3rd April

[Marcus Denker]

> On 27 Mar 2015, at 22:04, Hilaire  wrote:
> 
> Le 27/03/2015 17:11, Jean-Christophe Bach a écrit :
>> Hi Pharoers,
>> 
>> This email as a reminder for the next Pharo sprint: it will be next
>> Friday (3rd April) at Inria Lille. 
>> You can also join us on the IRC channel (#pharo on irc.freenode.net
>> server). During the sprint, we will try to synchronize local and remote
>> Pharo sprinters.
>> 
>> JC
> 
> Hi,
> 
> Is there any Pharo related things to prepare in advance if one wants to
> attempt remotely through IRC channel?
> 

- try to connect before to check that IRC works
- we try to have some issues tagged with “sprint” on the issue tracker..
  but this time it will be focused on bugs for Pharo4, I guess.

This means having a look at the issue tracker to find some issue that are
interesting to work on could be an idea.

Maybe a trello board could be used to sync for the remote sprinters.

Marcus

Re: [Pharo-dev] Pharo sprint on Friday, 3rd April

[Jean-Christophe Bach]

* Hilaire  [27.03.2015. @22:04:29 +0100]:

> Le 27/03/2015 17:11, Jean-Christophe Bach a écrit :
> > Hi Pharoers,
> >
> > This email as a reminder for the next Pharo sprint: it will be next
> > Friday (3rd April) at Inria Lille. 
> > You can also join us on the IRC channel (#pharo on irc.freenode.net
> > server). During the sprint, we will try to synchronize local and remote
> > Pharo sprinters.
> >
> > JC
> 
> Hi,
> 
> Is there any Pharo related things to prepare in advance if one wants to
> attempt remotely through IRC channel?
> 
> Thanks
> 
> -- 
> Dr. Geo - http://drgeo.eu
> iStoa - http://istoa.drgeo.eu

A Pharo environment and an IRC client :)
If you want to work on specific issues, you can check the opened issues
on fogbugz. Then you can propose them during the sprint. 

JC


signature.asc
Description: Digital signature