Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: (Max Leske)
This is my first contribution to the DevList and I hope you forgive me that it sounds more like "I see something we dont need" than the other way round, but there will be more positive posts of mine concering the Unicode debate (which I will postpone to the New Year in order to be able to respond quickly).
From a developer's point of view that is dealing with more than one environment (3 Smalltalk environments including Pharo, where I am a newby) and a handful of other languages, I dont like to reuse interfaces that are hard to remember and understand though the task done by them is so easy that I can write it down in one simple #inject:into-line 10 times faster than looking it up in the implementors browser. Furthermore, something like #inject:into: will work forever and never be deprecated! Fullstop. Next thing that is easily overlooked is the semantics. I am not that good in mathematics, but I would suppose that summing up does by definition not need a neutral element - only an implementation that can be written down in 2 lines needs it. A mathematically correct implementation of summing up anything (including nil ... see reason below) that implements #+ would be:
Collection:>>#sum | undef result | undef := result := Object new. self do: [:each | result := result == undef ifTrue: [each] ifFalse: [result + each]]. 2015-12-21 18:00 GMT+01:00 <pharo-dev-request@lists.pharo.org>:
Send Pharo-dev mailing list submissions to pharo-dev@lists.pharo.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org or, via email, send a message with subject or body 'help' to pharo-dev-request@lists.pharo.org
You can reach the person managing the list at pharo-dev-owner@lists.pharo.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Pharo-dev digest..."
Today's Topics:
1. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Dimitris Chloupis) 2. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) 3. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Mariano Martinez Peck) 4. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) 5. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Dimitris Chloupis) 6. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Thierry Goubier) 7. Re: #sum:, #detectSum:, #sumNumbers: (Tudor Girba) 8. [pharo-project/pharo-core] (GitHub) 9. [pharo-project/pharo-core] e8216b: 50508 (GitHub) 10. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Denis Kudriashov) 11. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Ben Coman) 12. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) 13. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Thierry Goubier) 14. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) 15. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Robert Withers) 16. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (phil@highoctane.be) 17. Re: [ANN] Multiple Desktop support for Pharo 5 (H. Hirzel) 18. No refactoring for equal/hash generation (Denis Kudriashov) 19. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Denis Kudriashov) 20. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Mariano Martinez Peck) 21. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Robert Withers)
----------------------------------------------------------------------
Message: 1 Date: Sun, 20 Dec 2015 17:17:42 +0000 From: Dimitris Chloupis <kilon.alios@gmail.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort Message-ID: <CAN88a2F3CNMTZRbdHttwmHzzsxKgs5qZUj= uBE4UAM4tAVZcrA@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
how the communication is happening via Fuel , does it save to a fuel file or it does it through memory some way ?
On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis@mail.msen.com> wrote:
On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote:
On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote:
Fuel I assume enters here the equation as a data exchange format , the problem I have with fuel is that its not backward compatible which for me
Fuel works well in this case. Version compatibility is not an issue, because when you fork an image/VM the two cooperating images are essentially identical.
Once you have a set of OS processes running Pharo how they talk to each other is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, JSONRPC, msgpack, coordinate via Redis/SQLite/PostgreSQL, etc.
Any of those would work, but Fuel is a good way to enable all kinds of objects to be copied from one image to another through a stream. In the case of RemoteTask, all of the results of a remote computation can be put into a single result object (an array or a dictionary or whatever), and that result can be passed back to the parent image by reading the single object. So - fork a copy of the image, have it do some work, and read the result object from a stream. You know you are done when you have read exactly one object.
Dave
On 21 Dec 2015, at 23:48, Richard Uttner <richard.uttner@gmail.com> wrote:
This is my first contribution to the DevList and I hope you forgive me that it sounds more like "I see something we dont need" than the other way round, but there will be more positive posts of mine concering the Unicode debate (which I will postpone to the New Year in order to be able to respond quickly).
Everybody's opinion count, thank you for yours.
From a developer's point of view that is dealing with more than one environment (3 Smalltalk environments including Pharo, where I am a newby) and a handful of other languages, I dont like to reuse interfaces that are hard to remember and understand though the task done by them is so easy that I can write it down in one simple #inject:into-line 10 times faster than looking it up in the implementors browser. Furthermore, something like #inject:into: will work forever and never be deprecated! Fullstops.
That is my fallback position: if we can't agree on an implementation, just throw them all out, it is very easy to write yourself. But I would not prefer it.
Next thing that is easily overlooked is the semantics. I am not that good in mathematics, but I would suppose that summing up does by definition not need a neutral element - only an implementation that can be written down in 2 lines needs it. A mathematically correct implementation of summing up anything (including nil ... see reason below) that implements #+ would be:
Collection:>>#sum | undef result | undef := result := Object new. self do: [:each | result := result == undef ifTrue: [each] ifFalse: [result + each]].
Interesting, clever, but I guess you forgot a return of result at the end ? In that case, you would return some new object for an empty collection, not 0 like I would prefer. For me the whole discussion centers around what happens with an empty collection. We know, and currently have, an implementation that can work on non-empty collection without using a neutral element to start with. That is cool. However, if you check the actual senders, more than half of them are doing silly empty checks before invoking the summing. Which to me defeats what you gain by not writing an #inject:into: on the spot.
2015-12-21 18:00 GMT+01:00 <pharo-dev-request@lists.pharo.org>: Send Pharo-dev mailing list submissions to pharo-dev@lists.pharo.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org or, via email, send a message with subject or body 'help' to pharo-dev-request@lists.pharo.org
You can reach the person managing the list at pharo-dev-owner@lists.pharo.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Pharo-dev digest..."
Today's Topics:
1. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Dimitris Chloupis) 2. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) 3. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Mariano Martinez Peck) 4. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) 5. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Dimitris Chloupis) 6. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Thierry Goubier) 7. Re: #sum:, #detectSum:, #sumNumbers: (Tudor Girba) 8. [pharo-project/pharo-core] (GitHub) 9. [pharo-project/pharo-core] e8216b: 50508 (GitHub) 10. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Denis Kudriashov) 11. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Ben Coman) 12. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) 13. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Thierry Goubier) 14. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) 15. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Robert Withers) 16. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (phil@highoctane.be) 17. Re: [ANN] Multiple Desktop support for Pharo 5 (H. Hirzel) 18. No refactoring for equal/hash generation (Denis Kudriashov) 19. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Denis Kudriashov) 20. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Mariano Martinez Peck) 21. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort (Robert Withers)
----------------------------------------------------------------------
Message: 1 Date: Sun, 20 Dec 2015 17:17:42 +0000 From: Dimitris Chloupis <kilon.alios@gmail.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort Message-ID: <CAN88a2F3CNMTZRbdHttwmHzzsxKgs5qZUj=uBE4UAM4tAVZcrA@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
how the communication is happening via Fuel , does it save to a fuel file or it does it through memory some way ?
On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis@mail.msen.com> wrote:
On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote:
On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote:
Fuel I assume enters here the equation as a data exchange format , the problem I have with fuel is that its not backward compatible which for me
Fuel works well in this case. Version compatibility is not an issue, because when you fork an image/VM the two cooperating images are essentially identical.
Once you have a set of OS processes running Pharo how they talk to each other is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, JSONRPC, msgpack, coordinate via Redis/SQLite/PostgreSQL, etc.
Any of those would work, but Fuel is a good way to enable all kinds of objects to be copied from one image to another through a stream. In the case of RemoteTask, all of the results of a remote computation can be put into a single result object (an array or a dictionary or whatever), and that result can be passed back to the parent image by reading the single object. So - fork a copy of the image, have it do some work, and read the result object from a stream. You know you are done when you have read exactly one object.
Dave
participants (2)
-
Richard Uttner -
Sven Van Caekenberghe