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

Re: [Pharo-dev] failing tests in Pharo 7

by Alistair Grant

Hi Ben, On 6 January 2018 at 12:09, Ben Coman <btc(a)openinworld.com> wrote: > It great having a CI system to check all our tests a passing, > but I thought I'd go old school and run them from the TestRunner GUI > and found in a fresh latest Pharo 7 there are "128 failures, 63 errors" > > This one is interesting... > ArrayTest>>test0FixtureAsSetForIdentityMultiplinessTest > | anElement res | > self elementsCopyNonIdenticalWithoutEqualElements. > anElement := self elementsCopyNonIdenticalWithoutEqualElements anyOne. > self deny: anElement copy == anElement. "<<<<FAILS" > > where anElement ==> SmallFloat64 (1.5) > so the deny fails. Which platform and image? Pharo 7.0 Build information: Pharo-7.0+alpha.build.410.sha.aa40385cd6fee69bb51d4a3afcacfb5f91eed206 (32 Bit) Ubuntu 16.04 14915 run, 14859 passes, 31 skipped, 50 expected failures, 5 failures, 1 errors, 0 unexpected passes Failures: ReleaseTest>>#testMethodsWithUnboundGlobals TonelWriterTest>>#testWriteSnapshot ReleaseTest>>#testUnpackagedClasses ReleaseTest>>#testNoEmptyPackages ReleaseTest>>#testThatAllMethodsArePackaged Errors: ZnClientTests>>#testRedirect Cheers, Alistair > It seems that the test setUp is wrong since > #elementsCopyNonIdenticalWithoutEqualElements > does not return a collection (of elements for which copy is not identical ) > without equal elements:" > > This seems like a permanent error rather than a transient one. > How does this slip through CI testing? > and what can be done about cleaning this up? > > cheers -ben > > P.S. With the loss of method version info is impossible to guess when this > may have been introduced, to guess which Issue it was related to, to guess > how I might approach fixing this myself.

Jan. 6, 2018

Re: [Pharo-dev] (Morph>>#asDraggableMorph) isPrimitive

by Eliot Miranda

Hi Denis, Hi Norbert, On Sat, Jan 6, 2018 at 6:30 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > I guess "quick" methods are compiled as special primitives. For example > accessors are primitives too: > > > (Point >> #x) isPrimitive > > > There is another method #isRealPrimitive which checks for explicit > primitive call. > That's right. The scheme is as follows: Numbered primitives used to be 9 bits fields and primitive numbers 1 through 255 were for conventional primitives, and primitive numbers 256 through 512 were for quick primitives, such that 256 through 263 pushed specific constants and 264 through 512 pushed the inst vars, 263 pushing inst var 0, 264 pushing inst var 1, etc. Here's the relevant section of the VM's primitive table: "Quick Push Const Methods" (256 nil) "primitivePushSelf" (257 nil) "primitivePushTrue" (258 nil) "primitivePushFalse" (259 nil) "primitivePushNil" (260 nil) "primitivePushMinusOne" (261 nil) "primitivePushZero" (262 nil) "primitivePushOne" (263 nil) "primitivePushTwo" "Quick Push Inst Var Methods" (264 519 nil) "primitiveLoadInstVar" Now we have 16 bits of primitive index. The scheme up to 32767 is the same; 1 through 32767 are available for conventional primitives, with 256 through 512 reserved for quick primitives. Numbers 32768 through 65535 are reserved for use "inline primitives". We divide the 32k values from 32767 on up into four 8k groups. Sista has the first 8k. Lowcode has the second 8k, and the remaining two groups of 8k are unassigned, reserved for future use. Now that SistaV1 and Spur support up to 64k inst vars one could argue that we should extend the range of numbers available to quick primitives. But in the JIT there's no difference between the code generated for a quick primitive and the code generated for a conventional pshInstVar:/pushConstant:, methodReturnTop. IQuicjk primitive serve to improve performance only in the interpreter. So given that we have no classes defining more than 210 inst vars (in my image) I don't think its a pressing need :-) > 2018-01-06 13:24 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > >> Can anyone explain why >> >> (Morph>>#asDraggableMorph) isPrimitive. >> >> returns true? >> >> Norbert >> > _,,,^..^,,,_ best, Eliot

Jan. 6, 2018

Re: [Pharo-dev] (Morph>>#asDraggableMorph) isPrimitive

by Denis Kudriashov

Hi. I guess "quick" methods are compiled as special primitives. For example accessors are primitives too: (Point >> #x) isPrimitive There is another method #isRealPrimitive which checks for explicit primitive call. 2018-01-06 13:24 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > Can anyone explain why > > (Morph>>#asDraggableMorph) isPrimitive. > > returns true? > > Norbert > >

Jan. 6, 2018

Re: [Pharo-dev] Calling primitiveFailed

by ClÃ©ment Bera

Hi Norbert, Not really. First we distinguish two cases: - essential primitives : provides features that cannot be implemented in Smalltalk (SmallInteger>>#+ for instance, requires to use the cpu addition) - optimisation primitives : optional, they just improve performance Optimisation primitives are optional and hence the fall-back code should be the Smalltalk implementation of the primitive. For essential primitives, the fall-back code is what is called when the primitive fails. If we look at SmallInteger>>#+, it can fail because one operand is not a SmallInteger, so the fall-back code use other code to perform the addition (LargeInteger, Integer code, etc.). In other cases, such as #at:put:, an error is raised when the primitive fails depending on why the primitive failed (bounds check, non integer index, etc.). The primitive is retried in case of number non integer (Try #(1) at: 1.0 put: $x). Some essential primitives should not fail in any circumstances and they can't really be simulated. Good examples is #== primitive or #basicIdentityHash, they should not fail. If it fails it means likely something is wrong in the VM or in the kernel, in which case the primitiveFail error is sent. PrimitiveFail error announces that a primitive has failed and there is no appropriate Smalltalk code to run. So no, most primitives should not call primitiveFail, you cannot assume that. On Sat, Jan 6, 2018 at 1:38 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Looking through primitive methods I can see two cases. Most methods seem > to call > > self primitiveFailed > > at the end of the method. But some as > > Object>>#at:put: > > do not. Can I assume that all primitive methods should call > primitiveFailed at the end? > > Norbert > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Jan. 6, 2018

Calling primitiveFailed

by Norbert Hartl

Looking through primitive methods I can see two cases. Most methods seem to call self primitiveFailed at the end of the method. But some as Object>>#at:put: do not. Can I assume that all primitive methods should call primitiveFailed at the end? Norbert

Jan. 6, 2018

Re: [Pharo-dev] (Morph>>#asDraggableMorph) isPrimitive

by Norbert Hartl

Forgot the details. I downloaded image and vm with wget -O- get.pharo.org/70+vm | bash one hour ago. Norbert > Am 06.01.2018 um 13:24 schrieb Norbert Hartl <norbert(a)hartl.name>: > > Can anyone explain why > > (Morph>>#asDraggableMorph) isPrimitive. > > returns true? > > Norbert

Jan. 6, 2018

(Morph>>#asDraggableMorph) isPrimitive

by Norbert Hartl

Can anyone explain why (Morph>>#asDraggableMorph) isPrimitive. returns true? Norbert

Jan. 6, 2018

Re: [Pharo-dev] failing tests in Pharo 7

by Ben Coman

On 6 January 2018 at 19:09, Ben Coman <btc(a)openinworld.com> wrote: > It great having a CI system to check all our tests a passing, > but I thought I'd go old school and run them from the TestRunner GUI > and found in a fresh latest Pharo 7 there are "128 failures, 63 errors" > So that was Pharo64bit. Pharo32bit is better with only has only "1 failures, 20 errors". So what is the CI dependency of the 32 bit and 64 bit Images? Do they both run tests independently? cheers -ben > > This one is interesting... > ArrayTest>>test0FixtureAsSetForIdentityMultiplinessTest > | anElement res | > self elementsCopyNonIdenticalWithoutEqualElements. > anElement := self elementsCopyNonIdenticalWithoutEqualElements anyOne. > self deny: anElement copy == anElement. "<<<<FAILS" > > where anElement ==> SmallFloat64 (1.5) > so the deny fails. > > It seems that the test setUp is wrong since # > elementsCopyNonIdenticalWithoutEqualElements > does not return a collection (of elements for which copy is not identical > ) without equal elements:" > > This seems like a permanent error rather than a transient one. > How does this slip through CI testing? > and what can be done about cleaning this up? > > cheers -ben > > P.S. With the loss of method version info is impossible to guess when this > may have been introduced, to guess which Issue it was related to, to guess > how I might approach fixing this myself. >

Jan. 6, 2018

Re: [Pharo-dev] New Year Wishlist (2018) ?

by Ben Coman

On 24 December 2017 at 00:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi everybody, > > This looks like a good moment of the year to ask all of you what would you > want to see in Pharo next year. > Features, improvements, radical changes, etcâ¦. whatever you want. > > Of course, this list will not be a roadmap and it does not means we will > implement all of it (as always, time drives our possibilities), but is a > good moment for us a a community to check where we are and where we wan to > go next :) > > So, letâs those wishes come! > > cheers, > Esteban > IIUC, our continuous integration system really only checks that "new" error are not introduced. This seems of limited facility to encourage dealing with existing errors. So my wish is for... 1. TestRunner GUI results to be kept fault free. 2. Periodically scheduled human-driven reality check of [1.] cheers -ben

Jan. 6, 2018

failing tests in Pharo 7

by Ben Coman

It great having a CI system to check all our tests a passing, but I thought I'd go old school and run them from the TestRunner GUI and found in a fresh latest Pharo 7 there are "128 failures, 63 errors" This one is interesting... ArrayTest>>test0FixtureAsSetForIdentityMultiplinessTest | anElement res | self elementsCopyNonIdenticalWithoutEqualElements. anElement := self elementsCopyNonIdenticalWithoutEqualElements anyOne. self deny: anElement copy == anElement. "<<<<FAILS" where anElement ==> SmallFloat64 (1.5) so the deny fails. It seems that the test setUp is wrong since #elementsCopyNonIdenticalWithoutEqualElements does not return a collection (of elements for which copy is not identical ) without equal elements:" This seems like a permanent error rather than a transient one. How does this slip through CI testing? and what can be done about cleaning this up? cheers -ben P.S. With the loss of method version info is impossible to guess when this may have been introduced, to guess which Issue it was related to, to guess how I might approach fixing this myself.

Jan. 6, 2018