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

Re: [Pharo-dev] Hello, Im and a litle confused. Can you help me get started please?

by Max Leske

Hi, welcome to Pharo! This is the development list for Pharo; your question is better suited for the users list ( http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org) There's also a very active Discord community: http://discord.gg/Sj2rhxn. As for documentation, there are loads of tutorials and screencasts here: http://pharo.org/documentation. Cheers, Max On 8 January 2018 at 09:55:23, Photon (nico-braun(a)live.de) wrote: Hello, Folks. As is wrote in the title, I`m somewhat confused. I`m new to programming but I think I understood what OOP is, yessterday before I discovered Pharo, was I was able to build a simple city model in Visual Studio (C#), with a city class which was build out of other classes wich were build out of other classes. City<-District<-Street<-House<-Room. So I get the idea that we want to discribe real world systems as network of objects to be able to solve problems within givin system. However I have a super hard time to grasp Pharo for some reason. What I understood so far is that everything is an object even the classes it self, wich is super cool by the way. I understand that as I use Pharo I have to use the libaries aswell since there is no clear cut between language and package. I know the browser to a slight degree and I read allready a bit code from some objects and methods. But then when i try to call some methods from the classes there I fail 90% of the time. I did not find much learning material online. Only a couple talks on Pharo and one or two text based tutorials wich were unfortunatly pretty old, version 1.5 or something like this. So I really want to dig into this wonderfull subject as the concept seems fascinating to me. I believe it can be a powerfull tool especially with the abillity to change things runtime. I`d be glad to get a little advice on how to start. Cheers -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 8, 2018

Re: [Pharo-dev] Hello, Im and a litle confused. Can you help me get started please?

by James Foster

Hi Photon, A good place to start would be http://pharo.org/ <http://pharo.org/> and then look for the link to the Pharo Mooc. Cheers, James > On Jan 8, 2018, at 12:54 AM, Photon <nico-braun(a)live.de> wrote: > > Hello, Folks. As is wrote in the title, I`m somewhat confused. I`m new to > programming but I think I understood what OOP is, yessterday before I > discovered Pharo, was I was able to build a simple city model in Visual > Studio (C#), with a city class which was build out of other classes wich > were build out of other classes. > City<-District<-Street<-House<-Room. So I get the idea that we want to > discribe real world systems as network of objects to be able to solve > problems within givin system. > > However I have a super hard time to grasp Pharo for some reason. What I > understood so far is that everything is an object even the classes it self, > wich is super cool by the way. I understand that as I use Pharo I have to > use the libaries aswell since there is no clear cut between language and > package. > I know the browser to a slight degree and I read allready a bit code from > some objects and methods. > But then when i try to call some methods from the classes there I fail 90% > of the time. > > I did not find much learning material online. Only a couple talks on Pharo > and one or two text based tutorials wich were unfortunatly pretty old, > version 1.5 or something like this. > So I really want to dig into this wonderfull subject as the concept seems > fascinating to me. I believe it can be a powerfull tool especially with the > abillity to change things runtime. > > I`d be glad to get a little advice on how to start. > Cheers > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Jan. 8, 2018

Hello, Im and a litle confused. Can you help me get started please?

by Photon

Hello, Folks. As is wrote in the title, I`m somewhat confused. I`m new to programming but I think I understood what OOP is, yessterday before I discovered Pharo, was I was able to build a simple city model in Visual Studio (C#), with a city class which was build out of other classes wich were build out of other classes. City<-District<-Street<-House<-Room. So I get the idea that we want to discribe real world systems as network of objects to be able to solve problems within givin system. However I have a super hard time to grasp Pharo for some reason. What I understood so far is that everything is an object even the classes it self, wich is super cool by the way. I understand that as I use Pharo I have to use the libaries aswell since there is no clear cut between language and package. I know the browser to a slight degree and I read allready a bit code from some objects and methods. But then when i try to call some methods from the classes there I fail 90% of the time. I did not find much learning material online. Only a couple talks on Pharo and one or two text based tutorials wich were unfortunatly pretty old, version 1.5 or something like this. So I really want to dig into this wonderfull subject as the concept seems fascinating to me. I believe it can be a powerfull tool especially with the abillity to change things runtime. I`d be glad to get a little advice on how to start. Cheers -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 8, 2018

Re: [Pharo-dev] [Vm-dev] Alien-TorstenBergmann.41 wipes all method stamps

by Eliot Miranda

On Sun, Jan 7, 2018 at 6:05 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > Alien-TorstenBergmann.41 is in repository Alien on squeaksource, and was > intended > to be a minor update. But it clobbers all method stamps in the entire > package. > > Could whoever saved this update please check this, and maybe re-save it > with just > Torsten's intended Alien class>>newCString: fix? > And can someone please explain what was the cause of the wiped method stamps? _,,,^..^,,,_ best, Eliot

Jan. 8, 2018

Re: [Pharo-dev] 1.0 largeIdentityHash fails on 64-bit Linux

by Nicolas Cellier

Known problem https://pharo.manuscript.com/f/cases/20119/basicIdentityHash-and-only-basic… https://pharo.manuscript.com/f/cases/20649/basicIdentityHash-and-only-basic… I thought it was resolved? 2018-01-07 15:38 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > https://github.com/pharo-project/pharo/pull/653 > > > > On Sun, Jan 7, 2018 at 3:14 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > Tx I added the discussion to > > https://pharo.fogbugz.com/f/cases/20936/64bit-primitiveFailure-for-1-0- > largeIdentityHash > > > > Stef > > > > On Sun, Jan 7, 2018 at 11:18 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> That seems to fix it. SmallFloat64 needs to implement #basicIdentityHash > >> with primitive 171. Thanks Eliot. > >> > >> > >> > >> On 7 January 2018 at 06:19:18, Eliot Miranda (eliot.miranda(a)gmail.com) > >> wrote: > >> > >> Hi Ben, > >> > >> On Sat, Jan 6, 2018 at 8:47 PM, Ben Coman <btc(a)openinworld.com> wrote: > >>> > >>> With Linux 64 bit image > >>> TestRunner running FLBinaryFileStreamSerializationTest > >>> produces error "PrimitiveFailed: primitive #basicIdentityHash in > >>> SmallFloat64 failed" > >> > >> > >> I suspect the SmallFloat64 basicIdentityHash method is missing or using > the > >> wrong primitive number. Here's what happens in Squeak: > >> > >> 1.0 class -> 1.0 identityHash hex -> ((1.0 class > whichClassIncludesSelector: > >> #identityHash) >> #identityHash) primitive > >> SmallFloat64->'16r7F0000000000000'->171 > >> > >> And primitive 171 is the primitiveImmediateAsInteger primitive that > converts > >> SmallIntegers to themselves, Characters to their integer codes, and > >> SmallFloat64 to an integer representing their bits. e.g. > >> > >> #(-0.0 0.0 -1.0 1.0) collect: [:n| n -> n identityHash hex -> (n > >> identityHash bitAnd: 2 << 64 - 1) hex] > >> {-0.0->'-16r1000000000000000'->'16r1F000000000000000' . > >> 0.0->'16r0'->'16r0' . > >> -1.0->'-16r810000000000000'->'16r1F7F0000000000000' . > >> 1.0->'16r7F0000000000000'->'16r7F0000000000000'} > >> > >> SmallFloat64>>identityHash > >> "Answer an integer unique to the receiver." > >> <primitive: 171> > >> ^self primitiveFailed > >> > >> HTH > >> > >>> > >>> The same error occurs evaluating... > >>> 1.0 largeIdentityHash > >>> which works fine on 32-bit. > >>> > >>> > >>> https://pharo.fogbugz.com/f/cases/20936/64bit- > primitiveFailure-for-1-0-largeIdentityHash > >>> > >>> Build information: > >>> Pharo-7.0+alpha.build.409.sha.bb4eaaf976e3fb148b33b6d87598022b77329768 > (64 > >>> Bit) > >>> CoInterpreter VMMaker.oscog-eem.2295 Dec 21 2017 > >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2297 Dec 21 2017 > >>> VM: 201712211450 > >>> Unix built on Dec 21 2017 14:53:19 Compiler: 4.8.4 > >>> > >>> cheers -ben > >> > >> > >> > >> > >> -- > >> _,,,^..^,,,_ > >> best, Eliot > >

Jan. 7, 2018

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

by Eliot Miranda

Hi All, > On Jan 7, 2018, at 1:30 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven. > >> On 6 January 2018 at 22:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 6 Jan 2018, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> 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. Shouldn't the test distinguish objects whose class answers true for isImmediateClass? In 64-bits SmallIntegers, Characters /and/ SmallFloat64s are all immediate so will always be #== to any instance of the same value. In 32-bits there are no instances of SmallFloat64. In 64-bits any float whose exponent falls within the single precision range (which excludes Inf & NaN) will be represented as a SmallFloat64. >>> >>> 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 >> >> Hmm, strange. Does it failed each time ? >> >> It does not fail for me (macOS). Furthermore, all Zinc tests are green https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/ > > It's failing quite rarely. I think we just got (un)lucky this time. > #testRedirect connects to http://zn.stfx.eu, so it could well be an > intermittent internet connection issue. > > What would we lose by restructuring the tests to use an internal > server? My initial reaction is that an increase in test reliability > would outweigh any loss of testing. And we could create manually run > tests for anything that can't be covered by the internal server tests. > > > Cheers, > Alistair > > > > > >>> 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. 7, 2018

Re: [Pharo-dev] Tonel trouble in P7 development branch for collection tests

by Stephane Ducasse

I have the same. I could not understand why some of my selectors get this . Do you think that this is just a bug in the file? I was trying to understand how such period appeared. But indeed they were already like that in Pharo 60. I integrated your PR Stef On Sat, Jan 6, 2018 at 1:06 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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. 7, 2018

[Pharo 7.0-dev] Build #412: SUCCESS

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

There is a new Pharo build available! The status of the build #412 was: SUCCESS. Could not extract further issue information from commit message: https://github.com/pharo-project/pharo/pull/617 https://pharo.fogbugz.com/f/cases/20875/ Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 7, 2018

Re: [Pharo-dev] 1.0 largeIdentityHash fails on 64-bit Linux

by Stephane Ducasse

https://github.com/pharo-project/pharo/pull/653 On Sun, Jan 7, 2018 at 3:14 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Tx I added the discussion to > https://pharo.fogbugz.com/f/cases/20936/64bit-primitiveFailure-for-1-0-larg… > > Stef > > On Sun, Jan 7, 2018 at 11:18 AM, Max Leske <maxleske(a)gmail.com> wrote: >> That seems to fix it. SmallFloat64 needs to implement #basicIdentityHash >> with primitive 171. Thanks Eliot. >> >> >> >> On 7 January 2018 at 06:19:18, Eliot Miranda (eliot.miranda(a)gmail.com) >> wrote: >> >> Hi Ben, >> >> On Sat, Jan 6, 2018 at 8:47 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> With Linux 64 bit image >>> TestRunner running FLBinaryFileStreamSerializationTest >>> produces error "PrimitiveFailed: primitive #basicIdentityHash in >>> SmallFloat64 failed" >> >> >> I suspect the SmallFloat64 basicIdentityHash method is missing or using the >> wrong primitive number. Here's what happens in Squeak: >> >> 1.0 class -> 1.0 identityHash hex -> ((1.0 class whichClassIncludesSelector: >> #identityHash) >> #identityHash) primitive >> SmallFloat64->'16r7F0000000000000'->171 >> >> And primitive 171 is the primitiveImmediateAsInteger primitive that converts >> SmallIntegers to themselves, Characters to their integer codes, and >> SmallFloat64 to an integer representing their bits. e.g. >> >> #(-0.0 0.0 -1.0 1.0) collect: [:n| n -> n identityHash hex -> (n >> identityHash bitAnd: 2 << 64 - 1) hex] >> {-0.0->'-16r1000000000000000'->'16r1F000000000000000' . >> 0.0->'16r0'->'16r0' . >> -1.0->'-16r810000000000000'->'16r1F7F0000000000000' . >> 1.0->'16r7F0000000000000'->'16r7F0000000000000'} >> >> SmallFloat64>>identityHash >> "Answer an integer unique to the receiver." >> <primitive: 171> >> ^self primitiveFailed >> >> HTH >> >>> >>> The same error occurs evaluating... >>> 1.0 largeIdentityHash >>> which works fine on 32-bit. >>> >>> >>> https://pharo.fogbugz.com/f/cases/20936/64bit-primitiveFailure-for-1-0-larg… >>> >>> Build information: >>> Pharo-7.0+alpha.build.409.sha.bb4eaaf976e3fb148b33b6d87598022b77329768 (64 >>> Bit) >>> CoInterpreter VMMaker.oscog-eem.2295 Dec 21 2017 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2297 Dec 21 2017 >>> VM: 201712211450 >>> Unix built on Dec 21 2017 14:53:19 Compiler: 4.8.4 >>> >>> cheers -ben >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot

Jan. 7, 2018

Re: [Pharo-dev] 1.0 largeIdentityHash fails on 64-bit Linux

by Stephane Ducasse

Tx I added the discussion to https://pharo.fogbugz.com/f/cases/20936/64bit-primitiveFailure-for-1-0-larg… Stef On Sun, Jan 7, 2018 at 11:18 AM, Max Leske <maxleske(a)gmail.com> wrote: > That seems to fix it. SmallFloat64 needs to implement #basicIdentityHash > with primitive 171. Thanks Eliot. > > > > On 7 January 2018 at 06:19:18, Eliot Miranda (eliot.miranda(a)gmail.com) > wrote: > > Hi Ben, > > On Sat, Jan 6, 2018 at 8:47 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> With Linux 64 bit image >> TestRunner running FLBinaryFileStreamSerializationTest >> produces error "PrimitiveFailed: primitive #basicIdentityHash in >> SmallFloat64 failed" > > > I suspect the SmallFloat64 basicIdentityHash method is missing or using the > wrong primitive number. Here's what happens in Squeak: > > 1.0 class -> 1.0 identityHash hex -> ((1.0 class whichClassIncludesSelector: > #identityHash) >> #identityHash) primitive > SmallFloat64->'16r7F0000000000000'->171 > > And primitive 171 is the primitiveImmediateAsInteger primitive that converts > SmallIntegers to themselves, Characters to their integer codes, and > SmallFloat64 to an integer representing their bits. e.g. > > #(-0.0 0.0 -1.0 1.0) collect: [:n| n -> n identityHash hex -> (n > identityHash bitAnd: 2 << 64 - 1) hex] > {-0.0->'-16r1000000000000000'->'16r1F000000000000000' . > 0.0->'16r0'->'16r0' . > -1.0->'-16r810000000000000'->'16r1F7F0000000000000' . > 1.0->'16r7F0000000000000'->'16r7F0000000000000'} > > SmallFloat64>>identityHash > "Answer an integer unique to the receiver." > <primitive: 171> > ^self primitiveFailed > > HTH > >> >> The same error occurs evaluating... >> 1.0 largeIdentityHash >> which works fine on 32-bit. >> >> >> https://pharo.fogbugz.com/f/cases/20936/64bit-primitiveFailure-for-1-0-larg… >> >> Build information: >> Pharo-7.0+alpha.build.409.sha.bb4eaaf976e3fb148b33b6d87598022b77329768 (64 >> Bit) >> CoInterpreter VMMaker.oscog-eem.2295 Dec 21 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2297 Dec 21 2017 >> VM: 201712211450 >> Unix built on Dec 21 2017 14:53:19 Compiler: 4.8.4 >> >> cheers -ben > > > > > -- > _,,,^..^,,,_ > best, Eliot

Jan. 7, 2018