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

CPU and RAM usage of Pharo3 vs. Pharo6

by Holger Freyther

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

Pharo6 64 bit linux Iceberg / git status?

by Alistair Grant

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

Pharo 7 and changes/sources files

by Pavel Krivanek

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… Cheers, -- Pavel

June 9, 2017

Fwd: PharoCloud drops VM hosting and focuses on Ephemeric Cloud

by Marcus Denker

> Begin forwarded message: > From: mikefilonov <mikefilonov(a)gmail.com> Subject: [Pharo-users] PharoCloud drops VM hosting and focuses on Ephemeric Cloud Date: 9 June 2017 at 00:59:33 GMT+2 To: pharo-users(a)lists.pharo.org Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Hello, I just wanted to make some clarifications on what is going on with PharoCloud and how I see the future of the project. PharoCloud is not closing, but just dropping VM hosting support. We will continue to develop and maintain Ephemeric Cloud which allows you to publish Pharo web applications online much easier than any other VM hosting can offer. In some way PharoCloud just becomes more "cloudy" by dropping outdated technologies off :) Our plan is to make the project more community oriented. We integrated PharoCloud with Pharo.org SSO and provide *FREE* access to all *Pharo Association* members. You are welcome to log in to the cloud with your Pharo Association account at: https://www.pharocloud.com/manager/connect We are encouraging you to migrate your applications hosted as Pharocloud VMs to the Ephemeric Cloud. It is much more simple! We have some positive experience already. There are some examples I moved from VM hosting to Ephemeric Cloud: http://pharo.pharocloud.com http://seaside31.swarm.pharocloud.com/ http://eph-b147b6e2.swarm.pharocloud.com/ http://smalltalk.mikefilonov.ru/ Here you can find a quick start guide to Ephemeric cloud and some tips on how to publish your app: http://docs.swarm.pharocloud.com/article/getting_started Also there is a REST API you can use to manage the cloud. And there is also a Pharo wrapper around the REST-API: http://docs.swarm.pharocloud.com/article/pharo_library_reference We also have video guides: quickstart (sorry for old UI of the manager) https://www.youtube.com/watch?v=a1GfuT9M4qo curl example: https://www.youtube.com/watch?v=9dKBCpj96cU In case of any questions or issues with images, please feel free to contact me. -- View this message in context: http://forum.world.st/PharoCloud-drops-VM-hosting-and-focuses-on-Ephemeric-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 9, 2017

Re: [Pharo-dev] remote development via VS Code

by K K Subbu

On Thursday 08 June 2017 09:15 PM, Eliot Miranda wrote: > There are many things one could use this for, but one clear > direction, from the success of docker, is to make a Smalltalk image > observable and configurable by devops people without having to start > up an image and navigate an unfamiliar and foreign UI & IDE. Such a > direction is probably not well served by a naÃ¯ve mapping of classes > and methods to directories and files (what about global variables, > what about doits, what about Instantiation?) but the potential is > there. FUSE is really useful for passive stores like zip, iso or tgz but not for suspended live object graph like an image. The toughest part here is not the mounting and name resolution but the semantic mapping between nodes and live objects. I have a different suggestion that I feel is more 'Smalltalkish'. It would be easier for us to build an object server thread into the VM to serve live objects in the image as a file hierarchy. It allows a finer control of object graph to filetree mapping. This encapsulates object implementation details in a single place (object manager) and respects platform-neutrality. There is already a precedence in sysfs of Linux. It shows a live tree of device and drivers object graph - subsystems, buses, devices, their drivers and events. The code is under 1500 lines [1] because it leverages ramfs for name resolution and just has the semantic functions for just four concepts - directory, file, group and mount. It uses special filenames like 'uevents' to pass events between userspace and kernel (equivalent to user processes and vm plugins in our case). The VM needs to have: a) a network responder (to listen and translate requests to paths (ordered collection of nodes), b) a name resolver to resolve paths to a name and name to a special object c) a semantic getter/setter to interpret these special objects. So you could have: /globals/<name>/value /classes -> /globals/classes/ /classes/Morph/instances/oop1/value, sizeInMemory etc. /objects -> /classes/Object/instances/ /Undefined/doIt /Undefined/printIt Instances don't comes with names one but they do have a unique id (oop) which can be mapped to a file (say oop%d). Indexed variables can be managed as 'group'. [1] http://elixir.free-electrons.com/linux/latest/source/fs/sysfs Regards .. Subbu

June 9, 2017

Re: [Pharo-dev] remote development via VS Code

by Luke Gorrie

On 8 June 2017 at 15:07, Ben Coman <btc(a)openinworld.com> wrote: > On Thu, Jun 8, 2017 at 6:15 PM, Luke Gorrie <luke(a)snabb.co> wrote: > >> Currently I am working towards teaching the Inspector to explore internal >> data structures in a tracing JIT. >> > > I presume this is for LuaJIT that Snabbu uses? > Short answer is yes. Long answer is that it is for RaptorJIT, which is the fork of LuaJIT where I am moving from diagnostics by introspection (Lua code running inside the VM) to by inspection (external Pharo/Nix tools that deeply understand the VM.) Ongoing hacking here: https://github.com/raptorjit/raptorjit/pull/63 Once it works the question will be whether to migrate Snabb to RaptorJIT or port the functionality back to LuaJIT. That will be impressive. It would be nice if the DWARF stuff can be > separated. I'm sure that could be useful sometime elsewhere. > I am finding it an interesting experience to write an application that is half Pharo (frontend) and half Nix (backend). For each piece of functionality the question is, how much should be done in the frontend vs the backend? For visualizing the JIT I could on the one hand do everything in the frontend with Pharo code to parse DWARF files, etc, or on the other hand I could do everything in the backend with Pharo simply displaying PNG files produced by Nix. Current trade-off is that Nix will produce a JSON summary of the DWARF type information and then Pharo will use that to decode the logged binary data structures via the GT Inspector. and when I say "Nix" I really mean the whole Nix ecosystem that includes basically every program and programming language. So I am able to freely mix shell, awk, perl, python, R, etc, and still keep things under control. That's the hypothesis anyway. Here is a PR showing the current Frankenstein DWARF backend if you're curious: https://github.com/studio/studio/pull/14

June 9, 2017

Re: [Pharo-dev] remote development via VS Code

by Luke Gorrie

Hi Eliot, On 8 June 2017 at 17:30, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > There is nothing inscrutable about the Cog JIT in the standard Pharo and > Squeak VMs. > Sounds lovely. I am working with LuaJIT. I have half a dozen significant technical problems to solve before I am anywhere close to helping mere mortals to understand the tracing JIT and use it effectively. My interest in Pharo is to build development tools for my application, which is network equipment for ISPs written in LuaJIT with a little assembler.

June 9, 2017

Re: [Pharo-dev] [Pharo-users] Pharo6 server deployment and no home directory

by Holger Freyther

> On 9. Jun 2017, at 13:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: Hey, > Why would $HOME not be set ? In this specific case runit doesn't export HOME when starting my service but looking at systemd and picking a random service like exim4.service I see: $ strings /proc/946/environ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LANG=C _SYSTEMCTL_SKIP_REDIRECT=true PWD=/ I think it is safe to assume this applies to other services started by systemd as well. > And if it is not set / seems like a reasonable default. In Shell it would be "" but with >>resolveString: '' it seems to be / but that seems to be fair enough. E.g. as {home} / '.config' is used anyway. holger

June 9, 2017

Re: [Pharo-dev] [Pharo-users] Pharo6 server deployment and no home directory

by Sven Van Caekenberghe

Why would $HOME not be set ? And if it is not set / seems like a reasonable default. > On 9 Jun 2017, at 06:06, Holger Freyther <holger(a)freyther.de> wrote: > > >> On 9. Jun 2017, at 11:09, Holger Freyther <holger(a)freyther.de> wrote: >> >> > > >> a.) Behave like unix and resolve $HOME to '' >> >> $ unset HOME >> $ echo $HOME/.config >> /.config >> >> self home / '.config' => '/.config' > > > Implementing UnixResolver>>#home as > > home > ^ self directoryFromEnvVariableNamed: 'HOME' or: [self resolveString: ''] > > will lead to something creating /.config/pharo (if possible). By itself this change is not good enough but when adding --no-default-preferences. > > > Comments? Opinions? > > holger > > >

June 9, 2017

Re: [Pharo-dev] [Pharo-users] Pharo6 server deployment and no home directory

by Holger Freyther

> On 9. Jun 2017, at 11:09, Holger Freyther <holger(a)freyther.de> wrote: > > > a.) Behave like unix and resolve $HOME to '' > > $ unset HOME > $ echo $HOME/.config > /.config > > self home / '.config' => '/.config' Implementing UnixResolver>>#home as home ^ self directoryFromEnvVariableNamed: 'HOME' or: [self resolveString: ''] will lead to something creating /.config/pharo (if possible). By itself this change is not good enough but when adding --no-default-preferences. Comments? Opinions? holger

June 9, 2017