2015-12-21 23:48 GMT+01:00 Richard Uttner <richard.uttner@gmail.com>:
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]].
"(Sorry for the incomplete mail .... Gmail in Browser apparently has a keyboard shortcut for sending the mail if caret key is pressed along with spaces ...weird ... :() Continuing with missing return statement for above:" ^result (Why I am using "Object new" instead of nil: I would not recommend implementing #+ in nil, but not prohibit it in a general interface, if somebody needs it in an own extension. Thus relying on nil would spoil this theoretical possibility unnecessarily.) The reasons for writing it down like above are: - no sideeffects with possibile overflows (think of a collection containing one element near maxval that is added twice like in the other proposed solutions, and then subtracted finally) - no need to implement #- in special classes that are no numbers but want to use #sum - no need for a neutral element Main disadvantage of my proposed implementation is the fact that we hardly can distinguish a valid result from an invalid one if we dont use nil. What I think is the main reason for all argueing around this interface is simply: Though it sounds reasonable to define something like #sum for Collection at first sight, in fact its semantics is too blurry - we need to pass the desired result in order to reasonably handle empty collections. For most practicable application cases, this can be done instead by simply injecting 0. So please avoid so many new methods that developers have to study in order to understand their respective limit conditions (and primitives are even worse - how will coercing be done if the result gets large? Will it fail on Fraction elements? ...?) So my personal summary is: No implementation of #sum - variants in Collection due to vague semantics and no real advantage against directly using #inject:into. Best regards, Richard
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