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

Re: [Pharo-dev] Tired of losing messages after 10k. Can we re-discuss moving Slack community to Discord?

by Alexandre Bergel

I would not mind moving to Discord. But, what is the plan to kill Slack? Can a Slack project be simply removed? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Apr 7, 2017, at 8:59 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > That. > Iâm also willing to try another service if you find something better, but I find discord cool enough. > Some remarks: > > - I actually like Slack. The problem is the amount of information lost because they do not display more than 10k lines (or we pay, and is super expensive). > - No, plain #irc is not an option. Community has talkedâ¦ and it does not worksâ¦ I have had more productive talks in one month in Slack than 5 years trying #irc. > > cheers! > Esteban > >

April 7, 2017

Re: [Pharo-dev] Tired of losing messages after 10k. Can we re-discuss moving Slack community to Discord?

by Norbert Hartl

I'm on discord now. Ready to leave slack Norbert > Am 07.04.2017 um 14:19 schrieb philippe.back(a)highoctane.be <philippe.back(a)gmail.com>: > > My xmpp client works okay now for that use case. Enable the gateway and I'll be able to pick them up, store them and make them searchable. > > Phil > > Le 7 avr. 2017 14:04, "Pavel Krivanek" <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> a Ã©crit : > Let's simply do it :-) > > -- Pavel > > 2017-04-07 13:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > Hi, > > That. > Iâm also willing to try another service if you find something better, but I find discord cool enough. > Some remarks: > > - I actually like Slack. The problem is the amount of information lost because they do not display more than 10k lines (or we pay, and is super expensive). > - No, plain #irc is not an option. Community has talkedâ¦ and it does not worksâ¦ I have had more productive talks in one month in Slack than 5 years trying #irc. > > cheers! > Esteban > > >

April 7, 2017

Re: [Pharo-dev] Tired of losing messages after 10k. Can we re-discuss moving Slack community to Discord?

by philippe.back＠highoctane.be

My xmpp client works okay now for that use case. Enable the gateway and I'll be able to pick them up, store them and make them searchable. Phil Le 7 avr. 2017 14:04, "Pavel Krivanek" <pavel.krivanek(a)gmail.com> a Ã©crit : > Let's simply do it :-) > > -- Pavel > > 2017-04-07 13:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Hi, >> >> That. >> Iâm also willing to try another service if you find something better, but >> I find discord cool enough. >> Some remarks: >> >> - I actually like Slack. The problem is the amount of information lost >> because they do not display more than 10k lines (or we pay, and is super >> expensive). >> - No, plain #irc is not an option. Community has talkedâ¦ and it does not >> worksâ¦ I have had more productive talks in one month in Slack than 5 years >> trying #irc. >> >> cheers! >> Esteban >> >> >> >

April 7, 2017

Re: [Pharo-dev] Tired of losing messages after 10k. Can we re-discuss moving Slack community to Discord?

by Pavel Krivanek

Let's simply do it :-) -- Pavel 2017-04-07 13:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > That. > Iâm also willing to try another service if you find something better, but > I find discord cool enough. > Some remarks: > > - I actually like Slack. The problem is the amount of information lost > because they do not display more than 10k lines (or we pay, and is super > expensive). > - No, plain #irc is not an option. Community has talkedâ¦ and it does not > worksâ¦ I have had more productive talks in one month in Slack than 5 years > trying #irc. > > cheers! > Esteban > > >

April 7, 2017

Tired of losing messages after 10k. Can we re-discuss moving Slack community to Discord?

by Esteban Lorenzano

Hi, That. Iâm also willing to try another service if you find something better, but I find discord cool enough. Some remarks: - I actually like Slack. The problem is the amount of information lost because they do not display more than 10k lines (or we pay, and is super expensive). - No, plain #irc is not an option. Community has talkedâ¦ and it does not worksâ¦ I have had more productive talks in one month in Slack than 5 years trying #irc. cheers! Esteban

April 7, 2017

Re: [Pharo-dev] Glamour Fast List selection bug or incorrect usage?

by Juraj Kubelka

Hi Andrei! > On Apr 6, 2017, at 07:05, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > On Tue, Apr 4, 2017 at 5:01 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: > Hi, > > yes, it is better, but it does not work intuitively. Try the following: > > 1. execute your script, > 2. click on 4 (selection), > 3. click on 8 (selection), > 4. click on 4 (deselection), > 5. click on 4 (selection) > > You can see that the third list still keeps the number 8. It is necessary to deselect 8 in order to see 4. > > Indeed, this is not what you'd expect. > > > This part explains to me how the transmit works: > > ``` > tabulator transmit > from: #one; to: #three; > from: #two; to: #three; > transformed: [ :x :y | y ifNil: [ x ] ifNotNil: [ y ] ]; > andShow: [ :a | > a fastList display: [ :x | Array with: x ] ]. > ``` > > By using #transformed: I can decide what to use (#one or #two). It is nice feature! > > I think what I need is having to possibility to change the third list also according to what list is active (#one or #two). > In the first screenshot, the first list is active (blue border). In the second screenshot, the second list is active. > So I would like to update the third list according to the active one. > Is it possible? > > Unfortunately this doesn't work out of the box. > We'll need to implement something that can generate evens/populates a port when a presentation gets the focus. Does it make sense such feature? I am willing to do it. Can you give me some starting points? My knowledge about Glamour design is a bit weak. I suppose that it is necessary to subscribe for MorphGotFocus and MorphLostFocus in each renderer and do some actions accordingly, right? What are the actions? Thanks! Juraj > > Cheers, > Andrei > > > <Screen Shot 2017-04-04 at 11.52.42.png><Screen Shot 2017-04-04 at 11.52.53.png> > > Thanks! > Juraj > >> On Apr 3, 2017, at 18:53, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: >> >> Hi, >> >> That's actually the default behavior, but I see there is also a bug. >> Normally if you want to allow deselection in a presentation you should use allowDeselection. Just I see there is a bug in the fast table renderer because if I add #allowDeselection to the first presentation when clicking again on the selected element the selection port is not cleared. If you use #list instead of #fastList it works. >> >> I think you can get the desired behaviur using this code: >> >> ----------------------------------------------------------------- >> tabulator := GLMTabulator new. >> >> tabulator column: #one; column: #two; column: #three. >> >> tabulator transmit to: #one; andShow: [ :composite | >> composite list >> allowDeselection; >> display: [ :x | Array with: x ] ]. >> tabulator transmit to: #two; andShow: [ :composite | >> composite list >> allowDeselection; >> display: [ :x | Array with: 2 * x ] ]. >> >> tabulator transmit >> from: #one; to: #three; >> from: #two; to: #three; >> transformed: [ :x :y | y ifNil: [ x ] ifNotNil: [ y ] ]; >> andShow: [ :a | >> a fastList display: [ :x | Array with: x ] ]. >> >> tabulator openOn: 4. >> ----------------------------------------------------------------- >> >> >> Cheers, >> Andrei >> >> On Mon, Apr 3, 2017 at 9:35 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: >> Hi! >> >> If you create the following Glamour browser: >> >> ``` >> tabulator := GLMTabulator new. >> >> tabulator column: #one; column: #two; column: #three. >> >> tabulator transmit to: #one; andShow: [ :composite | >> composite fastList display: [ :x | Array with: x ] ]. >> tabulator transmit to: #two; andShow: [ :composite | >> composite fastList display: [ :x | Array with: 2 * x ] ]. >> >> tabulator transmit from: #one; to: #three; andShow: [ :a | >> a fastList display: [ :x | Array with: x ] ]. >> tabulator transmit from: #two; to: #three; andShow: [ :a | >> a fastList display: [ :x | Array with: x ] ]. >> >> tabulator openOn: 4. >> ``` >> >> You will get the following browser: >> >> <Screen Shot 2017-04-03 at 16.30.28.png> >> >> if you then select 4, the third list appears. If you then select 8, the value is changed: >> >> <Screen Shot 2017-04-03 at 16.29.38.png> >> >> But since then, the third list does not change. It stays with 8 value forever. >> >> Do I miss something? Should I define it differently? >> Or if it is a bug: Can you give me insights how to fix it? >> >> Tested in the latest Pharo 6. >> >> Thanks! >> Juraj

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by marcus.denker＠inrira.fr

> > 1) itâs not only about removing. Maybe we should detect complicated boolean expressions that return something and suggest to break them down. No ideaâ¦ > 2) I just want to know why someone created such rule :). Because the author of the last update of the initialize method is Marcus :) > I did not add it originally. Marcus

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Gabriel Cotelli

The Boolean expression is easier to extract methods with an intention revealing name. The "case with returns " it's harder to automatically refactor. And if you get rid of the nils, it became easier to read and refactor. ð On Apr 7, 2017 07:06, "Yuriy Tymchuk" <yuriy.tymchuk(a)me.com> wrote: On 7 Apr 2017, at 12:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: On 7 Apr 2017, at 11:23, marcus.denker(a)inrira.fr <marcus.denker(a)inria.fr> wrote: On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: Hi, there is a rule that suggests to use and/or boolean operations instead of multiple returns. For example it suggests agains using: isTranslucentButNotTransparent backgroundColor ifNil: [ ^ true ]. (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. ^ false Instead you should use: isTranslucentButNotTransparent ^ backgroundColor isNil or: [ (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] And at least a few developers think that the suggested implementation is more complicated to comprehend. I really do not like the complex boolean expressionsâ¦ my brain can understand the âcheck and returnâ guards extremely fast: backgroundColor ifNil: [ ^ true ]. (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. ^ false while for the nesting everything in one huge or: /and: expression I have to think. I always feel that replacing the âguardâ style with complex nested booleans makes the code worse. I really would like to remove the rule. +42 1) itâs not only about removing. Maybe we should detect complicated boolean expressions that return something and suggest to break them down. 2) I just want to know why someone created such rule :). Because the author of the last update of the initialize method is Marcus :) Uko Marcus

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Yuriy Tymchuk

> On 7 Apr 2017, at 12:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 7 Apr 2017, at 11:23, marcus.denker(a)inrira.fr <mailto:marcus.denker@inrira.fr> <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >>> >>> On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> Hi, there is a rule that suggests to use and/or boolean operations instead of multiple returns. >>> >>> For example it suggests agains using: >>> >>> isTranslucentButNotTransparent >>> >>> backgroundColor ifNil: [ ^ true ]. >>> (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >>> (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >>> ^ false >>> >>> Instead you should use: >>> >>> isTranslucentButNotTransparent >>> >>> ^ backgroundColor isNil or: [ >>> (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ >>> borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] >>> >>> And at least a few developers think that the suggested implementation is more complicated to comprehend. >>> >> >> I really do not like the complex boolean expressionsâ¦ my brain can understand the âcheck and returnâ guards extremely fast: >> >> backgroundColor ifNil: [ ^ true ]. >> (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >> (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >> ^ false >> >> while for the nesting everything in one huge or: /and: expression I have to think. I always feel that replacing the âguardâ >> style with complex nested booleans makes the code worse. >> >> I really would like to remove the rule. > > +42 1) itâs not only about removing. Maybe we should detect complicated boolean expressions that return something and suggest to break them down. 2) I just want to know why someone created such rule :). Because the author of the last update of the initialize method is Marcus :) Uko > >> >> Marcus >

April 7, 2017

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

by Esteban Lorenzano

> On 7 Apr 2017, at 11:23, marcus.denker(a)inrira.fr <marcus.denker(a)inria.fr> wrote: > >> >> On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi, there is a rule that suggests to use and/or boolean operations instead of multiple returns. >> >> For example it suggests agains using: >> >> isTranslucentButNotTransparent >> >> backgroundColor ifNil: [ ^ true ]. >> (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >> (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. >> ^ false >> >> Instead you should use: >> >> isTranslucentButNotTransparent >> >> ^ backgroundColor isNil or: [ >> (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ >> borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ] >> >> And at least a few developers think that the suggested implementation is more complicated to comprehend. >> > > I really do not like the complex boolean expressionsâ¦ my brain can understand the âcheck and returnâ guards extremely fast: > > backgroundColor ifNil: [ ^ true ]. > (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. > ^ false > > while for the nesting everything in one huge or: /and: expression I have to think. I always feel that replacing the âguardâ > style with complex nested booleans makes the code worse. > > I really would like to remove the rule. +42 > > Marcus

April 7, 2017