November 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Marcus Denker

> On 20 Nov 2018, at 01:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi David, > > On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis(a)mail.msen.com <mailto:lewis@mail.msen.com>> wrote: > On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > > Hi All, > > > > In VisualWorks Message implements #= & #hash naturally; two messages > > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > > comparison. This is, to say the least, annoying. Any objections to > > implementing comparing in Message to match VisualWorks? > > > > That sounds like an obviously good thing to do :-) > > Is the lookupClass instance variable relevant for comparisons? I am > guessing not, since we already have #analogousCodeTo: for that type of > comparison. > > For me it is relevant. Two messages with different lookupClasses, e.g. one with nil and one with a specific class, represent different messages, one a normal send one a super send. So my changes in waiting include lookupClass in both hash and =. I don't think it makes much difference, but the incompatibility with VisualWorks, while regrettable, feels correct to me. > To me this looks like a good change, yes. Marcus

Nov. 20, 2018

Re: [Pharo-dev] [Cuis-dev] [squeak-dev] Message>>#= & Message>>#hash

by David T. Lewis

On Mon, Nov 19, 2018 at 04:16:51PM -0800, Eliot Miranda via Cuis-dev wrote: > Hi David, > > On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis(a)mail.msen.com> wrote: > > > On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > > > Hi All, > > > > > > In VisualWorks Message implements #= & #hash naturally; two messages > > > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > > > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > > > comparison. This is, to say the least, annoying. Any objections to > > > implementing comparing in Message to match VisualWorks? > > > > > > > That sounds like an obviously good thing to do :-) > > > > Is the lookupClass instance variable relevant for comparisons? I am > > guessing not, since we already have #analogousCodeTo: for that type of > > comparison. > > > > For me it is relevant. Two messages with different lookupClasses, e.g. one > with nil and one with a specific class, represent different messages, one a > normal send one a super send. So my changes in waiting include lookupClass > in both hash and =. I don't think it makes much difference, but the > incompatibility with VisualWorks, while regrettable, feels correct to me. That feels correct to me also. But implementation details and bikeshedding aside, I would be happy if "Message allInstances asSet asArray" could answer a reasonably small collection of different-looking things. So +1 to the change, with or without consideration of lookupClass. Dave

Nov. 20, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by Eliot Miranda

Hi David, On Mon, Nov 19, 2018 at 9:52 AM David T. Lewis <lewis(a)mail.msen.com> wrote: > On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > > Hi All, > > > > In VisualWorks Message implements #= & #hash naturally; two messages > > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > > comparison. This is, to say the least, annoying. Any objections to > > implementing comparing in Message to match VisualWorks? > > > > That sounds like an obviously good thing to do :-) > > Is the lookupClass instance variable relevant for comparisons? I am > guessing not, since we already have #analogousCodeTo: for that type of > comparison. > For me it is relevant. Two messages with different lookupClasses, e.g. one with nil and one with a specific class, represent different messages, one a normal send one a super send. So my changes in waiting include lookupClass in both hash and =. I don't think it makes much difference, but the incompatibility with VisualWorks, while regrettable, feels correct to me. Dave > _,,,^..^,,,_ best, Eliot

Nov. 20, 2018

Re: [Pharo-dev] Contributor license agreement via modern transport?

by Gabriel Cotelli

On 2008 I printed the document, signed it, scanned it with the signature and then sent a signed digital copy. I think the same procedure still applies. On Mon, Nov 19, 2018 at 5:15 PM Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: > Hi, do you know whether StÃ©phane will accept contributor license agreements > as scanned and e-mailed documents (can be digitally signed using PGP as > well)? > Or does one really have to print out and mail a piece of dead tree? :-) > > Cheers, > Hans-Martin > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 19, 2018

Contributor license agreement via modern transport?

by Hans-Martin

Hi, do you know whether StÃ©phane will accept contributor license agreements as scanned and e-mailed documents (can be digitally signed using PGP as well)? Or does one really have to print out and mail a piece of dead tree? :-) Cheers, Hans-Martin -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 19, 2018

Re: [Pharo-dev] [squeak-dev] Message>>#= & Message>>#hash

by David T. Lewis

On Mon, Nov 19, 2018 at 09:32:17AM -0800, Eliot Miranda wrote: > Hi All, > > In VisualWorks Message implements #= & #hash naturally; two messages > whose selectors and arguments are #= are also equal. But in Cuis, Squeak > and Pharo Message inherits #= and #hash from Object, i.e. uses identity > comparison. This is, to say the least, annoying. Any objections to > implementing comparing in Message to match VisualWorks? > That sounds like an obviously good thing to do :-) Is the lookkupClass instance variable relevant for comparisons? I am guessing not, since we already have #analogousCodeTo: for that type of comparison. Dave

Nov. 19, 2018

Message>>#= & Message>>#hash

by Eliot Miranda

Hi All, In VisualWorks Message implements #= & #hash naturally; two messages whose selectors and arguments are #= are also equal. But in Cuis, Squeak and Pharo Message inherits #= and #hash from Object, i.e. uses identity comparison. This is, to say the least, annoying. Any objections to implementing comparing in Message to match VisualWorks? _,,,^..^,,,_ best, Eliot

Nov. 19, 2018

Re: [Pharo-dev] Pharo 7 speed compared to VW

by Eliot Miranda

Hi Shaping, On Mon, Nov 19, 2018 at 5:04 AM Shaping <shaping(a)uurda.org> wrote: > (Second try in 6 days. Does anyone have recent performance data for Pharo > 7 relative to VW 7.10 or later?) > I don't have access to recent vnc versions beyond 7.7. If you have access perhaps you could run the computer language shootout benchmarks ( https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/smalltal…) and report the results. > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Shaping > *Sent:* Tuesday, November 13, 2018 00:33 > *To:* 'Pharo Development List' <pharo-dev(a)lists.pharo.org> > *Subject:* [Pharo-dev] Pharo 7 speed compared to VW (was: The STON > Specification, Cog speed, and namespaces/modules) > > > > Does anyone know whether Pharo 7 is as fast as VW 7.10 or later? > > > > Do we have recent comparative benchmarks? > > > > The comparison should ignore potential GPU-based improvement in my algo; > that will happen later. The test should involve some math, file streaming, > and the parsing that entailsâan ordinary mix of macrobenchmarks. The > comparison should be based on both Pharo 7 and VW each running a single > Smalltalk Process (one time-slice of one OS thread in one OS process). I > need Pharo 7 speed to be comparable or better to justify the port. > > > > Pharo is definitely looking and working better. Iâve spend more time with > it last few weeks than during the previous decade. Thanks to everyone for > the effort and improvements. > > > > > > Shaping > > > > *From:* Shaping [mailto:shaping@uurda.org <shaping(a)uurda.org>] > *Sent:* Wednesday, November 7, 2018 00:41 > *To:* 'Pharo Development List' <pharo-dev(a)lists.pharo.org> > *Subject:* RE: [Pharo-dev] [ANN] The STON Specification, Cog speed, and > namespaces/modules > > > > Hi Eliot. > > > > Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to > VW's Double. In 64-bit SmallFloat64 maps exactly to SmallDouble. But I > wonder whether there is any issue here. STON would use the print strings > for (PSC) Float / (VW) Double, and so deseerialization on Pharo would > automatically produce the right class. Going in the other direction might > need some help. APF needs support in PSC before one can port, but are > representable as suitably-sized word arrays. > > > > There is no support for __float128 anywhere in the VM (e.g. not even in > the FFI) on PSC as yet. > > > > I see Pharoâs WordArray. Iâll work on an APF for Pharo, as time permits. > Iâm using APFs in VW in the 300-bit range, and want to reduce the needed > precision to 64 bits, to save space and time on large (5 million+) scalar > time-series, both on the heap and during BOSSing (25 m save-time now). > The problem is not so much an issue for the JulianDayNumber > (JDN)-precision, which is adequate in this app at 14 to 15 digits (even > though my JDN class subclasses APF, for now). Other calculations need the > more extreme precision. I think I can make 128-bit floats work, and would > really like to see a small, fast, boxed 128-bit float implementation in > Pharo or VW. The APFs are big and slow. Where in the queue of planned > improvements to Pharo does such a task lie? I suspect itâs not a very > popular item. > > > > Broadening the issue somewhat, Iâm trying to find as many good reasons as > possible to justify the work needed to port all my VW stuff to Pharo. > > > > Iâve seen the references to Cogâs speed and coming speed-up. Are there > recent (say, in the last year) benchmarks comparing VW and Pharo? Any > details here would be very much appreciated. > > > > Having no namespaces in Pharo is, I think, the biggest impediment. I > prefer not to prefix class names, but there may be fewer name-collisions > than I suppose--maybe none. Still, I need to know how VW and Pharo > classes map in order to place overrides and extensions correctly. Besides > the mentioned float-class mappings is there a reference on this? > > > > Object allSubclasses > > > > in Pharo 7 64-bit, produces 14946 classes. Pharo is a little bigger than > it used to be. > > > > I suppose I donât need to check all unloaded packages because all classes > in each of those will have the same unique prefix. Is that correct? Or, I > could just load every package I can find, before I check names. But that > little experiment has never gone well in the past. > > > > Is the Pharo-with-namespaces issue dead or merely suspended, awaiting a > more fitting idea than what VW currently offers? > > > > > > Shaping > > > > > > On Tue, Nov 6, 2018 at 12:56 AM Shaping <shaping(a)uurda.org> wrote: > > STON is able to serialise Pharoâs Floats, what do you mean by double ? > > > > Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, > with a range between =10^307 and 10^307. > > > > Additionally, I recently asked Sven if t would be possible to store > ScaledDecimals (I think it implements what you call > ArbitraryPrecisionFloats) without loss of precision. > > > > Iâm referring to VWâs Double (and SmallDouble in 64-bit engines/images). > APFs are binary representations that can be arbitrarily large, using > Integers (LargePositiveIntegers for example) to model the bits of the > mantissa. > > > > Before, because STON extends JSON, it was storing all kind of numbers > either as float or integer. > > > > Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of > precision through serialisation as float, what was done before). > > > > But I do not know if this change is integrated in recent images yet. > > > > â¦.. > > > > Number subclass: #Float > > instanceVariableNames: '' > > classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 > MaxVal MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi > RadiansPerDegree Sqrt2 ThreePi Twopi' > > poolDictionaries: '' > > category: 'Kernel-Numbers' > > > > > > My instances represent IEEE-754 floating-point double-precision numbers. > They have about 16 digits of accuracy and their range is between plus and > minus 10^307. Some valid examples are: > > > > 8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12 > > â¦. > > > > I see that Pharoâs Float is VWâs Double. So then I just need to be able > to serialize APF. > > > > â¦. > > FIFloatType subclass: #FFIFloat128 > > instanceVariableNames: '' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'UnifiedFFI-Types' > > > > > > I'm a 128bits (cuadruple precision) float. > > It is usually not used, but some compiler modes support it (__float128 in > gcc) > > > > THIS IS NOT YET SUPPORTED > > â¦. > > > > The class above is also from the Pharo 7 image. This is the largest of > the c-type FFIFloats. Any Float classes of this size and larger for the > Smalltalk heap on 64-bit Pharo? > > > > > > Cheers, > > > > Shaping > > > > > > Le 6 nov. 2018 Ã 06:58, Shaping <shaping(a)uurda.org> a Ã©crit : > > > > (Having domain problems recently. Please excuse this posting if you have > seen it twice. I've not seen it appear yet on the list.) > > > Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? > > Shaping > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] On Behalf Of > David T. Lewis > Sent: Wednesday, October 31, 2018 14:58 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] [ANN] The STON Specification > > This is very clear and well written. > > Dave > > Hi, > > Since there can never be enough documentation I finally took some time > to write a more formal description of STON as a data format. > > https://github.com/svenvc/ston/blob/master/ston-spec.md > > The idea is to let this stabilise a bit and to then update the two > other documents describing STON, where necessary: > > https://github.com/svenvc/ston/blob/master/ston-paper.md > > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc > cessfulBuild/artifact/book-result/STON/STON.html > > Also, the latest changes in STON have to make their way to the Pharo > image as well. > > https://github.com/svenvc/ston > > All feedback is welcome. > > Sven > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Nov. 19, 2018

[Pharo 7.0-dev] Build #1407: 22684-testNoUnusedTemporaryVariablesLeft-uses-all-CompiledMethod-instances

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1407 was: FAILURE. The Pull Request #2003 was integrated: "22684-testNoUnusedTemporaryVariablesLeft-uses-all-CompiledMethod-instances" Pull request url: https://github.com/pharo-project/pharo/pull/2003 Issue Url: https://pharo.fogbugz.com/f/cases/22684 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2018

[Pharo 7.0-dev] Build #1406: 22682-when-callback-fails-a-default-value-should-be-returned-to-prevent-crashes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1406 was: SUCCESS. The Pull Request #2002 was integrated: "22682-when-callback-fails-a-default-value-should-be-returned-to-prevent-crashes" Pull request url: https://github.com/pharo-project/pharo/pull/2002 Issue Url: https://pharo.fogbugz.com/f/cases/22682 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2018