September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Message browser strange new behavior

by Nicolas Passerini

I agree, it is sometimes difficult to find a class in the message browser because of the inheritance organization. I think that most often I do not want that, but also it might be useful in other circunstances, so maybe the best would be to have both possibilities and make is easy to change from one to the other. On Sun, Sep 4, 2016 at 10:10 AM, stepharo <stepharo(a)free.fr> wrote: > Hi denis > > I looked at senders of iconNamed: > > and when I see a Smalltalk ui icons iconNamed: I change it into self > iconNamed: when I can. > > May be I was also changing the superclass to be Model and this would be > the problem. > > It would be nice to have the possibility to get the list displayed not > following inheritance but > > just based on alphabetic name of classes. > > > Stef > > Le 4/9/16 Ã 10:05, Denis Kudriashov a Ã©crit : > > I can't reproduce (or I not see it) > Could you explain more? > > 2016-09-03 22:11 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi >> >> >> Often I look at senders and I modify them directly in the message browser >> and I do not one by one. >> >> Now when I recompile a method I get a new one and I lose the next one. >> >> Am I the only one to have this behavior. It is highly disrputing. >> >> Stef >> >> >> > >

Sept. 5, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] c0db47: 60199

by Marcus Denker

> > Log Message: > ----------- > 10025 MethodDictionary at:put: and #flushCache > https://pharo.fogbugz.com/f/cases/10025 > For this one we need to carefully check if there are bad side effects. it should work as now at:put: is the fall-back case and flushes by selector. (instead of clients having to do it explicitly) Marcus

Sept. 5, 2016

Re: [Pharo-dev] Iceberg Question

by Nicolas Passerini

Yes, it can be cryptic. It would be nice that we discuss which is the best vocabulary to use so that it is clear both for people with or without a strong git background. Iceberg does not have a "pull" operation, as it is intended from the git command line. Instead you have fetch and merge separately (remember: git pull = git fetch + git merge). In this way, you first download all new versions from the remote repository, you can browse them, and then you can decide to: a. Merge the remote changes into your local branch b. Load any version, without merging (which in git is called "detached head"). I thought this way (more similar to current Pharo tools than to the git command line) is better for our needs, but I could be wrong. Or we could have both. Also, one tricky thing here is that "incomming changes" could be two different things: - changes in the remote repository but not merged into your current branch. - changes in your current branch but not loaded into the image I am not sure how should be the best way to show that information. On Sun, Sep 4, 2016 at 8:56 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I have a question regarding the window: > > > Why if I want to retrieve the new versions, I need to press the button > âFetch new versionsâ. I think I should do a pull ? But instead, i can do a > load or a merge. A bit crypticâ¦ > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Sept. 5, 2016

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

by Guille Polito

The questions we should ask ourselves always: - Would it make sense to use Sound without Jobs? - Would it make sense to use Jobs without Sound? First, I just want to say I do not have the answer to that question because I do not know those packages very well. Butttt.... it's smelly to me. My reflex is to put that as a third package. Second and more meta, I think we should ask ourselves those questions more often (just like Sean did, thanks Sean! :D). -------- Original Message -------- > > 2016-09-05 9:55 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com > <mailto:guillermopolito@gmail.com>>: > > Do you mean that job depends on sound? > > > I guess Sean wants put #beepAtEnd to Sound packageas Job extension. Is > such dependency valid?

Sept. 5, 2016

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