- Pharo-dev - lists.pharo.org

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%3DuBE4UAM4tAVZcrA(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

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

by Denis Kudriashov

2015-12-21 19:07 GMT+01:00 Robert Withers <robert.w.withers(a)gmail.com>: > What are you and the RMOD team doing, I am curious? RMOD is research team at INRIA university. We develop Pharo.

Dec. 21, 2015

Re: [Pharo-dev] in Togo teaching Pharo with Stef

by Esteban A. Maringolo

So Stef finally convinced you to visit it. Good luck! Esteban A. Maringolo 2015-12-21 15:15 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi guys, > > just letting you know that Iâm not working until January 4th because Iâm in Togo, helping Stef to teach Pharoâ¦ so the spur problems will need to wait a bit to be solved :) > > cheers, > Esteban > >

Dec. 21, 2015

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

by stepharo

:) 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 > <mailto:stepharo@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