February 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Integer arithmetic and bit counting performance in Squeak and Pharo

by ClÃ©ment Bera

Well the 64 bits VM is optimised for 61 bits signed integers instead of 31 bits signed integers, so bit operations on integers between 32 bits and 61 bits should get faster. In addition, some operations are optimised for unsigned machine word, and therefore the VM can use unsigned 64 bits integers instead of unsigned 32 bits integer. I am glad you enjoyed my blog post. Note that since I wrote it, I replaced (following a discussion between Eliot and Levente) the special selector #blockCopy: which has been unused for the past 9 years by #'~~' to have consistent behavior between #'~~' and #'=='. Latest VMs should have this feature. Best, Clement On Fri, Feb 10, 2017 at 1:21 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Oh! Many thanks for all the details! I thought about special selectors > and remembered that #bitAnd: and #bitOr: were those special kind of > "beasts" but I falsely assumed that #bitXor: was also a special selector... > :( I should have looked at the code! > > So that also explains the "strange" behavior of the 64bit image. Lots of > the tests in the 32bit image fell into the LargeInteger "range" and then, > executing the same code on the 64bit image, those numbers suddenly became > considered SmallInteger... That explains it all and why some operations > "suddenly" became so fast for no apparent reason !!! > > Now, just for my personal curiosity, what is going to be the impact of a > 64bit VM on such code? (Unfortunately, I am on Windows so I will have to > wait...) ? > > P.S. I should have persevered in my google searches as I just came across > this *excellent* post : Arithmetic, inlined and special selectors > <https://clementbera.wordpress.com/2014/08/12/arithmetic-inlined-and-special…> > > :) > > Thanks a lot! > > Arithmetic, inlined and special selectors > Today we are going to discuss how message sends are dispatched in the VM > and/or compiled in the image for arithm... > > <https://clementbera.wordpress.com/2014/08/12/arithmetic-inlined-and-special…> > > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > ------------------------------ > *From:* ClÃ©ment Bera <bera.clement(a)gmail.com> > *To:* Benoit St-Jean <bstjean(a)yahoo.com>; Pharo Development List < > pharo-dev(a)lists.pharo.org> > *Cc:* The General-purpose Squeak Developers List <squeak-dev@lists. > squeakfoundation.org> > *Sent:* Friday, February 10, 2017 5:14 AM > *Subject:* Re: [Pharo-dev] Integer arithmetic and bit counting > performance in Squeak and Pharo > > Hi, > > This is a lovely post. Thanks for posting about Smalltalk / Pharo / Squeak. > > > 1. Why *exactly* does the override work (in 32bit images)? > 2. What changed so that things are different in Squeak 5.1 64bit image > (overrides partially work)? > > If I am correct your questions are exclusively for bitOr: and bitAnd:. I > don't know what you are aware of and what you're not aware of, hence I am > going to give you some details on how bitAnd: is executed (bitOr: is done > exactly the same way), and hopefully there will be something you don't know > yet that should help you understand what's going on. > > *Execution of bitAnd:* > > bitAnd: a special selector. If you run Smalltalk specialSelectors you get > this array: #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 > #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 > #next 0 #nextPut: 1 #atEnd 0 #== 1 #class 0 #blockCopy: 1 #value 0 #value: > 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) which includes bitAnd: . > > Special selectors are encoded in the bytecode differently to save memory, > so they can be executed differently without inducing overhead. In Cog, > bitAnd: is executed differently using type-prediction. > > In the Stack Interpreter, the execution of bitAnd: is done as follows: > If both operands are SmallIntegers, > push the bitAnd: value of the 2 SmallIntegers > else > Try the primitive BitAnd for SmallIntegers (14) > on success > push the result > on failure > perform the send. > > In the JIT, bitAnd: sends are compiled differently that normal send, the > compilation logic is as follows: > If both operands are SmallInteger literals > compute the result during compilation and use this value > else > If one of the 2 operands is a SmallInteger literal > generate 2 paths, a quick inlined path testing at runtime that > the other operand is a SmallInteger, and if so, Ands the operands and use > that result, else use the slow path performing a send > else > generate a normal send > > *Primitives* > > primitive 14 -> Works for SmallIntegers and LargePositiveInteger fitting > in an unsigned machine word. (Slower than direct SmallInteger bitAnd > performed by the special selector) > primitive 34 -> Works for SmallIntegers and LargePositiveInteger fitting > in an unsigned int64. (Slower than primitive 14 in 32 bits but covering > more cases, equivalent in 64 bits) > primDigitBitAnd (in Integer) -> Works for any integer. (Slower than the > primitive 14 and 34) > > *SmallInteger encoding* > > In 32 bits, SmallIntegers are signed 31bits integer. > In 64 bits, SmallIntegers are signed 61 bits integer. > > *Discussion* > > Let's make some assertions based on previous information: > > 1) If you have the exact same bitAnd: implementation for #bitAnd: and > #bitAnd2:, #bitAnd2: is slower because it is not a special selector. > > 2) Still with the exact same bitAnd: implementation, using the JIT, things > like that: > 16r1 bitAnd: 1. "1 bits" > 16r2 bitAnd: 2. "2 bit" > 16r4 bitAnd: 4. "3 bit" > 16r8 bitAnd: 3. "4 bit" > Are bitAnd: operations between SmallInteger constants and the result is > unused. Hence this whole portion of code does not generate any native > instructions. > On the other hand, things like that: > 16r1 bitAnd2: 1. "1 bits" > 16r2 bitAnd2: 2. "2 bit" > 16r4 bitAnd2: 4. "3 bit" > 16r8 bitAnd2: 3. "4 bit" > Are sends, generating multiple native instructions including calls. > > 3) Because of the SmallInteger encoding, > 16r200000000000000 bitAnd: 98490667780264321. "58 bit" > is compiled by the JIT to nothing in 64 bits but to a send in 32 bits (the > JIT can't solve LargeInteger arithmetic at compilation time). > > 4) primitive 34 provides some speed-up over primitive 14 in 32 bits, > covering bitAnd: operations from unsigned 33 bits integer to unsigned 64 > bits integer, but makes no difference in 64 bits. In 64bits all the cases > covered by primitive 34 are covered by primitive 14, so it should even slow > down things. > > *So...* > > Does this answer your questions ? > Don't hesitate to ask further questions. > > If you want more details, I wrote something about special selectors a > while ago: https://clementbera.wordpress.com/2014/08/12/ > arithmetic-inlined-and-special-selectors/ . > > Best, > > Clement > > PS1: If I'm correct, you referenced my blog a couple times, thank you for > doing this, I really appreciate that. > PS2: I enjoy chess myself, so if you have an open-source/MIT working > algorithm at some point please send it to me, I will play against the AI > and look at the code. > > > On Fri, Feb 10, 2017 at 8:18 AM, Benoit St-Jean via Pharo-dev < > pharo-dev(a)lists.pharo.org> wrote: > > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: The General-purpose Squeak Developers List <squeak-dev@lists. > squeakfoundation.org <squeak-dev(a)lists.squeakfoundation.org>>, " > pharo-dev(a)lists.pharo.org" <pharo-dev(a)lists.pharo.org> > Cc: > Date: Fri, 10 Feb 2017 07:18:02 +0000 (UTC) > Subject: Integer arithmetic and bit counting performance in Squeak and > Pharo > For those interested in performance of bit operations and integer > arithmetic in Squeak and Pharo : > > Bit operations in general : https://endormitoire.wordpress > .com/2017/02/10/bits-and- pieces/ > <https://endormitoire.wordpress.com/2017/02/10/bits-and-pieces/> > > Bit counting algorithms : https://endormitoire.wordpress > .com/2017/02/10/1001001-sos/ > <https://endormitoire.wordpress.com/2017/02/10/1001001-sos/> > > Some questions, some results, some answers... > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > > >

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

by FranÃ§ois Stephany

There is a special price for non-profits organization: > The Slack for Nonprofits program offers eligible organizations a *free upgrade* to our Standard plan for teams of up to 250 members. For eligible teams above that size, we offer an 85% discount on the Standard plan. With 322 users it means that we still have to pay... See https://get.slack.help/hc/en-us/articles/204368833-Slack-for-Nonprofits for more information. On Fri, Feb 10, 2017 at 1:18 PM, denker <marcus.denker(a)inria.fr> wrote: > > > > >> I share many of what you sayâ¦ but in the other point of view, Slack as > really worked and there is a lot more happening now in Slack + mailing list > than what was before just in mailing list. > >> But most of that is lost because of Slack policies (also Slack pricing > model is impossible for a community as ours), and we need to find a > solution for that. > > > > Yes this is too expensive for the Pharo consortium ? > > > It is per active memberâ¦ which is defined as âhas logged in the last 14 > daysâ. We have 322 members. No idea how many > are active according to that definition. > > Fot 322 it would be: $8 per user per month. Which means $2576 per month or > $25772 per year (taking the special yearly price into account). > > Marcus > > >

Feb. 10, 2017

Re: [Pharo-dev] Integer arithmetic and bit counting performance in Squeak and Pharo

by Benoit St-Jean

Oh!Â Many thanks for all the details!Â I thought about special selectors and remembered that #bitAnd: and #bitOr: were those special kind of "beasts" but I falsely assumed that #bitXor: was also a special selector... :(Â I should have looked at the code! So that also explains the "strange" behavior of the 64bit image.Â Lots of the tests in the 32bit image fell into the LargeInteger "range" and then, executing the same code on the 64bit image, those numbers suddenly became considered SmallInteger...Â That explains it all and why some operations "suddenly" became so fast for no apparent reason !!! Now, just for my personal curiosity, what is going to be the impact of a 64bit VM on such code? (Unfortunately, I am on Windows so I will have to wait...) ? P.S. I should have persevered in my google searches as I just came across this *excellent* post :Â Arithmetic, inlined and special selectors :) Thanks a lot! | | | | | | | | | | | Arithmetic, inlined and special selectors Today we are going to discuss how message sends are dispatched in the VM and/or compiled in the image for arithm... | | | | Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) From: ClÃ©ment Bera <bera.clement(a)gmail.com> To: Benoit St-Jean <bstjean(a)yahoo.com>; Pharo Development List <pharo-dev(a)lists.pharo.org> Cc: The General-purpose Squeak Developers List <squeak-dev(a)lists.squeakfoundation.org> Sent: Friday, February 10, 2017 5:14 AM Subject: Re: [Pharo-dev] Integer arithmetic and bit counting performance in Squeak and Pharo Hi, This is a lovely post. Thanks for posting about Smalltalk / Pharo / Squeak. - WhyÂ exactlyÂ does the override work (in 32bit images)? - What changed so that things are different in Squeak 5.1 64bit image (overrides partially work)? If I am correct your questions are exclusively for bitOr: and bitAnd:. I don't know what you are aware of and what you're not aware of, hence I am going to give you some details on how bitAnd: is executed (bitOr: is done exactly the same way), and hopefully there will be something you don't know yet that should help you understand what's going on.Â Execution of bitAnd: bitAnd: a special selector. If you run Smalltalk specialSelectors you get this array:Â Â #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #== 1 #class 0 #blockCopy: 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0) which includes bitAnd: . Special selectors are encoded in the bytecode differently to save memory, so they can be executed differently without inducing overhead. In Cog, bitAnd: is executed differently using type-prediction.Â In the Stack Interpreter, the execution of bitAnd: is done as follows:Â Â If both operands are SmallIntegers,Â Â Â Â Â push the bitAnd: value of the 2 SmallIntegersÂ Â elseÂ Â Â Â Â Try the primitive BitAnd for SmallIntegers (14)Â Â Â Â on successÂ Â Â Â Â Â push the resultÂ Â Â Â on failureÂ Â Â Â Â Â perform the send. In the JIT, bitAnd: sends are compiled differently that normal send, the compilation logic is as follows:Â Â If both operands are SmallInteger literalsÂ Â Â Â compute the result during compilation and use this valueÂ Â elseÂ Â Â Â If one of the 2 operands is a SmallInteger literalÂ Â Â Â Â Â generate 2 paths, a quick inlined path testing at runtime that the other operand is a SmallInteger, and if so, Ands the operands and use that result, else use the slow path performing a sendÂ Â Â Â elseÂ Â Â Â Â Â generate a normal send Primitives primitive 14 -> Works for SmallIntegers and LargePositiveInteger fitting in an unsigned machine word. (Slower than direct SmallInteger bitAnd performed by the special selector)primitive 34 -> Works for SmallIntegers and LargePositiveInteger fitting in an unsigned int64. (Slower than primitive 14 in 32 bits but covering more cases, equivalent in 64 bits)primDigitBitAnd (in Integer) -> Works for any integer. (Slower than the primitive 14 and 34) SmallInteger encoding In 32 bits, SmallIntegers are signed 31bits integer.In 64 bits, SmallIntegers are signed 61 bits integer. Discussion Let's make some assertions based on previous information: 1)Â If you have the exact same bitAnd: implementation for #bitAnd: and #bitAnd2:, #bitAnd2: is slower because it is not a special selector. 2) Still with the exact same bitAnd: implementation, using the JIT, things like that:16r1 bitAnd: 1. "1 bits" 16r2 bitAnd: 2. "2 bit" 16r4 bitAnd: 4. "3 bit" 16r8 bitAnd: 3. "4 bit"Are bitAnd: operations between SmallInteger constants and the result is unused. Hence this whole portion of code does not generate any native instructions.On the other hand, things like that:16r1 bitAnd2: 1. "1 bits" 16r2 bitAnd2: 2. "2 bit" 16r4 bitAnd2: 4. "3 bit" 16r8 bitAnd2: 3. "4 bit"Are sends, generating multiple native instructions including calls. 3) Because of the SmallInteger encoding,16r200000000000000 bitAnd: 98490667780264321. "58 bit" is compiled by the JIT to nothing in 64 bits but to a send in 32 bits (the JIT can't solve LargeInteger arithmetic at compilation time). 4) primitive 34 provides some speed-up over primitive 14 in 32 bits, covering bitAnd: operations from unsigned 33 bits integer to unsigned 64 bits integer, but makes no difference in 64 bits. In 64bits all the cases covered by primitive 34 are covered by primitive 14, so it should even slow down things. So... Does this answer your questions ? Don't hesitate to ask further questions.Â If you want more details, I wrote something about special selectors a while ago:Â https://clementbera.wordpress.com/2014/08/12/arithmetic-inlined-and-special… . Best, Clement PS1: If I'm correct, you referenced my blog a couple times, thank you for doing this, I really appreciate that.PS2: I enjoy chess myself, so if you have an open-source/MIT working algorithm at some point please send it to me, I will play against the AI and look at the code. On Fri, Feb 10, 2017 at 8:18 AM, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: ---------- Forwarded message ---------- From:Â Benoit St-Jean <bstjean(a)yahoo.com> To:Â The General-purpose Squeak Developers List <squeak-dev@lists. squeakfoundation.org>, "pharo-dev(a)lists.pharo.org" <pharo-dev(a)lists.pharo.org> Cc:Â Date:Â Fri, 10 Feb 2017 07:18:02 +0000 (UTC) Subject:Â Integer arithmetic and bit counting performance in Squeak and Pharo For those interested in performance of bit operations and integer arithmetic in Squeak and Pharo : Bit operations in general : https://endormitoire.wordpress .com/2017/02/10/bits-and- pieces/ Bit counting algorithms : https://endormitoire.wordpress .com/2017/02/10/1001001-sos/ Some questions, some results, some answers...Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

by denker

> >> I share many of what you sayâ¦ but in the other point of view, Slack as really worked and there is a lot more happening now in Slack + mailing list than what was before just in mailing list. >> But most of that is lost because of Slack policies (also Slack pricing model is impossible for a community as ours), and we need to find a solution for that. > > Yes this is too expensive for the Pharo consortium ? > It is per active memberâ¦ which is defined as âhas logged in the last 14 daysâ. We have 322 members. No idea how many are active according to that definition. Fot 322 it would be: $8 per user per month. Which means $2576 per month or $25772 per year (taking the special yearly price into account). Marcus

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

by Dimitris Chloupis

I have been pushing for Discord because a) There is no need to host and maintain as Esteban said b) There a ton of communities already using it and its by far the second most mature chat client after Slack c) It has a very powerful Python API.... yes I know.... I know its no Pharo but still it makes it very easy to make bots that automate a lot of staff. I am using a bot that fetches RSS feeds (Although not sure how well this is working) connects to the reddit forum and of course fetches git commits d) The team listens to its users e) for personal reason.... all my favorite software (Blender, Unreal etc) is using it I am also making my own bot . I could try to add a way for the bot to connect the mailing list with the Discord channel turn the mailing lists discussions to Discord discussions and vice versa but I have not done this before so no promises. I do have find a website that turns pretty much anything to webhooks which is what Discord uses (probably Slack too) https://ifttt.com/discover I could do the same with Slack , meaning to send Slack messages to Discord and Discord to Slack, I think I found one bot that already does this. In short we can unite everything under one roof and let people keep using whatever people feel comfortable with (Slack, mailing lists, world.st forum, reddit , google hangouts , youtube , github and anything with webhooks or some form of web API) Also the Bot could store its own log even in the unlikely scenario of a nuclear explosion in Discord servers we wont lose our valuable data. Though I think I saw somewhere that Discord allows to backup and export the data so that may be proven unnecessary. On the other hand I will have to find a way to host my bot , but that is not a big deal , the bot is a simple python application and there are a ton of websites which offer hosting for python applications for free. Its getting there but will need time. Also my library Atlas can be used to access the APIs of all these chat software, Slack and Discord included, because Atlas allows you to use python libraries from inside Pharo. So its possible to have tools in the image for those of you that you love never having to leave the image that take advantage of these technologies. I wont be doing this though because a) porting APIs is a project by itself b) most of the code I find is python code and that makes it an easy copy paste approach (the vast majority of it is GPL or MIT licensed)

Feb. 10, 2017

GSOC Pharo application done

by Serge Stinckwich

Dear all, thanks to the efforts of Jigyasa Grover, Yuriy Tymchuk and Alexandre Bergel, , we were able to have a GSOC 2017 application for the Pharo Consortium. This is only the first phase. If we are selected by Google, they will give some slots for students. We have a list of projects for GSOC here : http://gsoc.pharo.org/ If you have more ideas, please send them to me or send a PR on : https://github.com/pharo-project/pharo-project-proposals/blob/master/Topics… Try to describe your project idea with 10-15 lines maximum. The ideas is not too much projects proposals but to find important projects for the Pharo community (i.e that will have some impact for the community) with the support of the appropriate mentors. I would like to have maximum 2-3 projects for each mentors. Thank you. Cheers, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

by phil＠highoctane.be

I am frustated by this too and indeed we need a way to keep the messages. I am about done with my wrapping of LibStrophe in Pharo with , which provides a XMPP/Jabber client to Pharo. So, if someone can activate the XMPP gateway on our Slack instance, we will have a way to archive the contents (and possibly post a kind of digest into a mailing list). https://get.slack.help/hc/en-us/articles/201727913-Connect-to-Slack-over-IR… Phil On Fri, Feb 10, 2017 at 11:42 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 10 Feb 2017, at 11:28, Serge Stinckwich <serge.stinckwich(a)gmail.com> > wrote: > > > > On Fri, Feb 10, 2017 at 10:58 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi Stephan, > >> > >>> On 10 Feb 2017, at 10:27, Stephan Eggermont <stephan(a)stack.nl> wrote: > >>> > >>> The past year we have started using Slack to communicate in real-time > about Pharo. It has nice (mobile) clients and makes it easy to share > pictures and snippets. As a result a large part of the communication about > design and how to do things has moved from the mailing lists to Slack. As > we're using the free version, and cannot afford to use the commercial > version, we have no long-time storage of the design discussions. This > contrasts with our mailing lists, that have a long-term archive. There was > some discussion about this, and I'm not aware of that resulting in an > accessible, easy to access archive. Also, we have not succeeded in > summarizing design discussions from slack to the mailing lists. The > resulting gap in design information forms an enormous long-term risk for > our community. Without the design discussions it is much more difficult to > later understand why decisions were taken. We cannot afford to let this > short-term ease-of-use destroy Pharo's community history, and thereby > Pharo. Let us fix this. > > > > Yes I agree with your concerns. > > > >> I share many of what you sayâ¦ but in the other point of view, Slack as > really worked and there is a lot more happening now in Slack + mailing list > than what was before just in mailing list. > >> But most of that is lost because of Slack policies (also Slack pricing > model is impossible for a community as ours), and we need to find a > solution for that. > > > > Yes this is too expensive for the Pharo consortium ? > > yes it is. > Is just not prepared for open source communities like ours. > > > > >> Last days we were experimenting with @kilon again on use discord as a > substitute and I find that for now it works really well and with a bit of > work we can have all what you want: discord incorporated a search function > (and they do not have the 10k limit) and we could do a bot that logs > everything that happens there and stores that into gists (or whatever, but > gists seems like a good idea). > >> > >> With this we would have enhanced the availability of those discussions > (it remains the fact that immediate communication is worst organised than > mails, but wellâ¦ we need to try) > > > > and move all the community on discord ? > > this is what I would like to propose, because... > > > Or use an open-source slack > > the problem with this is that we have to host itâ¦ and then is more > problems for maintenance, etc. > > Esteban > > > like : https://about.mattermost.com/ > > and host our own chat server. > > > > -- > > Serge Stinckwich > > UCBN & UMI UMMISCO 209 (IRD/UPMC) > > Every DSL ends up being Smalltalk > > http://www.doesnotunderstand.org/ > > > > >

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Final rush for submitting GSOC proposal - Need your help

by Serge Stinckwich

On Thu, Feb 9, 2017 at 5:28 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 09/02/17 17:05, Serge Stinckwich wrote: >> >> but all the projects are coming from RMOD team, but having all the >> projects proposal coming from the same place might be perceived >> negatively from Google. Can we add more projects from previous gsoc >> from other people also ? > > > My two earlier proposals are fine, and already on the site. Can you reduce the size of the "Distributed Issue Tracker" subject because there is too much details compared to other subjects. Thank you. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 10, 2017

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

by Esteban Lorenzano

> On 10 Feb 2017, at 11:28, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > On Fri, Feb 10, 2017 at 10:58 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi Stephan, >> >>> On 10 Feb 2017, at 10:27, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> The past year we have started using Slack to communicate in real-time about Pharo. It has nice (mobile) clients and makes it easy to share pictures and snippets. As a result a large part of the communication about design and how to do things has moved from the mailing lists to Slack. As we're using the free version, and cannot afford to use the commercial version, we have no long-time storage of the design discussions. This contrasts with our mailing lists, that have a long-term archive. There was some discussion about this, and I'm not aware of that resulting in an accessible, easy to access archive. Also, we have not succeeded in summarizing design discussions from slack to the mailing lists. The resulting gap in design information forms an enormous long-term risk for our community. Without the design discussions it is much more difficult to later understand why decisions were taken. We cannot afford to let this short-term ease-of-use destroy Pharo's community history, and thereby Pharo. Let us fix this. > > Yes I agree with your concerns. > >> I share many of what you sayâ¦ but in the other point of view, Slack as really worked and there is a lot more happening now in Slack + mailing list than what was before just in mailing list. >> But most of that is lost because of Slack policies (also Slack pricing model is impossible for a community as ours), and we need to find a solution for that. > > Yes this is too expensive for the Pharo consortium ? yes it is. Is just not prepared for open source communities like ours. > >> Last days we were experimenting with @kilon again on use discord as a substitute and I find that for now it works really well and with a bit of work we can have all what you want: discord incorporated a search function (and they do not have the 10k limit) and we could do a bot that logs everything that happens there and stores that into gists (or whatever, but gists seems like a good idea). >> >> With this we would have enhanced the availability of those discussions (it remains the fact that immediate communication is worst organised than mails, but wellâ¦ we need to try) > > and move all the community on discord ? this is what I would like to propose, because... > Or use an open-source slack the problem with this is that we have to host itâ¦ and then is more problems for maintenance, etc. Esteban > like : https://about.mattermost.com/ > and host our own chat server. > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

Feb. 10, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 10, 2017