December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Remote debugger progress

by Mariano Martinez Peck

This is very cool Denis. I just watched the video. I am very glad you continue Nick's project (he was coworker of mine back at Douai). We had lots of nice discussions...about proxies, about Fuel, etc etc etc. I am happy you are now in Rmod team. Enjoy! Best, On Tue, Dec 1, 2015 at 1:40 PM, Ben Coman <btc(a)openinworld.com> wrote: > That is exciting to hear. Potentially great for web servers and > embedded systems. > Are you consider handling/testing poor internet connections... > > http://stackoverflow.com/questions/130354/how-do-i-simulate-a-low-bandwidth… > cheers -ben > > On Tue, Dec 1, 2015 at 11:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > Hello. > > > > My name is Denis Kudriashov. I'm a new engineer in Rmod team. I'm > working on > > remote debugger project. And I want to share a little progress on it. > > > > Our idea is make current tools working with remote smalltalk images. We > not > > try to build new tools but we will adapt existed ones to be able to use > it > > for remote systems exploration. (maybe new tools will be needed but not > > now). > > > > Project is based on Seamless communication layer. It is kind of remote > > smalltalk. I fixed and improved it to the state when debugger can be > opened > > on shared remote process. Opening debugger api was cleaned. > > > > Current result is kind of prove of work. It's a bit slow and sometimes > > hangs. Next steps will be make it fast and stable. Some work on Pharo > > internals will be required. > > > > See attached video. (slowness and hangs are there :)). > > > > RemoteDebugger. Initial result > > > > Best regards, > > Denis > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2015

Is it possible to use GTDebugger with DarkTheme?

by Mariano Martinez Peck

Hi guys, I am trying to use GTDebugger in Pharo 4.0 but I find it complicated using it with DarkTheme set. It looks like if GTDebugger would not take into account some theme settings? I tried in 4.0 and 5.0. Look at the attached screenshot. The complicated part is the left pane, where the stack is. As you can see, the font is too dark for such a dark background. Also..should GTDebugger work in Pharo 4.0? If true, which version? Any idea? -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by GastÃ³n Dall' Oglio

You are welcome. Or you can use the API directly, but I do not know if it is paid or if you are limited to 10k latest messages https://api.slack.com/methods/channels.history Regards 2015-12-02 11:14 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Thanks Gaston > > I created the Pharo Slack's bot for it, but I'm getting a connection > refused error when trying to set up the SlackDigest.com integration. > I'll try later. > > Regards! > > > Esteban A. Maringolo > > > 2015-12-02 11:05 GMT-03:00 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com > >: > > Hello. > > > > Just a thought ... There's a automated tool for do that (I have not tried > > yet) > > http://slackdigest.com/digest.html > > > > It send a DM to interested users, but maybe using Outgoing WebHooks the > DM > > can be forwarded to some service to publish it. > > > > > > > > 2015-11-30 17:47 GMT-03:00 philippe.back(a)highoctane.be > > <philippe.back(a)gmail.com>: > >> > >> And I've not been looking at Slack that much. > >> > >> Digest would be we nice indeed. > >> > >> Phil > >> > >> On Nov 30, 2015 4:53 AM, "EuanM" <euanmee(a)gmail.com> wrote: > >>> > >>> And of course, we can stop doing it manually once threading arrives. > >>> > >>> On 30 November 2015 at 03:52, EuanM <euanmee(a)gmail.com> wrote: > >>> > I have been talking to the Slack dev team and they assure me that > >>> > threading is on its way - as a priority. > >>> > > >>> > I am happy to manually curate threads if someone gets a 24hour dump > to > >>> > log files working. > >>> > > >>> > The best way to do this would be to have teams of curators per > >>> > channel, each doing a little curation periodically on a rota per > >>> > channel basis. > >>> > > >>> > This is an ideal task for people still getting up to speed with Pharo > >>> > internals. It is a great way to be exposed to stuff you don't > >>> > understand, and put your mind around it. > >>> > > >>> > This provide a starter slope for future contributors. > >>> > > >>> > On 23 November 2015 at 08:14, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > >>> > wrote: > >>> >> The problem is, that it is not that easy to create a âdigestâ from > >>> >> Slack, as there is no kind of grouping. Either you have to detect > similar > >>> >> words in discussion, or you have to simply export everything. I > donât know > >>> >> whether it makes sense to just compose a huge email of all > discussions, but > >>> >> we can try to do that. > >>> >> > >>> >> Cheers. > >>> >> Uko > >>> >> > >>> >>> On 23 Nov 2015, at 00:21, EuanM <euanmee(a)gmail.com> wrote: > >>> >>> > >>> >>> I agree - if we can have each 24 hours of chat archived to > somewhere > >>> >>> that provides a free-text search, that would be very good. > >>> >>> > >>> >>> Up until now, I've been grabbing, editting and posting chats I find > >>> >>> of > >>> >>> interest and importance to me. And it seems to lend itself to > design > >>> >>> discussions. What it's not very good at, atm, is discussion > >>> >>> threading. It would be great to be able to set your typing as > >>> >>> belonging to a thread., so that when it get sucked out and archived > >>> >>> that the threads were segregated. > >>> >>> > >>> >>> Does someone have a server that could receive a text dump of all > >>> >>> recent Slack messages every 12 (or 24, or 6) hours, and then make > it > >>> >>> available for indexing by Google et al, and querying (via the > search > >>> >>> engines) by our dev base? > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> On 22 November 2015 at 13:57, Dimitris Chloupis > >>> >>> <kilon.alios(a)gmail.com> wrote: > >>> >>>> Just to clear something up , because I see people in slack saying > >>> >>>> goodbye, > >>> >>>> or "I cant reply right now I have something to do" . Slack is not > >>> >>>> just a > >>> >>>> real time chat, it keeps messages inside a history of 10 thousand > >>> >>>> messages. > >>> >>>> So that means you can log in Slack at any time and not lose a > >>> >>>> message. There > >>> >>>> is no reason for you to be online all time, no reason to say > >>> >>>> goodbye, > >>> >>>> goodmorning , goodafternoon. You can come and go as you please the > >>> >>>> exact > >>> >>>> same way as the mailing list. > >>> >>>> > >>> >>>> The problem arises when we exceed 10k messages, the old ones get > >>> >>>> lost and I > >>> >>>> think having a place to store them is a good idea. > >>> >>>> > >>> >>>> Also what is important is in the eye of the beholder, for example > I > >>> >>>> dont > >>> >>>> care about any discussion about web development , its just does > not > >>> >>>> interest > >>> >>>> me or database coding or many other things. I have learned to > filter > >>> >>>> out the > >>> >>>> messages I dont care about in the mailing list and just reject > them. > >>> >>>> Slack > >>> >>>> is same story, I quickly glance through its history and I can > search > >>> >>>> the > >>> >>>> messages that interest me using the search bar , I can star > messages > >>> >>>> that I > >>> >>>> want to keep, and I can comment on existing messages / code > snippets > >>> >>>> which > >>> >>>> create a thread about that message. > >>> >>>> > >>> >>>> In the end its impossible to keep the community in one place but > to > >>> >>>> have a > >>> >>>> central hub that collects all the little gems can be quite useful. > >>> >>>> > >>> >>>> On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> > wrote: > >>> >>>>> > >>> >>>>> Yes this would be good. > >>> >>>>> People should understand that important discussions should be via > >>> >>>>> the > >>> >>>>> mailing-list. > >>> >>>>> Emails are good because you can consume them the way you want. > >>> >>>>> I simply cannot be connected all the time. So emails are good > >>> >>>>> because I > >>> >>>>> can process them > >>> >>>>> when I decide. > >>> >>>>> Slack is good for more interactive session around debugger and > >>> >>>>> things > >>> >>>>> like that. > >>> >>>>> > >>> >>>>> Stef > >>> >>>>> > >>> >>>>> > >>> >>>>> Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : > >>> >>>>>> Should we have a digest from slack to a mailing list? > >>> >>>>>> We are already losing messages > >>> >>>>>> > >>> >>>>>> Stephan > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>> > >>> >>>>> > >>> >>>> > >>> >>> > >>> >> > >>> >> > >>> > > > >

Dec. 2, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Sven Van Caekenberghe

> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > > >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> > >> @Doru > >> Youâre missing the point: #anyOne *fails* for empty collections. > > > > I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. > > > > And sum: should be generic because of its name. > > I am missing understanding the other use cases. Can you describe > further the generic nature of #sum & #sum: ? I would have thought by > default they only applied to numbers. > > sum can be applied to anything that supports #+, not only numbers > sum: can be applied to any collection with a block that return some object that supports #+ > > therefore you can not assume 0 (<- a number) is a proper initial value therefore you *need* to work with #anyOne > and as you can not assume a proper initial value, you can not assume a default value for empty collections > -> it should throw an error. If you (the caller of the function) knows what to do with an empty collection you have > to check, or call inject:into: directly, with a proper initial value. I am sorry but I am getting really tired of this, you should read what is being said. I am not suggesting to stop using #anyOne because I like why it is there and what it can do. The change I want is what happens with an empty collection when using the simplest selector, #sum. I do not want to say to some collection of numbers #sumIfEmpty: [0], because summing numbers starting from zero is the most common case and everybody expects that, hence the unary selector fits. I want the less common cases to use the more complicated API, as in some collection of colors #sumIfEmpty: [ Color black ] In my book that is common sense API design. Doing that I do no take anything away, because today you already have to make sure the collection is not empty. The only change would be in the error behaviour. I think that is a reasonable price to pay. Instead of having #anyOne fail, it will say that #+ cannot add 0 to some object, and in a comment we can point to the alternative API. http://izquotes.com/quote/242740 right ? > cheers -ben > > > > >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >>> > >>> I don't want to be heretic (or too orthodox), but why not to delegate > >>> this behavior to other class (an iterator maybe?). > >>> > >>> It's too tempting adding these convenience methods to Collection > >>> and/or subclasses, but anything that requires an explicit protocol of > >>> its elements is wrong, IMO. > >>> > >>> something like aCollection arithmetic sum: [...] or.... aCollection > >>> arithmetic avg. > >> > >> > >> Interesting thought! > > > > +100 > > > > Doru > > > >>> > >>> My two cents for this. > >>> > >>> Regards! > >>> > >>> > >>> Esteban A. Maringolo > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow." > > > > > > > > > >

Dec. 2, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolai Hess

2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > > >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> > >> @Doru > >> Youâre missing the point: #anyOne *fails* for empty collections. > > > > I am not missing the point at all. I am saying that if you want sum: to > be generic, it cannot assume a specific Zero object. > > > > And sum: should be generic because of its name. > > I am missing understanding the other use cases. Can you describe > further the generic nature of #sum & #sum: ? I would have thought by > default they only applied to numbers. > sum can be applied to anything that supports #+, not only numbers sum: can be applied to any collection with a block that return some object that supports #+ therefore you can not assume 0 (<- a number) is a proper initial value therefore you *need* to work with #anyOne and as you can not assume a proper initial value, you can not assume a default value for empty collections -> it should throw an error. If you (the caller of the function) knows what to do with an empty collection you have to check, or call inject:into: directly, with a proper initial value. > > cheers -ben > > > > >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > >>> > >>> I don't want to be heretic (or too orthodox), but why not to delegate > >>> this behavior to other class (an iterator maybe?). > >>> > >>> It's too tempting adding these convenience methods to Collection > >>> and/or subclasses, but anything that requires an explicit protocol of > >>> its elements is wrong, IMO. > >>> > >>> something like aCollection arithmetic sum: [...] or.... aCollection > >>> arithmetic avg. > >> > >> > >> Interesting thought! > > > > +100 > > > > Doru > > > >>> > >>> My two cents for this. > >>> > >>> Regards! > >>> > >>> > >>> Esteban A. Maringolo > >>> > >> > >> > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow." > > > > > > > > > > > >

Dec. 2, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by Esteban A. Maringolo

Thanks Gaston I created the Pharo Slack's bot for it, but I'm getting a connection refused error when trying to set up the SlackDigest.com integration. I'll try later. Regards! Esteban A. Maringolo 2015-12-02 11:05 GMT-03:00 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com>: > Hello. > > Just a thought ... There's a automated tool for do that (I have not tried > yet) > http://slackdigest.com/digest.html > > It send a DM to interested users, but maybe using Outgoing WebHooks the DM > can be forwarded to some service to publish it. > > > > 2015-11-30 17:47 GMT-03:00 philippe.back(a)highoctane.be > <philippe.back(a)gmail.com>: >> >> And I've not been looking at Slack that much. >> >> Digest would be we nice indeed. >> >> Phil >> >> On Nov 30, 2015 4:53 AM, "EuanM" <euanmee(a)gmail.com> wrote: >>> >>> And of course, we can stop doing it manually once threading arrives. >>> >>> On 30 November 2015 at 03:52, EuanM <euanmee(a)gmail.com> wrote: >>> > I have been talking to the Slack dev team and they assure me that >>> > threading is on its way - as a priority. >>> > >>> > I am happy to manually curate threads if someone gets a 24hour dump to >>> > log files working. >>> > >>> > The best way to do this would be to have teams of curators per >>> > channel, each doing a little curation periodically on a rota per >>> > channel basis. >>> > >>> > This is an ideal task for people still getting up to speed with Pharo >>> > internals. It is a great way to be exposed to stuff you don't >>> > understand, and put your mind around it. >>> > >>> > This provide a starter slope for future contributors. >>> > >>> > On 23 November 2015 at 08:14, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> > wrote: >>> >> The problem is, that it is not that easy to create a âdigestâ from >>> >> Slack, as there is no kind of grouping. Either you have to detect similar >>> >> words in discussion, or you have to simply export everything. I donât know >>> >> whether it makes sense to just compose a huge email of all discussions, but >>> >> we can try to do that. >>> >> >>> >> Cheers. >>> >> Uko >>> >> >>> >>> On 23 Nov 2015, at 00:21, EuanM <euanmee(a)gmail.com> wrote: >>> >>> >>> >>> I agree - if we can have each 24 hours of chat archived to somewhere >>> >>> that provides a free-text search, that would be very good. >>> >>> >>> >>> Up until now, I've been grabbing, editting and posting chats I find >>> >>> of >>> >>> interest and importance to me. And it seems to lend itself to design >>> >>> discussions. What it's not very good at, atm, is discussion >>> >>> threading. It would be great to be able to set your typing as >>> >>> belonging to a thread., so that when it get sucked out and archived >>> >>> that the threads were segregated. >>> >>> >>> >>> Does someone have a server that could receive a text dump of all >>> >>> recent Slack messages every 12 (or 24, or 6) hours, and then make it >>> >>> available for indexing by Google et al, and querying (via the search >>> >>> engines) by our dev base? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 22 November 2015 at 13:57, Dimitris Chloupis >>> >>> <kilon.alios(a)gmail.com> wrote: >>> >>>> Just to clear something up , because I see people in slack saying >>> >>>> goodbye, >>> >>>> or "I cant reply right now I have something to do" . Slack is not >>> >>>> just a >>> >>>> real time chat, it keeps messages inside a history of 10 thousand >>> >>>> messages. >>> >>>> So that means you can log in Slack at any time and not lose a >>> >>>> message. There >>> >>>> is no reason for you to be online all time, no reason to say >>> >>>> goodbye, >>> >>>> goodmorning , goodafternoon. You can come and go as you please the >>> >>>> exact >>> >>>> same way as the mailing list. >>> >>>> >>> >>>> The problem arises when we exceed 10k messages, the old ones get >>> >>>> lost and I >>> >>>> think having a place to store them is a good idea. >>> >>>> >>> >>>> Also what is important is in the eye of the beholder, for example I >>> >>>> dont >>> >>>> care about any discussion about web development , its just does not >>> >>>> interest >>> >>>> me or database coding or many other things. I have learned to filter >>> >>>> out the >>> >>>> messages I dont care about in the mailing list and just reject them. >>> >>>> Slack >>> >>>> is same story, I quickly glance through its history and I can search >>> >>>> the >>> >>>> messages that interest me using the search bar , I can star messages >>> >>>> that I >>> >>>> want to keep, and I can comment on existing messages / code snippets >>> >>>> which >>> >>>> create a thread about that message. >>> >>>> >>> >>>> In the end its impossible to keep the community in one place but to >>> >>>> have a >>> >>>> central hub that collects all the little gems can be quite useful. >>> >>>> >>> >>>> On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> wrote: >>> >>>>> >>> >>>>> Yes this would be good. >>> >>>>> People should understand that important discussions should be via >>> >>>>> the >>> >>>>> mailing-list. >>> >>>>> Emails are good because you can consume them the way you want. >>> >>>>> I simply cannot be connected all the time. So emails are good >>> >>>>> because I >>> >>>>> can process them >>> >>>>> when I decide. >>> >>>>> Slack is good for more interactive session around debugger and >>> >>>>> things >>> >>>>> like that. >>> >>>>> >>> >>>>> Stef >>> >>>>> >>> >>>>> >>> >>>>> Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : >>> >>>>>> Should we have a digest from slack to a mailing list? >>> >>>>>> We are already losing messages >>> >>>>>> >>> >>>>>> Stephan >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>> >>> >>> >>> >> >>> >> >>> >

Dec. 2, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by GastÃ³n Dall' Oglio

Hello. Just a thought ... There's a automated tool for do that (I have not tried yet) http://slackdigest.com/digest.html It send a DM to interested users, but maybe using Outgoing WebHooks the DM can be forwarded to some service to publish it. 2015-11-30 17:47 GMT-03:00 philippe.back(a)highoctane.be < philippe.back(a)gmail.com>: > And I've not been looking at Slack that much. > > Digest would be we nice indeed. > > Phil > On Nov 30, 2015 4:53 AM, "EuanM" <euanmee(a)gmail.com> wrote: > >> And of course, we can stop doing it manually once threading arrives. >> >> On 30 November 2015 at 03:52, EuanM <euanmee(a)gmail.com> wrote: >> > I have been talking to the Slack dev team and they assure me that >> > threading is on its way - as a priority. >> > >> > I am happy to manually curate threads if someone gets a 24hour dump to >> > log files working. >> > >> > The best way to do this would be to have teams of curators per >> > channel, each doing a little curation periodically on a rota per >> > channel basis. >> > >> > This is an ideal task for people still getting up to speed with Pharo >> > internals. It is a great way to be exposed to stuff you don't >> > understand, and put your mind around it. >> > >> > This provide a starter slope for future contributors. >> > >> > On 23 November 2015 at 08:14, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >> The problem is, that it is not that easy to create a âdigestâ from >> Slack, as there is no kind of grouping. Either you have to detect similar >> words in discussion, or you have to simply export everything. I donât know >> whether it makes sense to just compose a huge email of all discussions, but >> we can try to do that. >> >> >> >> Cheers. >> >> Uko >> >> >> >>> On 23 Nov 2015, at 00:21, EuanM <euanmee(a)gmail.com> wrote: >> >>> >> >>> I agree - if we can have each 24 hours of chat archived to somewhere >> >>> that provides a free-text search, that would be very good. >> >>> >> >>> Up until now, I've been grabbing, editting and posting chats I find of >> >>> interest and importance to me. And it seems to lend itself to design >> >>> discussions. What it's not very good at, atm, is discussion >> >>> threading. It would be great to be able to set your typing as >> >>> belonging to a thread., so that when it get sucked out and archived >> >>> that the threads were segregated. >> >>> >> >>> Does someone have a server that could receive a text dump of all >> >>> recent Slack messages every 12 (or 24, or 6) hours, and then make it >> >>> available for indexing by Google et al, and querying (via the search >> >>> engines) by our dev base? >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On 22 November 2015 at 13:57, Dimitris Chloupis < >> kilon.alios(a)gmail.com> wrote: >> >>>> Just to clear something up , because I see people in slack saying >> goodbye, >> >>>> or "I cant reply right now I have something to do" . Slack is not >> just a >> >>>> real time chat, it keeps messages inside a history of 10 thousand >> messages. >> >>>> So that means you can log in Slack at any time and not lose a >> message. There >> >>>> is no reason for you to be online all time, no reason to say goodbye, >> >>>> goodmorning , goodafternoon. You can come and go as you please the >> exact >> >>>> same way as the mailing list. >> >>>> >> >>>> The problem arises when we exceed 10k messages, the old ones get >> lost and I >> >>>> think having a place to store them is a good idea. >> >>>> >> >>>> Also what is important is in the eye of the beholder, for example I >> dont >> >>>> care about any discussion about web development , its just does not >> interest >> >>>> me or database coding or many other things. I have learned to filter >> out the >> >>>> messages I dont care about in the mailing list and just reject them. >> Slack >> >>>> is same story, I quickly glance through its history and I can search >> the >> >>>> messages that interest me using the search bar , I can star messages >> that I >> >>>> want to keep, and I can comment on existing messages / code snippets >> which >> >>>> create a thread about that message. >> >>>> >> >>>> In the end its impossible to keep the community in one place but to >> have a >> >>>> central hub that collects all the little gems can be quite useful. >> >>>> >> >>>> On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> wrote: >> >>>>> >> >>>>> Yes this would be good. >> >>>>> People should understand that important discussions should be via >> the >> >>>>> mailing-list. >> >>>>> Emails are good because you can consume them the way you want. >> >>>>> I simply cannot be connected all the time. So emails are good >> because I >> >>>>> can process them >> >>>>> when I decide. >> >>>>> Slack is good for more interactive session around debugger and >> things >> >>>>> like that. >> >>>>> >> >>>>> Stef >> >>>>> >> >>>>> >> >>>>> Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : >> >>>>>> Should we have a digest from slack to a mailing list? >> >>>>>> We are already losing messages >> >>>>>> >> >>>>>> Stephan >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> >> >>

Dec. 2, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ben Coman

On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > >> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >> @Doru >> Youâre missing the point: #anyOne *fails* for empty collections. > > I am not missing the point at all. I am saying that if you want sum: to be generic, it cannot assume a specific Zero object. > > And sum: should be generic because of its name. I am missing understanding the other use cases. Can you describe further the generic nature of #sum & #sum: ? I would have thought by default they only applied to numbers. cheers -ben > >>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> I don't want to be heretic (or too orthodox), but why not to delegate >>> this behavior to other class (an iterator maybe?). >>> >>> It's too tempting adding these convenience methods to Collection >>> and/or subclasses, but anything that requires an explicit protocol of >>> its elements is wrong, IMO. >>> >>> something like aCollection arithmetic sum: [...] or.... aCollection >>> arithmetic avg. >> >> >> Interesting thought! > > +100 > > Doru > >>> >>> My two cents for this. >>> >>> Regards! >>> >>> >>> Esteban A. Maringolo >>> >> >> > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > >

Dec. 2, 2015

Re: [Pharo-dev] Help needed: old issues issue tracker entries

by webwarrior

Case 16725 - Merge changes from spec github repository. 2 subcases are resolved, 2 other need decision. Nothing time-consuming - just decide if we integrate them or mark as wontfix. Case 15927 - Menu is broken when contained in a list. This is much more complicated, it's even not clear which class (TransfromMorph or MenuItemMorph) is bugged. I tried to fix it myself, but had no success. -- View this message in context: http://forum.world.st/Help-needed-old-issues-issue-tracker-entries-tp486426… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2015

[pharo-project/pharo-core] 49cb98: 50481

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 49cb988a0b150e3b14a5cd420fac37dad93f5f4c https://github.com/pharo-project/pharo-core/commit/49cb988a0b150e3b14a5cd42… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-02 (Wed, 02 Dec 2015) Changed paths: A Morphic-Base.package/SelectionMorph.class/instance/submorphs-add%2Fremove/goBehind.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/browseMessages.st R OpalCompiler-Core.package/OCBytecodeEncodingError.class/README.md R OpalCompiler-Core.package/OCBytecodeEncodingError.class/definition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50480.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50481.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50480.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50481.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Core.package/ComposableModel.class/instance/widgets/newDiff.st A Spec-Tools.package/MessageBrowser.class/instance/accessing/textModel_.st M Spec-Tools.package/VersionBrowser.class/instance/instance creation/showDiffMorphWithConverter_.st M Spec-Tools.package/VersionBrowser.class/instance/instance creation/showSourceWithConverter_.st Log Message: ----------- 50481 17165 OCBytecodeEncodingError is not used --> remove https://pharo.fogbugz.com/f/cases/17165 15508 SelectionMorph send to back https://pharo.fogbugz.com/f/cases/15508 14845 Selecting a class and pressing command B+M raises an error https://pharo.fogbugz.com/f/cases/14845 15678 Remove ComposableModel>>#instantiateModels:s senders in NewVersionBrowser https://pharo.fogbugz.com/f/cases/15678 http://files.pharo.org/image/50/50481.zip

Dec. 2, 2015