- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Iceberg merged pull requests?

by Bernhard Pieber

Hi Esteban, Thanks for your answer. See more questions below. > Am 04.01.2018 um 09:16 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > >> On 3 Jan 2018, at 23:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> You should double click on the pharo lines and looks in the update >> pane you will see the updates (but you should pull from pharo to sync >> your repo). >> >> Stef >> >> On Tue, Jan 2, 2018 at 10:45 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> I saw that two pull requests were accepted and merged into the development branch. I had expected that Iceberg would show me them somewhere. However, in the branches pane of my repository the status pharo-project/development is shown as Up to date. >>> >>> Shouldn't there be some indication that new code is available to be merged, or am I misunderstanding Iceberg? > > you are misunderstanding iceberg :) That's what I suspected. ;-) > your repository shows the status of the image against your local copy of the repository, not the remote one. > If you want to see those changes, you need to first âfetchâ the remote repository (which will update the commits available in the local one). > this is a task (fetching) that other tools do in background time to time (for example, sourcetree does it like when you focus on the window), to show this as a âlive experienceâ, but we cannot do the same because a call to fetch would block the image (since FFI is blocking for the moment), then you will need to do that by hand until we get threaded FFI. Is this fetching from the upstream pharo-project repository something I should be able to do in Iceberg? I had assumed it is, but I could not find it? In SourceTree there is a command called Refresh Remote Status. Is there something akin to that in Iceberg? > also, notice that updating Pharo from iceberg is a very bad idea, and you can have an unusable image after that (update other projects will usually work). I am afraid I still don't understand. I thought that was the point of Iceberg? If not, what is the suggested workflow for merged pull requests to the pharo-project upstream? Should I build a new development image whenever new pull requests are merged? Bernhard

Jan. 6, 2018

Tonel trouble in P7 development branch for collection tests

by Torsten Bergmann

Hi, when contributing to Pharo 7 sometimes you might have noticed that during commit Iceberg will show you TDictionaryIncludesWithIdentityCheckTest>>nonEmptyWithCopyNonIdentical. TDictionaryTest>>nonEmptyWithCopyNonIdentical. as a deleted method. Maybe I was the only one seeing the effect so far - but I wondered and checked. Reason is that in the #development branch the src/Collections-Tests/TDictionaryIncludesWithIdentityCheckTest.trait.st src/Collections-Tests/DictionaryTest.class.st files are broken for Tonel format for the method #nonEmptyWithCopyNonIdentical as there was an additional "dot" after the selector. Here is the diff: https://github.com/pharo-project/pharo/pull/651/files I opened case 20932 for that topic and fixed it with the PR 651. Hope this will solve the issue once merged. Also I have not checked where this originally came from to find the root cause of the trouble. Bye T.

Jan. 6, 2018

Re: [Pharo-dev] extract method refactoring with assignment

by John Brant

> On Jan 5, 2018, at 11:10 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > I tried an extract to method refactoring yesterday that failed. The method looked like > > | ... v1 v2 v3 | > .... > v1 := self m1. > v2 := self m2. > v3 := v3 collect: [:e| ...]. > .... > > such that v1 and v2 were only used in the block, and the block was complex enough and did something useful e Pugh that I wanted to refactor as > > > | ... v1 v2 v3 | > .... > v3 := self complexCollect: v3. > .... > > complexCollect: a > | v1 v2 | > v1 := self m1. > v2 := self m2. > ^a collect: [:e| ...] > > So I was forced by the fact that assignment is written with the variable on the LHS to include "v3 := " in the selection to extract to method, even though my intent was for it not to be included. And of course the refactoring attempt fails precisely because the assignment /is/ included :-) > > Shouldn't this case be specially handled do that and trailing assignment is left behind in the refactored original method? Ifso, how would one go about it? > > Note that part of the prerequisite checks should also check that the variables v1 & v2 are not used elsewhere in the origins nail method and whether the refactoring is smart enough to remove them from the refactored origins nap is optional but definitely preferred. > When you extract multiple statements and the last one is an assignment, it should ask if you want to extract the assignment also. Depending on what you select the analysis is a bit different. For example, consider this method: foo | a b | a := self printString. âStatement 1" b := 1. âStatement 2" a := a âStatement 3" inject: 0 into: [ :s :e | b := b + 1. s + b + e asInteger ]. ^ a âStatement 4" If you select statements 2 & 3 and do an extract, it should ask if you want to extract the assignment. If you donât, then you get something like what you wanted above: foo | a | a := self printString. a := self bar: a. ^ a bar: a | b | b := 1. ^ a inject: 0 into: [ :s :e | b := b + 1. s + b + e asInteger ] If you do extract the assignment, it isn't allowed since we are splitting the âaâ variable (one in #foo and one in #bar). With a little bit of analysis we might be able to determine that the âaâ in #foo isnât live when we are running #bar, but if âaâ was used in a block, then things get really tough for that type of analysis. If you do this in VW, you get an error message dialog saying what the problem is. However, if you run in Pharo, you get a notice that gets displayed rather quickly and the refactoring proceeds like everything is fine even though it is producing code that will not run. If you extract statements 1-3 without the assignment, it sees that you are assigning âaâ inside the extracted method and using it in the unextracted code, and also you are needing to return the result of the #inject:into:. Since it appears that we need to return two items, it throws an error. In VW, this error causes a dialog to appear with what is wrong, and the refactoring aborts. In Pharo, the information quickly appears and the refactoring continues (which throws an unexpected error that we are trying to add another return statement after an existing return statement). In this case we could do some analysis to see that we donât need to return the âaâ variable since it is immediately assigned. Finally, if you extract statements 1-3 with the assignment, you should get: foo | a | a := self bar. ^ a bar | a b | a := self printString. b := 1. a := a inject: 0 into: [ :s :e | b := b + 1. s + b + e asInteger ]. ^ a In this case, you didnât need to return the value of #inject:into: so it could return the âaâ variable as the single return value from the extracted method. Anyway, Pharo should be fixed to not resume errors that the refactorings are throwing. There is a difference between error and warning. John Brant

Jan. 5, 2018