- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can Sound depend on Jobs?

by Denis Kudriashov

2016-09-05 9:55 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: > Do you mean that job depends on sound? I guess Sean wants put #beepAtEnd to Sound package as Job extension. Is such dependency valid?

Sept. 5, 2016

Re: [Pharo-dev] could we discuss 19006

by Guille Polito

Some aside-answers on the issue: The AbstractFileStream and its two childs are not "a stream library implementation" but low level streams that implement the primitives to talk to files. And their purpose is to provide a clean implementation of binary file streams that implement no buffering, no encoding, no text conversion. And so clean the usage of MultiByteCharacterMaybeTextMaybeBufferedMaybeBinaryMaybeReadMaybeWrite streams. Buffering, encoding, convertion to text and other facilities can be obtained by using the already provided Zn* facilities: - ZnBufferedRead/WriteStream - ZnEncodedStream and so on. Nice thing: the Zn* thingys are well tested, documented, and already used for socket streams. We can reuse them for files for free :) Guille -------- Original Message -------- > stepharo wrote >> Note that I'm not against. I just want to understand. > Me too. I looked over the issue, and it seemed one would already have to > understand the issue very well. I wished there was more explanation about > the problem and why the solution was a good one. In the end, I shrugged my > shoulders and just had to trust the author. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/could-we-discuss-19006-tp4913965p4914079.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 5, 2016

Re: [Pharo-dev] about package naming

by Nicolas Passerini

Yes Icebergs uses RPackages, I have RPackages and Tags and I do not remember having problems. On Mon, Sep 5, 2016 at 9:50 AM, Guille Polito <guillermopolito(a)gmail.com> wrote: > As far as I understand, Iceberg uses RPackages. And RPackages do not > necessarily follow MC conventions. > > > -------- Original Message -------- > > <offtopic> > Wow, I do not know where that email came from O_o. > It looks a spammish email. Maybe it came from my phone? > > If it happens again, please tell me so I can take action. > </offtopic> > > Now in-topic: I agree with having conventions and with the tests one > particularly. But as you say, we should also think what are the benefits in > terms of tooling so people do not feel forced to use it: they feel > attracted to use it :). > > > -------- Original Message -------- > > No guillermo. This is really annoying. > > With long package list like Collections* then you do not see well the > tests. > > So we should check the bug like that we are free. > > Je suis pas de place que no necesita activar gustamucho la ð¶ que ya el > otro lado > > Le 4 sept. 2016 10:18, "stepharo" <stepharo(a)free.fr> a Ã©crit : > >> Hi guys >> >> Sorry to be that dull and stupid but I do not get why (beside following >> the seaside convention - and I do not understand it either) why the test >> package for FileSystem-Core is named FileSystem-Tests-Core >> >> and not just >> >> FileSystem-Core-Tests >> >> like that we could have >> >> FileSystem-Core-Help >> >> FileSystem-Core-Examples >> >> And when we are looking for FileSystem-Core we can see automatically >> FileSystem-Core-Tests >> >> Now we cannot. >> >> Stef >> >> >> > > >

Sept. 5, 2016

Re: [Pharo-dev] Can Sound depend on Jobs?

by Guille Polito

Do you mean that job depends on sound? I think it should not. Can't that be an extension of yours? (in a method extension, in a separate package)? Guille -------- Original Message -------- > I wanted to add as an extension method to the Sound package: > Job>>#beepAtEnd > "Sound must first be enabled via `SoundSystem soundEnabled: true.`" > > self announcer when: JobEnd do: [ SoundSystem current beep ] > > I figured I'd get some feedback first since I know we're trying to reduce > dependencies... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Can-Sound-depend-on-Jobs-tp4914083.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 5, 2016

Re: [Pharo-dev] about package naming

by Guille Polito

As far as I understand, Iceberg uses RPackages. And RPackages do not necessarily follow MC conventions. -------- Original Message -------- > <offtopic> > Wow, I do not know where that email came from O_o. > It looks a spammish email. Maybe it came from my phone? > > If it happens again, please tell me so I can take action. > </offtopic> > > Now in-topic: I agree with having conventions and with the tests one > particularly. But as you say, we should also think what are the > benefits in terms of tooling so people do not feel forced to use it: > they feel attracted to use it :). > > > -------- Original Message -------- >> >> No guillermo. This is really annoying. >> >> With long package list like Collections* then you do not see well the >> tests. >> >> So we should check the bug like that we are free. >> >>> Je suis pas de place que no necesita activar gustamucho la ð¶ que >>> ya el otro lado >>> >>> >>> Le 4 sept. 2016 10:18, "stepharo" <stepharo(a)free.fr >>> <mailto:stepharo@free.fr>> a Ã©crit : >>> >>> Hi guys >>> >>> Sorry to be that dull and stupid but I do not get why (beside >>> following the seaside convention - and I do not understand it >>> either) why the test package for FileSystem-Core is named >>> FileSystem-Tests-Core >>> >>> and not just >>> >>> FileSystem-Core-Tests >>> >>> like that we could have >>> >>> FileSystem-Core-Help >>> >>> FileSystem-Core-Examples >>> >>> And when we are looking for FileSystem-Core we can see >>> automatically FileSystem-Core-Tests >>> >>> Now we cannot. >>> >>> Stef >>> >>> >> >

Sept. 5, 2016

Re: [Pharo-dev] about package naming

by Guille Polito

<offtopic> Wow, I do not know where that email came from O_o. It looks a spammish email. Maybe it came from my phone? If it happens again, please tell me so I can take action. </offtopic> Now in-topic: I agree with having conventions and with the tests one particularly. But as you say, we should also think what are the benefits in terms of tooling so people do not feel forced to use it: they feel attracted to use it :). -------- Original Message -------- > > No guillermo. This is really annoying. > > With long package list like Collections* then you do not see well the > tests. > > So we should check the bug like that we are free. > >> Je suis pas de place que no necesita activar gustamucho la ð¶ que ya >> el otro lado >> >> >> Le 4 sept. 2016 10:18, "stepharo" <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> a Ã©crit : >> >> Hi guys >> >> Sorry to be that dull and stupid but I do not get why (beside >> following the seaside convention - and I do not understand it >> either) why the test package for FileSystem-Core is named >> FileSystem-Tests-Core >> >> and not just >> >> FileSystem-Core-Tests >> >> like that we could have >> >> FileSystem-Core-Help >> >> FileSystem-Core-Examples >> >> And when we are looking for FileSystem-Core we can see >> automatically FileSystem-Core-Tests >> >> Now we cannot. >> >> Stef >> >> >

Sept. 5, 2016

SmallLintRule RBGuardingClauseRule and RBGuardClauseRule

by Nicolai Hess

We have to similar rules RBGuardClauseRule and RBGuardingClauseRule One is a ParseTreeLintRule, the other one is a TransformationRule. I don't know why we have to at all. One rule was "disabled" (or not chown) in the CriticsBrowser because it was removed from the set of all rules before opening CriticsBrowser (see method #allGoodRules). In the past, monty fixed the class comment and #rational for class RBGuardClauseRule to correctly explain what this rule is about. This of course now differes from the similar rule RBGuardingClauseRule. 1. Why do we have both (ok, on can only select the rule violation, whereas the other on does not select it but shows the possible transformation 2. why is the second one now in the set of all rules used by CriticsBrowser 3. what to do ? Remove one, fix the comment and #rational for the second one? nicolai

Sept. 5, 2016

Re: [Pharo-dev] Bizarre Text Selection in Pharo 5.0

by Nicolai Hess

2016-09-04 19:54 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Max Leske wrote > > Please open a new issue (you can add me to the notification list). > > Done. Sorry for the delay. > https://pharo.fogbugz.com/f/cases/19036/Bizarre-Text- > Selection-in-Pharo-5-0 Can you add the platform information. I can not reproduce this on windows And does this happens only for $[ or for the other smart characters as well? > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bizarre- > Text-Selection-in-Pharo-5-0-tp4908498p4914071.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Sept. 5, 2016

Re: [Pharo-dev] about package naming

by stepharo

Guille do you know if iceberg has the same problem? I do not remember what nicolas mentionned about if MC entities were kept around and used. Stef

Sept. 5, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] e64121: 60202

by stepharo

Sean this is like that since years. Stef Le 4/9/16 Ã 20:06, Sean P. DeNigris a Ã©crit : > GitHub wrote >> 19001 Another pass to introduce iconNamed: and avoid Smalltalk ui icons >> https://pharo.fogbugz.com/f/cases/19001 > This one surprised me. I thought we were trying to avoid extensions to > low-level classes when possible. How is icon retrieval a responsibility of > ClassDescription?! I'm all about convenience, but not getting this change. > Was there a discussion somewhere? What benefits am I missing? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/pharo-project-pharo-core-e64121-60202-tp4914016p49140… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Sept. 5, 2016