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

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

by Ben Coman

On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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. This seems the crux of the disparate viewpoints, which is why I suggested return a *generic* Zero object as follows... > On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > do something like... > > Collection>>sum > | sum sample | > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > sample := self anyOne. > sum := self inject: sample into: [ :accum :each | accum + each ]. > ^ sum - sample On Sat, Dec 5, 2015 at 3:12 AM, Max Leske <maxleske(a)gmail.com> wrote: > While I think you might be on to something, I think we should take small > steps. Iâd be happy already if we can just get rid of one superfluous method > and provide a better API without starting to think about the deeper > semantics. Sure, small steps are better, except when this hits a sticking point that the bigger step may overcome. I think returning a generic zero allowing the program to proceed is better than throwing an generic error that the programmer needs to explicitly deal with. The concept of zero is well defined for the common arithmetic functions. Just for a thought experiment, what arithmetic functions would need to be dealt with. > ArithmeticZero class >> + anObject > ^anObject AritmeticZero class >> * anObject ^ anObject zero AritmeticZero class >> - anObject ^ anObject zero - anObject > Also, I think thereâs a reason why Aconcagua is an external package: > developers usually are happy to work with numbers (which are already objects > in Smalltalk anyway) and theyâre fast. Sure its an external package, but when you have a collection of weight readings for example, you want to use the internal convenient #sum method... { 4 kg . 5 kg . 6 kg } sum --> 16kg { } sum + 1 kg --> 1kg { } sum * 1 kg --> 0 kg^2 "hmmm, zero with units and multiplication starts getting more complicated - maybe should be left out of this discussion" > While #sumNumbers may *technically* be the best name (which > we canât seem to agree onâ¦), #sum, #sum: and #sum:ifEmpty: > form a triple that naturally fits into the naming protocol applied > elsewhere. So maybe alternative naming of the generic zero... #sum (empty --> EmptyAggregateZero) #sum: (empty --> EmptyAggregateZero) #sum: ifEmpty: (empty --> whatever) > On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > Doru, > > For me this whole discussion started because you (the standpoint that you > take) hijacked the best selector (#sum) for a use case that is much less > common than adding a collection of numbers which should give 0 when empty > (you hijack it by not wanting to return 0, which I totally understand, but > doing so you redefine the meaning/semantics). > > Max's point is to make everything more consistent and remove some API. I > support that too. > > Now, I like Max's proposal. > > But, you know, my conclusion when the thread ended was that it might be > better to throw all these selectors away, since #inject:into: covers most > use cases at least as well and at least as clear. #sum is very convenient and that lowers the barrier of entry for newcomers over the relatively exotic #inject:into: We should keep trying to work through the sticky points, but maybe you guys getting together IRL is better than continuing on the mail list. cheers -ben

Dec. 22, 2015

SecureSession protocol version 1.0 ( was Re: [Vm-dev] Re: SecureSession frame types)

by Robert Withers

I updated with all the feedback and here is a version 1.0 pdf specification. I appreciate any comments or suggestions you may have for this. https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0 Thank you, Robert On 12/20/2015 10:51 AM, Robert Withers wrote: > More, sorry. I left out the msgSize in the FEC spec. Let me reorder > the tagging, fit the 3 bytes of normal msgSpec into 4bytes and thusly... > > > ---Default non-FEC msgSpec + header + payload layout: > > - 8bytes (X) messageSpecification... > - > - (32bits...) > - 4bits tagging > - 6bits multicastSymbol > - 6bits messageVersion > - 2bits sanguinity > - 6bits headerType "Implies Y header size. NOTE: except for FEC > encodings" > - 8bits unused > - (32bits...) > - 4bytes messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) - > 8bytes msgSpec (X = 8)) > - > - Ybytes message header > https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0 > - > - Zbytes message payload > > > > Special FEC coded 64bit <msgSpec + header> + payload layout, for 64bit > alignment: > > - 8bytes (X) message specification... > - > - (32bits...) > - 4bits tagging > - 6bits multicastSymbol > - 6bits messageVersion > - 2bits sanguinity > - 6bits FEC message type "NOTE: this means different layout" > - 2bits rsMode > - 6bits partial blockCount > - (32bits...) > - 4bits blockCount "NOTE: for 1MB encoded/982KB data - > blockCount * blockCodeBytes = Z" > - 20bits messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) - > 8bytes msgSpec (X = 8)) "NOTE: this can specify 1MB data" > - 8bits primitivePolynomial spec (good for our current rsModes) > - > - Y = 0 > - > - Zbytes-sized payload > > Ok, that's what it is I think, this proposal. > > robert > > > > On 12/20/2015 10:33 AM, Robert Withers wrote: >> ---Default non-FEC msgSpec + header + payload layout: >> >> - 6bits multicastSymbol >> - 2bits sanguinity >> - 6bits messageVersion >> - 6bits headerType "NOTE: except for FEC encodings" >> - 4bytes messageSize >> - Xbytes header >> - >> - (messageSized - headerSize - 7specBytes) Bytes-sized payload >> >> >> Special FEC coded 64bit <msgSpec + header> + payload layout, for >> 64bit alignment: >> >> - (32bits...) >> - 6bits multicastSymbol >> - 2bits sanguinity >> - 6bits messageVersion >> - 6bits FEC message type "NOTE: this means different layout" >> - 2bits rsMode >> - (32bits...) >> - 10bits blockCount "NOTE: for 1MB encoded/982KB data" >> - 20bits messageSize "NOTE: this can specify 1MB data plus >> - 8bits primitivePolynomial spec (good for our current rsModes) >> - 4bits tagging >> - >> - (messageSized - headerSize - 4specBytes) OR (blockCount * rsMode's >> blockCodeBytes) Bytes-sized payload > -- . .. ... ^,^ robert Go Panthers!

Dec. 22, 2015

Re: [Pharo-dev] Ephemerons

by Esteban A. Maringolo

2015-12-21 19:14 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> On 21 Dec 2015, at 22:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> you will have them with Pharo 5 > and spur, of courseâ¦ but pharo 5 will have them, not previous versions :) Good news for GLORP Weak Cache implementation :) Is it already available in the current Pharo 5 image builds? Regards!

Dec. 21, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: (Max Leske)

by Richard Uttner

2015-12-21 23:48 GMT+01:00 Richard Uttner <richard.uttner(a)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(a)lists.pharo.org>: > >> Send Pharo-dev mailing list submissions to >> pharo-dev(a)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(a)lists.pharo.org >> >> You can reach the person managing the list at >> pharo-dev-owner(a)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(a)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(a)gmail.com> >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium >> Sponsored Development Effort >> Message-ID: >> <CAN88a2F3CNMTZRbdHttwmHzzsxKgs5qZUj= >> uBE4UAM4tAVZcrA(a)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(a)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 >> > >> > >>

Dec. 21, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: (Max Leske)

by Sven Van Caekenberghe

> On 21 Dec 2015, at 23:48, Richard Uttner <richard.uttner(a)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(a)lists.pharo.org>: > Send Pharo-dev mailing list submissions to > pharo-dev(a)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(a)lists.pharo.org > > You can reach the person managing the list at > pharo-dev-owner(a)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(a)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(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium > Sponsored Development Effort > Message-ID: > <CAN88a2F3CNMTZRbdHttwmHzzsxKgs5qZUj=uBE4UAM4tAVZcrA(a)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(a)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 > > > > >

Dec. 21, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: (Max Leske)

by Richard Uttner

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(a)lists.pharo.org>: > Send Pharo-dev mailing list submissions to > pharo-dev(a)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(a)lists.pharo.org > > You can reach the person managing the list at > pharo-dev-owner(a)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(a)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(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium > Sponsored Development Effort > Message-ID: > <CAN88a2F3CNMTZRbdHttwmHzzsxKgs5qZUj= > uBE4UAM4tAVZcrA(a)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(a)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 > > > > >

Dec. 21, 2015

Re: [Pharo-dev] Ephemerons

by Esteban Lorenzano

> On 21 Dec 2015, at 22:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > you will have them with Pharo 5 and spur, of courseâ¦ but pharo 5 will have them, not previous versions :) > >> On 21 Dec 2015, at 19:50, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> Hi All, Elliot ;-) >> >> Do we have Ephemerons in Pharo? Will we have them? >> >> I'm migrating from VW some code that uses it, and if we're not going >> to have them I'd like to delete the code or package it separately and >> hopefully it will work if Ephemerons are added later to Pharo. >> >> Regards! >> >> Esteban A. Maringolo >> >

Dec. 21, 2015

Re: [Pharo-dev] Ephemerons

by Esteban Lorenzano

you will have them with Pharo 5 > On 21 Dec 2015, at 19:50, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Hi All, Elliot ;-) > > Do we have Ephemerons in Pharo? Will we have them? > > I'm migrating from VW some code that uses it, and if we're not going > to have them I'd like to delete the code or package it separately and > hopefully it will work if Ephemerons are added later to Pharo. > > Regards! > > Esteban A. Maringolo >

Dec. 21, 2015

Re: [Pharo-dev] [Vm-dev] VM Maker: VMMaker.oscog-eem.1609.mcz

by Nicolas Cellier

Hmm, for micro-benchmark maybe, but this has to be measured once the JIT is ready. >From the stack VM, I can notice a slight slowdown w.r.t. 32 bits stack. But it doesn't really matter, stak is too slow compared to COG, so let's wait. 2015-12-21 21:24 GMT+01:00 stepharo <stepharo(a)free.fr>: > :) > So is it correct to think that a lot of number oriented computation will > go faster because not on large positive integers? > > Stef > > Le 20/12/15 13:39, Nicolas Cellier a Ã©crit : > > SmallInteger maxVal highBit -> 60. > 3 bits reserved for immediate tags, 1 bit for sign, 60 remaining for > positive magnitude... > > 2015-12-20 11:56 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Super !!! >> Eliot what will be >> >> 1 class maxval >> then? >> >> Stef >> >> Le 17/12/15 20:12, Eliot Miranda a Ã©crit : >> >>> Hi All, >>> >>> the real Cog 64-bit Spur x64 VM just evaluated 3+4 correctly on Mac >>> OS X: >>> >>> >> >> > >

Dec. 21, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

by Robert Withers

On 12/21/2015 03:31 PM, Denis Kudriashov wrote: > > 2015-12-21 19:07 GMT+01:00 Robert Withers <robert.w.withers(a)gmail.com > <mailto:robert.w.withers@gmail.com>>: > > What are you and the RMOD team doing, I am curious? > > > RMOD is research team at INRIA university. We develop Pharo. Yes, absolutely! I did not know it but I am glad to hear it. RMOD is the Pharo team. You all keep going for excellence, every day. robert -- . .. ... ^,^ robert Go Panthers!

Dec. 21, 2015