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

Re: [Pharo-dev] evolutions of squeakelib & crypto (Reed Solomon)

by Robert Withers

Pharo Pholks, Is the spirit of #GivingTuesday, I am publishing my secure session code in progress. Some changes to pharo's internals will allow this there, though I am currently doing my work in Squeak. Cheers, Robert -------- Forwarded Message -------- Subject: Re: evolutions of squeakelib & crypto (Reed Solomon) Date: Tue, 1 Dec 2015 11:44:03 -0500 From: Robert Withers <robert.w.withers(a)gmail.com> To: squeak-dev(a)lists.squeakfoundation.org, Discussion of E and other capability languages <e-lang(a)mail.eros-os.org> Here is a newer version (201) with a protocol change to remove all tcpIds from the rendezvous. https://www.dropbox.com/s/7mgfglwu3e4bf4j/SqueakElib-rww.201.mcz?dl=0 - Robert On 12/01/2015 07:37 AM, Robert Withers wrote: > This version of the Cryptography package has beginnings of ReedSolomon > encoding. > > The rendezvous is separated into an OperationProtocol and a > StartupProtocol and the message pipeline of the session layer of > SqueakElib has been completely rewritten and LayeredProtocols have > been folded in. Please look at ElibVatTPDataTestCase for an example. > > Cryptography: > https://www.dropbox.com/s/z9dux2goimej79e/Cryptography-rww.40.mcz?dl=0 > SqueakElib: > https://www.dropbox.com/s/5yvkl3df89uyjnh/SqueakElib-rww.200.mcz?dl=0 > > In the spirit of #GivingTuesday, > Robert

Dec. 1, 2015

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

by Tudor Girba

Hi, > On Dec 1, 2015, at 3: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. Exactly. > 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. You said it correctly: âmostâ :). That is why, a generic meaning should be left generic and provide a solution that will work with âallâ cases :). Itâs a matter of choice, but sum: has a too generic meaning to have it confined to numbers. Cheers, Doru >> Cheers, >> Doru >> >>> >>>> Stephan >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Speaking louder won't make the point worthier." > > -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

Dec. 1, 2015

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

by J.F. Rick

Lovely little discussion which would be great for beginning OO programmers to see. The question of whether to return 0 for an empty collection is interesting. While other things can be summed, we tend to think of sums returning numbers. In that sense, 0 is a great default return. On the other hand, having a specific object for a generic sum function is problematic (+1). There is a real tension and that would be a great discussion for people to have. Either way, the need for sumIfEmpty: is obvious. Cheers, Jeff On Tue, Dec 1, 2015 at 11:19 AM Ben Coman <btc(a)openinworld.com> wrote: > 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] 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