June 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo6 64 bit linux Iceberg / git status?

by Alistair Grant

On Fri, Jun 09, 2017 at 03:25:36PM +0200, Esteban Lorenzano wrote: > Hi, > > Iceberg is not working on 64bits. I didn???t have the time to make > the migration, it will be ready and backported in a couple of weeks. > Esteban > No problem, thanks for your update. Cheers, Alistair > > On 9 Jun 2017, at 10:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi All, > > > > What's the current status of Iceberg / git on Pharo6 64 bit on linux > > (Ubuntu)? > > > > I'm getting LGit_GIT_ERROR: Invalid version 0 on git_remote_callbacks > > when trying to load a package with Iceberg. > > > > ...

June 9, 2017

Re: [Pharo-dev] CPU and RAM usage of Pharo3 vs. Pharo6

by Holger Freyther

> On 9. Jun 2017, at 19:11, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > Hi! > There is a server mode option somewhere that could reduce some usage. related to Morphic polling? Right now the images still install RFB to help poking it at runtime (I should use the remote debugging for sure) so disabling morphic completely might not be an option yet? holger

June 9, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by K K Subbu

On Friday 09 June 2017 06:38 PM, Guillermo Polito wrote: > On Fri, Jun 9, 2017 at 2:51 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com > When I asked it 2 years ago people were like: "oh, but you can just > download 1 sources file and use it by all the images". I donât care > about that micro space savings, but fine, I said: have it your way. > Now as we have to download sources all the time, why cannot we just > have it IN the image? > > We can, but that's something that requires changing lot's of things > inside the image and it requires probably lot of testing. What if the sources is appended to the image file with a special header. New code can relocate this pointer on the fly. The same technique can be applied to changes file too. A small script can split files for older code or combine them for new code. The resulting image file will be backward compatible. New code can preserve these files across saves. Just a thought .. Subbu

June 9, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Yuriy Tymchuk

Aha, good to know! > On 9 Jun 2017, at 14:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > We plan to change the sources management. But not immediately. > > -- Pavel > > 2017-06-09 14:51 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Why cannot we have the sources in the image? > > When I asked it 2 years ago people were like: "oh, but you can just download 1 sources file and use it by all the images". I donât care about that micro space savings, but fine, I said: have it your way. Now as we have to download sources all the time, why cannot we just have it IN the image? > > Uko > > >> On 9 Jun 2017, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> Hi, >> >> because during the image bootstrapping all source code is reloaded, it is all placed in the changes file and the sources file is useless. It would be strange to deliver Pharo with empty sources file and big changes so we decided to do sources compacting for every build. >> >> So Pharo 7 development versions will be delivered in an archive with three files named like: >> >> Pharo7.0-117934d.image >> Pharo7.0-117934d.changes >> Pharo7.0-117934d.sources >> >> where "117934d" is an abbreviated hash of the Git commit from which the Pharo image was bootstrapped. The sources file will be build-specific and of course you will be able to share it between images based on the same build. In changes file you will have only you own changes. >> >> You can test it here: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/lastSuccessfulBui… <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/lastSuccessfulBui…> >> >> Cheers, >> -- Pavel >> > >

June 9, 2017

Re: [Pharo-dev] Pharo6 64 bit linux Iceberg / git status?

by Esteban Lorenzano

Hi, Iceberg is not working on 64bits. I didnât have the time to make the migration, it will be ready and backported in a couple of weeks. Esteban > On 9 Jun 2017, at 10:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi All, > > What's the current status of Iceberg / git on Pharo6 64 bit on linux > (Ubuntu)? > > I'm getting LGit_GIT_ERROR: Invalid version 0 on git_remote_callbacks > when trying to load a package with Iceberg. > > OS: Ubuntu 16.04 > > Pharo 6.0 > Latest update: #60499 > > 5.0-201705310241 Wed May 31 04:44:35 UTC 2017 gcc 4.6.3 [Production Spur 64-bit ITHB VM] > CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2227 uuid: 7ea146b4-39ce-4de7-afa3-a76ed1d1da35 May 31 2017 > VM: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 30 19:41:27 2017 -0700 $ > Plugins: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Linux testing-gce-cd72b24e-f457-4c38-a83f-9f6cdf1fd02c 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > plugin path: /dev/shm/p64/pharo6.0-64/bin [default: /dev/shm/p64/pharo6.0-64/bin/lib/pharo/5.0-201705310241/] > > > > LGitReturnCodeEnum>>handleLGitReturnCode > LGitRepository(LGitExternalObject)>>withReturnHandlerDo: > LGitRepository>>clone:options:to: > LGitRepository>>clone:options: > [ | repo cloneOptions | > repo := LGitRepository on: self location. > cloneOptions := LGitCloneOptions > withCredentialsProvider: IceCredentialsProvider default. > repo clone: url options: cloneOptions. > aBranchName ifNotNil: [ repo checkout: aBranchName ]. > (LGitRemote of: repo named: 'origin') > lookup; > setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > [ self checkInitialized. > aBlock value ] in LGitGlobal class>>runSequence: > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: > BlockClosure>>ensure: > LGitActionSequence(DynamicVariable)>>value:during: > LGitActionSequence class(DynamicVariable class)>>value:during: > LGitGlobal class>>runSequence: > IceLibgitLocalRepository>>cloneRepositoryFrom:branch: > IceRepositoryCreator>>createRepository > [ :error | > iceRepository := IceRepositoryCreator new > remote: (IceRemote url: 'file:///home/alistair/pharo6/gitreps/knowling.git'); > subdirectory: 'repository'; > createRepository. > packages := iceRepository backend lookupPackages. > iceRepository register ] in UndefinedObject>>DoIt > BlockClosure>>cull: > Context>>evaluateSignal: > Context>>handleSignal: > IceLocalRepositoryMissing(Exception)>>signal > IceLocalRepositoryMissing class>>signalFor: > IceLibgitLocalRepository>>codeDirectory > IceLibgitLocalRepository>>packageEntries > IceLibgitLocalRepository>>lookupPackages > [ localRepository := IceLibgitLocalRepository > newRepositoryAt: imageDir / 'pharo-local/iceberg/local/knowling.git' > subdirectory: 'repository'. > iceRepository := IceRepository backend: localRepository. > packages := iceRepository backend lookupPackages. > iceRepository register ] in UndefinedObject>>DoIt > BlockClosure>>on:do: > UndefinedObject>>DoIt > OpalCompiler>>evaluate > DoItChunk>>importFor: > [ :declaration | > requestor ifNotNil: [ requestor contents: declaration contents ]. > value := declaration importFor: requestor ] in CodeImporter>>evaluateDeclarations > OrderedCollection>>do: > CodeImporter>>evaluateDeclarations > CodeImporter class>>evaluateFileStream: > MultiByteFileStream(FileStream)>>fileIn > FileStream class>>fileIn: > SimpleServiceEntry>>performServiceFor: > PluggableButtonMorph>>performAction: > [ :m | > (m containsPoint: evt cursorPoint) > ifTrue: [ m enabled > ifTrue: [ m performAction: evt ] ] ] in PluggableButtonMorph>>mouseUp: > Array(SequenceableCollection)>>do: > PluggableButtonMorph>>mouseUp: > PluggableButtonMorph(Morph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > PluggableButtonMorph(Morph)>>handleEvent: > PluggableButtonMorph(Morph)>>handleFocusEvent: > [ ActiveHand := self. > ActiveEvent := anEvent. > result := focusHolder > handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: > BlockClosure>>on:do: > WorldMorph(PasteUpMorph)>>becomeActiveDuring: > HandMorph>>sendFocusEvent:to:clear: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendMouseEvent: > HandMorph>>handleEvent: > HandMorph>>processEventsFromQueue: > HandMorph>>processEvents > [ :h | > self activeHand: h. > h processEvents. > self activeHand: nil ] in WorldState>>doOneCycleNowFor: > Array(SequenceableCollection)>>do: > WorldState>>handsDo: > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > [ [ WorldMorph doOneCycle. > Processor yield. > false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess > > > > Thanks, > Alistair >

June 9, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Guillermo Polito

On Fri, Jun 9, 2017 at 2:51 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Why cannot we have the sources in the image? > > When I asked it 2 years ago people were like: "oh, but you can just > download 1 sources file and use it by all the images". I donât care about > that micro space savings, but fine, I said: have it your way. Now as we > have to download sources all the time, why cannot we just have it IN the > image? > We can, but that's something that requires changing lot's of things inside the image and it requires probably lot of testing. So I'm not against it, but we cannot just make a change like this as we are right now facing lots of key changes at the same time: - migration to git, iceberg - bootstrap based process > > Uko > > > On 9 Jun 2017, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > because during the image bootstrapping all source code is reloaded, it is > all placed in the changes file and the sources file is useless. It would be > strange to deliver Pharo with empty sources file and big changes so we > decided to do sources compacting for every build. > > So Pharo 7 development versions will be delivered in an archive with three > files named like: > > Pharo7.0-117934d.image > Pharo7.0-117934d.changes > Pharo7.0-117934d.sources > > where "117934d" is an abbreviated hash of the Git commit from which the > Pharo image was bootstrapped. The sources file will be build-specific and > of course you will be able to share it between images based on the same > build. In changes file you will have only you own changes. > > You can test it here: https://ci.inria.fr/pharo/view/7.0/job/70- > Bootstrap-32bit/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0- > 117934d.zip > > Cheers, > -- Pavel > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 9, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Pavel Krivanek

We plan to change the sources management. But not immediately. -- Pavel 2017-06-09 14:51 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Why cannot we have the sources in the image? > > When I asked it 2 years ago people were like: "oh, but you can just > download 1 sources file and use it by all the images". I donât care about > that micro space savings, but fine, I said: have it your way. Now as we > have to download sources all the time, why cannot we just have it IN the > image? > > Uko > > > On 9 Jun 2017, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > because during the image bootstrapping all source code is reloaded, it is > all placed in the changes file and the sources file is useless. It would be > strange to deliver Pharo with empty sources file and big changes so we > decided to do sources compacting for every build. > > So Pharo 7 development versions will be delivered in an archive with three > files named like: > > Pharo7.0-117934d.image > Pharo7.0-117934d.changes > Pharo7.0-117934d.sources > > where "117934d" is an abbreviated hash of the Git commit from which the > Pharo image was bootstrapped. The sources file will be build-specific and > of course you will be able to share it between images based on the same > build. In changes file you will have only you own changes. > > You can test it here: https://ci.inria.fr/pharo/view/7.0/job/70- > Bootstrap-32bit/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0- > 117934d.zip > > Cheers, > -- Pavel > > >

June 9, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Yuriy Tymchuk

Why cannot we have the sources in the image? When I asked it 2 years ago people were like: "oh, but you can just download 1 sources file and use it by all the images". I donât care about that micro space savings, but fine, I said: have it your way. Now as we have to download sources all the time, why cannot we just have it IN the image? Uko > On 9 Jun 2017, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > because during the image bootstrapping all source code is reloaded, it is all placed in the changes file and the sources file is useless. It would be strange to deliver Pharo with empty sources file and big changes so we decided to do sources compacting for every build. > > So Pharo 7 development versions will be delivered in an archive with three files named like: > > Pharo7.0-117934d.image > Pharo7.0-117934d.changes > Pharo7.0-117934d.sources > > where "117934d" is an abbreviated hash of the Git commit from which the Pharo image was bootstrapped. The sources file will be build-specific and of course you will be able to share it between images based on the same build. In changes file you will have only you own changes. > > You can test it here: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/lastSuccessfulBui… <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/lastSuccessfulBui…> > > Cheers, > -- Pavel >

June 9, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Ben Coman

On Fri, Jun 9, 2017 at 4:01 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > because during the image bootstrapping all source code is reloaded, it is > all placed in the changes file and the sources file is useless. It would be > strange to deliver Pharo with empty sources file and big changes so we > decided to do sources compacting for every build. > > So Pharo 7 development versions will be delivered in an archive with three > files named like: > > Pharo7.0-117934d.image > Pharo7.0-117934d.changes > Pharo7.0-117934d.sources > > where "117934d" is an abbreviated hash of the Git commit from which the > Pharo image was bootstrapped. The sources file will be build-specific and > of course you will be able to share it between images based on the same > build. In changes file you will have only you own changes. > > > So what we need is for CompiledMethod>>#sourceCode to be based on git-hashes and directly access git, with one git repository shared by multiple Images. Debugging into... (Object>>#printString) sourceCode I see the trailer has "kind == #SourcePointer" and in #getSourceFromFile method #decodeSourcePointer does some interesting magic to calculate its "data" that later is returned by #sourcePointer in "SourceFiles sourceCodeAt: self sourcePointer" where SourceFiles is ...PharoV60.sources and ...PharoV60.changes. So I guess we'd need something like "kind == #ContentHash" and then in CompiledMethod>>sourceCode ahead of getSourceFromFile we add ... [ self getSourceFromUserLocalGit: contentHash ] ifNotNil: [:s | ^s]. [ self getSourceFromUserGitServer: contentHash ] ifNotNil: [:s | ^s]. [ self getSourceFromPharoGitServer: contentHash ] ifNotNil: [:s | ^s]. [ self getSourceFromPrivateEncryptedRepository: contentHash ] ifNotNil: [:s | ^s]. [ self getSourceFromIPFS: contentHash ] ifNotNil: [:s | ^s]. and such like. Perhaps some would need separate "kind"s, and this is oversimplistic since I haven't considered saving sources, but you get the idea. cheers -ben

June 9, 2017

Re: [Pharo-dev] CPU and RAM usage of Pharo3 vs. Pharo6

by philippe.back＠highoctane.be

There is a server mode option somewhere that could reduce some usage. Maybe it will help. Phil Le 9 juin 2017 13:07, "Holger Freyther" <holger(a)freyther.de> a Ã©crit : > Hey! > > my current major deployment is still with Pharo3 and due some bigger > changes I start to migrate to Pharo6 and today I finally managed to update > the test deployment (and be happy with it). The test is not scientific but > maybe an early indicator that there is something to look at? > > The image is idle and not handling any application payload so it might be > a fair comparison because of that. > > RSS + ~16 MiB RAM (~53 Mib vs. ~69 Mib) > CPU + ~0.005s per real second passed (think of Amazon AWS why that could > matter) > (In ~1400s wall clock 57.8s vs. 50.86s cpu time was used) > > Does anyone else see this increased usage? Has anyone explored the source > of it? Does anyone of you share the concern I have? :) > > holger > > > > Outline of the setup: > > * Take a Pharo3 or Pharo6 base image > * Load my code (and its dependencies, big difference is version of Voyage) > * Start the images on the test system > * Opens a TCP connection, initialize VoyageMongo > * Wait for work > > Look at top for RSS and CPU time used. >

June 9, 2017