- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Remote debugger progress

by Ben Coman

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

Dec. 1, 2015

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

by Tudor Girba

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. >> 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. 1, 2015

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

by Chris Cunningham

Hmm. On Tue, Dec 1, 2015 at 12:17 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi guys, > > Collection defines #sum:, #detectSum: and #sumNumbers:, all of which > accomplish the same (in principal) but with subtle differences: > > #sum: > - uses #inject:into: with #anyOne as the injected element and will thus > fail for empty collections > > #detectSum: > - uses ânextValue + sumâ instead of âsum + nextValueâ which makes it a lot > slower when dealing with large numbers (primitive fails and number > conversion is necessary) > > Interesting. On my machine (which is apparently really slow right now), I get: [ 100 timesRepeat: [ (1 to: 1000000) detectSum: [:x|x] ] ] timeToRun 104874 [ 100 timesRepeat: [ (1 to: 1000000) detectSumSwitch: [:x|x] ] ] timeToRun 44369 (this second one is where I add have switched the order - sum + nextValue - for speed. So, a little over twice as fast). If I change SmallInteger to be a bit smarter, I get: [ 100 timesRepeat: [ (1 to: 1000000) detectSum: [:x|x] ] ] timeToRun 45257 In other words just marginally slower than the optimized method above. The benefit here is that future folks won't have to remember which way to do their arithmetic to make things fast. Smarter + (in SmallInteger): + aNumber "Primitive. Add the receiver to the argument and answer with the result if it is a SmallInteger. Fail if the argument or the result is not a SmallInteger Essential No Lookup. See Object documentation whatIsAPrimitive." <primitive: 1> ^aNumber class = SmallInteger ifFalse: [aNumber + self] ifTrue: [super + aNumber] Of course, this wants to be thoroughly tested before use - certain additions may now work in ways not expected before (such as adding an array to a small integer - you may get odd results). Still... > #sumNumbers: > - same as #sum but doesnât fail for empty collections. Only good for > numbers though. > > > Benchmarks: > > [ 100 timesRepeat: [ (1 to: 1000000) sum: #yourself ] ] timeToRun 18062 > [ 100 timesRepeat: [ (1 to: 1000000) detectSum: #yourself ] ] timeToRun > 42391 > [ 100 timesRepeat: [ (1 to: 1000000) sumNumbers: #yourself ] ] timeToRun > 18096 > > > <snip> -cbc

Dec. 1, 2015

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

by Ben Coman

On Tue, Dec 1, 2015 at 10:24 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Doru, > >> On 01 Dec 2015, at 15:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>>> The basic question for me is, what should >>>>> >>>>> #() sum >>>>> >>>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>>> >>>> I like the error, it aligns with most of our collection protocol. >>> >>> I hate the error, a lot ;-) >>> >>>> It shows the need for #sum:ifEmpty: though >>> >>> Yes, as long as #() sum == 0 >> >> That wonât work :). > > Why ? Please explain. > >>> I want the simplest case to be simple, having a non-0 default is a special case IMHO >> >> That is why you have sumNumbers:. We could also add Collection>>sumNumbers. >> >> We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. > > It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection. > > The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element. > > But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message. https://en.wikipedia.org/wiki/Empty_sum

Dec. 1, 2015

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

by Max Leske

@Doru Youâre missing the point: #anyOne *fails* for empty collections. > 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! > > My two cents for this. > > Regards! > > > Esteban A. Maringolo >

Dec. 1, 2015

Remote debugger progress

by Denis Kudriashov

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 <https://www.youtube.com/watch?v=zkt1JoSaq9c> Best regards, Denis

Dec. 1, 2015

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

by Esteban A. Maringolo

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. My two cents for this. Regards! Esteban A. Maringolo

Dec. 1, 2015

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

by Tudor Girba

Hi, > On Dec 1, 2015, at 3:21 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 01 Dec 2015, at 15:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >>> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>>> The basic question for me is, what should >>>>> >>>>> #() sum >>>>> >>>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>>> >>>> I like the error, it aligns with most of our collection protocol. >>> >>> I hate the error, a lot ;-) >>> >>>> It shows the need for #sum:ifEmpty: though >>> >>> Yes, as long as #() sum == 0 >> >> That wonât work :). > > But wouldnât it be nice to have #sum:ifEmpty:? I think that this is a nice way to describe summing. Otherwise I have to do ifEmpty: [ something ] ifNotEmpty: [ :col | col sum: â¦ ] Sure. That would be fine, and would leave the meaning of sum to work with non-numbers objects. But, of course, you can also use sumNumbers: which starts from 0 not from anyOne and you will need no ifEmpty:. Cheers, Doru > > Cheers. > Uko > >> >>> I want the simplest case to be simple, having a non-0 default is a special case IMHO >> >> That is why you have sumNumbers:. We could also add Collection>>sumNumbers. >> >> We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. >> >> Cheers, >> Doru >> >>> >>>> Stephan >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Speaking louder won't make the point worthier." -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

Dec. 1, 2015

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

by Sven Van Caekenberghe

Doru, > On 01 Dec 2015, at 15:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>> The basic question for me is, what should >>>> >>>> #() sum >>>> >>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>> >>> I like the error, it aligns with most of our collection protocol. >> >> I hate the error, a lot ;-) >> >>> It shows the need for #sum:ifEmpty: though >> >> Yes, as long as #() sum == 0 > > That wonât work :). Why ? Please explain. >> I want the simplest case to be simple, having a non-0 default is a special case IMHO > > That is why you have sumNumbers:. We could also add Collection>>sumNumbers. > > We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection. The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element. But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message. > Cheers, > Doru > >> >>> Stephan >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier."

Dec. 1, 2015

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

by Yuriy Tymchuk

> On 01 Dec 2015, at 15:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> On 01-12-15 11:46, Sven Van Caekenberghe wrote: >>>> The basic question for me is, what should >>>> >>>> #() sum >>>> >>>> return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it. >>> >>> I like the error, it aligns with most of our collection protocol. >> >> I hate the error, a lot ;-) >> >>> It shows the need for #sum:ifEmpty: though >> >> Yes, as long as #() sum == 0 > > That wonât work :). But wouldnât it be nice to have #sum:ifEmpty:? I think that this is a nice way to describe summing. Otherwise I have to do ifEmpty: [ something ] ifNotEmpty: [ :col | col sum: â¦ ] Cheers. Uko > >> I want the simplest case to be simple, having a non-0 default is a special case IMHO > > That is why you have sumNumbers:. We could also add Collection>>sumNumbers. > > We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers. > > Cheers, > Doru > >> >>> Stephan >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > >

Dec. 1, 2015